9.9.0rc2

249 files changed, 28298 insertions, 157787 deletions

diff --git a/CHANGES b/CHANGES
index ab6060de..ded8bc2a 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,3 +1,39 @@
+	--- 9.9.0rc2 released ---
+
+3270.	[bug]		"rndc reload" didn't reuse existing zones correctly
+			when inline-signing was in use. [RT #27650]
+
+3269.	[port]		darwin 11 and later now built threaded by default.
+
+3268.	[bug]		Convert RRSIG expiry times to 64 timestamps to work
+			out the earliest expiry time. [RT #23311]
+
+3267.	[bug]		Memory allocation failures could be mis-reported as
+			unexpected error.  New ISC_R_UNSET result code.
+			[RT #27336]
+
+3266.	[bug]		The maximum number of NSEC3 iterations for a
+			DNSKEY RRset was not being properly computed.
+			[RT #26543]
+
+3265.	[bug]		Corrected a problem with lock ordering in the
+			inline-signing code. [RT #27557]
+
+3264.	[bug]		Automatic regeneration of signatures in an
+			inline-signing zone could stall when the server
+			was restarted. [RT #27344]
+
+3263.	[bug]		"rndc sync" did not affect the unsigned side of an
+			inline-signing zone. [RT #27337]
+
+3262.	[bug]		Signed responses were handled incorrectly by RPZ.
+			[RT #27316]
+
+3261.	[func]		RRset ordering now defaults to random. [RT #27174]
+
+3260.	[bug]		"rrset-order cyclic" could appear not to rotate
+			for some query patterns.  [RT #27170/27185]
+
 	--- 9.9.0rc1 released ---
 
 3259.	[bug]		named-compilezone: Suppress "dump zone to <file>"
@@ -53,7 +89,7 @@
 			ixfr-fromdifferences. [RT #26845]
 
 3244.	[func]		Added readline support to nslookup and nsupdate.
-			Also simplified nsupdate syntax to make "update" 
+			Also simplified nsupdate syntax to make "update"
 			and "prereq" optional. [RT #24659]
 
 3243.	[port]		freebsd,netbsd,bsdi: the thread defaults were not
@@ -66,9 +102,9 @@
 			inline-signing zones, to track changes between the
 			unsigned and signed versions of the zone, which may
 			have different serial numbers.
-			
+
 			(Note: raw zonefiles generated by this version of
-			BIND are no longer compatble with prior versions. 
+			BIND are no longer compatble with prior versions.
 			To generate a backward-compatible raw zonefile
 			using dnssec-signzone or named-compilezone, specify
 			output format "raw=0" instead of simply "raw".)
@@ -111,8 +147,8 @@
 3229.	[bug]		Fix local variable to struct var assignment
 			found by CLANG warning.
 
-3228.   [tuning]        Dynamically grow symbol table to improve zone
-                        loading performance. [RT #26523]
+3228.	[tuning]	Dynamically grow symbol table to improve zone
+			loading performance. [RT #26523]
 
 3227.	[bug]		Interim fix to make WKS's use of getprotobyname()
 			and getservbyname() self thread safe. [RT #26232]
@@ -137,8 +173,8 @@
 	--- 9.9.0b2 released ---
 
 3220.	[bug]		Change #3186 was incomplete; dns_db_rpz_findips()
-                        could fail to set the database version correctly,
-                        causing an assertion failure. [RT #26180]
+			could fail to set the database version correctly,
+			causing an assertion failure. [RT #26180]
 
 3219.	[bug]		Disable NOEDNS caching following a timeout.
 
@@ -154,12 +190,12 @@
 
 3214.	[func]		Add 'named -U' option to set the number of UDP
 			listener threads per interface. [RT #26485]
-			
+
 3213.	[doc]		Clarify ixfr-from-differences behavior. [RT #25188]
 
-3212.	[bug]		rbtdb.c: failed to remove a node from the deadnodes list
-			prior to adding a reference to it leading a possible
-			assertion failure. [RT #23219]
+3212.	[bug]		rbtdb.c: failed to remove a node from the deadnodes
+			list prior to adding a reference to it leading a
+			possible assertion failure. [RT #23219]
 
 3211.	[func]		dnssec-signzone: "-f -" prints to stdout; "-O full"
 			option prints in single-line-per-record format.
@@ -204,11 +240,11 @@
 3198.	[doc]		Clarified that dnssec-settime can alter keyfile
 			permissions. [RT #24866]
 
-3197.	[bug]		Don't try to log the filename and line number when 
+3197.	[bug]		Don't try to log the filename and line number when
 			the config parser can't open a file. [RT #22263]
 
-3196.   [bug]           nsupdate: return nonzero exit code when target zone
-                        doesn't exist. [RT #25783]
+3196.	[bug]		nsupdate: return nonzero exit code when target zone
+			doesn't exist. [RT #25783]
 
 3195.	[cleanup]	Silence "file not found" warnings when loading
 			managed-keys zone. [RT #26340]
@@ -228,12 +264,12 @@
 			[RT #26397]
 
 3189.	[test]		Added a summary report after system tests. [RT #25517]
-			
+
 3188.	[bug]		zone.c:zone_refreshkeys() could fail to detach
 			references correctly when errors occurred, causing
 			a hang on shutdown. [RT #26372]
 
-3187.	[port]		win32: support for Visual Studio 2008.	[RT #26356]
+3187.	[port]		win32: support for Visual Studio 2008.  [RT #26356]
 
 	--- 9.9.0b1 released ---
 
@@ -243,7 +279,7 @@
 			 - 'rndc signing -list' displays the current
 			   state of signing operations
 			 - 'rndc signing -clear' clears the signing state
-		  	   records for keys that have fully signed the zone
+			   records for keys that have fully signed the zone
 			 - 'rndc signing -nsec3param' sets the NSEC3
 			   parameters for the zone
 			The 'rndc keydone' syntax is removed. [RT #23729]
@@ -253,7 +289,7 @@
 
 3183.	[bug]		Added RTLD_GLOBAL flag to dlopen call. [RT #26301]
 
-3182.   [bug]		Auth servers behind firewalls which block packets
+3182.	[bug]		Auth servers behind firewalls which block packets
 			greater than 512 bytes may cause other servers to
 			perform poorly. Now, adb retains edns information
 			and caches noedns servers. [RT #23392/24964]
@@ -279,7 +315,7 @@
 			sample external DLZ module in contrib/dlz/example.
 			[RT #26215]
 
-3175.   [bug]           Fix how DNSSEC positive wildcard responses from a
+3175.	[bug]		Fix how DNSSEC positive wildcard responses from a
 			NSEC3 signed zone are validated.  Stop sending a
 			unnecessary NSEC3 record when generating such
 			responses. [RT #26200]
@@ -304,8 +340,9 @@
 			- new "rpz" logging channel
 			- RDATA for CNAME rules can include wildcards
 			- replace "NO-OP" named.conf policy override with
-			    "PASSTHRU" and add "DELETED" override (NO-OP is
-			    still recognized)
+			  "PASSTHRU" and add "DISABLED" override ("NO-OP"
+			  is still recognized)
+			[RT #25172]
 
 3169.	[func]		Catch db/version mis-matches when calling dns_db_*().
 			[RT #26017]
@@ -342,7 +379,7 @@
 3160.	[bug]		When printing out a NSEC3 record in multiline form
 			the newline was not being printed causing type codes
 			to be run together. [RT #25873]
-			
+
 3159.	[bug]		On some platforms, named could assert on startup
 			when running in a chrooted environment without
 			/proc. [RT #25863]
@@ -371,7 +408,7 @@
 			incorrect use of __builtin_expect. [RT #25183]
 
 3151.	[bug]		Queries for type RRSIG or SIG could be handled
-                        incorrectly.  [RT #21050]
+			incorrectly.  [RT #21050]
 
 3150.	[func]		Improved startup and reconfiguration time by
 			enabling zones to load in multiple threads. [RT #25333]
@@ -385,7 +422,7 @@
 
 	--- 9.9.0a1 released ---
 
-3146.   [test]		Fixed gcc4.6.0 errors in ATF. [RT #25598]
+3146.	[test]		Fixed gcc4.6.0 errors in ATF. [RT #25598]
 
 3145.	[test]		Capture output of ATF unit tests in "./atf.out" if
 			there were any errors while running them. [RT #25527]
@@ -400,13 +437,13 @@
 3141.	[bug]		Silence spurious "zone serial (0) unchanged" messages
 			associated with empty zones. [RT #25079]
 
-3140.	[func]		New command "rndc flushtree <name>" clears the 
+3140.	[func]		New command "rndc flushtree <name>" clears the
 			specified name from the server cache along with
 			all names under it. [RT #19970]
 
 3139.	[test]		Added tests from RFC 6234, RFC 2202, and RFC 1321
 			for the hashing algorithms (md5, sha1 - sha512, and
-			their hmac counterparts).  [RT #25067] 
+			their hmac counterparts).  [RT #25067]
 
 3138.	[bug]		Address memory leaks and out-of-order operations when
 			shutting named down. [RT #25210]
@@ -416,7 +453,7 @@
 			This can significantly increase query throughput
 			on some systems.  [RT #22992]
 
-3136.	[func]		Add RFC 1918 reverse zones to the list of built-in 
+3136.	[func]		Add RFC 1918 reverse zones to the list of built-in
 			empty zones switched on by the 'empty-zones-enable'
 			option. [RT #24990]
 
@@ -474,10 +511,10 @@
 
 3122.	[cleanup]	dnssec-settime: corrected usage message. [RT #24664]
 
-3121.   [security]      An authoritative name server sending a negative
-                        response containing a very large RRset could
-                        trigger an off-by-one error in the ncache code
-                        and crash named. [RT #24650]
+3121.	[security]	An authoritative name server sending a negative
+			response containing a very large RRset could
+			trigger an off-by-one error in the ncache code
+			and crash named. [RT #24650]
 
 3120.	[bug]		Named could fail to validate zones listed in a DLV
 			that validated insecure without using DLV and had
@@ -515,9 +552,9 @@
 			"krb5-subdomain", which allow machines to update
 			their own records, to the BIND 9 ARM.
 
-3111.   [bug]           Improved consistency checks for dnssec-enable and
-                        dnssec-validation, added test cases to the
-                        checkconf system test. [RT #24398]
+3111.	[bug]		Improved consistency checks for dnssec-enable and
+			dnssec-validation, added test cases to the
+			checkconf system test. [RT #24398]
 
 3110.	[bug]		dnssec-signzone: Wrong error message could appear
 			when attempting to sign with no KSK. [RT #24369]
@@ -532,17 +569,17 @@
 3108.	[cleanup]	dnssec-signzone: Clarified some error and
 			warning messages; removed #ifdef ALLOW_KSKLESS_ZONES
 			code (use -P instead). [RT #20852]
-			
+
 3107.	[bug]		dnssec-signzone: Report the correct number of ZSKs
 			when using -x. [RT #20852]
 
 3106.	[func]		When logging client requests, include the name of
 			the TSIG key if any. [RT #23619]
 
-3105.   [bug]           GOST support can be suppressed by "configure
-                        --without-gost" [RT #24367]
+3105.	[bug]		GOST support can be suppressed by "configure
+			--without-gost" [RT #24367]
 
-3104.   [bug]           Better support for cross-compiling. [RT #24367]
+3104.	[bug]		Better support for cross-compiling. [RT #24367]
 
 3103.	[bug]		Configuring 'dnssec-validation auto' in a view
 			instead of in the options statement could trigger
@@ -553,7 +590,7 @@
 			for updates when using automatic key maintenance.
 			Default is every 60 minutes (formerly hard-coded
 			to 12 hours). [RT #23744]
-			
+
 3101.	[bug]		Zones using automatic key maintenance could fail
 			to check the key repository for updates. [RT #23744]
 
@@ -749,9 +786,9 @@
 
 3043.	[test]		Merged in the NetBSD ATF test framework (currently
 			version 0.12) for development of future unit tests.
-                        Use configure --with-atf to build ATF internally
-                        or configure --with-atf=prefix to use an external
-                        copy.  [RT #23209]
+			Use configure --with-atf to build ATF internally
+			or configure --with-atf=prefix to use an external
+			copy.  [RT #23209]
 
 3042.	[bug]		dig +trace could fail attempting to use IPv6
 			addresses on systems with only IPv4 connectivity.
@@ -1187,7 +1224,7 @@
 2929.	[bug]		Improved handling of GSS security contexts:
 			 - added LRU expiration for generated TSIGs
 			 - added the ability to use a non-default realm
-                         - added new "realm" keyword in nsupdate
+			 - added new "realm" keyword in nsupdate
 			 - limited lifetime of generated keys to 1 hour
 			   or the lifetime of the context (whichever is
 			   smaller)
@@ -2016,7 +2053,7 @@
 			--with-export-includedir. [RT #20252]
 
 2675.	[bug]		dnssec-signzone could crash if the key directory
-                        did not exist. [RT #20232]
+			did not exist. [RT #20232]
 
 	--- 9.7.0a3 released ---
 
@@ -2107,7 +2144,7 @@
 			64-bit systems. [RT #20076]
 
 2650.	[bug]		Assertion failure in dnssec-signzone when trying
-                        to read keyset-* files. [RT #20075]
+			to read keyset-* files. [RT #20075]
 
 2649.	[bug]		Set the domain for forward only zones. [RT #19944]
 
@@ -2179,7 +2216,7 @@
 2630.	[func]		Improved syntax for DDNS autoconfiguration:  use
 			"update-policy local;" to switch on local DDNS in a
 			zone. (The "ddns-autoconf" option has been removed.)
-                        [RT #19875]
+			[RT #19875]
 
 2629.	[port]		Check for seteuid()/setegid(), use setresuid()/
 			setresgid() if not present. [RT #19932]
@@ -2864,10 +2901,10 @@
 			time. [RT #18277]
 
 2423.	[security]	Randomize server selection on queries, so as to
-                        make forgery a little more difficult.  Instead of
-                        always preferring the server with the lowest RTT,
-                        pick a server with RTT within the same 128
-                        millisecond band.  [RT #18441]
+			make forgery a little more difficult.  Instead of
+			always preferring the server with the lowest RTT,
+			pick a server with RTT within the same 128
+			millisecond band.  [RT #18441]
 
 2422.	[bug]		Handle the special return value of a empty node as
 			if it was a NXRRSET in the validator. [RT #18447]
@@ -2948,7 +2985,7 @@
 
 2399.	[placeholder]
 
-2398.	[bug]           Improve file descriptor management.  New,
+2398.	[bug]		Improve file descriptor management.  New,
 			temporary, named.conf option reserved-sockets,
 			default 512. [RT #18344]
 
diff --git a/COPYRIGHT b/COPYRIGHT
index ebbe7886..8342938a 100644
--- a/COPYRIGHT
+++ b/COPYRIGHT
@@ -1,4 +1,4 @@
-Copyright (C) 2004-2011  Internet Systems Consortium, Inc. ("ISC")
+Copyright (C) 2004-2012  Internet Systems Consortium, Inc. ("ISC")
 Copyright (C) 1996-2003  Internet Software Consortium.
 
 Permission to use, copy, modify, and/or distribute this software for any
@@ -13,7 +13,7 @@ LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 PERFORMANCE OF THIS SOFTWARE.
 
-$Id: COPYRIGHT,v 1.18 2011-02-22 06:29:42 marka Exp $
+$Id: COPYRIGHT,v 1.19 2012-01-03 23:46:59 tbox Exp $
 
 	Portions of this code release fall under one or more of the
 	following Copyright notices.  Please see individual source
diff --git a/bin/named/builtin.c b/bin/named/builtin.c
index c41bf786..5882249c 100644
--- a/bin/named/builtin.c
+++ b/bin/named/builtin.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007, 2009-2011  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009-2012  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: builtin.c,v 1.22 2011-10-11 02:39:03 marka Exp $ */
+/* $Id: builtin.c,v 1.26 2012-01-21 19:44:18 each Exp $ */
 
 /*! \file
  * \brief
@@ -303,8 +303,10 @@ do_authors_lookup(dns_sdblookup_t *lookup) {
 	const char **p;
 	static const char *authors[] = {
 		"Mark Andrews",
+		"Curtis Blackburn",
 		"James Brister",
 		"Ben Cottrell",
+		"John H. DuBois III",
 		"Francis Dupont",
 		"Michael Graff",
 		"Andreas Gustafsson",
@@ -312,6 +314,7 @@ do_authors_lookup(dns_sdblookup_t *lookup) {
 		"Evan Hunt",
 		"JINMEI Tatuya",
 		"David Lawrence",
+		"Scott Mann",
 		"Danny Mayer",
 		"Damien Neil",
 		"Matt Nelson",
diff --git a/bin/named/config.c b/bin/named/config.c
index 91e3eb2a..671e03b9 100644
--- a/bin/named/config.c
+++ b/bin/named/config.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2011  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2012  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: config.c,v 1.121 2011-08-30 23:46:51 tbox Exp $ */
+/* $Id: config.c,v 1.123 2012-01-06 23:46:41 tbox Exp $ */
 
 /*! \file */
 
@@ -90,7 +90,7 @@ options {\n\
 "\
 	recursive-clients 1000;\n\
 	resolver-query-timeout 30;\n\
-	rrset-order {type NS order random; order cyclic; };\n\
+	rrset-order { order random; };\n\
 	serial-queries 20;\n\
 	serial-query-rate 20;\n\
 	server-id none;\n\
diff --git a/bin/named/query.c b/bin/named/query.c
index cc422657..6002c365 100644
--- a/bin/named/query.c
+++ b/bin/named/query.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2011  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2012  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: query.c,v 1.378 2011-11-16 09:44:31 each Exp $ */
+/* $Id: query.c,v 1.381 2012-01-07 00:19:59 each Exp $ */
 
 /*! \file */
 
@@ -1126,7 +1126,8 @@ query_isduplicate(ns_client_t *client, dns_name_t *name,
 	if (name == mname)
 		mname = NULL;
 
-	*mnamep = mname;
+	if (mnamep != NULL)
+		*mnamep = mname;
 
 	CTRACE("query_isduplicate: false: done");
 	return (ISC_FALSE);
@@ -1373,6 +1374,8 @@ query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 			if (sigrdataset == NULL)
 				goto addname;
 		}
+		if (query_isduplicate(client, fname, dns_rdatatype_a, NULL))
+			goto aaaa_lookup;
 		result = dns_db_findrdataset(db, node, version,
 					     dns_rdatatype_a, 0,
 					     client->now,
@@ -1416,6 +1419,9 @@ query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 					dns_rdataset_disassociate(sigrdataset);
 			}
 		}
+  aaaa_lookup:
+		if (query_isduplicate(client, fname, dns_rdatatype_aaaa, NULL))
+			goto addname;
 		result = dns_db_findrdataset(db, node, version,
 					     dns_rdatatype_aaaa, 0,
 					     client->now,
@@ -1583,7 +1589,13 @@ query_addadditional2(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 	dns_clientinfomethods_t cm;
 	dns_clientinfo_t ci;
 
-	if (qtype != dns_rdatatype_a) {
+	/*
+	 * If we don't have an additional cache call query_addadditional.
+	 */
+	client = additionalctx->client;
+	REQUIRE(NS_CLIENT_VALID(client));
+
+	if (qtype != dns_rdatatype_a || client->view->acache == NULL) {
 		/*
 		 * This function is optimized for "address" types.  For other
 		 * types, use a generic routine.
@@ -1597,8 +1609,6 @@ query_addadditional2(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 	 * Initialization.
 	 */
 	rdataset_base = additionalctx->rdataset;
-	client = additionalctx->client;
-	REQUIRE(NS_CLIENT_VALID(client));
 	eresult = ISC_R_SUCCESS;
 	fname = NULL;
 	rdataset = NULL;
@@ -1857,6 +1867,9 @@ query_addadditional2(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 	if (sigrdataset == NULL)
 		goto cleanup;
 
+	if (additionaltype == dns_rdatasetadditional_fromcache &&
+	    query_isduplicate(client, fname, dns_rdatatype_a, NULL))
+		goto aaaa_lookup;
 	/*
 	 * Find A RRset with sig RRset.  Even if we don't find a sig RRset
 	 * for a client using DNSSEC, we'll continue the process to make a
@@ -1901,6 +1914,10 @@ query_addadditional2(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 		}
 	}
 
+ aaaa_lookup:
+	if (additionaltype == dns_rdatasetadditional_fromcache &&
+	    query_isduplicate(client, fname, dns_rdatatype_aaaa, NULL))
+		goto foundcache;
 	/* Find AAAA RRset with sig RRset */
 	result = dns_db_findrdataset(db, node, version, dns_rdatatype_aaaa,
 				     0, client->now, rdataset, sigrdataset);
@@ -5642,6 +5659,8 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 
 	if (!ISC_LIST_EMPTY(client->view->rpz_zones) &&
 	    RECURSIONOK(client) && !RECURSING(client) &&
+	    (!WANTDNSSEC(client) || sigrdataset == NULL ||
+	     !dns_rdataset_isassociated(sigrdataset)) &&
 	    (client->query.rpz_st == NULL ||
 	     (client->query.rpz_st->state & DNS_RPZ_REWRITTEN) == 0) &&
 	    !dns_name_equal(client->query.qname, dns_rootname)) {
diff --git a/bin/named/server.c b/bin/named/server.c
index 6f593aaf..fd2e72ab 100644
--- a/bin/named/server.c
+++ b/bin/named/server.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2011  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2012  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: server.c,v 1.634 2011-12-22 12:58:13 marka Exp $ */
+/* $Id: server.c,v 1.638.4.1 2012-01-31 01:11:54 each Exp $ */
 
 /*! \file */
 
@@ -3406,6 +3406,7 @@ configure_zone(const cfg_obj_t *config, const cfg_obj_t *zconfig,
 		result = dns_view_findzone(pview, origin, &zone);
 	if (result != ISC_R_NOTFOUND && result != ISC_R_SUCCESS)
 		goto cleanup;
+
 	if (zone != NULL && !ns_zone_reusable(zone, zconfig))
 		dns_zone_detach(&zone);
 
@@ -3472,10 +3473,8 @@ configure_zone(const cfg_obj_t *config, const cfg_obj_t *zconfig,
 			dns_zone_setview(raw, view);
 			if (view->acache != NULL)
 				dns_zone_setacache(raw, view->acache);
-			CHECK(dns_zonemgr_managezone(ns_g_server->zonemgr,
-						 raw));
 			dns_zone_setstats(raw, ns_g_server->zonestats);
-			dns_zone_link(zone, raw);
+			CHECK(dns_zone_link(zone, raw));
 		}
 	}
 
@@ -7256,8 +7255,15 @@ static isc_result_t
 synczone(dns_zone_t *zone, void *uap) {
 	isc_boolean_t cleanup = *(isc_boolean_t *)uap;
 	isc_result_t result;
+	dns_zone_t *raw = NULL;
 	char *journal;
 
+	dns_zone_getraw(zone, &raw);
+	if (raw != NULL) {
+		synczone(raw, uap);
+		dns_zone_detach(&raw);
+	}
+
 	result = dns_zone_flush(zone);
 	if (result != ISC_R_SUCCESS)
 		cleanup = ISC_FALSE;
@@ -7266,6 +7272,7 @@ synczone(dns_zone_t *zone, void *uap) {
 		if (journal != NULL)
 			(void)isc_file_remove(journal);
 	}
+
 	return (result);
 }
 
@@ -7950,20 +7957,14 @@ ns_server_signing(ns_server_t *server, char *args, isc_buffer_t *text) {
 		CHECK(ISC_R_UNEXPECTEDEND);
 
 	if (clear) {
-		result = dns_zone_keydone(zone, keystr);
-		if (result == ISC_R_SUCCESS) {
-			isc_buffer_putstr(text, "request queued");
-			isc_buffer_putuint8(text, 0);
-		} else
-			CHECK(result);
+		CHECK(dns_zone_keydone(zone, keystr));
+		isc_buffer_putstr(text, "request queued");
+		isc_buffer_putuint8(text, 0);
 	} else if (chain) {
-		result = dns_zone_setnsec3param(zone, hash, flags, iter,
-						saltlen, salt, ISC_TRUE);
-		if (result == ISC_R_SUCCESS) {
-			isc_buffer_putstr(text, "request queued");
-			isc_buffer_putuint8(text, 0);
-		} else
-			CHECK(result);
+		CHECK(dns_zone_setnsec3param(zone, hash, flags, iter,
+						saltlen, salt, ISC_TRUE));
+		isc_buffer_putstr(text, "request queued");
+		isc_buffer_putuint8(text, 0);
 	} else if (list) {
 		privatetype = dns_zone_getprivatetype(zone);
 		origin = dns_zone_getorigin(zone);
diff --git a/bin/named/zoneconf.c b/bin/named/zoneconf.c
index 7fa939cf..0b037878 100644
--- a/bin/named/zoneconf.c
+++ b/bin/named/zoneconf.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zoneconf.c,v 1.186 2011-12-20 00:06:54 marka Exp $ */
+/* $Id: zoneconf.c,v 1.186.22.1 2012-01-31 01:11:54 each Exp $ */
 
 /*% */
 
@@ -1600,44 +1600,65 @@ ns_zone_reusable(dns_zone_t *zone, const cfg_obj_t *zconfig) {
 	const char *zfilename;
 	dns_zone_t *raw = NULL;
 	isc_boolean_t has_raw;
+	dns_zonetype_t ztype;
 
 	zoptions = cfg_tuple_get(zconfig, "options");
 
-	if (zonetype_fromconfig(zoptions) != dns_zone_gettype(zone))
-		return (ISC_FALSE);
-
 	/*
 	 * We always reconfigure a static-stub zone for simplicity, assuming
 	 * the amount of data to be loaded is small.
 	 */
-	if (zonetype_fromconfig(zoptions) == dns_zone_staticstub)
-		return (ISC_FALSE);
-
-	obj = NULL;
-	(void)cfg_map_get(zoptions, "file", &obj);
-	if (obj != NULL)
-		cfilename = cfg_obj_asstring(obj);
-	else
-		cfilename = NULL;
-	zfilename = dns_zone_getfile(zone);
-	if (!((cfilename == NULL && zfilename == NULL) ||
-	      (cfilename != NULL && zfilename != NULL &&
-	       strcmp(cfilename, zfilename) == 0)))
+	if (zonetype_fromconfig(zoptions) == dns_zone_staticstub) {
+		dns_zone_log(zone, ISC_LOG_DEBUG(1),
+			     "not reusable: staticstub");
 		return (ISC_FALSE);
+	}
 
+	/* If there's a raw zone, use that for filename and type comparison */
 	dns_zone_getraw(zone, &raw);
 	if (raw != NULL) {
+		zfilename = dns_zone_getfile(raw);
+		ztype = dns_zone_gettype(raw);
 		dns_zone_detach(&raw);
 		has_raw = ISC_TRUE;
-	} else
+	} else {
+		zfilename = dns_zone_getfile(zone);
+		ztype = dns_zone_gettype(zone);
 		has_raw = ISC_FALSE;
+	}
 
 	obj = NULL;
 	(void)cfg_map_get(zoptions, "inline-signing", &obj);
-	if ((obj == NULL || !cfg_obj_asboolean(obj)) && has_raw)
+	if ((obj == NULL || !cfg_obj_asboolean(obj)) && has_raw) {
+		dns_zone_log(zone, ISC_LOG_DEBUG(1),
+			     "not reusable: old zone was inline-signing");
 		return (ISC_FALSE);
-	if ((obj != NULL && cfg_obj_asboolean(obj)) && !has_raw)
+	} else if ((obj != NULL && cfg_obj_asboolean(obj)) && !has_raw) {
+		dns_zone_log(zone, ISC_LOG_DEBUG(1),
+			     "not reusable: old zone was not inline-signing");
 		return (ISC_FALSE);
+	}
+
+	if (zonetype_fromconfig(zoptions) != ztype) {
+		dns_zone_log(zone, ISC_LOG_DEBUG(1),
+			     "not reusable: type mismatch");
+		return (ISC_FALSE);
+	}
+
+	obj = NULL;
+	(void)cfg_map_get(zoptions, "file", &obj);
+	if (obj != NULL)
+		cfilename = cfg_obj_asstring(obj);
+	else
+		cfilename = NULL;
+	if (!((cfilename == NULL && zfilename == NULL) ||
+	      (cfilename != NULL && zfilename != NULL &&
+	       strcmp(cfilename, zfilename) == 0)))
+	{
+		dns_zone_log(zone, ISC_LOG_DEBUG(1),
+			     "not reusable: filename mismatch");
+		return (ISC_FALSE);
+	}
 
 	return (ISC_TRUE);
 }
diff --git a/bin/pkcs11/openssl-0.9.8l-patch b/bin/pkcs11/openssl-0.9.8s-patch
index f410f468..cdf12342 100644
--- a/bin/pkcs11/openssl-0.9.8l-patch
+++ b/bin/pkcs11/openssl-0.9.8s-patch
@@ -1,7 +1,7 @@
 Index: openssl/Configure
-diff -u openssl/Configure:1.1.3.1 openssl/Configure:1.7
---- openssl/Configure:1.1.3.1	Mon Feb 16 08:44:22 2009
-+++ openssl/Configure	Mon Oct  5 13:16:50 2009
+diff -u openssl/Configure:1.8.6.1 openssl/Configure:1.8
+--- openssl/Configure:1.8.6.1	Sun Jan 15 15:45:33 2012
++++ openssl/Configure	Mon Jun 13 14:25:15 2011
 @@ -12,7 +12,7 @@
  
  # see INSTALL for instructions.
@@ -11,9 +11,9 @@ diff -u openssl/Configure:1.1.3.1 openssl/Configure:1.7
  
  # Options:
  #
-@@ -21,6 +21,12 @@
- # --prefix      prefix for the OpenSSL include, lib and bin directories
- #               (Default: the OPENSSLDIR directory)
+@@ -25,6 +25,12 @@
+ #               default).  This needn't be set in advance, you can
+ #               just as well use "make INSTALL_PREFIX=/whatever install".
  #
 +# --pk11-libname  PKCS#11 library name.
 +#               (No default)
@@ -21,10 +21,10 @@ diff -u openssl/Configure:1.1.3.1 openssl/Configure:1.7
 +# --pk11-flavor either crypto-accelerator or sign-only
 +#               (No default)
 +#
- # --install_prefix  Additional prefix for package builders (empty by
- #               default).  This needn't be set in advance, you can
- #               just as well use "make INSTALL_PREFIX=/whatever install".
-@@ -329,7 +335,7 @@
+ # --with-krb5-dir  Declare where Kerberos 5 lives.  The libraries are expected
+ #		to live in the subdirectory lib/ and the header files in
+ #		include/.  A value is required.
+@@ -335,7 +341,7 @@
  "linux-ppc",	"gcc:-DB_ENDIAN -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_RISC1 DES_UNROLL::linux_ppc32.o::::::::::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
  #### IA-32 targets...
  "linux-ia32-icc",	"icc:-DL_ENDIAN -DTERMIO -O2 -no_cpprt::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-KPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
@@ -33,16 +33,16 @@ diff -u openssl/Configure:1.1.3.1 openssl/Configure:1.7
  "linux-aout",	"gcc:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -march=i486 -Wall::(unknown):::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_out_asm}",
  ####
  "linux-generic64","gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
-@@ -337,7 +343,7 @@
+@@ -343,7 +349,7 @@
  "linux-ia64",	"gcc:-DL_ENDIAN -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK:${ia64_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
  "linux-ia64-ecc","ecc:-DL_ENDIAN -DTERMIO -O2 -Wall -no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK:${ia64_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
  "linux-ia64-icc","icc:-DL_ENDIAN -DTERMIO -O2 -Wall -no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK:${ia64_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
--"linux-x86_64",	"gcc:-m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK BF_PTR2 DES_INT DES_UNROLL:${x86_64_asm}:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
-+"linux-x86_64",	"gcc:-m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int::-D_REENTRANT -pthread::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK BF_PTR2 DES_INT DES_UNROLL:${x86_64_asm}:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+-"linux-x86_64",	"gcc:-m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
++"linux-x86_64",	"gcc:-m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int::-D_REENTRANT -pthread::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
  #### SPARC Linux setups
  # Ray Miller <ray.miller@computing-services.oxford.ac.uk> has patiently
  # assisted with debugging of following two configs.
-@@ -580,6 +586,10 @@
+@@ -590,6 +596,10 @@
  my $idx_ranlib = $idx++;
  my $idx_arflags = $idx++;
  
@@ -51,16 +51,16 @@ diff -u openssl/Configure:1.1.3.1 openssl/Configure:1.7
 +my $pk11_flavor="";
 +
  my $prefix="";
+ my $libdir="";
  my $openssldir="";
- my $exe_ext="";
-@@ -812,6 +822,14 @@
+@@ -828,6 +838,14 @@
  				{
  				$flags.=$_." ";
  				}
-+                        elsif (/^--pk11-libname=(.*)$/)
-+                                {
-+                                $pk11_libname=$1;
-+                                }
++			elsif (/^--pk11-libname=(.*)$/)
++				{
++				$pk11_libname=$1;
++				}
 +			elsif (/^--pk11-flavor=(.*)$/)
 +				{
 +				$pk11_flavor=$1;
@@ -68,7 +68,7 @@ diff -u openssl/Configure:1.1.3.1 openssl/Configure:1.7
  			elsif (/^--prefix=(.*)$/)
  				{
  				$prefix=$1;
-@@ -943,6 +961,22 @@
+@@ -963,6 +981,22 @@
  	exit 0;
  }
  
@@ -91,7 +91,7 @@ diff -u openssl/Configure:1.1.3.1 openssl/Configure:1.7
  if ($target =~ m/^CygWin32(-.*)$/) {
  	$target = "Cygwin".$1;
  }
-@@ -1057,6 +1091,25 @@
+@@ -1078,6 +1112,25 @@
  	print "\n";
  	}
  
@@ -117,7 +117,7 @@ diff -u openssl/Configure:1.1.3.1 openssl/Configure:1.7
  my $IsMK1MF=scalar grep /^$target$/,@MK1MF_Builds;
  
  $IsMK1MF=1 if ($target eq "mingw" && $^O ne "cygwin" && !is_msys());
-@@ -1103,6 +1156,8 @@
+@@ -1129,6 +1182,8 @@
  if ($flags ne "")	{ $cflags="$flags$cflags"; }
  else			{ $no_user_cflags=1;       }
  
@@ -126,7 +126,7 @@ diff -u openssl/Configure:1.1.3.1 openssl/Configure:1.7
  # Kerberos settings.  The flavor must be provided from outside, either through
  # the script "config" or manually.
  if (!$no_krb5)
-@@ -1456,6 +1511,7 @@
+@@ -1492,6 +1547,7 @@
  	s/^VERSION=.*/VERSION=$version/;
  	s/^MAJOR=.*/MAJOR=$major/;
  	s/^MINOR=.*/MINOR=$minor/;
@@ -135,9 +135,9 @@ diff -u openssl/Configure:1.1.3.1 openssl/Configure:1.7
  	s/^SHLIB_VERSION_HISTORY=.*/SHLIB_VERSION_HISTORY=$shlib_version_history/;
  	s/^SHLIB_MAJOR=.*/SHLIB_MAJOR=$shlib_major/;
 Index: openssl/Makefile.org
-diff -u openssl/Makefile.org:1.1.3.1 openssl/Makefile.org:1.3
---- openssl/Makefile.org:1.1.3.1	Tue Mar  3 22:40:29 2009
-+++ openssl/Makefile.org	Fri Sep  4 10:43:21 2009
+diff -u openssl/Makefile.org:1.4.6.1 openssl/Makefile.org:1.4
+--- openssl/Makefile.org:1.4.6.1	Sun Jan 15 15:45:33 2012
++++ openssl/Makefile.org	Mon Jun 13 14:25:15 2011
 @@ -26,6 +26,9 @@
  INSTALL_PREFIX=
  INSTALLTOP=/usr/local/ssl
@@ -149,13 +149,15 @@ diff -u openssl/Makefile.org:1.1.3.1 openssl/Makefile.org:1.3
  OPENSSLDIR=/usr/local/ssl
  
 Index: openssl/README.pkcs11
-diff -u /dev/null openssl/README.pkcs11:1.6
---- /dev/null	Thu Dec 24 13:00:42 2009
-+++ openssl/README.pkcs11	Mon Oct  5 13:16:50 2009
-@@ -0,0 +1,247 @@
+diff -u /dev/null openssl/README.pkcs11:1.6.4.1
+--- /dev/null	Mon Jan 16 18:53:41 2012
++++ openssl/README.pkcs11	Mon Jun 13 18:27:39 2011
+@@ -0,0 +1,261 @@
 +ISC modified
 +============
 +
++The previous key naming scheme was kept for backward compatibility.
++
 +The PKCS#11 engine exists in two flavors, crypto-accelerator and
 +sign-only. The first one is from the Solaris patch and uses the
 +PKCS#11 device for all crypto operations it supports. The second
@@ -170,10 +172,10 @@ diff -u /dev/null openssl/README.pkcs11:1.6
 +Note it is mandatory to set a pk11-flavor (and only one) in
 +config/Configure.
 +
-+PKCS#11 engine support for OpenSSL 0.9.8j
++PKCS#11 engine support for OpenSSL 0.9.8l
 +=========================================
 +
-+[March 11, 2009]
++[Nov 19, 2009]
 +
 +Contents:
 +
@@ -187,19 +189,19 @@ diff -u /dev/null openssl/README.pkcs11:1.6
 +
 +This patch containing code available in OpenSolaris adds support for PKCS#11
 +engine into OpenSSL and implements PKCS#11 v2.20. It is to be applied against
-+OpenSSL 0.9.8j source code distribution as shipped by OpenSSL.Org. Your system
++OpenSSL 0.9.8l source code distribution as shipped by OpenSSL.Org. Your system
 +must provide PKCS#11 backend otherwise the patch is useless. You provide the
 +PKCS#11 library name during the build configuration phase, see below.
 +
 +Patch can be applied like this:
 +
 +	# NOTE: use gtar if on Solaris
-+	tar xfzv openssl-0.9.8j.tar.gz
++	tar xfzv openssl-0.9.8l.tar.gz
 +	# now download the patch to the current directory
 +	# ...
-+	cd openssl-0.9.8j
++	cd openssl-0.9.8l
 +	# NOTE: must use gpatch if on Solaris (is part of the system)
-+	patch -p1 < path-to/pkcs11_engine-0.9.8j.patch.2009-03-11
++	patch -p1 < path-to/pkcs11_engine-0.9.8l.patch.2009-11-19
 +
 +It is designed to support pure acceleration for RSA, DSA, DH and all the
 +symetric ciphers and message digest algorithms that PKCS#11 and OpenSSL share
@@ -219,14 +221,6 @@ diff -u /dev/null openssl/README.pkcs11:1.6
 +example of code that uses the PKCS#11 engine and deals with the fork-safety
 +problem (see engine.c and packet.c files if interested).
 +
-++------------------------------------------------------------------------------+
-+| NOTE: this patch version does NOT contain experimental code for accessing    |
-+| RSA keys stored in PKCS#11 key stores by reference. Some problems were found |
-+| (thanks to all who wrote me!) and due to my ENOTIME problem I may address    |
-+| those issues in a future version of the patch that will have that code back, |
-+| hopefully fixed.                                                             | 
-++------------------------------------------------------------------------------+
-+
 +You must provide the location of PKCS#11 library in your system to the
 +configure script. You will be instructed to do that when you try to run the
 +config script:
@@ -247,13 +241,13 @@ diff -u /dev/null openssl/README.pkcs11:1.6
 +output. If you see no PKCS#11 engine support check that the built openssl binary
 +and the PKCS#11 library from --pk11-libname don't conflict on 32/64 bits.
 +
-+This patch was tested on Solaris against PKCS#11 engine available from Solaris
-+Cryptographic Framework (Solaris 10 and OpenSolaris) and also on Linux using
-+PKCS#11 libraries from openCryptoki project (see openCryptoki website
-+http://sourceforge.net/projects/opencryptoki for more information). Some Linux
-+distributions even ship those libraries with the system. The patch should work
-+on any system that is supported by OpenSSL itself and has functional PKCS#11
-+library.
++The patch, during various phases of development, was tested on Solaris against
++PKCS#11 engine available from Solaris Cryptographic Framework (Solaris 10 and
++OpenSolaris) and also on Linux using PKCS#11 libraries from openCryptoki project
++(see openCryptoki website http://sourceforge.net/projects/opencryptoki for more
++information). Some Linux distributions even ship those libraries with the
++system. The patch should work on any system that is supported by OpenSSL itself
++and has functional PKCS#11 library.
 +
 +The patch contains "RSA Security Inc. PKCS #11 Cryptographic Token Interface
 +(Cryptoki)" - files cryptoki.h, pkcs11.h, pkcs11f.h and pkcs11t.h which are
@@ -266,6 +260,16 @@ diff -u /dev/null openssl/README.pkcs11:1.6
 +Revisions of the patch for 0.9.8 branch
 +=======================================
 +
++2009-11-19
++- adjusted for OpenSSL version 0.9.8l
++
++- bugs and RFEs:
++
++	6479874 OpenSSL should support RSA key by reference/hardware keystores
++	6896677 PKCS#11 engine's hw_pk11_err.h needs to be split
++	6732677 make check to trigger Solaris specific code automatic in the
++		PKCS#11 engine
++
 +2009-03-11
 +- adjusted for OpenSSL version 0.9.8j 
 +
@@ -376,6 +380,8 @@ diff -u /dev/null openssl/README.pkcs11:1.6
 +../libcrypto.a(hw_pk11.o): In function `pk11_library_init':
 +hw_pk11.c:(.text+0x20f5): undefined reference to `pthread_atfork'
 +
++Answer:
++
 +	- don't use "no-threads" when configuring
 +	- if you didn't then OpenSSL failed to create a threaded library by
 +	  default. You may manually edit Configure and try again. Look for the
@@ -391,6 +397,14 @@ diff -u /dev/null openssl/README.pkcs11:1.6
 +
 +....-O3 -fomit-frame-pointer -Wall::-D_REENTRANT -pthread::-ldl:.....
 +
++(2) I'm using MinGW/MSYS environment and get undeclared reference error for
++pthread_atfork() function when trying to build OpenSSL with the patch.
++
++Answer:
++
++	Sorry, pthread_atfork() is not implemented in the current pthread-win32
++	(as of Nov 2009). You can not use the patch there.
++
 +
 +Feedback
 +========
@@ -401,8 +415,8 @@ diff -u /dev/null openssl/README.pkcs11:1.6
 +Latest version should be always available on http://blogs.sun.com/janp.
 +
 Index: openssl/crypto/opensslconf.h
-diff -u openssl/crypto/opensslconf.h:1.1.3.1 openssl/crypto/opensslconf.h:1.5
---- openssl/crypto/opensslconf.h:1.1.3.1	Wed Mar 25 13:11:43 2009
+diff -u openssl/crypto/opensslconf.h:1.5.10.1 openssl/crypto/opensslconf.h:1.5
+--- openssl/crypto/opensslconf.h:1.5.10.1	Sun Jan 15 15:45:34 2012
 +++ openssl/crypto/opensslconf.h	Fri Sep  4 10:43:21 2009
 @@ -38,6 +38,9 @@
  
@@ -472,9 +486,9 @@ diff -u openssl/crypto/opensslconf.h:1.1.3.1 openssl/crypto/opensslconf.h:1.5
  
  /* These default values were supplied by
 Index: openssl/crypto/bio/bss_file.c
-diff -u openssl/crypto/bio/bss_file.c:1.1.3.1 openssl/crypto/bio/bss_file.c:1.4
---- openssl/crypto/bio/bss_file.c:1.1.3.1	Tue Dec 30 13:30:55 2008
-+++ openssl/crypto/bio/bss_file.c	Fri Nov 27 12:32:32 2009
+diff -u openssl/crypto/bio/bss_file.c:1.5.6.1 openssl/crypto/bio/bss_file.c:1.5
+--- openssl/crypto/bio/bss_file.c:1.5.6.1	Sun Jan 15 15:45:35 2012
++++ openssl/crypto/bio/bss_file.c	Mon Jun 13 14:25:17 2011
 @@ -125,7 +125,7 @@
  		{
  		SYSerr(SYS_F_FOPEN,get_last_sys_error());
@@ -485,9 +499,9 @@ diff -u openssl/crypto/bio/bss_file.c:1.1.3.1 openssl/crypto/bio/bss_file.c:1.4
  		else
  			BIOerr(BIO_F_BIO_NEW_FILE,ERR_R_SYS_LIB);
 Index: openssl/crypto/engine/Makefile
-diff -u openssl/crypto/engine/Makefile:1.1.3.1 openssl/crypto/engine/Makefile:1.5
---- openssl/crypto/engine/Makefile:1.1.3.1	Wed Sep 17 17:10:59 2008
-+++ openssl/crypto/engine/Makefile	Mon Oct  5 13:16:50 2009
+diff -u openssl/crypto/engine/Makefile:1.6.6.1 openssl/crypto/engine/Makefile:1.6
+--- openssl/crypto/engine/Makefile:1.6.6.1	Sun Jan 15 15:45:35 2012
++++ openssl/crypto/engine/Makefile	Mon Jun 13 14:25:19 2011
 @@ -21,12 +21,14 @@
  	eng_table.c eng_pkey.c eng_fat.c eng_all.c \
  	tb_rsa.c tb_dsa.c tb_ecdsa.c tb_dh.c tb_ecdh.c tb_rand.c tb_store.c \
@@ -505,7 +519,7 @@ diff -u openssl/crypto/engine/Makefile:1.1.3.1 openssl/crypto/engine/Makefile:1.
  
  SRC= $(LIBSRC)
  
-@@ -286,6 +288,102 @@
+@@ -288,6 +290,102 @@
  eng_table.o: ../../include/openssl/symhacks.h ../../include/openssl/x509.h
  eng_table.o: ../../include/openssl/x509_vfy.h ../cryptlib.h eng_int.h
  eng_table.o: eng_table.c
@@ -610,7 +624,7 @@ diff -u openssl/crypto/engine/Makefile:1.1.3.1 openssl/crypto/engine/Makefile:1.
  tb_cipher.o: ../../include/openssl/crypto.h ../../include/openssl/e_os2.h
 Index: openssl/crypto/engine/cryptoki.h
 diff -u /dev/null openssl/crypto/engine/cryptoki.h:1.4
---- /dev/null	Thu Dec 24 13:00:45 2009
+--- /dev/null	Mon Jan 16 18:53:42 2012
 +++ openssl/crypto/engine/cryptoki.h	Thu Dec 18 00:14:12 2008
 @@ -0,0 +1,103 @@
 +/*
@@ -717,9 +731,9 @@ diff -u /dev/null openssl/crypto/engine/cryptoki.h:1.4
 +
 +#endif	/* _CRYPTOKI_H */
 Index: openssl/crypto/engine/eng_all.c
-diff -u openssl/crypto/engine/eng_all.c:1.1.3.1 openssl/crypto/engine/eng_all.c:1.3
---- openssl/crypto/engine/eng_all.c:1.1.3.1	Wed Jun  4 18:01:39 2008
-+++ openssl/crypto/engine/eng_all.c	Mon Oct  5 13:16:50 2009
+diff -u openssl/crypto/engine/eng_all.c:1.4.6.1 openssl/crypto/engine/eng_all.c:1.4
+--- openssl/crypto/engine/eng_all.c:1.4.6.1	Sun Jan 15 15:45:36 2012
++++ openssl/crypto/engine/eng_all.c	Mon Jun 13 14:25:19 2011
 @@ -110,6 +110,14 @@
  #if defined(OPENSSL_SYS_WIN32) && !defined(OPENSSL_NO_CAPIENG)
  	ENGINE_load_capi();
@@ -735,46 +749,30 @@ diff -u openssl/crypto/engine/eng_all.c:1.1.3.1 openssl/crypto/engine/eng_all.c:
  #endif
  	}
  
-Index: openssl/crypto/engine/eng_list.c
-diff -u openssl/crypto/engine/eng_list.c:1.1.3.1 openssl/crypto/engine/eng_list.c:1.2
---- openssl/crypto/engine/eng_list.c:1.1.3.1	Sat Aug  6 10:34:35 2005
-+++ openssl/crypto/engine/eng_list.c	Mon Oct  5 13:16:50 2009
-@@ -408,7 +408,11 @@
- 				!ENGINE_ctrl_cmd_string(iterator, "DIR_ADD",
- 					load_dir, 0) ||
- 				!ENGINE_ctrl_cmd_string(iterator, "LOAD", NULL, 0))
-+			{
-+				if (iterator)
-+					ENGINE_free(iterator);
- 				goto notfound;
-+			}
- 		return iterator;
- 		}
- notfound:
 Index: openssl/crypto/engine/engine.h
-diff -u openssl/crypto/engine/engine.h:1.1.3.1 openssl/crypto/engine/engine.h:1.3
---- openssl/crypto/engine/engine.h:1.1.3.1	Wed Jun  4 18:01:40 2008
-+++ openssl/crypto/engine/engine.h	Mon Oct  5 13:16:50 2009
-@@ -337,6 +337,12 @@
- void ENGINE_load_ubsec(void);
+diff -u openssl/crypto/engine/engine.h:1.4.6.1 openssl/crypto/engine/engine.h:1.4
+--- openssl/crypto/engine/engine.h:1.4.6.1	Sun Jan 15 15:45:36 2012
++++ openssl/crypto/engine/engine.h	Mon Jun 13 14:25:19 2011
+@@ -344,6 +344,12 @@
+ void ENGINE_load_capi(void);
+ #endif
  #endif
- void ENGINE_load_cryptodev(void);
 +#ifndef OPENSSL_NO_HW_PKCS11CA
 +void ENGINE_load_pk11ca(void);
 +#endif
 +#ifndef OPENSSL_NO_HW_PKCS11SO
 +void ENGINE_load_pk11so(void);
 +#endif
- void ENGINE_load_padlock(void);
- void ENGINE_load_builtin_engines(void);
- #ifndef OPENSSL_NO_CAPIENG
+ 
+ /* Get and set global flags (ENGINE_TABLE_FLAG_***) for the implementation
+  * "registry" handling. */
 Index: openssl/crypto/engine/hw_pk11.c
-diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
---- /dev/null	Thu Dec 24 13:00:45 2009
-+++ openssl/crypto/engine/hw_pk11.c	Mon Oct  5 13:16:50 2009
-@@ -0,0 +1,3927 @@
+diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26.4.2
+--- /dev/null	Mon Jan 16 18:53:42 2012
++++ openssl/crypto/engine/hw_pk11.c	Thu Jun 16 12:31:35 2011
+@@ -0,0 +1,4057 @@
 +/*
-+ * Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
++ * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
 + * Use is subject to license terms.
 + */
 +
@@ -904,7 +902,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 + * Solaris specific code. See comment at check_hw_mechanisms() for more
 + * information.
 + */
-+#if defined (__SVR4) && defined (__sun)
++#if defined(__SVR4) && defined(__sun)
 +#undef	SOLARIS_HW_SLOT_SELECTION
 +#endif
 +
@@ -939,6 +937,15 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +static int NID_aes_256_ctr = NID_undef;
 +#endif	/* SOLARIS_AES_CTR */
 +
++/*
++ * We use this lock to prevent multiple C_Login()s, guard getpassphrase(),
++ * uri_struct manipulation, and static token info. All of that is used by the
++ * RSA keys by reference feature.
++ */
++#ifndef NOPTHREADS
++pthread_mutex_t *token_lock;
++#endif
++
 +#ifdef	SOLARIS_HW_SLOT_SELECTION
 +/*
 + * Tables for symmetric ciphers and digest mechs found in the pkcs11_kernel
@@ -952,6 +959,12 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +static PK11_CACHE session_cache[OP_MAX];
 +
 +/*
++ * We cache the flags so that we do not have to run C_GetTokenInfo() again when
++ * logging into the token.
++ */
++CK_FLAGS pubkey_token_flags;
++
++/*
 + * As stated in v2.20, 11.7 Object Management Function, in section for
 + * C_FindObjectsInit(), at most one search operation may be active at a given
 + * time in a given session. Therefore, C_Find{,Init,Final}Objects() should be
@@ -1028,8 +1041,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +static int pk11_free_session_list(PK11_OPTYPE optype);
 +static int pk11_setup_session(PK11_SESSION *sp, PK11_OPTYPE optype);
 +static int pk11_destroy_cipher_key_objects(PK11_SESSION *session);
-+static int pk11_destroy_object(CK_SESSION_HANDLE session,
-+	CK_OBJECT_HANDLE oh);
++static int pk11_destroy_object(CK_SESSION_HANDLE session, CK_OBJECT_HANDLE oh,
++	CK_BBOOL persistent);
 +static const char *get_PK11_LIBNAME(void);
 +static void free_PK11_LIBNAME(void);
 +static long set_PK11_LIBNAME(const char *name);
@@ -1045,8 +1058,13 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +static int pk11_cipher_init(EVP_CIPHER_CTX *ctx, const unsigned char *key,
 +	const unsigned char *iv, int enc);
 +static int pk11_cipher_final(PK11_SESSION *sp);
++#if OPENSSL_VERSION_NUMBER < 0x10000000L
 +static int pk11_cipher_do_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
 +	const unsigned char *in, unsigned int inl);
++#else
++static int pk11_cipher_do_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
++	const unsigned char *in, size_t inl);
++#endif
 +static int pk11_cipher_cleanup(EVP_CIPHER_CTX *ctx);
 +static int pk11_engine_ciphers(ENGINE *e, const EVP_CIPHER **cipher,
 +	const int **nids, int nid);
@@ -1119,27 +1137,19 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +	PK11_DIGEST_MAX
 +};
 +
-+#define	TRY_OBJ_DESTROY(sess_hdl, obj_hdl, retval, uselock, alg_type)	\
++#define	TRY_OBJ_DESTROY(sp, obj_hdl, retval, uselock, alg_type, priv)	\
 +	{								\
 +	if (uselock)							\
 +		LOCK_OBJSTORE(alg_type);				\
 +	if (pk11_active_delete(obj_hdl, alg_type) == 1)			\
 +		{							\
-+		retval = pk11_destroy_object(sess_hdl, obj_hdl);	\
++		  retval = pk11_destroy_object(sp->session, obj_hdl,	\
++		  priv ? sp->priv_persistent : sp->pub_persistent);	\
 +		}							\
 +	if (uselock)							\
 +		UNLOCK_OBJSTORE(alg_type);				\
 +	}
 +
-+#define	TRY_OBJ_DELETE(sess_hdl, obj_hdl, retval, uselock, alg_type)	\
-+	{								\
-+	if (uselock)							\
-+		LOCK_OBJSTORE(alg_type);				\
-+	(void) pk11_active_delete(obj_hdl, alg_type);			\
-+	if (uselock)							\
-+		UNLOCK_OBJSTORE(alg_type);				\
-+	}
-+
 +static int cipher_nids[PK11_CIPHER_MAX];
 +static int digest_nids[PK11_DIGEST_MAX];
 +static int cipher_count		= 0;
@@ -1614,14 +1624,16 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +static const char PK11_GET_FUNCTION_LIST[] = "C_GetFunctionList";
 +
 +/*
-+ * These is the static string constant for the DSO file name and the function
-+ * symbol names to bind to.
++ * This is a static string constant for the DSO file name and the function
++ * symbol names to bind to. We set it in the Configure script based on whether
++ * this is 32 or 64 bit build.
 + */
 +static const char def_PK11_LIBNAME[] = PK11_LIB_LOCATION;
 +
 +static CK_BBOOL true = TRUE;
 +static CK_BBOOL false = FALSE;
-+static CK_SLOT_ID pubkey_SLOTID = 0;
++/* Needed in hw_pk11_pub.c as well so that's why it is not static. */
++CK_SLOT_ID pubkey_SLOTID = 0;
 +static CK_SLOT_ID rand_SLOTID = 0;
 +static CK_SLOT_ID SLOTID = 0;
 +char *pk11_pin = NULL;
@@ -1637,6 +1649,10 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +#ifndef NOPTHREADS
 +	int type;
 +
++	if ((token_lock = OPENSSL_malloc(sizeof (pthread_mutex_t))) == NULL)
++		goto malloc_err;
++	(void) pthread_mutex_init(token_lock, NULL);
++
 +#ifndef OPENSSL_NO_RSA
 +	find_lock[OP_RSA] = OPENSSL_malloc(sizeof (pthread_mutex_t));
 +	if (find_lock[OP_RSA] == NULL)
@@ -1928,6 +1944,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +	LOCK_OBJSTORE(OP_RSA);
 +	LOCK_OBJSTORE(OP_DSA);
 +	LOCK_OBJSTORE(OP_DH);
++	(void) pthread_mutex_lock(token_lock);
 +	for (i = 0; i < OP_MAX; i++)
 +		{
 +		(void) pthread_mutex_lock(session_cache[i].lock);
@@ -1951,6 +1968,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +	UNLOCK_OBJSTORE(OP_DH);
 +	UNLOCK_OBJSTORE(OP_DSA);
 +	UNLOCK_OBJSTORE(OP_RSA);
++	(void) pthread_mutex_unlock(token_lock);
 +#endif
 +	}
 +
@@ -1973,6 +1991,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +	UNLOCK_OBJSTORE(OP_DH);
 +	UNLOCK_OBJSTORE(OP_DSA);
 +	UNLOCK_OBJSTORE(OP_RSA);
++	(void) pthread_mutex_unlock(token_lock);
 +#endif
 +	}
 +
@@ -1982,6 +2001,16 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +	return (pk11_library_init(e));
 +}
 +
++static CK_C_INITIALIZE_ARGS pk11_init_args =
++	{
++	NULL_PTR,		/* CreateMutex */
++	NULL_PTR,		/* DestroyMutex */
++	NULL_PTR,		/* LockMutex */
++	NULL_PTR,		/* UnlockMutex */
++	CKF_OS_LOCKING_OK,	/* flags */
++	NULL_PTR,		/* pReserved */
++	};
++
 +/*
 + * Initialization function. Sets up various PKCS#11 library components.
 + * It selects a slot based on predefined critiera. In the process, it also
@@ -2003,15 +2032,17 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +#endif
 +
 +	/*
-+	 * pk11_library_initialized is set to 0 in pk11_finish() which is called
-+	 * from ENGINE_finish(). However, if there is still at least one
-+	 * existing functional reference to the engine (see engine(3) for more
-+	 * information), pk11_finish() is skipped. For example, this can happen
-+	 * if an application forgets to clear one cipher context. In case of a
-+	 * fork() when the application is finishing the engine so that it can be
-+	 * reinitialized in the child, forgotten functional reference causes
-+	 * pk11_library_initialized to stay 1. In that case we need the PID
-+	 * check so that we properly initialize the engine again.
++	 * pk11_library_initialized is set to 0 in pk11_finish() which
++	 * is called from ENGINE_finish(). However, if there is still
++	 * at least one existing functional reference to the engine
++	 * (see engine(3) for more information), pk11_finish() is
++	 * skipped. For example, this can happen if an application
++	 * forgets to clear one cipher context. In case of a fork()
++	 * when the application is finishing the engine so that it can
++	 * be reinitialized in the child, forgotten functional
++	 * reference causes pk11_library_initialized to stay 1. In
++	 * that case we need the PID check so that we properly
++	 * initialize the engine again.
 +	 */
 +	if (pk11_library_initialized)
 +		{
@@ -2078,7 +2109,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +	(void) sigaction(SIGTERM, NULL, &sigterm_act);
 +	(void) sigaction(SIGHUP, NULL, &sighup_act);
 +#endif
-+	rv = pFuncList->C_Initialize(NULL_PTR);
++	rv = pFuncList->C_Initialize((CK_VOID_PTR)&pk11_init_args);
 +#ifndef OPENSSL_SYS_WIN32
 +	(void) sigaction(SIGINT, &sigint_act, NULL);
 +	(void) sigaction(SIGTERM, &sigterm_act, NULL);
@@ -2382,6 +2413,16 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +				BN_free(sp->opdata_rsa_e_num);
 +				sp->opdata_rsa_e_num = NULL;
 +				}
++			if (sp->opdata_rsa_pn_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_pn_num);
++				sp->opdata_rsa_pn_num = NULL;
++				}
++			if (sp->opdata_rsa_pe_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_pe_num);
++				sp->opdata_rsa_pe_num = NULL;
++				}
 +			if (sp->opdata_rsa_d_num != NULL)
 +				{
 +				BN_free(sp->opdata_rsa_d_num);
@@ -2430,6 +2471,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +#ifndef NOPTHREADS
 +	pthread_mutex_t *freelist_lock = NULL;
 +#endif
++	static pid_t pid = 0;
++	pid_t new_pid;
 +	CK_RV rv;
 +
 +	switch (optype)
@@ -2454,6 +2497,15 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +#else
 +	CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
 +#endif
++
++	/*
++	 * Will use it to find out if we forked. We cannot use the PID field in
++	 * the session structure because we could get a newly allocated session
++	 * here, with no PID information.
++	 */
++	if (pid == 0)
++		pid = getpid();
++
 +	freelist = session_cache[optype].head;
 +	sp = freelist;
 +
@@ -2471,17 +2523,33 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +			goto err;
 +			}
 +		(void) memset(sp, 0, sizeof (PK11_SESSION));
++
++		/*
++		 * It is a new session so it will look like a cache miss to the
++		 * code below. So, we must not try to to destroy its members so
++		 * mark them as unused.
++		 */
++		sp->opdata_rsa_priv_key = CK_INVALID_HANDLE;
++		sp->opdata_rsa_pub_key = CK_INVALID_HANDLE;
 +		}
 +	else
 +		{
 +		freelist = sp->next;
 +		}
 +
-+	if (sp->pid != 0 && sp->pid != getpid())
++	/*
++	 * Check whether we have forked. In that case, we must get rid of all
++	 * inherited sessions and start allocating new ones.
++	 */
++	if (pid != (new_pid = getpid()))
 +		{
++		pid = new_pid;
++
 +		/*
 +		 * We are a new process and thus need to free any inherited
-+		 * PK11_SESSION objects.
++		 * PK11_SESSION objects aside from the first session (sp) which
++		 * is the only PK11_SESSION structure we will reuse (for the
++		 * head of the list).
 +		 */
 +		while ((sp1 = freelist) != NULL)
 +			{
@@ -2499,7 +2567,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +		pk11_free_active_list(optype);
 +
 +		/* Initialize the process */
-+		rv = pFuncList->C_Initialize(NULL_PTR);
++		rv = pFuncList->C_Initialize((CK_VOID_PTR)&pk11_init_args);
 +		if ((rv != CKR_OK) && (rv != CKR_CRYPTOKI_ALREADY_INITIALIZED))
 +			{
 +			PK11err_add_data(PK11_F_GET_SESSION, PK11_R_INITIALIZE,
@@ -2535,13 +2603,28 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +			goto err;
 +			}
 +
-+		/* It is an inherited session and needs re-initialization. */
++		/*
++		 * It is an inherited session from our parent so it needs
++		 * re-initialization.
++		 */
 +		if (pk11_setup_session(sp, optype) == 0)
 +			{
 +			OPENSSL_free(sp);
 +			sp = NULL;
++			goto err;
++			}
++		if (pk11_token_relogin(sp->session) == 0) 
++			{
++			/*
++			 * We will keep the session in the cache list and let
++			 * the caller cope with the situation.
++			 */
++			freelist = sp;
++			sp = NULL;
++			goto err;
 +			}
 +		}
++
 +	if (sp->pid == 0)
 +		{
 +		/* It is a new session and needs initialization. */
@@ -2577,6 +2660,11 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +#endif
 +	PK11_SESSION *freelist;
 +
++	/*
++	 * If this is a session from the parent it will be taken care of and
++	 * freed in pk11_get_session() as part of the post-fork clean up the
++	 * next time we will ask for a new session.
++	 */
 +	if (sp == NULL || sp->pid != getpid())
 +		return;
 +
@@ -2710,7 +2798,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +	}
 +
 +
-+static int pk11_setup_session(PK11_SESSION *sp, PK11_OPTYPE optype)
++static int
++pk11_setup_session(PK11_SESSION *sp, PK11_OPTYPE optype)
 +	{
 +	CK_RV rv;
 +	CK_SLOT_ID myslot;
@@ -2771,6 +2860,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +			sp->opdata_rsa_n_num = NULL;
 +			sp->opdata_rsa_e_num = NULL;
 +			sp->opdata_rsa_priv = NULL;
++			sp->opdata_rsa_pn_num = NULL;
++			sp->opdata_rsa_pe_num = NULL;
 +			sp->opdata_rsa_d_num = NULL;
 +			break;
 +#endif	/* OPENSSL_NO_RSA */
@@ -2799,6 +2890,12 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +			break;
 +		}
 +
++	/*
++	 * We always initialize the session as containing a non-persistent
++	 * object. The key load functions set it to persistent if that is so.
++	 */
++	sp->pub_persistent = CK_FALSE;
++	sp->priv_persistent = CK_FALSE;
 +	return (1);
 +	}
 +
@@ -2811,8 +2908,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +
 +	if (sp->opdata_rsa_pub_key != CK_INVALID_HANDLE)
 +		{
-+		TRY_OBJ_DESTROY(sp->session, sp->opdata_rsa_pub_key,
-+		    ret, uselock, OP_RSA);
++		TRY_OBJ_DESTROY(sp, sp->opdata_rsa_pub_key,
++		    ret, uselock, OP_RSA, CK_FALSE);
 +		sp->opdata_rsa_pub_key = CK_INVALID_HANDLE;
 +		sp->opdata_rsa_pub = NULL;
 +		if (sp->opdata_rsa_n_num != NULL)
@@ -2838,18 +2935,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +
 +	if (sp->opdata_rsa_priv_key != CK_INVALID_HANDLE)
 +		{
-+		if ((sp->opdata_rsa_priv->flags & RSA_FLAG_EXT_PKEY) != 0)
-+			{
-+			TRY_OBJ_DELETE(sp->session,
-+				       sp->opdata_rsa_priv_key,
-+				       ret, uselock, OP_RSA);
-+			}
-+		else
-+			{
-+			TRY_OBJ_DESTROY(sp->session,
-+					sp->opdata_rsa_priv_key,
-+					ret, uselock, OP_RSA);
-+			}
++		TRY_OBJ_DESTROY(sp, sp->opdata_rsa_priv_key,
++		    ret, uselock, OP_RSA, CK_TRUE);
 +		sp->opdata_rsa_priv_key = CK_INVALID_HANDLE;
 +		sp->opdata_rsa_priv = NULL;
 +		if (sp->opdata_rsa_d_num != NULL)
@@ -2857,6 +2944,22 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +			BN_free(sp->opdata_rsa_d_num);
 +			sp->opdata_rsa_d_num = NULL;
 +			}
++
++		/*
++		 * For the RSA key by reference code, public components 'n'/'e'
++		 * are the key components we use to check for the cache hit. We
++		 * must free those as well.
++		 */
++		if (sp->opdata_rsa_pn_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_pn_num);
++			sp->opdata_rsa_pn_num = NULL;
++			}
++		if (sp->opdata_rsa_pe_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_pe_num);
++			sp->opdata_rsa_pe_num = NULL;
++			}
 +		}
 +
 +	return (ret);
@@ -2931,8 +3034,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +
 +	if (sp->opdata_dsa_pub_key != CK_INVALID_HANDLE)
 +		{
-+		TRY_OBJ_DESTROY(sp->session, sp->opdata_dsa_pub_key,
-+		    ret, uselock, OP_DSA);
++		TRY_OBJ_DESTROY(sp, sp->opdata_dsa_pub_key,
++		    ret, uselock, OP_DSA, CK_FALSE);
 +		sp->opdata_dsa_pub_key = CK_INVALID_HANDLE;
 +		sp->opdata_dsa_pub = NULL;
 +		if (sp->opdata_dsa_pub_num != NULL)
@@ -2953,8 +3056,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +
 +	if (sp->opdata_dsa_priv_key != CK_INVALID_HANDLE)
 +		{
-+		TRY_OBJ_DESTROY(sp->session, sp->opdata_dsa_priv_key,
-+		    ret, uselock, OP_DSA);
++		TRY_OBJ_DESTROY(sp, sp->opdata_dsa_priv_key,
++		    ret, uselock, OP_DSA, CK_TRUE);
 +		sp->opdata_dsa_priv_key = CK_INVALID_HANDLE;
 +		sp->opdata_dsa_priv = NULL;
 +		if (sp->opdata_dsa_priv_num != NULL)
@@ -3036,8 +3139,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +
 +	if (sp->opdata_dh_key != CK_INVALID_HANDLE)
 +		{
-+		TRY_OBJ_DESTROY(sp->session, sp->opdata_dh_key,
-+		    ret, uselock, OP_DH);
++		TRY_OBJ_DESTROY(sp, sp->opdata_dh_key,
++		    ret, uselock, OP_DH, CK_TRUE);
 +		sp->opdata_dh_key = CK_INVALID_HANDLE;
 +		sp->opdata_dh = NULL;
 +		if (sp->opdata_dh_priv_num != NULL)
@@ -3104,9 +3207,20 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +	}
 +#endif	/* OPENSSL_NO_DH */
 +
-+static int pk11_destroy_object(CK_SESSION_HANDLE session, CK_OBJECT_HANDLE oh)
++static int
++pk11_destroy_object(CK_SESSION_HANDLE session, CK_OBJECT_HANDLE oh,
++	CK_BBOOL persistent)
 +	{
 +	CK_RV rv;
++
++	/*
++	 * We never try to destroy persistent objects which are the objects
++	 * stored in the keystore. Also, we always use read-only sessions so
++	 * C_DestroyObject() would be returning CKR_SESSION_READ_ONLY here.
++	 */
++	if (persistent == CK_TRUE)
++		return (1);
++
 +	rv = pFuncList->C_DestroyObject(session, oh);
 +	if (rv != CKR_OK)
 +		{
@@ -3363,9 +3477,15 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 + * An engine interface function. The calling function allocates sufficient
 + * memory for the output buffer "out" to hold the results.
 + */
++#if OPENSSL_VERSION_NUMBER < 0x10000000L
 +static int
 +pk11_cipher_do_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
 +	const unsigned char *in, unsigned int inl)
++#else
++static int
++pk11_cipher_do_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
++	const unsigned char *in, size_t inl)
++#endif
 +	{
 +	PK11_CIPHER_STATE *state = (PK11_CIPHER_STATE *) ctx->cipher_data;
 +	PK11_SESSION *sp;
@@ -3885,10 +4005,10 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +			{
 +			/*
 +			 * The secret key object is created in the
-+			 * global_session. See pk11_get_cipher_key
++			 * global_session. See pk11_get_cipher_key().
 +			 */
 +			if (pk11_destroy_object(global_session,
-+				sp->opdata_cipher_key) == 0)
++				sp->opdata_cipher_key, CK_FALSE) == 0)
 +				goto err;
 +			sp->opdata_cipher_key = CK_INVALID_HANDLE;
 +			}
@@ -3970,7 +4090,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +		*any_slot_found = 0;
 +
 +	/* Get slot list for memory allocation */
-+	rv = pFuncList->C_GetSlotList(0, NULL_PTR, &ulSlotCount);
++	rv = pFuncList->C_GetSlotList(CK_FALSE, NULL_PTR, &ulSlotCount);
 +
 +	if (rv != CKR_OK)
 +		{
@@ -3996,7 +4116,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +		}
 +
 +	/* Get the slot list for processing */
-+	rv = pFuncList->C_GetSlotList(0, pSlotList, &ulSlotCount);
++	rv = pFuncList->C_GetSlotList(CK_FALSE, pSlotList, &ulSlotCount);
 +	if (rv != CKR_OK)
 +		{
 +		PK11err_add_data(PK11_F_CHOOSE_SLOT, PK11_R_GETSLOTLIST, rv);
@@ -4140,6 +4260,12 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +			pk11_have_dsa = slot_has_dsa;
 +			pk11_have_dh = slot_has_dh;
 +			found_candidate_slot = CK_TRUE;
++			/*
++			 * Cache the flags for later use. We might
++			 * need those if RSA keys by reference feature
++			 * is used.
++			 */
++			pubkey_token_flags = token_info.flags;
 +#ifdef	DEBUG_SLOT_SELECTION
 +			fprintf(stderr,
 +			    "%s: setting found_candidate_slot to CK_TRUE\n",
@@ -4147,6 +4273,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +			fprintf(stderr,
 +			    "%s: best so far slot: %d\n", PK11_DBG,
 +			    best_slot_sofar);
++			fprintf(stderr, "%s: pubkey flags changed to "
++			    "%lu.\n", PK11_DBG, pubkey_token_flags);
 +			}
 +		else
 +			{
@@ -4158,7 +4286,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +#endif	/* DEBUG_SLOT_SELECTION */
 +		} /* for */
 +
-+	if (found_candidate_slot)
++	if (found_candidate_slot == CK_TRUE)
 +		{
 +		pubkey_SLOTID = best_slot_sofar;
 +		}
@@ -4536,7 +4664,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +		goto err;
 +		}
 +
-+	rv = pflist->C_Initialize(NULL_PTR);
++	rv = pflist->C_Initialize((CK_VOID_PTR)&pk11_init_args);
 +	if ((rv != CKR_OK) && (rv != CKR_CRYPTOKI_ALREADY_INITIALIZED))
 +		{
 +		PK11err_add_data(PK11_F_CHECK_HW_MECHANISMS,
@@ -4701,12 +4829,12 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.26
 +#endif	/* OPENSSL_NO_HW_PK11 */
 +#endif	/* OPENSSL_NO_HW */
 Index: openssl/crypto/engine/hw_pk11_err.c
-diff -u /dev/null openssl/crypto/engine/hw_pk11_err.c:1.4
---- /dev/null	Thu Dec 24 13:00:45 2009
-+++ openssl/crypto/engine/hw_pk11_err.c	Wed Dec 17 16:14:26 2008
-@@ -0,0 +1,259 @@
+diff -u /dev/null openssl/crypto/engine/hw_pk11_err.c:1.4.10.1
+--- /dev/null	Mon Jan 16 18:53:42 2012
++++ openssl/crypto/engine/hw_pk11_err.c	Tue Jun 14 21:52:40 2011
+@@ -0,0 +1,288 @@
 +/*
-+ * Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
++ * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
 + * Use is subject to license terms.
 + */
 +
@@ -4838,6 +4966,16 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_err.c:1.4
 +{ ERR_PACK(0, PK11_F_CHECK_HW_MECHANISMS, 0),	"PK11_CHECK_HW_MECHANISMS"},
 +{ ERR_PACK(0, PK11_F_INIT_SYMMETRIC, 0),	"PK11_INIT_SYMMETRIC"},
 +{ ERR_PACK(0, PK11_F_ADD_AES_CTR_NIDS, 0),	"PK11_ADD_AES_CTR_NIDS"},
++{ ERR_PACK(0, PK11_F_INIT_ALL_LOCKS, 0),	"PK11_INIT_ALL_LOCKS"},
++{ ERR_PACK(0, PK11_F_RETURN_SESSION, 0),	"PK11_RETURN_SESSION"},
++{ ERR_PACK(0, PK11_F_GET_PIN, 0),		"PK11_GET_PIN"},
++{ ERR_PACK(0, PK11_F_FIND_ONE_OBJECT, 0),	"PK11_FIND_ONE_OBJECT"},
++{ ERR_PACK(0, PK11_F_CHECK_TOKEN_ATTRS, 0),	"PK11_CHECK_TOKEN_ATTRS"},
++{ ERR_PACK(0, PK11_F_CACHE_PIN, 0),		"PK11_CACHE_PIN"},
++{ ERR_PACK(0, PK11_F_MLOCK_PIN_IN_MEMORY, 0),	"PK11_MLOCK_PIN_IN_MEMORY"},
++{ ERR_PACK(0, PK11_F_TOKEN_LOGIN, 0),		"PK11_TOKEN_LOGIN"},
++{ ERR_PACK(0, PK11_F_TOKEN_RELOGIN, 0),		"PK11_TOKEN_RELOGIN"},
++{ ERR_PACK(0, PK11_F_RUN_ASKPASS, 0),		"PK11_F_RUN_ASKPASS"},
 +{ 0, NULL}
 +};
 +
@@ -4904,13 +5042,32 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_err.c:1.4
 +{ PK11_R_DERIVEKEY,			"C_DeriveKey failed"},
 +{ PK11_R_GET_OPERATION_STATE,		"C_GetOperationState failed"},
 +{ PK11_R_SET_OPERATION_STATE,		"C_SetOperationState failed"},
-+{ PK11_R_INVALID_PIN,			"invalid PIN"},
-+{ PK11_R_TOO_MANY_OBJECTS,		"too many objects"},
-+{ PK11_R_OBJECT_NOT_FOUND,		"object not found"},
 +{ PK11_R_INVALID_HANDLE,		"invalid PKCS#11 object handle"},
 +{ PK11_R_KEY_OR_IV_LEN_PROBLEM,		"IV or key length incorrect"},
 +{ PK11_R_INVALID_OPERATION_TYPE,	"invalid operation type"},
 +{ PK11_R_ADD_NID_FAILED,		"failed to add NID" },
++{ PK11_R_ATFORK_FAILED,			"atfork() failed" },
++{ PK11_R_TOKEN_LOGIN_FAILED,		"C_Login() failed on token" },
++{ PK11_R_MORE_THAN_ONE_OBJECT_FOUND,	"more than one object found" },
++{ PK11_R_INVALID_PKCS11_URI,		"pkcs11 URI provided is invalid" },
++{ PK11_R_COULD_NOT_READ_PIN,		"could not read PIN from terminal" },
++{ PK11_R_PIN_NOT_READ_FROM_COMMAND,	"PIN not read from external command" },
++{ PK11_R_COULD_NOT_OPEN_COMMAND,	"could not popen() dialog command" },
++{ PK11_R_PIPE_FAILED,			"pipe() failed" },
++{ PK11_R_BAD_PASSPHRASE_SPEC,		"bad passphrasedialog specification" },
++{ PK11_R_TOKEN_NOT_INITIALIZED,		"token not initialized" },
++{ PK11_R_TOKEN_PIN_NOT_SET,		"token PIN required but not set" },
++{ PK11_R_TOKEN_PIN_NOT_PROVIDED,	"token PIN required but not provided" },
++{ PK11_R_MISSING_OBJECT_LABEL,		"missing mandatory 'object' keyword" },
++{ PK11_R_TOKEN_ATTRS_DO_NOT_MATCH,	"token attrs provided do not match" },
++{ PK11_R_PRIV_KEY_NOT_FOUND,		"private key not found in keystore" },
++{ PK11_R_NO_OBJECT_FOUND,		"specified object not found" },
++{ PK11_R_PIN_CACHING_POLICY_INVALID,	"PIN set but caching policy invalid" },
++{ PK11_R_SYSCONF_FAILED,		"sysconf() failed" },
++{ PK11_R_MMAP_FAILED,			"mmap() failed" },
++{ PK11_R_PRIV_PROC_LOCK_MEMORY_MISSING,	"PROC_LOCK_MEMORY privilege missing" },
++{ PK11_R_MLOCK_FAILED,			"mlock() failed" },
++{ PK11_R_FORK_FAILED,			"fork() failed" },
 +{ 0,	NULL}
 +};
 +#endif	/* OPENSSL_NO_ERR */
@@ -4965,16 +5122,15 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_err.c:1.4
 +	ERR_add_error_data(2, "PK11 CK_RV=0X", tmp_buf);
 +}
 Index: openssl/crypto/engine/hw_pk11_err.h
-diff -u /dev/null openssl/crypto/engine/hw_pk11_err.h:1.9
---- /dev/null	Thu Dec 24 13:00:45 2009
-+++ openssl/crypto/engine/hw_pk11_err.h	Wed Dec 17 15:01:45 2008
-@@ -0,0 +1,402 @@
+diff -u /dev/null openssl/crypto/engine/hw_pk11_err.h:1.9.10.1
+--- /dev/null	Mon Jan 16 18:53:42 2012
++++ openssl/crypto/engine/hw_pk11_err.h	Tue Jun 14 21:52:40 2011
+@@ -0,0 +1,440 @@
 +/*
-+ * Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
++ * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
 + * Use is subject to license terms.
 + */
 +
-+/* crypto/engine/hw_pk11_err.h */
 +/*
 + * This product includes software developed by the OpenSSL Project for
 + * use in the OpenSSL Toolkit (http://www.openssl.org/).
@@ -5048,41 +5204,41 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_err.h:1.9
 +
 +/* Function codes. */
 +
-+#define	PK11_F_INIT 				100
++#define	PK11_F_INIT				100
 +#define	PK11_F_FINISH				101
-+#define	PK11_F_DESTROY 				102
-+#define	PK11_F_CTRL 				103
-+#define	PK11_F_RSA_INIT 			104
-+#define	PK11_F_RSA_FINISH 			105
-+#define	PK11_F_GET_PUB_RSA_KEY 			106
-+#define	PK11_F_GET_PRIV_RSA_KEY 		107
-+#define	PK11_F_RSA_GEN_KEY 			108
-+#define	PK11_F_RSA_PUB_ENC 			109
-+#define	PK11_F_RSA_PRIV_ENC 			110
-+#define	PK11_F_RSA_PUB_DEC 			111
-+#define	PK11_F_RSA_PRIV_DEC 			112
-+#define	PK11_F_RSA_SIGN 			113
-+#define	PK11_F_RSA_VERIFY 			114
-+#define	PK11_F_RAND_ADD 			115
-+#define	PK11_F_RAND_BYTES 			116
-+#define	PK11_F_GET_SESSION 			117
-+#define	PK11_F_FREE_SESSION 			118
-+#define	PK11_F_LOAD_PUBKEY 			119
-+#define	PK11_F_LOAD_PRIVKEY 			120
-+#define	PK11_F_RSA_PUB_ENC_LOW 			121
-+#define	PK11_F_RSA_PRIV_ENC_LOW 		122
-+#define	PK11_F_RSA_PUB_DEC_LOW 			123
-+#define	PK11_F_RSA_PRIV_DEC_LOW 		124
++#define	PK11_F_DESTROY				102
++#define	PK11_F_CTRL				103
++#define	PK11_F_RSA_INIT				104
++#define	PK11_F_RSA_FINISH			105
++#define	PK11_F_GET_PUB_RSA_KEY			106
++#define	PK11_F_GET_PRIV_RSA_KEY			107
++#define	PK11_F_RSA_GEN_KEY			108
++#define	PK11_F_RSA_PUB_ENC			109
++#define	PK11_F_RSA_PRIV_ENC			110
++#define	PK11_F_RSA_PUB_DEC			111
++#define	PK11_F_RSA_PRIV_DEC			112
++#define	PK11_F_RSA_SIGN				113
++#define	PK11_F_RSA_VERIFY			114
++#define	PK11_F_RAND_ADD				115
++#define	PK11_F_RAND_BYTES			116
++#define	PK11_F_GET_SESSION			117
++#define	PK11_F_FREE_SESSION			118
++#define	PK11_F_LOAD_PUBKEY			119
++#define	PK11_F_LOAD_PRIVKEY			120
++#define	PK11_F_RSA_PUB_ENC_LOW			121
++#define	PK11_F_RSA_PRIV_ENC_LOW			122
++#define	PK11_F_RSA_PUB_DEC_LOW			123
++#define	PK11_F_RSA_PRIV_DEC_LOW			124
 +#define	PK11_F_DSA_SIGN				125
 +#define	PK11_F_DSA_VERIFY			126
 +#define	PK11_F_DSA_INIT				127
 +#define	PK11_F_DSA_FINISH			128
-+#define	PK11_F_GET_PUB_DSA_KEY 			129
-+#define	PK11_F_GET_PRIV_DSA_KEY 		130
-+#define	PK11_F_DH_INIT 				131
-+#define	PK11_F_DH_FINISH 			132
-+#define	PK11_F_MOD_EXP_DH 			133
-+#define	PK11_F_GET_DH_KEY 			134
++#define	PK11_F_GET_PUB_DSA_KEY			129
++#define	PK11_F_GET_PRIV_DSA_KEY			130
++#define	PK11_F_DH_INIT				131
++#define	PK11_F_DH_FINISH			132
++#define	PK11_F_MOD_EXP_DH			133
++#define	PK11_F_GET_DH_KEY			134
 +#define	PK11_F_FREE_ALL_SESSIONS		135
 +#define	PK11_F_SETUP_SESSION			136
 +#define	PK11_F_DESTROY_OBJECT			137
@@ -5094,11 +5250,11 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_err.h:1.9
 +#define	PK11_F_DIGEST_FINAL			143
 +#define	PK11_F_CHOOSE_SLOT			144
 +#define	PK11_F_CIPHER_FINAL			145
-+#define	PK11_F_LIBRARY_INIT 			146
-+#define	PK11_F_LOAD 				147
++#define	PK11_F_LIBRARY_INIT			146
++#define	PK11_F_LOAD				147
 +#define	PK11_F_DH_GEN_KEY			148
-+#define	PK11_F_DH_COMP_KEY 			149
-+#define	PK11_F_DIGEST_COPY 			150
++#define	PK11_F_DH_COMP_KEY			149
++#define	PK11_F_DIGEST_COPY			150
 +#define	PK11_F_CIPHER_CLEANUP			151
 +#define	PK11_F_ACTIVE_ADD			152
 +#define	PK11_F_ACTIVE_DELETE			153
@@ -5107,6 +5263,14 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_err.h:1.9
 +#define	PK11_F_ADD_AES_CTR_NIDS			156
 +#define	PK11_F_INIT_ALL_LOCKS			157
 +#define	PK11_F_RETURN_SESSION			158
++#define	PK11_F_GET_PIN				159
++#define	PK11_F_FIND_ONE_OBJECT			160
++#define	PK11_F_CHECK_TOKEN_ATTRS		161
++#define	PK11_F_CACHE_PIN			162
++#define	PK11_F_MLOCK_PIN_IN_MEMORY		163
++#define	PK11_F_TOKEN_LOGIN			164
++#define	PK11_F_TOKEN_RELOGIN			165
++#define	PK11_F_RUN_ASKPASS			166
 +
 +/* Reason codes. */
 +#define	PK11_R_ALREADY_LOADED 			100
@@ -5175,9 +5339,28 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_err.h:1.9
 +#define	PK11_R_INVALID_OPERATION_TYPE		164
 +#define	PK11_R_ADD_NID_FAILED			165
 +#define	PK11_R_ATFORK_FAILED			166
-+#define	PK11_R_INVALID_PIN			167
-+#define	PK11_R_TOO_MANY_OBJECTS			168
-+#define	PK11_R_OBJECT_NOT_FOUND			169
++
++#define	PK11_R_TOKEN_LOGIN_FAILED		167
++#define	PK11_R_MORE_THAN_ONE_OBJECT_FOUND	168
++#define	PK11_R_INVALID_PKCS11_URI		169
++#define	PK11_R_COULD_NOT_READ_PIN		170
++#define	PK11_R_COULD_NOT_OPEN_COMMAND		171
++#define	PK11_R_PIPE_FAILED			172
++#define	PK11_R_PIN_NOT_READ_FROM_COMMAND	173
++#define	PK11_R_BAD_PASSPHRASE_SPEC		174
++#define	PK11_R_TOKEN_NOT_INITIALIZED		175
++#define	PK11_R_TOKEN_PIN_NOT_SET		176
++#define	PK11_R_TOKEN_PIN_NOT_PROVIDED		177
++#define	PK11_R_MISSING_OBJECT_LABEL		178
++#define	PK11_R_TOKEN_ATTRS_DO_NOT_MATCH		179
++#define	PK11_R_PRIV_KEY_NOT_FOUND		180
++#define	PK11_R_NO_OBJECT_FOUND			181
++#define	PK11_R_PIN_CACHING_POLICY_INVALID	182
++#define	PK11_R_SYSCONF_FAILED			183
++#define	PK11_R_MMAP_FAILED			183
++#define	PK11_R_PRIV_PROC_LOCK_MEMORY_MISSING	184
++#define	PK11_R_MLOCK_FAILED			185
++#define	PK11_R_FORK_FAILED			186
 +
 +/* max byte length of a symetric key we support */
 +#define	PK11_KEY_LEN_MAX			32
@@ -5212,6 +5395,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_err.h:1.9
 +	struct PK11_st_SESSION	*next;
 +	CK_SESSION_HANDLE	session;	/* PK11 session handle */
 +	pid_t			pid;		/* Current process ID */
++	CK_BBOOL		pub_persistent;	/* is pub key in keystore? */
++	CK_BBOOL		priv_persistent;/* is priv key in keystore? */
 +	union
 +		{
 +#ifndef OPENSSL_NO_RSA
@@ -5223,6 +5408,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_err.h:1.9
 +			BIGNUM			*rsa_n_num; /* pub modulus */
 +			BIGNUM			*rsa_e_num; /* pub exponent */
 +			RSA			*rsa_priv; /* priv key addr */
++			BIGNUM			*rsa_pn_num; /* pub modulus */
++			BIGNUM			*rsa_pe_num; /* pub exponent */
 +			BIGNUM			*rsa_d_num; /* priv exponent */
 +			} u_RSA;
 +#endif /* OPENSSL_NO_RSA */
@@ -5261,6 +5448,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_err.h:1.9
 +#define	opdata_rsa_priv		opdata_u.u_RSA.rsa_priv
 +#define	opdata_rsa_n_num	opdata_u.u_RSA.rsa_n_num
 +#define	opdata_rsa_e_num	opdata_u.u_RSA.rsa_e_num
++#define	opdata_rsa_pn_num	opdata_u.u_RSA.rsa_pn_num
++#define	opdata_rsa_pe_num	opdata_u.u_RSA.rsa_pe_num
 +#define	opdata_rsa_d_num	opdata_u.u_RSA.rsa_d_num
 +#define	opdata_dsa_pub_key	opdata_u.u_DSA.dsa_pub_key
 +#define	opdata_dsa_priv_key	opdata_u.u_DSA.dsa_priv_key
@@ -5330,6 +5519,11 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_err.h:1.9
 +extern pthread_mutex_t *find_lock[];
 +#endif
 +extern PK11_active *active_list[];
++/*
++ * These variables are specific for the RSA keys by reference code. See
++ * hw_pk11_pub.c for explanation.
++ */
++extern CK_FLAGS pubkey_token_flags;
 +
 +#ifndef NOPTHREADS
 +#define	LOCK_OBJSTORE(alg_type)	\
@@ -5345,6 +5539,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_err.h:1.9
 +
 +extern PK11_SESSION *pk11_get_session(PK11_OPTYPE optype);
 +extern void pk11_return_session(PK11_SESSION *sp, PK11_OPTYPE optype);
++extern int pk11_token_relogin(CK_SESSION_HANDLE session);
 +
 +#ifndef OPENSSL_NO_RSA
 +extern int pk11_destroy_rsa_key_objects(PK11_SESSION *session);
@@ -5372,12 +5567,12 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_err.h:1.9
 +
 +#endif /* HW_PK11_ERR_H */
 Index: openssl/crypto/engine/hw_pk11_pub.c
-diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
---- /dev/null	Thu Dec 24 13:00:45 2009
-+++ openssl/crypto/engine/hw_pk11_pub.c	Mon Oct  5 13:16:55 2009
-@@ -0,0 +1,3140 @@
+diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32.4.3
+--- /dev/null	Mon Jan 16 18:53:42 2012
++++ openssl/crypto/engine/hw_pk11_pub.c	Fri Jun 17 07:56:20 2011
+@@ -0,0 +1,3530 @@
 +/*
-+ * Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
++ * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
 + * Use is subject to license terms.
 + */
 +
@@ -5508,6 +5703,12 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +#include "hw_pk11ca.h"
 +#include "hw_pk11_err.h"
 +
++static CK_BBOOL pk11_login_done = CK_FALSE;
++extern CK_SLOT_ID pubkey_SLOTID;
++#ifndef NOPTHREADS
++extern pthread_mutex_t *token_lock;
++#endif
++
 +#if !(defined(HAVE_GETPASSPHRASE) || (defined (__SVR4) && defined (__sun)))
 +#define getpassphrase(x)	getpass(x)
 +#endif
@@ -5526,10 +5727,16 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +static int pk11_RSA_finish(RSA *rsa);
 +static int pk11_RSA_sign(int type, const unsigned char *m, unsigned int m_len,
 +	unsigned char *sigret, unsigned int *siglen, const RSA *rsa);
++#if OPENSSL_VERSION_NUMBER < 0x10000000L
 +static int pk11_RSA_verify(int dtype, const unsigned char *m,
 +	unsigned int m_len, unsigned char *sigbuf, unsigned int siglen,
 +	const RSA *rsa);
-+EVP_PKEY *pk11_load_privkey(ENGINE*, const char *pubkey_file,
++#else
++static int pk11_RSA_verify(int dtype, const unsigned char *m,
++	unsigned int m_len, const unsigned char *sigbuf, unsigned int siglen,
++	const RSA *rsa);
++#endif
++EVP_PKEY *pk11_load_privkey(ENGINE*, const char *privkey_file,
 +	UI_METHOD *ui_method, void *callback_data);
 +EVP_PKEY *pk11_load_pubkey(ENGINE*, const char *pubkey_file,
 +	UI_METHOD *ui_method, void *callback_data);
@@ -5546,7 +5753,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +static CK_OBJECT_HANDLE pk11_get_public_rsa_key(RSA* rsa, RSA** key_ptr,
 +	BIGNUM **rsa_n_num, BIGNUM **rsa_e_num, CK_SESSION_HANDLE session);
 +static CK_OBJECT_HANDLE pk11_get_private_rsa_key(RSA* rsa, RSA** key_ptr,
-+	BIGNUM **rsa_d_num, CK_SESSION_HANDLE session);
++	BIGNUM **rsa_d_num, BIGNUM **rsa_n_num, BIGNUM **rsa_e_num,
++	CK_SESSION_HANDLE session);
 +
 +static int check_new_rsa_key_pub(PK11_SESSION *sp, const RSA *rsa);
 +static int check_new_rsa_key_priv(PK11_SESSION *sp, const RSA *rsa);
@@ -5584,10 +5792,15 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +static int check_new_dh_key(PK11_SESSION *sp, DH *dh);
 +#endif
 +
++static int find_one_object(PK11_OPTYPE op, CK_SESSION_HANDLE s,
++	CK_ATTRIBUTE_PTR ptempl, CK_ULONG nattr, CK_OBJECT_HANDLE_PTR pkey);
 +static int init_template_value(BIGNUM *bn, CK_VOID_PTR *pValue,
 +	CK_ULONG *ulValueLen);
 +static void attr_to_BN(CK_ATTRIBUTE_PTR attr, CK_BYTE attr_data[], BIGNUM **bn);
 +
++static int pk11_token_login(CK_SESSION_HANDLE session, CK_BBOOL *login_done,
++	CK_BBOOL is_private);
++
 +/* Read mode string to be used for fopen() */
 +#if SOLARIS_OPENSSL
 +static char *read_mode_flags = "rF";
@@ -6201,9 +6414,12 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +
 +	h_priv_key = sp->opdata_rsa_priv_key;
 +	if (h_priv_key == CK_INVALID_HANDLE)
++		{
 +		h_priv_key = sp->opdata_rsa_priv_key =
 +			pk11_get_private_rsa_key(rsa, &sp->opdata_rsa_priv,
-+			    &sp->opdata_rsa_d_num, sp->session);
++			    &sp->opdata_rsa_d_num, &sp->opdata_rsa_pn_num,
++			    &sp->opdata_rsa_pe_num, sp->session);
++		}
 +
 +	if (h_priv_key != CK_INVALID_HANDLE)
 +		{
@@ -6262,7 +6478,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +	if (h_priv_key == CK_INVALID_HANDLE)
 +		h_priv_key = sp->opdata_rsa_priv_key =
 +			pk11_get_private_rsa_key(rsa, &sp->opdata_rsa_priv,
-+			    &sp->opdata_rsa_d_num, sp->session);
++			    &sp->opdata_rsa_d_num, &sp->opdata_rsa_pn_num,
++			    &sp->opdata_rsa_pe_num, sp->session);
 +
 +	if (h_priv_key != CK_INVALID_HANDLE)
 +		{
@@ -6471,8 +6688,9 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +	if (h_priv_key == CK_INVALID_HANDLE)
 +		h_priv_key = sp->opdata_rsa_priv_key =
 +			pk11_get_private_rsa_key((RSA *)rsa,
-+			    &sp->opdata_rsa_priv,
-+			    &sp->opdata_rsa_d_num, sp->session);
++			    &sp->opdata_rsa_priv, &sp->opdata_rsa_d_num,
++			    &sp->opdata_rsa_pn_num, &sp->opdata_rsa_pe_num,
++			    sp->session);
 +
 +	if (h_priv_key != CK_INVALID_HANDLE)
 +		{
@@ -6508,9 +6726,15 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +	return (ret);
 +	}
 +
++#if OPENSSL_VERSION_NUMBER < 0x10000000L
 +static int pk11_RSA_verify(int type, const unsigned char *m,
 +	unsigned int m_len, unsigned char *sigbuf, unsigned int siglen,
 +	const RSA *rsa)
++#else
++static int pk11_RSA_verify(int type, const unsigned char *m,
++	unsigned int m_len, const unsigned char *sigbuf, unsigned int siglen,
++	const RSA *rsa)
++#endif
 +	{
 +	X509_SIG sig;
 +	ASN1_TYPE parameter;
@@ -6605,8 +6829,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +			    rv);
 +			goto err;
 +			}
-+		rv = pFuncList->C_Verify(sp->session, s, i, sigbuf,
-+			(CK_ULONG)siglen);
++		rv = pFuncList->C_Verify(sp->session, s, i,
++			(CK_BYTE_PTR)sigbuf, (CK_ULONG)siglen);
 +
 +		if (rv != CKR_OK)
 +			{
@@ -6629,7 +6853,12 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +
 +static int hndidx_rsa = -1;
 +
-+/* load RSA private key from a file */
++#define	MAXATTR	1024
++
++/*
++ * Load RSA private key from a file or get its PKCS#11 handle if stored in the
++ * PKCS#11 token.
++ */
 +/* ARGSUSED */
 +EVP_PKEY *pk11_load_privkey(ENGINE *e, const char *privkey_file,
 +	UI_METHOD *ui_method, void *callback_data)
@@ -6637,16 +6866,15 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +	EVP_PKEY *pkey = NULL;
 +	FILE *privkey;
 +	CK_OBJECT_HANDLE  h_priv_key = CK_INVALID_HANDLE;
-+	RSA *rsa;
++	RSA *rsa = NULL;
 +	PK11_SESSION *sp;
-+	/* everything else below needed for key by reference extension */
++	/* Anything else below is needed for the key by reference extension. */
 +	CK_RV rv;
-+	CK_ULONG objcnt = 0;
 +	CK_BBOOL is_token = TRUE;
-+	CK_BYTE attr_data[2][1024];
++	CK_BBOOL rollback = FALSE;
++	CK_BYTE attr_data[2][MAXATTR];
 +	CK_OBJECT_CLASS key_class = CKO_PRIVATE_KEY;
 +	CK_OBJECT_HANDLE ks_key = CK_INVALID_HANDLE;	/* key in keystore */
-+	extern char *pk11_pin;
 +
 +	/* we look for private keys only */
 +	CK_ATTRIBUTE search_templ[] =
@@ -6656,11 +6884,15 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +		{CKA_LABEL, NULL, 0}
 +		};
 +
-+	/* these attributes are needed to initialize OpenSSL RSA structure */
++	/*
++	 * These public attributes are needed to initialize the OpenSSL RSA
++	 * structure with something we can use to look up the key. Note that we
++	 * never ask for private components.
++	 */
 +	CK_ATTRIBUTE get_templ[] =
 +		{
-+		{CKA_MODULUS, (void *)attr_data[0], 1024},	    /* n */
-+		{CKA_PUBLIC_EXPONENT, (void *)attr_data[1], 1024},  /* e */
++		{CKA_MODULUS, (void *)attr_data[0], MAXATTR},		/* n */
++		{CKA_PUBLIC_EXPONENT, (void *)attr_data[1], MAXATTR},	/* e */
 +		};
 +
 +	if ((sp = pk11_get_session(OP_RSA)) == NULL)
@@ -6674,99 +6906,91 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +		search_templ[2].pValue = strstr(privkey_file, ":") + 1;
 +		search_templ[2].ulValueLen = strlen(search_templ[2].pValue);
 +
-+		if (pk11_pin == NULL)
-+			{
-+			pk11_pin = BUF_strdup(getpassphrase("Enter PIN: "));
-+
-+			if (pk11_pin == NULL)
-+				{
-+				PK11err(PK11_F_LOAD_PRIVKEY, PK11_R_MALLOC_FAILURE);
-+				goto err;
-+				}
-+			}
-+		if ((rv = pFuncList->C_Login(sp->session, CKU_USER, (CK_UTF8CHAR*)pk11_pin,
-+		    strlen(pk11_pin))) != CKR_OK && rv != CKR_USER_ALREADY_LOGGED_IN)
-+			{
-+			PK11err_add_data(PK11_F_LOAD_PRIVKEY,
-+					 PK11_R_INVALID_PIN, rv);
-+			goto err;
-+			}
-+
-+		LOCK_OBJSTORE(OP_RSA);
-+		if ((rv = pFuncList->C_FindObjectsInit(sp->session,
-+		    search_templ, 3)) != CKR_OK)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err_add_data(PK11_F_LOAD_PRIVKEY,
-+					 PK11_R_FINDOBJECTSINIT, rv);
-+			goto err;
-+			}
-+
-+		rv = pFuncList->C_FindObjects(sp->session, &ks_key, 1, &objcnt);
-+		if (rv != CKR_OK)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err_add_data(PK11_F_LOAD_PRIVKEY,
-+					 PK11_R_FINDOBJECTS, rv);
++		if (pk11_token_login(sp->session, &pk11_login_done,
++		    CK_TRUE) == 0)
 +			goto err;
-+			}
 +
-+		if (objcnt > 1)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err(PK11_F_LOAD_PRIVKEY, PK11_R_TOO_MANY_OBJECTS);
-+			goto err;
-+			}
-+
-+		if (objcnt != 1)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err(PK11_F_LOAD_PRIVKEY, PK11_R_OBJECT_NOT_FOUND);
++		/*
++		 * Now let's try to find the key in the token. It is a failure
++		 * if we can't find it.
++		 */
++		if (find_one_object(OP_RSA, sp->session, search_templ, 3,
++		    &ks_key) == 0)
 +			goto err;
-+			}
-+
-+		(void) pFuncList->C_FindObjectsFinal(sp->session);
-+		UNLOCK_OBJSTORE(OP_RSA);
 +
 +		if (hndidx_rsa == -1)
 +			hndidx_rsa = RSA_get_ex_new_index(0,
 +				        "pkcs11 RSA HSM key handle",
 +					NULL, NULL, NULL);
 +
-+		pkey = EVP_PKEY_new();
-+		if (pkey == NULL)
-+			goto err;
++		/*
++		 * We might have a cache hit which we could confirm
++		 * according to the 'n'/'e' params, RSA public pointer
++		 * as NULL, and non-NULL RSA private pointer. However,
++		 * it is easier just to recreate everything. We expect
++		 * the keys to be loaded once and used many times. We
++		 * do not check the return value because even in case
++		 * of failure the sp structure will have both key
++		 * pointer and object handle cleaned and
++		 * pk11_destroy_object() reports the failure to the
++		 * OpenSSL error message buffer.
++		 */
++		(void) pk11_destroy_rsa_object_priv(sp, TRUE);
++
++		sp->opdata_rsa_priv_key = ks_key;
++		/* This object shall not be deleted on a cache miss. */
++		sp->priv_persistent = CK_TRUE;
 +
-+		rsa = RSA_new_method(e);
-+		if (rsa == NULL) {
-+			EVP_PKEY_free(pkey);
-+			pkey = NULL;
++		/*
++		 * Cache the RSA private structure pointer. We do not
++		 * use it now for key-by-ref keys but let's do it for
++		 * consistency reasons.
++		 */
++		if ((rsa = sp->opdata_rsa_priv = RSA_new_method(e)) == NULL)
 +			goto err;
-+		}
-+		EVP_PKEY_assign_RSA(pkey, rsa);
++
++		/*
++		 * Now we have to initialize an OpenSSL RSA structure,
++		 * everything else is 0 or NULL.
++		 */
++		rsa->flags = RSA_FLAG_SIGN_VER | RSA_FLAG_EXT_PKEY;
++		RSA_set_ex_data(rsa, hndidx_rsa, (void *) ks_key);
 +
 +		if ((rv = pFuncList->C_GetAttributeValue(sp->session, ks_key,
 +		    get_templ, 2)) != CKR_OK)
 +			{
 +			PK11err_add_data(PK11_F_LOAD_PRIVKEY,
 +					 PK11_R_GETATTRIBUTVALUE, rv);
-+			EVP_PKEY_free(pkey);
-+			pkey = NULL;
 +			goto err;
 +			}
 +
 +		/*
-+		 * Now we have to initialize an OpenSSL RSA structure,
-+		 * everything else is 0 or NULL.
++		 * We do not use pk11_get_private_rsa_key() here so we
++		 * must take care of handle management ourselves.
 +		 */
-+		rsa->flags = RSA_FLAG_SIGN_VER | RSA_FLAG_EXT_PKEY;
-+		RSA_set_ex_data(rsa, hndidx_rsa, (void *) ks_key);
-+		(void) check_new_rsa_key_priv(sp, rsa);
-+		sp->opdata_rsa_priv = rsa;
-+		sp->opdata_rsa_priv_key = ks_key;
++		KEY_HANDLE_REFHOLD(ks_key, OP_RSA, FALSE, rollback, err);
 +
++		/*
++		 * Those are the sensitive components we do not want to export
++		 * from the token at all: rsa->(d|p|q|dmp1|dmq1|iqmp).
++		 */
 +		attr_to_BN(&get_templ[0], attr_data[0], &rsa->n);
 +		attr_to_BN(&get_templ[1], attr_data[1], &rsa->e);
++		/*
++		 * Must have 'n'/'e' components in the session structure as
++		 * well. They serve as a public look-up key for the private key
++		 * in the keystore.
++		 */
++		attr_to_BN(&get_templ[0], attr_data[0],
++			&sp->opdata_rsa_pn_num);
++		attr_to_BN(&get_templ[1], attr_data[1],
++			&sp->opdata_rsa_pe_num);
++
++		if ((pkey = EVP_PKEY_new()) == NULL)
++			goto err;
++
++		if (EVP_PKEY_assign_RSA(pkey, rsa) == 0)
++			goto err;
 +		}
 +	else if ((privkey = fopen(privkey_file, read_mode_flags)) != NULL)
 +		{
@@ -6777,32 +7001,47 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +			rsa = EVP_PKEY_get1_RSA(pkey);
 +			if (rsa != NULL)
 +				{
++				/*
++				 * This will always destroy the RSA
++				 * object since we have a new RSA
++				 * structure here.
++				 */
 +				(void) check_new_rsa_key_priv(sp, rsa);
++				sp->priv_persistent = CK_FALSE;
 +
 +				h_priv_key = sp->opdata_rsa_priv_key =
 +				    pk11_get_private_rsa_key(rsa,
-+				    &sp->opdata_rsa_priv, &sp->opdata_rsa_d_num,
-+				    sp->session);
++				    &sp->opdata_rsa_priv,
++				    &sp->opdata_rsa_d_num,
++				    &sp->opdata_rsa_pn_num,
++				    &sp->opdata_rsa_pe_num, sp->session);
 +				if (h_priv_key == CK_INVALID_HANDLE)
-+					{
-+					EVP_PKEY_free(pkey);
-+					pkey = NULL;
-+					}
++					goto err;
 +				}
 +			else
-+				{
-+				EVP_PKEY_free(pkey);
-+				pkey = NULL;
-+				}
++				goto err;
 +			}
 +		}
 +
++	pk11_return_session(sp, OP_RSA);
++	return (pkey);
 +err:
 +	pk11_return_session(sp, OP_RSA);
++	if (rsa != NULL)
++		RSA_free(rsa);
++	if (pkey != NULL)
++		{
++		EVP_PKEY_free(pkey);
++		pkey = NULL;
++		}
++	rollback = rollback;
 +	return (pkey);
 +	}
 +
-+/* load RSA public key from a file */
++/*
++ * Load RSA public key from a file or get its PKCS#11 handle if stored in the
++ * PKCS#11 token.
++ */
 +/* ARGSUSED */
 +EVP_PKEY *pk11_load_pubkey(ENGINE *e, const char *pubkey_file,
 +	UI_METHOD *ui_method, void *callback_data)
@@ -6810,16 +7049,14 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +	EVP_PKEY *pkey = NULL;
 +	FILE *pubkey;
 +	CK_OBJECT_HANDLE h_pub_key = CK_INVALID_HANDLE;
-+	RSA *rsa;
++	RSA *rsa = NULL;
 +	PK11_SESSION *sp;
-+	/* everything else below needed for key by reference extension */
++	/* Anything else below is needed for the key by reference extension. */
 +	CK_RV rv;
-+	CK_ULONG objcnt = 0;
 +	CK_BBOOL is_token = TRUE;
-+	CK_BYTE attr_data[2][1024];
++	CK_BYTE attr_data[2][MAXATTR];
 +	CK_OBJECT_CLASS key_class = CKO_PUBLIC_KEY;
 +	CK_OBJECT_HANDLE ks_key = CK_INVALID_HANDLE;	/* key in keystore */
-+	extern char *pk11_pin;
 +
 +	/* we look for public keys only */
 +	CK_ATTRIBUTE search_templ[] =
@@ -6829,11 +7066,14 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +		{CKA_LABEL, NULL, 0}
 +		};
 +
-+	/* these attributes are needed to initialize OpenSSL RSA structure */
++	/*
++	 * These public attributes are needed to initialize OpenSSL RSA
++	 * structure with something we can use to look up the key.
++	 */
 +	CK_ATTRIBUTE get_templ[] =
 +		{
-+		{CKA_MODULUS, (void *)attr_data[0], 1024},	    /* n */
-+		{CKA_PUBLIC_EXPONENT, (void *)attr_data[1], 1024},  /* e */
++		{CKA_MODULUS, (void *)attr_data[0], MAXATTR},		/* n */
++		{CKA_PUBLIC_EXPONENT, (void *)attr_data[1], MAXATTR},	/* e */
 +		};
 +
 +	if ((sp = pk11_get_session(OP_RSA)) == NULL)
@@ -6847,92 +7087,75 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +		search_templ[2].pValue = strstr(pubkey_file, ":") + 1;
 +		search_templ[2].ulValueLen = strlen(search_templ[2].pValue);
 +
-+#define ALLWAYS_LOGIN
-+#ifdef ALLWAYS_LOGIN
-+		if (pk11_pin == NULL)
-+			{
-+			pk11_pin = BUF_strdup(getpassphrase("Enter PIN: "));
-+
-+			if (pk11_pin == NULL)
-+				{
-+				PK11err(PK11_F_LOAD_PUBKEY, PK11_R_MALLOC_FAILURE);
-+				goto err;
-+				}
-+			}
-+		if ((rv = pFuncList->C_Login(sp->session, CKU_USER, (CK_UTF8CHAR*)pk11_pin,
-+		    strlen(pk11_pin))) != CKR_OK && rv != CKR_USER_ALREADY_LOGGED_IN)
-+			{
-+			PK11err_add_data(PK11_F_LOAD_PUBKEY,
-+					 PK11_R_INVALID_PIN, rv);
-+			goto err;
-+			}
-+#endif
-+
-+		LOCK_OBJSTORE(OP_RSA);
-+		if (pFuncList->C_FindObjectsInit(sp->session, search_templ, 3) != CKR_OK)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err_add_data(PK11_F_LOAD_PUBKEY,
-+					 PK11_R_FINDOBJECTSINIT, rv);
-+			goto err;
-+			}
-+		rv = pFuncList->C_FindObjects(sp->session, &ks_key, 1, &objcnt);
-+		if (rv != CKR_OK)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err_add_data(PK11_F_LOAD_PUBKEY,
-+					 PK11_R_FINDOBJECTS, rv);
-+			goto err;
-+			}
-+
-+		if (objcnt > 1)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err(PK11_F_LOAD_PUBKEY, PK11_R_TOO_MANY_OBJECTS);
++		if (pk11_token_login(sp->session, &pk11_login_done,
++		    CK_FALSE) == 0)
 +			goto err;
-+			}
 +
-+		if (objcnt != 1)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err(PK11_F_LOAD_PUBKEY, PK11_R_OBJECT_NOT_FOUND);
++		/*
++		 * Now let's try to find the key in the token. It is a failure
++		 * if we can't find it.
++		 */
++		if (find_one_object(OP_RSA, sp->session, search_templ, 3,
++		    &ks_key) == 0)
 +			goto err;
-+			}
 +
-+		(void) pFuncList->C_FindObjectsFinal(sp->session);
-+		UNLOCK_OBJSTORE(OP_RSA);
++		/*
++		 * We load a new public key so we will create a new RSA
++		 * structure. No cache hit is possible.
++		 */
++		(void) pk11_destroy_rsa_object_pub(sp, TRUE);
 +
 +		sp->opdata_rsa_pub_key = ks_key;
-+		pkey = EVP_PKEY_new();
-+		if (pkey == NULL)
-+			goto err;
++		/* This object shall not be deleted on a cache miss. */
++		sp->pub_persistent = CK_TRUE;
 +
-+		rsa = RSA_new_method(e);
-+		if (rsa == NULL) {
-+			EVP_PKEY_free(pkey);
-+			pkey = NULL;
-+			goto err;
-+		}
-+		EVP_PKEY_assign_RSA(pkey, rsa);
-+
-+		if (pFuncList->C_GetAttributeValue(sp->session, ks_key,
-+		    get_templ, 2) != CKR_OK)
-+			{
-+			PK11err_add_data(PK11_F_LOAD_PUBKEY,
-+					 PK11_R_GETATTRIBUTVALUE, rv);
++		/*
++		 * Cache the RSA public structure pointer.
++		 */
++		if ((rsa = sp->opdata_rsa_pub = RSA_new_method(e)) == NULL)
 +			goto err;
-+			}
 +
 +		/*
 +		 * Now we have to initialize an OpenSSL RSA structure,
 +		 * everything else is 0 or NULL.
 +		 */
 +		rsa->flags = RSA_FLAG_SIGN_VER;
-+		(void) check_new_rsa_key_pub(sp, rsa);
-+		sp->opdata_rsa_pub = rsa;
++
++		if ((rv = pFuncList->C_GetAttributeValue(sp->session, ks_key,
++		    get_templ, 2)) != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_LOAD_PUBKEY,
++					 PK11_R_GETATTRIBUTVALUE, rv);
++			goto err;
++			}
 +
 +		attr_to_BN(&get_templ[0], attr_data[0], &rsa->n);
 +		attr_to_BN(&get_templ[1], attr_data[1], &rsa->e);
++
++		if ((pkey = EVP_PKEY_new()) == NULL)
++			goto err;
++
++		if (EVP_PKEY_assign_RSA(pkey, rsa) == 0)
++			goto err;
++
++		/*
++		 * Create a session object from it so that when calling
++		 * pk11_get_public_rsa_key() the next time, we can find it. The
++		 * reason why we do that is that we cannot tell from the RSA
++		 * structure (OpenSSL RSA structure does not have any room for
++		 * additional data used by the engine, for example) if it bears
++		 * a public key stored in the keystore or not so it's better if
++		 * we always have a session key. Note that this is different
++		 * from what we do for the private keystore objects but in that
++		 * case, we can tell from the RSA structure that the keystore
++		 * object is in play - the 'd' component is NULL in that case.
++		 */
++		h_pub_key = sp->opdata_rsa_pub_key =
++		    pk11_get_public_rsa_key(rsa,
++		    &sp->opdata_rsa_pub, &sp->opdata_rsa_n_num,
++		    &sp->opdata_rsa_e_num, sp->session);
++		if (h_pub_key == CK_INVALID_HANDLE)
++			goto err;
 +		}
 +	else if ((pubkey = fopen(pubkey_file, read_mode_flags)) != NULL)
 +		{
@@ -6943,28 +7166,37 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +			rsa = EVP_PKEY_get1_RSA(pkey);
 +			if (rsa != NULL)
 +				{
++				/*
++				 * This will always destroy the RSA
++				 * object since we have a new RSA
++				 * structure here.
++				 */
 +				(void) check_new_rsa_key_pub(sp, rsa);
++				sp->pub_persistent = CK_FALSE;
 +
 +				h_pub_key = sp->opdata_rsa_pub_key =
 +				    pk11_get_public_rsa_key(rsa,
 +				    &sp->opdata_rsa_pub, &sp->opdata_rsa_n_num,
 +				    &sp->opdata_rsa_e_num, sp->session);
 +				if (h_pub_key == CK_INVALID_HANDLE)
-+					{
-+					EVP_PKEY_free(pkey);
-+					pkey = NULL;
-+					}
++					goto err;
 +				}
 +			else
-+				{
-+				EVP_PKEY_free(pkey);
-+				pkey = NULL;
-+				}
++				goto err;
 +			}
 +		}
 +
++	pk11_return_session(sp, OP_RSA);
++	return (pkey);
 +err:
 +	pk11_return_session(sp, OP_RSA);
++	if (rsa != NULL)
++		RSA_free(rsa);
++	if (pkey != NULL)
++		{
++		EVP_PKEY_free(pkey);
++		pkey = NULL;
++		}
 +	return (pkey);
 +	}
 +
@@ -7025,13 +7257,14 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +
 +	/* see find_lock array definition for more info on object locking */
 +	LOCK_OBJSTORE(OP_RSA);
++
 +	rv = pFuncList->C_FindObjectsInit(session, a_key_template,
 +		ul_key_attr_count);
 +
 +	if (rv != CKR_OK)
 +		{
-+		PK11err_add_data(PK11_F_GET_PUB_RSA_KEY, PK11_R_FINDOBJECTSINIT,
-+		    rv);
++		PK11err_add_data(PK11_F_GET_PUB_RSA_KEY,
++		    PK11_R_FINDOBJECTSINIT, rv);
 +		goto err;
 +		}
 +
@@ -7118,8 +7351,9 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 + * Create a private key object in the session from a given rsa structure.
 + * The *rsa_d_num pointer is non-NULL for RSA private keys.
 + */
-+static CK_OBJECT_HANDLE pk11_get_private_rsa_key(RSA *rsa,
-+    RSA **key_ptr, BIGNUM **rsa_d_num, CK_SESSION_HANDLE session)
++static CK_OBJECT_HANDLE
++pk11_get_private_rsa_key(RSA *rsa, RSA **key_ptr, BIGNUM **rsa_d_num,
++    BIGNUM **rsa_n_num, BIGNUM **rsa_e_num, CK_SESSION_HANDLE session)
 +	{
 +	CK_RV rv;
 +	CK_OBJECT_HANDLE h_key = CK_INVALID_HANDLE;
@@ -7146,7 +7380,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +		{CKA_PRIME_2, (void *)NULL, 0},
 +		{CKA_EXPONENT_1, (void *)NULL, 0},
 +		{CKA_EXPONENT_2, (void *)NULL, 0},
-+		{CKA_COEFFICIENT, (void *)NULL, 0}
++		{CKA_COEFFICIENT, (void *)NULL, 0},
 +		};
 +
 +	if ((rsa->flags & RSA_FLAG_EXT_PKEY) != 0) {
@@ -7182,6 +7416,23 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +
 +	/* see find_lock array definition for more info on object locking */
 +	LOCK_OBJSTORE(OP_RSA);
++
++	/*
++	 * We are getting the private key but the private 'd'
++	 * component is NULL.  That means this is key by reference RSA
++	 * key. In that case, we can use only public components for
++	 * searching for the private key handle.
++	 */
++	if (rsa->d == NULL)
++		{
++		ul_key_attr_count = 8;
++		/*
++		 * We will perform the search in the token, not in the existing
++		 * session keys.
++		 */
++		a_key_template[2].pValue = &true;
++		}
++
 +	rv = pFuncList->C_FindObjectsInit(session, a_key_template,
 +		ul_key_attr_count);
 +
@@ -7212,6 +7463,21 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +
 +	if (found == 0)
 +		{
++		/*
++		 * We have an RSA structure with 'n'/'e' components
++		 * only so we tried to find the private key in the
++		 * keystore. If it was really a token key we have a
++		 * problem. Note that for other key types we just
++		 * create a new session key using the private
++		 * components from the RSA structure.
++		 */
++		if (rsa->d == NULL)
++			{
++			PK11err(PK11_F_GET_PRIV_RSA_KEY,
++			    PK11_R_PRIV_KEY_NOT_FOUND);
++			goto err;
++			}
++
 +		rv = pFuncList->C_CreateObject(session,
 +			a_key_template, ul_key_attr_count, &h_key);
 +		if (rv != CKR_OK)
@@ -7225,16 +7491,36 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +set:
 +	if (rsa_d_num != NULL)
 +		{
-+		if (rsa->d == NULL)
-+			*rsa_d_num = NULL;
-+		else if ((*rsa_d_num = BN_dup(rsa->d)) == NULL)
++		/*
++		 * When RSA keys by reference code is used, we never
++		 * extract private components from the keystore. In
++		 * that case 'd' was set to NULL and we expect the
++		 * application to properly cope with that. It is
++		 * documented in openssl(5). In general, if keys by
++		 * reference are used we expect it to be used
++		 * exclusively using the high level API and then there
++		 * is no problem. If the application expects the
++		 * private components to be read from the keystore
++		 * then that is not a supported way of usage.
++		 */
++		if (rsa->d != NULL && (*rsa_d_num = BN_dup(rsa->d)) == NULL)
 +			{
 +			PK11err(PK11_F_GET_PRIV_RSA_KEY, PK11_R_MALLOC_FAILURE);
 +			rollback = TRUE;
 +			goto err;
 +			}
++		else
++			*rsa_d_num = NULL;
 +		}
 +
++	/*
++	 * For the key by reference code, we need public components as well
++	 * since 'd' component is always NULL. For that reason, we always cache
++	 * 'n'/'e' components as well.
++	 */
++	*rsa_n_num = BN_dup(rsa->n);
++	*rsa_e_num = BN_dup(rsa->e);
++
 +	/* LINTED: E_CONSTANT_CONDITION */
 +	KEY_HANDLE_REFHOLD(h_key, OP_RSA, FALSE, rollback, err);
 +	if (key_ptr != NULL)
@@ -7258,7 +7544,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +malloc_err:
 +	/*
 +	 * 6 to 13 entries in the key template are key components.
-+	 * They need to be freed apon exit or error.
++	 * They need to be freed upon exit or error.
 +	 */
 +	for (i = 6; i <= 13; i++)
 +		{
@@ -7285,10 +7571,17 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +	 * check for cache hit stronger. Only public components of RSA
 +	 * key matter here so it is sufficient to compare them with values
 +	 * cached in PK11_SESSION structure.
++	 *
++	 * We must check the handle as well since with key by reference, public
++	 * components 'n'/'e' are cached in private keys as well. That means we
++	 * could have a cache hit in a private key when looking for a public
++	 * key. That would not work, you cannot have one PKCS#11 object for
++	 * both data signing and verifying.
 +	 */
 +	if ((sp->opdata_rsa_pub != rsa) ||
 +	    (BN_cmp(sp->opdata_rsa_n_num, rsa->n) != 0) ||
-+	    (BN_cmp(sp->opdata_rsa_e_num, rsa->e) != 0))
++	    (BN_cmp(sp->opdata_rsa_e_num, rsa->e) != 0) ||
++	    (sp->opdata_rsa_priv_key != CK_INVALID_HANDLE))
 +		{
 +		/*
 +		 * We do not check the return value because even in case of
@@ -7309,14 +7602,21 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +static int check_new_rsa_key_priv(PK11_SESSION *sp, const RSA *rsa)
 +	{
 +	/*
-+	 * Provide protection against RSA structure reuse by making the
-+	 * check for cache hit stronger. Comparing private exponent of RSA
-+	 * key with value cached in PK11_SESSION structure should
-+	 * be sufficient.
++	 * Provide protection against RSA structure reuse by making
++	 * the check for cache hit stronger. Comparing public exponent
++	 * of RSA key with value cached in PK11_SESSION structure
++	 * should be sufficient. Note that we want to compare the
++	 * public component since with the keys by reference
++	 * mechanism, private components are not in the RSA
++	 * structure. Also, see check_new_rsa_key_pub() about why we
++	 * compare the handle as well.
 +	 */
 +	if ((sp->opdata_rsa_priv != rsa) ||
-+	    (BN_cmp(sp->opdata_rsa_d_num, rsa->d) != 0) ||
-+	    ((rsa->flags & RSA_FLAG_EXT_PKEY) != 0))
++	    (BN_cmp(sp->opdata_rsa_pn_num, rsa->n) != 0) ||
++	    (BN_cmp(sp->opdata_rsa_pe_num, rsa->e) != 0) ||
++	    (sp->opdata_rsa_pn_num == NULL) ||
++	    (sp->opdata_rsa_pe_num == NULL) ||
++	    (sp->opdata_rsa_pub_key != CK_INVALID_HANDLE))
 +		{
 +		/*
 +		 * We do not check the return value because even in case of
@@ -7599,8 +7899,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +
 +	if (rv != CKR_OK)
 +		{
-+		PK11err_add_data(PK11_F_GET_PUB_DSA_KEY, PK11_R_FINDOBJECTSINIT,
-+		    rv);
++		PK11err_add_data(PK11_F_GET_PUB_DSA_KEY,
++		    PK11_R_FINDOBJECTSINIT, rv);
 +		goto err;
 +		}
 +
@@ -8457,11 +8757,20 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 + * Local function to simplify key template population
 + * Return 0 -- error, 1 -- no error
 + */
-+static int init_template_value(BIGNUM *bn, CK_VOID_PTR *p_value,
++static int
++init_template_value(BIGNUM *bn, CK_VOID_PTR *p_value,
 +	CK_ULONG *ul_value_len)
 +	{
-+	CK_ULONG len = BN_num_bytes(bn);
-+	if (len == 0)
++	CK_ULONG len = 0;
++
++	/*
++	 * This function can be used on non-initialized BIGNUMs. It is
++	 * easier to check that here than individually in the callers.
++	 */
++	if (bn != NULL)
++		len = BN_num_bytes(bn);
++
++	if (bn == NULL || len == 0)
 +		return (1);
 +
 +	*ul_value_len = len;
@@ -8474,13 +8783,289 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +	return (1);
 +	}
 +
-+static void attr_to_BN(CK_ATTRIBUTE_PTR attr, CK_BYTE attr_data[], BIGNUM **bn)
++static void
++attr_to_BN(CK_ATTRIBUTE_PTR attr, CK_BYTE attr_data[], BIGNUM **bn)
 +	{
 +	if (attr->ulValueLen > 0)
-+		{
 +		*bn = BN_bin2bn(attr_data, attr->ulValueLen, NULL);
++	}
++
++/*
++ * Find one object in the token. It is an error if we can not find the
++ * object or if we find more objects based on the template we got.
++ *
++ * Returns:
++ *	1 OK
++ *	0 no object or more than 1 object found
++ */
++static int
++find_one_object(PK11_OPTYPE op, CK_SESSION_HANDLE s,
++    CK_ATTRIBUTE_PTR ptempl, CK_ULONG nattr, CK_OBJECT_HANDLE_PTR pkey)
++	{
++	CK_RV rv;
++	CK_ULONG objcnt;
++
++	LOCK_OBJSTORE(op);
++	if ((rv = pFuncList->C_FindObjectsInit(s, ptempl, nattr)) != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_FIND_ONE_OBJECT,
++		    PK11_R_FINDOBJECTSINIT, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjects(s, pkey, 1, &objcnt);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_FIND_ONE_OBJECT, PK11_R_FINDOBJECTS,
++		    rv);
++		goto err;
++		}
++
++	if (objcnt > 1)
++		{
++		PK11err(PK11_F_FIND_ONE_OBJECT,
++		    PK11_R_MORE_THAN_ONE_OBJECT_FOUND);
++		goto err;
 +		}
++	else if (objcnt == 0)
++		{
++		PK11err(PK11_F_FIND_ONE_OBJECT, PK11_R_NO_OBJECT_FOUND);
++		goto err;
++		}
++
++	(void) pFuncList->C_FindObjectsFinal(s);
++	UNLOCK_OBJSTORE(op);
++	return (1);
++err:
++	UNLOCK_OBJSTORE(op);
++	return (0);
++	}
++
++/* from uri stuff */
++
++extern char *pk11_pin;
++
++static int pk11_get_pin(void);
++
++static int
++pk11_get_pin(void)
++{
++	char *pin;
++
++	/* The getpassphrase() function is not MT safe. */
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(token_lock);
++#else
++	CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	pin = getpassphrase("Enter PIN: ");
++	if (pin == NULL)
++		{
++		PK11err(PK11_F_GET_PIN, PK11_R_COULD_NOT_READ_PIN);
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		goto err;
++		}
++	pk11_pin = BUF_strdup(pin);
++	if (pk11_pin == NULL)
++		{
++		PK11err(PK11_F_LOAD_PRIVKEY, PK11_R_MALLOC_FAILURE);
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		goto err;
++		}
++	memset(pin, 0, strlen(pin));
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(token_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	return (1);
++err:
++	return (0);
++	}
++
++/*
++ * Log in to the keystore if we are supposed to do that at all. Take care of
++ * reading and caching the PIN etc. Log in only once even when called from
++ * multiple threads.
++ *
++ * Returns:
++ *	1 on success
++ *	0 on failure
++ */
++static int
++pk11_token_login(CK_SESSION_HANDLE session, CK_BBOOL *login_done,
++    CK_BBOOL is_private)
++	{
++	CK_RV rv;
++
++#if 0
++	/* doesn't work on the AEP Keyper??? */
++	if ((pubkey_token_flags & CKF_TOKEN_INITIALIZED) == 0)
++		{
++		PK11err(PK11_F_TOKEN_LOGIN,
++		    PK11_R_TOKEN_NOT_INITIALIZED);
++		goto err;
++		}
++#endif
++
++	/*
++	 * If login is required or needed but the PIN has not been
++	 * even initialized we can bail out right now. Note that we
++	 * are supposed to always log in if we are going to access
++	 * private keys. However, we may need to log in even for
++	 * accessing public keys in case that the CKF_LOGIN_REQUIRED
++	 * flag is set.
++	 */
++	if (((pubkey_token_flags & CKF_LOGIN_REQUIRED) ||
++	     (is_private == CK_TRUE)) &&
++	    (~pubkey_token_flags & CKF_USER_PIN_INITIALIZED))
++		{
++		PK11err(PK11_F_TOKEN_LOGIN, PK11_R_TOKEN_PIN_NOT_SET);
++		goto err;
++		}
++
++	/*
++	 * Note on locking: it is possible that more than one thread
++	 * gets into pk11_get_pin() so we must deal with that. We
++	 * cannot avoid it since we cannot guard fork() in there with
++	 * a lock because we could end up in a dead lock in the
++	 * child. Why? Remember we are in a multithreaded environment
++	 * so we must lock all mutexes in the prefork function to
++	 * avoid a situation in which a thread that did not call
++	 * fork() held a lock, making future unlocking impossible. We
++	 * lock right before C_Login().
++	 */
++	if ((pubkey_token_flags & CKF_LOGIN_REQUIRED) ||
++	    (is_private == CK_TRUE))
++		{
++		if (*login_done == CK_FALSE)
++			{
++			if ((pk11_pin == NULL) && (pk11_get_pin() == 0))
++				{
++				PK11err(PK11_F_TOKEN_LOGIN,
++				    PK11_R_TOKEN_PIN_NOT_PROVIDED);
++				goto err;
++				}
++			}
++
++		/*
++		 * Note that what we are logging into is the keystore from
++		 * pubkey_SLOTID because we work with OP_RSA session type here.
++		 * That also means that we can work with only one keystore in
++		 * the engine.
++		 *
++		 * We must make sure we do not try to login more than once.
++		 * Also, see the comment above on locking strategy.
++		 */
++
++#ifndef NOPTHREADS
++		(void) pthread_mutex_lock(token_lock);
++#else
++		(void) pthread_mutex_lock(freelist_lock);
++#endif
++		if (*login_done == CK_FALSE)
++			{
++			if ((rv = pFuncList->C_Login(session,
++			    CKU_USER, (CK_UTF8CHAR*)pk11_pin,
++			    strlen(pk11_pin))) != CKR_OK)
++				{
++				PK11err_add_data(PK11_F_TOKEN_LOGIN,
++				    PK11_R_TOKEN_LOGIN_FAILED, rv);
++				goto err_locked;
++				}
++
++			*login_done = CK_TRUE;
++
++			}
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		}
++	else
++		{
++			/*
++			 * If token does not require login we take it as the
++			 * login was done.
++			 */
++			*login_done = CK_TRUE;
++		}
++
++	return (1);
++
++err_locked:
++	if (pk11_pin) {
++		memset(pk11_pin, 0, strlen(pk11_pin));
++		OPENSSL_free((void*)pk11_pin);
++	}
++	pk11_pin = NULL;
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(token_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++err:
++	return (0);
++	}
++
++/*
++ * Log in to the keystore in the child if we were logged in in the
++ * parent. There are similarities in the code with pk11_token_login()
++ * but still it is quite different so we need a separate function for
++ * this.
++ *
++ * Note that this function is called under the locked session mutex when fork is
++ * detected. That means that C_Login() will be called from the child just once.
++ *
++ * Returns:
++ *	1 on success
++ *	0 on failure
++ */
++int
++pk11_token_relogin(CK_SESSION_HANDLE session)
++	{
++	CK_RV rv;
++
++	if ((pk11_pin == NULL) && (pk11_get_pin() == 0))
++		goto err;
++
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(token_lock);
++#else
++	(void) pthread_mutex_lock(freelist_lock);
++#endif
++	if ((rv = pFuncList->C_Login(session, CKU_USER,
++	    (CK_UTF8CHAR_PTR)pk11_pin, strlen(pk11_pin))) != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_TOKEN_RELOGIN,
++		    PK11_R_TOKEN_LOGIN_FAILED, rv);
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		goto err;
++		}
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(token_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++
++	return (1);
++err:
++	return (0);
 +	}
++
 +#ifdef	OPENSSL_SYS_WIN32
 +char *getpassphrase(const char *prompt)
 +	{
@@ -8517,14 +9102,17 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.32
 +#endif	/* OPENSSL_NO_HW_PK11 */
 +#endif	/* OPENSSL_NO_HW */
 Index: openssl/crypto/engine/hw_pk11ca.h
-diff -u /dev/null openssl/crypto/engine/hw_pk11ca.h:1.2
---- /dev/null	Thu Dec 24 13:00:45 2009
-+++ openssl/crypto/engine/hw_pk11ca.h	Mon Oct  5 13:17:03 2009
-@@ -0,0 +1,28 @@
+diff -u /dev/null openssl/crypto/engine/hw_pk11ca.h:1.2.4.2
+--- /dev/null	Mon Jan 16 18:53:42 2012
++++ openssl/crypto/engine/hw_pk11ca.h	Wed Jun 15 21:12:32 2011
+@@ -0,0 +1,32 @@
 +/* Redefine all pk11/PK11 external symbols to pk11ca/PK11CA */
 +
++#define token_lock			pk11ca_token_lock
 +#define find_lock			pk11ca_find_lock
 +#define active_list			pk11ca_active_list
++#define pubkey_token_flags		pk11ca_pubkey_token_flags
++#define pubkey_SLOTID			pk11ca_pubkey_SLOTID
 +#define ERR_pk11_error			ERR_pk11ca_error
 +#define PK11err_add_data		PK11CAerr_add_data
 +#define pk11_get_session		pk11ca_get_session
@@ -8546,16 +9134,17 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11ca.h:1.2
 +#define pk11_destroy_dh_key_objects	pk11ca_destroy_dh_key_objects
 +#define pk11_destroy_dh_object		pk11ca_destroy_dh_object
 +#define PK11_DH				PK11CA_DH
++#define pk11_token_relogin		pk11ca_token_relogin
 +#define pFuncList			pk11ca_pFuncList
 +#define pk11_pin			pk11ca_pin
 +#define ENGINE_load_pk11		ENGINE_load_pk11ca
 Index: openssl/crypto/engine/hw_pk11so.c
-diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
---- /dev/null	Thu Dec 24 13:00:46 2009
-+++ openssl/crypto/engine/hw_pk11so.c	Mon Oct  5 13:17:03 2009
-@@ -0,0 +1,1618 @@
+diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.3.4.2
+--- /dev/null	Mon Jan 16 18:53:42 2012
++++ openssl/crypto/engine/hw_pk11so.c	Thu Jun 16 12:31:35 2011
+@@ -0,0 +1,1745 @@
 +/*
-+ * Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
++ * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
 + * Use is subject to license terms.
 + */
 +
@@ -8698,10 +9287,25 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +#include "hw_pk11so.h"
 +#include "hw_pk11_err.c"
 +
++/*
++ * We use this lock to prevent multiple C_Login()s, guard getpassphrase(),
++ * uri_struct manipulation, and static token info. All of that is used by the
++ * RSA keys by reference feature.
++ */
++#ifndef NOPTHREADS
++pthread_mutex_t *token_lock;
++#endif
++
 +/* PKCS#11 session caches and their locks for all operation types */
 +static PK11_CACHE session_cache[OP_MAX];
 +
 +/*
++ * We cache the flags so that we do not have to run C_GetTokenInfo() again when
++ * logging into the token.
++ */
++CK_FLAGS pubkey_token_flags;
++
++/*
 + * As stated in v2.20, 11.7 Object Management Function, in section for
 + * C_FindObjectsInit(), at most one search operation may be active at a given
 + * time in a given session. Therefore, C_Find{,Init,Final}Objects() should be
@@ -8766,8 +9370,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +static int pk11_free_all_sessions(void);
 +static int pk11_free_session_list(PK11_OPTYPE optype);
 +static int pk11_setup_session(PK11_SESSION *sp, PK11_OPTYPE optype);
-+static int pk11_destroy_object(CK_SESSION_HANDLE session,
-+	CK_OBJECT_HANDLE oh);
++static int pk11_destroy_object(CK_SESSION_HANDLE session, CK_OBJECT_HANDLE oh,
++	CK_BBOOL persistent);
 +static const char *get_PK11_LIBNAME(void);
 +static void free_PK11_LIBNAME(void);
 +static long set_PK11_LIBNAME(const char *name);
@@ -8777,27 +9381,19 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +static int pk11_init_all_locks(void);
 +static void pk11_free_all_locks(void);
 +
-+#define	TRY_OBJ_DESTROY(sess_hdl, obj_hdl, retval, uselock, alg_type)	\
++#define	TRY_OBJ_DESTROY(sp, obj_hdl, retval, uselock, alg_type, priv)	\
 +	{								\
 +	if (uselock)							\
 +		LOCK_OBJSTORE(alg_type);				\
 +	if (pk11_active_delete(obj_hdl, alg_type) == 1)			\
 +		{							\
-+		retval = pk11_destroy_object(sess_hdl, obj_hdl);	\
++		  retval = pk11_destroy_object(sp->session, obj_hdl,	\
++		  priv ? sp->priv_persistent : sp->pub_persistent);	\
 +		}							\
 +	if (uselock)							\
 +		UNLOCK_OBJSTORE(alg_type);				\
 +	}
 +
-+#define	TRY_OBJ_DELETE(sess_hdl, obj_hdl, retval, uselock, alg_type)	\
-+	{								\
-+	if (uselock)							\
-+		LOCK_OBJSTORE(alg_type);				\
-+	(void) pk11_active_delete(obj_hdl, alg_type);			\
-+	if (uselock)							\
-+		UNLOCK_OBJSTORE(alg_type);				\
-+	}
-+
 +static CK_BBOOL pk11_have_rsa	= CK_FALSE;
 +static CK_BBOOL pk11_have_random = CK_FALSE;
 +
@@ -8854,12 +9450,14 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +static const char PK11_GET_FUNCTION_LIST[] = "C_GetFunctionList";
 +
 +/*
-+ * These is the static string constant for the DSO file name and the function
-+ * symbol names to bind to.
++ * This is a static string constant for the DSO file name and the function
++ * symbol names to bind to. We set it in the Configure script based on whether
++ * this is 32 or 64 bit build.
 + */
 +static const char def_PK11_LIBNAME[] = PK11_LIB_LOCATION;
 +
-+static CK_SLOT_ID pubkey_SLOTID = 0;
++/* Needed in hw_pk11_pub.c as well so that's why it is not static. */
++CK_SLOT_ID pubkey_SLOTID = 0;
 +static CK_SLOT_ID rand_SLOTID = 0;
 +static CK_SLOT_ID SLOTID = 0;
 +char *pk11_pin = NULL;
@@ -8875,6 +9473,10 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +#ifndef NOPTHREADS
 +	int type;
 +
++	if ((token_lock = OPENSSL_malloc(sizeof (pthread_mutex_t))) == NULL)
++		goto malloc_err;
++	(void) pthread_mutex_init(token_lock, NULL);
++
 +	find_lock[OP_RSA] = OPENSSL_malloc(sizeof (pthread_mutex_t));
 +	if (find_lock[OP_RSA] == NULL)
 +		goto malloc_err;
@@ -9090,6 +9692,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +		return;
 +
 +	LOCK_OBJSTORE(OP_RSA);
++	(void) pthread_mutex_lock(token_lock);
 +	for (i = 0; i < OP_MAX; i++)
 +		{
 +		(void) pthread_mutex_lock(session_cache[i].lock);
@@ -9111,6 +9714,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +		(void) pthread_mutex_unlock(session_cache[i].lock);
 +		}
 +	UNLOCK_OBJSTORE(OP_RSA);
++	(void) pthread_mutex_unlock(token_lock);
 +#endif
 +	}
 +
@@ -9131,6 +9735,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +		(void) pthread_mutex_unlock(session_cache[i].lock);
 +		}
 +	UNLOCK_OBJSTORE(OP_RSA);
++	(void) pthread_mutex_unlock(token_lock);
 +#endif
 +	}
 +
@@ -9140,6 +9745,16 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +	return (pk11_library_init(e));
 +}
 +
++static CK_C_INITIALIZE_ARGS pk11_init_args =
++	{
++	NULL_PTR,		/* CreateMutex */
++	NULL_PTR,		/* DestroyMutex */
++	NULL_PTR,		/* LockMutex */
++	NULL_PTR,		/* UnlockMutex */
++	CKF_OS_LOCKING_OK,	/* flags */
++	NULL_PTR,		/* pReserved */
++	};
++
 +/*
 + * Initialization function. Sets up various PKCS#11 library components.
 + * It selects a slot based on predefined critiera. In the process, it also
@@ -9160,15 +9775,17 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +#endif
 +
 +	/*
-+	 * pk11_library_initialized is set to 0 in pk11_finish() which is called
-+	 * from ENGINE_finish(). However, if there is still at least one
-+	 * existing functional reference to the engine (see engine(3) for more
-+	 * information), pk11_finish() is skipped. For example, this can happen
-+	 * if an application forgets to clear one cipher context. In case of a
-+	 * fork() when the application is finishing the engine so that it can be
-+	 * reinitialized in the child, forgotten functional reference causes
-+	 * pk11_library_initialized to stay 1. In that case we need the PID
-+	 * check so that we properly initialize the engine again.
++	 * pk11_library_initialized is set to 0 in pk11_finish() which
++	 * is called from ENGINE_finish(). However, if there is still
++	 * at least one existing functional reference to the engine
++	 * (see engine(3) for more information), pk11_finish() is
++	 * skipped. For example, this can happen if an application
++	 * forgets to clear one cipher context. In case of a fork()
++	 * when the application is finishing the engine so that it can
++	 * be reinitialized in the child, forgotten functional
++	 * reference causes pk11_library_initialized to stay 1. In
++	 * that case we need the PID check so that we properly
++	 * initialize the engine again.
 +	 */
 +	if (pk11_library_initialized)
 +		{
@@ -9221,7 +9838,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +	(void) sigaction(SIGTERM, NULL, &sigterm_act);
 +	(void) sigaction(SIGHUP, NULL, &sighup_act);
 +#endif
-+	rv = pFuncList->C_Initialize(NULL_PTR);
++	rv = pFuncList->C_Initialize((CK_VOID_PTR)&pk11_init_args);
 +#ifndef OPENSSL_SYS_WIN32
 +	(void) sigaction(SIGINT, &sigint_act, NULL);
 +	(void) sigaction(SIGTERM, &sigterm_act, NULL);
@@ -9510,6 +10127,16 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +				BN_free(sp->opdata_rsa_e_num);
 +				sp->opdata_rsa_e_num = NULL;
 +				}
++			if (sp->opdata_rsa_pn_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_pn_num);
++				sp->opdata_rsa_pn_num = NULL;
++				}
++			if (sp->opdata_rsa_pe_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_pe_num);
++				sp->opdata_rsa_pe_num = NULL;
++				}
 +			if (sp->opdata_rsa_d_num != NULL)
 +				{
 +				BN_free(sp->opdata_rsa_d_num);
@@ -9534,6 +10161,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +#ifndef NOPTHREADS
 +	pthread_mutex_t *freelist_lock = NULL;
 +#endif
++	static pid_t pid = 0;
++	pid_t new_pid;
 +	CK_RV rv;
 +
 +	switch (optype)
@@ -9558,6 +10187,15 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +#else
 +	CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
 +#endif
++
++	/*
++	 * Will use it to find out if we forked. We cannot use the PID field in
++	 * the session structure because we could get a newly allocated session
++	 * here, with no PID information.
++	 */
++	if (pid == 0)
++		pid = getpid();
++
 +	freelist = session_cache[optype].head;
 +	sp = freelist;
 +
@@ -9575,17 +10213,33 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +			goto err;
 +			}
 +		(void) memset(sp, 0, sizeof (PK11_SESSION));
++
++		/*
++		 * It is a new session so it will look like a cache miss to the
++		 * code below. So, we must not try to to destroy its members so
++		 * mark them as unused.
++		 */
++		sp->opdata_rsa_priv_key = CK_INVALID_HANDLE;
++		sp->opdata_rsa_pub_key = CK_INVALID_HANDLE;
 +		}
 +	else
 +		{
 +		freelist = sp->next;
 +		}
 +
-+	if (sp->pid != 0 && sp->pid != getpid())
++	/*
++	 * Check whether we have forked. In that case, we must get rid of all
++	 * inherited sessions and start allocating new ones.
++	 */
++	if (pid != (new_pid = getpid()))
 +		{
++		pid = new_pid;
++
 +		/*
 +		 * We are a new process and thus need to free any inherited
-+		 * PK11_SESSION objects.
++		 * PK11_SESSION objects aside from the first session (sp) which
++		 * is the only PK11_SESSION structure we will reuse (for the
++		 * head of the list).
 +		 */
 +		while ((sp1 = freelist) != NULL)
 +			{
@@ -9603,7 +10257,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +		pk11_free_active_list(optype);
 +
 +		/* Initialize the process */
-+		rv = pFuncList->C_Initialize(NULL_PTR);
++		rv = pFuncList->C_Initialize((CK_VOID_PTR)&pk11_init_args);
 +		if ((rv != CKR_OK) && (rv != CKR_CRYPTOKI_ALREADY_INITIALIZED))
 +			{
 +			PK11err_add_data(PK11_F_GET_SESSION, PK11_R_INITIALIZE,
@@ -9635,13 +10289,28 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +			goto err;
 +			}
 +
-+		/* It is an inherited session and needs re-initialization. */
++		/*
++		 * It is an inherited session from our parent so it needs
++		 * re-initialization.
++		 */
 +		if (pk11_setup_session(sp, optype) == 0)
 +			{
 +			OPENSSL_free(sp);
 +			sp = NULL;
++			goto err;
++			}
++		if (pk11_token_relogin(sp->session) == 0) 
++			{
++			/*
++			 * We will keep the session in the cache list and let
++			 * the caller cope with the situation.
++			 */
++			freelist = sp;
++			sp = NULL;
++			goto err;
 +			}
 +		}
++
 +	if (sp->pid == 0)
 +		{
 +		/* It is a new session and needs initialization. */
@@ -9677,6 +10346,11 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +#endif
 +	PK11_SESSION *freelist;
 +
++	/*
++	 * If this is a session from the parent it will be taken care of and
++	 * freed in pk11_get_session() as part of the post-fork clean up the
++	 * next time we will ask for a new session.
++	 */
 +	if (sp == NULL || sp->pid != getpid())
 +		return;
 +
@@ -9801,7 +10475,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +	}
 +
 +
-+static int pk11_setup_session(PK11_SESSION *sp, PK11_OPTYPE optype)
++static int
++pk11_setup_session(PK11_SESSION *sp, PK11_OPTYPE optype)
 +	{
 +	CK_RV rv;
 +	CK_SLOT_ID myslot;
@@ -9854,9 +10529,17 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +		sp->opdata_rsa_n_num = NULL;
 +		sp->opdata_rsa_e_num = NULL;
 +		sp->opdata_rsa_priv = NULL;
++		sp->opdata_rsa_pn_num = NULL;
++		sp->opdata_rsa_pe_num = NULL;
 +		sp->opdata_rsa_d_num = NULL;
 +		}
 +
++	/*
++	 * We always initialize the session as containing a non-persistent
++	 * object. The key load functions set it to persistent if that is so.
++	 */
++	sp->pub_persistent = CK_FALSE;
++	sp->priv_persistent = CK_FALSE;
 +	return (1);
 +	}
 +
@@ -9868,8 +10551,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +
 +	if (sp->opdata_rsa_pub_key != CK_INVALID_HANDLE)
 +		{
-+		TRY_OBJ_DESTROY(sp->session, sp->opdata_rsa_pub_key,
-+		    ret, uselock, OP_RSA);
++		TRY_OBJ_DESTROY(sp, sp->opdata_rsa_pub_key,
++		    ret, uselock, OP_RSA, CK_FALSE);
 +		sp->opdata_rsa_pub_key = CK_INVALID_HANDLE;
 +		sp->opdata_rsa_pub = NULL;
 +		if (sp->opdata_rsa_n_num != NULL)
@@ -9895,9 +10578,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +
 +	if (sp->opdata_rsa_priv_key != CK_INVALID_HANDLE)
 +		{
-+		TRY_OBJ_DELETE(sp->session,
-+			       sp->opdata_rsa_priv_key,
-+			       ret, uselock, OP_RSA);
++		TRY_OBJ_DESTROY(sp, sp->opdata_rsa_priv_key,
++		    ret, uselock, OP_RSA, CK_TRUE);
 +		sp->opdata_rsa_priv_key = CK_INVALID_HANDLE;
 +		sp->opdata_rsa_priv = NULL;
 +		if (sp->opdata_rsa_d_num != NULL)
@@ -9905,6 +10587,22 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +			BN_free(sp->opdata_rsa_d_num);
 +			sp->opdata_rsa_d_num = NULL;
 +			}
++
++		/*
++		 * For the RSA key by reference code, public components 'n'/'e'
++		 * are the key components we use to check for the cache hit. We
++		 * must free those as well.
++		 */
++		if (sp->opdata_rsa_pn_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_pn_num);
++			sp->opdata_rsa_pn_num = NULL;
++			}
++		if (sp->opdata_rsa_pe_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_pe_num);
++			sp->opdata_rsa_pe_num = NULL;
++			}
 +		}
 +
 +	return (ret);
@@ -9969,9 +10667,20 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +	return (ret);
 +	}
 +
-+static int pk11_destroy_object(CK_SESSION_HANDLE session, CK_OBJECT_HANDLE oh)
++static int
++pk11_destroy_object(CK_SESSION_HANDLE session, CK_OBJECT_HANDLE oh,
++	CK_BBOOL persistent)
 +	{
 +	CK_RV rv;
++
++	/*
++	 * We never try to destroy persistent objects which are the objects
++	 * stored in the keystore. Also, we always use read-only sessions so
++	 * C_DestroyObject() would be returning CKR_SESSION_READ_ONLY here.
++	 */
++	if (persistent == CK_TRUE)
++		return (1);
++
 +	rv = pFuncList->C_DestroyObject(session, oh);
 +	if (rv != CKR_OK)
 +		{
@@ -9987,7 +10696,6 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +/*
 + * Public key mechanisms optionally supported
 + *
-+ * CKM_RSA_X_509
 + * CKM_RSA_PKCS
 + *
 + * The first slot that supports at least one of those mechanisms is chosen as a
@@ -10017,7 +10725,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +		*any_slot_found = 0;
 +
 +	/* Get slot list for memory allocation */
-+	rv = pFuncList->C_GetSlotList(0, NULL_PTR, &ulSlotCount);
++	rv = pFuncList->C_GetSlotList(CK_FALSE, NULL_PTR, &ulSlotCount);
 +
 +	if (rv != CKR_OK)
 +		{
@@ -10043,7 +10751,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +		}
 +
 +	/* Get the slot list for processing */
-+	rv = pFuncList->C_GetSlotList(0, pSlotList, &ulSlotCount);
++	rv = pFuncList->C_GetSlotList(CK_FALSE, pSlotList, &ulSlotCount);
 +	if (rv != CKR_OK)
 +		{
 +		PK11err_add_data(PK11_F_CHOOSE_SLOT, PK11_R_GETSLOTLIST, rv);
@@ -10125,6 +10833,12 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +			best_slot_sofar = current_slot;
 +			pk11_have_rsa = slot_has_rsa;
 +			found_candidate_slot = CK_TRUE;
++			/*
++			 * Cache the flags for later use. We might
++			 * need those if RSA keys by reference feature
++			 * is used.
++			 */
++			pubkey_token_flags = token_info.flags;
 +#ifdef	DEBUG_SLOT_SELECTION
 +			fprintf(stderr,
 +			    "%s: setting found_candidate_slot to CK_TRUE\n",
@@ -10132,6 +10846,8 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +			fprintf(stderr,
 +			    "%s: best so far slot: %d\n", PK11_DBG,
 +			    best_slot_sofar);
++			fprintf(stderr, "%s: pubkey flags changed to "
++			    "%lu.\n", PK11_DBG, pubkey_token_flags);
 +			}
 +		else
 +			{
@@ -10143,7 +10859,7 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +#endif	/* DEBUG_SLOT_SELECTION */
 +		} /* for */
 +
-+	if (found_candidate_slot)
++	if (found_candidate_slot == CK_TRUE)
 +		{
 +		pubkey_SLOTID = best_slot_sofar;
 +		}
@@ -10173,14 +10889,17 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.2
 +#endif	/* OPENSSL_NO_HW_PK11 */
 +#endif	/* OPENSSL_NO_HW */
 Index: openssl/crypto/engine/hw_pk11so.h
-diff -u /dev/null openssl/crypto/engine/hw_pk11so.h:1.2
---- /dev/null	Thu Dec 24 13:00:46 2009
-+++ openssl/crypto/engine/hw_pk11so.h	Mon Oct  5 13:17:03 2009
-@@ -0,0 +1,28 @@
+diff -u /dev/null openssl/crypto/engine/hw_pk11so.h:1.2.4.2
+--- /dev/null	Mon Jan 16 18:53:42 2012
++++ openssl/crypto/engine/hw_pk11so.h	Wed Jun 15 21:12:32 2011
+@@ -0,0 +1,32 @@
 +/* Redefine all pk11/PK11 external symbols to pk11so/PK11SO */
 +
++#define token_lock			pk11so_token_lock
 +#define find_lock			pk11so_find_lock
 +#define active_list			pk11so_active_list
++#define pubkey_token_flags		pk11so_pubkey_token_flags
++#define pubkey_SLOTID			pk11so_pubkey_SLOTID
 +#define ERR_pk11_error			ERR_pk11so_error
 +#define PK11err_add_data		PK11SOerr_add_data
 +#define pk11_get_session		pk11so_get_session
@@ -10202,16 +10921,17 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so.h:1.2
 +#define pk11_destroy_dh_key_objects	pk11so_destroy_dh_key_objects
 +#define pk11_destroy_dh_object		pk11so_destroy_dh_object
 +#define PK11_DH				PK11SO_DH
++#define pk11_token_relogin		pk11so_token_relogin
 +#define pFuncList			pk11so_pFuncList
 +#define pk11_pin			pk11so_pin
 +#define ENGINE_load_pk11		ENGINE_load_pk11so
 Index: openssl/crypto/engine/hw_pk11so_pub.c
-diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2
---- /dev/null	Thu Dec 24 13:00:46 2009
-+++ openssl/crypto/engine/hw_pk11so_pub.c	Mon Oct  5 13:17:03 2009
-@@ -0,0 +1,899 @@
+diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2.4.3
+--- /dev/null	Mon Jan 16 18:53:42 2012
++++ openssl/crypto/engine/hw_pk11so_pub.c	Fri Jun 17 07:56:21 2011
+@@ -0,0 +1,1622 @@
 +/*
-+ * Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
++ * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
 + * Use is subject to license terms.
 + */
 +
@@ -10328,13 +11048,6 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2
 +#ifndef OPENSSL_NO_HW_PK11
 +#ifndef OPENSSL_NO_HW_PK11SO
 +
-+#ifndef OPENSSL_NO_DSA
-+#define OPENSSL_NO_DSA
-+#endif
-+#ifndef OPENSSL_NO_DH
-+#define OPENSSL_NO_DH
-+#endif
-+
 +#ifdef OPENSSL_SYS_WIN32
 +#pragma pack(push, cryptoki, 1)
 +#include "cryptoki.h"
@@ -10347,6 +11060,12 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2
 +#include "hw_pk11so.h"
 +#include "hw_pk11_err.h"
 +
++static CK_BBOOL pk11_login_done = CK_FALSE;
++extern CK_SLOT_ID pubkey_SLOTID;
++#ifndef NOPTHREADS
++extern pthread_mutex_t *token_lock;
++#endif
++
 +#if !(defined(HAVE_GETPASSPHRASE) || (defined (__SVR4) && defined (__sun)))
 +#define getpassphrase(x)	getpass(x)
 +#endif
@@ -10354,19 +11073,29 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2
 +/* RSA stuff */
 +static int pk11_RSA_sign(int type, const unsigned char *m, unsigned int m_len,
 +	unsigned char *sigret, unsigned int *siglen, const RSA *rsa);
-+EVP_PKEY *pk11_load_privkey(ENGINE*, const char *pubkey_file,
++EVP_PKEY *pk11_load_privkey(ENGINE*, const char *privkey_file,
 +	UI_METHOD *ui_method, void *callback_data);
 +EVP_PKEY *pk11_load_pubkey(ENGINE*, const char *pubkey_file,
 +	UI_METHOD *ui_method, void *callback_data);
 +
++static CK_OBJECT_HANDLE pk11_get_public_rsa_key(RSA* rsa, RSA** key_ptr,
++	BIGNUM **rsa_n_num, BIGNUM **rsa_e_num, CK_SESSION_HANDLE session);
 +static CK_OBJECT_HANDLE pk11_get_private_rsa_key(RSA* rsa, RSA** key_ptr,
-+	BIGNUM **rsa_d_num, CK_SESSION_HANDLE session);
++	BIGNUM **rsa_d_num, BIGNUM **rsa_n_num, BIGNUM **rsa_e_num,
++	CK_SESSION_HANDLE session);
 +
 +static int check_new_rsa_key_pub(PK11_SESSION *sp, const RSA *rsa);
 +static int check_new_rsa_key_priv(PK11_SESSION *sp, const RSA *rsa);
 +
++static int find_one_object(PK11_OPTYPE op, CK_SESSION_HANDLE s,
++	CK_ATTRIBUTE_PTR ptempl, CK_ULONG nattr, CK_OBJECT_HANDLE_PTR pkey);
++static int init_template_value(BIGNUM *bn, CK_VOID_PTR *pValue,
++	CK_ULONG *ulValueLen);
 +static void attr_to_BN(CK_ATTRIBUTE_PTR attr, CK_BYTE attr_data[], BIGNUM **bn);
 +
++static int pk11_token_login(CK_SESSION_HANDLE session, CK_BBOOL *login_done,
++	CK_BBOOL is_private);
++
 +/* Read mode string to be used for fopen() */
 +#if SOLARIS_OPENSSL
 +static char *read_mode_flags = "rF";
@@ -10565,6 +11294,9 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2
 +/* Size of an SSL signature: MD5+SHA1 */
 +#define	SSL_SIG_LENGTH		36
 +
++static CK_BBOOL true = TRUE;
++static CK_BBOOL false = FALSE;
++
 +/*
 + * Standard engine interface function. Majority codes here are from
 + * rsa/rsa_sign.c. We replaced the decrypt function call by C_Sign of PKCS#11.
@@ -10655,8 +11387,9 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2
 +	if (h_priv_key == CK_INVALID_HANDLE)
 +		h_priv_key = sp->opdata_rsa_priv_key =
 +			pk11_get_private_rsa_key((RSA *)rsa,
-+			    &sp->opdata_rsa_priv,
-+			    &sp->opdata_rsa_d_num, sp->session);
++			    &sp->opdata_rsa_priv, &sp->opdata_rsa_d_num,
++			    &sp->opdata_rsa_pn_num, &sp->opdata_rsa_pe_num,
++			    sp->session);
 +
 +	if (h_priv_key != CK_INVALID_HANDLE)
 +		{
@@ -10694,23 +11427,28 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2
 +
 +static int hndidx_rsa = -1;
 +
-+/* load RSA private key from a file */
++#define	MAXATTR	1024
++
++/*
++ * Load RSA private key from a file or get its PKCS#11 handle if stored in the
++ * PKCS#11 token.
++ */
 +/* ARGSUSED */
 +EVP_PKEY *pk11_load_privkey(ENGINE *e, const char *privkey_file,
 +	UI_METHOD *ui_method, void *callback_data)
 +	{
 +	EVP_PKEY *pkey = NULL;
 +	FILE *privkey;
-+	RSA *rsa;
-+	PK11_SESSION *sp = NULL;
-+	/* everything else below needed for key by reference extension */
++	CK_OBJECT_HANDLE  h_priv_key = CK_INVALID_HANDLE;
++	RSA *rsa = NULL;
++	PK11_SESSION *sp;
++	/* Anything else below is needed for the key by reference extension. */
 +	CK_RV rv;
-+	CK_ULONG objcnt = 0;
 +	CK_BBOOL is_token = TRUE;
-+	CK_BYTE attr_data[2][1024];
++	CK_BBOOL rollback = FALSE;
++	CK_BYTE attr_data[2][MAXATTR];
 +	CK_OBJECT_CLASS key_class = CKO_PRIVATE_KEY;
 +	CK_OBJECT_HANDLE ks_key = CK_INVALID_HANDLE;	/* key in keystore */
-+	extern char *pk11_pin;
 +
 +	/* we look for private keys only */
 +	CK_ATTRIBUTE search_templ[] =
@@ -10720,144 +11458,179 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2
 +		{CKA_LABEL, NULL, 0}
 +		};
 +
-+	/* these attributes are needed to initialize OpenSSL RSA structure */
++	/*
++	 * These public attributes are needed to initialize the OpenSSL RSA
++	 * structure with something we can use to look up the key. Note that we
++	 * never ask for private components.
++	 */
 +	CK_ATTRIBUTE get_templ[] =
 +		{
-+		{CKA_MODULUS, (void *)attr_data[0], 1024},	    /* n */
-+		{CKA_PUBLIC_EXPONENT, (void *)attr_data[1], 1024},  /* e */
++		{CKA_MODULUS, (void *)attr_data[0], MAXATTR},		/* n */
++		{CKA_PUBLIC_EXPONENT, (void *)attr_data[1], MAXATTR},	/* e */
 +		};
 +
++	if ((sp = pk11_get_session(OP_RSA)) == NULL)
++		return (NULL);
++
 +	/*
 +	 * Use simple scheme "pkcs11:<KEY_LABEL>" for now.
 +	 */
 +	if (strstr(privkey_file, "pkcs11:") == privkey_file)
 +		{
-+		if ((sp = pk11_get_session(OP_RSA)) == NULL)
-+			return (NULL);
-+
 +		search_templ[2].pValue = strstr(privkey_file, ":") + 1;
 +		search_templ[2].ulValueLen = strlen(search_templ[2].pValue);
 +
-+		if (pk11_pin == NULL)
-+			{
-+			pk11_pin = BUF_strdup(getpassphrase("Enter PIN: "));
-+
-+			if (pk11_pin == NULL)
-+				{
-+				PK11err(PK11_F_LOAD_PRIVKEY, PK11_R_MALLOC_FAILURE);
-+				goto err;
-+				}
-+			}
-+		if ((rv = pFuncList->C_Login(sp->session, CKU_USER, (CK_UTF8CHAR*)pk11_pin,
-+		    strlen(pk11_pin))) != CKR_OK && rv != CKR_USER_ALREADY_LOGGED_IN)
-+			{
-+			PK11err_add_data(PK11_F_LOAD_PRIVKEY,
-+					 PK11_R_INVALID_PIN, rv);
-+			goto err;
-+			}
-+
-+		LOCK_OBJSTORE(OP_RSA);
-+		if ((rv = pFuncList->C_FindObjectsInit(sp->session,
-+		    search_templ, 3)) != CKR_OK)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err_add_data(PK11_F_LOAD_PRIVKEY,
-+					 PK11_R_FINDOBJECTSINIT, rv);
++		if (pk11_token_login(sp->session, &pk11_login_done,
++		    CK_TRUE) == 0)
 +			goto err;
-+			}
 +
-+		rv = pFuncList->C_FindObjects(sp->session, &ks_key, 1, &objcnt);
-+		if (rv != CKR_OK)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err_add_data(PK11_F_LOAD_PRIVKEY,
-+					 PK11_R_FINDOBJECTS, rv);
-+			goto err;
-+			}
-+
-+		if (objcnt > 1)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err(PK11_F_LOAD_PRIVKEY, PK11_R_TOO_MANY_OBJECTS);
-+			goto err;
-+			}
-+
-+		if (objcnt != 1)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err(PK11_F_LOAD_PRIVKEY, PK11_R_OBJECT_NOT_FOUND);
++		/*
++		 * Now let's try to find the key in the token. It is a failure
++		 * if we can't find it.
++		 */
++		if (find_one_object(OP_RSA, sp->session, search_templ, 3,
++		    &ks_key) == 0)
 +			goto err;
-+			}
-+
-+		(void) pFuncList->C_FindObjectsFinal(sp->session);
-+		UNLOCK_OBJSTORE(OP_RSA);
 +
 +		if (hndidx_rsa == -1)
 +			hndidx_rsa = RSA_get_ex_new_index(0,
 +				        "pkcs11 RSA HSM key handle",
 +					NULL, NULL, NULL);
 +
-+		pkey = EVP_PKEY_new();
-+		if (pkey == NULL)
-+			goto err;
++		/*
++		 * We might have a cache hit which we could confirm
++		 * according to the 'n'/'e' params, RSA public pointer
++		 * as NULL, and non-NULL RSA private pointer. However,
++		 * it is easier just to recreate everything. We expect
++		 * the keys to be loaded once and used many times. We
++		 * do not check the return value because even in case
++		 * of failure the sp structure will have both key
++		 * pointer and object handle cleaned and
++		 * pk11_destroy_object() reports the failure to the
++		 * OpenSSL error message buffer.
++		 */
++		(void) pk11_destroy_rsa_object_priv(sp, TRUE);
++
++		sp->opdata_rsa_priv_key = ks_key;
++		/* This object shall not be deleted on a cache miss. */
++		sp->priv_persistent = CK_TRUE;
 +
-+		rsa = RSA_new_method(e);
-+		if (rsa == NULL) {
-+			EVP_PKEY_free(pkey);
-+			pkey = NULL;
++		/*
++		 * Cache the RSA private structure pointer. We do not
++		 * use it now for key-by-ref keys but let's do it for
++		 * consistency reasons.
++		 */
++		if ((rsa = sp->opdata_rsa_priv = RSA_new_method(e)) == NULL)
 +			goto err;
-+		}
-+		EVP_PKEY_assign_RSA(pkey, rsa);
++
++		/*
++		 * Now we have to initialize an OpenSSL RSA structure,
++		 * everything else is 0 or NULL.
++		 */
++		rsa->flags = RSA_FLAG_SIGN_VER | RSA_FLAG_EXT_PKEY;
++		RSA_set_ex_data(rsa, hndidx_rsa, (void *) ks_key);
 +
 +		if ((rv = pFuncList->C_GetAttributeValue(sp->session, ks_key,
 +		    get_templ, 2)) != CKR_OK)
 +			{
 +			PK11err_add_data(PK11_F_LOAD_PRIVKEY,
 +					 PK11_R_GETATTRIBUTVALUE, rv);
-+			EVP_PKEY_free(pkey);
-+			pkey = NULL;
 +			goto err;
 +			}
 +
-+		/* Note: these flags are critical! */
-+		rsa->flags = RSA_FLAG_SIGN_VER | RSA_FLAG_EXT_PKEY;
-+		RSA_set_ex_data(rsa, hndidx_rsa, (void *) ks_key);
-+		(void) check_new_rsa_key_priv(sp, rsa);
-+		sp->opdata_rsa_priv = rsa;
-+		sp->opdata_rsa_priv_key = ks_key;
++		/*
++		 * We do not use pk11_get_private_rsa_key() here so we
++		 * must take care of handle management ourselves.
++		 */
++		KEY_HANDLE_REFHOLD(ks_key, OP_RSA, FALSE, rollback, err);
 +
++		/*
++		 * Those are the sensitive components we do not want to export
++		 * from the token at all: rsa->(d|p|q|dmp1|dmq1|iqmp).
++		 */
 +		attr_to_BN(&get_templ[0], attr_data[0], &rsa->n);
 +		attr_to_BN(&get_templ[1], attr_data[1], &rsa->e);
++		/*
++		 * Must have 'n'/'e' components in the session structure as
++		 * well. They serve as a public look-up key for the private key
++		 * in the keystore.
++		 */
++		attr_to_BN(&get_templ[0], attr_data[0],
++			&sp->opdata_rsa_pn_num);
++		attr_to_BN(&get_templ[1], attr_data[1],
++			&sp->opdata_rsa_pe_num);
++
++		if ((pkey = EVP_PKEY_new()) == NULL)
++			goto err;
++
++		if (EVP_PKEY_assign_RSA(pkey, rsa) == 0)
++			goto err;
 +		}
 +	else if ((privkey = fopen(privkey_file, read_mode_flags)) != NULL)
 +		{
 +		pkey = PEM_read_PrivateKey(privkey, NULL, NULL, NULL);
 +		(void) fclose(privkey);
++		if (pkey != NULL)
++			{
++			rsa = EVP_PKEY_get1_RSA(pkey);
++			if (rsa != NULL)
++				{
++				/*
++				 * This will always destroy the RSA
++				 * object since we have a new RSA
++				 * structure here.
++				 */
++				(void) check_new_rsa_key_priv(sp, rsa);
++				sp->priv_persistent = CK_FALSE;
++
++				h_priv_key = sp->opdata_rsa_priv_key =
++				    pk11_get_private_rsa_key(rsa,
++				    &sp->opdata_rsa_priv,
++				    &sp->opdata_rsa_d_num,
++				    &sp->opdata_rsa_pn_num,
++				    &sp->opdata_rsa_pe_num, sp->session);
++				if (h_priv_key == CK_INVALID_HANDLE)
++					goto err;
++				}
++			else
++				goto err;
++			}
 +		}
 +
++	pk11_return_session(sp, OP_RSA);
++	return (pkey);
 +err:
-+	if (sp != NULL)
-+		pk11_return_session(sp, OP_RSA);
++	pk11_return_session(sp, OP_RSA);
++	if (rsa != NULL)
++		RSA_free(rsa);
++	if (pkey != NULL)
++		{
++		EVP_PKEY_free(pkey);
++		pkey = NULL;
++		}
++	rollback = rollback;
 +	return (pkey);
 +	}
 +
-+/* load RSA public key from a file */
++/*
++ * Load RSA public key from a file or get its PKCS#11 handle if stored in the
++ * PKCS#11 token.
++ */
 +/* ARGSUSED */
 +EVP_PKEY *pk11_load_pubkey(ENGINE *e, const char *pubkey_file,
 +	UI_METHOD *ui_method, void *callback_data)
 +	{
 +	EVP_PKEY *pkey = NULL;
 +	FILE *pubkey;
-+	RSA *rsa;
-+	PK11_SESSION *sp = NULL;
-+	/* everything else below needed for key by reference extension */
++	CK_OBJECT_HANDLE h_pub_key = CK_INVALID_HANDLE;
++	RSA *rsa = NULL;
++	PK11_SESSION *sp;
++	/* Anything else below is needed for the key by reference extension. */
 +	CK_RV rv;
-+	CK_ULONG objcnt = 0;
 +	CK_BBOOL is_token = TRUE;
-+	CK_BYTE attr_data[2][1024];
++	CK_BYTE attr_data[2][MAXATTR];
 +	CK_OBJECT_CLASS key_class = CKO_PUBLIC_KEY;
 +	CK_OBJECT_HANDLE ks_key = CK_INVALID_HANDLE;	/* key in keystore */
-+	extern char *pk11_pin;
 +
 +	/* we look for public keys only */
 +	CK_ATTRIBUTE search_templ[] =
@@ -10867,146 +11640,497 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2
 +		{CKA_LABEL, NULL, 0}
 +		};
 +
-+	/* these attributes are needed to initialize OpenSSL RSA structure */
++	/*
++	 * These public attributes are needed to initialize OpenSSL RSA
++	 * structure with something we can use to look up the key.
++	 */
 +	CK_ATTRIBUTE get_templ[] =
 +		{
-+		{CKA_MODULUS, (void *)attr_data[0], 1024},	    /* n */
-+		{CKA_PUBLIC_EXPONENT, (void *)attr_data[1], 1024},  /* e */
++		{CKA_MODULUS, (void *)attr_data[0], MAXATTR},		/* n */
++		{CKA_PUBLIC_EXPONENT, (void *)attr_data[1], MAXATTR},	/* e */
 +		};
 +
++	if ((sp = pk11_get_session(OP_RSA)) == NULL)
++		return (NULL);
++
 +	/*
 +	 * Use simple scheme "pkcs11:<KEY_LABEL>" for now.
 +	 */
 +	if (strstr(pubkey_file, "pkcs11:") == pubkey_file)
 +		{
-+		if ((sp = pk11_get_session(OP_RSA)) == NULL)
-+			return (NULL);
-+
 +		search_templ[2].pValue = strstr(pubkey_file, ":") + 1;
 +		search_templ[2].ulValueLen = strlen(search_templ[2].pValue);
 +
-+#define ALLWAYS_LOGIN
-+#ifdef ALLWAYS_LOGIN
-+		if (pk11_pin == NULL)
-+			{
-+			pk11_pin = BUF_strdup(getpassphrase("Enter PIN: "));
++		if (pk11_token_login(sp->session, &pk11_login_done,
++		    CK_FALSE) == 0)
++			goto err;
 +
-+			if (pk11_pin == NULL)
-+				{
-+				PK11err(PK11_F_LOAD_PUBKEY, PK11_R_MALLOC_FAILURE);
-+				goto err;
-+				}
-+			}
-+		if ((rv = pFuncList->C_Login(sp->session, CKU_USER, (CK_UTF8CHAR*)pk11_pin,
-+		    strlen(pk11_pin))) != CKR_OK && rv != CKR_USER_ALREADY_LOGGED_IN)
-+			{
-+			PK11err_add_data(PK11_F_LOAD_PUBKEY,
-+					 PK11_R_INVALID_PIN, rv);
++		/*
++		 * Now let's try to find the key in the token. It is a failure
++		 * if we can't find it.
++		 */
++		if (find_one_object(OP_RSA, sp->session, search_templ, 3,
++		    &ks_key) == 0)
 +			goto err;
-+			}
-+#endif
 +
-+		LOCK_OBJSTORE(OP_RSA);
-+		if (pFuncList->C_FindObjectsInit(sp->session, search_templ, 3) != CKR_OK)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err_add_data(PK11_F_LOAD_PUBKEY,
-+					 PK11_R_FINDOBJECTSINIT, rv);
++		/*
++		 * We load a new public key so we will create a new RSA
++		 * structure. No cache hit is possible.
++		 */
++		(void) pk11_destroy_rsa_object_pub(sp, TRUE);
++
++		sp->opdata_rsa_pub_key = ks_key;
++		/* This object shall not be deleted on a cache miss. */
++		sp->pub_persistent = CK_TRUE;
++
++		/*
++		 * Cache the RSA public structure pointer.
++		 */
++		if ((rsa = sp->opdata_rsa_pub = RSA_new_method(e)) == NULL)
 +			goto err;
-+			}
-+		rv = pFuncList->C_FindObjects(sp->session, &ks_key, 1, &objcnt);
-+		if (rv != CKR_OK)
++
++		/*
++		 * Now we have to initialize an OpenSSL RSA structure,
++		 * everything else is 0 or NULL.
++		 */
++		rsa->flags = RSA_FLAG_SIGN_VER;
++
++		if ((rv = pFuncList->C_GetAttributeValue(sp->session, ks_key,
++		    get_templ, 2)) != CKR_OK)
 +			{
-+			UNLOCK_OBJSTORE(OP_RSA);
 +			PK11err_add_data(PK11_F_LOAD_PUBKEY,
-+					 PK11_R_FINDOBJECTS, rv);
++					 PK11_R_GETATTRIBUTVALUE, rv);
 +			goto err;
 +			}
 +
-+		if (objcnt > 1)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err(PK11_F_LOAD_PUBKEY, PK11_R_TOO_MANY_OBJECTS);
++		attr_to_BN(&get_templ[0], attr_data[0], &rsa->n);
++		attr_to_BN(&get_templ[1], attr_data[1], &rsa->e);
++
++		if ((pkey = EVP_PKEY_new()) == NULL)
 +			goto err;
-+			}
 +
-+		if (objcnt != 1)
-+			{
-+			UNLOCK_OBJSTORE(OP_RSA);
-+			PK11err(PK11_F_LOAD_PUBKEY, PK11_R_OBJECT_NOT_FOUND);
++		if (EVP_PKEY_assign_RSA(pkey, rsa) == 0)
 +			goto err;
++
++		/*
++		 * Create a session object from it so that when calling
++		 * pk11_get_public_rsa_key() the next time, we can find it. The
++		 * reason why we do that is that we cannot tell from the RSA
++		 * structure (OpenSSL RSA structure does not have any room for
++		 * additional data used by the engine, for example) if it bears
++		 * a public key stored in the keystore or not so it's better if
++		 * we always have a session key. Note that this is different
++		 * from what we do for the private keystore objects but in that
++		 * case, we can tell from the RSA structure that the keystore
++		 * object is in play - the 'd' component is NULL in that case.
++		 */
++		h_pub_key = sp->opdata_rsa_pub_key =
++		    pk11_get_public_rsa_key(rsa,
++		    &sp->opdata_rsa_pub, &sp->opdata_rsa_n_num,
++		    &sp->opdata_rsa_e_num, sp->session);
++		if (h_pub_key == CK_INVALID_HANDLE)
++			goto err;
++		}
++	else if ((pubkey = fopen(pubkey_file, read_mode_flags)) != NULL)
++		{
++		pkey = PEM_read_PUBKEY(pubkey, NULL, NULL, NULL);
++		(void) fclose(pubkey);
++		if (pkey != NULL)
++			{
++			rsa = EVP_PKEY_get1_RSA(pkey);
++			if (rsa != NULL)
++				{
++				/*
++				 * This will always destroy the RSA
++				 * object since we have a new RSA
++				 * structure here.
++				 */
++				(void) check_new_rsa_key_pub(sp, rsa);
++				sp->pub_persistent = CK_FALSE;
++
++				h_pub_key = sp->opdata_rsa_pub_key =
++				    pk11_get_public_rsa_key(rsa,
++				    &sp->opdata_rsa_pub, &sp->opdata_rsa_n_num,
++				    &sp->opdata_rsa_e_num, sp->session);
++				if (h_pub_key == CK_INVALID_HANDLE)
++					goto err;
++				}
++			else
++				goto err;
 +			}
++		}
++
++	pk11_return_session(sp, OP_RSA);
++	return (pkey);
++err:
++	pk11_return_session(sp, OP_RSA);
++	if (rsa != NULL)
++		RSA_free(rsa);
++	if (pkey != NULL)
++		{
++		EVP_PKEY_free(pkey);
++		pkey = NULL;
++		}
++	return (pkey);
++	}
++
++/*
++ * Create a public key object in a session from a given rsa structure.
++ * The *rsa_n_num and *rsa_e_num pointers are non-NULL for RSA public keys.
++ */
++static CK_OBJECT_HANDLE pk11_get_public_rsa_key(RSA *rsa,
++    RSA **key_ptr, BIGNUM **rsa_n_num, BIGNUM **rsa_e_num,
++    CK_SESSION_HANDLE session)
++	{
++	CK_RV rv;
++	CK_OBJECT_HANDLE h_key = CK_INVALID_HANDLE;
++	CK_ULONG found;
++	CK_OBJECT_CLASS o_key = CKO_PUBLIC_KEY;
++	CK_KEY_TYPE k_type = CKK_RSA;
++	CK_ULONG ul_key_attr_count = 8;
++	CK_BBOOL rollback = FALSE;
 +
-+		(void) pFuncList->C_FindObjectsFinal(sp->session);
-+		UNLOCK_OBJSTORE(OP_RSA);
++	CK_ATTRIBUTE  a_key_template[] =
++		{
++		{CKA_CLASS, (void *) NULL, sizeof (CK_OBJECT_CLASS)},
++		{CKA_KEY_TYPE, (void *) NULL, sizeof (CK_KEY_TYPE)},
++		{CKA_TOKEN, &false, sizeof (true)},
++		{CKA_ENCRYPT, &true, sizeof (true)},
++		{CKA_VERIFY, &true, sizeof (true)},
++		{CKA_VERIFY_RECOVER, &true, sizeof (true)},
++		{CKA_MODULUS, (void *)NULL, 0},
++		{CKA_PUBLIC_EXPONENT, (void *)NULL, 0}
++		};
 +
-+		sp->opdata_rsa_pub_key = ks_key;
-+		pkey = EVP_PKEY_new();
-+		if (pkey == NULL)
-+			goto err;
++	int i;
++
++	a_key_template[0].pValue = &o_key;
++	a_key_template[1].pValue = &k_type;
++
++	a_key_template[6].ulValueLen = BN_num_bytes(rsa->n);
++	a_key_template[6].pValue = (CK_VOID_PTR)OPENSSL_malloc(
++		(size_t)a_key_template[6].ulValueLen);
++	if (a_key_template[6].pValue == NULL)
++		{
++		PK11err(PK11_F_GET_PUB_RSA_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
 +
-+		rsa = RSA_new_method(e);
-+		if (rsa == NULL) {
-+			EVP_PKEY_free(pkey);
-+			pkey = NULL;
++	BN_bn2bin(rsa->n, a_key_template[6].pValue);
++
++	a_key_template[7].ulValueLen = BN_num_bytes(rsa->e);
++	a_key_template[7].pValue = (CK_VOID_PTR)OPENSSL_malloc(
++		(size_t)a_key_template[7].ulValueLen);
++	if (a_key_template[7].pValue == NULL)
++		{
++		PK11err(PK11_F_GET_PUB_RSA_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
++
++	BN_bn2bin(rsa->e, a_key_template[7].pValue);
++
++	/* see find_lock array definition for more info on object locking */
++	LOCK_OBJSTORE(OP_RSA);
++
++	rv = pFuncList->C_FindObjectsInit(session, a_key_template,
++		ul_key_attr_count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PUB_RSA_KEY,
++		    PK11_R_FINDOBJECTSINIT, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjects(session, &h_key, 1, &found);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PUB_RSA_KEY,
++		    PK11_R_FINDOBJECTS, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjectsFinal(session);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PUB_RSA_KEY,
++		    PK11_R_FINDOBJECTSFINAL, rv);
++		goto err;
++		}
++
++	if (found == 0)
++		{
++		rv = pFuncList->C_CreateObject(session,
++			a_key_template, ul_key_attr_count, &h_key);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_GET_PUB_RSA_KEY,
++			    PK11_R_CREATEOBJECT, rv);
 +			goto err;
++			}
 +		}
-+		EVP_PKEY_assign_RSA(pkey, rsa);
 +
-+		if (pFuncList->C_GetAttributeValue(sp->session, ks_key,
-+		    get_templ, 2) != CKR_OK)
++	if (rsa_n_num != NULL)
++		if ((*rsa_n_num = BN_dup(rsa->n)) == NULL)
 +			{
-+			PK11err_add_data(PK11_F_LOAD_PUBKEY,
-+					 PK11_R_GETATTRIBUTVALUE, rv);
++			PK11err(PK11_F_GET_PUB_RSA_KEY, PK11_R_MALLOC_FAILURE);
++			rollback = TRUE;
++			goto err;
++			}
++	if (rsa_e_num != NULL)
++		if ((*rsa_e_num = BN_dup(rsa->e)) == NULL)
++			{
++			PK11err(PK11_F_GET_PUB_RSA_KEY, PK11_R_MALLOC_FAILURE);
++			BN_free(*rsa_n_num);
++			*rsa_n_num = NULL;
++			rollback = TRUE;
 +			goto err;
 +			}
 +
-+		(void) check_new_rsa_key_pub(sp, rsa);
-+		sp->opdata_rsa_pub = rsa;
++	/* LINTED: E_CONSTANT_CONDITION */
++	KEY_HANDLE_REFHOLD(h_key, OP_RSA, FALSE, rollback, err);
++	if (key_ptr != NULL)
++		*key_ptr = rsa;
 +
-+		attr_to_BN(&get_templ[0], attr_data[0], &rsa->n);
-+		attr_to_BN(&get_templ[1], attr_data[1], &rsa->e);
++err:
++	if (rollback)
++		{
++		/*
++		 * We do not care about the return value from C_DestroyObject()
++		 * since we are doing rollback.
++		 */
++		if (found == 0)
++			(void) pFuncList->C_DestroyObject(session, h_key);
++		h_key = CK_INVALID_HANDLE;
 +		}
-+	else if ((pubkey = fopen(pubkey_file, read_mode_flags)) != NULL)
++
++	UNLOCK_OBJSTORE(OP_RSA);
++
++malloc_err:
++	for (i = 6; i <= 7; i++)
 +		{
-+		pkey = PEM_read_PUBKEY(pubkey, NULL, NULL, NULL);
-+		(void) fclose(pubkey);
++		if (a_key_template[i].pValue != NULL)
++			{
++			OPENSSL_free(a_key_template[i].pValue);
++			a_key_template[i].pValue = NULL;
++			}
 +		}
 +
-+err:
-+	if (sp != NULL)
-+		pk11_return_session(sp, OP_RSA);
-+	return (pkey);
++	return (h_key);
 +	}
 +
 +/*
 + * Create a private key object in the session from a given rsa structure.
 + * The *rsa_d_num pointer is non-NULL for RSA private keys.
 + */
-+static CK_OBJECT_HANDLE pk11_get_private_rsa_key(RSA *rsa,
-+    RSA **key_ptr, BIGNUM **rsa_d_num, CK_SESSION_HANDLE session)
++static CK_OBJECT_HANDLE
++pk11_get_private_rsa_key(RSA *rsa, RSA **key_ptr, BIGNUM **rsa_d_num,
++    BIGNUM **rsa_n_num, BIGNUM **rsa_e_num, CK_SESSION_HANDLE session)
 +	{
++	CK_RV rv;
 +	CK_OBJECT_HANDLE h_key = CK_INVALID_HANDLE;
++	int i;
++	CK_ULONG found;
++	CK_OBJECT_CLASS o_key = CKO_PRIVATE_KEY;
++	CK_KEY_TYPE k_type = CKK_RSA;
++	CK_ULONG ul_key_attr_count = 14;
++	CK_BBOOL rollback = FALSE;
++
++	/* Both CKA_TOKEN and CKA_SENSITIVE have to be FALSE for session keys */
++	CK_ATTRIBUTE  a_key_template[] =
++		{
++		{CKA_CLASS, (void *) NULL, sizeof (CK_OBJECT_CLASS)},
++		{CKA_KEY_TYPE, (void *) NULL, sizeof (CK_KEY_TYPE)},
++		{CKA_TOKEN, &false, sizeof (true)},
++		{CKA_SENSITIVE, &false, sizeof (true)},
++		{CKA_DECRYPT, &true, sizeof (true)},
++		{CKA_SIGN, &true, sizeof (true)},
++		{CKA_MODULUS, (void *)NULL, 0},
++		{CKA_PUBLIC_EXPONENT, (void *)NULL, 0},
++		{CKA_PRIVATE_EXPONENT, (void *)NULL, 0},
++		{CKA_PRIME_1, (void *)NULL, 0},
++		{CKA_PRIME_2, (void *)NULL, 0},
++		{CKA_EXPONENT_1, (void *)NULL, 0},
++		{CKA_EXPONENT_2, (void *)NULL, 0},
++		{CKA_COEFFICIENT, (void *)NULL, 0},
++		};
 +
-+	if ((rsa->flags & RSA_FLAG_EXT_PKEY) == 0) {
-+		PK11err(PK11_F_GET_PRIV_RSA_KEY, PK11_R_INCONSISTENT_KEY);
-+		return (h_key);
++	if ((rsa->flags & RSA_FLAG_EXT_PKEY) != 0) {
++		h_key = (CK_OBJECT_HANDLE)RSA_get_ex_data(rsa, hndidx_rsa);
++		LOCK_OBJSTORE(OP_RSA);
++		goto set;
 +	}
 +	
-+	h_key = (CK_OBJECT_HANDLE)RSA_get_ex_data(rsa, hndidx_rsa);
-+	(void) pk11_active_add(h_key, OP_RSA);
-+	if (key_ptr != NULL)
-+		*key_ptr = rsa;
-+	if (rsa_d_num != NULL)
++	a_key_template[0].pValue = &o_key;
++	a_key_template[1].pValue = &k_type;
++
++	/* Put the private key components into the template */
++	if (init_template_value(rsa->n, &a_key_template[6].pValue,
++		&a_key_template[6].ulValueLen) == 0 ||
++	    init_template_value(rsa->e, &a_key_template[7].pValue,
++		&a_key_template[7].ulValueLen) == 0 ||
++	    init_template_value(rsa->d, &a_key_template[8].pValue,
++		&a_key_template[8].ulValueLen) == 0 ||
++	    init_template_value(rsa->p, &a_key_template[9].pValue,
++		&a_key_template[9].ulValueLen) == 0 ||
++	    init_template_value(rsa->q, &a_key_template[10].pValue,
++		&a_key_template[10].ulValueLen) == 0 ||
++	    init_template_value(rsa->dmp1, &a_key_template[11].pValue,
++		&a_key_template[11].ulValueLen) == 0 ||
++	    init_template_value(rsa->dmq1, &a_key_template[12].pValue,
++		&a_key_template[12].ulValueLen) == 0 ||
++	    init_template_value(rsa->iqmp, &a_key_template[13].pValue,
++		&a_key_template[13].ulValueLen) == 0)
++		{
++		PK11err(PK11_F_GET_PRIV_RSA_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
++
++	/* see find_lock array definition for more info on object locking */
++	LOCK_OBJSTORE(OP_RSA);
++
++	/*
++	 * We are getting the private key but the private 'd'
++	 * component is NULL.  That means this is key by reference RSA
++	 * key. In that case, we can use only public components for
++	 * searching for the private key handle.
++	 */
++	if (rsa->d == NULL)
 +		{
++		ul_key_attr_count = 8;
++		/*
++		 * We will perform the search in the token, not in the existing
++		 * session keys.
++		 */
++		a_key_template[2].pValue = &true;
++		}
++
++	rv = pFuncList->C_FindObjectsInit(session, a_key_template,
++		ul_key_attr_count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PRIV_RSA_KEY,
++		    PK11_R_FINDOBJECTSINIT, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjects(session, &h_key, 1, &found);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PRIV_RSA_KEY,
++		    PK11_R_FINDOBJECTS, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjectsFinal(session);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PRIV_RSA_KEY,
++		    PK11_R_FINDOBJECTSFINAL, rv);
++		goto err;
++		}
++
++	if (found == 0)
++		{
++		/*
++		 * We have an RSA structure with 'n'/'e' components
++		 * only so we tried to find the private key in the
++		 * keystore. If it was really a token key we have a
++		 * problem. Note that for other key types we just
++		 * create a new session key using the private
++		 * components from the RSA structure.
++		 */
 +		if (rsa->d == NULL)
-+			*rsa_d_num = NULL;
-+		else if ((*rsa_d_num = BN_dup(rsa->d)) == NULL)
++			{
++			PK11err(PK11_F_GET_PRIV_RSA_KEY,
++			    PK11_R_PRIV_KEY_NOT_FOUND);
++			goto err;
++			}
++
++		rv = pFuncList->C_CreateObject(session,
++			a_key_template, ul_key_attr_count, &h_key);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_GET_PRIV_RSA_KEY,
++				PK11_R_CREATEOBJECT, rv);
++			goto err;
++			}
++		}
++
++set:
++	if (rsa_d_num != NULL)
++		{
++		/*
++		 * When RSA keys by reference code is used, we never
++		 * extract private components from the keystore. In
++		 * that case 'd' was set to NULL and we expect the
++		 * application to properly cope with that. It is
++		 * documented in openssl(5). In general, if keys by
++		 * reference are used we expect it to be used
++		 * exclusively using the high level API and then there
++		 * is no problem. If the application expects the
++		 * private components to be read from the keystore
++		 * then that is not a supported way of usage.
++		 */
++		if (rsa->d != NULL && (*rsa_d_num = BN_dup(rsa->d)) == NULL)
 +			{
 +			PK11err(PK11_F_GET_PRIV_RSA_KEY, PK11_R_MALLOC_FAILURE);
-+			return (h_key);
++			rollback = TRUE;
++			goto err;
++			}
++		else
++			*rsa_d_num = NULL;
++		}
++
++	/*
++	 * For the key by reference code, we need public components as well
++	 * since 'd' component is always NULL. For that reason, we always cache
++	 * 'n'/'e' components as well.
++	 */
++	*rsa_n_num = BN_dup(rsa->n);
++	*rsa_e_num = BN_dup(rsa->e);
++
++	/* LINTED: E_CONSTANT_CONDITION */
++	KEY_HANDLE_REFHOLD(h_key, OP_RSA, FALSE, rollback, err);
++	if (key_ptr != NULL)
++		*key_ptr = rsa;
++
++err:
++	if (rollback)
++		{
++		/*
++		 * We do not care about the return value from C_DestroyObject()
++		 * since we are doing rollback.
++		 */
++		if (found == 0 &&
++		    (rsa->flags & RSA_FLAG_EXT_PKEY) == 0)
++			(void) pFuncList->C_DestroyObject(session, h_key);
++		h_key = CK_INVALID_HANDLE;
++		}
++
++	UNLOCK_OBJSTORE(OP_RSA);
++
++malloc_err:
++	/*
++	 * 6 to 13 entries in the key template are key components.
++	 * They need to be freed upon exit or error.
++	 */
++	for (i = 6; i <= 13; i++)
++		{
++		if (a_key_template[i].pValue != NULL)
++			{
++			(void) memset(a_key_template[i].pValue, 0,
++				a_key_template[i].ulValueLen);
++			OPENSSL_free(a_key_template[i].pValue);
++			a_key_template[i].pValue = NULL;
 +			}
 +		}
++
 +	return (h_key);
 +	}
 +
@@ -11021,10 +12145,17 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2
 +	 * check for cache hit stronger. Only public components of RSA
 +	 * key matter here so it is sufficient to compare them with values
 +	 * cached in PK11_SESSION structure.
++	 *
++	 * We must check the handle as well since with key by reference, public
++	 * components 'n'/'e' are cached in private keys as well. That means we
++	 * could have a cache hit in a private key when looking for a public
++	 * key. That would not work, you cannot have one PKCS#11 object for
++	 * both data signing and verifying.
 +	 */
 +	if ((sp->opdata_rsa_pub != rsa) ||
 +	    (BN_cmp(sp->opdata_rsa_n_num, rsa->n) != 0) ||
-+	    (BN_cmp(sp->opdata_rsa_e_num, rsa->e) != 0))
++	    (BN_cmp(sp->opdata_rsa_e_num, rsa->e) != 0) ||
++	    (sp->opdata_rsa_priv_key != CK_INVALID_HANDLE))
 +		{
 +		/*
 +		 * We do not check the return value because even in case of
@@ -11045,14 +12176,21 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2
 +static int check_new_rsa_key_priv(PK11_SESSION *sp, const RSA *rsa)
 +	{
 +	/*
-+	 * Provide protection against RSA structure reuse by making the
-+	 * check for cache hit stronger. Comparing private exponent of RSA
-+	 * key with value cached in PK11_SESSION structure should
-+	 * be sufficient.
++	 * Provide protection against RSA structure reuse by making
++	 * the check for cache hit stronger. Comparing public exponent
++	 * of RSA key with value cached in PK11_SESSION structure
++	 * should be sufficient. Note that we want to compare the
++	 * public component since with the keys by reference
++	 * mechanism, private components are not in the RSA
++	 * structure. Also, see check_new_rsa_key_pub() about why we
++	 * compare the handle as well.
 +	 */
 +	if ((sp->opdata_rsa_priv != rsa) ||
-+	    (BN_cmp(sp->opdata_rsa_d_num, rsa->d) != 0) ||
-+	    ((rsa->flags & RSA_FLAG_EXT_PKEY) != 0))
++	    (BN_cmp(sp->opdata_rsa_pn_num, rsa->n) != 0) ||
++	    (BN_cmp(sp->opdata_rsa_pe_num, rsa->e) != 0) ||
++	    (sp->opdata_rsa_pn_num == NULL) ||
++	    (sp->opdata_rsa_pe_num == NULL) ||
++	    (sp->opdata_rsa_pub_key != CK_INVALID_HANDLE))
 +		{
 +		/*
 +		 * We do not check the return value because even in case of
@@ -11066,12 +12204,317 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2
 +	return (1);
 +	}
 +
-+static void attr_to_BN(CK_ATTRIBUTE_PTR attr, CK_BYTE attr_data[], BIGNUM **bn)
++/*
++ * Local function to simplify key template population
++ * Return 0 -- error, 1 -- no error
++ */
++static int
++init_template_value(BIGNUM *bn, CK_VOID_PTR *p_value,
++	CK_ULONG *ul_value_len)
++	{
++	CK_ULONG len = 0;
++
++	/*
++	 * This function can be used on non-initialized BIGNUMs. It is
++	 * easier to check that here than individually in the callers.
++	 */
++	if (bn != NULL)
++		len = BN_num_bytes(bn);
++
++	if (bn == NULL || len == 0)
++		return (1);
++
++	*ul_value_len = len;
++	*p_value = (CK_VOID_PTR)OPENSSL_malloc((size_t)*ul_value_len);
++	if (*p_value == NULL)
++		return (0);
++
++	BN_bn2bin(bn, *p_value);
++
++	return (1);
++	}
++
++static void
++attr_to_BN(CK_ATTRIBUTE_PTR attr, CK_BYTE attr_data[], BIGNUM **bn)
 +	{
 +	if (attr->ulValueLen > 0)
-+		{
 +		*bn = BN_bin2bn(attr_data, attr->ulValueLen, NULL);
++	}
++
++/*
++ * Find one object in the token. It is an error if we can not find the
++ * object or if we find more objects based on the template we got.
++ *
++ * Returns:
++ *	1 OK
++ *	0 no object or more than 1 object found
++ */
++static int
++find_one_object(PK11_OPTYPE op, CK_SESSION_HANDLE s,
++    CK_ATTRIBUTE_PTR ptempl, CK_ULONG nattr, CK_OBJECT_HANDLE_PTR pkey)
++	{
++	CK_RV rv;
++	CK_ULONG objcnt;
++
++	LOCK_OBJSTORE(op);
++	if ((rv = pFuncList->C_FindObjectsInit(s, ptempl, nattr)) != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_FIND_ONE_OBJECT,
++		    PK11_R_FINDOBJECTSINIT, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjects(s, pkey, 1, &objcnt);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_FIND_ONE_OBJECT, PK11_R_FINDOBJECTS,
++		    rv);
++		goto err;
++		}
++
++	if (objcnt > 1)
++		{
++		PK11err(PK11_F_FIND_ONE_OBJECT,
++		    PK11_R_MORE_THAN_ONE_OBJECT_FOUND);
++		goto err;
 +		}
++	else if (objcnt == 0)
++		{
++		PK11err(PK11_F_FIND_ONE_OBJECT, PK11_R_NO_OBJECT_FOUND);
++		goto err;
++		}
++
++	(void) pFuncList->C_FindObjectsFinal(s);
++	UNLOCK_OBJSTORE(op);
++	return (1);
++err:
++	UNLOCK_OBJSTORE(op);
++	return (0);
++	}
++
++/* from uri stuff */
++
++extern char *pk11_pin;
++
++static int pk11_get_pin(void);
++
++static int
++pk11_get_pin(void)
++{
++	char *pin;
++
++	/* The getpassphrase() function is not MT safe. */
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(token_lock);
++#else
++	CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	pin = getpassphrase("Enter PIN: ");
++	if (pin == NULL)
++		{
++		PK11err(PK11_F_GET_PIN, PK11_R_COULD_NOT_READ_PIN);
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		goto err;
++		}
++	pk11_pin = BUF_strdup(pin);
++	if (pk11_pin == NULL)
++		{
++		PK11err(PK11_F_LOAD_PRIVKEY, PK11_R_MALLOC_FAILURE);
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		goto err;
++		}
++	memset(pin, 0, strlen(pin));
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(token_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	return (1);
++err:
++	return (0);
++	}
++
++/*
++ * Log in to the keystore if we are supposed to do that at all. Take care of
++ * reading and caching the PIN etc. Log in only once even when called from
++ * multiple threads.
++ *
++ * Returns:
++ *	1 on success
++ *	0 on failure
++ */
++static int
++pk11_token_login(CK_SESSION_HANDLE session, CK_BBOOL *login_done,
++    CK_BBOOL is_private)
++	{
++	CK_RV rv;
++
++#if 0
++	/* doesn't work on the AEP Keyper??? */
++	if ((pubkey_token_flags & CKF_TOKEN_INITIALIZED) == 0)
++		{
++		PK11err(PK11_F_TOKEN_LOGIN,
++		    PK11_R_TOKEN_NOT_INITIALIZED);
++		goto err;
++		}
++#endif
++
++	/*
++	 * If login is required or needed but the PIN has not been
++	 * even initialized we can bail out right now. Note that we
++	 * are supposed to always log in if we are going to access
++	 * private keys. However, we may need to log in even for
++	 * accessing public keys in case that the CKF_LOGIN_REQUIRED
++	 * flag is set.
++	 */
++	if (((pubkey_token_flags & CKF_LOGIN_REQUIRED) ||
++	     (is_private == CK_TRUE)) &&
++	    (~pubkey_token_flags & CKF_USER_PIN_INITIALIZED))
++		{
++		PK11err(PK11_F_TOKEN_LOGIN, PK11_R_TOKEN_PIN_NOT_SET);
++		goto err;
++		}
++
++	/*
++	 * Note on locking: it is possible that more than one thread
++	 * gets into pk11_get_pin() so we must deal with that. We
++	 * cannot avoid it since we cannot guard fork() in there with
++	 * a lock because we could end up in a dead lock in the
++	 * child. Why? Remember we are in a multithreaded environment
++	 * so we must lock all mutexes in the prefork function to
++	 * avoid a situation in which a thread that did not call
++	 * fork() held a lock, making future unlocking impossible. We
++	 * lock right before C_Login().
++	 */
++	if ((pubkey_token_flags & CKF_LOGIN_REQUIRED) ||
++	    (is_private == CK_TRUE))
++		{
++		if (*login_done == CK_FALSE)
++			{
++			if ((pk11_pin == NULL) && (pk11_get_pin() == 0))
++				{
++				PK11err(PK11_F_TOKEN_LOGIN,
++				    PK11_R_TOKEN_PIN_NOT_PROVIDED);
++				goto err;
++				}
++			}
++
++		/*
++		 * Note that what we are logging into is the keystore from
++		 * pubkey_SLOTID because we work with OP_RSA session type here.
++		 * That also means that we can work with only one keystore in
++		 * the engine.
++		 *
++		 * We must make sure we do not try to login more than once.
++		 * Also, see the comment above on locking strategy.
++		 */
++
++#ifndef NOPTHREADS
++		(void) pthread_mutex_lock(token_lock);
++#else
++		(void) pthread_mutex_lock(freelist_lock);
++#endif
++		if (*login_done == CK_FALSE)
++			{
++			if ((rv = pFuncList->C_Login(session,
++			    CKU_USER, (CK_UTF8CHAR*)pk11_pin,
++			    strlen(pk11_pin))) != CKR_OK)
++				{
++				PK11err_add_data(PK11_F_TOKEN_LOGIN,
++				    PK11_R_TOKEN_LOGIN_FAILED, rv);
++				goto err_locked;
++				}
++
++			*login_done = CK_TRUE;
++
++			}
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		}
++	else
++		{
++			/*
++			 * If token does not require login we take it as the
++			 * login was done.
++			 */
++			*login_done = CK_TRUE;
++		}
++
++	return (1);
++
++err_locked:
++	if (pk11_pin) {
++		memset(pk11_pin, 0, strlen(pk11_pin));
++		OPENSSL_free((void*)pk11_pin);
++	}
++	pk11_pin = NULL;
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(token_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++err:
++	return (0);
++	}
++
++/*
++ * Log in to the keystore in the child if we were logged in in the
++ * parent. There are similarities in the code with pk11_token_login()
++ * but still it is quite different so we need a separate function for
++ * this.
++ *
++ * Note that this function is called under the locked session mutex when fork is
++ * detected. That means that C_Login() will be called from the child just once.
++ *
++ * Returns:
++ *	1 on success
++ *	0 on failure
++ */
++int
++pk11_token_relogin(CK_SESSION_HANDLE session)
++	{
++	CK_RV rv;
++
++	if ((pk11_pin == NULL) && (pk11_get_pin() == 0))
++		goto err;
++
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(token_lock);
++#else
++	(void) pthread_mutex_lock(freelist_lock);
++#endif
++	if ((rv = pFuncList->C_Login(session, CKU_USER,
++	    (CK_UTF8CHAR_PTR)pk11_pin, strlen(pk11_pin))) != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_TOKEN_RELOGIN,
++		    PK11_R_TOKEN_LOGIN_FAILED, rv);
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		goto err;
++		}
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(token_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++
++	return (1);
++err:
++	return (0);
 +	}
 +
 +#ifdef	OPENSSL_SYS_WIN32
@@ -11111,11 +12554,11 @@ diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.2
 +#endif	/* OPENSSL_NO_HW */
 Index: openssl/crypto/engine/pkcs11.h
 diff -u /dev/null openssl/crypto/engine/pkcs11.h:1.1.1.1
---- /dev/null	Thu Dec 24 13:00:46 2009
+--- /dev/null	Mon Jan 16 18:53:42 2012
 +++ openssl/crypto/engine/pkcs11.h	Wed Oct 24 23:27:09 2007
 @@ -0,0 +1,299 @@
 +/* pkcs11.h include file for PKCS #11. */
-+/* $Revision: 1.2 $ */
++/* $Revision: 1.3 $ */
 +
 +/* License to copy and use this software is granted provided that it is
 + * identified as "RSA Security Inc. PKCS #11 Cryptographic Token Interface
@@ -11415,11 +12858,11 @@ diff -u /dev/null openssl/crypto/engine/pkcs11.h:1.1.1.1
 +#endif
 Index: openssl/crypto/engine/pkcs11f.h
 diff -u /dev/null openssl/crypto/engine/pkcs11f.h:1.1.1.1
---- /dev/null	Thu Dec 24 13:00:46 2009
+--- /dev/null	Mon Jan 16 18:53:42 2012
 +++ openssl/crypto/engine/pkcs11f.h	Wed Oct 24 23:27:09 2007
 @@ -0,0 +1,912 @@
 +/* pkcs11f.h include file for PKCS #11. */
-+/* $Revision: 1.2 $ */
++/* $Revision: 1.3 $ */
 +
 +/* License to copy and use this software is granted provided that it is
 + * identified as "RSA Security Inc. PKCS #11 Cryptographic Token Interface
@@ -12332,11 +13775,11 @@ diff -u /dev/null openssl/crypto/engine/pkcs11f.h:1.1.1.1
 +#endif
 Index: openssl/crypto/engine/pkcs11t.h
 diff -u /dev/null openssl/crypto/engine/pkcs11t.h:1.2
---- /dev/null	Thu Dec 24 13:00:46 2009
+--- /dev/null	Mon Jan 16 18:53:42 2012
 +++ openssl/crypto/engine/pkcs11t.h	Sat Aug 30 11:58:07 2008
 @@ -0,0 +1,1885 @@
 +/* pkcs11t.h include file for PKCS #11. */
-+/* $Revision: 1.2 $ */
++/* $Revision: 1.3 $ */
 +
 +/* License to copy and use this software is granted provided that it is
 + * identified as "RSA Security Inc. PKCS #11 Cryptographic Token Interface
@@ -14221,19 +15664,19 @@ diff -u /dev/null openssl/crypto/engine/pkcs11t.h:1.2
 +
 +#endif
 Index: openssl/util/libeay.num
-diff -u openssl/util/libeay.num:1.1.3.1 openssl/util/libeay.num:1.6
---- openssl/util/libeay.num:1.1.3.1	Mon Feb  2 00:27:56 2009
-+++ openssl/util/libeay.num	Mon Oct  5 13:17:03 2009
-@@ -3725,3 +3725,5 @@
- JPAKE_STEP3A_init                       4111	EXIST::FUNCTION:JPAKE
- ERR_load_JPAKE_strings                  4112	EXIST::FUNCTION:JPAKE
- JPAKE_STEP2_init                        4113	EXIST::FUNCTION:JPAKE
-+ENGINE_load_pk11ca                      4114	EXIST::FUNCTION:HW_PKCS11CA,ENGINE
-+ENGINE_load_pk11so                      4114	EXIST::FUNCTION:HW_PKCS11SO,ENGINE
+diff -u openssl/util/libeay.num:1.7.6.1 openssl/util/libeay.num:1.7
+--- openssl/util/libeay.num:1.7.6.1	Sun Jan 15 15:45:40 2012
++++ openssl/util/libeay.num	Mon Jun 13 14:25:25 2011
+@@ -3728,3 +3728,5 @@
+ pqueue_size                             4114	EXIST::FUNCTION:
+ OPENSSL_uni2asc                         4115	EXIST:NETWARE:FUNCTION:
+ OPENSSL_asc2uni                         4116	EXIST:NETWARE:FUNCTION:
++ENGINE_load_pk11ca                      4117	EXIST::FUNCTION:HW_PKCS11CA,ENGINE
++ENGINE_load_pk11so                      4117	EXIST::FUNCTION:HW_PKCS11SO,ENGINE
 Index: openssl/util/mk1mf.pl
-diff -u openssl/util/mk1mf.pl:1.1.3.1 openssl/util/mk1mf.pl:1.7
---- openssl/util/mk1mf.pl:1.1.3.1	Tue Dec  2 23:50:21 2008
-+++ openssl/util/mk1mf.pl	Mon Oct  5 13:17:05 2009
+diff -u openssl/util/mk1mf.pl:1.8.6.1 openssl/util/mk1mf.pl:1.8
+--- openssl/util/mk1mf.pl:1.8.6.1	Sun Jan 15 15:45:40 2012
++++ openssl/util/mk1mf.pl	Mon Jun 13 14:25:25 2011
 @@ -87,6 +87,8 @@
  	no-ecdh					- No ECDH
  	no-engine				- No engine
@@ -14252,17 +15695,17 @@ diff -u openssl/util/mk1mf.pl:1.1.3.1 openssl/util/mk1mf.pl:1.7
  $cflags.=" -DOPENSSL_FIPS"    if $fips;
  $cflags.= " -DZLIB" if $zlib_opt;
  $cflags.= " -DZLIB_SHARED" if $zlib_opt == 2;
-@@ -322,6 +326,9 @@
- 	if ($key eq "ZLIB_INCLUDE")
- 		{ $cflags .= " $val" if $val ne "";}
+@@ -316,6 +320,9 @@
+ 		$dir=$val;
+ 		}
  
 +	if ($key eq "PK11_LIB_LOCATION")
 +		{ $cflags .= " -D$key=\\\"$val\\\"" if $val ne "";}
 +
- 	if ($key eq "LIBZLIB")
- 		{ $zlib_lib = "$val" if $val ne "";}
+ 	if ($key eq "KRB5_INCLUDES")
+ 		{ $cflags .= " $val";}
  
-@@ -1300,6 +1307,8 @@
+@@ -1301,6 +1308,8 @@
  		"no-ecdh" => \$no_ecdh,
  		"no-engine" => \$no_engine,
  		"no-hw" => \$no_hw,
@@ -14272,9 +15715,9 @@ diff -u openssl/util/mk1mf.pl:1.1.3.1 openssl/util/mk1mf.pl:1.7
  			[\$no_rc2, \$no_idea, \$no_des, \$no_bf, \$no_cast,
  			  \$no_md2, \$no_sha, \$no_mdc2, \$no_dsa, \$no_dh,
 Index: openssl/util/mkdef.pl
-diff -u openssl/util/mkdef.pl:1.1.3.1 openssl/util/mkdef.pl:1.5
---- openssl/util/mkdef.pl:1.1.3.1	Mon Nov 24 16:14:15 2008
-+++ openssl/util/mkdef.pl	Mon Oct  5 13:17:05 2009
+diff -u openssl/util/mkdef.pl:1.6.6.1 openssl/util/mkdef.pl:1.6
+--- openssl/util/mkdef.pl:1.6.6.1	Sun Jan 15 15:45:40 2012
++++ openssl/util/mkdef.pl	Mon Jun 13 14:25:25 2011
 @@ -93,7 +93,7 @@
  			 # External "algorithms"
  			 "FP_API", "STDIO", "SOCK", "KRB5", "DGRAM",
@@ -14301,7 +15744,7 @@ diff -u openssl/util/mkdef.pl:1.1.3.1 openssl/util/mkdef.pl:1.5
  	}
  
  
-@@ -1138,6 +1141,8 @@
+@@ -1155,6 +1158,8 @@
  			if ($keyword eq "KRB5" && $no_krb5) { return 0; }
  			if ($keyword eq "ENGINE" && $no_engine) { return 0; }
  			if ($keyword eq "HW" && $no_hw) { return 0; }
@@ -14311,15 +15754,15 @@ diff -u openssl/util/mkdef.pl:1.1.3.1 openssl/util/mkdef.pl:1.5
  			if ($keyword eq "STATIC_ENGINE" && $no_static_engine) { return 0; }
  			if ($keyword eq "GMP" && $no_gmp) { return 0; }
 Index: openssl/util/pl/VC-32.pl
-diff -u openssl/util/pl/VC-32.pl:1.1.3.1 openssl/util/pl/VC-32.pl:1.5
---- openssl/util/pl/VC-32.pl:1.1.3.1	Mon Mar  9 12:14:08 2009
-+++ openssl/util/pl/VC-32.pl	Fri Sep  4 10:43:23 2009
-@@ -113,7 +113,7 @@
+diff -u openssl/util/pl/VC-32.pl:1.6.6.1 openssl/util/pl/VC-32.pl:1.6
+--- openssl/util/pl/VC-32.pl:1.6.6.1	Sun Jan 15 15:45:41 2012
++++ openssl/util/pl/VC-32.pl	Mon Jun 13 14:25:26 2011
+@@ -52,7 +52,7 @@
      my $f = $shlib || $fips ?' /MD':' /MT';
      $lib_cflag='/Zl' if (!$shlib);	# remove /DEFAULTLIBs from static lib
-     $opt_cflags=$f.' /Ox /O2 /Ob2';
+     $opt_cflags=$f.' /Ox';
 -    $dbg_cflags=$f.'d /Od -DDEBUG -D_DEBUG';
 +    $dbg_cflags=$f.'d /Od /Zi -DDEBUG -D_DEBUG';
      $lflags="/nologo /subsystem:console /opt:ref";
      }
- $mlflags='';
+ elsif ($FLAVOR =~ /CE/)
diff --git a/bin/pkcs11/openssl-1.0.0f-patch b/bin/pkcs11/openssl-1.0.0f-patch
new file mode 100644
index 00000000..9cef8e30
--- /dev/null
+++ b/bin/pkcs11/openssl-1.0.0f-patch
@@ -0,0 +1,15789 @@
+Index: openssl/Configure
+diff -u openssl/Configure:1.9.2.1 openssl/Configure:1.10
+--- openssl/Configure:1.9.2.1	Sun Jan 15 16:09:40 2012
++++ openssl/Configure	Sun Jan 15 16:30:04 2012
+@@ -10,7 +10,7 @@
+ 
+ # see INSTALL for instructions.
+ 
+-my $usage="Usage: Configure [no-<cipher> ...] [enable-<cipher> ...] [experimental-<cipher> ...] [-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared] [[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [no-krb5] [386] [--prefix=DIR] [--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags]\n";
++my $usage="Usage: Configure --pk11-libname=PK11_LIB_LOCATION --pk11-flavor=FLAVOR [no-<cipher> ...] [enable-<cipher> ...] [experimental-<cipher> ...] [-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared] [[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [no-krb5] [386] [--prefix=DIR] [--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags]\n";
+ 
+ # Options:
+ #
+@@ -23,6 +23,12 @@
+ #               default).  This needn't be set in advance, you can
+ #               just as well use "make INSTALL_PREFIX=/whatever install".
+ #
++# --pk11-libname  PKCS#11 library name.
++#               (No default)
++#
++# --pk11-flavor either crypto-accelerator or sign-only
++#               (No default)
++#
+ # --with-krb5-dir  Declare where Kerberos 5 lives.  The libraries are expected
+ #		to live in the subdirectory lib/ and the header files in
+ #		include/.  A value is required.
+@@ -343,7 +349,7 @@
+ "linux-armv4",	"gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${armv4_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+ #### IA-32 targets...
+ "linux-ia32-icc",	"icc:-DL_ENDIAN -DTERMIO -O2 -no_cpprt::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-KPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+-"linux-elf",	"gcc:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
++"linux-elf",	"gcc:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT -pthread::-ldl:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+ "linux-aout",	"gcc:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -march=i486 -Wall::(unknown):::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_asm}:a.out",
+ ####
+ "linux-generic64","gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+@@ -351,7 +357,7 @@
+ "linux-ia64",	"gcc:-DL_ENDIAN -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_UNROLL DES_INT:${ia64_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+ "linux-ia64-ecc","ecc:-DL_ENDIAN -DTERMIO -O2 -Wall -no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT:${ia64_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+ "linux-ia64-icc","icc:-DL_ENDIAN -DTERMIO -O2 -Wall -no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1 DES_INT:${ia64_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+-"linux-x86_64",	"gcc:-m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
++"linux-x86_64",	"gcc:-m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int::-D_REENTRANT -pthread::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
+ "linux-s390x",	"gcc:-m64 -DB_ENDIAN -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL:${s390x_asm}:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
+ #### SPARC Linux setups
+ # Ray Miller <ray.miller@computing-services.oxford.ac.uk> has patiently
+@@ -622,6 +628,10 @@
+ my $idx_arflags = $idx++;
+ my $idx_multilib = $idx++;
+ 
++# PKCS#11 engine patch
++my $pk11_libname="";
++my $pk11_flavor="";
++
+ my $prefix="";
+ my $libdir="";
+ my $openssldir="";
+@@ -824,6 +834,14 @@
+ 				{
+ 				$flags.=$_." ";
+ 				}
++			elsif (/^--pk11-libname=(.*)$/)
++				{
++				$pk11_libname=$1;
++				}
++			elsif (/^--pk11-flavor=(.*)$/)
++				{
++				$pk11_flavor=$1;
++				}
+ 			elsif (/^--prefix=(.*)$/)
+ 				{
+ 				$prefix=$1;
+@@ -961,6 +979,22 @@
+ 	exit 0;
+ }
+ 
++if (! $pk11_libname)
++        {
++        print STDERR "You must set --pk11-libname for PKCS#11 library.\n";
++        print STDERR "See README.pkcs11 for more information.\n";
++        exit 1;
++        }
++
++if (! $pk11_flavor
++    || !($pk11_flavor eq "crypto-accelerator" || $pk11_flavor eq "sign-only"))
++	{
++	print STDERR "You must set --pk11-flavor.\n";
++	print STDERR "Choices are crypto-accelerator and sign-only.\n";
++	print STDERR "See README.pkcs11 for more information.\n";
++	exit 1;
++	}
++
+ if ($target =~ m/^CygWin32(-.*)$/) {
+ 	$target = "Cygwin".$1;
+ }
+@@ -1036,6 +1070,25 @@
+ 	$exp_cflags .= " -DOPENSSL_EXPERIMENTAL_$ALGO";
+ 	}
+ 
++if ($pk11_flavor eq "crypto-accelerator")
++	{
++	$openssl_other_defines .= "#define OPENSSL_NO_HW_PKCS11SO\n";
++	$default_depflags .= " -DOPENSSL_NO_HW_PKCS11SO";
++	$depflags .= " -DOPENSSL_NO_HW_PKCS11SO";
++	$options .= " no-hw-pkcs11so";
++	print "    no-hw-pkcs11so  [pk11-flavor]";
++	print " OPENSSL_NO_HW_PKCS11SO\n";
++	}
++else
++	{
++	$openssl_other_defines .= "#define OPENSSL_NO_HW_PKCS11CA\n";
++	$default_depflags .= " -DOPENSSL_NO_HW_PKCS11CA";
++	$depflags .= " -DOPENSSL_NO_HW_PKCS11CA";
++	$options .= " no-hw-pkcs11ca";
++	print "    no-hw-pkcs11ca  [pk11-flavor]";
++	print " OPENSSL_NO_HW_PKCS11CA\n";
++}
++
+ my $IsMK1MF=scalar grep /^$target$/,@MK1MF_Builds;
+ 
+ $exe_ext=".exe" if ($target eq "Cygwin" || $target eq "DJGPP" || $target =~ /^mingw/);
+@@ -1123,6 +1176,8 @@
+ if ($flags ne "")	{ $cflags="$flags$cflags"; }
+ else			{ $no_user_cflags=1;       }
+ 
++$cflags="-DPK11_LIB_LOCATION=\"$pk11_libname\" $cflags";
++
+ # Kerberos settings.  The flavor must be provided from outside, either through
+ # the script "config" or manually.
+ if (!$no_krb5)
+@@ -1492,6 +1547,7 @@
+ 	s/^VERSION=.*/VERSION=$version/;
+ 	s/^MAJOR=.*/MAJOR=$major/;
+ 	s/^MINOR=.*/MINOR=$minor/;
++	s/^PK11_LIB_LOCATION=.*/PK11_LIB_LOCATION=$pk11_libname/;
+ 	s/^SHLIB_VERSION_NUMBER=.*/SHLIB_VERSION_NUMBER=$shlib_version_number/;
+ 	s/^SHLIB_VERSION_HISTORY=.*/SHLIB_VERSION_HISTORY=$shlib_version_history/;
+ 	s/^SHLIB_MAJOR=.*/SHLIB_MAJOR=$shlib_major/;
+Index: openssl/Makefile.org
+diff -u openssl/Makefile.org:1.5.2.1 openssl/Makefile.org:1.5
+--- openssl/Makefile.org:1.5.2.1	Sun Jan 15 16:09:41 2012
++++ openssl/Makefile.org	Mon Jun 13 17:13:25 2011
+@@ -26,6 +26,9 @@
+ INSTALL_PREFIX=
+ INSTALLTOP=/usr/local/ssl
+ 
++# You must set this through --pk11-libname configure option.
++PK11_LIB_LOCATION=
++
+ # Do not edit this manually. Use Configure --openssldir=DIR do change this!
+ OPENSSLDIR=/usr/local/ssl
+ 
+Index: openssl/README.pkcs11
+diff -u /dev/null openssl/README.pkcs11:1.7
+--- /dev/null	Mon Jan 16 18:54:22 2012
++++ openssl/README.pkcs11	Mon Jun 13 18:27:17 2011
+@@ -0,0 +1,261 @@
++ISC modified
++============
++
++The previous key naming scheme was kept for backward compatibility.
++
++The PKCS#11 engine exists in two flavors, crypto-accelerator and
++sign-only. The first one is from the Solaris patch and uses the
++PKCS#11 device for all crypto operations it supports. The second
++is a stripped down version which provides only the useful
++function (i.e., signature with a RSA private key in the device
++protected key store and key loading).
++
++As a hint PKCS#11 boards should use the crypto-accelerator flavor,
++external PKCS#11 devices the sign-only. SCA 6000 is an example
++of the first, AEP Keyper of the second.
++
++Note it is mandatory to set a pk11-flavor (and only one) in
++config/Configure.
++
++PKCS#11 engine support for OpenSSL 0.9.8l
++=========================================
++
++[Nov 19, 2009]
++
++Contents:
++
++Overview
++Revisions of the patch for 0.9.8 branch
++FAQs
++Feedback
++
++Overview
++========
++
++This patch containing code available in OpenSolaris adds support for PKCS#11
++engine into OpenSSL and implements PKCS#11 v2.20. It is to be applied against
++OpenSSL 0.9.8l source code distribution as shipped by OpenSSL.Org. Your system
++must provide PKCS#11 backend otherwise the patch is useless. You provide the
++PKCS#11 library name during the build configuration phase, see below.
++
++Patch can be applied like this:
++
++	# NOTE: use gtar if on Solaris
++	tar xfzv openssl-0.9.8l.tar.gz
++	# now download the patch to the current directory
++	# ...
++	cd openssl-0.9.8l
++	# NOTE: must use gpatch if on Solaris (is part of the system)
++	patch -p1 < path-to/pkcs11_engine-0.9.8l.patch.2009-11-19
++
++It is designed to support pure acceleration for RSA, DSA, DH and all the
++symetric ciphers and message digest algorithms that PKCS#11 and OpenSSL share
++except for missing support for patented algorithms MDC2, RC3, RC5 and IDEA.
++
++According to the PKCS#11 providers installed on your machine, it can support
++following mechanisms:
++
++	RSA, DSA, DH, RAND, DES-CBC, DES-EDE3-CBC, DES-ECB, DES-EDE3, RC4,
++	AES-128-CBC, AES-192-CBC, AES-256-CBC, AES-128-ECB, AES-192-ECB,
++	AES-256-ECB, AES-128-CTR, AES-192-CTR, AES-256-CTR, MD5, SHA1, SHA224,
++	SHA256, SHA384, SHA512
++
++Note that for AES counter mode the application must provide their own EVP
++functions since OpenSSL doesn't support counter mode through EVP yet. You may
++see OpenSSH source code (cipher.c) to get the idea how to do that. SunSSH is an
++example of code that uses the PKCS#11 engine and deals with the fork-safety
++problem (see engine.c and packet.c files if interested).
++
++You must provide the location of PKCS#11 library in your system to the
++configure script. You will be instructed to do that when you try to run the
++config script:
++
++	$ ./config 
++	Operating system: i86pc-whatever-solaris2
++	Configuring for solaris-x86-cc
++	You must set --pk11-libname for PKCS#11 library.
++	See README.pkcs11 for more information.
++
++Taking openCryptoki project on Linux AMD64 box as an example, you would run
++configure script like this:
++
++	./config --pk11-libname=/usr/lib64/pkcs11/PKCS11_API.so
++
++To check whether newly built openssl really supports PKCS#11 it's enough to run
++"apps/openssl engine" and look for "(pkcs11) PKCS #11 engine support" in the
++output. If you see no PKCS#11 engine support check that the built openssl binary
++and the PKCS#11 library from --pk11-libname don't conflict on 32/64 bits.
++
++The patch, during various phases of development, was tested on Solaris against
++PKCS#11 engine available from Solaris Cryptographic Framework (Solaris 10 and
++OpenSolaris) and also on Linux using PKCS#11 libraries from openCryptoki project
++(see openCryptoki website http://sourceforge.net/projects/opencryptoki for more
++information). Some Linux distributions even ship those libraries with the
++system. The patch should work on any system that is supported by OpenSSL itself
++and has functional PKCS#11 library.
++
++The patch contains "RSA Security Inc. PKCS #11 Cryptographic Token Interface
++(Cryptoki)" - files cryptoki.h, pkcs11.h, pkcs11f.h and pkcs11t.h which are
++copyrighted by RSA Security Inc., see pkcs11.h for more information.
++
++Other added/modified code in this patch is copyrighted by Sun Microsystems,
++Inc. and is released under the OpenSSL license (see LICENSE file for more
++information).
++
++Revisions of the patch for 0.9.8 branch
++=======================================
++
++2009-11-19
++- adjusted for OpenSSL version 0.9.8l
++
++- bugs and RFEs:
++
++	6479874 OpenSSL should support RSA key by reference/hardware keystores
++	6896677 PKCS#11 engine's hw_pk11_err.h needs to be split
++	6732677 make check to trigger Solaris specific code automatic in the
++		PKCS#11 engine
++
++2009-03-11
++- adjusted for OpenSSL version 0.9.8j 
++
++- README.pkcs11 moved out of the patch, and is shipped together with it in a
++  tarball instead so that it can be read before the patch is applied.
++
++- fixed bugs:
++
++	6804216 pkcs#11 engine should support a key length range for RC4
++	6734038 Apache SSL web server using the pkcs11 engine fails to start if
++		meta slot is disabled
++
++2008-12-02
++- fixed bugs and RFEs (most of the work done by Vladimir Kotal)
++
++	6723504 more granular locking in PKCS#11 engine
++	6667128 CRYPTO_LOCK_PK11_ENGINE assumption does not hold true
++	6710420 PKCS#11 engine source should be lint clean
++	6747327 PKCS#11 engine atfork handlers need to be aware of guys who take
++		it seriously
++	6746712 PKCS#11 engine source code should be cstyle clean
++	6731380 return codes of several functions are not checked in the PKCS#11
++		engine code
++	6746735 PKCS#11 engine should use extended FILE space API
++	6734038 Apache SSL web server using the pkcs11 engine fails to start if
++		meta slot is disabled
++
++2008-08-01
++- fixed bug
++
++	6731839 OpenSSL PKCS#11 engine no longer uses n2cp for symmetric ciphers
++		and digests
++
++- Solaris specific code for slot selection made automatic
++
++2008-07-29
++- update the patch to OpenSSL 0.9.8h version
++- pkcs11t.h updated to the latest version:
++
++	6545665 make CKM_AES_CTR available to non-kernel users
++
++- fixed bugs in the engine code:
++
++	6602801 PK11_SESSION cache has to employ reference counting scheme for
++		asymmetric key operations
++	6605538 pkcs11 functions C_FindObjects[{Init,Final}]() not called
++		atomically
++	6607307 pkcs#11 engine can't read RSA private keys
++	6652362 pk11_RSA_finish() is cutting corners
++	6662112 pk11_destroy_{rsa,dsa,dh}_key_objects() use locking in
++		suboptimal way
++	6666625 pk11_destroy_{rsa,dsa,dh}_key_objects() should be more
++		resilient to destroy failures
++	6667273 OpenSSL engine should not use free() but OPENSSL_free()
++	6670363 PKCS#11 engine fails to reuse existing symmetric keys
++	6678135 memory corruption in pk11_DH_generate_key() in pkcs#11 engine
++	6678503 DSA signature conversion in pk11_dsa_do_verify() ignores size
++		of big numbers leading to failures
++	6706562 pk11_DH_compute_key() returns 0 in case of failure instead of
++		-1
++	6706622 pk11_load_{pub,priv}key create corrupted RSA key references
++	6707129 return values from BN_new() in pk11_DH_generate_key() are not
++		checked
++	6707274 DSA/RSA/DH PKCS#11 engine operations need to be resistant to
++		structure reuse
++	6707782 OpenSSL PKCS#11 engine pretends to be aware of
++		OPENSSL_NO_{RSA,DSA,DH}
++	defines but fails miserably
++	6709966 make check_new_*() to return values to indicate cache hit/miss
++	6705200 pk11_dh struct initialization in PKCS#11 engine is missing
++		generate_params parameter
++	6709513 PKCS#11 engine sets IV length even for ECB modes
++	6728296 buffer length not initialized for C_(En|De)crypt_Final() in the
++		PKCS#11 engine
++	6728871 PKCS#11 engine must reset global_session in pk11_finish()
++
++- new features and enhancements:
++
++	6562155 OpenSSL pkcs#11 engine needs support for SHA224/256/384/512
++	6685012 OpenSSL pkcs#11 engine needs support for new cipher modes
++	6725903 OpenSSL PKCS#11 engine shouldn't use soft token for symmetric
++		ciphers and digests
++
++2007-10-15
++- update for 0.9.8f version
++- update for "6607670 teach pkcs#11 engine how to use keys be reference"
++
++2007-10-02
++- draft for "6607670 teach pkcs#11 engine how to use keys be reference"
++- draft for "6607307 pkcs#11 engine can't read RSA private keys"
++
++2007-09-26
++- 6375348 Using pkcs11 as the SSLCryptoDevice with Apache/OpenSSL causes
++	  significant performance drop
++- 6573196 memory is leaked when OpenSSL is used with PKCS#11 engine
++
++2007-05-25
++- 6558630 race in OpenSSL pkcs11 engine when using symetric block ciphers
++
++2007-05-19
++- initial patch for 0.9.8e using latest OpenSolaris code
++
++FAQs
++====
++
++(1) my build failed on Linux distro with this error:
++
++../libcrypto.a(hw_pk11.o): In function `pk11_library_init':
++hw_pk11.c:(.text+0x20f5): undefined reference to `pthread_atfork'
++
++Answer:
++
++	- don't use "no-threads" when configuring
++	- if you didn't then OpenSSL failed to create a threaded library by
++	  default. You may manually edit Configure and try again. Look for the
++	  architecture that Configure printed, for example:
++
++Configured for linux-elf.
++
++	- then edit Configure, find string "linux-elf" (inluding the quotes),
++	  and add flags to support threads to the 4th column of the 2nd string.
++	  If you build with GCC then adding "-pthread" should be enough. With
++	  "linux-elf" as an example, you would add " -pthread" right after
++	  "-D_REENTRANT", like this:
++
++....-O3 -fomit-frame-pointer -Wall::-D_REENTRANT -pthread::-ldl:.....
++
++(2) I'm using MinGW/MSYS environment and get undeclared reference error for
++pthread_atfork() function when trying to build OpenSSL with the patch.
++
++Answer:
++
++	Sorry, pthread_atfork() is not implemented in the current pthread-win32
++	(as of Nov 2009). You can not use the patch there.
++
++
++Feedback
++========
++
++Please send feedback to security-discuss@opensolaris.org. The patch was
++created by Jan.Pechanec@Sun.COM from code available in OpenSolaris.
++
++Latest version should be always available on http://blogs.sun.com/janp.
++
+Index: openssl/crypto/opensslconf.h
+diff -u openssl/crypto/opensslconf.h:1.6.2.1 openssl/crypto/opensslconf.h:1.6
+--- openssl/crypto/opensslconf.h:1.6.2.1	Sun Jan 15 16:09:43 2012
++++ openssl/crypto/opensslconf.h	Mon Jun 13 17:13:28 2011
+@@ -29,6 +29,9 @@
+ 
+ #endif /* OPENSSL_DOING_MAKEDEPEND */
+ 
++#ifndef OPENSSL_THREADS
++# define OPENSSL_THREADS
++#endif
+ #ifndef OPENSSL_NO_DYNAMIC_ENGINE
+ # define OPENSSL_NO_DYNAMIC_ENGINE
+ #endif
+@@ -61,6 +64,8 @@
+ # endif
+ #endif
+ 
++#define OPENSSL_CPUID_OBJ
++
+ /* crypto/opensslconf.h.in */
+ 
+ /* Generate 80386 code? */
+@@ -107,7 +112,7 @@
+  * This enables code handling data aligned at natural CPU word
+  * boundary. See crypto/rc4/rc4_enc.c for further details.
+  */
+-#undef RC4_CHUNK
++#define RC4_CHUNK unsigned long
+ #endif
+ #endif
+ 
+@@ -115,7 +120,7 @@
+ /* If this is set to 'unsigned int' on a DEC Alpha, this gives about a
+  * %20 speed up (longs are 8 bytes, int's are 4). */
+ #ifndef DES_LONG
+-#define DES_LONG unsigned long
++#define DES_LONG unsigned int
+ #endif
+ #endif
+ 
+@@ -126,9 +131,9 @@
+ /* Should we define BN_DIV2W here? */
+ 
+ /* Only one for the following should be defined */
+-#undef SIXTY_FOUR_BIT_LONG
++#define SIXTY_FOUR_BIT_LONG
+ #undef SIXTY_FOUR_BIT
+-#define THIRTY_TWO_BIT
++#undef THIRTY_TWO_BIT
+ #endif
+ 
+ #if defined(HEADER_RC4_LOCL_H) && !defined(CONFIG_HEADER_RC4_LOCL_H)
+@@ -140,7 +145,7 @@
+ 
+ #if defined(HEADER_BF_LOCL_H) && !defined(CONFIG_HEADER_BF_LOCL_H)
+ #define CONFIG_HEADER_BF_LOCL_H
+-#undef BF_PTR
++#define BF_PTR2
+ #endif /* HEADER_BF_LOCL_H */
+ 
+ #if defined(HEADER_DES_LOCL_H) && !defined(CONFIG_HEADER_DES_LOCL_H)
+@@ -170,7 +175,7 @@
+ /* Unroll the inner loop, this sometimes helps, sometimes hinders.
+  * Very mucy CPU dependant */
+ #ifndef DES_UNROLL
+-#undef DES_UNROLL
++#define DES_UNROLL
+ #endif
+ 
+ /* These default values were supplied by
+Index: openssl/crypto/bio/bss_file.c
+diff -u openssl/crypto/bio/bss_file.c:1.6.2.1 openssl/crypto/bio/bss_file.c:1.6
+--- openssl/crypto/bio/bss_file.c:1.6.2.1	Sun Jan 15 16:09:44 2012
++++ openssl/crypto/bio/bss_file.c	Mon Jun 13 17:13:31 2011
+@@ -168,7 +168,7 @@
+ 		{
+ 		SYSerr(SYS_F_FOPEN,get_last_sys_error());
+ 		ERR_add_error_data(5,"fopen('",filename,"','",mode,"')");
+-		if (errno == ENOENT)
++		if ((errno == ENOENT) || ((*mode == 'r') && (errno == EACCES)))
+ 			BIOerr(BIO_F_BIO_NEW_FILE,BIO_R_NO_SUCH_FILE);
+ 		else
+ 			BIOerr(BIO_F_BIO_NEW_FILE,ERR_R_SYS_LIB);
+Index: openssl/crypto/engine/Makefile
+diff -u openssl/crypto/engine/Makefile:1.8.2.1 openssl/crypto/engine/Makefile:1.8
+--- openssl/crypto/engine/Makefile:1.8.2.1	Sun Jan 15 16:09:46 2012
++++ openssl/crypto/engine/Makefile	Tue Jun 14 21:51:32 2011
+@@ -21,12 +21,14 @@
+ 	eng_table.c eng_pkey.c eng_fat.c eng_all.c \
+ 	tb_rsa.c tb_dsa.c tb_ecdsa.c tb_dh.c tb_ecdh.c tb_rand.c tb_store.c \
+ 	tb_cipher.c tb_digest.c tb_pkmeth.c tb_asnmth.c \
+-	eng_openssl.c eng_cnf.c eng_dyn.c eng_cryptodev.c
++	eng_openssl.c eng_cnf.c eng_dyn.c eng_cryptodev.c \
++	hw_pk11.c hw_pk11_pub.c hw_pk11so.c hw_pk11so_pub.c
+ LIBOBJ= eng_err.o eng_lib.o eng_list.o eng_init.o eng_ctrl.o \
+ 	eng_table.o eng_pkey.o eng_fat.o eng_all.o \
+ 	tb_rsa.o tb_dsa.o tb_ecdsa.o tb_dh.o tb_ecdh.o tb_rand.o tb_store.o \
+ 	tb_cipher.o tb_digest.o tb_pkmeth.o tb_asnmth.o \
+-	eng_openssl.o eng_cnf.o eng_dyn.o eng_cryptodev.o
++	eng_openssl.o eng_cnf.o eng_dyn.o eng_cryptodev.o \
++	hw_pk11.o hw_pk11_pub.o hw_pk11so.o hw_pk11so_pub.o
+ 
+ SRC= $(LIBSRC)
+ 
+@@ -264,6 +266,83 @@
+ eng_table.o: ../../include/openssl/symhacks.h ../../include/openssl/x509.h
+ eng_table.o: ../../include/openssl/x509_vfy.h ../cryptlib.h eng_int.h
+ eng_table.o: eng_table.c
++hw_pk11.o: ../../e_os.h ../../include/openssl/aes.h
++hw_pk11.o: ../../include/openssl/asn1.h ../../include/openssl/bio.h
++hw_pk11.o: ../../include/openssl/bn.h ../../include/openssl/buffer.h
++hw_pk11.o: ../../include/openssl/crypto.h ../../include/openssl/dh.h
++hw_pk11.o: ../../include/openssl/dsa.h ../../include/openssl/dso.h
++hw_pk11.o: ../../include/openssl/e_os2.h ../../include/openssl/ec.h
++hw_pk11.o: ../../include/openssl/ecdh.h ../../include/openssl/ecdsa.h
++hw_pk11.o: ../../include/openssl/engine.h ../../include/openssl/err.h
++hw_pk11.o: ../../include/openssl/evp.h ../../include/openssl/lhash.h
++hw_pk11.o: ../../include/openssl/md5.h ../../include/openssl/obj_mac.h
++hw_pk11.o: ../../include/openssl/objects.h ../../include/openssl/opensslconf.h
++hw_pk11.o: ../../include/openssl/opensslv.h ../../include/openssl/ossl_typ.h
++hw_pk11.o: ../../include/openssl/pem.h ../../include/openssl/pem2.h
++hw_pk11.o: ../../include/openssl/pkcs7.h ../../include/openssl/rand.h
++hw_pk11.o: ../../include/openssl/rsa.h ../../include/openssl/safestack.h
++hw_pk11.o: ../../include/openssl/sha.h ../../include/openssl/stack.h
++hw_pk11.o: ../../include/openssl/symhacks.h ../../include/openssl/x509.h
++hw_pk11.o: ../../include/openssl/x509_vfy.h ../cryptlib.h cryptoki.h hw_pk11.c
++hw_pk11.o: hw_pk11_err.c hw_pk11_err.h hw_pk11ca.h pkcs11.h pkcs11f.h pkcs11t.h
++hw_pk11_pub.o: ../../e_os.h ../../include/openssl/asn1.h
++hw_pk11_pub.o: ../../include/openssl/bio.h ../../include/openssl/bn.h
++hw_pk11_pub.o: ../../include/openssl/buffer.h ../../include/openssl/crypto.h
++hw_pk11_pub.o: ../../include/openssl/dh.h ../../include/openssl/dsa.h
++hw_pk11_pub.o: ../../include/openssl/dso.h ../../include/openssl/e_os2.h
++hw_pk11_pub.o: ../../include/openssl/ec.h ../../include/openssl/ecdh.h
++hw_pk11_pub.o: ../../include/openssl/ecdsa.h ../../include/openssl/engine.h
++hw_pk11_pub.o: ../../include/openssl/err.h ../../include/openssl/evp.h
++hw_pk11_pub.o: ../../include/openssl/lhash.h ../../include/openssl/obj_mac.h
++hw_pk11_pub.o: ../../include/openssl/objects.h
++hw_pk11_pub.o: ../../include/openssl/opensslconf.h
++hw_pk11_pub.o: ../../include/openssl/opensslv.h
++hw_pk11_pub.o: ../../include/openssl/ossl_typ.h ../../include/openssl/pem.h
++hw_pk11_pub.o: ../../include/openssl/pem2.h ../../include/openssl/pkcs7.h
++hw_pk11_pub.o: ../../include/openssl/rand.h ../../include/openssl/rsa.h
++hw_pk11_pub.o: ../../include/openssl/safestack.h ../../include/openssl/sha.h
++hw_pk11_pub.o: ../../include/openssl/stack.h ../../include/openssl/symhacks.h
++hw_pk11_pub.o: ../../include/openssl/x509.h ../../include/openssl/x509_vfy.h
++hw_pk11_pub.o: ../cryptlib.h cryptoki.h hw_pk11_err.h hw_pk11_pub.c hw_pk11ca.h
++hw_pk11_pub.o: pkcs11.h pkcs11f.h pkcs11t.h
++hw_pk11so.o: ../../e_os.h ../../include/openssl/asn1.h
++hw_pk11so.o: ../../include/openssl/bio.h ../../include/openssl/bn.h
++hw_pk11so.o: ../../include/openssl/buffer.h ../../include/openssl/crypto.h
++hw_pk11so.o: ../../include/openssl/dso.h ../../include/openssl/e_os2.h
++hw_pk11so.o: ../../include/openssl/ec.h ../../include/openssl/ecdh.h
++hw_pk11so.o: ../../include/openssl/ecdsa.h ../../include/openssl/engine.h
++hw_pk11so.o: ../../include/openssl/err.h ../../include/openssl/evp.h
++hw_pk11so.o: ../../include/openssl/lhash.h ../../include/openssl/md5.h
++hw_pk11so.o: ../../include/openssl/obj_mac.h ../../include/openssl/objects.h
++hw_pk11so.o: ../../include/openssl/opensslconf.h
++hw_pk11so.o: ../../include/openssl/opensslv.h ../../include/openssl/ossl_typ.h
++hw_pk11so.o: ../../include/openssl/pem.h ../../include/openssl/pem2.h
++hw_pk11so.o: ../../include/openssl/pkcs7.h ../../include/openssl/rand.h
++hw_pk11so.o: ../../include/openssl/rsa.h ../../include/openssl/safestack.h
++hw_pk11so.o: ../../include/openssl/sha.h ../../include/openssl/stack.h
++hw_pk11so.o: ../../include/openssl/symhacks.h ../../include/openssl/x509.h
++hw_pk11so.o: ../../include/openssl/x509_vfy.h ../cryptlib.h cryptoki.h
++hw_pk11so.o: hw_pk11_err.c hw_pk11_err.h hw_pk11so.c hw_pk11so.h pkcs11.h
++hw_pk11so.o: pkcs11f.h pkcs11t.h
++hw_pk11so_pub.o: ../../e_os.h ../../include/openssl/asn1.h
++hw_pk11so_pub.o: ../../include/openssl/bio.h ../../include/openssl/bn.h
++hw_pk11so_pub.o: ../../include/openssl/buffer.h ../../include/openssl/crypto.h
++hw_pk11so_pub.o: ../../include/openssl/dso.h ../../include/openssl/e_os2.h
++hw_pk11so_pub.o: ../../include/openssl/ec.h ../../include/openssl/ecdh.h
++hw_pk11so_pub.o: ../../include/openssl/ecdsa.h ../../include/openssl/engine.h
++hw_pk11so_pub.o: ../../include/openssl/err.h ../../include/openssl/evp.h
++hw_pk11so_pub.o: ../../include/openssl/lhash.h ../../include/openssl/obj_mac.h
++hw_pk11so_pub.o: ../../include/openssl/objects.h
++hw_pk11so_pub.o: ../../include/openssl/opensslconf.h
++hw_pk11so_pub.o: ../../include/openssl/opensslv.h
++hw_pk11so_pub.o: ../../include/openssl/ossl_typ.h ../../include/openssl/pem.h
++hw_pk11so_pub.o: ../../include/openssl/pem2.h ../../include/openssl/pkcs7.h
++hw_pk11so_pub.o: ../../include/openssl/rand.h ../../include/openssl/rsa.h
++hw_pk11so_pub.o: ../../include/openssl/safestack.h ../../include/openssl/sha.h
++hw_pk11so_pub.o: ../../include/openssl/stack.h ../../include/openssl/symhacks.h
++hw_pk11so_pub.o: ../../include/openssl/x509.h ../../include/openssl/x509_vfy.h
++hw_pk11so_pub.o: ../cryptlib.h cryptoki.h hw_pk11_err.h hw_pk11so.h
++hw_pk11so_pub.o: hw_pk11so_pub.c pkcs11.h pkcs11f.h pkcs11t.h
+ tb_asnmth.o: ../../e_os.h ../../include/openssl/asn1.h
+ tb_asnmth.o: ../../include/openssl/bio.h ../../include/openssl/buffer.h
+ tb_asnmth.o: ../../include/openssl/crypto.h ../../include/openssl/e_os2.h
+Index: openssl/crypto/engine/cryptoki.h
+diff -u /dev/null openssl/crypto/engine/cryptoki.h:1.4
+--- /dev/null	Mon Jan 16 18:54:23 2012
++++ openssl/crypto/engine/cryptoki.h	Thu Dec 18 00:14:12 2008
+@@ -0,0 +1,103 @@
++/*
++ * CDDL HEADER START
++ *
++ * The contents of this file are subject to the terms of the
++ * Common Development and Distribution License, Version 1.0 only
++ * (the "License").  You may not use this file except in compliance
++ * with the License.
++ *
++ * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
++ * or http://www.opensolaris.org/os/licensing.
++ * See the License for the specific language governing permissions
++ * and limitations under the License.
++ *
++ * When distributing Covered Code, include this CDDL HEADER in each
++ * file and include the License file at usr/src/OPENSOLARIS.LICENSE.
++ * If applicable, add the following below this CDDL HEADER, with the
++ * fields enclosed by brackets "[]" replaced with your own identifying
++ * information: Portions Copyright [yyyy] [name of copyright owner]
++ *
++ * CDDL HEADER END
++ */
++/*
++ * Copyright 2003 Sun Microsystems, Inc.   All rights reserved.
++ * Use is subject to license terms.
++ */
++
++#ifndef	_CRYPTOKI_H
++#define	_CRYPTOKI_H
++
++/* ident	"@(#)cryptoki.h	1.2	05/06/08 SMI" */
++
++#ifdef	__cplusplus
++extern "C" {
++#endif
++
++#ifndef	CK_PTR
++#define	CK_PTR *
++#endif
++
++#ifndef CK_DEFINE_FUNCTION
++#define	CK_DEFINE_FUNCTION(returnType, name) returnType name
++#endif
++
++#ifndef CK_DECLARE_FUNCTION
++#define	CK_DECLARE_FUNCTION(returnType, name) returnType name
++#endif
++
++#ifndef CK_DECLARE_FUNCTION_POINTER
++#define	CK_DECLARE_FUNCTION_POINTER(returnType, name) returnType (* name)
++#endif
++
++#ifndef CK_CALLBACK_FUNCTION
++#define	CK_CALLBACK_FUNCTION(returnType, name) returnType (* name)
++#endif
++
++#ifndef NULL_PTR
++#include <unistd.h>	/* For NULL */
++#define	NULL_PTR NULL
++#endif
++
++/*
++ * pkcs11t.h defines TRUE and FALSE in a way that upsets lint
++ */
++#ifndef	CK_DISABLE_TRUE_FALSE
++#define	CK_DISABLE_TRUE_FALSE
++#ifndef	TRUE
++#define	TRUE	1
++#endif /* TRUE */
++#ifndef	FALSE
++#define	FALSE	0
++#endif /* FALSE */
++#endif /* CK_DISABLE_TRUE_FALSE */
++
++#undef CK_PKCS11_FUNCTION_INFO
++
++#include "pkcs11.h"
++
++/* Solaris specific functions */
++
++#include <stdlib.h>
++
++/*
++ * SUNW_C_GetMechSession will initialize the framework and do all
++ * the necessary PKCS#11 calls to create a session capable of
++ * providing operations on the requested mechanism
++ */
++CK_RV SUNW_C_GetMechSession(CK_MECHANISM_TYPE mech,
++    CK_SESSION_HANDLE_PTR hSession);
++
++/*
++ * SUNW_C_KeyToObject will create a secret key object for the given
++ * mechanism from the rawkey data.
++ */
++CK_RV SUNW_C_KeyToObject(CK_SESSION_HANDLE hSession,
++    CK_MECHANISM_TYPE mech, const void *rawkey, size_t rawkey_len,
++    CK_OBJECT_HANDLE_PTR obj);
++
++
++#ifdef	__cplusplus
++}
++#endif
++
++#endif	/* _CRYPTOKI_H */
+Index: openssl/crypto/engine/eng_all.c
+diff -u openssl/crypto/engine/eng_all.c:1.5.2.1 openssl/crypto/engine/eng_all.c:1.5
+--- openssl/crypto/engine/eng_all.c:1.5.2.1	Sun Jan 15 16:09:46 2012
++++ openssl/crypto/engine/eng_all.c	Mon Jun 13 17:13:35 2011
+@@ -111,6 +111,14 @@
+ #if defined(OPENSSL_SYS_WIN32) && !defined(OPENSSL_NO_CAPIENG)
+ 	ENGINE_load_capi();
+ #endif
++#ifndef OPENSSL_NO_HW_PKCS11
++#ifndef OPENSSL_NO_HW_PKCS11CA
++	ENGINE_load_pk11ca();
++#endif
++#ifndef OPENSSL_NO_HW_PKCS11SO
++	ENGINE_load_pk11so();
++#endif
++#endif
+ #endif
+ 	}
+ 
+Index: openssl/crypto/engine/engine.h
+diff -u openssl/crypto/engine/engine.h:1.5.2.1 openssl/crypto/engine/engine.h:1.5
+--- openssl/crypto/engine/engine.h:1.5.2.1	Sun Jan 15 16:09:46 2012
++++ openssl/crypto/engine/engine.h	Mon Jun 13 17:13:36 2011
+@@ -336,6 +336,12 @@
+ void ENGINE_load_ubsec(void);
+ void ENGINE_load_padlock(void);
+ void ENGINE_load_capi(void);
++#ifndef OPENSSL_NO_HW_PKCS11CA
++void ENGINE_load_pk11ca(void);
++#endif
++#ifndef OPENSSL_NO_HW_PKCS11SO
++void ENGINE_load_pk11so(void);
++#endif
+ #ifndef OPENSSL_NO_GMP
+ void ENGINE_load_gmp(void);
+ #endif
+Index: openssl/crypto/engine/hw_pk11.c
+diff -u /dev/null openssl/crypto/engine/hw_pk11.c:1.30
+--- /dev/null	Mon Jan 16 18:54:23 2012
++++ openssl/crypto/engine/hw_pk11.c	Thu Jun 16 12:31:53 2011
+@@ -0,0 +1,4057 @@
++/*
++ * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
++ * Use is subject to license terms.
++ */
++
++/* crypto/engine/hw_pk11.c */
++/*
++ * This product includes software developed by the OpenSSL Project for
++ * use in the OpenSSL Toolkit (http://www.openssl.org/).
++ *
++ * This project also referenced hw_pkcs11-0.9.7b.patch written by
++ * Afchine Madjlessi.
++ */
++/*
++ * ====================================================================
++ * Copyright (c) 2000-2001 The OpenSSL Project.  All rights reserved.
++ *
++ * Redistribution and use in source and binary forms, with or without
++ * modification, are permitted provided that the following conditions
++ * are met:
++ *
++ * 1. Redistributions of source code must retain the above copyright
++ *    notice, this list of conditions and the following disclaimer.
++ *
++ * 2. Redistributions in binary form must reproduce the above copyright
++ *    notice, this list of conditions and the following disclaimer in
++ *    the documentation and/or other materials provided with the
++ *    distribution.
++ *
++ * 3. All advertising materials mentioning features or use of this
++ *    software must display the following acknowledgment:
++ *    "This product includes software developed by the OpenSSL Project
++ *    for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
++ *
++ * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
++ *    endorse or promote products derived from this software without
++ *    prior written permission. For written permission, please contact
++ *    licensing@OpenSSL.org.
++ *
++ * 5. Products derived from this software may not be called "OpenSSL"
++ *    nor may "OpenSSL" appear in their names without prior written
++ *    permission of the OpenSSL Project.
++ *
++ * 6. Redistributions of any form whatsoever must retain the following
++ *    acknowledgment:
++ *    "This product includes software developed by the OpenSSL Project
++ *    for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
++ *
++ * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
++ * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
++ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
++ * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR
++ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
++ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
++ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
++ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
++ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
++ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
++ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
++ * OF THE POSSIBILITY OF SUCH DAMAGE.
++ * ====================================================================
++ *
++ * This product includes cryptographic software written by Eric Young
++ * (eay@cryptsoft.com).  This product includes software written by Tim
++ * Hudson (tjh@cryptsoft.com).
++ *
++ */
++
++#include <stdio.h>
++#include <stdlib.h>
++#include <string.h>
++#include <sys/types.h>
++
++#include <openssl/e_os2.h>
++#include <openssl/crypto.h>
++#include <cryptlib.h>
++#include <openssl/engine.h>
++#include <openssl/dso.h>
++#include <openssl/err.h>
++#include <openssl/bn.h>
++#include <openssl/md5.h>
++#include <openssl/pem.h>
++#ifndef OPENSSL_NO_RSA
++#include <openssl/rsa.h>
++#endif
++#ifndef OPENSSL_NO_DSA
++#include <openssl/dsa.h>
++#endif
++#ifndef OPENSSL_NO_DH
++#include <openssl/dh.h>
++#endif
++#include <openssl/rand.h>
++#include <openssl/objects.h>
++#include <openssl/x509.h>
++#include <openssl/aes.h>
++
++#ifdef OPENSSL_SYS_WIN32
++typedef int pid_t;
++#define getpid() GetCurrentProcessId()
++#define NOPTHREADS
++#ifndef NULL_PTR
++#define NULL_PTR NULL
++#endif
++#define CK_DEFINE_FUNCTION(returnType, name) \
++	returnType __declspec(dllexport) name
++#define CK_DECLARE_FUNCTION(returnType, name) \
++	returnType __declspec(dllimport) name
++#define CK_DECLARE_FUNCTION_POINTER(returnType, name) \
++	returnType __declspec(dllimport) (* name)
++#else
++#include <signal.h>
++#include <unistd.h>
++#include <dlfcn.h>
++#endif
++
++#ifndef NOPTHREADS
++#include <pthread.h>
++#endif
++
++#ifndef OPENSSL_NO_HW
++#ifndef OPENSSL_NO_HW_PK11
++#ifndef OPENSSL_NO_HW_PK11CA
++
++/* label for debug messages printed on stderr */
++#define	PK11_DBG	"PKCS#11 ENGINE DEBUG"
++/* prints a lot of debug messages on stderr about slot selection process */
++/* #undef	DEBUG_SLOT_SELECTION */
++/*
++ * Solaris specific code. See comment at check_hw_mechanisms() for more
++ * information.
++ */
++#if defined(__SVR4) && defined(__sun)
++#undef	SOLARIS_HW_SLOT_SELECTION
++#endif
++
++/*
++ * AES counter mode is not supported in the OpenSSL EVP API yet and neither
++ * there are official OIDs for mechanisms based on this mode. With our changes,
++ * an application can define its own EVP calls for AES counter mode and then
++ * it can make use of hardware acceleration through this engine. However, it's
++ * better if we keep AES CTR support code under ifdef's.
++ */
++#define	SOLARIS_AES_CTR
++
++#ifdef OPENSSL_SYS_WIN32
++#pragma pack(push, cryptoki, 1)
++#include "cryptoki.h"
++#include "pkcs11.h"
++#pragma pack(pop, cryptoki)
++#else
++#include "cryptoki.h"
++#include "pkcs11.h"
++#endif
++#include "hw_pk11ca.h"
++#include "hw_pk11_err.c"
++
++#ifdef	SOLARIS_AES_CTR
++/*
++ * NIDs for AES counter mode that will be defined during the engine
++ * initialization.
++ */
++static int NID_aes_128_ctr = NID_undef;
++static int NID_aes_192_ctr = NID_undef;
++static int NID_aes_256_ctr = NID_undef;
++#endif	/* SOLARIS_AES_CTR */
++
++/*
++ * We use this lock to prevent multiple C_Login()s, guard getpassphrase(),
++ * uri_struct manipulation, and static token info. All of that is used by the
++ * RSA keys by reference feature.
++ */
++#ifndef NOPTHREADS
++pthread_mutex_t *token_lock;
++#endif
++
++#ifdef	SOLARIS_HW_SLOT_SELECTION
++/*
++ * Tables for symmetric ciphers and digest mechs found in the pkcs11_kernel
++ * library. See comment at check_hw_mechanisms() for more information.
++ */
++static int *hw_cnids;
++static int *hw_dnids;
++#endif	/* SOLARIS_HW_SLOT_SELECTION */
++
++/* PKCS#11 session caches and their locks for all operation types */
++static PK11_CACHE session_cache[OP_MAX];
++
++/*
++ * We cache the flags so that we do not have to run C_GetTokenInfo() again when
++ * logging into the token.
++ */
++CK_FLAGS pubkey_token_flags;
++
++/*
++ * As stated in v2.20, 11.7 Object Management Function, in section for
++ * C_FindObjectsInit(), at most one search operation may be active at a given
++ * time in a given session. Therefore, C_Find{,Init,Final}Objects() should be
++ * grouped together to form one atomic search operation. This is already
++ * ensured by the property of unique PKCS#11 session handle used for each
++ * PK11_SESSION object.
++ *
++ * This is however not the biggest concern - maintaining consistency of the
++ * underlying object store is more important. The same section of the spec also
++ * says that one thread can be in the middle of a search operation while another
++ * thread destroys the object matching the search template which would result in
++ * invalid handle returned from the search operation.
++ *
++ * Hence, the following locks are used for both protection of the object stores.
++ * They are also used for active list protection.
++ */
++#ifndef NOPTHREADS
++pthread_mutex_t *find_lock[OP_MAX] = { NULL };
++#endif
++
++/*
++ * lists of asymmetric key handles which are active (referenced by at least one
++ * PK11_SESSION structure, either held by a thread or present in free_session
++ * list) for given algorithm type
++ */
++PK11_active *active_list[OP_MAX] = { NULL };
++
++/*
++ * Create all secret key objects in a global session so that they are available
++ * to use for other sessions. These other sessions may be opened or closed
++ * without losing the secret key objects.
++ */
++static CK_SESSION_HANDLE	global_session = CK_INVALID_HANDLE;
++
++/* ENGINE level stuff */
++static int pk11_init(ENGINE *e);
++static int pk11_library_init(ENGINE *e);
++static int pk11_finish(ENGINE *e);
++static int pk11_ctrl(ENGINE *e, int cmd, long i, void *p, void (*f)(void));
++static int pk11_destroy(ENGINE *e);
++
++/* RAND stuff */
++static void pk11_rand_seed(const void *buf, int num);
++static void pk11_rand_add(const void *buf, int num, double add_entropy);
++static void pk11_rand_cleanup(void);
++static int pk11_rand_bytes(unsigned char *buf, int num);
++static int pk11_rand_status(void);
++
++/* These functions are also used in other files */
++PK11_SESSION *pk11_get_session(PK11_OPTYPE optype);
++void pk11_return_session(PK11_SESSION *sp, PK11_OPTYPE optype);
++
++/* active list manipulation functions used in this file */
++extern int pk11_active_delete(CK_OBJECT_HANDLE h, PK11_OPTYPE type);
++extern void pk11_free_active_list(PK11_OPTYPE type);
++
++#ifndef OPENSSL_NO_RSA
++int pk11_destroy_rsa_key_objects(PK11_SESSION *session);
++int pk11_destroy_rsa_object_pub(PK11_SESSION *sp, CK_BBOOL uselock);
++int pk11_destroy_rsa_object_priv(PK11_SESSION *sp, CK_BBOOL uselock);
++#endif
++#ifndef OPENSSL_NO_DSA
++int pk11_destroy_dsa_key_objects(PK11_SESSION *session);
++int pk11_destroy_dsa_object_pub(PK11_SESSION *sp, CK_BBOOL uselock);
++int pk11_destroy_dsa_object_priv(PK11_SESSION *sp, CK_BBOOL uselock);
++#endif
++#ifndef OPENSSL_NO_DH
++int pk11_destroy_dh_key_objects(PK11_SESSION *session);
++int pk11_destroy_dh_object(PK11_SESSION *session, CK_BBOOL uselock);
++#endif
++
++/* Local helper functions */
++static int pk11_free_all_sessions(void);
++static int pk11_free_session_list(PK11_OPTYPE optype);
++static int pk11_setup_session(PK11_SESSION *sp, PK11_OPTYPE optype);
++static int pk11_destroy_cipher_key_objects(PK11_SESSION *session);
++static int pk11_destroy_object(CK_SESSION_HANDLE session, CK_OBJECT_HANDLE oh,
++	CK_BBOOL persistent);
++static const char *get_PK11_LIBNAME(void);
++static void free_PK11_LIBNAME(void);
++static long set_PK11_LIBNAME(const char *name);
++
++/* Symmetric cipher and digest support functions */
++static int cipher_nid_to_pk11(int nid);
++#ifdef	SOLARIS_AES_CTR
++static int pk11_add_NID(char *sn, char *ln);
++static int pk11_add_aes_ctr_NIDs(void);
++#endif	/* SOLARIS_AES_CTR */
++static int pk11_usable_ciphers(const int **nids);
++static int pk11_usable_digests(const int **nids);
++static int pk11_cipher_init(EVP_CIPHER_CTX *ctx, const unsigned char *key,
++	const unsigned char *iv, int enc);
++static int pk11_cipher_final(PK11_SESSION *sp);
++#if OPENSSL_VERSION_NUMBER < 0x10000000L
++static int pk11_cipher_do_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
++	const unsigned char *in, unsigned int inl);
++#else
++static int pk11_cipher_do_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
++	const unsigned char *in, size_t inl);
++#endif
++static int pk11_cipher_cleanup(EVP_CIPHER_CTX *ctx);
++static int pk11_engine_ciphers(ENGINE *e, const EVP_CIPHER **cipher,
++	const int **nids, int nid);
++static int pk11_engine_digests(ENGINE *e, const EVP_MD **digest,
++	const int **nids, int nid);
++static CK_OBJECT_HANDLE pk11_get_cipher_key(EVP_CIPHER_CTX *ctx,
++	const unsigned char *key, CK_KEY_TYPE key_type, PK11_SESSION *sp);
++static int check_new_cipher_key(PK11_SESSION *sp, const unsigned char *key,
++	int key_len);
++static int md_nid_to_pk11(int nid);
++static int pk11_digest_init(EVP_MD_CTX *ctx);
++static int pk11_digest_update(EVP_MD_CTX *ctx, const void *data,
++	size_t count);
++static int pk11_digest_final(EVP_MD_CTX *ctx, unsigned char *md);
++static int pk11_digest_copy(EVP_MD_CTX *to, const EVP_MD_CTX *from);
++static int pk11_digest_cleanup(EVP_MD_CTX *ctx);
++
++static int pk11_choose_slots(int *any_slot_found);
++static void pk11_find_symmetric_ciphers(CK_FUNCTION_LIST_PTR pflist,
++    CK_SLOT_ID current_slot, int *current_slot_n_cipher,
++    int *local_cipher_nids);
++static void pk11_find_digests(CK_FUNCTION_LIST_PTR pflist,
++    CK_SLOT_ID current_slot, int *current_slot_n_digest,
++    int *local_digest_nids);
++static void pk11_get_symmetric_cipher(CK_FUNCTION_LIST_PTR, int slot_id,
++    CK_MECHANISM_TYPE mech, int *current_slot_n_cipher, int *local_cipher_nids,
++    int id);
++static void pk11_get_digest(CK_FUNCTION_LIST_PTR pflist, int slot_id,
++    CK_MECHANISM_TYPE mech, int *current_slot_n_digest, int *local_digest_nids,
++    int id);
++
++static int pk11_init_all_locks(void);
++static void pk11_free_all_locks(void);
++
++#ifdef	SOLARIS_HW_SLOT_SELECTION
++static int check_hw_mechanisms(void);
++static int nid_in_table(int nid, int *nid_table);
++#endif	/* SOLARIS_HW_SLOT_SELECTION */
++
++/* Index for the supported ciphers */
++enum pk11_cipher_id {
++	PK11_DES_CBC,
++	PK11_DES3_CBC,
++	PK11_DES_ECB,
++	PK11_DES3_ECB,
++	PK11_RC4,
++	PK11_AES_128_CBC,
++	PK11_AES_192_CBC,
++	PK11_AES_256_CBC,
++	PK11_AES_128_ECB,
++	PK11_AES_192_ECB,
++	PK11_AES_256_ECB,
++	PK11_BLOWFISH_CBC,
++#ifdef	SOLARIS_AES_CTR
++	PK11_AES_128_CTR,
++	PK11_AES_192_CTR,
++	PK11_AES_256_CTR,
++#endif	/* SOLARIS_AES_CTR */
++	PK11_CIPHER_MAX
++};
++
++/* Index for the supported digests */
++enum pk11_digest_id {
++	PK11_MD5,
++	PK11_SHA1,
++	PK11_SHA224,
++	PK11_SHA256,
++	PK11_SHA384,
++	PK11_SHA512,
++	PK11_DIGEST_MAX
++};
++
++#define	TRY_OBJ_DESTROY(sp, obj_hdl, retval, uselock, alg_type, priv)	\
++	{								\
++	if (uselock)							\
++		LOCK_OBJSTORE(alg_type);				\
++	if (pk11_active_delete(obj_hdl, alg_type) == 1)			\
++		{							\
++		  retval = pk11_destroy_object(sp->session, obj_hdl,	\
++		  priv ? sp->priv_persistent : sp->pub_persistent);	\
++		}							\
++	if (uselock)							\
++		UNLOCK_OBJSTORE(alg_type);				\
++	}
++
++static int cipher_nids[PK11_CIPHER_MAX];
++static int digest_nids[PK11_DIGEST_MAX];
++static int cipher_count		= 0;
++static int digest_count		= 0;
++static CK_BBOOL pk11_have_rsa	= CK_FALSE;
++static CK_BBOOL pk11_have_recover = CK_FALSE;
++static CK_BBOOL pk11_have_dsa	= CK_FALSE;
++static CK_BBOOL pk11_have_dh	= CK_FALSE;
++static CK_BBOOL pk11_have_random = CK_FALSE;
++
++typedef struct PK11_CIPHER_st
++	{
++	enum pk11_cipher_id	id;
++	int			nid;
++	int			iv_len;
++	int			min_key_len;
++	int			max_key_len;
++	CK_KEY_TYPE		key_type;
++	CK_MECHANISM_TYPE	mech_type;
++	} PK11_CIPHER;
++
++static PK11_CIPHER ciphers[] =
++	{
++	{ PK11_DES_CBC,		NID_des_cbc,		8,	 8,   8,
++		CKK_DES,	CKM_DES_CBC, },
++	{ PK11_DES3_CBC,	NID_des_ede3_cbc,	8,	24,  24,
++		CKK_DES3,	CKM_DES3_CBC, },
++	{ PK11_DES_ECB,		NID_des_ecb,		0,	 8,   8,
++		CKK_DES,	CKM_DES_ECB, },
++	{ PK11_DES3_ECB,	NID_des_ede3_ecb,	0,	24,  24,
++		CKK_DES3,	CKM_DES3_ECB, },
++	{ PK11_RC4,		NID_rc4,		0,	16, 256,
++		CKK_RC4,	CKM_RC4, },
++	{ PK11_AES_128_CBC,	NID_aes_128_cbc,	16,	16,  16,
++		CKK_AES,	CKM_AES_CBC, },
++	{ PK11_AES_192_CBC,	NID_aes_192_cbc,	16,	24,  24,
++		CKK_AES,	CKM_AES_CBC, },
++	{ PK11_AES_256_CBC,	NID_aes_256_cbc,	16,	32,  32,
++		CKK_AES,	CKM_AES_CBC, },
++	{ PK11_AES_128_ECB,	NID_aes_128_ecb,	0,	16,  16,
++		CKK_AES,	CKM_AES_ECB, },
++	{ PK11_AES_192_ECB,	NID_aes_192_ecb,	0,	24,  24,
++		CKK_AES,	CKM_AES_ECB, },
++	{ PK11_AES_256_ECB,	NID_aes_256_ecb,	0,	32,  32,
++		CKK_AES,	CKM_AES_ECB, },
++	{ PK11_BLOWFISH_CBC,	NID_bf_cbc,		8,	16,  16,
++		CKK_BLOWFISH,	CKM_BLOWFISH_CBC, },
++#ifdef	SOLARIS_AES_CTR
++	/* we don't know the correct NIDs until the engine is initialized */
++	{ PK11_AES_128_CTR,	NID_undef,		16,	16,  16,
++		CKK_AES,	CKM_AES_CTR, },
++	{ PK11_AES_192_CTR,	NID_undef,		16,	24,  24,
++		CKK_AES,	CKM_AES_CTR, },
++	{ PK11_AES_256_CTR,	NID_undef,		16,	32,  32,
++		CKK_AES,	CKM_AES_CTR, },
++#endif	/* SOLARIS_AES_CTR */
++	};
++
++typedef struct PK11_DIGEST_st
++	{
++	enum pk11_digest_id	id;
++	int			nid;
++	CK_MECHANISM_TYPE	mech_type;
++	} PK11_DIGEST;
++
++static PK11_DIGEST digests[] =
++	{
++	{PK11_MD5,	NID_md5,	CKM_MD5, },
++	{PK11_SHA1,	NID_sha1,	CKM_SHA_1, },
++	{PK11_SHA224,	NID_sha224,	CKM_SHA224, },
++	{PK11_SHA256,	NID_sha256,	CKM_SHA256, },
++	{PK11_SHA384,	NID_sha384,	CKM_SHA384, },
++	{PK11_SHA512,	NID_sha512,	CKM_SHA512, },
++	{0,		NID_undef,	0xFFFF, },
++	};
++
++/*
++ * Structure to be used for the cipher_data/md_data in
++ * EVP_CIPHER_CTX/EVP_MD_CTX structures in order to use the same pk11
++ * session in multiple cipher_update calls
++ */
++typedef struct PK11_CIPHER_STATE_st
++	{
++	PK11_SESSION	*sp;
++	} PK11_CIPHER_STATE;
++
++
++/*
++ * libcrypto EVP stuff - this is how we get wired to EVP so the engine gets
++ * called when libcrypto requests a cipher NID.
++ *
++ * Note how the PK11_CIPHER_STATE is used here.
++ */
++
++/* DES CBC EVP */
++static const EVP_CIPHER pk11_des_cbc =
++	{
++	NID_des_cbc,
++	8, 8, 8,
++	EVP_CIPH_CBC_MODE,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	EVP_CIPHER_set_asn1_iv,
++	EVP_CIPHER_get_asn1_iv,
++	NULL
++	};
++
++/* 3DES CBC EVP */
++static const EVP_CIPHER pk11_3des_cbc =
++	{
++	NID_des_ede3_cbc,
++	8, 24, 8,
++	EVP_CIPH_CBC_MODE,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	EVP_CIPHER_set_asn1_iv,
++	EVP_CIPHER_get_asn1_iv,
++	NULL
++	};
++
++/*
++ * ECB modes don't use an Initial Vector so that's why set_asn1_parameters and
++ * get_asn1_parameters fields are set to NULL.
++ */
++static const EVP_CIPHER pk11_des_ecb =
++	{
++	NID_des_ecb,
++	8, 8, 8,
++	EVP_CIPH_ECB_MODE,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	NULL,
++	NULL,
++	NULL
++	};
++
++static const EVP_CIPHER pk11_3des_ecb =
++	{
++	NID_des_ede3_ecb,
++	8, 24, 8,
++	EVP_CIPH_ECB_MODE,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	NULL,
++	NULL,
++	NULL
++	};
++
++
++static const EVP_CIPHER pk11_aes_128_cbc =
++	{
++	NID_aes_128_cbc,
++	16, 16, 16,
++	EVP_CIPH_CBC_MODE,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	EVP_CIPHER_set_asn1_iv,
++	EVP_CIPHER_get_asn1_iv,
++	NULL
++	};
++
++static const EVP_CIPHER pk11_aes_192_cbc =
++	{
++	NID_aes_192_cbc,
++	16, 24, 16,
++	EVP_CIPH_CBC_MODE,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	EVP_CIPHER_set_asn1_iv,
++	EVP_CIPHER_get_asn1_iv,
++	NULL
++	};
++
++static const EVP_CIPHER pk11_aes_256_cbc =
++	{
++	NID_aes_256_cbc,
++	16, 32, 16,
++	EVP_CIPH_CBC_MODE,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	EVP_CIPHER_set_asn1_iv,
++	EVP_CIPHER_get_asn1_iv,
++	NULL
++	};
++
++/*
++ * ECB modes don't use IV so that's why set_asn1_parameters and
++ * get_asn1_parameters are set to NULL.
++ */
++static const EVP_CIPHER pk11_aes_128_ecb =
++	{
++	NID_aes_128_ecb,
++	16, 16, 0,
++	EVP_CIPH_ECB_MODE,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	NULL,
++	NULL,
++	NULL
++	};
++
++static const EVP_CIPHER pk11_aes_192_ecb =
++	{
++	NID_aes_192_ecb,
++	16, 24, 0,
++	EVP_CIPH_ECB_MODE,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	NULL,
++	NULL,
++	NULL
++	};
++
++static const EVP_CIPHER pk11_aes_256_ecb =
++	{
++	NID_aes_256_ecb,
++	16, 32, 0,
++	EVP_CIPH_ECB_MODE,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	NULL,
++	NULL,
++	NULL
++	};
++
++#ifdef	SOLARIS_AES_CTR
++/*
++ * NID_undef's will be changed to the AES counter mode NIDs as soon they are
++ * created in pk11_library_init(). Note that the need to change these structures
++ * is the reason why we don't define them with the const keyword.
++ */
++static EVP_CIPHER pk11_aes_128_ctr =
++	{
++	NID_undef,
++	16, 16, 16,
++	EVP_CIPH_CBC_MODE,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	EVP_CIPHER_set_asn1_iv,
++	EVP_CIPHER_get_asn1_iv,
++	NULL
++	};
++
++static EVP_CIPHER pk11_aes_192_ctr =
++	{
++	NID_undef,
++	16, 24, 16,
++	EVP_CIPH_CBC_MODE,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	EVP_CIPHER_set_asn1_iv,
++	EVP_CIPHER_get_asn1_iv,
++	NULL
++	};
++
++static EVP_CIPHER pk11_aes_256_ctr =
++	{
++	NID_undef,
++	16, 32, 16,
++	EVP_CIPH_CBC_MODE,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	EVP_CIPHER_set_asn1_iv,
++	EVP_CIPHER_get_asn1_iv,
++	NULL
++	};
++#endif	/* SOLARIS_AES_CTR */
++
++static const EVP_CIPHER pk11_bf_cbc =
++	{
++	NID_bf_cbc,
++	8, 16, 8,
++	EVP_CIPH_VARIABLE_LENGTH,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	EVP_CIPHER_set_asn1_iv,
++	EVP_CIPHER_get_asn1_iv,
++	NULL
++	};
++
++static const EVP_CIPHER pk11_rc4 =
++	{
++	NID_rc4,
++	1, 16, 0,
++	EVP_CIPH_VARIABLE_LENGTH,
++	pk11_cipher_init,
++	pk11_cipher_do_cipher,
++	pk11_cipher_cleanup,
++	sizeof (PK11_CIPHER_STATE),
++	NULL,
++	NULL,
++	NULL
++	};
++
++static const EVP_MD pk11_md5 =
++	{
++	NID_md5,
++	NID_md5WithRSAEncryption,
++	MD5_DIGEST_LENGTH,
++	0,
++	pk11_digest_init,
++	pk11_digest_update,
++	pk11_digest_final,
++	pk11_digest_copy,
++	pk11_digest_cleanup,
++	EVP_PKEY_RSA_method,
++	MD5_CBLOCK,
++	sizeof (PK11_CIPHER_STATE),
++	};
++
++static const EVP_MD pk11_sha1 =
++	{
++	NID_sha1,
++	NID_sha1WithRSAEncryption,
++	SHA_DIGEST_LENGTH,
++	0,
++	pk11_digest_init,
++	pk11_digest_update,
++	pk11_digest_final,
++	pk11_digest_copy,
++	pk11_digest_cleanup,
++	EVP_PKEY_RSA_method,
++	SHA_CBLOCK,
++	sizeof (PK11_CIPHER_STATE),
++	};
++
++static const EVP_MD pk11_sha224 =
++	{
++	NID_sha224,
++	NID_sha224WithRSAEncryption,
++	SHA224_DIGEST_LENGTH,
++	0,
++	pk11_digest_init,
++	pk11_digest_update,
++	pk11_digest_final,
++	pk11_digest_copy,
++	pk11_digest_cleanup,
++	EVP_PKEY_RSA_method,
++	/* SHA-224 uses the same cblock size as SHA-256 */
++	SHA256_CBLOCK,
++	sizeof (PK11_CIPHER_STATE),
++	};
++
++static const EVP_MD pk11_sha256 =
++	{
++	NID_sha256,
++	NID_sha256WithRSAEncryption,
++	SHA256_DIGEST_LENGTH,
++	0,
++	pk11_digest_init,
++	pk11_digest_update,
++	pk11_digest_final,
++	pk11_digest_copy,
++	pk11_digest_cleanup,
++	EVP_PKEY_RSA_method,
++	SHA256_CBLOCK,
++	sizeof (PK11_CIPHER_STATE),
++	};
++
++static const EVP_MD pk11_sha384 =
++	{
++	NID_sha384,
++	NID_sha384WithRSAEncryption,
++	SHA384_DIGEST_LENGTH,
++	0,
++	pk11_digest_init,
++	pk11_digest_update,
++	pk11_digest_final,
++	pk11_digest_copy,
++	pk11_digest_cleanup,
++	EVP_PKEY_RSA_method,
++	/* SHA-384 uses the same cblock size as SHA-512 */
++	SHA512_CBLOCK,
++	sizeof (PK11_CIPHER_STATE),
++	};
++
++static const EVP_MD pk11_sha512 =
++	{
++	NID_sha512,
++	NID_sha512WithRSAEncryption,
++	SHA512_DIGEST_LENGTH,
++	0,
++	pk11_digest_init,
++	pk11_digest_update,
++	pk11_digest_final,
++	pk11_digest_copy,
++	pk11_digest_cleanup,
++	EVP_PKEY_RSA_method,
++	SHA512_CBLOCK,
++	sizeof (PK11_CIPHER_STATE),
++	};
++
++/*
++ * Initialization function. Sets up various PKCS#11 library components.
++ * The definitions for control commands specific to this engine
++ */
++#define PK11_CMD_SO_PATH		ENGINE_CMD_BASE
++#define PK11_CMD_PIN			(ENGINE_CMD_BASE+1)
++#define PK11_CMD_SLOT			(ENGINE_CMD_BASE+2)
++static const ENGINE_CMD_DEFN pk11_cmd_defns[] =
++	{
++		{
++		PK11_CMD_SO_PATH,
++		"SO_PATH",
++		"Specifies the path to the 'pkcs#11' shared library",
++		ENGINE_CMD_FLAG_STRING
++		},
++		{
++		PK11_CMD_PIN,
++		"PIN",
++		"Specifies the pin code",
++		ENGINE_CMD_FLAG_STRING
++		},
++		{
++		PK11_CMD_SLOT,
++		"SLOT",
++		"Specifies the slot (default is auto select)",
++		ENGINE_CMD_FLAG_NUMERIC,
++		},
++		{0, NULL, NULL, 0}
++	};
++
++
++static RAND_METHOD pk11_random =
++	{
++	pk11_rand_seed,
++	pk11_rand_bytes,
++	pk11_rand_cleanup,
++	pk11_rand_add,
++	pk11_rand_bytes,
++	pk11_rand_status
++	};
++
++
++/* Constants used when creating the ENGINE */
++#ifdef OPENSSL_NO_HW_PK11SO
++#error "can't load both crypto-accelerator and sign-only PKCS#11 engines"
++#endif
++static const char *engine_pk11_id = "pkcs11";
++static const char *engine_pk11_name =
++	"PKCS #11 engine support (crypto accelerator)";
++
++CK_FUNCTION_LIST_PTR pFuncList = NULL;
++static const char PK11_GET_FUNCTION_LIST[] = "C_GetFunctionList";
++
++/*
++ * This is a static string constant for the DSO file name and the function
++ * symbol names to bind to. We set it in the Configure script based on whether
++ * this is 32 or 64 bit build.
++ */
++static const char def_PK11_LIBNAME[] = PK11_LIB_LOCATION;
++
++static CK_BBOOL true = TRUE;
++static CK_BBOOL false = FALSE;
++/* Needed in hw_pk11_pub.c as well so that's why it is not static. */
++CK_SLOT_ID pubkey_SLOTID = 0;
++static CK_SLOT_ID rand_SLOTID = 0;
++static CK_SLOT_ID SLOTID = 0;
++char *pk11_pin = NULL;
++static CK_BBOOL pk11_library_initialized = FALSE;
++static CK_BBOOL pk11_atfork_initialized = FALSE;
++static int pk11_pid = 0;
++
++static DSO *pk11_dso = NULL;
++
++/* allocate and initialize all locks used by the engine itself */
++static int pk11_init_all_locks(void)
++	{
++#ifndef NOPTHREADS
++	int type;
++
++	if ((token_lock = OPENSSL_malloc(sizeof (pthread_mutex_t))) == NULL)
++		goto malloc_err;
++	(void) pthread_mutex_init(token_lock, NULL);
++
++#ifndef OPENSSL_NO_RSA
++	find_lock[OP_RSA] = OPENSSL_malloc(sizeof (pthread_mutex_t));
++	if (find_lock[OP_RSA] == NULL)
++		goto malloc_err;
++	(void) pthread_mutex_init(find_lock[OP_RSA], NULL);
++#endif /* OPENSSL_NO_RSA */
++
++#ifndef OPENSSL_NO_DSA
++	find_lock[OP_DSA] = OPENSSL_malloc(sizeof (pthread_mutex_t));
++	if (find_lock[OP_DSA] == NULL)
++		goto malloc_err;
++	(void) pthread_mutex_init(find_lock[OP_DSA], NULL);
++#endif /* OPENSSL_NO_DSA */
++
++#ifndef OPENSSL_NO_DH
++	find_lock[OP_DH] = OPENSSL_malloc(sizeof (pthread_mutex_t));
++	if (find_lock[OP_DH] == NULL)
++		goto malloc_err;
++	(void) pthread_mutex_init(find_lock[OP_DH], NULL);
++#endif /* OPENSSL_NO_DH */
++
++	for (type = 0; type < OP_MAX; type++)
++		{
++		session_cache[type].lock =
++		    OPENSSL_malloc(sizeof (pthread_mutex_t));
++		if (session_cache[type].lock == NULL)
++			goto malloc_err;
++		(void) pthread_mutex_init(session_cache[type].lock, NULL);
++		}
++
++	return (1);
++
++malloc_err:
++	pk11_free_all_locks();
++	PK11err(PK11_F_INIT_ALL_LOCKS, PK11_R_MALLOC_FAILURE);
++	return (0);
++#else
++	return (1);
++#endif
++	}
++
++static void pk11_free_all_locks(void)
++	{
++#ifndef NOPTHREADS
++	int type;
++
++#ifndef OPENSSL_NO_RSA
++	if (find_lock[OP_RSA] != NULL)
++		{
++		(void) pthread_mutex_destroy(find_lock[OP_RSA]);
++		OPENSSL_free(find_lock[OP_RSA]);
++		find_lock[OP_RSA] = NULL;
++		}
++#endif /* OPENSSL_NO_RSA */
++#ifndef OPENSSL_NO_DSA
++	if (find_lock[OP_DSA] != NULL)
++		{
++		(void) pthread_mutex_destroy(find_lock[OP_DSA]);
++		OPENSSL_free(find_lock[OP_DSA]);
++		find_lock[OP_DSA] = NULL;
++		}
++#endif /* OPENSSL_NO_DSA */
++#ifndef OPENSSL_NO_DH
++	if (find_lock[OP_DH] != NULL)
++		{
++		(void) pthread_mutex_destroy(find_lock[OP_DH]);
++		OPENSSL_free(find_lock[OP_DH]);
++		find_lock[OP_DH] = NULL;
++		}
++#endif /* OPENSSL_NO_DH */
++
++	for (type = 0; type < OP_MAX; type++)
++		{
++		if (session_cache[type].lock != NULL)
++			{
++			(void) pthread_mutex_destroy(session_cache[type].lock);
++			OPENSSL_free(session_cache[type].lock);
++			session_cache[type].lock = NULL;
++			}
++		}
++#endif
++	}
++
++/*
++ * This internal function is used by ENGINE_pk11() and "dynamic" ENGINE support.
++ */
++static int bind_pk11(ENGINE *e)
++	{
++#ifndef OPENSSL_NO_RSA
++	const RSA_METHOD *rsa = NULL;
++	RSA_METHOD *pk11_rsa = PK11_RSA();
++#endif	/* OPENSSL_NO_RSA */
++	if (!pk11_library_initialized)
++		if (!pk11_library_init(e))
++			return (0);
++
++	if (!ENGINE_set_id(e, engine_pk11_id) ||
++	    !ENGINE_set_name(e, engine_pk11_name) ||
++	    !ENGINE_set_ciphers(e, pk11_engine_ciphers) ||
++	    !ENGINE_set_digests(e, pk11_engine_digests))
++		return (0);
++#ifndef OPENSSL_NO_RSA
++	if (pk11_have_rsa == CK_TRUE)
++		{
++		if (!ENGINE_set_RSA(e, PK11_RSA()) ||
++		    !ENGINE_set_load_privkey_function(e, pk11_load_privkey) ||
++		    !ENGINE_set_load_pubkey_function(e, pk11_load_pubkey))
++			return (0);
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, "%s: registered RSA\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++		}
++#endif	/* OPENSSL_NO_RSA */
++#ifndef OPENSSL_NO_DSA
++	if (pk11_have_dsa == CK_TRUE)
++		{
++		if (!ENGINE_set_DSA(e, PK11_DSA()))
++			return (0);
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, "%s: registered DSA\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++		}
++#endif	/* OPENSSL_NO_DSA */
++#ifndef OPENSSL_NO_DH
++	if (pk11_have_dh == CK_TRUE)
++		{
++		if (!ENGINE_set_DH(e, PK11_DH()))
++			return (0);
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, "%s: registered DH\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++		}
++#endif	/* OPENSSL_NO_DH */
++	if (pk11_have_random)
++		{
++		if (!ENGINE_set_RAND(e, &pk11_random))
++			return (0);
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, "%s: registered random\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++		}
++	if (!ENGINE_set_init_function(e, pk11_init) ||
++	    !ENGINE_set_destroy_function(e, pk11_destroy) ||
++	    !ENGINE_set_finish_function(e, pk11_finish) ||
++	    !ENGINE_set_ctrl_function(e, pk11_ctrl) ||
++	    !ENGINE_set_cmd_defns(e, pk11_cmd_defns))
++		return (0);
++
++/*
++ * Apache calls OpenSSL function RSA_blinding_on() once during startup
++ * which in turn calls bn_mod_exp. Since we do not implement bn_mod_exp
++ * here, we wire it back to the OpenSSL software implementation.
++ * Since it is used only once, performance is not a concern.
++ */
++#ifndef OPENSSL_NO_RSA
++	rsa = RSA_PKCS1_SSLeay();
++	pk11_rsa->rsa_mod_exp = rsa->rsa_mod_exp;
++	pk11_rsa->bn_mod_exp = rsa->bn_mod_exp;
++	if (pk11_have_recover != CK_TRUE)
++		pk11_rsa->rsa_pub_dec = rsa->rsa_pub_dec;
++#endif	/* OPENSSL_NO_RSA */
++
++	/* Ensure the pk11 error handling is set up */
++	ERR_load_pk11_strings();
++
++	return (1);
++	}
++
++/* Dynamic engine support is disabled at a higher level for Solaris */
++#ifdef	ENGINE_DYNAMIC_SUPPORT
++#error  "dynamic engine not supported"
++static int bind_helper(ENGINE *e, const char *id)
++	{
++	if (id && (strcmp(id, engine_pk11_id) != 0))
++		return (0);
++
++	if (!bind_pk11(e))
++		return (0);
++
++	return (1);
++	}
++
++IMPLEMENT_DYNAMIC_CHECK_FN()
++IMPLEMENT_DYNAMIC_BIND_FN(bind_helper)
++
++#else
++static ENGINE *engine_pk11(void)
++	{
++	ENGINE *ret = ENGINE_new();
++
++	if (!ret)
++		return (NULL);
++
++	if (!bind_pk11(ret))
++		{
++		ENGINE_free(ret);
++		return (NULL);
++		}
++
++	return (ret);
++	}
++
++void
++ENGINE_load_pk11(void)
++	{
++	ENGINE *e_pk11 = NULL;
++
++	/*
++	 * Do not use dynamic PKCS#11 library on Solaris due to
++	 * security reasons. We will link it in statically.
++	 */
++	/* Attempt to load PKCS#11 library */
++	if (!pk11_dso)
++		pk11_dso = DSO_load(NULL, get_PK11_LIBNAME(), NULL, 0);
++
++	if (pk11_dso == NULL)
++		{
++		PK11err(PK11_F_LOAD, PK11_R_DSO_FAILURE);
++		return;
++		}
++
++	e_pk11 = engine_pk11();
++	if (!e_pk11)
++		{
++		DSO_free(pk11_dso);
++		pk11_dso = NULL;
++		return;
++		}
++
++	/*
++	 * At this point, the pk11 shared library is either dynamically
++	 * loaded or statically linked in. So, initialize the pk11
++	 * library before calling ENGINE_set_default since the latter
++	 * needs cipher and digest algorithm information
++	 */
++	if (!pk11_library_init(e_pk11))
++		{
++		DSO_free(pk11_dso);
++		pk11_dso = NULL;
++		ENGINE_free(e_pk11);
++		return;
++		}
++
++	ENGINE_add(e_pk11);
++
++	ENGINE_free(e_pk11);
++	ERR_clear_error();
++	}
++#endif	/* ENGINE_DYNAMIC_SUPPORT */
++
++/*
++ * These are the static string constants for the DSO file name and
++ * the function symbol names to bind to.
++ */
++static const char *PK11_LIBNAME = NULL;
++
++static const char *get_PK11_LIBNAME(void)
++	{
++	if (PK11_LIBNAME)
++		return (PK11_LIBNAME);
++
++	return (def_PK11_LIBNAME);
++	}
++
++static void free_PK11_LIBNAME(void)
++	{
++	if (PK11_LIBNAME)
++		OPENSSL_free((void*)PK11_LIBNAME);
++
++	PK11_LIBNAME = NULL;
++	}
++
++static long set_PK11_LIBNAME(const char *name)
++	{
++	free_PK11_LIBNAME();
++
++	return ((PK11_LIBNAME = BUF_strdup(name)) != NULL ? 1 : 0);
++	}
++
++/* acquire all engine specific mutexes before fork */
++static void pk11_fork_prepare(void)
++	{
++#ifndef NOPTHREADS
++	int i;
++
++	if (!pk11_library_initialized)
++		return;
++
++	LOCK_OBJSTORE(OP_RSA);
++	LOCK_OBJSTORE(OP_DSA);
++	LOCK_OBJSTORE(OP_DH);
++	(void) pthread_mutex_lock(token_lock);
++	for (i = 0; i < OP_MAX; i++)
++		{
++		(void) pthread_mutex_lock(session_cache[i].lock);
++		}
++#endif
++	}
++
++/* release all engine specific mutexes */
++static void pk11_fork_parent(void)
++	{
++#ifndef NOPTHREADS
++	int i;
++
++	if (!pk11_library_initialized)
++		return;
++
++	for (i = OP_MAX - 1; i >= 0; i--)
++		{
++		(void) pthread_mutex_unlock(session_cache[i].lock);
++		}
++	UNLOCK_OBJSTORE(OP_DH);
++	UNLOCK_OBJSTORE(OP_DSA);
++	UNLOCK_OBJSTORE(OP_RSA);
++	(void) pthread_mutex_unlock(token_lock);
++#endif
++	}
++
++/*
++ * same situation as in parent - we need to unlock all locks to make them
++ * accessible to all threads.
++ */
++static void pk11_fork_child(void)
++	{
++#ifndef NOPTHREADS
++	int i;
++
++	if (!pk11_library_initialized)
++		return;
++
++	for (i = OP_MAX - 1; i >= 0; i--)
++		{
++		(void) pthread_mutex_unlock(session_cache[i].lock);
++		}
++	UNLOCK_OBJSTORE(OP_DH);
++	UNLOCK_OBJSTORE(OP_DSA);
++	UNLOCK_OBJSTORE(OP_RSA);
++	(void) pthread_mutex_unlock(token_lock);
++#endif
++	}
++
++/* Initialization function for the pk11 engine */
++static int pk11_init(ENGINE *e)
++{
++	return (pk11_library_init(e));
++}
++
++static CK_C_INITIALIZE_ARGS pk11_init_args =
++	{
++	NULL_PTR,		/* CreateMutex */
++	NULL_PTR,		/* DestroyMutex */
++	NULL_PTR,		/* LockMutex */
++	NULL_PTR,		/* UnlockMutex */
++	CKF_OS_LOCKING_OK,	/* flags */
++	NULL_PTR,		/* pReserved */
++	};
++
++/*
++ * Initialization function. Sets up various PKCS#11 library components.
++ * It selects a slot based on predefined critiera. In the process, it also
++ * count how many ciphers and digests to support. Since the cipher and
++ * digest information is needed when setting default engine, this function
++ * needs to be called before calling ENGINE_set_default.
++ */
++/* ARGSUSED */
++static int pk11_library_init(ENGINE *e)
++	{
++	CK_C_GetFunctionList p;
++	CK_RV rv = CKR_OK;
++	CK_INFO info;
++	CK_ULONG ul_state_len;
++	int any_slot_found;
++	int i;
++#ifndef OPENSSL_SYS_WIN32
++	struct sigaction sigint_act, sigterm_act, sighup_act;
++#endif
++
++	/*
++	 * pk11_library_initialized is set to 0 in pk11_finish() which
++	 * is called from ENGINE_finish(). However, if there is still
++	 * at least one existing functional reference to the engine
++	 * (see engine(3) for more information), pk11_finish() is
++	 * skipped. For example, this can happen if an application
++	 * forgets to clear one cipher context. In case of a fork()
++	 * when the application is finishing the engine so that it can
++	 * be reinitialized in the child, forgotten functional
++	 * reference causes pk11_library_initialized to stay 1. In
++	 * that case we need the PID check so that we properly
++	 * initialize the engine again.
++	 */
++	if (pk11_library_initialized)
++		{
++		if (pk11_pid == getpid())
++			{
++			return (1);
++			}
++		else
++			{
++			global_session = CK_INVALID_HANDLE;
++			/*
++			 * free the locks first to prevent memory leak in case
++			 * the application calls fork() without finishing the
++			 * engine first.
++			 */
++			pk11_free_all_locks();
++			}
++		}
++
++	if (pk11_dso == NULL)
++		{
++		PK11err(PK11_F_LIBRARY_INIT, PK11_R_DSO_FAILURE);
++		goto err;
++		}
++
++#ifdef	SOLARIS_AES_CTR
++	/*
++	 * We must do this before we start working with slots since we need all
++	 * NIDs there.
++	 */
++	if (pk11_add_aes_ctr_NIDs() == 0)
++		goto err;
++#endif	/* SOLARIS_AES_CTR */
++
++#ifdef	SOLARIS_HW_SLOT_SELECTION
++	if (check_hw_mechanisms() == 0)
++		goto err;
++#endif	/* SOLARIS_HW_SLOT_SELECTION */
++
++	/* get the C_GetFunctionList function from the loaded library */
++	p = (CK_C_GetFunctionList)DSO_bind_func(pk11_dso,
++		PK11_GET_FUNCTION_LIST);
++	if (!p)
++		{
++		PK11err(PK11_F_LIBRARY_INIT, PK11_R_DSO_FAILURE);
++		goto err;
++		}
++
++	/* get the full function list from the loaded library */
++	rv = p(&pFuncList);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_LIBRARY_INIT, PK11_R_DSO_FAILURE, rv);
++		goto err;
++		}
++
++#ifndef OPENSSL_SYS_WIN32
++	/* Not all PKCS#11 library are signal safe! */
++
++	(void) memset(&sigint_act, 0, sizeof(sigint_act));
++	(void) memset(&sigterm_act, 0, sizeof(sigterm_act));
++	(void) memset(&sighup_act, 0, sizeof(sighup_act));
++	(void) sigaction(SIGINT, NULL, &sigint_act);
++	(void) sigaction(SIGTERM, NULL, &sigterm_act);
++	(void) sigaction(SIGHUP, NULL, &sighup_act);
++#endif
++	rv = pFuncList->C_Initialize((CK_VOID_PTR)&pk11_init_args);
++#ifndef OPENSSL_SYS_WIN32
++	(void) sigaction(SIGINT, &sigint_act, NULL);
++	(void) sigaction(SIGTERM, &sigterm_act, NULL);
++	(void) sigaction(SIGHUP, &sighup_act, NULL);
++#endif
++	if ((rv != CKR_OK) && (rv != CKR_CRYPTOKI_ALREADY_INITIALIZED))
++		{
++		PK11err_add_data(PK11_F_LIBRARY_INIT, PK11_R_INITIALIZE, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_GetInfo(&info);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_LIBRARY_INIT, PK11_R_GETINFO, rv);
++		goto err;
++		}
++
++	if (pk11_choose_slots(&any_slot_found) == 0)
++		goto err;
++
++	/*
++	 * The library we use, set in def_PK11_LIBNAME, may not offer any
++	 * slot(s). In that case, we must not proceed but we must not return an
++	 * error. The reason is that applications that try to set up the PKCS#11
++	 * engine don't exit on error during the engine initialization just
++	 * because no slot was present.
++	 */
++	if (any_slot_found == 0)
++		return (1);
++
++	if (global_session == CK_INVALID_HANDLE)
++		{
++		/* Open the global_session for the new process */
++		rv = pFuncList->C_OpenSession(SLOTID, CKF_SERIAL_SESSION,
++			NULL_PTR, NULL_PTR, &global_session);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_LIBRARY_INIT,
++			    PK11_R_OPENSESSION, rv);
++			goto err;
++			}
++		}
++
++	/*
++	 * Disable digest if C_GetOperationState is not supported since
++	 * this function is required by OpenSSL digest copy function
++	 */
++	/* Keyper fails to return CKR_FUNCTION_NOT_SUPPORTED */
++	if (pFuncList->C_GetOperationState(global_session, NULL, &ul_state_len)
++			!= CKR_OK) {
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, "%s: C_GetOperationState() not supported, "
++		    "setting digest_count to 0\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++		digest_count = 0;
++	}
++
++	pk11_library_initialized = TRUE;
++	pk11_pid = getpid();
++	/*
++	 * if initialization of the locks fails pk11_init_all_locks()
++	 * will do the cleanup.
++	 */
++	if (!pk11_init_all_locks())
++		goto err;
++	for (i = 0; i < OP_MAX; i++)
++		session_cache[i].head = NULL;
++	/*
++	 * initialize active lists. We only use active lists
++	 * for asymmetric ciphers.
++	 */
++	for (i = 0; i < OP_MAX; i++)
++		active_list[i] = NULL;
++
++#ifndef NOPTHREADS
++	if (!pk11_atfork_initialized)
++		{
++		if (pthread_atfork(pk11_fork_prepare, pk11_fork_parent,
++		    pk11_fork_child) != 0)
++			{
++			PK11err(PK11_F_LIBRARY_INIT, PK11_R_ATFORK_FAILED);
++			goto err;
++			}
++		pk11_atfork_initialized = TRUE;
++		}
++#endif
++
++	return (1);
++
++err:
++	return (0);
++	}
++
++/* Destructor (complements the "ENGINE_pk11()" constructor) */
++/* ARGSUSED */
++static int pk11_destroy(ENGINE *e)
++	{
++	free_PK11_LIBNAME();
++	ERR_unload_pk11_strings();
++	if (pk11_pin) {
++		memset(pk11_pin, 0, strlen(pk11_pin));
++		OPENSSL_free((void*)pk11_pin);
++	}
++	pk11_pin = NULL;
++	return (1);
++	}
++
++/*
++ * Termination function to clean up the session, the token, and the pk11
++ * library.
++ */
++/* ARGSUSED */
++static int pk11_finish(ENGINE *e)
++	{
++	int i;
++
++	if (pk11_pin) {
++		memset(pk11_pin, 0, strlen(pk11_pin));
++		OPENSSL_free((void*)pk11_pin);
++	}
++	pk11_pin = NULL;
++
++	if (pk11_dso == NULL)
++		{
++		PK11err(PK11_F_FINISH, PK11_R_NOT_LOADED);
++		goto err;
++		}
++
++	OPENSSL_assert(pFuncList != NULL);
++
++	if (pk11_free_all_sessions() == 0)
++		goto err;
++
++	/* free all active lists */
++	for (i = 0; i < OP_MAX; i++)
++		pk11_free_active_list(i);
++
++	pFuncList->C_CloseSession(global_session);
++	global_session = CK_INVALID_HANDLE;
++
++	/*
++	 * Since we are part of a library (libcrypto.so), calling this function
++	 * may have side-effects.
++	 */
++#if 0
++	pFuncList->C_Finalize(NULL);
++#endif
++
++	if (!DSO_free(pk11_dso))
++		{
++		PK11err(PK11_F_FINISH, PK11_R_DSO_FAILURE);
++		goto err;
++		}
++	pk11_dso = NULL;
++	pFuncList = NULL;
++	pk11_library_initialized = FALSE;
++	pk11_pid = 0;
++	/*
++	 * There is no way how to unregister atfork handlers (other than
++	 * unloading the library) so we just free the locks. For this reason
++	 * the atfork handlers check if the engine is initialized and bail out
++	 * immediately if not. This is necessary in case a process finishes
++	 * the engine before calling fork().
++	 */
++	pk11_free_all_locks();
++
++	return (1);
++
++err:
++	return (0);
++	}
++
++/* Standard engine interface function to set the dynamic library path */
++/* ARGSUSED */
++static int pk11_ctrl(ENGINE *e, int cmd, long i, void *p, void (*f)(void))
++	{
++	int initialized = ((pk11_dso == NULL) ? 0 : 1);
++
++	switch (cmd)
++		{
++	case PK11_CMD_SO_PATH:
++		if (p == NULL)
++			{
++			PK11err(PK11_F_CTRL, ERR_R_PASSED_NULL_PARAMETER);
++			return (0);
++			}
++
++		if (initialized)
++			{
++			PK11err(PK11_F_CTRL, PK11_R_ALREADY_LOADED);
++			return (0);
++			}
++
++		return (set_PK11_LIBNAME((const char *)p));
++	case PK11_CMD_PIN:
++		if (pk11_pin) {
++			memset(pk11_pin, 0, strlen(pk11_pin));
++			OPENSSL_free((void*)pk11_pin);
++		}
++		pk11_pin = NULL;
++
++		if (p == NULL)
++			{
++			PK11err(PK11_F_CTRL, ERR_R_PASSED_NULL_PARAMETER);
++			return (0);
++			}
++
++		pk11_pin = BUF_strdup(p);
++		if (pk11_pin == NULL)
++			{
++			PK11err(PK11_F_GET_SESSION, PK11_R_MALLOC_FAILURE);
++			return (0);
++			}
++		return (1);
++	case PK11_CMD_SLOT:
++		SLOTID = (CK_SLOT_ID)i;
++#ifdef DEBUG_SLOT_SELECTION
++		fprintf(stderr, "%s: slot set\n", PK11_DBG);
++#endif
++		return (1);
++	default:
++		break;
++		}
++
++	PK11err(PK11_F_CTRL, PK11_R_CTRL_COMMAND_NOT_IMPLEMENTED);
++
++	return (0);
++	}
++
++
++/* Required function by the engine random interface. It does nothing here */
++static void pk11_rand_cleanup(void)
++	{
++	return;
++	}
++
++/* ARGSUSED */
++static void pk11_rand_add(const void *buf, int num, double add)
++	{
++	PK11_SESSION *sp;
++
++	if ((sp = pk11_get_session(OP_RAND)) == NULL)
++		return;
++
++	/*
++	 * Ignore any errors (e.g. CKR_RANDOM_SEED_NOT_SUPPORTED) since
++	 * the calling functions do not care anyway
++	 */
++	pFuncList->C_SeedRandom(sp->session, (unsigned char *) buf, num);
++	pk11_return_session(sp, OP_RAND);
++
++	return;
++	}
++
++static void pk11_rand_seed(const void *buf, int num)
++	{
++	pk11_rand_add(buf, num, 0);
++	}
++
++static int pk11_rand_bytes(unsigned char *buf, int num)
++	{
++	CK_RV rv;
++	PK11_SESSION *sp;
++
++	if ((sp = pk11_get_session(OP_RAND)) == NULL)
++		return (0);
++
++	rv = pFuncList->C_GenerateRandom(sp->session, buf, num);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_RAND_BYTES, PK11_R_GENERATERANDOM, rv);
++		pk11_return_session(sp, OP_RAND);
++		return (0);
++		}
++
++	pk11_return_session(sp, OP_RAND);
++	return (1);
++	}
++
++/* Required function by the engine random interface. It does nothing here */
++static int pk11_rand_status(void)
++	{
++	return (1);
++	}
++
++/* Free all BIGNUM structures from PK11_SESSION. */
++static void pk11_free_nums(PK11_SESSION *sp, PK11_OPTYPE optype)
++	{
++	switch (optype)
++		{
++#ifndef	OPENSSL_NO_RSA
++		case OP_RSA:
++			if (sp->opdata_rsa_n_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_n_num);
++				sp->opdata_rsa_n_num = NULL;
++				}
++			if (sp->opdata_rsa_e_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_e_num);
++				sp->opdata_rsa_e_num = NULL;
++				}
++			if (sp->opdata_rsa_pn_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_pn_num);
++				sp->opdata_rsa_pn_num = NULL;
++				}
++			if (sp->opdata_rsa_pe_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_pe_num);
++				sp->opdata_rsa_pe_num = NULL;
++				}
++			if (sp->opdata_rsa_d_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_d_num);
++				sp->opdata_rsa_d_num = NULL;
++				}
++			break;
++#endif
++#ifndef	OPENSSL_NO_DSA
++		case OP_DSA:
++			if (sp->opdata_dsa_pub_num != NULL)
++				{
++				BN_free(sp->opdata_dsa_pub_num);
++				sp->opdata_dsa_pub_num = NULL;
++				}
++			if (sp->opdata_dsa_priv_num != NULL)
++				{
++				BN_free(sp->opdata_dsa_priv_num);
++				sp->opdata_dsa_priv_num = NULL;
++				}
++			break;
++#endif
++#ifndef	OPENSSL_NO_DH
++		case OP_DH:
++			if (sp->opdata_dh_priv_num != NULL)
++				{
++				BN_free(sp->opdata_dh_priv_num);
++				sp->opdata_dh_priv_num = NULL;
++				}
++			break;
++#endif
++		default:
++			break;
++		}
++	}
++
++/*
++ * Get new PK11_SESSION structure ready for use. Every process must have
++ * its own freelist of PK11_SESSION structures so handle fork() here
++ * by destroying the old and creating new freelist.
++ * The returned PK11_SESSION structure is disconnected from the freelist.
++ */
++PK11_SESSION *
++pk11_get_session(PK11_OPTYPE optype)
++	{
++	PK11_SESSION *sp = NULL, *sp1, *freelist;
++#ifndef NOPTHREADS
++	pthread_mutex_t *freelist_lock = NULL;
++#endif
++	static pid_t pid = 0;
++	pid_t new_pid;
++	CK_RV rv;
++
++	switch (optype)
++		{
++		case OP_RSA:
++		case OP_DSA:
++		case OP_DH:
++		case OP_RAND:
++		case OP_DIGEST:
++		case OP_CIPHER:
++#ifndef NOPTHREADS
++			freelist_lock = session_cache[optype].lock;
++#endif
++			break;
++		default:
++			PK11err(PK11_F_GET_SESSION,
++				PK11_R_INVALID_OPERATION_TYPE);
++			return (NULL);
++		}
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(freelist_lock);
++#else
++	CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++
++	/*
++	 * Will use it to find out if we forked. We cannot use the PID field in
++	 * the session structure because we could get a newly allocated session
++	 * here, with no PID information.
++	 */
++	if (pid == 0)
++		pid = getpid();
++
++	freelist = session_cache[optype].head;
++	sp = freelist;
++
++	/*
++	 * If the free list is empty, allocate new unitialized (filled
++	 * with zeroes) PK11_SESSION structure otherwise return first
++	 * structure from the freelist.
++	 */
++	if (sp == NULL)
++		{
++		if ((sp = OPENSSL_malloc(sizeof (PK11_SESSION))) == NULL)
++			{
++			PK11err(PK11_F_GET_SESSION,
++				PK11_R_MALLOC_FAILURE);
++			goto err;
++			}
++		(void) memset(sp, 0, sizeof (PK11_SESSION));
++
++		/*
++		 * It is a new session so it will look like a cache miss to the
++		 * code below. So, we must not try to to destroy its members so
++		 * mark them as unused.
++		 */
++		sp->opdata_rsa_priv_key = CK_INVALID_HANDLE;
++		sp->opdata_rsa_pub_key = CK_INVALID_HANDLE;
++		}
++	else
++		{
++		freelist = sp->next;
++		}
++
++	/*
++	 * Check whether we have forked. In that case, we must get rid of all
++	 * inherited sessions and start allocating new ones.
++	 */
++	if (pid != (new_pid = getpid()))
++		{
++		pid = new_pid;
++
++		/*
++		 * We are a new process and thus need to free any inherited
++		 * PK11_SESSION objects aside from the first session (sp) which
++		 * is the only PK11_SESSION structure we will reuse (for the
++		 * head of the list).
++		 */
++		while ((sp1 = freelist) != NULL)
++			{
++			freelist = sp1->next;
++			/*
++			 * NOTE: we do not want to call pk11_free_all_sessions()
++			 * here because it would close underlying PKCS#11
++			 * sessions and destroy all objects.
++			 */
++			pk11_free_nums(sp1, optype);
++			OPENSSL_free(sp1);
++			}
++
++		/* we have to free the active list as well. */
++		pk11_free_active_list(optype);
++
++		/* Initialize the process */
++		rv = pFuncList->C_Initialize((CK_VOID_PTR)&pk11_init_args);
++		if ((rv != CKR_OK) && (rv != CKR_CRYPTOKI_ALREADY_INITIALIZED))
++			{
++			PK11err_add_data(PK11_F_GET_SESSION, PK11_R_INITIALIZE,
++			    rv);
++			OPENSSL_free(sp);
++			sp = NULL;
++			goto err;
++			}
++
++		/*
++		 * Choose slot here since the slot table is different on this
++		 * process. If we are here then we must have found at least one
++		 * usable slot before so we don't need to check any_slot_found.
++		 * See pk11_library_init()'s usage of this function for more
++		 * information.
++		 */
++#ifdef	SOLARIS_HW_SLOT_SELECTION
++		if (check_hw_mechanisms() == 0)
++			goto err;
++#endif	/* SOLARIS_HW_SLOT_SELECTION */
++		if (pk11_choose_slots(NULL) == 0)
++			goto err;
++
++		/* Open the global_session for the new process */
++		rv = pFuncList->C_OpenSession(SLOTID, CKF_SERIAL_SESSION,
++			NULL_PTR, NULL_PTR, &global_session);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_GET_SESSION, PK11_R_OPENSESSION,
++			    rv);
++			OPENSSL_free(sp);
++			sp = NULL;
++			goto err;
++			}
++
++		/*
++		 * It is an inherited session from our parent so it needs
++		 * re-initialization.
++		 */
++		if (pk11_setup_session(sp, optype) == 0)
++			{
++			OPENSSL_free(sp);
++			sp = NULL;
++			goto err;
++			}
++		if (pk11_token_relogin(sp->session) == 0) 
++			{
++			/*
++			 * We will keep the session in the cache list and let
++			 * the caller cope with the situation.
++			 */
++			freelist = sp;
++			sp = NULL;
++			goto err;
++			}
++		}
++
++	if (sp->pid == 0)
++		{
++		/* It is a new session and needs initialization. */
++		if (pk11_setup_session(sp, optype) == 0)
++			{
++			OPENSSL_free(sp);
++			sp = NULL;
++			}
++		}
++
++	/* set new head for the list of PK11_SESSION objects */
++	session_cache[optype].head = freelist;
++
++err:
++	if (sp != NULL)
++		sp->next = NULL;
++
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(freelist_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++
++	return (sp);
++	}
++
++
++void
++pk11_return_session(PK11_SESSION *sp, PK11_OPTYPE optype)
++	{
++#ifndef NOPTHREADS
++	pthread_mutex_t *freelist_lock;
++#endif
++	PK11_SESSION *freelist;
++
++	/*
++	 * If this is a session from the parent it will be taken care of and
++	 * freed in pk11_get_session() as part of the post-fork clean up the
++	 * next time we will ask for a new session.
++	 */
++	if (sp == NULL || sp->pid != getpid())
++		return;
++
++	switch (optype)
++		{
++		case OP_RSA:
++		case OP_DSA:
++		case OP_DH:
++		case OP_RAND:
++		case OP_DIGEST:
++		case OP_CIPHER:
++#ifndef NOPTHREADS
++			freelist_lock = session_cache[optype].lock;
++#endif
++			break;
++		default:
++			PK11err(PK11_F_RETURN_SESSION,
++				PK11_R_INVALID_OPERATION_TYPE);
++			return;
++		}
++
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(freelist_lock);
++#else
++	CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	freelist = session_cache[optype].head;
++	sp->next = freelist;
++	session_cache[optype].head = sp;
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(freelist_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	}
++
++
++/* Destroy all objects. This function is called when the engine is finished */
++static int pk11_free_all_sessions()
++	{
++	int ret = 1;
++	int type;
++
++#ifndef OPENSSL_NO_RSA
++	(void) pk11_destroy_rsa_key_objects(NULL);
++#endif	/* OPENSSL_NO_RSA */
++#ifndef OPENSSL_NO_DSA
++	(void) pk11_destroy_dsa_key_objects(NULL);
++#endif	/* OPENSSL_NO_DSA */
++#ifndef OPENSSL_NO_DH
++	(void) pk11_destroy_dh_key_objects(NULL);
++#endif	/* OPENSSL_NO_DH */
++	(void) pk11_destroy_cipher_key_objects(NULL);
++
++	/*
++	 * We try to release as much as we can but any error means that we will
++	 * return 0 on exit.
++	 */
++	for (type = 0; type < OP_MAX; type++)
++		{
++		if (pk11_free_session_list(type) == 0)
++			ret = 0;
++		}
++
++	return (ret);
++	}
++
++/*
++ * Destroy session structures from the linked list specified. Free as many
++ * sessions as possible but any failure in C_CloseSession() means that we
++ * return an error on return.
++ */
++static int pk11_free_session_list(PK11_OPTYPE optype)
++	{
++	CK_RV rv;
++	PK11_SESSION *sp = NULL;
++	PK11_SESSION *freelist = NULL;
++	pid_t mypid = getpid();
++#ifndef NOPTHREADS
++	pthread_mutex_t *freelist_lock;
++#endif
++	int ret = 1;
++
++	switch (optype)
++		{
++		case OP_RSA:
++		case OP_DSA:
++		case OP_DH:
++		case OP_RAND:
++		case OP_DIGEST:
++		case OP_CIPHER:
++#ifndef NOPTHREADS
++			freelist_lock = session_cache[optype].lock;
++#endif
++			break;
++		default:
++			PK11err(PK11_F_FREE_ALL_SESSIONS,
++				PK11_R_INVALID_OPERATION_TYPE);
++			return (0);
++		}
++
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(freelist_lock);
++#else
++	CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	freelist = session_cache[optype].head;
++	while ((sp = freelist) != NULL)
++		{
++		if (sp->session != CK_INVALID_HANDLE && sp->pid == mypid)
++			{
++			rv = pFuncList->C_CloseSession(sp->session);
++			if (rv != CKR_OK)
++				{
++				PK11err_add_data(PK11_F_FREE_ALL_SESSIONS,
++					PK11_R_CLOSESESSION, rv);
++				ret = 0;
++				}
++			}
++		freelist = sp->next;
++		pk11_free_nums(sp, optype);
++		OPENSSL_free(sp);
++		}
++
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(freelist_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	return (ret);
++	}
++
++
++static int
++pk11_setup_session(PK11_SESSION *sp, PK11_OPTYPE optype)
++	{
++	CK_RV rv;
++	CK_SLOT_ID myslot;
++
++	switch (optype)
++		{
++		case OP_RSA:
++		case OP_DSA:
++		case OP_DH:
++			myslot = pubkey_SLOTID;
++			break;
++		case OP_RAND:
++			myslot = rand_SLOTID;
++			break;
++		case OP_DIGEST:
++		case OP_CIPHER:
++			myslot = SLOTID;
++			break;
++		default:
++			PK11err(PK11_F_SETUP_SESSION,
++			    PK11_R_INVALID_OPERATION_TYPE);
++			return (0);
++		}
++
++	sp->session = CK_INVALID_HANDLE;
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: myslot=%d optype=%d\n", PK11_DBG, myslot, optype);
++#endif	/* DEBUG_SLOT_SELECTION */
++	rv = pFuncList->C_OpenSession(myslot, CKF_SERIAL_SESSION,
++		NULL_PTR, NULL_PTR, &sp->session);
++	if (rv == CKR_CRYPTOKI_NOT_INITIALIZED)
++		{
++		/*
++		 * We are probably a child process so force the
++		 * reinitialize of the session
++		 */
++		pk11_library_initialized = FALSE;
++		if (!pk11_library_init(NULL))
++			return (0);
++		rv = pFuncList->C_OpenSession(myslot, CKF_SERIAL_SESSION,
++			NULL_PTR, NULL_PTR, &sp->session);
++		}
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_SETUP_SESSION, PK11_R_OPENSESSION, rv);
++		return (0);
++		}
++
++	sp->pid = getpid();
++
++	switch (optype)
++		{
++#ifndef OPENSSL_NO_RSA
++		case OP_RSA:
++			sp->opdata_rsa_pub_key = CK_INVALID_HANDLE;
++			sp->opdata_rsa_priv_key = CK_INVALID_HANDLE;
++			sp->opdata_rsa_pub = NULL;
++			sp->opdata_rsa_n_num = NULL;
++			sp->opdata_rsa_e_num = NULL;
++			sp->opdata_rsa_priv = NULL;
++			sp->opdata_rsa_pn_num = NULL;
++			sp->opdata_rsa_pe_num = NULL;
++			sp->opdata_rsa_d_num = NULL;
++			break;
++#endif	/* OPENSSL_NO_RSA */
++#ifndef OPENSSL_NO_DSA
++		case OP_DSA:
++			sp->opdata_dsa_pub_key = CK_INVALID_HANDLE;
++			sp->opdata_dsa_priv_key = CK_INVALID_HANDLE;
++			sp->opdata_dsa_pub = NULL;
++			sp->opdata_dsa_pub_num = NULL;
++			sp->opdata_dsa_priv = NULL;
++			sp->opdata_dsa_priv_num = NULL;
++			break;
++#endif	/* OPENSSL_NO_DSA */
++#ifndef OPENSSL_NO_DH
++		case OP_DH:
++			sp->opdata_dh_key = CK_INVALID_HANDLE;
++			sp->opdata_dh = NULL;
++			sp->opdata_dh_priv_num = NULL;
++			break;
++#endif	/* OPENSSL_NO_DH */
++		case OP_CIPHER:
++			sp->opdata_cipher_key = CK_INVALID_HANDLE;
++			sp->opdata_encrypt = -1;
++			break;
++		default:
++			break;
++		}
++
++	/*
++	 * We always initialize the session as containing a non-persistent
++	 * object. The key load functions set it to persistent if that is so.
++	 */
++	sp->pub_persistent = CK_FALSE;
++	sp->priv_persistent = CK_FALSE;
++	return (1);
++	}
++
++#ifndef OPENSSL_NO_RSA
++/* Destroy RSA public key from single session. */
++int
++pk11_destroy_rsa_object_pub(PK11_SESSION *sp, CK_BBOOL uselock)
++	{
++	int ret = 0;
++
++	if (sp->opdata_rsa_pub_key != CK_INVALID_HANDLE)
++		{
++		TRY_OBJ_DESTROY(sp, sp->opdata_rsa_pub_key,
++		    ret, uselock, OP_RSA, CK_FALSE);
++		sp->opdata_rsa_pub_key = CK_INVALID_HANDLE;
++		sp->opdata_rsa_pub = NULL;
++		if (sp->opdata_rsa_n_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_n_num);
++			sp->opdata_rsa_n_num = NULL;
++			}
++		if (sp->opdata_rsa_e_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_e_num);
++			sp->opdata_rsa_e_num = NULL;
++			}
++		}
++
++	return (ret);
++	}
++
++/* Destroy RSA private key from single session. */
++int
++pk11_destroy_rsa_object_priv(PK11_SESSION *sp, CK_BBOOL uselock)
++	{
++	int ret = 0;
++
++	if (sp->opdata_rsa_priv_key != CK_INVALID_HANDLE)
++		{
++		TRY_OBJ_DESTROY(sp, sp->opdata_rsa_priv_key,
++		    ret, uselock, OP_RSA, CK_TRUE);
++		sp->opdata_rsa_priv_key = CK_INVALID_HANDLE;
++		sp->opdata_rsa_priv = NULL;
++		if (sp->opdata_rsa_d_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_d_num);
++			sp->opdata_rsa_d_num = NULL;
++			}
++
++		/*
++		 * For the RSA key by reference code, public components 'n'/'e'
++		 * are the key components we use to check for the cache hit. We
++		 * must free those as well.
++		 */
++		if (sp->opdata_rsa_pn_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_pn_num);
++			sp->opdata_rsa_pn_num = NULL;
++			}
++		if (sp->opdata_rsa_pe_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_pe_num);
++			sp->opdata_rsa_pe_num = NULL;
++			}
++		}
++
++	return (ret);
++	}
++
++/*
++ * Destroy RSA key object wrapper. If session is NULL, try to destroy all
++ * objects in the free list.
++ */
++int
++pk11_destroy_rsa_key_objects(PK11_SESSION *session)
++	{
++	int ret = 1;
++	PK11_SESSION *sp = NULL;
++	PK11_SESSION *local_free_session;
++	CK_BBOOL uselock = TRUE;
++
++	if (session != NULL)
++		local_free_session = session;
++	else
++		{
++#ifndef NOPTHREADS
++		(void) pthread_mutex_lock(session_cache[OP_RSA].lock);
++#else
++		CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		local_free_session = session_cache[OP_RSA].head;
++		uselock = FALSE;
++		}
++
++	/*
++	 * go through the list of sessions and delete key objects
++	 */
++	while ((sp = local_free_session) != NULL)
++		{
++		local_free_session = sp->next;
++
++		/*
++		 * Do not terminate list traversal if one of the
++		 * destroy operations fails.
++		 */
++		if (pk11_destroy_rsa_object_pub(sp, uselock) == 0)
++			{
++			ret = 0;
++			continue;
++			}
++		if (pk11_destroy_rsa_object_priv(sp, uselock) == 0)
++			{
++			ret = 0;
++			continue;
++			}
++		}
++
++#ifndef NOPTHREADS
++	if (session == NULL)
++		(void) pthread_mutex_unlock(session_cache[OP_RSA].lock);
++#else
++	if (session == NULL)
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++
++	return (ret);
++	}
++#endif	/* OPENSSL_NO_RSA */
++
++#ifndef OPENSSL_NO_DSA
++/* Destroy DSA public key from single session. */
++int
++pk11_destroy_dsa_object_pub(PK11_SESSION *sp, CK_BBOOL uselock)
++	{
++	int ret = 0;
++
++	if (sp->opdata_dsa_pub_key != CK_INVALID_HANDLE)
++		{
++		TRY_OBJ_DESTROY(sp, sp->opdata_dsa_pub_key,
++		    ret, uselock, OP_DSA, CK_FALSE);
++		sp->opdata_dsa_pub_key = CK_INVALID_HANDLE;
++		sp->opdata_dsa_pub = NULL;
++		if (sp->opdata_dsa_pub_num != NULL)
++			{
++			BN_free(sp->opdata_dsa_pub_num);
++			sp->opdata_dsa_pub_num = NULL;
++			}
++		}
++
++	return (ret);
++	}
++
++/* Destroy DSA private key from single session. */
++int
++pk11_destroy_dsa_object_priv(PK11_SESSION *sp, CK_BBOOL uselock)
++	{
++	int ret = 0;
++
++	if (sp->opdata_dsa_priv_key != CK_INVALID_HANDLE)
++		{
++		TRY_OBJ_DESTROY(sp, sp->opdata_dsa_priv_key,
++		    ret, uselock, OP_DSA, CK_TRUE);
++		sp->opdata_dsa_priv_key = CK_INVALID_HANDLE;
++		sp->opdata_dsa_priv = NULL;
++		if (sp->opdata_dsa_priv_num != NULL)
++			{
++			BN_free(sp->opdata_dsa_priv_num);
++			sp->opdata_dsa_priv_num = NULL;
++			}
++		}
++
++	return (ret);
++	}
++
++/*
++ * Destroy DSA key object wrapper. If session is NULL, try to destroy all
++ * objects in the free list.
++ */
++int
++pk11_destroy_dsa_key_objects(PK11_SESSION *session)
++	{
++	int ret = 1;
++	PK11_SESSION *sp = NULL;
++	PK11_SESSION *local_free_session;
++	CK_BBOOL uselock = TRUE;
++
++	if (session != NULL)
++		local_free_session = session;
++	else
++		{
++#ifndef NOPTHREADS
++		(void) pthread_mutex_lock(session_cache[OP_DSA].lock);
++#else
++		CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		local_free_session = session_cache[OP_DSA].head;
++		uselock = FALSE;
++		}
++
++	/*
++	 * go through the list of sessions and delete key objects
++	 */
++	while ((sp = local_free_session) != NULL)
++		{
++		local_free_session = sp->next;
++
++		/*
++		 * Do not terminate list traversal if one of the
++		 * destroy operations fails.
++		 */
++		if (pk11_destroy_dsa_object_pub(sp, uselock) == 0)
++			{
++			ret = 0;
++			continue;
++			}
++		if (pk11_destroy_dsa_object_priv(sp, uselock) == 0)
++			{
++			ret = 0;
++			continue;
++			}
++		}
++
++#ifndef NOPTHREADS
++	if (session == NULL)
++		(void) pthread_mutex_unlock(session_cache[OP_DSA].lock);
++#else
++	if (session == NULL)
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++
++	return (ret);
++	}
++#endif	/* OPENSSL_NO_DSA */
++
++#ifndef OPENSSL_NO_DH
++/* Destroy DH key from single session. */
++int
++pk11_destroy_dh_object(PK11_SESSION *sp, CK_BBOOL uselock)
++	{
++	int ret = 0;
++
++	if (sp->opdata_dh_key != CK_INVALID_HANDLE)
++		{
++		TRY_OBJ_DESTROY(sp, sp->opdata_dh_key,
++		    ret, uselock, OP_DH, CK_TRUE);
++		sp->opdata_dh_key = CK_INVALID_HANDLE;
++		sp->opdata_dh = NULL;
++		if (sp->opdata_dh_priv_num != NULL)
++			{
++			BN_free(sp->opdata_dh_priv_num);
++			sp->opdata_dh_priv_num = NULL;
++			}
++		}
++
++	return (ret);
++	}
++
++/*
++ * Destroy DH key object wrapper.
++ *
++ * arg0: pointer to PKCS#11 engine session structure
++ *       if session is NULL, try to destroy all objects in the free list
++ */
++int
++pk11_destroy_dh_key_objects(PK11_SESSION *session)
++	{
++	int ret = 1;
++	PK11_SESSION *sp = NULL;
++	PK11_SESSION *local_free_session;
++	CK_BBOOL uselock = TRUE;
++
++	if (session != NULL)
++		local_free_session = session;
++	else
++		{
++#ifndef NOPTHREADS
++		(void) pthread_mutex_lock(session_cache[OP_DH].lock);
++#else
++		CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		local_free_session = session_cache[OP_DH].head;
++		uselock = FALSE;
++		}
++
++	while ((sp = local_free_session) != NULL)
++		{
++		local_free_session = sp->next;
++
++		/*
++		 * Do not terminate list traversal if one of the
++		 * destroy operations fails.
++		 */
++		if (pk11_destroy_dh_object(sp, uselock) == 0)
++			{
++			ret = 0;
++			continue;
++			}
++		}
++
++#ifndef NOPTHREADS
++	if (session == NULL)
++		(void) pthread_mutex_unlock(session_cache[OP_DH].lock);
++#else
++	if (session == NULL)
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++
++	return (ret);
++	}
++#endif	/* OPENSSL_NO_DH */
++
++static int
++pk11_destroy_object(CK_SESSION_HANDLE session, CK_OBJECT_HANDLE oh,
++	CK_BBOOL persistent)
++	{
++	CK_RV rv;
++
++	/*
++	 * We never try to destroy persistent objects which are the objects
++	 * stored in the keystore. Also, we always use read-only sessions so
++	 * C_DestroyObject() would be returning CKR_SESSION_READ_ONLY here.
++	 */
++	if (persistent == CK_TRUE)
++		return (1);
++
++	rv = pFuncList->C_DestroyObject(session, oh);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DESTROY_OBJECT, PK11_R_DESTROYOBJECT,
++		    rv);
++		return (0);
++		}
++
++	return (1);
++	}
++
++
++/* Symmetric ciphers and digests support functions */
++
++static int
++cipher_nid_to_pk11(int nid)
++	{
++	int i;
++
++	for (i = 0; i < PK11_CIPHER_MAX; i++)
++		if (ciphers[i].nid == nid)
++			return (ciphers[i].id);
++	return (-1);
++	}
++
++static int
++pk11_usable_ciphers(const int **nids)
++	{
++	if (cipher_count > 0)
++		*nids = cipher_nids;
++	else
++		*nids = NULL;
++	return (cipher_count);
++	}
++
++static int
++pk11_usable_digests(const int **nids)
++	{
++	if (digest_count > 0)
++		*nids = digest_nids;
++	else
++		*nids = NULL;
++	return (digest_count);
++	}
++
++/*
++ * Init context for encryption or decryption using a symmetric key.
++ */
++static int pk11_init_symmetric(EVP_CIPHER_CTX *ctx, PK11_CIPHER *pcipher,
++	PK11_SESSION *sp, CK_MECHANISM_PTR pmech)
++	{
++	CK_RV rv;
++#ifdef	SOLARIS_AES_CTR
++	CK_AES_CTR_PARAMS ctr_params;
++#endif	/* SOLARIS_AES_CTR */
++
++	/*
++	 * We expect pmech->mechanism to be already set and
++	 * pParameter/ulParameterLen initialized to NULL/0 before
++	 * pk11_init_symetric() is called.
++	 */
++	OPENSSL_assert(pmech->mechanism != 0);
++	OPENSSL_assert(pmech->pParameter == NULL);
++	OPENSSL_assert(pmech->ulParameterLen == 0);
++
++#ifdef	SOLARIS_AES_CTR
++	if (ctx->cipher->nid == NID_aes_128_ctr ||
++	    ctx->cipher->nid == NID_aes_192_ctr ||
++	    ctx->cipher->nid == NID_aes_256_ctr)
++		{
++		pmech->pParameter = (void *)(&ctr_params);
++		pmech->ulParameterLen = sizeof (ctr_params);
++		/*
++		 * For now, we are limited to the fixed length of the counter,
++		 * it covers the whole counter block. That's what RFC 4344
++		 * needs. For more information on internal structure of the
++		 * counter block, see RFC 3686. If needed in the future, we can
++		 * add code so that the counter length can be set via
++		 * ENGINE_ctrl() function.
++		 */
++		ctr_params.ulCounterBits = AES_BLOCK_SIZE * 8;
++		OPENSSL_assert(pcipher->iv_len == AES_BLOCK_SIZE);
++		(void) memcpy(ctr_params.cb, ctx->iv, AES_BLOCK_SIZE);
++		}
++	else
++#endif	/* SOLARIS_AES_CTR */
++		{
++		if (pcipher->iv_len > 0)
++			{
++			pmech->pParameter = (void *)ctx->iv;
++			pmech->ulParameterLen = pcipher->iv_len;
++			}
++		}
++
++	/* if we get here, the encryption needs to be reinitialized */
++	if (ctx->encrypt)
++		rv = pFuncList->C_EncryptInit(sp->session, pmech,
++			sp->opdata_cipher_key);
++	else
++		rv = pFuncList->C_DecryptInit(sp->session, pmech,
++			sp->opdata_cipher_key);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_CIPHER_INIT, ctx->encrypt ?
++		    PK11_R_ENCRYPTINIT : PK11_R_DECRYPTINIT, rv);
++		pk11_return_session(sp, OP_CIPHER);
++		return (0);
++		}
++
++	return (1);
++	}
++
++/* ARGSUSED */
++static int
++pk11_cipher_init(EVP_CIPHER_CTX *ctx, const unsigned char *key,
++    const unsigned char *iv, int enc)
++	{
++	CK_MECHANISM mech;
++	int index;
++	PK11_CIPHER_STATE *state = (PK11_CIPHER_STATE *) ctx->cipher_data;
++	PK11_SESSION *sp;
++	PK11_CIPHER *p_ciph_table_row;
++
++	state->sp = NULL;
++
++	index = cipher_nid_to_pk11(ctx->cipher->nid);
++	if (index < 0 || index >= PK11_CIPHER_MAX)
++		return (0);
++
++	p_ciph_table_row = &ciphers[index];
++	/*
++	 * iv_len in the ctx->cipher structure is the maximum IV length for the
++	 * current cipher and it must be less or equal to the IV length in our
++	 * ciphers table. The key length must be in the allowed interval. From
++	 * all cipher modes that the PKCS#11 engine supports only RC4 allows a
++	 * key length to be in some range, all other NIDs have a precise key
++	 * length. Every application can define its own EVP functions so this
++	 * code serves as a sanity check.
++	 *
++	 * Note that the reason why the IV length in ctx->cipher might be
++	 * greater than the actual length is that OpenSSL uses BLOCK_CIPHER_defs
++	 * macro to define functions that return EVP structures for all DES
++	 * modes. So, even ECB modes get 8 byte IV.
++	 */
++	if (ctx->cipher->iv_len < p_ciph_table_row->iv_len ||
++	    ctx->key_len < p_ciph_table_row->min_key_len ||
++	    ctx->key_len > p_ciph_table_row->max_key_len) {
++		PK11err(PK11_F_CIPHER_INIT, PK11_R_KEY_OR_IV_LEN_PROBLEM);
++		return (0);
++	}
++
++	if ((sp = pk11_get_session(OP_CIPHER)) == NULL)
++		return (0);
++
++	/* if applicable, the mechanism parameter is used for IV */
++	mech.mechanism = p_ciph_table_row->mech_type;
++	mech.pParameter = NULL;
++	mech.ulParameterLen = 0;
++
++	/* The key object is destroyed here if it is not the current key. */
++	(void) check_new_cipher_key(sp, key, ctx->key_len);
++
++	/*
++	 * If the key is the same and the encryption is also the same, then
++	 * just reuse it. However, we must not forget to reinitialize the
++	 * context that was finalized in pk11_cipher_cleanup().
++	 */
++	if (sp->opdata_cipher_key != CK_INVALID_HANDLE &&
++	    sp->opdata_encrypt == ctx->encrypt)
++		{
++		state->sp = sp;
++		if (pk11_init_symmetric(ctx, p_ciph_table_row, sp, &mech) == 0)
++			return (0);
++
++		return (1);
++		}
++
++	/*
++	 * Check if the key has been invalidated. If so, a new key object
++	 * needs to be created.
++	 */
++	if (sp->opdata_cipher_key == CK_INVALID_HANDLE)
++		{
++		sp->opdata_cipher_key = pk11_get_cipher_key(
++			ctx, key, p_ciph_table_row->key_type, sp);
++		}
++
++	if (sp->opdata_encrypt != ctx->encrypt && sp->opdata_encrypt != -1)
++		{
++		/*
++		 * The previous encryption/decryption is different. Need to
++		 * terminate the previous * active encryption/decryption here.
++		 */
++		if (!pk11_cipher_final(sp))
++			{
++			pk11_return_session(sp, OP_CIPHER);
++			return (0);
++			}
++		}
++
++	if (sp->opdata_cipher_key == CK_INVALID_HANDLE)
++		{
++		pk11_return_session(sp, OP_CIPHER);
++		return (0);
++		}
++
++	/* now initialize the context with a new key */
++	if (pk11_init_symmetric(ctx, p_ciph_table_row, sp, &mech) == 0)
++		return (0);
++
++	sp->opdata_encrypt = ctx->encrypt;
++	state->sp = sp;
++
++	return (1);
++	}
++
++/*
++ * When reusing the same key in an encryption/decryption session for a
++ * decryption/encryption session, we need to close the active session
++ * and recreate a new one. Note that the key is in the global session so
++ * that it needs not be recreated.
++ *
++ * It is more appropriate to use C_En/DecryptFinish here. At the time of this
++ * development, these two functions in the PKCS#11 libraries used return
++ * unexpected errors when passing in 0 length output. It may be a good
++ * idea to try them again if performance is a problem here and fix
++ * C_En/DecryptFinial if there are bugs there causing the problem.
++ */
++static int
++pk11_cipher_final(PK11_SESSION *sp)
++	{
++	CK_RV rv;
++
++	rv = pFuncList->C_CloseSession(sp->session);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_CIPHER_FINAL, PK11_R_CLOSESESSION, rv);
++		return (0);
++		}
++
++	rv = pFuncList->C_OpenSession(SLOTID, CKF_SERIAL_SESSION,
++		NULL_PTR, NULL_PTR, &sp->session);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_CIPHER_FINAL, PK11_R_OPENSESSION, rv);
++		return (0);
++		}
++
++	return (1);
++	}
++
++/*
++ * An engine interface function. The calling function allocates sufficient
++ * memory for the output buffer "out" to hold the results.
++ */
++#if OPENSSL_VERSION_NUMBER < 0x10000000L
++static int
++pk11_cipher_do_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
++	const unsigned char *in, unsigned int inl)
++#else
++static int
++pk11_cipher_do_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
++	const unsigned char *in, size_t inl)
++#endif
++	{
++	PK11_CIPHER_STATE *state = (PK11_CIPHER_STATE *) ctx->cipher_data;
++	PK11_SESSION *sp;
++	CK_RV rv;
++	unsigned long outl = inl;
++
++	if (state == NULL || state->sp == NULL)
++		return (0);
++
++	sp = (PK11_SESSION *) state->sp;
++
++	if (!inl)
++		return (1);
++
++	/* RC4 is the only stream cipher we support */
++	if (ctx->cipher->nid != NID_rc4 && (inl % ctx->cipher->block_size) != 0)
++		return (0);
++
++	if (ctx->encrypt)
++		{
++		rv = pFuncList->C_EncryptUpdate(sp->session,
++			(unsigned char *)in, inl, out, &outl);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_CIPHER_DO_CIPHER,
++			    PK11_R_ENCRYPTUPDATE, rv);
++			return (0);
++			}
++		}
++	else
++		{
++		rv = pFuncList->C_DecryptUpdate(sp->session,
++			(unsigned char *)in, inl, out, &outl);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_CIPHER_DO_CIPHER,
++			    PK11_R_DECRYPTUPDATE, rv);
++			return (0);
++			}
++		}
++
++	/*
++	 * For DES_CBC, DES3_CBC, AES_CBC, and RC4, the output size is always
++	 * the same size of input.
++	 * The application has guaranteed to call the block ciphers with
++	 * correctly aligned buffers.
++	 */
++	if (inl != outl)
++		return (0);
++
++	return (1);
++	}
++
++/*
++ * Return the session to the pool. Calling C_EncryptFinal() and C_DecryptFinal()
++ * here is the right thing because in EVP_DecryptFinal_ex(), engine's
++ * do_cipher() is not even called, and in EVP_EncryptFinal_ex() it is called but
++ * the engine can't find out that it's the finalizing call. We wouldn't
++ * necessarily have to finalize the context here since reinitializing it with
++ * C_(Encrypt|Decrypt)Init() should be fine but for the sake of correctness,
++ * let's do it. Some implementations might leak memory if the previously used
++ * context is initialized without finalizing it first.
++ */
++static int
++pk11_cipher_cleanup(EVP_CIPHER_CTX *ctx)
++	{
++	CK_RV rv;
++	CK_ULONG len = EVP_MAX_BLOCK_LENGTH;
++	CK_BYTE buf[EVP_MAX_BLOCK_LENGTH];
++	PK11_CIPHER_STATE *state = ctx->cipher_data;
++
++	if (state != NULL && state->sp != NULL)
++		{
++		/*
++		 * We are not interested in the data here, we just need to get
++		 * rid of the context.
++		 */
++		if (ctx->encrypt)
++			rv = pFuncList->C_EncryptFinal(
++			    state->sp->session, buf, &len);
++		else
++			rv = pFuncList->C_DecryptFinal(
++			    state->sp->session, buf, &len);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_CIPHER_CLEANUP, ctx->encrypt ?
++			    PK11_R_ENCRYPTFINAL : PK11_R_DECRYPTFINAL, rv);
++			pk11_return_session(state->sp, OP_CIPHER);
++			return (0);
++			}
++
++		pk11_return_session(state->sp, OP_CIPHER);
++		state->sp = NULL;
++		}
++
++	return (1);
++	}
++
++/*
++ * Registered by the ENGINE when used to find out how to deal with
++ * a particular NID in the ENGINE. This says what we'll do at the
++ * top level - note, that list is restricted by what we answer with
++ */
++/* ARGSUSED */
++static int
++pk11_engine_ciphers(ENGINE *e, const EVP_CIPHER **cipher,
++	const int **nids, int nid)
++	{
++	if (!cipher)
++		return (pk11_usable_ciphers(nids));
++
++	switch (nid)
++		{
++		case NID_des_ede3_cbc:
++			*cipher = &pk11_3des_cbc;
++			break;
++		case NID_des_cbc:
++			*cipher = &pk11_des_cbc;
++			break;
++		case NID_des_ede3_ecb:
++			*cipher = &pk11_3des_ecb;
++			break;
++		case NID_des_ecb:
++			*cipher = &pk11_des_ecb;
++			break;
++		case NID_aes_128_cbc:
++			*cipher = &pk11_aes_128_cbc;
++			break;
++		case NID_aes_192_cbc:
++			*cipher = &pk11_aes_192_cbc;
++			break;
++		case NID_aes_256_cbc:
++			*cipher = &pk11_aes_256_cbc;
++			break;
++		case NID_aes_128_ecb:
++			*cipher = &pk11_aes_128_ecb;
++			break;
++		case NID_aes_192_ecb:
++			*cipher = &pk11_aes_192_ecb;
++			break;
++		case NID_aes_256_ecb:
++			*cipher = &pk11_aes_256_ecb;
++			break;
++		case NID_bf_cbc:
++			*cipher = &pk11_bf_cbc;
++			break;
++		case NID_rc4:
++			*cipher = &pk11_rc4;
++			break;
++		default:
++#ifdef	SOLARIS_AES_CTR
++			/*
++			 * These can't be in separated cases because the NIDs
++			 * here are not constants.
++			 */
++			if (nid == NID_aes_128_ctr)
++				*cipher = &pk11_aes_128_ctr;
++			else if (nid == NID_aes_192_ctr)
++				*cipher = &pk11_aes_192_ctr;
++			else if (nid == NID_aes_256_ctr)
++				*cipher = &pk11_aes_256_ctr;
++			else
++#endif	/* SOLARIS_AES_CTR */
++			*cipher = NULL;
++			break;
++		}
++	return (*cipher != NULL);
++	}
++
++/* ARGSUSED */
++static int
++pk11_engine_digests(ENGINE *e, const EVP_MD **digest,
++	const int **nids, int nid)
++	{
++	if (!digest)
++		return (pk11_usable_digests(nids));
++
++	switch (nid)
++		{
++		case NID_md5:
++			*digest = &pk11_md5;
++			break;
++		case NID_sha1:
++			*digest = &pk11_sha1;
++			break;
++		case NID_sha224:
++			*digest = &pk11_sha224;
++			break;
++		case NID_sha256:
++			*digest = &pk11_sha256;
++			break;
++		case NID_sha384:
++			*digest = &pk11_sha384;
++			break;
++		case NID_sha512:
++			*digest = &pk11_sha512;
++			break;
++		default:
++			*digest = NULL;
++			break;
++		}
++	return (*digest != NULL);
++	}
++
++
++/* Create a secret key object in a PKCS#11 session */
++static CK_OBJECT_HANDLE pk11_get_cipher_key(EVP_CIPHER_CTX *ctx,
++	const unsigned char *key, CK_KEY_TYPE key_type, PK11_SESSION *sp)
++	{
++	CK_RV rv;
++	CK_OBJECT_HANDLE h_key = CK_INVALID_HANDLE;
++	CK_OBJECT_CLASS obj_key = CKO_SECRET_KEY;
++	CK_ULONG ul_key_attr_count = 6;
++
++	CK_ATTRIBUTE  a_key_template[] =
++		{
++		{CKA_CLASS, (void*) NULL, sizeof (CK_OBJECT_CLASS)},
++		{CKA_KEY_TYPE, (void*) NULL, sizeof (CK_KEY_TYPE)},
++		{CKA_TOKEN, &false, sizeof (false)},
++		{CKA_ENCRYPT, &true, sizeof (true)},
++		{CKA_DECRYPT, &true, sizeof (true)},
++		{CKA_VALUE, (void*) NULL, 0},
++		};
++
++	/*
++	 * Create secret key object in global_session. All other sessions
++	 * can use the key handles. Here is why:
++	 * OpenSSL will call EncryptInit and EncryptUpdate using a secret key.
++	 * It may then call DecryptInit and DecryptUpdate using the same key.
++	 * To use the same key object, we need to call EncryptFinal with
++	 * a 0 length message. Currently, this does not work for 3DES
++	 * mechanism. To get around this problem, we close the session and
++	 * then create a new session to use the same key object. When a session
++	 * is closed, all the object handles will be invalid. Thus, create key
++	 * objects in a global session, an individual session may be closed to
++	 * terminate the active operation.
++	 */
++	CK_SESSION_HANDLE session = global_session;
++	a_key_template[0].pValue = &obj_key;
++	a_key_template[1].pValue = &key_type;
++	a_key_template[5].pValue = (void *) key;
++	a_key_template[5].ulValueLen = (unsigned long) ctx->key_len;
++
++	rv = pFuncList->C_CreateObject(session,
++		a_key_template, ul_key_attr_count, &h_key);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_CIPHER_KEY, PK11_R_CREATEOBJECT,
++		    rv);
++		goto err;
++		}
++
++	/*
++	 * Save the key information used in this session.
++	 * The max can be saved is PK11_KEY_LEN_MAX.
++	 */
++	sp->opdata_key_len = ctx->key_len > PK11_KEY_LEN_MAX ?
++		PK11_KEY_LEN_MAX : ctx->key_len;
++	(void) memcpy(sp->opdata_key, key, sp->opdata_key_len);
++err:
++
++	return (h_key);
++	}
++
++static int
++md_nid_to_pk11(int nid)
++	{
++	int i;
++
++	for (i = 0; i < PK11_DIGEST_MAX; i++)
++		if (digests[i].nid == nid)
++			return (digests[i].id);
++	return (-1);
++	}
++
++static int
++pk11_digest_init(EVP_MD_CTX *ctx)
++	{
++	CK_RV rv;
++	CK_MECHANISM mech;
++	int index;
++	PK11_SESSION *sp;
++	PK11_DIGEST *pdp;
++	PK11_CIPHER_STATE *state = (PK11_CIPHER_STATE *) ctx->md_data;
++
++	state->sp = NULL;
++
++	index = md_nid_to_pk11(ctx->digest->type);
++	if (index < 0 || index >= PK11_DIGEST_MAX)
++		return (0);
++
++	pdp = &digests[index];
++	if ((sp = pk11_get_session(OP_DIGEST)) == NULL)
++		return (0);
++
++	/* at present, no parameter is needed for supported digests */
++	mech.mechanism = pdp->mech_type;
++	mech.pParameter = NULL;
++	mech.ulParameterLen = 0;
++
++	rv = pFuncList->C_DigestInit(sp->session, &mech);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DIGEST_INIT, PK11_R_DIGESTINIT, rv);
++		pk11_return_session(sp, OP_DIGEST);
++		return (0);
++		}
++
++	state->sp = sp;
++
++	return (1);
++	}
++
++static int
++pk11_digest_update(EVP_MD_CTX *ctx, const void *data, size_t count)
++	{
++	CK_RV rv;
++	PK11_CIPHER_STATE *state = (PK11_CIPHER_STATE *) ctx->md_data;
++
++	/* 0 length message will cause a failure in C_DigestFinal */
++	if (count == 0)
++		return (1);
++
++	if (state == NULL || state->sp == NULL)
++		return (0);
++
++	rv = pFuncList->C_DigestUpdate(state->sp->session, (CK_BYTE *) data,
++		count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DIGEST_UPDATE, PK11_R_DIGESTUPDATE, rv);
++		pk11_return_session(state->sp, OP_DIGEST);
++		state->sp = NULL;
++		return (0);
++		}
++
++	return (1);
++	}
++
++static int
++pk11_digest_final(EVP_MD_CTX *ctx, unsigned char *md)
++	{
++	CK_RV rv;
++	unsigned long len;
++	PK11_CIPHER_STATE *state = (PK11_CIPHER_STATE *) ctx->md_data;
++	len = ctx->digest->md_size;
++
++	if (state == NULL || state->sp == NULL)
++		return (0);
++
++	rv = pFuncList->C_DigestFinal(state->sp->session, md, &len);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DIGEST_FINAL, PK11_R_DIGESTFINAL, rv);
++		pk11_return_session(state->sp, OP_DIGEST);
++		state->sp = NULL;
++		return (0);
++		}
++
++	if (ctx->digest->md_size != len)
++		return (0);
++
++	/*
++	 * Final is called and digest is returned, so return the session
++	 * to the pool
++	 */
++	pk11_return_session(state->sp, OP_DIGEST);
++	state->sp = NULL;
++
++	return (1);
++	}
++
++static int
++pk11_digest_copy(EVP_MD_CTX *to, const EVP_MD_CTX *from)
++	{
++	CK_RV rv;
++	int ret = 0;
++	PK11_CIPHER_STATE *state, *state_to;
++	CK_BYTE_PTR pstate = NULL;
++	CK_ULONG ul_state_len;
++
++	/* The copy-from state */
++	state = (PK11_CIPHER_STATE *) from->md_data;
++	if (state == NULL || state->sp == NULL)
++		goto err;
++
++	/* Initialize the copy-to state */
++	if (!pk11_digest_init(to))
++		goto err;
++	state_to = (PK11_CIPHER_STATE *) to->md_data;
++
++	/* Get the size of the operation state of the copy-from session */
++	rv = pFuncList->C_GetOperationState(state->sp->session, NULL,
++		&ul_state_len);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DIGEST_COPY, PK11_R_GET_OPERATION_STATE,
++		    rv);
++		goto err;
++		}
++	if (ul_state_len == 0)
++		{
++		goto err;
++		}
++
++	pstate = OPENSSL_malloc(ul_state_len);
++	if (pstate == NULL)
++		{
++		PK11err(PK11_F_DIGEST_COPY, PK11_R_MALLOC_FAILURE);
++		goto err;
++		}
++
++	/* Get the operation state of the copy-from session */
++	rv = pFuncList->C_GetOperationState(state->sp->session, pstate,
++		&ul_state_len);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DIGEST_COPY, PK11_R_GET_OPERATION_STATE,
++		    rv);
++		goto err;
++		}
++
++	/* Set the operation state of the copy-to session */
++	rv = pFuncList->C_SetOperationState(state_to->sp->session, pstate,
++		ul_state_len, 0, 0);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DIGEST_COPY,
++		    PK11_R_SET_OPERATION_STATE, rv);
++		goto err;
++		}
++
++	ret = 1;
++err:
++	if (pstate != NULL)
++		OPENSSL_free(pstate);
++
++	return (ret);
++	}
++
++/* Return any pending session state to the pool */
++static int
++pk11_digest_cleanup(EVP_MD_CTX *ctx)
++	{
++	PK11_CIPHER_STATE *state = ctx->md_data;
++	unsigned char buf[EVP_MAX_MD_SIZE];
++
++	if (state != NULL && state->sp != NULL)
++		{
++		/*
++		 * If state->sp is not NULL then pk11_digest_final() has not
++		 * been called yet. We must call it now to free any memory
++		 * that might have been allocated in the token when
++		 * pk11_digest_init() was called. pk11_digest_final()
++		 * will return the session to the cache.
++		 */
++		if (!pk11_digest_final(ctx, buf))
++			return (0);
++		}
++
++	return (1);
++	}
++
++/*
++ * Check if the new key is the same as the key object in the session. If the key
++ * is the same, no need to create a new key object. Otherwise, the old key
++ * object needs to be destroyed and a new one will be created. Return 1 for
++ * cache hit, 0 for cache miss. Note that we must check the key length first
++ * otherwise we could end up reusing a different, longer key with the same
++ * prefix.
++ */
++static int check_new_cipher_key(PK11_SESSION *sp, const unsigned char *key,
++	int key_len)
++	{
++	if (sp->opdata_key_len != key_len ||
++	    memcmp(sp->opdata_key, key, key_len) != 0)
++		{
++		(void) pk11_destroy_cipher_key_objects(sp);
++		return (0);
++		}
++	return (1);
++	}
++
++/* Destroy one or more secret key objects. */
++static int pk11_destroy_cipher_key_objects(PK11_SESSION *session)
++	{
++	int ret = 0;
++	PK11_SESSION *sp = NULL;
++	PK11_SESSION *local_free_session;
++
++	if (session != NULL)
++		local_free_session = session;
++	else
++		{
++#ifndef NOPTHREADS
++		(void) pthread_mutex_lock(session_cache[OP_CIPHER].lock);
++#else
++		CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		local_free_session = session_cache[OP_CIPHER].head;
++		}
++
++	while ((sp = local_free_session) != NULL)
++		{
++		local_free_session = sp->next;
++
++		if (sp->opdata_cipher_key != CK_INVALID_HANDLE)
++			{
++			/*
++			 * The secret key object is created in the
++			 * global_session. See pk11_get_cipher_key().
++			 */
++			if (pk11_destroy_object(global_session,
++				sp->opdata_cipher_key, CK_FALSE) == 0)
++				goto err;
++			sp->opdata_cipher_key = CK_INVALID_HANDLE;
++			}
++		}
++	ret = 1;
++err:
++
++#ifndef NOPTHREADS
++	if (session == NULL)
++		(void) pthread_mutex_unlock(session_cache[OP_CIPHER].lock);
++#else
++	if (session == NULL)
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++
++	return (ret);
++	}
++
++
++/*
++ * Public key mechanisms optionally supported
++ *
++ * CKM_RSA_X_509
++ * CKM_RSA_PKCS
++ * CKM_DSA
++ *
++ * The first slot that supports at least one of those mechanisms is chosen as a
++ * public key slot.
++ *
++ * Symmetric ciphers optionally supported
++ *
++ * CKM_DES3_CBC
++ * CKM_DES_CBC
++ * CKM_AES_CBC
++ * CKM_DES3_ECB
++ * CKM_DES_ECB
++ * CKM_AES_ECB
++ * CKM_AES_CTR
++ * CKM_RC4
++ * CKM_BLOWFISH_CBC
++ *
++ * Digests optionally supported
++ *
++ * CKM_MD5
++ * CKM_SHA_1
++ * CKM_SHA224
++ * CKM_SHA256
++ * CKM_SHA384
++ * CKM_SHA512
++ *
++ * The output of this function is a set of global variables indicating which
++ * mechanisms from RSA, DSA, DH and RAND are present, and also two arrays of
++ * mechanisms, one for symmetric ciphers and one for digests. Also, 3 global
++ * variables carry information about which slot was chosen for (a) public key
++ * mechanisms, (b) random operations, and (c) symmetric ciphers and digests.
++ */
++static int
++pk11_choose_slots(int *any_slot_found)
++	{
++	CK_SLOT_ID_PTR pSlotList = NULL_PTR;
++	CK_ULONG ulSlotCount = 0;
++	CK_MECHANISM_INFO mech_info;
++	CK_TOKEN_INFO token_info;
++	unsigned int i;
++	CK_RV rv;
++	CK_SLOT_ID best_slot_sofar = 0;
++	CK_BBOOL found_candidate_slot = CK_FALSE;
++	int slot_n_cipher = 0;
++	int slot_n_digest = 0;
++	CK_SLOT_ID current_slot = 0;
++	int current_slot_n_cipher = 0;
++	int current_slot_n_digest = 0;
++
++	int local_cipher_nids[PK11_CIPHER_MAX];
++	int local_digest_nids[PK11_DIGEST_MAX];
++
++	/* let's initialize the output parameter */
++	if (any_slot_found != NULL)
++		*any_slot_found = 0;
++
++	/* Get slot list for memory allocation */
++	rv = pFuncList->C_GetSlotList(CK_FALSE, NULL_PTR, &ulSlotCount);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_CHOOSE_SLOT, PK11_R_GETSLOTLIST, rv);
++		return (0);
++		}
++
++	/* it's not an error if we didn't find any providers */
++	if (ulSlotCount == 0)
++		{
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, "%s: no crypto providers found\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++		return (1);
++		}
++
++	pSlotList = OPENSSL_malloc(ulSlotCount * sizeof (CK_SLOT_ID));
++
++	if (pSlotList == NULL)
++		{
++		PK11err(PK11_F_CHOOSE_SLOT, PK11_R_MALLOC_FAILURE);
++		return (0);
++		}
++
++	/* Get the slot list for processing */
++	rv = pFuncList->C_GetSlotList(CK_FALSE, pSlotList, &ulSlotCount);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_CHOOSE_SLOT, PK11_R_GETSLOTLIST, rv);
++		OPENSSL_free(pSlotList);
++		return (0);
++		}
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: provider: %s\n", PK11_DBG, def_PK11_LIBNAME);
++	fprintf(stderr, "%s: number of slots: %d\n", PK11_DBG, ulSlotCount);
++
++	fprintf(stderr, "%s: == checking rand slots ==\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++	for (i = 0; i < ulSlotCount; i++)
++		{
++		current_slot = pSlotList[i];
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: checking slot: %d\n", PK11_DBG, i);
++#endif	/* DEBUG_SLOT_SELECTION */
++		/* Check if slot has random support. */
++		rv = pFuncList->C_GetTokenInfo(current_slot, &token_info);
++		if (rv != CKR_OK)
++			continue;
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: token label: %.32s\n", PK11_DBG, token_info.label);
++#endif	/* DEBUG_SLOT_SELECTION */
++
++		if (token_info.flags & CKF_RNG)
++			{
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: this token has CKF_RNG flag\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++			pk11_have_random = CK_TRUE;
++			rand_SLOTID = current_slot;
++			break;
++			}
++		}
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: == checking pubkey slots ==\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++
++	pubkey_SLOTID = pSlotList[0];
++	for (i = 0; i < ulSlotCount; i++)
++		{
++		CK_BBOOL slot_has_rsa = CK_FALSE;
++		CK_BBOOL slot_has_recover = CK_FALSE;
++		CK_BBOOL slot_has_dsa = CK_FALSE;
++		CK_BBOOL slot_has_dh = CK_FALSE;
++		current_slot = pSlotList[i];
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: checking slot: %d\n", PK11_DBG, i);
++#endif	/* DEBUG_SLOT_SELECTION */
++		rv = pFuncList->C_GetTokenInfo(current_slot, &token_info);
++		if (rv != CKR_OK)
++			continue;
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: token label: %.32s\n", PK11_DBG, token_info.label);
++#endif	/* DEBUG_SLOT_SELECTION */
++
++#ifndef OPENSSL_NO_RSA
++		/*
++		 * Check if this slot is capable of signing and
++		 * verifying with CKM_RSA_PKCS.
++		 */
++		rv = pFuncList->C_GetMechanismInfo(current_slot, CKM_RSA_PKCS,
++			&mech_info);
++
++		if (rv == CKR_OK && ((mech_info.flags & CKF_SIGN) &&
++				(mech_info.flags & CKF_VERIFY)))
++			{
++			/*
++			 * Check if this slot is capable of encryption,
++			 * decryption, sign, and verify with CKM_RSA_X_509.
++			 */
++			rv = pFuncList->C_GetMechanismInfo(current_slot,
++			    CKM_RSA_X_509, &mech_info);
++
++			if (rv == CKR_OK && ((mech_info.flags & CKF_SIGN) &&
++			    (mech_info.flags & CKF_VERIFY) &&
++			    (mech_info.flags & CKF_ENCRYPT) &&
++			    (mech_info.flags & CKF_DECRYPT)))
++				{
++				slot_has_rsa = CK_TRUE;
++				if (mech_info.flags & CKF_VERIFY_RECOVER)
++					{
++					slot_has_recover = CK_TRUE;
++					}
++				}
++			}
++#endif	/* OPENSSL_NO_RSA */
++
++#ifndef OPENSSL_NO_DSA
++		/*
++		 * Check if this slot is capable of signing and
++		 * verifying with CKM_DSA.
++		 */
++		rv = pFuncList->C_GetMechanismInfo(current_slot, CKM_DSA,
++			&mech_info);
++		if (rv == CKR_OK && ((mech_info.flags & CKF_SIGN) &&
++		    (mech_info.flags & CKF_VERIFY)))
++			{
++			slot_has_dsa = CK_TRUE;
++			}
++
++#endif	/* OPENSSL_NO_DSA */
++
++#ifndef OPENSSL_NO_DH
++		/*
++		 * Check if this slot is capable of DH key generataion and
++		 * derivation.
++		 */
++		rv = pFuncList->C_GetMechanismInfo(current_slot,
++		    CKM_DH_PKCS_KEY_PAIR_GEN, &mech_info);
++
++		if (rv == CKR_OK && (mech_info.flags & CKF_GENERATE_KEY_PAIR))
++			{
++			rv = pFuncList->C_GetMechanismInfo(current_slot,
++				CKM_DH_PKCS_DERIVE, &mech_info);
++			if (rv == CKR_OK && (mech_info.flags & CKF_DERIVE))
++				{
++				slot_has_dh = CK_TRUE;
++				}
++			}
++#endif	/* OPENSSL_NO_DH */
++
++		if (!found_candidate_slot &&
++		    (slot_has_rsa || slot_has_dsa || slot_has_dh))
++			{
++#ifdef	DEBUG_SLOT_SELECTION
++			fprintf(stderr,
++			    "%s: potential slot: %d\n", PK11_DBG, current_slot);
++#endif	/* DEBUG_SLOT_SELECTION */
++			best_slot_sofar = current_slot;
++			pk11_have_rsa = slot_has_rsa;
++			pk11_have_recover = slot_has_recover;
++			pk11_have_dsa = slot_has_dsa;
++			pk11_have_dh = slot_has_dh;
++			found_candidate_slot = CK_TRUE;
++			/*
++			 * Cache the flags for later use. We might
++			 * need those if RSA keys by reference feature
++			 * is used.
++			 */
++			pubkey_token_flags = token_info.flags;
++#ifdef	DEBUG_SLOT_SELECTION
++			fprintf(stderr,
++			    "%s: setting found_candidate_slot to CK_TRUE\n",
++			    PK11_DBG);
++			fprintf(stderr,
++			    "%s: best so far slot: %d\n", PK11_DBG,
++			    best_slot_sofar);
++			fprintf(stderr, "%s: pubkey flags changed to "
++			    "%lu.\n", PK11_DBG, pubkey_token_flags);
++			}
++		else
++			{
++			fprintf(stderr,
++			    "%s: no rsa/dsa/dh\n", PK11_DBG);
++			}
++#else
++			} /* if */
++#endif	/* DEBUG_SLOT_SELECTION */
++		} /* for */
++
++	if (found_candidate_slot == CK_TRUE)
++		{
++		pubkey_SLOTID = best_slot_sofar;
++		}
++
++	found_candidate_slot = CK_FALSE;
++	best_slot_sofar = 0;
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: == checking cipher/digest ==\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++
++	SLOTID = pSlotList[0];
++	for (i = 0; i < ulSlotCount; i++)
++		{
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: checking slot: %d\n", PK11_DBG, i);
++#endif	/* DEBUG_SLOT_SELECTION */
++
++		current_slot = pSlotList[i];
++		current_slot_n_cipher = 0;
++		current_slot_n_digest = 0;
++		(void) memset(local_cipher_nids, 0, sizeof (local_cipher_nids));
++		(void) memset(local_digest_nids, 0, sizeof (local_digest_nids));
++
++		pk11_find_symmetric_ciphers(pFuncList, current_slot,
++		    &current_slot_n_cipher, local_cipher_nids);
++
++		pk11_find_digests(pFuncList, current_slot,
++		    &current_slot_n_digest, local_digest_nids);
++
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, "%s: current_slot_n_cipher %d\n", PK11_DBG,
++			current_slot_n_cipher);
++		fprintf(stderr, "%s: current_slot_n_digest %d\n", PK11_DBG,
++			current_slot_n_digest);
++		fprintf(stderr, "%s: best so far cipher/digest slot: %d\n",
++			PK11_DBG, best_slot_sofar);
++#endif	/* DEBUG_SLOT_SELECTION */
++
++		/*
++		 * If the current slot supports more ciphers/digests than
++		 * the previous best one we change the current best to this one,
++		 * otherwise leave it where it is.
++		 */
++		if ((current_slot_n_cipher + current_slot_n_digest) >
++		    (slot_n_cipher + slot_n_digest))
++			{
++#ifdef	DEBUG_SLOT_SELECTION
++			fprintf(stderr,
++				"%s: changing best so far slot to %d\n",
++				PK11_DBG, current_slot);
++#endif	/* DEBUG_SLOT_SELECTION */
++			best_slot_sofar = SLOTID = current_slot;
++			cipher_count = slot_n_cipher = current_slot_n_cipher;
++			digest_count = slot_n_digest = current_slot_n_digest;
++			(void) memcpy(cipher_nids, local_cipher_nids,
++			    sizeof (local_cipher_nids));
++			(void) memcpy(digest_nids, local_digest_nids, 
++			    sizeof (local_digest_nids));
++			}
++		}
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr,
++	    "%s: chosen pubkey slot: %d\n", PK11_DBG, pubkey_SLOTID);
++	fprintf(stderr,
++	    "%s: chosen rand slot: %d\n", PK11_DBG, rand_SLOTID);
++	fprintf(stderr,
++	    "%s: chosen cipher/digest slot: %d\n", PK11_DBG, SLOTID);
++	fprintf(stderr,
++	    "%s: pk11_have_rsa %d\n", PK11_DBG, pk11_have_rsa);
++	fprintf(stderr,
++	    "%s: pk11_have_recover %d\n", PK11_DBG, pk11_have_recover);
++	fprintf(stderr,
++	    "%s: pk11_have_dsa %d\n", PK11_DBG, pk11_have_dsa);
++	fprintf(stderr,
++	    "%s: pk11_have_dh %d\n", PK11_DBG, pk11_have_dh);
++	fprintf(stderr,
++	    "%s: pk11_have_random %d\n", PK11_DBG, pk11_have_random);
++	fprintf(stderr,
++	    "%s: cipher_count %d\n", PK11_DBG, cipher_count);
++	fprintf(stderr,
++	    "%s: digest_count %d\n", PK11_DBG, digest_count);
++#endif	/* DEBUG_SLOT_SELECTION */
++
++	if (pSlotList != NULL)
++		OPENSSL_free(pSlotList);
++
++#ifdef	SOLARIS_HW_SLOT_SELECTION
++	OPENSSL_free(hw_cnids);
++	OPENSSL_free(hw_dnids);
++#endif	/* SOLARIS_HW_SLOT_SELECTION */
++
++	if (any_slot_found != NULL)
++		*any_slot_found = 1;
++	return (1);
++	}
++
++static void pk11_get_symmetric_cipher(CK_FUNCTION_LIST_PTR pflist,
++    int slot_id, CK_MECHANISM_TYPE mech, int *current_slot_n_cipher,
++    int *local_cipher_nids, int id)
++	{
++	CK_MECHANISM_INFO mech_info;
++	CK_RV rv;
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: checking mech: %x", PK11_DBG, mech);
++#endif	/* DEBUG_SLOT_SELECTION */
++	rv = pflist->C_GetMechanismInfo(slot_id, mech, &mech_info);
++
++	if (rv != CKR_OK)
++		{
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, " not found\n");
++#endif	/* DEBUG_SLOT_SELECTION */
++		return;
++		}
++
++	if ((mech_info.flags & CKF_ENCRYPT) &&
++	    (mech_info.flags & CKF_DECRYPT))
++		{
++#ifdef	SOLARIS_HW_SLOT_SELECTION
++		if (nid_in_table(ciphers[id].nid, hw_cnids))
++#endif	/* SOLARIS_HW_SLOT_SELECTION */
++			{
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, " usable\n");
++#endif	/* DEBUG_SLOT_SELECTION */
++			local_cipher_nids[(*current_slot_n_cipher)++] =
++			    ciphers[id].nid;
++			}
++#ifdef	SOLARIS_HW_SLOT_SELECTION
++#ifdef	DEBUG_SLOT_SELECTION
++		else
++			{
++		fprintf(stderr, " rejected, software implementation only\n");
++			}
++#endif	/* DEBUG_SLOT_SELECTION */
++#endif	/* SOLARIS_HW_SLOT_SELECTION */
++		}
++#ifdef	DEBUG_SLOT_SELECTION
++	else
++		{
++		fprintf(stderr, " unusable\n");
++		}
++#endif	/* DEBUG_SLOT_SELECTION */
++
++	return;
++	}
++
++static void pk11_get_digest(CK_FUNCTION_LIST_PTR pflist, int slot_id,
++    CK_MECHANISM_TYPE mech, int *current_slot_n_digest, int *local_digest_nids,
++    int id)
++	{
++	CK_MECHANISM_INFO mech_info;
++	CK_RV rv;
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: checking mech: %x", PK11_DBG, mech);
++#endif	/* DEBUG_SLOT_SELECTION */
++	rv = pflist->C_GetMechanismInfo(slot_id, mech, &mech_info);
++
++	if (rv != CKR_OK)
++		{
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, " not found\n");
++#endif	/* DEBUG_SLOT_SELECTION */
++		return;
++		}
++
++	if (mech_info.flags & CKF_DIGEST)
++		{
++#ifdef	SOLARIS_HW_SLOT_SELECTION
++		if (nid_in_table(digests[id].nid, hw_dnids))
++#endif	/* SOLARIS_HW_SLOT_SELECTION */
++			{
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, " usable\n");
++#endif	/* DEBUG_SLOT_SELECTION */
++			local_digest_nids[(*current_slot_n_digest)++] =
++			    digests[id].nid;
++			}
++#ifdef	SOLARIS_HW_SLOT_SELECTION
++#ifdef	DEBUG_SLOT_SELECTION
++		else
++			{
++		fprintf(stderr, " rejected, software implementation only\n");
++			}
++#endif	/* DEBUG_SLOT_SELECTION */
++#endif	/* SOLARIS_HW_SLOT_SELECTION */
++		}
++#ifdef	DEBUG_SLOT_SELECTION
++	else
++		{
++		fprintf(stderr, " unusable\n");
++		}
++#endif	/* DEBUG_SLOT_SELECTION */
++
++	return;
++	}
++
++#ifdef	SOLARIS_AES_CTR
++/* create a new NID when we have no OID for that mechanism */
++static int pk11_add_NID(char *sn, char *ln)
++	{
++	ASN1_OBJECT *o;
++	int nid;
++
++	if ((o = ASN1_OBJECT_create(OBJ_new_nid(1), (unsigned char *)"",
++	    1, sn, ln)) == NULL)
++		{
++		return (0);
++		}
++
++	/* will return NID_undef on error */
++	nid = OBJ_add_object(o);
++	ASN1_OBJECT_free(o);
++
++	return (nid);
++	}
++
++/*
++ * Create new NIDs for AES counter mode. OpenSSL doesn't support them now so we
++ * have to help ourselves here.
++ */
++static int pk11_add_aes_ctr_NIDs(void)
++	{
++	/* are we already set? */
++	if (NID_aes_256_ctr != NID_undef)
++		return (1);
++
++	/*
++	 * There are no official names for AES counter modes yet so we just
++	 * follow the format of those that exist.
++	 */
++	if ((NID_aes_128_ctr = pk11_add_NID("AES-128-CTR", "aes-128-ctr")) ==
++	    NID_undef)
++		goto err;
++	ciphers[PK11_AES_128_CTR].nid = pk11_aes_128_ctr.nid = NID_aes_128_ctr;
++	if ((NID_aes_192_ctr = pk11_add_NID("AES-192-CTR", "aes-192-ctr")) ==
++	    NID_undef)
++		goto err;
++	ciphers[PK11_AES_192_CTR].nid = pk11_aes_192_ctr.nid = NID_aes_192_ctr;
++	if ((NID_aes_256_ctr = pk11_add_NID("AES-256-CTR", "aes-256-ctr")) ==
++	    NID_undef)
++		goto err;
++	ciphers[PK11_AES_256_CTR].nid = pk11_aes_256_ctr.nid = NID_aes_256_ctr;
++	return (1);
++
++err:
++	PK11err(PK11_F_ADD_AES_CTR_NIDS, PK11_R_ADD_NID_FAILED);
++	return (0);
++	}
++#endif	/* SOLARIS_AES_CTR */
++
++/* Find what symmetric ciphers this slot supports. */
++static void pk11_find_symmetric_ciphers(CK_FUNCTION_LIST_PTR pflist,
++    CK_SLOT_ID current_slot, int *current_slot_n_cipher, int *local_cipher_nids)
++	{
++	int i;
++
++	for (i = 0; i < PK11_CIPHER_MAX; ++i)
++		{
++		pk11_get_symmetric_cipher(pflist, current_slot,
++		    ciphers[i].mech_type, current_slot_n_cipher,
++		    local_cipher_nids, ciphers[i].id);
++		}
++	}
++
++/* Find what digest algorithms this slot supports. */
++static void pk11_find_digests(CK_FUNCTION_LIST_PTR pflist,
++    CK_SLOT_ID current_slot, int *current_slot_n_digest, int *local_digest_nids)
++	{
++	int i;
++
++	for (i = 0; i < PK11_DIGEST_MAX; ++i)
++		{
++		pk11_get_digest(pflist, current_slot, digests[i].mech_type,
++		    current_slot_n_digest, local_digest_nids, digests[i].id);
++		}
++	}
++
++#ifdef	SOLARIS_HW_SLOT_SELECTION
++/*
++ * It would be great if we could use pkcs11_kernel directly since this library
++ * offers hardware slots only. That's the easiest way to achieve the situation
++ * where we use the hardware accelerators when present and OpenSSL native code
++ * otherwise. That presumes the fact that OpenSSL native code is faster than the
++ * code in the soft token. It's a logical assumption - Crypto Framework has some
++ * inherent overhead so going there for the software implementation of a
++ * mechanism should be logically slower in contrast to the OpenSSL native code,
++ * presuming that both implementations are of similar speed. For example, the
++ * soft token for AES is roughly three times slower than OpenSSL for 64 byte
++ * blocks and still 20% slower for 8KB blocks. So, if we want to ship products
++ * that use the PKCS#11 engine by default, we must somehow avoid that regression
++ * on machines without hardware acceleration. That's why switching to the
++ * pkcs11_kernel library seems like a very good idea.
++ *
++ * The problem is that OpenSSL built with SunStudio is roughly 2x slower for
++ * asymmetric operations (RSA/DSA/DH) than the soft token built with the same
++ * compiler. That means that if we switched to pkcs11_kernel from the libpkcs11
++ * library, we would have had a performance regression on machines without
++ * hardware acceleration for asymmetric operations for all applications that use
++ * the PKCS#11 engine. There is one such application - Apache web server since
++ * it's shipped configured to use the PKCS#11 engine by default. Having said
++ * that, we can't switch to the pkcs11_kernel library now and have to come with
++ * a solution that, on non-accelerated machines, uses the OpenSSL native code
++ * for all symmetric ciphers and digests while it uses the soft token for
++ * asymmetric operations.
++ *
++ * This is the idea: dlopen() pkcs11_kernel directly and find out what
++ * mechanisms are there. We don't care about duplications (more slots can
++ * support the same mechanism), we just want to know what mechanisms can be
++ * possibly supported in hardware on that particular machine. As said before,
++ * pkcs11_kernel will show you hardware providers only.
++ *
++ * Then, we rely on the fact that since we use libpkcs11 library we will find
++ * the metaslot. When we go through the metaslot's mechanisms for symmetric
++ * ciphers and digests, we check that any found mechanism is in the table
++ * created using the pkcs11_kernel library. So, as a result we have two arrays
++ * of mechanisms that were advertised as supported in hardware which was the
++ * goal of that whole excercise. Thus, we can use libpkcs11 but avoid soft token
++ * code for symmetric ciphers and digests. See pk11_choose_slots() for more
++ * information.
++ *
++ * This is Solaris specific code, if SOLARIS_HW_SLOT_SELECTION is not defined
++ * the code won't be used.
++ */
++#if defined(__sparcv9) || defined(__x86_64) || defined(__amd64)
++static const char pkcs11_kernel[] = "/usr/lib/security/64/pkcs11_kernel.so.1";
++#else
++static const char pkcs11_kernel[] = "/usr/lib/security/pkcs11_kernel.so.1";
++#endif
++
++/*
++ * Check hardware capabilities of the machines. The output are two lists,
++ * hw_cnids and hw_dnids, that contain hardware mechanisms found in all hardware
++ * providers together. They are not sorted and may contain duplicate mechanisms.
++ */
++static int check_hw_mechanisms(void)
++	{
++	int i;
++	CK_RV rv;
++	void *handle;
++	CK_C_GetFunctionList p;
++	CK_TOKEN_INFO token_info;
++	CK_ULONG ulSlotCount = 0;
++	int n_cipher = 0, n_digest = 0;
++	CK_FUNCTION_LIST_PTR pflist = NULL;
++	CK_SLOT_ID_PTR pSlotList = NULL_PTR;
++	int *tmp_hw_cnids = NULL, *tmp_hw_dnids = NULL;
++	int hw_ctable_size, hw_dtable_size;
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: SOLARIS_HW_SLOT_SELECTION code running\n",
++	    PK11_DBG);
++#endif
++	if ((handle = dlopen(pkcs11_kernel, RTLD_LAZY)) == NULL)
++		{
++		PK11err(PK11_F_CHECK_HW_MECHANISMS, PK11_R_DSO_FAILURE);
++		goto err;
++		}
++
++	if ((p = (CK_C_GetFunctionList)dlsym(handle,
++	    PK11_GET_FUNCTION_LIST)) == NULL)
++		{
++		PK11err(PK11_F_CHECK_HW_MECHANISMS, PK11_R_DSO_FAILURE);
++		goto err;
++		}
++
++	/* get the full function list from the loaded library */
++	if (p(&pflist) != CKR_OK)
++		{
++		PK11err(PK11_F_CHECK_HW_MECHANISMS, PK11_R_DSO_FAILURE);
++		goto err;
++		}
++
++	rv = pflist->C_Initialize((CK_VOID_PTR)&pk11_init_args);
++	if ((rv != CKR_OK) && (rv != CKR_CRYPTOKI_ALREADY_INITIALIZED))
++		{
++		PK11err_add_data(PK11_F_CHECK_HW_MECHANISMS,
++		    PK11_R_INITIALIZE, rv);
++		goto err;
++		}
++
++	if (pflist->C_GetSlotList(0, NULL_PTR, &ulSlotCount) != CKR_OK)
++		{
++		PK11err(PK11_F_CHECK_HW_MECHANISMS, PK11_R_GETSLOTLIST);
++		goto err;
++		}
++
++	/* no slots, set the hw mechanism tables as empty */
++	if (ulSlotCount == 0)
++		{
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: no hardware mechanisms found\n", PK11_DBG);
++#endif
++		hw_cnids = OPENSSL_malloc(sizeof (int));
++		hw_dnids = OPENSSL_malloc(sizeof (int));
++		if (hw_cnids == NULL || hw_dnids == NULL)
++			{
++			PK11err(PK11_F_CHECK_HW_MECHANISMS,
++			    PK11_R_MALLOC_FAILURE);
++			return (0);
++			}
++		/* this means empty tables */
++		hw_cnids[0] = NID_undef;
++		hw_dnids[0] = NID_undef;
++		return (1);
++		}
++
++	pSlotList = OPENSSL_malloc(ulSlotCount * sizeof (CK_SLOT_ID));
++	if (pSlotList == NULL)
++		{
++		PK11err(PK11_F_CHECK_HW_MECHANISMS, PK11_R_MALLOC_FAILURE);
++		goto err;
++		}
++
++	/* Get the slot list for processing */
++	if (pflist->C_GetSlotList(0, pSlotList, &ulSlotCount) != CKR_OK)
++		{
++		PK11err(PK11_F_CHECK_HW_MECHANISMS, PK11_R_GETSLOTLIST);
++		goto err;
++		}
++
++	/*
++	 * We don't care about duplicit mechanisms in multiple slots and also
++	 * reserve one slot for the terminal NID_undef which we use to stop the
++	 * search.
++	 */
++	hw_ctable_size = ulSlotCount * PK11_CIPHER_MAX + 1;
++	hw_dtable_size = ulSlotCount * PK11_DIGEST_MAX + 1;
++	tmp_hw_cnids = OPENSSL_malloc(hw_ctable_size * sizeof (int));
++	tmp_hw_dnids = OPENSSL_malloc(hw_dtable_size * sizeof (int));
++	if (tmp_hw_cnids == NULL || tmp_hw_dnids == NULL)
++		{
++		PK11err(PK11_F_CHECK_HW_MECHANISMS, PK11_R_MALLOC_FAILURE);
++		goto err;
++		}
++
++	/*
++	 * Do not use memset since we should not rely on the fact that NID_undef
++	 * is zero now.
++	 */
++	for (i = 0; i < hw_ctable_size; ++i)
++		tmp_hw_cnids[i] = NID_undef;
++	for (i = 0; i < hw_dtable_size; ++i)
++		tmp_hw_dnids[i] = NID_undef;
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: provider: %s\n", PK11_DBG, pkcs11_kernel);
++	fprintf(stderr, "%s: found %d hardware slots\n", PK11_DBG, ulSlotCount);
++	fprintf(stderr, "%s: now looking for mechs supported in hw\n",
++	    PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++
++	for (i = 0; i < ulSlotCount; i++)
++		{
++		if (pflist->C_GetTokenInfo(pSlotList[i], &token_info) != CKR_OK)
++			continue;
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: token label: %.32s\n", PK11_DBG, token_info.label);
++#endif	/* DEBUG_SLOT_SELECTION */
++
++		/*
++		 * We are filling the hw mech tables here. Global tables are
++		 * still NULL so all mechanisms are put into tmp tables.
++		 */
++		pk11_find_symmetric_ciphers(pflist, pSlotList[i],
++		    &n_cipher, tmp_hw_cnids);
++		pk11_find_digests(pflist, pSlotList[i],
++		    &n_digest, tmp_hw_dnids);
++		}
++
++	/*
++	 * Since we are part of a library (libcrypto.so), calling this function
++	 * may have side-effects. Also, C_Finalize() is triggered by
++	 * dlclose(3C).
++	 */
++#if 0
++	pflist->C_Finalize(NULL);
++#endif
++	OPENSSL_free(pSlotList);
++	(void) dlclose(handle);
++	hw_cnids = tmp_hw_cnids;
++	hw_dnids = tmp_hw_dnids;
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: hw mechs check complete\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++	return (1);
++
++err:
++	if (pSlotList != NULL)
++		OPENSSL_free(pSlotList);
++	if (tmp_hw_cnids != NULL)
++		OPENSSL_free(tmp_hw_cnids);
++	if (tmp_hw_dnids != NULL)
++		OPENSSL_free(tmp_hw_dnids);
++
++	return (0);
++	}
++
++/*
++ * Check presence of a NID in the table of NIDs. The table may be NULL (i.e.,
++ * non-existent).
++ */
++static int nid_in_table(int nid, int *nid_table)
++	{
++	int i = 0;
++
++	/*
++	 * a special case. NULL means that we are initializing a new
++	 * table.
++	 */
++	if (nid_table == NULL)
++		return (1);
++
++	/*
++	 * the table is never full, there is always at least one
++	 * NID_undef.
++	 */
++	while (nid_table[i] != NID_undef)
++		{
++		if (nid_table[i++] == nid)
++			{
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, " (NID %d in hw table, idx %d)", nid, i);
++#endif	/* DEBUG_SLOT_SELECTION */
++			return (1);
++			}
++		}
++
++	return (0);
++	}
++#endif	/* SOLARIS_HW_SLOT_SELECTION */
++
++#endif	/* OPENSSL_NO_HW_PK11CA */
++#endif	/* OPENSSL_NO_HW_PK11 */
++#endif	/* OPENSSL_NO_HW */
+Index: openssl/crypto/engine/hw_pk11_err.c
+diff -u /dev/null openssl/crypto/engine/hw_pk11_err.c:1.5
+--- /dev/null	Mon Jan 16 18:54:23 2012
++++ openssl/crypto/engine/hw_pk11_err.c	Tue Jun 14 00:43:26 2011
+@@ -0,0 +1,288 @@
++/*
++ * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
++ * Use is subject to license terms.
++ */
++
++/* crypto/engine/hw_pk11_err.c */
++/*
++ * This product includes software developed by the OpenSSL Project for
++ * use in the OpenSSL Toolkit (http://www.openssl.org/).
++ *
++ * This project also referenced hw_pkcs11-0.9.7b.patch written by
++ * Afchine Madjlessi.
++ */
++/*
++ * ====================================================================
++ * Copyright (c) 2000-2001 The OpenSSL Project.  All rights reserved.
++ *
++ * Redistribution and use in source and binary forms, with or without
++ * modification, are permitted provided that the following conditions
++ * are met:
++ *
++ * 1. Redistributions of source code must retain the above copyright
++ *    notice, this list of conditions and the following disclaimer.
++ *
++ * 2. Redistributions in binary form must reproduce the above copyright
++ *    notice, this list of conditions and the following disclaimer in
++ *    the documentation and/or other materials provided with the
++ *    distribution.
++ *
++ * 3. All advertising materials mentioning features or use of this
++ *    software must display the following acknowledgment:
++ *    "This product includes software developed by the OpenSSL Project
++ *    for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
++ *
++ * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
++ *    endorse or promote products derived from this software without
++ *    prior written permission. For written permission, please contact
++ *    licensing@OpenSSL.org.
++ *
++ * 5. Products derived from this software may not be called "OpenSSL"
++ *    nor may "OpenSSL" appear in their names without prior written
++ *    permission of the OpenSSL Project.
++ *
++ * 6. Redistributions of any form whatsoever must retain the following
++ *    acknowledgment:
++ *    "This product includes software developed by the OpenSSL Project
++ *    for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
++ *
++ * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
++ * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
++ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
++ * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR
++ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
++ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
++ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
++ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
++ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
++ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
++ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
++ * OF THE POSSIBILITY OF SUCH DAMAGE.
++ * ====================================================================
++ *
++ * This product includes cryptographic software written by Eric Young
++ * (eay@cryptsoft.com).  This product includes software written by Tim
++ * Hudson (tjh@cryptsoft.com).
++ *
++ */
++
++#include <stdio.h>
++#include <openssl/err.h>
++#include "hw_pk11_err.h"
++
++/* BEGIN ERROR CODES */
++#ifndef OPENSSL_NO_ERR
++static ERR_STRING_DATA pk11_str_functs[]=
++{
++{ ERR_PACK(0, PK11_F_INIT, 0),			"PK11_INIT"},
++{ ERR_PACK(0, PK11_F_FINISH, 0),		"PK11_FINISH"},
++{ ERR_PACK(0, PK11_F_DESTROY, 0),		"PK11_DESTROY"},
++{ ERR_PACK(0, PK11_F_CTRL, 0),			"PK11_CTRL"},
++{ ERR_PACK(0, PK11_F_RSA_INIT, 0),		"PK11_RSA_INIT"},
++{ ERR_PACK(0, PK11_F_RSA_FINISH, 0),		"PK11_RSA_FINISH"},
++{ ERR_PACK(0, PK11_F_GET_PUB_RSA_KEY, 0),	"PK11_GET_PUB_RSA_KEY"},
++{ ERR_PACK(0, PK11_F_GET_PRIV_RSA_KEY, 0),	"PK11_GET_PRIV_RSA_KEY"},
++{ ERR_PACK(0, PK11_F_RSA_GEN_KEY, 0),		"PK11_RSA_GEN_KEY"},
++{ ERR_PACK(0, PK11_F_RSA_PUB_ENC, 0),		"PK11_RSA_PUB_ENC"},
++{ ERR_PACK(0, PK11_F_RSA_PRIV_ENC, 0),		"PK11_RSA_PRIV_ENC"},
++{ ERR_PACK(0, PK11_F_RSA_PUB_DEC, 0),		"PK11_RSA_PUB_DEC"},
++{ ERR_PACK(0, PK11_F_RSA_PRIV_DEC, 0),		"PK11_RSA_PRIV_DEC"},
++{ ERR_PACK(0, PK11_F_RSA_SIGN, 0),		"PK11_RSA_SIGN"},
++{ ERR_PACK(0, PK11_F_RSA_VERIFY, 0),		"PK11_RSA_VERIFY"},
++{ ERR_PACK(0, PK11_F_RAND_ADD, 0),		"PK11_RAND_ADD"},
++{ ERR_PACK(0, PK11_F_RAND_BYTES, 0),		"PK11_RAND_BYTES"},
++{ ERR_PACK(0, PK11_F_GET_SESSION, 0),		"PK11_GET_SESSION"},
++{ ERR_PACK(0, PK11_F_FREE_SESSION, 0),		"PK11_FREE_SESSION"},
++{ ERR_PACK(0, PK11_F_LOAD_PUBKEY, 0),		"PK11_LOAD_PUBKEY"},
++{ ERR_PACK(0, PK11_F_LOAD_PRIVKEY, 0),		"PK11_LOAD_PRIV_KEY"},
++{ ERR_PACK(0, PK11_F_RSA_PUB_ENC_LOW, 0),	"PK11_RSA_PUB_ENC_LOW"},
++{ ERR_PACK(0, PK11_F_RSA_PRIV_ENC_LOW, 0),	"PK11_RSA_PRIV_ENC_LOW"},
++{ ERR_PACK(0, PK11_F_RSA_PUB_DEC_LOW, 0),	"PK11_RSA_PUB_DEC_LOW"},
++{ ERR_PACK(0, PK11_F_RSA_PRIV_DEC_LOW, 0),	"PK11_RSA_PRIV_DEC_LOW"},
++{ ERR_PACK(0, PK11_F_DSA_SIGN, 0),		"PK11_DSA_SIGN"},
++{ ERR_PACK(0, PK11_F_DSA_VERIFY, 0),		"PK11_DSA_VERIFY"},
++{ ERR_PACK(0, PK11_F_DSA_INIT, 0),		"PK11_DSA_INIT"},
++{ ERR_PACK(0, PK11_F_DSA_FINISH, 0),		"PK11_DSA_FINISH"},
++{ ERR_PACK(0, PK11_F_GET_PUB_DSA_KEY, 0),	"PK11_GET_PUB_DSA_KEY"},
++{ ERR_PACK(0, PK11_F_GET_PRIV_DSA_KEY, 0),	"PK11_GET_PRIV_DSA_KEY"},
++{ ERR_PACK(0, PK11_F_DH_INIT, 0),		"PK11_DH_INIT"},
++{ ERR_PACK(0, PK11_F_DH_FINISH, 0),		"PK11_DH_FINISH"},
++{ ERR_PACK(0, PK11_F_MOD_EXP_DH, 0),		"PK11_MOD_EXP_DH"},
++{ ERR_PACK(0, PK11_F_GET_DH_KEY, 0),		"PK11_GET_DH_KEY"},
++{ ERR_PACK(0, PK11_F_FREE_ALL_SESSIONS, 0),	"PK11_FREE_ALL_SESSIONS"},
++{ ERR_PACK(0, PK11_F_SETUP_SESSION, 0),		"PK11_SETUP_SESSION"},
++{ ERR_PACK(0, PK11_F_DESTROY_OBJECT, 0),	"PK11_DESTROY_OBJECT"},
++{ ERR_PACK(0, PK11_F_CIPHER_INIT, 0),		"PK11_CIPHER_INIT"},
++{ ERR_PACK(0, PK11_F_CIPHER_DO_CIPHER, 0),	"PK11_CIPHER_DO_CIPHER"},
++{ ERR_PACK(0, PK11_F_GET_CIPHER_KEY, 0),	"PK11_GET_CIPHER_KEY"},
++{ ERR_PACK(0, PK11_F_DIGEST_INIT, 0),		"PK11_DIGEST_INIT"},
++{ ERR_PACK(0, PK11_F_DIGEST_UPDATE, 0),		"PK11_DIGEST_UPDATE"},
++{ ERR_PACK(0, PK11_F_DIGEST_FINAL, 0),		"PK11_DIGEST_FINAL"},
++{ ERR_PACK(0, PK11_F_CHOOSE_SLOT, 0),		"PK11_CHOOSE_SLOT"},
++{ ERR_PACK(0, PK11_F_CIPHER_FINAL, 0),		"PK11_CIPHER_FINAL"},
++{ ERR_PACK(0, PK11_F_LIBRARY_INIT, 0),		"PK11_LIBRARY_INIT"},
++{ ERR_PACK(0, PK11_F_LOAD, 0),			"ENGINE_LOAD_PK11"},
++{ ERR_PACK(0, PK11_F_DH_GEN_KEY, 0),		"PK11_DH_GEN_KEY"},
++{ ERR_PACK(0, PK11_F_DH_COMP_KEY, 0),		"PK11_DH_COMP_KEY"},
++{ ERR_PACK(0, PK11_F_DIGEST_COPY, 0),		"PK11_DIGEST_COPY"},
++{ ERR_PACK(0, PK11_F_CIPHER_CLEANUP, 0),	"PK11_CIPHER_CLEANUP"},
++{ ERR_PACK(0, PK11_F_ACTIVE_ADD, 0),		"PK11_ACTIVE_ADD"},
++{ ERR_PACK(0, PK11_F_ACTIVE_DELETE, 0),		"PK11_ACTIVE_DELETE"},
++{ ERR_PACK(0, PK11_F_CHECK_HW_MECHANISMS, 0),	"PK11_CHECK_HW_MECHANISMS"},
++{ ERR_PACK(0, PK11_F_INIT_SYMMETRIC, 0),	"PK11_INIT_SYMMETRIC"},
++{ ERR_PACK(0, PK11_F_ADD_AES_CTR_NIDS, 0),	"PK11_ADD_AES_CTR_NIDS"},
++{ ERR_PACK(0, PK11_F_INIT_ALL_LOCKS, 0),	"PK11_INIT_ALL_LOCKS"},
++{ ERR_PACK(0, PK11_F_RETURN_SESSION, 0),	"PK11_RETURN_SESSION"},
++{ ERR_PACK(0, PK11_F_GET_PIN, 0),		"PK11_GET_PIN"},
++{ ERR_PACK(0, PK11_F_FIND_ONE_OBJECT, 0),	"PK11_FIND_ONE_OBJECT"},
++{ ERR_PACK(0, PK11_F_CHECK_TOKEN_ATTRS, 0),	"PK11_CHECK_TOKEN_ATTRS"},
++{ ERR_PACK(0, PK11_F_CACHE_PIN, 0),		"PK11_CACHE_PIN"},
++{ ERR_PACK(0, PK11_F_MLOCK_PIN_IN_MEMORY, 0),	"PK11_MLOCK_PIN_IN_MEMORY"},
++{ ERR_PACK(0, PK11_F_TOKEN_LOGIN, 0),		"PK11_TOKEN_LOGIN"},
++{ ERR_PACK(0, PK11_F_TOKEN_RELOGIN, 0),		"PK11_TOKEN_RELOGIN"},
++{ ERR_PACK(0, PK11_F_RUN_ASKPASS, 0),		"PK11_F_RUN_ASKPASS"},
++{ 0, NULL}
++};
++
++static ERR_STRING_DATA pk11_str_reasons[]=
++{
++{ PK11_R_ALREADY_LOADED,		"PKCS#11 DSO already loaded"},
++{ PK11_R_DSO_FAILURE,			"unable to load PKCS#11 DSO"},
++{ PK11_R_NOT_LOADED,			"PKCS#11 DSO not loaded"},
++{ PK11_R_PASSED_NULL_PARAMETER,		"null parameter passed"},
++{ PK11_R_COMMAND_NOT_IMPLEMENTED,	"command not implemented"},
++{ PK11_R_INITIALIZE,			"C_Initialize failed"},
++{ PK11_R_FINALIZE,			"C_Finalize failed"},
++{ PK11_R_GETINFO,			"C_GetInfo faile"},
++{ PK11_R_GETSLOTLIST,			"C_GetSlotList failed"},
++{ PK11_R_NO_MODULUS_OR_NO_EXPONENT,	"no modulus or no exponent"},
++{ PK11_R_ATTRIBUT_SENSITIVE_OR_INVALID,	"attr sensitive or invalid"},
++{ PK11_R_GETATTRIBUTVALUE,		"C_GetAttributeValue failed"},
++{ PK11_R_NO_MODULUS,			"no modulus"},
++{ PK11_R_NO_EXPONENT,			"no exponent"},
++{ PK11_R_FINDOBJECTSINIT,		"C_FindObjectsInit failed"},
++{ PK11_R_FINDOBJECTS,			"C_FindObjects failed"},
++{ PK11_R_FINDOBJECTSFINAL,		"C_FindObjectsFinal failed"},
++{ PK11_R_CREATEOBJECT,			"C_CreateObject failed"},
++{ PK11_R_DESTROYOBJECT,			"C_DestroyObject failed"},
++{ PK11_R_OPENSESSION,			"C_OpenSession failed"},
++{ PK11_R_CLOSESESSION,			"C_CloseSession failed"},
++{ PK11_R_ENCRYPTINIT,			"C_EncryptInit failed"},
++{ PK11_R_ENCRYPT,			"C_Encrypt failed"},
++{ PK11_R_SIGNINIT,			"C_SignInit failed"},
++{ PK11_R_SIGN,				"C_Sign failed"},
++{ PK11_R_DECRYPTINIT,			"C_DecryptInit failed"},
++{ PK11_R_DECRYPT,			"C_Decrypt failed"},
++{ PK11_R_VERIFYINIT,			"C_VerifyRecover failed"},
++{ PK11_R_VERIFY,			"C_Verify failed"},
++{ PK11_R_VERIFYRECOVERINIT,		"C_VerifyRecoverInit failed"},
++{ PK11_R_VERIFYRECOVER,			"C_VerifyRecover failed"},
++{ PK11_R_GEN_KEY,			"C_GenerateKeyPair failed"},
++{ PK11_R_SEEDRANDOM,			"C_SeedRandom failed"},
++{ PK11_R_GENERATERANDOM,		"C_GenerateRandom failed"},
++{ PK11_R_INVALID_MESSAGE_LENGTH,	"invalid message length"},
++{ PK11_R_UNKNOWN_ALGORITHM_TYPE,	"unknown algorithm type"},
++{ PK11_R_UNKNOWN_ASN1_OBJECT_ID,	"unknown asn1 onject id"},
++{ PK11_R_UNKNOWN_PADDING_TYPE,		"unknown padding type"},
++{ PK11_R_PADDING_CHECK_FAILED,		"padding check failed"},
++{ PK11_R_DIGEST_TOO_BIG,		"digest too big"},
++{ PK11_R_MALLOC_FAILURE,		"malloc failure"},
++{ PK11_R_CTRL_COMMAND_NOT_IMPLEMENTED,	"ctl command not implemented"},
++{ PK11_R_DATA_GREATER_THAN_MOD_LEN,	"data is bigger than mod"},
++{ PK11_R_DATA_TOO_LARGE_FOR_MODULUS,	"data is too larger for mod"},
++{ PK11_R_MISSING_KEY_COMPONENT,		"a dsa component is missing"},
++{ PK11_R_INVALID_SIGNATURE_LENGTH,	"invalid signature length"},
++{ PK11_R_INVALID_DSA_SIGNATURE_R,	"missing r in dsa verify"},
++{ PK11_R_INVALID_DSA_SIGNATURE_S,	"missing s in dsa verify"},
++{ PK11_R_INCONSISTENT_KEY,		"inconsistent key type"},
++{ PK11_R_ENCRYPTUPDATE,			"C_EncryptUpdate failed"},
++{ PK11_R_DECRYPTUPDATE,			"C_DecryptUpdate failed"},
++{ PK11_R_DIGESTINIT,			"C_DigestInit failed"},
++{ PK11_R_DIGESTUPDATE,			"C_DigestUpdate failed"},
++{ PK11_R_DIGESTFINAL,			"C_DigestFinal failed"},
++{ PK11_R_ENCRYPTFINAL,			"C_EncryptFinal failed"},
++{ PK11_R_DECRYPTFINAL,			"C_DecryptFinal failed"},
++{ PK11_R_NO_PRNG_SUPPORT,		"Slot does not support PRNG"},
++{ PK11_R_GETTOKENINFO,			"C_GetTokenInfo failed"},
++{ PK11_R_DERIVEKEY,			"C_DeriveKey failed"},
++{ PK11_R_GET_OPERATION_STATE,		"C_GetOperationState failed"},
++{ PK11_R_SET_OPERATION_STATE,		"C_SetOperationState failed"},
++{ PK11_R_INVALID_HANDLE,		"invalid PKCS#11 object handle"},
++{ PK11_R_KEY_OR_IV_LEN_PROBLEM,		"IV or key length incorrect"},
++{ PK11_R_INVALID_OPERATION_TYPE,	"invalid operation type"},
++{ PK11_R_ADD_NID_FAILED,		"failed to add NID" },
++{ PK11_R_ATFORK_FAILED,			"atfork() failed" },
++{ PK11_R_TOKEN_LOGIN_FAILED,		"C_Login() failed on token" },
++{ PK11_R_MORE_THAN_ONE_OBJECT_FOUND,	"more than one object found" },
++{ PK11_R_INVALID_PKCS11_URI,		"pkcs11 URI provided is invalid" },
++{ PK11_R_COULD_NOT_READ_PIN,		"could not read PIN from terminal" },
++{ PK11_R_PIN_NOT_READ_FROM_COMMAND,	"PIN not read from external command" },
++{ PK11_R_COULD_NOT_OPEN_COMMAND,	"could not popen() dialog command" },
++{ PK11_R_PIPE_FAILED,			"pipe() failed" },
++{ PK11_R_BAD_PASSPHRASE_SPEC,		"bad passphrasedialog specification" },
++{ PK11_R_TOKEN_NOT_INITIALIZED,		"token not initialized" },
++{ PK11_R_TOKEN_PIN_NOT_SET,		"token PIN required but not set" },
++{ PK11_R_TOKEN_PIN_NOT_PROVIDED,	"token PIN required but not provided" },
++{ PK11_R_MISSING_OBJECT_LABEL,		"missing mandatory 'object' keyword" },
++{ PK11_R_TOKEN_ATTRS_DO_NOT_MATCH,	"token attrs provided do not match" },
++{ PK11_R_PRIV_KEY_NOT_FOUND,		"private key not found in keystore" },
++{ PK11_R_NO_OBJECT_FOUND,		"specified object not found" },
++{ PK11_R_PIN_CACHING_POLICY_INVALID,	"PIN set but caching policy invalid" },
++{ PK11_R_SYSCONF_FAILED,		"sysconf() failed" },
++{ PK11_R_MMAP_FAILED,			"mmap() failed" },
++{ PK11_R_PRIV_PROC_LOCK_MEMORY_MISSING,	"PROC_LOCK_MEMORY privilege missing" },
++{ PK11_R_MLOCK_FAILED,			"mlock() failed" },
++{ PK11_R_FORK_FAILED,			"fork() failed" },
++{ 0,	NULL}
++};
++#endif	/* OPENSSL_NO_ERR */
++
++static int pk11_lib_error_code = 0;
++static int pk11_error_init = 1;
++
++static void
++ERR_load_pk11_strings(void)
++	{
++	if (pk11_lib_error_code == 0)
++		pk11_lib_error_code = ERR_get_next_error_library();
++
++	if (pk11_error_init)
++		{
++		pk11_error_init = 0;
++#ifndef OPENSSL_NO_ERR
++		ERR_load_strings(pk11_lib_error_code, pk11_str_functs);
++		ERR_load_strings(pk11_lib_error_code, pk11_str_reasons);
++#endif
++		}
++}
++
++static void
++ERR_unload_pk11_strings(void)
++	{
++	if (pk11_error_init == 0)
++		{
++#ifndef OPENSSL_NO_ERR
++		ERR_unload_strings(pk11_lib_error_code, pk11_str_functs);
++		ERR_unload_strings(pk11_lib_error_code, pk11_str_reasons);
++#endif
++		pk11_error_init = 1;
++		}
++}
++
++void
++ERR_pk11_error(int function, int reason, char *file, int line)
++{
++	if (pk11_lib_error_code == 0)
++		pk11_lib_error_code = ERR_get_next_error_library();
++	ERR_PUT_error(pk11_lib_error_code, function, reason, file, line);
++}
++
++void
++PK11err_add_data(int function, int reason, CK_RV rv)
++{
++	char tmp_buf[20];
++
++	PK11err(function, reason);
++	(void) BIO_snprintf(tmp_buf, sizeof (tmp_buf), "%lx", rv);
++	ERR_add_error_data(2, "PK11 CK_RV=0X", tmp_buf);
++}
+Index: openssl/crypto/engine/hw_pk11_err.h
+diff -u /dev/null openssl/crypto/engine/hw_pk11_err.h:1.12
+--- /dev/null	Mon Jan 16 18:54:23 2012
++++ openssl/crypto/engine/hw_pk11_err.h	Tue Jun 14 21:51:32 2011
+@@ -0,0 +1,440 @@
++/*
++ * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
++ * Use is subject to license terms.
++ */
++
++/*
++ * This product includes software developed by the OpenSSL Project for
++ * use in the OpenSSL Toolkit (http://www.openssl.org/).
++ *
++ * This project also referenced hw_pkcs11-0.9.7b.patch written by
++ * Afchine Madjlessi.
++ */
++/*
++ * ====================================================================
++ * Copyright (c) 2000-2001 The OpenSSL Project.  All rights reserved.
++ *
++ * Redistribution and use in source and binary forms, with or without
++ * modification, are permitted provided that the following conditions
++ * are met:
++ *
++ * 1. Redistributions of source code must retain the above copyright
++ *    notice, this list of conditions and the following disclaimer.
++ *
++ * 2. Redistributions in binary form must reproduce the above copyright
++ *    notice, this list of conditions and the following disclaimer in
++ *    the documentation and/or other materials provided with the
++ *    distribution.
++ *
++ * 3. All advertising materials mentioning features or use of this
++ *    software must display the following acknowledgment:
++ *    "This product includes software developed by the OpenSSL Project
++ *    for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
++ *
++ * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
++ *    endorse or promote products derived from this software without
++ *    prior written permission. For written permission, please contact
++ *    licensing@OpenSSL.org.
++ *
++ * 5. Products derived from this software may not be called "OpenSSL"
++ *    nor may "OpenSSL" appear in their names without prior written
++ *    permission of the OpenSSL Project.
++ *
++ * 6. Redistributions of any form whatsoever must retain the following
++ *    acknowledgment:
++ *    "This product includes software developed by the OpenSSL Project
++ *    for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
++ *
++ * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
++ * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
++ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
++ * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR
++ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
++ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
++ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
++ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
++ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
++ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
++ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
++ * OF THE POSSIBILITY OF SUCH DAMAGE.
++ * ====================================================================
++ *
++ * This product includes cryptographic software written by Eric Young
++ * (eay@cryptsoft.com).  This product includes software written by Tim
++ * Hudson (tjh@cryptsoft.com).
++ *
++ */
++
++#ifndef	HW_PK11_ERR_H
++#define	HW_PK11_ERR_H
++
++void ERR_pk11_error(int function, int reason, char *file, int line);
++void PK11err_add_data(int function, int reason, CK_RV rv);
++#define	PK11err(f, r)	ERR_pk11_error((f), (r), __FILE__, __LINE__)
++
++/* Error codes for the PK11 functions. */
++
++/* Function codes. */
++
++#define	PK11_F_INIT				100
++#define	PK11_F_FINISH				101
++#define	PK11_F_DESTROY				102
++#define	PK11_F_CTRL				103
++#define	PK11_F_RSA_INIT				104
++#define	PK11_F_RSA_FINISH			105
++#define	PK11_F_GET_PUB_RSA_KEY			106
++#define	PK11_F_GET_PRIV_RSA_KEY			107
++#define	PK11_F_RSA_GEN_KEY			108
++#define	PK11_F_RSA_PUB_ENC			109
++#define	PK11_F_RSA_PRIV_ENC			110
++#define	PK11_F_RSA_PUB_DEC			111
++#define	PK11_F_RSA_PRIV_DEC			112
++#define	PK11_F_RSA_SIGN				113
++#define	PK11_F_RSA_VERIFY			114
++#define	PK11_F_RAND_ADD				115
++#define	PK11_F_RAND_BYTES			116
++#define	PK11_F_GET_SESSION			117
++#define	PK11_F_FREE_SESSION			118
++#define	PK11_F_LOAD_PUBKEY			119
++#define	PK11_F_LOAD_PRIVKEY			120
++#define	PK11_F_RSA_PUB_ENC_LOW			121
++#define	PK11_F_RSA_PRIV_ENC_LOW			122
++#define	PK11_F_RSA_PUB_DEC_LOW			123
++#define	PK11_F_RSA_PRIV_DEC_LOW			124
++#define	PK11_F_DSA_SIGN				125
++#define	PK11_F_DSA_VERIFY			126
++#define	PK11_F_DSA_INIT				127
++#define	PK11_F_DSA_FINISH			128
++#define	PK11_F_GET_PUB_DSA_KEY			129
++#define	PK11_F_GET_PRIV_DSA_KEY			130
++#define	PK11_F_DH_INIT				131
++#define	PK11_F_DH_FINISH			132
++#define	PK11_F_MOD_EXP_DH			133
++#define	PK11_F_GET_DH_KEY			134
++#define	PK11_F_FREE_ALL_SESSIONS		135
++#define	PK11_F_SETUP_SESSION			136
++#define	PK11_F_DESTROY_OBJECT			137
++#define	PK11_F_CIPHER_INIT			138
++#define	PK11_F_CIPHER_DO_CIPHER			139
++#define	PK11_F_GET_CIPHER_KEY			140
++#define	PK11_F_DIGEST_INIT			141
++#define	PK11_F_DIGEST_UPDATE			142
++#define	PK11_F_DIGEST_FINAL			143
++#define	PK11_F_CHOOSE_SLOT			144
++#define	PK11_F_CIPHER_FINAL			145
++#define	PK11_F_LIBRARY_INIT			146
++#define	PK11_F_LOAD				147
++#define	PK11_F_DH_GEN_KEY			148
++#define	PK11_F_DH_COMP_KEY			149
++#define	PK11_F_DIGEST_COPY			150
++#define	PK11_F_CIPHER_CLEANUP			151
++#define	PK11_F_ACTIVE_ADD			152
++#define	PK11_F_ACTIVE_DELETE			153
++#define	PK11_F_CHECK_HW_MECHANISMS		154
++#define	PK11_F_INIT_SYMMETRIC			155
++#define	PK11_F_ADD_AES_CTR_NIDS			156
++#define	PK11_F_INIT_ALL_LOCKS			157
++#define	PK11_F_RETURN_SESSION			158
++#define	PK11_F_GET_PIN				159
++#define	PK11_F_FIND_ONE_OBJECT			160
++#define	PK11_F_CHECK_TOKEN_ATTRS		161
++#define	PK11_F_CACHE_PIN			162
++#define	PK11_F_MLOCK_PIN_IN_MEMORY		163
++#define	PK11_F_TOKEN_LOGIN			164
++#define	PK11_F_TOKEN_RELOGIN			165
++#define	PK11_F_RUN_ASKPASS			166
++
++/* Reason codes. */
++#define	PK11_R_ALREADY_LOADED 			100
++#define	PK11_R_DSO_FAILURE 			101
++#define	PK11_R_NOT_LOADED 			102
++#define	PK11_R_PASSED_NULL_PARAMETER 		103
++#define	PK11_R_COMMAND_NOT_IMPLEMENTED 		104
++#define	PK11_R_INITIALIZE 			105
++#define	PK11_R_FINALIZE 			106
++#define	PK11_R_GETINFO 				107
++#define	PK11_R_GETSLOTLIST 			108
++#define	PK11_R_NO_MODULUS_OR_NO_EXPONENT 	109
++#define	PK11_R_ATTRIBUT_SENSITIVE_OR_INVALID 	110
++#define	PK11_R_GETATTRIBUTVALUE 		111
++#define	PK11_R_NO_MODULUS 			112
++#define	PK11_R_NO_EXPONENT 			113
++#define	PK11_R_FINDOBJECTSINIT 			114
++#define	PK11_R_FINDOBJECTS 			115
++#define	PK11_R_FINDOBJECTSFINAL 		116
++#define	PK11_R_CREATEOBJECT 			118
++#define	PK11_R_DESTROYOBJECT 			119
++#define	PK11_R_OPENSESSION 			120
++#define	PK11_R_CLOSESESSION 			121
++#define	PK11_R_ENCRYPTINIT 			122
++#define	PK11_R_ENCRYPT 				123
++#define	PK11_R_SIGNINIT 			124
++#define	PK11_R_SIGN 				125
++#define	PK11_R_DECRYPTINIT 			126
++#define	PK11_R_DECRYPT 				127
++#define	PK11_R_VERIFYINIT 			128
++#define	PK11_R_VERIFY 				129
++#define	PK11_R_VERIFYRECOVERINIT 		130
++#define	PK11_R_VERIFYRECOVER 			131
++#define	PK11_R_GEN_KEY 				132
++#define	PK11_R_SEEDRANDOM 			133
++#define	PK11_R_GENERATERANDOM 			134
++#define	PK11_R_INVALID_MESSAGE_LENGTH 		135
++#define	PK11_R_UNKNOWN_ALGORITHM_TYPE 		136
++#define	PK11_R_UNKNOWN_ASN1_OBJECT_ID 		137
++#define	PK11_R_UNKNOWN_PADDING_TYPE 		138
++#define	PK11_R_PADDING_CHECK_FAILED 		139
++#define	PK11_R_DIGEST_TOO_BIG 			140
++#define	PK11_R_MALLOC_FAILURE 			141
++#define	PK11_R_CTRL_COMMAND_NOT_IMPLEMENTED 	142
++#define	PK11_R_DATA_GREATER_THAN_MOD_LEN 	143
++#define	PK11_R_DATA_TOO_LARGE_FOR_MODULUS 	144
++#define	PK11_R_MISSING_KEY_COMPONENT		145
++#define	PK11_R_INVALID_SIGNATURE_LENGTH		146
++#define	PK11_R_INVALID_DSA_SIGNATURE_R		147
++#define	PK11_R_INVALID_DSA_SIGNATURE_S		148
++#define	PK11_R_INCONSISTENT_KEY			149
++#define	PK11_R_ENCRYPTUPDATE			150
++#define	PK11_R_DECRYPTUPDATE			151
++#define	PK11_R_DIGESTINIT			152
++#define	PK11_R_DIGESTUPDATE			153
++#define	PK11_R_DIGESTFINAL			154
++#define	PK11_R_ENCRYPTFINAL			155
++#define	PK11_R_DECRYPTFINAL			156
++#define	PK11_R_NO_PRNG_SUPPORT			157
++#define	PK11_R_GETTOKENINFO			158
++#define	PK11_R_DERIVEKEY			159
++#define	PK11_R_GET_OPERATION_STATE		160
++#define	PK11_R_SET_OPERATION_STATE		161
++#define	PK11_R_INVALID_HANDLE			162
++#define	PK11_R_KEY_OR_IV_LEN_PROBLEM		163
++#define	PK11_R_INVALID_OPERATION_TYPE		164
++#define	PK11_R_ADD_NID_FAILED			165
++#define	PK11_R_ATFORK_FAILED			166
++
++#define	PK11_R_TOKEN_LOGIN_FAILED		167
++#define	PK11_R_MORE_THAN_ONE_OBJECT_FOUND	168
++#define	PK11_R_INVALID_PKCS11_URI		169
++#define	PK11_R_COULD_NOT_READ_PIN		170
++#define	PK11_R_COULD_NOT_OPEN_COMMAND		171
++#define	PK11_R_PIPE_FAILED			172
++#define	PK11_R_PIN_NOT_READ_FROM_COMMAND	173
++#define	PK11_R_BAD_PASSPHRASE_SPEC		174
++#define	PK11_R_TOKEN_NOT_INITIALIZED		175
++#define	PK11_R_TOKEN_PIN_NOT_SET		176
++#define	PK11_R_TOKEN_PIN_NOT_PROVIDED		177
++#define	PK11_R_MISSING_OBJECT_LABEL		178
++#define	PK11_R_TOKEN_ATTRS_DO_NOT_MATCH		179
++#define	PK11_R_PRIV_KEY_NOT_FOUND		180
++#define	PK11_R_NO_OBJECT_FOUND			181
++#define	PK11_R_PIN_CACHING_POLICY_INVALID	182
++#define	PK11_R_SYSCONF_FAILED			183
++#define	PK11_R_MMAP_FAILED			183
++#define	PK11_R_PRIV_PROC_LOCK_MEMORY_MISSING	184
++#define	PK11_R_MLOCK_FAILED			185
++#define	PK11_R_FORK_FAILED			186
++
++/* max byte length of a symetric key we support */
++#define	PK11_KEY_LEN_MAX			32
++
++#ifdef NOPTHREADS
++/*
++ * CRYPTO_LOCK_PK11_ENGINE lock is primarily used for the protection of the
++ * free_session list and active_list but generally serves as a global
++ * per-process lock for the whole engine.
++ *
++ * We reuse CRYPTO_LOCK_EC lock (which is defined in OpenSSL for EC method) as
++ * the global engine lock. This is not optimal w.r.t. performance but
++ * it's safe.
++ */
++#define CRYPTO_LOCK_PK11_ENGINE	CRYPTO_LOCK_EC
++#endif
++
++/*
++ * This structure encapsulates all reusable information for a PKCS#11
++ * session. A list of these objects is created on behalf of the
++ * calling application using an on-demand method. Each operation
++ * type (see PK11_OPTYPE below) has its own per-process list.
++ * Each of the lists is basically a cache for faster PKCS#11 object
++ * access to avoid expensive C_Find{,Init,Final}Object() calls.
++ *
++ * When a new request comes in, an object will be taken from the list
++ * (if there is one) or a new one is created to handle the request
++ * (if the list is empty). See pk11_get_session() on how it is done.
++ */
++typedef struct PK11_st_SESSION
++	{
++	struct PK11_st_SESSION	*next;
++	CK_SESSION_HANDLE	session;	/* PK11 session handle */
++	pid_t			pid;		/* Current process ID */
++	CK_BBOOL		pub_persistent;	/* is pub key in keystore? */
++	CK_BBOOL		priv_persistent;/* is priv key in keystore? */
++	union
++		{
++#ifndef OPENSSL_NO_RSA
++		struct
++			{
++			CK_OBJECT_HANDLE	rsa_pub_key; /* pub handle */
++			CK_OBJECT_HANDLE	rsa_priv_key; /* priv handle */
++			RSA			*rsa_pub; /* pub key addr */
++			BIGNUM			*rsa_n_num; /* pub modulus */
++			BIGNUM			*rsa_e_num; /* pub exponent */
++			RSA			*rsa_priv; /* priv key addr */
++			BIGNUM			*rsa_pn_num; /* pub modulus */
++			BIGNUM			*rsa_pe_num; /* pub exponent */
++			BIGNUM			*rsa_d_num; /* priv exponent */
++			} u_RSA;
++#endif /* OPENSSL_NO_RSA */
++#ifndef OPENSSL_NO_DSA
++		struct
++			{
++			CK_OBJECT_HANDLE	dsa_pub_key; /* pub handle */
++			CK_OBJECT_HANDLE	dsa_priv_key; /* priv handle */
++			DSA			*dsa_pub; /* pub key addr */
++			BIGNUM			*dsa_pub_num; /* pub key */
++			DSA			*dsa_priv; /* priv key addr */
++			BIGNUM			*dsa_priv_num; /* priv key */
++			} u_DSA;
++#endif /* OPENSSL_NO_DSA */
++#ifndef OPENSSL_NO_DH
++		struct
++			{
++			CK_OBJECT_HANDLE	dh_key; /* key handle */
++			DH			*dh; /* dh key addr */
++			BIGNUM			*dh_priv_num; /* priv dh key */
++			} u_DH;
++#endif /* OPENSSL_NO_DH */
++		struct
++			{
++			CK_OBJECT_HANDLE	cipher_key; /* key handle */
++			unsigned char		key[PK11_KEY_LEN_MAX];
++			int			key_len; /* priv key len */
++			int			encrypt; /* 1/0 enc/decr */
++			} u_cipher;
++		} opdata_u;
++	} PK11_SESSION;
++
++#define	opdata_rsa_pub_key	opdata_u.u_RSA.rsa_pub_key
++#define	opdata_rsa_priv_key	opdata_u.u_RSA.rsa_priv_key
++#define	opdata_rsa_pub		opdata_u.u_RSA.rsa_pub
++#define	opdata_rsa_priv		opdata_u.u_RSA.rsa_priv
++#define	opdata_rsa_n_num	opdata_u.u_RSA.rsa_n_num
++#define	opdata_rsa_e_num	opdata_u.u_RSA.rsa_e_num
++#define	opdata_rsa_pn_num	opdata_u.u_RSA.rsa_pn_num
++#define	opdata_rsa_pe_num	opdata_u.u_RSA.rsa_pe_num
++#define	opdata_rsa_d_num	opdata_u.u_RSA.rsa_d_num
++#define	opdata_dsa_pub_key	opdata_u.u_DSA.dsa_pub_key
++#define	opdata_dsa_priv_key	opdata_u.u_DSA.dsa_priv_key
++#define	opdata_dsa_pub		opdata_u.u_DSA.dsa_pub
++#define	opdata_dsa_pub_num	opdata_u.u_DSA.dsa_pub_num
++#define	opdata_dsa_priv		opdata_u.u_DSA.dsa_priv
++#define	opdata_dsa_priv_num	opdata_u.u_DSA.dsa_priv_num
++#define	opdata_dh_key		opdata_u.u_DH.dh_key
++#define	opdata_dh		opdata_u.u_DH.dh
++#define	opdata_dh_priv_num	opdata_u.u_DH.dh_priv_num
++#define	opdata_cipher_key	opdata_u.u_cipher.cipher_key
++#define	opdata_key		opdata_u.u_cipher.key
++#define	opdata_key_len		opdata_u.u_cipher.key_len
++#define	opdata_encrypt		opdata_u.u_cipher.encrypt
++
++/*
++ * We have 3 different groups of operation types:
++ *   1) asymmetric operations
++ *   2) random operations
++ *   3) symmetric and digest operations
++ *
++ * This division into groups stems from the fact that it's common that hardware
++ * providers may support operations from one group only. For example, hardware
++ * providers on UltraSPARC T2, n2rng(7d), ncp(7d), and n2cp(7d), each support
++ * only a single group of operations.
++ *
++ * For every group a different slot can be chosen. That means that we must have
++ * at least 3 different lists of cached PKCS#11 sessions since sessions from
++ * different groups may be initialized in different slots.
++ *
++ * To provide locking granularity in multithreaded environment, the groups are
++ * further splitted into types with each type having a separate session cache.
++ */
++typedef enum PK11_OPTYPE_ENUM
++	{
++	OP_RAND,
++	OP_RSA,
++	OP_DSA,
++	OP_DH,
++	OP_CIPHER,
++	OP_DIGEST,
++	OP_MAX
++	} PK11_OPTYPE;
++
++/*
++ * This structure contains the heads of the lists forming the object caches
++ * and locks associated with the lists.
++ */
++typedef struct PK11_st_CACHE
++	{
++	PK11_SESSION *head;
++#ifndef NOPTHREADS
++	pthread_mutex_t *lock;
++#endif
++	} PK11_CACHE;
++
++/* structure for tracking handles of asymmetric key objects */
++typedef struct PK11_active_st
++	{
++	CK_OBJECT_HANDLE h;
++	unsigned int refcnt;
++	struct PK11_active_st *prev;
++	struct PK11_active_st *next;
++	} PK11_active;
++
++#ifndef NOPTHREADS
++extern pthread_mutex_t *find_lock[];
++#endif
++extern PK11_active *active_list[];
++/*
++ * These variables are specific for the RSA keys by reference code. See
++ * hw_pk11_pub.c for explanation.
++ */
++extern CK_FLAGS pubkey_token_flags;
++
++#ifndef NOPTHREADS
++#define	LOCK_OBJSTORE(alg_type)	\
++	(void) pthread_mutex_lock(find_lock[alg_type])
++#define	UNLOCK_OBJSTORE(alg_type)	\
++	(void) pthread_mutex_unlock(find_lock[alg_type])
++#else
++#define	LOCK_OBJSTORE(alg_type)	\
++	CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE)
++#define	UNLOCK_OBJSTORE(alg_type)	\
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE)
++#endif
++
++extern PK11_SESSION *pk11_get_session(PK11_OPTYPE optype);
++extern void pk11_return_session(PK11_SESSION *sp, PK11_OPTYPE optype);
++extern int pk11_token_relogin(CK_SESSION_HANDLE session);
++
++#ifndef OPENSSL_NO_RSA
++extern int pk11_destroy_rsa_key_objects(PK11_SESSION *session);
++extern int pk11_destroy_rsa_object_pub(PK11_SESSION *sp, CK_BBOOL uselock);
++extern int pk11_destroy_rsa_object_priv(PK11_SESSION *sp, CK_BBOOL uselock);
++extern EVP_PKEY *pk11_load_privkey(ENGINE *e, const char *pubkey_file,
++	UI_METHOD *ui_method, void *callback_data);
++extern EVP_PKEY *pk11_load_pubkey(ENGINE *e, const char *pubkey_file,
++	UI_METHOD *ui_method, void *callback_data);
++extern RSA_METHOD *PK11_RSA(void);
++#endif /* OPENSSL_NO_RSA */
++#ifndef OPENSSL_NO_DSA
++extern int pk11_destroy_dsa_key_objects(PK11_SESSION *session);
++extern int pk11_destroy_dsa_object_pub(PK11_SESSION *sp, CK_BBOOL uselock);
++extern int pk11_destroy_dsa_object_priv(PK11_SESSION *sp, CK_BBOOL uselock);
++extern DSA_METHOD *PK11_DSA(void);
++#endif /* OPENSSL_NO_DSA */
++#ifndef OPENSSL_NO_DH
++extern int pk11_destroy_dh_key_objects(PK11_SESSION *session);
++extern int pk11_destroy_dh_object(PK11_SESSION *sp, CK_BBOOL uselock);
++extern DH_METHOD *PK11_DH(void);
++#endif /* OPENSSL_NO_DH */
++
++extern CK_FUNCTION_LIST_PTR pFuncList;
++
++#endif /* HW_PK11_ERR_H */
+Index: openssl/crypto/engine/hw_pk11_pub.c
+diff -u /dev/null openssl/crypto/engine/hw_pk11_pub.c:1.37
+--- /dev/null	Mon Jan 16 18:54:23 2012
++++ openssl/crypto/engine/hw_pk11_pub.c	Fri Jun 17 07:55:25 2011
+@@ -0,0 +1,3530 @@
++/*
++ * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
++ * Use is subject to license terms.
++ */
++
++/* crypto/engine/hw_pk11_pub.c */
++/*
++ * This product includes software developed by the OpenSSL Project for
++ * use in the OpenSSL Toolkit (http://www.openssl.org/).
++ *
++ * This project also referenced hw_pkcs11-0.9.7b.patch written by
++ * Afchine Madjlessi.
++ */
++/*
++ * ====================================================================
++ * Copyright (c) 2000-2001 The OpenSSL Project.  All rights reserved.
++ *
++ * Redistribution and use in source and binary forms, with or without
++ * modification, are permitted provided that the following conditions
++ * are met:
++ *
++ * 1. Redistributions of source code must retain the above copyright
++ *    notice, this list of conditions and the following disclaimer.
++ *
++ * 2. Redistributions in binary form must reproduce the above copyright
++ *    notice, this list of conditions and the following disclaimer in
++ *    the documentation and/or other materials provided with the
++ *    distribution.
++ *
++ * 3. All advertising materials mentioning features or use of this
++ *    software must display the following acknowledgment:
++ *    "This product includes software developed by the OpenSSL Project
++ *    for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
++ *
++ * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
++ *    endorse or promote products derived from this software without
++ *    prior written permission. For written permission, please contact
++ *    licensing@OpenSSL.org.
++ *
++ * 5. Products derived from this software may not be called "OpenSSL"
++ *    nor may "OpenSSL" appear in their names without prior written
++ *    permission of the OpenSSL Project.
++ *
++ * 6. Redistributions of any form whatsoever must retain the following
++ *    acknowledgment:
++ *    "This product includes software developed by the OpenSSL Project
++ *    for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
++ *
++ * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
++ * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
++ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
++ * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR
++ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
++ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
++ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
++ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
++ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
++ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
++ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
++ * OF THE POSSIBILITY OF SUCH DAMAGE.
++ * ====================================================================
++ *
++ * This product includes cryptographic software written by Eric Young
++ * (eay@cryptsoft.com).  This product includes software written by Tim
++ * Hudson (tjh@cryptsoft.com).
++ *
++ */
++
++#include <stdio.h>
++#include <stdlib.h>
++#include <string.h>
++#include <sys/types.h>
++
++#include <openssl/e_os2.h>
++#include <openssl/crypto.h>
++#include <cryptlib.h>
++#include <openssl/engine.h>
++#include <openssl/dso.h>
++#include <openssl/err.h>
++#include <openssl/bn.h>
++#include <openssl/pem.h>
++#ifndef OPENSSL_NO_RSA
++#include <openssl/rsa.h>
++#endif /* OPENSSL_NO_RSA */
++#ifndef OPENSSL_NO_DSA
++#include <openssl/dsa.h>
++#endif /* OPENSSL_NO_DSA */
++#ifndef OPENSSL_NO_DH
++#include <openssl/dh.h>
++#endif /* OPENSSL_NO_DH */
++#include <openssl/rand.h>
++#include <openssl/objects.h>
++#include <openssl/x509.h>
++
++#ifdef OPENSSL_SYS_WIN32
++#define NOPTHREADS
++typedef int pid_t;
++#define HAVE_GETPASSPHRASE
++static char *getpassphrase(const char *prompt);
++#ifndef NULL_PTR
++#define NULL_PTR NULL
++#endif
++#define CK_DEFINE_FUNCTION(returnType, name) \
++	returnType __declspec(dllexport) name
++#define CK_DECLARE_FUNCTION(returnType, name) \
++	returnType __declspec(dllimport) name
++#define CK_DECLARE_FUNCTION_POINTER(returnType, name) \
++	returnType __declspec(dllimport) (* name)
++#else
++#include <unistd.h>
++#endif
++
++#ifndef NOPTHREADS
++#include <pthread.h>
++#endif
++
++#ifndef OPENSSL_NO_HW
++#ifndef OPENSSL_NO_HW_PK11
++#ifndef OPENSSL_NO_HW_PK11CA
++
++#ifdef OPENSSL_SYS_WIN32
++#pragma pack(push, cryptoki, 1)
++#include "cryptoki.h"
++#include "pkcs11.h"
++#pragma pack(pop, cryptoki)
++#else
++#include "cryptoki.h"
++#include "pkcs11.h"
++#endif
++#include "hw_pk11ca.h"
++#include "hw_pk11_err.h"
++
++static CK_BBOOL pk11_login_done = CK_FALSE;
++extern CK_SLOT_ID pubkey_SLOTID;
++#ifndef NOPTHREADS
++extern pthread_mutex_t *token_lock;
++#endif
++
++#if !(defined(HAVE_GETPASSPHRASE) || (defined (__SVR4) && defined (__sun)))
++#define getpassphrase(x)	getpass(x)
++#endif
++
++#ifndef OPENSSL_NO_RSA
++/* RSA stuff */
++static int pk11_RSA_public_encrypt(int flen, const unsigned char *from,
++	unsigned char *to, RSA *rsa, int padding);
++static int pk11_RSA_private_encrypt(int flen, const unsigned char *from,
++	unsigned char *to, RSA *rsa, int padding);
++static int pk11_RSA_public_decrypt(int flen, const unsigned char *from,
++	unsigned char *to, RSA *rsa, int padding);
++static int pk11_RSA_private_decrypt(int flen, const unsigned char *from,
++	unsigned char *to, RSA *rsa, int padding);
++static int pk11_RSA_init(RSA *rsa);
++static int pk11_RSA_finish(RSA *rsa);
++static int pk11_RSA_sign(int type, const unsigned char *m, unsigned int m_len,
++	unsigned char *sigret, unsigned int *siglen, const RSA *rsa);
++#if OPENSSL_VERSION_NUMBER < 0x10000000L
++static int pk11_RSA_verify(int dtype, const unsigned char *m,
++	unsigned int m_len, unsigned char *sigbuf, unsigned int siglen,
++	const RSA *rsa);
++#else
++static int pk11_RSA_verify(int dtype, const unsigned char *m,
++	unsigned int m_len, const unsigned char *sigbuf, unsigned int siglen,
++	const RSA *rsa);
++#endif
++EVP_PKEY *pk11_load_privkey(ENGINE*, const char *privkey_file,
++	UI_METHOD *ui_method, void *callback_data);
++EVP_PKEY *pk11_load_pubkey(ENGINE*, const char *pubkey_file,
++	UI_METHOD *ui_method, void *callback_data);
++
++static int pk11_RSA_public_encrypt_low(int flen, const unsigned char *from,
++	unsigned char *to, RSA *rsa);
++static int pk11_RSA_private_encrypt_low(int flen, const unsigned char *from,
++	unsigned char *to, RSA *rsa);
++static int pk11_RSA_public_decrypt_low(int flen, const unsigned char *from,
++	unsigned char *to, RSA *rsa);
++static int pk11_RSA_private_decrypt_low(int flen, const unsigned char *from,
++	unsigned char *to, RSA *rsa);
++
++static CK_OBJECT_HANDLE pk11_get_public_rsa_key(RSA* rsa, RSA** key_ptr,
++	BIGNUM **rsa_n_num, BIGNUM **rsa_e_num, CK_SESSION_HANDLE session);
++static CK_OBJECT_HANDLE pk11_get_private_rsa_key(RSA* rsa, RSA** key_ptr,
++	BIGNUM **rsa_d_num, BIGNUM **rsa_n_num, BIGNUM **rsa_e_num,
++	CK_SESSION_HANDLE session);
++
++static int check_new_rsa_key_pub(PK11_SESSION *sp, const RSA *rsa);
++static int check_new_rsa_key_priv(PK11_SESSION *sp, const RSA *rsa);
++#endif
++
++/* DSA stuff */
++#ifndef OPENSSL_NO_DSA
++static int pk11_DSA_init(DSA *dsa);
++static int pk11_DSA_finish(DSA *dsa);
++static DSA_SIG *pk11_dsa_do_sign(const unsigned char *dgst, int dlen,
++	DSA *dsa);
++static int pk11_dsa_do_verify(const unsigned char *dgst, int dgst_len,
++	DSA_SIG *sig, DSA *dsa);
++
++static CK_OBJECT_HANDLE pk11_get_public_dsa_key(DSA* dsa, DSA **key_ptr,
++	BIGNUM **dsa_pub_num, CK_SESSION_HANDLE session);
++static CK_OBJECT_HANDLE pk11_get_private_dsa_key(DSA* dsa, DSA **key_ptr,
++	BIGNUM **dsa_priv_num, CK_SESSION_HANDLE session);
++
++static int check_new_dsa_key_pub(PK11_SESSION *sp, DSA *dsa);
++static int check_new_dsa_key_priv(PK11_SESSION *sp, DSA *dsa);
++#endif
++
++/* DH stuff */
++#ifndef OPENSSL_NO_DH
++static int pk11_DH_init(DH *dh);
++static int pk11_DH_finish(DH *dh);
++static int pk11_DH_generate_key(DH *dh);
++static int pk11_DH_compute_key(unsigned char *key,
++	const BIGNUM *pub_key, DH *dh);
++
++static CK_OBJECT_HANDLE pk11_get_dh_key(DH* dh, DH **key_ptr,
++	BIGNUM **priv_key, CK_SESSION_HANDLE session);
++
++static int check_new_dh_key(PK11_SESSION *sp, DH *dh);
++#endif
++
++static int find_one_object(PK11_OPTYPE op, CK_SESSION_HANDLE s,
++	CK_ATTRIBUTE_PTR ptempl, CK_ULONG nattr, CK_OBJECT_HANDLE_PTR pkey);
++static int init_template_value(BIGNUM *bn, CK_VOID_PTR *pValue,
++	CK_ULONG *ulValueLen);
++static void attr_to_BN(CK_ATTRIBUTE_PTR attr, CK_BYTE attr_data[], BIGNUM **bn);
++
++static int pk11_token_login(CK_SESSION_HANDLE session, CK_BBOOL *login_done,
++	CK_BBOOL is_private);
++
++/* Read mode string to be used for fopen() */
++#if SOLARIS_OPENSSL
++static char *read_mode_flags = "rF";
++#else
++static char *read_mode_flags = "r";
++#endif
++
++/*
++ * increment/create reference for an asymmetric key handle via active list
++ * manipulation. If active list operation fails, unlock (if locked), set error
++ * variable and jump to the specified label.
++ */
++#define	KEY_HANDLE_REFHOLD(key_handle, alg_type, unlock, var, label)	\
++	{								\
++	if (pk11_active_add(key_handle, alg_type) < 0)			\
++		{							\
++		var = TRUE;						\
++		if (unlock)						\
++			UNLOCK_OBJSTORE(alg_type);			\
++		goto label;						\
++		}							\
++	}
++
++/*
++ * Find active list entry according to object handle and return pointer to the
++ * entry otherwise return NULL.
++ *
++ * This function presumes it is called with lock protecting the active list
++ * held.
++ */
++static PK11_active *pk11_active_find(CK_OBJECT_HANDLE h, PK11_OPTYPE type)
++	{
++	PK11_active *entry;
++
++	for (entry = active_list[type]; entry != NULL; entry = entry->next)
++		if (entry->h == h)
++			return (entry);
++
++	return (NULL);
++	}
++
++/*
++ * Search for an entry in the active list using PKCS#11 object handle as a
++ * search key and return refcnt of the found/created entry or -1 in case of
++ * failure.
++ *
++ * This function presumes it is called with lock protecting the active list
++ * held.
++ */
++int
++pk11_active_add(CK_OBJECT_HANDLE h, PK11_OPTYPE type)
++	{
++	PK11_active *entry = NULL;
++
++	if (h == CK_INVALID_HANDLE)
++		{
++		PK11err(PK11_F_ACTIVE_ADD, PK11_R_INVALID_HANDLE);
++		return (-1);
++		}
++
++	/* search for entry in the active list */
++	if ((entry = pk11_active_find(h, type)) != NULL)
++		entry->refcnt++;
++	else
++		{
++		/* not found, create new entry and add it to the list */
++		entry = OPENSSL_malloc(sizeof (PK11_active));
++		if (entry == NULL)
++			{
++			PK11err(PK11_F_ACTIVE_ADD, PK11_R_MALLOC_FAILURE);
++			return (-1);
++			}
++		entry->h = h;
++		entry->refcnt = 1;
++		entry->prev = NULL;
++		entry->next = NULL;
++		/* connect the newly created entry to the list */
++		if (active_list[type] == NULL)
++			active_list[type] = entry;
++		else /* make the entry first in the list */
++			{
++			entry->next = active_list[type];
++			active_list[type]->prev = entry;
++			active_list[type] = entry;
++			}
++		}
++
++	return (entry->refcnt);
++	}
++
++/*
++ * Remove active list entry from the list and free it.
++ *
++ * This function presumes it is called with lock protecting the active list
++ * held.
++ */
++void
++pk11_active_remove(PK11_active *entry, PK11_OPTYPE type)
++	{
++	PK11_active *prev_entry;
++
++	/* remove the entry from the list and free it */
++	if ((prev_entry = entry->prev) != NULL)
++		{
++		prev_entry->next = entry->next;
++		if (entry->next != NULL)
++			entry->next->prev = prev_entry;
++		}
++	else
++		{
++		active_list[type] = entry->next;
++		/* we were the first but not the only one */
++		if (entry->next != NULL)
++			entry->next->prev = NULL;
++		}
++
++	/* sanitization */
++	entry->h = CK_INVALID_HANDLE;
++	entry->prev = NULL;
++	entry->next = NULL;
++	OPENSSL_free(entry);
++	}
++
++/* Free all entries from the active list. */
++void
++pk11_free_active_list(PK11_OPTYPE type)
++	{
++	PK11_active *entry;
++
++	/* only for asymmetric types since only they have C_Find* locks. */
++	switch (type)
++		{
++		case OP_RSA:
++		case OP_DSA:
++		case OP_DH:
++			break;
++		default:
++			return;
++		}
++
++	/* see find_lock array definition for more info on object locking */
++	LOCK_OBJSTORE(type);
++	while ((entry = active_list[type]) != NULL)
++		pk11_active_remove(entry, type);
++	UNLOCK_OBJSTORE(type);
++	}
++
++/*
++ * Search for active list entry associated with given PKCS#11 object handle,
++ * decrement its refcnt and if it drops to 0, disconnect the entry and free it.
++ *
++ * Return 1 if the PKCS#11 object associated with the entry has no references,
++ * return 0 if there is at least one reference, -1 on error.
++ *
++ * This function presumes it is called with lock protecting the active list
++ * held.
++ */
++int
++pk11_active_delete(CK_OBJECT_HANDLE h, PK11_OPTYPE type)
++	{
++	PK11_active *entry = NULL;
++
++	if ((entry = pk11_active_find(h, type)) == NULL)
++		{
++		PK11err(PK11_F_ACTIVE_DELETE, PK11_R_INVALID_HANDLE);
++		return (-1);
++		}
++
++	OPENSSL_assert(entry->refcnt > 0);
++	entry->refcnt--;
++	if (entry->refcnt == 0)
++		{
++		pk11_active_remove(entry, type);
++		return (1);
++		}
++
++	return (0);
++	}
++
++#ifndef OPENSSL_NO_RSA
++/* Our internal RSA_METHOD that we provide pointers to */
++static RSA_METHOD pk11_rsa =
++	{
++	"PKCS#11 RSA method",
++	pk11_RSA_public_encrypt,		/* rsa_pub_encrypt */
++	pk11_RSA_public_decrypt,		/* rsa_pub_decrypt */
++	pk11_RSA_private_encrypt,		/* rsa_priv_encrypt */
++	pk11_RSA_private_decrypt,		/* rsa_priv_decrypt */
++	NULL,					/* rsa_mod_exp */
++	NULL,					/* bn_mod_exp */
++	pk11_RSA_init,				/* init */
++	pk11_RSA_finish,			/* finish */
++	RSA_FLAG_SIGN_VER,			/* flags */
++	NULL,					/* app_data */
++	pk11_RSA_sign,				/* rsa_sign */
++	pk11_RSA_verify				/* rsa_verify */
++	};
++
++RSA_METHOD *
++PK11_RSA(void)
++	{
++	return (&pk11_rsa);
++	}
++#endif
++
++#ifndef OPENSSL_NO_DSA
++/* Our internal DSA_METHOD that we provide pointers to */
++static DSA_METHOD pk11_dsa =
++	{
++	"PKCS#11 DSA method",
++	pk11_dsa_do_sign, 	/* dsa_do_sign */
++	NULL, 			/* dsa_sign_setup */
++	pk11_dsa_do_verify, 	/* dsa_do_verify */
++	NULL,			/* dsa_mod_exp */
++	NULL, 			/* bn_mod_exp */
++	pk11_DSA_init, 		/* init */
++	pk11_DSA_finish, 	/* finish */
++	0, 			/* flags */
++	NULL 			/* app_data */
++	};
++
++DSA_METHOD *
++PK11_DSA(void)
++	{
++	return (&pk11_dsa);
++	}
++#endif
++
++#ifndef OPENSSL_NO_DH
++/*
++ * PKCS #11 V2.20, section 11.2 specifies that the number of bytes needed for
++ * output buffer may somewhat exceed the precise number of bytes needed, but
++ * should not exceed it by a large amount. That may be caused, for example, by
++ * rounding it up to multiple of X in the underlying bignum library. 8 should be
++ * enough.
++ */
++#define	DH_BUF_RESERVE	8
++
++/* Our internal DH_METHOD that we provide pointers to */
++static DH_METHOD pk11_dh =
++	{
++	"PKCS#11 DH method",
++	pk11_DH_generate_key,	/* generate_key */
++	pk11_DH_compute_key,	/* compute_key */
++	NULL,			/* bn_mod_exp */
++	pk11_DH_init,		/* init */
++	pk11_DH_finish,		/* finish */
++	0,			/* flags */
++	NULL,			/* app_data */
++	NULL			/* generate_params */
++	};
++
++DH_METHOD *
++PK11_DH(void)
++	{
++	return (&pk11_dh);
++	}
++#endif
++
++/* Size of an SSL signature: MD5+SHA1 */
++#define	SSL_SIG_LENGTH		36
++
++/* Lengths of DSA data and signature */
++#define	DSA_DATA_LEN		20
++#define	DSA_SIGNATURE_LEN	40
++
++static CK_BBOOL true = TRUE;
++static CK_BBOOL false = FALSE;
++
++#ifndef OPENSSL_NO_RSA
++/*
++ * Similiar to OpenSSL to take advantage of the paddings. The goal is to
++ * support all paddings in this engine although PK11 library does not
++ * support all the paddings used in OpenSSL.
++ * The input errors should have been checked in the padding functions.
++ */
++static int pk11_RSA_public_encrypt(int flen, const unsigned char *from,
++		unsigned char *to, RSA *rsa, int padding)
++	{
++	int i, num = 0, r = -1;
++	unsigned char *buf = NULL;
++
++	num = BN_num_bytes(rsa->n);
++	if ((buf = (unsigned char *)OPENSSL_malloc(num)) == NULL)
++		{
++		RSAerr(PK11_F_RSA_PUB_ENC, PK11_R_MALLOC_FAILURE);
++		goto err;
++		}
++
++	switch (padding)
++		{
++	case RSA_PKCS1_PADDING:
++		i = RSA_padding_add_PKCS1_type_2(buf, num, from, flen);
++		break;
++#ifndef OPENSSL_NO_SHA
++	case RSA_PKCS1_OAEP_PADDING:
++		i = RSA_padding_add_PKCS1_OAEP(buf, num, from, flen, NULL, 0);
++		break;
++#endif
++	case RSA_SSLV23_PADDING:
++		i = RSA_padding_add_SSLv23(buf, num, from, flen);
++		break;
++	case RSA_NO_PADDING:
++		i = RSA_padding_add_none(buf, num, from, flen);
++		break;
++	default:
++		RSAerr(PK11_F_RSA_PUB_ENC, PK11_R_UNKNOWN_PADDING_TYPE);
++		goto err;
++		}
++	if (i <= 0) goto err;
++
++	/* PK11 functions are called here */
++	r = pk11_RSA_public_encrypt_low(num, buf, to, rsa);
++err:
++	if (buf != NULL)
++		{
++		OPENSSL_cleanse(buf, num);
++		OPENSSL_free(buf);
++		}
++	return (r);
++	}
++
++
++/*
++ * Similar to Openssl to take advantage of the paddings. The input errors
++ * should be catched in the padding functions
++ */
++static int pk11_RSA_private_encrypt(int flen, const unsigned char *from,
++	unsigned char *to, RSA *rsa, int padding)
++	{
++	int i, num = 0, r = -1;
++	unsigned char *buf = NULL;
++
++	num = BN_num_bytes(rsa->n);
++	if ((buf = (unsigned char *)OPENSSL_malloc(num)) == NULL)
++		{
++		RSAerr(PK11_F_RSA_PRIV_ENC, PK11_R_MALLOC_FAILURE);
++		goto err;
++		}
++
++	switch (padding)
++		{
++	case RSA_PKCS1_PADDING:
++		i = RSA_padding_add_PKCS1_type_1(buf, num, from, flen);
++		break;
++	case RSA_NO_PADDING:
++		i = RSA_padding_add_none(buf, num, from, flen);
++		break;
++	case RSA_SSLV23_PADDING:
++	default:
++		RSAerr(PK11_F_RSA_PRIV_ENC, PK11_R_UNKNOWN_PADDING_TYPE);
++		goto err;
++		}
++	if (i <= 0) goto err;
++
++	/* PK11 functions are called here */
++	r = pk11_RSA_private_encrypt_low(num, buf, to, rsa);
++err:
++	if (buf != NULL)
++		{
++		OPENSSL_cleanse(buf, num);
++		OPENSSL_free(buf);
++		}
++	return (r);
++	}
++
++/* Similar to OpenSSL code. Input errors are also checked here */
++static int pk11_RSA_private_decrypt(int flen, const unsigned char *from,
++	unsigned char *to, RSA *rsa, int padding)
++	{
++	BIGNUM f;
++	int j, num = 0, r = -1;
++	unsigned char *p;
++	unsigned char *buf = NULL;
++
++	BN_init(&f);
++
++	num = BN_num_bytes(rsa->n);
++
++	if ((buf = (unsigned char *)OPENSSL_malloc(num)) == NULL)
++		{
++		RSAerr(PK11_F_RSA_PRIV_DEC, PK11_R_MALLOC_FAILURE);
++		goto err;
++		}
++
++	/*
++	 * This check was for equality but PGP does evil things
++	 * and chops off the top '0' bytes
++	 */
++	if (flen > num)
++		{
++		RSAerr(PK11_F_RSA_PRIV_DEC,
++			PK11_R_DATA_GREATER_THAN_MOD_LEN);
++		goto err;
++		}
++
++	/* make data into a big number */
++	if (BN_bin2bn(from, (int)flen, &f) == NULL)
++		goto err;
++
++	if (BN_ucmp(&f, rsa->n) >= 0)
++		{
++		RSAerr(PK11_F_RSA_PRIV_DEC,
++			PK11_R_DATA_TOO_LARGE_FOR_MODULUS);
++		goto err;
++		}
++
++	/* PK11 functions are called here */
++	r = pk11_RSA_private_decrypt_low(flen, from, buf, rsa);
++
++	/*
++	 * PK11 CKM_RSA_X_509 mechanism pads 0's at the beginning.
++	 * Needs to skip these 0's paddings here.
++	 */
++	for (j = 0; j < r; j++)
++		if (buf[j] != 0)
++			break;
++
++	p = buf + j;
++	j = r - j;  /* j is only used with no-padding mode */
++
++	switch (padding)
++		{
++	case RSA_PKCS1_PADDING:
++		r = RSA_padding_check_PKCS1_type_2(to, num, p, j, num);
++		break;
++#ifndef OPENSSL_NO_SHA
++	case RSA_PKCS1_OAEP_PADDING:
++		r = RSA_padding_check_PKCS1_OAEP(to, num, p, j, num, NULL, 0);
++		break;
++#endif
++	case RSA_SSLV23_PADDING:
++		r = RSA_padding_check_SSLv23(to, num, p, j, num);
++		break;
++	case RSA_NO_PADDING:
++		r = RSA_padding_check_none(to, num, p, j, num);
++		break;
++	default:
++		RSAerr(PK11_F_RSA_PRIV_DEC, PK11_R_UNKNOWN_PADDING_TYPE);
++		goto err;
++		}
++	if (r < 0)
++		RSAerr(PK11_F_RSA_PRIV_DEC, PK11_R_PADDING_CHECK_FAILED);
++
++err:
++	BN_clear_free(&f);
++	if (buf != NULL)
++		{
++		OPENSSL_cleanse(buf, num);
++		OPENSSL_free(buf);
++		}
++	return (r);
++	}
++
++/* Similar to OpenSSL code. Input errors are also checked here */
++static int pk11_RSA_public_decrypt(int flen, const unsigned char *from,
++	unsigned char *to, RSA *rsa, int padding)
++	{
++	BIGNUM f;
++	int i, num = 0, r = -1;
++	unsigned char *p;
++	unsigned char *buf = NULL;
++
++	BN_init(&f);
++	num = BN_num_bytes(rsa->n);
++	buf = (unsigned char *)OPENSSL_malloc(num);
++	if (buf == NULL)
++		{
++		RSAerr(PK11_F_RSA_PUB_DEC, PK11_R_MALLOC_FAILURE);
++		goto err;
++		}
++
++	/*
++	 * This check was for equality but PGP does evil things
++	 * and chops off the top '0' bytes
++	 */
++	if (flen > num)
++		{
++		RSAerr(PK11_F_RSA_PUB_DEC, PK11_R_DATA_GREATER_THAN_MOD_LEN);
++		goto err;
++		}
++
++	if (BN_bin2bn(from, flen, &f) == NULL)
++		goto err;
++
++	if (BN_ucmp(&f, rsa->n) >= 0)
++		{
++		RSAerr(PK11_F_RSA_PUB_DEC,
++			PK11_R_DATA_TOO_LARGE_FOR_MODULUS);
++		goto err;
++		}
++
++	/* PK11 functions are called here */
++	r = pk11_RSA_public_decrypt_low(flen, from, buf, rsa);
++
++	/*
++	 * PK11 CKM_RSA_X_509 mechanism pads 0's at the beginning.
++	 * Needs to skip these 0's here
++	 */
++	for (i = 0; i < r; i++)
++		if (buf[i] != 0)
++			break;
++
++	p = buf + i;
++	i = r - i;  /* i is only used with no-padding mode */
++
++	switch (padding)
++		{
++	case RSA_PKCS1_PADDING:
++		r = RSA_padding_check_PKCS1_type_1(to, num, p, i, num);
++		break;
++	case RSA_NO_PADDING:
++		r = RSA_padding_check_none(to, num, p, i, num);
++		break;
++	default:
++		RSAerr(PK11_F_RSA_PUB_DEC, PK11_R_UNKNOWN_PADDING_TYPE);
++		goto err;
++		}
++	if (r < 0)
++		RSAerr(PK11_F_RSA_PUB_DEC, PK11_R_PADDING_CHECK_FAILED);
++
++err:
++	BN_clear_free(&f);
++	if (buf != NULL)
++		{
++		OPENSSL_cleanse(buf, num);
++		OPENSSL_free(buf);
++		}
++	return (r);
++	}
++
++/*
++ * This function implements RSA public encryption using C_EncryptInit and
++ * C_Encrypt pk11 interfaces. Note that the CKM_RSA_X_509 is used here.
++ * The calling function allocated sufficient memory in "to" to store results.
++ */
++static int pk11_RSA_public_encrypt_low(int flen,
++	const unsigned char *from, unsigned char *to, RSA *rsa)
++	{
++	CK_ULONG bytes_encrypted = flen;
++	int retval = -1;
++	CK_RV rv;
++	CK_MECHANISM mech_rsa = {CKM_RSA_X_509, NULL, 0};
++	CK_MECHANISM *p_mech = &mech_rsa;
++	CK_OBJECT_HANDLE h_pub_key = CK_INVALID_HANDLE;
++	PK11_SESSION *sp;
++
++	if ((sp = pk11_get_session(OP_RSA)) == NULL)
++		return (-1);
++
++	(void) check_new_rsa_key_pub(sp, rsa);
++
++	h_pub_key = sp->opdata_rsa_pub_key;
++	if (h_pub_key == CK_INVALID_HANDLE)
++		h_pub_key = sp->opdata_rsa_pub_key =
++			pk11_get_public_rsa_key(rsa, &sp->opdata_rsa_pub,
++			    &sp->opdata_rsa_n_num, &sp->opdata_rsa_e_num,
++			    sp->session);
++
++	if (h_pub_key != CK_INVALID_HANDLE)
++		{
++		rv = pFuncList->C_EncryptInit(sp->session, p_mech,
++			h_pub_key);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_PUB_ENC_LOW,
++			    PK11_R_ENCRYPTINIT, rv);
++			pk11_return_session(sp, OP_RSA);
++			return (-1);
++			}
++
++		rv = pFuncList->C_Encrypt(sp->session,
++			(unsigned char *)from, flen, to, &bytes_encrypted);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_PUB_ENC_LOW,
++			    PK11_R_ENCRYPT, rv);
++			pk11_return_session(sp, OP_RSA);
++			return (-1);
++			}
++		retval = bytes_encrypted;
++		}
++
++	pk11_return_session(sp, OP_RSA);
++	return (retval);
++	}
++
++
++/*
++ * This function implements RSA private encryption using C_SignInit and
++ * C_Sign pk11 APIs. Note that CKM_RSA_X_509 is used here.
++ * The calling function allocated sufficient memory in "to" to store results.
++ */
++static int pk11_RSA_private_encrypt_low(int flen,
++	const unsigned char *from, unsigned char *to, RSA *rsa)
++	{
++	CK_ULONG ul_sig_len = flen;
++	int retval = -1;
++	CK_RV rv;
++	CK_MECHANISM mech_rsa = {CKM_RSA_X_509, NULL, 0};
++	CK_MECHANISM *p_mech = &mech_rsa;
++	CK_OBJECT_HANDLE h_priv_key = CK_INVALID_HANDLE;
++	PK11_SESSION *sp;
++
++	if ((sp = pk11_get_session(OP_RSA)) == NULL)
++		return (-1);
++
++	(void) check_new_rsa_key_priv(sp, rsa);
++
++	h_priv_key = sp->opdata_rsa_priv_key;
++	if (h_priv_key == CK_INVALID_HANDLE)
++		{
++		h_priv_key = sp->opdata_rsa_priv_key =
++			pk11_get_private_rsa_key(rsa, &sp->opdata_rsa_priv,
++			    &sp->opdata_rsa_d_num, &sp->opdata_rsa_pn_num,
++			    &sp->opdata_rsa_pe_num, sp->session);
++		}
++
++	if (h_priv_key != CK_INVALID_HANDLE)
++		{
++		rv = pFuncList->C_SignInit(sp->session, p_mech,
++			h_priv_key);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_PRIV_ENC_LOW,
++			    PK11_R_SIGNINIT, rv);
++			pk11_return_session(sp, OP_RSA);
++			return (-1);
++			}
++
++		rv = pFuncList->C_Sign(sp->session,
++			(unsigned char *)from, flen, to, &ul_sig_len);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_PRIV_ENC_LOW, PK11_R_SIGN,
++			    rv);
++			pk11_return_session(sp, OP_RSA);
++			return (-1);
++			}
++
++		retval = ul_sig_len;
++		}
++
++	pk11_return_session(sp, OP_RSA);
++	return (retval);
++	}
++
++
++/*
++ * This function implements RSA private decryption using C_DecryptInit and
++ * C_Decrypt pk11 APIs. Note that CKM_RSA_X_509 mechanism is used here.
++ * The calling function allocated sufficient memory in "to" to store results.
++ */
++static int pk11_RSA_private_decrypt_low(int flen,
++	const unsigned char *from, unsigned char *to, RSA *rsa)
++	{
++	CK_ULONG bytes_decrypted = flen;
++	int retval = -1;
++	CK_RV rv;
++	CK_MECHANISM mech_rsa = {CKM_RSA_X_509, NULL, 0};
++	CK_MECHANISM *p_mech = &mech_rsa;
++	CK_OBJECT_HANDLE h_priv_key;
++	PK11_SESSION *sp;
++
++	if ((sp = pk11_get_session(OP_RSA)) == NULL)
++		return (-1);
++
++	(void) check_new_rsa_key_priv(sp, rsa);
++
++	h_priv_key = sp->opdata_rsa_priv_key;
++	if (h_priv_key == CK_INVALID_HANDLE)
++		h_priv_key = sp->opdata_rsa_priv_key =
++			pk11_get_private_rsa_key(rsa, &sp->opdata_rsa_priv,
++			    &sp->opdata_rsa_d_num, &sp->opdata_rsa_pn_num,
++			    &sp->opdata_rsa_pe_num, sp->session);
++
++	if (h_priv_key != CK_INVALID_HANDLE)
++		{
++		rv = pFuncList->C_DecryptInit(sp->session, p_mech,
++			h_priv_key);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_PRIV_DEC_LOW,
++				PK11_R_DECRYPTINIT, rv);
++			pk11_return_session(sp, OP_RSA);
++			return (-1);
++			}
++
++		rv = pFuncList->C_Decrypt(sp->session,
++			(unsigned char *)from, flen, to, &bytes_decrypted);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_PRIV_DEC_LOW,
++			    PK11_R_DECRYPT, rv);
++			pk11_return_session(sp, OP_RSA);
++			return (-1);
++			}
++		retval = bytes_decrypted;
++		}
++
++	pk11_return_session(sp, OP_RSA);
++	return (retval);
++	}
++
++
++/*
++ * This function implements RSA public decryption using C_VerifyRecoverInit
++ * and C_VerifyRecover pk11 APIs. Note that CKM_RSA_X_509 is used here.
++ * The calling function allocated sufficient memory in "to" to store results.
++ */
++static int pk11_RSA_public_decrypt_low(int flen,
++	const unsigned char *from, unsigned char *to, RSA *rsa)
++	{
++	CK_ULONG bytes_decrypted = flen;
++	int retval = -1;
++	CK_RV rv;
++	CK_MECHANISM mech_rsa = {CKM_RSA_X_509, NULL, 0};
++	CK_MECHANISM *p_mech = &mech_rsa;
++	CK_OBJECT_HANDLE h_pub_key = CK_INVALID_HANDLE;
++	PK11_SESSION *sp;
++
++	if ((sp = pk11_get_session(OP_RSA)) == NULL)
++		return (-1);
++
++	(void) check_new_rsa_key_pub(sp, rsa);
++
++	h_pub_key = sp->opdata_rsa_pub_key;
++	if (h_pub_key == CK_INVALID_HANDLE)
++		h_pub_key = sp->opdata_rsa_pub_key =
++			pk11_get_public_rsa_key(rsa, &sp->opdata_rsa_pub,
++			    &sp->opdata_rsa_n_num, &sp->opdata_rsa_e_num,
++			    sp->session);
++
++	if (h_pub_key != CK_INVALID_HANDLE)
++		{
++		rv = pFuncList->C_VerifyRecoverInit(sp->session,
++			p_mech, h_pub_key);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_PUB_DEC_LOW,
++				PK11_R_VERIFYRECOVERINIT, rv);
++			pk11_return_session(sp, OP_RSA);
++			return (-1);
++			}
++
++		rv = pFuncList->C_VerifyRecover(sp->session,
++			(unsigned char *)from, flen, to, &bytes_decrypted);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_PUB_DEC_LOW,
++			    PK11_R_VERIFYRECOVER, rv);
++			pk11_return_session(sp, OP_RSA);
++			return (-1);
++			}
++		retval = bytes_decrypted;
++		}
++
++	pk11_return_session(sp, OP_RSA);
++	return (retval);
++	}
++
++static int pk11_RSA_init(RSA *rsa)
++	{
++	/*
++	 * This flag in the RSA_METHOD enables the new rsa_sign,
++	 * rsa_verify functions. See rsa.h for details.
++	 */
++	rsa->flags |= RSA_FLAG_SIGN_VER;
++
++	return (1);
++	}
++
++static int pk11_RSA_finish(RSA *rsa)
++	{
++	/*
++	 * Since we are overloading OpenSSL's native RSA_eay_finish() we need
++	 * to do the same as in the original function, i.e. to free bignum
++	 * structures.
++	 */
++	if (rsa->_method_mod_n != NULL)
++		BN_MONT_CTX_free(rsa->_method_mod_n);
++	if (rsa->_method_mod_p != NULL)
++		BN_MONT_CTX_free(rsa->_method_mod_p);
++	if (rsa->_method_mod_q != NULL)
++		BN_MONT_CTX_free(rsa->_method_mod_q);
++
++	return (1);
++	}
++
++/*
++ * Standard engine interface function. Majority codes here are from
++ * rsa/rsa_sign.c. We replaced the decrypt function call by C_Sign of PKCS#11.
++ * See more details in rsa/rsa_sign.c
++ */
++static int pk11_RSA_sign(int type, const unsigned char *m, unsigned int m_len,
++	unsigned char *sigret, unsigned int *siglen, const RSA *rsa)
++	{
++	X509_SIG sig;
++	ASN1_TYPE parameter;
++	int i, j = 0;
++	unsigned char *p, *s = NULL;
++	X509_ALGOR algor;
++	ASN1_OCTET_STRING digest;
++	CK_RV rv;
++	CK_MECHANISM mech_rsa = {CKM_RSA_PKCS, NULL, 0};
++	CK_MECHANISM *p_mech = &mech_rsa;
++	CK_OBJECT_HANDLE h_priv_key;
++	PK11_SESSION *sp = NULL;
++	int ret = 0;
++	unsigned long ulsiglen;
++
++	/* Encode the digest */
++	/* Special case: SSL signature, just check the length */
++	if (type == NID_md5_sha1)
++		{
++		if (m_len != SSL_SIG_LENGTH)
++			{
++			PK11err(PK11_F_RSA_SIGN,
++				PK11_R_INVALID_MESSAGE_LENGTH);
++			goto err;
++			}
++		i = SSL_SIG_LENGTH;
++		s = (unsigned char *)m;
++		}
++	else
++		{
++		sig.algor = &algor;
++		sig.algor->algorithm = OBJ_nid2obj(type);
++		if (sig.algor->algorithm == NULL)
++			{
++			PK11err(PK11_F_RSA_SIGN,
++				PK11_R_UNKNOWN_ALGORITHM_TYPE);
++			goto err;
++			}
++		if (sig.algor->algorithm->length == 0)
++			{
++			PK11err(PK11_F_RSA_SIGN,
++				PK11_R_UNKNOWN_ASN1_OBJECT_ID);
++			goto err;
++			}
++		parameter.type = V_ASN1_NULL;
++		parameter.value.ptr = NULL;
++		sig.algor->parameter = &parameter;
++
++		sig.digest = &digest;
++		sig.digest->data = (unsigned char *)m;
++		sig.digest->length = m_len;
++
++		i = i2d_X509_SIG(&sig, NULL);
++		}
++
++	j = RSA_size(rsa);
++	if ((i - RSA_PKCS1_PADDING) > j)
++		{
++		PK11err(PK11_F_RSA_SIGN, PK11_R_DIGEST_TOO_BIG);
++		goto err;
++		}
++
++	if (type != NID_md5_sha1)
++		{
++		s = (unsigned char *)OPENSSL_malloc((unsigned int)(j + 1));
++		if (s == NULL)
++			{
++			PK11err(PK11_F_RSA_SIGN, PK11_R_MALLOC_FAILURE);
++			goto err;
++			}
++		p = s;
++		(void) i2d_X509_SIG(&sig, &p);
++		}
++
++	if ((sp = pk11_get_session(OP_RSA)) == NULL)
++		goto err;
++
++	(void) check_new_rsa_key_priv(sp, rsa);
++
++	h_priv_key = sp->opdata_rsa_priv_key;
++	if (h_priv_key == CK_INVALID_HANDLE)
++		h_priv_key = sp->opdata_rsa_priv_key =
++			pk11_get_private_rsa_key((RSA *)rsa,
++			    &sp->opdata_rsa_priv, &sp->opdata_rsa_d_num,
++			    &sp->opdata_rsa_pn_num, &sp->opdata_rsa_pe_num,
++			    sp->session);
++
++	if (h_priv_key != CK_INVALID_HANDLE)
++		{
++		rv = pFuncList->C_SignInit(sp->session, p_mech, h_priv_key);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_SIGN, PK11_R_SIGNINIT, rv);
++			goto err;
++			}
++
++		ulsiglen = j;
++		rv = pFuncList->C_Sign(sp->session, s, i, sigret,
++			(CK_ULONG_PTR) &ulsiglen);
++		*siglen = ulsiglen;
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_SIGN, PK11_R_SIGN, rv);
++			goto err;
++			}
++		ret = 1;
++		}
++
++err:
++	if ((type != NID_md5_sha1) && (s != NULL))
++		{
++		(void) memset(s, 0, (unsigned int)(j + 1));
++		OPENSSL_free(s);
++		}
++
++	pk11_return_session(sp, OP_RSA);
++	return (ret);
++	}
++
++#if OPENSSL_VERSION_NUMBER < 0x10000000L
++static int pk11_RSA_verify(int type, const unsigned char *m,
++	unsigned int m_len, unsigned char *sigbuf, unsigned int siglen,
++	const RSA *rsa)
++#else
++static int pk11_RSA_verify(int type, const unsigned char *m,
++	unsigned int m_len, const unsigned char *sigbuf, unsigned int siglen,
++	const RSA *rsa)
++#endif
++	{
++	X509_SIG sig;
++	ASN1_TYPE parameter;
++	int i, j = 0;
++	unsigned char *p, *s = NULL;
++	X509_ALGOR algor;
++	ASN1_OCTET_STRING digest;
++	CK_RV rv;
++	CK_MECHANISM mech_rsa = {CKM_RSA_PKCS, NULL, 0};
++	CK_MECHANISM *p_mech = &mech_rsa;
++	CK_OBJECT_HANDLE h_pub_key;
++	PK11_SESSION *sp = NULL;
++	int ret = 0;
++
++	/* Encode the digest	*/
++	/* Special case: SSL signature, just check the length */
++	if (type == NID_md5_sha1)
++		{
++		if (m_len != SSL_SIG_LENGTH)
++			{
++			PK11err(PK11_F_RSA_VERIFY,
++				PK11_R_INVALID_MESSAGE_LENGTH);
++			goto err;
++			}
++		i = SSL_SIG_LENGTH;
++		s = (unsigned char *)m;
++		}
++	else
++		{
++		sig.algor = &algor;
++		sig.algor->algorithm = OBJ_nid2obj(type);
++		if (sig.algor->algorithm == NULL)
++			{
++			PK11err(PK11_F_RSA_VERIFY,
++				PK11_R_UNKNOWN_ALGORITHM_TYPE);
++			goto err;
++			}
++		if (sig.algor->algorithm->length == 0)
++			{
++			PK11err(PK11_F_RSA_VERIFY,
++				PK11_R_UNKNOWN_ASN1_OBJECT_ID);
++			goto err;
++			}
++		parameter.type = V_ASN1_NULL;
++		parameter.value.ptr = NULL;
++		sig.algor->parameter = &parameter;
++		sig.digest = &digest;
++		sig.digest->data = (unsigned char *)m;
++		sig.digest->length = m_len;
++		i = i2d_X509_SIG(&sig, NULL);
++		}
++
++	j = RSA_size(rsa);
++	if ((i - RSA_PKCS1_PADDING) > j)
++		{
++		PK11err(PK11_F_RSA_VERIFY, PK11_R_DIGEST_TOO_BIG);
++		goto err;
++		}
++
++	if (type != NID_md5_sha1)
++		{
++		s = (unsigned char *)OPENSSL_malloc((unsigned int)(j + 1));
++		if (s == NULL)
++			{
++			PK11err(PK11_F_RSA_VERIFY, PK11_R_MALLOC_FAILURE);
++			goto err;
++			}
++		p = s;
++		(void) i2d_X509_SIG(&sig, &p);
++		}
++
++	if ((sp = pk11_get_session(OP_RSA)) == NULL)
++		goto err;
++
++	(void) check_new_rsa_key_pub(sp, rsa);
++
++	h_pub_key = sp->opdata_rsa_pub_key;
++	if (h_pub_key == CK_INVALID_HANDLE)
++		h_pub_key = sp->opdata_rsa_pub_key =
++			pk11_get_public_rsa_key((RSA *)rsa, &sp->opdata_rsa_pub,
++			    &sp->opdata_rsa_n_num, &sp->opdata_rsa_e_num,
++			    sp->session);
++
++	if (h_pub_key != CK_INVALID_HANDLE)
++		{
++		rv = pFuncList->C_VerifyInit(sp->session, p_mech,
++			h_pub_key);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_VERIFY, PK11_R_VERIFYINIT,
++			    rv);
++			goto err;
++			}
++		rv = pFuncList->C_Verify(sp->session, s, i,
++			(CK_BYTE_PTR)sigbuf, (CK_ULONG)siglen);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_VERIFY, PK11_R_VERIFY, rv);
++			goto err;
++			}
++		ret = 1;
++		}
++
++err:
++	if ((type != NID_md5_sha1) && (s != NULL))
++		{
++		(void) memset(s, 0, (unsigned int)(j + 1));
++		OPENSSL_free(s);
++		}
++
++	pk11_return_session(sp, OP_RSA);
++	return (ret);
++	}
++
++static int hndidx_rsa = -1;
++
++#define	MAXATTR	1024
++
++/*
++ * Load RSA private key from a file or get its PKCS#11 handle if stored in the
++ * PKCS#11 token.
++ */
++/* ARGSUSED */
++EVP_PKEY *pk11_load_privkey(ENGINE *e, const char *privkey_file,
++	UI_METHOD *ui_method, void *callback_data)
++	{
++	EVP_PKEY *pkey = NULL;
++	FILE *privkey;
++	CK_OBJECT_HANDLE  h_priv_key = CK_INVALID_HANDLE;
++	RSA *rsa = NULL;
++	PK11_SESSION *sp;
++	/* Anything else below is needed for the key by reference extension. */
++	CK_RV rv;
++	CK_BBOOL is_token = TRUE;
++	CK_BBOOL rollback = FALSE;
++	CK_BYTE attr_data[2][MAXATTR];
++	CK_OBJECT_CLASS key_class = CKO_PRIVATE_KEY;
++	CK_OBJECT_HANDLE ks_key = CK_INVALID_HANDLE;	/* key in keystore */
++
++	/* we look for private keys only */
++	CK_ATTRIBUTE search_templ[] =
++		{
++		{CKA_TOKEN, &is_token, sizeof(is_token)},
++		{CKA_CLASS, &key_class, sizeof(key_class)},
++		{CKA_LABEL, NULL, 0}
++		};
++
++	/*
++	 * These public attributes are needed to initialize the OpenSSL RSA
++	 * structure with something we can use to look up the key. Note that we
++	 * never ask for private components.
++	 */
++	CK_ATTRIBUTE get_templ[] =
++		{
++		{CKA_MODULUS, (void *)attr_data[0], MAXATTR},		/* n */
++		{CKA_PUBLIC_EXPONENT, (void *)attr_data[1], MAXATTR},	/* e */
++		};
++
++	if ((sp = pk11_get_session(OP_RSA)) == NULL)
++		return (NULL);
++
++	/*
++	 * Use simple scheme "pkcs11:<KEY_LABEL>" for now.
++	 */
++	if (strstr(privkey_file, "pkcs11:") == privkey_file)
++		{
++		search_templ[2].pValue = strstr(privkey_file, ":") + 1;
++		search_templ[2].ulValueLen = strlen(search_templ[2].pValue);
++
++		if (pk11_token_login(sp->session, &pk11_login_done,
++		    CK_TRUE) == 0)
++			goto err;
++
++		/*
++		 * Now let's try to find the key in the token. It is a failure
++		 * if we can't find it.
++		 */
++		if (find_one_object(OP_RSA, sp->session, search_templ, 3,
++		    &ks_key) == 0)
++			goto err;
++
++		if (hndidx_rsa == -1)
++			hndidx_rsa = RSA_get_ex_new_index(0,
++				        "pkcs11 RSA HSM key handle",
++					NULL, NULL, NULL);
++
++		/*
++		 * We might have a cache hit which we could confirm
++		 * according to the 'n'/'e' params, RSA public pointer
++		 * as NULL, and non-NULL RSA private pointer. However,
++		 * it is easier just to recreate everything. We expect
++		 * the keys to be loaded once and used many times. We
++		 * do not check the return value because even in case
++		 * of failure the sp structure will have both key
++		 * pointer and object handle cleaned and
++		 * pk11_destroy_object() reports the failure to the
++		 * OpenSSL error message buffer.
++		 */
++		(void) pk11_destroy_rsa_object_priv(sp, TRUE);
++
++		sp->opdata_rsa_priv_key = ks_key;
++		/* This object shall not be deleted on a cache miss. */
++		sp->priv_persistent = CK_TRUE;
++
++		/*
++		 * Cache the RSA private structure pointer. We do not
++		 * use it now for key-by-ref keys but let's do it for
++		 * consistency reasons.
++		 */
++		if ((rsa = sp->opdata_rsa_priv = RSA_new_method(e)) == NULL)
++			goto err;
++
++		/*
++		 * Now we have to initialize an OpenSSL RSA structure,
++		 * everything else is 0 or NULL.
++		 */
++		rsa->flags = RSA_FLAG_SIGN_VER | RSA_FLAG_EXT_PKEY;
++		RSA_set_ex_data(rsa, hndidx_rsa, (void *) ks_key);
++
++		if ((rv = pFuncList->C_GetAttributeValue(sp->session, ks_key,
++		    get_templ, 2)) != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_LOAD_PRIVKEY,
++					 PK11_R_GETATTRIBUTVALUE, rv);
++			goto err;
++			}
++
++		/*
++		 * We do not use pk11_get_private_rsa_key() here so we
++		 * must take care of handle management ourselves.
++		 */
++		KEY_HANDLE_REFHOLD(ks_key, OP_RSA, FALSE, rollback, err);
++
++		/*
++		 * Those are the sensitive components we do not want to export
++		 * from the token at all: rsa->(d|p|q|dmp1|dmq1|iqmp).
++		 */
++		attr_to_BN(&get_templ[0], attr_data[0], &rsa->n);
++		attr_to_BN(&get_templ[1], attr_data[1], &rsa->e);
++		/*
++		 * Must have 'n'/'e' components in the session structure as
++		 * well. They serve as a public look-up key for the private key
++		 * in the keystore.
++		 */
++		attr_to_BN(&get_templ[0], attr_data[0],
++			&sp->opdata_rsa_pn_num);
++		attr_to_BN(&get_templ[1], attr_data[1],
++			&sp->opdata_rsa_pe_num);
++
++		if ((pkey = EVP_PKEY_new()) == NULL)
++			goto err;
++
++		if (EVP_PKEY_assign_RSA(pkey, rsa) == 0)
++			goto err;
++		}
++	else if ((privkey = fopen(privkey_file, read_mode_flags)) != NULL)
++		{
++		pkey = PEM_read_PrivateKey(privkey, NULL, NULL, NULL);
++		(void) fclose(privkey);
++		if (pkey != NULL)
++			{
++			rsa = EVP_PKEY_get1_RSA(pkey);
++			if (rsa != NULL)
++				{
++				/*
++				 * This will always destroy the RSA
++				 * object since we have a new RSA
++				 * structure here.
++				 */
++				(void) check_new_rsa_key_priv(sp, rsa);
++				sp->priv_persistent = CK_FALSE;
++
++				h_priv_key = sp->opdata_rsa_priv_key =
++				    pk11_get_private_rsa_key(rsa,
++				    &sp->opdata_rsa_priv,
++				    &sp->opdata_rsa_d_num,
++				    &sp->opdata_rsa_pn_num,
++				    &sp->opdata_rsa_pe_num, sp->session);
++				if (h_priv_key == CK_INVALID_HANDLE)
++					goto err;
++				}
++			else
++				goto err;
++			}
++		}
++
++	pk11_return_session(sp, OP_RSA);
++	return (pkey);
++err:
++	pk11_return_session(sp, OP_RSA);
++	if (rsa != NULL)
++		RSA_free(rsa);
++	if (pkey != NULL)
++		{
++		EVP_PKEY_free(pkey);
++		pkey = NULL;
++		}
++	rollback = rollback;
++	return (pkey);
++	}
++
++/*
++ * Load RSA public key from a file or get its PKCS#11 handle if stored in the
++ * PKCS#11 token.
++ */
++/* ARGSUSED */
++EVP_PKEY *pk11_load_pubkey(ENGINE *e, const char *pubkey_file,
++	UI_METHOD *ui_method, void *callback_data)
++	{
++	EVP_PKEY *pkey = NULL;
++	FILE *pubkey;
++	CK_OBJECT_HANDLE h_pub_key = CK_INVALID_HANDLE;
++	RSA *rsa = NULL;
++	PK11_SESSION *sp;
++	/* Anything else below is needed for the key by reference extension. */
++	CK_RV rv;
++	CK_BBOOL is_token = TRUE;
++	CK_BYTE attr_data[2][MAXATTR];
++	CK_OBJECT_CLASS key_class = CKO_PUBLIC_KEY;
++	CK_OBJECT_HANDLE ks_key = CK_INVALID_HANDLE;	/* key in keystore */
++
++	/* we look for public keys only */
++	CK_ATTRIBUTE search_templ[] =
++		{
++		{CKA_TOKEN, &is_token, sizeof(is_token)},
++		{CKA_CLASS, &key_class, sizeof(key_class)},
++		{CKA_LABEL, NULL, 0}
++		};
++
++	/*
++	 * These public attributes are needed to initialize OpenSSL RSA
++	 * structure with something we can use to look up the key.
++	 */
++	CK_ATTRIBUTE get_templ[] =
++		{
++		{CKA_MODULUS, (void *)attr_data[0], MAXATTR},		/* n */
++		{CKA_PUBLIC_EXPONENT, (void *)attr_data[1], MAXATTR},	/* e */
++		};
++
++	if ((sp = pk11_get_session(OP_RSA)) == NULL)
++		return (NULL);
++
++	/*
++	 * Use simple scheme "pkcs11:<KEY_LABEL>" for now.
++	 */
++	if (strstr(pubkey_file, "pkcs11:") == pubkey_file)
++		{
++		search_templ[2].pValue = strstr(pubkey_file, ":") + 1;
++		search_templ[2].ulValueLen = strlen(search_templ[2].pValue);
++
++		if (pk11_token_login(sp->session, &pk11_login_done,
++		    CK_FALSE) == 0)
++			goto err;
++
++		/*
++		 * Now let's try to find the key in the token. It is a failure
++		 * if we can't find it.
++		 */
++		if (find_one_object(OP_RSA, sp->session, search_templ, 3,
++		    &ks_key) == 0)
++			goto err;
++
++		/*
++		 * We load a new public key so we will create a new RSA
++		 * structure. No cache hit is possible.
++		 */
++		(void) pk11_destroy_rsa_object_pub(sp, TRUE);
++
++		sp->opdata_rsa_pub_key = ks_key;
++		/* This object shall not be deleted on a cache miss. */
++		sp->pub_persistent = CK_TRUE;
++
++		/*
++		 * Cache the RSA public structure pointer.
++		 */
++		if ((rsa = sp->opdata_rsa_pub = RSA_new_method(e)) == NULL)
++			goto err;
++
++		/*
++		 * Now we have to initialize an OpenSSL RSA structure,
++		 * everything else is 0 or NULL.
++		 */
++		rsa->flags = RSA_FLAG_SIGN_VER;
++
++		if ((rv = pFuncList->C_GetAttributeValue(sp->session, ks_key,
++		    get_templ, 2)) != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_LOAD_PUBKEY,
++					 PK11_R_GETATTRIBUTVALUE, rv);
++			goto err;
++			}
++
++		attr_to_BN(&get_templ[0], attr_data[0], &rsa->n);
++		attr_to_BN(&get_templ[1], attr_data[1], &rsa->e);
++
++		if ((pkey = EVP_PKEY_new()) == NULL)
++			goto err;
++
++		if (EVP_PKEY_assign_RSA(pkey, rsa) == 0)
++			goto err;
++
++		/*
++		 * Create a session object from it so that when calling
++		 * pk11_get_public_rsa_key() the next time, we can find it. The
++		 * reason why we do that is that we cannot tell from the RSA
++		 * structure (OpenSSL RSA structure does not have any room for
++		 * additional data used by the engine, for example) if it bears
++		 * a public key stored in the keystore or not so it's better if
++		 * we always have a session key. Note that this is different
++		 * from what we do for the private keystore objects but in that
++		 * case, we can tell from the RSA structure that the keystore
++		 * object is in play - the 'd' component is NULL in that case.
++		 */
++		h_pub_key = sp->opdata_rsa_pub_key =
++		    pk11_get_public_rsa_key(rsa,
++		    &sp->opdata_rsa_pub, &sp->opdata_rsa_n_num,
++		    &sp->opdata_rsa_e_num, sp->session);
++		if (h_pub_key == CK_INVALID_HANDLE)
++			goto err;
++		}
++	else if ((pubkey = fopen(pubkey_file, read_mode_flags)) != NULL)
++		{
++		pkey = PEM_read_PUBKEY(pubkey, NULL, NULL, NULL);
++		(void) fclose(pubkey);
++		if (pkey != NULL)
++			{
++			rsa = EVP_PKEY_get1_RSA(pkey);
++			if (rsa != NULL)
++				{
++				/*
++				 * This will always destroy the RSA
++				 * object since we have a new RSA
++				 * structure here.
++				 */
++				(void) check_new_rsa_key_pub(sp, rsa);
++				sp->pub_persistent = CK_FALSE;
++
++				h_pub_key = sp->opdata_rsa_pub_key =
++				    pk11_get_public_rsa_key(rsa,
++				    &sp->opdata_rsa_pub, &sp->opdata_rsa_n_num,
++				    &sp->opdata_rsa_e_num, sp->session);
++				if (h_pub_key == CK_INVALID_HANDLE)
++					goto err;
++				}
++			else
++				goto err;
++			}
++		}
++
++	pk11_return_session(sp, OP_RSA);
++	return (pkey);
++err:
++	pk11_return_session(sp, OP_RSA);
++	if (rsa != NULL)
++		RSA_free(rsa);
++	if (pkey != NULL)
++		{
++		EVP_PKEY_free(pkey);
++		pkey = NULL;
++		}
++	return (pkey);
++	}
++
++/*
++ * Create a public key object in a session from a given rsa structure.
++ * The *rsa_n_num and *rsa_e_num pointers are non-NULL for RSA public keys.
++ */
++static CK_OBJECT_HANDLE pk11_get_public_rsa_key(RSA *rsa,
++    RSA **key_ptr, BIGNUM **rsa_n_num, BIGNUM **rsa_e_num,
++    CK_SESSION_HANDLE session)
++	{
++	CK_RV rv;
++	CK_OBJECT_HANDLE h_key = CK_INVALID_HANDLE;
++	CK_ULONG found;
++	CK_OBJECT_CLASS o_key = CKO_PUBLIC_KEY;
++	CK_KEY_TYPE k_type = CKK_RSA;
++	CK_ULONG ul_key_attr_count = 8;
++	CK_BBOOL rollback = FALSE;
++
++	CK_ATTRIBUTE  a_key_template[] =
++		{
++		{CKA_CLASS, (void *) NULL, sizeof (CK_OBJECT_CLASS)},
++		{CKA_KEY_TYPE, (void *) NULL, sizeof (CK_KEY_TYPE)},
++		{CKA_TOKEN, &false, sizeof (true)},
++		{CKA_ENCRYPT, &true, sizeof (true)},
++		{CKA_VERIFY, &true, sizeof (true)},
++		{CKA_VERIFY_RECOVER, &true, sizeof (true)},
++		{CKA_MODULUS, (void *)NULL, 0},
++		{CKA_PUBLIC_EXPONENT, (void *)NULL, 0}
++		};
++
++	int i;
++
++	a_key_template[0].pValue = &o_key;
++	a_key_template[1].pValue = &k_type;
++
++	a_key_template[6].ulValueLen = BN_num_bytes(rsa->n);
++	a_key_template[6].pValue = (CK_VOID_PTR)OPENSSL_malloc(
++		(size_t)a_key_template[6].ulValueLen);
++	if (a_key_template[6].pValue == NULL)
++		{
++		PK11err(PK11_F_GET_PUB_RSA_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
++
++	BN_bn2bin(rsa->n, a_key_template[6].pValue);
++
++	a_key_template[7].ulValueLen = BN_num_bytes(rsa->e);
++	a_key_template[7].pValue = (CK_VOID_PTR)OPENSSL_malloc(
++		(size_t)a_key_template[7].ulValueLen);
++	if (a_key_template[7].pValue == NULL)
++		{
++		PK11err(PK11_F_GET_PUB_RSA_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
++
++	BN_bn2bin(rsa->e, a_key_template[7].pValue);
++
++	/* see find_lock array definition for more info on object locking */
++	LOCK_OBJSTORE(OP_RSA);
++
++	rv = pFuncList->C_FindObjectsInit(session, a_key_template,
++		ul_key_attr_count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PUB_RSA_KEY,
++		    PK11_R_FINDOBJECTSINIT, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjects(session, &h_key, 1, &found);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PUB_RSA_KEY,
++		    PK11_R_FINDOBJECTS, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjectsFinal(session);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PUB_RSA_KEY,
++		    PK11_R_FINDOBJECTSFINAL, rv);
++		goto err;
++		}
++
++	if (found == 0)
++		{
++		rv = pFuncList->C_CreateObject(session,
++			a_key_template, ul_key_attr_count, &h_key);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_GET_PUB_RSA_KEY,
++			    PK11_R_CREATEOBJECT, rv);
++			goto err;
++			}
++		}
++
++	if (rsa_n_num != NULL)
++		if ((*rsa_n_num = BN_dup(rsa->n)) == NULL)
++			{
++			PK11err(PK11_F_GET_PUB_RSA_KEY, PK11_R_MALLOC_FAILURE);
++			rollback = TRUE;
++			goto err;
++			}
++	if (rsa_e_num != NULL)
++		if ((*rsa_e_num = BN_dup(rsa->e)) == NULL)
++			{
++			PK11err(PK11_F_GET_PUB_RSA_KEY, PK11_R_MALLOC_FAILURE);
++			BN_free(*rsa_n_num);
++			*rsa_n_num = NULL;
++			rollback = TRUE;
++			goto err;
++			}
++
++	/* LINTED: E_CONSTANT_CONDITION */
++	KEY_HANDLE_REFHOLD(h_key, OP_RSA, FALSE, rollback, err);
++	if (key_ptr != NULL)
++		*key_ptr = rsa;
++
++err:
++	if (rollback)
++		{
++		/*
++		 * We do not care about the return value from C_DestroyObject()
++		 * since we are doing rollback.
++		 */
++		if (found == 0)
++			(void) pFuncList->C_DestroyObject(session, h_key);
++		h_key = CK_INVALID_HANDLE;
++		}
++
++	UNLOCK_OBJSTORE(OP_RSA);
++
++malloc_err:
++	for (i = 6; i <= 7; i++)
++		{
++		if (a_key_template[i].pValue != NULL)
++			{
++			OPENSSL_free(a_key_template[i].pValue);
++			a_key_template[i].pValue = NULL;
++			}
++		}
++
++	return (h_key);
++	}
++
++/*
++ * Create a private key object in the session from a given rsa structure.
++ * The *rsa_d_num pointer is non-NULL for RSA private keys.
++ */
++static CK_OBJECT_HANDLE
++pk11_get_private_rsa_key(RSA *rsa, RSA **key_ptr, BIGNUM **rsa_d_num,
++    BIGNUM **rsa_n_num, BIGNUM **rsa_e_num, CK_SESSION_HANDLE session)
++	{
++	CK_RV rv;
++	CK_OBJECT_HANDLE h_key = CK_INVALID_HANDLE;
++	int i;
++	CK_ULONG found;
++	CK_OBJECT_CLASS o_key = CKO_PRIVATE_KEY;
++	CK_KEY_TYPE k_type = CKK_RSA;
++	CK_ULONG ul_key_attr_count = 14;
++	CK_BBOOL rollback = FALSE;
++
++	/* Both CKA_TOKEN and CKA_SENSITIVE have to be FALSE for session keys */
++	CK_ATTRIBUTE  a_key_template[] =
++		{
++		{CKA_CLASS, (void *) NULL, sizeof (CK_OBJECT_CLASS)},
++		{CKA_KEY_TYPE, (void *) NULL, sizeof (CK_KEY_TYPE)},
++		{CKA_TOKEN, &false, sizeof (true)},
++		{CKA_SENSITIVE, &false, sizeof (true)},
++		{CKA_DECRYPT, &true, sizeof (true)},
++		{CKA_SIGN, &true, sizeof (true)},
++		{CKA_MODULUS, (void *)NULL, 0},
++		{CKA_PUBLIC_EXPONENT, (void *)NULL, 0},
++		{CKA_PRIVATE_EXPONENT, (void *)NULL, 0},
++		{CKA_PRIME_1, (void *)NULL, 0},
++		{CKA_PRIME_2, (void *)NULL, 0},
++		{CKA_EXPONENT_1, (void *)NULL, 0},
++		{CKA_EXPONENT_2, (void *)NULL, 0},
++		{CKA_COEFFICIENT, (void *)NULL, 0},
++		};
++
++	if ((rsa->flags & RSA_FLAG_EXT_PKEY) != 0) {
++		h_key = (CK_OBJECT_HANDLE)RSA_get_ex_data(rsa, hndidx_rsa);
++		LOCK_OBJSTORE(OP_RSA);
++		goto set;
++	}
++	
++	a_key_template[0].pValue = &o_key;
++	a_key_template[1].pValue = &k_type;
++
++	/* Put the private key components into the template */
++	if (init_template_value(rsa->n, &a_key_template[6].pValue,
++		&a_key_template[6].ulValueLen) == 0 ||
++	    init_template_value(rsa->e, &a_key_template[7].pValue,
++		&a_key_template[7].ulValueLen) == 0 ||
++	    init_template_value(rsa->d, &a_key_template[8].pValue,
++		&a_key_template[8].ulValueLen) == 0 ||
++	    init_template_value(rsa->p, &a_key_template[9].pValue,
++		&a_key_template[9].ulValueLen) == 0 ||
++	    init_template_value(rsa->q, &a_key_template[10].pValue,
++		&a_key_template[10].ulValueLen) == 0 ||
++	    init_template_value(rsa->dmp1, &a_key_template[11].pValue,
++		&a_key_template[11].ulValueLen) == 0 ||
++	    init_template_value(rsa->dmq1, &a_key_template[12].pValue,
++		&a_key_template[12].ulValueLen) == 0 ||
++	    init_template_value(rsa->iqmp, &a_key_template[13].pValue,
++		&a_key_template[13].ulValueLen) == 0)
++		{
++		PK11err(PK11_F_GET_PRIV_RSA_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
++
++	/* see find_lock array definition for more info on object locking */
++	LOCK_OBJSTORE(OP_RSA);
++
++	/*
++	 * We are getting the private key but the private 'd'
++	 * component is NULL.  That means this is key by reference RSA
++	 * key. In that case, we can use only public components for
++	 * searching for the private key handle.
++	 */
++	if (rsa->d == NULL)
++		{
++		ul_key_attr_count = 8;
++		/*
++		 * We will perform the search in the token, not in the existing
++		 * session keys.
++		 */
++		a_key_template[2].pValue = &true;
++		}
++
++	rv = pFuncList->C_FindObjectsInit(session, a_key_template,
++		ul_key_attr_count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PRIV_RSA_KEY,
++		    PK11_R_FINDOBJECTSINIT, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjects(session, &h_key, 1, &found);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PRIV_RSA_KEY,
++		    PK11_R_FINDOBJECTS, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjectsFinal(session);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PRIV_RSA_KEY,
++		    PK11_R_FINDOBJECTSFINAL, rv);
++		goto err;
++		}
++
++	if (found == 0)
++		{
++		/*
++		 * We have an RSA structure with 'n'/'e' components
++		 * only so we tried to find the private key in the
++		 * keystore. If it was really a token key we have a
++		 * problem. Note that for other key types we just
++		 * create a new session key using the private
++		 * components from the RSA structure.
++		 */
++		if (rsa->d == NULL)
++			{
++			PK11err(PK11_F_GET_PRIV_RSA_KEY,
++			    PK11_R_PRIV_KEY_NOT_FOUND);
++			goto err;
++			}
++
++		rv = pFuncList->C_CreateObject(session,
++			a_key_template, ul_key_attr_count, &h_key);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_GET_PRIV_RSA_KEY,
++				PK11_R_CREATEOBJECT, rv);
++			goto err;
++			}
++		}
++
++set:
++	if (rsa_d_num != NULL)
++		{
++		/*
++		 * When RSA keys by reference code is used, we never
++		 * extract private components from the keystore. In
++		 * that case 'd' was set to NULL and we expect the
++		 * application to properly cope with that. It is
++		 * documented in openssl(5). In general, if keys by
++		 * reference are used we expect it to be used
++		 * exclusively using the high level API and then there
++		 * is no problem. If the application expects the
++		 * private components to be read from the keystore
++		 * then that is not a supported way of usage.
++		 */
++		if (rsa->d != NULL && (*rsa_d_num = BN_dup(rsa->d)) == NULL)
++			{
++			PK11err(PK11_F_GET_PRIV_RSA_KEY, PK11_R_MALLOC_FAILURE);
++			rollback = TRUE;
++			goto err;
++			}
++		else
++			*rsa_d_num = NULL;
++		}
++
++	/*
++	 * For the key by reference code, we need public components as well
++	 * since 'd' component is always NULL. For that reason, we always cache
++	 * 'n'/'e' components as well.
++	 */
++	*rsa_n_num = BN_dup(rsa->n);
++	*rsa_e_num = BN_dup(rsa->e);
++
++	/* LINTED: E_CONSTANT_CONDITION */
++	KEY_HANDLE_REFHOLD(h_key, OP_RSA, FALSE, rollback, err);
++	if (key_ptr != NULL)
++		*key_ptr = rsa;
++
++err:
++	if (rollback)
++		{
++		/*
++		 * We do not care about the return value from C_DestroyObject()
++		 * since we are doing rollback.
++		 */
++		if (found == 0 &&
++		    (rsa->flags & RSA_FLAG_EXT_PKEY) == 0)
++			(void) pFuncList->C_DestroyObject(session, h_key);
++		h_key = CK_INVALID_HANDLE;
++		}
++
++	UNLOCK_OBJSTORE(OP_RSA);
++
++malloc_err:
++	/*
++	 * 6 to 13 entries in the key template are key components.
++	 * They need to be freed upon exit or error.
++	 */
++	for (i = 6; i <= 13; i++)
++		{
++		if (a_key_template[i].pValue != NULL)
++			{
++			(void) memset(a_key_template[i].pValue, 0,
++				a_key_template[i].ulValueLen);
++			OPENSSL_free(a_key_template[i].pValue);
++			a_key_template[i].pValue = NULL;
++			}
++		}
++
++	return (h_key);
++	}
++
++/*
++ * Check for cache miss and clean the object pointer and handle
++ * in such case. Return 1 for cache hit, 0 for cache miss.
++ */
++static int check_new_rsa_key_pub(PK11_SESSION *sp, const RSA *rsa)
++	{
++	/*
++	 * Provide protection against RSA structure reuse by making the
++	 * check for cache hit stronger. Only public components of RSA
++	 * key matter here so it is sufficient to compare them with values
++	 * cached in PK11_SESSION structure.
++	 *
++	 * We must check the handle as well since with key by reference, public
++	 * components 'n'/'e' are cached in private keys as well. That means we
++	 * could have a cache hit in a private key when looking for a public
++	 * key. That would not work, you cannot have one PKCS#11 object for
++	 * both data signing and verifying.
++	 */
++	if ((sp->opdata_rsa_pub != rsa) ||
++	    (BN_cmp(sp->opdata_rsa_n_num, rsa->n) != 0) ||
++	    (BN_cmp(sp->opdata_rsa_e_num, rsa->e) != 0) ||
++	    (sp->opdata_rsa_priv_key != CK_INVALID_HANDLE))
++		{
++		/*
++		 * We do not check the return value because even in case of
++		 * failure the sp structure will have both key pointer
++		 * and object handle cleaned and pk11_destroy_object()
++		 * reports the failure to the OpenSSL error message buffer.
++		 */
++		(void) pk11_destroy_rsa_object_pub(sp, TRUE);
++		return (0);
++		}
++	return (1);
++	}
++
++/*
++ * Check for cache miss and clean the object pointer and handle
++ * in such case. Return 1 for cache hit, 0 for cache miss.
++ */
++static int check_new_rsa_key_priv(PK11_SESSION *sp, const RSA *rsa)
++	{
++	/*
++	 * Provide protection against RSA structure reuse by making
++	 * the check for cache hit stronger. Comparing public exponent
++	 * of RSA key with value cached in PK11_SESSION structure
++	 * should be sufficient. Note that we want to compare the
++	 * public component since with the keys by reference
++	 * mechanism, private components are not in the RSA
++	 * structure. Also, see check_new_rsa_key_pub() about why we
++	 * compare the handle as well.
++	 */
++	if ((sp->opdata_rsa_priv != rsa) ||
++	    (BN_cmp(sp->opdata_rsa_pn_num, rsa->n) != 0) ||
++	    (BN_cmp(sp->opdata_rsa_pe_num, rsa->e) != 0) ||
++	    (sp->opdata_rsa_pn_num == NULL) ||
++	    (sp->opdata_rsa_pe_num == NULL) ||
++	    (sp->opdata_rsa_pub_key != CK_INVALID_HANDLE))
++		{
++		/*
++		 * We do not check the return value because even in case of
++		 * failure the sp structure will have both key pointer
++		 * and object handle cleaned and pk11_destroy_object()
++		 * reports the failure to the OpenSSL error message buffer.
++		 */
++		(void) pk11_destroy_rsa_object_priv(sp, TRUE);
++		return (0);
++		}
++	return (1);
++	}
++#endif
++
++#ifndef OPENSSL_NO_DSA
++/* The DSA function implementation */
++/* ARGSUSED */
++static int pk11_DSA_init(DSA *dsa)
++	{
++	return (1);
++	}
++
++/* ARGSUSED */
++static int pk11_DSA_finish(DSA *dsa)
++	{
++	return (1);
++	}
++
++
++static DSA_SIG *
++pk11_dsa_do_sign(const unsigned char *dgst, int dlen, DSA *dsa)
++	{
++	BIGNUM *r = NULL, *s = NULL;
++	int i;
++	DSA_SIG *dsa_sig = NULL;
++
++	CK_RV rv;
++	CK_MECHANISM Mechanism_dsa = {CKM_DSA, NULL, 0};
++	CK_MECHANISM *p_mech = &Mechanism_dsa;
++	CK_OBJECT_HANDLE h_priv_key;
++
++	/*
++	 * The signature is the concatenation of r and s,
++	 * each is 20 bytes long
++	 */
++	unsigned char sigret[DSA_SIGNATURE_LEN];
++	unsigned long siglen = DSA_SIGNATURE_LEN;
++	unsigned int siglen2 = DSA_SIGNATURE_LEN / 2;
++
++	PK11_SESSION *sp = NULL;
++
++	if ((dsa->p == NULL) || (dsa->q == NULL) || (dsa->g == NULL))
++		{
++		PK11err(PK11_F_DSA_SIGN, PK11_R_MISSING_KEY_COMPONENT);
++		goto ret;
++		}
++
++	i = BN_num_bytes(dsa->q); /* should be 20 */
++	if (dlen > i)
++		{
++		PK11err(PK11_F_DSA_SIGN, PK11_R_INVALID_SIGNATURE_LENGTH);
++		goto ret;
++		}
++
++	if ((sp = pk11_get_session(OP_DSA)) == NULL)
++		goto ret;
++
++	(void) check_new_dsa_key_priv(sp, dsa);
++
++	h_priv_key = sp->opdata_dsa_priv_key;
++	if (h_priv_key == CK_INVALID_HANDLE)
++		h_priv_key = sp->opdata_dsa_priv_key =
++			pk11_get_private_dsa_key((DSA *)dsa,
++			    &sp->opdata_dsa_priv,
++			    &sp->opdata_dsa_priv_num, sp->session);
++
++	if (h_priv_key != CK_INVALID_HANDLE)
++		{
++		rv = pFuncList->C_SignInit(sp->session, p_mech, h_priv_key);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_DSA_SIGN, PK11_R_SIGNINIT, rv);
++			goto ret;
++			}
++
++		(void) memset(sigret, 0, siglen);
++		rv = pFuncList->C_Sign(sp->session,
++			(unsigned char*) dgst, dlen, sigret,
++			(CK_ULONG_PTR) &siglen);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_DSA_SIGN, PK11_R_SIGN, rv);
++			goto ret;
++			}
++		}
++
++
++	if ((s = BN_new()) == NULL)
++		{
++		PK11err(PK11_F_DSA_SIGN, PK11_R_MALLOC_FAILURE);
++		goto ret;
++		}
++
++	if ((r = BN_new()) == NULL)
++		{
++		PK11err(PK11_F_DSA_SIGN, PK11_R_MALLOC_FAILURE);
++		goto ret;
++		}
++
++	if ((dsa_sig = DSA_SIG_new()) == NULL)
++		{
++		PK11err(PK11_F_DSA_SIGN, PK11_R_MALLOC_FAILURE);
++		goto ret;
++		}
++
++	if (BN_bin2bn(sigret, siglen2, r) == NULL ||
++	    BN_bin2bn(&sigret[siglen2], siglen2, s) == NULL)
++		{
++		PK11err(PK11_F_DSA_SIGN, PK11_R_MALLOC_FAILURE);
++		goto ret;
++		}
++
++	dsa_sig->r = r;
++	dsa_sig->s = s;
++
++ret:
++	if (dsa_sig == NULL)
++		{
++		if (r != NULL)
++			BN_free(r);
++		if (s != NULL)
++			BN_free(s);
++		}
++
++	pk11_return_session(sp, OP_DSA);
++	return (dsa_sig);
++	}
++
++static int
++pk11_dsa_do_verify(const unsigned char *dgst, int dlen, DSA_SIG *sig,
++	DSA *dsa)
++	{
++	int i;
++	CK_RV rv;
++	int retval = 0;
++	CK_MECHANISM Mechanism_dsa = {CKM_DSA, NULL, 0};
++	CK_MECHANISM *p_mech = &Mechanism_dsa;
++	CK_OBJECT_HANDLE h_pub_key;
++
++	unsigned char sigbuf[DSA_SIGNATURE_LEN];
++	unsigned long siglen = DSA_SIGNATURE_LEN;
++	unsigned long siglen2 = DSA_SIGNATURE_LEN/2;
++
++	PK11_SESSION *sp = NULL;
++
++	if (BN_is_zero(sig->r) || sig->r->neg || BN_ucmp(sig->r, dsa->q) >= 0)
++		{
++		PK11err(PK11_F_DSA_VERIFY,
++			PK11_R_INVALID_DSA_SIGNATURE_R);
++		goto ret;
++		}
++
++	if (BN_is_zero(sig->s) || sig->s->neg || BN_ucmp(sig->s, dsa->q) >= 0)
++		{
++		PK11err(PK11_F_DSA_VERIFY,
++			PK11_R_INVALID_DSA_SIGNATURE_S);
++		goto ret;
++		}
++
++	i = BN_num_bytes(dsa->q); /* should be 20 */
++
++	if (dlen > i)
++		{
++		PK11err(PK11_F_DSA_VERIFY,
++			PK11_R_INVALID_SIGNATURE_LENGTH);
++		goto ret;
++		}
++
++	if ((sp = pk11_get_session(OP_DSA)) == NULL)
++		goto ret;
++
++	(void) check_new_dsa_key_pub(sp, dsa);
++
++	h_pub_key = sp->opdata_dsa_pub_key;
++	if (h_pub_key == CK_INVALID_HANDLE)
++		h_pub_key = sp->opdata_dsa_pub_key =
++			pk11_get_public_dsa_key((DSA *)dsa, &sp->opdata_dsa_pub,
++			    &sp->opdata_dsa_pub_num, sp->session);
++
++	if (h_pub_key != CK_INVALID_HANDLE)
++		{
++		rv = pFuncList->C_VerifyInit(sp->session, p_mech,
++			h_pub_key);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_DSA_VERIFY, PK11_R_VERIFYINIT,
++			    rv);
++			goto ret;
++			}
++
++		/*
++		 * The representation of each of the two big numbers could
++		 * be shorter than DSA_SIGNATURE_LEN/2 bytes so we need
++		 * to act accordingly and shift if necessary.
++		 */
++		(void) memset(sigbuf, 0, siglen);
++		BN_bn2bin(sig->r, sigbuf + siglen2 - BN_num_bytes(sig->r));
++		BN_bn2bin(sig->s, &sigbuf[siglen2] + siglen2 -
++		    BN_num_bytes(sig->s));
++
++		rv = pFuncList->C_Verify(sp->session,
++			(unsigned char *) dgst, dlen, sigbuf, (CK_ULONG)siglen);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_DSA_VERIFY, PK11_R_VERIFY, rv);
++			goto ret;
++			}
++		}
++
++	retval = 1;
++ret:
++
++	pk11_return_session(sp, OP_DSA);
++	return (retval);
++	}
++
++
++/*
++ * Create a public key object in a session from a given dsa structure.
++ * The *dsa_pub_num pointer is non-NULL for DSA public keys.
++ */
++static CK_OBJECT_HANDLE pk11_get_public_dsa_key(DSA* dsa,
++    DSA **key_ptr, BIGNUM **dsa_pub_num, CK_SESSION_HANDLE session)
++	{
++	CK_RV rv;
++	CK_OBJECT_CLASS o_key = CKO_PUBLIC_KEY;
++	CK_OBJECT_HANDLE h_key = CK_INVALID_HANDLE;
++	CK_ULONG found;
++	CK_KEY_TYPE k_type = CKK_DSA;
++	CK_ULONG ul_key_attr_count = 8;
++	CK_BBOOL rollback = FALSE;
++	int i;
++
++	CK_ATTRIBUTE  a_key_template[] =
++		{
++		{CKA_CLASS, (void *) NULL, sizeof (CK_OBJECT_CLASS)},
++		{CKA_KEY_TYPE, (void *) NULL, sizeof (CK_KEY_TYPE)},
++		{CKA_TOKEN, &false, sizeof (true)},
++		{CKA_VERIFY, &true, sizeof (true)},
++		{CKA_PRIME, (void *)NULL, 0},		/* p */
++		{CKA_SUBPRIME, (void *)NULL, 0},	/* q */
++		{CKA_BASE, (void *)NULL, 0},		/* g */
++		{CKA_VALUE, (void *)NULL, 0}		/* pub_key - y */
++		};
++
++	a_key_template[0].pValue = &o_key;
++	a_key_template[1].pValue = &k_type;
++
++	if (init_template_value(dsa->p, &a_key_template[4].pValue,
++		&a_key_template[4].ulValueLen) == 0 ||
++	    init_template_value(dsa->q, &a_key_template[5].pValue,
++		&a_key_template[5].ulValueLen) == 0 ||
++	    init_template_value(dsa->g, &a_key_template[6].pValue,
++		&a_key_template[6].ulValueLen) == 0 ||
++	    init_template_value(dsa->pub_key, &a_key_template[7].pValue,
++		&a_key_template[7].ulValueLen) == 0)
++		{
++		PK11err(PK11_F_GET_PUB_DSA_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
++
++	/* see find_lock array definition for more info on object locking */
++	LOCK_OBJSTORE(OP_DSA);
++	rv = pFuncList->C_FindObjectsInit(session, a_key_template,
++		ul_key_attr_count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PUB_DSA_KEY,
++		    PK11_R_FINDOBJECTSINIT, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjects(session, &h_key, 1, &found);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PUB_DSA_KEY,
++		    PK11_R_FINDOBJECTS, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjectsFinal(session);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PUB_DSA_KEY,
++		    PK11_R_FINDOBJECTSFINAL, rv);
++		goto err;
++		}
++
++	if (found == 0)
++		{
++		rv = pFuncList->C_CreateObject(session,
++			a_key_template, ul_key_attr_count, &h_key);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_GET_PUB_DSA_KEY,
++			    PK11_R_CREATEOBJECT, rv);
++			goto err;
++			}
++		}
++
++	if (dsa_pub_num != NULL)
++		if ((*dsa_pub_num = BN_dup(dsa->pub_key)) == NULL)
++			{
++			PK11err(PK11_F_GET_PUB_DSA_KEY, PK11_R_MALLOC_FAILURE);
++			rollback = TRUE;
++			goto err;
++			}
++
++	/* LINTED: E_CONSTANT_CONDITION */
++	KEY_HANDLE_REFHOLD(h_key, OP_DSA, FALSE, rollback, err);
++	if (key_ptr != NULL)
++		*key_ptr = dsa;
++
++err:
++	if (rollback)
++		{
++		/*
++		 * We do not care about the return value from C_DestroyObject()
++		 * since we are doing rollback.
++		 */
++		if (found == 0)
++			(void) pFuncList->C_DestroyObject(session, h_key);
++		h_key = CK_INVALID_HANDLE;
++		}
++
++	UNLOCK_OBJSTORE(OP_DSA);
++
++malloc_err:
++	for (i = 4; i <= 7; i++)
++		{
++		if (a_key_template[i].pValue != NULL)
++			{
++			OPENSSL_free(a_key_template[i].pValue);
++			a_key_template[i].pValue = NULL;
++			}
++		}
++
++	return (h_key);
++	}
++
++/*
++ * Create a private key object in the session from a given dsa structure
++ * The *dsa_priv_num pointer is non-NULL for DSA private keys.
++ */
++static CK_OBJECT_HANDLE pk11_get_private_dsa_key(DSA* dsa,
++    DSA **key_ptr, BIGNUM **dsa_priv_num, CK_SESSION_HANDLE session)
++	{
++	CK_RV rv;
++	CK_OBJECT_HANDLE h_key = CK_INVALID_HANDLE;
++	CK_OBJECT_CLASS o_key = CKO_PRIVATE_KEY;
++	int i;
++	CK_ULONG found;
++	CK_KEY_TYPE k_type = CKK_DSA;
++	CK_ULONG ul_key_attr_count = 9;
++	CK_BBOOL rollback = FALSE;
++
++	/* Both CKA_TOKEN and CKA_SENSITIVE have to be FALSE for session keys */
++	CK_ATTRIBUTE  a_key_template[] =
++		{
++		{CKA_CLASS, (void *) NULL, sizeof (CK_OBJECT_CLASS)},
++		{CKA_KEY_TYPE, (void *) NULL, sizeof (CK_KEY_TYPE)},
++		{CKA_TOKEN, &false, sizeof (true)},
++		{CKA_SENSITIVE, &false, sizeof (true)},
++		{CKA_SIGN, &true, sizeof (true)},
++		{CKA_PRIME, (void *)NULL, 0},		/* p */
++		{CKA_SUBPRIME, (void *)NULL, 0},	/* q */
++		{CKA_BASE, (void *)NULL, 0},		/* g */
++		{CKA_VALUE, (void *)NULL, 0}		/* priv_key - x */
++		};
++
++	a_key_template[0].pValue = &o_key;
++	a_key_template[1].pValue = &k_type;
++
++	/* Put the private key components into the template */
++	if (init_template_value(dsa->p, &a_key_template[5].pValue,
++		&a_key_template[5].ulValueLen) == 0 ||
++	    init_template_value(dsa->q, &a_key_template[6].pValue,
++		&a_key_template[6].ulValueLen) == 0 ||
++	    init_template_value(dsa->g, &a_key_template[7].pValue,
++		&a_key_template[7].ulValueLen) == 0 ||
++	    init_template_value(dsa->priv_key, &a_key_template[8].pValue,
++		&a_key_template[8].ulValueLen) == 0)
++		{
++		PK11err(PK11_F_GET_PRIV_DSA_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
++
++	/* see find_lock array definition for more info on object locking */
++	LOCK_OBJSTORE(OP_DSA);
++	rv = pFuncList->C_FindObjectsInit(session, a_key_template,
++		ul_key_attr_count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PRIV_DSA_KEY,
++		    PK11_R_FINDOBJECTSINIT, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjects(session, &h_key, 1, &found);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PRIV_DSA_KEY,
++		    PK11_R_FINDOBJECTS, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjectsFinal(session);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PRIV_DSA_KEY,
++		    PK11_R_FINDOBJECTSFINAL, rv);
++		goto err;
++		}
++
++	if (found == 0)
++		{
++		rv = pFuncList->C_CreateObject(session,
++			a_key_template, ul_key_attr_count, &h_key);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_GET_PRIV_DSA_KEY,
++			    PK11_R_CREATEOBJECT, rv);
++			goto err;
++			}
++		}
++
++	if (dsa_priv_num != NULL)
++		if ((*dsa_priv_num = BN_dup(dsa->priv_key)) == NULL)
++			{
++			PK11err(PK11_F_GET_PRIV_DSA_KEY, PK11_R_MALLOC_FAILURE);
++			rollback = TRUE;
++			goto err;
++			}
++
++	/* LINTED: E_CONSTANT_CONDITION */
++	KEY_HANDLE_REFHOLD(h_key, OP_DSA, FALSE, rollback, err);
++	if (key_ptr != NULL)
++		*key_ptr = dsa;
++
++err:
++	if (rollback)
++		{
++		/*
++		 * We do not care about the return value from C_DestroyObject()
++		 * since we are doing rollback.
++		 */
++		if (found == 0)
++			(void) pFuncList->C_DestroyObject(session, h_key);
++		h_key = CK_INVALID_HANDLE;
++		}
++
++	UNLOCK_OBJSTORE(OP_DSA);
++
++malloc_err:
++	/*
++	 * 5 to 8 entries in the key template are key components.
++	 * They need to be freed apon exit or error.
++	 */
++	for (i = 5; i <= 8; i++)
++		{
++		if (a_key_template[i].pValue != NULL)
++			{
++			(void) memset(a_key_template[i].pValue, 0,
++				a_key_template[i].ulValueLen);
++			OPENSSL_free(a_key_template[i].pValue);
++			a_key_template[i].pValue = NULL;
++			}
++		}
++
++	return (h_key);
++	}
++
++/*
++ * Check for cache miss and clean the object pointer and handle
++ * in such case. Return 1 for cache hit, 0 for cache miss.
++ */
++static int check_new_dsa_key_pub(PK11_SESSION *sp, DSA *dsa)
++	{
++	/*
++	 * Provide protection against DSA structure reuse by making the
++	 * check for cache hit stronger. Only public key component of DSA
++	 * key matters here so it is sufficient to compare it with value
++	 * cached in PK11_SESSION structure.
++	 */
++	if ((sp->opdata_dsa_pub != dsa) ||
++	    (BN_cmp(sp->opdata_dsa_pub_num, dsa->pub_key) != 0))
++		{
++		/*
++		 * We do not check the return value because even in case of
++		 * failure the sp structure will have both key pointer
++		 * and object handle cleaned and pk11_destroy_object()
++		 * reports the failure to the OpenSSL error message buffer.
++		 */
++		(void) pk11_destroy_dsa_object_pub(sp, TRUE);
++		return (0);
++		}
++	return (1);
++	}
++
++/*
++ * Check for cache miss and clean the object pointer and handle
++ * in such case. Return 1 for cache hit, 0 for cache miss.
++ */
++static int check_new_dsa_key_priv(PK11_SESSION *sp, DSA *dsa)
++	{
++	/*
++	 * Provide protection against DSA structure reuse by making the
++	 * check for cache hit stronger. Only private key component of DSA
++	 * key matters here so it is sufficient to compare it with value
++	 * cached in PK11_SESSION structure.
++	 */
++	if ((sp->opdata_dsa_priv != dsa) ||
++	    (BN_cmp(sp->opdata_dsa_priv_num, dsa->priv_key) != 0))
++		{
++		/*
++		 * We do not check the return value because even in case of
++		 * failure the sp structure will have both key pointer
++		 * and object handle cleaned and pk11_destroy_object()
++		 * reports the failure to the OpenSSL error message buffer.
++		 */
++		(void) pk11_destroy_dsa_object_priv(sp, TRUE);
++		return (0);
++		}
++	return (1);
++	}
++#endif
++
++
++#ifndef OPENSSL_NO_DH
++/* The DH function implementation */
++/* ARGSUSED */
++static int pk11_DH_init(DH *dh)
++	{
++	return (1);
++	}
++
++/* ARGSUSED */
++static int pk11_DH_finish(DH *dh)
++	{
++	return (1);
++	}
++
++/*
++ * Generate DH key-pair.
++ *
++ * Warning: Unlike OpenSSL's DH_generate_key(3) we ignore dh->priv_key
++ * and override it even if it is set. OpenSSL does not touch dh->priv_key
++ * if set and just computes dh->pub_key. It looks like PKCS#11 standard
++ * is not capable of providing this functionality. This could be a problem
++ * for applications relying on OpenSSL's semantics.
++ */
++static int pk11_DH_generate_key(DH *dh)
++	{
++	CK_ULONG i;
++	CK_RV rv, rv1;
++	int reuse_mem_len = 0, ret = 0;
++	PK11_SESSION *sp = NULL;
++	CK_BYTE_PTR reuse_mem;
++
++	CK_MECHANISM mechanism = {CKM_DH_PKCS_KEY_PAIR_GEN, NULL_PTR, 0};
++	CK_OBJECT_HANDLE h_pub_key = CK_INVALID_HANDLE;
++	CK_OBJECT_HANDLE h_priv_key = CK_INVALID_HANDLE;
++
++	CK_ULONG ul_pub_key_attr_count = 3;
++	CK_ATTRIBUTE pub_key_template[] =
++		{
++		{CKA_PRIVATE, &false, sizeof (false)},
++		{CKA_PRIME, (void *)NULL, 0},
++		{CKA_BASE, (void *)NULL, 0}
++		};
++
++	CK_ULONG ul_priv_key_attr_count = 3;
++	CK_ATTRIBUTE priv_key_template[] =
++		{
++		{CKA_PRIVATE, &false, sizeof (false)},
++		{CKA_SENSITIVE, &false, sizeof (false)},
++		{CKA_DERIVE, &true, sizeof (true)}
++		};
++
++	CK_ULONG pub_key_attr_result_count = 1;
++	CK_ATTRIBUTE pub_key_result[] =
++		{
++		{CKA_VALUE, (void *)NULL, 0}
++		};
++
++	CK_ULONG priv_key_attr_result_count = 1;
++	CK_ATTRIBUTE priv_key_result[] =
++		{
++		{CKA_VALUE, (void *)NULL, 0}
++		};
++
++	pub_key_template[1].ulValueLen = BN_num_bytes(dh->p);
++	if (pub_key_template[1].ulValueLen > 0)
++		{
++		/*
++		 * We must not increase ulValueLen by DH_BUF_RESERVE since that
++		 * could cause the same rounding problem. See definition of
++		 * DH_BUF_RESERVE above.
++		 */
++		pub_key_template[1].pValue =
++			OPENSSL_malloc(pub_key_template[1].ulValueLen +
++			DH_BUF_RESERVE);
++		if (pub_key_template[1].pValue == NULL)
++			{
++			PK11err(PK11_F_DH_GEN_KEY, PK11_R_MALLOC_FAILURE);
++			goto err;
++			}
++
++		i = BN_bn2bin(dh->p, pub_key_template[1].pValue);
++		}
++	else
++		goto err;
++
++	pub_key_template[2].ulValueLen = BN_num_bytes(dh->g);
++	if (pub_key_template[2].ulValueLen > 0)
++		{
++		pub_key_template[2].pValue =
++			OPENSSL_malloc(pub_key_template[2].ulValueLen +
++			DH_BUF_RESERVE);
++		if (pub_key_template[2].pValue == NULL)
++			{
++			PK11err(PK11_F_DH_GEN_KEY, PK11_R_MALLOC_FAILURE);
++			goto err;
++			}
++
++		i = BN_bn2bin(dh->g, pub_key_template[2].pValue);
++		}
++	else
++		goto err;
++
++	/*
++	 * Note: we are only using PK11_SESSION structure for getting
++	 *	 a session handle. The objects created in this function are
++	 *	 destroyed before return and thus not cached.
++	 */
++	if ((sp = pk11_get_session(OP_DH)) == NULL)
++		goto err;
++
++	rv = pFuncList->C_GenerateKeyPair(sp->session,
++	    &mechanism,
++	    pub_key_template,
++	    ul_pub_key_attr_count,
++	    priv_key_template,
++	    ul_priv_key_attr_count,
++	    &h_pub_key,
++	    &h_priv_key);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DH_GEN_KEY, PK11_R_GEN_KEY, rv);
++		goto err;
++		}
++
++	/*
++	 * Reuse the larger memory allocated. We know the larger memory
++	 * should be sufficient for reuse.
++	 */
++	if (pub_key_template[1].ulValueLen > pub_key_template[2].ulValueLen)
++		{
++		reuse_mem = pub_key_template[1].pValue;
++		reuse_mem_len = pub_key_template[1].ulValueLen + DH_BUF_RESERVE;
++		}
++	else
++		{
++		reuse_mem = pub_key_template[2].pValue;
++		reuse_mem_len = pub_key_template[2].ulValueLen + DH_BUF_RESERVE;
++		}
++
++	rv = pFuncList->C_GetAttributeValue(sp->session, h_pub_key,
++		pub_key_result, pub_key_attr_result_count);
++	rv1 = pFuncList->C_GetAttributeValue(sp->session, h_priv_key,
++		priv_key_result, priv_key_attr_result_count);
++
++	if (rv != CKR_OK || rv1 != CKR_OK)
++		{
++		rv = (rv != CKR_OK) ? rv : rv1;
++		PK11err_add_data(PK11_F_DH_GEN_KEY,
++		    PK11_R_GETATTRIBUTVALUE, rv);
++		goto err;
++		}
++
++	if (((CK_LONG) pub_key_result[0].ulValueLen) <= 0 ||
++		((CK_LONG) priv_key_result[0].ulValueLen) <= 0)
++		{
++		PK11err(PK11_F_DH_GEN_KEY, PK11_R_GETATTRIBUTVALUE);
++		goto err;
++		}
++
++	/* Reuse the memory allocated */
++	pub_key_result[0].pValue = reuse_mem;
++	pub_key_result[0].ulValueLen = reuse_mem_len;
++
++	rv = pFuncList->C_GetAttributeValue(sp->session, h_pub_key,
++		pub_key_result, pub_key_attr_result_count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DH_GEN_KEY,
++		    PK11_R_GETATTRIBUTVALUE, rv);
++		goto err;
++		}
++
++	if (pub_key_result[0].type == CKA_VALUE)
++		{
++		if (dh->pub_key == NULL)
++			if ((dh->pub_key = BN_new()) == NULL)
++				{
++				PK11err(PK11_F_DH_GEN_KEY,
++					PK11_R_MALLOC_FAILURE);
++				goto err;
++				}
++		dh->pub_key = BN_bin2bn(pub_key_result[0].pValue,
++			pub_key_result[0].ulValueLen, dh->pub_key);
++		if (dh->pub_key == NULL)
++			{
++			PK11err(PK11_F_DH_GEN_KEY, PK11_R_MALLOC_FAILURE);
++			goto err;
++			}
++		}
++
++	/* Reuse the memory allocated */
++	priv_key_result[0].pValue = reuse_mem;
++	priv_key_result[0].ulValueLen = reuse_mem_len;
++
++	rv = pFuncList->C_GetAttributeValue(sp->session, h_priv_key,
++		priv_key_result, priv_key_attr_result_count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DH_GEN_KEY,
++		    PK11_R_GETATTRIBUTVALUE, rv);
++		goto err;
++		}
++
++	if (priv_key_result[0].type == CKA_VALUE)
++		{
++		if (dh->priv_key == NULL)
++			if ((dh->priv_key = BN_new()) == NULL)
++				{
++				PK11err(PK11_F_DH_GEN_KEY,
++					PK11_R_MALLOC_FAILURE);
++				goto err;
++				}
++		dh->priv_key = BN_bin2bn(priv_key_result[0].pValue,
++			priv_key_result[0].ulValueLen, dh->priv_key);
++		if (dh->priv_key == NULL)
++			{
++			PK11err(PK11_F_DH_GEN_KEY, PK11_R_MALLOC_FAILURE);
++			goto err;
++			}
++		}
++
++	ret = 1;
++
++err:
++
++	if (h_pub_key != CK_INVALID_HANDLE)
++		{
++		rv = pFuncList->C_DestroyObject(sp->session, h_pub_key);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_DH_GEN_KEY,
++			    PK11_R_DESTROYOBJECT, rv);
++			}
++		}
++
++	if (h_priv_key != CK_INVALID_HANDLE)
++		{
++		rv = pFuncList->C_DestroyObject(sp->session, h_priv_key);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_DH_GEN_KEY,
++			    PK11_R_DESTROYOBJECT, rv);
++			}
++		}
++
++	for (i = 1; i <= 2; i++)
++		{
++		if (pub_key_template[i].pValue != NULL)
++			{
++			OPENSSL_free(pub_key_template[i].pValue);
++			pub_key_template[i].pValue = NULL;
++			}
++		}
++
++	pk11_return_session(sp, OP_DH);
++	return (ret);
++	}
++
++static int pk11_DH_compute_key(unsigned char *key, const BIGNUM *pub_key,
++	DH *dh)
++	{
++	unsigned int i;
++	CK_MECHANISM mechanism = {CKM_DH_PKCS_DERIVE, NULL_PTR, 0};
++	CK_OBJECT_CLASS key_class = CKO_SECRET_KEY;
++	CK_KEY_TYPE key_type = CKK_GENERIC_SECRET;
++	CK_OBJECT_HANDLE h_derived_key = CK_INVALID_HANDLE;
++	CK_OBJECT_HANDLE h_key = CK_INVALID_HANDLE;
++
++	CK_ULONG ul_priv_key_attr_count = 2;
++	CK_ATTRIBUTE priv_key_template[] =
++		{
++		{CKA_CLASS, (void*) NULL, sizeof (key_class)},
++		{CKA_KEY_TYPE, (void*) NULL, sizeof (key_type)},
++		};
++
++	CK_ULONG priv_key_attr_result_count = 1;
++	CK_ATTRIBUTE priv_key_result[] =
++		{
++		{CKA_VALUE, (void *)NULL, 0}
++		};
++
++	CK_RV rv;
++	int ret = -1;
++	PK11_SESSION *sp = NULL;
++
++	if (dh->priv_key == NULL)
++		goto err;
++
++	priv_key_template[0].pValue = &key_class;
++	priv_key_template[1].pValue = &key_type;
++
++	if ((sp = pk11_get_session(OP_DH)) == NULL)
++		goto err;
++
++	mechanism.ulParameterLen = BN_num_bytes(pub_key);
++	mechanism.pParameter = OPENSSL_malloc(mechanism.ulParameterLen);
++	if (mechanism.pParameter == NULL)
++		{
++		PK11err(PK11_F_DH_COMP_KEY, PK11_R_MALLOC_FAILURE);
++		goto err;
++		}
++	BN_bn2bin(pub_key, mechanism.pParameter);
++
++	(void) check_new_dh_key(sp, dh);
++
++	h_key = sp->opdata_dh_key;
++	if (h_key == CK_INVALID_HANDLE)
++		h_key = sp->opdata_dh_key =
++			pk11_get_dh_key((DH*) dh, &sp->opdata_dh,
++			    &sp->opdata_dh_priv_num, sp->session);
++
++	if (h_key == CK_INVALID_HANDLE)
++		{
++		PK11err(PK11_F_DH_COMP_KEY, PK11_R_CREATEOBJECT);
++		goto err;
++		}
++
++	rv = pFuncList->C_DeriveKey(sp->session,
++	    &mechanism,
++	    h_key,
++	    priv_key_template,
++	    ul_priv_key_attr_count,
++	    &h_derived_key);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DH_COMP_KEY, PK11_R_DERIVEKEY, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_GetAttributeValue(sp->session, h_derived_key,
++	    priv_key_result, priv_key_attr_result_count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DH_COMP_KEY, PK11_R_GETATTRIBUTVALUE,
++		    rv);
++		goto err;
++		}
++
++	if (((CK_LONG) priv_key_result[0].ulValueLen) <= 0)
++		{
++		PK11err(PK11_F_DH_COMP_KEY, PK11_R_GETATTRIBUTVALUE);
++		goto err;
++		}
++	priv_key_result[0].pValue =
++		OPENSSL_malloc(priv_key_result[0].ulValueLen);
++	if (!priv_key_result[0].pValue)
++		{
++		PK11err(PK11_F_DH_COMP_KEY, PK11_R_MALLOC_FAILURE);
++		goto err;
++		}
++
++	rv = pFuncList->C_GetAttributeValue(sp->session, h_derived_key,
++		priv_key_result, priv_key_attr_result_count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DH_COMP_KEY, PK11_R_GETATTRIBUTVALUE,
++		    rv);
++		goto err;
++		}
++
++	/*
++	 * OpenSSL allocates the output buffer 'key' which is the same
++	 * length of the public key. It is long enough for the derived key
++	 */
++	if (priv_key_result[0].type == CKA_VALUE)
++		{
++		/*
++		 * CKM_DH_PKCS_DERIVE mechanism is not supposed to strip
++		 * leading zeros from a computed shared secret. However,
++		 * OpenSSL always did it so we must do the same here. The
++		 * vagueness of the spec regarding leading zero bytes was
++		 * finally cleared with TLS 1.1 (RFC 4346) saying that leading
++		 * zeros are stripped before the computed data is used as the
++		 * pre-master secret.
++		 */
++		for (i = 0; i < priv_key_result[0].ulValueLen; ++i)
++			{
++			if (((char *)priv_key_result[0].pValue)[i] != 0)
++				break;
++			}
++
++		(void) memcpy(key, ((char *)priv_key_result[0].pValue) + i,
++			priv_key_result[0].ulValueLen - i);
++		ret = priv_key_result[0].ulValueLen - i;
++		}
++
++err:
++
++	if (h_derived_key != CK_INVALID_HANDLE)
++		{
++		rv = pFuncList->C_DestroyObject(sp->session, h_derived_key);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_DH_COMP_KEY,
++			    PK11_R_DESTROYOBJECT, rv);
++			}
++		}
++	if (priv_key_result[0].pValue)
++		{
++		OPENSSL_free(priv_key_result[0].pValue);
++		priv_key_result[0].pValue = NULL;
++		}
++
++	if (mechanism.pParameter)
++		{
++		OPENSSL_free(mechanism.pParameter);
++		mechanism.pParameter = NULL;
++		}
++
++	pk11_return_session(sp, OP_DH);
++	return (ret);
++	}
++
++
++static CK_OBJECT_HANDLE pk11_get_dh_key(DH* dh,
++	DH **key_ptr, BIGNUM **dh_priv_num, CK_SESSION_HANDLE session)
++	{
++	CK_RV rv;
++	CK_OBJECT_HANDLE h_key = CK_INVALID_HANDLE;
++	CK_OBJECT_CLASS class = CKO_PRIVATE_KEY;
++	CK_KEY_TYPE key_type = CKK_DH;
++	CK_ULONG found;
++	CK_BBOOL rollback = FALSE;
++	int i;
++
++	CK_ULONG ul_key_attr_count = 7;
++	CK_ATTRIBUTE key_template[] =
++		{
++		{CKA_CLASS, (void*) NULL, sizeof (class)},
++		{CKA_KEY_TYPE, (void*) NULL, sizeof (key_type)},
++		{CKA_DERIVE, &true, sizeof (true)},
++		{CKA_PRIVATE, &false, sizeof (false)},
++		{CKA_PRIME, (void *) NULL, 0},
++		{CKA_BASE, (void *) NULL, 0},
++		{CKA_VALUE, (void *) NULL, 0},
++		};
++
++	key_template[0].pValue = &class;
++	key_template[1].pValue = &key_type;
++
++	key_template[4].ulValueLen = BN_num_bytes(dh->p);
++	key_template[4].pValue = (CK_VOID_PTR)OPENSSL_malloc(
++		(size_t)key_template[4].ulValueLen);
++	if (key_template[4].pValue == NULL)
++		{
++		PK11err(PK11_F_GET_DH_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
++
++	BN_bn2bin(dh->p, key_template[4].pValue);
++
++	key_template[5].ulValueLen = BN_num_bytes(dh->g);
++	key_template[5].pValue = (CK_VOID_PTR)OPENSSL_malloc(
++		(size_t)key_template[5].ulValueLen);
++	if (key_template[5].pValue == NULL)
++		{
++		PK11err(PK11_F_GET_DH_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
++
++	BN_bn2bin(dh->g, key_template[5].pValue);
++
++	key_template[6].ulValueLen = BN_num_bytes(dh->priv_key);
++	key_template[6].pValue = (CK_VOID_PTR)OPENSSL_malloc(
++		(size_t)key_template[6].ulValueLen);
++	if (key_template[6].pValue == NULL)
++		{
++		PK11err(PK11_F_GET_DH_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
++
++	BN_bn2bin(dh->priv_key, key_template[6].pValue);
++
++	/* see find_lock array definition for more info on object locking */
++	LOCK_OBJSTORE(OP_DH);
++	rv = pFuncList->C_FindObjectsInit(session, key_template,
++		ul_key_attr_count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_DH_KEY, PK11_R_FINDOBJECTSINIT, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjects(session, &h_key, 1, &found);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_DH_KEY, PK11_R_FINDOBJECTS, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjectsFinal(session);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_DH_KEY, PK11_R_FINDOBJECTSFINAL,
++		    rv);
++		goto err;
++		}
++
++	if (found == 0)
++		{
++		rv = pFuncList->C_CreateObject(session,
++			key_template, ul_key_attr_count, &h_key);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_GET_DH_KEY, PK11_R_CREATEOBJECT,
++			    rv);
++			goto err;
++			}
++		}
++
++	if (dh_priv_num != NULL)
++		if ((*dh_priv_num = BN_dup(dh->priv_key)) == NULL)
++			{
++			PK11err(PK11_F_GET_DH_KEY, PK11_R_MALLOC_FAILURE);
++			rollback = TRUE;
++			goto err;
++			}
++
++	/* LINTED: E_CONSTANT_CONDITION */
++	KEY_HANDLE_REFHOLD(h_key, OP_DH, FALSE, rollback, err);
++	if (key_ptr != NULL)
++		*key_ptr = dh;
++
++err:
++	if (rollback)
++		{
++		/*
++		 * We do not care about the return value from C_DestroyObject()
++		 * since we are doing rollback.
++		 */
++		if (found == 0)
++			(void) pFuncList->C_DestroyObject(session, h_key);
++		h_key = CK_INVALID_HANDLE;
++		}
++
++	UNLOCK_OBJSTORE(OP_DH);
++
++malloc_err:
++	for (i = 4; i <= 6; i++)
++		{
++		if (key_template[i].pValue != NULL)
++			{
++			OPENSSL_free(key_template[i].pValue);
++			key_template[i].pValue = NULL;
++			}
++		}
++
++	return (h_key);
++	}
++
++/*
++ * Check for cache miss and clean the object pointer and handle
++ * in such case. Return 1 for cache hit, 0 for cache miss.
++ *
++ * Note: we rely on pk11_destroy_dh_key_objects() to set sp->opdata_dh
++ *       to CK_INVALID_HANDLE even when it fails to destroy the object.
++ */
++static int check_new_dh_key(PK11_SESSION *sp, DH *dh)
++	{
++	/*
++	 * Provide protection against DH structure reuse by making the
++	 * check for cache hit stronger. Private key component of DH key
++	 * is unique so it is sufficient to compare it with value cached
++	 * in PK11_SESSION structure.
++	 */
++	if ((sp->opdata_dh != dh) ||
++	    (BN_cmp(sp->opdata_dh_priv_num, dh->priv_key) != 0))
++		{
++		/*
++		 * We do not check the return value because even in case of
++		 * failure the sp structure will have both key pointer
++		 * and object handle cleaned and pk11_destroy_object()
++		 * reports the failure to the OpenSSL error message buffer.
++		 */
++		(void) pk11_destroy_dh_object(sp, TRUE);
++		return (0);
++		}
++	return (1);
++	}
++#endif
++
++/*
++ * Local function to simplify key template population
++ * Return 0 -- error, 1 -- no error
++ */
++static int
++init_template_value(BIGNUM *bn, CK_VOID_PTR *p_value,
++	CK_ULONG *ul_value_len)
++	{
++	CK_ULONG len = 0;
++
++	/*
++	 * This function can be used on non-initialized BIGNUMs. It is
++	 * easier to check that here than individually in the callers.
++	 */
++	if (bn != NULL)
++		len = BN_num_bytes(bn);
++
++	if (bn == NULL || len == 0)
++		return (1);
++
++	*ul_value_len = len;
++	*p_value = (CK_VOID_PTR)OPENSSL_malloc((size_t)*ul_value_len);
++	if (*p_value == NULL)
++		return (0);
++
++	BN_bn2bin(bn, *p_value);
++
++	return (1);
++	}
++
++static void
++attr_to_BN(CK_ATTRIBUTE_PTR attr, CK_BYTE attr_data[], BIGNUM **bn)
++	{
++	if (attr->ulValueLen > 0)
++		*bn = BN_bin2bn(attr_data, attr->ulValueLen, NULL);
++	}
++
++/*
++ * Find one object in the token. It is an error if we can not find the
++ * object or if we find more objects based on the template we got.
++ *
++ * Returns:
++ *	1 OK
++ *	0 no object or more than 1 object found
++ */
++static int
++find_one_object(PK11_OPTYPE op, CK_SESSION_HANDLE s,
++    CK_ATTRIBUTE_PTR ptempl, CK_ULONG nattr, CK_OBJECT_HANDLE_PTR pkey)
++	{
++	CK_RV rv;
++	CK_ULONG objcnt;
++
++	LOCK_OBJSTORE(op);
++	if ((rv = pFuncList->C_FindObjectsInit(s, ptempl, nattr)) != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_FIND_ONE_OBJECT,
++		    PK11_R_FINDOBJECTSINIT, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjects(s, pkey, 1, &objcnt);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_FIND_ONE_OBJECT, PK11_R_FINDOBJECTS,
++		    rv);
++		goto err;
++		}
++
++	if (objcnt > 1)
++		{
++		PK11err(PK11_F_FIND_ONE_OBJECT,
++		    PK11_R_MORE_THAN_ONE_OBJECT_FOUND);
++		goto err;
++		}
++	else if (objcnt == 0)
++		{
++		PK11err(PK11_F_FIND_ONE_OBJECT, PK11_R_NO_OBJECT_FOUND);
++		goto err;
++		}
++
++	(void) pFuncList->C_FindObjectsFinal(s);
++	UNLOCK_OBJSTORE(op);
++	return (1);
++err:
++	UNLOCK_OBJSTORE(op);
++	return (0);
++	}
++
++/* from uri stuff */
++
++extern char *pk11_pin;
++
++static int pk11_get_pin(void);
++
++static int
++pk11_get_pin(void)
++{
++	char *pin;
++
++	/* The getpassphrase() function is not MT safe. */
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(token_lock);
++#else
++	CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	pin = getpassphrase("Enter PIN: ");
++	if (pin == NULL)
++		{
++		PK11err(PK11_F_GET_PIN, PK11_R_COULD_NOT_READ_PIN);
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		goto err;
++		}
++	pk11_pin = BUF_strdup(pin);
++	if (pk11_pin == NULL)
++		{
++		PK11err(PK11_F_LOAD_PRIVKEY, PK11_R_MALLOC_FAILURE);
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		goto err;
++		}
++	memset(pin, 0, strlen(pin));
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(token_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	return (1);
++err:
++	return (0);
++	}
++
++/*
++ * Log in to the keystore if we are supposed to do that at all. Take care of
++ * reading and caching the PIN etc. Log in only once even when called from
++ * multiple threads.
++ *
++ * Returns:
++ *	1 on success
++ *	0 on failure
++ */
++static int
++pk11_token_login(CK_SESSION_HANDLE session, CK_BBOOL *login_done,
++    CK_BBOOL is_private)
++	{
++	CK_RV rv;
++
++#if 0
++	/* doesn't work on the AEP Keyper??? */
++	if ((pubkey_token_flags & CKF_TOKEN_INITIALIZED) == 0)
++		{
++		PK11err(PK11_F_TOKEN_LOGIN,
++		    PK11_R_TOKEN_NOT_INITIALIZED);
++		goto err;
++		}
++#endif
++
++	/*
++	 * If login is required or needed but the PIN has not been
++	 * even initialized we can bail out right now. Note that we
++	 * are supposed to always log in if we are going to access
++	 * private keys. However, we may need to log in even for
++	 * accessing public keys in case that the CKF_LOGIN_REQUIRED
++	 * flag is set.
++	 */
++	if (((pubkey_token_flags & CKF_LOGIN_REQUIRED) ||
++	     (is_private == CK_TRUE)) &&
++	    (~pubkey_token_flags & CKF_USER_PIN_INITIALIZED))
++		{
++		PK11err(PK11_F_TOKEN_LOGIN, PK11_R_TOKEN_PIN_NOT_SET);
++		goto err;
++		}
++
++	/*
++	 * Note on locking: it is possible that more than one thread
++	 * gets into pk11_get_pin() so we must deal with that. We
++	 * cannot avoid it since we cannot guard fork() in there with
++	 * a lock because we could end up in a dead lock in the
++	 * child. Why? Remember we are in a multithreaded environment
++	 * so we must lock all mutexes in the prefork function to
++	 * avoid a situation in which a thread that did not call
++	 * fork() held a lock, making future unlocking impossible. We
++	 * lock right before C_Login().
++	 */
++	if ((pubkey_token_flags & CKF_LOGIN_REQUIRED) ||
++	    (is_private == CK_TRUE))
++		{
++		if (*login_done == CK_FALSE)
++			{
++			if ((pk11_pin == NULL) && (pk11_get_pin() == 0))
++				{
++				PK11err(PK11_F_TOKEN_LOGIN,
++				    PK11_R_TOKEN_PIN_NOT_PROVIDED);
++				goto err;
++				}
++			}
++
++		/*
++		 * Note that what we are logging into is the keystore from
++		 * pubkey_SLOTID because we work with OP_RSA session type here.
++		 * That also means that we can work with only one keystore in
++		 * the engine.
++		 *
++		 * We must make sure we do not try to login more than once.
++		 * Also, see the comment above on locking strategy.
++		 */
++
++#ifndef NOPTHREADS
++		(void) pthread_mutex_lock(token_lock);
++#else
++		(void) pthread_mutex_lock(freelist_lock);
++#endif
++		if (*login_done == CK_FALSE)
++			{
++			if ((rv = pFuncList->C_Login(session,
++			    CKU_USER, (CK_UTF8CHAR*)pk11_pin,
++			    strlen(pk11_pin))) != CKR_OK)
++				{
++				PK11err_add_data(PK11_F_TOKEN_LOGIN,
++				    PK11_R_TOKEN_LOGIN_FAILED, rv);
++				goto err_locked;
++				}
++
++			*login_done = CK_TRUE;
++
++			}
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		}
++	else
++		{
++			/*
++			 * If token does not require login we take it as the
++			 * login was done.
++			 */
++			*login_done = CK_TRUE;
++		}
++
++	return (1);
++
++err_locked:
++	if (pk11_pin) {
++		memset(pk11_pin, 0, strlen(pk11_pin));
++		OPENSSL_free((void*)pk11_pin);
++	}
++	pk11_pin = NULL;
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(token_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++err:
++	return (0);
++	}
++
++/*
++ * Log in to the keystore in the child if we were logged in in the
++ * parent. There are similarities in the code with pk11_token_login()
++ * but still it is quite different so we need a separate function for
++ * this.
++ *
++ * Note that this function is called under the locked session mutex when fork is
++ * detected. That means that C_Login() will be called from the child just once.
++ *
++ * Returns:
++ *	1 on success
++ *	0 on failure
++ */
++int
++pk11_token_relogin(CK_SESSION_HANDLE session)
++	{
++	CK_RV rv;
++
++	if ((pk11_pin == NULL) && (pk11_get_pin() == 0))
++		goto err;
++
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(token_lock);
++#else
++	(void) pthread_mutex_lock(freelist_lock);
++#endif
++	if ((rv = pFuncList->C_Login(session, CKU_USER,
++	    (CK_UTF8CHAR_PTR)pk11_pin, strlen(pk11_pin))) != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_TOKEN_RELOGIN,
++		    PK11_R_TOKEN_LOGIN_FAILED, rv);
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		goto err;
++		}
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(token_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++
++	return (1);
++err:
++	return (0);
++	}
++
++#ifdef	OPENSSL_SYS_WIN32
++char *getpassphrase(const char *prompt)
++	{
++	static char buf[128];
++	HANDLE h;
++	DWORD cc, mode;
++	int cnt;
++
++	h = GetStdHandle(STD_INPUT_HANDLE);
++	fputs(prompt, stderr);
++	fflush(stderr);
++	fflush(stdout);
++	FlushConsoleInputBuffer(h);
++	GetConsoleMode(h, &mode);
++	SetConsoleMode(h, ENABLE_PROCESSED_INPUT);
++
++	for (cnt = 0; cnt < sizeof(buf) - 1; cnt++)
++		{
++		ReadFile(h, buf + cnt, 1, &cc, NULL);
++		if (buf[cnt] == '\r')
++			break;
++		fputc('*', stdout);
++		fflush(stderr);
++		fflush(stdout);
++		}
++
++	SetConsoleMode(h, mode);
++	buf[cnt] = '\0';
++	fputs("\n", stderr);
++	return buf;
++	}
++#endif	/* OPENSSL_SYS_WIN32 */
++#endif	/* OPENSSL_NO_HW_PK11CA */
++#endif	/* OPENSSL_NO_HW_PK11 */
++#endif	/* OPENSSL_NO_HW */
+Index: openssl/crypto/engine/hw_pk11ca.h
+diff -u /dev/null openssl/crypto/engine/hw_pk11ca.h:1.4
+--- /dev/null	Mon Jan 16 18:54:23 2012
++++ openssl/crypto/engine/hw_pk11ca.h	Wed Jun 15 21:12:20 2011
+@@ -0,0 +1,32 @@
++/* Redefine all pk11/PK11 external symbols to pk11ca/PK11CA */
++
++#define token_lock			pk11ca_token_lock
++#define find_lock			pk11ca_find_lock
++#define active_list			pk11ca_active_list
++#define pubkey_token_flags		pk11ca_pubkey_token_flags
++#define pubkey_SLOTID			pk11ca_pubkey_SLOTID
++#define ERR_pk11_error			ERR_pk11ca_error
++#define PK11err_add_data		PK11CAerr_add_data
++#define pk11_get_session		pk11ca_get_session
++#define pk11_return_session		pk11ca_return_session
++#define pk11_active_add			pk11ca_active_add
++#define pk11_active_delete		pk11ca_active_delete
++#define pk11_active_remove		pk11ca_active_remove
++#define pk11_free_active_list		pk11ca_free_active_list
++#define pk11_destroy_rsa_key_objects	pk11ca_destroy_rsa_key_objects
++#define pk11_destroy_rsa_object_pub	pk11ca_destroy_rsa_object_pub
++#define pk11_destroy_rsa_object_priv	pk11ca_destroy_rsa_object_priv
++#define pk11_load_privkey		pk11ca_load_privkey
++#define pk11_load_pubkey		pk11ca_load_pubkey
++#define PK11_RSA			PK11CA_RSA
++#define pk11_destroy_dsa_key_objects	pk11ca_destroy_dsa_key_objects
++#define pk11_destroy_dsa_object_pub	pk11ca_destroy_dsa_object_pub
++#define pk11_destroy_dsa_object_priv	pk11ca_destroy_dsa_object_priv
++#define PK11_DSA			PK11CA_DSA
++#define pk11_destroy_dh_key_objects	pk11ca_destroy_dh_key_objects
++#define pk11_destroy_dh_object		pk11ca_destroy_dh_object
++#define PK11_DH				PK11CA_DH
++#define pk11_token_relogin		pk11ca_token_relogin
++#define pFuncList			pk11ca_pFuncList
++#define pk11_pin			pk11ca_pin
++#define ENGINE_load_pk11		ENGINE_load_pk11ca
+Index: openssl/crypto/engine/hw_pk11so.c
+diff -u /dev/null openssl/crypto/engine/hw_pk11so.c:1.7
+--- /dev/null	Mon Jan 16 18:54:23 2012
++++ openssl/crypto/engine/hw_pk11so.c	Thu Jun 16 12:31:53 2011
+@@ -0,0 +1,1745 @@
++/*
++ * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
++ * Use is subject to license terms.
++ */
++
++/* crypto/engine/hw_pk11.c */
++/*
++ * This product includes software developed by the OpenSSL Project for
++ * use in the OpenSSL Toolkit (http://www.openssl.org/).
++ *
++ * This project also referenced hw_pkcs11-0.9.7b.patch written by
++ * Afchine Madjlessi.
++ */
++/*
++ * ====================================================================
++ * Copyright (c) 2000-2001 The OpenSSL Project.  All rights reserved.
++ *
++ * Redistribution and use in source and binary forms, with or without
++ * modification, are permitted provided that the following conditions
++ * are met:
++ *
++ * 1. Redistributions of source code must retain the above copyright
++ *    notice, this list of conditions and the following disclaimer.
++ *
++ * 2. Redistributions in binary form must reproduce the above copyright
++ *    notice, this list of conditions and the following disclaimer in
++ *    the documentation and/or other materials provided with the
++ *    distribution.
++ *
++ * 3. All advertising materials mentioning features or use of this
++ *    software must display the following acknowledgment:
++ *    "This product includes software developed by the OpenSSL Project
++ *    for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
++ *
++ * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
++ *    endorse or promote products derived from this software without
++ *    prior written permission. For written permission, please contact
++ *    licensing@OpenSSL.org.
++ *
++ * 5. Products derived from this software may not be called "OpenSSL"
++ *    nor may "OpenSSL" appear in their names without prior written
++ *    permission of the OpenSSL Project.
++ *
++ * 6. Redistributions of any form whatsoever must retain the following
++ *    acknowledgment:
++ *    "This product includes software developed by the OpenSSL Project
++ *    for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
++ *
++ * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
++ * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
++ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
++ * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR
++ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
++ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
++ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
++ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
++ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
++ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
++ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
++ * OF THE POSSIBILITY OF SUCH DAMAGE.
++ * ====================================================================
++ *
++ * This product includes cryptographic software written by Eric Young
++ * (eay@cryptsoft.com).  This product includes software written by Tim
++ * Hudson (tjh@cryptsoft.com).
++ *
++ */
++
++/* Modified to keep only RNG and RSA Sign */
++
++#ifdef OPENSSL_NO_RSA
++#error RSA is disabled
++#endif
++
++#include <stdio.h>
++#include <stdlib.h>
++#include <string.h>
++#include <sys/types.h>
++
++#include <openssl/e_os2.h>
++#include <openssl/crypto.h>
++#include <cryptlib.h>
++#include <openssl/engine.h>
++#include <openssl/dso.h>
++#include <openssl/err.h>
++#include <openssl/bn.h>
++#include <openssl/md5.h>
++#include <openssl/pem.h>
++#include <openssl/rsa.h>
++#include <openssl/rand.h>
++#include <openssl/objects.h>
++#include <openssl/x509.h>
++
++#ifdef OPENSSL_SYS_WIN32
++typedef int pid_t;
++#define getpid() GetCurrentProcessId()
++#define NOPTHREADS
++#ifndef NULL_PTR
++#define NULL_PTR NULL
++#endif
++#define CK_DEFINE_FUNCTION(returnType, name) \
++	returnType __declspec(dllexport) name
++#define CK_DECLARE_FUNCTION(returnType, name) \
++	returnType __declspec(dllimport) name
++#define CK_DECLARE_FUNCTION_POINTER(returnType, name) \
++	returnType __declspec(dllimport) (* name)
++#else
++#include <signal.h>
++#include <unistd.h>
++#include <dlfcn.h>
++#endif
++
++#ifndef NOPTHREADS
++#include <pthread.h>
++#endif
++
++#ifndef OPENSSL_NO_HW
++#ifndef OPENSSL_NO_HW_PK11
++#ifndef OPENSSL_NO_HW_PK11SO
++
++/* label for debug messages printed on stderr */
++#define	PK11_DBG	"PKCS#11 ENGINE DEBUG"
++/* prints a lot of debug messages on stderr about slot selection process */
++/*#undef	DEBUG_SLOT_SELECTION */
++
++#ifndef OPENSSL_NO_DSA
++#define OPENSSL_NO_DSA
++#endif
++#ifndef OPENSSL_NO_DH
++#define OPENSSL_NO_DH
++#endif
++
++#ifdef OPENSSL_SYS_WIN32
++#pragma pack(push, cryptoki, 1)
++#include "cryptoki.h"
++#include "pkcs11.h"
++#pragma pack(pop, cryptoki)
++#else
++#include "cryptoki.h"
++#include "pkcs11.h"
++#endif
++#include "hw_pk11so.h"
++#include "hw_pk11_err.c"
++
++/*
++ * We use this lock to prevent multiple C_Login()s, guard getpassphrase(),
++ * uri_struct manipulation, and static token info. All of that is used by the
++ * RSA keys by reference feature.
++ */
++#ifndef NOPTHREADS
++pthread_mutex_t *token_lock;
++#endif
++
++/* PKCS#11 session caches and their locks for all operation types */
++static PK11_CACHE session_cache[OP_MAX];
++
++/*
++ * We cache the flags so that we do not have to run C_GetTokenInfo() again when
++ * logging into the token.
++ */
++CK_FLAGS pubkey_token_flags;
++
++/*
++ * As stated in v2.20, 11.7 Object Management Function, in section for
++ * C_FindObjectsInit(), at most one search operation may be active at a given
++ * time in a given session. Therefore, C_Find{,Init,Final}Objects() should be
++ * grouped together to form one atomic search operation. This is already
++ * ensured by the property of unique PKCS#11 session handle used for each
++ * PK11_SESSION object.
++ *
++ * This is however not the biggest concern - maintaining consistency of the
++ * underlying object store is more important. The same section of the spec also
++ * says that one thread can be in the middle of a search operation while another
++ * thread destroys the object matching the search template which would result in
++ * invalid handle returned from the search operation.
++ *
++ * Hence, the following locks are used for both protection of the object stores.
++ * They are also used for active list protection.
++ */
++#ifndef NOPTHREADS
++pthread_mutex_t *find_lock[OP_MAX] = { NULL };
++#endif
++
++/*
++ * lists of asymmetric key handles which are active (referenced by at least one
++ * PK11_SESSION structure, either held by a thread or present in free_session
++ * list) for given algorithm type
++ */
++PK11_active *active_list[OP_MAX] = { NULL };
++
++/*
++ * Create all secret key objects in a global session so that they are available
++ * to use for other sessions. These other sessions may be opened or closed
++ * without losing the secret key objects.
++ */
++static CK_SESSION_HANDLE	global_session = CK_INVALID_HANDLE;
++
++/* ENGINE level stuff */
++static int pk11_init(ENGINE *e);
++static int pk11_library_init(ENGINE *e);
++static int pk11_finish(ENGINE *e);
++static int pk11_ctrl(ENGINE *e, int cmd, long i, void *p, void (*f)(void));
++static int pk11_destroy(ENGINE *e);
++
++/* RAND stuff */
++static void pk11_rand_seed(const void *buf, int num);
++static void pk11_rand_add(const void *buf, int num, double add_entropy);
++static void pk11_rand_cleanup(void);
++static int pk11_rand_bytes(unsigned char *buf, int num);
++static int pk11_rand_status(void);
++
++/* These functions are also used in other files */
++PK11_SESSION *pk11_get_session(PK11_OPTYPE optype);
++void pk11_return_session(PK11_SESSION *sp, PK11_OPTYPE optype);
++
++/* active list manipulation functions used in this file */
++extern int pk11_active_delete(CK_OBJECT_HANDLE h, PK11_OPTYPE type);
++extern void pk11_free_active_list(PK11_OPTYPE type);
++
++int pk11_destroy_rsa_key_objects(PK11_SESSION *session);
++int pk11_destroy_rsa_object_pub(PK11_SESSION *sp, CK_BBOOL uselock);
++int pk11_destroy_rsa_object_priv(PK11_SESSION *sp, CK_BBOOL uselock);
++
++/* Local helper functions */
++static int pk11_free_all_sessions(void);
++static int pk11_free_session_list(PK11_OPTYPE optype);
++static int pk11_setup_session(PK11_SESSION *sp, PK11_OPTYPE optype);
++static int pk11_destroy_object(CK_SESSION_HANDLE session, CK_OBJECT_HANDLE oh,
++	CK_BBOOL persistent);
++static const char *get_PK11_LIBNAME(void);
++static void free_PK11_LIBNAME(void);
++static long set_PK11_LIBNAME(const char *name);
++
++static int pk11_choose_slots(int *any_slot_found);
++
++static int pk11_init_all_locks(void);
++static void pk11_free_all_locks(void);
++
++#define	TRY_OBJ_DESTROY(sp, obj_hdl, retval, uselock, alg_type, priv)	\
++	{								\
++	if (uselock)							\
++		LOCK_OBJSTORE(alg_type);				\
++	if (pk11_active_delete(obj_hdl, alg_type) == 1)			\
++		{							\
++		  retval = pk11_destroy_object(sp->session, obj_hdl,	\
++		  priv ? sp->priv_persistent : sp->pub_persistent);	\
++		}							\
++	if (uselock)							\
++		UNLOCK_OBJSTORE(alg_type);				\
++	}
++
++static CK_BBOOL pk11_have_rsa	= CK_FALSE;
++static CK_BBOOL pk11_have_random = CK_FALSE;
++
++/*
++ * Initialization function. Sets up various PKCS#11 library components.
++ * The definitions for control commands specific to this engine
++ */
++#define PK11_CMD_SO_PATH		ENGINE_CMD_BASE
++#define PK11_CMD_PIN			(ENGINE_CMD_BASE+1)
++#define PK11_CMD_SLOT			(ENGINE_CMD_BASE+2)
++static const ENGINE_CMD_DEFN pk11_cmd_defns[] =
++	{
++		{
++		PK11_CMD_SO_PATH,
++		"SO_PATH",
++		"Specifies the path to the 'pkcs#11' shared library",
++		ENGINE_CMD_FLAG_STRING
++		},
++		{
++		PK11_CMD_PIN,
++		"PIN",
++		"Specifies the pin code",
++		ENGINE_CMD_FLAG_STRING
++		},
++		{
++		PK11_CMD_SLOT,
++		"SLOT",
++		"Specifies the slot (default is auto select)",
++		ENGINE_CMD_FLAG_NUMERIC,
++		},
++		{0, NULL, NULL, 0}
++	};
++
++
++static RAND_METHOD pk11_random =
++	{
++	pk11_rand_seed,
++	pk11_rand_bytes,
++	pk11_rand_cleanup,
++	pk11_rand_add,
++	pk11_rand_bytes,
++	pk11_rand_status
++	};
++
++
++/* Constants used when creating the ENGINE */
++#ifdef OPENSSL_NO_HW_PK11CA
++#error "can't load both crypto-accelerator and sign-only PKCS#11 engines"
++#endif
++static const char *engine_pk11_id = "pkcs11";
++static const char *engine_pk11_name = "PKCS #11 engine support (sign only)";
++
++CK_FUNCTION_LIST_PTR pFuncList = NULL;
++static const char PK11_GET_FUNCTION_LIST[] = "C_GetFunctionList";
++
++/*
++ * This is a static string constant for the DSO file name and the function
++ * symbol names to bind to. We set it in the Configure script based on whether
++ * this is 32 or 64 bit build.
++ */
++static const char def_PK11_LIBNAME[] = PK11_LIB_LOCATION;
++
++/* Needed in hw_pk11_pub.c as well so that's why it is not static. */
++CK_SLOT_ID pubkey_SLOTID = 0;
++static CK_SLOT_ID rand_SLOTID = 0;
++static CK_SLOT_ID SLOTID = 0;
++char *pk11_pin = NULL;
++static CK_BBOOL pk11_library_initialized = FALSE;
++static CK_BBOOL pk11_atfork_initialized = FALSE;
++static int pk11_pid = 0;
++
++static DSO *pk11_dso = NULL;
++
++/* allocate and initialize all locks used by the engine itself */
++static int pk11_init_all_locks(void)
++	{
++#ifndef NOPTHREADS
++	int type;
++
++	if ((token_lock = OPENSSL_malloc(sizeof (pthread_mutex_t))) == NULL)
++		goto malloc_err;
++	(void) pthread_mutex_init(token_lock, NULL);
++
++	find_lock[OP_RSA] = OPENSSL_malloc(sizeof (pthread_mutex_t));
++	if (find_lock[OP_RSA] == NULL)
++		goto malloc_err;
++	(void) pthread_mutex_init(find_lock[OP_RSA], NULL);
++
++	for (type = 0; type < OP_MAX; type++)
++		{
++		session_cache[type].lock =
++		    OPENSSL_malloc(sizeof (pthread_mutex_t));
++		if (session_cache[type].lock == NULL)
++			goto malloc_err;
++		(void) pthread_mutex_init(session_cache[type].lock, NULL);
++		}
++
++	return (1);
++
++malloc_err:
++	pk11_free_all_locks();
++	PK11err(PK11_F_INIT_ALL_LOCKS, PK11_R_MALLOC_FAILURE);
++	return (0);
++#else
++	return (1);
++#endif
++	}
++
++static void pk11_free_all_locks(void)
++	{
++#ifndef NOPTHREADS
++	int type;
++
++	if (find_lock[OP_RSA] != NULL)
++		{
++		(void) pthread_mutex_destroy(find_lock[OP_RSA]);
++		OPENSSL_free(find_lock[OP_RSA]);
++		find_lock[OP_RSA] = NULL;
++		}
++
++	for (type = 0; type < OP_MAX; type++)
++		{
++		if (session_cache[type].lock != NULL)
++			{
++			(void) pthread_mutex_destroy(session_cache[type].lock);
++			OPENSSL_free(session_cache[type].lock);
++			session_cache[type].lock = NULL;
++			}
++		}
++#endif
++	}
++
++/*
++ * This internal function is used by ENGINE_pk11() and "dynamic" ENGINE support.
++ */
++static int bind_pk11(ENGINE *e)
++	{
++	if (!pk11_library_initialized)
++		if (!pk11_library_init(e))
++			return (0);
++
++	if (!ENGINE_set_id(e, engine_pk11_id) ||
++	    !ENGINE_set_name(e, engine_pk11_name))
++		return (0);
++
++	if (pk11_have_rsa == CK_TRUE)
++		{
++		if (!ENGINE_set_RSA(e, PK11_RSA()) ||
++		    !ENGINE_set_load_privkey_function(e, pk11_load_privkey) ||
++		    !ENGINE_set_load_pubkey_function(e, pk11_load_pubkey))
++			return (0);
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, "%s: registered RSA\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++		}
++
++	if (pk11_have_random)
++		{
++		if (!ENGINE_set_RAND(e, &pk11_random))
++			return (0);
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, "%s: registered random\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++		}
++	if (!ENGINE_set_init_function(e, pk11_init) ||
++	    !ENGINE_set_destroy_function(e, pk11_destroy) ||
++	    !ENGINE_set_finish_function(e, pk11_finish) ||
++	    !ENGINE_set_ctrl_function(e, pk11_ctrl) ||
++	    !ENGINE_set_cmd_defns(e, pk11_cmd_defns))
++		return (0);
++
++	/* Ensure the pk11 error handling is set up */
++	ERR_load_pk11_strings();
++
++	return (1);
++	}
++
++/* Dynamic engine support is disabled at a higher level for Solaris */
++#ifdef	ENGINE_DYNAMIC_SUPPORT
++#error	"dynamic engine not supported"
++static int bind_helper(ENGINE *e, const char *id)
++	{
++	if (id && (strcmp(id, engine_pk11_id) != 0))
++		return (0);
++
++	if (!bind_pk11(e))
++		return (0);
++
++	return (1);
++	}
++
++IMPLEMENT_DYNAMIC_CHECK_FN()
++IMPLEMENT_DYNAMIC_BIND_FN(bind_helper)
++
++#else
++static ENGINE *engine_pk11(void)
++	{
++	ENGINE *ret = ENGINE_new();
++
++	if (!ret)
++		return (NULL);
++
++	if (!bind_pk11(ret))
++		{
++		ENGINE_free(ret);
++		return (NULL);
++		}
++
++	return (ret);
++	}
++
++void
++ENGINE_load_pk11(void)
++	{
++	ENGINE *e_pk11 = NULL;
++
++	/*
++	 * Do not use dynamic PKCS#11 library on Solaris due to
++	 * security reasons. We will link it in statically.
++	 */
++	/* Attempt to load PKCS#11 library */
++	if (!pk11_dso)
++		pk11_dso = DSO_load(NULL, get_PK11_LIBNAME(), NULL, 0);
++
++	if (pk11_dso == NULL)
++		{
++		PK11err(PK11_F_LOAD, PK11_R_DSO_FAILURE);
++		return;
++		}
++
++	e_pk11 = engine_pk11();
++	if (!e_pk11)
++		{
++		DSO_free(pk11_dso);
++		pk11_dso = NULL;
++		return;
++		}
++
++	/*
++	 * At this point, the pk11 shared library is either dynamically
++	 * loaded or statically linked in. So, initialize the pk11
++	 * library before calling ENGINE_set_default since the latter
++	 * needs cipher and digest algorithm information
++	 */
++	if (!pk11_library_init(e_pk11))
++		{
++		DSO_free(pk11_dso);
++		pk11_dso = NULL;
++		ENGINE_free(e_pk11);
++		return;
++		}
++
++	ENGINE_add(e_pk11);
++
++	ENGINE_free(e_pk11);
++	ERR_clear_error();
++	}
++#endif	/* ENGINE_DYNAMIC_SUPPORT */
++
++/*
++ * These are the static string constants for the DSO file name and
++ * the function symbol names to bind to.
++ */
++static const char *PK11_LIBNAME = NULL;
++
++static const char *get_PK11_LIBNAME(void)
++	{
++	if (PK11_LIBNAME)
++		return (PK11_LIBNAME);
++
++	return (def_PK11_LIBNAME);
++	}
++
++static void free_PK11_LIBNAME(void)
++	{
++	if (PK11_LIBNAME)
++		OPENSSL_free((void*)PK11_LIBNAME);
++
++	PK11_LIBNAME = NULL;
++	}
++
++static long set_PK11_LIBNAME(const char *name)
++	{
++	free_PK11_LIBNAME();
++
++	return ((PK11_LIBNAME = BUF_strdup(name)) != NULL ? 1 : 0);
++	}
++
++/* acquire all engine specific mutexes before fork */
++static void pk11_fork_prepare(void)
++	{
++#ifndef NOPTHREADS
++	int i;
++
++	if (!pk11_library_initialized)
++		return;
++
++	LOCK_OBJSTORE(OP_RSA);
++	(void) pthread_mutex_lock(token_lock);
++	for (i = 0; i < OP_MAX; i++)
++		{
++		(void) pthread_mutex_lock(session_cache[i].lock);
++		}
++#endif
++	}
++
++/* release all engine specific mutexes */
++static void pk11_fork_parent(void)
++	{
++#ifndef NOPTHREADS
++	int i;
++
++	if (!pk11_library_initialized)
++		return;
++
++	for (i = OP_MAX - 1; i >= 0; i--)
++		{
++		(void) pthread_mutex_unlock(session_cache[i].lock);
++		}
++	UNLOCK_OBJSTORE(OP_RSA);
++	(void) pthread_mutex_unlock(token_lock);
++#endif
++	}
++
++/*
++ * same situation as in parent - we need to unlock all locks to make them
++ * accessible to all threads.
++ */
++static void pk11_fork_child(void)
++	{
++#ifndef NOPTHREADS
++	int i;
++
++	if (!pk11_library_initialized)
++		return;
++
++	for (i = OP_MAX - 1; i >= 0; i--)
++		{
++		(void) pthread_mutex_unlock(session_cache[i].lock);
++		}
++	UNLOCK_OBJSTORE(OP_RSA);
++	(void) pthread_mutex_unlock(token_lock);
++#endif
++	}
++
++/* Initialization function for the pk11 engine */
++static int pk11_init(ENGINE *e)
++{
++	return (pk11_library_init(e));
++}
++
++static CK_C_INITIALIZE_ARGS pk11_init_args =
++	{
++	NULL_PTR,		/* CreateMutex */
++	NULL_PTR,		/* DestroyMutex */
++	NULL_PTR,		/* LockMutex */
++	NULL_PTR,		/* UnlockMutex */
++	CKF_OS_LOCKING_OK,	/* flags */
++	NULL_PTR,		/* pReserved */
++	};
++
++/*
++ * Initialization function. Sets up various PKCS#11 library components.
++ * It selects a slot based on predefined critiera. In the process, it also
++ * count how many ciphers and digests to support. Since the cipher and
++ * digest information is needed when setting default engine, this function
++ * needs to be called before calling ENGINE_set_default.
++ */
++/* ARGSUSED */
++static int pk11_library_init(ENGINE *e)
++	{
++	CK_C_GetFunctionList p;
++	CK_RV rv = CKR_OK;
++	CK_INFO info;
++	int any_slot_found;
++	int i;
++#ifndef OPENSSL_SYS_WIN32
++	struct sigaction sigint_act, sigterm_act, sighup_act;
++#endif
++
++	/*
++	 * pk11_library_initialized is set to 0 in pk11_finish() which
++	 * is called from ENGINE_finish(). However, if there is still
++	 * at least one existing functional reference to the engine
++	 * (see engine(3) for more information), pk11_finish() is
++	 * skipped. For example, this can happen if an application
++	 * forgets to clear one cipher context. In case of a fork()
++	 * when the application is finishing the engine so that it can
++	 * be reinitialized in the child, forgotten functional
++	 * reference causes pk11_library_initialized to stay 1. In
++	 * that case we need the PID check so that we properly
++	 * initialize the engine again.
++	 */
++	if (pk11_library_initialized)
++		{
++		if (pk11_pid == getpid())
++			{
++			return (1);
++			}
++		else
++			{
++			global_session = CK_INVALID_HANDLE;
++			/*
++			 * free the locks first to prevent memory leak in case
++			 * the application calls fork() without finishing the
++			 * engine first.
++			 */
++			pk11_free_all_locks();
++			}
++		}
++
++	if (pk11_dso == NULL)
++		{
++		PK11err(PK11_F_LIBRARY_INIT, PK11_R_DSO_FAILURE);
++		goto err;
++		}
++
++	/* get the C_GetFunctionList function from the loaded library */
++	p = (CK_C_GetFunctionList)DSO_bind_func(pk11_dso,
++		PK11_GET_FUNCTION_LIST);
++	if (!p)
++		{
++		PK11err(PK11_F_LIBRARY_INIT, PK11_R_DSO_FAILURE);
++		goto err;
++		}
++
++	/* get the full function list from the loaded library */
++	rv = p(&pFuncList);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_LIBRARY_INIT, PK11_R_DSO_FAILURE, rv);
++		goto err;
++		}
++
++#ifndef OPENSSL_SYS_WIN32
++	/* Not all PKCS#11 library are signal safe! */
++
++	(void) memset(&sigint_act, 0, sizeof(sigint_act));
++	(void) memset(&sigterm_act, 0, sizeof(sigterm_act));
++	(void) memset(&sighup_act, 0, sizeof(sighup_act));
++	(void) sigaction(SIGINT, NULL, &sigint_act);
++	(void) sigaction(SIGTERM, NULL, &sigterm_act);
++	(void) sigaction(SIGHUP, NULL, &sighup_act);
++#endif
++	rv = pFuncList->C_Initialize((CK_VOID_PTR)&pk11_init_args);
++#ifndef OPENSSL_SYS_WIN32
++	(void) sigaction(SIGINT, &sigint_act, NULL);
++	(void) sigaction(SIGTERM, &sigterm_act, NULL);
++	(void) sigaction(SIGHUP, &sighup_act, NULL);
++#endif
++	if ((rv != CKR_OK) && (rv != CKR_CRYPTOKI_ALREADY_INITIALIZED))
++		{
++		PK11err_add_data(PK11_F_LIBRARY_INIT, PK11_R_INITIALIZE, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_GetInfo(&info);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_LIBRARY_INIT, PK11_R_GETINFO, rv);
++		goto err;
++		}
++
++	if (pk11_choose_slots(&any_slot_found) == 0)
++		goto err;
++
++	/*
++	 * The library we use, set in def_PK11_LIBNAME, may not offer any
++	 * slot(s). In that case, we must not proceed but we must not return an
++	 * error. The reason is that applications that try to set up the PKCS#11
++	 * engine don't exit on error during the engine initialization just
++	 * because no slot was present.
++	 */
++	if (any_slot_found == 0)
++		return (1);
++
++	if (global_session == CK_INVALID_HANDLE)
++		{
++		/* Open the global_session for the new process */
++		rv = pFuncList->C_OpenSession(SLOTID, CKF_SERIAL_SESSION,
++			NULL_PTR, NULL_PTR, &global_session);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_LIBRARY_INIT,
++			    PK11_R_OPENSESSION, rv);
++			goto err;
++			}
++		}
++
++	pk11_library_initialized = TRUE;
++	pk11_pid = getpid();
++	/*
++	 * if initialization of the locks fails pk11_init_all_locks()
++	 * will do the cleanup.
++	 */
++	if (!pk11_init_all_locks())
++		goto err;
++	for (i = 0; i < OP_MAX; i++)
++		session_cache[i].head = NULL;
++	/*
++	 * initialize active lists. We only use active lists
++	 * for asymmetric ciphers.
++	 */
++	for (i = 0; i < OP_MAX; i++)
++		active_list[i] = NULL;
++
++#ifndef NOPTHREADS
++	if (!pk11_atfork_initialized)
++		{
++		if (pthread_atfork(pk11_fork_prepare, pk11_fork_parent,
++		    pk11_fork_child) != 0)
++			{
++			PK11err(PK11_F_LIBRARY_INIT, PK11_R_ATFORK_FAILED);
++			goto err;
++			}
++		pk11_atfork_initialized = TRUE;
++		}
++#endif
++
++	return (1);
++
++err:
++	return (0);
++	}
++
++/* Destructor (complements the "ENGINE_pk11()" constructor) */
++/* ARGSUSED */
++static int pk11_destroy(ENGINE *e)
++	{
++	free_PK11_LIBNAME();
++	ERR_unload_pk11_strings();
++	if (pk11_pin) {
++		memset(pk11_pin, 0, strlen(pk11_pin));
++		OPENSSL_free((void*)pk11_pin);
++	}
++	pk11_pin = NULL;
++	return (1);
++	}
++
++/*
++ * Termination function to clean up the session, the token, and the pk11
++ * library.
++ */
++/* ARGSUSED */
++static int pk11_finish(ENGINE *e)
++	{
++	int i;
++
++	if (pk11_pin) {
++		memset(pk11_pin, 0, strlen(pk11_pin));
++		OPENSSL_free((void*)pk11_pin);
++	}
++	pk11_pin = NULL;
++
++	if (pk11_dso == NULL)
++		{
++		PK11err(PK11_F_FINISH, PK11_R_NOT_LOADED);
++		goto err;
++		}
++
++	OPENSSL_assert(pFuncList != NULL);
++
++	if (pk11_free_all_sessions() == 0)
++		goto err;
++
++	/* free all active lists */
++	for (i = 0; i < OP_MAX; i++)
++		pk11_free_active_list(i);
++
++	pFuncList->C_CloseSession(global_session);
++	global_session = CK_INVALID_HANDLE;
++
++	/*
++	 * Since we are part of a library (libcrypto.so), calling this function
++	 * may have side-effects.
++	 */
++#if 0
++	pFuncList->C_Finalize(NULL);
++#endif
++
++	if (!DSO_free(pk11_dso))
++		{
++		PK11err(PK11_F_FINISH, PK11_R_DSO_FAILURE);
++		goto err;
++		}
++	pk11_dso = NULL;
++	pFuncList = NULL;
++	pk11_library_initialized = FALSE;
++	pk11_pid = 0;
++	/*
++	 * There is no way how to unregister atfork handlers (other than
++	 * unloading the library) so we just free the locks. For this reason
++	 * the atfork handlers check if the engine is initialized and bail out
++	 * immediately if not. This is necessary in case a process finishes
++	 * the engine before calling fork().
++	 */
++	pk11_free_all_locks();
++
++	return (1);
++
++err:
++	return (0);
++	}
++
++/* Standard engine interface function to set the dynamic library path */
++/* ARGSUSED */
++static int pk11_ctrl(ENGINE *e, int cmd, long i, void *p, void (*f)(void))
++	{
++	int initialized = ((pk11_dso == NULL) ? 0 : 1);
++
++	switch (cmd)
++		{
++	case PK11_CMD_SO_PATH:
++		if (p == NULL)
++			{
++			PK11err(PK11_F_CTRL, ERR_R_PASSED_NULL_PARAMETER);
++			return (0);
++			}
++
++		if (initialized)
++			{
++			PK11err(PK11_F_CTRL, PK11_R_ALREADY_LOADED);
++			return (0);
++			}
++
++		return (set_PK11_LIBNAME((const char *)p));
++	case PK11_CMD_PIN:
++		if (pk11_pin) {
++			memset(pk11_pin, 0, strlen(pk11_pin));
++			OPENSSL_free((void*)pk11_pin);
++		}
++		pk11_pin = NULL;
++
++		if (p == NULL)
++			{
++			PK11err(PK11_F_CTRL, ERR_R_PASSED_NULL_PARAMETER);
++			return (0);
++			}
++
++		pk11_pin = BUF_strdup(p);
++		if (pk11_pin == NULL)
++			{
++			PK11err(PK11_F_GET_SESSION, PK11_R_MALLOC_FAILURE);
++			return (0);
++			}
++		return (1);
++	case PK11_CMD_SLOT:
++		SLOTID = (CK_SLOT_ID)i;
++#ifdef DEBUG_SLOT_SELECTION
++		fprintf(stderr, "%s: slot set\n", PK11_DBG);
++#endif
++		return (1);
++	default:
++		break;
++		}
++
++	PK11err(PK11_F_CTRL, PK11_R_CTRL_COMMAND_NOT_IMPLEMENTED);
++
++	return (0);
++	}
++
++
++/* Required function by the engine random interface. It does nothing here */
++static void pk11_rand_cleanup(void)
++	{
++	return;
++	}
++
++/* ARGSUSED */
++static void pk11_rand_add(const void *buf, int num, double add)
++	{
++	PK11_SESSION *sp;
++
++	if ((sp = pk11_get_session(OP_RAND)) == NULL)
++		return;
++
++	/*
++	 * Ignore any errors (e.g. CKR_RANDOM_SEED_NOT_SUPPORTED) since
++	 * the calling functions do not care anyway
++	 */
++	pFuncList->C_SeedRandom(sp->session, (unsigned char *) buf, num);
++	pk11_return_session(sp, OP_RAND);
++
++	return;
++	}
++
++static void pk11_rand_seed(const void *buf, int num)
++	{
++	pk11_rand_add(buf, num, 0);
++	}
++
++static int pk11_rand_bytes(unsigned char *buf, int num)
++	{
++	CK_RV rv;
++	PK11_SESSION *sp;
++
++	if ((sp = pk11_get_session(OP_RAND)) == NULL)
++		return (0);
++
++	rv = pFuncList->C_GenerateRandom(sp->session, buf, num);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_RAND_BYTES, PK11_R_GENERATERANDOM, rv);
++		pk11_return_session(sp, OP_RAND);
++		return (0);
++		}
++
++	pk11_return_session(sp, OP_RAND);
++	return (1);
++	}
++
++/* Required function by the engine random interface. It does nothing here */
++static int pk11_rand_status(void)
++	{
++	return (1);
++	}
++
++/* Free all BIGNUM structures from PK11_SESSION. */
++static void pk11_free_nums(PK11_SESSION *sp, PK11_OPTYPE optype)
++	{
++	switch (optype)
++		{
++		case OP_RSA:
++			if (sp->opdata_rsa_n_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_n_num);
++				sp->opdata_rsa_n_num = NULL;
++				}
++			if (sp->opdata_rsa_e_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_e_num);
++				sp->opdata_rsa_e_num = NULL;
++				}
++			if (sp->opdata_rsa_pn_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_pn_num);
++				sp->opdata_rsa_pn_num = NULL;
++				}
++			if (sp->opdata_rsa_pe_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_pe_num);
++				sp->opdata_rsa_pe_num = NULL;
++				}
++			if (sp->opdata_rsa_d_num != NULL)
++				{
++				BN_free(sp->opdata_rsa_d_num);
++				sp->opdata_rsa_d_num = NULL;
++				}
++			break;
++		default:
++			break;
++		}
++	}
++
++/*
++ * Get new PK11_SESSION structure ready for use. Every process must have
++ * its own freelist of PK11_SESSION structures so handle fork() here
++ * by destroying the old and creating new freelist.
++ * The returned PK11_SESSION structure is disconnected from the freelist.
++ */
++PK11_SESSION *
++pk11_get_session(PK11_OPTYPE optype)
++	{
++	PK11_SESSION *sp = NULL, *sp1, *freelist;
++#ifndef NOPTHREADS
++	pthread_mutex_t *freelist_lock = NULL;
++#endif
++	static pid_t pid = 0;
++	pid_t new_pid;
++	CK_RV rv;
++
++	switch (optype)
++		{
++		case OP_RSA:
++		case OP_DSA:
++		case OP_DH:
++		case OP_RAND:
++		case OP_DIGEST:
++		case OP_CIPHER:
++#ifndef NOPTHREADS
++			freelist_lock = session_cache[optype].lock;
++#endif
++			break;
++		default:
++			PK11err(PK11_F_GET_SESSION,
++				PK11_R_INVALID_OPERATION_TYPE);
++			return (NULL);
++		}
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(freelist_lock);
++#else
++	CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++
++	/*
++	 * Will use it to find out if we forked. We cannot use the PID field in
++	 * the session structure because we could get a newly allocated session
++	 * here, with no PID information.
++	 */
++	if (pid == 0)
++		pid = getpid();
++
++	freelist = session_cache[optype].head;
++	sp = freelist;
++
++	/*
++	 * If the free list is empty, allocate new unitialized (filled
++	 * with zeroes) PK11_SESSION structure otherwise return first
++	 * structure from the freelist.
++	 */
++	if (sp == NULL)
++		{
++		if ((sp = OPENSSL_malloc(sizeof (PK11_SESSION))) == NULL)
++			{
++			PK11err(PK11_F_GET_SESSION,
++				PK11_R_MALLOC_FAILURE);
++			goto err;
++			}
++		(void) memset(sp, 0, sizeof (PK11_SESSION));
++
++		/*
++		 * It is a new session so it will look like a cache miss to the
++		 * code below. So, we must not try to to destroy its members so
++		 * mark them as unused.
++		 */
++		sp->opdata_rsa_priv_key = CK_INVALID_HANDLE;
++		sp->opdata_rsa_pub_key = CK_INVALID_HANDLE;
++		}
++	else
++		{
++		freelist = sp->next;
++		}
++
++	/*
++	 * Check whether we have forked. In that case, we must get rid of all
++	 * inherited sessions and start allocating new ones.
++	 */
++	if (pid != (new_pid = getpid()))
++		{
++		pid = new_pid;
++
++		/*
++		 * We are a new process and thus need to free any inherited
++		 * PK11_SESSION objects aside from the first session (sp) which
++		 * is the only PK11_SESSION structure we will reuse (for the
++		 * head of the list).
++		 */
++		while ((sp1 = freelist) != NULL)
++			{
++			freelist = sp1->next;
++			/*
++			 * NOTE: we do not want to call pk11_free_all_sessions()
++			 * here because it would close underlying PKCS#11
++			 * sessions and destroy all objects.
++			 */
++			pk11_free_nums(sp1, optype);
++			OPENSSL_free(sp1);
++			}
++
++		/* we have to free the active list as well. */
++		pk11_free_active_list(optype);
++
++		/* Initialize the process */
++		rv = pFuncList->C_Initialize((CK_VOID_PTR)&pk11_init_args);
++		if ((rv != CKR_OK) && (rv != CKR_CRYPTOKI_ALREADY_INITIALIZED))
++			{
++			PK11err_add_data(PK11_F_GET_SESSION, PK11_R_INITIALIZE,
++			    rv);
++			OPENSSL_free(sp);
++			sp = NULL;
++			goto err;
++			}
++
++		/*
++		 * Choose slot here since the slot table is different on this
++		 * process. If we are here then we must have found at least one
++		 * usable slot before so we don't need to check any_slot_found.
++		 * See pk11_library_init()'s usage of this function for more
++		 * information.
++		 */
++		if (pk11_choose_slots(NULL) == 0)
++			goto err;
++
++		/* Open the global_session for the new process */
++		rv = pFuncList->C_OpenSession(SLOTID, CKF_SERIAL_SESSION,
++			NULL_PTR, NULL_PTR, &global_session);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_GET_SESSION, PK11_R_OPENSESSION,
++			    rv);
++			OPENSSL_free(sp);
++			sp = NULL;
++			goto err;
++			}
++
++		/*
++		 * It is an inherited session from our parent so it needs
++		 * re-initialization.
++		 */
++		if (pk11_setup_session(sp, optype) == 0)
++			{
++			OPENSSL_free(sp);
++			sp = NULL;
++			goto err;
++			}
++		if (pk11_token_relogin(sp->session) == 0) 
++			{
++			/*
++			 * We will keep the session in the cache list and let
++			 * the caller cope with the situation.
++			 */
++			freelist = sp;
++			sp = NULL;
++			goto err;
++			}
++		}
++
++	if (sp->pid == 0)
++		{
++		/* It is a new session and needs initialization. */
++		if (pk11_setup_session(sp, optype) == 0)
++			{
++			OPENSSL_free(sp);
++			sp = NULL;
++			}
++		}
++
++	/* set new head for the list of PK11_SESSION objects */
++	session_cache[optype].head = freelist;
++
++err:
++	if (sp != NULL)
++		sp->next = NULL;
++
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(freelist_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++
++	return (sp);
++	}
++
++
++void
++pk11_return_session(PK11_SESSION *sp, PK11_OPTYPE optype)
++	{
++#ifndef NOPTHREADS
++	pthread_mutex_t *freelist_lock;
++#endif
++	PK11_SESSION *freelist;
++
++	/*
++	 * If this is a session from the parent it will be taken care of and
++	 * freed in pk11_get_session() as part of the post-fork clean up the
++	 * next time we will ask for a new session.
++	 */
++	if (sp == NULL || sp->pid != getpid())
++		return;
++
++	switch (optype)
++		{
++		case OP_RSA:
++		case OP_DSA:
++		case OP_DH:
++		case OP_RAND:
++		case OP_DIGEST:
++		case OP_CIPHER:
++#ifndef NOPTHREADS
++			freelist_lock = session_cache[optype].lock;
++#endif
++			break;
++		default:
++			PK11err(PK11_F_RETURN_SESSION,
++				PK11_R_INVALID_OPERATION_TYPE);
++			return;
++		}
++
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(freelist_lock);
++#else
++	CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	freelist = session_cache[optype].head;
++	sp->next = freelist;
++	session_cache[optype].head = sp;
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(freelist_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	}
++
++
++/* Destroy all objects. This function is called when the engine is finished */
++static int pk11_free_all_sessions()
++	{
++	int ret = 1;
++	int type;
++
++	(void) pk11_destroy_rsa_key_objects(NULL);
++
++	/*
++	 * We try to release as much as we can but any error means that we will
++	 * return 0 on exit.
++	 */
++	for (type = 0; type < OP_MAX; type++)
++		{
++		if (pk11_free_session_list(type) == 0)
++			ret = 0;
++		}
++
++	return (ret);
++	}
++
++/*
++ * Destroy session structures from the linked list specified. Free as many
++ * sessions as possible but any failure in C_CloseSession() means that we
++ * return an error on return.
++ */
++static int pk11_free_session_list(PK11_OPTYPE optype)
++	{
++	CK_RV rv;
++	PK11_SESSION *sp = NULL;
++	PK11_SESSION *freelist = NULL;
++	pid_t mypid = getpid();
++#ifndef NOPTHREADS
++	pthread_mutex_t *freelist_lock;
++#endif
++	int ret = 1;
++
++	switch (optype)
++		{
++		case OP_RSA:
++		case OP_DSA:
++		case OP_DH:
++		case OP_RAND:
++		case OP_DIGEST:
++		case OP_CIPHER:
++#ifndef NOPTHREADS
++			freelist_lock = session_cache[optype].lock;
++#endif
++			break;
++		default:
++			PK11err(PK11_F_FREE_ALL_SESSIONS,
++				PK11_R_INVALID_OPERATION_TYPE);
++			return (0);
++		}
++
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(freelist_lock);
++#else
++	CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	freelist = session_cache[optype].head;
++	while ((sp = freelist) != NULL)
++		{
++		if (sp->session != CK_INVALID_HANDLE && sp->pid == mypid)
++			{
++			rv = pFuncList->C_CloseSession(sp->session);
++			if (rv != CKR_OK)
++				{
++				PK11err_add_data(PK11_F_FREE_ALL_SESSIONS,
++					PK11_R_CLOSESESSION, rv);
++				ret = 0;
++				}
++			}
++		freelist = sp->next;
++		pk11_free_nums(sp, optype);
++		OPENSSL_free(sp);
++		}
++
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(freelist_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	return (ret);
++	}
++
++
++static int
++pk11_setup_session(PK11_SESSION *sp, PK11_OPTYPE optype)
++	{
++	CK_RV rv;
++	CK_SLOT_ID myslot;
++
++	switch (optype)
++		{
++		case OP_RSA:
++			myslot = pubkey_SLOTID;
++			break;
++		case OP_RAND:
++			myslot = rand_SLOTID;
++			break;
++		default:
++			PK11err(PK11_F_SETUP_SESSION,
++			    PK11_R_INVALID_OPERATION_TYPE);
++			return (0);
++		}
++
++	sp->session = CK_INVALID_HANDLE;
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: myslot=%d optype=%d\n", PK11_DBG, myslot, optype);
++#endif	/* DEBUG_SLOT_SELECTION */
++	rv = pFuncList->C_OpenSession(myslot, CKF_SERIAL_SESSION,
++		NULL_PTR, NULL_PTR, &sp->session);
++	if (rv == CKR_CRYPTOKI_NOT_INITIALIZED)
++		{
++		/*
++		 * We are probably a child process so force the
++		 * reinitialize of the session
++		 */
++		pk11_library_initialized = FALSE;
++		if (!pk11_library_init(NULL))
++			return (0);
++		rv = pFuncList->C_OpenSession(myslot, CKF_SERIAL_SESSION,
++			NULL_PTR, NULL_PTR, &sp->session);
++		}
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_SETUP_SESSION, PK11_R_OPENSESSION, rv);
++		return (0);
++		}
++
++	sp->pid = getpid();
++
++	if (optype == OP_RSA)
++		{
++		sp->opdata_rsa_pub_key = CK_INVALID_HANDLE;
++		sp->opdata_rsa_priv_key = CK_INVALID_HANDLE;
++		sp->opdata_rsa_pub = NULL;
++		sp->opdata_rsa_n_num = NULL;
++		sp->opdata_rsa_e_num = NULL;
++		sp->opdata_rsa_priv = NULL;
++		sp->opdata_rsa_pn_num = NULL;
++		sp->opdata_rsa_pe_num = NULL;
++		sp->opdata_rsa_d_num = NULL;
++		}
++
++	/*
++	 * We always initialize the session as containing a non-persistent
++	 * object. The key load functions set it to persistent if that is so.
++	 */
++	sp->pub_persistent = CK_FALSE;
++	sp->priv_persistent = CK_FALSE;
++	return (1);
++	}
++
++/* Destroy RSA public key from single session. */
++int
++pk11_destroy_rsa_object_pub(PK11_SESSION *sp, CK_BBOOL uselock)
++	{
++	int ret = 0;
++
++	if (sp->opdata_rsa_pub_key != CK_INVALID_HANDLE)
++		{
++		TRY_OBJ_DESTROY(sp, sp->opdata_rsa_pub_key,
++		    ret, uselock, OP_RSA, CK_FALSE);
++		sp->opdata_rsa_pub_key = CK_INVALID_HANDLE;
++		sp->opdata_rsa_pub = NULL;
++		if (sp->opdata_rsa_n_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_n_num);
++			sp->opdata_rsa_n_num = NULL;
++			}
++		if (sp->opdata_rsa_e_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_e_num);
++			sp->opdata_rsa_e_num = NULL;
++			}
++		}
++
++	return (ret);
++	}
++
++/* Destroy RSA private key from single session. */
++int
++pk11_destroy_rsa_object_priv(PK11_SESSION *sp, CK_BBOOL uselock)
++	{
++	int ret = 0;
++
++	if (sp->opdata_rsa_priv_key != CK_INVALID_HANDLE)
++		{
++		TRY_OBJ_DESTROY(sp, sp->opdata_rsa_priv_key,
++		    ret, uselock, OP_RSA, CK_TRUE);
++		sp->opdata_rsa_priv_key = CK_INVALID_HANDLE;
++		sp->opdata_rsa_priv = NULL;
++		if (sp->opdata_rsa_d_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_d_num);
++			sp->opdata_rsa_d_num = NULL;
++			}
++
++		/*
++		 * For the RSA key by reference code, public components 'n'/'e'
++		 * are the key components we use to check for the cache hit. We
++		 * must free those as well.
++		 */
++		if (sp->opdata_rsa_pn_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_pn_num);
++			sp->opdata_rsa_pn_num = NULL;
++			}
++		if (sp->opdata_rsa_pe_num != NULL)
++			{
++			BN_free(sp->opdata_rsa_pe_num);
++			sp->opdata_rsa_pe_num = NULL;
++			}
++		}
++
++	return (ret);
++	}
++
++/*
++ * Destroy RSA key object wrapper. If session is NULL, try to destroy all
++ * objects in the free list.
++ */
++int
++pk11_destroy_rsa_key_objects(PK11_SESSION *session)
++	{
++	int ret = 1;
++	PK11_SESSION *sp = NULL;
++	PK11_SESSION *local_free_session;
++	CK_BBOOL uselock = TRUE;
++
++	if (session != NULL)
++		local_free_session = session;
++	else
++		{
++#ifndef NOPTHREADS
++		(void) pthread_mutex_lock(session_cache[OP_RSA].lock);
++#else
++		CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		local_free_session = session_cache[OP_RSA].head;
++		uselock = FALSE;
++		}
++
++	/*
++	 * go through the list of sessions and delete key objects
++	 */
++	while ((sp = local_free_session) != NULL)
++		{
++		local_free_session = sp->next;
++
++		/*
++		 * Do not terminate list traversal if one of the
++		 * destroy operations fails.
++		 */
++		if (pk11_destroy_rsa_object_pub(sp, uselock) == 0)
++			{
++			ret = 0;
++			continue;
++			}
++		if (pk11_destroy_rsa_object_priv(sp, uselock) == 0)
++			{
++			ret = 0;
++			continue;
++			}
++		}
++
++#ifndef NOPTHREADS
++	if (session == NULL)
++		(void) pthread_mutex_unlock(session_cache[OP_RSA].lock);
++#else
++	if (session == NULL)
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++
++	return (ret);
++	}
++
++static int
++pk11_destroy_object(CK_SESSION_HANDLE session, CK_OBJECT_HANDLE oh,
++	CK_BBOOL persistent)
++	{
++	CK_RV rv;
++
++	/*
++	 * We never try to destroy persistent objects which are the objects
++	 * stored in the keystore. Also, we always use read-only sessions so
++	 * C_DestroyObject() would be returning CKR_SESSION_READ_ONLY here.
++	 */
++	if (persistent == CK_TRUE)
++		return (1);
++
++	rv = pFuncList->C_DestroyObject(session, oh);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_DESTROY_OBJECT, PK11_R_DESTROYOBJECT,
++		    rv);
++		return (0);
++		}
++
++	return (1);
++	}
++
++
++/*
++ * Public key mechanisms optionally supported
++ *
++ * CKM_RSA_PKCS
++ *
++ * The first slot that supports at least one of those mechanisms is chosen as a
++ * public key slot.
++ *
++ * The output of this function is a set of global variables indicating which
++ * mechanisms from RSA, DSA, DH and RAND are present, and also two arrays of
++ * mechanisms, one for symmetric ciphers and one for digests. Also, 3 global
++ * variables carry information about which slot was chosen for (a) public key
++ * mechanisms, (b) random operations, and (c) symmetric ciphers and digests.
++ */
++static int
++pk11_choose_slots(int *any_slot_found)
++	{
++	CK_SLOT_ID_PTR pSlotList = NULL_PTR;
++	CK_ULONG ulSlotCount = 0;
++	CK_MECHANISM_INFO mech_info;
++	CK_TOKEN_INFO token_info;
++	unsigned int i;
++	CK_RV rv;
++	CK_SLOT_ID best_slot_sofar = 0;
++	CK_BBOOL found_candidate_slot = CK_FALSE;
++	CK_SLOT_ID current_slot = 0;
++
++	/* let's initialize the output parameter */
++	if (any_slot_found != NULL)
++		*any_slot_found = 0;
++
++	/* Get slot list for memory allocation */
++	rv = pFuncList->C_GetSlotList(CK_FALSE, NULL_PTR, &ulSlotCount);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_CHOOSE_SLOT, PK11_R_GETSLOTLIST, rv);
++		return (0);
++		}
++
++	/* it's not an error if we didn't find any providers */
++	if (ulSlotCount == 0)
++		{
++#ifdef	DEBUG_SLOT_SELECTION
++		fprintf(stderr, "%s: no crypto providers found\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++		return (1);
++		}
++
++	pSlotList = OPENSSL_malloc(ulSlotCount * sizeof (CK_SLOT_ID));
++
++	if (pSlotList == NULL)
++		{
++		PK11err(PK11_F_CHOOSE_SLOT, PK11_R_MALLOC_FAILURE);
++		return (0);
++		}
++
++	/* Get the slot list for processing */
++	rv = pFuncList->C_GetSlotList(CK_FALSE, pSlotList, &ulSlotCount);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_CHOOSE_SLOT, PK11_R_GETSLOTLIST, rv);
++		OPENSSL_free(pSlotList);
++		return (0);
++		}
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: provider: %s\n", PK11_DBG, def_PK11_LIBNAME);
++	fprintf(stderr, "%s: number of slots: %d\n", PK11_DBG, ulSlotCount);
++
++	fprintf(stderr, "%s: == checking rand slots ==\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++	for (i = 0; i < ulSlotCount; i++)
++		{
++		current_slot = pSlotList[i];
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: checking slot: %d\n", PK11_DBG, i);
++#endif	/* DEBUG_SLOT_SELECTION */
++		/* Check if slot has random support. */
++		rv = pFuncList->C_GetTokenInfo(current_slot, &token_info);
++		if (rv != CKR_OK)
++			continue;
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: token label: %.32s\n", PK11_DBG, token_info.label);
++#endif	/* DEBUG_SLOT_SELECTION */
++
++		if (token_info.flags & CKF_RNG)
++			{
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: this token has CKF_RNG flag\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++			pk11_have_random = CK_TRUE;
++			rand_SLOTID = current_slot;
++			break;
++			}
++		}
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: == checking pubkey slots ==\n", PK11_DBG);
++#endif	/* DEBUG_SLOT_SELECTION */
++
++	pubkey_SLOTID = pSlotList[0];
++	for (i = 0; i < ulSlotCount; i++)
++		{
++		CK_BBOOL slot_has_rsa = CK_FALSE;
++		current_slot = pSlotList[i];
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: checking slot: %d\n", PK11_DBG, i);
++#endif	/* DEBUG_SLOT_SELECTION */
++		rv = pFuncList->C_GetTokenInfo(current_slot, &token_info);
++		if (rv != CKR_OK)
++			continue;
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr, "%s: token label: %.32s\n", PK11_DBG, token_info.label);
++#endif	/* DEBUG_SLOT_SELECTION */
++
++		/*
++		 * Check if this slot is capable of signing with CKM_RSA_PKCS.
++		 */
++		rv = pFuncList->C_GetMechanismInfo(current_slot, CKM_RSA_PKCS,
++			&mech_info);
++
++		if (rv == CKR_OK && ((mech_info.flags & CKF_SIGN)))
++			{
++			slot_has_rsa = CK_TRUE;
++			}
++
++		if (!found_candidate_slot && slot_has_rsa)
++			{
++#ifdef	DEBUG_SLOT_SELECTION
++			fprintf(stderr,
++			    "%s: potential slot: %d\n", PK11_DBG, current_slot);
++#endif	/* DEBUG_SLOT_SELECTION */
++			best_slot_sofar = current_slot;
++			pk11_have_rsa = slot_has_rsa;
++			found_candidate_slot = CK_TRUE;
++			/*
++			 * Cache the flags for later use. We might
++			 * need those if RSA keys by reference feature
++			 * is used.
++			 */
++			pubkey_token_flags = token_info.flags;
++#ifdef	DEBUG_SLOT_SELECTION
++			fprintf(stderr,
++			    "%s: setting found_candidate_slot to CK_TRUE\n",
++			    PK11_DBG);
++			fprintf(stderr,
++			    "%s: best so far slot: %d\n", PK11_DBG,
++			    best_slot_sofar);
++			fprintf(stderr, "%s: pubkey flags changed to "
++			    "%lu.\n", PK11_DBG, pubkey_token_flags);
++			}
++		else
++			{
++			fprintf(stderr,
++			    "%s: no rsa\n", PK11_DBG);
++			}
++#else
++			} /* if */
++#endif	/* DEBUG_SLOT_SELECTION */
++		} /* for */
++
++	if (found_candidate_slot == CK_TRUE)
++		{
++		pubkey_SLOTID = best_slot_sofar;
++		}
++
++	/*SLOTID = pSlotList[0];*/
++
++#ifdef	DEBUG_SLOT_SELECTION
++	fprintf(stderr,
++	    "%s: chosen pubkey slot: %d\n", PK11_DBG, pubkey_SLOTID);
++	fprintf(stderr,
++	    "%s: chosen rand slot: %d\n", PK11_DBG, rand_SLOTID);
++	fprintf(stderr,
++	    "%s: pk11_have_rsa %d\n", PK11_DBG, pk11_have_rsa);
++	fprintf(stderr,
++	    "%s: pk11_have_random %d\n", PK11_DBG, pk11_have_random);
++#endif	/* DEBUG_SLOT_SELECTION */
++
++	if (pSlotList != NULL)
++		OPENSSL_free(pSlotList);
++
++	if (any_slot_found != NULL)
++		*any_slot_found = 1;
++	return (1);
++	}
++
++#endif	/* OPENSSL_NO_HW_PK11SO */
++#endif	/* OPENSSL_NO_HW_PK11 */
++#endif	/* OPENSSL_NO_HW */
+Index: openssl/crypto/engine/hw_pk11so.h
+diff -u /dev/null openssl/crypto/engine/hw_pk11so.h:1.4
+--- /dev/null	Mon Jan 16 18:54:23 2012
++++ openssl/crypto/engine/hw_pk11so.h	Wed Jun 15 21:12:20 2011
+@@ -0,0 +1,32 @@
++/* Redefine all pk11/PK11 external symbols to pk11so/PK11SO */
++
++#define token_lock			pk11so_token_lock
++#define find_lock			pk11so_find_lock
++#define active_list			pk11so_active_list
++#define pubkey_token_flags		pk11so_pubkey_token_flags
++#define pubkey_SLOTID			pk11so_pubkey_SLOTID
++#define ERR_pk11_error			ERR_pk11so_error
++#define PK11err_add_data		PK11SOerr_add_data
++#define pk11_get_session		pk11so_get_session
++#define pk11_return_session		pk11so_return_session
++#define pk11_active_add			pk11so_active_add
++#define pk11_active_delete		pk11so_active_delete
++#define pk11_active_remove		pk11so_active_remove
++#define pk11_free_active_list		pk11so_free_active_list
++#define pk11_destroy_rsa_key_objects	pk11so_destroy_rsa_key_objects
++#define pk11_destroy_rsa_object_pub	pk11so_destroy_rsa_object_pub
++#define pk11_destroy_rsa_object_priv	pk11so_destroy_rsa_object_priv
++#define pk11_load_privkey		pk11so_load_privkey
++#define pk11_load_pubkey		pk11so_load_pubkey
++#define PK11_RSA			PK11SO_RSA
++#define pk11_destroy_dsa_key_objects	pk11so_destroy_dsa_key_objects
++#define pk11_destroy_dsa_object_pub	pk11so_destroy_dsa_object_pub
++#define pk11_destroy_dsa_object_priv	pk11so_destroy_dsa_object_priv
++#define PK11_DSA			PK11SO_DSA
++#define pk11_destroy_dh_key_objects	pk11so_destroy_dh_key_objects
++#define pk11_destroy_dh_object		pk11so_destroy_dh_object
++#define PK11_DH				PK11SO_DH
++#define pk11_token_relogin		pk11so_token_relogin
++#define pFuncList			pk11so_pFuncList
++#define pk11_pin			pk11so_pin
++#define ENGINE_load_pk11		ENGINE_load_pk11so
+Index: openssl/crypto/engine/hw_pk11so_pub.c
+diff -u /dev/null openssl/crypto/engine/hw_pk11so_pub.c:1.7
+--- /dev/null	Mon Jan 16 18:54:23 2012
++++ openssl/crypto/engine/hw_pk11so_pub.c	Fri Jun 17 07:55:25 2011
+@@ -0,0 +1,1622 @@
++/*
++ * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
++ * Use is subject to license terms.
++ */
++
++/* crypto/engine/hw_pk11_pub.c */
++/*
++ * This product includes software developed by the OpenSSL Project for
++ * use in the OpenSSL Toolkit (http://www.openssl.org/).
++ *
++ * This project also referenced hw_pkcs11-0.9.7b.patch written by
++ * Afchine Madjlessi.
++ */
++/*
++ * ====================================================================
++ * Copyright (c) 2000-2001 The OpenSSL Project.  All rights reserved.
++ *
++ * Redistribution and use in source and binary forms, with or without
++ * modification, are permitted provided that the following conditions
++ * are met:
++ *
++ * 1. Redistributions of source code must retain the above copyright
++ *    notice, this list of conditions and the following disclaimer.
++ *
++ * 2. Redistributions in binary form must reproduce the above copyright
++ *    notice, this list of conditions and the following disclaimer in
++ *    the documentation and/or other materials provided with the
++ *    distribution.
++ *
++ * 3. All advertising materials mentioning features or use of this
++ *    software must display the following acknowledgment:
++ *    "This product includes software developed by the OpenSSL Project
++ *    for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
++ *
++ * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
++ *    endorse or promote products derived from this software without
++ *    prior written permission. For written permission, please contact
++ *    licensing@OpenSSL.org.
++ *
++ * 5. Products derived from this software may not be called "OpenSSL"
++ *    nor may "OpenSSL" appear in their names without prior written
++ *    permission of the OpenSSL Project.
++ *
++ * 6. Redistributions of any form whatsoever must retain the following
++ *    acknowledgment:
++ *    "This product includes software developed by the OpenSSL Project
++ *    for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
++ *
++ * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
++ * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
++ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
++ * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR
++ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
++ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
++ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
++ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
++ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
++ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
++ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
++ * OF THE POSSIBILITY OF SUCH DAMAGE.
++ * ====================================================================
++ *
++ * This product includes cryptographic software written by Eric Young
++ * (eay@cryptsoft.com).  This product includes software written by Tim
++ * Hudson (tjh@cryptsoft.com).
++ *
++ */
++
++/* Modified to keep only RNG and RSA Sign */
++
++#ifdef OPENSSL_NO_RSA
++#error RSA is disabled
++#endif
++
++#include <stdio.h>
++#include <stdlib.h>
++#include <string.h>
++#include <sys/types.h>
++
++#include <openssl/e_os2.h>
++#include <openssl/crypto.h>
++#include <cryptlib.h>
++#include <openssl/engine.h>
++#include <openssl/dso.h>
++#include <openssl/err.h>
++#include <openssl/bn.h>
++#include <openssl/pem.h>
++#include <openssl/rsa.h>
++#include <openssl/rand.h>
++#include <openssl/objects.h>
++#include <openssl/x509.h>
++
++#ifdef OPENSSL_SYS_WIN32
++#define NOPTHREADS
++typedef int pid_t;
++#define HAVE_GETPASSPHRASE
++static char *getpassphrase(const char *prompt);
++#ifndef NULL_PTR
++#define NULL_PTR NULL
++#endif
++#define CK_DEFINE_FUNCTION(returnType, name) \
++	returnType __declspec(dllexport) name
++#define CK_DECLARE_FUNCTION(returnType, name) \
++	returnType __declspec(dllimport) name
++#define CK_DECLARE_FUNCTION_POINTER(returnType, name) \
++	returnType __declspec(dllimport) (* name)
++#else
++#include <unistd.h>
++#endif
++
++#ifndef NOPTHREADS
++#include <pthread.h>
++#endif
++
++#ifndef OPENSSL_NO_HW
++#ifndef OPENSSL_NO_HW_PK11
++#ifndef OPENSSL_NO_HW_PK11SO
++
++#ifdef OPENSSL_SYS_WIN32
++#pragma pack(push, cryptoki, 1)
++#include "cryptoki.h"
++#include "pkcs11.h"
++#pragma pack(pop, cryptoki)
++#else
++#include "cryptoki.h"
++#include "pkcs11.h"
++#endif
++#include "hw_pk11so.h"
++#include "hw_pk11_err.h"
++
++static CK_BBOOL pk11_login_done = CK_FALSE;
++extern CK_SLOT_ID pubkey_SLOTID;
++#ifndef NOPTHREADS
++extern pthread_mutex_t *token_lock;
++#endif
++
++#if !(defined(HAVE_GETPASSPHRASE) || (defined (__SVR4) && defined (__sun)))
++#define getpassphrase(x)	getpass(x)
++#endif
++
++/* RSA stuff */
++static int pk11_RSA_sign(int type, const unsigned char *m, unsigned int m_len,
++	unsigned char *sigret, unsigned int *siglen, const RSA *rsa);
++EVP_PKEY *pk11_load_privkey(ENGINE*, const char *privkey_file,
++	UI_METHOD *ui_method, void *callback_data);
++EVP_PKEY *pk11_load_pubkey(ENGINE*, const char *pubkey_file,
++	UI_METHOD *ui_method, void *callback_data);
++
++static CK_OBJECT_HANDLE pk11_get_public_rsa_key(RSA* rsa, RSA** key_ptr,
++	BIGNUM **rsa_n_num, BIGNUM **rsa_e_num, CK_SESSION_HANDLE session);
++static CK_OBJECT_HANDLE pk11_get_private_rsa_key(RSA* rsa, RSA** key_ptr,
++	BIGNUM **rsa_d_num, BIGNUM **rsa_n_num, BIGNUM **rsa_e_num,
++	CK_SESSION_HANDLE session);
++
++static int check_new_rsa_key_pub(PK11_SESSION *sp, const RSA *rsa);
++static int check_new_rsa_key_priv(PK11_SESSION *sp, const RSA *rsa);
++
++static int find_one_object(PK11_OPTYPE op, CK_SESSION_HANDLE s,
++	CK_ATTRIBUTE_PTR ptempl, CK_ULONG nattr, CK_OBJECT_HANDLE_PTR pkey);
++static int init_template_value(BIGNUM *bn, CK_VOID_PTR *pValue,
++	CK_ULONG *ulValueLen);
++static void attr_to_BN(CK_ATTRIBUTE_PTR attr, CK_BYTE attr_data[], BIGNUM **bn);
++
++static int pk11_token_login(CK_SESSION_HANDLE session, CK_BBOOL *login_done,
++	CK_BBOOL is_private);
++
++/* Read mode string to be used for fopen() */
++#if SOLARIS_OPENSSL
++static char *read_mode_flags = "rF";
++#else
++static char *read_mode_flags = "r";
++#endif
++
++/*
++ * increment/create reference for an asymmetric key handle via active list
++ * manipulation. If active list operation fails, unlock (if locked), set error
++ * variable and jump to the specified label.
++ */
++#define	KEY_HANDLE_REFHOLD(key_handle, alg_type, unlock, var, label)	\
++	{								\
++	if (pk11_active_add(key_handle, alg_type) < 0)			\
++		{							\
++		var = TRUE;						\
++		if (unlock)						\
++			UNLOCK_OBJSTORE(alg_type);			\
++		goto label;						\
++		}							\
++	}
++
++/*
++ * Find active list entry according to object handle and return pointer to the
++ * entry otherwise return NULL.
++ *
++ * This function presumes it is called with lock protecting the active list
++ * held.
++ */
++static PK11_active *pk11_active_find(CK_OBJECT_HANDLE h, PK11_OPTYPE type)
++	{
++	PK11_active *entry;
++
++	for (entry = active_list[type]; entry != NULL; entry = entry->next)
++		if (entry->h == h)
++			return (entry);
++
++	return (NULL);
++	}
++
++/*
++ * Search for an entry in the active list using PKCS#11 object handle as a
++ * search key and return refcnt of the found/created entry or -1 in case of
++ * failure.
++ *
++ * This function presumes it is called with lock protecting the active list
++ * held.
++ */
++int
++pk11_active_add(CK_OBJECT_HANDLE h, PK11_OPTYPE type)
++	{
++	PK11_active *entry = NULL;
++
++	if (h == CK_INVALID_HANDLE)
++		{
++		PK11err(PK11_F_ACTIVE_ADD, PK11_R_INVALID_HANDLE);
++		return (-1);
++		}
++
++	/* search for entry in the active list */
++	if ((entry = pk11_active_find(h, type)) != NULL)
++		entry->refcnt++;
++	else
++		{
++		/* not found, create new entry and add it to the list */
++		entry = OPENSSL_malloc(sizeof (PK11_active));
++		if (entry == NULL)
++			{
++			PK11err(PK11_F_ACTIVE_ADD, PK11_R_MALLOC_FAILURE);
++			return (-1);
++			}
++		entry->h = h;
++		entry->refcnt = 1;
++		entry->prev = NULL;
++		entry->next = NULL;
++		/* connect the newly created entry to the list */
++		if (active_list[type] == NULL)
++			active_list[type] = entry;
++		else /* make the entry first in the list */
++			{
++			entry->next = active_list[type];
++			active_list[type]->prev = entry;
++			active_list[type] = entry;
++			}
++		}
++
++	return (entry->refcnt);
++	}
++
++/*
++ * Remove active list entry from the list and free it.
++ *
++ * This function presumes it is called with lock protecting the active list
++ * held.
++ */
++void
++pk11_active_remove(PK11_active *entry, PK11_OPTYPE type)
++	{
++	PK11_active *prev_entry;
++
++	/* remove the entry from the list and free it */
++	if ((prev_entry = entry->prev) != NULL)
++		{
++		prev_entry->next = entry->next;
++		if (entry->next != NULL)
++			entry->next->prev = prev_entry;
++		}
++	else
++		{
++		active_list[type] = entry->next;
++		/* we were the first but not the only one */
++		if (entry->next != NULL)
++			entry->next->prev = NULL;
++		}
++
++	/* sanitization */
++	entry->h = CK_INVALID_HANDLE;
++	entry->prev = NULL;
++	entry->next = NULL;
++	OPENSSL_free(entry);
++	}
++
++/* Free all entries from the active list. */
++void
++pk11_free_active_list(PK11_OPTYPE type)
++	{
++	PK11_active *entry;
++
++	/* only for asymmetric types since only they have C_Find* locks. */
++	switch (type)
++		{
++		case OP_RSA:
++			break;
++		default:
++			return;
++		}
++
++	/* see find_lock array definition for more info on object locking */
++	LOCK_OBJSTORE(type);
++	while ((entry = active_list[type]) != NULL)
++		pk11_active_remove(entry, type);
++	UNLOCK_OBJSTORE(type);
++	}
++
++/*
++ * Search for active list entry associated with given PKCS#11 object handle,
++ * decrement its refcnt and if it drops to 0, disconnect the entry and free it.
++ *
++ * Return 1 if the PKCS#11 object associated with the entry has no references,
++ * return 0 if there is at least one reference, -1 on error.
++ *
++ * This function presumes it is called with lock protecting the active list
++ * held.
++ */
++int
++pk11_active_delete(CK_OBJECT_HANDLE h, PK11_OPTYPE type)
++	{
++	PK11_active *entry = NULL;
++
++	if ((entry = pk11_active_find(h, type)) == NULL)
++		{
++		PK11err(PK11_F_ACTIVE_DELETE, PK11_R_INVALID_HANDLE);
++		return (-1);
++		}
++
++	OPENSSL_assert(entry->refcnt > 0);
++	entry->refcnt--;
++	if (entry->refcnt == 0)
++		{
++		pk11_active_remove(entry, type);
++		return (1);
++		}
++
++	return (0);
++	}
++
++/* Our internal RSA_METHOD that we provide pointers to */
++static RSA_METHOD pk11_rsa;
++
++RSA_METHOD *
++PK11_RSA(void)
++	{
++	const RSA_METHOD *rsa;
++
++	if (pk11_rsa.name == NULL)
++		{
++		rsa = RSA_PKCS1_SSLeay();
++		memcpy(&pk11_rsa, rsa, sizeof(*rsa));
++		pk11_rsa.name = "PKCS#11 RSA method";
++		pk11_rsa.rsa_sign = pk11_RSA_sign;
++		}
++	return (&pk11_rsa);
++	}
++
++/* Size of an SSL signature: MD5+SHA1 */
++#define	SSL_SIG_LENGTH		36
++
++static CK_BBOOL true = TRUE;
++static CK_BBOOL false = FALSE;
++
++/*
++ * Standard engine interface function. Majority codes here are from
++ * rsa/rsa_sign.c. We replaced the decrypt function call by C_Sign of PKCS#11.
++ * See more details in rsa/rsa_sign.c
++ */
++static int pk11_RSA_sign(int type, const unsigned char *m, unsigned int m_len,
++	unsigned char *sigret, unsigned int *siglen, const RSA *rsa)
++	{
++	X509_SIG sig;
++	ASN1_TYPE parameter;
++	int i, j = 0;
++	unsigned char *p, *s = NULL;
++	X509_ALGOR algor;
++	ASN1_OCTET_STRING digest;
++	CK_RV rv;
++	CK_MECHANISM mech_rsa = {CKM_RSA_PKCS, NULL, 0};
++	CK_MECHANISM *p_mech = &mech_rsa;
++	CK_OBJECT_HANDLE h_priv_key;
++	PK11_SESSION *sp = NULL;
++	int ret = 0;
++	unsigned long ulsiglen;
++
++	/* Encode the digest */
++	/* Special case: SSL signature, just check the length */
++	if (type == NID_md5_sha1)
++		{
++		if (m_len != SSL_SIG_LENGTH)
++			{
++			PK11err(PK11_F_RSA_SIGN,
++				PK11_R_INVALID_MESSAGE_LENGTH);
++			goto err;
++			}
++		i = SSL_SIG_LENGTH;
++		s = (unsigned char *)m;
++		}
++	else
++		{
++		sig.algor = &algor;
++		sig.algor->algorithm = OBJ_nid2obj(type);
++		if (sig.algor->algorithm == NULL)
++			{
++			PK11err(PK11_F_RSA_SIGN,
++				PK11_R_UNKNOWN_ALGORITHM_TYPE);
++			goto err;
++			}
++		if (sig.algor->algorithm->length == 0)
++			{
++			PK11err(PK11_F_RSA_SIGN,
++				PK11_R_UNKNOWN_ASN1_OBJECT_ID);
++			goto err;
++			}
++		parameter.type = V_ASN1_NULL;
++		parameter.value.ptr = NULL;
++		sig.algor->parameter = &parameter;
++
++		sig.digest = &digest;
++		sig.digest->data = (unsigned char *)m;
++		sig.digest->length = m_len;
++
++		i = i2d_X509_SIG(&sig, NULL);
++		}
++
++	j = RSA_size(rsa);
++	if ((i - RSA_PKCS1_PADDING) > j)
++		{
++		PK11err(PK11_F_RSA_SIGN, PK11_R_DIGEST_TOO_BIG);
++		goto err;
++		}
++
++	if (type != NID_md5_sha1)
++		{
++		s = (unsigned char *)OPENSSL_malloc((unsigned int)(j + 1));
++		if (s == NULL)
++			{
++			PK11err(PK11_F_RSA_SIGN, PK11_R_MALLOC_FAILURE);
++			goto err;
++			}
++		p = s;
++		(void) i2d_X509_SIG(&sig, &p);
++		}
++
++	if ((sp = pk11_get_session(OP_RSA)) == NULL)
++		goto err;
++
++	(void) check_new_rsa_key_priv(sp, rsa);
++
++	h_priv_key = sp->opdata_rsa_priv_key;
++	if (h_priv_key == CK_INVALID_HANDLE)
++		h_priv_key = sp->opdata_rsa_priv_key =
++			pk11_get_private_rsa_key((RSA *)rsa,
++			    &sp->opdata_rsa_priv, &sp->opdata_rsa_d_num,
++			    &sp->opdata_rsa_pn_num, &sp->opdata_rsa_pe_num,
++			    sp->session);
++
++	if (h_priv_key != CK_INVALID_HANDLE)
++		{
++		rv = pFuncList->C_SignInit(sp->session, p_mech, h_priv_key);
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_SIGN, PK11_R_SIGNINIT, rv);
++			goto err;
++			}
++
++		ulsiglen = j;
++		rv = pFuncList->C_Sign(sp->session, s, i, sigret,
++			(CK_ULONG_PTR) &ulsiglen);
++		*siglen = ulsiglen;
++
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_RSA_SIGN, PK11_R_SIGN, rv);
++			goto err;
++			}
++		ret = 1;
++		}
++
++err:
++	if ((type != NID_md5_sha1) && (s != NULL))
++		{
++		(void) memset(s, 0, (unsigned int)(j + 1));
++		OPENSSL_free(s);
++		}
++
++	pk11_return_session(sp, OP_RSA);
++	return (ret);
++	}
++
++static int hndidx_rsa = -1;
++
++#define	MAXATTR	1024
++
++/*
++ * Load RSA private key from a file or get its PKCS#11 handle if stored in the
++ * PKCS#11 token.
++ */
++/* ARGSUSED */
++EVP_PKEY *pk11_load_privkey(ENGINE *e, const char *privkey_file,
++	UI_METHOD *ui_method, void *callback_data)
++	{
++	EVP_PKEY *pkey = NULL;
++	FILE *privkey;
++	CK_OBJECT_HANDLE  h_priv_key = CK_INVALID_HANDLE;
++	RSA *rsa = NULL;
++	PK11_SESSION *sp;
++	/* Anything else below is needed for the key by reference extension. */
++	CK_RV rv;
++	CK_BBOOL is_token = TRUE;
++	CK_BBOOL rollback = FALSE;
++	CK_BYTE attr_data[2][MAXATTR];
++	CK_OBJECT_CLASS key_class = CKO_PRIVATE_KEY;
++	CK_OBJECT_HANDLE ks_key = CK_INVALID_HANDLE;	/* key in keystore */
++
++	/* we look for private keys only */
++	CK_ATTRIBUTE search_templ[] =
++		{
++		{CKA_TOKEN, &is_token, sizeof(is_token)},
++		{CKA_CLASS, &key_class, sizeof(key_class)},
++		{CKA_LABEL, NULL, 0}
++		};
++
++	/*
++	 * These public attributes are needed to initialize the OpenSSL RSA
++	 * structure with something we can use to look up the key. Note that we
++	 * never ask for private components.
++	 */
++	CK_ATTRIBUTE get_templ[] =
++		{
++		{CKA_MODULUS, (void *)attr_data[0], MAXATTR},		/* n */
++		{CKA_PUBLIC_EXPONENT, (void *)attr_data[1], MAXATTR},	/* e */
++		};
++
++	if ((sp = pk11_get_session(OP_RSA)) == NULL)
++		return (NULL);
++
++	/*
++	 * Use simple scheme "pkcs11:<KEY_LABEL>" for now.
++	 */
++	if (strstr(privkey_file, "pkcs11:") == privkey_file)
++		{
++		search_templ[2].pValue = strstr(privkey_file, ":") + 1;
++		search_templ[2].ulValueLen = strlen(search_templ[2].pValue);
++
++		if (pk11_token_login(sp->session, &pk11_login_done,
++		    CK_TRUE) == 0)
++			goto err;
++
++		/*
++		 * Now let's try to find the key in the token. It is a failure
++		 * if we can't find it.
++		 */
++		if (find_one_object(OP_RSA, sp->session, search_templ, 3,
++		    &ks_key) == 0)
++			goto err;
++
++		if (hndidx_rsa == -1)
++			hndidx_rsa = RSA_get_ex_new_index(0,
++				        "pkcs11 RSA HSM key handle",
++					NULL, NULL, NULL);
++
++		/*
++		 * We might have a cache hit which we could confirm
++		 * according to the 'n'/'e' params, RSA public pointer
++		 * as NULL, and non-NULL RSA private pointer. However,
++		 * it is easier just to recreate everything. We expect
++		 * the keys to be loaded once and used many times. We
++		 * do not check the return value because even in case
++		 * of failure the sp structure will have both key
++		 * pointer and object handle cleaned and
++		 * pk11_destroy_object() reports the failure to the
++		 * OpenSSL error message buffer.
++		 */
++		(void) pk11_destroy_rsa_object_priv(sp, TRUE);
++
++		sp->opdata_rsa_priv_key = ks_key;
++		/* This object shall not be deleted on a cache miss. */
++		sp->priv_persistent = CK_TRUE;
++
++		/*
++		 * Cache the RSA private structure pointer. We do not
++		 * use it now for key-by-ref keys but let's do it for
++		 * consistency reasons.
++		 */
++		if ((rsa = sp->opdata_rsa_priv = RSA_new_method(e)) == NULL)
++			goto err;
++
++		/*
++		 * Now we have to initialize an OpenSSL RSA structure,
++		 * everything else is 0 or NULL.
++		 */
++		rsa->flags = RSA_FLAG_SIGN_VER | RSA_FLAG_EXT_PKEY;
++		RSA_set_ex_data(rsa, hndidx_rsa, (void *) ks_key);
++
++		if ((rv = pFuncList->C_GetAttributeValue(sp->session, ks_key,
++		    get_templ, 2)) != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_LOAD_PRIVKEY,
++					 PK11_R_GETATTRIBUTVALUE, rv);
++			goto err;
++			}
++
++		/*
++		 * We do not use pk11_get_private_rsa_key() here so we
++		 * must take care of handle management ourselves.
++		 */
++		KEY_HANDLE_REFHOLD(ks_key, OP_RSA, FALSE, rollback, err);
++
++		/*
++		 * Those are the sensitive components we do not want to export
++		 * from the token at all: rsa->(d|p|q|dmp1|dmq1|iqmp).
++		 */
++		attr_to_BN(&get_templ[0], attr_data[0], &rsa->n);
++		attr_to_BN(&get_templ[1], attr_data[1], &rsa->e);
++		/*
++		 * Must have 'n'/'e' components in the session structure as
++		 * well. They serve as a public look-up key for the private key
++		 * in the keystore.
++		 */
++		attr_to_BN(&get_templ[0], attr_data[0],
++			&sp->opdata_rsa_pn_num);
++		attr_to_BN(&get_templ[1], attr_data[1],
++			&sp->opdata_rsa_pe_num);
++
++		if ((pkey = EVP_PKEY_new()) == NULL)
++			goto err;
++
++		if (EVP_PKEY_assign_RSA(pkey, rsa) == 0)
++			goto err;
++		}
++	else if ((privkey = fopen(privkey_file, read_mode_flags)) != NULL)
++		{
++		pkey = PEM_read_PrivateKey(privkey, NULL, NULL, NULL);
++		(void) fclose(privkey);
++		if (pkey != NULL)
++			{
++			rsa = EVP_PKEY_get1_RSA(pkey);
++			if (rsa != NULL)
++				{
++				/*
++				 * This will always destroy the RSA
++				 * object since we have a new RSA
++				 * structure here.
++				 */
++				(void) check_new_rsa_key_priv(sp, rsa);
++				sp->priv_persistent = CK_FALSE;
++
++				h_priv_key = sp->opdata_rsa_priv_key =
++				    pk11_get_private_rsa_key(rsa,
++				    &sp->opdata_rsa_priv,
++				    &sp->opdata_rsa_d_num,
++				    &sp->opdata_rsa_pn_num,
++				    &sp->opdata_rsa_pe_num, sp->session);
++				if (h_priv_key == CK_INVALID_HANDLE)
++					goto err;
++				}
++			else
++				goto err;
++			}
++		}
++
++	pk11_return_session(sp, OP_RSA);
++	return (pkey);
++err:
++	pk11_return_session(sp, OP_RSA);
++	if (rsa != NULL)
++		RSA_free(rsa);
++	if (pkey != NULL)
++		{
++		EVP_PKEY_free(pkey);
++		pkey = NULL;
++		}
++	rollback = rollback;
++	return (pkey);
++	}
++
++/*
++ * Load RSA public key from a file or get its PKCS#11 handle if stored in the
++ * PKCS#11 token.
++ */
++/* ARGSUSED */
++EVP_PKEY *pk11_load_pubkey(ENGINE *e, const char *pubkey_file,
++	UI_METHOD *ui_method, void *callback_data)
++	{
++	EVP_PKEY *pkey = NULL;
++	FILE *pubkey;
++	CK_OBJECT_HANDLE h_pub_key = CK_INVALID_HANDLE;
++	RSA *rsa = NULL;
++	PK11_SESSION *sp;
++	/* Anything else below is needed for the key by reference extension. */
++	CK_RV rv;
++	CK_BBOOL is_token = TRUE;
++	CK_BYTE attr_data[2][MAXATTR];
++	CK_OBJECT_CLASS key_class = CKO_PUBLIC_KEY;
++	CK_OBJECT_HANDLE ks_key = CK_INVALID_HANDLE;	/* key in keystore */
++
++	/* we look for public keys only */
++	CK_ATTRIBUTE search_templ[] =
++		{
++		{CKA_TOKEN, &is_token, sizeof(is_token)},
++		{CKA_CLASS, &key_class, sizeof(key_class)},
++		{CKA_LABEL, NULL, 0}
++		};
++
++	/*
++	 * These public attributes are needed to initialize OpenSSL RSA
++	 * structure with something we can use to look up the key.
++	 */
++	CK_ATTRIBUTE get_templ[] =
++		{
++		{CKA_MODULUS, (void *)attr_data[0], MAXATTR},		/* n */
++		{CKA_PUBLIC_EXPONENT, (void *)attr_data[1], MAXATTR},	/* e */
++		};
++
++	if ((sp = pk11_get_session(OP_RSA)) == NULL)
++		return (NULL);
++
++	/*
++	 * Use simple scheme "pkcs11:<KEY_LABEL>" for now.
++	 */
++	if (strstr(pubkey_file, "pkcs11:") == pubkey_file)
++		{
++		search_templ[2].pValue = strstr(pubkey_file, ":") + 1;
++		search_templ[2].ulValueLen = strlen(search_templ[2].pValue);
++
++		if (pk11_token_login(sp->session, &pk11_login_done,
++		    CK_FALSE) == 0)
++			goto err;
++
++		/*
++		 * Now let's try to find the key in the token. It is a failure
++		 * if we can't find it.
++		 */
++		if (find_one_object(OP_RSA, sp->session, search_templ, 3,
++		    &ks_key) == 0)
++			goto err;
++
++		/*
++		 * We load a new public key so we will create a new RSA
++		 * structure. No cache hit is possible.
++		 */
++		(void) pk11_destroy_rsa_object_pub(sp, TRUE);
++
++		sp->opdata_rsa_pub_key = ks_key;
++		/* This object shall not be deleted on a cache miss. */
++		sp->pub_persistent = CK_TRUE;
++
++		/*
++		 * Cache the RSA public structure pointer.
++		 */
++		if ((rsa = sp->opdata_rsa_pub = RSA_new_method(e)) == NULL)
++			goto err;
++
++		/*
++		 * Now we have to initialize an OpenSSL RSA structure,
++		 * everything else is 0 or NULL.
++		 */
++		rsa->flags = RSA_FLAG_SIGN_VER;
++
++		if ((rv = pFuncList->C_GetAttributeValue(sp->session, ks_key,
++		    get_templ, 2)) != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_LOAD_PUBKEY,
++					 PK11_R_GETATTRIBUTVALUE, rv);
++			goto err;
++			}
++
++		attr_to_BN(&get_templ[0], attr_data[0], &rsa->n);
++		attr_to_BN(&get_templ[1], attr_data[1], &rsa->e);
++
++		if ((pkey = EVP_PKEY_new()) == NULL)
++			goto err;
++
++		if (EVP_PKEY_assign_RSA(pkey, rsa) == 0)
++			goto err;
++
++		/*
++		 * Create a session object from it so that when calling
++		 * pk11_get_public_rsa_key() the next time, we can find it. The
++		 * reason why we do that is that we cannot tell from the RSA
++		 * structure (OpenSSL RSA structure does not have any room for
++		 * additional data used by the engine, for example) if it bears
++		 * a public key stored in the keystore or not so it's better if
++		 * we always have a session key. Note that this is different
++		 * from what we do for the private keystore objects but in that
++		 * case, we can tell from the RSA structure that the keystore
++		 * object is in play - the 'd' component is NULL in that case.
++		 */
++		h_pub_key = sp->opdata_rsa_pub_key =
++		    pk11_get_public_rsa_key(rsa,
++		    &sp->opdata_rsa_pub, &sp->opdata_rsa_n_num,
++		    &sp->opdata_rsa_e_num, sp->session);
++		if (h_pub_key == CK_INVALID_HANDLE)
++			goto err;
++		}
++	else if ((pubkey = fopen(pubkey_file, read_mode_flags)) != NULL)
++		{
++		pkey = PEM_read_PUBKEY(pubkey, NULL, NULL, NULL);
++		(void) fclose(pubkey);
++		if (pkey != NULL)
++			{
++			rsa = EVP_PKEY_get1_RSA(pkey);
++			if (rsa != NULL)
++				{
++				/*
++				 * This will always destroy the RSA
++				 * object since we have a new RSA
++				 * structure here.
++				 */
++				(void) check_new_rsa_key_pub(sp, rsa);
++				sp->pub_persistent = CK_FALSE;
++
++				h_pub_key = sp->opdata_rsa_pub_key =
++				    pk11_get_public_rsa_key(rsa,
++				    &sp->opdata_rsa_pub, &sp->opdata_rsa_n_num,
++				    &sp->opdata_rsa_e_num, sp->session);
++				if (h_pub_key == CK_INVALID_HANDLE)
++					goto err;
++				}
++			else
++				goto err;
++			}
++		}
++
++	pk11_return_session(sp, OP_RSA);
++	return (pkey);
++err:
++	pk11_return_session(sp, OP_RSA);
++	if (rsa != NULL)
++		RSA_free(rsa);
++	if (pkey != NULL)
++		{
++		EVP_PKEY_free(pkey);
++		pkey = NULL;
++		}
++	return (pkey);
++	}
++
++/*
++ * Create a public key object in a session from a given rsa structure.
++ * The *rsa_n_num and *rsa_e_num pointers are non-NULL for RSA public keys.
++ */
++static CK_OBJECT_HANDLE pk11_get_public_rsa_key(RSA *rsa,
++    RSA **key_ptr, BIGNUM **rsa_n_num, BIGNUM **rsa_e_num,
++    CK_SESSION_HANDLE session)
++	{
++	CK_RV rv;
++	CK_OBJECT_HANDLE h_key = CK_INVALID_HANDLE;
++	CK_ULONG found;
++	CK_OBJECT_CLASS o_key = CKO_PUBLIC_KEY;
++	CK_KEY_TYPE k_type = CKK_RSA;
++	CK_ULONG ul_key_attr_count = 8;
++	CK_BBOOL rollback = FALSE;
++
++	CK_ATTRIBUTE  a_key_template[] =
++		{
++		{CKA_CLASS, (void *) NULL, sizeof (CK_OBJECT_CLASS)},
++		{CKA_KEY_TYPE, (void *) NULL, sizeof (CK_KEY_TYPE)},
++		{CKA_TOKEN, &false, sizeof (true)},
++		{CKA_ENCRYPT, &true, sizeof (true)},
++		{CKA_VERIFY, &true, sizeof (true)},
++		{CKA_VERIFY_RECOVER, &true, sizeof (true)},
++		{CKA_MODULUS, (void *)NULL, 0},
++		{CKA_PUBLIC_EXPONENT, (void *)NULL, 0}
++		};
++
++	int i;
++
++	a_key_template[0].pValue = &o_key;
++	a_key_template[1].pValue = &k_type;
++
++	a_key_template[6].ulValueLen = BN_num_bytes(rsa->n);
++	a_key_template[6].pValue = (CK_VOID_PTR)OPENSSL_malloc(
++		(size_t)a_key_template[6].ulValueLen);
++	if (a_key_template[6].pValue == NULL)
++		{
++		PK11err(PK11_F_GET_PUB_RSA_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
++
++	BN_bn2bin(rsa->n, a_key_template[6].pValue);
++
++	a_key_template[7].ulValueLen = BN_num_bytes(rsa->e);
++	a_key_template[7].pValue = (CK_VOID_PTR)OPENSSL_malloc(
++		(size_t)a_key_template[7].ulValueLen);
++	if (a_key_template[7].pValue == NULL)
++		{
++		PK11err(PK11_F_GET_PUB_RSA_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
++
++	BN_bn2bin(rsa->e, a_key_template[7].pValue);
++
++	/* see find_lock array definition for more info on object locking */
++	LOCK_OBJSTORE(OP_RSA);
++
++	rv = pFuncList->C_FindObjectsInit(session, a_key_template,
++		ul_key_attr_count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PUB_RSA_KEY,
++		    PK11_R_FINDOBJECTSINIT, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjects(session, &h_key, 1, &found);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PUB_RSA_KEY,
++		    PK11_R_FINDOBJECTS, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjectsFinal(session);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PUB_RSA_KEY,
++		    PK11_R_FINDOBJECTSFINAL, rv);
++		goto err;
++		}
++
++	if (found == 0)
++		{
++		rv = pFuncList->C_CreateObject(session,
++			a_key_template, ul_key_attr_count, &h_key);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_GET_PUB_RSA_KEY,
++			    PK11_R_CREATEOBJECT, rv);
++			goto err;
++			}
++		}
++
++	if (rsa_n_num != NULL)
++		if ((*rsa_n_num = BN_dup(rsa->n)) == NULL)
++			{
++			PK11err(PK11_F_GET_PUB_RSA_KEY, PK11_R_MALLOC_FAILURE);
++			rollback = TRUE;
++			goto err;
++			}
++	if (rsa_e_num != NULL)
++		if ((*rsa_e_num = BN_dup(rsa->e)) == NULL)
++			{
++			PK11err(PK11_F_GET_PUB_RSA_KEY, PK11_R_MALLOC_FAILURE);
++			BN_free(*rsa_n_num);
++			*rsa_n_num = NULL;
++			rollback = TRUE;
++			goto err;
++			}
++
++	/* LINTED: E_CONSTANT_CONDITION */
++	KEY_HANDLE_REFHOLD(h_key, OP_RSA, FALSE, rollback, err);
++	if (key_ptr != NULL)
++		*key_ptr = rsa;
++
++err:
++	if (rollback)
++		{
++		/*
++		 * We do not care about the return value from C_DestroyObject()
++		 * since we are doing rollback.
++		 */
++		if (found == 0)
++			(void) pFuncList->C_DestroyObject(session, h_key);
++		h_key = CK_INVALID_HANDLE;
++		}
++
++	UNLOCK_OBJSTORE(OP_RSA);
++
++malloc_err:
++	for (i = 6; i <= 7; i++)
++		{
++		if (a_key_template[i].pValue != NULL)
++			{
++			OPENSSL_free(a_key_template[i].pValue);
++			a_key_template[i].pValue = NULL;
++			}
++		}
++
++	return (h_key);
++	}
++
++/*
++ * Create a private key object in the session from a given rsa structure.
++ * The *rsa_d_num pointer is non-NULL for RSA private keys.
++ */
++static CK_OBJECT_HANDLE
++pk11_get_private_rsa_key(RSA *rsa, RSA **key_ptr, BIGNUM **rsa_d_num,
++    BIGNUM **rsa_n_num, BIGNUM **rsa_e_num, CK_SESSION_HANDLE session)
++	{
++	CK_RV rv;
++	CK_OBJECT_HANDLE h_key = CK_INVALID_HANDLE;
++	int i;
++	CK_ULONG found;
++	CK_OBJECT_CLASS o_key = CKO_PRIVATE_KEY;
++	CK_KEY_TYPE k_type = CKK_RSA;
++	CK_ULONG ul_key_attr_count = 14;
++	CK_BBOOL rollback = FALSE;
++
++	/* Both CKA_TOKEN and CKA_SENSITIVE have to be FALSE for session keys */
++	CK_ATTRIBUTE  a_key_template[] =
++		{
++		{CKA_CLASS, (void *) NULL, sizeof (CK_OBJECT_CLASS)},
++		{CKA_KEY_TYPE, (void *) NULL, sizeof (CK_KEY_TYPE)},
++		{CKA_TOKEN, &false, sizeof (true)},
++		{CKA_SENSITIVE, &false, sizeof (true)},
++		{CKA_DECRYPT, &true, sizeof (true)},
++		{CKA_SIGN, &true, sizeof (true)},
++		{CKA_MODULUS, (void *)NULL, 0},
++		{CKA_PUBLIC_EXPONENT, (void *)NULL, 0},
++		{CKA_PRIVATE_EXPONENT, (void *)NULL, 0},
++		{CKA_PRIME_1, (void *)NULL, 0},
++		{CKA_PRIME_2, (void *)NULL, 0},
++		{CKA_EXPONENT_1, (void *)NULL, 0},
++		{CKA_EXPONENT_2, (void *)NULL, 0},
++		{CKA_COEFFICIENT, (void *)NULL, 0},
++		};
++
++	if ((rsa->flags & RSA_FLAG_EXT_PKEY) != 0) {
++		h_key = (CK_OBJECT_HANDLE)RSA_get_ex_data(rsa, hndidx_rsa);
++		LOCK_OBJSTORE(OP_RSA);
++		goto set;
++	}
++	
++	a_key_template[0].pValue = &o_key;
++	a_key_template[1].pValue = &k_type;
++
++	/* Put the private key components into the template */
++	if (init_template_value(rsa->n, &a_key_template[6].pValue,
++		&a_key_template[6].ulValueLen) == 0 ||
++	    init_template_value(rsa->e, &a_key_template[7].pValue,
++		&a_key_template[7].ulValueLen) == 0 ||
++	    init_template_value(rsa->d, &a_key_template[8].pValue,
++		&a_key_template[8].ulValueLen) == 0 ||
++	    init_template_value(rsa->p, &a_key_template[9].pValue,
++		&a_key_template[9].ulValueLen) == 0 ||
++	    init_template_value(rsa->q, &a_key_template[10].pValue,
++		&a_key_template[10].ulValueLen) == 0 ||
++	    init_template_value(rsa->dmp1, &a_key_template[11].pValue,
++		&a_key_template[11].ulValueLen) == 0 ||
++	    init_template_value(rsa->dmq1, &a_key_template[12].pValue,
++		&a_key_template[12].ulValueLen) == 0 ||
++	    init_template_value(rsa->iqmp, &a_key_template[13].pValue,
++		&a_key_template[13].ulValueLen) == 0)
++		{
++		PK11err(PK11_F_GET_PRIV_RSA_KEY, PK11_R_MALLOC_FAILURE);
++		goto malloc_err;
++		}
++
++	/* see find_lock array definition for more info on object locking */
++	LOCK_OBJSTORE(OP_RSA);
++
++	/*
++	 * We are getting the private key but the private 'd'
++	 * component is NULL.  That means this is key by reference RSA
++	 * key. In that case, we can use only public components for
++	 * searching for the private key handle.
++	 */
++	if (rsa->d == NULL)
++		{
++		ul_key_attr_count = 8;
++		/*
++		 * We will perform the search in the token, not in the existing
++		 * session keys.
++		 */
++		a_key_template[2].pValue = &true;
++		}
++
++	rv = pFuncList->C_FindObjectsInit(session, a_key_template,
++		ul_key_attr_count);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PRIV_RSA_KEY,
++		    PK11_R_FINDOBJECTSINIT, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjects(session, &h_key, 1, &found);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PRIV_RSA_KEY,
++		    PK11_R_FINDOBJECTS, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjectsFinal(session);
++
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_GET_PRIV_RSA_KEY,
++		    PK11_R_FINDOBJECTSFINAL, rv);
++		goto err;
++		}
++
++	if (found == 0)
++		{
++		/*
++		 * We have an RSA structure with 'n'/'e' components
++		 * only so we tried to find the private key in the
++		 * keystore. If it was really a token key we have a
++		 * problem. Note that for other key types we just
++		 * create a new session key using the private
++		 * components from the RSA structure.
++		 */
++		if (rsa->d == NULL)
++			{
++			PK11err(PK11_F_GET_PRIV_RSA_KEY,
++			    PK11_R_PRIV_KEY_NOT_FOUND);
++			goto err;
++			}
++
++		rv = pFuncList->C_CreateObject(session,
++			a_key_template, ul_key_attr_count, &h_key);
++		if (rv != CKR_OK)
++			{
++			PK11err_add_data(PK11_F_GET_PRIV_RSA_KEY,
++				PK11_R_CREATEOBJECT, rv);
++			goto err;
++			}
++		}
++
++set:
++	if (rsa_d_num != NULL)
++		{
++		/*
++		 * When RSA keys by reference code is used, we never
++		 * extract private components from the keystore. In
++		 * that case 'd' was set to NULL and we expect the
++		 * application to properly cope with that. It is
++		 * documented in openssl(5). In general, if keys by
++		 * reference are used we expect it to be used
++		 * exclusively using the high level API and then there
++		 * is no problem. If the application expects the
++		 * private components to be read from the keystore
++		 * then that is not a supported way of usage.
++		 */
++		if (rsa->d != NULL && (*rsa_d_num = BN_dup(rsa->d)) == NULL)
++			{
++			PK11err(PK11_F_GET_PRIV_RSA_KEY, PK11_R_MALLOC_FAILURE);
++			rollback = TRUE;
++			goto err;
++			}
++		else
++			*rsa_d_num = NULL;
++		}
++
++	/*
++	 * For the key by reference code, we need public components as well
++	 * since 'd' component is always NULL. For that reason, we always cache
++	 * 'n'/'e' components as well.
++	 */
++	*rsa_n_num = BN_dup(rsa->n);
++	*rsa_e_num = BN_dup(rsa->e);
++
++	/* LINTED: E_CONSTANT_CONDITION */
++	KEY_HANDLE_REFHOLD(h_key, OP_RSA, FALSE, rollback, err);
++	if (key_ptr != NULL)
++		*key_ptr = rsa;
++
++err:
++	if (rollback)
++		{
++		/*
++		 * We do not care about the return value from C_DestroyObject()
++		 * since we are doing rollback.
++		 */
++		if (found == 0 &&
++		    (rsa->flags & RSA_FLAG_EXT_PKEY) == 0)
++			(void) pFuncList->C_DestroyObject(session, h_key);
++		h_key = CK_INVALID_HANDLE;
++		}
++
++	UNLOCK_OBJSTORE(OP_RSA);
++
++malloc_err:
++	/*
++	 * 6 to 13 entries in the key template are key components.
++	 * They need to be freed upon exit or error.
++	 */
++	for (i = 6; i <= 13; i++)
++		{
++		if (a_key_template[i].pValue != NULL)
++			{
++			(void) memset(a_key_template[i].pValue, 0,
++				a_key_template[i].ulValueLen);
++			OPENSSL_free(a_key_template[i].pValue);
++			a_key_template[i].pValue = NULL;
++			}
++		}
++
++	return (h_key);
++	}
++
++/*
++ * Check for cache miss and clean the object pointer and handle
++ * in such case. Return 1 for cache hit, 0 for cache miss.
++ */
++static int check_new_rsa_key_pub(PK11_SESSION *sp, const RSA *rsa)
++	{
++	/*
++	 * Provide protection against RSA structure reuse by making the
++	 * check for cache hit stronger. Only public components of RSA
++	 * key matter here so it is sufficient to compare them with values
++	 * cached in PK11_SESSION structure.
++	 *
++	 * We must check the handle as well since with key by reference, public
++	 * components 'n'/'e' are cached in private keys as well. That means we
++	 * could have a cache hit in a private key when looking for a public
++	 * key. That would not work, you cannot have one PKCS#11 object for
++	 * both data signing and verifying.
++	 */
++	if ((sp->opdata_rsa_pub != rsa) ||
++	    (BN_cmp(sp->opdata_rsa_n_num, rsa->n) != 0) ||
++	    (BN_cmp(sp->opdata_rsa_e_num, rsa->e) != 0) ||
++	    (sp->opdata_rsa_priv_key != CK_INVALID_HANDLE))
++		{
++		/*
++		 * We do not check the return value because even in case of
++		 * failure the sp structure will have both key pointer
++		 * and object handle cleaned and pk11_destroy_object()
++		 * reports the failure to the OpenSSL error message buffer.
++		 */
++		(void) pk11_destroy_rsa_object_pub(sp, TRUE);
++		return (0);
++		}
++	return (1);
++	}
++
++/*
++ * Check for cache miss and clean the object pointer and handle
++ * in such case. Return 1 for cache hit, 0 for cache miss.
++ */
++static int check_new_rsa_key_priv(PK11_SESSION *sp, const RSA *rsa)
++	{
++	/*
++	 * Provide protection against RSA structure reuse by making
++	 * the check for cache hit stronger. Comparing public exponent
++	 * of RSA key with value cached in PK11_SESSION structure
++	 * should be sufficient. Note that we want to compare the
++	 * public component since with the keys by reference
++	 * mechanism, private components are not in the RSA
++	 * structure. Also, see check_new_rsa_key_pub() about why we
++	 * compare the handle as well.
++	 */
++	if ((sp->opdata_rsa_priv != rsa) ||
++	    (BN_cmp(sp->opdata_rsa_pn_num, rsa->n) != 0) ||
++	    (BN_cmp(sp->opdata_rsa_pe_num, rsa->e) != 0) ||
++	    (sp->opdata_rsa_pn_num == NULL) ||
++	    (sp->opdata_rsa_pe_num == NULL) ||
++	    (sp->opdata_rsa_pub_key != CK_INVALID_HANDLE))
++		{
++		/*
++		 * We do not check the return value because even in case of
++		 * failure the sp structure will have both key pointer
++		 * and object handle cleaned and pk11_destroy_object()
++		 * reports the failure to the OpenSSL error message buffer.
++		 */
++		(void) pk11_destroy_rsa_object_priv(sp, TRUE);
++		return (0);
++		}
++	return (1);
++	}
++
++/*
++ * Local function to simplify key template population
++ * Return 0 -- error, 1 -- no error
++ */
++static int
++init_template_value(BIGNUM *bn, CK_VOID_PTR *p_value,
++	CK_ULONG *ul_value_len)
++	{
++	CK_ULONG len = 0;
++
++	/*
++	 * This function can be used on non-initialized BIGNUMs. It is
++	 * easier to check that here than individually in the callers.
++	 */
++	if (bn != NULL)
++		len = BN_num_bytes(bn);
++
++	if (bn == NULL || len == 0)
++		return (1);
++
++	*ul_value_len = len;
++	*p_value = (CK_VOID_PTR)OPENSSL_malloc((size_t)*ul_value_len);
++	if (*p_value == NULL)
++		return (0);
++
++	BN_bn2bin(bn, *p_value);
++
++	return (1);
++	}
++
++static void
++attr_to_BN(CK_ATTRIBUTE_PTR attr, CK_BYTE attr_data[], BIGNUM **bn)
++	{
++	if (attr->ulValueLen > 0)
++		*bn = BN_bin2bn(attr_data, attr->ulValueLen, NULL);
++	}
++
++/*
++ * Find one object in the token. It is an error if we can not find the
++ * object or if we find more objects based on the template we got.
++ *
++ * Returns:
++ *	1 OK
++ *	0 no object or more than 1 object found
++ */
++static int
++find_one_object(PK11_OPTYPE op, CK_SESSION_HANDLE s,
++    CK_ATTRIBUTE_PTR ptempl, CK_ULONG nattr, CK_OBJECT_HANDLE_PTR pkey)
++	{
++	CK_RV rv;
++	CK_ULONG objcnt;
++
++	LOCK_OBJSTORE(op);
++	if ((rv = pFuncList->C_FindObjectsInit(s, ptempl, nattr)) != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_FIND_ONE_OBJECT,
++		    PK11_R_FINDOBJECTSINIT, rv);
++		goto err;
++		}
++
++	rv = pFuncList->C_FindObjects(s, pkey, 1, &objcnt);
++	if (rv != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_FIND_ONE_OBJECT, PK11_R_FINDOBJECTS,
++		    rv);
++		goto err;
++		}
++
++	if (objcnt > 1)
++		{
++		PK11err(PK11_F_FIND_ONE_OBJECT,
++		    PK11_R_MORE_THAN_ONE_OBJECT_FOUND);
++		goto err;
++		}
++	else if (objcnt == 0)
++		{
++		PK11err(PK11_F_FIND_ONE_OBJECT, PK11_R_NO_OBJECT_FOUND);
++		goto err;
++		}
++
++	(void) pFuncList->C_FindObjectsFinal(s);
++	UNLOCK_OBJSTORE(op);
++	return (1);
++err:
++	UNLOCK_OBJSTORE(op);
++	return (0);
++	}
++
++/* from uri stuff */
++
++extern char *pk11_pin;
++
++static int pk11_get_pin(void);
++
++static int
++pk11_get_pin(void)
++{
++	char *pin;
++
++	/* The getpassphrase() function is not MT safe. */
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(token_lock);
++#else
++	CRYPTO_w_lock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	pin = getpassphrase("Enter PIN: ");
++	if (pin == NULL)
++		{
++		PK11err(PK11_F_GET_PIN, PK11_R_COULD_NOT_READ_PIN);
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		goto err;
++		}
++	pk11_pin = BUF_strdup(pin);
++	if (pk11_pin == NULL)
++		{
++		PK11err(PK11_F_LOAD_PRIVKEY, PK11_R_MALLOC_FAILURE);
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		goto err;
++		}
++	memset(pin, 0, strlen(pin));
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(token_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++	return (1);
++err:
++	return (0);
++	}
++
++/*
++ * Log in to the keystore if we are supposed to do that at all. Take care of
++ * reading and caching the PIN etc. Log in only once even when called from
++ * multiple threads.
++ *
++ * Returns:
++ *	1 on success
++ *	0 on failure
++ */
++static int
++pk11_token_login(CK_SESSION_HANDLE session, CK_BBOOL *login_done,
++    CK_BBOOL is_private)
++	{
++	CK_RV rv;
++
++#if 0
++	/* doesn't work on the AEP Keyper??? */
++	if ((pubkey_token_flags & CKF_TOKEN_INITIALIZED) == 0)
++		{
++		PK11err(PK11_F_TOKEN_LOGIN,
++		    PK11_R_TOKEN_NOT_INITIALIZED);
++		goto err;
++		}
++#endif
++
++	/*
++	 * If login is required or needed but the PIN has not been
++	 * even initialized we can bail out right now. Note that we
++	 * are supposed to always log in if we are going to access
++	 * private keys. However, we may need to log in even for
++	 * accessing public keys in case that the CKF_LOGIN_REQUIRED
++	 * flag is set.
++	 */
++	if (((pubkey_token_flags & CKF_LOGIN_REQUIRED) ||
++	     (is_private == CK_TRUE)) &&
++	    (~pubkey_token_flags & CKF_USER_PIN_INITIALIZED))
++		{
++		PK11err(PK11_F_TOKEN_LOGIN, PK11_R_TOKEN_PIN_NOT_SET);
++		goto err;
++		}
++
++	/*
++	 * Note on locking: it is possible that more than one thread
++	 * gets into pk11_get_pin() so we must deal with that. We
++	 * cannot avoid it since we cannot guard fork() in there with
++	 * a lock because we could end up in a dead lock in the
++	 * child. Why? Remember we are in a multithreaded environment
++	 * so we must lock all mutexes in the prefork function to
++	 * avoid a situation in which a thread that did not call
++	 * fork() held a lock, making future unlocking impossible. We
++	 * lock right before C_Login().
++	 */
++	if ((pubkey_token_flags & CKF_LOGIN_REQUIRED) ||
++	    (is_private == CK_TRUE))
++		{
++		if (*login_done == CK_FALSE)
++			{
++			if ((pk11_pin == NULL) && (pk11_get_pin() == 0))
++				{
++				PK11err(PK11_F_TOKEN_LOGIN,
++				    PK11_R_TOKEN_PIN_NOT_PROVIDED);
++				goto err;
++				}
++			}
++
++		/*
++		 * Note that what we are logging into is the keystore from
++		 * pubkey_SLOTID because we work with OP_RSA session type here.
++		 * That also means that we can work with only one keystore in
++		 * the engine.
++		 *
++		 * We must make sure we do not try to login more than once.
++		 * Also, see the comment above on locking strategy.
++		 */
++
++#ifndef NOPTHREADS
++		(void) pthread_mutex_lock(token_lock);
++#else
++		(void) pthread_mutex_lock(freelist_lock);
++#endif
++		if (*login_done == CK_FALSE)
++			{
++			if ((rv = pFuncList->C_Login(session,
++			    CKU_USER, (CK_UTF8CHAR*)pk11_pin,
++			    strlen(pk11_pin))) != CKR_OK)
++				{
++				PK11err_add_data(PK11_F_TOKEN_LOGIN,
++				    PK11_R_TOKEN_LOGIN_FAILED, rv);
++				goto err_locked;
++				}
++
++			*login_done = CK_TRUE;
++
++			}
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		}
++	else
++		{
++			/*
++			 * If token does not require login we take it as the
++			 * login was done.
++			 */
++			*login_done = CK_TRUE;
++		}
++
++	return (1);
++
++err_locked:
++	if (pk11_pin) {
++		memset(pk11_pin, 0, strlen(pk11_pin));
++		OPENSSL_free((void*)pk11_pin);
++	}
++	pk11_pin = NULL;
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(token_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++err:
++	return (0);
++	}
++
++/*
++ * Log in to the keystore in the child if we were logged in in the
++ * parent. There are similarities in the code with pk11_token_login()
++ * but still it is quite different so we need a separate function for
++ * this.
++ *
++ * Note that this function is called under the locked session mutex when fork is
++ * detected. That means that C_Login() will be called from the child just once.
++ *
++ * Returns:
++ *	1 on success
++ *	0 on failure
++ */
++int
++pk11_token_relogin(CK_SESSION_HANDLE session)
++	{
++	CK_RV rv;
++
++	if ((pk11_pin == NULL) && (pk11_get_pin() == 0))
++		goto err;
++
++#ifndef NOPTHREADS
++	(void) pthread_mutex_lock(token_lock);
++#else
++	(void) pthread_mutex_lock(freelist_lock);
++#endif
++	if ((rv = pFuncList->C_Login(session, CKU_USER,
++	    (CK_UTF8CHAR_PTR)pk11_pin, strlen(pk11_pin))) != CKR_OK)
++		{
++		PK11err_add_data(PK11_F_TOKEN_RELOGIN,
++		    PK11_R_TOKEN_LOGIN_FAILED, rv);
++#ifndef NOPTHREADS
++		(void) pthread_mutex_unlock(token_lock);
++#else
++		CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++		goto err;
++		}
++#ifndef NOPTHREADS
++	(void) pthread_mutex_unlock(token_lock);
++#else
++	CRYPTO_w_unlock(CRYPTO_LOCK_PK11_ENGINE);
++#endif
++
++	return (1);
++err:
++	return (0);
++	}
++
++#ifdef	OPENSSL_SYS_WIN32
++char *getpassphrase(const char *prompt)
++	{
++	static char buf[128];
++	HANDLE h;
++	DWORD cc, mode;
++	int cnt;
++
++	h = GetStdHandle(STD_INPUT_HANDLE);
++	fputs(prompt, stderr);
++	fflush(stderr);
++	fflush(stdout);
++	FlushConsoleInputBuffer(h);
++	GetConsoleMode(h, &mode);
++	SetConsoleMode(h, ENABLE_PROCESSED_INPUT);
++
++	for (cnt = 0; cnt < sizeof(buf) - 1; cnt++)
++		{
++		ReadFile(h, buf + cnt, 1, &cc, NULL);
++		if (buf[cnt] == '\r')
++			break;
++		fputc('*', stdout);
++		fflush(stderr);
++		fflush(stdout);
++		}
++
++	SetConsoleMode(h, mode);
++	buf[cnt] = '\0';
++	fputs("\n", stderr);
++	return buf;
++	}
++#endif	/* OPENSSL_SYS_WIN32 */
++#endif	/* OPENSSL_NO_HW_PK11SO */
++#endif	/* OPENSSL_NO_HW_PK11 */
++#endif	/* OPENSSL_NO_HW */
+Index: openssl/crypto/engine/pkcs11.h
+diff -u /dev/null openssl/crypto/engine/pkcs11.h:1.1.1.1
+--- /dev/null	Mon Jan 16 18:54:23 2012
++++ openssl/crypto/engine/pkcs11.h	Wed Oct 24 23:27:09 2007
+@@ -0,0 +1,299 @@
++/* pkcs11.h include file for PKCS #11. */
++/* $Revision: 1.2 $ */
++
++/* License to copy and use this software is granted provided that it is
++ * identified as "RSA Security Inc. PKCS #11 Cryptographic Token Interface
++ * (Cryptoki)" in all material mentioning or referencing this software.
++
++ * License is also granted to make and use derivative works provided that
++ * such works are identified as "derived from the RSA Security Inc. PKCS #11
++ * Cryptographic Token Interface (Cryptoki)" in all material mentioning or 
++ * referencing the derived work.
++
++ * RSA Security Inc. makes 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.
++ */
++
++#ifndef _PKCS11_H_
++#define _PKCS11_H_ 1
++
++#ifdef __cplusplus
++extern "C" {
++#endif
++
++/* Before including this file (pkcs11.h) (or pkcs11t.h by
++ * itself), 6 platform-specific macros must be defined.  These
++ * macros are described below, and typical definitions for them
++ * are also given.  Be advised that these definitions can depend
++ * on both the platform and the compiler used (and possibly also
++ * on whether a Cryptoki library is linked statically or
++ * dynamically).
++ *
++ * In addition to defining these 6 macros, the packing convention
++ * for Cryptoki structures should be set.  The Cryptoki
++ * convention on packing is that structures should be 1-byte
++ * aligned.
++ *
++ * If you're using Microsoft Developer Studio 5.0 to produce
++ * Win32 stuff, this might be done by using the following
++ * preprocessor directive before including pkcs11.h or pkcs11t.h:
++ *
++ * #pragma pack(push, cryptoki, 1)
++ *
++ * and using the following preprocessor directive after including
++ * pkcs11.h or pkcs11t.h:
++ *
++ * #pragma pack(pop, cryptoki)
++ *
++ * If you're using an earlier version of Microsoft Developer
++ * Studio to produce Win16 stuff, this might be done by using
++ * the following preprocessor directive before including
++ * pkcs11.h or pkcs11t.h:
++ *
++ * #pragma pack(1)
++ *
++ * In a UNIX environment, you're on your own for this.  You might
++ * not need to do (or be able to do!) anything.
++ *
++ *
++ * Now for the macros:
++ *
++ *
++ * 1. CK_PTR: The indirection string for making a pointer to an
++ * object.  It can be used like this:
++ *
++ * typedef CK_BYTE CK_PTR CK_BYTE_PTR;
++ *
++ * If you're using Microsoft Developer Studio 5.0 to produce
++ * Win32 stuff, it might be defined by:
++ *
++ * #define CK_PTR *
++ *
++ * If you're using an earlier version of Microsoft Developer
++ * Studio to produce Win16 stuff, it might be defined by:
++ *
++ * #define CK_PTR far *
++ *
++ * In a typical UNIX environment, it might be defined by:
++ *
++ * #define CK_PTR *
++ *
++ *
++ * 2. CK_DEFINE_FUNCTION(returnType, name): A macro which makes
++ * an exportable Cryptoki library function definition out of a
++ * return type and a function name.  It should be used in the
++ * following fashion to define the exposed Cryptoki functions in
++ * a Cryptoki library:
++ *
++ * CK_DEFINE_FUNCTION(CK_RV, C_Initialize)(
++ *   CK_VOID_PTR pReserved
++ * )
++ * {
++ *   ...
++ * }
++ *
++ * If you're using Microsoft Developer Studio 5.0 to define a
++ * function in a Win32 Cryptoki .dll, it might be defined by:
++ *
++ * #define CK_DEFINE_FUNCTION(returnType, name) \
++ *   returnType __declspec(dllexport) name
++ *
++ * If you're using an earlier version of Microsoft Developer
++ * Studio to define a function in a Win16 Cryptoki .dll, it
++ * might be defined by:
++ *
++ * #define CK_DEFINE_FUNCTION(returnType, name) \
++ *   returnType __export _far _pascal name
++ *
++ * In a UNIX environment, it might be defined by:
++ *
++ * #define CK_DEFINE_FUNCTION(returnType, name) \
++ *   returnType name
++ *
++ *
++ * 3. CK_DECLARE_FUNCTION(returnType, name): A macro which makes
++ * an importable Cryptoki library function declaration out of a
++ * return type and a function name.  It should be used in the
++ * following fashion:
++ *
++ * extern CK_DECLARE_FUNCTION(CK_RV, C_Initialize)(
++ *   CK_VOID_PTR pReserved
++ * );
++ *
++ * If you're using Microsoft Developer Studio 5.0 to declare a
++ * function in a Win32 Cryptoki .dll, it might be defined by:
++ *
++ * #define CK_DECLARE_FUNCTION(returnType, name) \
++ *   returnType __declspec(dllimport) name
++ *
++ * If you're using an earlier version of Microsoft Developer
++ * Studio to declare a function in a Win16 Cryptoki .dll, it
++ * might be defined by:
++ *
++ * #define CK_DECLARE_FUNCTION(returnType, name) \
++ *   returnType __export _far _pascal name
++ *
++ * In a UNIX environment, it might be defined by:
++ *
++ * #define CK_DECLARE_FUNCTION(returnType, name) \
++ *   returnType name
++ *
++ *
++ * 4. CK_DECLARE_FUNCTION_POINTER(returnType, name): A macro
++ * which makes a Cryptoki API function pointer declaration or
++ * function pointer type declaration out of a return type and a
++ * function name.  It should be used in the following fashion:
++ *
++ * // Define funcPtr to be a pointer to a Cryptoki API function
++ * // taking arguments args and returning CK_RV.
++ * CK_DECLARE_FUNCTION_POINTER(CK_RV, funcPtr)(args);
++ *
++ * or
++ *
++ * // Define funcPtrType to be the type of a pointer to a
++ * // Cryptoki API function taking arguments args and returning
++ * // CK_RV, and then define funcPtr to be a variable of type
++ * // funcPtrType.
++ * typedef CK_DECLARE_FUNCTION_POINTER(CK_RV, funcPtrType)(args);
++ * funcPtrType funcPtr;
++ *
++ * If you're using Microsoft Developer Studio 5.0 to access
++ * functions in a Win32 Cryptoki .dll, in might be defined by:
++ *
++ * #define CK_DECLARE_FUNCTION_POINTER(returnType, name) \
++ *   returnType __declspec(dllimport) (* name)
++ *
++ * If you're using an earlier version of Microsoft Developer
++ * Studio to access functions in a Win16 Cryptoki .dll, it might
++ * be defined by:
++ *
++ * #define CK_DECLARE_FUNCTION_POINTER(returnType, name) \
++ *   returnType __export _far _pascal (* name)
++ *
++ * In a UNIX environment, it might be defined by:
++ *
++ * #define CK_DECLARE_FUNCTION_POINTER(returnType, name) \
++ *   returnType (* name)
++ *
++ *
++ * 5. CK_CALLBACK_FUNCTION(returnType, name): A macro which makes
++ * a function pointer type for an application callback out of
++ * a return type for the callback and a name for the callback.
++ * It should be used in the following fashion:
++ *
++ * CK_CALLBACK_FUNCTION(CK_RV, myCallback)(args);
++ *
++ * to declare a function pointer, myCallback, to a callback
++ * which takes arguments args and returns a CK_RV.  It can also
++ * be used like this:
++ *
++ * typedef CK_CALLBACK_FUNCTION(CK_RV, myCallbackType)(args);
++ * myCallbackType myCallback;
++ *
++ * If you're using Microsoft Developer Studio 5.0 to do Win32
++ * Cryptoki development, it might be defined by:
++ *
++ * #define CK_CALLBACK_FUNCTION(returnType, name) \
++ *   returnType (* name)
++ *
++ * If you're using an earlier version of Microsoft Developer
++ * Studio to do Win16 development, it might be defined by:
++ *
++ * #define CK_CALLBACK_FUNCTION(returnType, name) \
++ *   returnType _far _pascal (* name)
++ *
++ * In a UNIX environment, it might be defined by:
++ *
++ * #define CK_CALLBACK_FUNCTION(returnType, name) \
++ *   returnType (* name)
++ *
++ *
++ * 6. NULL_PTR: This macro is the value of a NULL pointer.
++ *
++ * In any ANSI/ISO C environment (and in many others as well),
++ * this should best be defined by
++ *
++ * #ifndef NULL_PTR
++ * #define NULL_PTR 0
++ * #endif
++ */
++
++
++/* All the various Cryptoki types and #define'd values are in the
++ * file pkcs11t.h. */
++#include "pkcs11t.h"
++
++#define __PASTE(x,y)      x##y
++
++
++/* ==============================================================
++ * Define the "extern" form of all the entry points.
++ * ==============================================================
++ */
++
++#define CK_NEED_ARG_LIST  1
++#define CK_PKCS11_FUNCTION_INFO(name) \
++  extern CK_DECLARE_FUNCTION(CK_RV, name)
++
++/* pkcs11f.h has all the information about the Cryptoki
++ * function prototypes. */
++#include "pkcs11f.h"
++
++#undef CK_NEED_ARG_LIST
++#undef CK_PKCS11_FUNCTION_INFO
++
++
++/* ==============================================================
++ * Define the typedef form of all the entry points.  That is, for
++ * each Cryptoki function C_XXX, define a type CK_C_XXX which is
++ * a pointer to that kind of function.
++ * ==============================================================
++ */
++
++#define CK_NEED_ARG_LIST  1
++#define CK_PKCS11_FUNCTION_INFO(name) \
++  typedef CK_DECLARE_FUNCTION_POINTER(CK_RV, __PASTE(CK_,name))
++
++/* pkcs11f.h has all the information about the Cryptoki
++ * function prototypes. */
++#include "pkcs11f.h"
++
++#undef CK_NEED_ARG_LIST
++#undef CK_PKCS11_FUNCTION_INFO
++
++
++/* ==============================================================
++ * Define structed vector of entry points.  A CK_FUNCTION_LIST
++ * contains a CK_VERSION indicating a library's Cryptoki version
++ * and then a whole slew of function pointers to the routines in
++ * the library.  This type was declared, but not defined, in
++ * pkcs11t.h.
++ * ==============================================================
++ */
++
++#define CK_PKCS11_FUNCTION_INFO(name) \
++  __PASTE(CK_,name) name;
++  
++struct CK_FUNCTION_LIST {
++
++  CK_VERSION    version;  /* Cryptoki version */
++
++/* Pile all the function pointers into the CK_FUNCTION_LIST. */
++/* pkcs11f.h has all the information about the Cryptoki
++ * function prototypes. */
++#include "pkcs11f.h"
++
++};
++
++#undef CK_PKCS11_FUNCTION_INFO
++
++
++#undef __PASTE
++
++#ifdef __cplusplus
++}
++#endif
++
++#endif
+Index: openssl/crypto/engine/pkcs11f.h
+diff -u /dev/null openssl/crypto/engine/pkcs11f.h:1.1.1.1
+--- /dev/null	Mon Jan 16 18:54:23 2012
++++ openssl/crypto/engine/pkcs11f.h	Wed Oct 24 23:27:09 2007
+@@ -0,0 +1,912 @@
++/* pkcs11f.h include file for PKCS #11. */
++/* $Revision: 1.2 $ */
++
++/* License to copy and use this software is granted provided that it is
++ * identified as "RSA Security Inc. PKCS #11 Cryptographic Token Interface
++ * (Cryptoki)" in all material mentioning or referencing this software.
++
++ * License is also granted to make and use derivative works provided that
++ * such works are identified as "derived from the RSA Security Inc. PKCS #11
++ * Cryptographic Token Interface (Cryptoki)" in all material mentioning or 
++ * referencing the derived work.
++
++ * RSA Security Inc. makes 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.
++ */
++
++/* This header file contains pretty much everything about all the */
++/* Cryptoki function prototypes.  Because this information is */
++/* used for more than just declaring function prototypes, the */
++/* order of the functions appearing herein is important, and */
++/* should not be altered. */
++
++/* General-purpose */
++
++/* C_Initialize initializes the Cryptoki library. */
++CK_PKCS11_FUNCTION_INFO(C_Initialize)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_VOID_PTR   pInitArgs  /* if this is not NULL_PTR, it gets
++                            * cast to CK_C_INITIALIZE_ARGS_PTR
++                            * and dereferenced */
++);
++#endif
++
++
++/* C_Finalize indicates that an application is done with the
++ * Cryptoki library. */
++CK_PKCS11_FUNCTION_INFO(C_Finalize)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_VOID_PTR   pReserved  /* reserved.  Should be NULL_PTR */
++);
++#endif
++
++
++/* C_GetInfo returns general information about Cryptoki. */
++CK_PKCS11_FUNCTION_INFO(C_GetInfo)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_INFO_PTR   pInfo  /* location that receives information */
++);
++#endif
++
++
++/* C_GetFunctionList returns the function list. */
++CK_PKCS11_FUNCTION_INFO(C_GetFunctionList)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_FUNCTION_LIST_PTR_PTR ppFunctionList  /* receives pointer to
++                                            * function list */
++);
++#endif
++
++
++
++/* Slot and token management */
++
++/* C_GetSlotList obtains a list of slots in the system. */
++CK_PKCS11_FUNCTION_INFO(C_GetSlotList)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_BBOOL       tokenPresent,  /* only slots with tokens? */
++  CK_SLOT_ID_PTR pSlotList,     /* receives array of slot IDs */
++  CK_ULONG_PTR   pulCount       /* receives number of slots */
++);
++#endif
++
++
++/* C_GetSlotInfo obtains information about a particular slot in
++ * the system. */
++CK_PKCS11_FUNCTION_INFO(C_GetSlotInfo)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SLOT_ID       slotID,  /* the ID of the slot */
++  CK_SLOT_INFO_PTR pInfo    /* receives the slot information */
++);
++#endif
++
++
++/* C_GetTokenInfo obtains information about a particular token
++ * in the system. */
++CK_PKCS11_FUNCTION_INFO(C_GetTokenInfo)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SLOT_ID        slotID,  /* ID of the token's slot */
++  CK_TOKEN_INFO_PTR pInfo    /* receives the token information */
++);
++#endif
++
++
++/* C_GetMechanismList obtains a list of mechanism types
++ * supported by a token. */
++CK_PKCS11_FUNCTION_INFO(C_GetMechanismList)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SLOT_ID            slotID,          /* ID of token's slot */
++  CK_MECHANISM_TYPE_PTR pMechanismList,  /* gets mech. array */
++  CK_ULONG_PTR          pulCount         /* gets # of mechs. */
++);
++#endif
++
++
++/* C_GetMechanismInfo obtains information about a particular
++ * mechanism possibly supported by a token. */
++CK_PKCS11_FUNCTION_INFO(C_GetMechanismInfo)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SLOT_ID            slotID,  /* ID of the token's slot */
++  CK_MECHANISM_TYPE     type,    /* type of mechanism */
++  CK_MECHANISM_INFO_PTR pInfo    /* receives mechanism info */
++);
++#endif
++
++
++/* C_InitToken initializes a token. */
++CK_PKCS11_FUNCTION_INFO(C_InitToken)
++#ifdef CK_NEED_ARG_LIST
++/* pLabel changed from CK_CHAR_PTR to CK_UTF8CHAR_PTR for v2.10 */
++(
++  CK_SLOT_ID      slotID,    /* ID of the token's slot */
++  CK_UTF8CHAR_PTR pPin,      /* the SO's initial PIN */
++  CK_ULONG        ulPinLen,  /* length in bytes of the PIN */
++  CK_UTF8CHAR_PTR pLabel     /* 32-byte token label (blank padded) */
++);
++#endif
++
++
++/* C_InitPIN initializes the normal user's PIN. */
++CK_PKCS11_FUNCTION_INFO(C_InitPIN)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,  /* the session's handle */
++  CK_UTF8CHAR_PTR   pPin,      /* the normal user's PIN */
++  CK_ULONG          ulPinLen   /* length in bytes of the PIN */
++);
++#endif
++
++
++/* C_SetPIN modifies the PIN of the user who is logged in. */
++CK_PKCS11_FUNCTION_INFO(C_SetPIN)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,  /* the session's handle */
++  CK_UTF8CHAR_PTR   pOldPin,   /* the old PIN */
++  CK_ULONG          ulOldLen,  /* length of the old PIN */
++  CK_UTF8CHAR_PTR   pNewPin,   /* the new PIN */
++  CK_ULONG          ulNewLen   /* length of the new PIN */
++);
++#endif
++
++
++
++/* Session management */
++
++/* C_OpenSession opens a session between an application and a
++ * token. */
++CK_PKCS11_FUNCTION_INFO(C_OpenSession)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SLOT_ID            slotID,        /* the slot's ID */
++  CK_FLAGS              flags,         /* from CK_SESSION_INFO */
++  CK_VOID_PTR           pApplication,  /* passed to callback */
++  CK_NOTIFY             Notify,        /* callback function */
++  CK_SESSION_HANDLE_PTR phSession      /* gets session handle */
++);
++#endif
++
++
++/* C_CloseSession closes a session between an application and a
++ * token. */
++CK_PKCS11_FUNCTION_INFO(C_CloseSession)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession  /* the session's handle */
++);
++#endif
++
++
++/* C_CloseAllSessions closes all sessions with a token. */
++CK_PKCS11_FUNCTION_INFO(C_CloseAllSessions)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SLOT_ID     slotID  /* the token's slot */
++);
++#endif
++
++
++/* C_GetSessionInfo obtains information about the session. */
++CK_PKCS11_FUNCTION_INFO(C_GetSessionInfo)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE   hSession,  /* the session's handle */
++  CK_SESSION_INFO_PTR pInfo      /* receives session info */
++);
++#endif
++
++
++/* C_GetOperationState obtains the state of the cryptographic operation
++ * in a session. */
++CK_PKCS11_FUNCTION_INFO(C_GetOperationState)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,             /* session's handle */
++  CK_BYTE_PTR       pOperationState,      /* gets state */
++  CK_ULONG_PTR      pulOperationStateLen  /* gets state length */
++);
++#endif
++
++
++/* C_SetOperationState restores the state of the cryptographic
++ * operation in a session. */
++CK_PKCS11_FUNCTION_INFO(C_SetOperationState)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,            /* session's handle */
++  CK_BYTE_PTR      pOperationState,      /* holds state */
++  CK_ULONG         ulOperationStateLen,  /* holds state length */
++  CK_OBJECT_HANDLE hEncryptionKey,       /* en/decryption key */
++  CK_OBJECT_HANDLE hAuthenticationKey    /* sign/verify key */
++);
++#endif
++
++
++/* C_Login logs a user into a token. */
++CK_PKCS11_FUNCTION_INFO(C_Login)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,  /* the session's handle */
++  CK_USER_TYPE      userType,  /* the user type */
++  CK_UTF8CHAR_PTR   pPin,      /* the user's PIN */
++  CK_ULONG          ulPinLen   /* the length of the PIN */
++);
++#endif
++
++
++/* C_Logout logs a user out from a token. */
++CK_PKCS11_FUNCTION_INFO(C_Logout)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession  /* the session's handle */
++);
++#endif
++
++
++
++/* Object management */
++
++/* C_CreateObject creates a new object. */
++CK_PKCS11_FUNCTION_INFO(C_CreateObject)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,    /* the session's handle */
++  CK_ATTRIBUTE_PTR  pTemplate,   /* the object's template */
++  CK_ULONG          ulCount,     /* attributes in template */
++  CK_OBJECT_HANDLE_PTR phObject  /* gets new object's handle. */
++);
++#endif
++
++
++/* C_CopyObject copies an object, creating a new object for the
++ * copy. */
++CK_PKCS11_FUNCTION_INFO(C_CopyObject)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE    hSession,    /* the session's handle */
++  CK_OBJECT_HANDLE     hObject,     /* the object's handle */
++  CK_ATTRIBUTE_PTR     pTemplate,   /* template for new object */
++  CK_ULONG             ulCount,     /* attributes in template */
++  CK_OBJECT_HANDLE_PTR phNewObject  /* receives handle of copy */
++);
++#endif
++
++
++/* C_DestroyObject destroys an object. */
++CK_PKCS11_FUNCTION_INFO(C_DestroyObject)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,  /* the session's handle */
++  CK_OBJECT_HANDLE  hObject    /* the object's handle */
++);
++#endif
++
++
++/* C_GetObjectSize gets the size of an object in bytes. */
++CK_PKCS11_FUNCTION_INFO(C_GetObjectSize)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,  /* the session's handle */
++  CK_OBJECT_HANDLE  hObject,   /* the object's handle */
++  CK_ULONG_PTR      pulSize    /* receives size of object */
++);
++#endif
++
++
++/* C_GetAttributeValue obtains the value of one or more object
++ * attributes. */
++CK_PKCS11_FUNCTION_INFO(C_GetAttributeValue)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,   /* the session's handle */
++  CK_OBJECT_HANDLE  hObject,    /* the object's handle */
++  CK_ATTRIBUTE_PTR  pTemplate,  /* specifies attrs; gets vals */
++  CK_ULONG          ulCount     /* attributes in template */
++);
++#endif
++
++
++/* C_SetAttributeValue modifies the value of one or more object
++ * attributes */
++CK_PKCS11_FUNCTION_INFO(C_SetAttributeValue)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,   /* the session's handle */
++  CK_OBJECT_HANDLE  hObject,    /* the object's handle */
++  CK_ATTRIBUTE_PTR  pTemplate,  /* specifies attrs and values */
++  CK_ULONG          ulCount     /* attributes in template */
++);
++#endif
++
++
++/* C_FindObjectsInit initializes a search for token and session
++ * objects that match a template. */
++CK_PKCS11_FUNCTION_INFO(C_FindObjectsInit)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,   /* the session's handle */
++  CK_ATTRIBUTE_PTR  pTemplate,  /* attribute values to match */
++  CK_ULONG          ulCount     /* attrs in search template */
++);
++#endif
++
++
++/* C_FindObjects continues a search for token and session
++ * objects that match a template, obtaining additional object
++ * handles. */
++CK_PKCS11_FUNCTION_INFO(C_FindObjects)
++#ifdef CK_NEED_ARG_LIST
++(
++ CK_SESSION_HANDLE    hSession,          /* session's handle */
++ CK_OBJECT_HANDLE_PTR phObject,          /* gets obj. handles */
++ CK_ULONG             ulMaxObjectCount,  /* max handles to get */
++ CK_ULONG_PTR         pulObjectCount     /* actual # returned */
++);
++#endif
++
++
++/* C_FindObjectsFinal finishes a search for token and session
++ * objects. */
++CK_PKCS11_FUNCTION_INFO(C_FindObjectsFinal)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession  /* the session's handle */
++);
++#endif
++
++
++
++/* Encryption and decryption */
++
++/* C_EncryptInit initializes an encryption operation. */
++CK_PKCS11_FUNCTION_INFO(C_EncryptInit)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,    /* the session's handle */
++  CK_MECHANISM_PTR  pMechanism,  /* the encryption mechanism */
++  CK_OBJECT_HANDLE  hKey         /* handle of encryption key */
++);
++#endif
++
++
++/* C_Encrypt encrypts single-part data. */
++CK_PKCS11_FUNCTION_INFO(C_Encrypt)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,            /* session's handle */
++  CK_BYTE_PTR       pData,               /* the plaintext data */
++  CK_ULONG          ulDataLen,           /* bytes of plaintext */
++  CK_BYTE_PTR       pEncryptedData,      /* gets ciphertext */
++  CK_ULONG_PTR      pulEncryptedDataLen  /* gets c-text size */
++);
++#endif
++
++
++/* C_EncryptUpdate continues a multiple-part encryption
++ * operation. */
++CK_PKCS11_FUNCTION_INFO(C_EncryptUpdate)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,           /* session's handle */
++  CK_BYTE_PTR       pPart,              /* the plaintext data */
++  CK_ULONG          ulPartLen,          /* plaintext data len */
++  CK_BYTE_PTR       pEncryptedPart,     /* gets ciphertext */
++  CK_ULONG_PTR      pulEncryptedPartLen /* gets c-text size */
++);
++#endif
++
++
++/* C_EncryptFinal finishes a multiple-part encryption
++ * operation. */
++CK_PKCS11_FUNCTION_INFO(C_EncryptFinal)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,                /* session handle */
++  CK_BYTE_PTR       pLastEncryptedPart,      /* last c-text */
++  CK_ULONG_PTR      pulLastEncryptedPartLen  /* gets last size */
++);
++#endif
++
++
++/* C_DecryptInit initializes a decryption operation. */
++CK_PKCS11_FUNCTION_INFO(C_DecryptInit)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,    /* the session's handle */
++  CK_MECHANISM_PTR  pMechanism,  /* the decryption mechanism */
++  CK_OBJECT_HANDLE  hKey         /* handle of decryption key */
++);
++#endif
++
++
++/* C_Decrypt decrypts encrypted data in a single part. */
++CK_PKCS11_FUNCTION_INFO(C_Decrypt)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,           /* session's handle */
++  CK_BYTE_PTR       pEncryptedData,     /* ciphertext */
++  CK_ULONG          ulEncryptedDataLen, /* ciphertext length */
++  CK_BYTE_PTR       pData,              /* gets plaintext */
++  CK_ULONG_PTR      pulDataLen          /* gets p-text size */
++);
++#endif
++
++
++/* C_DecryptUpdate continues a multiple-part decryption
++ * operation. */
++CK_PKCS11_FUNCTION_INFO(C_DecryptUpdate)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,            /* session's handle */
++  CK_BYTE_PTR       pEncryptedPart,      /* encrypted data */
++  CK_ULONG          ulEncryptedPartLen,  /* input length */
++  CK_BYTE_PTR       pPart,               /* gets plaintext */
++  CK_ULONG_PTR      pulPartLen           /* p-text size */
++);
++#endif
++
++
++/* C_DecryptFinal finishes a multiple-part decryption
++ * operation. */
++CK_PKCS11_FUNCTION_INFO(C_DecryptFinal)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,       /* the session's handle */
++  CK_BYTE_PTR       pLastPart,      /* gets plaintext */
++  CK_ULONG_PTR      pulLastPartLen  /* p-text size */
++);
++#endif
++
++
++
++/* Message digesting */
++
++/* C_DigestInit initializes a message-digesting operation. */
++CK_PKCS11_FUNCTION_INFO(C_DigestInit)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,   /* the session's handle */
++  CK_MECHANISM_PTR  pMechanism  /* the digesting mechanism */
++);
++#endif
++
++
++/* C_Digest digests data in a single part. */
++CK_PKCS11_FUNCTION_INFO(C_Digest)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,     /* the session's handle */
++  CK_BYTE_PTR       pData,        /* data to be digested */
++  CK_ULONG          ulDataLen,    /* bytes of data to digest */
++  CK_BYTE_PTR       pDigest,      /* gets the message digest */
++  CK_ULONG_PTR      pulDigestLen  /* gets digest length */
++);
++#endif
++
++
++/* C_DigestUpdate continues a multiple-part message-digesting
++ * operation. */
++CK_PKCS11_FUNCTION_INFO(C_DigestUpdate)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,  /* the session's handle */
++  CK_BYTE_PTR       pPart,     /* data to be digested */
++  CK_ULONG          ulPartLen  /* bytes of data to be digested */
++);
++#endif
++
++
++/* C_DigestKey continues a multi-part message-digesting
++ * operation, by digesting the value of a secret key as part of
++ * the data already digested. */
++CK_PKCS11_FUNCTION_INFO(C_DigestKey)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,  /* the session's handle */
++  CK_OBJECT_HANDLE  hKey       /* secret key to digest */
++);
++#endif
++
++
++/* C_DigestFinal finishes a multiple-part message-digesting
++ * operation. */
++CK_PKCS11_FUNCTION_INFO(C_DigestFinal)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,     /* the session's handle */
++  CK_BYTE_PTR       pDigest,      /* gets the message digest */
++  CK_ULONG_PTR      pulDigestLen  /* gets byte count of digest */
++);
++#endif
++
++
++
++/* Signing and MACing */
++
++/* C_SignInit initializes a signature (private key encryption)
++ * operation, where the signature is (will be) an appendix to
++ * the data, and plaintext cannot be recovered from the
++ *signature. */
++CK_PKCS11_FUNCTION_INFO(C_SignInit)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,    /* the session's handle */
++  CK_MECHANISM_PTR  pMechanism,  /* the signature mechanism */
++  CK_OBJECT_HANDLE  hKey         /* handle of signature key */
++);
++#endif
++
++
++/* C_Sign signs (encrypts with private key) data in a single
++ * part, where the signature is (will be) an appendix to the
++ * data, and plaintext cannot be recovered from the signature. */
++CK_PKCS11_FUNCTION_INFO(C_Sign)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,        /* the session's handle */
++  CK_BYTE_PTR       pData,           /* the data to sign */
++  CK_ULONG          ulDataLen,       /* count of bytes to sign */
++  CK_BYTE_PTR       pSignature,      /* gets the signature */
++  CK_ULONG_PTR      pulSignatureLen  /* gets signature length */
++);
++#endif
++
++
++/* C_SignUpdate continues a multiple-part signature operation,
++ * where the signature is (will be) an appendix to the data, 
++ * and plaintext cannot be recovered from the signature. */
++CK_PKCS11_FUNCTION_INFO(C_SignUpdate)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,  /* the session's handle */
++  CK_BYTE_PTR       pPart,     /* the data to sign */
++  CK_ULONG          ulPartLen  /* count of bytes to sign */
++);
++#endif
++
++
++/* C_SignFinal finishes a multiple-part signature operation, 
++ * returning the signature. */
++CK_PKCS11_FUNCTION_INFO(C_SignFinal)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,        /* the session's handle */
++  CK_BYTE_PTR       pSignature,      /* gets the signature */
++  CK_ULONG_PTR      pulSignatureLen  /* gets signature length */
++);
++#endif
++
++
++/* C_SignRecoverInit initializes a signature operation, where
++ * the data can be recovered from the signature. */
++CK_PKCS11_FUNCTION_INFO(C_SignRecoverInit)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,   /* the session's handle */
++  CK_MECHANISM_PTR  pMechanism, /* the signature mechanism */
++  CK_OBJECT_HANDLE  hKey        /* handle of the signature key */
++);
++#endif
++
++
++/* C_SignRecover signs data in a single operation, where the
++ * data can be recovered from the signature. */
++CK_PKCS11_FUNCTION_INFO(C_SignRecover)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,        /* the session's handle */
++  CK_BYTE_PTR       pData,           /* the data to sign */
++  CK_ULONG          ulDataLen,       /* count of bytes to sign */
++  CK_BYTE_PTR       pSignature,      /* gets the signature */
++  CK_ULONG_PTR      pulSignatureLen  /* gets signature length */
++);
++#endif
++
++
++
++/* Verifying signatures and MACs */
++
++/* C_VerifyInit initializes a verification operation, where the
++ * signature is an appendix to the data, and plaintext cannot
++ *  cannot be recovered from the signature (e.g. DSA). */
++CK_PKCS11_FUNCTION_INFO(C_VerifyInit)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,    /* the session's handle */
++  CK_MECHANISM_PTR  pMechanism,  /* the verification mechanism */
++  CK_OBJECT_HANDLE  hKey         /* verification key */ 
++);
++#endif
++
++
++/* C_Verify verifies a signature in a single-part operation, 
++ * where the signature is an appendix to the data, and plaintext
++ * cannot be recovered from the signature. */
++CK_PKCS11_FUNCTION_INFO(C_Verify)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,       /* the session's handle */
++  CK_BYTE_PTR       pData,          /* signed data */
++  CK_ULONG          ulDataLen,      /* length of signed data */
++  CK_BYTE_PTR       pSignature,     /* signature */
++  CK_ULONG          ulSignatureLen  /* signature length*/
++);
++#endif
++
++
++/* C_VerifyUpdate continues a multiple-part verification
++ * operation, where the signature is an appendix to the data, 
++ * and plaintext cannot be recovered from the signature. */
++CK_PKCS11_FUNCTION_INFO(C_VerifyUpdate)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,  /* the session's handle */
++  CK_BYTE_PTR       pPart,     /* signed data */
++  CK_ULONG          ulPartLen  /* length of signed data */
++);
++#endif
++
++
++/* C_VerifyFinal finishes a multiple-part verification
++ * operation, checking the signature. */
++CK_PKCS11_FUNCTION_INFO(C_VerifyFinal)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,       /* the session's handle */
++  CK_BYTE_PTR       pSignature,     /* signature to verify */
++  CK_ULONG          ulSignatureLen  /* signature length */
++);
++#endif
++
++
++/* C_VerifyRecoverInit initializes a signature verification
++ * operation, where the data is recovered from the signature. */
++CK_PKCS11_FUNCTION_INFO(C_VerifyRecoverInit)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,    /* the session's handle */
++  CK_MECHANISM_PTR  pMechanism,  /* the verification mechanism */
++  CK_OBJECT_HANDLE  hKey         /* verification key */
++);
++#endif
++
++
++/* C_VerifyRecover verifies a signature in a single-part
++ * operation, where the data is recovered from the signature. */
++CK_PKCS11_FUNCTION_INFO(C_VerifyRecover)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,        /* the session's handle */
++  CK_BYTE_PTR       pSignature,      /* signature to verify */
++  CK_ULONG          ulSignatureLen,  /* signature length */
++  CK_BYTE_PTR       pData,           /* gets signed data */
++  CK_ULONG_PTR      pulDataLen       /* gets signed data len */
++);
++#endif
++
++
++
++/* Dual-function cryptographic operations */
++
++/* C_DigestEncryptUpdate continues a multiple-part digesting
++ * and encryption operation. */
++CK_PKCS11_FUNCTION_INFO(C_DigestEncryptUpdate)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,            /* session's handle */
++  CK_BYTE_PTR       pPart,               /* the plaintext data */
++  CK_ULONG          ulPartLen,           /* plaintext length */
++  CK_BYTE_PTR       pEncryptedPart,      /* gets ciphertext */
++  CK_ULONG_PTR      pulEncryptedPartLen  /* gets c-text length */
++);
++#endif
++
++
++/* C_DecryptDigestUpdate continues a multiple-part decryption and
++ * digesting operation. */
++CK_PKCS11_FUNCTION_INFO(C_DecryptDigestUpdate)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,            /* session's handle */
++  CK_BYTE_PTR       pEncryptedPart,      /* ciphertext */
++  CK_ULONG          ulEncryptedPartLen,  /* ciphertext length */
++  CK_BYTE_PTR       pPart,               /* gets plaintext */
++  CK_ULONG_PTR      pulPartLen           /* gets plaintext len */
++);
++#endif
++
++
++/* C_SignEncryptUpdate continues a multiple-part signing and
++ * encryption operation. */
++CK_PKCS11_FUNCTION_INFO(C_SignEncryptUpdate)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,            /* session's handle */
++  CK_BYTE_PTR       pPart,               /* the plaintext data */
++  CK_ULONG          ulPartLen,           /* plaintext length */
++  CK_BYTE_PTR       pEncryptedPart,      /* gets ciphertext */
++  CK_ULONG_PTR      pulEncryptedPartLen  /* gets c-text length */
++);
++#endif
++
++
++/* C_DecryptVerifyUpdate continues a multiple-part decryption and
++ * verify operation. */
++CK_PKCS11_FUNCTION_INFO(C_DecryptVerifyUpdate)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,            /* session's handle */
++  CK_BYTE_PTR       pEncryptedPart,      /* ciphertext */
++  CK_ULONG          ulEncryptedPartLen,  /* ciphertext length */
++  CK_BYTE_PTR       pPart,               /* gets plaintext */
++  CK_ULONG_PTR      pulPartLen           /* gets p-text length */
++);
++#endif
++
++
++
++/* Key management */
++
++/* C_GenerateKey generates a secret key, creating a new key
++ * object. */
++CK_PKCS11_FUNCTION_INFO(C_GenerateKey)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE    hSession,    /* the session's handle */
++  CK_MECHANISM_PTR     pMechanism,  /* key generation mech. */
++  CK_ATTRIBUTE_PTR     pTemplate,   /* template for new key */
++  CK_ULONG             ulCount,     /* # of attrs in template */
++  CK_OBJECT_HANDLE_PTR phKey        /* gets handle of new key */
++);
++#endif
++
++
++/* C_GenerateKeyPair generates a public-key/private-key pair, 
++ * creating new key objects. */
++CK_PKCS11_FUNCTION_INFO(C_GenerateKeyPair)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE    hSession,                    /* session
++                                                     * handle */
++  CK_MECHANISM_PTR     pMechanism,                  /* key-gen
++                                                     * mech. */
++  CK_ATTRIBUTE_PTR     pPublicKeyTemplate,          /* template
++                                                     * for pub.
++                                                     * key */
++  CK_ULONG             ulPublicKeyAttributeCount,   /* # pub.
++                                                     * attrs. */
++  CK_ATTRIBUTE_PTR     pPrivateKeyTemplate,         /* template
++                                                     * for priv.
++                                                     * key */
++  CK_ULONG             ulPrivateKeyAttributeCount,  /* # priv.
++                                                     * attrs. */
++  CK_OBJECT_HANDLE_PTR phPublicKey,                 /* gets pub.
++                                                     * key
++                                                     * handle */
++  CK_OBJECT_HANDLE_PTR phPrivateKey                 /* gets
++                                                     * priv. key
++                                                     * handle */
++);
++#endif
++
++
++/* C_WrapKey wraps (i.e., encrypts) a key. */
++CK_PKCS11_FUNCTION_INFO(C_WrapKey)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,        /* the session's handle */
++  CK_MECHANISM_PTR  pMechanism,      /* the wrapping mechanism */
++  CK_OBJECT_HANDLE  hWrappingKey,    /* wrapping key */
++  CK_OBJECT_HANDLE  hKey,            /* key to be wrapped */
++  CK_BYTE_PTR       pWrappedKey,     /* gets wrapped key */
++  CK_ULONG_PTR      pulWrappedKeyLen /* gets wrapped key size */
++);
++#endif
++
++
++/* C_UnwrapKey unwraps (decrypts) a wrapped key, creating a new
++ * key object. */
++CK_PKCS11_FUNCTION_INFO(C_UnwrapKey)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE    hSession,          /* session's handle */
++  CK_MECHANISM_PTR     pMechanism,        /* unwrapping mech. */
++  CK_OBJECT_HANDLE     hUnwrappingKey,    /* unwrapping key */
++  CK_BYTE_PTR          pWrappedKey,       /* the wrapped key */
++  CK_ULONG             ulWrappedKeyLen,   /* wrapped key len */
++  CK_ATTRIBUTE_PTR     pTemplate,         /* new key template */
++  CK_ULONG             ulAttributeCount,  /* template length */
++  CK_OBJECT_HANDLE_PTR phKey              /* gets new handle */
++);
++#endif
++
++
++/* C_DeriveKey derives a key from a base key, creating a new key
++ * object. */
++CK_PKCS11_FUNCTION_INFO(C_DeriveKey)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE    hSession,          /* session's handle */
++  CK_MECHANISM_PTR     pMechanism,        /* key deriv. mech. */
++  CK_OBJECT_HANDLE     hBaseKey,          /* base key */
++  CK_ATTRIBUTE_PTR     pTemplate,         /* new key template */
++  CK_ULONG             ulAttributeCount,  /* template length */
++  CK_OBJECT_HANDLE_PTR phKey              /* gets new handle */
++);
++#endif
++
++
++
++/* Random number generation */
++
++/* C_SeedRandom mixes additional seed material into the token's
++ * random number generator. */
++CK_PKCS11_FUNCTION_INFO(C_SeedRandom)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,  /* the session's handle */
++  CK_BYTE_PTR       pSeed,     /* the seed material */
++  CK_ULONG          ulSeedLen  /* length of seed material */
++);
++#endif
++
++
++/* C_GenerateRandom generates random data. */
++CK_PKCS11_FUNCTION_INFO(C_GenerateRandom)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession,    /* the session's handle */
++  CK_BYTE_PTR       RandomData,  /* receives the random data */
++  CK_ULONG          ulRandomLen  /* # of bytes to generate */
++);
++#endif
++
++
++
++/* Parallel function management */
++
++/* C_GetFunctionStatus is a legacy function; it obtains an
++ * updated status of a function running in parallel with an
++ * application. */
++CK_PKCS11_FUNCTION_INFO(C_GetFunctionStatus)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession  /* the session's handle */
++);
++#endif
++
++
++/* C_CancelFunction is a legacy function; it cancels a function
++ * running in parallel. */
++CK_PKCS11_FUNCTION_INFO(C_CancelFunction)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_SESSION_HANDLE hSession  /* the session's handle */
++);
++#endif
++
++
++
++/* Functions added in for Cryptoki Version 2.01 or later */
++
++/* C_WaitForSlotEvent waits for a slot event (token insertion,
++ * removal, etc.) to occur. */
++CK_PKCS11_FUNCTION_INFO(C_WaitForSlotEvent)
++#ifdef CK_NEED_ARG_LIST
++(
++  CK_FLAGS flags,        /* blocking/nonblocking flag */
++  CK_SLOT_ID_PTR pSlot,  /* location that receives the slot ID */
++  CK_VOID_PTR pRserved   /* reserved.  Should be NULL_PTR */
++);
++#endif
+Index: openssl/crypto/engine/pkcs11t.h
+diff -u /dev/null openssl/crypto/engine/pkcs11t.h:1.2
+--- /dev/null	Mon Jan 16 18:54:23 2012
++++ openssl/crypto/engine/pkcs11t.h	Sat Aug 30 11:58:07 2008
+@@ -0,0 +1,1885 @@
++/* pkcs11t.h include file for PKCS #11. */
++/* $Revision: 1.2 $ */
++
++/* License to copy and use this software is granted provided that it is
++ * identified as "RSA Security Inc. PKCS #11 Cryptographic Token Interface
++ * (Cryptoki)" in all material mentioning or referencing this software.
++
++ * License is also granted to make and use derivative works provided that
++ * such works are identified as "derived from the RSA Security Inc. PKCS #11
++ * Cryptographic Token Interface (Cryptoki)" in all material mentioning or
++ * referencing the derived work.
++
++ * RSA Security Inc. makes 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.
++ */
++
++/* See top of pkcs11.h for information about the macros that
++ * must be defined and the structure-packing conventions that
++ * must be set before including this file. */
++
++#ifndef _PKCS11T_H_
++#define _PKCS11T_H_ 1
++
++#define CRYPTOKI_VERSION_MAJOR 2
++#define CRYPTOKI_VERSION_MINOR 20
++#define CRYPTOKI_VERSION_AMENDMENT 3
++
++#define CK_TRUE 1
++#define CK_FALSE 0
++
++#ifndef CK_DISABLE_TRUE_FALSE
++#ifndef FALSE
++#define FALSE CK_FALSE
++#endif
++
++#ifndef TRUE
++#define TRUE CK_TRUE
++#endif
++#endif
++
++/* an unsigned 8-bit value */
++typedef unsigned char     CK_BYTE;
++
++/* an unsigned 8-bit character */
++typedef CK_BYTE           CK_CHAR;
++
++/* an 8-bit UTF-8 character */
++typedef CK_BYTE           CK_UTF8CHAR;
++
++/* a BYTE-sized Boolean flag */
++typedef CK_BYTE           CK_BBOOL;
++
++/* an unsigned value, at least 32 bits long */
++typedef unsigned long int CK_ULONG;
++
++/* a signed value, the same size as a CK_ULONG */
++/* CK_LONG is new for v2.0 */
++typedef long int          CK_LONG;
++
++/* at least 32 bits; each bit is a Boolean flag */
++typedef CK_ULONG          CK_FLAGS;
++
++
++/* some special values for certain CK_ULONG variables */
++#define CK_UNAVAILABLE_INFORMATION (~0UL)
++#define CK_EFFECTIVELY_INFINITE    0
++
++
++typedef CK_BYTE     CK_PTR   CK_BYTE_PTR;
++typedef CK_CHAR     CK_PTR   CK_CHAR_PTR;
++typedef CK_UTF8CHAR CK_PTR   CK_UTF8CHAR_PTR;
++typedef CK_ULONG    CK_PTR   CK_ULONG_PTR;
++typedef void        CK_PTR   CK_VOID_PTR;
++
++/* Pointer to a CK_VOID_PTR-- i.e., pointer to pointer to void */
++typedef CK_VOID_PTR CK_PTR CK_VOID_PTR_PTR;
++
++
++/* The following value is always invalid if used as a session */
++/* handle or object handle */
++#define CK_INVALID_HANDLE 0
++
++
++typedef struct CK_VERSION {
++  CK_BYTE       major;  /* integer portion of version number */
++  CK_BYTE       minor;  /* 1/100ths portion of version number */
++} CK_VERSION;
++
++typedef CK_VERSION CK_PTR CK_VERSION_PTR;
++
++
++typedef struct CK_INFO {
++  /* manufacturerID and libraryDecription have been changed from
++   * CK_CHAR to CK_UTF8CHAR for v2.10 */
++  CK_VERSION    cryptokiVersion;     /* Cryptoki interface ver */
++  CK_UTF8CHAR   manufacturerID[32];  /* blank padded */
++  CK_FLAGS      flags;               /* must be zero */
++
++  /* libraryDescription and libraryVersion are new for v2.0 */
++  CK_UTF8CHAR   libraryDescription[32];  /* blank padded */
++  CK_VERSION    libraryVersion;          /* version of library */
++} CK_INFO;
++
++typedef CK_INFO CK_PTR    CK_INFO_PTR;
++
++
++/* CK_NOTIFICATION enumerates the types of notifications that
++ * Cryptoki provides to an application */
++/* CK_NOTIFICATION has been changed from an enum to a CK_ULONG
++ * for v2.0 */
++typedef CK_ULONG CK_NOTIFICATION;
++#define CKN_SURRENDER       0
++
++/* The following notification is new for PKCS #11 v2.20 amendment 3 */
++#define CKN_OTP_CHANGED     1
++
++
++typedef CK_ULONG          CK_SLOT_ID;
++
++typedef CK_SLOT_ID CK_PTR CK_SLOT_ID_PTR;
++
++
++/* CK_SLOT_INFO provides information about a slot */
++typedef struct CK_SLOT_INFO {
++  /* slotDescription and manufacturerID have been changed from
++   * CK_CHAR to CK_UTF8CHAR for v2.10 */
++  CK_UTF8CHAR   slotDescription[64];  /* blank padded */
++  CK_UTF8CHAR   manufacturerID[32];   /* blank padded */
++  CK_FLAGS      flags;
++
++  /* hardwareVersion and firmwareVersion are new for v2.0 */
++  CK_VERSION    hardwareVersion;  /* version of hardware */
++  CK_VERSION    firmwareVersion;  /* version of firmware */
++} CK_SLOT_INFO;
++
++/* flags: bit flags that provide capabilities of the slot
++ *      Bit Flag              Mask        Meaning
++ */
++#define CKF_TOKEN_PRESENT     0x00000001  /* a token is there */
++#define CKF_REMOVABLE_DEVICE  0x00000002  /* removable devices*/
++#define CKF_HW_SLOT           0x00000004  /* hardware slot */
++
++typedef CK_SLOT_INFO CK_PTR CK_SLOT_INFO_PTR;
++
++
++/* CK_TOKEN_INFO provides information about a token */
++typedef struct CK_TOKEN_INFO {
++  /* label, manufacturerID, and model have been changed from
++   * CK_CHAR to CK_UTF8CHAR for v2.10 */
++  CK_UTF8CHAR   label[32];           /* blank padded */
++  CK_UTF8CHAR   manufacturerID[32];  /* blank padded */
++  CK_UTF8CHAR   model[16];           /* blank padded */
++  CK_CHAR       serialNumber[16];    /* blank padded */
++  CK_FLAGS      flags;               /* see below */
++
++  /* ulMaxSessionCount, ulSessionCount, ulMaxRwSessionCount,
++   * ulRwSessionCount, ulMaxPinLen, and ulMinPinLen have all been
++   * changed from CK_USHORT to CK_ULONG for v2.0 */
++  CK_ULONG      ulMaxSessionCount;     /* max open sessions */
++  CK_ULONG      ulSessionCount;        /* sess. now open */
++  CK_ULONG      ulMaxRwSessionCount;   /* max R/W sessions */
++  CK_ULONG      ulRwSessionCount;      /* R/W sess. now open */
++  CK_ULONG      ulMaxPinLen;           /* in bytes */
++  CK_ULONG      ulMinPinLen;           /* in bytes */
++  CK_ULONG      ulTotalPublicMemory;   /* in bytes */
++  CK_ULONG      ulFreePublicMemory;    /* in bytes */
++  CK_ULONG      ulTotalPrivateMemory;  /* in bytes */
++  CK_ULONG      ulFreePrivateMemory;   /* in bytes */
++
++  /* hardwareVersion, firmwareVersion, and time are new for
++   * v2.0 */
++  CK_VERSION    hardwareVersion;       /* version of hardware */
++  CK_VERSION    firmwareVersion;       /* version of firmware */
++  CK_CHAR       utcTime[16];           /* time */
++} CK_TOKEN_INFO;
++
++/* The flags parameter is defined as follows:
++ *      Bit Flag                    Mask        Meaning
++ */
++#define CKF_RNG                     0x00000001  /* has random #
++                                                 * generator */
++#define CKF_WRITE_PROTECTED         0x00000002  /* token is
++                                                 * write-
++                                                 * protected */
++#define CKF_LOGIN_REQUIRED          0x00000004  /* user must
++                                                 * login */
++#define CKF_USER_PIN_INITIALIZED    0x00000008  /* normal user's
++                                                 * PIN is set */
++
++/* CKF_RESTORE_KEY_NOT_NEEDED is new for v2.0.  If it is set,
++ * that means that *every* time the state of cryptographic
++ * operations of a session is successfully saved, all keys
++ * needed to continue those operations are stored in the state */
++#define CKF_RESTORE_KEY_NOT_NEEDED  0x00000020
++
++/* CKF_CLOCK_ON_TOKEN is new for v2.0.  If it is set, that means
++ * that the token has some sort of clock.  The time on that
++ * clock is returned in the token info structure */
++#define CKF_CLOCK_ON_TOKEN          0x00000040
++
++/* CKF_PROTECTED_AUTHENTICATION_PATH is new for v2.0.  If it is
++ * set, that means that there is some way for the user to login
++ * without sending a PIN through the Cryptoki library itself */
++#define CKF_PROTECTED_AUTHENTICATION_PATH 0x00000100
++
++/* CKF_DUAL_CRYPTO_OPERATIONS is new for v2.0.  If it is true,
++ * that means that a single session with the token can perform
++ * dual simultaneous cryptographic operations (digest and
++ * encrypt; decrypt and digest; sign and encrypt; and decrypt
++ * and sign) */
++#define CKF_DUAL_CRYPTO_OPERATIONS  0x00000200
++
++/* CKF_TOKEN_INITIALIZED if new for v2.10. If it is true, the
++ * token has been initialized using C_InitializeToken or an
++ * equivalent mechanism outside the scope of PKCS #11.
++ * Calling C_InitializeToken when this flag is set will cause
++ * the token to be reinitialized. */
++#define CKF_TOKEN_INITIALIZED       0x00000400
++
++/* CKF_SECONDARY_AUTHENTICATION if new for v2.10. If it is
++ * true, the token supports secondary authentication for
++ * private key objects. This flag is deprecated in v2.11 and
++   onwards. */
++#define CKF_SECONDARY_AUTHENTICATION  0x00000800
++
++/* CKF_USER_PIN_COUNT_LOW if new for v2.10. If it is true, an
++ * incorrect user login PIN has been entered at least once
++ * since the last successful authentication. */
++#define CKF_USER_PIN_COUNT_LOW       0x00010000
++
++/* CKF_USER_PIN_FINAL_TRY if new for v2.10. If it is true,
++ * supplying an incorrect user PIN will it to become locked. */
++#define CKF_USER_PIN_FINAL_TRY       0x00020000
++
++/* CKF_USER_PIN_LOCKED if new for v2.10. If it is true, the
++ * user PIN has been locked. User login to the token is not
++ * possible. */
++#define CKF_USER_PIN_LOCKED          0x00040000
++
++/* CKF_USER_PIN_TO_BE_CHANGED if new for v2.10. If it is true,
++ * the user PIN value is the default value set by token
++ * initialization or manufacturing, or the PIN has been
++ * expired by the card. */
++#define CKF_USER_PIN_TO_BE_CHANGED   0x00080000
++
++/* CKF_SO_PIN_COUNT_LOW if new for v2.10. If it is true, an
++ * incorrect SO login PIN has been entered at least once since
++ * the last successful authentication. */
++#define CKF_SO_PIN_COUNT_LOW         0x00100000
++
++/* CKF_SO_PIN_FINAL_TRY if new for v2.10. If it is true,
++ * supplying an incorrect SO PIN will it to become locked. */
++#define CKF_SO_PIN_FINAL_TRY         0x00200000
++
++/* CKF_SO_PIN_LOCKED if new for v2.10. If it is true, the SO
++ * PIN has been locked. SO login to the token is not possible.
++ */
++#define CKF_SO_PIN_LOCKED            0x00400000
++
++/* CKF_SO_PIN_TO_BE_CHANGED if new for v2.10. If it is true,
++ * the SO PIN value is the default value set by token
++ * initialization or manufacturing, or the PIN has been
++ * expired by the card. */
++#define CKF_SO_PIN_TO_BE_CHANGED     0x00800000
++
++typedef CK_TOKEN_INFO CK_PTR CK_TOKEN_INFO_PTR;
++
++
++/* CK_SESSION_HANDLE is a Cryptoki-assigned value that
++ * identifies a session */
++typedef CK_ULONG          CK_SESSION_HANDLE;
++
++typedef CK_SESSION_HANDLE CK_PTR CK_SESSION_HANDLE_PTR;
++
++
++/* CK_USER_TYPE enumerates the types of Cryptoki users */
++/* CK_USER_TYPE has been changed from an enum to a CK_ULONG for
++ * v2.0 */
++typedef CK_ULONG          CK_USER_TYPE;
++/* Security Officer */
++#define CKU_SO    0
++/* Normal user */
++#define CKU_USER  1
++/* Context specific (added in v2.20) */
++#define CKU_CONTEXT_SPECIFIC   2
++
++/* CK_STATE enumerates the session states */
++/* CK_STATE has been changed from an enum to a CK_ULONG for
++ * v2.0 */
++typedef CK_ULONG          CK_STATE;
++#define CKS_RO_PUBLIC_SESSION  0
++#define CKS_RO_USER_FUNCTIONS  1
++#define CKS_RW_PUBLIC_SESSION  2
++#define CKS_RW_USER_FUNCTIONS  3
++#define CKS_RW_SO_FUNCTIONS    4
++
++
++/* CK_SESSION_INFO provides information about a session */
++typedef struct CK_SESSION_INFO {
++  CK_SLOT_ID    slotID;
++  CK_STATE      state;
++  CK_FLAGS      flags;          /* see below */
++
++  /* ulDeviceError was changed from CK_USHORT to CK_ULONG for
++   * v2.0 */
++  CK_ULONG      ulDeviceError;  /* device-dependent error code */
++} CK_SESSION_INFO;
++
++/* The flags are defined in the following table:
++ *      Bit Flag                Mask        Meaning
++ */
++#define CKF_RW_SESSION          0x00000002  /* session is r/w */
++#define CKF_SERIAL_SESSION      0x00000004  /* no parallel */
++
++typedef CK_SESSION_INFO CK_PTR CK_SESSION_INFO_PTR;
++
++
++/* CK_OBJECT_HANDLE is a token-specific identifier for an
++ * object  */
++typedef CK_ULONG          CK_OBJECT_HANDLE;
++
++typedef CK_OBJECT_HANDLE CK_PTR CK_OBJECT_HANDLE_PTR;
++
++
++/* CK_OBJECT_CLASS is a value that identifies the classes (or
++ * types) of objects that Cryptoki recognizes.  It is defined
++ * as follows: */
++/* CK_OBJECT_CLASS was changed from CK_USHORT to CK_ULONG for
++ * v2.0 */
++typedef CK_ULONG          CK_OBJECT_CLASS;
++
++/* The following classes of objects are defined: */
++/* CKO_HW_FEATURE is new for v2.10 */
++/* CKO_DOMAIN_PARAMETERS is new for v2.11 */
++/* CKO_MECHANISM is new for v2.20 */
++#define CKO_DATA              0x00000000
++#define CKO_CERTIFICATE       0x00000001
++#define CKO_PUBLIC_KEY        0x00000002
++#define CKO_PRIVATE_KEY       0x00000003
++#define CKO_SECRET_KEY        0x00000004
++#define CKO_HW_FEATURE        0x00000005
++#define CKO_DOMAIN_PARAMETERS 0x00000006
++#define CKO_MECHANISM         0x00000007
++
++/* CKO_OTP_KEY is new for PKCS #11 v2.20 amendment 1 */
++#define CKO_OTP_KEY           0x00000008
++
++#define CKO_VENDOR_DEFINED    0x80000000
++
++typedef CK_OBJECT_CLASS CK_PTR CK_OBJECT_CLASS_PTR;
++
++/* CK_HW_FEATURE_TYPE is new for v2.10. CK_HW_FEATURE_TYPE is a
++ * value that identifies the hardware feature type of an object
++ * with CK_OBJECT_CLASS equal to CKO_HW_FEATURE. */
++typedef CK_ULONG          CK_HW_FEATURE_TYPE;
++
++/* The following hardware feature types are defined */
++/* CKH_USER_INTERFACE is new for v2.20 */
++#define CKH_MONOTONIC_COUNTER  0x00000001
++#define CKH_CLOCK           0x00000002
++#define CKH_USER_INTERFACE  0x00000003
++#define CKH_VENDOR_DEFINED  0x80000000
++
++/* CK_KEY_TYPE is a value that identifies a key type */
++/* CK_KEY_TYPE was changed from CK_USHORT to CK_ULONG for v2.0 */
++typedef CK_ULONG          CK_KEY_TYPE;
++
++/* the following key types are defined: */
++#define CKK_RSA             0x00000000
++#define CKK_DSA             0x00000001
++#define CKK_DH              0x00000002
++
++/* CKK_ECDSA and CKK_KEA are new for v2.0 */
++/* CKK_ECDSA is deprecated in v2.11, CKK_EC is preferred. */
++#define CKK_ECDSA           0x00000003
++#define CKK_EC              0x00000003
++#define CKK_X9_42_DH        0x00000004
++#define CKK_KEA             0x00000005
++
++#define CKK_GENERIC_SECRET  0x00000010
++#define CKK_RC2             0x00000011
++#define CKK_RC4             0x00000012
++#define CKK_DES             0x00000013
++#define CKK_DES2            0x00000014
++#define CKK_DES3            0x00000015
++
++/* all these key types are new for v2.0 */
++#define CKK_CAST            0x00000016
++#define CKK_CAST3           0x00000017
++/* CKK_CAST5 is deprecated in v2.11, CKK_CAST128 is preferred. */
++#define CKK_CAST5           0x00000018
++#define CKK_CAST128         0x00000018
++#define CKK_RC5             0x00000019
++#define CKK_IDEA            0x0000001A
++#define CKK_SKIPJACK        0x0000001B
++#define CKK_BATON           0x0000001C
++#define CKK_JUNIPER         0x0000001D
++#define CKK_CDMF            0x0000001E
++#define CKK_AES             0x0000001F
++
++/* BlowFish and TwoFish are new for v2.20 */
++#define CKK_BLOWFISH        0x00000020
++#define CKK_TWOFISH         0x00000021
++
++/* SecurID, HOTP, and ACTI are new for PKCS #11 v2.20 amendment 1 */
++#define CKK_SECURID         0x00000022
++#define CKK_HOTP            0x00000023
++#define CKK_ACTI            0x00000024
++
++/* Camellia is new for PKCS #11 v2.20 amendment 3 */
++#define CKK_CAMELLIA                   0x00000025
++/* ARIA is new for PKCS #11 v2.20 amendment 3 */
++#define CKK_ARIA                       0x00000026
++
++
++#define CKK_VENDOR_DEFINED  0x80000000
++
++
++/* CK_CERTIFICATE_TYPE is a value that identifies a certificate
++ * type */
++/* CK_CERTIFICATE_TYPE was changed from CK_USHORT to CK_ULONG
++ * for v2.0 */
++typedef CK_ULONG          CK_CERTIFICATE_TYPE;
++
++/* The following certificate types are defined: */
++/* CKC_X_509_ATTR_CERT is new for v2.10 */
++/* CKC_WTLS is new for v2.20 */
++#define CKC_X_509           0x00000000
++#define CKC_X_509_ATTR_CERT 0x00000001
++#define CKC_WTLS            0x00000002
++#define CKC_VENDOR_DEFINED  0x80000000
++
++
++/* CK_ATTRIBUTE_TYPE is a value that identifies an attribute
++ * type */
++/* CK_ATTRIBUTE_TYPE was changed from CK_USHORT to CK_ULONG for
++ * v2.0 */
++typedef CK_ULONG          CK_ATTRIBUTE_TYPE;
++
++/* The CKF_ARRAY_ATTRIBUTE flag identifies an attribute which
++   consists of an array of values. */
++#define CKF_ARRAY_ATTRIBUTE    0x40000000
++
++/* The following OTP-related defines are new for PKCS #11 v2.20 amendment 1
++   and relates to the CKA_OTP_FORMAT attribute */
++#define CK_OTP_FORMAT_DECIMAL      0
++#define CK_OTP_FORMAT_HEXADECIMAL  1
++#define CK_OTP_FORMAT_ALPHANUMERIC 2
++#define CK_OTP_FORMAT_BINARY       3
++
++/* The following OTP-related defines are new for PKCS #11 v2.20 amendment 1
++   and relates to the CKA_OTP_..._REQUIREMENT attributes */
++#define CK_OTP_PARAM_IGNORED       0
++#define CK_OTP_PARAM_OPTIONAL      1
++#define CK_OTP_PARAM_MANDATORY     2
++
++/* The following attribute types are defined: */
++#define CKA_CLASS              0x00000000
++#define CKA_TOKEN              0x00000001
++#define CKA_PRIVATE            0x00000002
++#define CKA_LABEL              0x00000003
++#define CKA_APPLICATION        0x00000010
++#define CKA_VALUE              0x00000011
++
++/* CKA_OBJECT_ID is new for v2.10 */
++#define CKA_OBJECT_ID          0x00000012
++
++#define CKA_CERTIFICATE_TYPE   0x00000080
++#define CKA_ISSUER             0x00000081
++#define CKA_SERIAL_NUMBER      0x00000082
++
++/* CKA_AC_ISSUER, CKA_OWNER, and CKA_ATTR_TYPES are new
++ * for v2.10 */
++#define CKA_AC_ISSUER          0x00000083
++#define CKA_OWNER              0x00000084
++#define CKA_ATTR_TYPES         0x00000085
++
++/* CKA_TRUSTED is new for v2.11 */
++#define CKA_TRUSTED            0x00000086
++
++/* CKA_CERTIFICATE_CATEGORY ...
++ * CKA_CHECK_VALUE are new for v2.20 */
++#define CKA_CERTIFICATE_CATEGORY        0x00000087
++#define CKA_JAVA_MIDP_SECURITY_DOMAIN   0x00000088
++#define CKA_URL                         0x00000089
++#define CKA_HASH_OF_SUBJECT_PUBLIC_KEY  0x0000008A
++#define CKA_HASH_OF_ISSUER_PUBLIC_KEY   0x0000008B
++#define CKA_CHECK_VALUE                 0x00000090
++
++#define CKA_KEY_TYPE           0x00000100
++#define CKA_SUBJECT            0x00000101
++#define CKA_ID                 0x00000102
++#define CKA_SENSITIVE          0x00000103
++#define CKA_ENCRYPT            0x00000104
++#define CKA_DECRYPT            0x00000105
++#define CKA_WRAP               0x00000106
++#define CKA_UNWRAP             0x00000107
++#define CKA_SIGN               0x00000108
++#define CKA_SIGN_RECOVER       0x00000109
++#define CKA_VERIFY             0x0000010A
++#define CKA_VERIFY_RECOVER     0x0000010B
++#define CKA_DERIVE             0x0000010C
++#define CKA_START_DATE         0x00000110
++#define CKA_END_DATE           0x00000111
++#define CKA_MODULUS            0x00000120
++#define CKA_MODULUS_BITS       0x00000121
++#define CKA_PUBLIC_EXPONENT    0x00000122
++#define CKA_PRIVATE_EXPONENT   0x00000123
++#define CKA_PRIME_1            0x00000124
++#define CKA_PRIME_2            0x00000125
++#define CKA_EXPONENT_1         0x00000126
++#define CKA_EXPONENT_2         0x00000127
++#define CKA_COEFFICIENT        0x00000128
++#define CKA_PRIME              0x00000130
++#define CKA_SUBPRIME           0x00000131
++#define CKA_BASE               0x00000132
++
++/* CKA_PRIME_BITS and CKA_SUB_PRIME_BITS are new for v2.11 */
++#define CKA_PRIME_BITS         0x00000133
++#define CKA_SUBPRIME_BITS      0x00000134
++#define CKA_SUB_PRIME_BITS     CKA_SUBPRIME_BITS
++/* (To retain backwards-compatibility) */
++
++#define CKA_VALUE_BITS         0x00000160
++#define CKA_VALUE_LEN          0x00000161
++
++/* CKA_EXTRACTABLE, CKA_LOCAL, CKA_NEVER_EXTRACTABLE,
++ * CKA_ALWAYS_SENSITIVE, CKA_MODIFIABLE, CKA_ECDSA_PARAMS,
++ * and CKA_EC_POINT are new for v2.0 */
++#define CKA_EXTRACTABLE        0x00000162
++#define CKA_LOCAL              0x00000163
++#define CKA_NEVER_EXTRACTABLE  0x00000164
++#define CKA_ALWAYS_SENSITIVE   0x00000165
++
++/* CKA_KEY_GEN_MECHANISM is new for v2.11 */
++#define CKA_KEY_GEN_MECHANISM  0x00000166
++
++#define CKA_MODIFIABLE         0x00000170
++
++/* CKA_ECDSA_PARAMS is deprecated in v2.11,
++ * CKA_EC_PARAMS is preferred. */
++#define CKA_ECDSA_PARAMS       0x00000180
++#define CKA_EC_PARAMS          0x00000180
++
++#define CKA_EC_POINT           0x00000181
++
++/* CKA_SECONDARY_AUTH, CKA_AUTH_PIN_FLAGS,
++ * are new for v2.10. Deprecated in v2.11 and onwards. */
++#define CKA_SECONDARY_AUTH     0x00000200
++#define CKA_AUTH_PIN_FLAGS     0x00000201
++
++/* CKA_ALWAYS_AUTHENTICATE ...
++ * CKA_UNWRAP_TEMPLATE are new for v2.20 */
++#define CKA_ALWAYS_AUTHENTICATE  0x00000202
++
++#define CKA_WRAP_WITH_TRUSTED    0x00000210
++#define CKA_WRAP_TEMPLATE        (CKF_ARRAY_ATTRIBUTE|0x00000211)
++#define CKA_UNWRAP_TEMPLATE      (CKF_ARRAY_ATTRIBUTE|0x00000212)
++
++/* CKA_OTP... atttributes are new for PKCS #11 v2.20 amendment 3. */
++#define CKA_OTP_FORMAT                0x00000220
++#define CKA_OTP_LENGTH                0x00000221
++#define CKA_OTP_TIME_INTERVAL         0x00000222
++#define CKA_OTP_USER_FRIENDLY_MODE    0x00000223
++#define CKA_OTP_CHALLENGE_REQUIREMENT 0x00000224
++#define CKA_OTP_TIME_REQUIREMENT      0x00000225
++#define CKA_OTP_COUNTER_REQUIREMENT   0x00000226
++#define CKA_OTP_PIN_REQUIREMENT       0x00000227
++#define CKA_OTP_COUNTER               0x0000022E
++#define CKA_OTP_TIME                  0x0000022F
++#define CKA_OTP_USER_IDENTIFIER       0x0000022A
++#define CKA_OTP_SERVICE_IDENTIFIER    0x0000022B
++#define CKA_OTP_SERVICE_LOGO          0x0000022C
++#define CKA_OTP_SERVICE_LOGO_TYPE     0x0000022D
++
++
++/* CKA_HW_FEATURE_TYPE, CKA_RESET_ON_INIT, and CKA_HAS_RESET
++ * are new for v2.10 */
++#define CKA_HW_FEATURE_TYPE    0x00000300
++#define CKA_RESET_ON_INIT      0x00000301
++#define CKA_HAS_RESET          0x00000302
++
++/* The following attributes are new for v2.20 */
++#define CKA_PIXEL_X                     0x00000400
++#define CKA_PIXEL_Y                     0x00000401
++#define CKA_RESOLUTION                  0x00000402
++#define CKA_CHAR_ROWS                   0x00000403
++#define CKA_CHAR_COLUMNS                0x00000404
++#define CKA_COLOR                       0x00000405
++#define CKA_BITS_PER_PIXEL              0x00000406
++#define CKA_CHAR_SETS                   0x00000480
++#define CKA_ENCODING_METHODS            0x00000481
++#define CKA_MIME_TYPES                  0x00000482
++#define CKA_MECHANISM_TYPE              0x00000500
++#define CKA_REQUIRED_CMS_ATTRIBUTES     0x00000501
++#define CKA_DEFAULT_CMS_ATTRIBUTES      0x00000502
++#define CKA_SUPPORTED_CMS_ATTRIBUTES    0x00000503
++#define CKA_ALLOWED_MECHANISMS          (CKF_ARRAY_ATTRIBUTE|0x00000600)
++
++#define CKA_VENDOR_DEFINED     0x80000000
++
++/* CK_ATTRIBUTE is a structure that includes the type, length
++ * and value of an attribute */
++typedef struct CK_ATTRIBUTE {
++  CK_ATTRIBUTE_TYPE type;
++  CK_VOID_PTR       pValue;
++
++  /* ulValueLen went from CK_USHORT to CK_ULONG for v2.0 */
++  CK_ULONG          ulValueLen;  /* in bytes */
++} CK_ATTRIBUTE;
++
++typedef CK_ATTRIBUTE CK_PTR CK_ATTRIBUTE_PTR;
++
++
++/* CK_DATE is a structure that defines a date */
++typedef struct CK_DATE{
++  CK_CHAR       year[4];   /* the year ("1900" - "9999") */
++  CK_CHAR       month[2];  /* the month ("01" - "12") */
++  CK_CHAR       day[2];    /* the day   ("01" - "31") */
++} CK_DATE;
++
++
++/* CK_MECHANISM_TYPE is a value that identifies a mechanism
++ * type */
++/* CK_MECHANISM_TYPE was changed from CK_USHORT to CK_ULONG for
++ * v2.0 */
++typedef CK_ULONG          CK_MECHANISM_TYPE;
++
++/* the following mechanism types are defined: */
++#define CKM_RSA_PKCS_KEY_PAIR_GEN      0x00000000
++#define CKM_RSA_PKCS                   0x00000001
++#define CKM_RSA_9796                   0x00000002
++#define CKM_RSA_X_509                  0x00000003
++
++/* CKM_MD2_RSA_PKCS, CKM_MD5_RSA_PKCS, and CKM_SHA1_RSA_PKCS
++ * are new for v2.0.  They are mechanisms which hash and sign */
++#define CKM_MD2_RSA_PKCS               0x00000004
++#define CKM_MD5_RSA_PKCS               0x00000005
++#define CKM_SHA1_RSA_PKCS              0x00000006
++
++/* CKM_RIPEMD128_RSA_PKCS, CKM_RIPEMD160_RSA_PKCS, and
++ * CKM_RSA_PKCS_OAEP are new for v2.10 */
++#define CKM_RIPEMD128_RSA_PKCS         0x00000007
++#define CKM_RIPEMD160_RSA_PKCS         0x00000008
++#define CKM_RSA_PKCS_OAEP              0x00000009
++
++/* CKM_RSA_X9_31_KEY_PAIR_GEN, CKM_RSA_X9_31, CKM_SHA1_RSA_X9_31,
++ * CKM_RSA_PKCS_PSS, and CKM_SHA1_RSA_PKCS_PSS are new for v2.11 */
++#define CKM_RSA_X9_31_KEY_PAIR_GEN     0x0000000A
++#define CKM_RSA_X9_31                  0x0000000B
++#define CKM_SHA1_RSA_X9_31             0x0000000C
++#define CKM_RSA_PKCS_PSS               0x0000000D
++#define CKM_SHA1_RSA_PKCS_PSS          0x0000000E
++
++#define CKM_DSA_KEY_PAIR_GEN           0x00000010
++#define CKM_DSA                        0x00000011
++#define CKM_DSA_SHA1                   0x00000012
++#define CKM_DH_PKCS_KEY_PAIR_GEN       0x00000020
++#define CKM_DH_PKCS_DERIVE             0x00000021
++
++/* CKM_X9_42_DH_KEY_PAIR_GEN, CKM_X9_42_DH_DERIVE,
++ * CKM_X9_42_DH_HYBRID_DERIVE, and CKM_X9_42_MQV_DERIVE are new for
++ * v2.11 */
++#define CKM_X9_42_DH_KEY_PAIR_GEN      0x00000030
++#define CKM_X9_42_DH_DERIVE            0x00000031
++#define CKM_X9_42_DH_HYBRID_DERIVE     0x00000032
++#define CKM_X9_42_MQV_DERIVE           0x00000033
++
++/* CKM_SHA256/384/512 are new for v2.20 */
++#define CKM_SHA256_RSA_PKCS            0x00000040
++#define CKM_SHA384_RSA_PKCS            0x00000041
++#define CKM_SHA512_RSA_PKCS            0x00000042
++#define CKM_SHA256_RSA_PKCS_PSS        0x00000043
++#define CKM_SHA384_RSA_PKCS_PSS        0x00000044
++#define CKM_SHA512_RSA_PKCS_PSS        0x00000045
++
++/* SHA-224 RSA mechanisms are new for PKCS #11 v2.20 amendment 3 */
++#define CKM_SHA224_RSA_PKCS            0x00000046
++#define CKM_SHA224_RSA_PKCS_PSS        0x00000047
++
++#define CKM_RC2_KEY_GEN                0x00000100
++#define CKM_RC2_ECB                    0x00000101
++#define CKM_RC2_CBC                    0x00000102
++#define CKM_RC2_MAC                    0x00000103
++
++/* CKM_RC2_MAC_GENERAL and CKM_RC2_CBC_PAD are new for v2.0 */
++#define CKM_RC2_MAC_GENERAL            0x00000104
++#define CKM_RC2_CBC_PAD                0x00000105
++
++#define CKM_RC4_KEY_GEN                0x00000110
++#define CKM_RC4                        0x00000111
++#define CKM_DES_KEY_GEN                0x00000120
++#define CKM_DES_ECB                    0x00000121
++#define CKM_DES_CBC                    0x00000122
++#define CKM_DES_MAC                    0x00000123
++
++/* CKM_DES_MAC_GENERAL and CKM_DES_CBC_PAD are new for v2.0 */
++#define CKM_DES_MAC_GENERAL            0x00000124
++#define CKM_DES_CBC_PAD                0x00000125
++
++#define CKM_DES2_KEY_GEN               0x00000130
++#define CKM_DES3_KEY_GEN               0x00000131
++#define CKM_DES3_ECB                   0x00000132
++#define CKM_DES3_CBC                   0x00000133
++#define CKM_DES3_MAC                   0x00000134
++
++/* CKM_DES3_MAC_GENERAL, CKM_DES3_CBC_PAD, CKM_CDMF_KEY_GEN,
++ * CKM_CDMF_ECB, CKM_CDMF_CBC, CKM_CDMF_MAC,
++ * CKM_CDMF_MAC_GENERAL, and CKM_CDMF_CBC_PAD are new for v2.0 */
++#define CKM_DES3_MAC_GENERAL           0x00000135
++#define CKM_DES3_CBC_PAD               0x00000136
++#define CKM_CDMF_KEY_GEN               0x00000140
++#define CKM_CDMF_ECB                   0x00000141
++#define CKM_CDMF_CBC                   0x00000142
++#define CKM_CDMF_MAC                   0x00000143
++#define CKM_CDMF_MAC_GENERAL           0x00000144
++#define CKM_CDMF_CBC_PAD               0x00000145
++
++/* the following four DES mechanisms are new for v2.20 */
++#define CKM_DES_OFB64                  0x00000150
++#define CKM_DES_OFB8                   0x00000151
++#define CKM_DES_CFB64                  0x00000152
++#define CKM_DES_CFB8                   0x00000153
++
++#define CKM_MD2                        0x00000200
++
++/* CKM_MD2_HMAC and CKM_MD2_HMAC_GENERAL are new for v2.0 */
++#define CKM_MD2_HMAC                   0x00000201
++#define CKM_MD2_HMAC_GENERAL           0x00000202
++
++#define CKM_MD5                        0x00000210
++
++/* CKM_MD5_HMAC and CKM_MD5_HMAC_GENERAL are new for v2.0 */
++#define CKM_MD5_HMAC                   0x00000211
++#define CKM_MD5_HMAC_GENERAL           0x00000212
++
++#define CKM_SHA_1                      0x00000220
++
++/* CKM_SHA_1_HMAC and CKM_SHA_1_HMAC_GENERAL are new for v2.0 */
++#define CKM_SHA_1_HMAC                 0x00000221
++#define CKM_SHA_1_HMAC_GENERAL         0x00000222
++
++/* CKM_RIPEMD128, CKM_RIPEMD128_HMAC,
++ * CKM_RIPEMD128_HMAC_GENERAL, CKM_RIPEMD160, CKM_RIPEMD160_HMAC,
++ * and CKM_RIPEMD160_HMAC_GENERAL are new for v2.10 */
++#define CKM_RIPEMD128                  0x00000230
++#define CKM_RIPEMD128_HMAC             0x00000231
++#define CKM_RIPEMD128_HMAC_GENERAL     0x00000232
++#define CKM_RIPEMD160                  0x00000240
++#define CKM_RIPEMD160_HMAC             0x00000241
++#define CKM_RIPEMD160_HMAC_GENERAL     0x00000242
++
++/* CKM_SHA256/384/512 are new for v2.20 */
++#define CKM_SHA256                     0x00000250
++#define CKM_SHA256_HMAC                0x00000251
++#define CKM_SHA256_HMAC_GENERAL        0x00000252
++
++/* SHA-224 is new for PKCS #11 v2.20 amendment 3 */
++#define CKM_SHA224                     0x00000255
++#define CKM_SHA224_HMAC                0x00000256
++#define CKM_SHA224_HMAC_GENERAL        0x00000257
++
++#define CKM_SHA384                     0x00000260
++#define CKM_SHA384_HMAC                0x00000261
++#define CKM_SHA384_HMAC_GENERAL        0x00000262
++#define CKM_SHA512                     0x00000270
++#define CKM_SHA512_HMAC                0x00000271
++#define CKM_SHA512_HMAC_GENERAL        0x00000272
++
++/* SecurID is new for PKCS #11 v2.20 amendment 1 */
++#define CKM_SECURID_KEY_GEN            0x00000280
++#define CKM_SECURID                    0x00000282
++
++/* HOTP is new for PKCS #11 v2.20 amendment 1 */
++#define CKM_HOTP_KEY_GEN    0x00000290
++#define CKM_HOTP            0x00000291
++
++/* ACTI is new for PKCS #11 v2.20 amendment 1 */
++#define CKM_ACTI            0x000002A0
++#define CKM_ACTI_KEY_GEN    0x000002A1
++
++/* All of the following mechanisms are new for v2.0 */
++/* Note that CAST128 and CAST5 are the same algorithm */
++#define CKM_CAST_KEY_GEN               0x00000300
++#define CKM_CAST_ECB                   0x00000301
++#define CKM_CAST_CBC                   0x00000302
++#define CKM_CAST_MAC                   0x00000303
++#define CKM_CAST_MAC_GENERAL           0x00000304
++#define CKM_CAST_CBC_PAD               0x00000305
++#define CKM_CAST3_KEY_GEN              0x00000310
++#define CKM_CAST3_ECB                  0x00000311
++#define CKM_CAST3_CBC                  0x00000312
++#define CKM_CAST3_MAC                  0x00000313
++#define CKM_CAST3_MAC_GENERAL          0x00000314
++#define CKM_CAST3_CBC_PAD              0x00000315
++#define CKM_CAST5_KEY_GEN              0x00000320
++#define CKM_CAST128_KEY_GEN            0x00000320
++#define CKM_CAST5_ECB                  0x00000321
++#define CKM_CAST128_ECB                0x00000321
++#define CKM_CAST5_CBC                  0x00000322
++#define CKM_CAST128_CBC                0x00000322
++#define CKM_CAST5_MAC                  0x00000323
++#define CKM_CAST128_MAC                0x00000323
++#define CKM_CAST5_MAC_GENERAL          0x00000324
++#define CKM_CAST128_MAC_GENERAL        0x00000324
++#define CKM_CAST5_CBC_PAD              0x00000325
++#define CKM_CAST128_CBC_PAD            0x00000325
++#define CKM_RC5_KEY_GEN                0x00000330
++#define CKM_RC5_ECB                    0x00000331
++#define CKM_RC5_CBC                    0x00000332
++#define CKM_RC5_MAC                    0x00000333
++#define CKM_RC5_MAC_GENERAL            0x00000334
++#define CKM_RC5_CBC_PAD                0x00000335
++#define CKM_IDEA_KEY_GEN               0x00000340
++#define CKM_IDEA_ECB                   0x00000341
++#define CKM_IDEA_CBC                   0x00000342
++#define CKM_IDEA_MAC                   0x00000343
++#define CKM_IDEA_MAC_GENERAL           0x00000344
++#define CKM_IDEA_CBC_PAD               0x00000345
++#define CKM_GENERIC_SECRET_KEY_GEN     0x00000350
++#define CKM_CONCATENATE_BASE_AND_KEY   0x00000360
++#define CKM_CONCATENATE_BASE_AND_DATA  0x00000362
++#define CKM_CONCATENATE_DATA_AND_BASE  0x00000363
++#define CKM_XOR_BASE_AND_DATA          0x00000364
++#define CKM_EXTRACT_KEY_FROM_KEY       0x00000365
++#define CKM_SSL3_PRE_MASTER_KEY_GEN    0x00000370
++#define CKM_SSL3_MASTER_KEY_DERIVE     0x00000371
++#define CKM_SSL3_KEY_AND_MAC_DERIVE    0x00000372
++
++/* CKM_SSL3_MASTER_KEY_DERIVE_DH, CKM_TLS_PRE_MASTER_KEY_GEN,
++ * CKM_TLS_MASTER_KEY_DERIVE, CKM_TLS_KEY_AND_MAC_DERIVE, and
++ * CKM_TLS_MASTER_KEY_DERIVE_DH are new for v2.11 */
++#define CKM_SSL3_MASTER_KEY_DERIVE_DH  0x00000373
++#define CKM_TLS_PRE_MASTER_KEY_GEN     0x00000374
++#define CKM_TLS_MASTER_KEY_DERIVE      0x00000375
++#define CKM_TLS_KEY_AND_MAC_DERIVE     0x00000376
++#define CKM_TLS_MASTER_KEY_DERIVE_DH   0x00000377
++
++/* CKM_TLS_PRF is new for v2.20 */
++#define CKM_TLS_PRF                    0x00000378
++
++#define CKM_SSL3_MD5_MAC               0x00000380
++#define CKM_SSL3_SHA1_MAC              0x00000381
++#define CKM_MD5_KEY_DERIVATION         0x00000390
++#define CKM_MD2_KEY_DERIVATION         0x00000391
++#define CKM_SHA1_KEY_DERIVATION        0x00000392
++
++/* CKM_SHA256/384/512 are new for v2.20 */
++#define CKM_SHA256_KEY_DERIVATION      0x00000393
++#define CKM_SHA384_KEY_DERIVATION      0x00000394
++#define CKM_SHA512_KEY_DERIVATION      0x00000395
++
++/* SHA-224 key derivation is new for PKCS #11 v2.20 amendment 3 */
++#define CKM_SHA224_KEY_DERIVATION      0x00000396
++
++#define CKM_PBE_MD2_DES_CBC            0x000003A0
++#define CKM_PBE_MD5_DES_CBC            0x000003A1
++#define CKM_PBE_MD5_CAST_CBC           0x000003A2
++#define CKM_PBE_MD5_CAST3_CBC          0x000003A3
++#define CKM_PBE_MD5_CAST5_CBC          0x000003A4
++#define CKM_PBE_MD5_CAST128_CBC        0x000003A4
++#define CKM_PBE_SHA1_CAST5_CBC         0x000003A5
++#define CKM_PBE_SHA1_CAST128_CBC       0x000003A5
++#define CKM_PBE_SHA1_RC4_128           0x000003A6
++#define CKM_PBE_SHA1_RC4_40            0x000003A7
++#define CKM_PBE_SHA1_DES3_EDE_CBC      0x000003A8
++#define CKM_PBE_SHA1_DES2_EDE_CBC      0x000003A9
++#define CKM_PBE_SHA1_RC2_128_CBC       0x000003AA
++#define CKM_PBE_SHA1_RC2_40_CBC        0x000003AB
++
++/* CKM_PKCS5_PBKD2 is new for v2.10 */
++#define CKM_PKCS5_PBKD2                0x000003B0
++
++#define CKM_PBA_SHA1_WITH_SHA1_HMAC    0x000003C0
++
++/* WTLS mechanisms are new for v2.20 */
++#define CKM_WTLS_PRE_MASTER_KEY_GEN         0x000003D0
++#define CKM_WTLS_MASTER_KEY_DERIVE          0x000003D1
++#define CKM_WTLS_MASTER_KEY_DERIVE_DH_ECC   0x000003D2
++#define CKM_WTLS_PRF                        0x000003D3
++#define CKM_WTLS_SERVER_KEY_AND_MAC_DERIVE  0x000003D4
++#define CKM_WTLS_CLIENT_KEY_AND_MAC_DERIVE  0x000003D5
++
++#define CKM_KEY_WRAP_LYNKS             0x00000400
++#define CKM_KEY_WRAP_SET_OAEP          0x00000401
++
++/* CKM_CMS_SIG is new for v2.20 */
++#define CKM_CMS_SIG                    0x00000500
++
++/* CKM_KIP mechanisms are new for PKCS #11 v2.20 amendment 2 */
++#define CKM_KIP_DERIVE                 0x00000510
++#define CKM_KIP_WRAP                   0x00000511
++#define CKM_KIP_MAC                    0x00000512
++
++/* Camellia is new for PKCS #11 v2.20 amendment 3 */
++#define CKM_CAMELLIA_KEY_GEN           0x00000550
++#define CKM_CAMELLIA_ECB               0x00000551
++#define CKM_CAMELLIA_CBC               0x00000552
++#define CKM_CAMELLIA_MAC               0x00000553
++#define CKM_CAMELLIA_MAC_GENERAL       0x00000554
++#define CKM_CAMELLIA_CBC_PAD           0x00000555
++#define CKM_CAMELLIA_ECB_ENCRYPT_DATA  0x00000556
++#define CKM_CAMELLIA_CBC_ENCRYPT_DATA  0x00000557
++#define CKM_CAMELLIA_CTR               0x00000558
++
++/* ARIA is new for PKCS #11 v2.20 amendment 3 */
++#define CKM_ARIA_KEY_GEN               0x00000560
++#define CKM_ARIA_ECB                   0x00000561
++#define CKM_ARIA_CBC                   0x00000562
++#define CKM_ARIA_MAC                   0x00000563
++#define CKM_ARIA_MAC_GENERAL           0x00000564
++#define CKM_ARIA_CBC_PAD               0x00000565
++#define CKM_ARIA_ECB_ENCRYPT_DATA      0x00000566
++#define CKM_ARIA_CBC_ENCRYPT_DATA      0x00000567
++
++/* Fortezza mechanisms */
++#define CKM_SKIPJACK_KEY_GEN           0x00001000
++#define CKM_SKIPJACK_ECB64             0x00001001
++#define CKM_SKIPJACK_CBC64             0x00001002
++#define CKM_SKIPJACK_OFB64             0x00001003
++#define CKM_SKIPJACK_CFB64             0x00001004
++#define CKM_SKIPJACK_CFB32             0x00001005
++#define CKM_SKIPJACK_CFB16             0x00001006
++#define CKM_SKIPJACK_CFB8              0x00001007
++#define CKM_SKIPJACK_WRAP              0x00001008
++#define CKM_SKIPJACK_PRIVATE_WRAP      0x00001009
++#define CKM_SKIPJACK_RELAYX            0x0000100a
++#define CKM_KEA_KEY_PAIR_GEN           0x00001010
++#define CKM_KEA_KEY_DERIVE             0x00001011
++#define CKM_FORTEZZA_TIMESTAMP         0x00001020
++#define CKM_BATON_KEY_GEN              0x00001030
++#define CKM_BATON_ECB128               0x00001031
++#define CKM_BATON_ECB96                0x00001032
++#define CKM_BATON_CBC128               0x00001033
++#define CKM_BATON_COUNTER              0x00001034
++#define CKM_BATON_SHUFFLE              0x00001035
++#define CKM_BATON_WRAP                 0x00001036
++
++/* CKM_ECDSA_KEY_PAIR_GEN is deprecated in v2.11,
++ * CKM_EC_KEY_PAIR_GEN is preferred */
++#define CKM_ECDSA_KEY_PAIR_GEN         0x00001040
++#define CKM_EC_KEY_PAIR_GEN            0x00001040
++
++#define CKM_ECDSA                      0x00001041
++#define CKM_ECDSA_SHA1                 0x00001042
++
++/* CKM_ECDH1_DERIVE, CKM_ECDH1_COFACTOR_DERIVE, and CKM_ECMQV_DERIVE
++ * are new for v2.11 */
++#define CKM_ECDH1_DERIVE               0x00001050
++#define CKM_ECDH1_COFACTOR_DERIVE      0x00001051
++#define CKM_ECMQV_DERIVE               0x00001052
++
++#define CKM_JUNIPER_KEY_GEN            0x00001060
++#define CKM_JUNIPER_ECB128             0x00001061
++#define CKM_JUNIPER_CBC128             0x00001062
++#define CKM_JUNIPER_COUNTER            0x00001063
++#define CKM_JUNIPER_SHUFFLE            0x00001064
++#define CKM_JUNIPER_WRAP               0x00001065
++#define CKM_FASTHASH                   0x00001070
++
++/* CKM_AES_KEY_GEN, CKM_AES_ECB, CKM_AES_CBC, CKM_AES_MAC,
++ * CKM_AES_MAC_GENERAL, CKM_AES_CBC_PAD, CKM_DSA_PARAMETER_GEN,
++ * CKM_DH_PKCS_PARAMETER_GEN, and CKM_X9_42_DH_PARAMETER_GEN are
++ * new for v2.11 */
++#define CKM_AES_KEY_GEN                0x00001080
++#define CKM_AES_ECB                    0x00001081
++#define CKM_AES_CBC                    0x00001082
++#define CKM_AES_MAC                    0x00001083
++#define CKM_AES_MAC_GENERAL            0x00001084
++#define CKM_AES_CBC_PAD                0x00001085
++
++/* AES counter mode is new for PKCS #11 v2.20 amendment 3 */
++#define CKM_AES_CTR                    0x00001086
++
++/* BlowFish and TwoFish are new for v2.20 */
++#define CKM_BLOWFISH_KEY_GEN           0x00001090
++#define CKM_BLOWFISH_CBC               0x00001091
++#define CKM_TWOFISH_KEY_GEN            0x00001092
++#define CKM_TWOFISH_CBC                0x00001093
++
++
++/* CKM_xxx_ENCRYPT_DATA mechanisms are new for v2.20 */
++#define CKM_DES_ECB_ENCRYPT_DATA       0x00001100
++#define CKM_DES_CBC_ENCRYPT_DATA       0x00001101
++#define CKM_DES3_ECB_ENCRYPT_DATA      0x00001102
++#define CKM_DES3_CBC_ENCRYPT_DATA      0x00001103
++#define CKM_AES_ECB_ENCRYPT_DATA       0x00001104
++#define CKM_AES_CBC_ENCRYPT_DATA       0x00001105
++
++#define CKM_DSA_PARAMETER_GEN          0x00002000
++#define CKM_DH_PKCS_PARAMETER_GEN      0x00002001
++#define CKM_X9_42_DH_PARAMETER_GEN     0x00002002
++
++#define CKM_VENDOR_DEFINED             0x80000000
++
++typedef CK_MECHANISM_TYPE CK_PTR CK_MECHANISM_TYPE_PTR;
++
++
++/* CK_MECHANISM is a structure that specifies a particular
++ * mechanism  */
++typedef struct CK_MECHANISM {
++  CK_MECHANISM_TYPE mechanism;
++  CK_VOID_PTR       pParameter;
++
++  /* ulParameterLen was changed from CK_USHORT to CK_ULONG for
++   * v2.0 */
++  CK_ULONG          ulParameterLen;  /* in bytes */
++} CK_MECHANISM;
++
++typedef CK_MECHANISM CK_PTR CK_MECHANISM_PTR;
++
++
++/* CK_MECHANISM_INFO provides information about a particular
++ * mechanism */
++typedef struct CK_MECHANISM_INFO {
++    CK_ULONG    ulMinKeySize;
++    CK_ULONG    ulMaxKeySize;
++    CK_FLAGS    flags;
++} CK_MECHANISM_INFO;
++
++/* The flags are defined as follows:
++ *      Bit Flag               Mask        Meaning */
++#define CKF_HW                 0x00000001  /* performed by HW */
++
++/* The flags CKF_ENCRYPT, CKF_DECRYPT, CKF_DIGEST, CKF_SIGN,
++ * CKG_SIGN_RECOVER, CKF_VERIFY, CKF_VERIFY_RECOVER,
++ * CKF_GENERATE, CKF_GENERATE_KEY_PAIR, CKF_WRAP, CKF_UNWRAP,
++ * and CKF_DERIVE are new for v2.0.  They specify whether or not
++ * a mechanism can be used for a particular task */
++#define CKF_ENCRYPT            0x00000100
++#define CKF_DECRYPT            0x00000200
++#define CKF_DIGEST             0x00000400
++#define CKF_SIGN               0x00000800
++#define CKF_SIGN_RECOVER       0x00001000
++#define CKF_VERIFY             0x00002000
++#define CKF_VERIFY_RECOVER     0x00004000
++#define CKF_GENERATE           0x00008000
++#define CKF_GENERATE_KEY_PAIR  0x00010000
++#define CKF_WRAP               0x00020000
++#define CKF_UNWRAP             0x00040000
++#define CKF_DERIVE             0x00080000
++
++/* CKF_EC_F_P, CKF_EC_F_2M, CKF_EC_ECPARAMETERS, CKF_EC_NAMEDCURVE,
++ * CKF_EC_UNCOMPRESS, and CKF_EC_COMPRESS are new for v2.11. They
++ * describe a token's EC capabilities not available in mechanism
++ * information. */
++#define CKF_EC_F_P             0x00100000
++#define CKF_EC_F_2M            0x00200000
++#define CKF_EC_ECPARAMETERS    0x00400000
++#define CKF_EC_NAMEDCURVE      0x00800000
++#define CKF_EC_UNCOMPRESS      0x01000000
++#define CKF_EC_COMPRESS        0x02000000
++
++#define CKF_EXTENSION          0x80000000 /* FALSE for this version */
++
++typedef CK_MECHANISM_INFO CK_PTR CK_MECHANISM_INFO_PTR;
++
++
++/* CK_RV is a value that identifies the return value of a
++ * Cryptoki function */
++/* CK_RV was changed from CK_USHORT to CK_ULONG for v2.0 */
++typedef CK_ULONG          CK_RV;
++
++#define CKR_OK                                0x00000000
++#define CKR_CANCEL                            0x00000001
++#define CKR_HOST_MEMORY                       0x00000002
++#define CKR_SLOT_ID_INVALID                   0x00000003
++
++/* CKR_FLAGS_INVALID was removed for v2.0 */
++
++/* CKR_GENERAL_ERROR and CKR_FUNCTION_FAILED are new for v2.0 */
++#define CKR_GENERAL_ERROR                     0x00000005
++#define CKR_FUNCTION_FAILED                   0x00000006
++
++/* CKR_ARGUMENTS_BAD, CKR_NO_EVENT, CKR_NEED_TO_CREATE_THREADS,
++ * and CKR_CANT_LOCK are new for v2.01 */
++#define CKR_ARGUMENTS_BAD                     0x00000007
++#define CKR_NO_EVENT                          0x00000008
++#define CKR_NEED_TO_CREATE_THREADS            0x00000009
++#define CKR_CANT_LOCK                         0x0000000A
++
++#define CKR_ATTRIBUTE_READ_ONLY               0x00000010
++#define CKR_ATTRIBUTE_SENSITIVE               0x00000011
++#define CKR_ATTRIBUTE_TYPE_INVALID            0x00000012
++#define CKR_ATTRIBUTE_VALUE_INVALID           0x00000013
++#define CKR_DATA_INVALID                      0x00000020
++#define CKR_DATA_LEN_RANGE                    0x00000021
++#define CKR_DEVICE_ERROR                      0x00000030
++#define CKR_DEVICE_MEMORY                     0x00000031
++#define CKR_DEVICE_REMOVED                    0x00000032
++#define CKR_ENCRYPTED_DATA_INVALID            0x00000040
++#define CKR_ENCRYPTED_DATA_LEN_RANGE          0x00000041
++#define CKR_FUNCTION_CANCELED                 0x00000050
++#define CKR_FUNCTION_NOT_PARALLEL             0x00000051
++
++/* CKR_FUNCTION_NOT_SUPPORTED is new for v2.0 */
++#define CKR_FUNCTION_NOT_SUPPORTED            0x00000054
++
++#define CKR_KEY_HANDLE_INVALID                0x00000060
++
++/* CKR_KEY_SENSITIVE was removed for v2.0 */
++
++#define CKR_KEY_SIZE_RANGE                    0x00000062
++#define CKR_KEY_TYPE_INCONSISTENT             0x00000063
++
++/* CKR_KEY_NOT_NEEDED, CKR_KEY_CHANGED, CKR_KEY_NEEDED,
++ * CKR_KEY_INDIGESTIBLE, CKR_KEY_FUNCTION_NOT_PERMITTED,
++ * CKR_KEY_NOT_WRAPPABLE, and CKR_KEY_UNEXTRACTABLE are new for
++ * v2.0 */
++#define CKR_KEY_NOT_NEEDED                    0x00000064
++#define CKR_KEY_CHANGED                       0x00000065
++#define CKR_KEY_NEEDED                        0x00000066
++#define CKR_KEY_INDIGESTIBLE                  0x00000067
++#define CKR_KEY_FUNCTION_NOT_PERMITTED        0x00000068
++#define CKR_KEY_NOT_WRAPPABLE                 0x00000069
++#define CKR_KEY_UNEXTRACTABLE                 0x0000006A
++
++#define CKR_MECHANISM_INVALID                 0x00000070
++#define CKR_MECHANISM_PARAM_INVALID           0x00000071
++
++/* CKR_OBJECT_CLASS_INCONSISTENT and CKR_OBJECT_CLASS_INVALID
++ * were removed for v2.0 */
++#define CKR_OBJECT_HANDLE_INVALID             0x00000082
++#define CKR_OPERATION_ACTIVE                  0x00000090
++#define CKR_OPERATION_NOT_INITIALIZED         0x00000091
++#define CKR_PIN_INCORRECT                     0x000000A0
++#define CKR_PIN_INVALID                       0x000000A1
++#define CKR_PIN_LEN_RANGE                     0x000000A2
++
++/* CKR_PIN_EXPIRED and CKR_PIN_LOCKED are new for v2.0 */
++#define CKR_PIN_EXPIRED                       0x000000A3
++#define CKR_PIN_LOCKED                        0x000000A4
++
++#define CKR_SESSION_CLOSED                    0x000000B0
++#define CKR_SESSION_COUNT                     0x000000B1
++#define CKR_SESSION_HANDLE_INVALID            0x000000B3
++#define CKR_SESSION_PARALLEL_NOT_SUPPORTED    0x000000B4
++#define CKR_SESSION_READ_ONLY                 0x000000B5
++#define CKR_SESSION_EXISTS                    0x000000B6
++
++/* CKR_SESSION_READ_ONLY_EXISTS and
++ * CKR_SESSION_READ_WRITE_SO_EXISTS are new for v2.0 */
++#define CKR_SESSION_READ_ONLY_EXISTS          0x000000B7
++#define CKR_SESSION_READ_WRITE_SO_EXISTS      0x000000B8
++
++#define CKR_SIGNATURE_INVALID                 0x000000C0
++#define CKR_SIGNATURE_LEN_RANGE               0x000000C1
++#define CKR_TEMPLATE_INCOMPLETE               0x000000D0
++#define CKR_TEMPLATE_INCONSISTENT             0x000000D1
++#define CKR_TOKEN_NOT_PRESENT                 0x000000E0
++#define CKR_TOKEN_NOT_RECOGNIZED              0x000000E1
++#define CKR_TOKEN_WRITE_PROTECTED             0x000000E2
++#define CKR_UNWRAPPING_KEY_HANDLE_INVALID     0x000000F0
++#define CKR_UNWRAPPING_KEY_SIZE_RANGE         0x000000F1
++#define CKR_UNWRAPPING_KEY_TYPE_INCONSISTENT  0x000000F2
++#define CKR_USER_ALREADY_LOGGED_IN            0x00000100
++#define CKR_USER_NOT_LOGGED_IN                0x00000101
++#define CKR_USER_PIN_NOT_INITIALIZED          0x00000102
++#define CKR_USER_TYPE_INVALID                 0x00000103
++
++/* CKR_USER_ANOTHER_ALREADY_LOGGED_IN and CKR_USER_TOO_MANY_TYPES
++ * are new to v2.01 */
++#define CKR_USER_ANOTHER_ALREADY_LOGGED_IN    0x00000104
++#define CKR_USER_TOO_MANY_TYPES               0x00000105
++
++#define CKR_WRAPPED_KEY_INVALID               0x00000110
++#define CKR_WRAPPED_KEY_LEN_RANGE             0x00000112
++#define CKR_WRAPPING_KEY_HANDLE_INVALID       0x00000113
++#define CKR_WRAPPING_KEY_SIZE_RANGE           0x00000114
++#define CKR_WRAPPING_KEY_TYPE_INCONSISTENT    0x00000115
++#define CKR_RANDOM_SEED_NOT_SUPPORTED         0x00000120
++
++/* These are new to v2.0 */
++#define CKR_RANDOM_NO_RNG                     0x00000121
++
++/* These are new to v2.11 */
++#define CKR_DOMAIN_PARAMS_INVALID             0x00000130
++
++/* These are new to v2.0 */
++#define CKR_BUFFER_TOO_SMALL                  0x00000150
++#define CKR_SAVED_STATE_INVALID               0x00000160
++#define CKR_INFORMATION_SENSITIVE             0x00000170
++#define CKR_STATE_UNSAVEABLE                  0x00000180
++
++/* These are new to v2.01 */
++#define CKR_CRYPTOKI_NOT_INITIALIZED          0x00000190
++#define CKR_CRYPTOKI_ALREADY_INITIALIZED      0x00000191
++#define CKR_MUTEX_BAD                         0x000001A0
++#define CKR_MUTEX_NOT_LOCKED                  0x000001A1
++
++/* The following return values are new for PKCS #11 v2.20 amendment 3 */
++#define CKR_NEW_PIN_MODE                      0x000001B0
++#define CKR_NEXT_OTP                          0x000001B1
++
++/* This is new to v2.20 */
++#define CKR_FUNCTION_REJECTED                 0x00000200
++
++#define CKR_VENDOR_DEFINED                    0x80000000
++
++
++/* CK_NOTIFY is an application callback that processes events */
++typedef CK_CALLBACK_FUNCTION(CK_RV, CK_NOTIFY)(
++  CK_SESSION_HANDLE hSession,     /* the session's handle */
++  CK_NOTIFICATION   event,
++  CK_VOID_PTR       pApplication  /* passed to C_OpenSession */
++);
++
++
++/* CK_FUNCTION_LIST is a structure holding a Cryptoki spec
++ * version and pointers of appropriate types to all the
++ * Cryptoki functions */
++/* CK_FUNCTION_LIST is new for v2.0 */
++typedef struct CK_FUNCTION_LIST CK_FUNCTION_LIST;
++
++typedef CK_FUNCTION_LIST CK_PTR CK_FUNCTION_LIST_PTR;
++
++typedef CK_FUNCTION_LIST_PTR CK_PTR CK_FUNCTION_LIST_PTR_PTR;
++
++
++/* CK_CREATEMUTEX is an application callback for creating a
++ * mutex object */
++typedef CK_CALLBACK_FUNCTION(CK_RV, CK_CREATEMUTEX)(
++  CK_VOID_PTR_PTR ppMutex  /* location to receive ptr to mutex */
++);
++
++
++/* CK_DESTROYMUTEX is an application callback for destroying a
++ * mutex object */
++typedef CK_CALLBACK_FUNCTION(CK_RV, CK_DESTROYMUTEX)(
++  CK_VOID_PTR pMutex  /* pointer to mutex */
++);
++
++
++/* CK_LOCKMUTEX is an application callback for locking a mutex */
++typedef CK_CALLBACK_FUNCTION(CK_RV, CK_LOCKMUTEX)(
++  CK_VOID_PTR pMutex  /* pointer to mutex */
++);
++
++
++/* CK_UNLOCKMUTEX is an application callback for unlocking a
++ * mutex */
++typedef CK_CALLBACK_FUNCTION(CK_RV, CK_UNLOCKMUTEX)(
++  CK_VOID_PTR pMutex  /* pointer to mutex */
++);
++
++
++/* CK_C_INITIALIZE_ARGS provides the optional arguments to
++ * C_Initialize */
++typedef struct CK_C_INITIALIZE_ARGS {
++  CK_CREATEMUTEX CreateMutex;
++  CK_DESTROYMUTEX DestroyMutex;
++  CK_LOCKMUTEX LockMutex;
++  CK_UNLOCKMUTEX UnlockMutex;
++  CK_FLAGS flags;
++  CK_VOID_PTR pReserved;
++} CK_C_INITIALIZE_ARGS;
++
++/* flags: bit flags that provide capabilities of the slot
++ *      Bit Flag                           Mask       Meaning
++ */
++#define CKF_LIBRARY_CANT_CREATE_OS_THREADS 0x00000001
++#define CKF_OS_LOCKING_OK                  0x00000002
++
++typedef CK_C_INITIALIZE_ARGS CK_PTR CK_C_INITIALIZE_ARGS_PTR;
++
++
++/* additional flags for parameters to functions */
++
++/* CKF_DONT_BLOCK is for the function C_WaitForSlotEvent */
++#define CKF_DONT_BLOCK     1
++
++/* CK_RSA_PKCS_OAEP_MGF_TYPE is new for v2.10.
++ * CK_RSA_PKCS_OAEP_MGF_TYPE  is used to indicate the Message
++ * Generation Function (MGF) applied to a message block when
++ * formatting a message block for the PKCS #1 OAEP encryption
++ * scheme. */
++typedef CK_ULONG CK_RSA_PKCS_MGF_TYPE;
++
++typedef CK_RSA_PKCS_MGF_TYPE CK_PTR CK_RSA_PKCS_MGF_TYPE_PTR;
++
++/* The following MGFs are defined */
++/* CKG_MGF1_SHA256, CKG_MGF1_SHA384, and CKG_MGF1_SHA512
++ * are new for v2.20 */
++#define CKG_MGF1_SHA1         0x00000001
++#define CKG_MGF1_SHA256       0x00000002
++#define CKG_MGF1_SHA384       0x00000003
++#define CKG_MGF1_SHA512       0x00000004
++/* SHA-224 is new for PKCS #11 v2.20 amendment 3 */
++#define CKG_MGF1_SHA224       0x00000005
++
++/* CK_RSA_PKCS_OAEP_SOURCE_TYPE is new for v2.10.
++ * CK_RSA_PKCS_OAEP_SOURCE_TYPE  is used to indicate the source
++ * of the encoding parameter when formatting a message block
++ * for the PKCS #1 OAEP encryption scheme. */
++typedef CK_ULONG CK_RSA_PKCS_OAEP_SOURCE_TYPE;
++
++typedef CK_RSA_PKCS_OAEP_SOURCE_TYPE CK_PTR CK_RSA_PKCS_OAEP_SOURCE_TYPE_PTR;
++
++/* The following encoding parameter sources are defined */
++#define CKZ_DATA_SPECIFIED    0x00000001
++
++/* CK_RSA_PKCS_OAEP_PARAMS is new for v2.10.
++ * CK_RSA_PKCS_OAEP_PARAMS provides the parameters to the
++ * CKM_RSA_PKCS_OAEP mechanism. */
++typedef struct CK_RSA_PKCS_OAEP_PARAMS {
++        CK_MECHANISM_TYPE hashAlg;
++        CK_RSA_PKCS_MGF_TYPE mgf;
++        CK_RSA_PKCS_OAEP_SOURCE_TYPE source;
++        CK_VOID_PTR pSourceData;
++        CK_ULONG ulSourceDataLen;
++} CK_RSA_PKCS_OAEP_PARAMS;
++
++typedef CK_RSA_PKCS_OAEP_PARAMS CK_PTR CK_RSA_PKCS_OAEP_PARAMS_PTR;
++
++/* CK_RSA_PKCS_PSS_PARAMS is new for v2.11.
++ * CK_RSA_PKCS_PSS_PARAMS provides the parameters to the
++ * CKM_RSA_PKCS_PSS mechanism(s). */
++typedef struct CK_RSA_PKCS_PSS_PARAMS {
++        CK_MECHANISM_TYPE    hashAlg;
++        CK_RSA_PKCS_MGF_TYPE mgf;
++        CK_ULONG             sLen;
++} CK_RSA_PKCS_PSS_PARAMS;
++
++typedef CK_RSA_PKCS_PSS_PARAMS CK_PTR CK_RSA_PKCS_PSS_PARAMS_PTR;
++
++/* CK_EC_KDF_TYPE is new for v2.11. */
++typedef CK_ULONG CK_EC_KDF_TYPE;
++
++/* The following EC Key Derivation Functions are defined */
++#define CKD_NULL                 0x00000001
++#define CKD_SHA1_KDF             0x00000002
++
++/* CK_ECDH1_DERIVE_PARAMS is new for v2.11.
++ * CK_ECDH1_DERIVE_PARAMS provides the parameters to the
++ * CKM_ECDH1_DERIVE and CKM_ECDH1_COFACTOR_DERIVE mechanisms,
++ * where each party contributes one key pair.
++ */
++typedef struct CK_ECDH1_DERIVE_PARAMS {
++  CK_EC_KDF_TYPE kdf;
++  CK_ULONG ulSharedDataLen;
++  CK_BYTE_PTR pSharedData;
++  CK_ULONG ulPublicDataLen;
++  CK_BYTE_PTR pPublicData;
++} CK_ECDH1_DERIVE_PARAMS;
++
++typedef CK_ECDH1_DERIVE_PARAMS CK_PTR CK_ECDH1_DERIVE_PARAMS_PTR;
++
++
++/* CK_ECDH2_DERIVE_PARAMS is new for v2.11.
++ * CK_ECDH2_DERIVE_PARAMS provides the parameters to the
++ * CKM_ECMQV_DERIVE mechanism, where each party contributes two key pairs. */
++typedef struct CK_ECDH2_DERIVE_PARAMS {
++  CK_EC_KDF_TYPE kdf;
++  CK_ULONG ulSharedDataLen;
++  CK_BYTE_PTR pSharedData;
++  CK_ULONG ulPublicDataLen;
++  CK_BYTE_PTR pPublicData;
++  CK_ULONG ulPrivateDataLen;
++  CK_OBJECT_HANDLE hPrivateData;
++  CK_ULONG ulPublicDataLen2;
++  CK_BYTE_PTR pPublicData2;
++} CK_ECDH2_DERIVE_PARAMS;
++
++typedef CK_ECDH2_DERIVE_PARAMS CK_PTR CK_ECDH2_DERIVE_PARAMS_PTR;
++
++typedef struct CK_ECMQV_DERIVE_PARAMS {
++  CK_EC_KDF_TYPE kdf;
++  CK_ULONG ulSharedDataLen;
++  CK_BYTE_PTR pSharedData;
++  CK_ULONG ulPublicDataLen;
++  CK_BYTE_PTR pPublicData;
++  CK_ULONG ulPrivateDataLen;
++  CK_OBJECT_HANDLE hPrivateData;
++  CK_ULONG ulPublicDataLen2;
++  CK_BYTE_PTR pPublicData2;
++  CK_OBJECT_HANDLE publicKey;
++} CK_ECMQV_DERIVE_PARAMS;
++
++typedef CK_ECMQV_DERIVE_PARAMS CK_PTR CK_ECMQV_DERIVE_PARAMS_PTR;
++
++/* Typedefs and defines for the CKM_X9_42_DH_KEY_PAIR_GEN and the
++ * CKM_X9_42_DH_PARAMETER_GEN mechanisms (new for PKCS #11 v2.11) */
++typedef CK_ULONG CK_X9_42_DH_KDF_TYPE;
++typedef CK_X9_42_DH_KDF_TYPE CK_PTR CK_X9_42_DH_KDF_TYPE_PTR;
++
++/* The following X9.42 DH key derivation functions are defined
++   (besides CKD_NULL already defined : */
++#define CKD_SHA1_KDF_ASN1        0x00000003
++#define CKD_SHA1_KDF_CONCATENATE 0x00000004
++
++/* CK_X9_42_DH1_DERIVE_PARAMS is new for v2.11.
++ * CK_X9_42_DH1_DERIVE_PARAMS provides the parameters to the
++ * CKM_X9_42_DH_DERIVE key derivation mechanism, where each party
++ * contributes one key pair */
++typedef struct CK_X9_42_DH1_DERIVE_PARAMS {
++  CK_X9_42_DH_KDF_TYPE kdf;
++  CK_ULONG ulOtherInfoLen;
++  CK_BYTE_PTR pOtherInfo;
++  CK_ULONG ulPublicDataLen;
++  CK_BYTE_PTR pPublicData;
++} CK_X9_42_DH1_DERIVE_PARAMS;
++
++typedef struct CK_X9_42_DH1_DERIVE_PARAMS CK_PTR CK_X9_42_DH1_DERIVE_PARAMS_PTR;
++
++/* CK_X9_42_DH2_DERIVE_PARAMS is new for v2.11.
++ * CK_X9_42_DH2_DERIVE_PARAMS provides the parameters to the
++ * CKM_X9_42_DH_HYBRID_DERIVE and CKM_X9_42_MQV_DERIVE key derivation
++ * mechanisms, where each party contributes two key pairs */
++typedef struct CK_X9_42_DH2_DERIVE_PARAMS {
++  CK_X9_42_DH_KDF_TYPE kdf;
++  CK_ULONG ulOtherInfoLen;
++  CK_BYTE_PTR pOtherInfo;
++  CK_ULONG ulPublicDataLen;
++  CK_BYTE_PTR pPublicData;
++  CK_ULONG ulPrivateDataLen;
++  CK_OBJECT_HANDLE hPrivateData;
++  CK_ULONG ulPublicDataLen2;
++  CK_BYTE_PTR pPublicData2;
++} CK_X9_42_DH2_DERIVE_PARAMS;
++
++typedef CK_X9_42_DH2_DERIVE_PARAMS CK_PTR CK_X9_42_DH2_DERIVE_PARAMS_PTR;
++
++typedef struct CK_X9_42_MQV_DERIVE_PARAMS {
++  CK_X9_42_DH_KDF_TYPE kdf;
++  CK_ULONG ulOtherInfoLen;
++  CK_BYTE_PTR pOtherInfo;
++  CK_ULONG ulPublicDataLen;
++  CK_BYTE_PTR pPublicData;
++  CK_ULONG ulPrivateDataLen;
++  CK_OBJECT_HANDLE hPrivateData;
++  CK_ULONG ulPublicDataLen2;
++  CK_BYTE_PTR pPublicData2;
++  CK_OBJECT_HANDLE publicKey;
++} CK_X9_42_MQV_DERIVE_PARAMS;
++
++typedef CK_X9_42_MQV_DERIVE_PARAMS CK_PTR CK_X9_42_MQV_DERIVE_PARAMS_PTR;
++
++/* CK_KEA_DERIVE_PARAMS provides the parameters to the
++ * CKM_KEA_DERIVE mechanism */
++/* CK_KEA_DERIVE_PARAMS is new for v2.0 */
++typedef struct CK_KEA_DERIVE_PARAMS {
++  CK_BBOOL      isSender;
++  CK_ULONG      ulRandomLen;
++  CK_BYTE_PTR   pRandomA;
++  CK_BYTE_PTR   pRandomB;
++  CK_ULONG      ulPublicDataLen;
++  CK_BYTE_PTR   pPublicData;
++} CK_KEA_DERIVE_PARAMS;
++
++typedef CK_KEA_DERIVE_PARAMS CK_PTR CK_KEA_DERIVE_PARAMS_PTR;
++
++
++/* CK_RC2_PARAMS provides the parameters to the CKM_RC2_ECB and
++ * CKM_RC2_MAC mechanisms.  An instance of CK_RC2_PARAMS just
++ * holds the effective keysize */
++typedef CK_ULONG          CK_RC2_PARAMS;
++
++typedef CK_RC2_PARAMS CK_PTR CK_RC2_PARAMS_PTR;
++
++
++/* CK_RC2_CBC_PARAMS provides the parameters to the CKM_RC2_CBC
++ * mechanism */
++typedef struct CK_RC2_CBC_PARAMS {
++  /* ulEffectiveBits was changed from CK_USHORT to CK_ULONG for
++   * v2.0 */
++  CK_ULONG      ulEffectiveBits;  /* effective bits (1-1024) */
++
++  CK_BYTE       iv[8];            /* IV for CBC mode */
++} CK_RC2_CBC_PARAMS;
++
++typedef CK_RC2_CBC_PARAMS CK_PTR CK_RC2_CBC_PARAMS_PTR;
++
++
++/* CK_RC2_MAC_GENERAL_PARAMS provides the parameters for the
++ * CKM_RC2_MAC_GENERAL mechanism */
++/* CK_RC2_MAC_GENERAL_PARAMS is new for v2.0 */
++typedef struct CK_RC2_MAC_GENERAL_PARAMS {
++  CK_ULONG      ulEffectiveBits;  /* effective bits (1-1024) */
++  CK_ULONG      ulMacLength;      /* Length of MAC in bytes */
++} CK_RC2_MAC_GENERAL_PARAMS;
++
++typedef CK_RC2_MAC_GENERAL_PARAMS CK_PTR \
++  CK_RC2_MAC_GENERAL_PARAMS_PTR;
++
++
++/* CK_RC5_PARAMS provides the parameters to the CKM_RC5_ECB and
++ * CKM_RC5_MAC mechanisms */
++/* CK_RC5_PARAMS is new for v2.0 */
++typedef struct CK_RC5_PARAMS {
++  CK_ULONG      ulWordsize;  /* wordsize in bits */
++  CK_ULONG      ulRounds;    /* number of rounds */
++} CK_RC5_PARAMS;
++
++typedef CK_RC5_PARAMS CK_PTR CK_RC5_PARAMS_PTR;
++
++
++/* CK_RC5_CBC_PARAMS provides the parameters to the CKM_RC5_CBC
++ * mechanism */
++/* CK_RC5_CBC_PARAMS is new for v2.0 */
++typedef struct CK_RC5_CBC_PARAMS {
++  CK_ULONG      ulWordsize;  /* wordsize in bits */
++  CK_ULONG      ulRounds;    /* number of rounds */
++  CK_BYTE_PTR   pIv;         /* pointer to IV */
++  CK_ULONG      ulIvLen;     /* length of IV in bytes */
++} CK_RC5_CBC_PARAMS;
++
++typedef CK_RC5_CBC_PARAMS CK_PTR CK_RC5_CBC_PARAMS_PTR;
++
++
++/* CK_RC5_MAC_GENERAL_PARAMS provides the parameters for the
++ * CKM_RC5_MAC_GENERAL mechanism */
++/* CK_RC5_MAC_GENERAL_PARAMS is new for v2.0 */
++typedef struct CK_RC5_MAC_GENERAL_PARAMS {
++  CK_ULONG      ulWordsize;   /* wordsize in bits */
++  CK_ULONG      ulRounds;     /* number of rounds */
++  CK_ULONG      ulMacLength;  /* Length of MAC in bytes */
++} CK_RC5_MAC_GENERAL_PARAMS;
++
++typedef CK_RC5_MAC_GENERAL_PARAMS CK_PTR \
++  CK_RC5_MAC_GENERAL_PARAMS_PTR;
++
++
++/* CK_MAC_GENERAL_PARAMS provides the parameters to most block
++ * ciphers' MAC_GENERAL mechanisms.  Its value is the length of
++ * the MAC */
++/* CK_MAC_GENERAL_PARAMS is new for v2.0 */
++typedef CK_ULONG          CK_MAC_GENERAL_PARAMS;
++
++typedef CK_MAC_GENERAL_PARAMS CK_PTR CK_MAC_GENERAL_PARAMS_PTR;
++
++/* CK_DES/AES_ECB/CBC_ENCRYPT_DATA_PARAMS are new for v2.20 */
++typedef struct CK_DES_CBC_ENCRYPT_DATA_PARAMS {
++  CK_BYTE      iv[8];
++  CK_BYTE_PTR  pData;
++  CK_ULONG     length;
++} CK_DES_CBC_ENCRYPT_DATA_PARAMS;
++
++typedef CK_DES_CBC_ENCRYPT_DATA_PARAMS CK_PTR CK_DES_CBC_ENCRYPT_DATA_PARAMS_PTR;
++
++typedef struct CK_AES_CBC_ENCRYPT_DATA_PARAMS {
++  CK_BYTE      iv[16];
++  CK_BYTE_PTR  pData;
++  CK_ULONG     length;
++} CK_AES_CBC_ENCRYPT_DATA_PARAMS;
++
++typedef CK_AES_CBC_ENCRYPT_DATA_PARAMS CK_PTR CK_AES_CBC_ENCRYPT_DATA_PARAMS_PTR;
++
++/* CK_SKIPJACK_PRIVATE_WRAP_PARAMS provides the parameters to the
++ * CKM_SKIPJACK_PRIVATE_WRAP mechanism */
++/* CK_SKIPJACK_PRIVATE_WRAP_PARAMS is new for v2.0 */
++typedef struct CK_SKIPJACK_PRIVATE_WRAP_PARAMS {
++  CK_ULONG      ulPasswordLen;
++  CK_BYTE_PTR   pPassword;
++  CK_ULONG      ulPublicDataLen;
++  CK_BYTE_PTR   pPublicData;
++  CK_ULONG      ulPAndGLen;
++  CK_ULONG      ulQLen;
++  CK_ULONG      ulRandomLen;
++  CK_BYTE_PTR   pRandomA;
++  CK_BYTE_PTR   pPrimeP;
++  CK_BYTE_PTR   pBaseG;
++  CK_BYTE_PTR   pSubprimeQ;
++} CK_SKIPJACK_PRIVATE_WRAP_PARAMS;
++
++typedef CK_SKIPJACK_PRIVATE_WRAP_PARAMS CK_PTR \
++  CK_SKIPJACK_PRIVATE_WRAP_PTR;
++
++
++/* CK_SKIPJACK_RELAYX_PARAMS provides the parameters to the
++ * CKM_SKIPJACK_RELAYX mechanism */
++/* CK_SKIPJACK_RELAYX_PARAMS is new for v2.0 */
++typedef struct CK_SKIPJACK_RELAYX_PARAMS {
++  CK_ULONG      ulOldWrappedXLen;
++  CK_BYTE_PTR   pOldWrappedX;
++  CK_ULONG      ulOldPasswordLen;
++  CK_BYTE_PTR   pOldPassword;
++  CK_ULONG      ulOldPublicDataLen;
++  CK_BYTE_PTR   pOldPublicData;
++  CK_ULONG      ulOldRandomLen;
++  CK_BYTE_PTR   pOldRandomA;
++  CK_ULONG      ulNewPasswordLen;
++  CK_BYTE_PTR   pNewPassword;
++  CK_ULONG      ulNewPublicDataLen;
++  CK_BYTE_PTR   pNewPublicData;
++  CK_ULONG      ulNewRandomLen;
++  CK_BYTE_PTR   pNewRandomA;
++} CK_SKIPJACK_RELAYX_PARAMS;
++
++typedef CK_SKIPJACK_RELAYX_PARAMS CK_PTR \
++  CK_SKIPJACK_RELAYX_PARAMS_PTR;
++
++
++typedef struct CK_PBE_PARAMS {
++  CK_BYTE_PTR      pInitVector;
++  CK_UTF8CHAR_PTR  pPassword;
++  CK_ULONG         ulPasswordLen;
++  CK_BYTE_PTR      pSalt;
++  CK_ULONG         ulSaltLen;
++  CK_ULONG         ulIteration;
++} CK_PBE_PARAMS;
++
++typedef CK_PBE_PARAMS CK_PTR CK_PBE_PARAMS_PTR;
++
++
++/* CK_KEY_WRAP_SET_OAEP_PARAMS provides the parameters to the
++ * CKM_KEY_WRAP_SET_OAEP mechanism */
++/* CK_KEY_WRAP_SET_OAEP_PARAMS is new for v2.0 */
++typedef struct CK_KEY_WRAP_SET_OAEP_PARAMS {
++  CK_BYTE       bBC;     /* block contents byte */
++  CK_BYTE_PTR   pX;      /* extra data */
++  CK_ULONG      ulXLen;  /* length of extra data in bytes */
++} CK_KEY_WRAP_SET_OAEP_PARAMS;
++
++typedef CK_KEY_WRAP_SET_OAEP_PARAMS CK_PTR \
++  CK_KEY_WRAP_SET_OAEP_PARAMS_PTR;
++
++
++typedef struct CK_SSL3_RANDOM_DATA {
++  CK_BYTE_PTR  pClientRandom;
++  CK_ULONG     ulClientRandomLen;
++  CK_BYTE_PTR  pServerRandom;
++  CK_ULONG     ulServerRandomLen;
++} CK_SSL3_RANDOM_DATA;
++
++
++typedef struct CK_SSL3_MASTER_KEY_DERIVE_PARAMS {
++  CK_SSL3_RANDOM_DATA RandomInfo;
++  CK_VERSION_PTR pVersion;
++} CK_SSL3_MASTER_KEY_DERIVE_PARAMS;
++
++typedef struct CK_SSL3_MASTER_KEY_DERIVE_PARAMS CK_PTR \
++  CK_SSL3_MASTER_KEY_DERIVE_PARAMS_PTR;
++
++
++typedef struct CK_SSL3_KEY_MAT_OUT {
++  CK_OBJECT_HANDLE hClientMacSecret;
++  CK_OBJECT_HANDLE hServerMacSecret;
++  CK_OBJECT_HANDLE hClientKey;
++  CK_OBJECT_HANDLE hServerKey;
++  CK_BYTE_PTR      pIVClient;
++  CK_BYTE_PTR      pIVServer;
++} CK_SSL3_KEY_MAT_OUT;
++
++typedef CK_SSL3_KEY_MAT_OUT CK_PTR CK_SSL3_KEY_MAT_OUT_PTR;
++
++
++typedef struct CK_SSL3_KEY_MAT_PARAMS {
++  CK_ULONG                ulMacSizeInBits;
++  CK_ULONG                ulKeySizeInBits;
++  CK_ULONG                ulIVSizeInBits;
++  CK_BBOOL                bIsExport;
++  CK_SSL3_RANDOM_DATA     RandomInfo;
++  CK_SSL3_KEY_MAT_OUT_PTR pReturnedKeyMaterial;
++} CK_SSL3_KEY_MAT_PARAMS;
++
++typedef CK_SSL3_KEY_MAT_PARAMS CK_PTR CK_SSL3_KEY_MAT_PARAMS_PTR;
++
++/* CK_TLS_PRF_PARAMS is new for version 2.20 */
++typedef struct CK_TLS_PRF_PARAMS {
++  CK_BYTE_PTR  pSeed;
++  CK_ULONG     ulSeedLen;
++  CK_BYTE_PTR  pLabel;
++  CK_ULONG     ulLabelLen;
++  CK_BYTE_PTR  pOutput;
++  CK_ULONG_PTR pulOutputLen;
++} CK_TLS_PRF_PARAMS;
++
++typedef CK_TLS_PRF_PARAMS CK_PTR CK_TLS_PRF_PARAMS_PTR;
++
++/* WTLS is new for version 2.20 */
++typedef struct CK_WTLS_RANDOM_DATA {
++  CK_BYTE_PTR pClientRandom;
++  CK_ULONG    ulClientRandomLen;
++  CK_BYTE_PTR pServerRandom;
++  CK_ULONG    ulServerRandomLen;
++} CK_WTLS_RANDOM_DATA;
++
++typedef CK_WTLS_RANDOM_DATA CK_PTR CK_WTLS_RANDOM_DATA_PTR;
++
++typedef struct CK_WTLS_MASTER_KEY_DERIVE_PARAMS {
++  CK_MECHANISM_TYPE   DigestMechanism;
++  CK_WTLS_RANDOM_DATA RandomInfo;
++  CK_BYTE_PTR         pVersion;
++} CK_WTLS_MASTER_KEY_DERIVE_PARAMS;
++
++typedef CK_WTLS_MASTER_KEY_DERIVE_PARAMS CK_PTR \
++  CK_WTLS_MASTER_KEY_DERIVE_PARAMS_PTR;
++
++typedef struct CK_WTLS_PRF_PARAMS {
++  CK_MECHANISM_TYPE DigestMechanism;
++  CK_BYTE_PTR       pSeed;
++  CK_ULONG          ulSeedLen;
++  CK_BYTE_PTR       pLabel;
++  CK_ULONG          ulLabelLen;
++  CK_BYTE_PTR       pOutput;
++  CK_ULONG_PTR      pulOutputLen;
++} CK_WTLS_PRF_PARAMS;
++
++typedef CK_WTLS_PRF_PARAMS CK_PTR CK_WTLS_PRF_PARAMS_PTR;
++
++typedef struct CK_WTLS_KEY_MAT_OUT {
++  CK_OBJECT_HANDLE hMacSecret;
++  CK_OBJECT_HANDLE hKey;
++  CK_BYTE_PTR      pIV;
++} CK_WTLS_KEY_MAT_OUT;
++
++typedef CK_WTLS_KEY_MAT_OUT CK_PTR CK_WTLS_KEY_MAT_OUT_PTR;
++
++typedef struct CK_WTLS_KEY_MAT_PARAMS {
++  CK_MECHANISM_TYPE       DigestMechanism;
++  CK_ULONG                ulMacSizeInBits;
++  CK_ULONG                ulKeySizeInBits;
++  CK_ULONG                ulIVSizeInBits;
++  CK_ULONG                ulSequenceNumber;
++  CK_BBOOL                bIsExport;
++  CK_WTLS_RANDOM_DATA     RandomInfo;
++  CK_WTLS_KEY_MAT_OUT_PTR pReturnedKeyMaterial;
++} CK_WTLS_KEY_MAT_PARAMS;
++
++typedef CK_WTLS_KEY_MAT_PARAMS CK_PTR CK_WTLS_KEY_MAT_PARAMS_PTR;
++
++/* CMS is new for version 2.20 */
++typedef struct CK_CMS_SIG_PARAMS {
++  CK_OBJECT_HANDLE      certificateHandle;
++  CK_MECHANISM_PTR      pSigningMechanism;
++  CK_MECHANISM_PTR      pDigestMechanism;
++  CK_UTF8CHAR_PTR       pContentType;
++  CK_BYTE_PTR           pRequestedAttributes;
++  CK_ULONG              ulRequestedAttributesLen;
++  CK_BYTE_PTR           pRequiredAttributes;
++  CK_ULONG              ulRequiredAttributesLen;
++} CK_CMS_SIG_PARAMS;
++
++typedef CK_CMS_SIG_PARAMS CK_PTR CK_CMS_SIG_PARAMS_PTR;
++
++typedef struct CK_KEY_DERIVATION_STRING_DATA {
++  CK_BYTE_PTR pData;
++  CK_ULONG    ulLen;
++} CK_KEY_DERIVATION_STRING_DATA;
++
++typedef CK_KEY_DERIVATION_STRING_DATA CK_PTR \
++  CK_KEY_DERIVATION_STRING_DATA_PTR;
++
++
++/* The CK_EXTRACT_PARAMS is used for the
++ * CKM_EXTRACT_KEY_FROM_KEY mechanism.  It specifies which bit
++ * of the base key should be used as the first bit of the
++ * derived key */
++/* CK_EXTRACT_PARAMS is new for v2.0 */
++typedef CK_ULONG CK_EXTRACT_PARAMS;
++
++typedef CK_EXTRACT_PARAMS CK_PTR CK_EXTRACT_PARAMS_PTR;
++
++/* CK_PKCS5_PBKD2_PSEUDO_RANDOM_FUNCTION_TYPE is new for v2.10.
++ * CK_PKCS5_PBKD2_PSEUDO_RANDOM_FUNCTION_TYPE is used to
++ * indicate the Pseudo-Random Function (PRF) used to generate
++ * key bits using PKCS #5 PBKDF2. */
++typedef CK_ULONG CK_PKCS5_PBKD2_PSEUDO_RANDOM_FUNCTION_TYPE;
++
++typedef CK_PKCS5_PBKD2_PSEUDO_RANDOM_FUNCTION_TYPE CK_PTR CK_PKCS5_PBKD2_PSEUDO_RANDOM_FUNCTION_TYPE_PTR;
++
++/* The following PRFs are defined in PKCS #5 v2.0. */
++#define CKP_PKCS5_PBKD2_HMAC_SHA1 0x00000001
++
++
++/* CK_PKCS5_PBKDF2_SALT_SOURCE_TYPE is new for v2.10.
++ * CK_PKCS5_PBKDF2_SALT_SOURCE_TYPE is used to indicate the
++ * source of the salt value when deriving a key using PKCS #5
++ * PBKDF2. */
++typedef CK_ULONG CK_PKCS5_PBKDF2_SALT_SOURCE_TYPE;
++
++typedef CK_PKCS5_PBKDF2_SALT_SOURCE_TYPE CK_PTR CK_PKCS5_PBKDF2_SALT_SOURCE_TYPE_PTR;
++
++/* The following salt value sources are defined in PKCS #5 v2.0. */
++#define CKZ_SALT_SPECIFIED        0x00000001
++
++/* CK_PKCS5_PBKD2_PARAMS is new for v2.10.
++ * CK_PKCS5_PBKD2_PARAMS is a structure that provides the
++ * parameters to the CKM_PKCS5_PBKD2 mechanism. */
++typedef struct CK_PKCS5_PBKD2_PARAMS {
++        CK_PKCS5_PBKDF2_SALT_SOURCE_TYPE           saltSource;
++        CK_VOID_PTR                                pSaltSourceData;
++        CK_ULONG                                   ulSaltSourceDataLen;
++        CK_ULONG                                   iterations;
++        CK_PKCS5_PBKD2_PSEUDO_RANDOM_FUNCTION_TYPE prf;
++        CK_VOID_PTR                                pPrfData;
++        CK_ULONG                                   ulPrfDataLen;
++        CK_UTF8CHAR_PTR                            pPassword;
++        CK_ULONG_PTR                               ulPasswordLen;
++} CK_PKCS5_PBKD2_PARAMS;
++
++typedef CK_PKCS5_PBKD2_PARAMS CK_PTR CK_PKCS5_PBKD2_PARAMS_PTR;
++
++/* All CK_OTP structs are new for PKCS #11 v2.20 amendment 3 */
++
++typedef CK_ULONG CK_OTP_PARAM_TYPE;
++typedef CK_OTP_PARAM_TYPE CK_PARAM_TYPE; /* B/w compatibility */
++
++typedef struct CK_OTP_PARAM {
++    CK_OTP_PARAM_TYPE type;
++    CK_VOID_PTR pValue;
++    CK_ULONG ulValueLen;
++} CK_OTP_PARAM;
++
++typedef CK_OTP_PARAM CK_PTR CK_OTP_PARAM_PTR;
++
++typedef struct CK_OTP_PARAMS {
++    CK_OTP_PARAM_PTR pParams;
++    CK_ULONG ulCount;
++} CK_OTP_PARAMS;
++
++typedef CK_OTP_PARAMS CK_PTR CK_OTP_PARAMS_PTR;
++
++typedef struct CK_OTP_SIGNATURE_INFO {
++    CK_OTP_PARAM_PTR pParams;
++    CK_ULONG ulCount;
++} CK_OTP_SIGNATURE_INFO;
++
++typedef CK_OTP_SIGNATURE_INFO CK_PTR CK_OTP_SIGNATURE_INFO_PTR;
++
++/* The following OTP-related defines are new for PKCS #11 v2.20 amendment 1 */
++#define CK_OTP_VALUE          0
++#define CK_OTP_PIN            1
++#define CK_OTP_CHALLENGE      2
++#define CK_OTP_TIME           3
++#define CK_OTP_COUNTER        4
++#define CK_OTP_FLAGS          5
++#define CK_OTP_OUTPUT_LENGTH  6
++#define CK_OTP_OUTPUT_FORMAT  7
++
++/* The following OTP-related defines are new for PKCS #11 v2.20 amendment 1 */
++#define CKF_NEXT_OTP          0x00000001
++#define CKF_EXCLUDE_TIME      0x00000002
++#define CKF_EXCLUDE_COUNTER   0x00000004
++#define CKF_EXCLUDE_CHALLENGE 0x00000008
++#define CKF_EXCLUDE_PIN       0x00000010
++#define CKF_USER_FRIENDLY_OTP 0x00000020
++
++/* CK_KIP_PARAMS is new for PKCS #11 v2.20 amendment 2 */
++typedef struct CK_KIP_PARAMS {
++    CK_MECHANISM_PTR  pMechanism;
++    CK_OBJECT_HANDLE  hKey;
++    CK_BYTE_PTR       pSeed;
++    CK_ULONG          ulSeedLen;
++} CK_KIP_PARAMS;
++
++typedef CK_KIP_PARAMS CK_PTR CK_KIP_PARAMS_PTR;
++
++/* CK_AES_CTR_PARAMS is new for PKCS #11 v2.20 amendment 3 */
++typedef struct CK_AES_CTR_PARAMS {
++    CK_ULONG ulCounterBits;
++    CK_BYTE cb[16];
++} CK_AES_CTR_PARAMS;
++
++typedef CK_AES_CTR_PARAMS CK_PTR CK_AES_CTR_PARAMS_PTR;
++
++/* CK_CAMELLIA_CTR_PARAMS is new for PKCS #11 v2.20 amendment 3 */
++typedef struct CK_CAMELLIA_CTR_PARAMS {
++    CK_ULONG ulCounterBits;
++    CK_BYTE cb[16];
++} CK_CAMELLIA_CTR_PARAMS;
++
++typedef CK_CAMELLIA_CTR_PARAMS CK_PTR CK_CAMELLIA_CTR_PARAMS_PTR;
++
++/* CK_CAMELLIA_CBC_ENCRYPT_DATA_PARAMS is new for PKCS #11 v2.20 amendment 3 */
++typedef struct CK_CAMELLIA_CBC_ENCRYPT_DATA_PARAMS {
++    CK_BYTE      iv[16];
++    CK_BYTE_PTR  pData;
++    CK_ULONG     length;
++} CK_CAMELLIA_CBC_ENCRYPT_DATA_PARAMS;
++
++typedef CK_CAMELLIA_CBC_ENCRYPT_DATA_PARAMS CK_PTR CK_CAMELLIA_CBC_ENCRYPT_DATA_PARAMS_PTR;
++
++/* CK_ARIA_CBC_ENCRYPT_DATA_PARAMS is new for PKCS #11 v2.20 amendment 3 */
++typedef struct CK_ARIA_CBC_ENCRYPT_DATA_PARAMS {
++    CK_BYTE      iv[16];
++    CK_BYTE_PTR  pData;
++    CK_ULONG     length;
++} CK_ARIA_CBC_ENCRYPT_DATA_PARAMS;
++
++typedef CK_ARIA_CBC_ENCRYPT_DATA_PARAMS CK_PTR CK_ARIA_CBC_ENCRYPT_DATA_PARAMS_PTR;
++
++#endif
+Index: openssl/test/clean_test.com
+diff -u openssl/test/clean_test.com:1.1.2.1 openssl/test/clean_test.com:removed
+--- openssl/test/clean_test.com:1.1.2.1	Sun Jan 15 16:09:50 2012
++++ openssl/test/clean_test.com	Mon Jan 16 18:54:23 2012
+@@ -1,35 +0,0 @@
+-$!
+-$! Delete various test results files.
+-$!
+-$ def_orig = f$environment( "default")
+-$ proc = f$environment( "procedure")
+-$ proc_dev_dir = f$parse( "A.;", proc) - "A.;"
+-$!
+-$ on control_c then goto tidy
+-$ on error then goto tidy
+-$!
+-$ set default 'proc_dev_dir'
+-$!
+-$ files := *.cms;*, *.srl;*, *.ss;*, -
+-   cms.err;*, cms.out;*, newreq.pem;*, -
+-   p.txt-zlib-cipher;*, -
+-   smtst.txt;*, testkey.pem;*, testreq.pem;*, -
+-   test_*.err;*, test_*.out;*, -
+-   .rnd;*
+-$!
+-$ delim = ","
+-$ i = 0
+-$ loop:
+-$    file = f$edit( f$element( i, delim, files), "trim")
+-$    if (file .eqs. delim) then goto loop_end
+-$    if (f$search( file) .nes. "") then -
+-      delete 'p1' 'file'
+-$    i = i+ 1
+-$ goto loop
+-$ loop_end:
+-$!
+-$ tidy:
+-$ 
+-$ if (f$type( def_orig) .nes. "") then -
+-   set default 'def_orig'
+-$!
+Index: openssl/util/libeay.num
+diff -u openssl/util/libeay.num:1.8.2.1 openssl/util/libeay.num:1.9
+--- openssl/util/libeay.num:1.8.2.1	Sun Jan 15 16:09:52 2012
++++ openssl/util/libeay.num	Sun Jan 15 16:30:10 2012
+@@ -4194,3 +4194,5 @@
+ OPENSSL_strncasecmp                     4566	EXIST::FUNCTION:
+ OPENSSL_gmtime                          4567	EXIST::FUNCTION:
+ OPENSSL_gmtime_adj                      4568	EXIST::FUNCTION:
++ENGINE_load_pk11ca                      4569	EXIST::FUNCTION:HW_PKCS11CA,ENGINE
++ENGINE_load_pk11so                      4569	EXIST::FUNCTION:HW_PKCS11SO,ENGINE
+Index: openssl/util/mk1mf.pl
+diff -u openssl/util/mk1mf.pl:1.9.2.1 openssl/util/mk1mf.pl:1.9
+--- openssl/util/mk1mf.pl:1.9.2.1	Sun Jan 15 16:09:52 2012
++++ openssl/util/mk1mf.pl	Mon Jun 13 17:13:56 2011
+@@ -109,6 +109,8 @@
+ 	no-ecdh					- No ECDH
+ 	no-engine				- No engine
+ 	no-hw					- No hw
++	no-hw-pkcs11ca				- No hw PKCS#11 CA flavor
++	no-hw-pkcs11so				- No hw PKCS#11 SO flavor
+ 	nasm 					- Use NASM for x86 asm
+ 	nw-nasm					- Use NASM x86 asm for NetWare
+ 	nw-mwasm				- Use Metrowerks x86 asm for NetWare
+@@ -270,6 +272,8 @@
+ $cflags.=" -DOPENSSL_NO_GOST" if $no_gost;
+ $cflags.=" -DOPENSSL_NO_ENGINE"   if $no_engine;
+ $cflags.=" -DOPENSSL_NO_HW"   if $no_hw;
++$cflags.=" -DOPENSSL_NO_HW_PKCS11CA"   if $no_hw_pkcs11ca;
++$cflags.=" -DOPENSSL_NO_HW_PKCS11SO"   if $no_hw_pkcs11so;
+ $cflags.=" -DOPENSSL_NO_JPAKE"    if $no_jpake;
+ $cflags.= " -DZLIB" if $zlib_opt;
+ $cflags.= " -DZLIB_SHARED" if $zlib_opt == 2;
+@@ -335,6 +339,9 @@
+ 		$dir=$val;
+ 		}
+ 
++	if ($key eq "PK11_LIB_LOCATION")
++		{ $cflags .= " -D$key=\\\"$val\\\"" if $val ne "";}
++
+ 	if ($key eq "KRB5_INCLUDES")
+ 		{ $cflags .= " $val";}
+ 
+@@ -1067,6 +1074,8 @@
+ 		"no-gost" => \$no_gost,
+ 		"no-engine" => \$no_engine,
+ 		"no-hw" => \$no_hw,
++		"no-hw-pkcs11ca" => \$no_hw_pkcs11ca,
++		"no-hw-pkcs11so" => \$no_hw_pkcs11so,
+ 		"just-ssl" =>
+ 			[\$no_rc2, \$no_idea, \$no_des, \$no_bf, \$no_cast,
+ 			  \$no_md2, \$no_sha, \$no_mdc2, \$no_dsa, \$no_dh,
+Index: openssl/util/mkdef.pl
+diff -u openssl/util/mkdef.pl:1.7.2.1 openssl/util/mkdef.pl:1.8
+--- openssl/util/mkdef.pl:1.7.2.1	Sun Jan 15 16:09:52 2012
++++ openssl/util/mkdef.pl	Sun Jan 15 16:30:10 2012
+@@ -94,7 +94,7 @@
+ 			 # External "algorithms"
+ 			 "FP_API", "STDIO", "SOCK", "KRB5", "DGRAM",
+ 			 # Engines
+-			 "STATIC_ENGINE", "ENGINE", "HW", "GMP",
++			 "STATIC_ENGINE", "ENGINE", "HW", "GMP", "HW_PKCS11CA", "HW_PKCS11SO",
+ 			 # RFC3779
+ 			 "RFC3779",
+ 			 # TLS
+@@ -125,6 +125,7 @@
+ my $no_md2; my $no_md4; my $no_md5; my $no_sha; my $no_ripemd; my $no_mdc2;
+ my $no_rsa; my $no_dsa; my $no_dh; my $no_hmac=0; my $no_aes; my $no_krb5;
+ my $no_ec; my $no_ecdsa; my $no_ecdh; my $no_engine; my $no_hw;
++my $no_pkcs11ca; my $no_pkcs11so;
+ my $no_fp_api; my $no_static_engine=1; my $no_gmp; my $no_deprecated;
+ my $no_rfc3779; my $no_psk; my $no_tlsext; my $no_cms; my $no_capieng;
+ my $no_jpake; my $no_ssl2;
+@@ -218,6 +219,8 @@
+ 	elsif (/^no-ssl2$/)	{ $no_ssl2=1; }
+ 	elsif (/^no-capieng$/)	{ $no_capieng=1; }
+ 	elsif (/^no-jpake$/)	{ $no_jpake=1; }
++	elsif (/^no-hw-pkcs11ca$/) { $no_pkcs11ca=1; }
++	elsif (/^no-hw-pkcs11so$/) { $no_pkcs11so=1; }
+ 	}
+ 
+ 
+@@ -1165,6 +1168,8 @@
+ 			if ($keyword eq "KRB5" && $no_krb5) { return 0; }
+ 			if ($keyword eq "ENGINE" && $no_engine) { return 0; }
+ 			if ($keyword eq "HW" && $no_hw) { return 0; }
++			if ($keyword eq "HW_PKCS11CA" && $no_pkcs11ca) { return 0; }
++			if ($keyword eq "HW_PKCS11SO" && $no_pkcs11so) { return 0; }
+ 			if ($keyword eq "FP_API" && $no_fp_api) { return 0; }
+ 			if ($keyword eq "STATIC_ENGINE" && $no_static_engine) { return 0; }
+ 			if ($keyword eq "GMP" && $no_gmp) { return 0; }
+Index: openssl/util/pl/VC-32.pl
+diff -u openssl/util/pl/VC-32.pl:1.7.2.1 openssl/util/pl/VC-32.pl:1.7
+--- openssl/util/pl/VC-32.pl:1.7.2.1	Sun Jan 15 16:09:52 2012
++++ openssl/util/pl/VC-32.pl	Mon Jun 13 17:13:57 2011
+@@ -36,7 +36,7 @@
+     my $f = $shlib?' /MD':' /MT';
+     $lib_cflag='/Zl' if (!$shlib);	# remove /DEFAULTLIBs from static lib
+     $opt_cflags=$f.' /Ox';
+-    $dbg_cflags=$f.'d /Od -DDEBUG -D_DEBUG';
++    $dbg_cflags=$f.'d /Od /Zi -DDEBUG -D_DEBUG';
+     $lflags="/nologo /subsystem:console /opt:ref";
+ 
+     *::perlasm_compile_target = sub {
diff --git a/bin/tests/system/inline/clean.sh b/bin/tests/system/inline/clean.sh
index 2f6db994..0b905fa8 100644
--- a/bin/tests/system/inline/clean.sh
+++ b/bin/tests/system/inline/clean.sh
@@ -1,4 +1,4 @@
-# Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
 #
 # Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: clean.sh,v 1.8 2011-12-22 07:32:40 each Exp $
+# $Id: clean.sh,v 1.12 2012-01-17 08:26:03 marka Exp $
 
 rm -f */named.memstats
 rm -f */named.run
@@ -45,6 +45,10 @@ rm -f ns3/updated.db
 rm -f ns3/updated.db.jnl
 rm -f ns3/updated.db.signed
 rm -f ns3/updated.db.signed.jnl
+rm -f ns3/expired.db
+rm -f ns3/expired.db.jnl
+rm -f ns3/expired.db.signed
+rm -f ns3/expired.db.signed.jnl
 rm -f ns4/K*
 rm -f ns4/noixfr.db
 rm -f ns4/noixfr.db.jnl
diff --git a/bin/tests/system/inline/ns1/root.db.in b/bin/tests/system/inline/ns1/root.db.in
index e0319c96..378df511 100644
--- a/bin/tests/system/inline/ns1/root.db.in
+++ b/bin/tests/system/inline/ns1/root.db.in
@@ -1,4 +1,4 @@
-; Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+; Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
 ;
 ; Permission to use, copy, modify, and/or distribute this software for any
 ; purpose with or without fee is hereby granted, provided that the above
@@ -12,7 +12,7 @@
 ; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 ; PERFORMANCE OF THIS SOFTWARE.
 
-; $Id: root.db.in,v 1.5 2011-12-22 07:32:40 each Exp $
+; $Id: root.db.in,v 1.7 2012-01-10 23:46:58 tbox Exp $
 
 $TTL 300
 . 			IN SOA	gson.nominum.com. a.root.servers.nil. (
@@ -41,3 +41,6 @@ ns3.dynamic.		A	10.53.0.3
 
 updated.			NS	ns3.updated.
 ns3.updated.		A	10.53.0.3
+
+expired.			NS	ns3.expired.
+ns3.expired.		A	10.53.0.3
diff --git a/bin/tests/system/inline/ns3/master.db.in b/bin/tests/system/inline/ns3/master.db.in
index 600d6cb4..c49c06cc 100644
--- a/bin/tests/system/inline/ns3/master.db.in
+++ b/bin/tests/system/inline/ns3/master.db.in
@@ -1,4 +1,4 @@
-; Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+; Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
 ;
 ; Permission to use, copy, modify, and/or distribute this software for any
 ; purpose with or without fee is hereby granted, provided that the above
@@ -12,10 +12,10 @@
 ; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 ; PERFORMANCE OF THIS SOFTWARE.
 
-; $Id: master.db.in,v 1.2 2011-10-26 20:56:45 marka Exp $
+; $Id: master.db.in,v 1.4 2012-01-16 23:46:46 tbox Exp $
 
 $TTL 300	; 5 minutes
-@			IN SOA	ns2 . (
+@			IN SOA	ns3 . (
 				2000042407 ; serial
 				20         ; refresh (20 seconds)
 				20         ; retry (20 seconds)
diff --git a/bin/tests/system/inline/ns3/master2.db.in b/bin/tests/system/inline/ns3/master2.db.in
index bff22d40..3cba8539 100644
--- a/bin/tests/system/inline/ns3/master2.db.in
+++ b/bin/tests/system/inline/ns3/master2.db.in
@@ -1,4 +1,4 @@
-; Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+; Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
 ;
 ; Permission to use, copy, modify, and/or distribute this software for any
 ; purpose with or without fee is hereby granted, provided that the above
@@ -12,10 +12,10 @@
 ; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 ; PERFORMANCE OF THIS SOFTWARE.
 
-; $Id: master2.db.in,v 1.2 2011-10-26 20:56:45 marka Exp $
+; $Id: master2.db.in,v 1.4 2012-01-16 23:46:46 tbox Exp $
 
 $TTL 300	; 5 minutes
-@			IN SOA	ns2 . (
+@			IN SOA	ns3 . (
 				2000042408 ; serial
 				20         ; refresh (20 seconds)
 				20         ; retry (20 seconds)
diff --git a/bin/tests/system/inline/ns3/master3.db.in b/bin/tests/system/inline/ns3/master3.db.in
new file mode 100644
index 00000000..21c31800
--- /dev/null
+++ b/bin/tests/system/inline/ns3/master3.db.in
@@ -0,0 +1,136 @@
+; Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
+;
+; Permission to use, copy, modify, and/or distribute this software for any
+; purpose with or without fee is hereby granted, provided that the above
+; copyright notice and this permission notice appear in all copies.
+;
+; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+; AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+; PERFORMANCE OF THIS SOFTWARE.
+
+; $Id: master3.db.in,v 1.1.4.2 2012-01-31 01:12:29 each Exp $
+
+$TTL 300	; 5 minutes
+@			IN SOA	ns3 . (
+				2000042409 ; serial
+				20         ; refresh (20 seconds)
+				20         ; retry (20 seconds)
+				1814400    ; expire (3 weeks)
+				3600       ; minimum (1 hour)
+				)
+			NS	ns3
+ns2			A	10.53.0.2
+ns3			A	10.53.0.3
+
+a			A	10.0.0.1
+b			A	10.0.0.2
+c			A	10.0.0.3
+d			A	10.0.0.4
+e			A	10.0.0.5
+
+; Used for testing ANY queries
+foo			TXT	"testing"
+foo			A	10.0.1.0
+
+bad-cname		CNAME   a
+bad-dname		DNAME   @
+
+; Used for testing CNAME queries
+cname1			CNAME	cname1-target
+cname1-target		TXT	"testing cname"
+
+cname2			CNAME	cname2-target
+cname2-target		TXT	"testing cname"
+
+; Used for testing DNAME queries
+dname1			DNAME	dname1-target
+foo.dname1-target	TXT	"testing dname"
+
+dname2			DNAME	dname2-target
+foo.dname2-target	TXT	"testing dname"
+
+; A secure subdomain
+secure			NS	ns.secure
+ns.secure		A	10.53.0.3
+
+; An insecure subdomain
+insecure		NS	ns.insecure
+ns.insecure		A	10.53.0.3
+
+; A secure subdomain we're going to inject bogus data into
+bogus			NS	ns.bogus
+ns.bogus		A	10.53.0.3
+
+; A dynamic secure subdomain
+dynamic			NS	dynamic
+dynamic			A	10.53.0.3
+
+; A insecure subdomain
+mustbesecure		NS	ns.mustbesecure
+ns.mustbesecure		A	10.53.0.3
+
+; A rfc2535 signed zone w/ CNAME
+rfc2535			NS	ns.rfc2535
+ns.rfc2535		A	10.53.0.3
+
+z			A	10.0.0.26
+
+keyless			NS	ns.keyless
+ns.keyless		A	10.53.0.3
+
+nsec3			NS	ns.nsec3
+ns.nsec3		A	10.53.0.3
+
+optout			NS	ns.optout
+ns.optout		A	10.53.0.3
+
+nsec3-unknown		NS	ns.nsec3-unknown
+ns.nsec3-unknown	A	10.53.0.3
+
+optout-unknown		NS	ns.optout-unknown
+ns.optout-unknown	A	10.53.0.3
+
+multiple		NS	ns.multiple
+ns.multiple		A	10.53.0.3
+
+*.wild			A	10.0.0.27
+
+rsasha256		NS	ns.rsasha256
+ns.rsasha256		A	10.53.0.3
+
+rsasha512		NS	ns.rsasha512
+ns.rsasha512		A	10.53.0.3
+
+kskonly 		NS	ns.kskonly
+ns.kskonly		A	10.53.0.3
+
+update-nsec3		NS	ns.update-nsec3
+ns.update-nsec3		A	10.53.0.3
+
+auto-nsec		NS	ns.auto-nsec
+ns.auto-nsec		A	10.53.0.3
+
+auto-nsec3		NS	ns.auto-nsec3
+ns.auto-nsec3		A	10.53.0.3
+
+
+below-cname		CNAME	some.where.else.
+
+insecure.below-cname	NS	ns.insecure.below-cname
+ns.insecure.below-cname	A	10.53.0.3
+
+secure.below-cname	NS	ns.secure.below-cname
+ns.secure.below-cname	A	10.53.0.3
+
+ttlpatch		NS	ns.ttlpatch
+ns.ttlpatch		A	10.53.0.3
+
+split-dnssec		NS	ns.split-dnssec
+ns.split-dnssec		A	10.53.0.3
+
+split-smart		NS	ns.split-smart
+ns.split-smart		A	10.53.0.3
diff --git a/bin/tests/system/inline/ns3/named.conf b/bin/tests/system/inline/ns3/named.conf
index 3ccff8f5..6d3ea27c 100644
--- a/bin/tests/system/inline/ns3/named.conf
+++ b/bin/tests/system/inline/ns3/named.conf
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: named.conf,v 1.5 2011-12-22 07:32:40 each Exp $ */
+/* $Id: named.conf,v 1.7 2012-01-10 23:46:58 tbox Exp $ */
 
 // NS3
 
@@ -78,3 +78,11 @@ zone "updated" {
 	allow-update { none; };
 	file "updated.db";
 };
+
+zone "expired" {
+	type master;
+	inline-signing yes;
+	auto-dnssec maintain;
+	allow-update { any; };
+	file "expired.db";
+};
diff --git a/bin/tests/system/inline/ns3/sign.sh b/bin/tests/system/inline/ns3/sign.sh
index 4905123a..9d75299b 100644
--- a/bin/tests/system/inline/ns3/sign.sh
+++ b/bin/tests/system/inline/ns3/sign.sh
@@ -1,6 +1,6 @@
 #!/bin/sh -e
 #
-# Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
 #
 # Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
@@ -14,7 +14,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: sign.sh,v 1.5 2011-12-22 07:32:40 each Exp $
+# $Id: sign.sh,v 1.7 2012-01-10 23:46:58 tbox Exp $
 
 SYSTEMTESTTOP=../..
 . $SYSTEMTESTTOP/conf.sh
@@ -57,3 +57,12 @@ keyname=`$KEYGEN -q -r $RANDFILE -a RSASHA1 -b 1024 -n zone -f KSK $zone`
 $DSFROMKEY -T 1200 $keyname >> ../ns1/root.db
 $SIGNER -S -O raw -L 2000042407 -o ${zone} ${zone}.db > /dev/null 2>&1
 cp master2.db.in updated.db
+
+# signatures are expired and should be regenerated on startup
+zone=expired
+rm -f K${zone}.+*+*.key
+rm -f K${zone}.+*+*.private
+keyname=`$KEYGEN -q -r $RANDFILE -a RSASHA1 -b 768 -n zone $zone`
+keyname=`$KEYGEN -q -r $RANDFILE -a RSASHA1 -b 1024 -n zone -f KSK $zone`
+$DSFROMKEY -T 1200 $keyname >> ../ns1/root.db
+$SIGNER -PS -s 20100101000000 -e 20110101000000 -O raw -L 2000042407 -o ${zone} ${zone}.db > /dev/null 2>&1
diff --git a/bin/tests/system/inline/setup.sh b/bin/tests/system/inline/setup.sh
index 1f09ce11..f7606888 100644
--- a/bin/tests/system/inline/setup.sh
+++ b/bin/tests/system/inline/setup.sh
@@ -1,4 +1,4 @@
-# Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
 #
 # Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: setup.sh,v 1.8 2011-12-22 07:32:40 each Exp $
+# $Id: setup.sh,v 1.10 2012-01-10 23:46:58 tbox Exp $
 
 sh clean.sh
 
@@ -23,29 +23,10 @@ touch ns2/trusted.conf
 cp ns2/bits.db.in ns2/bits.db
 rm -f ns2/bits.db.jnl
 
-rm -f ns3/bits.bk
-rm -f ns3/bits.bk.jnl
-rm -f ns3/bits.bk.signed
-rm -f ns3/bits.bk.signed.jnl
-
-rm -f ns3/noixfr.bk
-rm -f ns3/noixfr.bk.jnl
-rm -f ns3/noixfr.bk.signed
-rm -f ns3/noixfr.bk.signed.jnl
-
-rm -f ns3/master.db
-rm -f ns3/master.db.jnl
-rm -f ns3/master.db.signed
-rm -f ns3/master.db.signed.jnl
-
-rm -f ns3/dynamic.db
-rm -f ns3/dynamic.db.jnl
-rm -f ns3/dynamic.db.signed
-rm -f ns3/dynamic.db.signed.jnl
-
 cp ns3/master.db.in ns3/master.db
 cp ns3/master.db.in ns3/dynamic.db
 cp ns3/master.db.in ns3/updated.db
+cp ns3/master.db.in ns3/expired.db
 
 touch ns4/trusted.conf
 cp ns4/noixfr.db.in ns4/noixfr.db
diff --git a/bin/tests/system/inline/tests.sh b/bin/tests/system/inline/tests.sh
index d37cc0d7..afa3c026 100644
--- a/bin/tests/system/inline/tests.sh
+++ b/bin/tests/system/inline/tests.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
 #
 # Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
@@ -14,7 +14,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: tests.sh,v 1.11 2011-12-22 07:32:40 each Exp $
+# $Id: tests.sh,v 1.16.12.1 2012-01-31 01:11:54 each Exp $
 
 SYSTEMTESTTOP=..
 . $SYSTEMTESTTOP/conf.sh
@@ -41,6 +41,15 @@ if [ $ret != 0 ]; then echo "I:failed"; fi
 status=`expr $status + $ret`
 
 n=`expr $n + 1`
+echo "I:checking expired signatures are updated on load ($n)"
+ret=0
+$DIG $DIGOPTS @10.53.0.3 -p 5300 +noall +answer +dnssec expired SOA > dig.out.ns3.test$n
+expiry=`awk '$4 == "RRSIG" { print $9 }' dig.out.ns3.test$n`
+[ "$expiry" = "20110101000000" ] && ret=1
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
+
+n=`expr $n + 1`
 echo "I:checking removal of private type record via 'rndc signing -clear' ($n)"
 ret=0
 $RNDC -c ../common/rndc.conf -s 10.53.0.3 -p 9953 signing -list bits > signing.out.test$n 2>&1
@@ -310,10 +319,8 @@ status=`expr $status + $ret`
 n=`expr $n + 1`
 echo "I:check adding of record to unsigned master ($n)"
 ret=0
-sleep 1
 cp ns3/master2.db.in ns3/master.db
 $RNDC -c ../common/rndc.conf -s 10.53.0.3 -p 9953 reload master || ret=1
-
 for i in 1 2 3 4 5 6 7 8 9
 do
 	ans=0
@@ -324,7 +331,35 @@ do
 	sleep 1
 done
 [ $ans = 0 ] || ret=1
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
 
+n=`expr $n + 1`
+echo "I:check adding record fails when SOA serial not changed ($n)"
+ret=0
+echo "c A 10.0.0.3" >> ns3/master.db
+$RNDC -c ../common/rndc.conf -s 10.53.0.3 -p 9953 reload || ret=1
+sleep 1
+$DIG $DIGOPTS @10.53.0.3 -p 5300 c.master A > dig.out.ns3.test$n
+grep "NXDOMAIN" dig.out.ns3.test$n > /dev/null || ret=1
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
+
+n=`expr $n + 1`
+echo "I:check adding record works after updating SOA serial ($n)"
+ret=0
+cp ns3/master3.db.in ns3/master.db
+$RNDC -c ../common/rndc.conf -s 10.53.0.3 -p 9953 reload master || ret=1
+for i in 1 2 3 4 5 6 7 8 9
+do
+	ans=0
+	$DIG $DIGOPTS @10.53.0.3 -p 5300 c.master A > dig.out.ns3.test$n
+	grep "10.0.0.3" dig.out.ns3.test$n > /dev/null || ans=1
+	grep "ANSWER: 2," dig.out.ns3.test$n > /dev/null || ans=1
+	[ $ans = 1 ] || break
+	sleep 1
+done
+[ $ans = 0 ] || ret=1
 if [ $ret != 0 ]; then echo "I:failed"; fi
 status=`expr $status + $ret`
 
@@ -638,4 +673,24 @@ done
 if [ $ret != 0 ]; then echo "I:failed"; fi
 status=`expr $status + $ret`
 
+n=`expr $n + 1`
+echo "I:check rndc reload allows reuse of inline-signing zones ($n)"
+ret=0
+{ $RNDC -c ../common/rndc.conf -s 10.53.0.3 -p 9953 reload 2>&1 || ret=1 ; } |
+sed 's/^/I:ns3 /'
+grep "not reusable" ns3/named.run > /dev/null 2>&1 && ret=1
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
+
+n=`expr $n + 1`
+echo "I:check rndc sync removes both signed and unsigned journals ($n)"
+ret=0
+[ -f ns3/dynamic.db.jnl ] || ret=1
+[ -f ns3/dynamic.db.signed.jnl ] || ret=1
+$RNDC -c ../common/rndc.conf -s 10.53.0.3 -p 9953 sync -clean dynamic 2>&1 || ret=1
+[ -f ns3/dynamic.db.jnl ] && ret=1
+[ -f ns3/dynamic.db.signed.jnl ] && ret=1
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
+
 exit $status
diff --git a/bin/tests/system/rpz/clean.sh b/bin/tests/system/rpz/clean.sh
index 2008de1c..d46fd80d 100644
--- a/bin/tests/system/rpz/clean.sh
+++ b/bin/tests/system/rpz/clean.sh
@@ -1,4 +1,4 @@
-# Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
 #
 # Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: clean.sh,v 1.4 2011-10-13 01:32:32 vjs Exp $
+# $Id: clean.sh,v 1.6 2012-01-07 23:46:53 tbox Exp $
 
 
 # Clean up after rpz tests.
@@ -20,3 +20,5 @@
 rm -f proto.* dig.out* nsupdate.tmp
 rm -f  */named.memstats */named.run */named.rpz */session.key
 rm -f ns3/bl*.db */*.jnl */*.core */*.pid
+rm -f ns2/signed-tld2.db
+rm -f ns2/K*.private ns2/K*.key dsset-*
diff --git a/bin/tests/system/rpz/ns1/root.db b/bin/tests/system/rpz/ns1/root.db
index aa209311..001cdd12 100644
--- a/bin/tests/system/rpz/ns1/root.db
+++ b/bin/tests/system/rpz/ns1/root.db
@@ -1,4 +1,4 @@
-; Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+; Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
 ;
 ; Permission to use, copy, modify, and/or distribute this software for any
 ; purpose with or without fee is hereby granted, provided that the above
@@ -12,7 +12,7 @@
 ; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 ; PERFORMANCE OF THIS SOFTWARE.
 
-; $Id: root.db,v 1.4 2011-10-13 01:32:33 vjs Exp $
+; $Id: root.db,v 1.6 2012-01-07 23:46:53 tbox Exp $
 
 $TTL	120
 @		SOA	ns. hostmaster.ns. ( 1 3600 1200 604800 60 )
@@ -25,6 +25,11 @@ tld2.		NS	ns.tld2.
 ns.tld2.	A	10.53.0.2
 ns2.tld2.	A	10.53.0.2
 
+; rewrite responses from this zone unless dnssec requested
+signed-tld2.		NS	ns.signed-tld2.
+ns.signed-tld2.		A	10.53.0.2
+ns2.signed-tld2.	A	10.53.0.2
+
 ; requests come from here
 tld3.		NS	ns.tld3.
 ns.tld3.	A	10.53.0.3
diff --git a/bin/tests/system/rpz/ns2/named.conf b/bin/tests/system/rpz/ns2/named.conf
index bed5187f..1a29c1ae 100644
--- a/bin/tests/system/rpz/ns2/named.conf
+++ b/bin/tests/system/rpz/ns2/named.conf
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: named.conf,v 1.4 2011-10-13 01:32:33 vjs Exp $ */
+/* $Id: named.conf,v 1.6 2012-01-07 23:46:53 tbox Exp $ */
 
 
 controls { /* empty */ };
@@ -40,3 +40,4 @@ zone "sub2.tld2."	    {type master; file "tld2.db";};
 zone "subsub.sub2.tld2."    {type master; file "tld2.db";};
 zone "sub3.tld2."	    {type master; file "tld2.db";};
 zone "subsub.sub3.tld2."    {type master; file "tld2.db";};
+zone "signed-tld2."	    {type master; file "signed-tld2.db";};
diff --git a/bin/tests/system/rpz/setup.sh b/bin/tests/system/rpz/setup.sh
index 947b28a4..7bf70f5b 100644
--- a/bin/tests/system/rpz/setup.sh
+++ b/bin/tests/system/rpz/setup.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
 #
 # Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
@@ -14,11 +14,18 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: setup.sh,v 1.4 2011-10-13 01:32:32 vjs Exp $
+# $Id: setup.sh,v 1.6 2012-01-07 23:46:53 tbox Exp $
 
-sh clean.sh
+SYSTEMTESTTOP=..
+. $SYSTEMTESTTOP/conf.sh
+. ./clean.sh
 
 #  NO-OP is an obsolete synonym for PASSHTRU
 for NM in '' -2 -given -disabled -passthru -no-op -nodata -nxdomain -cname -wildcname -garden; do
     sed -e "/SOA/s/blx/bl$NM/g" ns3/base.db >ns3/bl$NM.db
 done
+
+../../../tools/genrandom 400 random.data
+$KEYGEN -Kns2 -q -r random.data -3 signed-tld2. > /dev/null 2>&1
+$KEYGEN -Kns2 -q -r random.data -3fk signed-tld2. > /dev/null 2>&1
+$SIGNER -S -Kns2 -o signed-tld2. -f ns2/signed-tld2.db ns2/tld2.db > /dev/null 2>&1
diff --git a/bin/tests/system/rpz/test1 b/bin/tests/system/rpz/test1
index 50be5dfa..c2b52cf6 100644
--- a/bin/tests/system/rpz/test1
+++ b/bin/tests/system/rpz/test1
@@ -12,7 +12,7 @@
 ; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 ; PERFORMANCE OF THIS SOFTWARE.
 
-; $Id: test1,v 1.7 2011-10-28 11:46:49 marka Exp $
+; $Id: test1,v 1.8 2012-01-07 00:19:59 each Exp $
 
 
 ; Use comment lines instead of blank lines to combine update requests into
@@ -26,6 +26,7 @@ server 10.53.0.3 5300
 
 ; NXDOMAIN
 update add  a0-1.tld2.bl.	300 CNAME .
+update add  a0-1.signed-tld2.bl.	300 CNAME .
 ;
 ; NODATA
 update add  a3-1.tld2.bl.	300 CNAME *.
diff --git a/bin/tests/system/rpz/tests.sh b/bin/tests/system/rpz/tests.sh
index 75ce53a4..b20cac8c 100644
--- a/bin/tests/system/rpz/tests.sh
+++ b/bin/tests/system/rpz/tests.sh
@@ -1,4 +1,4 @@
-# Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
 #
 # Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: tests.sh,v 1.10 2011-11-18 19:32:13 each Exp $
+# $Id: tests.sh,v 1.12 2012-01-07 23:46:53 tbox Exp $
 
 # test response policy zones (RPZ)
 
@@ -215,6 +215,10 @@ addr 57.57.57.57  a3-7.sub1.tld2	# 15 wildcard CNAME
 addr 127.0.0.16	  a4-5-cname3.tld2	# 16 CNAME chain
 addr 127.0.0.17	  a4-6-cname3.tld2	# 17 stop short in CNAME chain
 nxdomain c1.crash2.tld3			# 18 assert in rbtdb.c
+nochange a0-1.tld2      +norecurse
+nxdomain a0-1.tld2      +dnssec
+nxdomain a0-1.signed-tld2
+nochange a0-1.signed-tld2       +dnssec
 end_group
 
 start_group "IP rewrites" test2
diff --git a/bin/tests/system/rrsetorder/clean.sh b/bin/tests/system/rrsetorder/clean.sh
index f9071a2d..67802308 100644
--- a/bin/tests/system/rrsetorder/clean.sh
+++ b/bin/tests/system/rrsetorder/clean.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# Copyright (C) 2006-2008  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2006-2008, 2011  Internet Systems Consortium, Inc. ("ISC")
 #
 # Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
@@ -14,8 +14,9 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: clean.sh,v 1.8 2008-04-24 23:46:59 tbox Exp $
+# $Id: clean.sh,v 1.10 2011-12-23 23:47:13 tbox Exp $
 
+rm -f dig.out.test*
 rm -f dig.out.cyclic dig.out.fixed dig.out.random
 rm -f dig.out.0 dig.out.1 dig.out.2 dig.out.3
 rm -f ns2/root.bk
diff --git a/bin/tests/system/rrsetorder/ns1/root.db b/bin/tests/system/rrsetorder/ns1/root.db
index 2e454d70..ea5023d6 100644
--- a/bin/tests/system/rrsetorder/ns1/root.db
+++ b/bin/tests/system/rrsetorder/ns1/root.db
@@ -1,4 +1,4 @@
-; Copyright (C) 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
+; Copyright (C) 2006, 2007, 2012  Internet Systems Consortium, Inc. ("ISC")
 ;
 ; Permission to use, copy, modify, and/or distribute this software for any
 ; purpose with or without fee is hereby granted, provided that the above
@@ -12,7 +12,7 @@
 ; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 ; PERFORMANCE OF THIS SOFTWARE.
 
-; $Id: root.db,v 1.4 2007-06-19 23:47:05 tbox Exp $
+; $Id: root.db,v 1.6 2012-01-04 23:46:49 tbox Exp $
 
 $TTL 3600
 .                       SOA	hostmaster.isc.org. a.root-servers.nil. (
@@ -22,7 +22,8 @@ $TTL 3600
 				1200
 				600 )
 .                       NS      a.root-servers.nil.
-a.root-servers.nil	A       10.53.0.1
+.                       NS      cyclic.example.
+a.root-servers.nil.	A       10.53.0.1
 ;
 fixed.example.		A	1.2.3.4
 fixed.example.		A	1.2.3.3
@@ -38,3 +39,8 @@ cyclic.example.		A	1.2.3.4
 cyclic.example.		A	1.2.3.3
 cyclic.example.		A	1.2.3.2
 cyclic.example.		A	1.2.3.1
+;
+cyclic2.example.	A	1.2.3.4
+cyclic2.example.	A	1.2.3.3
+cyclic2.example.	A	1.2.3.2
+cyclic2.example.	A	1.2.3.1
diff --git a/bin/tests/system/rrsetorder/tests.sh b/bin/tests/system/rrsetorder/tests.sh
index b3f83dcd..3101f5ab 100644
--- a/bin/tests/system/rrsetorder/tests.sh
+++ b/bin/tests/system/rrsetorder/tests.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# Copyright (C) 2006-2008  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2006-2008, 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
 #
 # Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
@@ -14,7 +14,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: tests.sh,v 1.8 2008-10-09 21:27:52 each Exp $
+# $Id: tests.sh,v 1.13 2012-01-04 23:46:49 tbox Exp $
 
 SYSTEMTESTTOP=..
 . $SYSTEMTESTTOP/conf.sh
@@ -47,7 +47,7 @@ fi
 #
 #
 #
-echo "I: Checking order cyclic (master)"
+echo "I: Checking order cyclic (master + additional)"
 ret=0
 matches=0
 for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
@@ -71,6 +71,32 @@ if [ $matches -ne 16 ]; then ret=1; fi
 if [ $ret != 0 ]; then echo "I:failed"; fi
 status=`expr $status + $ret`
 
+#
+#
+#
+echo "I: Checking order cyclic (master)"
+ret=0
+matches=0
+for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
+do
+    j=`expr $i % 4`
+    $DIG +nosea +nocomm +nocmd +noquest +noadd +noauth +nocomm +nostat +short \
+	    -p 5300 @10.53.0.1 cyclic2.example > dig.out.cyclic2 || ret=1
+    if [ $i -le 4 ]; then
+        cp dig.out.cyclic2 dig.out.$j
+    else
+        cmp -s dig.out.cyclic2 dig.out.$j && matches=`expr $matches + 1`
+    fi
+done
+cmp -s dig.out.0 dig.out.1 && ret=1
+cmp -s dig.out.0 dig.out.2 && ret=1
+cmp -s dig.out.0 dig.out.3 && ret=1
+cmp -s dig.out.1 dig.out.2 && ret=1
+cmp -s dig.out.1 dig.out.3 && ret=1
+cmp -s dig.out.2 dig.out.3 && ret=1
+if [ $matches -ne 16 ]; then ret=1; fi
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
 echo "I: Checking order random (master)"
 ret=0
 for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
@@ -118,7 +144,7 @@ fi
 #
 #
 #
-echo "I: Checking order cyclic (slave)"
+echo "I: Checking order cyclic (slave + additional)"
 ret=0
 matches=0
 for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
@@ -142,6 +168,33 @@ if [ $matches -ne 16 ]; then ret=1; fi
 if [ $ret != 0 ]; then echo "I:failed"; fi
 status=`expr $status + $ret`
 
+#
+#
+#
+echo "I: Checking order cyclic (slave)"
+ret=0
+matches=0
+for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
+do
+    j=`expr $i % 4`
+    $DIG +nosea +nocomm +nocmd +noquest +noadd +noauth +nocomm +nostat +short \
+	    -p 5300 @10.53.0.2 cyclic2.example > dig.out.cyclic2 || ret=1
+    if [ $i -le 4 ]; then
+        cp dig.out.cyclic2 dig.out.$j
+    else
+        cmp -s dig.out.cyclic2 dig.out.$j && matches=`expr $matches + 1`
+    fi
+done
+cmp -s dig.out.0 dig.out.1 && ret=1
+cmp -s dig.out.0 dig.out.2 && ret=1
+cmp -s dig.out.0 dig.out.3 && ret=1
+cmp -s dig.out.1 dig.out.2 && ret=1
+cmp -s dig.out.1 dig.out.3 && ret=1
+cmp -s dig.out.2 dig.out.3 && ret=1
+if [ $matches -ne 16 ]; then ret=1; fi
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
+
 echo "I: Checking order random (slave)"
 ret=0
 for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
@@ -205,7 +258,7 @@ fi
 #
 #
 #
-echo "I: Checking order cyclic (slave loaded from disk)"
+echo "I: Checking order cyclic (slave + additional, loaded from disk)"
 ret=0
 matches=0
 for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
@@ -229,6 +282,33 @@ if [ $matches -ne 16 ]; then ret=1; fi
 if [ $ret != 0 ]; then echo "I:failed"; fi
 status=`expr $status + $ret`
 
+#
+#
+#
+echo "I: Checking order cyclic (slave loaded from disk)"
+ret=0
+matches=0
+for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
+do
+    j=`expr $i % 4`
+    $DIG +nosea +nocomm +nocmd +noquest +noadd +noauth +nocomm +nostat +short \
+	    -p 5300 @10.53.0.2 cyclic2.example > dig.out.cyclic2 || ret=1
+    if [ $i -le 4 ]; then
+        cp dig.out.cyclic2 dig.out.$j
+    else
+        cmp -s dig.out.cyclic2 dig.out.$j && matches=`expr $matches + 1`
+    fi
+done
+cmp -s dig.out.0 dig.out.1 && ret=1
+cmp -s dig.out.0 dig.out.2 && ret=1
+cmp -s dig.out.0 dig.out.3 && ret=1
+cmp -s dig.out.1 dig.out.2 && ret=1
+cmp -s dig.out.1 dig.out.3 && ret=1
+cmp -s dig.out.2 dig.out.3 && ret=1
+if [ $matches -ne 16 ]; then ret=1; fi
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
+
 echo "I: Checking order random (slave loaded from disk)"
 ret=0
 for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
@@ -276,8 +356,11 @@ fi
 #
 #
 #
-echo "I: Checking order cyclic (cache)"
+echo "I: Checking order cyclic (cache + additional)"
 ret=0
+# prime acache
+$DIG +nosea +nocomm +nocmd +noquest +noadd +noauth +nocomm +nostat +short \
+	    -p 5300 @10.53.0.3 cyclic.example > dig.out.cyclic || ret=1
 matches=0
 for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
 do
@@ -300,6 +383,36 @@ if [ $matches -ne 16 ]; then ret=1; fi
 if [ $ret != 0 ]; then echo "I:failed"; fi
 status=`expr $status + $ret`
 
+#
+#
+#
+echo "I: Checking order cyclic (cache)"
+ret=0
+# prime acache
+$DIG +nosea +nocomm +nocmd +noquest +noadd +noauth +nocomm +nostat +short \
+	    -p 5300 @10.53.0.3 cyclic2.example > dig.out.cyclic2 || ret=1
+matches=0
+for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
+do
+    j=`expr $i % 4`
+    $DIG +nosea +nocomm +nocmd +noquest +noadd +noauth +nocomm +nostat +short \
+	    -p 5300 @10.53.0.3 cyclic2.example > dig.out.cyclic2 || ret=1
+    if [ $i -le 4 ]; then
+        cp dig.out.cyclic2 dig.out.$j
+    else
+        cmp -s dig.out.cyclic2 dig.out.$j && matches=`expr $matches + 1`
+    fi
+done
+cmp -s dig.out.0 dig.out.1 && ret=1
+cmp -s dig.out.0 dig.out.2 && ret=1
+cmp -s dig.out.0 dig.out.3 && ret=1
+cmp -s dig.out.1 dig.out.2 && ret=1
+cmp -s dig.out.1 dig.out.3 && ret=1
+cmp -s dig.out.2 dig.out.3 && ret=1
+if [ $matches -ne 16 ]; then ret=1; fi
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
+
 echo "I: Checking order random (cache)"
 ret=0
 for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
diff --git a/bin/tests/system/upforwd/prereq.sh b/bin/tests/system/upforwd/prereq.sh
new file mode 100644
index 00000000..7b4175b7
--- /dev/null
+++ b/bin/tests/system/upforwd/prereq.sh
@@ -0,0 +1,25 @@
+#!/bin/sh
+#
+# Copyright (C) 2012  Internet Systems Consortium, Inc. ("ISC")
+#
+# Permission to use, copy, modify, and/or distribute this software for any
+# purpose with or without fee is hereby granted, provided that the above
+# copyright notice and this permission notice appear in all copies.
+#
+# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+# PERFORMANCE OF THIS SOFTWARE.
+
+# $Id: prereq.sh,v 1.3 2012-01-23 23:46:48 tbox Exp $
+
+if $PERL -e 'use Net::DNS;' 2>/dev/null
+then
+    :
+else
+    echo "I:This test requires the Net::DNS library." >&2
+    exit 1
+fi
diff --git a/config.h.in b/config.h.in
index 4670040b..5486c4de 100644
--- a/config.h.in
+++ b/config.h.in
@@ -16,7 +16,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: config.h.in,v 1.152 2011-12-20 00:49:49 marka Exp $ */
+/* $Id: config.h.in,v 1.152.22.1 2012-01-30 10:09:37 marka Exp $ */
 
 /*! \file */
 
diff --git a/config.threads.in b/config.threads.in
index 3dd9ea76..3094ab08 100644
--- a/config.threads.in
+++ b/config.threads.in
@@ -60,7 +60,9 @@ case $host in
 	# Linux kernels produce unusable core dumps from multithreaded
 	# programs, and because of limitations in setuid().
 	use_threads=false ;;	
-*-darwin10.*)
+*-darwin[[123456789]].*)
+	use_threads=false ;;
+*-darwin*.*)
 	use_threads=true ;;
 *)
 	use_threads=false ;;
diff --git a/configure b/configure
index 36e0593d..5447ee50 100755
--- a/configure
+++ b/configure
@@ -1,5 +1,5 @@
 #! /bin/sh
-# Copyright (C) 2004-2011  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2012  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1996-2003  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 #
-# $Id: configure,v 1.517 2011-12-20 00:49:49 marka Exp $
+# $Id: configure,v 1.517.22.1 2012-01-30 10:09:37 marka Exp $
 #
 # 	Portions of this code release fall under one or more of the
 # 	following Copyright notices.  Please see individual source
@@ -22176,7 +22176,9 @@ case $host in
 	# Linux kernels produce unusable core dumps from multithreaded
 	# programs, and because of limitations in setuid().
 	use_threads=false ;;
-*-darwin10.*)
+*-darwin[123456789].*)
+	use_threads=false ;;
+*-darwin*.*)
 	use_threads=true ;;
 *)
 	use_threads=false ;;
diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml
index a0d42733..fefe129d 100644
--- a/doc/arm/Bv9ARM-book.xml
+++ b/doc/arm/Bv9ARM-book.xml
@@ -2,7 +2,7 @@
               "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004-2011  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- File: $Id: Bv9ARM-book.xml,v 1.518 2011-11-23 18:58:39 each Exp $ -->
+<!-- File: $Id: Bv9ARM-book.xml,v 1.521 2012-01-15 21:16:04 each Exp $ -->
 <book xmlns:xi="http://www.w3.org/2001/XInclude">
   <title>BIND 9 Administrator Reference Manual</title>
 
@@ -32,6 +32,7 @@
       <year>2009</year>
       <year>2010</year>
       <year>2011</year>
+      <year>2012</year>
       <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
     </copyright>
     <copyright>
@@ -4664,11 +4665,17 @@ category notify { null; };
 		    </para>
 
                     <para>
-                      <computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput>
+                      <computeroutput>client 127.0.0.1#62536 (www.example.com): query: www.example.com IN AAAA +SE</computeroutput>
                     </para>
                     <para>
-                      <computeroutput>client ::1#62537: query: www.example.net IN AAAA -SE</computeroutput>
+                      <computeroutput>client ::1#62537 (www.example.net): query: www.example.net IN AAAA -SE</computeroutput>
                     </para>
+		    <para>
+                      (The first part of this log message, showing the
+                      client address/port number and query name, is
+                      repeated in all subsequent log messages related
+                      to the same query.)
+		    </para>
                   </entry>
                 </row>
                 <row rowsep="0">
@@ -8633,8 +8640,10 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
           </para>
           <para>
             If multiple <command>rrset-order</command> statements
-            appear,
-            they are not combined &mdash; the last one applies.
+            appear, they are not combined &mdash; the last one applies.
+          </para>
+          <para>
+            By default, all records are returned in random order.
           </para>
 
           <note>
diff --git a/doc/arm/Bv9ARM.ch01.html b/doc/arm/Bv9ARM.ch01.html
index 5ea583c8..62bed98e 100644
--- a/doc/arm/Bv9ARM.ch01.html
+++ b/doc/arm/Bv9ARM.ch01.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch01.html,v 1.50 2011-06-22 01:14:38 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch01.html,v 1.51 2012-01-07 01:14:54 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,17 +45,17 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564371">Scope of Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564394">Organization of This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564534">Conventions Used in This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564715">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564374">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564397">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564537">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564718">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564737">DNS Fundamentals</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564771">Domains and Domain Names</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567176">Zones</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567253">Authoritative Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567426">Caching Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567556">Name Servers in Multiple Roles</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564740">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564774">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567179">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567256">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567429">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567559">Name Servers in Multiple Roles</a></span></dt>
 </dl></dd>
 </dl>
 </div>
@@ -71,7 +71,7 @@
     </p>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564371"></a>Scope of Document</h2></div></div></div>
+<a name="id2564374"></a>Scope of Document</h2></div></div></div>
 <p>
         The Berkeley Internet Name Domain
         (<acronym class="acronym">BIND</acronym>) implements a
@@ -87,7 +87,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564394"></a>Organization of This Document</h2></div></div></div>
+<a name="id2564397"></a>Organization of This Document</h2></div></div></div>
 <p>
         In this document, <span class="emphasis"><em>Chapter 1</em></span> introduces
         the basic <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym> concepts. <span class="emphasis"><em>Chapter 2</em></span>
@@ -116,7 +116,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564534"></a>Conventions Used in This Document</h2></div></div></div>
+<a name="id2564537"></a>Conventions Used in This Document</h2></div></div></div>
 <p>
         In this document, we use the following general typographic
         conventions:
@@ -243,7 +243,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564715"></a>The Domain Name System (<acronym class="acronym">DNS</acronym>)</h2></div></div></div>
+<a name="id2564718"></a>The Domain Name System (<acronym class="acronym">DNS</acronym>)</h2></div></div></div>
 <p>
         The purpose of this document is to explain the installation
         and upkeep of the <acronym class="acronym">BIND</acronym> (Berkeley Internet
@@ -253,7 +253,7 @@
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2564737"></a>DNS Fundamentals</h3></div></div></div>
+<a name="id2564740"></a>DNS Fundamentals</h3></div></div></div>
 <p>
           The Domain Name System (DNS) is a hierarchical, distributed
           database.  It stores information for mapping Internet host names to
@@ -275,7 +275,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2564771"></a>Domains and Domain Names</h3></div></div></div>
+<a name="id2564774"></a>Domains and Domain Names</h3></div></div></div>
 <p>
           The data stored in the DNS is identified by <span class="emphasis"><em>domain names</em></span> that are organized as a tree according to
           organizational or administrative boundaries. Each node of the tree,
@@ -321,7 +321,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567176"></a>Zones</h3></div></div></div>
+<a name="id2567179"></a>Zones</h3></div></div></div>
 <p>
           To properly operate a name server, it is important to understand
           the difference between a <span class="emphasis"><em>zone</em></span>
@@ -374,7 +374,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567253"></a>Authoritative Name Servers</h3></div></div></div>
+<a name="id2567256"></a>Authoritative Name Servers</h3></div></div></div>
 <p>
           Each zone is served by at least
           one <span class="emphasis"><em>authoritative name server</em></span>,
@@ -391,7 +391,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567276"></a>The Primary Master</h4></div></div></div>
+<a name="id2567280"></a>The Primary Master</h4></div></div></div>
 <p>
             The authoritative server where the master copy of the zone
             data is maintained is called the
@@ -411,7 +411,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567374"></a>Slave Servers</h4></div></div></div>
+<a name="id2567378"></a>Slave Servers</h4></div></div></div>
 <p>
             The other authoritative servers, the <span class="emphasis"><em>slave</em></span>
             servers (also known as <span class="emphasis"><em>secondary</em></span> servers)
@@ -427,7 +427,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567396"></a>Stealth Servers</h4></div></div></div>
+<a name="id2567399"></a>Stealth Servers</h4></div></div></div>
 <p>
             Usually all of the zone's authoritative servers are listed in
             NS records in the parent zone.  These NS records constitute
@@ -462,7 +462,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567426"></a>Caching Name Servers</h3></div></div></div>
+<a name="id2567429"></a>Caching Name Servers</h3></div></div></div>
 <p>
           The resolver libraries provided by most operating systems are
           <span class="emphasis"><em>stub resolvers</em></span>, meaning that they are not
@@ -489,7 +489,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567529"></a>Forwarding</h4></div></div></div>
+<a name="id2567532"></a>Forwarding</h4></div></div></div>
 <p>
             Even a caching name server does not necessarily perform
             the complete recursive lookup itself.  Instead, it can
@@ -516,7 +516,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567556"></a>Name Servers in Multiple Roles</h3></div></div></div>
+<a name="id2567559"></a>Name Servers in Multiple Roles</h3></div></div></div>
 <p>
           The <acronym class="acronym">BIND</acronym> name server can
           simultaneously act as
diff --git a/doc/arm/Bv9ARM.ch02.html b/doc/arm/Bv9ARM.ch02.html
index a9fde322..b3f69072 100644
--- a/doc/arm/Bv9ARM.ch02.html
+++ b/doc/arm/Bv9ARM.ch02.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch02.html,v 1.43 2011-01-05 01:14:07 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch02.html,v 1.44 2012-01-07 01:14:55 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,16 +45,16 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567590">Hardware requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567617">CPU Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567629">Memory Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567724">Name Server Intensive Environment Issues</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567735">Supported Operating Systems</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567593">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567620">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567633">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567728">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567738">Supported Operating Systems</a></span></dt>
 </dl>
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567590"></a>Hardware requirements</h2></div></div></div>
+<a name="id2567593"></a>Hardware requirements</h2></div></div></div>
 <p>
         <acronym class="acronym">DNS</acronym> hardware requirements have
         traditionally been quite modest.
@@ -73,7 +73,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567617"></a>CPU Requirements</h2></div></div></div>
+<a name="id2567620"></a>CPU Requirements</h2></div></div></div>
 <p>
         CPU requirements for <acronym class="acronym">BIND</acronym> 9 range from
         i486-class machines
@@ -84,7 +84,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567629"></a>Memory Requirements</h2></div></div></div>
+<a name="id2567633"></a>Memory Requirements</h2></div></div></div>
 <p>
         The memory of the server has to be large enough to fit the
         cache and zones loaded off disk.  The <span><strong class="command">max-cache-size</strong></span>
@@ -107,7 +107,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567724"></a>Name Server Intensive Environment Issues</h2></div></div></div>
+<a name="id2567728"></a>Name Server Intensive Environment Issues</h2></div></div></div>
 <p>
         For name server intensive environments, there are two alternative
         configurations that may be used. The first is where clients and
@@ -124,7 +124,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567735"></a>Supported Operating Systems</h2></div></div></div>
+<a name="id2567738"></a>Supported Operating Systems</h2></div></div></div>
 <p>
         ISC <acronym class="acronym">BIND</acronym> 9 compiles and runs on a large
         number
diff --git a/doc/arm/Bv9ARM.ch03.html b/doc/arm/Bv9ARM.ch03.html
index d9299bea..6a1e71cd 100644
--- a/doc/arm/Bv9ARM.ch03.html
+++ b/doc/arm/Bv9ARM.ch03.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch03.html,v 1.90 2011-11-05 01:14:49 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch03.html,v 1.91 2012-01-07 01:14:55 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -47,14 +47,14 @@
 <dl>
 <dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567767">A Caching-only Name Server</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567988">An Authoritative-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567770">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567991">An Authoritative-only Name Server</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568010">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568364">Name Server Operations</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568013">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568368">Name Server Operations</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568370">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570628">Signals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568373">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570631">Signals</a></span></dt>
 </dl></dd>
 </dl>
 </div>
@@ -68,7 +68,7 @@
 <a name="sample_configuration"></a>Sample Configurations</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567767"></a>A Caching-only Name Server</h3></div></div></div>
+<a name="id2567770"></a>A Caching-only Name Server</h3></div></div></div>
 <p>
           The following sample configuration is appropriate for a caching-only
           name server for use by clients internal to a corporation.  All
@@ -98,7 +98,7 @@ zone "0.0.127.in-addr.arpa" {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567988"></a>An Authoritative-only Name Server</h3></div></div></div>
+<a name="id2567991"></a>An Authoritative-only Name Server</h3></div></div></div>
 <p>
           This sample configuration is for an authoritative-only server
           that is the master server for "<code class="filename">example.com</code>"
@@ -146,7 +146,7 @@ zone "eng.example.com" {
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2568010"></a>Load Balancing</h2></div></div></div>
+<a name="id2568013"></a>Load Balancing</h2></div></div></div>
 <p>
         A primitive form of load balancing can be achieved in
         the <acronym class="acronym">DNS</acronym> by using multiple records
@@ -289,10 +289,10 @@ zone "eng.example.com" {
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2568364"></a>Name Server Operations</h2></div></div></div>
+<a name="id2568368"></a>Name Server Operations</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2568370"></a>Tools for Use With the Name Server Daemon</h3></div></div></div>
+<a name="id2568373"></a>Tools for Use With the Name Server Daemon</h3></div></div></div>
 <p>
           This section describes several indispensable diagnostic,
           administrative and monitoring tools available to the system
@@ -968,7 +968,7 @@ controls {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2570628"></a>Signals</h3></div></div></div>
+<a name="id2570631"></a>Signals</h3></div></div></div>
 <p>
           Certain UNIX signals cause the name server to take specific
           actions, as described in the following table.  These signals can
diff --git a/doc/arm/Bv9ARM.ch04.html b/doc/arm/Bv9ARM.ch04.html
index c38a8dd0..e39c144a 100644
--- a/doc/arm/Bv9ARM.ch04.html
+++ b/doc/arm/Bv9ARM.ch04.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch04.html,v 1.149 2011-11-24 01:14:52 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch04.html,v 1.153 2012-01-17 01:15:02 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -49,59 +49,59 @@
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2564035">Split DNS</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564053">Example split DNS setup</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2563970">Split DNS</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563988">Example split DNS setup</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571722">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571796">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571806">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571979">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572105">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572154">Errors</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571725">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571799">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572014">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572051">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572108">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572157">Errors</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572168">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572217">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572171">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572289">SIG(0)</a></span></dt>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572354">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572433">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572582">Configuring Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572357">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572436">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572585">Configuring Servers</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#dnssec.dynamic.zones">DNSSEC, Dynamic Zones, and Automatic Signing</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2608427">Converting from insecure to secure</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2608465">Dynamic DNS update method</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563513">Fully automatic zone signing</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563685">Private-type records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563790">DNSKEY rollovers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563803">Dynamic DNS update method</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563836">Automatic key rollovers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563863">NSEC3PARAM rollovers via UPDATE</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563873">Converting from NSEC to NSEC3</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563882">Converting from NSEC3 to NSEC</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571200">Converting from secure to insecure</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571237">Periodic re-signing</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571246">NSEC3 and OPTOUT</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2608776">Converting from insecure to secure</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563484">Dynamic DNS update method</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563521">Fully automatic zone signing</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563692">Private-type records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563730">DNSKEY rollovers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563742">Dynamic DNS update method</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563776">Automatic key rollovers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563802">NSEC3PARAM rollovers via UPDATE</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563812">Converting from NSEC to NSEC3</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563821">Converting from NSEC3 to NSEC</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571207">Converting from secure to insecure</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571244">Periodic re-signing</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571254">NSEC3 and OPTOUT</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#rfc5011.support">Dynamic Trust Anchor Management</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2607869">Validating Resolver</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2607892">Authoritative Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2609037">Validating Resolver</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2609060">Authoritative Server</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#pkcs11">PKCS #11 (Cryptoki) support</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2610805">Prerequisites</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2608755">Building BIND 9 with PKCS#11</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2608850">PKCS #11 Tools</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2608881">Using the HSM</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2611537">Specifying the engine on the command line</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2611582">Running named with automatic zone re-signing</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2611347">Prerequisites</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2609255">Building BIND 9 with PKCS#11</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2635799">PKCS #11 Tools</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2635830">Using the HSM</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2636097">Specifying the engine on the command line</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2636142">Running named with automatic zone re-signing</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572802">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572805">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2573068">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2573090">Address to Name Lookups Using Nibble Format</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2573003">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2573025">Address to Name Lookups Using Nibble Format</a></span></dt>
 </dl></dd>
 </dl>
 </div>
@@ -256,7 +256,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564035"></a>Split DNS</h2></div></div></div>
+<a name="id2563970"></a>Split DNS</h2></div></div></div>
 <p>
         Setting up different views, or visibility, of the DNS space to
         internal and external resolvers is usually referred to as a
@@ -286,7 +286,7 @@
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2564053"></a>Example split DNS setup</h3></div></div></div>
+<a name="id2563988"></a>Example split DNS setup</h3></div></div></div>
 <p>
         Let's say a company named <span class="emphasis"><em>Example, Inc.</em></span>
         (<code class="literal">example.com</code>)
@@ -543,7 +543,7 @@ nameserver 172.16.72.4
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571722"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
+<a name="id2571725"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
 <p>
           A shared secret is generated to be shared between <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host2</em></span>.
           An arbitrary key name is chosen: "host1-host2.". The key name must
@@ -551,7 +551,7 @@ nameserver 172.16.72.4
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2571739"></a>Automatic Generation</h4></div></div></div>
+<a name="id2571742"></a>Automatic Generation</h4></div></div></div>
 <p>
             The following command will generate a 128-bit (16 byte) HMAC-SHA256
             key as described above. Longer keys are better, but shorter keys
@@ -575,7 +575,7 @@ nameserver 172.16.72.4
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2571778"></a>Manual Generation</h4></div></div></div>
+<a name="id2571781"></a>Manual Generation</h4></div></div></div>
 <p>
             The shared secret is simply a random sequence of bits, encoded
             in base-64. Most ASCII strings are valid base-64 strings (assuming
@@ -590,7 +590,7 @@ nameserver 172.16.72.4
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571796"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
+<a name="id2571799"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
 <p>
           This is beyond the scope of DNS. A secure transport mechanism
           should be used. This could be secure FTP, ssh, telephone, etc.
@@ -598,7 +598,7 @@ nameserver 172.16.72.4
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571806"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
+<a name="id2572014"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
 <p>
           Imagine <span class="emphasis"><em>host1</em></span> and <span class="emphasis"><em>host 2</em></span>
           are
@@ -625,7 +625,7 @@ key host1-host2. {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571979"></a>Instructing the Server to Use the Key</h3></div></div></div>
+<a name="id2572051"></a>Instructing the Server to Use the Key</h3></div></div></div>
 <p>
           Since keys are shared between two hosts only, the server must
           be told when keys are to be used. The following is added to the <code class="filename">named.conf</code> file
@@ -657,7 +657,7 @@ server 10.1.2.3 {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2572105"></a>TSIG Key Based Access Control</h3></div></div></div>
+<a name="id2572108"></a>TSIG Key Based Access Control</h3></div></div></div>
 <p>
           <acronym class="acronym">BIND</acronym> allows IP addresses and ranges
           to be specified in ACL
@@ -684,7 +684,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2572154"></a>Errors</h3></div></div></div>
+<a name="id2572157"></a>Errors</h3></div></div></div>
 <p>
           The processing of TSIG signed messages can result in
           several errors. If a signed message is sent to a non-TSIG aware
@@ -710,7 +710,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2572168"></a>TKEY</h2></div></div></div>
+<a name="id2572171"></a>TKEY</h2></div></div></div>
 <p><span><strong class="command">TKEY</strong></span>
         is a mechanism for automatically generating a shared secret
         between two hosts.  There are several "modes" of
@@ -746,7 +746,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2572217"></a>SIG(0)</h2></div></div></div>
+<a name="id2572289"></a>SIG(0)</h2></div></div></div>
 <p>
         <acronym class="acronym">BIND</acronym> 9 partially supports DNSSEC SIG(0)
             transaction signatures as specified in RFC 2535 and RFC 2931.
@@ -807,7 +807,7 @@ allow-update { key host1-host2. ;};
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2572354"></a>Generating Keys</h3></div></div></div>
+<a name="id2572357"></a>Generating Keys</h3></div></div></div>
 <p>
           The <span><strong class="command">dnssec-keygen</strong></span> program is used to
           generate keys.
@@ -863,7 +863,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2572433"></a>Signing the Zone</h3></div></div></div>
+<a name="id2572436"></a>Signing the Zone</h3></div></div></div>
 <p>
           The <span><strong class="command">dnssec-signzone</strong></span> program is used
           to sign a zone.
@@ -905,7 +905,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2572582"></a>Configuring Servers</h3></div></div></div>
+<a name="id2572585"></a>Configuring Servers</h3></div></div></div>
 <p>
           To enable <span><strong class="command">named</strong></span> to respond appropriately
           to DNS requests from DNSSEC aware clients,
@@ -1065,7 +1065,7 @@ options {
   from insecure to signed and back again. A secure zone can use
   either NSEC or NSEC3 chains.</p>
 <div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title">
-<a name="id2608427"></a>Converting from insecure to secure</h3></div></div></div></div>
+<a name="id2608776"></a>Converting from insecure to secure</h3></div></div></div></div>
 <p>Changing a zone from insecure to secure can be done in two
   ways: using a dynamic DNS update, or the 
   <span><strong class="command">auto-dnssec</strong></span> zone option.</p>
@@ -1091,7 +1091,7 @@ options {
   well. An NSEC chain will be generated as part of the initial
   signing process.</p>
 <div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title">
-<a name="id2608465"></a>Dynamic DNS update method</h3></div></div></div></div>
+<a name="id2563484"></a>Dynamic DNS update method</h3></div></div></div></div>
 <p>To insert the keys via dynamic update:</p>
 <pre class="screen">
         % nsupdate
@@ -1127,7 +1127,7 @@ options {
 <p>While the initial signing and NSEC/NSEC3 chain generation
   is happening, other updates are possible as well.</p>
 <div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title">
-<a name="id2563513"></a>Fully automatic zone signing</h3></div></div></div></div>
+<a name="id2563521"></a>Fully automatic zone signing</h3></div></div></div></div>
 <p>To enable automatic signing, add the 
   <span><strong class="command">auto-dnssec</strong></span> option to the zone statement in 
   <code class="filename">named.conf</code>. 
@@ -1183,7 +1183,7 @@ options {
   configuration. If this has not been done, the configuration will
   fail.</p>
 <div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title">
-<a name="id2563685"></a>Private-type records</h3></div></div></div></div>
+<a name="id2563692"></a>Private-type records</h3></div></div></div></div>
 <p>The state of the signing process is signaled by
   private-type records (with a default type value of 65534). When
   signing is complete, these records will have a nonzero value for
@@ -1224,12 +1224,12 @@ options {
 <p>
   </p>
 <div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title">
-<a name="id2563790"></a>DNSKEY rollovers</h3></div></div></div></div>
+<a name="id2563730"></a>DNSKEY rollovers</h3></div></div></div></div>
 <p>As with insecure-to-secure conversions, rolling DNSSEC
   keys can be done in two ways: using a dynamic DNS update, or the 
   <span><strong class="command">auto-dnssec</strong></span> zone option.</p>
 <div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title">
-<a name="id2563803"></a>Dynamic DNS update method</h3></div></div></div></div>
+<a name="id2563742"></a>Dynamic DNS update method</h3></div></div></div></div>
 <p> To perform key rollovers via dynamic update, you need to add
   the <code class="filename">K*</code> files for the new keys so that 
   <span><strong class="command">named</strong></span> can find them. You can then add the new
@@ -1251,7 +1251,7 @@ options {
   <span><strong class="command">named</strong></span> will clean out any signatures generated
   by the old key after the update completes.</p>
 <div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title">
-<a name="id2563836"></a>Automatic key rollovers</h3></div></div></div></div>
+<a name="id2563776"></a>Automatic key rollovers</h3></div></div></div></div>
 <p>When a new key reaches its activation date (as set by
   <span><strong class="command">dnssec-keygen</strong></span> or <span><strong class="command">dnssec-settime</strong></span>),
   if the <span><strong class="command">auto-dnssec</strong></span> zone option is set to 
@@ -1266,27 +1266,27 @@ options {
   completes in 30 days, after which it will be safe to remove the
   old key from the DNSKEY RRset.</p>
 <div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title">
-<a name="id2563863"></a>NSEC3PARAM rollovers via UPDATE</h3></div></div></div></div>
+<a name="id2563802"></a>NSEC3PARAM rollovers via UPDATE</h3></div></div></div></div>
 <p>Add the new NSEC3PARAM record via dynamic update. When the
   new NSEC3 chain has been generated, the NSEC3PARAM flag field
   will be zero. At this point you can remove the old NSEC3PARAM
   record. The old chain will be removed after the update request
   completes.</p>
 <div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title">
-<a name="id2563873"></a>Converting from NSEC to NSEC3</h3></div></div></div></div>
+<a name="id2563812"></a>Converting from NSEC to NSEC3</h3></div></div></div></div>
 <p>To do this, you just need to add an NSEC3PARAM record. When
   the conversion is complete, the NSEC chain will have been removed
   and the NSEC3PARAM record will have a zero flag field. The NSEC3
   chain will be generated before the NSEC chain is
   destroyed.</p>
 <div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title">
-<a name="id2563882"></a>Converting from NSEC3 to NSEC</h3></div></div></div></div>
+<a name="id2563821"></a>Converting from NSEC3 to NSEC</h3></div></div></div></div>
 <p>To do this, use <span><strong class="command">nsupdate</strong></span> to
   remove all NSEC3PARAM records with a zero flag
   field. The NSEC chain will be generated before the NSEC3 chain is
   removed.</p>
 <div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title">
-<a name="id2571200"></a>Converting from secure to insecure</h3></div></div></div></div>
+<a name="id2571207"></a>Converting from secure to insecure</h3></div></div></div></div>
 <p>To convert a signed zone to unsigned using dynamic DNS,
   delete all the DNSKEY records from the zone apex using
   <span><strong class="command">nsupdate</strong></span>. All signatures, NSEC or NSEC3 chains,
@@ -1301,14 +1301,14 @@ options {
   <span><strong class="command">allow</strong></span> instead (or it will re-sign).
   </p>
 <div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title">
-<a name="id2571237"></a>Periodic re-signing</h3></div></div></div></div>
+<a name="id2571244"></a>Periodic re-signing</h3></div></div></div></div>
 <p>In any secure zone which supports dynamic updates, named
   will periodically re-sign RRsets which have not been re-signed as
   a result of some update action. The signature lifetimes will be
   adjusted so as to spread the re-sign load over time rather than
   all at once.</p>
 <div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title">
-<a name="id2571246"></a>NSEC3 and OPTOUT</h3></div></div></div></div>
+<a name="id2571254"></a>NSEC3 and OPTOUT</h3></div></div></div></div>
 <p>
   <span><strong class="command">named</strong></span> only supports creating new NSEC3 chains
   where all the NSEC3 records in the zone have the same OPTOUT
@@ -1330,7 +1330,7 @@ options {
   configuration files.</p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2607869"></a>Validating Resolver</h3></div></div></div>
+<a name="id2609037"></a>Validating Resolver</h3></div></div></div>
 <p>To configure a validating resolver to use RFC 5011 to
     maintain a trust anchor, configure the trust anchor using a 
     <span><strong class="command">managed-keys</strong></span> statement. Information about
@@ -1341,7 +1341,7 @@ options {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2607892"></a>Authoritative Server</h3></div></div></div>
+<a name="id2609060"></a>Authoritative Server</h3></div></div></div>
 <p>To set up an authoritative zone for RFC 5011 trust anchor
     maintenance, generate two (or more) key signing keys (KSKs) for
     the zone. Sign the zone with one of them; this is the "active"
@@ -1415,7 +1415,7 @@ $ <strong class="userinput"><code>dnssec-signzone -S -K keys example.net</code><
   Debian Linux, Solaris x86 and Windows Server 2003.</p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2610805"></a>Prerequisites</h3></div></div></div>
+<a name="id2611347"></a>Prerequisites</h3></div></div></div>
 <p>See the HSM vendor documentation for information about
     installing, initializing, testing and troubleshooting the
     HSM.</p>
@@ -1450,13 +1450,16 @@ $ <strong class="userinput"><code>dnssec-signzone -S -K keys example.net</code><
         other computationally-intensive operations. The AEP Keyper
         is an example of such a device.</p></li>
 </ul></div>
-<p>The modified OpenSSL code is included in the BIND 9.7.0
-    release, in the form of a context diff against the latest OpenSSL.
+<p>The modified OpenSSL code is included in the BIND 9 release,
+        in the form of a context diff against the latest verions of
+        OpenSSL.  OpenSSL 0.9.8 and 1.0.0 are both supported; there are
+        separate diffs for each version.  In the examples to follow,
+        we use OpenSSL 0.9.8, but the same methods work with OpenSSL 1.0.0.
     </p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
-      The latest OpenSSL version at the time of the BIND release
-      is 0.9.8l.
+      The latest OpenSSL versions at the time of the BIND release
+      are 0.9.8s and 1.0.0f.
       ISC will provide an updated patch as new versions of OpenSSL
       are released. The version number in the following examples
       is expected to change.</div>
@@ -1465,18 +1468,18 @@ $ <strong class="userinput"><code>dnssec-signzone -S -K keys example.net</code><
     necessary to build OpenSSL with this patch in place and inform
     it of the path to the HSM-specific PKCS #11 provider
     library.</p>
-<p>Obtain OpenSSL 0.9.8l:</p>
+<p>Obtain OpenSSL 0.9.8s:</p>
 <pre class="screen">
-$ <strong class="userinput"><code>wget <a href="" target="_top">http://www.openssl.org/source/openssl-0.9.8l.tar.gz</a></code></strong>
+$ <strong class="userinput"><code>wget <a href="" target="_top">http://www.openssl.org/source/openssl-0.9.8s.tar.gz</a></code></strong>
 </pre>
 <p>Extract the tarball:</p>
 <pre class="screen">
-$ <strong class="userinput"><code>tar zxf openssl-0.9.8l.tar.gz</code></strong>
+$ <strong class="userinput"><code>tar zxf openssl-0.9.8s.tar.gz</code></strong>
 </pre>
 <p>Apply the patch from the BIND 9 release:</p>
 <pre class="screen">
-$ <strong class="userinput"><code>patch -p1 -d openssl-0.9.8l \
-            &lt; bind-9.7.0/bin/pkcs11/openssl-0.9.8l-patch</code></strong>
+$ <strong class="userinput"><code>patch -p1 -d openssl-0.9.8s \
+            &lt; bind9/bin/pkcs11/openssl-0.9.8s-patch</code></strong>
 </pre>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>(Note that the patch file may not be compatible with the
@@ -1489,7 +1492,7 @@ $ <strong class="userinput"><code>patch -p1 -d openssl-0.9.8l \
     when we configure BIND 9.</p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2608238"></a>Building OpenSSL for the AEP Keyper on Linux</h4></div></div></div>
+<a name="id2608302"></a>Building OpenSSL for the AEP Keyper on Linux</h4></div></div></div>
 <p>The AEP Keyper is a highly secure key storage device,
       but does not provide hardware cryptographic acceleration. It
       can carry out cryptographic operations, but it is probably
@@ -1508,7 +1511,7 @@ $ <strong class="userinput"><code>cp pkcs11.GCC4.0.2.so.4.05 /opt/pkcs11/usr/lib
 <p>Finally, the Keyper library requires threads, so we
       must specify -pthread.</p>
 <pre class="screen">
-$ <strong class="userinput"><code>cd openssl-0.9.8l</code></strong>
+$ <strong class="userinput"><code>cd openssl-0.9.8s</code></strong>
 $ <strong class="userinput"><code>./Configure linux-generic32 -m32 -pthread \
             --pk11-libname=/opt/pkcs11/usr/lib/libpkcs11.so \
             --pk11-flavor=sign-only \
@@ -1521,7 +1524,7 @@ $ <strong class="userinput"><code>./Configure linux-generic32 -m32 -pthread \
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2608376"></a>Building OpenSSL for the SCA 6000 on Solaris</h4></div></div></div>
+<a name="id2608850"></a>Building OpenSSL for the SCA 6000 on Solaris</h4></div></div></div>
 <p>The SCA-6000 PKCS #11 provider is installed as a system
       library, libpkcs11. It is a true crypto accelerator, up to 4
       times faster than any CPU, so the flavor shall be
@@ -1529,7 +1532,7 @@ $ <strong class="userinput"><code>./Configure linux-generic32 -m32 -pthread \
 <p>In this example, we are building on Solaris x86 on an
       AMD64 system.</p>
 <pre class="screen">
-$ <strong class="userinput"><code>cd openssl-0.9.8l</code></strong>
+$ <strong class="userinput"><code>cd openssl-0.9.8s</code></strong>
 $ <strong class="userinput"><code>./Configure solaris64-x86_64-cc \
             --pk11-libname=/usr/lib/64/libpkcs11.so \
             --pk11-flavor=crypto-accelerator \
@@ -1540,11 +1543,50 @@ $ <strong class="userinput"><code>./Configure solaris64-x86_64-cc \
 <p>After configuring, run 
       <span><strong class="command">make</strong></span> and 
       <span><strong class="command">make test</strong></span>.</p>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2608967"></a>Building OpenSSL for SoftHSM</h4></div></div></div>
+<p>SoftHSM is a software library provided by the OpenDNSSEC
+      project (http://www.opendnssec.org) which provides a PKCS#11
+      interface to a virtual HSM, implemented in the form of encrypted
+      data on the local filesystem.  It uses the Botan library for
+      encryption and SQLite3 for data storage.  Though less secure
+      than a true HSM, it can provide more secure key storage than
+      traditional key files, and can allow you to experiment with
+      PKCS#11 when an HSM is not available.</p>
+<p>The SoftHSM cryptographic store must be installed and
+      initialized before using it with OpenSSL, and the SOFTHSM_CONF
+      environment variable must always point to the SoftHSM configuration
+      file:</p>
+<pre class="screen">
+$ <strong class="userinput"><code> cd softhsm-1.3.0 </code></strong>
+$ <strong class="userinput"><code> configure --prefix=/opt/pkcs11/usr </code></strong>
+$ <strong class="userinput"><code> make </code></strong>
+$ <strong class="userinput"><code> make install </code></strong>
+$ <strong class="userinput"><code> export SOFTHSM_CONF=/opt/pkcs11/softhsm.conf </code></strong>
+$ <strong class="userinput"><code> echo "0:/opt/pkcs11/softhsm.db" &gt; $SOFTHSM_CONF </code></strong>
+$ <strong class="userinput"><code> /opt/pkcs11/usr/bin/softhsm --init-token 0 --slot 0 --label softhsm </code></strong>
+</pre>
+<p>SoftHSM can perform all cryptographic operations, but
+      since it only uses your system CPU, there is no need to use it
+      for anything but signing.  Therefore, we choose the 'sign-only'
+      flavor when building OpenSSL.</p>
+<pre class="screen">
+$ <strong class="userinput"><code>cd openssl-0.9.8s</code></strong>
+$ <strong class="userinput"><code>./Configure linux-x86_64 -pthread \
+            --pk11-libname=/opt/pkcs11/usr/lib/libpkcs11.so \
+            --pk11-flavor=sign-only \
+            --prefix=/opt/pkcs11/usr</code></strong>
+</pre>
+<p>After configuring, run "<span><strong class="command">make</strong></span>"
+      and "<span><strong class="command">make test</strong></span>".</p>
+</div>
 <p>Once you have built OpenSSL, run
-      "<span><strong class="command">apps/openssl engine pkcs11</strong></span>" to confirm
-      that PKCS #11 support was compiled in correctly. The output
-      should be one of the following lines, depending on the flavor
-      selected:</p>
+    "<span><strong class="command">apps/openssl engine pkcs11</strong></span>" to confirm
+    that PKCS #11 support was compiled in correctly. The output
+    should be one of the following lines, depending on the flavor
+    selected:</p>
 <pre class="screen">
         (pkcs11) PKCS #11 engine support (sign only)
 </pre>
@@ -1553,24 +1595,23 @@ $ <strong class="userinput"><code>./Configure solaris64-x86_64-cc \
         (pkcs11) PKCS #11 engine support (crypto accelerator)
 </pre>
 <p>Next, run
-      "<span><strong class="command">apps/openssl engine pkcs11 -t</strong></span>". This will
-      attempt to initialize the PKCS #11 engine. If it is able to
-      do so successfully, it will report
-      &#8220;<span class="quote"><code class="literal">[ available ]</code></span>&#8221;.</p>
+    "<span><strong class="command">apps/openssl engine pkcs11 -t</strong></span>". This will
+    attempt to initialize the PKCS #11 engine. If it is able to
+    do so successfully, it will report
+    &#8220;<span class="quote"><code class="literal">[ available ]</code></span>&#8221;.</p>
 <p>If the output is correct, run
-      "<span><strong class="command">make install</strong></span>" which will install the
-      modified OpenSSL suite to 
-      <code class="filename">/opt/pkcs11/usr</code>.</p>
-</div>
+    "<span><strong class="command">make install</strong></span>" which will install the
+    modified OpenSSL suite to 
+    <code class="filename">/opt/pkcs11/usr</code>.</p>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2608755"></a>Building BIND 9 with PKCS#11</h3></div></div></div>
+<a name="id2609255"></a>Building BIND 9 with PKCS#11</h3></div></div></div>
 <p>When building BIND 9, the location of the custom-built
     OpenSSL library must be specified via configure.</p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2608763"></a>Configuring BIND 9 for Linux</h4></div></div></div>
+<a name="id2609264"></a>Configuring BIND 9 for Linux with the AEP Keyper</h4></div></div></div>
 <p>To link with the PKCS #11 provider, threads must be
       enabled in the BIND 9 build.</p>
 <p>The PKCS #11 library for the AEP Keyper is currently
@@ -1578,7 +1619,7 @@ $ <strong class="userinput"><code>./Configure solaris64-x86_64-cc \
       64-bit host, we must force a 32-bit build by adding "-m32" to
       the CC options on the "configure" command line.</p>
 <pre class="screen">
-$ <strong class="userinput"><code>cd ../bind-9.7.0</code></strong>
+$ <strong class="userinput"><code>cd ../bind9</code></strong>
 $ <strong class="userinput"><code>./configure CC="gcc -m32" --enable-threads \
            --with-openssl=/opt/pkcs11/usr \
            --with-pkcs11=/opt/pkcs11/usr/lib/libpkcs11.so</code></strong>
@@ -1586,11 +1627,11 @@ $ <strong class="userinput"><code>./configure CC="gcc -m32" --enable-threads \
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2608794"></a>Configuring BIND 9 for Solaris</h4></div></div></div>
+<a name="id2611412"></a>Configuring BIND 9 for Solaris with the SCA 6000</h4></div></div></div>
 <p>To link with the PKCS #11 provider, threads must be
       enabled in the BIND 9 build.</p>
 <pre class="screen">
-$ <strong class="userinput"><code>cd ../bind-9.7.0</code></strong>
+$ <strong class="userinput"><code>cd ../bind9</code></strong>
 $ <strong class="userinput"><code>./configure CC="cc -xarch=amd64" --enable-threads \
             --with-openssl=/opt/pkcs11/usr \
             --with-pkcs11=/usr/lib/64/libpkcs11.so</code></strong>
@@ -1602,14 +1643,26 @@ $ <strong class="userinput"><code>./configure CC="cc -xarch=amd64" --enable-thre
       same as the --prefix argument to the OpenSSL
       Configure).</p>
 </div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2611448"></a>Configuring BIND 9 for SoftHSM</h4></div></div></div>
+<pre class="screen">
+$ <strong class="userinput"><code>cd ../bind9</code></strong>
+$ <strong class="userinput"><code>./configure --enable-threads \
+           --with-openssl=/opt/pkcs11/usr \
+           --with-pkcs11=/opt/pkcs11/usr/lib/libpkcs11.so</code></strong>
+</pre>
+</div>
 <p>After configuring, run
     "<span><strong class="command">make</strong></span>",
     "<span><strong class="command">make test</strong></span>" and
     "<span><strong class="command">make install</strong></span>".</p>
+<p>(Note: If "make test" fails in the "pkcs11" system test, you may
+    have forgotten to set the SOFTHSM_CONF environment variable.)</p>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2608850"></a>PKCS #11 Tools</h3></div></div></div>
+<a name="id2635799"></a>PKCS #11 Tools</h3></div></div></div>
 <p>BIND 9 includes a minimal set of tools to operate the
     HSM, including 
     <span><strong class="command">pkcs11-keygen</strong></span> to generate a new key pair
@@ -1627,7 +1680,7 @@ $ <strong class="userinput"><code>./configure CC="cc -xarch=amd64" --enable-thre
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2608881"></a>Using the HSM</h3></div></div></div>
+<a name="id2635830"></a>Using the HSM</h3></div></div></div>
 <p>First, we must set up the runtime environment so the
     OpenSSL and PKCS #11 libraries can be loaded:</p>
 <pre class="screen">
@@ -1715,7 +1768,7 @@ example.net.signed
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2611537"></a>Specifying the engine on the command line</h3></div></div></div>
+<a name="id2636097"></a>Specifying the engine on the command line</h3></div></div></div>
 <p>The OpenSSL engine can be specified in 
     <span><strong class="command">named</strong></span> and all of the BIND 
     <span><strong class="command">dnssec-*</strong></span> tools by using the "-E
@@ -1736,7 +1789,7 @@ $ <strong class="userinput"><code>dnssec-signzone -E '' -S example.net</code></s
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2611582"></a>Running named with automatic zone re-signing</h3></div></div></div>
+<a name="id2636142"></a>Running named with automatic zone re-signing</h3></div></div></div>
 <p>If you want 
     <span><strong class="command">named</strong></span> to dynamically re-sign zones using HSM
     keys, and/or to to sign new records inserted via nsupdate, then
@@ -1772,7 +1825,7 @@ $ <strong class="userinput"><code>dnssec-signzone -E '' -S example.net</code></s
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2572802"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
+<a name="id2572805"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
 <p>
         <acronym class="acronym">BIND</acronym> 9 fully supports all currently
         defined forms of IPv6 name to address and address to name
@@ -1810,7 +1863,7 @@ $ <strong class="userinput"><code>dnssec-signzone -E '' -S example.net</code></s
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2573068"></a>Address Lookups Using AAAA Records</h3></div></div></div>
+<a name="id2573003"></a>Address Lookups Using AAAA Records</h3></div></div></div>
 <p>
           The IPv6 AAAA record is a parallel to the IPv4 A record,
           and, unlike the deprecated A6 record, specifies the entire
@@ -1829,7 +1882,7 @@ host            3600    IN      AAAA    2001:db8::1
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2573090"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
+<a name="id2573025"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
 <p>
           When looking up an address in nibble format, the address
           components are simply reversed, just as in IPv4, and
diff --git a/doc/arm/Bv9ARM.ch05.html b/doc/arm/Bv9ARM.ch05.html
index be5c35b6..5b3f7ed5 100644
--- a/doc/arm/Bv9ARM.ch05.html
+++ b/doc/arm/Bv9ARM.ch05.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch05.html,v 1.100 2011-11-05 01:14:50 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch05.html,v 1.101 2012-01-07 01:14:55 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,13 +45,13 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2573123">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2573058">The Lightweight Resolver Library</a></span></dt>
 <dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
 </dl>
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2573123"></a>The Lightweight Resolver Library</h2></div></div></div>
+<a name="id2573058"></a>The Lightweight Resolver Library</h2></div></div></div>
 <p>
         Traditionally applications have been linked with a stub resolver
         library that sends recursive DNS queries to a local caching name
diff --git a/doc/arm/Bv9ARM.ch06.html b/doc/arm/Bv9ARM.ch06.html
index f5dfa4b4..2f92f213 100644
--- a/doc/arm/Bv9ARM.ch06.html
+++ b/doc/arm/Bv9ARM.ch06.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch06.html,v 1.301 2011-11-24 01:14:52 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch06.html,v 1.303 2012-01-16 01:14:57 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -48,58 +48,58 @@
 <dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574465">Comment Syntax</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574468">Comment Syntax</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575193"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575196"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575383"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575386"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575742"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575760"><span><strong class="command">include</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575746"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575763"><span><strong class="command">include</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575783"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575806"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575965"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576160"><span><strong class="command">logging</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575786"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575810"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575969"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576163"><span><strong class="command">logging</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578117"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578259"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578323"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578366"><span><strong class="command">masters</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578121"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578263"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578327"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578371"><span><strong class="command">masters</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578388"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578392"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and
           Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and
             Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#statschannels"><span><strong class="command">statistics-channels</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590061"><span><strong class="command">statistics-channels</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590137"><span><strong class="command">statistics-channels</strong></span> Statement Definition and
             Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#trusted-keys"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590201"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590277"><span><strong class="command">trusted-keys</strong></span> Statement Definition
             and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590248"><span><strong class="command">managed-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590324"><span><strong class="command">managed-keys</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#managed-keys"><span><strong class="command">managed-keys</strong></span> Statement Definition
             and Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590742"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590749"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
             Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592422"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592429"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2595920">Zone File</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2595995">Zone File</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2598082">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2598226">Discussion of MX Records</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2598697">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2598824">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2599029"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2598841">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2598968">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2599173"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch06.html#statistics">BIND9 Statistics</a></span></dt>
@@ -477,7 +477,7 @@
 <a name="address_match_lists"></a>Address Match Lists</h3></div></div></div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2574299"></a>Syntax</h4></div></div></div>
+<a name="id2574302"></a>Syntax</h4></div></div></div>
 <pre class="programlisting"><code class="varname">address_match_list</code> = address_match_list_element ;
   [<span class="optional"> address_match_list_element; ... </span>]
 <code class="varname">address_match_list_element</code> = [<span class="optional"> ! </span>] (ip_address [<span class="optional">/length</span>] |
@@ -486,7 +486,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2574327"></a>Definition and Usage</h4></div></div></div>
+<a name="id2574330"></a>Definition and Usage</h4></div></div></div>
 <p>
             Address match lists are primarily used to determine access
             control for various server operations. They are also used in
@@ -570,7 +570,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574465"></a>Comment Syntax</h3></div></div></div>
+<a name="id2574468"></a>Comment Syntax</h3></div></div></div>
 <p>
           The <acronym class="acronym">BIND</acronym> 9 comment syntax allows for
           comments to appear
@@ -580,7 +580,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2574616"></a>Syntax</h4></div></div></div>
+<a name="id2574551"></a>Syntax</h4></div></div></div>
 <p>
             </p>
 <pre class="programlisting">/* This is a <acronym class="acronym">BIND</acronym> comment as in C */</pre>
@@ -596,7 +596,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2574646"></a>Definition and Usage</h4></div></div></div>
+<a name="id2574581"></a>Definition and Usage</h4></div></div></div>
 <p>
             Comments may appear anywhere that whitespace may appear in
             a <acronym class="acronym">BIND</acronym> configuration file.
@@ -850,7 +850,7 @@
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2575193"></a><span><strong class="command">acl</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2575196"></a><span><strong class="command">acl</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">acl</strong></span> acl-name {
     address_match_list
 };
@@ -932,7 +932,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2575383"></a><span><strong class="command">controls</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2575386"></a><span><strong class="command">controls</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">controls</strong></span> {
    [ inet ( ip_addr | * ) [ port ip_port ]
                 allow { <em class="replaceable"><code> address_match_list </code></em> }
@@ -1056,12 +1056,12 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2575742"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2575746"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">include</strong></span> <em class="replaceable"><code>filename</code></em>;</pre>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2575760"></a><span><strong class="command">include</strong></span> Statement Definition and
+<a name="id2575763"></a><span><strong class="command">include</strong></span> Statement Definition and
           Usage</h3></div></div></div>
 <p>
           The <span><strong class="command">include</strong></span> statement inserts the
@@ -1076,7 +1076,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2575783"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2575786"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">key</strong></span> <em class="replaceable"><code>key_id</code></em> {
     algorithm <em class="replaceable"><code>string</code></em>;
     secret <em class="replaceable"><code>string</code></em>;
@@ -1085,7 +1085,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2575806"></a><span><strong class="command">key</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2575810"></a><span><strong class="command">key</strong></span> Statement Definition and Usage</h3></div></div></div>
 <p>
           The <span><strong class="command">key</strong></span> statement defines a shared
           secret key for use with TSIG (see <a href="Bv9ARM.ch04.html#tsig" title="TSIG">the section called &#8220;TSIG&#8221;</a>)
@@ -1132,7 +1132,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2575965"></a><span><strong class="command">logging</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2575969"></a><span><strong class="command">logging</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">logging</strong></span> {
    [ <span><strong class="command">channel</strong></span> <em class="replaceable"><code>channel_name</code></em> {
      ( <span><strong class="command">file</strong></span> <em class="replaceable"><code>path_name</code></em>
@@ -1156,7 +1156,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2576160"></a><span><strong class="command">logging</strong></span> Statement Definition and
+<a name="id2576163"></a><span><strong class="command">logging</strong></span> Statement Definition and
           Usage</h3></div></div></div>
 <p>
           The <span><strong class="command">logging</strong></span> statement configures a
@@ -1190,7 +1190,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2576212"></a>The <span><strong class="command">channel</strong></span> Phrase</h4></div></div></div>
+<a name="id2576215"></a>The <span><strong class="command">channel</strong></span> Phrase</h4></div></div></div>
 <p>
             All log output goes to one or more <span class="emphasis"><em>channels</em></span>;
             you can make as many of them as you want.
@@ -1651,10 +1651,16 @@ category notify { null; };
                     </p>
 
                     <p>
-                      <code class="computeroutput">client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</code>
+                      <code class="computeroutput">client 127.0.0.1#62536 (www.example.com): query: www.example.com IN AAAA +SE</code>
                     </p>
                     <p>
-                      <code class="computeroutput">client ::1#62537: query: www.example.net IN AAAA -SE</code>
+                      <code class="computeroutput">client ::1#62537 (www.example.net): query: www.example.net IN AAAA -SE</code>
+                    </p>
+                    <p>
+                      (The first part of this log message, showing the
+                      client address/port number and query name, is
+                      repeated in all subsequent log messages related
+                      to the same query.)
                     </p>
                   </td>
 </tr>
@@ -1768,7 +1774,7 @@ category notify { null; };
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2577597"></a>The <span><strong class="command">query-errors</strong></span> Category</h4></div></div></div>
+<a name="id2577670"></a>The <span><strong class="command">query-errors</strong></span> Category</h4></div></div></div>
 <p>
             The <span><strong class="command">query-errors</strong></span> category is
             specifically intended for debugging purposes: To identify
@@ -1996,7 +2002,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2578117"></a><span><strong class="command">lwres</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2578121"></a><span><strong class="command">lwres</strong></span> Statement Grammar</h3></div></div></div>
 <p>
            This is the grammar of the <span><strong class="command">lwres</strong></span>
           statement in the <code class="filename">named.conf</code> file:
@@ -2012,7 +2018,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2578259"></a><span><strong class="command">lwres</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2578263"></a><span><strong class="command">lwres</strong></span> Statement Definition and Usage</h3></div></div></div>
 <p>
           The <span><strong class="command">lwres</strong></span> statement configures the
           name
@@ -2063,7 +2069,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2578323"></a><span><strong class="command">masters</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2578327"></a><span><strong class="command">masters</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting">
 <span><strong class="command">masters</strong></span> <em class="replaceable"><code>name</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] { ( <em class="replaceable"><code>masters_list</code></em> | 
       <em class="replaceable"><code>ip_addr</code></em> [<span class="optional">port <em class="replaceable"><code>ip_port</code></em></span>] [<span class="optional">key <em class="replaceable"><code>key</code></em></span>] ) ; [<span class="optional">...</span>] };
@@ -2071,7 +2077,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2578366"></a><span><strong class="command">masters</strong></span> Statement Definition and
+<a name="id2578371"></a><span><strong class="command">masters</strong></span> Statement Definition and
           Usage</h3></div></div></div>
 <p><span><strong class="command">masters</strong></span>
           lists allow for a common set of masters to be easily used by
@@ -2081,7 +2087,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2578388"></a><span><strong class="command">options</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2578392"></a><span><strong class="command">options</strong></span> Statement Grammar</h3></div></div></div>
 <p>
           This is the grammar of the <span><strong class="command">options</strong></span>
           statement in the <code class="filename">named.conf</code> file:
@@ -3718,7 +3724,7 @@ options {
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2584052"></a>Forwarding</h4></div></div></div>
+<a name="id2584056"></a>Forwarding</h4></div></div></div>
 <p>
             The forwarding facility can be used to create a large site-wide
             cache on a few servers, reducing traffic over links to external
@@ -3762,7 +3768,7 @@ options {
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2584179"></a>Dual-stack Servers</h4></div></div></div>
+<a name="id2584183"></a>Dual-stack Servers</h4></div></div></div>
 <p>
             Dual-stack servers are used as servers of last resort to work
             around
@@ -3973,7 +3979,7 @@ options {
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2584798"></a>Interfaces</h4></div></div></div>
+<a name="id2584734"></a>Interfaces</h4></div></div></div>
 <p>
             The interfaces and ports that the server will answer queries
             from may be specified using the <span><strong class="command">listen-on</strong></span> option. <span><strong class="command">listen-on</strong></span> takes
@@ -4441,7 +4447,7 @@ avoid-v6-udp-ports {};
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2586016"></a>UDP Port Lists</h4></div></div></div>
+<a name="id2585952"></a>UDP Port Lists</h4></div></div></div>
 <p>
             <span><strong class="command">use-v4-udp-ports</strong></span>,
             <span><strong class="command">avoid-v4-udp-ports</strong></span>,
@@ -4483,7 +4489,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2586075"></a>Operating System Resource Limits</h4></div></div></div>
+<a name="id2586080"></a>Operating System Resource Limits</h4></div></div></div>
 <p>
             The server's usage of many system resources can be limited.
             Scaled values are allowed when specifying resource limits.  For
@@ -4645,7 +4651,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2586566"></a>Periodic Task Intervals</h4></div></div></div>
+<a name="id2586638"></a>Periodic Task Intervals</h4></div></div></div>
 <div class="variablelist"><dl>
 <dt><span class="term"><span><strong class="command">cleaning-interval</strong></span></span></dt>
 <dd><p>
@@ -4947,8 +4953,10 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
           </p>
 <p>
             If multiple <span><strong class="command">rrset-order</strong></span> statements
-            appear,
-            they are not combined &#8212; the last one applies.
+            appear, they are not combined &#8212; the last one applies.
+          </p>
+<p>
+            By default, all records are returned in random order.
           </p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
@@ -5501,7 +5509,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2588632"></a>Content Filtering</h4></div></div></div>
+<a name="id2588640"></a>Content Filtering</h4></div></div></div>
 <p>
             <acronym class="acronym">BIND</acronym> 9 provides the ability to filter
             out DNS responses from external DNS servers containing
@@ -5624,7 +5632,7 @@ deny-answer-aliases { "example.net"; };
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2588823"></a>Response Policy Zone (RPZ) Rewriting</h4></div></div></div>
+<a name="id2588899"></a>Response Policy Zone (RPZ) Rewriting</h4></div></div></div>
 <p>
             <acronym class="acronym">BIND</acronym> 9 includes an intentionally limited
             mechanism to modify DNS responses for recursive requests
@@ -6060,7 +6068,7 @@ ns.domain.com.rpz-nsdname   CNAME   .
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2590061"></a><span><strong class="command">statistics-channels</strong></span> Statement Definition and
+<a name="id2590137"></a><span><strong class="command">statistics-channels</strong></span> Statement Definition and
             Usage</h3></div></div></div>
 <p>
           The <span><strong class="command">statistics-channels</strong></span> statement
@@ -6120,7 +6128,7 @@ ns.domain.com.rpz-nsdname   CNAME   .
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2590201"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<a name="id2590277"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition
             and Usage</h3></div></div></div>
 <p>
             The <span><strong class="command">trusted-keys</strong></span> statement defines
@@ -6160,7 +6168,7 @@ ns.domain.com.rpz-nsdname   CNAME   .
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2590248"></a><span><strong class="command">managed-keys</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2590324"></a><span><strong class="command">managed-keys</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">managed-keys</strong></span> {
     <em class="replaceable"><code>string</code></em> initial-key <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ;
     [<span class="optional"> <em class="replaceable"><code>string</code></em> initial-key <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>number</code></em> <em class="replaceable"><code>string</code></em> ; [<span class="optional">...</span>]</span>]
@@ -6295,7 +6303,7 @@ ns.domain.com.rpz-nsdname   CNAME   .
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2590742"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2590749"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div>
 <p>
             The <span><strong class="command">view</strong></span> statement is a powerful
             feature
@@ -6596,10 +6604,10 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2592422"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2592429"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2592429"></a>Zone Types</h4></div></div></div>
+<a name="id2592437"></a>Zone Types</h4></div></div></div>
 <div class="informaltable"><table border="1">
 <colgroup>
 <col>
@@ -6879,7 +6887,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2593006"></a>Class</h4></div></div></div>
+<a name="id2593014"></a>Class</h4></div></div></div>
 <p>
               The zone's name may optionally be followed by a class. If
               a class is not specified, class <code class="literal">IN</code> (for <code class="varname">Internet</code>),
@@ -6901,7 +6909,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2593040"></a>Zone Options</h4></div></div></div>
+<a name="id2593115"></a>Zone Options</h4></div></div></div>
 <div class="variablelist"><dl>
 <dt><span class="term"><span><strong class="command">allow-notify</strong></span></span></dt>
 <dd><p>
@@ -7812,7 +7820,7 @@ example.com. NS ns2.example.net.
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2595920"></a>Zone File</h2></div></div></div>
+<a name="id2595995"></a>Zone File</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="types_of_resource_records_and_when_to_use_them"></a>Types of Resource Records and When to Use Them</h3></div></div></div>
@@ -7825,7 +7833,7 @@ example.com. NS ns2.example.net.
           </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2595938"></a>Resource Records</h4></div></div></div>
+<a name="id2596013"></a>Resource Records</h4></div></div></div>
 <p>
               A domain name identifies a node.  Each node has a set of
               resource information, which may be empty.  The set of resource
@@ -8562,7 +8570,7 @@ example.com. NS ns2.example.net.
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2597561"></a>Textual expression of RRs</h4></div></div></div>
+<a name="id2597637"></a>Textual expression of RRs</h4></div></div></div>
 <p>
               RRs are represented in binary form in the packets of the DNS
               protocol, and are usually represented in highly encoded form
@@ -8765,7 +8773,7 @@ example.com. NS ns2.example.net.
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2598082"></a>Discussion of MX Records</h3></div></div></div>
+<a name="id2598226"></a>Discussion of MX Records</h3></div></div></div>
 <p>
             As described above, domain servers store information as a
             series of resource records, each of which contains a particular
@@ -9021,7 +9029,7 @@ example.com. NS ns2.example.net.
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2598697"></a>Inverse Mapping in IPv4</h3></div></div></div>
+<a name="id2598841"></a>Inverse Mapping in IPv4</h3></div></div></div>
 <p>
             Reverse name resolution (that is, translation from IP address
             to name) is achieved by means of the <span class="emphasis"><em>in-addr.arpa</em></span> domain
@@ -9082,7 +9090,7 @@ example.com. NS ns2.example.net.
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2598824"></a>Other Zone File Directives</h3></div></div></div>
+<a name="id2598968"></a>Other Zone File Directives</h3></div></div></div>
 <p>
             The Master File Format was initially defined in RFC 1035 and
             has subsequently been extended. While the Master File Format
@@ -9097,7 +9105,7 @@ example.com. NS ns2.example.net.
           </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2598846"></a>The <span><strong class="command">@</strong></span> (at-sign)</h4></div></div></div>
+<a name="id2598990"></a>The <span><strong class="command">@</strong></span> (at-sign)</h4></div></div></div>
 <p>
               When used in the label (or name) field, the asperand or
               at-sign (@) symbol represents the current origin.
@@ -9108,7 +9116,7 @@ example.com. NS ns2.example.net.
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2598862"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div>
+<a name="id2599006"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div>
 <p>
               Syntax: <span><strong class="command">$ORIGIN</strong></span>
               <em class="replaceable"><code>domain-name</code></em>
@@ -9137,7 +9145,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2598923"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div>
+<a name="id2599067"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div>
 <p>
               Syntax: <span><strong class="command">$INCLUDE</strong></span>
               <em class="replaceable"><code>filename</code></em>
@@ -9173,7 +9181,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2598993"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div>
+<a name="id2599137"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div>
 <p>
               Syntax: <span><strong class="command">$TTL</strong></span>
               <em class="replaceable"><code>default-ttl</code></em>
@@ -9192,7 +9200,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2599029"></a><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div>
+<a name="id2599173"></a><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div>
 <p>
             Syntax: <span><strong class="command">$GENERATE</strong></span>
             <em class="replaceable"><code>range</code></em>
@@ -9616,7 +9624,7 @@ HOST-127.EXAMPLE. MX 0 .
           </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2600119"></a>Name Server Statistics Counters</h4></div></div></div>
+<a name="id2600263"></a>Name Server Statistics Counters</h4></div></div></div>
 <div class="informaltable"><table border="1">
 <colgroup>
 <col>
@@ -10173,7 +10181,7 @@ HOST-127.EXAMPLE. MX 0 .
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2601660"></a>Zone Maintenance Statistics Counters</h4></div></div></div>
+<a name="id2601804"></a>Zone Maintenance Statistics Counters</h4></div></div></div>
 <div class="informaltable"><table border="1">
 <colgroup>
 <col>
@@ -10327,7 +10335,7 @@ HOST-127.EXAMPLE. MX 0 .
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2602043"></a>Resolver Statistics Counters</h4></div></div></div>
+<a name="id2602187"></a>Resolver Statistics Counters</h4></div></div></div>
 <div class="informaltable"><table border="1">
 <colgroup>
 <col>
@@ -10710,7 +10718,7 @@ HOST-127.EXAMPLE. MX 0 .
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2603133"></a>Socket I/O Statistics Counters</h4></div></div></div>
+<a name="id2603277"></a>Socket I/O Statistics Counters</h4></div></div></div>
 <p>
               Socket I/O statistics counters are defined per socket
               types, which are
@@ -10865,7 +10873,7 @@ HOST-127.EXAMPLE. MX 0 .
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2603575"></a>Compatibility with <span class="emphasis"><em>BIND</em></span> 8 Counters</h4></div></div></div>
+<a name="id2603719"></a>Compatibility with <span class="emphasis"><em>BIND</em></span> 8 Counters</h4></div></div></div>
 <p>
               Most statistics counters that were available
               in <span><strong class="command">BIND</strong></span> 8 are also supported in
diff --git a/doc/arm/Bv9ARM.ch07.html b/doc/arm/Bv9ARM.ch07.html
index 2901a145..a998a0d2 100644
--- a/doc/arm/Bv9ARM.ch07.html
+++ b/doc/arm/Bv9ARM.ch07.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch07.html,v 1.264 2011-11-07 01:15:04 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch07.html,v 1.266 2012-01-16 01:14:57 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -46,10 +46,10 @@
 <p><b>Table of Contents</b></p>
 <dl>
 <dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2603817"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2603961"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2603898">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2603958">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2604042">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2604102">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
 </dl>
@@ -121,7 +121,7 @@ zone "example.com" {
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2603817"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span>
+<a name="id2603961"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span>
 </h2></div></div></div>
 <p>
           On UNIX servers, it is possible to run <acronym class="acronym">BIND</acronym>
@@ -147,7 +147,7 @@ zone "example.com" {
         </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2603898"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
+<a name="id2604042"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
 <p>
             In order for a <span><strong class="command">chroot</strong></span> environment
             to
@@ -175,7 +175,7 @@ zone "example.com" {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2603958"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
+<a name="id2604102"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
 <p>
             Prior to running the <span><strong class="command">named</strong></span> daemon,
             use
diff --git a/doc/arm/Bv9ARM.ch08.html b/doc/arm/Bv9ARM.ch08.html
index 8f8289ec..74139602 100644
--- a/doc/arm/Bv9ARM.ch08.html
+++ b/doc/arm/Bv9ARM.ch08.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch08.html,v 1.265 2011-11-07 01:15:05 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch08.html,v 1.267 2012-01-16 01:14:57 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,18 +45,18 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2604038">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2604043">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2604055">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2604072">Where Can I Get Help?</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2604182">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2604187">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2604199">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2604216">Where Can I Get Help?</a></span></dt>
 </dl>
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2604038"></a>Common Problems</h2></div></div></div>
+<a name="id2604182"></a>Common Problems</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2604043"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div>
+<a name="id2604187"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div>
 <p>
             The best solution to solving installation and
             configuration issues is to take preventative measures by setting
@@ -68,7 +68,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2604055"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
+<a name="id2604199"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
 <p>
           Zone serial numbers are just numbers &#8212; they aren't
           date related.  A lot of people set them to a number that
@@ -95,7 +95,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2604072"></a>Where Can I Get Help?</h2></div></div></div>
+<a name="id2604216"></a>Where Can I Get Help?</h2></div></div></div>
 <p>
           The Internet Systems Consortium
           (<acronym class="acronym">ISC</acronym>) offers a wide range
diff --git a/doc/arm/Bv9ARM.ch09.html b/doc/arm/Bv9ARM.ch09.html
index dbfacfc5..8ef09474 100644
--- a/doc/arm/Bv9ARM.ch09.html
+++ b/doc/arm/Bv9ARM.ch09.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch09.html,v 1.270 2011-11-24 01:14:52 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch09.html,v 1.273 2012-01-17 01:15:02 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,31 +45,31 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2604134">Acknowledgments</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2604278">Acknowledgments</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2604442">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2604654">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2607654">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2607866">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch09.html#bind9.library">BIND 9 DNS Library Support</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609046">Prerequisite</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609056">Compilation</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609080">Installation</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609179">Known Defects/Restrictions</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609256">The dns.conf File</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609283">Sample Applications</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2610256">Library References</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609315">Prerequisite</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609324">Compilation</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609349">Installation</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609380">Known Defects/Restrictions</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609457">The dns.conf File</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609483">Sample Applications</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2610593">Library References</a></span></dt>
 </dl></dd>
 </dl>
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2604134"></a>Acknowledgments</h2></div></div></div>
+<a name="id2604278"></a>Acknowledgments</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="historical_dns_information"></a>A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym>
@@ -172,7 +172,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2604442"></a>General <acronym class="acronym">DNS</acronym> Reference Information</h2></div></div></div>
+<a name="id2604654"></a>General <acronym class="acronym">DNS</acronym> Reference Information</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="ipv6addresses"></a>IPv6 addresses (AAAA)</h3></div></div></div>
@@ -260,17 +260,17 @@
           </p>
 <div class="bibliography">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2604562"></a>Bibliography</h4></div></div></div>
+<a name="id2604774"></a>Bibliography</h4></div></div></div>
 <div class="bibliodiv">
 <h3 class="title">Standards</h3>
 <div class="biblioentry">
-<a name="id2604572"></a><p>[<abbr class="abbrev">RFC974</abbr>] <span class="author"><span class="firstname">C.</span> <span class="surname">Partridge</span>. </span><span class="title"><i>Mail Routing and the Domain System</i>. </span><span class="pubdate">January 1986. </span></p>
+<a name="id2604853"></a><p>[<abbr class="abbrev">RFC974</abbr>] <span class="author"><span class="firstname">C.</span> <span class="surname">Partridge</span>. </span><span class="title"><i>Mail Routing and the Domain System</i>. </span><span class="pubdate">January 1986. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2604664"></a><p>[<abbr class="abbrev">RFC1034</abbr>] <span class="author"><span class="firstname">P.V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Concepts and Facilities</i>. </span><span class="pubdate">November 1987. </span></p>
+<a name="id2604876"></a><p>[<abbr class="abbrev">RFC1034</abbr>] <span class="author"><span class="firstname">P.V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Concepts and Facilities</i>. </span><span class="pubdate">November 1987. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2604688"></a><p>[<abbr class="abbrev">RFC1035</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Implementation and
+<a name="id2604900"></a><p>[<abbr class="abbrev">RFC1035</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Implementation and
                   Specification</i>. </span><span class="pubdate">November 1987. </span></p>
 </div>
 </div>
@@ -278,42 +278,42 @@
 <h3 class="title">
 <a name="proposed_standards"></a>Proposed Standards</h3>
 <div class="biblioentry">
-<a name="id2604724"></a><p>[<abbr class="abbrev">RFC2181</abbr>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <acronym class="acronym">DNS</acronym>
+<a name="id2605004"></a><p>[<abbr class="abbrev">RFC2181</abbr>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <acronym class="acronym">DNS</acronym>
                   Specification</i>. </span><span class="pubdate">July 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2604750"></a><p>[<abbr class="abbrev">RFC2308</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <acronym class="acronym">DNS</acronym>
+<a name="id2605031"></a><p>[<abbr class="abbrev">RFC2308</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <acronym class="acronym">DNS</acronym>
                   Queries</i>. </span><span class="pubdate">March 1998. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2604776"></a><p>[<abbr class="abbrev">RFC1995</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">August 1996. </span></p>
+<a name="id2605057"></a><p>[<abbr class="abbrev">RFC1995</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">August 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2604801"></a><p>[<abbr class="abbrev">RFC1996</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A Mechanism for Prompt Notification of Zone Changes</i>. </span><span class="pubdate">August 1996. </span></p>
+<a name="id2605081"></a><p>[<abbr class="abbrev">RFC1996</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A Mechanism for Prompt Notification of Zone Changes</i>. </span><span class="pubdate">August 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2604824"></a><p>[<abbr class="abbrev">RFC2136</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">Y.</span> <span class="surname">Rekhter</span>, and <span class="firstname">J.</span> <span class="surname">Bound</span>. </span><span class="title"><i>Dynamic Updates in the Domain Name System</i>. </span><span class="pubdate">April 1997. </span></p>
+<a name="id2605105"></a><p>[<abbr class="abbrev">RFC2136</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">Y.</span> <span class="surname">Rekhter</span>, and <span class="firstname">J.</span> <span class="surname">Bound</span>. </span><span class="title"><i>Dynamic Updates in the Domain Name System</i>. </span><span class="pubdate">April 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2604880"></a><p>[<abbr class="abbrev">RFC2671</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Extension Mechanisms for DNS (EDNS0)</i>. </span><span class="pubdate">August 1997. </span></p>
+<a name="id2605160"></a><p>[<abbr class="abbrev">RFC2671</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Extension Mechanisms for DNS (EDNS0)</i>. </span><span class="pubdate">August 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2604906"></a><p>[<abbr class="abbrev">RFC2672</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Non-Terminal DNS Name Redirection</i>. </span><span class="pubdate">August 1999. </span></p>
+<a name="id2605187"></a><p>[<abbr class="abbrev">RFC2672</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Non-Terminal DNS Name Redirection</i>. </span><span class="pubdate">August 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2604933"></a><p>[<abbr class="abbrev">RFC2845</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>, <span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, and <span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secret Key Transaction Authentication for <acronym class="acronym">DNS</acronym> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p>
+<a name="id2605213"></a><p>[<abbr class="abbrev">RFC2845</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>, <span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, and <span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secret Key Transaction Authentication for <acronym class="acronym">DNS</acronym> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2604995"></a><p>[<abbr class="abbrev">RFC2930</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secret Key Establishment for DNS (TKEY RR)</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2605275"></a><p>[<abbr class="abbrev">RFC2930</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secret Key Establishment for DNS (TKEY RR)</i>. </span><span class="pubdate">September 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605025"></a><p>[<abbr class="abbrev">RFC2931</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DNS Request and Transaction Signatures (SIG(0)s)</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2605305"></a><p>[<abbr class="abbrev">RFC2931</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DNS Request and Transaction Signatures (SIG(0)s)</i>. </span><span class="pubdate">September 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605054"></a><p>[<abbr class="abbrev">RFC3007</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secure Domain Name System (DNS) Dynamic Update</i>. </span><span class="pubdate">November 2000. </span></p>
+<a name="id2605335"></a><p>[<abbr class="abbrev">RFC3007</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secure Domain Name System (DNS) Dynamic Update</i>. </span><span class="pubdate">November 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605081"></a><p>[<abbr class="abbrev">RFC3645</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Kwan</span>, <span class="firstname">P.</span> <span class="surname">Garg</span>, <span class="firstname">J.</span> <span class="surname">Gilroy</span>, <span class="firstname">L.</span> <span class="surname">Esibov</span>, <span class="firstname">J.</span> <span class="surname">Westhead</span>, and <span class="firstname">R.</span> <span class="surname">Hall</span>. </span><span class="title"><i>Generic Security Service Algorithm for Secret
+<a name="id2605362"></a><p>[<abbr class="abbrev">RFC3645</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Kwan</span>, <span class="firstname">P.</span> <span class="surname">Garg</span>, <span class="firstname">J.</span> <span class="surname">Gilroy</span>, <span class="firstname">L.</span> <span class="surname">Esibov</span>, <span class="firstname">J.</span> <span class="surname">Westhead</span>, and <span class="firstname">R.</span> <span class="surname">Hall</span>. </span><span class="title"><i>Generic Security Service Algorithm for Secret
                        Key Transaction Authentication for DNS
                        (GSS-TSIG)</i>. </span><span class="pubdate">October 2003. </span></p>
 </div>
@@ -322,19 +322,19 @@
 <h3 class="title">
 <acronym class="acronym">DNS</acronym> Security Proposed Standards</h3>
 <div class="biblioentry">
-<a name="id2605163"></a><p>[<abbr class="abbrev">RFC3225</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Conrad</span>. </span><span class="title"><i>Indicating Resolver Support of DNSSEC</i>. </span><span class="pubdate">December 2001. </span></p>
+<a name="id2605444"></a><p>[<abbr class="abbrev">RFC3225</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Conrad</span>. </span><span class="title"><i>Indicating Resolver Support of DNSSEC</i>. </span><span class="pubdate">December 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605190"></a><p>[<abbr class="abbrev">RFC3833</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Atkins</span> and <span class="firstname">R.</span> <span class="surname">Austein</span>. </span><span class="title"><i>Threat Analysis of the Domain Name System (DNS)</i>. </span><span class="pubdate">August 2004. </span></p>
+<a name="id2605470"></a><p>[<abbr class="abbrev">RFC3833</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Atkins</span> and <span class="firstname">R.</span> <span class="surname">Austein</span>. </span><span class="title"><i>Threat Analysis of the Domain Name System (DNS)</i>. </span><span class="pubdate">August 2004. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605226"></a><p>[<abbr class="abbrev">RFC4033</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>DNS Security Introduction and Requirements</i>. </span><span class="pubdate">March 2005. </span></p>
+<a name="id2605507"></a><p>[<abbr class="abbrev">RFC4033</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>DNS Security Introduction and Requirements</i>. </span><span class="pubdate">March 2005. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605291"></a><p>[<abbr class="abbrev">RFC4034</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Resource Records for the DNS Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
+<a name="id2605572"></a><p>[<abbr class="abbrev">RFC4034</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Resource Records for the DNS Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605356"></a><p>[<abbr class="abbrev">RFC4035</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Protocol Modifications for the DNS
+<a name="id2605637"></a><p>[<abbr class="abbrev">RFC4035</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Protocol Modifications for the DNS
                        Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
 </div>
 </div>
@@ -342,146 +342,146 @@
 <h3 class="title">Other Important RFCs About <acronym class="acronym">DNS</acronym>
                 Implementation</h3>
 <div class="biblioentry">
-<a name="id2605430"></a><p>[<abbr class="abbrev">RFC1535</abbr>] <span class="author"><span class="firstname">E.</span> <span class="surname">Gavron</span>. </span><span class="title"><i>A Security Problem and Proposed Correction With Widely
+<a name="id2605710"></a><p>[<abbr class="abbrev">RFC1535</abbr>] <span class="author"><span class="firstname">E.</span> <span class="surname">Gavron</span>. </span><span class="title"><i>A Security Problem and Proposed Correction With Widely
                   Deployed <acronym class="acronym">DNS</acronym> Software.</i>. </span><span class="pubdate">October 1993. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605456"></a><p>[<abbr class="abbrev">RFC1536</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Kumar</span>, <span class="firstname">J.</span> <span class="surname">Postel</span>, <span class="firstname">C.</span> <span class="surname">Neuman</span>, <span class="firstname">P.</span> <span class="surname">Danzig</span>, and <span class="firstname">S.</span> <span class="surname">Miller</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Implementation
+<a name="id2605736"></a><p>[<abbr class="abbrev">RFC1536</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Kumar</span>, <span class="firstname">J.</span> <span class="surname">Postel</span>, <span class="firstname">C.</span> <span class="surname">Neuman</span>, <span class="firstname">P.</span> <span class="surname">Danzig</span>, and <span class="firstname">S.</span> <span class="surname">Miller</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Implementation
                   Errors and Suggested Fixes</i>. </span><span class="pubdate">October 1993. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605524"></a><p>[<abbr class="abbrev">RFC1982</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Elz</span> and <span class="firstname">R.</span> <span class="surname">Bush</span>. </span><span class="title"><i>Serial Number Arithmetic</i>. </span><span class="pubdate">August 1996. </span></p>
+<a name="id2605804"></a><p>[<abbr class="abbrev">RFC1982</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Elz</span> and <span class="firstname">R.</span> <span class="surname">Bush</span>. </span><span class="title"><i>Serial Number Arithmetic</i>. </span><span class="pubdate">August 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605559"></a><p>[<abbr class="abbrev">RFC4074</abbr>] <span class="authorgroup"><span class="firstname">Y.</span> <span class="surname">Morishita</span> and <span class="firstname">T.</span> <span class="surname">Jinmei</span>. </span><span class="title"><i>Common Misbehaviour Against <acronym class="acronym">DNS</acronym>
+<a name="id2605840"></a><p>[<abbr class="abbrev">RFC4074</abbr>] <span class="authorgroup"><span class="firstname">Y.</span> <span class="surname">Morishita</span> and <span class="firstname">T.</span> <span class="surname">Jinmei</span>. </span><span class="title"><i>Common Misbehaviour Against <acronym class="acronym">DNS</acronym>
                 Queries for IPv6 Addresses</i>. </span><span class="pubdate">May 2005. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">Resource Record Types</h3>
 <div class="biblioentry">
-<a name="id2605605"></a><p>[<abbr class="abbrev">RFC1183</abbr>] <span class="authorgroup"><span class="firstname">C.F.</span> <span class="surname">Everhart</span>, <span class="firstname">L. A.</span> <span class="surname">Mamakos</span>, <span class="firstname">R.</span> <span class="surname">Ullmann</span>, and <span class="firstname">P.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>New <acronym class="acronym">DNS</acronym> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p>
+<a name="id2605885"></a><p>[<abbr class="abbrev">RFC1183</abbr>] <span class="authorgroup"><span class="firstname">C.F.</span> <span class="surname">Everhart</span>, <span class="firstname">L. A.</span> <span class="surname">Mamakos</span>, <span class="firstname">R.</span> <span class="surname">Ullmann</span>, and <span class="firstname">P.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>New <acronym class="acronym">DNS</acronym> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605662"></a><p>[<abbr class="abbrev">RFC1706</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">R.</span> <span class="surname">Colella</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p>
+<a name="id2605943"></a><p>[<abbr class="abbrev">RFC1706</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">R.</span> <span class="surname">Colella</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605700"></a><p>[<abbr class="abbrev">RFC2168</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Daniel</span> and <span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="title"><i>Resolution of Uniform Resource Identifiers using
+<a name="id2605980"></a><p>[<abbr class="abbrev">RFC2168</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Daniel</span> and <span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="title"><i>Resolution of Uniform Resource Identifiers using
                   the Domain Name System</i>. </span><span class="pubdate">June 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605735"></a><p>[<abbr class="abbrev">RFC1876</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Davis</span>, <span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">T.</span>, and <span class="firstname">I.</span> <span class="surname">Dickinson</span>. </span><span class="title"><i>A Means for Expressing Location Information in the
+<a name="id2606016"></a><p>[<abbr class="abbrev">RFC1876</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Davis</span>, <span class="firstname">P.</span> <span class="surname">Vixie</span>, <span class="firstname">T.</span>, and <span class="firstname">I.</span> <span class="surname">Dickinson</span>. </span><span class="title"><i>A Means for Expressing Location Information in the
                   Domain
                   Name System</i>. </span><span class="pubdate">January 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605858"></a><p>[<abbr class="abbrev">RFC2052</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A <acronym class="acronym">DNS</acronym> RR for Specifying the
+<a name="id2606070"></a><p>[<abbr class="abbrev">RFC2052</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>A <acronym class="acronym">DNS</acronym> RR for Specifying the
                   Location of
                   Services.</i>. </span><span class="pubdate">October 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605896"></a><p>[<abbr class="abbrev">RFC2163</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <acronym class="acronym">DNS</acronym> to
+<a name="id2606108"></a><p>[<abbr class="abbrev">RFC2163</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <acronym class="acronym">DNS</acronym> to
                   Distribute MIXER
                   Conformant Global Address Mapping</i>. </span><span class="pubdate">January 1998. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605922"></a><p>[<abbr class="abbrev">RFC2230</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">October 1997. </span></p>
+<a name="id2606134"></a><p>[<abbr class="abbrev">RFC2230</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">October 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605947"></a><p>[<abbr class="abbrev">RFC2536</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DSA KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2606160"></a><p>[<abbr class="abbrev">RFC2536</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DSA KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2605974"></a><p>[<abbr class="abbrev">RFC2537</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2606186"></a><p>[<abbr class="abbrev">RFC2537</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606001"></a><p>[<abbr class="abbrev">RFC2538</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Storing Certificates in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2606213"></a><p>[<abbr class="abbrev">RFC2538</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Storing Certificates in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606040"></a><p>[<abbr class="abbrev">RFC2539</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2606252"></a><p>[<abbr class="abbrev">RFC2539</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606070"></a><p>[<abbr class="abbrev">RFC2540</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Detached Domain Name System (DNS) Information</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2606282"></a><p>[<abbr class="abbrev">RFC2540</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Detached Domain Name System (DNS) Information</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606100"></a><p>[<abbr class="abbrev">RFC2782</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span>. </span><span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="author"><span class="firstname">L.</span> <span class="surname">Esibov</span>. </span><span class="title"><i>A DNS RR for specifying the location of services (DNS SRV)</i>. </span><span class="pubdate">February 2000. </span></p>
+<a name="id2606312"></a><p>[<abbr class="abbrev">RFC2782</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span>. </span><span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="author"><span class="firstname">L.</span> <span class="surname">Esibov</span>. </span><span class="title"><i>A DNS RR for specifying the location of services (DNS SRV)</i>. </span><span class="pubdate">February 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606142"></a><p>[<abbr class="abbrev">RFC2915</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="author"><span class="firstname">R.</span> <span class="surname">Daniel</span>. </span><span class="title"><i>The Naming Authority Pointer (NAPTR) DNS Resource Record</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2606355"></a><p>[<abbr class="abbrev">RFC2915</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="author"><span class="firstname">R.</span> <span class="surname">Daniel</span>. </span><span class="title"><i>The Naming Authority Pointer (NAPTR) DNS Resource Record</i>. </span><span class="pubdate">September 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606176"></a><p>[<abbr class="abbrev">RFC3110</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</i>. </span><span class="pubdate">May 2001. </span></p>
+<a name="id2606388"></a><p>[<abbr class="abbrev">RFC3110</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</i>. </span><span class="pubdate">May 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606202"></a><p>[<abbr class="abbrev">RFC3123</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Koch</span>. </span><span class="title"><i>A DNS RR Type for Lists of Address Prefixes (APL RR)</i>. </span><span class="pubdate">June 2001. </span></p>
+<a name="id2606414"></a><p>[<abbr class="abbrev">RFC3123</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Koch</span>. </span><span class="title"><i>A DNS RR Type for Lists of Address Prefixes (APL RR)</i>. </span><span class="pubdate">June 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606226"></a><p>[<abbr class="abbrev">RFC3596</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">C.</span> <span class="surname">Huitema</span>, <span class="firstname">V.</span> <span class="surname">Ksinant</span>, and <span class="firstname">M.</span> <span class="surname">Souissi</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Extensions to support IP
+<a name="id2606438"></a><p>[<abbr class="abbrev">RFC3596</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">C.</span> <span class="surname">Huitema</span>, <span class="firstname">V.</span> <span class="surname">Ksinant</span>, and <span class="firstname">M.</span> <span class="surname">Souissi</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Extensions to support IP
                   version 6</i>. </span><span class="pubdate">October 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606283"></a><p>[<abbr class="abbrev">RFC3597</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gustafsson</span>. </span><span class="title"><i>Handling of Unknown DNS Resource Record (RR) Types</i>. </span><span class="pubdate">September 2003. </span></p>
+<a name="id2606496"></a><p>[<abbr class="abbrev">RFC3597</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gustafsson</span>. </span><span class="title"><i>Handling of Unknown DNS Resource Record (RR) Types</i>. </span><span class="pubdate">September 2003. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">
 <acronym class="acronym">DNS</acronym> and the Internet</h3>
 <div class="biblioentry">
-<a name="id2606315"></a><p>[<abbr class="abbrev">RFC1101</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Network Names
+<a name="id2606528"></a><p>[<abbr class="abbrev">RFC1101</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Network Names
                   and Other Types</i>. </span><span class="pubdate">April 1989. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606341"></a><p>[<abbr class="abbrev">RFC1123</abbr>] <span class="author"><span class="surname">Braden</span>. </span><span class="title"><i>Requirements for Internet Hosts - Application and
+<a name="id2606553"></a><p>[<abbr class="abbrev">RFC1123</abbr>] <span class="author"><span class="surname">Braden</span>. </span><span class="title"><i>Requirements for Internet Hosts - Application and
                   Support</i>. </span><span class="pubdate">October 1989. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606363"></a><p>[<abbr class="abbrev">RFC1591</abbr>] <span class="author"><span class="firstname">J.</span> <span class="surname">Postel</span>. </span><span class="title"><i>Domain Name System Structure and Delegation</i>. </span><span class="pubdate">March 1994. </span></p>
+<a name="id2606576"></a><p>[<abbr class="abbrev">RFC1591</abbr>] <span class="author"><span class="firstname">J.</span> <span class="surname">Postel</span>. </span><span class="title"><i>Domain Name System Structure and Delegation</i>. </span><span class="pubdate">March 1994. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606387"></a><p>[<abbr class="abbrev">RFC2317</abbr>] <span class="authorgroup"><span class="firstname">H.</span> <span class="surname">Eidnes</span>, <span class="firstname">G.</span> <span class="surname">de Groot</span>, and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Classless IN-ADDR.ARPA Delegation</i>. </span><span class="pubdate">March 1998. </span></p>
+<a name="id2606599"></a><p>[<abbr class="abbrev">RFC2317</abbr>] <span class="authorgroup"><span class="firstname">H.</span> <span class="surname">Eidnes</span>, <span class="firstname">G.</span> <span class="surname">de Groot</span>, and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Classless IN-ADDR.ARPA Delegation</i>. </span><span class="pubdate">March 1998. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606433"></a><p>[<abbr class="abbrev">RFC2826</abbr>] <span class="authorgroup"><span class="surname">Internet Architecture Board</span>. </span><span class="title"><i>IAB Technical Comment on the Unique DNS Root</i>. </span><span class="pubdate">May 2000. </span></p>
+<a name="id2606645"></a><p>[<abbr class="abbrev">RFC2826</abbr>] <span class="authorgroup"><span class="surname">Internet Architecture Board</span>. </span><span class="title"><i>IAB Technical Comment on the Unique DNS Root</i>. </span><span class="pubdate">May 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606456"></a><p>[<abbr class="abbrev">RFC2929</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, <span class="firstname">E.</span> <span class="surname">Brunner-Williams</span>, and <span class="firstname">B.</span> <span class="surname">Manning</span>. </span><span class="title"><i>Domain Name System (DNS) IANA Considerations</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2606668"></a><p>[<abbr class="abbrev">RFC2929</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, <span class="firstname">E.</span> <span class="surname">Brunner-Williams</span>, and <span class="firstname">B.</span> <span class="surname">Manning</span>. </span><span class="title"><i>Domain Name System (DNS) IANA Considerations</i>. </span><span class="pubdate">September 2000. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">
 <acronym class="acronym">DNS</acronym> Operations</h3>
 <div class="biblioentry">
-<a name="id2606514"></a><p>[<abbr class="abbrev">RFC1033</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Lottor</span>. </span><span class="title"><i>Domain administrators operations guide.</i>. </span><span class="pubdate">November 1987. </span></p>
+<a name="id2606726"></a><p>[<abbr class="abbrev">RFC1033</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Lottor</span>. </span><span class="title"><i>Domain administrators operations guide.</i>. </span><span class="pubdate">November 1987. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606537"></a><p>[<abbr class="abbrev">RFC1537</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Data File
+<a name="id2606749"></a><p>[<abbr class="abbrev">RFC1537</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Data File
                   Configuration Errors</i>. </span><span class="pubdate">October 1993. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606564"></a><p>[<abbr class="abbrev">RFC1912</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Operational and
+<a name="id2606776"></a><p>[<abbr class="abbrev">RFC1912</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Operational and
                   Configuration Errors</i>. </span><span class="pubdate">February 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606590"></a><p>[<abbr class="abbrev">RFC2010</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Operational Criteria for Root Name Servers.</i>. </span><span class="pubdate">October 1996. </span></p>
+<a name="id2606803"></a><p>[<abbr class="abbrev">RFC2010</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Manning</span> and <span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Operational Criteria for Root Name Servers.</i>. </span><span class="pubdate">October 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606627"></a><p>[<abbr class="abbrev">RFC2219</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Hamilton</span> and <span class="firstname">R.</span> <span class="surname">Wright</span>. </span><span class="title"><i>Use of <acronym class="acronym">DNS</acronym> Aliases for
+<a name="id2606839"></a><p>[<abbr class="abbrev">RFC2219</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Hamilton</span> and <span class="firstname">R.</span> <span class="surname">Wright</span>. </span><span class="title"><i>Use of <acronym class="acronym">DNS</acronym> Aliases for
                   Network Services.</i>. </span><span class="pubdate">October 1997. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">Internationalized Domain Names</h3>
 <div class="biblioentry">
-<a name="id2606673"></a><p>[<abbr class="abbrev">RFC2825</abbr>] <span class="authorgroup"><span class="surname">IAB</span> and <span class="firstname">R.</span> <span class="surname">Daigle</span>. </span><span class="title"><i>A Tangled Web: Issues of I18N, Domain Names,
+<a name="id2606885"></a><p>[<abbr class="abbrev">RFC2825</abbr>] <span class="authorgroup"><span class="surname">IAB</span> and <span class="firstname">R.</span> <span class="surname">Daigle</span>. </span><span class="title"><i>A Tangled Web: Issues of I18N, Domain Names,
                        and the Other Internet protocols</i>. </span><span class="pubdate">May 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606705"></a><p>[<abbr class="abbrev">RFC3490</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Faltstrom</span>, <span class="firstname">P.</span> <span class="surname">Hoffman</span>, and <span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Internationalizing Domain Names in Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
+<a name="id2606917"></a><p>[<abbr class="abbrev">RFC3490</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Faltstrom</span>, <span class="firstname">P.</span> <span class="surname">Hoffman</span>, and <span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Internationalizing Domain Names in Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606750"></a><p>[<abbr class="abbrev">RFC3491</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Hoffman</span> and <span class="firstname">M.</span> <span class="surname">Blanchet</span>. </span><span class="title"><i>Nameprep: A Stringprep Profile for Internationalized Domain Names</i>. </span><span class="pubdate">March 2003. </span></p>
+<a name="id2606963"></a><p>[<abbr class="abbrev">RFC3491</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Hoffman</span> and <span class="firstname">M.</span> <span class="surname">Blanchet</span>. </span><span class="title"><i>Nameprep: A Stringprep Profile for Internationalized Domain Names</i>. </span><span class="pubdate">March 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606786"></a><p>[<abbr class="abbrev">RFC3492</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Punycode: A Bootstring encoding of Unicode
+<a name="id2606998"></a><p>[<abbr class="abbrev">RFC3492</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Punycode: A Bootstring encoding of Unicode
                        for Internationalized Domain Names in
                        Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
 </div>
@@ -497,47 +497,47 @@
                 </p>
 </div>
 <div class="biblioentry">
-<a name="id2606830"></a><p>[<abbr class="abbrev">RFC1464</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Rosenbaum</span>. </span><span class="title"><i>Using the Domain Name System To Store Arbitrary String
+<a name="id2607043"></a><p>[<abbr class="abbrev">RFC1464</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Rosenbaum</span>. </span><span class="title"><i>Using the Domain Name System To Store Arbitrary String
                   Attributes</i>. </span><span class="pubdate">May 1993. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606853"></a><p>[<abbr class="abbrev">RFC1713</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <acronym class="acronym">DNS</acronym> Debugging</i>. </span><span class="pubdate">November 1994. </span></p>
+<a name="id2607065"></a><p>[<abbr class="abbrev">RFC1713</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <acronym class="acronym">DNS</acronym> Debugging</i>. </span><span class="pubdate">November 1994. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606878"></a><p>[<abbr class="abbrev">RFC1794</abbr>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Support for Load
+<a name="id2607091"></a><p>[<abbr class="abbrev">RFC1794</abbr>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Support for Load
                   Balancing</i>. </span><span class="pubdate">April 1995. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606972"></a><p>[<abbr class="abbrev">RFC2240</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Legal Basis for Domain Name Allocation</i>. </span><span class="pubdate">November 1997. </span></p>
+<a name="id2607185"></a><p>[<abbr class="abbrev">RFC2240</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Legal Basis for Domain Name Allocation</i>. </span><span class="pubdate">November 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2606996"></a><p>[<abbr class="abbrev">RFC2345</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>, <span class="firstname">T.</span> <span class="surname">Wolf</span>, and <span class="firstname">G.</span> <span class="surname">Oglesby</span>. </span><span class="title"><i>Domain Names and Company Name Retrieval</i>. </span><span class="pubdate">May 1998. </span></p>
+<a name="id2607208"></a><p>[<abbr class="abbrev">RFC2345</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>, <span class="firstname">T.</span> <span class="surname">Wolf</span>, and <span class="firstname">G.</span> <span class="surname">Oglesby</span>. </span><span class="title"><i>Domain Names and Company Name Retrieval</i>. </span><span class="pubdate">May 1998. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607042"></a><p>[<abbr class="abbrev">RFC2352</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Convention For Using Legal Names as Domain Names</i>. </span><span class="pubdate">May 1998. </span></p>
+<a name="id2607254"></a><p>[<abbr class="abbrev">RFC2352</abbr>] <span class="author"><span class="firstname">O.</span> <span class="surname">Vaughan</span>. </span><span class="title"><i>A Convention For Using Legal Names as Domain Names</i>. </span><span class="pubdate">May 1998. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607065"></a><p>[<abbr class="abbrev">RFC3071</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>. </span><span class="title"><i>Reflections on the DNS, RFC 1591, and Categories of Domains</i>. </span><span class="pubdate">February 2001. </span></p>
+<a name="id2607277"></a><p>[<abbr class="abbrev">RFC3071</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>. </span><span class="title"><i>Reflections on the DNS, RFC 1591, and Categories of Domains</i>. </span><span class="pubdate">February 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607092"></a><p>[<abbr class="abbrev">RFC3258</abbr>] <span class="authorgroup"><span class="firstname">T.</span> <span class="surname">Hardie</span>. </span><span class="title"><i>Distributing Authoritative Name Servers via
+<a name="id2607304"></a><p>[<abbr class="abbrev">RFC3258</abbr>] <span class="authorgroup"><span class="firstname">T.</span> <span class="surname">Hardie</span>. </span><span class="title"><i>Distributing Authoritative Name Servers via
                        Shared Unicast Addresses</i>. </span><span class="pubdate">April 2002. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607117"></a><p>[<abbr class="abbrev">RFC3901</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Durand</span> and <span class="firstname">J.</span> <span class="surname">Ihren</span>. </span><span class="title"><i>DNS IPv6 Transport Operational Guidelines</i>. </span><span class="pubdate">September 2004. </span></p>
+<a name="id2607330"></a><p>[<abbr class="abbrev">RFC3901</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Durand</span> and <span class="firstname">J.</span> <span class="surname">Ihren</span>. </span><span class="title"><i>DNS IPv6 Transport Operational Guidelines</i>. </span><span class="pubdate">September 2004. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">Obsolete and Unimplemented Experimental RFC</h3>
 <div class="biblioentry">
-<a name="id2607161"></a><p>[<abbr class="abbrev">RFC1712</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Farrell</span>, <span class="firstname">M.</span> <span class="surname">Schulze</span>, <span class="firstname">S.</span> <span class="surname">Pleitner</span>, and <span class="firstname">D.</span> <span class="surname">Baldoni</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Geographical
+<a name="id2607373"></a><p>[<abbr class="abbrev">RFC1712</abbr>] <span class="authorgroup"><span class="firstname">C.</span> <span class="surname">Farrell</span>, <span class="firstname">M.</span> <span class="surname">Schulze</span>, <span class="firstname">S.</span> <span class="surname">Pleitner</span>, and <span class="firstname">D.</span> <span class="surname">Baldoni</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Geographical
                   Location</i>. </span><span class="pubdate">November 1994. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607219"></a><p>[<abbr class="abbrev">RFC2673</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Binary Labels in the Domain Name System</i>. </span><span class="pubdate">August 1999. </span></p>
+<a name="id2607431"></a><p>[<abbr class="abbrev">RFC2673</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Binary Labels in the Domain Name System</i>. </span><span class="pubdate">August 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607245"></a><p>[<abbr class="abbrev">RFC2874</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i>DNS Extensions to Support IPv6 Address Aggregation
+<a name="id2607458"></a><p>[<abbr class="abbrev">RFC2874</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i>DNS Extensions to Support IPv6 Address Aggregation
                        and Renumbering</i>. </span><span class="pubdate">July 2000. </span></p>
 </div>
 </div>
@@ -551,39 +551,39 @@
                 </p>
 </div>
 <div class="biblioentry">
-<a name="id2607293"></a><p>[<abbr class="abbrev">RFC2065</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">C.</span> <span class="surname">Kaufman</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">January 1997. </span></p>
+<a name="id2607506"></a><p>[<abbr class="abbrev">RFC2065</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">C.</span> <span class="surname">Kaufman</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">January 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607333"></a><p>[<abbr class="abbrev">RFC2137</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secure Domain Name System Dynamic Update</i>. </span><span class="pubdate">April 1997. </span></p>
+<a name="id2607545"></a><p>[<abbr class="abbrev">RFC2137</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secure Domain Name System Dynamic Update</i>. </span><span class="pubdate">April 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607360"></a><p>[<abbr class="abbrev">RFC2535</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2607572"></a><p>[<abbr class="abbrev">RFC2535</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607389"></a><p>[<abbr class="abbrev">RFC3008</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Domain Name System Security (DNSSEC)
+<a name="id2607602"></a><p>[<abbr class="abbrev">RFC3008</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Domain Name System Security (DNSSEC)
                        Signing Authority</i>. </span><span class="pubdate">November 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607415"></a><p>[<abbr class="abbrev">RFC3090</abbr>] <span class="authorgroup"><span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>DNS Security Extension Clarification on Zone Status</i>. </span><span class="pubdate">March 2001. </span></p>
+<a name="id2607627"></a><p>[<abbr class="abbrev">RFC3090</abbr>] <span class="authorgroup"><span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>DNS Security Extension Clarification on Zone Status</i>. </span><span class="pubdate">March 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607442"></a><p>[<abbr class="abbrev">RFC3445</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Massey</span> and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Limiting the Scope of the KEY Resource Record (RR)</i>. </span><span class="pubdate">December 2002. </span></p>
+<a name="id2607654"></a><p>[<abbr class="abbrev">RFC3445</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Massey</span> and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Limiting the Scope of the KEY Resource Record (RR)</i>. </span><span class="pubdate">December 2002. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607478"></a><p>[<abbr class="abbrev">RFC3655</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Redefinition of DNS Authenticated Data (AD) bit</i>. </span><span class="pubdate">November 2003. </span></p>
+<a name="id2607690"></a><p>[<abbr class="abbrev">RFC3655</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Redefinition of DNS Authenticated Data (AD) bit</i>. </span><span class="pubdate">November 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607514"></a><p>[<abbr class="abbrev">RFC3658</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Delegation Signer (DS) Resource Record (RR)</i>. </span><span class="pubdate">December 2003. </span></p>
+<a name="id2607726"></a><p>[<abbr class="abbrev">RFC3658</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Delegation Signer (DS) Resource Record (RR)</i>. </span><span class="pubdate">December 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607541"></a><p>[<abbr class="abbrev">RFC3755</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Weiler</span>. </span><span class="title"><i>Legacy Resolver Compatibility for Delegation Signer (DS)</i>. </span><span class="pubdate">May 2004. </span></p>
+<a name="id2607753"></a><p>[<abbr class="abbrev">RFC3755</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Weiler</span>. </span><span class="title"><i>Legacy Resolver Compatibility for Delegation Signer (DS)</i>. </span><span class="pubdate">May 2004. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607568"></a><p>[<abbr class="abbrev">RFC3757</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Kolkman</span>, <span class="firstname">J.</span> <span class="surname">Schlyter</span>, and <span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>Domain Name System KEY (DNSKEY) Resource Record
+<a name="id2607780"></a><p>[<abbr class="abbrev">RFC3757</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Kolkman</span>, <span class="firstname">J.</span> <span class="surname">Schlyter</span>, and <span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>Domain Name System KEY (DNSKEY) Resource Record
                       (RR) Secure Entry Point (SEP) Flag</i>. </span><span class="pubdate">April 2004. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2607612"></a><p>[<abbr class="abbrev">RFC3845</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Schlyter</span>. </span><span class="title"><i>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</i>. </span><span class="pubdate">August 2004. </span></p>
+<a name="id2607825"></a><p>[<abbr class="abbrev">RFC3845</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Schlyter</span>. </span><span class="title"><i>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</i>. </span><span class="pubdate">August 2004. </span></p>
 </div>
 </div>
 </div>
@@ -604,14 +604,14 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2607654"></a>Other Documents About <acronym class="acronym">BIND</acronym>
+<a name="id2607866"></a>Other Documents About <acronym class="acronym">BIND</acronym>
 </h3></div></div></div>
 <p></p>
 <div class="bibliography">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2607664"></a>Bibliography</h4></div></div></div>
+<a name="id2607876"></a>Bibliography</h4></div></div></div>
 <div class="biblioentry">
-<a name="id2607666"></a><p><span class="authorgroup"><span class="firstname">Paul</span> <span class="surname">Albitz</span> and <span class="firstname">Cricket</span> <span class="surname">Liu</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p>
+<a name="id2607878"></a><p><span class="authorgroup"><span class="firstname">Paul</span> <span class="surname">Albitz</span> and <span class="firstname">Cricket</span> <span class="surname">Liu</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p>
 </div>
 </div>
 </div>
@@ -648,7 +648,7 @@
 </ul></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2609046"></a>Prerequisite</h3></div></div></div>
+<a name="id2609315"></a>Prerequisite</h3></div></div></div>
 <p>GNU make is required to build the export libraries (other
   part of BIND 9 can still be built with other types of make). In
   the reminder of this document, "make" means GNU make. Note that
@@ -657,7 +657,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2609056"></a>Compilation</h3></div></div></div>
+<a name="id2609324"></a>Compilation</h3></div></div></div>
 <pre class="screen">
 $ <strong class="userinput"><code>./configure --enable-exportlib <em class="replaceable"><code>[other flags]</code></em></code></strong>
 $ <strong class="userinput"><code>make</code></strong>
@@ -672,7 +672,7 @@ $ <strong class="userinput"><code>make</code></strong>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2609080"></a>Installation</h3></div></div></div>
+<a name="id2609349"></a>Installation</h3></div></div></div>
 <pre class="screen">
 $ <strong class="userinput"><code>cd lib/export</code></strong>
 $ <strong class="userinput"><code>make install</code></strong>
@@ -694,7 +694,7 @@ $ <strong class="userinput"><code>make install</code></strong>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2609179"></a>Known Defects/Restrictions</h3></div></div></div>
+<a name="id2609380"></a>Known Defects/Restrictions</h3></div></div></div>
 <div class="itemizedlist"><ul type="disc">
 <li><p>Currently, win32 is not supported for the export
       library. (Normal BIND 9 application can be built as
@@ -734,7 +734,7 @@ $ <strong class="userinput"><code>make</code></strong>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2609256"></a>The dns.conf File</h3></div></div></div>
+<a name="id2609457"></a>The dns.conf File</h3></div></div></div>
 <p>The IRS library supports an "advanced" configuration file
   related to the DNS library for configuration parameters that
   would be beyond the capability of the
@@ -752,14 +752,14 @@ $ <strong class="userinput"><code>make</code></strong>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2609283"></a>Sample Applications</h3></div></div></div>
+<a name="id2609483"></a>Sample Applications</h3></div></div></div>
 <p>Some sample application programs using this API are
   provided for reference. The following is a brief description of
   these applications.
   </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2609291"></a>sample: a simple stub resolver utility</h4></div></div></div>
+<a name="id2609492"></a>sample: a simple stub resolver utility</h4></div></div></div>
 <p>
   It sends a query of a given name (of a given optional RR type) to a
   specified recursive server, and prints the result as a list of
@@ -823,7 +823,7 @@ $ <strong class="userinput"><code>make</code></strong>
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2609382"></a>sample-async: a simple stub resolver, working asynchronously</h4></div></div></div>
+<a name="id2609582"></a>sample-async: a simple stub resolver, working asynchronously</h4></div></div></div>
 <p>
   Similar to "sample", but accepts a list
   of (query) domain names as a separate file and resolves the names
@@ -864,7 +864,7 @@ $ <strong class="userinput"><code>make</code></strong>
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2609435"></a>sample-request: a simple DNS transaction client</h4></div></div></div>
+<a name="id2609636"></a>sample-request: a simple DNS transaction client</h4></div></div></div>
 <p>
   It sends a query to a specified server, and
   prints the response with minimal processing. It doesn't act as a
@@ -905,7 +905,7 @@ $ <strong class="userinput"><code>make</code></strong>
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2609499"></a>sample-gai: getaddrinfo() and getnameinfo() test code</h4></div></div></div>
+<a name="id2609700"></a>sample-gai: getaddrinfo() and getnameinfo() test code</h4></div></div></div>
 <p>
   This is a test program
   to check getaddrinfo() and getnameinfo() behavior. It takes a
@@ -922,7 +922,7 @@ $ <strong class="userinput"><code>make</code></strong>
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2609514"></a>sample-update: a simple dynamic update client program</h4></div></div></div>
+<a name="id2609715"></a>sample-update: a simple dynamic update client program</h4></div></div></div>
 <p>
   It accepts a single update command as a
   command-line argument, sends an update request message to the
@@ -1017,7 +1017,7 @@ $ <strong class="userinput"><code>sample-update -a sample-update -k Kxxx.+nnn+mm
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2610192"></a>nsprobe: domain/name server checker in terms of RFC 4074</h4></div></div></div>
+<a name="id2610529"></a>nsprobe: domain/name server checker in terms of RFC 4074</h4></div></div></div>
 <p>
   It checks a set
   of domains to see the name servers of the domains behave
@@ -1074,7 +1074,7 @@ $ <strong class="userinput"><code>sample-update -a sample-update -k Kxxx.+nnn+mm
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2610256"></a>Library References</h3></div></div></div>
+<a name="id2610593"></a>Library References</h3></div></div></div>
 <p>As of this writing, there is no formal "manual" of the
   libraries, except this document, header files (some of them
   provide pretty detailed explanations), and sample application
diff --git a/doc/arm/Bv9ARM.ch10.html b/doc/arm/Bv9ARM.ch10.html
index 7ff08e1a..4f93501d 100644
--- a/doc/arm/Bv9ARM.ch10.html
+++ b/doc/arm/Bv9ARM.ch10.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch10.html,v 1.20 2011-01-05 01:14:09 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch10.html,v 1.21 2012-01-07 01:14:55 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/doc/arm/Bv9ARM.html b/doc/arm/Bv9ARM.html
index 6b10622d..c65e73b5 100644
--- a/doc/arm/Bv9ARM.html
+++ b/doc/arm/Bv9ARM.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.html,v 1.287 2011-11-24 01:14:51 tbox Exp $ -->
+<!-- $Id: Bv9ARM.html,v 1.290 2012-01-17 01:15:00 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -41,7 +41,7 @@
 <div>
 <div><h1 class="title">
 <a name="id2563174"></a>BIND 9 Administrator Reference Manual</h1></div>
-<div><p class="copyright">Copyright © 2004-2011 Internet Systems Consortium, Inc. ("ISC")</p></div>
+<div><p class="copyright">Copyright © 2004-2012 Internet Systems Consortium, Inc. ("ISC")</p></div>
 <div><p class="copyright">Copyright © 2000-2003 Internet Software Consortium.</p></div>
 </div>
 <hr>
@@ -51,39 +51,39 @@
 <dl>
 <dt><span class="chapter"><a href="Bv9ARM.ch01.html">1. Introduction</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564371">Scope of Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564394">Organization of This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564534">Conventions Used in This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564715">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564374">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564397">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564537">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564718">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564737">DNS Fundamentals</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564771">Domains and Domain Names</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567176">Zones</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567253">Authoritative Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567426">Caching Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567556">Name Servers in Multiple Roles</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564740">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564774">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567179">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567256">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567429">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567559">Name Servers in Multiple Roles</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch02.html">2. <acronym class="acronym">BIND</acronym> Resource Requirements</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567590">Hardware requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567617">CPU Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567629">Memory Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567724">Name Server Intensive Environment Issues</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567735">Supported Operating Systems</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567593">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567620">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567633">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567728">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567738">Supported Operating Systems</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch03.html">3. Name Server Configuration</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="Bv9ARM.ch03.html#sample_configuration">Sample Configurations</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567767">A Caching-only Name Server</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567988">An Authoritative-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567770">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567991">An Authoritative-only Name Server</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568010">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568364">Name Server Operations</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568013">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568368">Name Server Operations</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568370">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570628">Signals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568373">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570631">Signals</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch04.html">4. Advanced DNS Features</a></span></dt>
@@ -92,64 +92,64 @@
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#dynamic_update">Dynamic Update</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#journal">The journal file</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#incremental_zone_transfers">Incremental Zone Transfers (IXFR)</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2564035">Split DNS</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564053">Example split DNS setup</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2563970">Split DNS</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563988">Example split DNS setup</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#tsig">TSIG</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571722">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571796">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571806">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571979">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572105">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572154">Errors</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571725">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571799">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572014">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572051">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572108">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572157">Errors</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572168">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572217">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572171">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572289">SIG(0)</a></span></dt>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#DNSSEC">DNSSEC</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572354">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572433">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572582">Configuring Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572357">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572436">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572585">Configuring Servers</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#dnssec.dynamic.zones">DNSSEC, Dynamic Zones, and Automatic Signing</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2608427">Converting from insecure to secure</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2608465">Dynamic DNS update method</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563513">Fully automatic zone signing</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563685">Private-type records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563790">DNSKEY rollovers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563803">Dynamic DNS update method</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563836">Automatic key rollovers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563863">NSEC3PARAM rollovers via UPDATE</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563873">Converting from NSEC to NSEC3</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563882">Converting from NSEC3 to NSEC</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571200">Converting from secure to insecure</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571237">Periodic re-signing</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571246">NSEC3 and OPTOUT</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2608776">Converting from insecure to secure</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563484">Dynamic DNS update method</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563521">Fully automatic zone signing</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563692">Private-type records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563730">DNSKEY rollovers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563742">Dynamic DNS update method</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563776">Automatic key rollovers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563802">NSEC3PARAM rollovers via UPDATE</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563812">Converting from NSEC to NSEC3</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2563821">Converting from NSEC3 to NSEC</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571207">Converting from secure to insecure</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571244">Periodic re-signing</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571254">NSEC3 and OPTOUT</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#rfc5011.support">Dynamic Trust Anchor Management</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2607869">Validating Resolver</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2607892">Authoritative Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2609037">Validating Resolver</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2609060">Authoritative Server</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch04.html#pkcs11">PKCS #11 (Cryptoki) support</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2610805">Prerequisites</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2608755">Building BIND 9 with PKCS#11</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2608850">PKCS #11 Tools</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2608881">Using the HSM</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2611537">Specifying the engine on the command line</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2611582">Running named with automatic zone re-signing</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2611347">Prerequisites</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2609255">Building BIND 9 with PKCS#11</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2635799">PKCS #11 Tools</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2635830">Using the HSM</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2636097">Specifying the engine on the command line</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2636142">Running named with automatic zone re-signing</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572802">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572805">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2573068">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2573090">Address to Name Lookups Using Nibble Format</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2573003">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2573025">Address to Name Lookups Using Nibble Format</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch05.html">5. The <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2573123">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2573058">The Lightweight Resolver Library</a></span></dt>
 <dt><span class="sect1"><a href="Bv9ARM.ch05.html#lwresd">Running a Resolver Daemon</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch06.html">6. <acronym class="acronym">BIND</acronym> 9 Configuration Reference</a></span></dt>
@@ -157,58 +157,58 @@
 <dt><span class="sect1"><a href="Bv9ARM.ch06.html#configuration_file_elements">Configuration File Elements</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#address_match_lists">Address Match Lists</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574465">Comment Syntax</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574468">Comment Syntax</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch06.html#Configuration_File_Grammar">Configuration File Grammar</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575193"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575196"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#acl"><span><strong class="command">acl</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575383"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575386"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#controls_statement_definition_and_usage"><span><strong class="command">controls</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575742"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575760"><span><strong class="command">include</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575746"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575763"><span><strong class="command">include</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575783"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575806"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575965"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576160"><span><strong class="command">logging</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575786"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575810"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575969"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576163"><span><strong class="command">logging</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578117"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578259"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578323"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578366"><span><strong class="command">masters</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578121"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578263"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578327"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578371"><span><strong class="command">masters</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578388"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2578392"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#options"><span><strong class="command">options</strong></span> Statement Definition and
           Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_grammar"><span><strong class="command">server</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#server_statement_definition_and_usage"><span><strong class="command">server</strong></span> Statement Definition and
             Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#statschannels"><span><strong class="command">statistics-channels</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590061"><span><strong class="command">statistics-channels</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590137"><span><strong class="command">statistics-channels</strong></span> Statement Definition and
             Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#trusted-keys"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590201"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590277"><span><strong class="command">trusted-keys</strong></span> Statement Definition
             and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590248"><span><strong class="command">managed-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590324"><span><strong class="command">managed-keys</strong></span> Statement Grammar</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#managed-keys"><span><strong class="command">managed-keys</strong></span> Statement Definition
             and Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#view_statement_grammar"><span><strong class="command">view</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590742"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2590749"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zone_statement_grammar"><span><strong class="command">zone</strong></span>
             Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592422"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592429"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2595920">Zone File</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2595995">Zone File</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them">Types of Resource Records and When to Use Them</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2598082">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2598226">Discussion of MX Records</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#Setting_TTLs">Setting TTLs</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2598697">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2598824">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2599029"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2598841">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2598968">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2599173"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch06.html#statistics">BIND9 Statistics</a></span></dt>
@@ -217,41 +217,41 @@
 <dt><span class="chapter"><a href="Bv9ARM.ch07.html">7. <acronym class="acronym">BIND</acronym> 9 Security Considerations</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2603817"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2603961"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2603898">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2603958">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2604042">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2604102">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch08.html">8. Troubleshooting</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2604038">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2604043">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2604055">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2604072">Where Can I Get Help?</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2604182">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2604187">It's not working; how can I figure out what's wrong?</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2604199">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2604216">Where Can I Get Help?</a></span></dt>
 </dl></dd>
 <dt><span class="appendix"><a href="Bv9ARM.ch09.html">A. Appendices</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2604134">Acknowledgments</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2604278">Acknowledgments</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2604442">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2604654">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#ipv6addresses">IPv6 addresses (AAAA)</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch09.html#bibliography">Bibliography (and Suggested Reading)</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="Bv9ARM.ch09.html#rfcs">Request for Comments (RFCs)</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch09.html#internet_drafts">Internet Drafts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2607654">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2607866">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="Bv9ARM.ch09.html#bind9.library">BIND 9 DNS Library Support</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609046">Prerequisite</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609056">Compilation</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609080">Installation</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609179">Known Defects/Restrictions</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609256">The dns.conf File</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609283">Sample Applications</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2610256">Library References</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609315">Prerequisite</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609324">Compilation</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609349">Installation</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609380">Known Defects/Restrictions</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609457">The dns.conf File</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2609483">Sample Applications</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2610593">Library References</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="reference"><a href="Bv9ARM.ch10.html">I. Manual pages</a></span></dt>
diff --git a/doc/arm/Bv9ARM.pdf b/doc/arm/Bv9ARM.pdf
index e8bc3417..5a46f2bc 100755
--- a/doc/arm/Bv9ARM.pdf
+++ b/doc/arm/Bv9ARM.pdf
@@ -444,939 +444,951 @@ endobj
 (4.11.1.2 Building OpenSSL for the SCA 6000 on Solaris)
 endobj
 301 0 obj
-<< /S /GoTo /D (subsection.4.11.2) >>
+<< /S /GoTo /D (subsubsection.4.11.1.3) >>
 endobj
 304 0 obj
-(4.11.2 Building BIND 9 with PKCS\04311)
+(4.11.1.3 Building OpenSSL for SoftHSM)
 endobj
 305 0 obj
-<< /S /GoTo /D (subsubsection.4.11.2.1) >>
+<< /S /GoTo /D (subsection.4.11.2) >>
 endobj
 308 0 obj
-(4.11.2.1 Configuring BIND 9 for Linux)
+(4.11.2 Building BIND 9 with PKCS\04311)
 endobj
 309 0 obj
-<< /S /GoTo /D (subsubsection.4.11.2.2) >>
+<< /S /GoTo /D (subsubsection.4.11.2.1) >>
 endobj
 312 0 obj
-(4.11.2.2 Configuring BIND 9 for Solaris)
+(4.11.2.1 Configuring BIND 9 for Linux with the AEP Keyper)
 endobj
 313 0 obj
-<< /S /GoTo /D (subsection.4.11.3) >>
+<< /S /GoTo /D (subsubsection.4.11.2.2) >>
 endobj
 316 0 obj
-(4.11.3 PKCS \04311 Tools)
+(4.11.2.2 Configuring BIND 9 for Solaris with the SCA 6000)
 endobj
 317 0 obj
-<< /S /GoTo /D (subsection.4.11.4) >>
+<< /S /GoTo /D (subsubsection.4.11.2.3) >>
 endobj
 320 0 obj
-(4.11.4 Using the HSM)
+(4.11.2.3 Configuring BIND 9 for SoftHSM)
 endobj
 321 0 obj
-<< /S /GoTo /D (subsection.4.11.5) >>
+<< /S /GoTo /D (subsection.4.11.3) >>
 endobj
 324 0 obj
-(4.11.5 Specifying the engine on the command line)
+(4.11.3 PKCS \04311 Tools)
 endobj
 325 0 obj
-<< /S /GoTo /D (subsection.4.11.6) >>
+<< /S /GoTo /D (subsection.4.11.4) >>
 endobj
 328 0 obj
-(4.11.6 Running named with automatic zone re-signing)
+(4.11.4 Using the HSM)
 endobj
 329 0 obj
-<< /S /GoTo /D (section.4.12) >>
+<< /S /GoTo /D (subsection.4.11.5) >>
 endobj
 332 0 obj
-(4.12 IPv6 Support in BIND 9)
+(4.11.5 Specifying the engine on the command line)
 endobj
 333 0 obj
-<< /S /GoTo /D (subsection.4.12.1) >>
+<< /S /GoTo /D (subsection.4.11.6) >>
 endobj
 336 0 obj
-(4.12.1 Address Lookups Using AAAA Records)
+(4.11.6 Running named with automatic zone re-signing)
 endobj
 337 0 obj
-<< /S /GoTo /D (subsection.4.12.2) >>
+<< /S /GoTo /D (section.4.12) >>
 endobj
 340 0 obj
-(4.12.2 Address to Name Lookups Using Nibble Format)
+(4.12 IPv6 Support in BIND 9)
 endobj
 341 0 obj
-<< /S /GoTo /D (chapter.5) >>
+<< /S /GoTo /D (subsection.4.12.1) >>
 endobj
 344 0 obj
-(5 The BIND 9 Lightweight Resolver)
+(4.12.1 Address Lookups Using AAAA Records)
 endobj
 345 0 obj
-<< /S /GoTo /D (section.5.1) >>
+<< /S /GoTo /D (subsection.4.12.2) >>
 endobj
 348 0 obj
-(5.1 The Lightweight Resolver Library)
+(4.12.2 Address to Name Lookups Using Nibble Format)
 endobj
 349 0 obj
-<< /S /GoTo /D (section.5.2) >>
+<< /S /GoTo /D (chapter.5) >>
 endobj
 352 0 obj
-(5.2 Running a Resolver Daemon)
+(5 The BIND 9 Lightweight Resolver)
 endobj
 353 0 obj
-<< /S /GoTo /D (chapter.6) >>
+<< /S /GoTo /D (section.5.1) >>
 endobj
 356 0 obj
-(6 BIND 9 Configuration Reference)
+(5.1 The Lightweight Resolver Library)
 endobj
 357 0 obj
-<< /S /GoTo /D (section.6.1) >>
+<< /S /GoTo /D (section.5.2) >>
 endobj
 360 0 obj
-(6.1 Configuration File Elements)
+(5.2 Running a Resolver Daemon)
 endobj
 361 0 obj
-<< /S /GoTo /D (subsection.6.1.1) >>
+<< /S /GoTo /D (chapter.6) >>
 endobj
 364 0 obj
-(6.1.1 Address Match Lists)
+(6 BIND 9 Configuration Reference)
 endobj
 365 0 obj
-<< /S /GoTo /D (subsubsection.6.1.1.1) >>
+<< /S /GoTo /D (section.6.1) >>
 endobj
 368 0 obj
-(6.1.1.1 Syntax)
+(6.1 Configuration File Elements)
 endobj
 369 0 obj
-<< /S /GoTo /D (subsubsection.6.1.1.2) >>
+<< /S /GoTo /D (subsection.6.1.1) >>
 endobj
 372 0 obj
-(6.1.1.2 Definition and Usage)
+(6.1.1 Address Match Lists)
 endobj
 373 0 obj
-<< /S /GoTo /D (subsection.6.1.2) >>
+<< /S /GoTo /D (subsubsection.6.1.1.1) >>
 endobj
 376 0 obj
-(6.1.2 Comment Syntax)
+(6.1.1.1 Syntax)
 endobj
 377 0 obj
-<< /S /GoTo /D (subsubsection.6.1.2.1) >>
+<< /S /GoTo /D (subsubsection.6.1.1.2) >>
 endobj
 380 0 obj
-(6.1.2.1 Syntax)
+(6.1.1.2 Definition and Usage)
 endobj
 381 0 obj
-<< /S /GoTo /D (subsubsection.6.1.2.2) >>
+<< /S /GoTo /D (subsection.6.1.2) >>
 endobj
 384 0 obj
-(6.1.2.2 Definition and Usage)
+(6.1.2 Comment Syntax)
 endobj
 385 0 obj
-<< /S /GoTo /D (section.6.2) >>
+<< /S /GoTo /D (subsubsection.6.1.2.1) >>
 endobj
 388 0 obj
-(6.2 Configuration File Grammar)
+(6.1.2.1 Syntax)
 endobj
 389 0 obj
-<< /S /GoTo /D (subsection.6.2.1) >>
+<< /S /GoTo /D (subsubsection.6.1.2.2) >>
 endobj
 392 0 obj
-(6.2.1 acl Statement Grammar)
+(6.1.2.2 Definition and Usage)
 endobj
 393 0 obj
-<< /S /GoTo /D (subsection.6.2.2) >>
+<< /S /GoTo /D (section.6.2) >>
 endobj
 396 0 obj
-(6.2.2 acl Statement Definition and Usage)
+(6.2 Configuration File Grammar)
 endobj
 397 0 obj
-<< /S /GoTo /D (subsection.6.2.3) >>
+<< /S /GoTo /D (subsection.6.2.1) >>
 endobj
 400 0 obj
-(6.2.3 controls Statement Grammar)
+(6.2.1 acl Statement Grammar)
 endobj
 401 0 obj
-<< /S /GoTo /D (subsection.6.2.4) >>
+<< /S /GoTo /D (subsection.6.2.2) >>
 endobj
 404 0 obj
-(6.2.4 controls Statement Definition and Usage)
+(6.2.2 acl Statement Definition and Usage)
 endobj
 405 0 obj
-<< /S /GoTo /D (subsection.6.2.5) >>
+<< /S /GoTo /D (subsection.6.2.3) >>
 endobj
 408 0 obj
-(6.2.5 include Statement Grammar)
+(6.2.3 controls Statement Grammar)
 endobj
 409 0 obj
-<< /S /GoTo /D (subsection.6.2.6) >>
+<< /S /GoTo /D (subsection.6.2.4) >>
 endobj
 412 0 obj
-(6.2.6 include Statement Definition and Usage)
+(6.2.4 controls Statement Definition and Usage)
 endobj
 413 0 obj
-<< /S /GoTo /D (subsection.6.2.7) >>
+<< /S /GoTo /D (subsection.6.2.5) >>
 endobj
 416 0 obj
-(6.2.7 key Statement Grammar)
+(6.2.5 include Statement Grammar)
 endobj
 417 0 obj
-<< /S /GoTo /D (subsection.6.2.8) >>
+<< /S /GoTo /D (subsection.6.2.6) >>
 endobj
 420 0 obj
-(6.2.8 key Statement Definition and Usage)
+(6.2.6 include Statement Definition and Usage)
 endobj
 421 0 obj
-<< /S /GoTo /D (subsection.6.2.9) >>
+<< /S /GoTo /D (subsection.6.2.7) >>
 endobj
 424 0 obj
-(6.2.9 logging Statement Grammar)
+(6.2.7 key Statement Grammar)
 endobj
 425 0 obj
-<< /S /GoTo /D (subsection.6.2.10) >>
+<< /S /GoTo /D (subsection.6.2.8) >>
 endobj
 428 0 obj
-(6.2.10 logging Statement Definition and Usage)
+(6.2.8 key Statement Definition and Usage)
 endobj
 429 0 obj
-<< /S /GoTo /D (subsubsection.6.2.10.1) >>
+<< /S /GoTo /D (subsection.6.2.9) >>
 endobj
 432 0 obj
-(6.2.10.1 The channel Phrase)
+(6.2.9 logging Statement Grammar)
 endobj
 433 0 obj
-<< /S /GoTo /D (subsubsection.6.2.10.2) >>
+<< /S /GoTo /D (subsection.6.2.10) >>
 endobj
 436 0 obj
-(6.2.10.2 The category Phrase)
+(6.2.10 logging Statement Definition and Usage)
 endobj
 437 0 obj
-<< /S /GoTo /D (subsubsection.6.2.10.3) >>
+<< /S /GoTo /D (subsubsection.6.2.10.1) >>
 endobj
 440 0 obj
-(6.2.10.3 The query-errors Category)
+(6.2.10.1 The channel Phrase)
 endobj
 441 0 obj
-<< /S /GoTo /D (subsection.6.2.11) >>
+<< /S /GoTo /D (subsubsection.6.2.10.2) >>
 endobj
 444 0 obj
-(6.2.11 lwres Statement Grammar)
+(6.2.10.2 The category Phrase)
 endobj
 445 0 obj
-<< /S /GoTo /D (subsection.6.2.12) >>
+<< /S /GoTo /D (subsubsection.6.2.10.3) >>
 endobj
 448 0 obj
-(6.2.12 lwres Statement Definition and Usage)
+(6.2.10.3 The query-errors Category)
 endobj
 449 0 obj
-<< /S /GoTo /D (subsection.6.2.13) >>
+<< /S /GoTo /D (subsection.6.2.11) >>
 endobj
 452 0 obj
-(6.2.13 masters Statement Grammar)
+(6.2.11 lwres Statement Grammar)
 endobj
 453 0 obj
-<< /S /GoTo /D (subsection.6.2.14) >>
+<< /S /GoTo /D (subsection.6.2.12) >>
 endobj
 456 0 obj
-(6.2.14 masters Statement Definition and Usage)
+(6.2.12 lwres Statement Definition and Usage)
 endobj
 457 0 obj
-<< /S /GoTo /D (subsection.6.2.15) >>
+<< /S /GoTo /D (subsection.6.2.13) >>
 endobj
 460 0 obj
-(6.2.15 options Statement Grammar)
+(6.2.13 masters Statement Grammar)
 endobj
 461 0 obj
-<< /S /GoTo /D (subsection.6.2.16) >>
+<< /S /GoTo /D (subsection.6.2.14) >>
 endobj
 464 0 obj
-(6.2.16 options Statement Definition and Usage)
+(6.2.14 masters Statement Definition and Usage)
 endobj
 465 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.1) >>
+<< /S /GoTo /D (subsection.6.2.15) >>
 endobj
 468 0 obj
-(6.2.16.1 Boolean Options)
+(6.2.15 options Statement Grammar)
 endobj
 469 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.2) >>
+<< /S /GoTo /D (subsection.6.2.16) >>
 endobj
 472 0 obj
-(6.2.16.2 Forwarding)
+(6.2.16 options Statement Definition and Usage)
 endobj
 473 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.3) >>
+<< /S /GoTo /D (subsubsection.6.2.16.1) >>
 endobj
 476 0 obj
-(6.2.16.3 Dual-stack Servers)
+(6.2.16.1 Boolean Options)
 endobj
 477 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.4) >>
+<< /S /GoTo /D (subsubsection.6.2.16.2) >>
 endobj
 480 0 obj
-(6.2.16.4 Access Control)
+(6.2.16.2 Forwarding)
 endobj
 481 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.5) >>
+<< /S /GoTo /D (subsubsection.6.2.16.3) >>
 endobj
 484 0 obj
-(6.2.16.5 Interfaces)
+(6.2.16.3 Dual-stack Servers)
 endobj
 485 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.6) >>
+<< /S /GoTo /D (subsubsection.6.2.16.4) >>
 endobj
 488 0 obj
-(6.2.16.6 Query Address)
+(6.2.16.4 Access Control)
 endobj
 489 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.7) >>
+<< /S /GoTo /D (subsubsection.6.2.16.5) >>
 endobj
 492 0 obj
-(6.2.16.7 Zone Transfers)
+(6.2.16.5 Interfaces)
 endobj
 493 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.8) >>
+<< /S /GoTo /D (subsubsection.6.2.16.6) >>
 endobj
 496 0 obj
-(6.2.16.8 UDP Port Lists)
+(6.2.16.6 Query Address)
 endobj
 497 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.9) >>
+<< /S /GoTo /D (subsubsection.6.2.16.7) >>
 endobj
 500 0 obj
-(6.2.16.9 Operating System Resource Limits)
+(6.2.16.7 Zone Transfers)
 endobj
 501 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.10) >>
+<< /S /GoTo /D (subsubsection.6.2.16.8) >>
 endobj
 504 0 obj
-(6.2.16.10 Server Resource Limits)
+(6.2.16.8 UDP Port Lists)
 endobj
 505 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.11) >>
+<< /S /GoTo /D (subsubsection.6.2.16.9) >>
 endobj
 508 0 obj
-(6.2.16.11 Periodic Task Intervals)
+(6.2.16.9 Operating System Resource Limits)
 endobj
 509 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.12) >>
+<< /S /GoTo /D (subsubsection.6.2.16.10) >>
 endobj
 512 0 obj
-(6.2.16.12 Topology)
+(6.2.16.10 Server Resource Limits)
 endobj
 513 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.13) >>
+<< /S /GoTo /D (subsubsection.6.2.16.11) >>
 endobj
 516 0 obj
-(6.2.16.13 The sortlist Statement)
+(6.2.16.11 Periodic Task Intervals)
 endobj
 517 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.14) >>
+<< /S /GoTo /D (subsubsection.6.2.16.12) >>
 endobj
 520 0 obj
-(6.2.16.14 RRset Ordering)
+(6.2.16.12 Topology)
 endobj
 521 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.15) >>
+<< /S /GoTo /D (subsubsection.6.2.16.13) >>
 endobj
 524 0 obj
-(6.2.16.15 Tuning)
+(6.2.16.13 The sortlist Statement)
 endobj
 525 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.16) >>
+<< /S /GoTo /D (subsubsection.6.2.16.14) >>
 endobj
 528 0 obj
-(6.2.16.16 Built-in server information zones)
+(6.2.16.14 RRset Ordering)
 endobj
 529 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.17) >>
+<< /S /GoTo /D (subsubsection.6.2.16.15) >>
 endobj
 532 0 obj
-(6.2.16.17 Built-in Empty Zones)
+(6.2.16.15 Tuning)
 endobj
 533 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.18) >>
+<< /S /GoTo /D (subsubsection.6.2.16.16) >>
 endobj
 536 0 obj
-(6.2.16.18 Additional Section Caching)
+(6.2.16.16 Built-in server information zones)
 endobj
 537 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.19) >>
+<< /S /GoTo /D (subsubsection.6.2.16.17) >>
 endobj
 540 0 obj
-(6.2.16.19 Content Filtering)
+(6.2.16.17 Built-in Empty Zones)
 endobj
 541 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.20) >>
+<< /S /GoTo /D (subsubsection.6.2.16.18) >>
 endobj
 544 0 obj
-(6.2.16.20 Response Policy Zone \(RPZ\) Rewriting)
+(6.2.16.18 Additional Section Caching)
 endobj
 545 0 obj
-<< /S /GoTo /D (subsection.6.2.17) >>
+<< /S /GoTo /D (subsubsection.6.2.16.19) >>
 endobj
 548 0 obj
-(6.2.17 server Statement Grammar)
+(6.2.16.19 Content Filtering)
 endobj
 549 0 obj
-<< /S /GoTo /D (subsection.6.2.18) >>
+<< /S /GoTo /D (subsubsection.6.2.16.20) >>
 endobj
 552 0 obj
-(6.2.18 server Statement Definition and Usage)
+(6.2.16.20 Response Policy Zone \(RPZ\) Rewriting)
 endobj
 553 0 obj
-<< /S /GoTo /D (subsection.6.2.19) >>
+<< /S /GoTo /D (subsection.6.2.17) >>
 endobj
 556 0 obj
-(6.2.19 statistics-channels Statement Grammar)
+(6.2.17 server Statement Grammar)
 endobj
 557 0 obj
-<< /S /GoTo /D (subsection.6.2.20) >>
+<< /S /GoTo /D (subsection.6.2.18) >>
 endobj
 560 0 obj
-(6.2.20 statistics-channels Statement Definition and Usage)
+(6.2.18 server Statement Definition and Usage)
 endobj
 561 0 obj
-<< /S /GoTo /D (subsection.6.2.21) >>
+<< /S /GoTo /D (subsection.6.2.19) >>
 endobj
 564 0 obj
-(6.2.21 trusted-keys Statement Grammar)
+(6.2.19 statistics-channels Statement Grammar)
 endobj
 565 0 obj
-<< /S /GoTo /D (subsection.6.2.22) >>
+<< /S /GoTo /D (subsection.6.2.20) >>
 endobj
 568 0 obj
-(6.2.22 trusted-keys Statement Definition and Usage)
+(6.2.20 statistics-channels Statement Definition and Usage)
 endobj
 569 0 obj
-<< /S /GoTo /D (subsection.6.2.23) >>
+<< /S /GoTo /D (subsection.6.2.21) >>
 endobj
 572 0 obj
-(6.2.23 managed-keys Statement Grammar)
+(6.2.21 trusted-keys Statement Grammar)
 endobj
 573 0 obj
-<< /S /GoTo /D (subsection.6.2.24) >>
+<< /S /GoTo /D (subsection.6.2.22) >>
 endobj
 576 0 obj
-(6.2.24 managed-keys Statement Definition and Usage)
+(6.2.22 trusted-keys Statement Definition and Usage)
 endobj
 577 0 obj
-<< /S /GoTo /D (subsection.6.2.25) >>
+<< /S /GoTo /D (subsection.6.2.23) >>
 endobj
 580 0 obj
-(6.2.25 view Statement Grammar)
+(6.2.23 managed-keys Statement Grammar)
 endobj
 581 0 obj
-<< /S /GoTo /D (subsection.6.2.26) >>
+<< /S /GoTo /D (subsection.6.2.24) >>
 endobj
 584 0 obj
-(6.2.26 view Statement Definition and Usage)
+(6.2.24 managed-keys Statement Definition and Usage)
 endobj
 585 0 obj
-<< /S /GoTo /D (subsection.6.2.27) >>
+<< /S /GoTo /D (subsection.6.2.25) >>
 endobj
 588 0 obj
-(6.2.27 zone Statement Grammar)
+(6.2.25 view Statement Grammar)
 endobj
 589 0 obj
-<< /S /GoTo /D (subsection.6.2.28) >>
+<< /S /GoTo /D (subsection.6.2.26) >>
 endobj
 592 0 obj
-(6.2.28 zone Statement Definition and Usage)
+(6.2.26 view Statement Definition and Usage)
 endobj
 593 0 obj
-<< /S /GoTo /D (subsubsection.6.2.28.1) >>
+<< /S /GoTo /D (subsection.6.2.27) >>
 endobj
 596 0 obj
-(6.2.28.1 Zone Types)
+(6.2.27 zone Statement Grammar)
 endobj
 597 0 obj
-<< /S /GoTo /D (subsubsection.6.2.28.2) >>
+<< /S /GoTo /D (subsection.6.2.28) >>
 endobj
 600 0 obj
-(6.2.28.2 Class)
+(6.2.28 zone Statement Definition and Usage)
 endobj
 601 0 obj
-<< /S /GoTo /D (subsubsection.6.2.28.3) >>
+<< /S /GoTo /D (subsubsection.6.2.28.1) >>
 endobj
 604 0 obj
-(6.2.28.3 Zone Options)
+(6.2.28.1 Zone Types)
 endobj
 605 0 obj
-<< /S /GoTo /D (subsubsection.6.2.28.4) >>
+<< /S /GoTo /D (subsubsection.6.2.28.2) >>
 endobj
 608 0 obj
-(6.2.28.4 Dynamic Update Policies)
+(6.2.28.2 Class)
 endobj
 609 0 obj
-<< /S /GoTo /D (section.6.3) >>
+<< /S /GoTo /D (subsubsection.6.2.28.3) >>
 endobj
 612 0 obj
-(6.3 Zone File)
+(6.2.28.3 Zone Options)
 endobj
 613 0 obj
-<< /S /GoTo /D (subsection.6.3.1) >>
+<< /S /GoTo /D (subsubsection.6.2.28.4) >>
 endobj
 616 0 obj
-(6.3.1 Types of Resource Records and When to Use Them)
+(6.2.28.4 Dynamic Update Policies)
 endobj
 617 0 obj
-<< /S /GoTo /D (subsubsection.6.3.1.1) >>
+<< /S /GoTo /D (section.6.3) >>
 endobj
 620 0 obj
-(6.3.1.1 Resource Records)
+(6.3 Zone File)
 endobj
 621 0 obj
-<< /S /GoTo /D (subsubsection.6.3.1.2) >>
+<< /S /GoTo /D (subsection.6.3.1) >>
 endobj
 624 0 obj
-(6.3.1.2 Textual expression of RRs)
+(6.3.1 Types of Resource Records and When to Use Them)
 endobj
 625 0 obj
-<< /S /GoTo /D (subsection.6.3.2) >>
+<< /S /GoTo /D (subsubsection.6.3.1.1) >>
 endobj
 628 0 obj
-(6.3.2 Discussion of MX Records)
+(6.3.1.1 Resource Records)
 endobj
 629 0 obj
-<< /S /GoTo /D (subsection.6.3.3) >>
+<< /S /GoTo /D (subsubsection.6.3.1.2) >>
 endobj
 632 0 obj
-(6.3.3 Setting TTLs)
+(6.3.1.2 Textual expression of RRs)
 endobj
 633 0 obj
-<< /S /GoTo /D (subsection.6.3.4) >>
+<< /S /GoTo /D (subsection.6.3.2) >>
 endobj
 636 0 obj
-(6.3.4 Inverse Mapping in IPv4)
+(6.3.2 Discussion of MX Records)
 endobj
 637 0 obj
-<< /S /GoTo /D (subsection.6.3.5) >>
+<< /S /GoTo /D (subsection.6.3.3) >>
 endobj
 640 0 obj
-(6.3.5 Other Zone File Directives)
+(6.3.3 Setting TTLs)
 endobj
 641 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.1) >>
+<< /S /GoTo /D (subsection.6.3.4) >>
 endobj
 644 0 obj
-(6.3.5.1 The @ \(at-sign\))
+(6.3.4 Inverse Mapping in IPv4)
 endobj
 645 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.2) >>
+<< /S /GoTo /D (subsection.6.3.5) >>
 endobj
 648 0 obj
-(6.3.5.2 The \044ORIGIN Directive)
+(6.3.5 Other Zone File Directives)
 endobj
 649 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.3) >>
+<< /S /GoTo /D (subsubsection.6.3.5.1) >>
 endobj
 652 0 obj
-(6.3.5.3 The \044INCLUDE Directive)
+(6.3.5.1 The @ \(at-sign\))
 endobj
 653 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.4) >>
+<< /S /GoTo /D (subsubsection.6.3.5.2) >>
 endobj
 656 0 obj
-(6.3.5.4 The \044TTL Directive)
+(6.3.5.2 The \044ORIGIN Directive)
 endobj
 657 0 obj
-<< /S /GoTo /D (subsection.6.3.6) >>
+<< /S /GoTo /D (subsubsection.6.3.5.3) >>
 endobj
 660 0 obj
-(6.3.6 BIND Master File Extension: the \044GENERATE Directive)
+(6.3.5.3 The \044INCLUDE Directive)
 endobj
 661 0 obj
-<< /S /GoTo /D (subsection.6.3.7) >>
+<< /S /GoTo /D (subsubsection.6.3.5.4) >>
 endobj
 664 0 obj
-(6.3.7 Additional File Formats)
+(6.3.5.4 The \044TTL Directive)
 endobj
 665 0 obj
-<< /S /GoTo /D (section.6.4) >>
+<< /S /GoTo /D (subsection.6.3.6) >>
 endobj
 668 0 obj
-(6.4 BIND9 Statistics)
+(6.3.6 BIND Master File Extension: the \044GENERATE Directive)
 endobj
 669 0 obj
-<< /S /GoTo /D (subsubsection.6.4.0.1) >>
+<< /S /GoTo /D (subsection.6.3.7) >>
 endobj
 672 0 obj
-(6.4.0.1 The Statistics File)
+(6.3.7 Additional File Formats)
 endobj
 673 0 obj
-<< /S /GoTo /D (subsection.6.4.1) >>
+<< /S /GoTo /D (section.6.4) >>
 endobj
 676 0 obj
-(6.4.1 Statistics Counters)
+(6.4 BIND9 Statistics)
 endobj
 677 0 obj
-<< /S /GoTo /D (subsubsection.6.4.1.1) >>
+<< /S /GoTo /D (subsubsection.6.4.0.1) >>
 endobj
 680 0 obj
-(6.4.1.1 Name Server Statistics Counters)
+(6.4.0.1 The Statistics File)
 endobj
 681 0 obj
-<< /S /GoTo /D (subsubsection.6.4.1.2) >>
+<< /S /GoTo /D (subsection.6.4.1) >>
 endobj
 684 0 obj
-(6.4.1.2 Zone Maintenance Statistics Counters)
+(6.4.1 Statistics Counters)
 endobj
 685 0 obj
-<< /S /GoTo /D (subsubsection.6.4.1.3) >>
+<< /S /GoTo /D (subsubsection.6.4.1.1) >>
 endobj
 688 0 obj
-(6.4.1.3 Resolver Statistics Counters)
+(6.4.1.1 Name Server Statistics Counters)
 endobj
 689 0 obj
-<< /S /GoTo /D (subsubsection.6.4.1.4) >>
+<< /S /GoTo /D (subsubsection.6.4.1.2) >>
 endobj
 692 0 obj
-(6.4.1.4 Socket I/O Statistics Counters)
+(6.4.1.2 Zone Maintenance Statistics Counters)
 endobj
 693 0 obj
-<< /S /GoTo /D (subsubsection.6.4.1.5) >>
+<< /S /GoTo /D (subsubsection.6.4.1.3) >>
 endobj
 696 0 obj
-(6.4.1.5 Compatibility with BIND 8 Counters)
+(6.4.1.3 Resolver Statistics Counters)
 endobj
 697 0 obj
-<< /S /GoTo /D (chapter.7) >>
+<< /S /GoTo /D (subsubsection.6.4.1.4) >>
 endobj
 700 0 obj
-(7 BIND 9 Security Considerations)
+(6.4.1.4 Socket I/O Statistics Counters)
 endobj
 701 0 obj
-<< /S /GoTo /D (section.7.1) >>
+<< /S /GoTo /D (subsubsection.6.4.1.5) >>
 endobj
 704 0 obj
-(7.1 Access Control Lists)
+(6.4.1.5 Compatibility with BIND 8 Counters)
 endobj
 705 0 obj
-<< /S /GoTo /D (section.7.2) >>
+<< /S /GoTo /D (chapter.7) >>
 endobj
 708 0 obj
-(7.2 Chroot and Setuid)
+(7 BIND 9 Security Considerations)
 endobj
 709 0 obj
-<< /S /GoTo /D (subsection.7.2.1) >>
+<< /S /GoTo /D (section.7.1) >>
 endobj
 712 0 obj
-(7.2.1 The chroot Environment)
+(7.1 Access Control Lists)
 endobj
 713 0 obj
-<< /S /GoTo /D (subsection.7.2.2) >>
+<< /S /GoTo /D (section.7.2) >>
 endobj
 716 0 obj
-(7.2.2 Using the setuid Function)
+(7.2 Chroot and Setuid)
 endobj
 717 0 obj
-<< /S /GoTo /D (section.7.3) >>
+<< /S /GoTo /D (subsection.7.2.1) >>
 endobj
 720 0 obj
-(7.3 Dynamic Update Security)
+(7.2.1 The chroot Environment)
 endobj
 721 0 obj
-<< /S /GoTo /D (chapter.8) >>
+<< /S /GoTo /D (subsection.7.2.2) >>
 endobj
 724 0 obj
-(8 Troubleshooting)
+(7.2.2 Using the setuid Function)
 endobj
 725 0 obj
-<< /S /GoTo /D (section.8.1) >>
+<< /S /GoTo /D (section.7.3) >>
 endobj
 728 0 obj
-(8.1 Common Problems)
+(7.3 Dynamic Update Security)
 endobj
 729 0 obj
-<< /S /GoTo /D (subsection.8.1.1) >>
+<< /S /GoTo /D (chapter.8) >>
 endobj
 732 0 obj
-(8.1.1 It's not working; how can I figure out what's wrong?)
+(8 Troubleshooting)
 endobj
 733 0 obj
-<< /S /GoTo /D (section.8.2) >>
+<< /S /GoTo /D (section.8.1) >>
 endobj
 736 0 obj
-(8.2 Incrementing and Changing the Serial Number)
+(8.1 Common Problems)
 endobj
 737 0 obj
-<< /S /GoTo /D (section.8.3) >>
+<< /S /GoTo /D (subsection.8.1.1) >>
 endobj
 740 0 obj
-(8.3 Where Can I Get Help?)
+(8.1.1 It's not working; how can I figure out what's wrong?)
 endobj
 741 0 obj
-<< /S /GoTo /D (appendix.A) >>
+<< /S /GoTo /D (section.8.2) >>
 endobj
 744 0 obj
-(A Appendices)
+(8.2 Incrementing and Changing the Serial Number)
 endobj
 745 0 obj
-<< /S /GoTo /D (section.A.1) >>
+<< /S /GoTo /D (section.8.3) >>
 endobj
 748 0 obj
-(A.1 Acknowledgments)
+(8.3 Where Can I Get Help?)
 endobj
 749 0 obj
-<< /S /GoTo /D (subsection.A.1.1) >>
+<< /S /GoTo /D (appendix.A) >>
 endobj
 752 0 obj
-(A.1.1 A Brief History of the DNS and BIND)
+(A Appendices)
 endobj
 753 0 obj
-<< /S /GoTo /D (section.A.2) >>
+<< /S /GoTo /D (section.A.1) >>
 endobj
 756 0 obj
-(A.2 General DNS Reference Information)
+(A.1 Acknowledgments)
 endobj
 757 0 obj
-<< /S /GoTo /D (subsection.A.2.1) >>
+<< /S /GoTo /D (subsection.A.1.1) >>
 endobj
 760 0 obj
-(A.2.1 IPv6 addresses \(AAAA\))
+(A.1.1 A Brief History of the DNS and BIND)
 endobj
 761 0 obj
-<< /S /GoTo /D (section.A.3) >>
+<< /S /GoTo /D (section.A.2) >>
 endobj
 764 0 obj
-(A.3 Bibliography \(and Suggested Reading\))
+(A.2 General DNS Reference Information)
 endobj
 765 0 obj
-<< /S /GoTo /D (subsection.A.3.1) >>
+<< /S /GoTo /D (subsection.A.2.1) >>
 endobj
 768 0 obj
-(A.3.1 Request for Comments \(RFCs\))
+(A.2.1 IPv6 addresses \(AAAA\))
 endobj
 769 0 obj
-<< /S /GoTo /D (subsection.A.3.2) >>
+<< /S /GoTo /D (section.A.3) >>
 endobj
 772 0 obj
-(A.3.2 Internet Drafts)
+(A.3 Bibliography \(and Suggested Reading\))
 endobj
 773 0 obj
-<< /S /GoTo /D (subsection.A.3.3) >>
+<< /S /GoTo /D (subsection.A.3.1) >>
 endobj
 776 0 obj
-(A.3.3 Other Documents About BIND)
+(A.3.1 Request for Comments \(RFCs\))
 endobj
 777 0 obj
-<< /S /GoTo /D (section.A.4) >>
+<< /S /GoTo /D (subsection.A.3.2) >>
 endobj
 780 0 obj
-(A.4 BIND 9 DNS Library Support)
+(A.3.2 Internet Drafts)
 endobj
 781 0 obj
-<< /S /GoTo /D (subsection.A.4.1) >>
+<< /S /GoTo /D (subsection.A.3.3) >>
 endobj
 784 0 obj
-(A.4.1 Prerequisite)
+(A.3.3 Other Documents About BIND)
 endobj
 785 0 obj
-<< /S /GoTo /D (subsection.A.4.2) >>
+<< /S /GoTo /D (section.A.4) >>
 endobj
 788 0 obj
-(A.4.2 Compilation)
+(A.4 BIND 9 DNS Library Support)
 endobj
 789 0 obj
-<< /S /GoTo /D (subsection.A.4.3) >>
+<< /S /GoTo /D (subsection.A.4.1) >>
 endobj
 792 0 obj
-(A.4.3 Installation)
+(A.4.1 Prerequisite)
 endobj
 793 0 obj
-<< /S /GoTo /D (subsection.A.4.4) >>
+<< /S /GoTo /D (subsection.A.4.2) >>
 endobj
 796 0 obj
-(A.4.4 Known Defects/Restrictions)
+(A.4.2 Compilation)
 endobj
 797 0 obj
-<< /S /GoTo /D (subsection.A.4.5) >>
+<< /S /GoTo /D (subsection.A.4.3) >>
 endobj
 800 0 obj
-(A.4.5 The dns.conf File)
+(A.4.3 Installation)
 endobj
 801 0 obj
-<< /S /GoTo /D (subsection.A.4.6) >>
+<< /S /GoTo /D (subsection.A.4.4) >>
 endobj
 804 0 obj
-(A.4.6 Sample Applications)
+(A.4.4 Known Defects/Restrictions)
 endobj
 805 0 obj
-<< /S /GoTo /D (subsubsection.A.4.6.1) >>
+<< /S /GoTo /D (subsection.A.4.5) >>
 endobj
 808 0 obj
-(A.4.6.1 sample: a simple stub resolver utility)
+(A.4.5 The dns.conf File)
 endobj
 809 0 obj
-<< /S /GoTo /D (subsubsection.A.4.6.2) >>
+<< /S /GoTo /D (subsection.A.4.6) >>
 endobj
 812 0 obj
-(A.4.6.2 sample-async: a simple stub resolver, working asynchronously)
+(A.4.6 Sample Applications)
 endobj
 813 0 obj
-<< /S /GoTo /D (subsubsection.A.4.6.3) >>
+<< /S /GoTo /D (subsubsection.A.4.6.1) >>
 endobj
 816 0 obj
-(A.4.6.3 sample-request: a simple DNS transaction client)
+(A.4.6.1 sample: a simple stub resolver utility)
 endobj
 817 0 obj
-<< /S /GoTo /D (subsubsection.A.4.6.4) >>
+<< /S /GoTo /D (subsubsection.A.4.6.2) >>
 endobj
 820 0 obj
-(A.4.6.4 sample-gai: getaddrinfo\(\) and getnameinfo\(\) test code)
+(A.4.6.2 sample-async: a simple stub resolver, working asynchronously)
 endobj
 821 0 obj
-<< /S /GoTo /D (subsubsection.A.4.6.5) >>
+<< /S /GoTo /D (subsubsection.A.4.6.3) >>
 endobj
 824 0 obj
-(A.4.6.5 sample-update: a simple dynamic update client program)
+(A.4.6.3 sample-request: a simple DNS transaction client)
 endobj
 825 0 obj
-<< /S /GoTo /D (subsubsection.A.4.6.6) >>
+<< /S /GoTo /D (subsubsection.A.4.6.4) >>
 endobj
 828 0 obj
-(A.4.6.6 nsprobe: domain/name server checker in terms of RFC 4074)
+(A.4.6.4 sample-gai: getaddrinfo\(\) and getnameinfo\(\) test code)
 endobj
 829 0 obj
-<< /S /GoTo /D (subsection.A.4.7) >>
+<< /S /GoTo /D (subsubsection.A.4.6.5) >>
 endobj
 832 0 obj
-(A.4.7 Library References)
+(A.4.6.5 sample-update: a simple dynamic update client program)
 endobj
 833 0 obj
-<< /S /GoTo /D (appendix.B) >>
+<< /S /GoTo /D (subsubsection.A.4.6.6) >>
 endobj
 836 0 obj
-(B Manual pages)
+(A.4.6.6 nsprobe: domain/name server checker in terms of RFC 4074)
 endobj
 837 0 obj
-<< /S /GoTo /D (section.B.1) >>
+<< /S /GoTo /D (subsection.A.4.7) >>
 endobj
 840 0 obj
-(B.1 dig)
+(A.4.7 Library References)
 endobj
 841 0 obj
-<< /S /GoTo /D (section.B.2) >>
+<< /S /GoTo /D (appendix.B) >>
 endobj
 844 0 obj
-(B.2 host)
+(B Manual pages)
 endobj
 845 0 obj
-<< /S /GoTo /D (section.B.3) >>
+<< /S /GoTo /D (section.B.1) >>
 endobj
 848 0 obj
-(B.3 dnssec-dsfromkey)
+(B.1 dig)
 endobj
 849 0 obj
-<< /S /GoTo /D (section.B.4) >>
+<< /S /GoTo /D (section.B.2) >>
 endobj
 852 0 obj
-(B.4 dnssec-keyfromlabel)
+(B.2 host)
 endobj
 853 0 obj
-<< /S /GoTo /D (section.B.5) >>
+<< /S /GoTo /D (section.B.3) >>
 endobj
 856 0 obj
-(B.5 dnssec-keygen)
+(B.3 dnssec-dsfromkey)
 endobj
 857 0 obj
-<< /S /GoTo /D (section.B.6) >>
+<< /S /GoTo /D (section.B.4) >>
 endobj
 860 0 obj
-(B.6 dnssec-revoke)
+(B.4 dnssec-keyfromlabel)
 endobj
 861 0 obj
-<< /S /GoTo /D (section.B.7) >>
+<< /S /GoTo /D (section.B.5) >>
 endobj
 864 0 obj
-(B.7 dnssec-settime)
+(B.5 dnssec-keygen)
 endobj
 865 0 obj
-<< /S /GoTo /D (section.B.8) >>
+<< /S /GoTo /D (section.B.6) >>
 endobj
 868 0 obj
-(B.8 dnssec-signzone)
+(B.6 dnssec-revoke)
 endobj
 869 0 obj
-<< /S /GoTo /D (section.B.9) >>
+<< /S /GoTo /D (section.B.7) >>
 endobj
 872 0 obj
-(B.9 named-checkconf)
+(B.7 dnssec-settime)
 endobj
 873 0 obj
-<< /S /GoTo /D (section.B.10) >>
+<< /S /GoTo /D (section.B.8) >>
 endobj
 876 0 obj
-(B.10 named-checkzone)
+(B.8 dnssec-signzone)
 endobj
 877 0 obj
-<< /S /GoTo /D (section.B.11) >>
+<< /S /GoTo /D (section.B.9) >>
 endobj
 880 0 obj
-(B.11 named)
+(B.9 named-checkconf)
 endobj
 881 0 obj
-<< /S /GoTo /D (section.B.12) >>
+<< /S /GoTo /D (section.B.10) >>
 endobj
 884 0 obj
-(B.12 named-journalprint)
+(B.10 named-checkzone)
 endobj
 885 0 obj
-<< /S /GoTo /D (section.B.13) >>
+<< /S /GoTo /D (section.B.11) >>
 endobj
 888 0 obj
-(B.13 nsupdate)
+(B.11 named)
 endobj
 889 0 obj
-<< /S /GoTo /D (section.B.14) >>
+<< /S /GoTo /D (section.B.12) >>
 endobj
 892 0 obj
-(B.14 rndc)
+(B.12 named-journalprint)
 endobj
 893 0 obj
-<< /S /GoTo /D (section.B.15) >>
+<< /S /GoTo /D (section.B.13) >>
 endobj
 896 0 obj
-(B.15 rndc.conf)
+(B.13 nsupdate)
 endobj
 897 0 obj
-<< /S /GoTo /D (section.B.16) >>
+<< /S /GoTo /D (section.B.14) >>
 endobj
 900 0 obj
-(B.16 rndc-confgen)
+(B.14 rndc)
 endobj
 901 0 obj
-<< /S /GoTo /D (section.B.17) >>
+<< /S /GoTo /D (section.B.15) >>
 endobj
 904 0 obj
-(B.17 ddns-confgen)
+(B.15 rndc.conf)
 endobj
 905 0 obj
-<< /S /GoTo /D (section.B.18) >>
+<< /S /GoTo /D (section.B.16) >>
 endobj
 908 0 obj
-(B.18 arpaname)
+(B.16 rndc-confgen)
 endobj
 909 0 obj
-<< /S /GoTo /D (section.B.19) >>
+<< /S /GoTo /D (section.B.17) >>
 endobj
 912 0 obj
-(B.19 genrandom)
+(B.17 ddns-confgen)
 endobj
 913 0 obj
-<< /S /GoTo /D (section.B.20) >>
+<< /S /GoTo /D (section.B.18) >>
 endobj
 916 0 obj
-(B.20 isc-hmac-fixup)
+(B.18 arpaname)
 endobj
 917 0 obj
-<< /S /GoTo /D (section.B.21) >>
+<< /S /GoTo /D (section.B.19) >>
 endobj
 920 0 obj
-(B.21 nsec3hash)
+(B.19 genrandom)
 endobj
 921 0 obj
-<< /S /GoTo /D [922 0 R  /FitH ] >>
+<< /S /GoTo /D (section.B.20) >>
+endobj
+924 0 obj
+(B.20 isc-hmac-fixup)
+endobj
+925 0 obj
+<< /S /GoTo /D (section.B.21) >>
 endobj
-925 0 obj <<
+928 0 obj
+(B.21 nsec3hash)
+endobj
+929 0 obj
+<< /S /GoTo /D [930 0 R  /FitH ] >>
+endobj
+933 0 obj <<
 /Length 240       
 /Filter /FlateDecode
 >>
@@ -1384,32 +1396,32 @@ stream
 xÚ•�OKAÅïó)rl›N2Éü9ZªRA¡27ñ°´[)¸[ºÖïïlWË‚^$�0ïý˜y[Š *Z—BTK
 ÛÖXx+Þ½¡oFÔ¡Šsåð‡[	LÁ+T\@1M±_8±Eo=C¥BÈÌ~À—Ù,CyÄŠƒÂ•Ë»—Ùrý´š——ì,�ãf׺Ãǹ¯ÏÇ~”ž›}Ó7ݶ™¿æ a$/¾äKc¼\óXwŸõûà›Û|
§â1'p®äðqH'`Ôð3‹zšüßÚ±y±n	VG³1°™ž07l(%tî[þM^Xúendstream
 endobj
-922 0 obj <<
+930 0 obj <<
 /Type /Page
-/Contents 925 0 R
-/Resources 924 0 R
+/Contents 933 0 R
+/Resources 932 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 931 0 R
+/Parent 939 0 R
 >> endobj
-923 0 obj <<
+931 0 obj <<
 /Type /XObject
 /Subtype /Form
 /FormType 1
 /PTEX.FileName (./isc-logo.pdf)
 /PTEX.PageNumber 1
-/PTEX.InfoDict 932 0 R 
+/PTEX.InfoDict 940 0 R 
 /Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
 /BBox [0.00000000 0.00000000 612.00000000 792.00000000]
 /PieceInfo <<
-/Illustrator 933 0 R
+/Illustrator 941 0 R
 >>
 /Resources <<
 /ColorSpace <<
-/CS0 934 0 R
+/CS0 942 0 R
 >>/Properties <<
-/MC0 935 0 R
+/MC0 943 0 R
 >>/ExtGState <<
-/GS0 936 0 R
+/GS0 944 0 R
 >>>>
 /Length 843
 /Filter /FlateDecode
@@ -1425,7 +1437,7 @@ BqÕ•l9uš
 !=§ ¨Œø†vGc	£I#/'~<1‚ÀÔRPy±´ýl1½Ͷw1	чd

}¡þa
 Ë9b	�:žÎÞF"‹>64”~0IGD˜ËØ°$ÙtMâ¯%Z½Gð¾¥Úñ§a�ÑÌ‘I¼ý—/øýzü+À
 endobj
-932 0 obj
+940 0 obj
 <<
 /CreationDate (D:20100303120319-08'00')
 /Creator (Adobe Illustrator CS3)
@@ -1434,24 +1446,24 @@ endobj
 /Title (ISC_logo_only_RGB)
 >>
 endobj
-933 0 obj
+941 0 obj
 <<
-/Private 937 0 R
+/Private 945 0 R
 /LastModified (D:20100412113400-07'00')
 >>
 endobj
-934 0 obj
-[/ICCBased 938 0 R]
+942 0 obj
+[/ICCBased 946 0 R]
 endobj
-935 0 obj
+943 0 obj
 <<
-/Intent 939 0 R
-/Usage 940 0 R
+/Intent 947 0 R
+/Usage 948 0 R
 /Name (Layer 1)
 /Type /OCG
 >>
 endobj
-936 0 obj
+944 0 obj
 <<
 /OPM 1
 /BM /Normal
@@ -1465,22 +1477,22 @@ endobj
 /SA true
 >>
 endobj
-937 0 obj
+945 0 obj
 <<
 /RoundtripVersion 13
 /ContainerVersion 11
 /CreatorVersion 13
-/AIMetaData 941 0 R
-/AIPrivateData1 942 0 R
-/AIPrivateData2 943 0 R
-/AIPrivateData3 944 0 R
-/AIPrivateData4 945 0 R
-/AIPrivateData5 946 0 R
+/AIMetaData 949 0 R
+/AIPrivateData1 950 0 R
+/AIPrivateData2 951 0 R
+/AIPrivateData3 952 0 R
+/AIPrivateData4 953 0 R
+/AIPrivateData5 954 0 R
 /NumBlock 5
 /RoundtripStreamType 1
 >>
 endobj
-938 0 obj
+946 0 obj
 <<
 /Length 281
 /Filter /FlateDecode
@@ -1491,10 +1503,10 @@ H‰b``2ptqre``ÈÍ+)
 rwRˆˆŒR`?ÏÀÆÀÌ
 ò‹KRS€j!îAˆBPˆi
 endobj
-939 0 obj
+947 0 obj
 [/View/Design]
 endobj
-940 0 obj
+948 0 obj
 <<
 /CreatorInfo <<
 /Subtype /Artwork
@@ -1502,21 +1514,21 @@ endobj
 >>
 >>
 endobj
-941 0 obj
+949 0 obj
 <<
 /Length 981
 >>
 stream
 %!PS-Adobe-3.0 
%%Creator: Adobe Illustrator(R) 13.0
%%AI8_CreatorVersion: 13.0.2
%%For: (Brian Reid) ()
%%Title: (ISC_logo_only_RGB.ai)
%%CreationDate: 4/12/10 11:34 AM
%%BoundingBox: 247 367 366 413
%%HiResBoundingBox: 247.0869 367.5654 365.0859 412.583
%%DocumentProcessColors: Cyan Magenta Yellow Black
%AI5_FileFormat 9.0
%AI12_BuildNumber: 434
%AI3_ColorUsage: Color
%AI7_ImageSettings: 0
%%RGBProcessColor: 0 0.658824 0.8 (ISC logo blue)
%%+ 0.372549 0.376471 0.384314 (PANTONE 425 U)
%%+ 0 0 0 ([Registration])
%AI3_TemplateBox: 306.5 395.5 306.5 395.5
%AI3_TileBox: 18 33.1201 594 786.96
%AI3_DocumentPreview: None
%AI5_ArtSize: 612 792
%AI5_RulerUnits: 3
%AI9_ColorModel: 1
%AI5_ArtFlags: 0 0 0 1 0 0 0 0 0
%AI5_TargetResolution: 800
%AI5_NumLayers: 1
%AI9_OpenToView: -381 793 0.92 1268 743 26 0 0 117 75 0 0 1 1 1 0 1
%AI5_OpenViewLayers: 7
%%PageOrigin:0 0
%AI7_GridSettings: 72 8 72 8 1 0 0.8 0.8 0.8 0.9 0.9 0.9
%AI9_Flatten: 1
%AI12_CMSettings: 00.MS
%%EndComments
endstream
 endobj
-942 0 obj
+950 0 obj
 <<
 /Length 11082
 >>
 stream
 %%BoundingBox: 247 367 366 413
%%HiResBoundingBox: 247.0869 367.5654 365.0859 412.583
%AI7_Thumbnail: 128 52 8
%%BeginData: 10932 Hex Bytes
%0000330000660000990000CC0033000033330033660033990033CC0033FF
%0066000066330066660066990066CC0066FF009900009933009966009999
%0099CC0099FF00CC0000CC3300CC6600CC9900CCCC00CCFF00FF3300FF66
%00FF9900FFCC3300003300333300663300993300CC3300FF333300333333
%3333663333993333CC3333FF3366003366333366663366993366CC3366FF
%3399003399333399663399993399CC3399FF33CC0033CC3333CC6633CC99
%33CCCC33CCFF33FF0033FF3333FF6633FF9933FFCC33FFFF660000660033
%6600666600996600CC6600FF6633006633336633666633996633CC6633FF
%6666006666336666666666996666CC6666FF669900669933669966669999
%6699CC6699FF66CC0066CC3366CC6666CC9966CCCC66CCFF66FF0066FF33
%66FF6666FF9966FFCC66FFFF9900009900339900669900999900CC9900FF
%9933009933339933669933999933CC9933FF996600996633996666996699
%9966CC9966FF9999009999339999669999999999CC9999FF99CC0099CC33
%99CC6699CC9999CCCC99CCFF99FF0099FF3399FF6699FF9999FFCC99FFFF
%CC0000CC0033CC0066CC0099CC00CCCC00FFCC3300CC3333CC3366CC3399
%CC33CCCC33FFCC6600CC6633CC6666CC6699CC66CCCC66FFCC9900CC9933
%CC9966CC9999CC99CCCC99FFCCCC00CCCC33CCCC66CCCC99CCCCCCCCCCFF
%CCFF00CCFF33CCFF66CCFF99CCFFCCCCFFFFFF0033FF0066FF0099FF00CC
%FF3300FF3333FF3366FF3399FF33CCFF33FFFF6600FF6633FF6666FF6699
%FF66CCFF66FFFF9900FF9933FF9966FF9999FF99CCFF99FFFFCC00FFCC33
%FFCC66FFCC99FFCCCCFFCCFFFFFF33FFFF66FFFF99FFFFCC110000001100
%000011111111220000002200000022222222440000004400000044444444
%550000005500000055555555770000007700000077777777880000008800
%000088888888AA000000AA000000AAAAAAAABB000000BB000000BBBBBBBB
%DD000000DD000000DDDDDDDDEE000000EE000000EEEEEEEE0000000000FF
%00FF0000FFFFFF0000FF00FFFFFF00FFFFFF
%524C45FD1F52285252A8FD04FFFD05A8FFFFFFA87DFD4F52285252522852
%525228525252285252522852525228525252285252522852277DA8FFFFA8
%7D7D525227FD04527DA8FFFFA85252275252522852525228525252285252
%522852525228525252285252522852525228525252285252522852525228
%52525228525252285252522852525228525252285252522852525228FD21
%52A8FFFF7D7D525227FD0752275252A8FFFF7DFD215227FD2A522E522752
%2E5227522E5227522E5227522E5227522E5227522E5227527DFFFFA85252
%27522E5227522E5227522E5227522752A8FF7D5227522E5227522E522752
%2E5227522E5227522E5227522E5227522E522752277D7D7D275227522E52
%27522E5227522E5227522E5227522E5227522E5227522E5227522E522752
%2E5227FD1A52277DA8FFA87D2EFD11522E527DFFA853FD1D52A8FFFFFF7D
%28FD285228525252285252522852525228525252285252522852277DFFFF
%7D522752525228525252285252522852525228525252275252FFA8522752
%285252522852525228525252285252522852525228525252277DFFA852A8
%FF5227525252285252522852525228525252285252522852525228525252
%285252522852525228FD1852277DFFFFFD1B52FFA8FD1A527DFFA8275252
%FF7DFD265227522E5227522E5227522E5227522E5227522E522752277DFF
%FF525227522E5227522E5227522E5227522E5227522E5227522E52275252
%FFA852275227522E5227522E5227522E5227522E5227522E522752A8A827
%522E527DA9275227522E5227522E5227522E5227522E5227522E52275227
%5227522E5227522E5227522EFD17527DFFA8FD1E527DFFA8FD17527DFFFD
%0452287DFFFD155228FD075228FD08522852525228525252285252522852
%5252285252522852527D2752525228525252285252522852525228525252
%2852525228525252285252527DFF7D522852525228525252285252522852
%525228FD0452FF7D5228FD0452FF52522852525228525252285252522752
%2752527DA1A8A8FFCACFA8CAA17D5252275228FD3C52A8FFFD145228A8FF
%53FD0652FFA82EFD0C527D7DCAFD04FFAFAF85AF85AFAFFFFFFFA87DFD05
%522E5227522E5227522E5227522E5227522E5227522E5227522E5227522E
%5227522E5227522E5227522E5227522E5227522E5227522E5227522752A8
%FF275227522E5227522E5227522E5227522E522752FFA827522E5227522E
%FF7D522E5227522E522752275252A8FFFFAFAF603CFD041413FD04143C60
%AFFFFF535227FD3A52277DFFA827FD11527DFFFD0852A8FFFD0952A8CFFF
%FFAF3C3D1414141A141A141A141A141A14141461AFFFA8FD045228525252
%285252522852525228525252285252522852525228525252285252522852
%5252285252522852525228525252285252522852525227A8FF5227525252
%2852525228525252285252522EFFA85227525252285228A87D5252522852
%27527DFFFFAF603CFD07141A1414141A1414141AFD041460FFA8FD3D52FF
%A8FD10527DFF7DFD0F527DFFFFA9611414141A141A141A141A141A141A14
%1A141A141A141A14143CFFA827522E5227522E5227522E5227522E522752
%2E5227522E5227522E5227522E5227522E5227522E5227522E5227522E52
%27522E5227522E5227522E527DFF525227522E5227522E5227522E522752
%A8FF27522E5227522E5227522852275252A8FFFF3C1413FD191436FFFD3C
%5259FFA828FD0E52FF7DFD0D527DFFFF8B1414141A141A141A141A141A14
%1A141A141A141A141A141A141A141A141460285252522852525228525252
%285252522852525228525252275227522752275227525252285252522852
%52522852525228525252285252522852525227A8FF7D2752525228525252
%2852525227A8FF52275252522852525228522752A8FFA93CFD05141A1414
%141A1414141A1414141A1414141A1414141A1414141A1414FD1552285252
%7D527D597D527DFD065227FD1852FFA8FD0D52FFFFFD0A52277DFFFF601A
%141A141A141A141A141A141A141A141A141A141A141A141A141A141A141A
%141A142E5227522E5227522E5227522E5227522752527D7DA8A8FD09FFA8
%FFA8A87D532852275227522E5227522E5227522E5227522E5227522E527D
%FF525227522E5227522E52275252FF7D522E5227522E522752277DFFFF36
%FD2314FD0E527D7DFD07FFA8A87DA87DA87DFD04A8FD05FFA87DFD15527D
%FFA827FD0A52A8FF7DFD0952A8FFAF1414141A141A141A141A141A141A14
%1A141A141A141A141A141A141A141A141A141A141A145252285252522852
%525227527DA8FFFFFFA87D7D52522752275227522752275227522752527D
%A8FFFFFFA87E52522752525228525252285252522852525227A8FF522752
%5252285252522752FFA8275252522852525227A8FF85FD05141A1414141A
%1414141A1414141A1414141A1414141A1414141A1414141A1414141AFD07
%52275253A8FFFFFFA8FD045227FD0F522EFD04527D7DFFFFFFA87DFD1052
%7DFF7DFD0A52FF7DFD0852A8FF8B1414141A141A141A141A141A141A141A
%141A141A141A141A141A141A141A141A141A141A141A1427522E52275227
%7DA8FFFFA85252275227522E5227522E5227522E5227522E5227522E5227
%522E52275227527DFFFFFF7D52275227522E5227522E5227522752A8A827
%5227522E52275227A8FF5227522752525227A8FF6113FD2714FD0652A8FF
%FF7D7D28FD22527DA8FFFF7DFD0C5227A8FF7DFD0852A8FFFD06522EA8FF
%61141A141A141A141A141A141A141A141A141A141A141A141A141A141A14
%1A141A141A141A141A141A14285227527DFFFF7D52522752285252522852
%525228525252285252522852525228525252285252522852525228522752
%52FFFFA8525228522852525228FD0452FF7D5228525252285252FF7D5252
%52285227A8FF611414141A1414141A1414141A1414141A1414141A141414
%1A1414141A1414141A1414141A1414141A141452277DFFFFA87D28FD2952
%287DFFFF7EFD0B52A8FFFD065227A8FF7D2752525227A8FF8B141A141A14
%1A141A141A141A141A141A141A141A141A141A141A141A141A141A141A14
%1A141A141A141A1428A8FFFF525227522E5227522E5227522E5227522E52
%27522E5227522E5227522E5227522E5227522E5227522E5227522E522752
%7DFFA87D275227522E522752277EFF52275227522852A8FF52522752277D
%FF8BFD121413FD0F1413FD0914FFFFA8FD3352FFFFA8FD0952FF7DFD0652
%FFA8FD04527DFFAF141A141A141A141A141A141A141A141A141A14613C3C
%141A141A141A141A141A141A143D3C3C141A141A141A14FF7D2752525228
%525252285252522852525228525252285252522852525228525252285252
%522852525228525252285252522852525227A8FFA8FD045228525252A8A8
%27522852277DFF7D27522752A8FFFD051461A9AF848B1414141A141436AF
%AFFFFFFFAFAF36FD04141A14141461A9FFAFFFAFAF601A1414141A7D2EFD
%3552277DFFFFFD0752A8FFFD05527DFFFD04527DFF3C14141A141484FFFF
%FFAF1A141A141A85FD09FF841A141A141A14AFFD08FF841A141A1427522E
%5227522E5227522E5227522E5227522E5227522E5227522E5227522E5227
%522E5227522E5227522E5227522E5227522E5227522E52277DA8FF52522E
%5227527DFF52522E5227FFA852275252FF60FD061485FFFFFFAFFD041460
%FD0BFF36FD0414AFFD0AFF60141414FD3A5253FFFF7DFD04527DFFA85252
%527DFFA8285252FFAF1A141A141A141A84FFFFFFAF3D141A14FD05FF603D
%60FD04FFAF141A1461FD04FFA96136AFFD04FF141A142852525228525252
%285252522852525228525252285252522852525228525252285252522852
%52522852525228525252285252522852525228522752A8FF5252285252FF
%A8FD0452FF7D5227A8FF3C141AFD051485FFFFFFAF14141460FD04FF3614
%141460FFFFFFA91A141484FFFFFFA91A141414FD04FF611414FD3D52A8FF
%FD0452A8FF525228A8FF7D277DFF8B141A141A141A141A85FFFFFFAF1A14
%1A60FD04FF3C141A1461FD04FF141A14FD04FF8B141A141AAFFFFFFF601A
%142E5227522E5227522E5227522E5227522E5227522E5227522E5227522E
%5227522E5227522E5227522E5227522E5227522E5227522E5227522E5227
%522752A8FF5252277DFF7D2752A8FF2752A8FFFD08141385FFFFFFAF1414
%1361FD04FF36FD04148584856014133CFD04FF60FD0414FD04FF851314FD
%3D52287DFFFF525252FF7D5252FFA8527DFF3C1A141A141A141A141A85FF
%FFFFAF1A141A60FD04FFAF141A141A141A141A141A3CFD04FF61141A141A
%3C616061361A145252285252522852525228525252285252522852525228
%525252285252522852525228525252285252522852525228525252275252
%522752525228525252277DFF7E2752FFA82753FF7E27FFA914141A141414
%1A1414148BFFFFFFAF1414143CAFFD04FFAFFD091461FD04FF3614141AFD
%07141AFD2B522852285227FD075227FD075227A8FF7D27FFA8527DFF7D7D
%FF3D141A141A141A141A141484FFFFFFA91A141A1485FD06FF603C141A14
%1A14143CFD04FF61141A141A141A141A141A1427522E5227522E5227522E
%5227522E5227522E5227522E5227522E5227522E5227522E522752275227
%FD04527D7DA8A8FFA8FFA8FFA8A87D7D52522752275227FFA8527DFF277D
%FF52A8AF13FD0A1485FFFFFFAFFD0414138BFD06FFA860FD05143CFD04FF
%36FD0B14FD2852A8A8FD07FFA8FFA8FFA8FD06FFA87D5227527DFF7D7DFF
%7DA8FF7DFF3C1A141A141A141A141A141A84FFFFFFAF3D141A141A148BFD
%07FF8B141A141A3CFD04FF61141A141A141A141A141A1428525252285252
%522852525228525252285252522852525228525252285252522752275252
%A8A8FFFFFFA8A87D7DFD065227FD04527D7DA8FFFFA87D2752A8FF52FF7D
%A8A8CAA914141A1414141A1414141A1485FFFFFFAFFD071460A8FD06FF8B
%1414143CFD04FF36FD04141A1414141A1414FD2252A8FD04FF7D7D525228
%5227FD0B52275252527DFFFFFF5253FFA8A8A8FFA8FF61141A141A141A14
%1A141A141A85FFFFFFAF1A141A141A141A141A60FD06FF85141A3CFD04FF
%61141A141A141A141A141A142E5227522E5227522E5227522E5227522E52
%27522E5227522E5227522752277DA8FFFFA859522752275227522E522752
%2E5227522E5227522E5227522752277DA8FF7DA8FFFFA8FFFFAFFD0C1413
%85FFFFFFAFFD061413FD0414AFFD04FFA9141360FD04FF36FD051413FD05
%14FD1D527DFFFFFF7D7DFD1E52A8FFA8FD05FF601A141A141A141A141A14
%1A141A85FFFFFFAF1A141A143D363D141A141A14FD05FF3C1A3CFD04FF61
%141A141A60AF85AF601A1452522852525228525252285252522852525228
%52525228525252277DFFFFA87D2E52275252522852525228525252285252
%52285252522852525228525252285228527DFD06FF3C141A1414141A1414
%141A1414148BFFFFFFAF141414AFFFFFAF8BFD04143CFD04FF3C143CFD04
%FF60FD04148BFFFFFFAF1414FD1752285259FFFFA9525227FD2352A8FD04
%FFAF141A141A141A141A141A141A141484FFFFFFA91A141484FFFFFFA91A
%141A1461FD04FF3C1414FD04FF8B141A141AA9FFFFFF85141427522E5227
%522E5227522E5227522E5227522E52275227527DFFA87D27522E5227522E
%5227522E5227522E5227522E5227522E5227522E5227522E5227522E5227
%522752A8FFFFFF60FD0E1485FFFFFFAF14141485FD04FFFD041436FD04FF
%3C141484FFFFFFA8FD0414FD04FF611414FD16527DFFFF7D5228FD275227
%A8FFFFFF3D141A141A141A141A141A141A141A84FFFFFFAF3D141460FD04
%FFAF363C3CFD05FF141A1461FD04FF853C148BFD04FF3C1A142752275227
%52275227522752275227522752275227A8FFA82852275227522752275227
%522752275227522752275227522752275227522752275227522752275227
%52275252FFFFAFFD0F1485FFFFFFAFFD0414A8FD05FFAFFD05FF36FD0414
%AFFD0AFF841414147D527D527D527D527D527D527D527D527D527D52A8FF
%FF527D527D527D527D527D527D527D527D527D527D527D527D527D527D52
%7D527D527D527D527D527D527D527D527DA8FF853C363D3C3C363D3C3C36
%3D3C3C363D85FFFFFFAF3D363D3685FD0AFFAF3C363D3C3C60FD0AFF6136
%3D3CFD16FFA8FD49FFAFFD11FFAFFD09FFAFFFFFFF
%%EndData
endstream
 endobj
-943 0 obj
+951 0 obj
 <<
 /Length 65536
 >>
@@ -1790,7 +1802,7 @@ sÓ
·ÓíÑ·OÒ„ŸuMÊ’ÏyÒ�ÁQÊ—*V€)-z=¦Hèªmƈœ~ÅñÓ×z…Sý[t¸c&4 ŽªªAj^råº;ņÜ�(�cçç
 Dx^QÜ×}Ì
 ˜ØyY‰Ÿ‹©
¨zŽ…N¬V¥%™­‚¨™@“£=HU˜ü¢³l0¼Tq_PIÐ/u,dÆö¶fý"íŒØ¾MMæu [endstream
 endobj
-944 0 obj
+952 0 obj
 <<
 /Length 65536
 >>
@@ -2032,7 +2044,7 @@ qlÞ¯­ò�×âô`>
 ¶“¬ûVG=#	[ül&wJ΂fkíY”&{öñß1øÀ	ÛÄ%'DSì
  F?؆Fß®U
E2,„Ò-[‰Ðð~Eô׈bˆ¨<Þë‹uAhÜš:®—Ú[ɬëxÏ*}ñ
 endobj
-945 0 obj
+953 0 obj
 <<
 /Length 65536
 >>
@@ -2255,7 +2267,7 @@ uALŽk‹Š=ŽÉÀÇš?éì•ëðå0ƒ¨Ua¦7S“«ÙŽ®&éÀ­Ó˜çÈî¹m(‚4„Ð�‹z35Ãùd2pnSø׸®÷—fSµNP™š
 ]×g1Í�¼‘ôAÚF¥5³ò(ª®
Í
 
 endobj
-946 0 obj
+954 0 obj
 <<
 /Length 53114
 >>
@@ -2452,43 +2464,43 @@ Y‘φ㧻Ç'ÇÕpV�—	´Š›·§/	óü8
 œ;ø#ñ<
Ý°'€å‰íöÐ"W€­
 Ö^IY�ïc­
 endobj
-926 0 obj <<
-/D [922 0 R /XYZ 85.0394 794.5015 null]
+934 0 obj <<
+/D [930 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-927 0 obj <<
-/D [922 0 R /XYZ 85.0394 769.5949 null]
+935 0 obj <<
+/D [930 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-924 0 obj <<
-/Font << /F21 930 0 R >>
-/XObject << /Im1 923 0 R >>
+932 0 obj <<
+/Font << /F21 938 0 R >>
+/XObject << /Im1 931 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-949 0 obj <<
-/Length 1063      
+957 0 obj <<
+/Length 1065      
 /Filter /FlateDecode
 >>
 stream
-xÚµV]“ª8}Ÿ_ÁãX5D’0ûÆ *[.à�ÚÚ»ŒâHÕŒXÂ\kþývH
-c2Š˜I)Lî¬ê&#ˆB5�šhÞ.Q7hf#Š)×t›qdQø ŸÓ‡ñŒ�#nKKwšEáŒh*Ýþõè–ǯSñ¶¯G§¿kÌ@¶Á�¢†!
±0žaó“N�mq[Ó/p?!S	ÅA®"O
"†a>�tÂa²Þ´zÓîÍIoòÎÄFobiù‡:?òZÎ’¯ªÎ?*9qËCUžêâóã©ÅnÐH§Ø
-
Dá1F„Boè`pÛU¤·ÏeÀWàí”AQ¶Šø±Y,Û|ÛÒÍêÖRî³×òWÞK!;­™ʺØä�×	¯¤À�Ç<SYj={—‰ð	â†Å†™@ì"¯šF�æ58¢&…’cqJì’.<ÕjÑ,}qòèÄê‹ŸÈqG?ü©7•3±{�¤Eˆ™´�pÚ~t¥1+pü¥;A 
%vÂÔ÷Ôâ‹Ÿ.¤{s'žÊm	§1%ÔR¡~$¡é¢¥x‡|èë©ί‚ûËUà·¹ÜcÍä¸ôbw
#Û|tžýÀOÿìì,Ä͉ݲÃ
»™Ÿ†^’ –ƒCÅ×ûá�?IxÑ3jõzVÔßy”=‹â6ª
-Ÿ¬<×w‚§VãØsŽí‰Þ|M`YC1Ý(L¼?ÖÀ
-<*‡ÎÒ™wZ\¬¾,%M"H,n«—¬ƒæk'ý,Ž–*±(éE”ãU�׉×æ&Ý7ò�Ž¥“§–‡]5wÚÑMý(–ÒNcg QèÍî…®7Œ5žWx�	–[6c<¢6ä­“Ë�ʱûI'E´N‡L¢+ÖÀ,ô.÷Û¢Û§ Ï ¬bãsŠ‡"®¼:géôù̾Û27W	ÁÂܶà€dà{•t`ý}{•‚¶'¼ó)ˆÞ{L\_tMšÞh&µ†úsf(ð>;�#奖çw^«¾·��í+…â|{.KuþºE=¸œÜì½€‹æPd�“ÁÃ�Þô©#ÝSáž‰íëúøÛx|>Ÿ…¨¨6¨lH½�onmõ€¥‰'ê~¾þN!–Éendstream
+xÚÅV]�ªH}Ÿ_Á㘌m@Cl\À;ÙìÝFq$™#Ì5óïoA7 j&û¶ñ¡«écÕ©SÕDÃð#šÁTh¦Ð‘�‰¡m>°ökó¢0ºÁ�¡3“;«c]7‘‰¹ÐÆLGx»DÝ 9EL›†@œQV£Ÿ“‡ÉŒRM Á)×’�ÆMd̵•lÿytŠã×)ÛW£“?5CXˆ†ÃX6õÂdFôOcŠL.Lm|�û	™Jè (¡r­ó¬Acýi4¦®M£7yoš½iõ¦èL‚{“ô&•–w¨²Ó!«ä,þ*«ì£”§8”Å©Ê??žZì5i&�Î8$D†AUFþI©îÅN=À”Ôè7é¤'¤ç4¥™º®[§=¾„ߊ0¨”nŠÞëÿR©^gÜëŒio²»’»êœžFÄzÌ®uG×úÁ. [š	º[„ðoåkÁãKô­z†…(¦¤÷Y§³ÊNyYæÅArª
+9~–™ÊgòŽ!�jþQlóÝàKzØNŠ“´·yY�ò×ÏJåXísÕeåMþ»öOéáKÇÏÓ±(Õò9¯öÒjqõ—âSé¹Ë4½JeЃVÝg2à«
+ðvJ¡([EüØ,¿òm¶mé¦Uk)÷ékñ+ë¥��ÖLE•o²Nƒë„�WÒàÇc–ª¬rµž¾¿ËD„…æF›	‘M\ó¬”ÛrL±@LgPrb"Á¨Õ@’…«Z-œ%/#AíH}ñb9®¢ð‡7u§rVï^;nõLÚv0m?:Ò˜‚åÛÞR�mß—†ŠÙAâ¹jñÅKҊܹM嶄ӚÑaq’ZýPB“EKñùÀñ×S/˜_÷–+ßks¹Ç$œÉqéFÎF¦þh?{¾—üÝ'Z³ãHè–9|æ%�Ǩå Ç@ñu¸àO^ôŒZ½žuß³Ÿ}eϨ�ªÂÇ+×ñlÿ©Õ8r�†c{7ŸÀEÓ
+ܹïÍÝÀq‡‘ÂÆsÍÞÔ"ÃrËfŒFÌ„|Ãu|R9¶#/î¤×É�IxŘîã~[tûô”µÞø‚‘¡ˆ+7‚ÎYÚ}>³ï¶ÌÍUB	GD˜H¼’o¯’<¾@ß^%”DLKt>k¢÷^×]“&¥°Ýê/¬ÀûôŽ”—JžßY¥úž#“˜W
+EÙö\êüuòjp99é{Í!Oº
oPvÓ§¶tÏj÷tHl_UÇ?&“óù\+ŒòrƒŠ†ÔÛäæÖV\f ú	ûŸŸ·¿
—�~endstream
 endobj
-948 0 obj <<
+956 0 obj <<
 /Type /Page
-/Contents 949 0 R
-/Resources 947 0 R
+/Contents 957 0 R
+/Resources 955 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 931 0 R
+/Parent 939 0 R
 >> endobj
-950 0 obj <<
-/D [948 0 R /XYZ 56.6929 794.5015 null]
+958 0 obj <<
+/D [956 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-947 0 obj <<
-/Font << /F22 953 0 R /F14 956 0 R >>
+955 0 obj <<
+/Font << /F22 961 0 R /F14 964 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-959 0 obj <<
+967 0 obj <<
 /Length 2886      
 /Filter /FlateDecode
 >>
@@ -2501,1765 +2513,1772 @@ x6$a»N9pšÛCcÓ®³ŒhÉ\HŸE�.õ]y<çö°þ4ü|U/6+›Íã¹2ù±?l¾žå™Éÿß$5>Ó;²}Ž`¸+äîù?CO$
 ¿Z×U½n—÷Ð̈ƒ2f�ûHBÎ’�
 ‹µÁPá_ù™óœ˜ØûÆ»
Õõ Î…�~‰‰&Áº"15s_êb["_ø3yoÿ>ªendstream
 endobj
-958 0 obj <<
+966 0 obj <<
 /Type /Page
-/Contents 959 0 R
-/Resources 957 0 R
+/Contents 967 0 R
+/Resources 965 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 931 0 R
-/Annots [ 962 0 R 963 0 R 964 0 R 965 0 R 966 0 R 967 0 R 968 0 R 969 0 R 970 0 R 971 0 R 972 0 R 973 0 R 974 0 R 975 0 R 976 0 R 977 0 R 978 0 R 979 0 R 980 0 R 981 0 R 982 0 R 983 0 R 984 0 R 985 0 R 986 0 R 987 0 R 988 0 R 989 0 R 990 0 R 991 0 R 992 0 R 993 0 R 994 0 R 995 0 R 996 0 R 997 0 R 998 0 R 999 0 R 1000 0 R 1001 0 R 1002 0 R 1003 0 R 1004 0 R 1005 0 R 1006 0 R 1007 0 R 1008 0 R 1009 0 R 1010 0 R 1011 0 R ]
+/Parent 939 0 R
+/Annots [ 970 0 R 971 0 R 972 0 R 973 0 R 974 0 R 975 0 R 976 0 R 977 0 R 978 0 R 979 0 R 980 0 R 981 0 R 982 0 R 983 0 R 984 0 R 985 0 R 986 0 R 987 0 R 988 0 R 989 0 R 990 0 R 991 0 R 992 0 R 993 0 R 994 0 R 995 0 R 996 0 R 997 0 R 998 0 R 999 0 R 1000 0 R 1001 0 R 1002 0 R 1003 0 R 1004 0 R 1005 0 R 1006 0 R 1007 0 R 1008 0 R 1009 0 R 1010 0 R 1011 0 R 1012 0 R 1013 0 R 1014 0 R 1015 0 R 1016 0 R 1017 0 R 1018 0 R 1019 0 R ]
 >> endobj
-962 0 obj <<
+970 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 688.709 539.579 697.4212]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.1) >>
 >> endobj
-963 0 obj <<
+971 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 676.5858 539.579 685.5919]
 /Subtype /Link
 /A << /S /GoTo /D (section.1.1) >>
 >> endobj
-964 0 obj <<
+972 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 664.4876 539.579 673.4937]
 /Subtype /Link
 /A << /S /GoTo /D (section.1.2) >>
 >> endobj
-965 0 obj <<
+973 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 652.3894 539.579 661.3954]
 /Subtype /Link
 /A << /S /GoTo /D (section.1.3) >>
 >> endobj
-966 0 obj <<
+974 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 640.2911 539.579 649.1477]
 /Subtype /Link
 /A << /S /GoTo /D (section.1.4) >>
 >> endobj
-967 0 obj <<
+975 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 628.1929 539.579 637.0495]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.1) >>
 >> endobj
-968 0 obj <<
+976 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 616.0946 539.579 624.9512]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.2) >>
 >> endobj
-969 0 obj <<
+977 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 603.9964 539.579 612.853]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.3) >>
 >> endobj
-970 0 obj <<
+978 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 591.7985 539.579 600.7547]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.4) >>
 >> endobj
-971 0 obj <<
+979 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 579.7002 539.579 588.6565]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.1.4.4.1) >>
 >> endobj
-972 0 obj <<
+980 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 567.6019 539.579 576.5582]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.1.4.4.2) >>
 >> endobj
-973 0 obj <<
+981 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 555.5037 539.579 564.46]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.1.4.4.3) >>
 >> endobj
-974 0 obj <<
+982 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 543.5051 539.579 552.5112]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.5) >>
 >> endobj
-975 0 obj <<
+983 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 531.4069 539.579 540.413]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.1.4.5.1) >>
 >> endobj
-976 0 obj <<
+984 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 519.3086 539.579 528.3147]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.6) >>
 >> endobj
-977 0 obj <<
+985 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 496.5559 539.579 505.288]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.2) >>
 >> endobj
-978 0 obj <<
+986 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 484.4775 539.579 493.4338]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.1) >>
 >> endobj
-979 0 obj <<
+987 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 472.3792 539.579 481.3355]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.2) >>
 >> endobj
-980 0 obj <<
+988 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 460.281 539.579 469.2373]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.3) >>
 >> endobj
-981 0 obj <<
+989 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 448.1827 539.579 457.139]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.4) >>
 >> endobj
-982 0 obj <<
+990 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 436.0845 539.579 445.0408]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.5) >>
 >> endobj
-983 0 obj <<
+991 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 413.5759 539.579 422.1635]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.3) >>
 >> endobj
-984 0 obj <<
+992 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 401.4527 539.579 410.3093]
 /Subtype /Link
 /A << /S /GoTo /D (section.3.1) >>
 >> endobj
-985 0 obj <<
+993 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 389.3544 539.579 398.2111]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.3.1.1) >>
 >> endobj
-986 0 obj <<
+994 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 377.2562 539.579 386.1128]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.3.1.2) >>
 >> endobj
-987 0 obj <<
+995 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 365.0583 539.579 374.0146]
 /Subtype /Link
 /A << /S /GoTo /D (section.3.2) >>
 >> endobj
-988 0 obj <<
+996 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 352.96 539.579 361.9163]
 /Subtype /Link
 /A << /S /GoTo /D (section.3.3) >>
 >> endobj
-989 0 obj <<
+997 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 340.8618 539.579 349.818]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.3.3.1) >>
 >> endobj
-990 0 obj <<
+998 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 328.7635 539.579 337.7198]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.3.3.1.1) >>
 >> endobj
-991 0 obj <<
+999 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 316.6653 539.579 325.6216]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.3.3.1.2) >>
 >> endobj
-992 0 obj <<
+1000 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 304.567 539.579 313.6728]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.3.3.2) >>
 >> endobj
-993 0 obj <<
+1001 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 281.9139 539.579 290.7706]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.4) >>
 >> endobj
-994 0 obj <<
+1002 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 269.8356 539.579 278.9413]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.1) >>
 >> endobj
-995 0 obj <<
+1003 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 257.7373 539.579 266.8431]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.2) >>
 >> endobj
-996 0 obj <<
+1004 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 245.6391 539.579 254.7448]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.2.1) >>
 >> endobj
-997 0 obj <<
+1005 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 233.5408 539.579 242.6465]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.3) >>
 >> endobj
-998 0 obj <<
+1006 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 221.4426 539.579 230.5483]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.4) >>
 >> endobj
-999 0 obj <<
+1007 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 209.444 539.579 218.4501]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.4.1) >>
 >> endobj
-1000 0 obj <<
+1008 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 197.2461 539.579 206.3518]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.5) >>
 >> endobj
-1001 0 obj <<
+1009 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 185.1478 539.579 194.1041]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.1) >>
 >> endobj
-1002 0 obj <<
+1010 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 173.0496 539.579 182.0058]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.4.5.1.1) >>
 >> endobj
-1003 0 obj <<
+1011 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 160.9513 539.579 169.9076]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.4.5.1.2) >>
 >> endobj
-1004 0 obj <<
+1012 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 148.8531 539.579 157.8094]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.2) >>
 >> endobj
-1005 0 obj <<
+1013 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 136.7548 539.579 145.7111]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.3) >>
 >> endobj
-1006 0 obj <<
+1014 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 124.7562 539.579 133.7623]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.4) >>
 >> endobj
-1007 0 obj <<
+1015 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 112.658 539.579 121.6641]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.5) >>
 >> endobj
-1008 0 obj <<
+1016 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 100.5597 539.579 109.5658]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.6) >>
 >> endobj
-1009 0 obj <<
+1017 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 88.4615 539.579 97.4676]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.6) >>
 >> endobj
-1010 0 obj <<
+1018 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 76.3632 539.579 85.2199]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.7) >>
 >> endobj
-1011 0 obj <<
+1019 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 64.265 539.579 73.1216]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.8) >>
 >> endobj
-960 0 obj <<
-/D [958 0 R /XYZ 85.0394 794.5015 null]
+968 0 obj <<
+/D [966 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-961 0 obj <<
-/D [958 0 R /XYZ 85.0394 711.9273 null]
+969 0 obj <<
+/D [966 0 R /XYZ 85.0394 711.9273 null]
 >> endobj
-957 0 obj <<
-/Font << /F21 930 0 R /F22 953 0 R >>
+965 0 obj <<
+/Font << /F21 938 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1014 0 obj <<
-/Length 3290      
+1022 0 obj <<
+/Length 3275      
 /Filter /FlateDecode
 >>
 stream
-xÚí�mS#7Çßó)\uo ê¬=K/	Ëæ’ì²ÜÚ{UwI^8f\ñ1ö&äÓŸÆ3­icMƒrû8©Z{ÚÝôÿçVK£±y¯ÿóž6Ìxá{Ö+¦®{ãÙAÑ»Ï}{À›súpRŸõÍðà/¥íyæ�0½áûžÒš	½y1Ç
-çxoxñãáÉ›³áéÙppôóðûƒÓa|U왲zÉß~ü¹è]„
-½@$B5Dœ/'Bè¯n¯ýëâ?^l~^„&Ò:»o"ï éÌFR¨`¹„íF%…
-éP1’IëÚADà r6øáô?’Åtº¨ç¶û)išÈf6)È�"«E‘’ˆƒ"…ô¤hΤjgÌìÛ�N WÙ CŠ¬ÅA"ŠÒ;p C‡Áu;¸Ø†ƒ;É_ËÛdõÐÊ퇔˜Äl@�!‰$é
-
-ƒD¤wÀ �L4áEÕ8>¹ËÁÓÆ
-�D ¤w¸ü©µf…�óŒªÁÐw¯x�|UPÜáúfÕ\îœ�¯Ëúøõh>º,gå|UÉaŸ$/�h@ö²Ñ@†Xá»ÑHÄA¡Az‡Ú¡$+Lœƒã¦ëøw5ùM'hÖÛòf1
½ÈQ_
-½_×LÃ	͆R°`Á(XqP°�Þ
ÉY!ÕÂÒt%ÇëU¨“U`åC‰·Ú„–D«}/rHc6"È�BËD!’ˆƒB„ô‡î˜÷Î#¼jÎ8iV»ÿV=TüTèâdy{½Zü:	ÇÍ£7ëëëÅ2Œ2V=?p:‰�¤fƒ)b°h²è&&EéŠJaÂCqªÃ9Œ@çõì¦þ÷·õäf²*«uO÷ˆ7{~¹a	²œM2¤Â*R%â "½sa˜’\õT`ÉË8ªª(r¡ž|³žL/bó溜¯š…hnãvâãÓó¸ýºlž]Ì럯&óõáE¥ú2mhü#s%Ć„„[I”¼SÂT„„´÷VB'˜/¤ÅŠ¿ áàä¸>0EQl8XLGËI(!^Š/ZÎãßš­$2¤”Ť”LÄA)Izoʹ²sñÒ7çÐ"n‹øÍwg/ê#_ÿø}²ºª�ªN¡îŒzý ¤,›†ÖŽ‚
	"»oæHA¡@¹nßÓÚ1§
-‰`€²œØœ¿ÃD|s7•W®}wŸVmHJ¶ÜÈ�Ò'�<¥8齕\æ
-ÔþÉÅ_�¼­ÕÂ<jµ!Ùj#CJmœoJíD”Ú¤w(õR1k‘ÔͲsb®7¬V“‹iÔnß±?„œ&»Ùà´v7H;Ù}3N"ŠÊ5@#³J£1AÕÔ¼»Ù½½ïŸƒ×
ë÷À<Èl61È�B+G1“ˆƒ‚†ôÔ„Ó-—¦¥F×Ô®Ëñäýí.:åür;÷aŸ/f³xElº9O~.Ê>ö¬2“­:2¤TÇ™—ª[õD”ê¤÷Fué3ŽûVuS«þv=oož�fåÅÝYDç]w/™?_»Ä1
¹cCBâ­4§â $¦½Ãz±t†ÝÎD½^üÝùÓt‚° \ïjI4Ž^ðý
-Ç„VµTzs¿{õ1_Ýéižþe9ZÞ†áô‘\xýØï$H_ö;	Rï$,ÅD"Š
Ò{dƒ&„
¢ac«�¥¨x1*gÕôÉ[½¿JB2³IA†)X,Š”D);ÞS5Wxɼõf4ÓÔÜ�RÛ®å†9L¯ß–ïËe9—�™‹/þÐz‹
ˆz»´ìÞñ‚_ŽÈÔ®×Ô{J8ÎœçµL&ÖÛdj^N ·8�nvQVw÷qû\ç+�|@JsßYØ�xgmIFq’ˆƒâ…ôÞ4­Âxæ´×€Kü@š�¦õõh5¾‚Aù¦BÅX±ŸÓÞAÒ™�
-2¤PÁr©î
-©8(THïñ2šÐ–9a]ËY­‡ÜÎW£?ŽúÒëýzøC@�Tfƒ‚)P°T(‰8(PHï-(J3ë
G ˆ”e5Í'í(—¼ßÝŒ.˯d‹åç¸4³”Í
-,…J"
-Ò{[.gVŠv\ûq寂©ÌR `©(PqP �Þ[P
-ÏlÁ9e?®ì2
-Î7'÷)pº¿âèâ	N§šÔfSÓÚQÐ á(fvƒ �¡\7Ä8ϤS2ãï%fº¸¼¬¶“%Æ)ˤñú¾E�¯ý³‚>òøÎÙà`ýpAà�®á«—‚ØZ´¥†ŸŠœt8_f“ÕÇšiC*³¿“©µ£¾’		¥º÷v'‚ ¾�‰r¯/ͤàø`€j»ò.-¦óh}îøj4Ÿ—©Å>é˜ÒÚ4ç�_-G7
#ųêcšä棘‘ߧ…#�Ù�`‡˜øE³}áYòc|«9g^kñÿ¯mûõ»*
-¦�Ö=ztYÏɤ{n}
-ýYt
-endstream
+xÚí�msÛ6ÇßûShæÞØ3'ñ¼t§×6q|‘r3wm_¨6ãhªW–’ºŸþ@‘®$pmä’4¶ÕÎD´ÄÕ®öÿ#vA‚ïáÞÓ†/|ÏzÅtÁuïbzPô®ÂkßðfŸ>ìÔÇ{=üã…´=ϼ¦7|×SZ3¡×oæXáï
/:<y}6<=Ž~þpp:ŒïŠ=óBVoùûÁO¿½ËÀ“ÞéÞÇðGÁ¸÷¢7=PZ2­¤„g&ƒƒÅ7D¯®M“Ÿ„LH#EôQª5ïY홑B®?ˆbŽñ£>Eqø]9+£åxvuÔº8ü±¼½9ê;#ÙQ_‡Þƒòþ³½Ù¶ÔEȺ•¦ÍçŽ6‹«^½ñ«v}l¸«ÖîûWz	±¨ŸŠƒb…ô¬(ËLQ˜ÈŠhXŒ¯f”åû²Þøï|¶laöÄ�Ä@V³‰A†1X5!»‰IÄACzb¤fÚ8‰‘
1'óÙÏE!®V‹ÈÍ \|(ÕÃåSE¥“Èc6#È�bëD1’ˆƒb„ônyrL(�"T5iE‰ˆ�‡çgƒÁéÉßk8žßÎFÓñE;°Ü4/Œf—õÆñj9Ÿ†zÕì‡$eÕ7
@§ä�•lÉ‘!%9κÐÝ’'â $'½Ã°ÀyèL4›Ž0,„1 m:Þ-Ž¸;œOë¿Æ³›òbµ~ª)1ËyýˆŸ÷V>ØÑ HX6È�‚
BÁ�ˆƒ‚�ôÞÀ`¼gÊJa€®b㘣A½±º¾-ù§åòý<ÿÖ˧Qb®r9À†Z¤â 8 ½Î2¥D,±Wx±šLn›Ñ~s�ÿsÝa®
+�D ¤w
+É„@S^T�ã}0�»<n UÙ C
+,…A"
+Ò{ƒ�öœqçÚZÀù}0è:]¹y"ó1ž°Œ	Ë…
0lBÀ�Šƒ€�ö0Ø ¿¶miࢆá¼\Œç—Ð8ÖòöÛ3SÜ=ñ¡�°@B³aA†,X0
+–D,¤w€ÅØÀ‡V-,²†•ˆx
ëõù°‚æõÛaŒßŸ�
+,H"
+Ò;\þÔZ³ÂÇyFÕ`èí+žÃ#_
(îpu³l.wÎ.ÞÏõö«ÑltUNËÙ²’Ã>J^:Ñ€ìe£�)4°:Âw£‘ˆƒBƒôc‡’¬0qŒ›®ãßÕäs4_¢õYoÊ›ù$ô"G})ôþ¼fHh6,È�‚FÁ’ˆƒ‚…ô°HÎ
+Y¨–¦+9^-ÃH1^V>”x©MhI´Ú÷"[ˆ@³A†"X&
+‘D"¤÷Xj¸cÞ;ŒðºÔœÿxÒœíþ[õTµñs¡‹“ÅíõrþÛ8l7ÏÞ¬®¯ç‹Pe¬zzàtIÍ&RÄ`ÑdÑML"ŠÒ;*…	OÅ©çP�ÎëÙMýïï«ñÍxYVç=Ý^ìùו%Èr6AÈ�"«H”ˆƒ"ˆôÎ…aJrÕS�%/ã¨b¨¢È…ñäÙj<¹ŒÌëër6¼lN¤@s—ŸžÇ•è×eóê|V?¾ÏV„7•ê¯iCã‡Ì•n$QòN	SqÒÞ[	�`¾�K(>AÂÁÉq½aŠ¢Øp0ŸŒã0„x)þÒá<~Öl%‘!¥$Î%¥d"JIÒ{«¤-˜‹¿×BÊû9˜¿[þsðªZeår“YÈ–¸µ£F9–Ýwh$‚ ô¥\7ÕZiÇœ*d«n3ØÔöÙ÷gÏë-_?|/ß×[U'X÷€F=�~?æ,›dHÁ€5‘Ý+ëSqP8�ÞÛÃ]æ
+Ôð3
µ7qÆñÀoÊë&,Ý•Ù(óÕ
+/|Âlý�!¥Î ¥_"J?Ò{«ŸTÌÚ
ùÄ'È‹k‡€[uù³»Ï­bó9³Elí(
Q)	wƒ ¤\·
+Á¬ÒxH†‚›© T^®æ8‰È–RãDS"'â T&½CÝ
»[.M+rs�'qbeX�º�Ï'á`4…ÛO�7dH¡ƒå£ÐIÄA¡CzoБÞ1ã¸oÑQ5:oovo¨­
+Í÷çLÓÂ%˜zY¢oô‚ï	ä8 dH
„5”Ý·Ì¥â 
+ÐýtÎ؇¼L$æ%[sdHiŽóNižˆƒÒœôšKÇ´h§"^ùßÖ<®E5‚¦àlü믓fŸóE¨Õ¶ÿæe†TdËŒ)™qª)™qP2ïxçØ{ó5R’&„¬«îo,B.†ÐÄíœ;x9¾z¿üXVÿn­êÌ8aÜ/kÈ ÷Îû®³Ö}~;*[;^“•´‡‚çõrq½þ†‰ê[Eb¾ºÓÓ¼üëb´¸
åô�,uøÜG¤/ûHB†Ô‘„塘HÄA±Az6„uQ{×°!66úèQŠŠç£rZMŸ¼Õûõ/�’1™¹¤`C‚”
±RRq¤ìzO�¹Âxæ´¯15͘»3Ô¶§ræ×oÊw墜]”Ý™ƒ7¿ïx‹
ˆñv#hÙ½Æ¿•©¯ÉcJ[æ„­e2q¼M¦æÅz‹ÓÉzÝru?-·Ou¾Òɤ4ûÈB†Ô‘…%£8IÄAñBzošV¡4³ÞpÀ%~ÔNÓúj´¼xEù¦BÅX±ŸÓn¡éÌFR¨`¹T÷²T*¤÷xMHɬQº…e�‹¬Î‡ÜΖ£?ŽúÒëýùðû€©ÌR `©(PqP �Þ[PgV
+‡@
(Ï˪ÍÆmŠ§¼ßÞŒ®ÊodQó׸4³”Í
+ÏlÁÛº"â}ûÓú)�F
íì~Ô Q�tf£‚)T°\*‰8(THïq¸àÞ2c¼jaÙוO%¦2lH€²!
J*Ú{ŠÓa–Ó,!ªAÙו] KÙ CŠ
¬‚ê^Y›Šƒb€ôó[n%3Eœ°ˆûÍo¿[Œ¦ÓQuöÈÊýôvÈh6.È�Â+Fá’ˆƒÂ…ôÞ´!Üp¦Ã�´°õˆµuÂFræ\¡‚ƒj¯ÑŤÙgcÒLðÐóÔû–£eÙ¶1‘.+ö_FÖæ<›'dHñ„5UÝëÄRqP<‘Þ�'å™VÂFžÄ—àéîZæ<|ãä6›dHqƒµ£¸IÄAqCzn¤e:ΆªµÇwas1Ÿ-ÕúÔ]v¤g—⎱H»ÇùÅ%�ø4)Φ§µ£àARììA¡C¹r„fÊú¶‚©/†Î=Zh-)�ˆ@.³A†$X+Õ½5…	é8á’)eÛʤïäd<»˜¬.Ë&†YÏïêvO«Q†gãƒ)|°„>‰8(|Hï€OÁ™â&Òc¾=w2_û¢þg^±
™Ì†¤µ£A:©îE±‰ (B(×
 Î3锌€Ø;
©¾±9Ñø†
+ä�¼ch‘ÒíOúBÊsIBvIXP‚¤DI¤køÕ!ˤíPã¾Iw3ºx|S(HmöϵvÔ¯!ábAP¿MD¹Ž¿À¤h'OþN`&ó««jY¢6wÆë»Îã|ë_Èõ™kV“àüŸ
 endobj
-1013 0 obj <<
+1021 0 obj <<
 /Type /Page
-/Contents 1014 0 R
-/Resources 1012 0 R
+/Contents 1022 0 R
+/Resources 1020 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 931 0 R
-/Annots [ 1019 0 R 1020 0 R 1021 0 R 1022 0 R 1023 0 R 1024 0 R 1025 0 R 1026 0 R 1027 0 R 1028 0 R 1029 0 R 1030 0 R 1031 0 R 1032 0 R 1033 0 R 1034 0 R 1035 0 R 1036 0 R 1037 0 R 1038 0 R 1039 0 R 1040 0 R 1041 0 R 1042 0 R 1043 0 R 1044 0 R 1045 0 R 1046 0 R 1047 0 R 1048 0 R 1049 0 R 1050 0 R 1051 0 R 1052 0 R 1053 0 R 1054 0 R 1055 0 R 1056 0 R 1057 0 R 1058 0 R 1059 0 R 1060 0 R 1061 0 R 1062 0 R 1063 0 R 1064 0 R 1065 0 R 1066 0 R 1067 0 R 1068 0 R 1069 0 R 1070 0 R 1071 0 R 1072 0 R 1073 0 R 1074 0 R 1075 0 R ]
+/Parent 939 0 R
+/Annots [ 1027 0 R 1028 0 R 1029 0 R 1030 0 R 1031 0 R 1032 0 R 1033 0 R 1034 0 R 1035 0 R 1036 0 R 1037 0 R 1038 0 R 1039 0 R 1040 0 R 1041 0 R 1042 0 R 1043 0 R 1044 0 R 1045 0 R 1046 0 R 1047 0 R 1048 0 R 1049 0 R 1050 0 R 1051 0 R 1052 0 R 1053 0 R 1054 0 R 1055 0 R 1056 0 R 1057 0 R 1058 0 R 1059 0 R 1060 0 R 1061 0 R 1062 0 R 1063 0 R 1064 0 R 1065 0 R 1066 0 R 1067 0 R 1068 0 R 1069 0 R 1070 0 R 1071 0 R 1072 0 R 1073 0 R 1074 0 R 1075 0 R 1076 0 R 1077 0 R 1078 0 R 1079 0 R 1080 0 R 1081 0 R 1082 0 R 1083 0 R ]
 >> endobj
-1019 0 obj <<
+1027 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 758.5763 511.2325 767.4329]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.8.1) >>
 >> endobj
-1020 0 obj <<
+1028 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 746.445 511.2325 755.4012]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.8.2) >>
 >> endobj
-1021 0 obj <<
+1029 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 734.4133 511.2325 743.3696]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.8.3) >>
 >> endobj
-1022 0 obj <<
+1030 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 722.3816 511.2325 731.3379]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.9) >>
 >> endobj
-1023 0 obj <<
+1031 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 710.3499 511.2325 719.3062]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.1) >>
 >> endobj
-1024 0 obj <<
+1032 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 698.3182 511.2325 707.2745]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.2) >>
 >> endobj
-1025 0 obj <<
+1033 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 686.2866 511.2325 695.2428]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.3) >>
 >> endobj
-1026 0 obj <<
+1034 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 674.3546 511.2325 683.2112]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.4) >>
 >> endobj
-1027 0 obj <<
+1035 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 662.3229 511.2325 671.1795]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.5) >>
 >> endobj
-1028 0 obj <<
+1036 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 650.2912 511.2325 659.1478]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.6) >>
 >> endobj
-1029 0 obj <<
+1037 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 638.2595 511.2325 647.1161]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.7) >>
 >> endobj
-1030 0 obj <<
+1038 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 626.1282 511.2325 635.0845]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.8) >>
 >> endobj
-1031 0 obj <<
+1039 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 614.0965 511.2325 623.0528]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.9) >>
 >> endobj
-1032 0 obj <<
+1040 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 602.0648 511.2325 611.0211]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.10) >>
 >> endobj
-1033 0 obj <<
+1041 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 590.0331 511.2325 598.9894]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.11) >>
 >> endobj
-1034 0 obj <<
+1042 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 578.0015 511.2325 586.9578]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.12) >>
 >> endobj
-1035 0 obj <<
+1043 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 565.9698 511.2325 574.9261]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.13) >>
 >> endobj
-1036 0 obj <<
+1044 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 553.9381 511.2325 562.8944]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.10) >>
 >> endobj
-1037 0 obj <<
+1045 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 541.9064 511.2325 550.8627]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.10.1) >>
 >> endobj
-1038 0 obj <<
+1046 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 529.8748 511.2325 538.831]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.10.2) >>
 >> endobj
-1039 0 obj <<
+1047 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 517.8431 511.2325 526.7994]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.11) >>
 >> endobj
-1040 0 obj <<
+1048 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 505.8114 511.2325 514.7677]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.11.1) >>
 >> endobj
-1041 0 obj <<
+1049 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 493.7797 511.2325 502.8855]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.4.11.1.1) >>
 >> endobj
-1042 0 obj <<
+1050 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 481.7481 511.2325 490.8538]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.4.11.1.2) >>
 >> endobj
-1043 0 obj <<
+1051 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 469.7164 511.2325 478.6727]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.4.11.2) >>
+/A << /S /GoTo /D (subsubsection.4.11.1.3) >>
 >> endobj
-1044 0 obj <<
+1052 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 457.6847 511.2325 466.641]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.4.11.2.1) >>
+/A << /S /GoTo /D (subsection.4.11.2) >>
 >> endobj
-1045 0 obj <<
+1053 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 445.653 511.2325 454.6093]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.4.11.2.2) >>
+/A << /S /GoTo /D (subsubsection.4.11.2.1) >>
 >> endobj
-1046 0 obj <<
+1054 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 433.6213 511.2325 442.5776]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.4.11.3) >>
+/A << /S /GoTo /D (subsubsection.4.11.2.2) >>
 >> endobj
-1047 0 obj <<
+1055 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 421.5897 511.2325 430.5459]
 /Subtype /Link
+/A << /S /GoTo /D (subsubsection.4.11.2.3) >>
+>> endobj
+1056 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 409.558 511.2325 418.5143]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.4.11.3) >>
+>> endobj
+1057 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [499.2773 397.5263 511.2325 406.6321]
+/Subtype /Link
 /A << /S /GoTo /D (subsection.4.11.4) >>
 >> endobj
-1048 0 obj <<
+1058 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 409.558 511.2325 418.6637]
+/Rect [499.2773 385.4946 511.2325 394.4509]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.11.5) >>
 >> endobj
-1049 0 obj <<
+1059 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 397.5263 511.2325 406.6321]
+/Rect [499.2773 373.4629 511.2325 382.4192]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.11.6) >>
 >> endobj
-1050 0 obj <<
+1060 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 385.4946 511.2325 394.4509]
+/Rect [499.2773 361.4313 511.2325 370.3876]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.12) >>
 >> endobj
-1051 0 obj <<
+1061 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 373.4629 511.2325 382.4192]
+/Rect [499.2773 349.3996 511.2325 358.3559]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.12.1) >>
 >> endobj
-1052 0 obj <<
+1062 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 361.4313 511.2325 370.3876]
+/Rect [499.2773 337.3679 511.2325 346.3242]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.12.2) >>
 >> endobj
-1053 0 obj <<
+1063 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 339.111 511.2325 347.8432]
+/Rect [499.2773 315.0477 511.2325 323.7798]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.5) >>
 >> endobj
-1054 0 obj <<
+1064 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 327.0992 511.2325 336.0555]
+/Rect [499.2773 303.0359 511.2325 311.9922]
 /Subtype /Link
 /A << /S /GoTo /D (section.5.1) >>
 >> endobj
-1055 0 obj <<
+1065 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 315.0676 511.2325 324.0238]
+/Rect [499.2773 291.0042 511.2325 299.9605]
 /Subtype /Link
 /A << /S /GoTo /D (section.5.2) >>
 >> endobj
-1056 0 obj <<
+1066 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 292.7473 511.2325 301.4795]
+/Rect [499.2773 268.684 511.2325 277.4161]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.6) >>
 >> endobj
-1057 0 obj <<
+1067 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 280.7355 511.2325 289.6918]
+/Rect [499.2773 256.6722 511.2325 265.6285]
 /Subtype /Link
 /A << /S /GoTo /D (section.6.1) >>
 >> endobj
-1058 0 obj <<
+1068 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 268.7038 511.2325 277.8096]
+/Rect [499.2773 244.6405 511.2325 253.7462]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.1.1) >>
 >> endobj
-1059 0 obj <<
+1069 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 256.6722 511.2325 265.7779]
+/Rect [499.2773 232.6088 511.2325 241.7146]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.1.1.1) >>
 >> endobj
-1060 0 obj <<
+1070 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 244.7402 511.2325 253.7462]
+/Rect [499.2773 220.6768 511.2325 229.6829]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.1.1.2) >>
 >> endobj
-1061 0 obj <<
+1071 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 232.7085 511.2325 241.7146]
+/Rect [499.2773 208.6451 511.2325 217.6512]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.1.2) >>
 >> endobj
-1062 0 obj <<
+1072 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 220.6768 511.2325 229.6829]
+/Rect [499.2773 196.6134 511.2325 205.6195]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.1.2.1) >>
 >> endobj
-1063 0 obj <<
+1073 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 208.6451 511.2325 217.6512]
+/Rect [499.2773 184.5818 511.2325 193.5878]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.1.2.2) >>
 >> endobj
-1064 0 obj <<
+1074 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 196.6134 511.2325 205.6195]
+/Rect [499.2773 172.5501 511.2325 181.5562]
 /Subtype /Link
 /A << /S /GoTo /D (section.6.2) >>
 >> endobj
-1065 0 obj <<
+1075 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 184.4821 511.2325 193.5878]
+/Rect [499.2773 160.4187 511.2325 169.5245]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.1) >>
 >> endobj
-1066 0 obj <<
+1076 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 172.4504 511.2325 181.5562]
+/Rect [499.2773 148.3871 511.2325 157.4928]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.2) >>
 >> endobj
-1067 0 obj <<
+1077 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 160.4187 511.2325 169.5245]
+/Rect [499.2773 136.3554 511.2325 145.4611]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.3) >>
 >> endobj
-1068 0 obj <<
+1078 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 148.4867 511.2325 157.4928]
+/Rect [499.2773 124.4234 511.2325 133.4295]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.4) >>
 >> endobj
-1069 0 obj <<
+1079 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 136.4551 511.2325 145.4611]
+/Rect [499.2773 112.3917 511.2325 121.3978]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.5) >>
 >> endobj
-1070 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 124.3237 511.2325 133.4295]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.6) >>
->> endobj
-1071 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 112.292 511.2325 121.3978]
-/Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.7) >>
->> endobj
-1072 0 obj <<
+1080 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 100.2604 511.2325 109.3661]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.8) >>
+/A << /S /GoTo /D (subsection.6.2.6) >>
 >> endobj
-1073 0 obj <<
+1081 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 88.2287 511.2325 97.3344]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.9) >>
+/A << /S /GoTo /D (subsection.6.2.7) >>
 >> endobj
-1074 0 obj <<
+1082 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 76.197 511.2325 85.3027]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.10) >>
+/A << /S /GoTo /D (subsection.6.2.8) >>
 >> endobj
-1075 0 obj <<
+1083 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 64.1653 511.2325 73.2711]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.10.1) >>
+/A << /S /GoTo /D (subsection.6.2.9) >>
 >> endobj
-1015 0 obj <<
-/D [1013 0 R /XYZ 56.6929 794.5015 null]
+1023 0 obj <<
+/D [1021 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1012 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R >>
+1020 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1078 0 obj <<
-/Length 3426      
+1086 0 obj <<
+/Length 3431      
 /Filter /FlateDecode
 >>
 stream
 xÚí�KSIÇï|
-æ
-ž[´2F>èV&䲘`ˆaµRªŸ“L(¨÷8ûÖZ«¤Ö̾ŸÏçÓjÔŠú¦¥Ã{p[9
º%!]Å0
-°\LjZ¬Tk56& XZ`ˆilD¿¸™80uQïI^¥	ã¦[…¢~g“›5Loɯx/
!GÅ
-
Ìä$>¸¸\µeë� ú>” ¾GŸrT@²Ãô
-`òßSs�Ä÷ãE¡i·aõŸ�ž®79�¦a•{œ~¥_ŒÆçëŽÂi½=%‡˜Žb¡�!¦4L·íßÌ�‹ÓõžÄ––ëº%׈]¯^Ç-n/ý¯};$B<â±`ÌX1Àã
*bû+̹80P‰d¶³Ã…·EÈãjy9Ÿ-«°ø0�ŒAÛß¼ú�*züöƒÿƒ…jå獩LK&ï}·¾~±¸À¦×ö×sq`â¢ÞãŽXÉ%‘Ò€â’Ù¸#¶ÄeŠÔ³¡7Üàf›§½…Ls1Ž ’¶¿��‹ãõž8bœH£A	ÊÞG›7V[·
…§˜Ñb^€!ÆTÌörq`¼ Þ/”E(<¹Í¼x&ËÕd¼ŽÏG³Y5ÍíÊ·ŠHe݆FHr³'›c‹
†#P%‹”2q`Œ Þ##Âz!SŠÓïÁÈæF¹ˆD1[¥,@C„…Ž¹8p‰ÒiÊ7r_-®–«êtøgõµïn7
V¬ÜÚ
IHi1/ÉÆÑr3ÌubEK¢¨Uq~§°ln0¸kðSX0Äè€axdâÀø@½'@÷aðTÎâ·9®>óRö¢ýTZ	±¡5ÑRn_3’YŒ
-0ÄP�bÙþýÙ¹80TPï	•ú¦%ÅR1ŒË;Eå³jî}ë’VŒ0Ä�€¢`HdâÀ�@½'$ê0jµ#›O šTŸs7¤Hÿ…üÜo5”�`!µ¦�îb˜€!”Óö¯«äâÀ`B½'˜ê�ýÔ¥ú×wÓævE;½=—4Å´C1h l4™80hPï	*‰àº¾¹h[/®ç¡¡Æmº
-	+æ
b<@AP2�`< î#ÌBi¼E¶æ�·<¬�ÔV_VWaC{õå2\¾K±a8^Oeô¶ö1O¥@CƒŽ¾§ïÅ ‚
î>ö¬~Žw6bÀÛ~`²_eôþå?™&BÒGù<„ aÈa1"ÀCjÄhÿ<$†ê>!b¡õ^±€ˆhyW­Òí*''¯× ȧAf9@!ÃÅ
-P& Ô}H³úyV‘Ùòs8«/m‡¿Œ./#Lá$ÝáÛOþÍÜŠ§ùHHb1"É#HÄhÿn¤L˜ï„‡t„±xÅ�¨/‡\óñfuNÊ^Ÿý®—S&Í d¼š|ª§+B²ÇÜ	…,1B J("™@0FP÷i¸*a2Þä!‰Ó—ÛÜïñ¯ÌZ�%xxC}Dk´.'g³æ˜–Rì©cŠY/†
-bPAUQ¨2�`P¡îTÜSd”Pñ¨~zs|øêð(÷pBC‹—Ætª½¡»Gdý];!ƒž!¡Å¼
-ð"Jx9<zñúýþAnwµ‰kÑÛ×]…T“1R TŒöï�Ì‚‘‚ºO¤PF¸�"KHñ³©ÜîM¬t=”¥×€8¤¸˜ `ˆ%D	Ê‚„º�£bë×<•çt;(~~x´fLõÿ®�Š¾¬ªY]¶ù§3º»ÊâÆŒö ª°Uò§WGÇÏêºßI®yÒ~žG…̃§¿Sñ§„�©R€‚
Ô
£ 
ê;=TÐîX*¼˜–�ëŽ$õ_®ïªoœ1úiÎòWJ°CÈ€ê0Ú¿6ö´@ÌwX#Ö~àÁÆÙ®×-ƒko ‰g@÷ê{𞃿¤6ߥ%3# %cÈs�n„p¢ø÷!wÄæjEõÿ#N5|ú¶ƧÇÚ×Ók{¦ð‚"5WáÇ@íz÷d2AN1­ßbÿæ””Íendstream
+ö
+~3Ýû¸÷c|Cð¿kÓÜQÂe¹É|ÎÁ'aœëŒ�N9¢ë�¢	÷¡¶Ä_ÎÀå‚k©ô>Ú˦ó³³É쬿¾­0Dh§ûë>®F«æ¢™­†\ÑýÃæJùl²šÌgÝoF³Óîŧåè¬9:föÉÁPQz?ÿHçþ»kB+n‰æ”¥\ÞPfq6è^C­‚ÝÞÔêæû·É•úFAû\)¨w¦$1Ƹ�‘†hÍ$ …°ÿÕ¡û'çMM	eÒô0ŒÏG³Y3ÍAc‰T*\÷á|1Zz|D÷ÊÂpROHo5<ÀƒʇÁ“‰ƒõžàŠhG„‡WÀã’³ùâ[†I‰¶×á‘Ô>xî¥å	é­†bð@ù¤-Ó‰ƒõžàá‚æ»
+	™80ŽPï‘#a½�� eí«­Û…ÂSÌh-/ÐáeC1[.0äâ@xÁ½'^Œ&Jƒ
¥ÛŽ‹ç`²\MÆËa[…ܦ|«ˆTÖmiƒ$7;p°9$±š�d‡
$²å²B&Ìu¢CK¢¨?qzxloZ”ûi(b²UÍ
0Ä@€j`$dâÀP@½'÷aðTbâÛÏ·¯WËUs:ü­ùVºù
·ÛÆ)VîìX$æ´š`ˆ5ÈÉÄ�ƒzOÄ´wGQ,¬8¿Sb¶7\‰G6ø)¬b€@‰lyÓm.Ô{¤
£Õ>r›óê3/em‰PBliR´”»×–„dV£1T X*™80TPï	•vÿ-u©Æå�¢r‹Ù
5¾õI«FbH@Q0$2q`H ÞT#À
wøöcè_&Í×ÜR¤ÿ@Fmi5”O`%µSHw5LÀƒ	ÊiË‹k¹80˜Pï&î81Ú¤º	×wÓövE;½;7iŠi­…"ÐlȆ@“‹�÷ž ±”N
ñíEÛv‰=
5nÛ]0”µOxy'¦»&`ˆÁåtåµÝ\L¨÷“�Xp¶�Û;ai{dÛ�^+dµ™d‡4så%£L/˜ë¸È•&V)Pš³áÆר}»lÖ‡�ÄSÝVd#¤°`ˆÑ
%ÂðÈÄ�ñ�zO€HéÛ
+É! ýÍ2^MGë¬�ädó`Lh5.ÀÃ
+æÊA¹80\Pï	Á‰cB@\Äõö$ÞeGðçf$ê2WÍ0ĸ€Ê`\dâÀ¸@½'.8%Nr¹èo§qøm6ºÇž>]žúqØ2i{©ÔÎÉ.ˆnç“11·•½·BÃœì×ß¿M<£Èp4¦;êÞù—ÖCÁ©%ΰ0õ-
£MÁëÉ´]‡SîÑw!rø 2TC1È ÌŒ–·´åÁ CÝÇ9s†PoX+Ú,ãtcàÚÂ6ÿ\:_{ÜŒçÝ¡˜åµÙ̿Λ~‚³š‡ùMŸ·'°�¨dÛ3R+84DßÈ8&x.DpÜ}ìMXû\îl|-¹Ø®­ìI
.‚^!aÕ<
+Ú›?.ÃÝwbí"6ÇëùŒÞÕ~ æ©`ˆa
+I&Ô}®2?6¡R%Hâôå6÷÷øgf±Î¿<\ÐÑ­†ËÉÙ¬;¦¥{îžbÖ«¡†TPUªL T¨ûõ“!4€ŠW@õ·÷Çoß¼}—{8¡!‚Å›Æl4TC÷€Èú³vB=CB«y
†/P0”—L /¨ûÈ‹u„kn
+|¥žÔp8d¸–`‡°õÃØÉD�={ó
ÎCgÝ�ƒ_¾}wfJíS¿®„�þX5³¶Tó?ft•�í	UawäßÞ½;:~Ñ–úNrM’„R!óÈé{*ø”èUK@2C
 endobj
-1077 0 obj <<
+1085 0 obj <<
 /Type /Page
-/Contents 1078 0 R
-/Resources 1076 0 R
+/Contents 1086 0 R
+/Resources 1084 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 931 0 R
-/Annots [ 1080 0 R 1081 0 R 1082 0 R 1083 0 R 1084 0 R 1085 0 R 1086 0 R 1087 0 R 1088 0 R 1089 0 R 1090 0 R 1091 0 R 1092 0 R 1093 0 R 1094 0 R 1095 0 R 1096 0 R 1097 0 R 1098 0 R 1099 0 R 1100 0 R 1101 0 R 1102 0 R 1103 0 R 1104 0 R 1105 0 R 1106 0 R 1107 0 R 1108 0 R 1109 0 R 1110 0 R 1111 0 R 1112 0 R 1113 0 R 1114 0 R 1115 0 R 1116 0 R 1117 0 R 1118 0 R 1119 0 R 1120 0 R 1121 0 R 1122 0 R 1123 0 R 1124 0 R 1125 0 R 1126 0 R 1127 0 R 1128 0 R 1129 0 R 1130 0 R 1131 0 R 1132 0 R 1133 0 R 1134 0 R 1135 0 R 1136 0 R 1137 0 R 1138 0 R ]
+/Parent 939 0 R
+/Annots [ 1088 0 R 1089 0 R 1090 0 R 1091 0 R 1092 0 R 1093 0 R 1094 0 R 1095 0 R 1096 0 R 1097 0 R 1098 0 R 1099 0 R 1100 0 R 1101 0 R 1102 0 R 1103 0 R 1104 0 R 1105 0 R 1106 0 R 1107 0 R 1108 0 R 1109 0 R 1110 0 R 1111 0 R 1112 0 R 1113 0 R 1114 0 R 1115 0 R 1116 0 R 1117 0 R 1118 0 R 1119 0 R 1120 0 R 1121 0 R 1122 0 R 1123 0 R 1124 0 R 1125 0 R 1126 0 R 1127 0 R 1128 0 R 1129 0 R 1130 0 R 1131 0 R 1132 0 R 1133 0 R 1134 0 R 1135 0 R 1136 0 R 1137 0 R 1138 0 R 1139 0 R 1140 0 R 1141 0 R 1142 0 R 1143 0 R 1144 0 R 1145 0 R 1146 0 R ]
 >> endobj
-1080 0 obj <<
+1088 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 758.4766 539.579 767.5824]
 /Subtype /Link
+/A << /S /GoTo /D (subsection.6.2.10) >>
+>> endobj
+1089 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 746.5057 539.579 755.6115]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.10.1) >>
+>> endobj
+1090 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 734.5349 539.579 743.6406]
+/Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.10.2) >>
 >> endobj
-1081 0 obj <<
+1091 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 746.5057 539.579 755.462]
+/Rect [527.6238 722.564 539.579 731.5203]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.10.3) >>
 >> endobj
-1082 0 obj <<
+1092 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 734.5349 539.579 743.6406]
+/Rect [527.6238 710.5931 539.579 719.6988]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.11) >>
 >> endobj
-1083 0 obj <<
+1093 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 722.564 539.579 731.6697]
+/Rect [527.6238 698.6222 539.579 707.5785]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.12) >>
 >> endobj
-1084 0 obj <<
+1094 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 710.5931 539.579 719.5494]
+/Rect [527.6238 686.6513 539.579 695.6076]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.13) >>
 >> endobj
-1085 0 obj <<
+1095 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 698.6222 539.579 707.5785]
+/Rect [527.6238 674.6804 539.579 683.6367]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.14) >>
 >> endobj
-1086 0 obj <<
+1096 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 686.6513 539.579 695.6076]
+/Rect [527.6238 662.7096 539.579 671.6658]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.15) >>
 >> endobj
-1087 0 obj <<
+1097 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 674.6804 539.579 683.6367]
+/Rect [527.6238 650.7387 539.579 659.695]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.16) >>
 >> endobj
-1088 0 obj <<
+1098 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 662.7096 539.579 671.6658]
+/Rect [527.6238 638.7678 539.579 647.7241]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.1) >>
 >> endobj
-1089 0 obj <<
+1099 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 650.7387 539.579 659.695]
+/Rect [527.6238 626.7969 539.579 635.7532]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.2) >>
 >> endobj
-1090 0 obj <<
+1100 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 638.7678 539.579 647.7241]
+/Rect [527.6238 614.826 539.579 623.7823]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.3) >>
 >> endobj
-1091 0 obj <<
+1101 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 626.7969 539.579 635.7532]
+/Rect [527.6238 602.8551 539.579 611.8114]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.4) >>
 >> endobj
-1092 0 obj <<
+1102 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 614.826 539.579 623.7823]
+/Rect [527.6238 590.8843 539.579 599.8405]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.5) >>
 >> endobj
-1093 0 obj <<
+1103 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 602.8551 539.579 611.8114]
+/Rect [527.6238 578.9134 539.579 587.8696]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.6) >>
 >> endobj
-1094 0 obj <<
+1104 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 590.8843 539.579 599.8405]
+/Rect [527.6238 566.9425 539.579 575.8988]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.7) >>
 >> endobj
-1095 0 obj <<
+1105 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 579.013 539.579 587.8696]
+/Rect [527.6238 555.0713 539.579 563.9279]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.8) >>
 >> endobj
-1096 0 obj <<
+1106 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 566.9425 539.579 575.8988]
+/Rect [527.6238 543.0007 539.579 551.957]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.9) >>
 >> endobj
-1097 0 obj <<
+1107 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 554.9716 539.579 563.9279]
+/Rect [527.6238 531.0298 539.579 539.9861]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.10) >>
 >> endobj
-1098 0 obj <<
+1108 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 543.1004 539.579 552.1065]
+/Rect [527.6238 519.1586 539.579 528.1647]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.11) >>
 >> endobj
-1099 0 obj <<
+1109 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 531.1295 539.579 540.1356]
+/Rect [527.6238 507.0881 539.579 516.0443]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.12) >>
 >> endobj
-1100 0 obj <<
+1110 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 519.0589 539.579 528.0152]
+/Rect [527.6238 495.1172 539.579 504.0735]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.13) >>
 >> endobj
-1101 0 obj <<
+1111 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 507.0881 539.579 516.0443]
+/Rect [527.6238 483.1463 539.579 492.1026]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.14) >>
 >> endobj
-1102 0 obj <<
+1112 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 495.2168 539.579 504.0735]
+/Rect [527.6238 471.2751 539.579 480.1317]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.15) >>
 >> endobj
-1103 0 obj <<
+1113 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 483.1463 539.579 492.1026]
+/Rect [527.6238 459.2045 539.579 468.1608]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.16) >>
 >> endobj
-1104 0 obj <<
+1114 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 471.1754 539.579 480.1317]
+/Rect [527.6238 447.2336 539.579 456.1899]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.17) >>
 >> endobj
-1105 0 obj <<
+1115 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 459.2045 539.579 468.3103]
+/Rect [527.6238 435.2628 539.579 444.3685]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.18) >>
 >> endobj
-1106 0 obj <<
+1116 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 447.2336 539.579 456.1899]
+/Rect [527.6238 423.2919 539.579 432.2481]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.19) >>
 >> endobj
-1107 0 obj <<
+1117 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 435.2628 539.579 444.219]
+/Rect [527.6238 411.321 539.579 420.2773]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.20) >>
 >> endobj
-1108 0 obj <<
+1118 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 423.2919 539.579 432.2481]
+/Rect [527.6238 399.3501 539.579 408.3064]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.17) >>
 >> endobj
-1109 0 obj <<
+1119 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 411.321 539.579 420.2773]
+/Rect [527.6238 387.3792 539.579 396.3355]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.18) >>
 >> endobj
-1110 0 obj <<
+1120 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 399.3501 539.579 408.3064]
+/Rect [527.6238 375.4083 539.579 384.3646]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.19) >>
 >> endobj
-1111 0 obj <<
+1121 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 387.3792 539.579 396.3355]
+/Rect [527.6238 363.4374 539.579 372.3937]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.20) >>
 >> endobj
-1112 0 obj <<
+1122 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 375.4083 539.579 384.3646]
+/Rect [527.6238 351.4666 539.579 360.4228]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.21) >>
 >> endobj
-1113 0 obj <<
+1123 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 363.4374 539.579 372.3937]
+/Rect [527.6238 339.4957 539.579 348.452]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.22) >>
 >> endobj
-1114 0 obj <<
+1124 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 351.4666 539.579 360.4228]
+/Rect [527.6238 327.5248 539.579 336.4811]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.23) >>
 >> endobj
-1115 0 obj <<
+1125 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 339.4957 539.579 348.452]
+/Rect [527.6238 315.5539 539.579 324.5102]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.24) >>
 >> endobj
-1116 0 obj <<
+1126 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 327.5248 539.579 336.4811]
+/Rect [527.6238 303.583 539.579 312.5393]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.25) >>
 >> endobj
-1117 0 obj <<
+1127 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 315.5539 539.579 324.5102]
+/Rect [527.6238 291.6121 539.579 300.5684]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.26) >>
 >> endobj
-1118 0 obj <<
+1128 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 303.583 539.579 312.5393]
+/Rect [527.6238 279.6413 539.579 288.5975]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.27) >>
 >> endobj
-1119 0 obj <<
+1129 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 291.6121 539.579 300.5684]
+/Rect [527.6238 267.6704 539.579 276.6267]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.28) >>
 >> endobj
-1120 0 obj <<
+1130 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 279.6413 539.579 288.5975]
+/Rect [527.6238 255.6995 539.579 264.6558]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.28.1) >>
 >> endobj
-1121 0 obj <<
+1131 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 267.6704 539.579 276.6267]
+/Rect [527.6238 243.7286 539.579 252.6849]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.28.2) >>
 >> endobj
-1122 0 obj <<
+1132 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 255.6995 539.579 264.6558]
+/Rect [527.6238 231.7577 539.579 240.714]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.28.3) >>
 >> endobj
-1123 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 243.7286 539.579 252.8343]
-/Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.28.4) >>
->> endobj
-1124 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 231.7577 539.579 240.8635]
-/Subtype /Link
-/A << /S /GoTo /D (section.6.3) >>
->> endobj
-1125 0 obj <<
+1133 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 219.7868 539.579 228.8926]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.1) >>
+/A << /S /GoTo /D (subsubsection.6.2.28.4) >>
 >> endobj
-1126 0 obj <<
+1134 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 207.8159 539.579 216.9217]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.3.1.1) >>
+/A << /S /GoTo /D (section.6.3) >>
 >> endobj
-1127 0 obj <<
+1135 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 195.845 539.579 204.9508]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.3.1.2) >>
+/A << /S /GoTo /D (subsection.6.3.1) >>
 >> endobj
-1128 0 obj <<
+1136 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 183.8742 539.579 192.9799]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.2) >>
+/A << /S /GoTo /D (subsubsection.6.3.1.1) >>
 >> endobj
-1129 0 obj <<
+1137 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 171.9033 539.579 181.009]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.3) >>
+/A << /S /GoTo /D (subsubsection.6.3.1.2) >>
 >> endobj
-1130 0 obj <<
+1138 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 159.9324 539.579 169.0381]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.4) >>
+/A << /S /GoTo /D (subsection.6.3.2) >>
 >> endobj
-1131 0 obj <<
+1139 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 147.9615 539.579 157.0673]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.5) >>
+/A << /S /GoTo /D (subsection.6.3.3) >>
 >> endobj
-1132 0 obj <<
+1140 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 135.9906 539.579 145.0964]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.3.5.1) >>
+/A << /S /GoTo /D (subsection.6.3.4) >>
 >> endobj
-1133 0 obj <<
+1141 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 124.0197 539.579 133.1255]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.3.5.2) >>
+/A << /S /GoTo /D (subsection.6.3.5) >>
 >> endobj
-1134 0 obj <<
+1142 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 112.0489 539.579 121.1546]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.3.5.3) >>
+/A << /S /GoTo /D (subsubsection.6.3.5.1) >>
 >> endobj
-1135 0 obj <<
+1143 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 100.078 539.579 109.1837]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.3.5.4) >>
+/A << /S /GoTo /D (subsubsection.6.3.5.2) >>
 >> endobj
-1136 0 obj <<
+1144 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 88.1071 539.579 97.2128]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.6) >>
+/A << /S /GoTo /D (subsubsection.6.3.5.3) >>
 >> endobj
-1137 0 obj <<
+1145 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 76.1362 539.579 85.242]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.3.7) >>
+/A << /S /GoTo /D (subsubsection.6.3.5.4) >>
 >> endobj
-1138 0 obj <<
+1146 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 64.1653 539.579 73.2711]
 /Subtype /Link
-/A << /S /GoTo /D (section.6.4) >>
+/A << /S /GoTo /D (subsection.6.3.6) >>
 >> endobj
-1079 0 obj <<
-/D [1077 0 R /XYZ 85.0394 794.5015 null]
+1087 0 obj <<
+/D [1085 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1076 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R >>
+1084 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1141 0 obj <<
-/Length 3413      
+1149 0 obj <<
+/Length 3424      
 /Filter /FlateDecode
 >>
 stream
-xÚí�msÛÆÇßëSð]¥™êŒ{Ƶ/:–§J'•”éLÓ¼€HˆBM4AZã~úˆ»ãR<lt±[6ãɈ”°Øåþ·¸'€t”Ùt$Q†™‘6‚ÈŒÊÑx~”�¦öoßQwÌ©?èuv}ôì%×#CŒbjt};R&7'ËI–çtt=ùåøüÇW×ß¼º¾:ùõú»£o®ÃY¡gšñî”oŽ~ù5Ml
-ÇÁx@Ýw°H:ÒBÛŸ4t,°l�óf]¯Ê¥}—gæ3Åà““â“™L
-0ÄH�bQJ‡I‰‚‘‚ºßV.‰P9`%TŽWÅÜ—Žrù¶\ÆËÈ–!Áò§ ÷ Ð>ÉBCLh˜iTèH ˜Ð¨û­ÐŒž+
-„fNè7µú‡¢²bÖE=.Km£Åç"ì ¢þ#'+
-1EaJ)eÊFÁEÝo¥”ðL@E¹Sô²l›Ù#šl®ØÓ+؃rû|$Ë
1¹a¾Q¹#�`r£îƒÜÊÂ,Ô©}ÕŒ_—«^Û‹g?þ–è*_€Ú>©b;Dk˜lJù Ô‘(¥Qß[¡sMì�­ÎÒé|ÞÌVÔ›jV­ÞõªÞW«».8;Æ1;çÒD˜LÙ
-bXAeQ¬"�`X¡î=VTÙ¢c¶X1‡ÕÏmUOûËè*J˜V$7¾:¶ƒ5-#:5íåºw�«Šþª‘òYOF
-bHAUQ¤"�`H¡îõ5³£­¥cŠ»®Ú‹wu1¯Æ=S?/&Ū|Ø»ÕRzcqb|N“‰
†1P3”˜H 1{îc£ ™[t˜ä~„º]ŸPJ�—ÍúfV¶wöúÕ¤¡ü„3<v°
�ÁÎNd”šÁ¼Àó!ùØwkAR™nñ°Ÿ—ÈÃ`缙ϻâÙ5šŸúµÍͼÄqÛ$7ª�æÔF
‘Fµ##
-O$"Ô½»²K©‰P40:Œ«?¹
sݸÙÄûfùÚ¶®¿öïîšûþŸp°]ô?þ“elºÞ€çJw³ög¸+Âiï]rú7[Ñiþ	(Üç$Yp`ˆ	sŽ
-	uª†�„kãg®j\Ôã^²®O:uÝHµŸ5¹+êéN_ϯV…›Gyµžßt‹ÖÉ*ƒø4%C
-B$Ô}ècdŒd™ò$×Çx¸1S¾¯n–…³^­‹fi±PÔ&7¼ž>£É¼
-dOAxŒÂ¤nɸ©oáCT®…EÆg5`ˆ!U£,F&†êÞ#Ã‘Tl‘Q=2WÅ|1sÔ<_,fÕØݘu*…:,ø> Ä'1™`ˆEB	‰‚‚º÷trªíF·Œô›7íHºÝ`ò—“SnÇBE�K[mÑiWë›þ•[î
wv¯Wî^P)ôYµ™HbBÃL£BGÁ„FÝo…Î$á2ƒB³¡O‹ö]=N–[‹ã?ïìÉt‹€ÝÉîܾÊfÝÎÞu{´Ø{Jä?C²DÀ“戲áÍK±@0‰P÷A"f8a*
-ñ]…ü…íå
ëæ»VË¢n‹±^dÇãYµ¹IÊdüÓ41ÿ
Såvˆz0}˜x‘(íPß[érJh®€tbWºiQ9ɦåª[!¯êÛ¦[Òê—³v6ËØ#êb^î±
-kdãfbå–\~|ÍÜ'KÖlk‡iò†j¶¦æ{«™2Ý“ÓMÞÜó3ÜÔ&ð¡5¸AÈ·´îõ¢/‚Óe1?9Õ;Ë–jƒpø$É"
CL%˜)ʇÓ	u¿Jj’1
-…RN¨ºué½ñ2MšyQÕÏêðŒ¨<#j|WŽ_û7Uí[ÕrÞîîd»|yÞ¿™éwy
êä?H²NÀÓ	&Šòá-c±@0�P÷n´Á„ †›íåK÷£��e—�­b6é:“‡�¦qV|:“Y
†+P.”•H +{îcµc„çº/ügÝv~üCQ¯ýÞÂE1EökëÇî׆È~í�¨(~º<–‹=·±uLf�·=Ä~Uìl³,ÅÍñ¤š~;žÜœPÐ#¹å
C¬åA½QÊ"�`´¡î=mÔä„1îic=mwM׳”ú€ÛŽ[$7hˆà¶#8åÃ}ìX n¸û€[®îAUg›¥¯®¸Õm[ŽO'ímß{›¿.m�çù�¦ß�‘Ot2FÀÃ
-IÅð †ê>`¤ɤñ‰Œ,<ž£YqSΞøSƒ?
;>»Éì
-Šâ	Ã	upb’hîéqFò]œªiý¿ÍSÕ…à�Þ$Ÿêd�€!”’J¤ß		u@¢œ(a<H¦©›XŸœn&ÒûÝFJ²A¿› Ÿãd‚€!FÔ�Êá÷±@0‚P÷� Œ©ÜÃ@ÎͺýÑ;¹Z$Eè÷#ä“œŒ0Ä‚"R9¼ë1†êÞ#”"r¢€ ;Ì7ò0Cùñg(½©€
;„/¨0UÃóJ‘(ºPß.­‰È|¿›2X�þÛ¬—u1[,«n_(uÀ'ý{Oúô&ëI0þód+UÃK(û!`ßw‚8Þ>ÕŸø=|î�iýæ©Å¡}Ì'¦÷éOÂ?ùí
š@Zª�oÔØa©ðUŠ§Ì�<�~Ÿ„ýŸ#%{ÿonÜ~Á¤Ð„çC߸Ŵ!,Ëô¨û^.7:­Þ"71lŽ¡ÿá>í‡endstream
+xÚí�[sÛ6Çßý)ô¶öÌ
+Á• vvl§é¦—´k»³3Ûí-Ñ2'éŠR<ÙO¿ @Gxj$iÇj¦cÙâá9:ÿq#ÅFÔþc#•‘Ìp3ÒFE™MGt4³ï}}ÄÜ1cÐuvuôâ•Ð#CLƳÑÕÍH*E¸Úœ,'4ÏÙèjúóñùo®¾zsuyòËÕ7G_]…³BÏŒŠî”¿ýüMm
+�ç¶ý2É\=¿]6Í*Rg…$TrwTQO#gb†¥¥;æ²\­«iìL¹
Iú’ý¦?5±^Ódb�!F,d†±l˜ØH ±¨{7Ùc»w„i­<°a²§›øÛGN1Ke.K“AxíðPsØWõ»ª/ õ¢¬m×SdâùTÇA¬|擱†VPY«H V¨{‡•2œP£¶Xq‡ÕOmUÏúËè*J˜ÎHn|ulk%š†šöj]OºN‹UE?g¤BÖS‘‚†R;ªbHÅA�ÂÝûk«Ê)¡LHÇ”p]µ—ïëbQMz¦~º›«òaïV«ìЋãsšL0Ĉ�š¡ÄDÁˆÙs)eG´ã~¬º]�0ÆŽ—Íúz^¶·öúÕ¤Áüø3<v°
�ÁÎNdŒ
/ ÃóaùØsmAR¡�ËGìœ7‹EW<»Fóc¡¶¹YtÃy)c›ôFåӜܨ€!Ö¨ Œ(<‘@0ˆP÷þÊ.„�B3ÏPè0¾^ýÅ
˜ëÆM/Þ7Ë·¶uý½ÿí¶¹ï_L
+ÛëþÇ)å³õ<Wº›µ?ÃmN{ïú�³ØŠÎò?�‚AÁ}N’†˜à0ç¨à‘@0ÁQ÷¡jpÛ›gÊ+Î]Õx]Ozɺ>}èÔu#Õ~Ö䶨g;}=¿XùÝKoÖ‹ën±Á:yB¥`Ÿ¦d€!
”
… 
ê>@@
aB8|ßëß·%l¶çö×~�áŸåüζZ)בG¡ä’�LÒÖ	H‰r´†ÑCß±™Ì3b»nùÆ÷©-㜟ÞÝ•õ´š”ÃSÎÁì±½0h€ôÂvÂa|xMžÉÁ¾ÛXS’Ziò~¢û´»~jmÓ0y[7÷ór:ëêi·ÈÊÍ¡ï•ÜtBrSÛ4DÏŽx(2‘@0tP÷®ï%3N$Ë9;¦kB}•=[Vå�+¸U»j–na§¹yp~ùæòÁÕº_Ê(ûrŠhHV2	À#
Š�’	#
uŠˆ¢D™9x_D¾.ëré»WAå‹òÆ]¦ÃÎœ×õÍfÃøfÒ,3_fÅ$Ãç.™`ˆ‘
µa|xßG,ŒÔ½¯›åÀð5âõ�ï2×è§Óž†¶-[?SôÔþg²n_.$!�É�
+I$Ô}(<#LSO‰èËÇYu=¯šÙ²¸»}¿#\$.׳Yٮʩ/+ÅÔðzfçÏ£o2—Ì0ĸ€Ê \DÁ¸@ÝûâÁdw•òXøâqQþº¶Ê÷ºÛ+‡ß±p}U�ÊÅ«ó¶ç!Ï…Ÿ²d€!Æ”å!ÆêÞó@9¡4ÛòÀÝŤÛîUûÑýËeqÓQ`?NƒŒÏj22ÀCªÆøð¢K,Ô½CFäöO\Ê€Œè‘ùauë7¿l&kP8N¯Ãto?QŒ?�>FÈU*Ð
aG„X ¸{ßÇZ“\rO‚t}Œ‡›Ã0å»êzYø1ëåúî®YZ,2f“^OŸÑd^€!ÆTå%ÆêÞŽL�Qáqñ}�~EÒ
`]WmÕ-ðkv˜û
+yà&�ŸÚdn€!Æ
”å&Æ
êÞs#Qöo�á;¹íª˜{p¾ØÝÞ?>ÅÉü
+˜&Rp(P=á

+Óº%“¦¾��OÈr}((2>«ÉÈ
+u¿Jp’+
…ÊœPuëÒ{íeš6‹¢ª_ÔáéP-x:Ô䶜¼õ¿TµoZËE»»“íâÕyÿBR-ÓïïÔÉ�d�€!¦LÃ[Æb�`:¡îÝhƒsJ´V:¨¤ûÑÆβËÎV1›tMÕa£iœŸÎdV€!Æ
+”e%ÆÊžûØFmfr¹è—�Ϻíâøû¢^û½…wÅÙ¯¬»_ ûµw¢bbø);ð|H.öÝÆÖ1m'‘0éãt¶Y–æxZ;ŒOnN(è‘Úò !ÒòvôF)‹‚цº´iI¨2ž6ÞÓvÛtÝK¥¸ýñ¸yA’q†nPp&†{Ù±@0ÜP÷
·Œ£µp¸	WÜê¶-'ãi{Ó÷ÞoKÛAy~ éƒ1ò‰NÆbA!™ÄÁ0BÝŒ¤!¹Q#¹ƒ‘…Çs4/®Ëù^ðŸÀŽÏn2;ÀcªÇäðÓX ;¨ûÀŽÐ$÷7$žmÖÍvØ™•Ý¾
©×µOD“Ïw2MÀ£	êÉäðØb�`4¡îM\-Ü“5Î6Kj[šú¡í»æm·öªØ�¨OD”Ïy2QÀ#
+jj‹Ê0Q‘@0¢P÷�(&H&�'JïÕ–«UÕMe
+Ô§ÃÉ'<'`ˆáEqŠ‚ᄺ8QFTææqFò]œªYý¿ÍÕ¥�>$Ÿêd�€!”’)¤ß		uïAÊ
‘¹ò™ž£n^}:ÞÌ£÷›�2Å
 endobj
-1140 0 obj <<
+1148 0 obj <<
 /Type /Page
-/Contents 1141 0 R
-/Resources 1139 0 R
+/Contents 1149 0 R
+/Resources 1147 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 931 0 R
-/Annots [ 1143 0 R 1144 0 R 1145 0 R 1146 0 R 1147 0 R 1148 0 R 1152 0 R 1153 0 R 1154 0 R 1155 0 R 1156 0 R 1157 0 R 1158 0 R 1159 0 R 1160 0 R 1161 0 R 1162 0 R 1163 0 R 1164 0 R 1165 0 R 1166 0 R 1167 0 R 1168 0 R 1169 0 R 1170 0 R 1171 0 R 1172 0 R 1173 0 R 1174 0 R 1175 0 R 1176 0 R 1177 0 R 1178 0 R 1179 0 R 1180 0 R 1181 0 R 1182 0 R 1183 0 R 1184 0 R 1185 0 R 1186 0 R 1187 0 R 1188 0 R 1189 0 R 1190 0 R 1191 0 R 1192 0 R 1193 0 R 1194 0 R 1195 0 R 1196 0 R 1197 0 R 1198 0 R 1199 0 R 1200 0 R ]
+/Parent 939 0 R
+/Annots [ 1151 0 R 1152 0 R 1153 0 R 1154 0 R 1155 0 R 1156 0 R 1157 0 R 1158 0 R 1162 0 R 1163 0 R 1164 0 R 1165 0 R 1166 0 R 1167 0 R 1168 0 R 1169 0 R 1170 0 R 1171 0 R 1172 0 R 1173 0 R 1174 0 R 1175 0 R 1176 0 R 1177 0 R 1178 0 R 1179 0 R 1180 0 R 1181 0 R 1182 0 R 1183 0 R 1184 0 R 1185 0 R 1186 0 R 1187 0 R 1188 0 R 1189 0 R 1190 0 R 1191 0 R 1192 0 R 1193 0 R 1194 0 R 1195 0 R 1196 0 R 1197 0 R 1198 0 R 1199 0 R 1200 0 R 1201 0 R 1202 0 R 1203 0 R 1204 0 R 1205 0 R 1206 0 R 1207 0 R 1208 0 R ]
 >> endobj
-1143 0 obj <<
+1151 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [494.296 758.4766 511.2325 767.5824]
 /Subtype /Link
+/A << /S /GoTo /D (subsection.6.3.7) >>
+>> endobj
+1152 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [494.296 746.3946 511.2325 755.5003]
+/Subtype /Link
+/A << /S /GoTo /D (section.6.4) >>
+>> endobj
+1153 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [494.296 734.3125 511.2325 743.4183]
+/Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.4.0.1) >>
 >> endobj
-1144 0 obj <<
+1154 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 746.4943 511.2325 755.5003]
+/Rect [494.296 722.3302 511.2325 731.3362]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.4.1) >>
 >> endobj
-1145 0 obj <<
+1155 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 734.4122 511.2325 743.4183]
+/Rect [494.296 710.2481 511.2325 719.2542]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.4.1.1) >>
 >> endobj
-1146 0 obj <<
+1156 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 722.3302 511.2325 731.3362]
+/Rect [494.296 698.1661 511.2325 707.1721]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.4.1.2) >>
 >> endobj
-1147 0 obj <<
+1157 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 710.2481 511.2325 719.2542]
+/Rect [494.296 686.084 511.2325 695.0901]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.4.1.3) >>
 >> endobj
-1148 0 obj <<
+1158 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 698.0664 511.2325 707.1721]
+/Rect [494.296 673.9023 511.2325 683.008]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.4.1.4) >>
 >> endobj
-1152 0 obj <<
+1162 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 686.084 511.2325 695.0901]
+/Rect [494.296 661.9199 511.2325 670.926]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.4.1.5) >>
 >> endobj
-1153 0 obj <<
+1163 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 663.4123 511.2325 672.2689]
+/Rect [494.296 639.2482 511.2325 648.1048]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.7) >>
 >> endobj
-1154 0 obj <<
+1164 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 651.3501 511.2325 660.4558]
+/Rect [494.296 627.186 511.2325 636.2917]
 /Subtype /Link
 /A << /S /GoTo /D (section.7.1) >>
 >> endobj
-1155 0 obj <<
+1165 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 639.268 511.2325 648.3738]
+/Rect [494.296 615.1039 511.2325 624.2097]
 /Subtype /Link
 /A << /S /GoTo /D (section.7.2) >>
 >> endobj
-1156 0 obj <<
+1166 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 627.186 511.2325 636.2917]
+/Rect [494.296 603.0219 511.2325 612.1276]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.7.2.1) >>
 >> endobj
-1157 0 obj <<
+1167 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 615.1039 511.2325 624.2097]
+/Rect [494.296 590.9398 511.2325 600.0456]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.7.2.2) >>
 >> endobj
-1158 0 obj <<
+1168 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 603.0219 511.2325 612.1276]
+/Rect [494.296 578.8578 511.2325 587.9635]
 /Subtype /Link
 /A << /S /GoTo /D (section.7.3) >>
 >> endobj
-1159 0 obj <<
+1169 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 580.4498 511.2325 589.3064]
+/Rect [494.296 556.2857 511.2325 565.1423]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.8) >>
 >> endobj
-1160 0 obj <<
+1170 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 568.3876 511.2325 577.4934]
+/Rect [494.296 544.2235 511.2325 553.3293]
 /Subtype /Link
 /A << /S /GoTo /D (section.8.1) >>
 >> endobj
-1161 0 obj <<
+1171 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 556.3056 511.2325 565.4113]
+/Rect [494.296 532.1415 511.2325 541.2472]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.8.1.1) >>
 >> endobj
-1162 0 obj <<
+1172 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 544.2235 511.2325 553.3293]
+/Rect [494.296 520.0594 511.2325 529.1652]
 /Subtype /Link
 /A << /S /GoTo /D (section.8.2) >>
 >> endobj
-1163 0 obj <<
+1173 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 532.1415 511.2325 541.2472]
+/Rect [494.296 507.9774 511.2325 517.0831]
 /Subtype /Link
 /A << /S /GoTo /D (section.8.3) >>
 >> endobj
-1164 0 obj <<
+1174 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 509.7138 511.2325 518.426]
+/Rect [494.296 485.5497 511.2325 494.2619]
 /Subtype /Link
 /A << /S /GoTo /D (appendix.A) >>
 >> endobj
-1165 0 obj <<
+1175 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 497.6069 511.2325 506.6129]
+/Rect [494.296 473.4428 511.2325 482.4488]
 /Subtype /Link
 /A << /S /GoTo /D (section.A.1) >>
 >> endobj
-1166 0 obj <<
+1176 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 485.5248 511.2325 494.5309]
+/Rect [494.296 461.3607 511.2325 470.3668]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.1.1) >>
 >> endobj
-1167 0 obj <<
+1177 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 473.4428 511.2325 482.4488]
+/Rect [494.296 449.2787 511.2325 458.2847]
 /Subtype /Link
 /A << /S /GoTo /D (section.A.2) >>
 >> endobj
-1168 0 obj <<
+1178 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 461.3607 511.2325 470.3668]
+/Rect [494.296 437.1966 511.2325 446.2027]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.2.1) >>
 >> endobj
-1169 0 obj <<
+1179 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 449.2787 511.2325 458.2847]
+/Rect [494.296 425.1146 511.2325 434.1207]
 /Subtype /Link
 /A << /S /GoTo /D (section.A.3) >>
 >> endobj
-1170 0 obj <<
+1180 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 437.1966 511.2325 446.2027]
+/Rect [494.296 413.0325 511.2325 422.0386]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.3.1) >>
 >> endobj
-1171 0 obj <<
+1181 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 425.0149 511.2325 434.1207]
+/Rect [494.296 400.8508 511.2325 409.9566]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.3.2) >>
 >> endobj
-1172 0 obj <<
+1182 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 412.9329 511.2325 422.0386]
+/Rect [494.296 388.7688 511.2325 397.8745]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.3.3) >>
 >> endobj
-1173 0 obj <<
+1183 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 400.8508 511.2325 409.9566]
+/Rect [494.296 376.6867 511.2325 385.7925]
 /Subtype /Link
 /A << /S /GoTo /D (section.A.4) >>
 >> endobj
-1174 0 obj <<
+1184 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 388.8684 511.2325 397.8745]
+/Rect [494.296 364.7043 511.2325 373.7104]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.4.1) >>
 >> endobj
-1175 0 obj <<
+1185 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 376.7864 511.2325 385.7925]
+/Rect [494.296 352.6223 511.2325 361.6284]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.4.2) >>
 >> endobj
-1176 0 obj <<
+1186 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 364.7043 511.2325 373.7104]
+/Rect [494.296 340.5402 511.2325 349.5463]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.4.3) >>
 >> endobj
-1177 0 obj <<
+1187 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 352.6223 511.2325 361.6284]
+/Rect [494.296 328.4582 511.2325 337.4643]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.4.4) >>
 >> endobj
-1178 0 obj <<
+1188 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 340.4406 511.2325 349.5463]
+/Rect [494.296 316.2765 511.2325 325.3822]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.4.5) >>
 >> endobj
-1179 0 obj <<
+1189 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 328.3585 511.2325 337.4643]
+/Rect [494.296 304.1944 511.2325 313.3002]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.4.6) >>
 >> endobj
-1180 0 obj <<
+1190 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 316.2765 511.2325 325.3822]
+/Rect [494.296 292.1124 511.2325 301.2181]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.A.4.6.1) >>
 >> endobj
-1181 0 obj <<
+1191 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 304.1944 511.2325 313.3002]
+/Rect [494.296 280.0303 511.2325 289.1361]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.A.4.6.2) >>
 >> endobj
-1182 0 obj <<
+1192 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 292.1124 511.2325 301.2181]
+/Rect [494.296 267.9483 511.2325 277.054]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.A.4.6.3) >>
 >> endobj
-1183 0 obj <<
+1193 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 280.0303 511.2325 289.1361]
+/Rect [494.296 255.8662 511.2325 264.972]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.A.4.6.4) >>
 >> endobj
-1184 0 obj <<
+1194 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 267.9483 511.2325 277.054]
+/Rect [494.296 243.7842 511.2325 252.8899]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.A.4.6.5) >>
 >> endobj
-1185 0 obj <<
+1195 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 255.8662 511.2325 264.972]
+/Rect [494.296 231.7021 511.2325 240.8079]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.A.4.6.6) >>
 >> endobj
-1186 0 obj <<
+1196 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 243.7842 511.2325 252.8899]
+/Rect [494.296 219.6201 511.2325 228.7258]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.4.7) >>
 >> endobj
-1187 0 obj <<
+1197 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 221.2121 511.2325 230.0687]
+/Rect [494.296 197.048 511.2325 205.9046]
 /Subtype /Link
 /A << /S /GoTo /D (appendix.B) >>
 >> endobj
-1188 0 obj <<
+1198 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 209.1499 511.2325 218.2557]
+/Rect [494.296 184.9858 511.2325 194.0916]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.1) >>
 >> endobj
-1189 0 obj <<
+1199 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 197.0679 511.2325 206.1736]
+/Rect [494.296 172.9038 511.2325 182.0095]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.2) >>
 >> endobj
-1190 0 obj <<
+1200 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 184.9858 511.2325 194.0916]
+/Rect [494.296 160.8217 511.2325 169.9275]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.3) >>
 >> endobj
-1191 0 obj <<
+1201 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 173.0034 511.2325 182.0095]
+/Rect [494.296 148.8393 511.2325 157.8454]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.4) >>
 >> endobj
-1192 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 160.8217 511.2325 169.9275]
-/Subtype /Link
-/A << /S /GoTo /D (section.B.5) >>
->> endobj
-1193 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [494.296 148.7397 511.2325 157.8454]
-/Subtype /Link
-/A << /S /GoTo /D (section.B.6) >>
->> endobj
-1194 0 obj <<
+1202 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [494.296 136.6576 511.2325 145.7634]
 /Subtype /Link
-/A << /S /GoTo /D (section.B.7) >>
+/A << /S /GoTo /D (section.B.5) >>
 >> endobj
-1195 0 obj <<
+1203 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [494.296 124.5756 511.2325 133.6813]
 /Subtype /Link
-/A << /S /GoTo /D (section.B.8) >>
+/A << /S /GoTo /D (section.B.6) >>
 >> endobj
-1196 0 obj <<
+1204 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [494.296 112.4935 511.2325 121.5993]
 /Subtype /Link
-/A << /S /GoTo /D (section.B.9) >>
+/A << /S /GoTo /D (section.B.7) >>
 >> endobj
-1197 0 obj <<
+1205 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [494.296 100.4115 511.2325 109.5172]
 /Subtype /Link
-/A << /S /GoTo /D (section.B.10) >>
+/A << /S /GoTo /D (section.B.8) >>
 >> endobj
-1198 0 obj <<
+1206 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [494.296 88.3294 511.2325 97.4352]
 /Subtype /Link
-/A << /S /GoTo /D (section.B.11) >>
+/A << /S /GoTo /D (section.B.9) >>
 >> endobj
-1199 0 obj <<
+1207 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [494.296 76.2474 511.2325 85.3531]
 /Subtype /Link
-/A << /S /GoTo /D (section.B.12) >>
+/A << /S /GoTo /D (section.B.10) >>
 >> endobj
-1200 0 obj <<
+1208 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [494.296 64.1653 511.2325 73.2711]
 /Subtype /Link
-/A << /S /GoTo /D (section.B.13) >>
+/A << /S /GoTo /D (section.B.11) >>
 >> endobj
-1142 0 obj <<
-/D [1140 0 R /XYZ 56.6929 794.5015 null]
+1150 0 obj <<
+/D [1148 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1139 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F39 1151 0 R /F21 930 0 R >>
+1147 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F39 1161 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1203 0 obj <<
-/Length 660       
+1211 0 obj <<
+/Length 764       
 /Filter /FlateDecode
 >>
 stream
-xÚíØ;oÛ0
-Ü[PÍùü²Qˆg›ì-ZHßg�9iïvEú‹/qÃC�O~:×q0î¤� (UHÎ[6ýàMYf¬…àMwé¯ïDc…`ªKÑ
ê(²úµ}éG¾›Õ
-Ì¡ŠÛ
-ÆQ%
-ɡʦPù2üyä*Û£jšvwDåŒ�5�ISØïÉš¢Àœ¦¸Ÿ`带D!9MÙôƒ&
-ÞÃú¶«ézSÕô+çâÏÏ7ïau&QaÏ'‹Šs¢âžfE%
-ɉʦDYÍP™pÓ( Õî–µ\W»õ‚¢”óQuXaë'Ês°âÖ‚5ã°…œÀž�Q£8Ó !õ�ÌÿC­Åÿ?’;>8ôw�Ò9‘^®äŽ!KümD7W·Ø_£K=Š*ÿ#Èendstream
+xÚíÙÍOÛ0
+Áø é¡‰Ò<¾å³Þ,ëêyæ6G‹�æè®Þâå0˜WˆñŠJôóJ‚ñBÓ^\ÍÀz^¢ãµjê©;ó¿Ó:´·¼ùŽöbÞ⎃2ýÞ…`ÞÐôÁ›+C+e¼7Ù¦?½�eŒXmŠvPK‘LÍ]7òÕ¬
+ÚÉôvähô }§;Œ1‡±P¶ßa¢Ì!š>8 @y‡jwÞ+Zl÷³fRpàã9î°¨ü¶Fb¨â¶‚†~T‰B0Thz�J¹#•ð¨t‡ª®›õ•QzÔtMa¿‡jŠM¯ú	ºÿÊ?U¢	O4M,…pãh:MÕjYµ7�“‚©ñJ옟€¡
ƒyE�¯¸Á û¯üS…`¼Ðô�—–Ä
+n,mÇË�£VUS/æíÇŸ}–ßúÁ°¢@VÜZвV¢š>ÀRœXKý-%£¬Çõ´x˜WÓâ;¥ìÏfé|YEH”ßóÁ¢¢@LTÜSTT¢Lš>ˆ’ŒP.ýM#ÿl6åÕúaRXÎÇSÕQ`ù­+
+Ä`Å­­úa%
+Ùƒžß
+QÔÅ%á»_ VJxÿ»¯5„&Ü–^.§Æ1W:ç’´sµ‹ýÕ»Ôí ¨ò¿ã|ì–endstream
 endobj
-1202 0 obj <<
+1210 0 obj <<
 /Type /Page
-/Contents 1203 0 R
-/Resources 1201 0 R
+/Contents 1211 0 R
+/Resources 1209 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1216 0 R
-/Annots [ 1205 0 R 1209 0 R 1210 0 R 1211 0 R 1212 0 R 1213 0 R 1214 0 R 1215 0 R ]
+/Parent 1226 0 R
+/Annots [ 1213 0 R 1214 0 R 1215 0 R 1219 0 R 1220 0 R 1221 0 R 1222 0 R 1223 0 R 1224 0 R 1225 0 R ]
 >> endobj
-1205 0 obj <<
+1213 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 758.4766 539.579 767.5824]
 /Subtype /Link
-/A << /S /GoTo /D (section.B.14) >>
+/A << /S /GoTo /D (section.B.12) >>
 >> endobj
-1209 0 obj <<
+1214 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [522.6425 746.5215 539.579 755.6272]
 /Subtype /Link
+/A << /S /GoTo /D (section.B.13) >>
+>> endobj
+1215 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [522.6425 734.5663 539.579 743.672]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.14) >>
+>> endobj
+1219 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [522.6425 722.6111 539.579 731.7169]
+/Subtype /Link
 /A << /S /GoTo /D (section.B.15) >>
 >> endobj
-1210 0 obj <<
+1220 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 734.666 539.579 743.672]
+/Rect [522.6425 710.7556 539.579 719.7617]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.16) >>
 >> endobj
-1211 0 obj <<
+1221 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 722.6111 539.579 731.7169]
+/Rect [522.6425 698.7008 539.579 707.8065]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.17) >>
 >> endobj
-1212 0 obj <<
+1222 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 710.7556 539.579 719.7617]
+/Rect [522.6425 686.8453 539.579 695.8514]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.18) >>
 >> endobj
-1213 0 obj <<
+1223 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 698.7008 539.579 707.8065]
+/Rect [522.6425 674.7905 539.579 683.8962]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.19) >>
 >> endobj
-1214 0 obj <<
+1224 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 686.7456 539.579 695.8514]
+/Rect [522.6425 662.8353 539.579 671.941]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.20) >>
 >> endobj
-1215 0 obj <<
+1225 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 674.7905 539.579 683.8962]
+/Rect [522.6425 650.8801 539.579 659.9859]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.21) >>
 >> endobj
-1204 0 obj <<
-/D [1202 0 R /XYZ 85.0394 794.5015 null]
+1212 0 obj <<
+/D [1210 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1201 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F41 1208 0 R >>
+1209 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1219 0 obj <<
+1229 0 obj <<
 /Length 2174      
 /Filter /FlateDecode
 >>
@@ -4275,48 +4294,48 @@ FŠüäuܹê;´¡’<ÕY®§6<�ÁG‰ÐB
 –Q�£­¢+O(Ÿèº³ß…Ù¤
 �µ¾€Ð5༚ºÜ¸c3Í¡vÃH-Ôø·¿‹ß
 endobj
-1218 0 obj <<
+1228 0 obj <<
 /Type /Page
-/Contents 1219 0 R
-/Resources 1217 0 R
+/Contents 1229 0 R
+/Resources 1227 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1216 0 R
+/Parent 1226 0 R
 >> endobj
 6 0 obj <<
-/D [1218 0 R /XYZ 85.0394 769.5949 null]
+/D [1228 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1220 0 obj <<
-/D [1218 0 R /XYZ 85.0394 582.8476 null]
+1230 0 obj <<
+/D [1228 0 R /XYZ 85.0394 582.8476 null]
 >> endobj
 10 0 obj <<
-/D [1218 0 R /XYZ 85.0394 512.9824 null]
+/D [1228 0 R /XYZ 85.0394 512.9824 null]
 >> endobj
-1221 0 obj <<
-/D [1218 0 R /XYZ 85.0394 474.7837 null]
+1231 0 obj <<
+/D [1228 0 R /XYZ 85.0394 474.7837 null]
 >> endobj
 14 0 obj <<
-/D [1218 0 R /XYZ 85.0394 399.5462 null]
+/D [1228 0 R /XYZ 85.0394 399.5462 null]
 >> endobj
-1222 0 obj <<
-/D [1218 0 R /XYZ 85.0394 363.8828 null]
+1232 0 obj <<
+/D [1228 0 R /XYZ 85.0394 363.8828 null]
 >> endobj
 18 0 obj <<
-/D [1218 0 R /XYZ 85.0394 223.0066 null]
+/D [1228 0 R /XYZ 85.0394 223.0066 null]
 >> endobj
-1223 0 obj <<
-/D [1218 0 R /XYZ 85.0394 190.9009 null]
+1233 0 obj <<
+/D [1228 0 R /XYZ 85.0394 190.9009 null]
 >> endobj
-1224 0 obj <<
-/D [1218 0 R /XYZ 85.0394 170.4169 null]
+1234 0 obj <<
+/D [1228 0 R /XYZ 85.0394 170.4169 null]
 >> endobj
-1225 0 obj <<
-/D [1218 0 R /XYZ 85.0394 158.4617 null]
+1235 0 obj <<
+/D [1228 0 R /XYZ 85.0394 158.4617 null]
 >> endobj
-1217 0 obj <<
-/Font << /F21 930 0 R /F22 953 0 R /F39 1151 0 R /F41 1208 0 R /F48 1228 0 R >>
+1227 0 obj <<
+/Font << /F21 938 0 R /F22 961 0 R /F39 1161 0 R /F41 1218 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1231 0 obj <<
+1241 0 obj <<
 /Length 3187      
 /Filter /FlateDecode
 >>
@@ -4334,63 +4353,63 @@ H•²/hÊ
 ®£fw"®höx׺©;°Çn|>”°�ÃÓ¶PˇýjÎÖ�zýÁ”rþ!È£+Œ�­$üE™Bö‘Q�™…­Ê"ôãÇœ/Áò±r=?5M[ô°ÌÏ[€Ì°u¸Âz
Æm�Üo<)¶ó=P¿+{’‘OíRzw�dîØPÖ6ôV`0ÐhõðlÓã>§¦|êv=£lÁá“xý1‡š[ÚÍ„C9ßšÞ4â¦Å7ɵkù ’ßÿe¬ˆ¦¯¸Çÿ¤ùâãý×þ{Ôñ¿Ä T0iª_ð‡)¶ˆÌ€
 @Ÿ!þ�êó
4Ï©Êendstream
 endobj
-1230 0 obj <<
+1240 0 obj <<
 /Type /Page
-/Contents 1231 0 R
-/Resources 1229 0 R
+/Contents 1241 0 R
+/Resources 1239 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1216 0 R
-/Annots [ 1237 0 R 1238 0 R ]
+/Parent 1226 0 R
+/Annots [ 1247 0 R 1248 0 R ]
 >> endobj
-1237 0 obj <<
+1247 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [272.8897 207.1951 329.1084 219.2548]
 /Subtype /Link
 /A << /S /GoTo /D (types_of_resource_records_and_when_to_use_them) >>
 >> endobj
-1238 0 obj <<
+1248 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [190.6691 179.6723 249.6573 189.0819]
 /Subtype /Link
 /A << /S /GoTo /D (rfcs) >>
 >> endobj
-1232 0 obj <<
-/D [1230 0 R /XYZ 56.6929 756.8229 null]
+1242 0 obj <<
+/D [1240 0 R /XYZ 56.6929 756.8229 null]
 >> endobj
-1233 0 obj <<
-/D [1230 0 R /XYZ 56.6929 744.8677 null]
+1243 0 obj <<
+/D [1240 0 R /XYZ 56.6929 744.8677 null]
 >> endobj
 22 0 obj <<
-/D [1230 0 R /XYZ 56.6929 651.295 null]
+/D [1240 0 R /XYZ 56.6929 651.295 null]
 >> endobj
-1234 0 obj <<
-/D [1230 0 R /XYZ 56.6929 612.4036 null]
+1244 0 obj <<
+/D [1240 0 R /XYZ 56.6929 612.4036 null]
 >> endobj
 26 0 obj <<
-/D [1230 0 R /XYZ 56.6929 555.4285 null]
+/D [1240 0 R /XYZ 56.6929 555.4285 null]
 >> endobj
-1235 0 obj <<
-/D [1230 0 R /XYZ 56.6929 530.6703 null]
+1245 0 obj <<
+/D [1240 0 R /XYZ 56.6929 530.6703 null]
 >> endobj
 30 0 obj <<
-/D [1230 0 R /XYZ 56.6929 416.0112 null]
+/D [1240 0 R /XYZ 56.6929 416.0112 null]
 >> endobj
-1236 0 obj <<
-/D [1230 0 R /XYZ 56.6929 391.253 null]
+1246 0 obj <<
+/D [1240 0 R /XYZ 56.6929 391.253 null]
 >> endobj
 34 0 obj <<
-/D [1230 0 R /XYZ 56.6929 164.815 null]
+/D [1240 0 R /XYZ 56.6929 164.815 null]
 >> endobj
-1239 0 obj <<
-/D [1230 0 R /XYZ 56.6929 137.4068 null]
+1249 0 obj <<
+/D [1240 0 R /XYZ 56.6929 137.4068 null]
 >> endobj
-1229 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F39 1151 0 R /F41 1208 0 R /F21 930 0 R >>
+1239 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F39 1161 0 R /F41 1218 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1244 0 obj <<
+1254 0 obj <<
 /Length 3415      
 /Filter /FlateDecode
 >>
@@ -4410,60 +4429,60 @@ txÕÁ(1Âùãqt0úØÇ‘C×µLm›§:ÂÄ$è’y¦
 ·o
¾Àbº¦
úž&\Õ=¯d‚Ó÷aŠKѨðÀæ@pð
 –þvA•c«ÇøÀ†û,¤ÆAg€hCõoœ€}¼ew8ýš*çÐð‡#çô/�œÿn1]/‚0Péú\í8°ef´>+sŒBO�D‡+^ .ùRéØ{
 endobj
-1243 0 obj <<
+1253 0 obj <<
 /Type /Page
-/Contents 1244 0 R
-/Resources 1242 0 R
+/Contents 1254 0 R
+/Resources 1252 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1216 0 R
-/Annots [ 1247 0 R 1248 0 R ]
+/Parent 1226 0 R
+/Annots [ 1257 0 R 1258 0 R ]
 >> endobj
-1247 0 obj <<
+1257 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [519.8432 463.1122 539.579 475.1718]
 /Subtype /Link
 /A << /S /GoTo /D (diagnostic_tools) >>
 >> endobj
-1248 0 obj <<
+1258 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [84.0431 451.8246 133.308 463.2167]
 /Subtype /Link
 /A << /S /GoTo /D (diagnostic_tools) >>
 >> endobj
-1245 0 obj <<
-/D [1243 0 R /XYZ 85.0394 794.5015 null]
+1255 0 obj <<
+/D [1253 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 38 0 obj <<
-/D [1243 0 R /XYZ 85.0394 570.5252 null]
+/D [1253 0 R /XYZ 85.0394 570.5252 null]
 >> endobj
-1246 0 obj <<
-/D [1243 0 R /XYZ 85.0394 541.3751 null]
+1256 0 obj <<
+/D [1253 0 R /XYZ 85.0394 541.3751 null]
 >> endobj
 42 0 obj <<
-/D [1243 0 R /XYZ 85.0394 434.1868 null]
+/D [1253 0 R /XYZ 85.0394 434.1868 null]
 >> endobj
-1249 0 obj <<
-/D [1243 0 R /XYZ 85.0394 406.5769 null]
+1259 0 obj <<
+/D [1253 0 R /XYZ 85.0394 406.5769 null]
 >> endobj
 46 0 obj <<
-/D [1243 0 R /XYZ 85.0394 301.1559 null]
+/D [1253 0 R /XYZ 85.0394 301.1559 null]
 >> endobj
-1250 0 obj <<
-/D [1243 0 R /XYZ 85.0394 276.6843 null]
+1260 0 obj <<
+/D [1253 0 R /XYZ 85.0394 276.6843 null]
 >> endobj
 50 0 obj <<
-/D [1243 0 R /XYZ 85.0394 200.1512 null]
+/D [1253 0 R /XYZ 85.0394 200.1512 null]
 >> endobj
-1251 0 obj <<
-/D [1243 0 R /XYZ 85.0394 175.6796 null]
+1261 0 obj <<
+/D [1253 0 R /XYZ 85.0394 175.6796 null]
 >> endobj
-1242 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F39 1151 0 R /F41 1208 0 R /F21 930 0 R >>
+1252 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F39 1161 0 R /F41 1218 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1255 0 obj <<
+1265 0 obj <<
 /Length 2457      
 /Filter /FlateDecode
 >>
@@ -4482,39 +4501,39 @@ S¦…€Äüœº
ã2±öŠ�
41ÑÍ–,÷úBäí]¨u›«˜úDOâ‚
ÙLë–3žatÙ±º÷5vxn�ïH‘šªmÝóìAߌå
 M­
  ZãŠÜƒ[æž.ÇñS!�L%:P–ô˜¥Hé!”·i"®"!G­š¼ü…3Ãø(M¶æÒ?/ÕºðõwÕNïÉzê-çÕÃÿ­@úÂ?Dþ		ÇD÷ÿï2ýý¥�Ê2¹ü—ŠÌ OÕÈŠ%ºaÜÿ?sËù
y;:»endstream
 endobj
-1254 0 obj <<
+1264 0 obj <<
 /Type /Page
-/Contents 1255 0 R
-/Resources 1253 0 R
+/Contents 1265 0 R
+/Resources 1263 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1216 0 R
+/Parent 1226 0 R
 >> endobj
-1256 0 obj <<
-/D [1254 0 R /XYZ 56.6929 794.5015 null]
+1266 0 obj <<
+/D [1264 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 54 0 obj <<
-/D [1254 0 R /XYZ 56.6929 717.7272 null]
+/D [1264 0 R /XYZ 56.6929 717.7272 null]
 >> endobj
-1257 0 obj <<
-/D [1254 0 R /XYZ 56.6929 690.4227 null]
+1267 0 obj <<
+/D [1264 0 R /XYZ 56.6929 690.4227 null]
 >> endobj
 58 0 obj <<
-/D [1254 0 R /XYZ 56.6929 550.0786 null]
+/D [1264 0 R /XYZ 56.6929 550.0786 null]
 >> endobj
-1258 0 obj <<
-/D [1254 0 R /XYZ 56.6929 525.2967 null]
+1268 0 obj <<
+/D [1264 0 R /XYZ 56.6929 525.2967 null]
 >> endobj
 62 0 obj <<
-/D [1254 0 R /XYZ 56.6929 393.0502 null]
+/D [1264 0 R /XYZ 56.6929 393.0502 null]
 >> endobj
-1259 0 obj <<
-/D [1254 0 R /XYZ 56.6929 363.1913 null]
+1269 0 obj <<
+/D [1264 0 R /XYZ 56.6929 363.1913 null]
 >> endobj
-1253 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F39 1151 0 R >>
+1263 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1262 0 obj <<
+1272 0 obj <<
 /Length 2097      
 /Filter /FlateDecode
 >>
@@ -4530,66 +4549,66 @@ hZã|jY/ýE‰áÝN6“dy 8xp]7b~{é0h”~�’e±½„3×rÓ,�Ã,*r¸2Ư{ë³½ŸØøÎê±×꛼cµ¬Ë"
 Ìk
 âþî^̲EÑÅk˜èP<sgÕ1BÚÖP�!žÅj˜K±dx	’;mêá6¨BÐ¾I½�Ÿp
 endobj
-1261 0 obj <<
+1271 0 obj <<
 /Type /Page
-/Contents 1262 0 R
-/Resources 1260 0 R
+/Contents 1272 0 R
+/Resources 1270 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1216 0 R
-/Annots [ 1268 0 R 1269 0 R ]
+/Parent 1226 0 R
+/Annots [ 1278 0 R 1279 0 R ]
 >> endobj
-1268 0 obj <<
+1278 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [519.8432 268.1131 539.579 280.1727]
 /Subtype /Link
 /A << /S /GoTo /D (acache) >>
 >> endobj
-1269 0 obj <<
+1279 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [84.0431 256.1579 143.5361 268.2175]
 /Subtype /Link
 /A << /S /GoTo /D (acache) >>
 >> endobj
-1263 0 obj <<
-/D [1261 0 R /XYZ 85.0394 794.5015 null]
+1273 0 obj <<
+/D [1271 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 66 0 obj <<
-/D [1261 0 R /XYZ 85.0394 769.5949 null]
+/D [1271 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1264 0 obj <<
-/D [1261 0 R /XYZ 85.0394 574.3444 null]
+1274 0 obj <<
+/D [1271 0 R /XYZ 85.0394 574.3444 null]
 >> endobj
 70 0 obj <<
-/D [1261 0 R /XYZ 85.0394 574.3444 null]
+/D [1271 0 R /XYZ 85.0394 574.3444 null]
 >> endobj
-1265 0 obj <<
-/D [1261 0 R /XYZ 85.0394 540.5052 null]
+1275 0 obj <<
+/D [1271 0 R /XYZ 85.0394 540.5052 null]
 >> endobj
 74 0 obj <<
-/D [1261 0 R /XYZ 85.0394 447.7637 null]
+/D [1271 0 R /XYZ 85.0394 447.7637 null]
 >> endobj
-1266 0 obj <<
-/D [1261 0 R /XYZ 85.0394 410.3389 null]
+1276 0 obj <<
+/D [1271 0 R /XYZ 85.0394 410.3389 null]
 >> endobj
 78 0 obj <<
-/D [1261 0 R /XYZ 85.0394 348.7624 null]
+/D [1271 0 R /XYZ 85.0394 348.7624 null]
 >> endobj
-1267 0 obj <<
-/D [1261 0 R /XYZ 85.0394 311.223 null]
+1277 0 obj <<
+/D [1271 0 R /XYZ 85.0394 311.223 null]
 >> endobj
 82 0 obj <<
-/D [1261 0 R /XYZ 85.0394 189.9853 null]
+/D [1271 0 R /XYZ 85.0394 189.9853 null]
 >> endobj
-1270 0 obj <<
-/D [1261 0 R /XYZ 85.0394 156.0037 null]
+1280 0 obj <<
+/D [1271 0 R /XYZ 85.0394 156.0037 null]
 >> endobj
-1260 0 obj <<
-/Font << /F21 930 0 R /F22 953 0 R >>
+1270 0 obj <<
+/Font << /F21 938 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1274 0 obj <<
+1284 0 obj <<
 /Length 591       
 /Filter /FlateDecode
 >>
@@ -4597,27 +4616,27 @@ stream
 xÚ¥TKs›0¾ó+t3AÕ�tt’:3Nƒû˜4Ç()SŒ\ÀIóï+!°Iâž:³«}|ì~Ú…
 ÕºÕõ«3uE�ó»$�hô®ËZ«
¤iëâa׺BÿÚ*Æ‘]…#;`ÞþÒþ{ã¿¡0FLzX¦ñÐS�‘ŒÙ¾(Klô¡ða3?VþP%6endstream
 endobj
-1273 0 obj <<
+1283 0 obj <<
 /Type /Page
-/Contents 1274 0 R
-/Resources 1272 0 R
+/Contents 1284 0 R
+/Resources 1282 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1277 0 R
+/Parent 1287 0 R
 >> endobj
-1275 0 obj <<
-/D [1273 0 R /XYZ 56.6929 794.5015 null]
+1285 0 obj <<
+/D [1283 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 86 0 obj <<
-/D [1273 0 R /XYZ 56.6929 769.5949 null]
+/D [1283 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-1276 0 obj <<
-/D [1273 0 R /XYZ 56.6929 744.7247 null]
+1286 0 obj <<
+/D [1283 0 R /XYZ 56.6929 744.7247 null]
 >> endobj
-1272 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R >>
+1282 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1280 0 obj <<
+1290 0 obj <<
 /Length 1159      
 /Filter /FlateDecode
 >>
@@ -4630,45 +4649,45 @@ JxI1|«ÄR{}Ö8!S8ÆM§,ývrö‹çf¨qdü)G%§ÀÚÉ®×r›6H–¬Ú‹½‹…¿ðÃJNXV�„ÐO^nóëÅ¿_æ’£
 Ó–ÿ¼\g¥»ÜE
 ¾qÂôr�œº=ȘZ\
ö\FØ
ÿxd²ó‘ód¦·$4%9‡‹{¦úÃ9šfؼ!¼‚¦ÿH	ËI)xáõ8kØ;ߥo…­<©»çÃ¥ÛŽ›­>L/‰ÁÌ ²”Š,`îö$àžÇV”ðl×ØæÚ,˜Lá5]Ö·[öhLs&¾Ñ¡0ÌC/—U5U}hõö5¡æ^uº…®û]}á¦×=}»ž^êáý-Rb_ósoù _dð!AK"8�YXù½±é_Á£µ
 endobj
-1279 0 obj <<
+1289 0 obj <<
 /Type /Page
-/Contents 1280 0 R
-/Resources 1278 0 R
+/Contents 1290 0 R
+/Resources 1288 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1277 0 R
+/Parent 1287 0 R
 >> endobj
-1281 0 obj <<
-/D [1279 0 R /XYZ 85.0394 794.5015 null]
+1291 0 obj <<
+/D [1289 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 90 0 obj <<
-/D [1279 0 R /XYZ 85.0394 769.5949 null]
+/D [1289 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1282 0 obj <<
-/D [1279 0 R /XYZ 85.0394 575.896 null]
+1292 0 obj <<
+/D [1289 0 R /XYZ 85.0394 575.896 null]
 >> endobj
 94 0 obj <<
-/D [1279 0 R /XYZ 85.0394 529.2011 null]
+/D [1289 0 R /XYZ 85.0394 529.2011 null]
 >> endobj
-1283 0 obj <<
-/D [1279 0 R /XYZ 85.0394 492.9468 null]
+1293 0 obj <<
+/D [1289 0 R /XYZ 85.0394 492.9468 null]
 >> endobj
 98 0 obj <<
-/D [1279 0 R /XYZ 85.0394 492.9468 null]
+/D [1289 0 R /XYZ 85.0394 492.9468 null]
 >> endobj
-1284 0 obj <<
-/D [1279 0 R /XYZ 85.0394 466.0581 null]
+1294 0 obj <<
+/D [1289 0 R /XYZ 85.0394 466.0581 null]
 >> endobj
 102 0 obj <<
-/D [1279 0 R /XYZ 85.0394 201.2466 null]
+/D [1289 0 R /XYZ 85.0394 201.2466 null]
 >> endobj
-1285 0 obj <<
-/D [1279 0 R /XYZ 85.0394 170.5419 null]
+1295 0 obj <<
+/D [1289 0 R /XYZ 85.0394 170.5419 null]
 >> endobj
-1278 0 obj <<
-/Font << /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+1288 0 obj <<
+/Font << /F21 938 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1288 0 obj <<
+1298 0 obj <<
 /Length 1768      
 /Filter /FlateDecode
 >>
@@ -4682,41 +4701,41 @@ tèErÆ)LÌìÔ)ÂpÉ!è©n½ˆ4ï8Ky^ëéMšezºÈsk¿²å‘µΔk1…éÔ‹T©¦ô0j}z¬¬Ó%ÿn¿�ô¡�ô1µ
 ÊTˆiivíÚÔ�«×eΓ=5’´Š£.mÃU;GÝ©ÔE^à9�"–J�ØCàxy¥™Zÿqdkà“µ› jÝ
 Na>¤¯xÁã/jY»—|‘´7ŠÂ-Ý M¤³•PQŽŠ2Q£ýëq€:Ž¦­Ö÷£J\„¥r8�.ù ¬� "~AªíŪNAÕ1̃`àùFŒ!Mr¡äå‡~-zP©Ä¢VÊKu¦}?N[êÃ�FÓ=¦SYl‹3¼îb¿§”Cˆ¹Ê[öOÂ]Có¬ûœ„è�éÌEc½â°õbz|í/×<ÇG,„i¸Ï(ôY«•P=x¢ºù7Û£û_`#~›endstream
 endobj
-1287 0 obj <<
+1297 0 obj <<
 /Type /Page
-/Contents 1288 0 R
-/Resources 1286 0 R
+/Contents 1298 0 R
+/Resources 1296 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1277 0 R
-/Annots [ 1293 0 R ]
+/Parent 1287 0 R
+/Annots [ 1303 0 R ]
 >> endobj
-1293 0 obj <<
+1303 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [55.6967 61.5153 126.3509 73.5749]
 /Subtype /Link
 /A << /S /GoTo /D (rrset_ordering) >>
 >> endobj
-1289 0 obj <<
-/D [1287 0 R /XYZ 56.6929 794.5015 null]
+1299 0 obj <<
+/D [1297 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 106 0 obj <<
-/D [1287 0 R /XYZ 56.6929 372.6686 null]
+/D [1297 0 R /XYZ 56.6929 372.6686 null]
 >> endobj
-1290 0 obj <<
-/D [1287 0 R /XYZ 56.6929 334.1957 null]
+1300 0 obj <<
+/D [1297 0 R /XYZ 56.6929 334.1957 null]
 >> endobj
-1291 0 obj <<
-/D [1287 0 R /XYZ 56.6929 266.1213 null]
+1301 0 obj <<
+/D [1297 0 R /XYZ 56.6929 266.1213 null]
 >> endobj
-1292 0 obj <<
-/D [1287 0 R /XYZ 56.6929 254.1661 null]
+1302 0 obj <<
+/D [1297 0 R /XYZ 56.6929 254.1661 null]
 >> endobj
-1286 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F21 930 0 R /F22 953 0 R >>
+1296 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F21 938 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1297 0 obj <<
+1307 0 obj <<
 /Length 2693      
 /Filter /FlateDecode
 >>
@@ -4737,45 +4756,45 @@ v‚_Ñ&-Ë÷
–Ðùs’LŒ“é¨úc­º¯ç½¿ªîzWnBˇ¢—ålÊOøQ‚x#£cÇl»„“¬ðܯb¼o�càÁ
 p¬xJ´§¹�=vrB þ²¡ðÙ£,ˆ†—
 N8çŒd¬`—·Àvÿ¤?í.îü›¾ü2õÃ%0
'üµµQ†Ìè‘2ÂÒTúÄ„íû&·×�ˆã<dÏÄŸ¼÷?²œÿ¿Gd„çùÌ9#×çŒ,ñJiõ‹©âþ^.5ÿ+Lendstream
 endobj
-1296 0 obj <<
+1306 0 obj <<
 /Type /Page
-/Contents 1297 0 R
-/Resources 1295 0 R
+/Contents 1307 0 R
+/Resources 1305 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1277 0 R
+/Parent 1287 0 R
 >> endobj
-1298 0 obj <<
-/D [1296 0 R /XYZ 85.0394 794.5015 null]
+1308 0 obj <<
+/D [1306 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 110 0 obj <<
-/D [1296 0 R /XYZ 85.0394 769.5949 null]
+/D [1306 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1299 0 obj <<
-/D [1296 0 R /XYZ 85.0394 744.949 null]
+1309 0 obj <<
+/D [1306 0 R /XYZ 85.0394 744.949 null]
 >> endobj
 114 0 obj <<
-/D [1296 0 R /XYZ 85.0394 744.949 null]
+/D [1306 0 R /XYZ 85.0394 744.949 null]
 >> endobj
-1300 0 obj <<
-/D [1296 0 R /XYZ 85.0394 721.0357 null]
+1310 0 obj <<
+/D [1306 0 R /XYZ 85.0394 721.0357 null]
 >> endobj
 118 0 obj <<
-/D [1296 0 R /XYZ 85.0394 672.3079 null]
+/D [1306 0 R /XYZ 85.0394 672.3079 null]
 >> endobj
-1252 0 obj <<
-/D [1296 0 R /XYZ 85.0394 647.0603 null]
+1262 0 obj <<
+/D [1306 0 R /XYZ 85.0394 647.0603 null]
 >> endobj
 122 0 obj <<
-/D [1296 0 R /XYZ 85.0394 136.5325 null]
+/D [1306 0 R /XYZ 85.0394 136.5325 null]
 >> endobj
-1304 0 obj <<
-/D [1296 0 R /XYZ 85.0394 113.5963 null]
+1314 0 obj <<
+/D [1306 0 R /XYZ 85.0394 113.5963 null]
 >> endobj
-1295 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F53 1303 0 R >>
+1305 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1307 0 obj <<
+1317 0 obj <<
 /Length 3556      
 /Filter /FlateDecode
 >>
@@ -4793,50 +4812,50 @@ r¹Lœ±‰
ÕŒM8*ƒÉªû:¢ÿÀ¹ÆÀ$$ë
 ?¡ñ¡9êb‹÷5KSv–Õ­%lŸêµ“Ê‚„„úÛ3'e€ñUi}q�&Ë—þf€Ï÷ô•
 }U·fÃSÕû–æxÚ`°Àn¿ã8Ü[<´~‡Ûêž~^7ý#©,cíwœÛ�'Tr‚¦+ïwôÍ/ô;‚eèwS�,ú�õCú‘÷Cz¼4kÓ^HAÀD/¤ÇÝyÖ/#׃öþ68†ÌðËe@Œ«Ȳ‹ùžMÕ~4ÞÓ‚-¦<ÄBÑZC]ê‹RØï÷
:Åž}å°4ì·TÅ–…%Ó_·e‡>7QË—ýkþ8Éq'¿â±ÄÌ&öÿT`âúŸ "—ø;_ü¿Vý¿ éËJM}oÌ´¥
 endobj
-1306 0 obj <<
+1316 0 obj <<
 /Type /Page
-/Contents 1307 0 R
-/Resources 1305 0 R
+/Contents 1317 0 R
+/Resources 1315 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1277 0 R
-/Annots [ 1312 0 R 1313 0 R 1314 0 R 1315 0 R ]
+/Parent 1287 0 R
+/Annots [ 1322 0 R 1323 0 R 1324 0 R 1325 0 R ]
 >> endobj
-1312 0 obj <<
+1322 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [219.3839 342.7466 281.1025 354.8062]
 /Subtype /Link
 /A << /S /GoTo /D (options) >>
 >> endobj
-1313 0 obj <<
+1323 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [401.2123 288.8914 470.1877 300.951]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_policies) >>
 >> endobj
-1314 0 obj <<
+1324 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [243.8464 235.0361 306.1963 247.0958]
 /Subtype /Link
 /A << /S /GoTo /D (options) >>
 >> endobj
-1315 0 obj <<
+1325 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [368.2917 181.1809 436.8984 193.2405]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_policies) >>
 >> endobj
-1308 0 obj <<
-/D [1306 0 R /XYZ 56.6929 794.5015 null]
+1318 0 obj <<
+/D [1316 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1305 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F41 1208 0 R /F53 1303 0 R /F22 953 0 R /F14 956 0 R /F48 1228 0 R /F55 1311 0 R >>
+1315 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F41 1218 0 R /F53 1313 0 R /F22 961 0 R /F14 964 0 R /F48 1238 0 R /F55 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1320 0 obj <<
+1330 0 obj <<
 /Length 3160      
 /Filter /FlateDecode
 >>
@@ -4857,21 +4876,21 @@ R37µ1k˜Õl‹âeï^:®üU@óà~‰§yf‚—¬þëÔj0DJÇØè†R‘zZ7!�õ@7E(ˆc™ÔýSsRc@À¥RŸ£±HC¾¹/
 /'¥TpmkOÔ–”?ŸÒ¶‰¬™h"‘EÎæYÉÀ½!e¸fƒÙŒ
:*ëh§ª‚X뢱‘Ÿ$_dkê’­qÈ6#²y‰Zª±Dýd’'X–}‘ÈÖ„L\ICm
ß�àçíæÉlé
é©
 �ïÑäCà(üšã{d3Žï¨ˆÑ¢ùÇŸe sü!ßç€N{îsÞ%ûЙAß9~AÉ¢tÈ–ï­ƒ#	98
 endobj
-1319 0 obj <<
+1329 0 obj <<
 /Type /Page
-/Contents 1320 0 R
-/Resources 1318 0 R
+/Contents 1330 0 R
+/Resources 1328 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1277 0 R
+/Parent 1287 0 R
 >> endobj
-1321 0 obj <<
-/D [1319 0 R /XYZ 85.0394 794.5015 null]
+1331 0 obj <<
+/D [1329 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1318 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F48 1228 0 R /F55 1311 0 R /F14 956 0 R /F41 1208 0 R >>
+1328 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F48 1238 0 R /F55 1321 0 R /F14 964 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1324 0 obj <<
+1334 0 obj <<
 /Length 3939      
 /Filter /FlateDecode
 >>
@@ -4892,29 +4911,29 @@ X®¯yÏä÷¹Ñfág°»
æôµ+èJ07pæ‘à�x uFÐZ©	zб9
 �Ζ¥0u-z²__RãCPsÄË‘ú¸
 6§ýˆŸ:cϘ`êèó<ˆ—	—Y°Žã�óÍÙé§#y2÷Ù¿þËÙO
áÏjÛý/
ãJÀÒ¤Ö'>¨¹Æ“<é…çâhå<aÅÌÒÿ‹jw¢endstream
 endobj
-1323 0 obj <<
+1333 0 obj <<
 /Type /Page
-/Contents 1324 0 R
-/Resources 1322 0 R
+/Contents 1334 0 R
+/Resources 1332 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1327 0 R
-/Annots [ 1326 0 R ]
+/Parent 1337 0 R
+/Annots [ 1336 0 R ]
 >> endobj
-1326 0 obj <<
+1336 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [91.7912 64.1653 148.0099 73.3807]
 /Subtype /Link
 /A << /S /GoTo /D (controls_statement_definition_and_usage) >>
 >> endobj
-1325 0 obj <<
-/D [1323 0 R /XYZ 56.6929 794.5015 null]
+1335 0 obj <<
+/D [1333 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1322 0 obj <<
-/Font << /F37 1018 0 R /F48 1228 0 R /F22 953 0 R /F21 930 0 R /F55 1311 0 R /F53 1303 0 R /F41 1208 0 R >>
+1332 0 obj <<
+/Font << /F37 1026 0 R /F48 1238 0 R /F22 961 0 R /F21 938 0 R /F55 1321 0 R /F53 1313 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1331 0 obj <<
+1341 0 obj <<
 /Length 3214      
 /Filter /FlateDecode
 >>
@@ -4935,33 +4954,33 @@ _�á—À4‘Ï—û�K<›¾ö˜]U>Áç7KTG§XÆf[,Û•LËC³XsxÕ±Gù»óÂ
 µ|óÅÞØYˆ"%!‰5îîíA©,—<@Æ€ÝØ>*ìpßîííŽAõ¡ó•û\Ô]lå*¨~é�鬪î¶.îÃ�F¼ÀðÅhwÛ6+_q>(öèràd´ÕD®3ÅMªœš\£
 ûùÿ'&róœä�+ÿ"ûsJh/ö©†xËY¦}&tøÇ42{RQOýÜðï@ì­kÍÒzÀ‰rÝ3ð­ˆAùþ†ÿËy¨éÿH;²endstream
 endobj
-1330 0 obj <<
+1340 0 obj <<
 /Type /Page
-/Contents 1331 0 R
-/Resources 1329 0 R
+/Contents 1341 0 R
+/Resources 1339 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1327 0 R
+/Parent 1337 0 R
 >> endobj
-1332 0 obj <<
-/D [1330 0 R /XYZ 85.0394 794.5015 null]
+1342 0 obj <<
+/D [1340 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 126 0 obj <<
-/D [1330 0 R /XYZ 85.0394 149.8567 null]
+/D [1340 0 R /XYZ 85.0394 149.8567 null]
 >> endobj
-1333 0 obj <<
-/D [1330 0 R /XYZ 85.0394 122.5522 null]
+1343 0 obj <<
+/D [1340 0 R /XYZ 85.0394 122.5522 null]
 >> endobj
-1334 0 obj <<
-/D [1330 0 R /XYZ 85.0394 93.0348 null]
+1344 0 obj <<
+/D [1340 0 R /XYZ 85.0394 93.0348 null]
 >> endobj
-1335 0 obj <<
-/D [1330 0 R /XYZ 85.0394 81.0797 null]
+1345 0 obj <<
+/D [1340 0 R /XYZ 85.0394 81.0797 null]
 >> endobj
-1329 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F41 1208 0 R /F21 930 0 R /F48 1228 0 R >>
+1339 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F41 1218 0 R /F21 938 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1338 0 obj <<
+1348 0 obj <<
 /Length 488       
 /Filter /FlateDecode
 >>
@@ -4972,21 +4991,21 @@ k<36…5Ø*l4À�ƒb‡`¼Ô|YØéh(å9ß=fäì©6äÿ±l ;hšM9hÑnóìÏžå¢2Éãç²
 åÃ�òa=øµjonËÙ}>}«ÚÙý¼
 Ê__aWª
Âã•R$`Í¢tã©sËkô9 Cö€Ç(@ÄÚa£qñgƒµðŽf°=ŽÝÛ�|
{Mçk±J±5£W¹a	¶ïν;ÔŽrcçž�x©:‰Ý4­:ö¹û潓›B0Ýn0À2Jê³ÄZº
íÞ³ƒù&«Eý7ô¢�˜endstream
 endobj
-1337 0 obj <<
+1347 0 obj <<
 /Type /Page
-/Contents 1338 0 R
-/Resources 1336 0 R
+/Contents 1348 0 R
+/Resources 1346 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1327 0 R
+/Parent 1337 0 R
 >> endobj
-1339 0 obj <<
-/D [1337 0 R /XYZ 56.6929 794.5015 null]
+1349 0 obj <<
+/D [1347 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1336 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R >>
+1346 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1343 0 obj <<
+1353 0 obj <<
 /Length 2407      
 /Filter /FlateDecode
 >>
@@ -5005,29 +5024,29 @@ SDôçÃÃ@x´»'¡w˜+
"1f¼ù¤È,Üì£�ù™0Ž–ïé3€>5áwâ„K¤`Á.ä›&‘¿——0*«í*
{ÿvÖœ¦º
 ΄£Màõ¿|ŒÜHÖôA-08×I@t98ÔÌÁˆÏùMã혽B†·Ã�³å`æp„²Þ"°q—o—^ÇãsÇM´^„|UÀ1øXžÆÛŒØ<âr“ü–«üû¦GŒ—¼{÷Ö-m»ðhŽ|€Jä¹ùç_4’ÏŸï>~xEë·°•z…)AÃK,¹pÝ׶�½ÿ¬&TdÍ9³à¤Õ‚w:|d…êäÛ£dZK&œÈªVŸ±*Œ£�_KSÐ=5m8#<ÌÁ,–JÍ#D±”îI—€-`ñcóÝ�Ó|Ä—×Ç:—üK³›”Œüs
 ý1àÖº@TÿyÀp�.ª…aGØ…~æII¨L>óznvFš¥Â¦
ˆBE	D¨3SÏ>º^÷µµ^endstream
 endobj
-1342 0 obj <<
+1352 0 obj <<
 /Type /Page
-/Contents 1343 0 R
-/Resources 1341 0 R
+/Contents 1353 0 R
+/Resources 1351 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1327 0 R
-/Annots [ 1347 0 R 1348 0 R 1356 0 R ]
+/Parent 1337 0 R
+/Annots [ 1357 0 R 1358 0 R 1366 0 R ]
 >> endobj
-1340 0 obj <<
+1350 0 obj <<
 /Type /XObject
 /Subtype /Form
 /FormType 1
 /PTEX.FileName (/usr/local/share/db2latex/xsl/figures/note.pdf)
 /PTEX.PageNumber 1
-/PTEX.InfoDict 1357 0 R 
+/PTEX.InfoDict 1367 0 R 
 /Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
 /BBox [0.00000000 0.00000000 27.00000000 27.00000000]
 /Resources <<
 /ProcSet [ /PDF ]
 /ExtGState <<
-/R4 1358 0 R
+/R4 1368 0 R
 >>>>
-/Length 1359 0 R
+/Length 1369 0 R
 /Filter /FlateDecode
 >>
 stream
@@ -5040,12 +5059,12 @@ q�ª„Ñ«ò�^ÿï>‹«>÷—
.13×…Óƒ!¶3¢SËAÕ”ih¥Å¨Š^…(€<Îm䦽ªšÛÆlLÊâ³ò7Ù
 n*Œ1½÷¨¾x¥Æˆpîâ‹
&Xî
Ãœ§³±è\íD¤ß�ä0}#XŒûž˜‹¸À>#^V°¡|2Îi‰9ÊÎ�r)`˜¢Xh¡Ò& „hb—H°Œe"Ãê
 þrÓGçX5¾ûû8‡´ÕªOª«t–Ô³$Ây°‰—BÒ›ÀÄ5
©/¨�vp�÷o`kA“ôr±ñœÓ4N.4Žæ
 endobj
-1357 0 obj
+1367 0 obj
 <<
 /Producer (AFPL Ghostscript 6.50)
 >>
 endobj
-1358 0 obj
+1368 0 obj
 <<
 /Type /ExtGState
 /Name /R4
@@ -5055,57 +5074,57 @@ endobj
 /SA true
 >>
 endobj
-1359 0 obj
+1369 0 obj
 1049
 endobj
-1347 0 obj <<
+1357 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [470.3398 467.2776 539.579 479.3373]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1348 0 obj <<
+1358 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [316.7164 455.3224 385.3363 467.3821]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1356 0 obj <<
+1366 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [304.6433 163.6578 373.3153 175.7175]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_policies) >>
 >> endobj
-1344 0 obj <<
-/D [1342 0 R /XYZ 85.0394 794.5015 null]
+1354 0 obj <<
+/D [1352 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 130 0 obj <<
-/D [1342 0 R /XYZ 85.0394 769.5949 null]
+/D [1352 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1345 0 obj <<
-/D [1342 0 R /XYZ 85.0394 576.3463 null]
+1355 0 obj <<
+/D [1352 0 R /XYZ 85.0394 576.3463 null]
 >> endobj
 134 0 obj <<
-/D [1342 0 R /XYZ 85.0394 576.3463 null]
+/D [1352 0 R /XYZ 85.0394 576.3463 null]
 >> endobj
-1346 0 obj <<
-/D [1342 0 R /XYZ 85.0394 533.5444 null]
+1356 0 obj <<
+/D [1352 0 R /XYZ 85.0394 533.5444 null]
 >> endobj
 138 0 obj <<
-/D [1342 0 R /XYZ 85.0394 299.6823 null]
+/D [1352 0 R /XYZ 85.0394 299.6823 null]
 >> endobj
-1355 0 obj <<
-/D [1342 0 R /XYZ 85.0394 263.0631 null]
+1365 0 obj <<
+/D [1352 0 R /XYZ 85.0394 263.0631 null]
 >> endobj
-1341 0 obj <<
-/Font << /F21 930 0 R /F22 953 0 R /F62 1351 0 R /F63 1354 0 R /F48 1228 0 R /F41 1208 0 R >>
-/XObject << /Im2 1340 0 R >>
+1351 0 obj <<
+/Font << /F21 938 0 R /F22 961 0 R /F62 1361 0 R /F63 1364 0 R /F48 1238 0 R /F41 1218 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1364 0 obj <<
+1374 0 obj <<
 /Length 3579      
 /Filter /FlateDecode
 >>
@@ -5123,54 +5142,54 @@ j=§’úq’IÇ¥kn5� .
'·JíË4¶°AmÞò\y0SS•:5×R*ô5ãOÀ!O ´	.–d¬‡Ò,üÔïÖ ¡¢¥hÆc
 ´Úl8<ëfXžŒ�	(Ñq–zxûȦÐO
žüö^þ‡9žï
Ä'“’G³¡ÄÝ?õ‘³�ŽÞj¶š
%&êÀ*½ñâ Wð]Gjä]$’cä„D"é€	Fo
ŸH¬a™ú™®¼Àè™2i+ê‚ó1/=Ó’	Ü|ꊞW°Òâ“I¿|À)%í6N”+qì­xfß¹¥(wF$Œà	ÃpbrÁÃÁÄ'¸M¾
 Gg\ªà
8"À`xbílgC‹›d¬.â)h¨Ký©§¢
cDߣɑb	ÃЯ¿Tš*%„$¼Â
î`ªˆ	™�qÄg�ylþ;
 endobj
-1363 0 obj <<
+1373 0 obj <<
 /Type /Page
-/Contents 1364 0 R
-/Resources 1362 0 R
+/Contents 1374 0 R
+/Resources 1372 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1327 0 R
-/Annots [ 1368 0 R 1369 0 R ]
+/Parent 1337 0 R
+/Annots [ 1378 0 R 1379 0 R ]
 >> endobj
-1368 0 obj <<
+1378 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [464.1993 393.2115 511.2325 405.2711]
 /Subtype /Link
 /A << /S /GoTo /D (proposed_standards) >>
 >> endobj
-1369 0 obj <<
+1379 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [55.6967 382.2725 105.4 393.3159]
 /Subtype /Link
 /A << /S /GoTo /D (proposed_standards) >>
 >> endobj
-1365 0 obj <<
-/D [1363 0 R /XYZ 56.6929 794.5015 null]
+1375 0 obj <<
+/D [1373 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 142 0 obj <<
-/D [1363 0 R /XYZ 56.6929 769.5949 null]
+/D [1373 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-1366 0 obj <<
-/D [1363 0 R /XYZ 56.6929 749.4437 null]
+1376 0 obj <<
+/D [1373 0 R /XYZ 56.6929 749.4437 null]
 >> endobj
 146 0 obj <<
-/D [1363 0 R /XYZ 56.6929 458.7525 null]
+/D [1373 0 R /XYZ 56.6929 458.7525 null]
 >> endobj
-1367 0 obj <<
-/D [1363 0 R /XYZ 56.6929 425.4132 null]
+1377 0 obj <<
+/D [1373 0 R /XYZ 56.6929 425.4132 null]
 >> endobj
 150 0 obj <<
-/D [1363 0 R /XYZ 56.6929 270.5184 null]
+/D [1373 0 R /XYZ 56.6929 270.5184 null]
 >> endobj
-1370 0 obj <<
-/D [1363 0 R /XYZ 56.6929 234.9696 null]
+1380 0 obj <<
+/D [1373 0 R /XYZ 56.6929 234.9696 null]
 >> endobj
-1362 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F55 1311 0 R /F48 1228 0 R /F39 1151 0 R >>
+1372 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F55 1321 0 R /F48 1238 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1374 0 obj <<
+1384 0 obj <<
 /Length 3172      
 /Filter /FlateDecode
 >>
@@ -5187,35 +5206,35 @@ xÚå]sãÆíÝ¿Bo¡3'v¿¹LŸ®9§¹Lr¹äÜ6Ó$3¥%Þ™=™TDÚ:ç×Xì’KŠ’ìfúÔуö°
 CEÕ0´2ÂE¥ϦD1ÑÎ�ÊNSí¡ÉNÒv+3&û-¤�thÊYÈ6ÙÈ[NÚã3õˆÔ©6Lž¯ñefõj.õÌ‚NgÆ5þ1
J“f"³g4A�Ð`€:¯ÁST#
NÉÎk0&û¿Ôà™~ ÏŒ}Fùü”# ÌÇ-Æ㊧Q÷œ"#¨ŠPçyŠj¤È)ÙyEÆdŸ®Èw>B8*+µ<øIYÅPÇeÕC�•ÕIªƒ¬ÈÎÊjDöjè)MjÇðÞox8Ž”£igc¡ÜKùдΘ1ãóë!G>*ÿcYÛ“B7?¿1gtA�ÐQ€:¯£ST#MÉÎë(&ûÿZ¸Â¯¡Ä™êb¨Pç5xŠj¤Á)Ùy
ÆdÏß2Ð(}’t^‹Z¤�áeOÒ¢yvTù/µ¸XJ ˜³<Ÿ\ö²ÿD!SÔïË”ÿNKEݘôµ4þ�+®SVŸ…Îb¦ü—|n¸÷Kÿv¯Âp´.ÛÕ®º¡¯3€ÔMó€_
A=’¼iº2 *º0
 L…ÿ1NÌÑlyÙó¨G¯‰ÿ<©EFo�c§wòæPdNŠ-Z|lîwçAQÙQ†Î_[–S“V «¤]púÒô1'mî>,hðcdÜ=ü2~àиñ¢ ÞÅ_ÁÉ”pã>3sp¿Ð9¦¸¢WÄÒ²Tkk¦oâð4©ßÇ‚?QÀqâw¬3|³þÕ?ü¹ìàØÔoÖŠy	HfR+ò,0…g<tjýwµ‡¬ÿíp~endstream
 endobj
-1373 0 obj <<
+1383 0 obj <<
 /Type /Page
-/Contents 1374 0 R
-/Resources 1372 0 R
+/Contents 1384 0 R
+/Resources 1382 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1327 0 R
-/Annots [ 1377 0 R ]
+/Parent 1337 0 R
+/Annots [ 1387 0 R ]
 >> endobj
-1377 0 obj <<
+1387 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [417.8476 110.3446 466.5943 122.4042]
 /Subtype /Link
 /A << /S /GoTo /D (sample_configuration) >>
 >> endobj
-1375 0 obj <<
-/D [1373 0 R /XYZ 85.0394 794.5015 null]
+1385 0 obj <<
+/D [1383 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 154 0 obj <<
-/D [1373 0 R /XYZ 85.0394 769.5949 null]
+/D [1383 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1376 0 obj <<
-/D [1373 0 R /XYZ 85.0394 749.3028 null]
+1386 0 obj <<
+/D [1383 0 R /XYZ 85.0394 749.3028 null]
 >> endobj
-1372 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R /F41 1208 0 R /F14 956 0 R >>
+1382 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R /F41 1218 0 R /F14 964 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1380 0 obj <<
+1390 0 obj <<
 /Length 735       
 /Filter /FlateDecode
 >>
@@ -5225,21 +5244,21 @@ xÚÅWMs›0½ó+˜œà Y€a|r§m¦“IcÚKšÅrÊG�ïɯ@� ܤNÓÉL‚–§ÝÕ{om›Hü`Óõ �ÀtvÍ
 Ư/t-lvWo{‡ Ý‚Zr*4ÐÂ'ºzªë"ÊÖ)“ÏQšæ7 äѪX2.c?�‹V¹¢€‰%Ö‘ ÛºÑr%¶õÄÓÈYQò$.åêòŠñ»M_qÌ
 -k²lúðÌ´“g.û‹F8‹¯x!>÷d[z!¼§Â@ëcýè4Í„Y” ÷B	]­:^#öŠ¤d²Û:Œól¯mGµ©s€ònÝ©¥¥v™¨†ö²Q¿ÈV9¹2ÏÔ$‰<*“kÖ(–§We£@åÚ§meg@ûšÀ-Vy[ãm™ž

­úÏZ�-Š4RÜõ]�u® /uy抺ԟLQŒú5´ã"=6ôeD·Òü_Æo¤ð¶Áï
°Êù�^7½M…É»ÍÒî³óêÑéÍÀKˆÅ»À¯d÷ÿMÞMÝ5šº°ºûj.½¨cç+öÓÎRß'Íí™�Ö홌}èø"ɦ©ªsì÷:Wwñ~ë¿
ÈUendstream
 endobj
-1379 0 obj <<
+1389 0 obj <<
 /Type /Page
-/Contents 1380 0 R
-/Resources 1378 0 R
+/Contents 1390 0 R
+/Resources 1388 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
+/Parent 1392 0 R
 >> endobj
-1381 0 obj <<
-/D [1379 0 R /XYZ 56.6929 794.5015 null]
+1391 0 obj <<
+/D [1389 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1378 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R >>
+1388 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1385 0 obj <<
+1395 0 obj <<
 /Length 1364      
 /Filter /FlateDecode
 >>
@@ -5251,27 +5270,27 @@ R/JýÄŠïÛ@‰2/ü@ƒrý¥—]#jŠø‹Ø­P}Õ6ÄØ´ª&?AFÉîNvDçmó�1ý‚±|ò‰Iæ¸�ï±ü@c";1cóª!
 ÑKLæ—Ä£´ïéã�Ó©
 ñ�¦lÌ.Ù´C]çÚ¦§‚7nœ¿\ê}Ÿ¤fß'Ùƒzä’£4�>U¹„J9$iè‰}óÆ5	ÃÆ�ž9ò'+eÆF
z{ãq’W°»
Š8ƒê&' €n¿ëÛu'vre‚íÙD¾-�Dv¸ºüò“ôá
&^�¦¾ýµ°ØKý,�B˜yvêùáíú­ëÿ
¨6Eendstream
 endobj
-1384 0 obj <<
+1394 0 obj <<
 /Type /Page
-/Contents 1385 0 R
-/Resources 1383 0 R
+/Contents 1395 0 R
+/Resources 1393 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
+/Parent 1392 0 R
 >> endobj
-1386 0 obj <<
-/D [1384 0 R /XYZ 85.0394 794.5015 null]
+1396 0 obj <<
+/D [1394 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 158 0 obj <<
-/D [1384 0 R /XYZ 85.0394 223.4026 null]
+/D [1394 0 R /XYZ 85.0394 223.4026 null]
 >> endobj
-1387 0 obj <<
-/D [1384 0 R /XYZ 85.0394 185.2496 null]
+1397 0 obj <<
+/D [1394 0 R /XYZ 85.0394 185.2496 null]
 >> endobj
-1383 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F41 1208 0 R /F21 930 0 R >>
+1393 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F41 1218 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1390 0 obj <<
+1400 0 obj <<
 /Length 2265      
 /Filter /FlateDecode
 >>
@@ -5283,51 +5302,51 @@ Nƽ“š2:Š�`
 €u¾}¤1¡
 / ‚3ÉÝýsÑÿdiÙendstream
 endobj
-1389 0 obj <<
+1399 0 obj <<
 /Type /Page
-/Contents 1390 0 R
-/Resources 1388 0 R
+/Contents 1400 0 R
+/Resources 1398 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
+/Parent 1392 0 R
 >> endobj
-1391 0 obj <<
-/D [1389 0 R /XYZ 56.6929 794.5015 null]
+1401 0 obj <<
+/D [1399 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 162 0 obj <<
-/D [1389 0 R /XYZ 56.6929 726.8027 null]
+/D [1399 0 R /XYZ 56.6929 726.8027 null]
 >> endobj
-1392 0 obj <<
-/D [1389 0 R /XYZ 56.6929 697.6944 null]
+1402 0 obj <<
+/D [1399 0 R /XYZ 56.6929 697.6944 null]
 >> endobj
 166 0 obj <<
-/D [1389 0 R /XYZ 56.6929 648.8841 null]
+/D [1399 0 R /XYZ 56.6929 648.8841 null]
 >> endobj
-1393 0 obj <<
-/D [1389 0 R /XYZ 56.6929 624.769 null]
+1403 0 obj <<
+/D [1399 0 R /XYZ 56.6929 624.769 null]
 >> endobj
 170 0 obj <<
-/D [1389 0 R /XYZ 56.6929 472.4047 null]
+/D [1399 0 R /XYZ 56.6929 472.4047 null]
 >> endobj
-1394 0 obj <<
-/D [1389 0 R /XYZ 56.6929 448.2896 null]
+1404 0 obj <<
+/D [1399 0 R /XYZ 56.6929 448.2896 null]
 >> endobj
 174 0 obj <<
-/D [1389 0 R /XYZ 56.6929 356.0575 null]
+/D [1399 0 R /XYZ 56.6929 356.0575 null]
 >> endobj
-1395 0 obj <<
-/D [1389 0 R /XYZ 56.6929 324.2991 null]
+1405 0 obj <<
+/D [1399 0 R /XYZ 56.6929 324.2991 null]
 >> endobj
 178 0 obj <<
-/D [1389 0 R /XYZ 56.6929 275.4888 null]
+/D [1399 0 R /XYZ 56.6929 275.4888 null]
 >> endobj
-1396 0 obj <<
-/D [1389 0 R /XYZ 56.6929 246.3805 null]
+1406 0 obj <<
+/D [1399 0 R /XYZ 56.6929 246.3805 null]
 >> endobj
-1388 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R /F39 1151 0 R /F48 1228 0 R >>
+1398 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R /F39 1161 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1399 0 obj <<
+1409 0 obj <<
 /Length 2935      
 /Filter /FlateDecode
 >>
@@ -5348,53 +5367,53 @@ u?ðÉÉ“L†‡ÚÙÈ(��ÃÃѾaÄG8|3ô{.ºc¢xzá¡^>A_¯¸Á»{Ê=˜oj$¼›
 ò-?ÎCño_iòvËõT‚du¹|Hyž¿ª1¾ð¤ Ká�$î´ô‘…»‚H½R”hcð|æB±­=„” Wào8¦Í9}‚Aìie:l5œÑJ"eò£Ðú™›g 1O•Ñ/žÝ©tôÎç'ù‘‘ÉŽŒLîo*ÔØ»ù¤eø{”Ljeñðflðe]åÉø
 �Ÿˆ_–œœž/Ëâ÷âñÌCysI/6ÝÑW‰}wüɶ¬6Uï?J„@�>Žù콟㿇­™+Šü¥n÷�ìUôÜ¿,$ÐÖN½G¨!Mÿ¿ÿypø«…K#›eÏ<lÀýŠ2“§ž)„Òèc·¿(œ²þ?G°±endstream
 endobj
-1398 0 obj <<
+1408 0 obj <<
 /Type /Page
-/Contents 1399 0 R
-/Resources 1397 0 R
+/Contents 1409 0 R
+/Resources 1407 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
-/Annots [ 1403 0 R ]
+/Parent 1392 0 R
+/Annots [ 1413 0 R ]
 >> endobj
-1403 0 obj <<
+1413 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [101.3082 379.428 169.9802 391.3282]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_policies) >>
 >> endobj
-1400 0 obj <<
-/D [1398 0 R /XYZ 85.0394 794.5015 null]
+1410 0 obj <<
+/D [1408 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 182 0 obj <<
-/D [1398 0 R /XYZ 85.0394 769.5949 null]
+/D [1408 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1401 0 obj <<
-/D [1398 0 R /XYZ 85.0394 749.2913 null]
+1411 0 obj <<
+/D [1408 0 R /XYZ 85.0394 749.2913 null]
 >> endobj
 186 0 obj <<
-/D [1398 0 R /XYZ 85.0394 546.785 null]
+/D [1408 0 R /XYZ 85.0394 546.785 null]
 >> endobj
-1402 0 obj <<
-/D [1398 0 R /XYZ 85.0394 519.0032 null]
+1412 0 obj <<
+/D [1408 0 R /XYZ 85.0394 519.0032 null]
 >> endobj
 190 0 obj <<
-/D [1398 0 R /XYZ 85.0394 364.477 null]
+/D [1408 0 R /XYZ 85.0394 364.477 null]
 >> endobj
-1404 0 obj <<
-/D [1398 0 R /XYZ 85.0394 339.5007 null]
+1414 0 obj <<
+/D [1408 0 R /XYZ 85.0394 339.5007 null]
 >> endobj
 194 0 obj <<
-/D [1398 0 R /XYZ 85.0394 175.6792 null]
+/D [1408 0 R /XYZ 85.0394 175.6792 null]
 >> endobj
-1405 0 obj <<
-/D [1398 0 R /XYZ 85.0394 143.0963 null]
+1415 0 obj <<
+/D [1408 0 R /XYZ 85.0394 143.0963 null]
 >> endobj
-1397 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F39 1151 0 R /F14 956 0 R >>
+1407 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F39 1161 0 R /F14 964 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1408 0 obj <<
+1418 0 obj <<
 /Length 3227      
 /Filter /FlateDecode
 >>
@@ -5413,39 +5432,39 @@ vDw’§Eá£ÐÕ&â,
 /\øŽó8«úÁjÜ(,ÿñÃ=�½•8 «þ
XÒЙv¦ò
sð	\}6óiÁ@È»Ÿ¾û¥ü%Èã;VÅ—A.T¥föµ4ó$N井¯™�QqfÂWCd
 <Å^Ÿ"ßX=³°ŸDáS¢“+
(}€¦þº7ILç©ð¯¿`yZÐ÷+/a´~¨EJG:š3&<¯§væa´üP„ÁNr9M|zvÜÎî!}Ì3�-%Üeàñ³3×>e~æfC‚™Šd�¹Õt0øè?ü¶ÏŸ,|(þ̯;”Žñ'+¿Å!}þ¿ùqúÉKšÇʹþ£™›85°	å>µÉg”ûŸˆ<'ý¿w€=endstream
 endobj
-1407 0 obj <<
+1417 0 obj <<
 /Type /Page
-/Contents 1408 0 R
-/Resources 1406 0 R
+/Contents 1418 0 R
+/Resources 1416 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
+/Parent 1392 0 R
 >> endobj
-1409 0 obj <<
-/D [1407 0 R /XYZ 56.6929 794.5015 null]
+1419 0 obj <<
+/D [1417 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 198 0 obj <<
-/D [1407 0 R /XYZ 56.6929 678.9507 null]
+/D [1417 0 R /XYZ 56.6929 678.9507 null]
 >> endobj
-1410 0 obj <<
-/D [1407 0 R /XYZ 56.6929 644.5195 null]
+1420 0 obj <<
+/D [1417 0 R /XYZ 56.6929 644.5195 null]
 >> endobj
 202 0 obj <<
-/D [1407 0 R /XYZ 56.6929 514.5361 null]
+/D [1417 0 R /XYZ 56.6929 514.5361 null]
 >> endobj
-1411 0 obj <<
-/D [1407 0 R /XYZ 56.6929 481.3387 null]
+1421 0 obj <<
+/D [1417 0 R /XYZ 56.6929 481.3387 null]
 >> endobj
 206 0 obj <<
-/D [1407 0 R /XYZ 56.6929 279.5586 null]
+/D [1417 0 R /XYZ 56.6929 279.5586 null]
 >> endobj
-1412 0 obj <<
-/D [1407 0 R /XYZ 56.6929 251.1623 null]
+1422 0 obj <<
+/D [1417 0 R /XYZ 56.6929 251.1623 null]
 >> endobj
-1406 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F39 1151 0 R /F41 1208 0 R /F48 1228 0 R >>
+1416 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F39 1161 0 R /F41 1218 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1415 0 obj <<
+1425 0 obj <<
 /Length 3255      
 /Filter /FlateDecode
 >>
@@ -5462,33 +5481,33 @@ dlVÕïóU9†ãÂ3ê
 ¢èêuÏ$º¾Zrôô“‹‘ÛÚ–GÁbB„½žþ0�séÄae�ø¨(üT�Ž=þ(W>€²Úí”hKæ½ý�·VvU_º…
/Ú21NÅÝP¶fèi²‘æŶ‹U
O~šœXŠ0;íƒ�†þ[Œ˜É±•%…ŠŽÁ8zjÛtÿ¯=&JEÊ“¨ò…�ÂFXŠiºH#M�¬?Ú	'›ÑÄ­-ºí7üdžض³ôÌvÆ;‚á{¨©<->Ÿ⪩†*¯öÂ8¥�ž<>{÷ñ‡è±û×ßTs½þúO×ß²ûîû§vírHû››õ7zUß.¿Êïïžû‘Žþ÷gæO?Ò·ÿï¿ÿUBÐYÎÿ{Hc�54©#
 ™êSÊý‘ÎIÿݳÊZendstream
 endobj
-1414 0 obj <<
+1424 0 obj <<
 /Type /Page
-/Contents 1415 0 R
-/Resources 1413 0 R
+/Contents 1425 0 R
+/Resources 1423 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
+/Parent 1392 0 R
 >> endobj
-1416 0 obj <<
-/D [1414 0 R /XYZ 85.0394 794.5015 null]
+1426 0 obj <<
+/D [1424 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 210 0 obj <<
-/D [1414 0 R /XYZ 85.0394 671.4386 null]
+/D [1424 0 R /XYZ 85.0394 671.4386 null]
 >> endobj
-1417 0 obj <<
-/D [1414 0 R /XYZ 85.0394 641.1061 null]
+1427 0 obj <<
+/D [1424 0 R /XYZ 85.0394 641.1061 null]
 >> endobj
 214 0 obj <<
-/D [1414 0 R /XYZ 85.0394 444.8166 null]
+/D [1424 0 R /XYZ 85.0394 444.8166 null]
 >> endobj
-1418 0 obj <<
-/D [1414 0 R /XYZ 85.0394 417.1342 null]
+1428 0 obj <<
+/D [1424 0 R /XYZ 85.0394 417.1342 null]
 >> endobj
-1413 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R /F48 1228 0 R >>
+1423 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1421 0 obj <<
+1431 0 obj <<
 /Length 1913      
 /Filter /FlateDecode
 >>
@@ -5500,22 +5519,22 @@ xÚ­W[“ªH~ï_aÌËê:B](.qbPlñ.
 8îcbE裋ё•G”
 iÇ!€D.÷upsõÎ)1„§#.e¤#0�l)ð;Ç�Æ–uú•›_Cu
	T„b ¹3¥mj€“$œ3½¬ï®~Á}ƒmïPI‰¨C¥ŸžŠk¯šïNñèe§�ÊEíC‘†FÌG§Ám>©!A*GëÛ¯X>y��m�²sûw›ªn¤À¿�Y9ÕŸìþ1ßq*”óÙ$'YñCSRA¤|Ë+Úƒ1GÊí0ßß[ôFà@ùä¯Î
]ÓGί_@ÄQtÊ·^à<<P…”£ õ_Œ~9Ž—$Jbé%~.«nùK$ž¦Õ÷çÒÏåüK¢òôò#Òk¢þøâäéý„€tw|æ9·ø"ñãÁy[¿Öõíû=ú›·;ÿ°Âû‚žL\�"m>NTà=àts…ÿ
 endobj
-1420 0 obj <<
+1430 0 obj <<
 /Type /Page
-/Contents 1421 0 R
-/Resources 1419 0 R
+/Contents 1431 0 R
+/Resources 1429 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1423 0 R
+/Parent 1433 0 R
 >> endobj
-1422 0 obj <<
-/D [1420 0 R /XYZ 56.6929 794.5015 null]
+1432 0 obj <<
+/D [1430 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1419 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R /F62 1351 0 R >>
-/XObject << /Im2 1340 0 R >>
+1429 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R /F62 1361 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1426 0 obj <<
+1436 0 obj <<
 /Length 2465      
 /Filter /FlateDecode
 >>
@@ -5533,40 +5552,40 @@ BB'TÅÄû÷‡ZÓ¬ñ@À–Û¢Ù0® ÔÊÊ�ƒTcavlr
׳¶ØåhkÂFSœ|(Êßµ�Z„wÒôŸòÛ©Ëߊ
 c
T‘öí/�.v“;8¢[#�‰'¤Ñum:ùÄ_4SÞ5ö¦É¸|
~ààu“�®˜;¹Þ­/½jª¾*˜Mǽ!-¢¡ÔÝ_¶4éÐÐD¶?u[Òág
 &‚©~þïfirÜØY-ÜdÅ*òkHè´æSÙd2(þFq×t,ì„›ýƒHú¾&@¿O=€‚yð×…‰ŸÂÁ�Ÿý#Æx«
 endobj
-1425 0 obj <<
+1435 0 obj <<
 /Type /Page
-/Contents 1426 0 R
-/Resources 1424 0 R
+/Contents 1436 0 R
+/Resources 1434 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1423 0 R
+/Parent 1433 0 R
 >> endobj
-1427 0 obj <<
-/D [1425 0 R /XYZ 85.0394 794.5015 null]
+1437 0 obj <<
+/D [1435 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 218 0 obj <<
-/D [1425 0 R /XYZ 85.0394 486.5796 null]
+/D [1435 0 R /XYZ 85.0394 486.5796 null]
 >> endobj
-1431 0 obj <<
-/D [1425 0 R /XYZ 85.0394 454.3582 null]
+1441 0 obj <<
+/D [1435 0 R /XYZ 85.0394 454.3582 null]
 >> endobj
 222 0 obj <<
-/D [1425 0 R /XYZ 85.0394 412.0822 null]
+/D [1435 0 R /XYZ 85.0394 412.0822 null]
 >> endobj
-1432 0 obj <<
-/D [1425 0 R /XYZ 85.0394 381.7503 null]
+1442 0 obj <<
+/D [1435 0 R /XYZ 85.0394 381.7503 null]
 >> endobj
 226 0 obj <<
-/D [1425 0 R /XYZ 85.0394 150.1125 null]
+/D [1435 0 R /XYZ 85.0394 150.1125 null]
 >> endobj
-1433 0 obj <<
-/D [1425 0 R /XYZ 85.0394 122.4306 null]
+1443 0 obj <<
+/D [1435 0 R /XYZ 85.0394 122.4306 null]
 >> endobj
-1424 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F62 1351 0 R /F65 1430 0 R /F21 930 0 R /F41 1208 0 R >>
-/XObject << /Im2 1340 0 R >>
+1434 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F62 1361 0 R /F65 1440 0 R /F21 938 0 R /F41 1218 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1436 0 obj <<
+1446 0 obj <<
 /Length 3336      
 /Filter /FlateDecode
 >>
@@ -5583,42 +5602,42 @@ $ˆDÑ2ˆ¨"THz\ØýK(;(§…Ál}8Z’aÃÖÓ¶Úpƒ–.€ÒXð
Ü+CQ<€EÓ�éÔè¦	…xÓˆƒç6NRû1VÎÈŸ
 ç3úd, ù«À¥'8¿=ìÇ÷cÅÕó
 |*�=„CÎcm	"Ƚ›™
û€™˜�š¤Ý&íBjsÙ¾ó2Nð(Í |¥w÷q>À<åx�l²2êsîH“„(³køº�?eÛý–p¦4…§ôhŽÕWzàµãk!û+_Œ×ÚAØO.LG˜…‘ÓÆÜ5yŽUZ�媑ãI%ÿ(§Džb*Û€6{O`ã¦È	øÝÊÝÕàÊÁ±9a|¡29è8K—µ…'¼ì襢úÙ±˜’uÒ·}Q—§wsák…v<²NÁ‚ ÎÓÄt‚D˧¥c¿	Ð’1ͽˆ²í¥ÙhÅÜ»�1íªLM«‡Ê~ã!`„TíE㹨�¡#uãÈù¸
 endobj
-1435 0 obj <<
+1445 0 obj <<
 /Type /Page
-/Contents 1436 0 R
-/Resources 1434 0 R
+/Contents 1446 0 R
+/Resources 1444 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1423 0 R
-/Annots [ 1442 0 R 1443 0 R ]
+/Parent 1433 0 R
+/Annots [ 1452 0 R 1453 0 R ]
 >> endobj
-1442 0 obj <<
+1452 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [411.5778 302.2913 489.9929 314.351]
 /Subtype /Link
 /A << /S /GoTo /D (man.dnssec-keygen) >>
 >> endobj
-1443 0 obj <<
+1453 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [55.6967 291.0037 134.1116 302.3958]
 /Subtype /Link
 /A << /S /GoTo /D (man.dnssec-settime) >>
 >> endobj
-1437 0 obj <<
-/D [1435 0 R /XYZ 56.6929 794.5015 null]
+1447 0 obj <<
+/D [1445 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 230 0 obj <<
-/D [1435 0 R /XYZ 56.6929 436.3593 null]
+/D [1445 0 R /XYZ 56.6929 436.3593 null]
 >> endobj
-1438 0 obj <<
-/D [1435 0 R /XYZ 56.6929 405.7905 null]
+1448 0 obj <<
+/D [1445 0 R /XYZ 56.6929 405.7905 null]
 >> endobj
-1434 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R /F21 930 0 R /F11 1441 0 R >>
+1444 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R /F21 938 0 R /F11 1451 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1448 0 obj <<
+1458 0 obj <<
 /Length 2453      
 /Filter /FlateDecode
 >>
@@ -5633,45 +5652,45 @@ JzÊ$ðžê³‹Ÿ†#iË×dpʽ.)_Ä‘b•}°F‹ü4
Ž�Ÿ(Iúøó„pÐ=I¥f,Œ¥a¾måínfî;q©©Ĕ綇
 û½·##Ö9�LÛ„Ô�—ÖS5�ù~,ˆ>"†â�Ô”Â�Mß+‡ª{B’[jœäe
Ζ
~‰’Š‹w_òÌr
#d²bûDôµÒÐCDk:õêLž}Íé]¦£¦ª÷8 �^1]qô>òâ±WéxÛ#—b“ѸAD
 ªvpùŽ2þû‰
 endobj
-1447 0 obj <<
+1457 0 obj <<
 /Type /Page
-/Contents 1448 0 R
-/Resources 1446 0 R
+/Contents 1458 0 R
+/Resources 1456 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1423 0 R
+/Parent 1433 0 R
 >> endobj
-1449 0 obj <<
-/D [1447 0 R /XYZ 85.0394 794.5015 null]
+1459 0 obj <<
+/D [1457 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 234 0 obj <<
-/D [1447 0 R /XYZ 85.0394 769.5949 null]
+/D [1457 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1450 0 obj <<
-/D [1447 0 R /XYZ 85.0394 749.2278 null]
+1460 0 obj <<
+/D [1457 0 R /XYZ 85.0394 749.2278 null]
 >> endobj
 238 0 obj <<
-/D [1447 0 R /XYZ 85.0394 398.6362 null]
+/D [1457 0 R /XYZ 85.0394 398.6362 null]
 >> endobj
-1451 0 obj <<
-/D [1447 0 R /XYZ 85.0394 370.8109 null]
+1461 0 obj <<
+/D [1457 0 R /XYZ 85.0394 370.8109 null]
 >> endobj
 242 0 obj <<
-/D [1447 0 R /XYZ 85.0394 321.6035 null]
+/D [1457 0 R /XYZ 85.0394 321.6035 null]
 >> endobj
-1452 0 obj <<
-/D [1447 0 R /XYZ 85.0394 293.6228 null]
+1462 0 obj <<
+/D [1457 0 R /XYZ 85.0394 293.6228 null]
 >> endobj
 246 0 obj <<
-/D [1447 0 R /XYZ 85.0394 120.47 null]
+/D [1457 0 R /XYZ 85.0394 120.47 null]
 >> endobj
-1453 0 obj <<
-/D [1447 0 R /XYZ 85.0394 92.4893 null]
+1463 0 obj <<
+/D [1457 0 R /XYZ 85.0394 92.4893 null]
 >> endobj
-1446 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+1456 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1456 0 obj <<
+1466 0 obj <<
 /Length 2247      
 /Filter /FlateDecode
 >>
@@ -5687,57 +5706,57 @@ BŸM
>pxJPÄS�<±)í—GÒ¼02;éÁlˆ{:fimÓ?гS’µÓønš€¦!Þf—–£‚×<|È‹Üλ-L–a–iÅ™£
 눔$À‚’`Q—‹o$„R±#‡�òXóvÙfSsøÎë¦Ãêñ㎞X	úNÏ9¯Fæ‚uú^ƒ7ªB FõÌ*ŽI¸fs;¢
îìQÄ
(-4Ôj(ä^ß©ïí­ñxap�oèì‹]Íï¡OcOQâô#PäXÒu
 ¶áãÍúã§õHz]À�p2D«ö…ïKw<,¿@hñ#UJ§äØ9nE)»…ý¼Ë�cH,4}¾Ù\Œœ,�i¯7Ý
œ'@ñõƒ;©Æò2z±åg¼X£—ì3xʶmÑ#^KB‘¨¸[êÇ|uKiç³ÖS¨Ù¾¦àÃóêŽ`ðEóY¦ã+±cÂÅ7Ö#‡-`ÒVg€;Ñi}B'h-E¤UØOåƒùJgÙs†öÔËÎPR‹H*ý=wø°?:od%½J*V?9ˆ¸v_à÷H÷ö2°I’M$ƒUYö¥Ú¦ÈÌ“ÉNéžøíU–
â#݇Aß—¸©)~ØÖ�T°ó™©²½%$‰}¨ˆ‹QÄï}+EÛÊÙ=[ÊVgn àV]%ËÚÕHÙ[
Šº´€®ñéÇÐñÒÿ:øçÄÈ¿²)=û?�ö¿#Ž;qì�ÿ½áE±ðcPÂF¡ý^<°ÜýY24ý–æÆendstream
 endobj
-1455 0 obj <<
+1465 0 obj <<
 /Type /Page
-/Contents 1456 0 R
-/Resources 1454 0 R
+/Contents 1466 0 R
+/Resources 1464 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1423 0 R
+/Parent 1433 0 R
 >> endobj
-1457 0 obj <<
-/D [1455 0 R /XYZ 56.6929 794.5015 null]
+1467 0 obj <<
+/D [1465 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 250 0 obj <<
-/D [1455 0 R /XYZ 56.6929 687.5192 null]
+/D [1465 0 R /XYZ 56.6929 687.5192 null]
 >> endobj
-1458 0 obj <<
-/D [1455 0 R /XYZ 56.6929 659.2346 null]
+1468 0 obj <<
+/D [1465 0 R /XYZ 56.6929 659.2346 null]
 >> endobj
 254 0 obj <<
-/D [1455 0 R /XYZ 56.6929 590.6286 null]
+/D [1465 0 R /XYZ 56.6929 590.6286 null]
 >> endobj
-1459 0 obj <<
-/D [1455 0 R /XYZ 56.6929 559.3791 null]
+1469 0 obj <<
+/D [1465 0 R /XYZ 56.6929 559.3791 null]
 >> endobj
 258 0 obj <<
-/D [1455 0 R /XYZ 56.6929 493.738 null]
+/D [1465 0 R /XYZ 56.6929 493.738 null]
 >> endobj
-1460 0 obj <<
-/D [1455 0 R /XYZ 56.6929 462.4885 null]
+1470 0 obj <<
+/D [1465 0 R /XYZ 56.6929 462.4885 null]
 >> endobj
 262 0 obj <<
-/D [1455 0 R /XYZ 56.6929 408.8026 null]
+/D [1465 0 R /XYZ 56.6929 408.8026 null]
 >> endobj
-1461 0 obj <<
-/D [1455 0 R /XYZ 56.6929 377.553 null]
+1471 0 obj <<
+/D [1465 0 R /XYZ 56.6929 377.553 null]
 >> endobj
 266 0 obj <<
-/D [1455 0 R /XYZ 56.6929 258.7201 null]
+/D [1465 0 R /XYZ 56.6929 258.7201 null]
 >> endobj
-1462 0 obj <<
-/D [1455 0 R /XYZ 56.6929 227.4706 null]
+1472 0 obj <<
+/D [1465 0 R /XYZ 56.6929 227.4706 null]
 >> endobj
 270 0 obj <<
-/D [1455 0 R /XYZ 56.6929 161.8295 null]
+/D [1465 0 R /XYZ 56.6929 161.8295 null]
 >> endobj
-1463 0 obj <<
-/D [1455 0 R /XYZ 56.6929 133.5449 null]
+1473 0 obj <<
+/D [1465 0 R /XYZ 56.6929 133.5449 null]
 >> endobj
-1454 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F48 1228 0 R /F41 1208 0 R >>
+1464 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F48 1238 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1466 0 obj <<
+1476 0 obj <<
 /Length 3154      
 /Filter /FlateDecode
 >>
@@ -5762,288 +5781,334 @@ Zµ¼‚Ì^õØ
Mè?ºŽç+ £c×nÓj'£¢7^A8aQƒPÞd
 üB¢‡9#PÊa3@m RæÏÝJæIÜ™•åû}™(q¶È(ïFB
 †O¨´.9·�¡Lzâg'ðnºh$õ©P%,£•u™-¡A_6á¸{èENÏL¼8+û’ˆÒÍ¿oN¥PýR_/6"?
‡='Šë’å²òp5q¸avèrÃþÁc
 endobj
-1465 0 obj <<
+1475 0 obj <<
 /Type /Page
-/Contents 1466 0 R
-/Resources 1464 0 R
+/Contents 1476 0 R
+/Resources 1474 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1423 0 R
-/Annots [ 1470 0 R ]
+/Parent 1433 0 R
+/Annots [ 1480 0 R ]
 >> endobj
-1470 0 obj <<
+1480 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [408.1244 623.7385 469.3244 635.7981]
 /Subtype /Link
 /A << /S /GoTo /D (managed-keys) >>
 >> endobj
-1467 0 obj <<
-/D [1465 0 R /XYZ 85.0394 794.5015 null]
+1477 0 obj <<
+/D [1475 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 274 0 obj <<
-/D [1465 0 R /XYZ 85.0394 769.5949 null]
+/D [1475 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1468 0 obj <<
-/D [1465 0 R /XYZ 85.0394 744.1913 null]
+1478 0 obj <<
+/D [1475 0 R /XYZ 85.0394 744.1913 null]
 >> endobj
 278 0 obj <<
-/D [1465 0 R /XYZ 85.0394 684.3648 null]
+/D [1475 0 R /XYZ 85.0394 684.3648 null]
 >> endobj
-1469 0 obj <<
-/D [1465 0 R /XYZ 85.0394 655.3895 null]
+1479 0 obj <<
+/D [1475 0 R /XYZ 85.0394 655.3895 null]
 >> endobj
 282 0 obj <<
-/D [1465 0 R /XYZ 85.0394 606.8822 null]
+/D [1475 0 R /XYZ 85.0394 606.8822 null]
 >> endobj
-1471 0 obj <<
-/D [1465 0 R /XYZ 85.0394 580.8718 null]
+1481 0 obj <<
+/D [1475 0 R /XYZ 85.0394 580.8718 null]
 >> endobj
-1464 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+1474 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1475 0 obj <<
-/Length 2743      
+1485 0 obj <<
+/Length 2889      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥koÛ8ò{~…�= 2+¢¨g¿¥iöší^›«Ó;¶û�–i[WYrõˆ›þú›á%9Qr
¢áp8çI‹™bFn”úé,N7ôD8ËögÞls?L³°D‹1Õ›»³‹_e<KÝ4ò£ÙÝfÄ+q½$³»õNà
-áÎ�…çܾ¿ZÎ~è9¿AÀ/ô®>Íeìüçön.çãûÀñìòóííG3{7‡½Cß¹zwy{wý‰¦æ{ùö_s!„sùáêú-M½ýÀ;ýz}9�çîó§ëåüÏ»ßήïús�Ï.<‰‡úvöÇŸÞl
*øíÌseš„³#<W¤©?ÛŸ¡tÃ@J‹)ΖgÿìŽfÍÒI]
-ÏõeäO(Ó3¸2€É±6ÃÔõ“Øïµ9_Ï{^›õ᭾惛îp¨êO{ø£óf)ÜT„‘aΟ9€o»U‘g4~¯ m¶µ:ìF:ËV•kUã%®{.,Öú‹çù¥nh¨ès(T»©êý‚†y¹Ö
ÿÊ–—·7
-\×r5~øn
-´"0X^€ÁI‚Ö)8!†<ï¢[EºÕá‡d?ƒ^Èû|­‰²ÔGšÙhÕv±Â4]ÆŒ�ü@|{ó�{UBpØ›Äaì>&~ )aÂR‰ÿFÓ·Ìô#ëL
…Ö$uªåЃÁ¬ŒH˜¸˜@
-_Ìr)äßØ„
-ï� Îb{æä„@¯¦P€`³Zµµtéq
€¨¼lu½Q™&¼¹8@“Ý
Â$Ä<γxž( £:c–@¶~(Õ>Ï”q5œ(*µÆ3áäŠqƒ
-i:3~Ä�Iâ“LíÌJ[yúb¦ÐëÉ y·Ó}ŠUã
W�16@ªûªnp@hSÁ—u…¬@
¡#E­	ƒWbvØñVƒÀ€/êœw)õévG(3v´ß¾kx8òÄõe»ªÁhdôÚöJAen»¾<AÍ0ÞÝ_yVÕ¤�Ì®ÜUy¦m%f}+¸ò¹yl¿¯Ÿk¹A"ƒ—›¥1•©ïE0Êó±p#�x¡
-¾x"~¼iüD⿼©%zºéIq‘7LÓðtÓÏ
+âåÔ„C ðSqczóE„\d‘îLAUÂÎÞÙNÝkÂMÞ�KP |T‚†§ÁÿÜ×`Iv£.©-\ö†Ë^@õ­IÞ}ŒšLq¥Œ’/.1þ	H
-:\Ì!ÙeŒG�ø<Ì;g(åD¶uÑ”¹ÉŠIË—ÍmLõ¼¹õTÿÏÜ^Ü´7·'›NšÛɦdnqì¼jòm¹¨Êâ
Í*îÛ›8¶f86+À
6èµÆÅFý0e®
-°›®ÌØ„
-
-Ï
¥’Š�óE$ð9ò�ëÇš
ž^ìÇ3߃õ=³õìÛL¸^�¦’ˆF°9ë ƒ¸¸Ùû³·œh6:”e¼s6‡ŠÆ‰2M`2†ýýÄ�’tÔtJ“fènú"ÜÏ¡£ÖucR"Sµv)–Ê¡¹�LqoPÍVk¦Kƒ¯ç¦nR˜vÉm?`�yQLÙá¡®æ"t¸‹—äÉøíkeÊ$és÷Ìó
}!€ùPPÒ`tž6Rû£VÛ¬­y‹:¸VØÀgòiªáú qÊ94Ý~e‚ŒsÆ“OÅè~(AQ˜£©�Ž1ÌšTÃ+›ñt€T"¯Š¾äQ(-€Ï¯"|ßO“ÙØîΕÐiê½ÅðCÄÏ9ú©wz˜èdÅgÉD„¥Ÿ$C~3Îã)t¼]^ØW	k‡ˆO	Áe`Ú÷ñ©à^5íïs~šh	kÌÒ®x[=ÐÐÜNãÖ„RÀÉž-u€#k�0¡œ³Ô¡P¶ÃÞ
JŽð·§	¬ÖÀy÷üóÀâñÂ_zΰ�AX>L>|\µÊJ>œäé¯)‚Bè<ý}XJÇþÄNt½Å×R„vm{x}qq<]ÈþeÓnUo/šª«3}Á¨’VÕîöÇ3?B
›\oke{ø^+°xEdz
¹¡¿�bªWñúÜñÓ?ï�ZûØ•IòL×þŽÍµì¥ÂsIï‰ìö‡À	áÿÜ÷‡•endstream
+xÚ¥]oÛ8ò=¿ÂÀPˆQÔgï)›f¯Ùîµ¹:½Ãa»´Lۺʒ+ÉqÝ_3œ¡$;Jv�"@4‡œá|ÒbâÁŸ˜„‘¥~:‰ÓÀ
=N²í…7YÃÜ?.ÓÌ,ÑlHõóÃÅÕ/2ž¤nùÑäa5à•¸^’ˆÉÃòw'p…p§ÀÂsîßÝ̧3?ôœŸ„ à³z7§2vþ{ÿ0‰óáÝàxvþéþþƒ™}˜ÂÞ¡ïܼ½¾¸ýHÓ
ó½~ó啕~sû†¦Þ¼ç�~¹½žÆ�óðéãí|úÇï·�\CÙ…'Q¨¯¿ÿáM– ‚_/<W¦I89ÀÀsEšú“íEJ7¤´˜âb~ñ¯Žá`Ö,Õ¥ð\_Fþˆ2}1�+˜j3L]?‰ýN›Ó™ð¼çµYwmõ%ïµØìw»ªnQzØÃ\˜7™ù©+ã04Ì™cà3G
+Õ®ªz;£a^.õNÿ²%Äõý
@DÛ´Sál4ÁYU¶fê@éP0¶4IYÕŠ°áSè«Y-:Û×y{¤Ñ¶Zîs8ÖãÛù?›^‡ 
U»Ñ5�Y¯£ž�ªÍ`©óL7nw´Ä
¼(6Gûùî=Zj;)~"'ohø¥¬%¡ÚŠP‡ªþB˜CÞn×*Bá1_Og2
+ãðÙ7Æ
ú
+|(u69³±_EŸ†ó˜ÙØù¢Võ‘·\à=£¤À"lÇœœèÕØÍ`ÆØl�Vm-]z\ */[]¯T¦	o.Ðdw€0
	1çiå‰2: 3f	dËc©¶y¦Œ«áDQ©%Ê„“Æõ~
+Ñ&ÍæÝS
9¬ÄÎaìÖ€é–�Xݶ›0;V
G�'¾ìwvÕ�Æ5vsCñðÖ›fD†Úë®sI`¥�ªåY´EÛË€$TïžÍ˜Hß)Ý&@	Þ@›ŸÚ–;a•$¤Ð9’Á-&ö
 u
+ôžÓXý®°?G…DP§Öl¥0 µEVTGñ@p˜òÜÔMäB6r„ë¹ãú
+Ä.§¦PÂ,jŒ¥Z¾åè3�±²ÕTz˜YCò{
¤™CŽ!]â‹{]MEèðƒ‹y ¥‰ýn©LE‹HÓãÞ¼µÀr�ÖNó§¢J“øi¦÷.\[ó&µ}(4rbQInæ$”æˆ�N9…^o¿]`¾@‚œñ­]adFÇGÑæÅç5¢û(�+›á4ë$1̘ø
3”<PŸ'îDøKLšLñc.†Î¦P—Ïú_Œ~,
+i×"]ò#RKX²C$\ð¶`=ÒД,8�[ªÏY'{¶ÔÃ¥ÖXGü!çzbW(ûпؔœ’nOK�îm
 endobj
-1474 0 obj <<
+1484 0 obj <<
 /Type /Page
-/Contents 1475 0 R
-/Resources 1473 0 R
+/Contents 1485 0 R
+/Resources 1483 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1479 0 R
+/Parent 1489 0 R
 >> endobj
-1476 0 obj <<
-/D [1474 0 R /XYZ 56.6929 794.5015 null]
+1486 0 obj <<
+/D [1484 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 286 0 obj <<
-/D [1474 0 R /XYZ 56.6929 769.5949 null]
+/D [1484 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-1477 0 obj <<
-/D [1474 0 R /XYZ 56.6929 743.6915 null]
+1487 0 obj <<
+/D [1484 0 R /XYZ 56.6929 744.5025 null]
 >> endobj
 290 0 obj <<
-/D [1474 0 R /XYZ 56.6929 650.8595 null]
+/D [1484 0 R /XYZ 56.6929 659.1833 null]
 >> endobj
-1478 0 obj <<
-/D [1474 0 R /XYZ 56.6929 617.7643 null]
+1488 0 obj <<
+/D [1484 0 R /XYZ 56.6929 628.6281 null]
 >> endobj
-1473 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F14 956 0 R /F62 1351 0 R /F41 1208 0 R >>
-/XObject << /Im2 1340 0 R >>
+1483 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F14 964 0 R /F62 1361 0 R /F41 1218 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1482 0 obj <<
-/Length 2100      
+1492 0 obj <<
+/Length 2097      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥X[oã¶~ϯЬDoº´Ù$»M·'›³ñž¢èöA–i[ˆ,y-9‰ûëÏ�CÊ’£´i†¡g8ä¿¹PÌ£ðc^*RéÅ©$!e¡—¯O¨·Þûfe'ô¥ÞNOÎÞ‰ØKIñÈ›.zºB“„yÓùoþÅ�ç·Ó«O“€‡Ô—d„õÏ/ÿ7aŒùç7W—Ⱥ¼¹CâÝÕù$–þôó§+‰Ó�Ã4ÆìÌÛVî;Æ�øBCzñi"bÿ×Ûé„%þÇ×0f¹wŸoo?îtòûô§“«igWßvF…6êëÉo¿So.øé„‘&¡÷/”°4åÞúD†‚„R7RžÜ�ü·SØãš©c¾EB„Ç#ΔlÌ™2&Q£3ÿ5	"Jý6Û"ñÇÓ‰z£ª¦)JR’”ÈòmïÙ;Î{Z©J8�ºóͦܣ›Ú•Bb“µù
-ÉÅV{³^I¼½¾±g–âÈ©Re�ú7®9°d¸¦5Á.£É`Ã,13Ǿ0!µn/f$àG@D†ÜèüefE5RzäÙæ>o;jpá�	F¢4J_ÆIš†r
-`tE+œGA—%ÝŒ¡ªCø…¡ŠFbàl;?,¼”’˜AØE,!ßÜôPFp0 È(	‡�‰�à=ÑDÜ¿:öè”¶Æ’ÁÍÒÞW�*ÓT P�6¶|`ή×Ü»¬Á"¯g”Sô5£¢>`‡ãŒ%l ‰‰c³cñ7ux”R
-Ÿ²õ¦T
øˆSî?Z©|U×�¥ÛŸôðÅ
ëÈ€¼Ûº¼k¶zˆŒÙòË$å¾­,�…�1P»F¹ªS4HnDÍÊJæu¥c}¹sž8ªUÄ&ÂãÒ$	—6¯˜>~`…zòvWXähÝÁ˜ÒXo�ªâùÕ-Ô^‡¸¡Ýn.ªÝÓx9æ!‘"ÂÚ8ÕÊç¨0ß)ÓƒÚú™ácU,Wºzk±Få�Ùšw¯öH4m½Í–
-¥æê¡ÈÕ©N1P,w-Š @5ß
-Hqh0;Ïx(ìö?ËfÆA Ñ
-–`’Ñ,¿@Ù´r:æbçÀMi’±&õ™êçQ9ƒ-¿ºÉÌ7¶Ù4ÓÉû‹(„“¦&@„ÈY@ÿíHìÕEO­‰¬ïNæ»A}òHeYQ&�¹Í!0ŽÙ
Eì¤‚3ã ¡¥ÕºõµIû<z½@ŽñžžÔe>xÑÝt%Øc0ÌDÅ‘<(î–ç6F�È�‡KÇ•ÊUÓ µ!V—aî3|tv8˜ÛÀ™ÙÙ¼‹}þ`-¸]®:
-'3Ýf×�N,Íhˆ¼o•%ºëôHE?CŽ¬»È|ÝH4n¾fóÆjjêaܯwM;0ÄZ±9L%¯Æìø%häDìrvQW‹êžÂ�RŸg°T•Ú¹ö£¹[­;Jï
-vôŠ{UlîÀGU¶V?üe¤5vÛe}e‹R羺¤øÒ¤n[µ(žŽ×	ÊÀYпà.ZsÐ2ìµ€²SÛNW!mºù磒$	ôxWZg÷jdmèmR
-E…ðb •BÓ¨	ù’v¸nÆTò¾r3¯U
+xÚ¥X[oã¶~ϯЬDoº´Ù$»M·'›³ñž¢èöA–i[ˆ,y-9‰ûëÏ�CÊ’£´iF¢g8ä¿¹PÌ£ðc^*RéÅ©$!e¡—¯O¨·Þûfe'ô¥ÞNOÎÞ‰ØKIñÈ›.zºB“„yÓùoþÅ�ç·Ó«O“€‡Ô—d„õÏ/ÿ7aŒùç7W—Ⱥ¼¹CâÝÕù$–þôó§+‰Ó�Ã4ÆìÌÛVî;Æ�øBCzñi"bÿ×Ûé„%þÇ×0f¹wŸoo?îtòûô§“«igWßvF…6êëÉo¿So.øé„‘&¡÷/”°4åÞúD†‚„R7RžÜ�ü·SØãš©c¾EB„Ç#ΔlÌ™2&Q£3ÿ5	"Jý6Û"ñÇÓ‰z£ª¦)JR’4ÈòmïÙ;Î{Z©J8�ºóͦܣ›Ú•Bb“µù
+ÉÅV{³^I¼½¾±g–âÈ©Re�ú7®9°d¸¦5Á.£É`Ã,13Ǿ0!µn/f$àG@D†ÜèüefE5OÏàÿÙæ>o;*
+pÍ@	F¢4J_…ÆIš†r`ogE‚(œGA—%ÝŒ¡ªCä…¡ŠFXàX;,¼”’˜AÄE,!·Üô
+Ÿ²õ¦T
øˆSî?Z©|U×�¥ÛŸôðÅ
ëÈ€¼Ûº¼k¶zˆŒÙòË$å¾-*�…�1P»F¹‚S4HnDÍÊJæu¥c}¹sž8*SÄ&Âãª$	—6¯˜~`…RòvWXähÝÁ˜ªXo�
+âùÕ-Ô^‡¸¡Ýn.ªÝÓx%æ!‘"²8ÕÊç¨0ß)ÓƒÚú™ácU,Wºpk±Få�Ùšw¯öH4m½Í–
+¥æê¡ÈÕ©N1P'w-Š @5ß
+Hqh0;Ïx(ìö?ËfÆA Ñ
+–`’Ñ,¿@Ù´r:æbçÀMi’±&õ™êçQ9ƒ-¿º¿Ì7¶Ï4ÓÉû‹(„“¦&@„ÈY@ÿÙ9�Øÿª�žZYß�Ìwƒúä‘ʲ¢Lr›C`³ŠØI>fÆ@CK«uë“ö1xôz�ã==©Ë|ð¢»èJ°Ç`˜‰Š#yPÜ-ÏmŒ‘;—Ž+•«¦AkC¬.1Â&Ü)føèìp0·�3³³
xûüÁZp»\uNfºÍ®�XšÑyÞ*Kt×é‘Š~†>Yw‡ùº+�hÜ<|Íæ�ÕÔÔø_ïšv`ˆµbs˜J^�ÙñûÏȉØ	ä좮Ô=…¥>Ï`©*µ-ríGs­Zw”ÞìèWª ØÜ3€�ªl­~øËHjì¶ËúÊ¥Î}?tIñ¥IݶjQ<¯=”�³ ·]´æ eØk
+áÅ@+…¦Qò%ípÝŒ©ä}åf^«
+ÚÝL3Am�£X¨»› í²±ËÚÌÙ£o/Â4�}åVKkbYá
+Ø?Z¾ëAÁ=P3GkÛn3<@i_‹µ«
‹¬iUçßÌz1«l¦‡ñ¨4t‡0ìöšUæ®83×ânƒþFØé›Ñºv]ß‹º¾jP’²þ-hØYcÀ¼<%Ñ�ël<ÿÏedýán‘ß\ÉÆ>½	
:1öµ”v߸¾ùÛìá«‚Œ!Ç%|<u‘„§±Û”6J<ûŽÒ}Ä}¾õÿã}Ó{endstream
 endobj
-1481 0 obj <<
+1491 0 obj <<
 /Type /Page
-/Contents 1482 0 R
-/Resources 1480 0 R
+/Contents 1492 0 R
+/Resources 1490 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1479 0 R
+/Parent 1489 0 R
 >> endobj
-1483 0 obj <<
-/D [1481 0 R /XYZ 85.0394 794.5015 null]
+1493 0 obj <<
+/D [1491 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 294 0 obj <<
-/D [1481 0 R /XYZ 85.0394 491.3865 null]
+/D [1491 0 R /XYZ 85.0394 491.3865 null]
 >> endobj
-1484 0 obj <<
-/D [1481 0 R /XYZ 85.0394 466.1094 null]
+1494 0 obj <<
+/D [1491 0 R /XYZ 85.0394 466.1094 null]
 >> endobj
 298 0 obj <<
-/D [1481 0 R /XYZ 85.0394 166.668 null]
+/D [1491 0 R /XYZ 85.0394 166.668 null]
 >> endobj
-1485 0 obj <<
-/D [1481 0 R /XYZ 85.0394 141.3909 null]
+1495 0 obj <<
+/D [1491 0 R /XYZ 85.0394 141.3909 null]
 >> endobj
-1480 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R /F62 1351 0 R /F21 930 0 R >>
-/XObject << /Im2 1340 0 R >>
+1490 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R /F62 1361 0 R /F21 938 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1488 0 obj <<
-/Length 1727      
+1498 0 obj <<
+/Length 2160      
 /Filter /FlateDecode
 >>
 stream
-xÚÕXY�Û6~÷¯0Ú>È@D‹¤¨£À>lœM›¤Èn³n‹"	
-­$¯…È’+É{ô×w†3R|hÛ¢-
-~9䜜ù8´œzð“Sˆ Vñ4Œ}a<i¦éfâMoa훉ä=n¿ÉÝßõ|9™¿Ôá4q ‚érµ'+^Éé2{ïøBJ1žsõfq=s•ñœ/¥¤ÁÏx‹w3:?_-g2r.ß¼¯^ÿpuuiW—3Ðm”³øöüjyñŽ–}–{þâÇ™”Ò9»¸xAK/Þ²¦—ç³Ðw–?¼»¸ž}\¾ž\,¿ö}—žF§~�¼ÿèM3Áë‰'t™é=L<!ãXM7ßha|­{J9¹ž|?Ü[µ¬£±”žP:P#ÁôåX0M,­´
æW37ð<GÌuµ*nwMN„¶.“¦hß}ˆ‚_à“¦´ðAjÝž†R„ÔÃaÄÆ(+Íu·Ÿ¤tËâ¦J6ùÙ|×6s˜Ì?ÛOi»ÛúH’7*dU&wus–6�Û®v“4Í˼IººyŠ[öÜM¾*Îæõ¶›“J´÷Î_*µ·wAK¡Ò€óç%*Á³N裕{St4¾ÙeöŒÆ»6ç¤SÊçˆa¼ XHaUFƒ!û¡67{?b¡‚зvœ¯ºœ­Hëêƒç)8œ¢ºeÕÍ,rv;µÊÒó„g´
y(f“|ÊG\W!äS(yš8")Ú€5{‚¬ê.o»‘¾¾"Þ.¬Oàä¦ïG‡¾]V)ÈÒ*vë
ÖÉ“0À
/·yu}ýÝ3š±Ë0ŽlÀÇLŒP@ûµÝ¶�yÕ¶%ÉÈ«Û¢bEt#žHˆN,£>:t”ÈÑÕôåi6L^'l0áhñIín»­›ŽÂ¡b-”'£Ã„¿OZØ«}�»ÙežáÌ8EÕS›�,O»òÑÂ’E)€ uN;ê]·ÝuÄÕ®ë]™ý&'Z]õWDèzÎU]–õ=¤ÑKN‹á6ÆÉr\6,Õl
³(Oc…Žaµšvyö5E÷
-‹ä‹çW´ô&Üæ¼jqhéŽá¡ÂæÂ.áíI£²
-½ÓêÄòþO¡SÓ
-æñBendstream
+xÚ½X{oÛ8ÿ?ŸÂØ[`e ¢ùõ(ÐÒ4¹íî^“­Ým±�m9ÖE–|’'÷éo†CÚ’«¤»·À!LÍ�Ãá<~œ¡qø#²0‘É(J¦¹Ð£ÅæŒ�î€÷·3açøn’ß�õfv6¹VÑ(aI(ÃÑlÕ‘3Çb4[~ò&ƒîÝþ|9ûRsï/BÐà3×üòÃXEÞ?ogc{7?¿šåN?ÞÞÞîl{ké]þxq;»ú@ìÀʽxû�±»xyõ–XoßÛ�®¯.ÆQàÍ>~¸šŽ¿Ì~:»šÎÕ=»à
+õï³O_øh	&øéŒ3•Äz´‡ÎD’ÈÑæ,Њé@)G)Φg¿v¸fé -gR…rÀ˜�2¦NX¨¤2Æü~쇜{lrY•«ünWgDhª"­ó&üÇ8ü
~b|*Àc�"Á"Ûƒ3­¥‘æûÛ{!ü"Ÿ—é&{=Ù5õ>&a€?ÛûE³›êD²*Ò‡ª~½¨Ÿ¶m始EVduÚVõs«…[]g«üñõ¤Ú¶ÚõÀ¹“k);ñÝX7¢å>׸º:¥%ýyÞÒx¾Ë‹å9�wMfcNÊÀͶBŠ•Q.ip0F×Ì„¦;FÌ¡c£ÇŪͬ‹ªü̹ßäå�ݺÇÞ®´gê:YpθV䡘MzŸ
œ\FN‘°“PÅ
I	S:
+º‚ÌÖmÖ´"ÅÆv:è‹5b0x
+l9Ò*d
W¿«n�,‰ãx¸jðý®HSôðRÈ
+=¾‘Ž1
ø’0È°ªniº�•ßÐ=…ìé*ÿ¢°ÅÚZßñWC–óïˆÿWúù¾»åKg:1Ïdž—N¨3$f•ßV÷HáŽÑU{B
+±~€Õ9ªÄ+šŒ23Ð#(U�b
+K$„½»p�–OíšðHp«6�›ü®*^d‰@ܤÝ�¡V2ôö͆À¨ÜtÑñ”áãa $¡Â
+œØ„ê8š»
+màHÙ@æ:ò¤Ûw¸”Ũi
+Ÿ³„ÅÍ3a=بy¹{´MŠ�¨m»®³tù?ô+'�}Z­³óèô-s~³Ùù3íÊïkMÊ`àWAü�†!`	]W1ÐÝ<#]	þ±&"élC…�/AK�÷]¯@¸¡d•	+8X§–„qÚÒ°sK×3Š’ñ³F	5“±Š\ƒ´Ý6¢$#+ïòÒnDN8�€6+±èY
W˜<‡_ë2YH^§Vaz×@©¾R³ÛšË�Ì‘(&¹ˆOz†áIAqWm¶9•:JSMo¨5ÁÁ¢…¨Äç
óÚØ:fT»vk V5P
K¢›2J!º‰+"´nåªÂ2’€	è�”¦äDT\fØôX•ÕÆ.ÕGœÈŽzþ´C¥@±Xòè«î�ÜAO>˜ydK[âÀyÏ\9Ö®”¥°ׂd¯ëÏNsqh÷›úÿ©'ÝkôÝyù#
+¿Ï[DŠ8>"Eül.kèÞeæ.sÚâØæ„ûC™. à„Lï§:´a¢Ñ´	16…�¶pÉn[ú0eÌ;•»¥¯íÀ¾
+ÆîUz>Ð
êPÏl"¼w++ÃÊ´74 KÈté~«]WÌ.íoã~wà�¦Yí
+›Z€óC¯dŽb S�\i�S
D�ˆ Ð�…C OÖÏ®_¢Ï/†…u�Ã
Õ€i	W}EC¨Ðe2Ú7 u�ãœ;
+Üç0TIE'H8¿SŸè®#¦@Á\Â÷‚CcG£›•Ò×~S-s„Tƒ}¡>> áG³ËÛŒVƒ¿¶¹TŠéÈ]ræB&ÓR±Pë /^Ö:�ÃëÞsØÐC±Ò, æìôYþí^úùøÚ  âX7ƒ2‚¸ˆAˆU
+Wò+ÍÝkóתÿ
+ú*sendstream
 endobj
-1487 0 obj <<
+1497 0 obj <<
 /Type /Page
-/Contents 1488 0 R
-/Resources 1486 0 R
+/Contents 1498 0 R
+/Resources 1496 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1479 0 R
+/Parent 1489 0 R
 >> endobj
-1489 0 obj <<
-/D [1487 0 R /XYZ 56.6929 794.5015 null]
+1499 0 obj <<
+/D [1497 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 302 0 obj <<
-/D [1487 0 R /XYZ 56.6929 442.1519 null]
+/D [1497 0 R /XYZ 56.6929 655.8524 null]
 >> endobj
-1490 0 obj <<
-/D [1487 0 R /XYZ 56.6929 411.6415 null]
+1500 0 obj <<
+/D [1497 0 R /XYZ 56.6929 630.3608 null]
+>> endobj
+1496 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R /F21 938 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1503 0 obj <<
+/Length 1877      
+/Filter /FlateDecode
+>>
+stream
+xÚÝXÝoã6÷_a´}��•LŠúâ
û�õ&mº½$]{{-º}�e9Vc‰®%'ëÿþf8¤,+Jo¯=ÐÆH
ÉùâÌ�Cò1ƒ'¡Ç„Ʊ¼�ñpœ•#6¾‡±¯GÜÌqí$·;ëÍb4½ñXz2ò£ñbÝá•x,Iøx±úÙ™}sq·¸|?qý�9�7qÈ9o˜pÎ�‹›Ùå[z{3§ÎÕåÅ$œÅ‡÷—@‰eèÃ2ÎÍÊ»w33ïKΩó‘…lö~"b移ń'Îí»k ™Ñù‡»»[=º˜ü²øvt¹híêÚΙ@£~ýü¯Àߎ˜'dŽŸàƒy\J\Ž‚Pxa „¥lGóÑ÷-ÃΨ^:äËP$^˜øñ€3}>;eúgÞ¥	_hojOø—3Æœ7‡b»*ª{2ôÍõ�q¥¤æ©h6ÔC§¡»À~�âw¶Œ�a‚N–šý¿6yÌ¥p–-oü"ÞØ“¯€%�f“a«²´)”Y¦ÖÔšáÀÉu£JÙ54t»Ë«ùü;³ºXîÓý‘>J˜k¤æõ.ÏŠ�ŒùùŠ�Ejøª
+é÷‡=îxîÛø¹m|‰¤ã:�çÍZ/{p­öÔù®¨Ÿú^Õ6bçâòŽ:ïòã.ßÿž›I•ÅDúŽ¢5Û¢zx‘ó@´ï´Áê±X�$È“Wv	9"]ÕD gboi˜åUºÜ¢#ñ£¨z¢ž¯#@ûÕçµ<I}½†V=.Œz@j7©ä? 6v¹
+†Œ«4±¨‰–ödDÕl�4¤*ÛKÓbL¸cx¥µiiµðÝeÑiYT¨Bà†/çzM³žìb’d¦Û`·Æê,$üÂÈ<D)‚GN�$mTÝ€û…ð5[&¯ã Ú²ül¹UIZ*‘—G3kE9‡´�¾¸¥ð±¥ÑFÑH>Ø�³�©&aMD«scg!�^Æh¶göúÚÞL•eZ­Úà´©ôS‹yA$#½æ«‰AJe+j=o
+°’CìÍTo
+ê¬P&'Âlöú‹û,£4ûÓu)l]p
+n¤~ä‚”� «Bœo™ëb*¹
+€¦®·¯§à›éî!«9Ÿê}�CO?³–¦÷—N!ºñŸ(^­PÇmU
+b�qÙÅÿ�`Ï\mÓ}Q¿ˆóÙuÀ,ö·ÃžÿKàµq÷)Ýg›×i¹Š‚Ï‹¿˜{±àƒ!ô_†
+?sQ0vÝ]v­&]÷`eteã(¥¦…Iëf³‰ª´TðˆÆ‹Œ>Ñ)ÉŒcpÌÓõÕÙÑh‰f!Àz`c‰ån›ˆR>œåéRikü¨”¡>©ý$B,ÎQˆ\¦Gb°I
ç”áO->kªÑ»hò¬éh•FQ—i“m¼¡H¹mc;ŽŒÔØJ�¹•
+½¢Ê”9±2:±€xV² �¢:»Tç’µ'³A
+Ä€²ü‰SÆ<eºù~±nr㼬ëi“âûIâöÚã¿·}œá­#H@aéC> 
+ó
 :<)Ðr8&žs„ˆ(ép7
+!M£v…´*4ïUÓäV„2Üò¦'s~{µ09Õ½	‡Ü÷âˆÃýSßIÿsî¾'“$¾	»-G·Ë’®¹g[À!�)O’õ£ÁíÍíD
+6ð?VUÅ„Ô(&<¶‡U^1%bYTE™n‰¦7©xgFB£E™®‚;RÚ䆨q¨°�¯ˆDRÌÍ¥Ÿ£Ûfšû�ï!JžÛI/‘ør¡g“|éÀÜV�„¬�N•?ÑÞÈÄâÛ@ØP-¦‚‘”ººÄðG*Y
DmÅ
+endobj
+1502 0 obj <<
+/Type /Page
+/Contents 1503 0 R
+/Resources 1501 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1489 0 R
+>> endobj
+1504 0 obj <<
+/D [1502 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 306 0 obj <<
-/D [1487 0 R /XYZ 56.6929 374.4296 null]
+/D [1502 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1491 0 obj <<
-/D [1487 0 R /XYZ 56.6929 347.6871 null]
+1505 0 obj <<
+/D [1502 0 R /XYZ 85.0394 749.1709 null]
 >> endobj
 310 0 obj <<
-/D [1487 0 R /XYZ 56.6929 190.5336 null]
+/D [1502 0 R /XYZ 85.0394 714.4776 null]
 >> endobj
-1492 0 obj <<
-/D [1487 0 R /XYZ 56.6929 160.9816 null]
+1506 0 obj <<
+/D [1502 0 R /XYZ 85.0394 688.8412 null]
 >> endobj
-1486 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R /F21 930 0 R >>
+314 0 obj <<
+/D [1502 0 R /XYZ 85.0394 535.7123 null]
+>> endobj
+1507 0 obj <<
+/D [1502 0 R /XYZ 85.0394 507.2665 null]
+>> endobj
+318 0 obj <<
+/D [1502 0 R /XYZ 85.0394 332.8138 null]
+>> endobj
+1508 0 obj <<
+/D [1502 0 R /XYZ 85.0394 307.1774 null]
+>> endobj
+322 0 obj <<
+/D [1502 0 R /XYZ 85.0394 163.8619 null]
+>> endobj
+1509 0 obj <<
+/D [1502 0 R /XYZ 85.0394 138.0002 null]
+>> endobj
+1501 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1495 0 obj <<
-/Length 2310      
+1512 0 obj <<
+/Length 2117      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥koÛ8ò{~…�]`m ’EQÏ
-ћ̿öO?�Œ'£ë�a»Vß1†ëYý“³ßBˆþÉåé茖Î.oø8:øNr{=Œº6‚OŽ/NyßOBðÍr­Óë�ôû_Æ“�úWç€ãÕ›ÛñøJ¯Nß'¿�&�^ûºK¢R}ýnõæ`‚_�,S†�ÛÛÀÄ2EÚ½ôÈq¥é:RÖ˜äèæè_
Á½U}´Ë–®L7°ýcÚv—1ÝÐô¤-µ1QÕ�yAšE4HÛ˜ÆÁÓuœÌßœ§5öôôý7Ûvf3š�Q�fš-ßGéÜspÍÔû€�†L߶æx¾€C¡ÝŸåÙ7˲ïÖú¨ª‘é*‰â¬Ä©ìGÓ|]ÑÊÕJe77Ÿi’åŒÝäÅ}œÝ�€Ò’ým¾&tm‰À2z`Ê
Òz«‡X–;®Ô¬Ú“DöÓ¸L£j¶4„º.¹àU�…fñ=æê×\}Qs(ÎfyAdgUÂËåJÍbÔ]Í	Q-yû*ª–ŒÊiÜ©
ð²´äHd™¯>?U-:e”2•­%¸oE¡�D™ìp·6µ¥KUÆ÷®¥ÂQS`'zÅá�¢˜‡@Ö;YTŠ=nçt‹ˆ+A�q$‚'!	pe±çÊÂB_v ¬ŒîïÚwxpÂÐò\Þ„¤Þ=Oö;2Ü'JÚª²ê ïHÓ‘^¸Gž£(›?ËF
-3–÷„
x}%I'×3…»ÏÈlÈ6÷´è¡3šv( HX8¾Þ¯S�²:“ÝDçÍ<OÊÎps60·ƒPÓúp~‰ÉU†ý‡
-
-À¨É༿"0Ï´)<p¥aØ“

-iˆ™D«,Í	‹WËÜôÅ%L¤ˆ6‚mEø|UÅyfv%RÌß—W“Ñ1êàP%„±¡Ô�
¤–FŠ
-ÃQl6¡îB´›9ðmh:}Ò¯oúÒyU;g›aÝÍœÑP4öI>íÔœÀ7-ß³wœÑ–ãë«ßÎÏ ñ帲¡zÁ¡½Uö“
³]Õ~ˆŠ£ÿ°†ë.d±mtö�®Zßv‡¦Ãk"«.@Þ®
-V1ÒuC96Ëx¶ìJ8e•SâÆj(mhy‘23Dð“BJÉñ8VSËœ�uÉ«Ó-�tûxPß>¢Zù
-0ä[ÝSáÓõtš?`ǪфÔba¡;üÅq|Óõܺcr¨±Í	:
-)5¤Ü6.HÈaÍû©“ˆÐ7mϪ»5°B—óÍî—œøbôe<ºîpäNù^vÞ	~	mÍ“P†tÜ$»’öPŠÀ…)ŸÒ©�
„�zÐË”'2¸e[°¶Ñ(¬|¬RÖ8&KÝ*BÏu«-o}±]…Ëͦ«�Ä¿¯ê"�Àô|_¼‘Ø�û?/0-ϱ_¢Wo˜ge©f¨ë¢ÈShGU×S'tMØök…d¢e|—ý7ïtkß
ß	�7üñ�xp{A󦄆n—Š ¥	}ºÛÕq0u”>
,êo0T›<%8[§Óú¥Ìo”ÛSW¼ÛU¦§
-Ù †Û¨œE©šwhA†²~†R¿ŠÍœé¾wØ‘ÿ>mìªõóB	pó,ß0†®~?áœÊ%E	aÀšü8‰ù0…�¥
`tÞ,ÅõK&*눷³-aÛ®4Øð$¡
úso	v?ð©zÊÓQMÈK›Ç|¥«D÷å=Î^_ÔÃ\£Œ)�$¯Æ$4"âÅäŸRŠ´v±¨j9›6„î�!C”o–¿Î+m+�2ý=wŽÏ/�»>˜Ñ{ï«õý˜öÁeŽUO›@8¾HÏeCÌ’¨,	”4èkø|§Ù/;ýB˜x”»$c¶âY¶þ¶öÙ>IÔ"¯ß¥"Ä, ‹‚äëé»Ñ¨œFLiE4`~ð·(EÅ
¡ýhØ;Cß&ÂGz÷"¶S#OrË,£ÁÓ÷S·®·”¾ëï[m«¯«8‰+:ÛéÏs]*m©•Å–H
-ë¸È±‹u¬;ë°ÈO?€té†Ml9:É8�ACan;‘J;£²uNèÊÑmHà…ux1ÒR�š´™©êmI «þý(ð	¿àêæ¢n«Ö?úáAº&þZÐñ3�Õ¼Ðþï%v¿Þ@ó)ƒÀî~Åâ—¹ÀýZ(´…”mÉ›_/žŠþ?«–²endstream
+xÚ­XmoÛHþž_aàXùP)šÑ{€ý�6î5›^ëMÜ]m±�­q¬‹,ù,Ù©{¸ÿ~ä�#˶úìÁÄáÌpHù�c1pá'A脉LQâ;�+‚Ályæîaîg‚×Øf‘Ý]õ|rvþÒ‹‰“„2LæY±ãƱL²–ïáA„k�o^Ü
m¸Öß„ ⣸/n‡^d½O†"¶ÞÞ\�gïÞ�ÇoõìdgÒzñêr<ÝÒ´Ïr/¯~
+!¬Ë7/FW4uõ†Oz9ºF¾5yw;º~šüz6š´vum®‡FýûìÃ'w��~=s/‰ƒÁ#\G$‰,ÏüÀsßó§8»;û­Ø™Õ[{})\Gz¡ìq¦”}Î'ô¤§�ù˜ÅÐöbaM7yÑ’‰fÁ“«5º´Úæ™ZÇ�­€BÍyÛ¦ÌÔGו¥ÊÀ±‘ëYïju$Ñ^Ò·Z5yU2½&‰í"¼g¸à#oûAàD¾Û±èü-�$Žã~oÛ­D»+òÔ•~;‘L¢C_Žoßþ~}±z‚,W:®ÆÂ5	©×¨r›“Ë¥*
+©mºÎÓi¡hÔTô­Wj–ÏwÌ\ðì*m‡ëöSÝË�ut܃2 ½´ZÌÁVÛN7³O(h×uá†òòþHð«»²˜®@ŠŒœ(¾–ò2_×Í3ÚðÈ—›šM¬›Õ‘ðõ0†@iò%�{=TÛúv¥Ê»»×4HËŒˆ<(òéÜ«jÎÒ’ˆ)*ª4SÙÙç‹Cû<áÄ2Öæý4´Áa–ú¼ªÖ
ѯ¯þ|}ýüöòöýŸãËÉ«_Î!†ÏW³ZˆóM½>‡£/~úÏѪÿö{²sÒ…:†˜j�6t0L™}9q£v+ºjô{è[yC9ZJ+-´ã€Sª™ªët½£aÃì}Œ…œ“HÕ,¥lÔZ̦¥õQJ™Îy©�¤YÌóB±�‹|¶Ðià†ÝTúnñ:<OZy9¯ÖK>é´Ò ãyœýÀc35=¯˜ØÔ<;ÝÑ—î7ê»GÖZ
‡¢a§Á±>­ëùÑql
È,V¶Uº'Z|?r‚0ˆÀb4ôœAÀpÙTÁ0NȨsB¶ñš”<7gŸÆˆH"G†PSH>'x¡/tívõwBøfô~<ºí	ã^õ¾ºdÙd¡ô½$Éi·HWÓÂœ˜ò.�H<B¨­¾7˜&�(u*àlZîˆhªª %Í"å­à”ÚðX, Ø3¢òrVl2d€ñÀ˜î5Q*Ûjw¯ÊÛC¸[í�œ
+Ärì	^ÀâŠl>æÇNEâ‰Â2U7ëjקtL¡/¿'Ï,ÈʺV3´u¾®–E:UE�Ð$pD,å�*ÉBëü¾üRõFuäCO’øOøõ	áöbs#Ø
+î‘rÑsBᇈDýçROÝÓ„F]¬ ÔTK¢ËÍrª˜êh¨®J¬¹ÏöeéÔ 	j­ÉeºTY�%žë$‰ò*‡,�à® ŽBÌo'ŽL½&ÒÂ8wMyƒ0/«GæÞ¦
¯ ZIYBðfMTΛ)m\í
+¿Ï¯ß\•L=Hí`z¸Xb™
QÞ…m]k	ºu[Ös×›&/òNúVVé2)=m,vCžÐyŽ“œç0iòÜç<‡I~ó
¥Ë6,bÏÑNæiôD¥8§YJ+Óúh+ìÐU£ÚŠÀë1e©ÏZ´SªæI
 endobj
-1494 0 obj <<
+1511 0 obj <<
 /Type /Page
-/Contents 1495 0 R
-/Resources 1493 0 R
+/Contents 1512 0 R
+/Resources 1510 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1479 0 R
->> endobj
-1496 0 obj <<
-/D [1494 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-314 0 obj <<
-/D [1494 0 R /XYZ 85.0394 678.3493 null]
+/Parent 1489 0 R
 >> endobj
-1497 0 obj <<
-/D [1494 0 R /XYZ 85.0394 652.8222 null]
+1513 0 obj <<
+/D [1511 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-318 0 obj <<
-/D [1494 0 R /XYZ 85.0394 535.8888 null]
+326 0 obj <<
+/D [1511 0 R /XYZ 56.6929 725.1329 null]
 >> endobj
-1498 0 obj <<
-/D [1494 0 R /XYZ 85.0394 507.3968 null]
+1514 0 obj <<
+/D [1511 0 R /XYZ 56.6929 694.9784 null]
 >> endobj
-1493 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R >>
+1510 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1501 0 obj <<
-/Length 2554      
+1518 0 obj <<
+/Length 2294      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥koÛÈñ»…€8)iî.ŸAQÀçØMέãFÊ
½Ë} Ä•E˜"u")×ùõ�Ù™%)‰É¥-ü�ÃÙá¼vž–˜xð'&A膉L&Qâ»�'‚Éj{áMáìo‚iKä©~\\\Þªh’¸I(ÃÉb=à»^‹É"ûuê»B¸3`áMî®ç3GÞôOBðÙ¼ë�3Mÿõ°˜‰xúáî=àøtþéááƒ9]Ì@v §×ï®7éØg¾Wož	!¦W÷×7oéèí=Kº½¹šEþtñéãÍ|öÛ⧋›Eg×Ðvá)4ê÷‹_ó&¸à§ÏUILžáÅsE’ÈÉö”øJYLq1¿øgÇppj>õ¥ð\©B9âL)Çœ$n¨¤2Î\lôÌQa8Ý£¯tÝM^>"*˜Þ½rŸô§eF
-×{ŒF9]W�
-üCþuºev;ãéʻݕÎZº w¤Ëê ‘m€>$ÑôÈò5Ò®5}R6„uŠt©ó]h‰kH c†I›±ü)¿
Wmó¦éd}–ÒwÖßÍïð•^ÖdÇßÄ´™‰©±ବÁéÎØeƒ`û�Ñ‘n=5¨Çv6Ôoð»Ë[_
-pQX™ËŸ¡BxÞt÷´ª…p€'\<¡œ%=…‡jLAO¸€]¡�/õÓ˜ã™#kn´ì4ü
-ó®ÿmn©Rû¨Þž¨}U4z_¦M~ÐE1h¿	i¶é
$zMIî™Çgá’â
-U™²C«ÒÉrÔq˜S,ŒãÁÞ\àûý~?úìðÃb“cJ©.PÕ ~	u„!�ÒîócUa.™ÞxzÚ¤Ä0¡y/Û†äåJw´Ìue?7�	©(]
crIÚíRïëj˦À([
- åar�=‘OšeGn0å«ÁÂÏÖ°éfT;¯HÂ[ �Y·;#*p“(
-AŽùŠnâÕð`€7óì¹Å2t}O0Ó~´TÞN]ã3®Öuc4}cý²îƒ™¯¾«¹yãšeäÜ4Gø‘ëÇAô­¢Ûݵ¥ùhù=�è›Ò艔ïïߌåôÏzŸ¯_Œ–Hf¬E —Å!xtJ£N‡O‹Ç
-Òc³­GeÜÏo®ÕÇùÕüÝ•pÇôü¥Ö¹_0��É1ÂôÊÊ|CÄC!Œúe~W3(^Óón€bÝWØ—ùØ£Ç^ª'�#ë&%gù2¦Ìà\4
Š›MÇŽÌ´C¶ÙD©~›
fŽð€û|§Wö"ŽÂN—�¹
¼ª<K¡í–¶x)òѤ©2€RFƒµÆòP*çó¿ã‹ê¤à
õI
-Ø^bEý�ƇJˆ1|]¶yÑÈ[dg@�°ÑMÜC
ØblJ9
pø]×�€*Óë´- ¸›–à®…â¤ßb…�#c	@4÷¥:Î "�â¸Ï‡8²-	 š�³võϘ§DZ Û’Ç €iH
-*a·¸³òPázXîª\Ÿ�︋姖ùOÜQé ÿ<ŸÔ	‰DÒŽ5—�
-—”—m½¿™—CÙç�„Ó“‚ý [E•_nEÁqk Ý[ÁÔW­Rn»JPÕWVuj1Pt+»¤*ÞèðóƒÞïó,ÓÿBO¨Â\ù•èyx¸¹Ç6vòSˆJ`©Š"‰åHb×ÿŽßB¤›@�ÿât�
Çó_9À5®†�XtÓõ‡û[RV—‡œÚY¹¥F¦Ò}îðÖêKÆÄ“¹®oI§ËÕÕ“Šå~íg!¸ø[ÎÈ�8^W&ÿúßÖ`¡Tq,Çý$£ÖM`ÂJ¡�Ê?ÓÜþ¶t®ú
+xÚ¥YmoãÈ
þž_a N>¬�F¯Áµ@.ët÷ruÒØw@owq�åq,¬,yõâÔýõ%‡”,ÙêÞE>˜âp†Î�|8þÄ$ô,[Fî$ˆ\˳…7IvWöäÆþv%XÆl…̾Ô�Ë«ë{L"+ò²ÜôÖ
+-;Åd¹þ`ܽ»}ZΞ§¦ãÙ†kMMÏ·�Û·¿N…Æíünö–†ÞÎDÜÏn§�k,yž
'ˆ<¦	Á3ŸîXîOBñÑöì»ç©Œ>-§"4Þ�G¿<==êÑåôÓò§«Ù²ÛWï–¸©/W>Ù“5¸à§+Û’QèM^áöD9“Ý•ëIËs¥l9ÙÕâêÝ‚½Q=uÌ—ž-/t‚gºbÌ™n`ùA@ÎüóÔômÛXçU¥ó³:¾¨œXê_ñnŸ)+W5nóúÞqz‹ÙSÚ–'<©—YnÓjjJûVÒ©0ÖŠ™™ª˜-M™ÖGü
+�zçħßÐx·ø;1À} oàNiÕÔ¼@š'ª“åU“vúJ±TV¼§(Y¤Ù­TY;–¨o*fl@ö‰;ƒ»yž£wv2؉|CoNÅU‘Wh˜iM#»˜EÐ'òŒ]AÂÄUüøhÛN’ªœç 
§U+Ux®öŽ€*¢Ð<Mhƒ‘Hs®·Ì /kaZñKÓ©‚…Ì*}ÉÓüe¸KºÅ^•q�¹…î†XÑkú¡ñï"WÝDÍÁƒÑ„vºã´c`ÐÉg™ZÓwÏðÕ·)ëÎÖ	¤‘nHâX4´àkZmyL»•»½Ê«¸nWÓî
+J#ó¢V7ôù~C¢yQÑTäT˜ÅÓmÃä\TìO6ƒ(
+‡0h‹P
+ì«ÌJòÍ%xÇf,=ÇWñª8¨A怃¹LÆuà´¨æ"áš"㺩ÊkÐyÝ×}y‘<IèºFÄc lº.oxÃÊ@í·ÌW$1W])(éËÖ~y¾c�èv,Û.UrK‡Óª,ÓõZµü#ýBæÄ/ÅiíǧÙ«ØÙ—5<t¤?q\pŠ÷Mo\ŽA�¿p™Ý‚foEýz5ÄyN`…Π•ÒO��ó{²V凔ÊY¾£B{9ÄejrÓê:ÂÄÁe:U¤óÖŽÒêYÂ}Xèksq
Ç*´�¡cŸµ�<çwè–7TeþB?í
+ÂqgUÑRú-IFÎá©!65Dò¤6_ögQžÔjÚ¢”Ñ�ËöÊ”‘§SÖ²�LQɪÆ^½Ú4GŠ5`å
+Ò�ë?IQ¡8aX¯Š
îí’ðéÙ¨ªÏ^�Úbõ¥a�ë!¦ë°4X¹ëžNÆÓ¥gáøÈÓ·Ýa�ÿû¡ýô	¸"2�ñ,$m.P´F¡›¥wny÷"iú
 endobj
-1500 0 obj <<
+1517 0 obj <<
 /Type /Page
-/Contents 1501 0 R
-/Resources 1499 0 R
+/Contents 1518 0 R
+/Resources 1516 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1479 0 R
+/Parent 1489 0 R
 >> endobj
-1502 0 obj <<
-/D [1500 0 R /XYZ 56.6929 794.5015 null]
+1519 0 obj <<
+/D [1517 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-322 0 obj <<
-/D [1500 0 R /XYZ 56.6929 353.0332 null]
+330 0 obj <<
+/D [1517 0 R /XYZ 85.0394 519.9229 null]
 >> endobj
-1503 0 obj <<
-/D [1500 0 R /XYZ 56.6929 322.4681 null]
+1520 0 obj <<
+/D [1517 0 R /XYZ 85.0394 488.8874 null]
 >> endobj
-326 0 obj <<
-/D [1500 0 R /XYZ 56.6929 162.2421 null]
+334 0 obj <<
+/D [1517 0 R /XYZ 85.0394 326.6298 null]
 >> endobj
-1504 0 obj <<
-/D [1500 0 R /XYZ 56.6929 134.4864 null]
+1521 0 obj <<
+/D [1517 0 R /XYZ 85.0394 298.4037 null]
 >> endobj
-1499 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F41 1208 0 R /F21 930 0 R /F11 1441 0 R >>
+1516 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R /F21 938 0 R /F11 1451 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1508 0 obj <<
-/Length 2381      
+1524 0 obj <<
+/Length 2424      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥YmoÛ8þž_áœ|ˆU¾ˆz	îpۤ͢ÛæwïC[,‹N„È’+ÉñfýÍp(™–åÞM€pDg†Ã™‡C†OüòI¬|&“`%�¯W“åúŒM`ìÝ·<³Žiær½^œ½º’Ñ$ñ“P„“ÅÊ‘û,Žùd‘}ñÞ¼Ÿß,.o§3¡˜øÓ™
-™7ûÛ”sîÍ?¾¹|KCo?Þqu9ŸF�·ø|{	=ÀÅ$ÌãÂN½¾ù-$Æ»Ï77Ÿn§2òÔqý‘Ú××­ÐdúmñËÙå¢_Š»\Œëø~öå›d°ê_Θ/“XMvðÁ|ž$b²>”ôU e×SœÝ�ý§茚©cîS2öU,¢ÿ	1æ?•ø¡Òøï.]o
-MË©6ºlšÂ_–«\Ù««€;óƒÈ�5Rø I™ùvÎï˪\Mg!cÞ¿¨é2½BY`*8ÛO”fÞ—c.Óñí�™6Y—y©›ùÔ÷{£—m^•?P1`ÓBü›§eÃù�êWÂ]%ÆÓJn0Š
ÿ¼ù0sIt?öþòöòß´;8lA`D.sp�ˆbo—QiÑTUT;"ÛGMD>×ËÙ?lwUMGÚIË¥nšÁ¬÷w¿vjÚÇjÛÒ‡1	]¶õ‹I;H%™(ï+SlÑM&�¨´ªF\EŠ!.I1Y^O9hZ¶i:§þ²j‰xÎS">A\ÝÝ}°ãÆÐÚÁ›.“­¿�£íÉ{«•T}ßZ�õ¶VÔ¶±l`åÚ‡¥òSX ¢Ðçaü—°
-»ièhMCNª„²ßdfö†„™�ièë³kü´ ‘¯Be~i‹1!ÈÑùhÀ$£^ƒÁ(âQöÊÄÁ^C%âÀVPù&ôÓz“Ž ´TÀ(,_V­ÁI´p.A%£X0ØsR
-o§év û[Ú¯*2'œcÌl7­�­å
÷W‰cmÇþ±±KD!¬Å,Š"ï“Qjô㶀O2ÏÀôÚ=
*¡
»'Æ¡®ùèùû¼Lëâ+Ò{]˜í0náT±Ôu‰×‹ù¡òžÊjWIXZ©mÓÖƒøaª|ÃB|N¨po®BÐë
-™ŠAu»ÔÐÇyjpŠRŸ¹Rᥑ,îÒrפ6t˜Š[G6žx"ðF¥šê„™¥¶e‘?é!Áð¬!SÃÈk6z™c"é?AÕ˜»ñ<LJ×#[„ ã=Vn ´r¶Ï:ý‡y?=y.e‡¥ût{ý®{à³Ó|€ûÑÛÉcÕ@ŽFX%ðO1$é
?»pÀ>`áÙ}|qÁO^èz>cí#e`R[JÚÀY^ÎÈ58²†³w
éÁ¥»Ì£L$¬ƒŽÎ=뵆ƒ"3¯èÒ»^Y	ÔÐrpž9òÌHI-…9Úœ•¢ûÞ#øäÑàƈû"˜îè¼»ñµ�#ÛÅy·ö¾R¹¸XÁÏO>Þù�…•�qƒØNJ›
Ú:kòO½œàÿ$±K~úÿÎûBäË8'–…~,’¨3ÊTjhyÿ‡cÓÿNtendstream
+xÚ¥Y[Sä¶~çWø!UÇSÅ(ºY¶yc¯!•°`“‡lÌXÎzìٱ̈́üúÓ­–=cÈ©Z¨B-©ÕjõåSˈ€Ã¯"ÃL*Ó N5‹¸ˆ‚Õæ„÷0÷ñDxžeÏ´s½¹=ùñƒŠƒ”¥Fšàv=’•0ž$"¸Íÿ5’-@/®~3‹¥ŒxxóùêêÓõBÅá-
\\RûæâòQéb)„à*|ûÓùÕíûkÕ^Ôù»ß0ž_¾}ï¼»¼!âÃûóE¬ÃÛÏ×ïoÞþ|òþv8Êø¸ Ïñíä�?y�é>áL¥Iì¡Ã™HSlNt¤X¤•êGÊ“›“ÿG³néœùž¥N˜ ãÿÙÌ–¦‘žß–ËD±„ó²,ZÇA–'ûÇ¢Þ5F2Gñà])!XEݳ*&ˆ•dIœçÞßÑÂŽ3e‘ÑaMCHpÇq¾X^»¿àe#‹�–áÇ©‡`Ë80IÂb°*|+¤Bkå˜Æ´;ýÁ*nàÇ‹�
+ÞÕpÆ`tÌ^ðr,ÙÓÈQCìWÄ<f&–‘;ÃU™­Šê~±T2	ÛKÄO7¿þg

×P÷
+ƒ‰¢¢6óüv¡xøwK½/œËÒ3¶…—±ÉªÊîz×=Qggóne'
+4vÕ
³ˆÂ¢õ|Y¾D‹b€®ƒ<.dfU›ÝÃRiâ°^SÛ5î\Hfµp,FÔÇûÀ."ôR§ûvÿ�µD=-$ëÎ/„Û“zmMmîÛ;»ÆãÕ;¯Ðª®Ð4÷ý�@«£sš|ÚÚêææX“ù°õ
E[’Ùç!›F—6)“IšãXÿ¾ôÁD�Rùs€€ïKîãŒäq,)¡™ÒFŽ
×HÅbÄ•pÁ„œ#à>ö€Ûm·õ®¥Ž³ÛlYÜ'X^&�©rb=3�™±Yweù„¤�øpÒšÈÊ’Nˆ›$´UKœà}‹N®lîeÔ»MC2\@Â�ר*ÛX¢\ì ä<'��_”UùìÌaÉAHY×_»mÃæÒãÂ[f_8Ý�Êʦ&ªk¬¿£kŽv³

µž{“}õìß:»+úéýƒõFß-’°«*Ê:è×~<«¦»¬²mvWziÍSÓÚÍAù˜¥�îNù5¤Œ”
+­¹Ïœb9
ø#Ÿb/é=ã)5Þm�Ú

Ô•óPçðCtU“\0ßRq^xKÓJETn· ɳg­õ:8°B‚숻¬ýfv‡Ó¹¼'G›4\•„Ó²)rKÍÙÐY;S
+µW
+lÝì페A²îŒèyÏÉ‘ç0ÀW+»õyæ�€y³ƒíÖn;èÑÈ<å;:ôÏMŸN“ð<J�x” XxPn™~ÚÒÔ(UŒœìÊPœ!RLÃ0hŸmQWYI3_¤ÔUqi‹1!ÈÑéÀ$§QÂ(âÁøªt¾*�JµA5T±5,Ûm³˜V0ŠÔ3æõ¬DŽ€›)f<âzâwWÊpo]hÅj¡c
Q—ù(žLíq^?WWh
…m”ŽÔ-àâ®­Ä*Qª#m1�â8üä6uû£_À¨
©çðF½S€JiÂ;ÅYt¬>šþ®¨²Ýñ•Ù�-�?œYDÌY'òa¾€¥<è›(üZÕûŠH㥶M»ƒ ĬÄB>%X¸ëZ!Säë­(ô‰%¤$ªæ7x �€ÇZ¿÷ªÞlKÛZ¦hŠMQ¸u&ƒÅÈ3Ù‡ðŒöÕ&ü5«œfÛmY€+½‰a„‚q0±‘}ÜSµ&ên‰è*ðRÓz<î�Äá`’Nä!øaß¾-ýä Ñ†òמz“÷ÒÝ}<s,ân»Ð:u—'¶– 
ó»ÅšÚ{€a3ƒõ…gÝf»¶XueÖºÂLèå
¸"Ó •RC��A6ÑTA¸y4„ÜN,5„jHùÇÀÌ…7Å»Á¼@;ó6¯Ô£rBe÷Xؽï­=ê>Ø
pÉ=n‰Gjq,RVmGv>^ûBtê×Z;­¹UÄ™N ßà	ÌŒ†B5K“»{ÿj»=—þåxAÿ #ßT.Zàî³¢/ªÎ™dâÙ
+~È:ûw†€}JÑbâ�”%Iœ:µ~øt}ñ?>,c
+­€Eâ
Ø¡îÕíµ§ðá„Ãkˆa=ÃqvöNm÷�xá€øŸƒ™
+…ÈñÝÿÄ8|pÔ1SXRÍ–:ðÄRGõJ¹†y¦¹
 endobj
-1507 0 obj <<
+1523 0 obj <<
 /Type /Page
-/Contents 1508 0 R
-/Resources 1506 0 R
+/Contents 1524 0 R
+/Resources 1522 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1479 0 R
-/Annots [ 1511 0 R ]
+/Parent 1530 0 R
+/Annots [ 1527 0 R ]
 >> endobj
-1505 0 obj <<
+1515 0 obj <<
 /Type /XObject
 /Subtype /Form
 /FormType 1
@@ -6063,63 +6128,40 @@ xÚm”In1EOPw¨u€$ÅIg0²Êľÿ6¤¤êV5oʯÅésÀó�ή¯�ƒÖ×O²Î Ž¢‘ÿ¨#h8Çùø:„5?ù
 6\>RgÈbÏWÖ¹j[†�›
 WŒÏ¢®{6;»²þFÃÇñ÷ø]š¨)Õ/Ô¬Mu;pk;Ì©Ëdh<åE–ñ¬AÏw³ð¬±±Nê¦ó¡Ä½�t•‹ùD„™Â²]°Ä(�‡;�„ ·åŽ°Š­r²ÂÙÄLûˆ
T¥Í¡誋ŠŽt’¹w_=Î]ˆ‹=¦uSä÷—ä"ï±yl±‡µÃ-ËkHsŠöreOÚ³êvg›<7ºt,‡Ýe—;ãÒèЭ/I…B÷&ê(ýê³ö󻉨YÙ¹Ç,çkRÔšÚ'^
m"	^�˜h±�ÎW9AVªy­Â©/f�ýÆ"•œãûFy-Sng	\Çdª¼˜©Æ¥†Í}B©•µŒÎ$âw1.¶&�Øíþ²C¶O–ÃVç X×9g¹E{îÇ<•ãóP)!ÍZÜÅŸLÞª~ÑÔ'¯UâXLµüc“ÅXsЖõÚ¯½˜Ó’~òBL–§èªÆ¹O¦ºNZ�_[Èü.øšŠû*]3QôçÇñ!Ö-žendstream
 endobj
-1511 0 obj <<
+1527 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [377.8384 238.2889 436.8266 249.0732]
+/Rect [349.4919 431.1147 408.4801 441.8991]
 /Subtype /Link
 /A << /S /GoTo /D (ipv6addresses) >>
 >> endobj
-1509 0 obj <<
-/D [1507 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-330 0 obj <<
-/D [1507 0 R /XYZ 85.0394 463.8124 null]
->> endobj
-1510 0 obj <<
-/D [1507 0 R /XYZ 85.0394 428.0717 null]
->> endobj
-334 0 obj <<
-/D [1507 0 R /XYZ 85.0394 217.284 null]
+1525 0 obj <<
+/D [1523 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1512 0 obj <<
-/D [1507 0 R /XYZ 85.0394 184.4347 null]
+338 0 obj <<
+/D [1523 0 R /XYZ 56.6929 640.7425 null]
 >> endobj
-1506 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F41 1208 0 R /F62 1351 0 R /F21 930 0 R /F39 1151 0 R >>
-/XObject << /Im3 1505 0 R >>
-/ProcSet [ /PDF /Text ]
+1526 0 obj <<
+/D [1523 0 R /XYZ 56.6929 609.2714 null]
 >> endobj
-1516 0 obj <<
-/Length 712       
-/Filter /FlateDecode
->>
-stream
-xÚ¥T;sÛ0Þõ+4t�î*”O‰Êæ$Nê\Ïqm%Òr$ÇneIõ#Nÿ}A‘–åÆéÒã@€
-ˆRÔM²O
-
ÇÌ]:Br�‚óýIáLœ¯mÀŽµ¹z’>J€ñ��à�Q—Rˆ¥dGÊBÎø�@†l‚¸³l•¯×è¦2û0]æFúRU?·µ5ß­å³õXL§…õ¹ªVËt£‰ÁçY§|Ä
˜€XPѼûmž—~À±FmBie[›=µÆ3ò©òš¬ôÁÂJû¦–gÍ›Q¡‘·™çï\}ª–uUæåÆê©1e½XÖÅo#›ó—|µÎ³&jèýØ®7Ú(¼ô�‚Ô°ZŠÖ`ô"l"i™íÐ $HcA÷EBºªS8A˜T Ý;îs®ë¼ÌòÌä¢K¤O[Ìð¶ØXF…Wbù°­EÔÔƸå¯)¢ÍÿflVEµkk±«¶…}¨nW/‹,oPc»ÀŽá{ôæ7vˆ3ÝP¶½S4½cä™ÎC©Ùæ•&WK»ÅfnM�ê½e‘â`TD–F=˦ê쌞 2”I.¬/œ°�£‚l,¥Tãùáv<¸Ö£#įAàx)˜B†;m4G•<t…á…ù×Â߇<*Ѳ"vb¡ê�’±•¾IšàŒJÐ-tÔxšC°uìt0iã%úÞ”âôh91SH;6þ{‚¦»ˆ€+Åé[#énÇ 6)
‰‡o2ß�º·©ÿ
v[ƒ#endstream
-endobj
-1515 0 obj <<
-/Type /Page
-/Contents 1516 0 R
-/Resources 1514 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1519 0 R
+342 0 obj <<
+/D [1523 0 R /XYZ 56.6929 416.9256 null]
 >> endobj
-1517 0 obj <<
-/D [1515 0 R /XYZ 56.6929 794.5015 null]
+1528 0 obj <<
+/D [1523 0 R /XYZ 56.6929 388.3459 null]
 >> endobj
-338 0 obj <<
-/D [1515 0 R /XYZ 56.6929 769.5949 null]
+346 0 obj <<
+/D [1523 0 R /XYZ 56.6929 261.2322 null]
 >> endobj
-1518 0 obj <<
-/D [1515 0 R /XYZ 56.6929 749.4437 null]
+1529 0 obj <<
+/D [1523 0 R /XYZ 56.6929 232.6525 null]
 >> endobj
-1514 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+1522 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F62 1361 0 R /F21 938 0 R /F39 1161 0 R /F41 1218 0 R >>
+/XObject << /Im3 1515 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1522 0 obj <<
+1534 0 obj <<
 /Length 1913      
 /Filter /FlateDecode
 >>
@@ -6131,59 +6173,59 @@ xÚ�XQ�Û8~ï¯È£h\K²-û±½Ù[tqW,º³O×{Ple"Ô¶²‘=¹ù÷GŠ’gœn ¦)Š¢Hê#e¶ÉàÇ6U‘f¢Î7²ÎÓ"cÅ
 ¯“�Ä�`ÄЖœè•
 H�g‘…žEÎJŸ°ÕËûkŽ½.{²úöúâ-Tšz§mØÀ"'©�3V‡+úJZ•ø�?Õ“²Û¦t¾¦¿
 �,çóýÃì(êTÊ¢ºîUÞýò4KŒ_E‘â÷Ƶ¯�Qd{‘¡O�‹“‘
ä
 endobj
-1521 0 obj <<
+1533 0 obj <<
 /Type /Page
-/Contents 1522 0 R
-/Resources 1520 0 R
+/Contents 1534 0 R
+/Resources 1532 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1519 0 R
+/Parent 1530 0 R
 >> endobj
-1523 0 obj <<
-/D [1521 0 R /XYZ 85.0394 794.5015 null]
+1535 0 obj <<
+/D [1533 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-342 0 obj <<
-/D [1521 0 R /XYZ 85.0394 769.5949 null]
+350 0 obj <<
+/D [1533 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1524 0 obj <<
-/D [1521 0 R /XYZ 85.0394 576.7004 null]
+1536 0 obj <<
+/D [1533 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
-346 0 obj <<
-/D [1521 0 R /XYZ 85.0394 576.7004 null]
+354 0 obj <<
+/D [1533 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
-1525 0 obj <<
-/D [1521 0 R /XYZ 85.0394 544.8207 null]
+1537 0 obj <<
+/D [1533 0 R /XYZ 85.0394 544.8207 null]
 >> endobj
-350 0 obj <<
-/D [1521 0 R /XYZ 85.0394 403.9445 null]
+358 0 obj <<
+/D [1533 0 R /XYZ 85.0394 403.9445 null]
 >> endobj
-1526 0 obj <<
-/D [1521 0 R /XYZ 85.0394 368.2811 null]
+1538 0 obj <<
+/D [1533 0 R /XYZ 85.0394 368.2811 null]
 >> endobj
-1520 0 obj <<
-/Font << /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+1532 0 obj <<
+/Font << /F21 938 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1529 0 obj <<
+1541 0 obj <<
 /Length 69        
 /Filter /FlateDecode
 >>
 stream
 xÚ3T0
 endobj
-1528 0 obj <<
+1540 0 obj <<
 /Type /Page
-/Contents 1529 0 R
-/Resources 1527 0 R
+/Contents 1541 0 R
+/Resources 1539 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1519 0 R
+/Parent 1530 0 R
 >> endobj
-1530 0 obj <<
-/D [1528 0 R /XYZ 56.6929 794.5015 null]
+1542 0 obj <<
+/D [1540 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1527 0 obj <<
+1539 0 obj <<
 /ProcSet [ /PDF ]
 >> endobj
-1533 0 obj <<
+1545 0 obj <<
 /Length 3198      
 /Filter /FlateDecode
 >>
@@ -6196,47 +6238,47 @@ q@ÏÉÉ
 Ög�M±	q^Pב"Ü*ïJ¬}9ÊôÅ9u•½Ma®¨«„¬ÖbP„sÉ
dKFè±2dw£CF:ñPïBFã!¤C‘Ÿ·(9˜p@Ê@èë‹òˆq6F™‰xT¨âTD_ZÈœW¡¸8öõëýGz<i=Ô°…¼¦BNƒñø¸ˆ=º†s/�ÞÎß�0^pw$Vóz]®®;¼¿‡ä‚6žq)�^i·¥‘ºé«'Ìaüs¹Ú…ÞðøÉþð…`¤1ô¦«6å¶ì	ÞÆÚ×åüÜ/�Rü‹ý‘êb:ÅÅ#¡.³©k @;“‚®�*kÌÌkå7V°
 *3ëÛk
 endobj
-1532 0 obj <<
+1544 0 obj <<
 /Type /Page
-/Contents 1533 0 R
-/Resources 1531 0 R
+/Contents 1545 0 R
+/Resources 1543 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1519 0 R
-/Annots [ 1539 0 R ]
+/Parent 1530 0 R
+/Annots [ 1551 0 R ]
 >> endobj
-1539 0 obj <<
+1551 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [356.2946 363.7923 412.5133 376.6291]
 /Subtype /Link
 /A << /S /GoTo /D (address_match_lists) >>
 >> endobj
-1534 0 obj <<
-/D [1532 0 R /XYZ 85.0394 794.5015 null]
+1546 0 obj <<
+/D [1544 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-354 0 obj <<
-/D [1532 0 R /XYZ 85.0394 769.5949 null]
+362 0 obj <<
+/D [1544 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1535 0 obj <<
-/D [1532 0 R /XYZ 85.0394 576.7004 null]
+1547 0 obj <<
+/D [1544 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
-358 0 obj <<
-/D [1532 0 R /XYZ 85.0394 479.565 null]
+366 0 obj <<
+/D [1544 0 R /XYZ 85.0394 479.565 null]
 >> endobj
-1536 0 obj <<
-/D [1532 0 R /XYZ 85.0394 441.8891 null]
+1548 0 obj <<
+/D [1544 0 R /XYZ 85.0394 441.8891 null]
 >> endobj
-1537 0 obj <<
-/D [1532 0 R /XYZ 85.0394 424.9629 null]
+1549 0 obj <<
+/D [1544 0 R /XYZ 85.0394 424.9629 null]
 >> endobj
-1538 0 obj <<
-/D [1532 0 R /XYZ 85.0394 413.0077 null]
+1550 0 obj <<
+/D [1544 0 R /XYZ 85.0394 413.0077 null]
 >> endobj
-1531 0 obj <<
-/Font << /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+1543 0 obj <<
+/Font << /F21 938 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1543 0 obj <<
+1555 0 obj <<
 /Length 4062      
 /Filter /FlateDecode
 >>
@@ -6270,33 +6312,33 @@ s–Ö*hîžm­™â‰µ
 Ó�æÉ
 ›¬s짼h "”IŒ)%F*<zé“'â¡jÿÿÍ”àxÒ‡BvÉ
 endobj
-1542 0 obj <<
+1554 0 obj <<
 /Type /Page
-/Contents 1543 0 R
-/Resources 1541 0 R
+/Contents 1555 0 R
+/Resources 1553 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1519 0 R
+/Parent 1530 0 R
 >> endobj
-1544 0 obj <<
-/D [1542 0 R /XYZ 56.6929 794.5015 null]
+1556 0 obj <<
+/D [1554 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-362 0 obj <<
-/D [1542 0 R /XYZ 56.6929 165.9801 null]
+370 0 obj <<
+/D [1554 0 R /XYZ 56.6929 165.9801 null]
 >> endobj
-1540 0 obj <<
-/D [1542 0 R /XYZ 56.6929 136.242 null]
+1552 0 obj <<
+/D [1554 0 R /XYZ 56.6929 136.242 null]
 >> endobj
-366 0 obj <<
-/D [1542 0 R /XYZ 56.6929 136.242 null]
+374 0 obj <<
+/D [1554 0 R /XYZ 56.6929 136.242 null]
 >> endobj
-1545 0 obj <<
-/D [1542 0 R /XYZ 56.6929 106.2766 null]
+1557 0 obj <<
+/D [1554 0 R /XYZ 56.6929 106.2766 null]
 >> endobj
-1541 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R /F21 930 0 R /F48 1228 0 R >>
+1553 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R /F21 938 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1548 0 obj <<
+1560 0 obj <<
 /Length 3065      
 /Filter /FlateDecode
 >>
@@ -6312,39 +6354,39 @@ xÚ¥ZÝsÛ6÷_¡>En,˜ø 
^ŸR×iÝi“\âÎ=4�”–`‹cŠTHÊŽ§wÿûíb
’’(¹£
 ¬_²Õº°n–Ô§X;‘LjÉRÓaXΓçB}ƒY™š~E•qùÍX|ë$Œ¤Ï\tc©ÕƒZN‰
 覷=èv/P>ÂQl­'æ^r) \œùòåË3ŠKU=ú”¸´Eq¾¶u÷”ú„ËÍïe‚€=éýƒqï!C§Pü°Sœ;bH›4†.¦•¤ÿ(|í:‚bƒŽkw_á(B™QAû‚µÎŸ\oà.©¼ ÁÒ¡ÈÁÁÝ9½2ú¹ÿˆ¥L
 endobj
-1547 0 obj <<
+1559 0 obj <<
 /Type /Page
-/Contents 1548 0 R
-/Resources 1546 0 R
+/Contents 1560 0 R
+/Resources 1558 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1519 0 R
+/Parent 1530 0 R
 >> endobj
-1549 0 obj <<
-/D [1547 0 R /XYZ 85.0394 794.5015 null]
+1561 0 obj <<
+/D [1559 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-370 0 obj <<
-/D [1547 0 R /XYZ 85.0394 730.0812 null]
+378 0 obj <<
+/D [1559 0 R /XYZ 85.0394 730.0812 null]
 >> endobj
-1550 0 obj <<
-/D [1547 0 R /XYZ 85.0394 700.9798 null]
+1562 0 obj <<
+/D [1559 0 R /XYZ 85.0394 700.9798 null]
 >> endobj
-374 0 obj <<
-/D [1547 0 R /XYZ 85.0394 216.5924 null]
+382 0 obj <<
+/D [1559 0 R /XYZ 85.0394 216.5924 null]
 >> endobj
-1551 0 obj <<
-/D [1547 0 R /XYZ 85.0394 187.7778 null]
+1563 0 obj <<
+/D [1559 0 R /XYZ 85.0394 187.7778 null]
 >> endobj
-378 0 obj <<
-/D [1547 0 R /XYZ 85.0394 127.6814 null]
+386 0 obj <<
+/D [1559 0 R /XYZ 85.0394 127.6814 null]
 >> endobj
-1552 0 obj <<
-/D [1547 0 R /XYZ 85.0394 101.3894 null]
+1564 0 obj <<
+/D [1559 0 R /XYZ 85.0394 101.3894 null]
 >> endobj
-1546 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F21 930 0 R /F22 953 0 R /F14 956 0 R /F39 1151 0 R >>
+1558 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F21 938 0 R /F22 961 0 R /F14 964 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1555 0 obj <<
+1567 0 obj <<
 /Length 2310      
 /Filter /FlateDecode
 >>
@@ -6356,40 +6398,40 @@ LHE(ã�Íã{¦˜…“«µš¼«á‰ï•ïÜClùÖœdC¶ïŽùøÿÌD
 Œ[†,Šñ6ËËãgÛ¸¸¤þ¥q¤QjÜ%ć*[›šV®~ ¥l¹$4t�µùÊÈ·K°Yìv¥)Hrk‘å9AǦÑØRñVŽéh×4­Û•ÞvSsè€ãsqÏŽ×ñ%Š(î	z9Jwâ‘AQ”<#2òqh›†M5µ«Ÿ‘[^Z›hºVnÇaZXAŽ ËfØù»Õw-ËoúLþ°û-RŽÅ‡Ë£¶Õ2!*”ÕŽ€vmQíÃL1}\‚w^Çî¿P‚	DC!¢§%˜@ôLÛä
 ós.ÔÓ‹c–Šš¿è‡g¹Õlt^ wÃ"n
Ë ¯Àݬ»ü�“÷Áê·D¶î„o¶
‡’7ï²×î²›õhøß¿{éÏ®éBÔâÃÕåã²òøð:Æ`[‰â	È*bI”¨±ßßøäYÕé¯}}öÄ ­Dú…˜gñq‚�¨�!.dU JN÷³ …òHÿ’ Q>endstream
 endobj
-1554 0 obj <<
+1566 0 obj <<
 /Type /Page
-/Contents 1555 0 R
-/Resources 1553 0 R
+/Contents 1567 0 R
+/Resources 1565 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1561 0 R
+/Parent 1573 0 R
 >> endobj
-1556 0 obj <<
-/D [1554 0 R /XYZ 56.6929 794.5015 null]
+1568 0 obj <<
+/D [1566 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-382 0 obj <<
-/D [1554 0 R /XYZ 56.6929 730.9277 null]
+390 0 obj <<
+/D [1566 0 R /XYZ 56.6929 730.9277 null]
 >> endobj
-1557 0 obj <<
-/D [1554 0 R /XYZ 56.6929 704.9004 null]
+1569 0 obj <<
+/D [1566 0 R /XYZ 56.6929 704.9004 null]
 >> endobj
-386 0 obj <<
-/D [1554 0 R /XYZ 56.6929 236.9993 null]
+394 0 obj <<
+/D [1566 0 R /XYZ 56.6929 236.9993 null]
 >> endobj
-1558 0 obj <<
-/D [1554 0 R /XYZ 56.6929 205.1553 null]
+1570 0 obj <<
+/D [1566 0 R /XYZ 56.6929 205.1553 null]
 >> endobj
-1559 0 obj <<
-/D [1554 0 R /XYZ 56.6929 146.386 null]
+1571 0 obj <<
+/D [1566 0 R /XYZ 56.6929 146.386 null]
 >> endobj
-1560 0 obj <<
-/D [1554 0 R /XYZ 56.6929 134.4308 null]
+1572 0 obj <<
+/D [1566 0 R /XYZ 56.6929 134.4308 null]
 >> endobj
-1553 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F21 930 0 R /F22 953 0 R /F62 1351 0 R >>
-/XObject << /Im3 1505 0 R >>
+1565 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F21 938 0 R /F22 961 0 R /F62 1361 0 R >>
+/XObject << /Im3 1515 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1564 0 obj <<
+1576 0 obj <<
 /Length 2419      
 /Filter /FlateDecode
 >>
@@ -6407,45 +6449,45 @@ b%C{1rŠ
 -ez»„t˨ޘ®Ìšúù¦cVúÀ
á}IᎠQýÈ¿hS7ÖÙË‘§íøzž»\ê&xÓ8šfÈzs÷#gÁã»|!þPy(3�I�Ó&˪ÁÆ="…¯à.ù$¬Hð³ö(
†u“¶Yäå£ß*XÏ¥¸L}¦ÿRŠ¬&³f^cß;±£;`38=´¶œÞ£.6¾*q¬^yøÃQJ ¤I�}?ø¤§I`²+Kv›:êænc°®xXô^wqZÙ¡dßl™ÿÝhÿð(!Û—!ØË]uÊ�è˺#¢H
 :n�Ñž[Û»¯»b›[û’:÷øÀ‚¹Ü®¸r`€Ä˜}ŸQæ2­ àç¬zÅOûÏLbS]	$B	ä¿Áßn^ZØÁÆ4¼m¸lê¹n9ÝGœ
7¬Á–ÿÉi÷Ÿ½wùΑ›¥„DK�¥Õ_Â2í
8Ð�«Ã.÷Õ²éxo:Ÿ·þ°uÇ=–mO1NéP	ŠE.|—ëÝa‘ëA‰Ú—AkÐ!xñ~Búˆþ¹Jv‰Oe�}…Žb¯çþãËæ¿‚@w˜o+�s¡Ü™¤xr•Á#•áz@ôÿ
þ¬Žendstream
 endobj
-1563 0 obj <<
+1575 0 obj <<
 /Type /Page
-/Contents 1564 0 R
-/Resources 1562 0 R
+/Contents 1576 0 R
+/Resources 1574 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1561 0 R
+/Parent 1573 0 R
 >> endobj
-1565 0 obj <<
-/D [1563 0 R /XYZ 85.0394 794.5015 null]
+1577 0 obj <<
+/D [1575 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-390 0 obj <<
-/D [1563 0 R /XYZ 85.0394 513.3136 null]
+398 0 obj <<
+/D [1575 0 R /XYZ 85.0394 513.3136 null]
 >> endobj
-1566 0 obj <<
-/D [1563 0 R /XYZ 85.0394 488.974 null]
+1578 0 obj <<
+/D [1575 0 R /XYZ 85.0394 488.974 null]
 >> endobj
-394 0 obj <<
-/D [1563 0 R /XYZ 85.0394 420.2055 null]
+402 0 obj <<
+/D [1575 0 R /XYZ 85.0394 420.2055 null]
 >> endobj
-1567 0 obj <<
-/D [1563 0 R /XYZ 85.0394 390.0916 null]
+1579 0 obj <<
+/D [1575 0 R /XYZ 85.0394 390.0916 null]
 >> endobj
-1568 0 obj <<
-/D [1563 0 R /XYZ 85.0394 312.7536 null]
+1580 0 obj <<
+/D [1575 0 R /XYZ 85.0394 312.7536 null]
 >> endobj
-1569 0 obj <<
-/D [1563 0 R /XYZ 85.0394 300.7984 null]
+1581 0 obj <<
+/D [1575 0 R /XYZ 85.0394 300.7984 null]
 >> endobj
-398 0 obj <<
-/D [1563 0 R /XYZ 85.0394 159.3 null]
+406 0 obj <<
+/D [1575 0 R /XYZ 85.0394 159.3 null]
 >> endobj
-1570 0 obj <<
-/D [1563 0 R /XYZ 85.0394 131.3824 null]
+1582 0 obj <<
+/D [1575 0 R /XYZ 85.0394 131.3824 null]
 >> endobj
-1562 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+1574 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1573 0 obj <<
+1585 0 obj <<
 /Length 4330      
 /Filter /FlateDecode
 >>
@@ -6469,48 +6511,48 @@ epc	.ѯs±“YGþóêpŒÕr:q#"OÎr'tå-½ý"„JÈVÆr°‹ç¬¨Î€õ|bE‘¢£
­i=k·ÕÀÑ ©„zÂ
+?��l
 9ѽ1W·.ýU¥Q^^‡«ltsiçÛ×þzÖ`šX°ÏxÀíQºº¢¶ª;Ïòxš!ºÄ¢W‘ƒpÇ€~1\Má�™$�¿ »à…Kq˜x•Ò/Lå6I“«“4ý­€ûdè»"ÃÞ¿N©+Žåã8èð?aR‹ÌXéÊ™T~oñ?b´ÿ�@"›ýªJþCÌw»¤�
 kþï%A\uWo*´>¯O¦—u†ÿ
•HL²Èüÿ£Õ��†xB…8‘i5EAƒLáj”:â<üGÖ1ëÿnI”endstream
 endobj
-1572 0 obj <<
+1584 0 obj <<
 /Type /Page
-/Contents 1573 0 R
-/Resources 1571 0 R
+/Contents 1585 0 R
+/Resources 1583 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1561 0 R
-/Annots [ 1575 0 R 1576 0 R ]
+/Parent 1573 0 R
+/Annots [ 1587 0 R 1588 0 R ]
 >> endobj
-1575 0 obj <<
+1587 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [55.6967 387.5149 256.3816 399.5745]
 /Subtype /Link
 /A << /S /GoTo /D (rndc) >>
 >> endobj
-1576 0 obj <<
+1588 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [268.5158 387.5149 332.4306 399.5745]
 /Subtype /Link
 /A << /S /GoTo /D (admin_tools) >>
 >> endobj
-1574 0 obj <<
-/D [1572 0 R /XYZ 56.6929 794.5015 null]
+1586 0 obj <<
+/D [1584 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-402 0 obj <<
-/D [1572 0 R /XYZ 56.6929 692.9565 null]
+410 0 obj <<
+/D [1584 0 R /XYZ 56.6929 692.9565 null]
 >> endobj
-1328 0 obj <<
-/D [1572 0 R /XYZ 56.6929 660.5438 null]
+1338 0 obj <<
+/D [1584 0 R /XYZ 56.6929 660.5438 null]
 >> endobj
-406 0 obj <<
-/D [1572 0 R /XYZ 56.6929 112.3379 null]
+414 0 obj <<
+/D [1584 0 R /XYZ 56.6929 112.3379 null]
 >> endobj
-1577 0 obj <<
-/D [1572 0 R /XYZ 56.6929 85.6994 null]
+1589 0 obj <<
+/D [1584 0 R /XYZ 56.6929 85.6994 null]
 >> endobj
-1571 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F21 930 0 R /F22 953 0 R /F48 1228 0 R /F14 956 0 R >>
+1583 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F21 938 0 R /F22 961 0 R /F48 1238 0 R /F14 964 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1581 0 obj <<
+1593 0 obj <<
 /Length 2372      
 /Filter /FlateDecode
 >>
@@ -6525,67 +6567,67 @@ gRLöõ„ÝáÉC)’g~.™‘	R
‹ë„zÎÍË\D€úQQy($-ËåßÍ®Á2x{Œ
{Çöˆ‘ÃU?–3ü‚¼
Š:åN)"B®Ni
 q„Ìc–!l4+׬‘¢oT¸oFˆ'|7búz
EF˜öÉ],m“¨Ü–ˆTmË`aÁUÔr¢óþùêÈæ.~Áúçƒq\Á ™,c߉�WÙaìÛÖ
ؽ!OdFÙ1ÔÇLðC
4�ѶbD‰®6´�"ÈÍG¢Vy,ê3ö.B–`‰ `ΠryoÈêCŠÓ�%lK0fz0fQ€f+b%µ„-«Y¼Ù˜�:n¡ö7á×}�?¸¿•Óvr Ú.æmµï·¸£m¡èÛbm_Jú…ÄœIc‚(Ä�m f"ÊøÖ¦Xì[CEýôä-úiŒaïhìûaLA½jÛóCa?#Fß0¾bÁ6 à÷<í$E¤Ç¼ðèë¤]áî£}8.Ô
„„G{Z�ÇZøül«"/sw—!ôe.õ{úMþo3� Ç
w³rùS›]ªÂ_}oz7º]mf6›9¾þèä+Š½C>ؼ Æ–aín¯¨ÔöžÓ¤)	N­Çj{I6UoÝé5ì4Ý”=Ûš‘,yõX�¶eæaë	y®|§u9BÝÁõçéPÄ¡ÆÇÇ�]ƒÇ´�Íà«^Ü�ñÒÉVÕ§ï)�÷fJlJ©Í;w8EeÞ¢þ|Ïc¹»Ñ)Odæß
 ­ù|ƒAЊËXuLYÎÃIï·ÿ“sÊú_—0‰Äendstream
 endobj
-1580 0 obj <<
+1592 0 obj <<
 /Type /Page
-/Contents 1581 0 R
-/Resources 1579 0 R
+/Contents 1593 0 R
+/Resources 1591 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1561 0 R
-/Annots [ 1586 0 R 1587 0 R 1588 0 R ]
+/Parent 1573 0 R
+/Annots [ 1598 0 R 1599 0 R 1600 0 R ]
 >> endobj
-1586 0 obj <<
+1598 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [406.6264 524.1437 456.8481 536.2033]
 /Subtype /Link
 /A << /S /GoTo /D (tsig) >>
 >> endobj
-1587 0 obj <<
+1599 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [140.5805 512.856 196.7992 524.2481]
 /Subtype /Link
 /A << /S /GoTo /D (controls_statement_definition_and_usage) >>
 >> endobj
-1588 0 obj <<
+1600 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [103.6195 470.0794 159.8382 482.1391]
 /Subtype /Link
 /A << /S /GoTo /D (controls_statement_definition_and_usage) >>
 >> endobj
-1582 0 obj <<
-/D [1580 0 R /XYZ 85.0394 794.5015 null]
+1594 0 obj <<
+/D [1592 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-410 0 obj <<
-/D [1580 0 R /XYZ 85.0394 769.5949 null]
+418 0 obj <<
+/D [1592 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1583 0 obj <<
-/D [1580 0 R /XYZ 85.0394 749.3189 null]
+1595 0 obj <<
+/D [1592 0 R /XYZ 85.0394 749.3189 null]
 >> endobj
-414 0 obj <<
-/D [1580 0 R /XYZ 85.0394 679.8163 null]
+422 0 obj <<
+/D [1592 0 R /XYZ 85.0394 679.8163 null]
 >> endobj
-1584 0 obj <<
-/D [1580 0 R /XYZ 85.0394 652.1211 null]
+1596 0 obj <<
+/D [1592 0 R /XYZ 85.0394 652.1211 null]
 >> endobj
-418 0 obj <<
-/D [1580 0 R /XYZ 85.0394 573.4726 null]
+426 0 obj <<
+/D [1592 0 R /XYZ 85.0394 573.4726 null]
 >> endobj
-1585 0 obj <<
-/D [1580 0 R /XYZ 85.0394 542.9681 null]
+1597 0 obj <<
+/D [1592 0 R /XYZ 85.0394 542.9681 null]
 >> endobj
-422 0 obj <<
-/D [1580 0 R /XYZ 85.0394 335.1831 null]
+430 0 obj <<
+/D [1592 0 R /XYZ 85.0394 335.1831 null]
 >> endobj
-1589 0 obj <<
-/D [1580 0 R /XYZ 85.0394 307.4879 null]
+1601 0 obj <<
+/D [1592 0 R /XYZ 85.0394 307.4879 null]
 >> endobj
-1579 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F53 1303 0 R >>
+1591 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1592 0 obj <<
+1604 0 obj <<
 /Length 3489      
 /Filter /FlateDecode
 >>
@@ -6610,33 +6652,33 @@ vk^)úåDa%“…Kå�ãVYH13øŠmG+4ÝtÝM9”\k
 ü“Ål7·5Ú'}Á¯"´ú‚HcÀÀž¢í¶dÚ¼Œ~?Ú×í°¤jç=U}ô#Í›ªs—QqÏùw2Eš<\{ðõl$a@Z)ĉ+&9¹b’ók$0L’Óë#Ép2
 kî²Úc¯0¹¿C8_Pø;v! ¹(Éï3S|µŒ@x"BÉ_–
IJ,Ç÷xc$†âÖ•Æ'Ëýн.ô'
&
 endobj
-1591 0 obj <<
+1603 0 obj <<
 /Type /Page
-/Contents 1592 0 R
-/Resources 1590 0 R
+/Contents 1604 0 R
+/Resources 1602 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1561 0 R
+/Parent 1573 0 R
 >> endobj
-1593 0 obj <<
-/D [1591 0 R /XYZ 56.6929 794.5015 null]
+1605 0 obj <<
+/D [1603 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-426 0 obj <<
-/D [1591 0 R /XYZ 56.6929 769.5949 null]
+434 0 obj <<
+/D [1603 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-1594 0 obj <<
-/D [1591 0 R /XYZ 56.6929 749.2381 null]
+1606 0 obj <<
+/D [1603 0 R /XYZ 56.6929 749.2381 null]
 >> endobj
-430 0 obj <<
-/D [1591 0 R /XYZ 56.6929 540.3599 null]
+438 0 obj <<
+/D [1603 0 R /XYZ 56.6929 540.3599 null]
 >> endobj
-1595 0 obj <<
-/D [1591 0 R /XYZ 56.6929 517.4049 null]
+1607 0 obj <<
+/D [1603 0 R /XYZ 56.6929 517.4049 null]
 >> endobj
-1590 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F39 1151 0 R >>
+1602 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1598 0 obj <<
+1610 0 obj <<
 /Length 3318      
 /Filter /FlateDecode
 >>
@@ -6651,29 +6693,29 @@ Sÿ&t«�&b_­À’‰ÌG)MœJH•œÃBÇe^0�CÉóèX
è ùÂl�Âd 0�—AÎÚ¢#h-Jʯ�‚£Î4^Ñ0FBï¹*YC	g’×±
 ˆü"Š¤{'BEc„LåEiÇ3¢�å Y=ˆ&Òñü¹D6u;iÖXûÖŽp5ów/ÖÂÙÁg¸:sNjYR0ß×I�µ|à†ÀË¢9�¡\ˆy˜°õB^î|�­�ÝáØ¡æ•œ¤àå/Pú«—öP,Ë5Wgùh¡yIýÞ@FÕœRjþö¢Fdôp¸ïCi"=	åò7wÎolƒ8óÇ«6�‡]jw]b˜ÁE_­ëú«÷¡
 au–z¢�³(½¤¼ÿµÕSÒÿ:[)Žendstream
 endobj
-1597 0 obj <<
+1609 0 obj <<
 /Type /Page
-/Contents 1598 0 R
-/Resources 1596 0 R
+/Contents 1610 0 R
+/Resources 1608 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1561 0 R
-/Annots [ 1600 0 R ]
+/Parent 1573 0 R
+/Annots [ 1612 0 R ]
 >> endobj
-1600 0 obj <<
+1612 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [173.6261 273.4719 242.2981 282.8815]
 /Subtype /Link
 /A << /S /GoTo /D (the_category_phrase) >>
 >> endobj
-1599 0 obj <<
-/D [1597 0 R /XYZ 85.0394 794.5015 null]
+1611 0 obj <<
+/D [1609 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1596 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R >>
+1608 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1604 0 obj <<
+1616 0 obj <<
 /Length 2400      
 /Filter /FlateDecode
 >>
@@ -6689,1981 +6731,2001 @@ kü"YS•Í·<Ê&À=b¿*MÈ*£P˜TJ–`yœÒ[ˆP!GrUí÷.áG‘—î&
^Ôæ_ïL¿ÇÆ®oÚq4Á‡Ë“±~žÎ
 ª÷.k}ü
“sgó'í—<œ_÷§�^G4Ξ�ÅÄñÛ+‡ôÍð8‚¿yõ5§î!�±×õæû¯ò½šª†ç.;ÁÁ™O	ðôÜ=4­³ªŸzºf�KeÁ“Þ bœ–£æ<5LzÇD/µHÂ~šÃŒ‡ìB׎çæ)Ïù ±'2ÄŸ[/±<
S½]’À¹AÆ4 rb=Eáé4r5ÈŠAÔ×vü 0Bè§,/²».†ŒºÄpm(,î
 ;Ízm×c?Ú¾@´€Ú6âÁÃO�B¤3Ç"ÔÐÚ?ãéê–H‚äì¥ñÿ;åÁ^ju¬õãй
 endobj
-1603 0 obj <<
+1615 0 obj <<
 /Type /Page
-/Contents 1604 0 R
-/Resources 1602 0 R
+/Contents 1616 0 R
+/Resources 1614 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1608 0 R
+/Parent 1620 0 R
 >> endobj
-1605 0 obj <<
-/D [1603 0 R /XYZ 56.6929 794.5015 null]
+1617 0 obj <<
+/D [1615 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-434 0 obj <<
-/D [1603 0 R /XYZ 56.6929 520.4669 null]
+442 0 obj <<
+/D [1615 0 R /XYZ 56.6929 520.4669 null]
 >> endobj
-1601 0 obj <<
-/D [1603 0 R /XYZ 56.6929 495.6849 null]
+1613 0 obj <<
+/D [1615 0 R /XYZ 56.6929 495.6849 null]
 >> endobj
-1606 0 obj <<
-/D [1603 0 R /XYZ 56.6929 178.7136 null]
+1618 0 obj <<
+/D [1615 0 R /XYZ 56.6929 178.7136 null]
 >> endobj
-1607 0 obj <<
-/D [1603 0 R /XYZ 56.6929 166.7584 null]
+1619 0 obj <<
+/D [1615 0 R /XYZ 56.6929 166.7584 null]
 >> endobj
-1602 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R /F21 930 0 R >>
+1614 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1611 0 obj <<
-/Length 3175      
+1623 0 obj <<
+/Length 2566      
 /Filter /FlateDecode
 >>
 stream
-xÚÍZKsã6¾ûW¨j‘+ƒ
�ssü˜u*cÏÚÚªÝMr EØf
E*"e�óë·
H”L‰™OUìšx£Ñ�¯â#ÿ|”¨ˆÉ4™4Žãj4›±Ñ´½?â¾Ï$tšt{ý4=úñBšQ¥ZèÑô¾3W±$á£iþëøôŸ'§ç7Ç¡ØXGÇ¥Ùø§Ë«3ªI©8½¾º¸|ÿc�§—×WT}s~q~s~uz~<á‰â0^øö¸¸ü在÷7'>œÜÿ>ýùè|º>K÷¼œI<ÈG¿þÎF9ûç#É4Q£gø`OS1šÅJF*–2Ô”G·GÿZOØiuCûø3q¡äh"“(V*Ù¿,-Á`YOr¥Jí®:áÒÀLïDéˆ
¹¾Á;wÂc%Rª‘Qi¤¥�îRfuõcâ
¹Dg
-&€9Lû3<ö¹ç ½°N}'@Öš¥ã:�€ÛJ£6ª…}Ș1.‹@5«ù<[¾Ð‡³ŸPfeSûŽõÃC†¸æJbÓ®p£Éšï{UI$WágYkjXžsN€¶p;•‰ØfþôÑmNªÍøÒãP{JF5
éÔ¹
C™QÃøBÞ—ëÜævéàÎX‘J‚¹½ÏV¥Ÿ²hûPXÇÛx…wzçôšC
-ð¥”<ˆïª,ûØÃ#˜ó˜U•=d‰;*ùujþm-1‘Jä %æ:↑%®lû\/?
Ú�+ß�l0`f貶�Íü�]?c‘É°Ò,Ž÷Ú½Zä ÃËXÎbF,£1‡øÕÙÈߘ_*I x“r€_*‘PiÚáפÁ ¬h‡1Óɤ§¬Ü‰˜s[¡2 
_€º‡x3^§<‰ø"yCör[¦†ƒàv«°˜"+8ü²
-µ½Uë!‹0)Î~ÌÇä¨SwN‚žð±ªJ@O}&±H:|�‘=;„3qðLõÂ'‹`îÇÌAð‹ÖV¥‰L¶¡…c zX›÷²�˜Èí‚HÜ‹#À�†:ºîE½lýÂmHˆâ;_}ù‘6˜å¹Ï¼øÔÉžõqFtæïüÎn\¾òZ,…_Jòõ±7 LßÏã?¬ÝyYX@^ åàŠ>ïÀâ€À};'Ã
-n‡݇[‰Ê	áàç™m
-™SðXf~†ÌOÕØ^„òSì{بVã­’FtÔâqt:žP5(×=`÷½B3ñšo Î-S;¨Ä5o×èñ9fÈzöFƒ€ÎŠÊUc‰ÀÎÃLÒ ~zú‘ˆõP’oÆL×cÄzÌÙõ¦6r{~Js^ÂÎ}×E<$�<"¡±~nlpXêq
ü>=Ûô;}´³ON3±å¬hPƒs·–ë³;{J£°C¿µºo]rÃI'a]äã—¦-ª�Û…–mm؈´Øˆ4÷샺€”´?
-ÁwUÅ/‚á†Ð¨Í³úÉn€]Ê]æ	Kz]G*¥´¬"
-P2a¤k*ɱ÷8µö±n¶ÞH¼7Ï!Ú
YëíGË"Ó¹�¯»áo*4,f"Ó!™a
-‚-åíª-탻ÎI]•ÃI€³u7äØ
¢ìåDB<òKýÐPËÆÙœP�Ù“%Ê…TŽÂô1\ÄŒ2­r»úÏÙõ‡“K÷[	ã”…Òá!Ìt¼(}SÂÐ{¯~uP×ö§^3j{d(ë‰*�Ù&IJÃÜ3qÇ,ÄÈEµõ
NÊgNkÿ‚×´«;¢þ\¿üå"/R¹ýÚ¹ú·PÁôü¢Ÿ"øQ"¥M ì3²i¼Å$÷qÄ°Qs5Óác:SAø ÎP[‡½kêëã1=^”Yáûº_; ‘¯z­¹útÜs¨m*œ($ï¡�JðR×TT…S¹ºõ`’è-‹ê:tÌXêâÕ‰½³>/¢Æ7§D
+xÚÍZKsã6¾ûW¨j+W"‚çæØò¬S3ö¬­­ÚÝ$Z¤%ÖP¤"’ö8¿>Ýh�¢dJÌ”=UcâÙøºÑý5(1âð/FF3®Bo„Ó\èÑ|uÂGh{"\ŸIÓiÒíõóìä§KŒBúÒÍ:sÆ�£Yüëøü_gŸfÓÛÓ‰Ô|ì³Ó‰öùøç«ëª	éq~s}yõþ?·g§�7ž]Ý\Sõíôrz;½>ŸžN„ÑÆK7Ã�
—W¦Tz{öñãÙíéï³_N¦³v/Ýý
+®p#œüú;Å°í_N8S¡Ñ£'xáL„¡­N<­˜ö”jj²“»“·vZíÐ>ü<.˜�Z�&Ê0OksxYZ‚ò®(µÞ_u"T
+O`
P†¯˜’F˜#xJ �Êc YèùEë|Uó%„ª!H?–Ñ"ÁØ'$î¨ÑBw9ÈBC0fõM¬€”„žt½ž"7g�G÷H{ìü=ã¤J6«4oªáP`´�ºQà¯v¢î<‹J˜L9mÛ'8å…�©âi™bÄWä¡È
+§ôv¼ùã¦öÕ”tþ Î
+ψZâU¨/Û¹Š“�¥;?b…!–âä!ª37eZõ±°N´qÞ.è‚ÓK„4ðK¥Dc¾u–õÁ#˜jÀYFyžóÄ�#ùºcþm=±�L5艅ÏDÀÉçIõTl>ú�k×�|0pf›èó¶a¾çÐÏ9ó¥"V>÷˜ît×ëŽÆpÆòž3�d4æ^A¾c¼´1�¼)5€—%“:;xMJLÂÒj˜3�­AzŒ²½Œ9Nò´©l˜€SÇW0�î&Þ.Ÿñ¦äëj;Ä;Œ6„/6xe¡
¬Á=Ê«`ë›ÂûÆwëdŽüÕ¢ö´� øÚÌANwYÔYܤ¾ôlƒ•uŬÏgŸ�§ö”¿mªz
Nß30­jɶÚäm¬é‰w>=_4Îúð•a<-IÁíÛ¹m�uO2¥¤Þ5q„E!Î~*ƦC»O"žðRçp§>
eÀ¤'MGÀgÙ#!h,ðš¸T¬ÝU̽Œ,!€¨˜$¹£F
g¡Qf—XX
+*¢,¶
+jИ6¶=`œp½šfšl Î.o‡¤‹Ü;¨Ä5ïÚ	üñïÇzd£Á(gNϺL¨€3L›¸" ~vþ‰
+íPoÇÌÚ1²sq³mAî¦ç4çÍgìܧ.Âx4b
+CcÝÜØ`™>Ôãø~~±íw¾LæŸíÉÄ–‹´ÄÛµlŸýÙC…ú½ÕCe¯6¬uÓ��böRViÞÜìBËîiØš´Üš´pðA]Ó-±?Bo·–ë÷O—^×Ïì!Ø$À@Æè‚8ü‹øR+ÿ�‘>==±äK´Zg	›+„ãÝéDHN>ÿù]¯í¢¯®éyTúánڧ箔ïÞ‘|
½îK”Ó‰è‰G²î
:$Ñ„$ÚóÁ=°X§©<m—
¦7ø²Ž6¶äQêigX².+J§Ñd}ƒ±ò‰¬ÒsGÛmœŽýDžS©°ñœ¶l= œaÙvò•Ê‡óÁÊŠÔZO�Ô
¡›Õý
G%Fæú¾D¦Ô'…	hXµWXMóf4-6S²×Ú<LDwÚP"!mŠÙœû^þµ¥5¯dJß”ê*(ùºˆQž`�J{[;�@¦[l†9ØUŽß¿¨E÷xUk‹[&]ÓØ’3H˜­: Æúu
^¦°Z€š‡(Íjêx˜w7÷RR(÷†Ò3%C `>Yxœ–k¼òNÐ\G¢x`Ò6£P+ÁѹZ
Ž`þ9©ÊÖ…ïzüöZÊ«"®3â¦/¼è.ņáÍW¢�êb—hw>º˜Ð¯ÌJßñw"Åðßp(wT\K×”;Æ9l}þw¾éè&‹³»«÷//Ü¿îÓkWæ·:'J3ãë¯ÑV3â ´@	™Álá8´2TLXÌ2ðÛ2ßa_õÁ:yЊ3ø¯AU€	Gé¢í-l8^¥å|÷£8Æ)Ÿ[…¨óª ‹”ýãâÁ´Qúx¢çÅc²%è¡°÷‡ø¤ßH`)¤œ´œJ�íP4ÆrAO
+Q=±¸ZåΗ.ÇÊâzÓ~{Øýô|ØhºÚx�†¿­Ñ(àŒÂ�G©¦…SLœdÉÂêsRäÙð]ÎEÛóF5¶ƒèz¢ ±üP,JjÙF¼@5JËè1¡’Í�m	¿€&æta®ðêëÿ^Ü|<»²?y	ìï¤ö›ï™A'”Ò;]'ôÙÞ±QÛö§ûJ`vÒGèz®
 endobj
-1610 0 obj <<
+1622 0 obj <<
 /Type /Page
-/Contents 1611 0 R
-/Resources 1609 0 R
+/Contents 1623 0 R
+/Resources 1621 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1608 0 R
+/Parent 1620 0 R
 >> endobj
-1612 0 obj <<
-/D [1610 0 R /XYZ 85.0394 794.5015 null]
+1624 0 obj <<
+/D [1622 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1609 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+1621 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1615 0 obj <<
-/Length 2903      
+1627 0 obj <<
+/Length 2959      
 /Filter /FlateDecode
 >>
 stream
-xÚÅZKsÛF¾ëW°jKU‰ãya
-Xd‚àh×…à1ð?�‰’L¨@u2‘b !¦£p13J*+“Û_ÿƒïSå`*¼HèøãœëjUï6I[Ô<iΓ婘×û–zùnw*¢y½k¨_ØYfn©y³­«&§‘m]é�þYWŽú;ç²Ì›3<츂ÅA íÖÄã°+Ú6¶*Ò#¶°h¡¡›T
&-}ÛuN�uq¿Î›ÖÝqôg17‘»d–/÷÷O
Oj¸ŸTæ_óÒ�t!ˆ[èh|âMN$ðõç/ª{"%p•Í¶mØ1u2-bÐ@Œß
¥#¦@ÿf‹’Ïaׄ<<Âøÿ¶ÊD˜˜© ·�!ãáX7éˆ#
-íEÈb%#;㢥M[Tbl›´šÚöò𮻣¯µoöÉΈ�'ö¥;ÛÓÙ_±ñnvRZgùx—àmƒ`þÛr¾¸~GÔÂ�eøX‰£­ê²¬
-•Oœ"xÿhd¶X:qw-X¤•pó@!Ã@ÍßÕ÷„e-
Øh;¿N_`rúê
í±XºÖ6ÙµEº/“Z=ê¼Ü:Äuæk„Ú4Ù7/BìÊë‰54øÝ·ëÜ1D3_‡&ß}Í�ÕñP9VP£ÜæFw
-
-´NA�l4I»±ÑG
-jB¯ƒ4NKk°ð¸-ŠQ 5àI`J÷»†NÝ‘šºÜãtw†v�´£a€í¤}vï%ŠŽÆX\)P©áÄ},в®?»Vñ9ÿ+fB‚K�ÂØžl•·hÉPKA™A§[o¼òîðú :Ð_ð\ük0iP%q²#ĹˆÔ9õÛbãwƒ8÷U³OS¸+>fõ&)ªó
óéØ5_�MHÊsy'm
åçáÙ—ÝC�>�Îpà}œ•É&?çgÜp·ƒÆ”œ–IL¶çâ,É–4m®­#4¿&%µ>=Ìà»F],³�ÜX#±k.<´:HäåÐarã`SÒº´°ZQCã‡Ç"!Â1T;’‡*ÑH1a™µÐÕ´{æø[
€i MŒj†�z¦
RLGñŠXôâ%r»T¸vl(„“ìM‘‚/S%%Q‡QÒ…±Uæ~a퇃ÇJ…Ó¬�Ça4ð»
Øs·¾chM<¶,œ' å�ÝÐàcŸR¨	�
-"ˆŒcoì{…™ŽPÃ0ˆ:{oͼ�@ÈÀûAÜW)§Í”Ú(íQ!ÊÛM¥~
ÉÝ#cgJÂT+“Áb°´é5nt<[Ñ«
-ÇNq¿µUR6¥æ�¤áɆ"°~È»šñm‘RÕí(G×6áñ	*‚ÎBZÙ‘žçUZB®•Ýæ<ðm¾ìûìúË]’~ÎÛÆ�:m€å
F
Ä;�g0tùeéÕ$RÎNFÊQî,/Ko^'
ÐÙ\ú[[…ˆú¤vd0¢�…ª«w�§›ÊrÐ,HŸÏ¢.çeF»øËjï;4Æ<ù–ÔWw• ;ça[ù(y´fŠ†:PåÙ?�q´cDYà`qÏùà³?gÆ Zå�Rcuáä t!ÈÙ(oÀŽã!LºòNôú
-]èz×Dœjýü#°v”4‡Ø'ó“	[ûûõ¤‚RUÇÅñãp	hΖ¡+rè»®Ž–%Ëú«k:Ÿâ'=à&l©t…_£Aó8,anê¦í£y¯¹ÄÊÁv™=]ÚŠñG•6}àòr–~Å“hQÌx¬Í3hÓ‰|l…!þËÀïÑ�
Û6ü¦i‰Ù3¶É8RË-ãÍí
-Z?¸©Û|
-f�#%P
'ì<v
´ÛÄæ9
-rö¦ÜaYNXX´g>…ß}1�Þû]èëÌp<ª§QõÉ×ôuu7h}®lh„K(�B¢+2çUÏyºZ68Ï7]p`äèýŸR»!ž¿OGzµ“ŠÅâ/i2­PßP;0iùmµÃn°ÂjËW”N¿ÐÄÕ›x#»êJ_ÕîË<êظL+W]I5¡Ç”<`Jéø9
ZtGF”ƒ7ú¾w?¥ú¡¢ÔXWñ3¢‹àŽ¹làe²„dª“%´)ì’žICÔ¦¨R7¹õ«ŽäÚQ:§H/×GÁtâ]áÐ|CVƒGøQ²"½Œ¤·‹ÓqôŒ¤”d1„Ðî6ù�0½£ôÒ,Ké’ÉÓ
õÈÓÁP_=À^ÒNÉgZ!µ!ÈgSšRŽýÖû. à¼ÆYplÛ$Ýæ5]©óÌn5–ШO—ÄV^8?xb?ÊCìïzr¾| ¯ýMA`vh³["ŽÏAJí–Ù_`z2šhë#vÚŠ¾X—Ýo=ç©Ä¿©ˆÿn+À5Ë'G€,;Y&vs%­Ç½xû=áQú¤ºÊ__ÉNÆS?ÄCÍÔfyOëSÔæÖƒ€6iÈÍä_jÀî˜ßýw!ýÍè�©(êýÛ€îgo…/òÂç	ø£¿ZœIe¤Ÿ58ú
EQendstream
+xÚ¥ËrÛ8òî¯PÕ–®²‚
+¼›Û7×½¾¿zûöêþ|)t$¼Wÿ¾úåáúž§bËãåíÝOŒIùóÓûë›ëûë»W×ç~>»~èï2¾¯$^äóÙ‡�Á"‡kÿ|ø2ÕÑâƒÀi.vg*’~¤¤t˜òìýÙz†£YZ:'?_„‘\,C%`�Ú³ûò
ìkÁPD
+G‹@8I¤Ø	©ßÔ� Õ ö>wæP˜†í6kŠ¼möÅ0neLÅЦ>œí­�=S×LÛ5–t_f…¥ýéî=ygð0°íR?…‹Ñþ´6J½¶Ø™ºkÐ)#ïa[4<Á_íÕ›–ö²"\¿xk s™]ÝZ‚ƾ˜ƒåTÕíÜ	V¦¨PIäÝß¼b
+�
²ò˜=5óÎmw¨,·Ø»yw¿œnÈVóöú5?”ȾÊkŠ]QfFÒ¥
+¶UÀWX‹;>Œë�]·�uxèá„è&„èݬ‚�ùÚ^úÂÄž÷øb*û¦$ b|Þ­çý»8f·[‘�EöˆðÝÀ+šå¾nŠ¶øbé韾–ëŠV	¦ËÊòɺç±O×Ê—	1vÏU¶›uâ2öEa�©ŽE	FÁ
Ø]G"%ñ#ŒvÏPËGÌHNxÂ¥?’A2½zÓ­·øVqï”y”Ù/»ßØú}ø².
`u	 x-FJÅLª|NÜ`cÔ÷4˜0Â+À0ZñHd#�ÎV`šme™HH=ð�Ê'ƯˬiŠÍÓ¬?fµQƒÕ!ŒœÊì—¯­X²øåk`¯�ÊRÃQ+†'7ªb·œ»9lJÖ¡G2ÓäŸß_¿bÜ—¬,r�Ï…à²zíøsWXÈ6l
+ågV‘R¾’)Kîþ—ÿ}7Ÿº­@ì;÷`)ijºõ®å‘9�köɉ*1Ê¡`f_—Åú‰g¯+‹ý-ÂÒ@<�Ñcæq<-eJR«	[Â
+†”@à$F>ürè`[<nÁ�Î8%¡?
bçor³êç¼RèÇ�#*ÁÍ•ö¤ËP@&-”žªâÎô
 W/<¿uä
±5»½õ¨óÚ6zÆS�AÛ†lÿ{å®I‚ä¤|ø{«ÜADœbÀ‚"ñÁŽ&eÇ7åG˜hPTB!¢S_ÅÑ3
+íj#€TIØ×oNUYMÍ�"=-AWYO±ËZóXžf=ÀÊÞ@(âùÀáûT�R_‡½‘LøË«™ ²´k·3ü˜òFü6{³.ÐÖFy®½Ï1ýÀe;RD¬¬�L
+½‡ó4¤¬ä—!Jð踵
+'ûõN„5›¥@Y p<}ó5ƒÅø�©¼¸½{qæ†ÌîOùëK©u0ïÆ'çÔœxù¬² UAã0ÈèÁ:lΧ=ÎîôŒpqý1³±¸XSÉAì[ž.©Ú@�• |-ü6ug»<¦ˆ
+ef‚¢K=q[þzæîJøZIaé0�$µVH—Uƒ�Éiðëíu¤Lm_Ñ�B;],-´‡4¹Xwev(mµº5åÞj\ï¾&Z»ÎºæOiìÆÙIf3جk·5„ãl¨r¸ d¯ãTåÔ@ci7�Uo €ë
ÐtÀ…ü¡�cub PÛÃóZ•F²u
þ«Ý¢˜$Z#ž6•í
ŸºG5uÙµÔ$!z×S�#õã�jߌßû3†N…é(”R;
+âËà¢Â¦Â
€¹wZe90Ù_Š‹,_1ÙB)zG
+˜�m!ɺ.kÛ
+àûâpC��RIåά�S;ßÚ¥à.ƒ¾.¥ðzËÇ	Û[–Ô¡éq+ƒ–rqÇÇo—åØÜåö²6$â¤Uh²•HaS $™úrâlÙ8EC=›íÄŒRŒ ²}Ãz•­¨¾
+;tŒê›­4ß·Ña�×ÇŠ!Êxð§’Êv¹Ö[ü�oÃÒd9g@@Bm{äd‡ìyPXv2p[“‘úÏ4¾û6Ϥ›„qÈ…šém¹•ÕNjp“ÏF|V�JG*�Õl­<S­K¨µrÆSÍßæs7T0^¨ïÖØYk
°¼ÁÌ£�|§qÆ!_cBP–ÎL´kpké’({Η˜¥s¯³
+Ðû\•¸[“A表�8�ø‰ìûéæªt¡«gÑ–
5§awYåb‡ÂœÇìÙ|Ußù
´
™IñHnŠ§z¥2ù¿y´eÄUàhñÀùèª?׎ý ’ò›ö¿­™†Ô}¢AÖG9õqì4Âb oïI¯KPíoZ–È©™&YM·Ûe‡âwWQÕ	‡±—E<Z×7Ý£¾§àòCý÷[=ÃÏ衯v*ñ§çTÏýTÿ¬²ýðÓïö*ñ¡Æ	‡¦ÏXóúæ�Œ|ä…ßül.?”qO5:úÿ
<{aEendstream
 endobj
-1614 0 obj <<
+1626 0 obj <<
 /Type /Page
-/Contents 1615 0 R
-/Resources 1613 0 R
+/Contents 1627 0 R
+/Resources 1625 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1608 0 R
+/Parent 1620 0 R
 >> endobj
-1616 0 obj <<
-/D [1614 0 R /XYZ 56.6929 794.5015 null]
+1628 0 obj <<
+/D [1626 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-438 0 obj <<
-/D [1614 0 R /XYZ 56.6929 689.473 null]
+446 0 obj <<
+/D [1626 0 R /XYZ 56.6929 474.28 null]
 >> endobj
-1617 0 obj <<
-/D [1614 0 R /XYZ 56.6929 661.8816 null]
+1629 0 obj <<
+/D [1626 0 R /XYZ 56.6929 446.6886 null]
 >> endobj
-1618 0 obj <<
-/D [1614 0 R /XYZ 56.6929 297.0896 null]
+1630 0 obj <<
+/D [1626 0 R /XYZ 56.6929 81.8965 null]
 >> endobj
-1619 0 obj <<
-/D [1614 0 R /XYZ 56.6929 285.1344 null]
+1631 0 obj <<
+/D [1626 0 R /XYZ 56.6929 69.9414 null]
 >> endobj
-1613 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+1625 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1622 0 obj <<
-/Length 2618      
+1634 0 obj <<
+/Length 2586      
 /Filter /FlateDecode
 >>
 stream
-xÚÍkoã¸ñ{~…¿UÎ<¾ôê~Ên’m·Ùk’=HÅ¢m¡¶ä³ä¤Ûâþ{g8¤,ÉJ²�kQ,Ž†Ãá�ó¦WL8ü“$d\¥z§š…\„“ùæ„O–0÷öD8š™'šu©^ßžüx¡âIÊÒHF“ÛE‡WÂx’ˆÉm~¼ùËé/·ç×Ó™y±é,ŒxðúòêŒ0)
oÞ_]\¾ýp}:�up{ùþŠÐ×çç×çWoΧ3‘„ÖKÇ቗?ŸôöúôÝ»ÓëéÇÛŸNÎoÛ³tÏ+¸Âƒüvr÷‘Or8öO'œ©4	'�ðÁ™HS9ÙœèP±P+å1ë“›“¿¶;³véØýi.˜�¡‚›„ÄQøô¶´‡m¦,ŽÃd°ëL¨˜é0F�ð„IyP‰•­X¢T8‰�O¤¤²:)Mcv;¼š/¤ì�åġŽa$»]™éLi”ûͽÙ\-hD"	ªÒTûšPaêýºqˆf•5²¬”§©Öž¡)g(	ì9‚¥a(íæój_‚”–<G•FAQÒX›©ʼ(—ôýÛÞì
-SÓîˆ#îhØ¿�0f‘VÒ�0¯6p=¾•0
WìÈþ§»S2Þ—–-ÈšFŒ‡Q:”z³©J<˜æYm*jÝ-hw›ªqßµÙ¹ûðÄa°/‰*›¯²ûµ#ÌʼYädÄXEÃëm1sS<à
�)
-Ó—|(JS–„‘¶ç¾Ïò�©·_æDQµN„0:ŽûÒüskæ
Z8~;õm«²Fm!êï<äè×­—*Gìz`ëlcF$“Š¥ôH2à,¦3-DÐT4¶Ž„µ)‚î?;2<
-}+CLÖHF¼.LK½äu3ÉC¦”8¹ßS&ÖUÞ÷ÄÁÆtÌÉã¯`éW<mcR§æ/ØX:Jyjžå÷_§/²b½w:�옆6R†)—.P"ºvðÛ‡$Íòܱ¨=´RœWê <J“$M:¡
-×VFÅ•‹]€8={ÍõÞÓ´á�.œÖ¦ »ÒÆJnc¦
Ê~¯Ap´Y(JÝV
-(¡K”my¨¹K¡
--ÜF
+xÚÍ]sÛ¸ñÝ¿Bo•g"¾IöžœÄN}sq®Žï¦3n&CK”͉D*"eŸÛéï. H‰²”Øétô€Åb±°ß€Ä€ÃObøJô J43\˜Áx~Ä·0öîHxšQ µ©^_ýt¦¢AÂ+íàjÚâ3Çbp5¹¾ùÛÉoW§—Ç#iøв㑱|øúüâ-ajÞ|¸8;÷ûåÉq¤‡Wç.}yzvzyzñæôx$b#`¾ôvL8;ÿõ” w—'ïߟ\ºúåèôªÙK{¿‚+ÜÈ×£ëO|0�mÿrÄ™Jb3x€g"Iä`~¤�bF+0³£�Go¶FÝÔ¾óÓ\0!�Œ”f±|Vé˜E<ÚñY¼ð2f7/šÇ�—ÃŒ.«‘PÓ&BùJÅ"kãF¾Z´ä+´b±RfÁ¤Ù£€—Ù4[.ÓžôOgR¶&ÀGFGð$¼ºË@4 ®b5¿É–—SlÕpy,â¡çTÑPèi¬*g÷aaÆY~ŸM±Ã•«Û»®H–#ÝÇËU
„:ñ\
h¸®ê¼,· &㬪@Ï”àÃóbcZzSÞ{0û3�/fY È+Ò<h; ;�¯hôá.ߘҨ3/«š Yþ%›=<.瞶˜à?Ê`„m*·íñÉA[ŽÏÓ
ÔBÆ<™„E‘I¾�%͈w«›µŠ%	Oö©›0øéÕ­ªÓe}˜¶ÁgmCµ
Ûñãx–U×wi ?¥«pnh™£¦­çe�õéY•-a°6 <ÈØpR·ÞÎþ,Ø·M¬_卵§yѳ-ÍY¢¥ñdÿ*‹TSð8qº‰ì³5
+?èöE ÛŽÒzÉ(`ÈDHÑÕÍÆ´¬€
Tdð±ð)Â}]eËGÿÉ
_”U•ßÌ<ÆLË‹[š˜×¨ìV'Ùð½Ù;Û³~ÁÒ4†¹(‹*ƒÏ	?\RK›EèKQ>4¥Hç!éü=çéšóöño¬gçù+0
+Ûõ¢°‡ñ@i;¼É¨O›D(Ë}°ƒÃ6‰J¶–�|…Þ<R›Ø*ˆH÷é,Ÿ²­v„)ý´´"ò´C¸šÕžlJí¬,¿¬�s_FˆEPò䦀ëdâ9yÄ$­Ó›Ô}zvOÞ¾ÆpøŠ0¸J•RaûJ62îY'áC Í&»Mª­«/ËÁš”N,³"ÞË¬�K`„çP€&-—‡•Ò²1*„�|¡EX+à+B­UÁ#(µ$ȱڌuŽQ1êÓŽq¹*j/bç+-ª‘kA)À%ûtúë¨j,Lcw™§‰˜ÕØgÌ4œq×>•Œ†ŠÌg’pîÜØ
낪dŽ	�ÒÌi/@dÁ:œ‚nçЮ¿6÷@l†«‚¨@MÓ›™'Ä2h‡/å·›ÇÛ`\Èq–eÈÞaäüÍûßÚþ ƒ€=ŸyVõÊ©JoŸˆKmí|)#ú
u¿¶_‰=F¤ã˜A%‚Û¾I'P‰-³!­ÂhCØ®ŠìÏ…÷éØo;ÝŠPèøJòÙØ‹*öçò;Bfˆø´2*-´.”`ÛØv(Eã„#£x)¶â¥pFHzŒ.LKmH–ÚÝK•úҌ·³3vk˜�,Qr_æ£�d*Ö¤céäæ7}–法—	”¼‰qŽÒ$¨<\z?‰è¶×Á~ð:HÚŠ¿�j)=»|Œã$nyRð'\»5*î« D@xg„úho
+HïM9]™ÑLç*¹7N£ð­Žúø dý÷ýp‘º|ĆŠ¡I™\éÝ¥÷~0-=Ð_å·’šu2?.];©žÐê–º<O¨ßTQĸµû.°4×ÌXEÉÇ4/&SPÙoÔk¼j¡2ºí€ü-Šèˆ´{"ººÍ(¹¢ëJ
mÚXË:�QB±®
­¯
£á´»D—v4÷°tåêSl]¹åÚŸ¹{Ø]:Ò>üÿcϧdÂÀùË=:¢lÌlÓe"ߣ"qL’‰£áÛ‹�OßΕ5)9_K9üã8�Š# ‰hºÅ*T=jAÉ)–‡‘Ú¹w÷:R["ÇÁÖ-;a�wÎGgù¼Wr*ýŒ¡ÒÛ^Çl@0 ÏT š«¤å—CqCÈÇ}(LµaK3ÿÙ²À+O„îÒÅ"+Îûò‘Qœ0|î9,Bx¥¤•<¡ï-Ez)Ÿ¸~´ú¾ç¨ç=b	›0I|°5.Û¯g[¯hŠ[ØMAž”@ãõ3dç<ߌ [�#Ê%NÜ=bðEÖ'ÙÍê–p³ì>s�NÖxk‡ŠšrIè»üsPPO¼ÙŽøšO寞]…€Å@E½Ô3¬ïÊÊÐ]¦	sm{
‚†ÜR<uS¬#¾¼½ue LiQ°8—÷˜JSºøŠÇeÍúxzyJûÇnåäüWFÅÍ¥DZTd·àî=~#5GTµÂ›xWQUžÍ?Þ~xr~á±ëû	ãs‡†Ñ-
NœI·8´VÞãv•kñé»ä«ÿÇò•/#_¹-_ÝÈW÷Ëпø¨ˆ=à_2¥ºñ×ÍBT¯(Å[ïßÍn¤«×ËÇ9·|D¶Ho(ëÓÚ«öªko²qºª²ðêßDÛUc놘®]èf«ó©�äS¤Ár`ì.êé”pÐ	¿ëçù„¥ÉWWËÊç+Üó^<X�Š+ ¦D†'n7øW!ð¥Žóáìa™ùÅ}¬Ó:›ÓûþMa™Îçi_‘ü¤eI”ȧӬòÖópJÍZ�^²“nˆÒ‚
­«§RŽ 
+IFÕ]qû�¶#_¤:fš‰EÄ„�ËbÚó
+(¹iªq.gÙ_ûb©„òYĪmíþ<ñÂøßN•Biß1“k¢˜åU�# MpM¾øìòb×¹^”˺Ácçõ~vÜ#Á"µñfzýml\Ø¿åöèÿüº®|ë~¦³‡û<{XCŸñ`;syï¬*K—è£[Û¦,ä3•w­¥]?=üôÊyïÑ“²öB¢Ú¡=§ï?9�áizþAÃC{öÿuÖfÒ¨ä±ìO"šdÃ/
+÷eÄæÊ
TÜ&–QÏÒÿZ†Tendstream
 endobj
-1621 0 obj <<
+1633 0 obj <<
 /Type /Page
-/Contents 1622 0 R
-/Resources 1620 0 R
+/Contents 1634 0 R
+/Resources 1632 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1608 0 R
-/Annots [ 1626 0 R 1627 0 R ]
+/Parent 1620 0 R
 >> endobj
-1626 0 obj <<
+1635 0 obj <<
+/D [1633 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+450 0 obj <<
+/D [1633 0 R /XYZ 85.0394 189.8991 null]
+>> endobj
+1636 0 obj <<
+/D [1633 0 R /XYZ 85.0394 163.5217 null]
+>> endobj
+1632 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R /F21 938 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1639 0 obj <<
+/Length 2051      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥]Sä6ò�_1�¦*£•dùëò´Ù…
©„ä€<Š¶fÆLl„»Ü¿nµì±g�lQ5n·ZýÝ­–b„,Ld²ˆÅ.‚EZžðÅÖ¾œG³ì‰–cªïnN>œûÑ"aI(ÃÅÍjÄ+f<ŽÅâ&»õB&Ù)pàÞ§Ÿ/Ï/¾üzõñ4RÞÍÅÏ—§KpïüâÇ3‚¾\}üé§�W§KÂûôýÇ_nήh)t<¾»¸üL˜„/0½:;?»:»ütvzwóÃÉÙÍ`ËØ^Á}4ä�“Û;¾ÈÀìN8ó“8X<Ág"Iä¢<Q�Ïåû=¦8¹>ù÷Àp´j·ÎúOp&ýPÎ8P‰9	}é[þï[´áù!XIùb©"‡~0xYHðçÜ+žÓ’®;Ý™ÒT½~6¿q.«¼ËëŠ0ºÊøµÕkã$É‘N HL&"²‚n6fPgO$G
+íE’ÌJBZ$è)KÕîUó¥ðÒºBÝÖ»æTÄê�ØÄY Ò¥…¸×šæÑ4n¹¦§.ÚJ?í8hzùzÓ=ü%„SŽÙÀò“MúÞo<à×Ʀ�J$S‰¿ã�©(KZkÖ®FÁïÉ—czû‰sŽ¸¢�®MºDñÀÅXÌ9ð’
+îþ±3-Wë
+
+jÆ»X¢ªé‰Æ”;Ò½£²o°ÚÃM"Iè‰w­É8;/ §QH@qkÕm]æ]gEak�jŽ˜§¼(±}ØZj\3�ƒ4aÂq"¥íñ'ÅA®ù¯÷g•„.‡só4W`
+õ�ŽMƾ÷�WYK ¹¡}Bà&>5=ŠüTx£œ@Ü´ÓÞ2®'¬šNN/Ù‰ú|yM
+mß!S�ˆ¦�ØêÔ ïüØÃBÚ„ÆÔ–6É

N¯m]µ†ˆ @ ~A/ŽšLÛ5§±·K)R¶(z®Ž¨µB¥®*k'ÖeK8M�ªnJí¸“1€„ižû­]º±�Lö%8É2¹d"íqÅ…ËU5䪚æªïõè}vú>wG,,gf¥¡M
y¡~V…­�„†»6ˆÚÿXÕ£:àŽuŠ;
tE+¦¡^Ú‚gŒîš|½vÒ²w´[(
¡’!½�nÒÍLø‚I¥ÔL¨ØÚ…O¨åüQÞf®J¬+g$Ï0ôÅ׉v'Ãá¼8œL—~hlq1HÔÕŒ€$`¡ýÈŸ'ÞEGº»sì1ÏŒ³RӃ΄êUš£Hôó¬.5t×à69ØH�­Ïû²Ýš*ëÛœõÛÐ Ýå�ŽÎ6�¹ë…Xï;a!äÈÜ*«»Ù¹"bIœˆ¯”û2¦
<)¼ð$Rá›$Ë$¿ï8øþ£ˆÃXk#`ëÊò„¶Î&ÛÁ
+i¾ÕÅ[ùôsˆ
�…ßcI¶Ÿy÷ûÌ·N¿%lò/WyaÞï‰lWnß¾u¢>Þëm"üÍö¹OèÐbñ»÷ÌWE>4å¯þ¼¾ÿßÌ
~Ëùï“2‚V§š}¾Ã«þþ°}Hendstream
+endobj
+1638 0 obj <<
+/Type /Page
+/Contents 1639 0 R
+/Resources 1637 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1620 0 R
+/Annots [ 1642 0 R 1643 0 R ]
+>> endobj
+1642 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [519.8432 183.6871 539.579 195.7468]
+/Rect [491.4967 682.6714 511.2325 694.731]
 /Subtype /Link
 /A << /S /GoTo /D (lwresd) >>
 >> endobj
-1627 0 obj <<
+1643 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [84.0431 171.732 117.8035 183.7916]
+/Rect [55.6967 670.7162 89.457 682.7759]
 /Subtype /Link
 /A << /S /GoTo /D (lwresd) >>
 >> endobj
-1623 0 obj <<
-/D [1621 0 R /XYZ 85.0394 794.5015 null]
+1640 0 obj <<
+/D [1638 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-442 0 obj <<
-/D [1621 0 R /XYZ 85.0394 402.0723 null]
+454 0 obj <<
+/D [1638 0 R /XYZ 56.6929 731.9325 null]
 >> endobj
-1624 0 obj <<
-/D [1621 0 R /XYZ 85.0394 375.8082 null]
+1641 0 obj <<
+/D [1638 0 R /XYZ 56.6929 701.4683 null]
 >> endobj
-446 0 obj <<
-/D [1621 0 R /XYZ 85.0394 235.594 null]
+458 0 obj <<
+/D [1638 0 R /XYZ 56.6929 475.6865 null]
 >> endobj
-1625 0 obj <<
-/D [1621 0 R /XYZ 85.0394 203.5557 null]
+1644 0 obj <<
+/D [1638 0 R /XYZ 56.6929 450.9966 null]
 >> endobj
-1620 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R /F21 930 0 R >>
+462 0 obj <<
+/D [1638 0 R /XYZ 56.6929 381.4304 null]
+>> endobj
+1645 0 obj <<
+/D [1638 0 R /XYZ 56.6929 350.9662 null]
+>> endobj
+466 0 obj <<
+/D [1638 0 R /XYZ 56.6929 305.6252 null]
+>> endobj
+1646 0 obj <<
+/D [1638 0 R /XYZ 56.6929 277.9066 null]
+>> endobj
+1637 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F21 938 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1630 0 obj <<
-/Length 1487      
+1649 0 obj <<
+/Length 1107      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥XIsÛ6¾ëWè(ˆ Á¥99‰“:Ó:­£œ�&!.
-
zéòßû°�Ú•äñŒñ
-œ&!íÈ¿w▕újô˜.Ô´dÀŒ¢
-,7ã÷Ž·‚KdtðAvŒÒ Nž9ÁÄ™[ç�’N!
-…©7ûÄÝ2å(^šÈÈg
y0øi­aGCgÇ
tkß÷AE©xë ?ïúz˪
-Äüœ
1B©¤q
-UTPÏ{ØPñJ7d¸“Dæšß—«¦]ÕÍ>Õ¸{üÈ(lE~d
-Þyú[ÒÄG$x¾ø“Õã÷<ø1$	™þEbxÏ%
+xÚ½X]s£6}÷¯à1~åÃØ0}ʦNš�n¶uݧ4ã‘AØš‰•Dlïvÿ{…ü‘ÁØ»“É
+c‚´)…r9£0A¿êç—œ­ضxžÓt3
+^Ñæb€ÜCÕÃ;þö	HÚ¦nÇr™ÌpÔ"„%BB‰…ġЦ
3Æg”�ëÞ^Æ‹G'€£0ãÓE×	¼4ô¯Œ"p‰~0“K@×K ¦ç»GÂB(Pi€ÖX¶Âhpˆ0$YZ¿Ÿ±Tª´j1~_À_2Ä7ç#.Á‚dèü c’‰%Èå9s±ÌdÄV\B@"Œ¨ì0ƒK&ä¹)`¿
+iÂ%RªÔªþŽß©òÑ°”›N-ÎÒ©d Í”‚˜4xAG§Ø¼}È(ÊRµ!†ŒG¼.ÜzGÇdý[a…Õz=§^hµ+¡…ú­Ð¡w+Ùê~á'rüíÇŽyD'�çDýÈèÐÝ«æ|(ZéNµQúö¶Àïíáj�V�•õSp–@ÕQÏ.‹s›Ò¨Ak-|7Lç&(·ý+ÆPÍÍ�A#_?lÉ!qYN¯»×_M‹
+÷úJd©j;Ìݱ3'×3óƒ¢#'DVµÝ^|µ;¬ŒL×÷�ê¨ÉqjGM®54}'•AåÄ=w?òêàê0ôÿ
À$dÝendstream
 endobj
-1629 0 obj <<
+1648 0 obj <<
 /Type /Page
-/Contents 1630 0 R
-/Resources 1628 0 R
+/Contents 1649 0 R
+/Resources 1647 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1608 0 R
->> endobj
-1631 0 obj <<
-/D [1629 0 R /XYZ 56.6929 794.5015 null]
+/Parent 1620 0 R
 >> endobj
-450 0 obj <<
-/D [1629 0 R /XYZ 56.6929 687.8224 null]
->> endobj
-1632 0 obj <<
-/D [1629 0 R /XYZ 56.6929 663.4753 null]
->> endobj
-454 0 obj <<
-/D [1629 0 R /XYZ 56.6929 594.6899 null]
->> endobj
-1633 0 obj <<
-/D [1629 0 R /XYZ 56.6929 564.5686 null]
->> endobj
-458 0 obj <<
-/D [1629 0 R /XYZ 56.6929 520.0085 null]
->> endobj
-1634 0 obj <<
-/D [1629 0 R /XYZ 56.6929 492.6327 null]
+1650 0 obj <<
+/D [1648 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1628 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R >>
+1647 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1637 0 obj <<
-/Length 1202      
+1653 0 obj <<
+/Length 1220      
 /Filter /FlateDecode
 >>
 stream
-xÚ½X[s£6~÷¯à1îŒTn20û”M�4;ÝlëºOiƃAÄš€ÄJàÄ{ùïW_R“�L&ƒÒwÎ÷éèèH†¦Ë?CsÔ-ÏÖφH7�$#]»—ß®FFÙT�@»×Çùè×KËÑ<èM̉6�ZX.Ô]×ÐæáíÙÅïçΧ³10‘~6�c€&úÙÇë›ßT‹§_n.¯¯þ™��ûl~ýåF5Ϧ—ÓÙôæb:†‹9Þ,Ž¸¼þcª~]ÍÎ?>Ÿ�ïæŸFÓyÍ¥Í×Э‚È×Ñí�®…’ö§‘-ÏEÚ£|Ñ¡áy¦–ŒldAd[VÕ�þýU¶¾n‡ÒY.D®éÐ6Zº=Ûs4ypb™ÖVÁÛ1˜èúÙŠ‰ˆÌψÈH @â?©4O–˜P/waiô2Û	¡$ñcÀ±HX¨æ
Æ”�‘ÇIcê''m
-îtá‡a©ìmÊxV·/wê­4!¬ìm?OÑ'—éQæØàAÊÍ×µGm}ß‚™ôŠÍ¤Ã¨ÑEÍ֢ȘÿW¡BéÀ�ƽ�¹R¡Œ°–b[KÓÕäQJ¬°T¥•õ~ÇÒG§¥ÚtZ~ž �Ú
)ŸÄ�rOÇÇؼ±Ï(ÌS¹!Œ‡{¼^i\FÇäé�=’8êõÚ'_¨ñrWÂ÷œd›þ™¢b«ê…wä,øúmmÐI�eLè}•ü8f�€âGð�QÜM};[àÏÓáZ•V‰U$,Ä"ñ³`µˆI•œOI�
-ôkŽù«0Í#˜ Úö†
|97o!‚BÞíŒûTDU:v§$L‹wx%òT–ƒøM@AYgÔ«u
-ÄËá(aûåjuBèä+ÊŠ�ÌZ½ÒdiL>ð¦ð·©Þ^PQÆÌ%ŽØî\–ò=�¦%ŒªqAÆ$N»ÞÝI‚žƒÊäÚÌ‚bS�¤,«þ”T ¬'@lh¶’ÊŠÁbpËÒrÅâᢺ8p®m�‡)(ÊÀ®«EKßU½fòüúJÄ}'Ãá•N†ã\ôÆM»m€:%vç41ÀÔÕf%™÷µ¬60Ár쥘æIíÖ‘£<š8´LIXèØ–½Eý¥sji}¨«|`Lh9¦}Pÿ†bÛx‹yu,² rl£´�ŽÙF�í¶n?JOL‘é>䔢ž¤„å@ÛµíþÞ¹‘´,®Üê5â«o+›«\[NˆëšõE¤i¶."-}]Ós*§
+xÚÍX]s£6}÷¯àÑîŒTI @“§lê¤Ùéf[×}r3ä„#/àd½Ýýï{1Ûà$�ŽÇƒÒ¹ç]IW¢�Õ¸‰MÁ„f	sB¹æ.zD{€o7=š·AE#TmõnÜûùZ·4�…ÉLm<«`Ù˜Ø6ÕÆÞ¤ob†€@úWï®ooþ],£?¾ýx7@Œ“þõíoìt3ºüðár4@Ôæ´õëåïãá(ûdæïnï~ÉjDö8
+Á´EÏà:憮5AïÏÞ%`åë¦k£~”`¦›¬A@ƒV´	6	@Y\`SgúFÀÉ
+p²ò£ìõâ˜cI´F‰»Mf Ëcw—²@y2Q¼“GP6~µù8îüQò%ˆ5oW±DOZyK´TQR§šÖtdè<)ß{UÄ
CóEx´�¡ùzÓÖ2D*Ÿ@“-PVò—ÓíËý«CiœysË5	?¯$L’X­"wo‰Ù–ü¥1M­‹MŠG-�ufq€Å–¡ó
êOÙ§ÜÃʇt)Ú|CÔ´°n1£Qˆ­‹UãÏsÛ6
+Öûö¶«º}Ë™0Ž9zsôg¢¶RB·°aFÎÆ8ÄÆØc“Ñ06ta6ŽÏ#ȶââ(5v(tʸmŽs_3aafÖ9zlŽux{Åèé0^Ç¢‡¶ŠóTôtºÓCô?Žžt/ØDPJo´Úž÷¯²uh�mì@d	×™™ËÂù‚’È	㙌Pâ/$*Ò³cô8„Z%/¡á{A;' ZѨ'_�x¹�/ÃÎc3ä—¬-î\žÑ²ÅØ’íÍ׈ƒqß	²àD„CGû•þ¾ìJ>U-Ï
+ÚÈʈÀŒr~àT·Çõ¤´ŒQL-b¶§»áaYØ"öîØ24Žå…éöyPó.GÜP%þl�<8ëbýrUèÅ
”Ž"´šKÛÜ¿1@ù‹”Z:Ö
Ñ 5–§gÒvZ¾Å¤3›YÇäLpušï<Ú\\Ä
+eHµ£"°Ú¸šö›ÝÍ_y0™Ë
 
-ÈÚõ¼¾ÖÜwý?È5èYendstream
+¡³�¥g‡YÖŽksyóÀײÍú©íx±—Æø_f
+ÔŠý¯òŒl옶óm÷´4�—Òm1®Jïãöz¶GÈF�ŽýkÌü HAº�Ç�·²Þt+¬sœ^å6Üá’òTñâãíuº
+‹m³ò2˜±Êe0³l8c
HN*u’{Ì‹«å}ê?
 endobj
-1636 0 obj <<
+1652 0 obj <<
 /Type /Page
-/Contents 1637 0 R
-/Resources 1635 0 R
+/Contents 1653 0 R
+/Resources 1651 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1608 0 R
+/Parent 1655 0 R
 >> endobj
-1638 0 obj <<
-/D [1636 0 R /XYZ 85.0394 794.5015 null]
+1654 0 obj <<
+/D [1652 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1635 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R >>
+1651 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1641 0 obj <<
-/Length 1171      
+1658 0 obj <<
+/Length 1074      
 /Filter /FlateDecode
 >>
 stream
-xÚÍX]“›6}÷¯àÑîŒT} Ó§ÍÖ»ÝL³i]÷ÉõxÈ»j0�7qšþ÷Š/ll;™éøÁ q�Î=ºWº6�þaƒYÐrˆcpÇ„afx›2žtßý—߀ê#PÿêÍ|ôã冋XÆ|]ò!²mlÌýÅØ‚N4ß¾¼{¸ÿsv3áæxþðþqC㻇_§ÅÓýìæÝ»›Ù`›áñí/7¿Í§³¢Ë*1Þ<<þ\´8ÅßÐÙôn:›>ÞN'ËùÛÑt¾÷¥î/F4säÓh±D†¯Ý~;B�:63>ë±ãc32…̤´j	FŒ~ßÖzsÓVý0‚„Z¤E@×ÄH÷bjœ9Т„æ
-.&ÀBhG‰*žþBO2^š¿e¾k>\Ã¹IYñCÙƈQëÐP¸°^î±Ë†ŸªöÌ`Ó�&u,ýT¢Ô¨}ÚŠdÒh›x¼XÇ,ë|­•ëûIƒ°Ã!±éA¸`d3Hõ[+£ab™çÆ6ÛÅúV2!2âЊ	®3ÉÜiÚI	Ê¡i›fÿ©»>Eÿãè٦䔑
qEûN¤«(Y…QµªÜ´ÙS)y¸Ý|I;¹
-ô’µ†öd%È�3Ö*k׫Ò‚!æÈêN7çÁ9äÈ>Þ
;†ÆÑö‰�·Ï³š_ÙCb„‘’ëðEàîªõË‹B?m¡t¡S.YRNÌs
Ê^ ˜SHM§=@,¯gÒ!-¿GÒ;›ðKrªHsu�æ³óœ¸A�©høgÏ*w5³t´L|\¿žó`ñQ”Pú!t7bïÙyÕh—µ9�œÿAÕæ¿M-�¼8)cä—u‚è	¤ò«P�ý­&ÔÛùÁ<{Z¥±ð:̃ébæÔ²ó<êjÔíißð`-ƒªé?xª\ïãkØ{�pC>�îuƒý³põA¸
-¬Ès³µë‰¡
+xÚ­X[“¢8}÷Wð¨a	7¡æÉéµ{�Ú±g]÷©×²Ò5µ@˜$8Ú3óß7Ü”v€n-+&ä;ù®'!PÑä*Ž¥j†k*c×T-
ZŠ4e+Ÿ=`1”“@uÖÇåà·{c¬¸ªk붲ÜT°Us¨,ý§áÝ“/ËébtKÚêX¶6ü8›ÿž�¸ys÷8¿Ÿ=ü³˜ŒÆæp9{œçËéýt1�ßMG
+]WWÂ�iªeF9þüu¬<ÍD›ügŽj9ú¸Á�&¬8jŽêšîX[®jº‘yðilMz
F‰¶€D³=
+òá(	Ÿ1û�wV©¹rM
+w�­ûžl�>ñ‰86¦Bᨼ³ªùçW¸ò—UID}̯1Û¤i%m‘HX{¨WÇ÷	I¥‚wŒPÂe¥6ÅBGÌ×”­#ÚzݘÑ=ñ1ZH3ü5Á\´—®é.XJTˆKÎékDæ<¼‘
Ü
Až�¹Þ^k"Øñ­z¼	"–´WÐy¼N;-4—¬H¡
+À†Ñ DìúÆã+£�¾`E¾Äðñž”#±[G¨ôN'"ãä—uû‚¯©ùvhäŽ
BÇØÅ6R’F—²Ù�@Ò!@òhöf>ü¯fi�^ú‘7ϲ^þ~$õN°…õ•õÚí„-l�jØ…Þ³/{IJvÈ¡„OåtCuÓÓW“´•d×O›‹ø¦1y7ãðÁ¿O6'çdÞ*ÀZXÆ°—0NöXfJpìžk×IÓ,
Ãu2îÖÑ(KÀå_rÔ¹6™BÀ£‘@žè"˜æfLá6HðeñLjE3‘ŸÚÀüq>íT=Xê	?®PG§ÓWOÑô4 Y/À[”ri%ü7’4õ_%5k§Ë¦ÊÝœåÙ»/Wû„£ç
 endobj
-1640 0 obj <<
+1657 0 obj <<
 /Type /Page
-/Contents 1641 0 R
-/Resources 1639 0 R
+/Contents 1658 0 R
+/Resources 1656 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1643 0 R
+/Parent 1655 0 R
 >> endobj
-1642 0 obj <<
-/D [1640 0 R /XYZ 56.6929 794.5015 null]
+1659 0 obj <<
+/D [1657 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1639 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R >>
+1656 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1646 0 obj <<
-/Length 1515      
+1662 0 obj <<
+/Length 2686      
 /Filter /FlateDecode
 >>
 stream
-xÚ­]s›8ðÝ¿‚GgæD˜¯é“Û:½t®I/uŸÚŽGÙ0Å@‘lǽö¿ß.„´ŽûA«ewµ_Ú•D5þTólÝ°ü‰æúÝ6¨­›‘¡­áÛÛ­hHMDÚT¯æ£—–«ùºï˜Ž6_µdyºáyT›‡ŸÇ¯ÿž~˜Ïn/ˆicG¿ ¶cŒ_]]¿Q_
¯o®/¯Þ~º�^¸“ñüêæZ¡og—³ÛÙõëÙ¡žM�߬$<ÀpyõÏLAoo§ïßOo/¾Îß�fóÆ–¶½Ô°Ð�ï£Ï_
-³ß�Ýò=[ÛÃÄЩï›Úf4±-ÝžXV�IFGÿ6[_KÖ!ÿÙ–§Ûžé8pB[¤†§ûßÕ\Û×Ë´J~¾ ŽaŒeÁ™$AA˜ "g
W苬X¤™š¾TÃW´'”ê¾m›mA›8%_\DDÆ›JNºÝ,yqºvw–z_YžªÇ“DäY!眜 9ÃXÆYʲ*²
a[��¾¬€ÑÙÁ-X‚Œ�ïâ:Cr&£EÊjïœpj©ñ�Š
¡…ÈyðˆÐÈ "–ç<$`$äŠà¢gØ	rVq"9¤=üH–’ÝD¡¿¶1襟jXÂ~ùFÂ
z‚õ­õâ¿&Nh¢´k‘Ģʚ_'Ø
-Ø„ëdËû›gÚÙ4Søu×7׳Gíz’m˜·J‡ªÇ'ó3Y‹,“Põ¾fXK[áÿM’¢ÿZ©Y¯rj™ü¾åÅ!ÉÖçÖê0l™pÂ’uVÄ2ÚT;
-8‹ÓîvªITfQÇÕ-ל÷“#mÛ îÎ#}Ýö¦ª?OQ¿³ûš$œ¥qº&q
-euÇ’3’‚�Õ�è@
%9”ö2pg7žK’
-ø$ØšWk™­›+,e:ºCM¥Ï<â�B­ë-Ün}ß
b¤©5¸/ÌI–eWt¢¥œe�ǃ0BÛ\�ë$[bWAøhLd†ãd¼äƒÀ"´<¨ß!tΣ¸bë-¸a1šYQ­S/pÛFµi72YËqÆw}»ÞLy¿!&á ‡cûã«•BÊJ
õÆ\1¢rˆ†R3àXÇÓ=ߧö¬ áö=ûÈömˆ²Z«q".¸L²à›÷1^r‘‚C	T8E«`�úŒŽGD,E•´†£{¶ïu}òÛ&UÒíã$QP.1\ú½÷C7l�j®«›®C‡Ÿ«*Ò"*[:Nk^‚*"ÔˆIhQUá{+Ó‰¡[u~»tCtívèÄÖ­‰éwŸ&I¶G¯{Îx~‰sl¢8ÛżþPºF±&=<•^ˆ…sVÍTµ)±ü,¡CŠ¹À3SÑ«+(bån³“íÓ¶ 2Ž¨í;~/Œ•t ¦jkáXSËôÇKìqˆŽWjl³Ú@
-Hzå"è¸Û2Kx«ð
o žFSNŸüNx|D�ÀÁÛóÌáÌ°p§˜¾[+…¶í¾æ̓â}Õÿ�³üendstream
+xÚ½]sÛ¸ñÝ¿Âs/¡gŽ@$qy²svê›»¤õùÚ‡\&CI�Å	E*eGióß»‹(R¢�¤ítô€åb±X,ö§~âT¦,U‘:ÍTÂ$òt¾>á§w0÷êD8šÐ…Cª‹Û“çWqvª˜J£ôôv9à•3žçâôvñ6HYÄ΀^¾y}uýê�›ó³,	n¯ß¼>#Ƀ«ë_/	zusþÛoç7g¡È¥^þåü¯·—74•:ׯ&Œ¢á¦7—W—7—¯_^ž½»ýåäò¶?Ëð¼‚Çx��'oßñÓû—Îb•ËÓøàL(�®O3™Ä±ÇT'¿Ÿü­g8˜µK'õ'8‹â4šP`"
+Ì9K9°Ê¤biÅV�oÏ”óà³n›°nBÓa×UἘ¯4Mí´yß´ïë†>_Ðð�û‡B0%e4dÖjÓT÷º
?nu»»r­›mGsõv=Óí7³Zèzµy
+‡T6è�Ôæ3RO…B]‡sAþ`s!")D<½{O5±ýð2@Bð‡4ï^UÍê>Oƒ5h§ÜTš¾îKí'¬‚a4«¢7’œŒ±e}ç¹d… ¡„d0´Ö\Ò:Æ­
+»AfoÎbš‡zÈÈÞf,!á¦jlèž;Pr0Ý£�E*˜a¦Ct¹¤qp@øòpUÜ;d·r€±¡f£É}Ðëá£7Â˦% îéIE�w·ÖV'ÒÅ7N§í�¼‘@lð@8ád#ŒŠ<jñ…âöÏa3
H`ãRØÃ!f­×M»sËI†NcL9«º\oì&ͽcøÔiè*ôI0ªÌK]£b¬[í¼[�€vó¤O¬ç‘ZÈø©XuR
+iˆO:Í�¥K°o.“Qx‚}•¢àc©R™†Pèþˆ1=/ñ6hÃDYOÉ‘€¯'àÄÄÛšò±
+À@¸ðÂtgÅ5wÍÔUÏÎö™q&qiÙH
+|…¥\ÔÆèyXÌí³±þ´)ÛÉÚ\)&sù½lAÄrQøû€eÎYQø	–aa<NÇŽ³.>Q`Àÿ&ø¦Ðgñ8y‚oi©ï3�]ý$¿ú6ž~?bgÊÏS‰.Í´ñ{ùú·á‰F7Á'-¿õÁ_(S¬áð¡šè}}¦@>�˳×MgK‹Äûða=’8—üÌ!|A¨Q 1q«°$Þ·ük¹5äÈ@Bõ.Ò»£ÒÚ¬zà�vû£	Ç\”.ÖbÔâ}
ß‹…õú°ŠO¨Š—û7¾}	&Yä
+7@î·[Á-[
+ãÍôàï&ŽÞ²…,§Ã
E8uÂzAzVÜH	ê&åªÒm뾧6Vh`ø’¡Åô¼§\Û†€Ë
 endobj
-1645 0 obj <<
+1661 0 obj <<
 /Type /Page
-/Contents 1646 0 R
-/Resources 1644 0 R
+/Contents 1662 0 R
+/Resources 1660 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1643 0 R
+/Parent 1655 0 R
 >> endobj
-1647 0 obj <<
-/D [1645 0 R /XYZ 85.0394 794.5015 null]
+1663 0 obj <<
+/D [1661 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-462 0 obj <<
-/D [1645 0 R /XYZ 85.0394 179.8868 null]
+470 0 obj <<
+/D [1661 0 R /XYZ 56.6929 670.4118 null]
 >> endobj
-1316 0 obj <<
-/D [1645 0 R /XYZ 85.0394 148.102 null]
+1326 0 obj <<
+/D [1661 0 R /XYZ 56.6929 638.8546 null]
 >> endobj
-1644 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F21 930 0 R /F22 953 0 R >>
+1660 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F21 938 0 R /F22 961 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1650 0 obj <<
-/Length 3141      
+1666 0 obj <<
+/Length 3874      
 /Filter /FlateDecode
 >>
 stream
-xÚ½ZÝ�Û6ß¿ÂèK´@ÄðC”¨öi7Ý´)Úä.Ù»{hœl˱[r%y7ÛÃýï7Ã!õá¥7	
-ü j8‡3?ÎP?±Ð)Ks™/²<aš½Xí/øâôýp!Oì™â)×õíÅ‹W*[ä,Oeº¸ÝLdÆ�‹Ûõ¯QÊ$»	<zùöÍ«×?üãÝÕe–D·¯ß¾¹Œ¥æÑ«×?ßPë‡wW¿ürõî2F‹èå�W»½yG]©“qýúÍ÷DÉéqFè»›W7ïnÞ¼¼¹üýö§‹›Ûa-Óõ
-®p!\üú;_¬aÙ?]p¦r£÷ð™Ès¹Ø_$Z1�(å)»‹÷NzíРýgR¥2`@)'4‚é<׋Lç,URYõÖÄÓhU¬¶Uýá9¼‰4ê·MWRÇ]UÞwž§ÆFuÛ¢½&r,…£ÂøÝ¥ jf%:†¾qÅ�£ìË}Ó>¸á¤Cš®«–;G®ö;IsçÒ”]³;öUS£íÁ
-e7r7¤5DZº÷!\×75‹þµ-ëqxÀ¹
-‰]55*ùáèb–ôñPäsäI¹‰ùÜ‘F|Ñ ÿñ
-§LA‡¯““Ëo=¹/0:JÑ.«¾-Z§)ú®ÃPˆD8àüŸnåUÝ€òà#Jç0ÚJ¦0O9l%t¢y�lí
ï~[¤Í�Ò—]ÙSýÕvÙ‚ß±‰„鎡@êõN

-ˆD‘ó�Í0~P^‹éK¿¥7÷ê	Í«çô¼vO›ì`ãå)¡©1d혓žë0rP¨HÐ|
-…†ò1£G(Ìï©ÔqÆM“ζ¯HmDš¤§©
H·.;jáÀÐØeáã7®¹ÅOๆñ¬£â`ËÁ#ªÝР1á)‰öv¡’Àù±ÇÆÑý¿¥U$³5;ƒ(0-9æRq
-ÙÎ7WßPã?vB?Íl^¼ J)±5ŽßŽTõ®a=/å|ÌHN÷•1§'³Ñêþû]hÌDã뿦q‹&wT´7>¯žugu�}Å[î»à2ä—-ãåSËÿWÃO5>	‚8è?ÿ¼Ô:r rЯè©5:x-è1
-ˆœ½—±iðÜ°±�ôGê
ñ
-UO¿F‰ëª?C]j”ð£~.ËZ‡Š\Èó”ñSÿY¶M\7q×çT…MÐÒ‹öéYúq9ËÎÞ4½Í,§éHâ"èKGðù�f80âFaB|ìÜ@¯Í±£8JpPùð(ó�«ž„£íÆâ(—ëÊAÍ: 2øA-ÌÖ§9|B9¼¦~žÀÇI&]ÞÄ1oS0Ø*nÅ
-Ì'[—ˆ7µë8£¤±ŽÝ汜q-ïIé5Ù9ç~A¹ ZI.)=¶î=4qŽþÕÝ;1‚ªM’WRÃÐúã¥!eM}c99c'in¦tb!ãíÓ¾øhÓH˜¥¬;פ|
OŸsò¨¼³wÆÕGÝv¿9îpWàœ}ÝÕ–SFDÅz_Õà'PK ´LEÏ\�; èGËj‡˜ß?P¥|0YÝÇ—?*2¿ÀßV¥+¥*W!LRP¯]­Œ–r%¡�ݵ—&:†‹0W÷.§…ôìÒX°Lˆt!ÓÎ.Î\òS<å¢;^¸$¸È-œïxÝz2sžÁyfÌÓ3{¦ÀÌS,R¸5›šR©¡®o?’cÂËÚå�tÀñÞ>•JEíK<í/”
-{Ñ@“Ü°ÏK‹eU¯]b?ôÌöÏ
-|ôQ,ü¤*JÎV1m½^1Üñ
-`hŒñš›3ñª¥ó4lHÄáu¼w†ÁuCDŸB{}2ߘu�¸¡Ì$ø„ɆÊ|Üe†qðFÀûáÃÖ¼÷Uç•s�—eLbþ2™÷?^I�Rb€²}âûÚx‡ì*ˆÎÿ¡Àgö6õVž²D	Ÿ9°ý™hW†)�
-ÇV~‚bºÊŠb½.×gcˆG%?S3Œ<çÌñ©`ü	±ÿ4¤8@˜€óõ‰YžÓiU>ƒHºr
+xÚ¥]sã6î=¿"oUæÖ)’9÷´ÙmÚ붷ñÍÍMÛ™“m%Ö¬-¥–¼Ùܯ?€ õeÉÙ»Nfb
+	@
+–Ã8aÖh*Âý÷„ d"YÂyê—Ǧ
+Äq( àò�5å„IHä±1y
+@ÔíìyNŒ¡Á�}ë­
+î5¶z°SðÀ.µ:DÎ.yÝÓØßâXy)š~¼
¤Áo…xRØë©8Ûe—²MøPئÚC<!gžSnBƒ„Ýj’hyeã¨"ÎŽµg1ØÒ«‰ØÃÆLË8ÌÔ;-×Ì]$ô%7ËÄ•RÛ0ÍþX{ýËvuE­U+ø®â¾³„¿½î»íalO'Q˜ þŸhÀ¬Ë—	õú…rYiÞá¤Vv�€†¥2	™êyÂ
ç”ðÀÅ+ÄŒ‡”ÉÀ ^óÔ];{|tôÆ…ÖÚGÅ:Í#úò<4]ÑL§xP Þú$ÒöÅh=äeŽqì†FtIÖ@@2ŽA{xPˆå�7ÿš*©¤L@^й$àk~¸Ÿ*Ôve‡ª¸Þ®¾é\ÿ”q玦¡#ž ÀSJ½À’e<ML›õ­·Yùà|%O\ºŽôöÙ35ª‘k
NC±Ñæ)"8„nòºhåêð]-¬/‚	ç‚<2úkŸìÇV¸Átæ5¬Þ¾çLÇédá2nŸAËmsHû±1ØfkèˆÀÑ­ÕTU@$š	eCÆö"áÞŽïœ?!éi¦j get(+üe‚´¬LûŽiÖûŒ*`W‹Ž�ŸCÝáU¨8p&�©‘O!ÃN`2é¤$“®k %™z)A‡—´f¤yë\Qà]Še›¥Æ¦xÀôlºŠb“¶Š2-!0
ûÿIH'Ö%­È¼¿Ã‚•­³šŠä:�ÉžRq¦„œ<œ'ˆÇ‰’®Þm}½Û„Òuü@*ù]M àÔ	¼¢øÍATý¶ƒ2|bµ8ÿZ@ôCEppiÇU7•�vÅgŸÜöÖó�ìý8¤Ã:5ñ·\IÇ̬=O]H/Úý)'ܾ0Li;Êa˽‡˜(`›L´ãìþh¹6Ãhkuî’�Ûè¹:bÌ{•E€ú8á]„áz|_²CBjâî7/`r<òKºQ„¼õXîòÚ�m©_Jéƒa&NF÷ÂßCnÿ·P!Ùûw6VècÍ-Vg®[_Ñ?­ä©ó¤Òéø´Ž'‡´—¡êûŽ®”\¶¼ø>ßíöΚÂA€(¾œ
+ Õó¨fÜ&*–‚„…耠}lj½E¸ú6Åm€CgG¨µEï¶ö$a	p7|†s#À™mœˆÑ�OÔÚ8XR¢Ì7&¦ó–81IÍtwÂŽi´ñµ€xm‡–“	ôìªÌ_ï5aŠp™è¸<�ݽ¡¢‚V{IMg½„ŒÆÆfä­ÚEŒ–ËQ¹¼»LÐ3×x©yë‡Ñi@Ù'�ƒÉ€±^á/øò^€ßbŽ}9ÖôÛ¹qŽy«ƒ³/1J¾`u=¬3V°\ ’­·ù¢»ì>¿IY21ýüÆcM�>¿�S%æé�>UÐû)�ûœØ xm7ÉU2z{ó®%@`–³Ò©bâ…+¾g^rÇÇýã¬Ø,3ÉYª
å„êP`ŠÈ.CÖ¯ï'§
Z[>è€�{B ò_�m2püY†U>¤£ìZEY7‡+×”ìô�6þ·®ˆÔL´€ƒÔØD
m/†½)W›ÕtÀwWOÁ>ïÇIðð=Nßô5 bêRÜùaÓþ�Ãxk%^�A6�,0ñþŸŽwÚý)�2¯ì>
ɵhA٤+c,‹¥xáê!Í«K@r·vÅfNG Î�¥JÏn‘N)Sl	¦“(/§/LÉ¡¦�ï쪙r¨i«îζñ׸¾J¿v<nß…[]Ì8Szuˆ·¹9{.Þ‘ë^_Ò%óÄ{Žp[…¸Ï
+'®g
+¥¤Ó1çNHmât‚õÿ±Öó"endstream
 endobj
-1649 0 obj <<
+1665 0 obj <<
 /Type /Page
-/Contents 1650 0 R
-/Resources 1648 0 R
+/Contents 1666 0 R
+/Resources 1664 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1643 0 R
+/Parent 1655 0 R
 >> endobj
-1651 0 obj <<
-/D [1649 0 R /XYZ 56.6929 794.5015 null]
+1667 0 obj <<
+/D [1665 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1648 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F53 1303 0 R /F41 1208 0 R /F39 1151 0 R >>
+1664 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F39 1161 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1654 0 obj <<
-/Length 3769      
+1670 0 obj <<
+/Length 3702      
 /Filter /FlateDecode
 >>
 stream
-xÚ½[ÝsÛ6÷_á·“ç"Ÿ$1÷”&nêöšölÝÜÜ´} DÚæD"‘Jâÿþv±
-|Ú_ñ|Ñ>싼»”jqÓà+æA‹ù¼‚ß”/š–ž»ê©Ø}…okðx
•%Rj”
goŠ]U.¿ÞW{ÇË£AX£�c�¡UêŽ~›ª*«òo(‚XÔ½£ÞšM_·M±­ûçx€Y¬õ¶w¤¦w2÷�VÜË¥`<1ÔÆáWkä¤�íªýg�¶=9Ù\–0
v—ñ,ɸÓÆ옖1íŸ2fÏ…Rô«çåC×Oõš}±‹À3žÈT¿ Càšb`YšH•Ž¤X�¦–’§‹n¿ÑÔrÂØö¯Œ‰­ã@åâ„lqßî‰òþîn¹º»yïúŸJ0—�‹å‹›{7úw[ín%µ=­«zš³hJÇ�ê¡MLÓD1¦†›è4·±†6Óôu±…]U‚LCI°àž 0_ôh×Jƒ ðP5Ôãd¥‡/õÖÍ°®ˆRl·í—ª$â—†¹y&ÈH”]Ñoëæ�ÈŸöu³©Ÿ‚XnMoœÌ¿·î©ÚÔ¨o»'íìa¦©LriÎÛeÄ4o–žil•›}ÐëØ2ah¦ÎËàyNeX¥aI& <ÅBX£„ظÍao]ŸÆ{�4ÚÛz¬7®ÙÇ[ÿ¦öc{Ø–Ô.À³l0®Y
-¼vG-ZäÓ¡êzØ	k€ Î,KåÐ
-¡œóH'–†ˆ¥�RÞ}¸{=¡k!ƒ°‡˜È’²ÝèNõœAÒayê¸qaû6ébueÄ¢%ÉljÁ†÷¥W¨ÃˆDKágŠò„b:±Ð2¶ïY�$`mü4»Cçì¯Øv-µÖ
%¸®úþè+H÷{lÇÚy[íG“¸4‚öb
³Á^g*aÆÈóÑ>æš÷�+¨ï¨£A�W2áú…µ=ÓÄÚƒ0¯ò Çhqr3ÀkN
- Ô"™„e©gª¾n‹æÁFL0Ë­·+ž©Ñîi¹@°vŠ
kÔ÷ÏÔíi
-º«ƒ^-¿ÅÐœ¢	‘3FmÎù¦=n ’)#V¼ý+Rg,Ñ"K‡
-¢}6™[[v›á7t
¶Ùä”(°ƒ0¶ÖÕDÌâ©N¸2¾bñ{‘2çÍ÷5Έ�Pôôjæ g•ëÌMð׉5 ed‡§ÙÒdZFÉ'ƒäó¼åþKÝUNK2ƒr0çf×HÒï„”NK2=v
´¤%èpZ‚ÖŒ–`EBìpE»#µ<V_©QÖXžMhˆ)h}VCàæ�iH§Æ­(ü®Å �o¶)ºª{Ežíðõȉ–R±Dq9J¬´°ÕáÄâ"
4àßÄH‘J
¹‹IHðJÉ¿tDòA
ùp�W„Ñ]�dq°µ~»é±i›eõµ„†‰ŒÝa}œÊ,¶õGWÜzñ/äSú ’s
~†¡œ«D
-ÐÁï8ª‰Éó|ú bf\ÆSNÄ}ž'š¬l~Ë]„˜€°M¹ðÖqv´
\®ó!¦àûr3‹çö€82v
-6òÄ\èUîÛPßO�½WÍfÛvþ^Õ—e{ ’ÚŸ­½²ž	¡¸FÉô|�¹æChà²8
-/8±vœ¤J'�cÒó®	ñ@Ø‘#(Ýj§[í¬~û+¾ðÁfµ÷­£Ë?í!ê ÿÓ
�ó÷u:ŠžZÇCxØŒ.GµvfêD$‹lÝeÌ|h#´k³oë7ÛáÍ6º…™ª²¡€V©OÁG˜6júŒRgñåÿéæhpN¦�UN¡g
/é™P/vÌ5oØ�Ëâ ‘$žð0ظ³"®	†çE`Ñyª‡BP¦c*Æðd1s&Š„�ÿ˜:F
-!¤‚c‡HÅ}w)}D*©œ±DÐ4g|h‰sÒ
-\/Èq:ÛùÐ!�K³N˜c®3¡ÃsÙkê¦ÄSÄó)Ñœ pMH0‘ÅPʉ™ŒsbF�©=+’Í3ðë¾üpz?�ýJqi‘2ÛàÐQ’Ê”?3Åõc®Kß·~žº¥æÞÇÇãýdñE$¦%¨^ïªH4:¦6"
ÝRèݺÎY Ÿ>“ÖxÕÉ|â+›®«6ËmÛ~,:TÁDVÂû^æ/Ôº§`Œá³7éçb[—ô%ÎĬ
-qák'w0ÉÁ¡û¢Þv6+—�¹ÏÇâ$ûSnèŠò1Ÿ‰‚hà*\=�­×ð$´éÄnóK_Æ̈š%"Kùß¡™Î|†ê˜è³�;mûYg“&)àîs«¦Óå‡9Z%�™óÁú+ÿ
XäiŠÊxúfÌ‚¯ÅÄ
-ŽÉ¢FœÑš9#•*‘Œ�î6ŽàÑ+yú
-Så©üŸ’&gDzéXÉé?UŸ0øëÌÿOüïø©y>wB$Yšä^Ñ	…‚ël,yøtþTôÿ
-Oendstream
+xÚ½Z_sÛ¸÷§ÐÛÉ3'š Hœ>ù'u{q®¶¯ÓÎÝ=P"lqN"’²ã~úîbHQòCgêLFÀb	,±?ì?PÌBø'fI¤Y”ÍTI(’Ùj{Ξaìó…`ž…cZø\?=^\}’j–Y¥³Ç'o.„Z‹ÙcñÛ<
¢àfç¾Þ}ºýüëýõ¥Šç�·_ï.QÎ?Ýþ|C­Ï÷×_¾\ß_.„NÄüÃ_¯y¼¹§¡”çøéöî#Q2ú91éýͧ›û›»7—<þíâæ±ÿ}E(ñE¾]üöG8+àµÿv2ÓÉì:a ²,šm/âDI,¥£l..þÑOè�ÚG'÷O„A$Óhb£ÈÛ@-‚$Ë’™J² •‘´øÚ”]g*x¯,šçUáoØsó½l»²z&r]j¼–›
µ–Li.…ž›mýb
+ØÌX&ó»ºã±n�w¸S �ð䉒8ˆ•Œà-P’
+g'®hÀ¤!KLeËÒÏŸæíµ¶K?^.dÁ,Ý€ã÷0Œ6¦Ê·†ða•Ù"Òaª$™-„²$‰ìÝÚЫ<Ѽ†4n×…_š¦ZmêÖ<\ÑoQï—~äÛ6 
Ž "%D:SBQ
+ŸV)1-|.Ò¨˜:Žß 1«}Ó‚Îôîc
0‡!Àå¬=ׄ¾zD›§U2”áqm7!™ïòn�›O½ú‰~»õ¥˜3�…d:7ZÓ¼€l»ØowíhüÛÞÀMiú�¼£V~ÐZ2‡� nÕmÞˆD}Þ!"½®
ÿ1œ2­2‡21eÕvÍ¥žïW�SwW;uÓoË¿¯%¼Ù1ÐE¨§c¸©Šñ÷ªšÀ}š‰’1?gJŠp~û4‚a»3«·Ðà
°²­…yÊ÷›®Ç¯]"È%ál‰L¹z*‚s2i0©Ô½L' �ª8Ð:}Ú>×ih÷\¸bÛåÚ£U{Û2H­Î‹ÐsMÈ0À¶ÐA‡b(„ŶcÛØClË�1Šll÷DläÌw;S-ô¯ÆOÔôkÁiÙG8ô™
+þmkbÝ{úó7u!áPÇáÈäeJB´z�Á­€ë8`1ŠXć,íÓ,Jkø

õX”©<�Å8�)²
OÉ“f�TÊ94¾¸¯&ûMŸýCKcž%`‰J¶]ݼ]
+!Ük¡zÉ?¤àäÈ€WØæ|¦ê§Ñ‰;˜²ƒÃ(L»jÊ¥ç(F��"ððð>2ð͈ElžgÔ¸÷ÀÛó/üŽÁ{</Êÿ
+íy—Ÿ]½g:^~Â!ªÁúä•ôý¡"›�Ôœº=~€d]üB@Õ4eÁtnžå¾Ütv ³µ-ù'`ÃWåõ,Êë˜�Ç–o†A
+´ì¡ðOßĹ“ ÁTyðI:HyÂÙ“#3
fFèáÑ)Êvµo[FŸÀ—?BÓ,]´WTmkV‹M]ÿ™·¸	.	69‹Fpp7ö¿h.Æ“¾ä›²Èía˜˜5
+ 0uCA+raº¼Ü´ÖÇ쌅sÆÑ‘3Î4D¾3' †£qâœëG$Q®*C‹mºÕB:°Š>_©@…:}ÏO')¤OQöÎaó¹NŸ¶žËúi³jêº;}Ü
+‘lUˆ«B¤tî	R!Žõ*D²§B†ó^bAâ}b…Ð�•C»¤;yØYoóÕ¢]çô'	õ9‡äO\ÅbÀ
+*³VM÷GIj)ª§H=æID„†,t¦PÐȶHð&""Ðá8ù5�N:¿y±òQ¬Z Ë“í$ÀdZEò<À|®Ó
+-ŒŽû’“
+í š±W=�^*lMbÄ°w5såFi?q¬¶'–Ø­óÊÉ9F¾<ò3‘¥qžÎÕÏ\‰}Uo·ûª\ÙØ°¯±“•çM½ÌyJØúÓÓ ‰!Ü;�p�ë—ÍÉ
+ 
+`Ñ.2¼‰ ˜`Å}˜ð‚âî�¸¿ø»dƽ½Ë²ÇÑÏIP1šÓ7ãÉpø»kÊmÞ”&WÆnV‹8l€‚n>°QOël�z‡ù	€¹ý‘ó˜½ÍzÀŽç-ý>þýæßÔ‚ãTµ¹
o­·uÁ%–”+êôÙEr¥Þ«|®3ÿ§®ð®¬~ƇÊrîxbËŽx1hk–[*
+q
+‡%ohK›X#"\‘ÏFl¶ÿD[¹¥^ŸâINñb¶:yA=_‘ìá’�‹ñvù’q¿¹
—µ®#ô¶Ø_âÛ¾lÈ„�Ö¼²ðÏ°Åæ%·¸ö¡\ÙKyqh¯ó–F—xùçXÍ÷un+—hѽr“iPGE
+ån
•ðl#ðY§NÍÉz…ã:'v Ÿ+:·S©
$H±K
X{„X,7Åñ(xíƒõaÏH¯~%(c'`ÀCt?…îÙ¡QÑ�:´¬ý|-[ƒûfÎ'Œ¯Ì!~Ò?…Óvg\Ä
+t<ÌG¨•ÿi¯N¡i¬;z‚ÑU¼®$Fw!�¿H�¦Ã×.«²+�á]Õjéyßx™Ë¦ÎùâÃ]šüIˆ9WÓíwlÍË­sU1¼C�sÊ	¸éÛý²…½·—:ö>Õ2ᢧïÝ#‘2y/Žö¹N;�žË†9�y2McŠÅ3"ñÈDx#ϯßsM0ô�É4J`ÏŽ>ªCgî@j9ß”|K
 endobj
-1653 0 obj <<
+1669 0 obj <<
 /Type /Page
-/Contents 1654 0 R
-/Resources 1652 0 R
+/Contents 1670 0 R
+/Resources 1668 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1643 0 R
-/Annots [ 1656 0 R ]
+/Parent 1655 0 R
+/Annots [ 1672 0 R 1673 0 R ]
 >> endobj
-1656 0 obj <<
+1672 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [250.9056 159.9586 314.5963 169.3682]
+/Rect [222.5592 649.8203 286.2499 659.2299]
 /Subtype /Link
 /A << /S /GoTo /D (statsfile) >>
 >> endobj
-1655 0 obj <<
-/D [1653 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1652 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R /F48 1228 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1660 0 obj <<
-/Length 3345      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZÝsÛ6÷_¡¹—£g*š 
~LŸÜXÉ¥W;=Ûé\§é%B§üPIÊŽïæþ÷ÛÅ.(’¢œ¹¹d‹°Üýa?@‰…ÅB…n˜øÉ"J¤«<¡›òÂ[<Á؇Á<KË´rýðxqõ>ˆ‰›„~¸xÜÖŠ]/ŽÅâ1ûÍ	]ß½„<çݧ»÷?|¾¿¾Œ¤óøñÓÝåÒWžóþãO+j}¸¿¾½½¾¿\ŠX	çÝß®~\ÝÓPÈküðñî†(	=Î,z¿z¿º_ݽ[]þþøãÅê±—áû
-/Àùóâ·ß½E¯ýã…çI¬/Ðñ\‘$þ¢¼�*p•K)..þÑ/85Sçô'Uì*_† ÉÀ
‘ÌkY¸‘ÀIáŠ0	{-ûbNË–µÜê¶Íëjù‡~ýây~¡§ï-|‰Ò‹áâ'"ô\32ø„Ÿ¸"ö±�;}¹„ïìÓnW¥%÷ê-=;;Ìšv^u5µ^vùfÇœ–Ôäó¥ôx|øø�ZüÆÔ�צƓ®t“v:£îúõ0Q` <×}xcå̘køŠË ‰ÜP¨á&Jù†}[7°´ò�C«©1»‡L\?Œ#»G{ØgiÇ–ÅÌvÊÅ+É
-§¥]äP,!•ë!þh›«ç´¹jÕ•Q«ÔEmžJ(”r¥ˆü±ˆ_<å=è¸ÅÂUI¢‘ˆ\_%æœÑXó´ Æý
-‚	'­|>B›dÚ§M—oEÚ�LYÞnÅ> #Ã)¤D”¸Qä[ý¢–ûºÈ7sæ
-AqÈÌm¼¥®º¿ZTÄCìÀ*-öŠz“Î!4\/ñ,tê½Q:°áIIÜ؇rzRЗб£©—W0P¦d2$¤ëúÐQ³Ûå-µ¶:í4͈‰7ξ2Œ¤Çp˜ßt¨C®óµçš8Tãɦx
-$¬�ÄoÐsÍH0ÂS
-�”™Â,Î'Ðá8Å5Ÿ€.°q
xŽq
ørã¾À*,(¥˜ÙÎLE€Ë3éY�¯
ÓyxY&Üy_7ÝtÇH�íaæ[;ZžÓGáÎseÈÑŽ”cy±óùæç«Çw?SÇÈ
­È©åZ7Dí,o«›gK¸µÄJ©�$�?çÕ‘Èrfj•õÔ›»šº7Sê®ÞÔïÕ¤[¤¡7è[bidEsAŠè…p}‰ŠÈ—¨Ø�@„Ö‡4�Ad㌶´2Í«â•iUb¾‡#s¢þ�‘¥Óm¯ð=ôB�‰ä”áК7D2�’>q¬%òšÝ.­¬œs0|É‹‚¢9Sh¬µ�q·Œã†ç¦.ËC•oLVˆ„ð6
-2驨×)/	ª?�mðO±
-ão€{Àõº-¾Q0¨Ëe¦ŸóÍlE…‘x{ûžkfÿiE
hÆ´‹ÄsÚš²�
÷1UÂ'¤4Åý+P¿ø\3#À=cŠåè×$@Ýèb(óœÕt1>÷M^¦M^0¹Ò:³«Äaô°zÇîΫŒ“1âë=V&
-ÑMÌ�ÑcÁ
1çEºi‰UÜÕ{"úY<½Æœ¶åèÛÊ	fP°ª;ÂS§BLë4ã§Idj1µÂM݇Œí�gÆíƒ D†Ð�Ì‚7Tø#
-G‘nY=ªdñ¹æÑ2Íôx„“—#d7/º÷}fä•žGMRŸÕ	­>—‰ç�s§£�3ù9Ü(Ÿ–Hýë`§ã\„>ŽZ.ÍcÔ›¶aùkzžX‰\m°b7
'JŽ’Œ¶å\ ÁÁ£ß–ŸIMîþyóéöúãÝ©Gh‡G¼~Î3OØ‘¼»»¾]�ñxY?ëQJ»I!2ðDx5“©…fÏ c3†ž5cH))µú²˲¢­Ôv°Äà]^dÄwœ�wüli„.pRñ’¾òû¬`Š/ì8á:Ý”y¥gSÀ�f7(€y¼š6”nFåÐ<&¹Ø#}AcøòØgp@‹Ä7´f2‰_Òr™|I9Ÿ®‰†¥·„% @Á�åÂ'o•µ<¯G^
-Öñ×Ñèeª�¶Lhu³ÎŽIöÀ˜µf½ó @ô{ß÷ghl)%•sm–k-¯Ù˜�AÉOŽ§š§›w¦5�7Œ�k
b¿]l•ì'ãeù’2zi^þóÒ\
Ý@?··>©É?©$i™¶ÙéÍmO}<arÛõwMìãÉÑå~ùë^Çùä¬ÎåXeüÒsŸ/`17w®¬$|j¬×†�µæ#Ç.;›
y™icœ¿”Vl‚ÄàÂ…CÒ eƒÞi“[®�Ñ §Ë½�·Ä™�‡YUUSûä›õ:zÈ$}HádÈy5å 3Àe—9R
-WÅg‚æ1Ç>‰¿×w¿ò}ÇŒòîjƒ	N£.¹Eɤ/‡È´ 4F±ú,-´PMÚ}bâ瘛Õºá7ÃÐü	?%üÒcCüü€ÿóžTá÷íç‡Õç[lQÉÀ>�42ù%µ,¥â<v‚6¾+
 ¸3Àxøå9”û°`èyοÍr2rcß‹Æ‹ÎÖfRŸÓ
-æñ—Lÿå{nÏ}óÐöÍòÐêCi»ÿù¾ÿprº5
ÎUOQäúQø�âiÀôƯ?˜ÉÜ¥ç-^0/ûLíéçoPå©7è™N%üŽ\)E<á†DÀ+vûÁ0}K¤¾$5ƒi͘IB®�a­‹úå[+R>º”pn¡
-¶…w¨ÜXúÁøàî‹Ùïê¡+db?«Ïërúa&v!\ûÓ�ë|¶Ó¡Ç_¿Ð- DÂO½ëèÝDY·ö
-ɾÛÆsÖÇ÷Ÿöû"gG;÷£¦@¹øK¤ãÂ?èÿýƒ§ã¯Á
-e“+cX„…BM©øô``­ú3¢ÿ•MÇÚendstream
-endobj
-1659 0 obj <<
-/Type /Page
-/Contents 1660 0 R
-/Resources 1658 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1643 0 R
-/Annots [ 1662 0 R ]
->> endobj
-1662 0 obj <<
+1673 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [80.6033 713.4536 149.9876 725.5132]
+/Rect [80.6033 496.1408 149.9876 508.2004]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_policies) >>
 >> endobj
-1661 0 obj <<
-/D [1659 0 R /XYZ 56.6929 794.5015 null]
+1671 0 obj <<
+/D [1669 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1658 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F48 1228 0 R >>
+1668 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1665 0 obj <<
-/Length 3944      
+1677 0 obj <<
+/Length 3656      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥Z[së¶~÷¯ð[噈 .$“Ngœs|R·‰“ú¸ítÒ>Ðŭ"‘²âüúîbàÅ”í¤öƒ@\‹½|»€<ð/ÏS	•éó$Ó‘Òœ¯¶gâü3´}s&¹ÏÒwZ{}}wöî£Jγ(³±=¿ÛæJ#‘¦òünýãâýŸ/¸»º½XÆF,lt±4V,¾¾¾ù@5ý¼ÿþæãõ7¿½¼Hôâîúûª¾½úxu{uóþêb)S#a|Ì3œðñúÛ+*}s{ùÝw—·ÿ¹ûËÙÕ]ØËp¿R(ÜÈÏg?þGœ¯aÛ9‘ÊRs~„É,‹Ï·gÚ¨Èh¥|MuöéìoaÂA«:Ç?mÒÈÄÚž/�Ž”QzžË"¸¶L4¬¤¡ä¹Ë9.û^ÈåuݶÅjY5ÍOy[®‹é¶¥U0¹UçùŸQzÍ�H�X%vLÃ?Šx¯ãE[t_ ʵ‰2
‰“$OÖ
Žè8ñvû™.šGèÛÒ:ÝCA…Ǽ*×y×ìéóXvTÊ™¢¼êŠ}�w®¿\l‹î¡Yó$M?lj
-÷‡²ê–%­‹M~¨:ú€“<¸c„õ7¨	XI'…^p[ìêäÜue¾±¶)t£óé•Lyï9hIk¡˜WMýÙ÷s–+¹{Ø~±ê	¢½åxû
f‘´Æþ&·dDbç‡+9›??Àú£©çNOŽÄ‚yѱ[Ï		uÝt=#oô’H„CÜ95A]òƒîõ
-Zˆ­Pp³ÃoÛ‘:µ�ÞŽÿ^‡c§ç"®˜Wz¤‰Š”ÔÞÜ—õ:‚éÛ™ýƒ“
äèYôÕ€ˆ,
-¤c*|oÚnYŽ¤ÆÓ³c'þÐu»öËwïŽÇ#î.*ÛUDZùù]ÛT´yí»uõHäÈ‘ÔZ%Bzzþ8
âxŸYtëHd™¢ð€š:÷¥¿>ÂÈåp¨F<_
	ùÓtŒ�&ArI6’„b¯‘%Cpq‡¼@D!Å#‰˜Ô>b¸¯ŠmK]ʹs•ЪPæ-çj£,–CÓ�³:ã‹nšC�^¬W*¨K>t'‰„?>¯Ú†û6Û]Iº†ÔÖTT|ÄQ°D1€Ü×졈€ÛvÌO[ˆÛìX×n‹ê©tŽ7±‡¼4–Î$†|
Ô�§�‚ÇgÛ­CÇè°ÒxñÐáö–sMÎËѸŸ^çö
&Äiñë¶>ÑÒsÀa9˜ß!Š!}ÌQÜã‰Ä�M·Ð}R:
¬Hã	OÀ8?ÜÃÌÔ�ÈÀÊD#¤:Ü›ï﮾œÙ6ìÇXó†M[í7ÝÔ•RçàZ*®Š}GQ |„(pEßN²]ihu¦*au$ã€7ßDƒ†bÓ´¯â ˆqP@ÆIÇ8øÀ˜JÒw&qj"0º§a>h
-†:Pçý–Á°4Ÿã€  žp¼íi6@Ⱦ_²�ž¥š8Ÿ£-xìØÆ/'}†½N'}B¯
øØb{_,¡|Ø?Ïü¤I”é8y™ŒÐk†ŽFÍb0€:>¡„mPãdñPûܱnÅ–*�åê�ŠH-•óá×1[rž‚ŽgÐÃíÌŸFì£Êϵ;4ø&É�‚HרylëR 8IǾԇ
#ˆ
-jc/ÇOÅœ¬Kà€™
DO‚è36™1é´9•c´š
-¯ÖPÊW«bç,'à•º=û–\ìŸ:{ä»%Ù€gÞ1¿çX(0´±|=.‘3›v«†N*úNJ‘Ø…\xl,œA™„„!Çè4ßí*mÀ#VÍ‘œ‘戀E‡¢€K´åT{
-pÍG’³ó(*m~oì˼XÒ|Õ•�Åi[(`||êš!ØÂA¯l¡ïŤ[ýÌö
ûL–%//zͬ;Ö�ö@Ñ4�8�!vû«¤x@µ=¹ÜȪkgsG2j©^³¨<‰
-ðaݵó(Zš�î¼|ÿ­Wfd4®±.ºb¿-ë‚×怛ü¬D“g)¶äüØ€G÷fâþ‰Z\V„¯Š (ÇÚ°€Cîà®7“ƒ
-v›
gê]^¾}á6AZ€"‰Šƒ¾=}õêu�O¥eŽÖ%©ßpÆ
-eb^;ã4²·?;d—Yw7鋇GIl“€q‚™9ãŸ¨áÓ%ïSüªXùu}Ä	õ„ƒ1c„�½‰”l‰à¸¾{Zè S@>ãƒ.§I¡#�Õ—ƒÛÈWåá7‹ClDiú;ÄÁåeS—
T.¦«èzøNª,Q›ú1jC¥Ð)5]ãb*¬"3Œ%VIhoŽhÞ°Ž5Ví©br/øÅU›)Žü
-³øî’¿-æüì³·ˆg
-¥iÈýáÕŽð‚/;ܳoR¡éÃ÷C:ROG²ð†˜6N’hš·*ëU³
à5!@ÁQj§O>Hoo?]ÓŽ£Ðàp�Ï^õaê>~ŠÍèùXpÈ$?Ñ©÷Þh•šËÿŠ`¾ÿï·àýCy
Ž=MO\¢)a£0‚'
-9n²)åì¢Iãd†ôÿ
Îxendstream
+xÚ¥]sã¶ñÝ¿ÂÓ'zæ„@‚¹NgÛ—:¹ó]m_ÛL’J‚,6©ˆ”}N§ÿ½»ØEÊ”í´w3ÖX,‹ý&Õ±„ÿê85B†Ytœd‘0R™ãÙêHßÁÜwGŠq&iÒÇúööèíû09ÎDëøøvÑ£•
+™¦êøvþSpö×ÓÏ·×'md‹“‰‰eðíåÕ9�dôsöéêýåw_®OO’(¸½ütEÃ×ï/®/®Î.N&*5
+Ök¦p`ÁûË}w}úñãéõÉ/·ß]ÜvgéŸWÉòÛÑO¿Èã9ûû#)Â,5Çð …Ê2}¼:ŠL(L†~¤<º9ú[G°7ë–ŽÉÏ„©0©NF¨uO€JÅljÉDêÐ	ð÷º²'“PfA½�_%ƒªnA
+Qš·KKCù¶]Ö›¢}$ÌÆÎÚ¢®è¡h§lj±_óUQÙ9�·µ_ÄÄŠ
´K»9Qi`‡tì}1·ÕÌz¤¼e:KÊ«æÁ2¯°n
+�Õ»4x²«µSï(„k™ûu?K#«š`’Ö¬v¿sFp꿤d¸8_YX¥h¸¨ÓhRéäT�
+§®ÊÇ}¡8A:ÈAà·­Ý0^û¸ÞžS*N¯~<QJ£Â»ª�žDIÐÔ+†n?œ;%ˆwZŠÃD€ïÅdÅ«áÏZGçø÷
Oøá$ÓÁß»ÁÔ
~¹Á¿¼g5ßaürsñå#B(K¦{»$%M‚²h˜'?‚LŽÔ~]æÛÕÒIáíûHõ" ‡àW£„¬^ãÙ€`,eðoG.JDªe24ÄM]·“�0&$\d¿ÎÊíÜz
+îçOsû§w–÷¸m:pµmìvåÿóÎí<Ýš&G
+i š8Fé–‘&},
+j$ÂvX¸å¼hòii'yy‡!`¹jöYP‰)pú,i„…AŒJŒHÒ4òpN<ÀUÇlK:ƒfmgÅÏRjô›8s~ussqF“=vݪûujS[Ö/QDkFíƒäàã¶l‹	ÝMlDA
+-£Îž^qs	(ˆŠ3^€ñ*ñŽ#‘»«z³ÊK‚;×|Ÿ'an™74QÚEKC�_í#Ím«vs’¬ìœwD$ºÑP	ÃM®ÔãOòj¶$™êΪ5[uˆVm«9	‘õÅxå€0”¸Ð�
ú9§Ø=¦2ã›ê
+›&b�iâ õ
+ÊÞ`‰ž²_ÐÜ‘ÂîÌvC*TµLˆé×VV™‰0Ü+Õˆ3ñ´¶´yÃtà\qœRÔòù
+|j,�CyÚOã÷ 1÷M]WÏPG–‚QÄå(�ŠöU
;‘D1·ñ8 I';jìJ~‹ãæX´+hq’´GbºÝŒ¿…{zí˜÷ù¸Õn\arÈs¦`K©÷÷äôö«
5¿ñÎ~•WùÝaz4C>éxs9Jß
+ÿh_‡4qºã»Ü”ˆGFÄ2ÜKwž'VèDàW2iÙk�£9F:¸liÖ%–€_T­o±ÂhËT¦L•C4âW43««m«™ï+ŸÜ
”Æ}x¹íx‘CI»âS˜dg¤Jû%u&”IºwPHEaKÿűgº×Ïàãˆ? iàꯜ§¸—bëòy\ÿI€«%û&ç9mWžAúNvꉃRći/ó{Æ+mu×.›áw
+¡f_I¤˜˜
Ï:·¿e�ñ~9[û¬éúý/‘F�ñ~:Ÿx»¹e@­_çmn[\~ŽÅéõgÌÇO÷¿¡ ŠÐÔÁBëóîKjwö?ré§ÿ±JÖ5øN-¯ ÆÈ^9/Ç:2ÚgZÒ{Ò†@ê�›6XÏîc•9í„D®&§ççׇ	m›·y¬ð+–âwwn ~vuúñ¢#&±Ç³3‰‰ûŠd3x 
»o~ÄÓeÂD±éÛØ,¸…€1F1q4èžhîžà¯÷{‰Œ"ºKAû¯…øeµs†S|óËllÿ?î�’^þ_	&j˜pòïÿ‘ÐàscÛ6ïl0o÷*ÉûÂ>ô–
ÎCA¦xoË6è*šáNu5ü‰\ùd¨ÝΗ@¼oÆlð€ËÔ‘0‰~…ÇL£.Ù®×õ¦å¦Ÿkˆ…þ¤�?Ž4åc&Ý«â$‡UÛŒ§ÐÊt­ÎÓ³ƒ�ÐB¹ûîŒ÷æj§<Õ½¯Ê`&_àù÷ÓGšq-~GBú”î}Á°K\&äîír±wO�Óf·Ytã®'ß<ó"Aá7I¨;s{|÷â‹ qèËÐü.r$/’ÝëˆÿûóËÝ·©Q"Â4Õã	V(c‘jHĘ)dÜdûœwßi>eý¿ÊŸïÖendstream
 endobj
-1664 0 obj <<
+1676 0 obj <<
 /Type /Page
-/Contents 1665 0 R
-/Resources 1663 0 R
+/Contents 1677 0 R
+/Resources 1675 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1643 0 R
-/Annots [ 1667 0 R ]
+/Parent 1655 0 R
+/Annots [ 1679 0 R ]
 >> endobj
-1667 0 obj <<
+1679 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
-/Rect [278.4002 570.2936 280.3928 582.3532]
+/Rect [278.4002 357.6318 280.3928 369.6915]
 /Subtype/Link/A<</Type/Action/S/URI/URI()>>
 >> endobj
-1666 0 obj <<
-/D [1664 0 R /XYZ 85.0394 794.5015 null]
+1678 0 obj <<
+/D [1676 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1663 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F48 1228 0 R /F41 1208 0 R /F11 1441 0 R >>
+1675 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F41 1218 0 R /F21 938 0 R /F48 1238 0 R /F11 1451 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1670 0 obj <<
-/Length 3369      
+1682 0 obj <<
+/Length 3403      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥ZQsÛ¸~÷¯PŸNž‰I yrrNꛞÓ:î\;w÷@K�ņ"u"eÇíô¿w»€H‰²“i2	Ap
,v»ß.$&1ü“4‹2#Í$7*Jc‘Næë³xrß>ž	¦™y¢YŸêÝíÙëI>1‘Éd6¹]öæÒQ¬µ˜Ü.~�f‘ŒÎa†xúþÓõ‡«�¿¹8ÏÕôöêÓõùL¦ñôÃÕ_.©õñæâçŸ/nÎgB§búþϽ½¼¡OÏñîêúGê1ô81éÍå‡Ë›Ëë÷—ç¿ßþtvyöÒ߯ˆÜÈg¿þO°íŸÎâ(1:�<ÂK	cäd}¦Ò$JU’øžêìóÙß„½¯nè¨üDÉ$“#T¢'@!M¤d,'¹Ê£,ÏI‚ż:Ÿeq<Ý.çÂM/ÿ¡‡ˆ_ë·Ü42™~-2ß‘cÇk!ùý¿oQÀÒL&‘ÁÝãô‹ºÍdê͇æÝ›7¯MæWÁÀ�–q>™	™4•nܼ*mݵnŠúéh­þ˜u±ÙØÅ`ÈŸxWo_š�„a¿Î«Ý¦è³Íƒß¼YŸ71üqÿí¿Œ3Öî–Ëò«K$³ÑmÓø�I‰("›dÈòX�0
"šõ©œH1r„k¨µóÙn³(:;[7°ýDGyj^à!P�0!ûf˜¦Q®â.®–ç³$I§Ýªl©Õlº²©©íûZÛ1YÃ:þ²°ËbWñׇ¢ÚYže‰»9<	d/„
ÆÉnʺƒD9`+R-˜°dv
-zü»©÷«[O;²^n¢,5:,×vv;²Ø,�3çR�òqUÎW0lH±žþxýùóåûY[Þ×hðø©¨ômÞԿű¼ßmÏ…žúÏN`HVUÍ#.žêb]ΩŸÔÏÓÿ§qk�ì@Åy”ë4ÜŒóoôq{?¡ÆMÏ"ý¬?àØ"ŽçÅm¶s6
- êK┑‘ÚĉSçÿ'JïÁÁ;ê,èqN°‹NÒ¢ESŸ³:Ç6;'g‘æ v53x#´F	K#ä?˺
-™¸Ìª$Û!6è,½=/"J™ò´ö+ÄﺨFÖ÷ n\”ô6+²å°dªŠ#HP$Y>ô$Á—‚Ñéž³—Z±ãƒ^çØ$%RT]%j{î,O³»[—]gy<XÃSRé[%w-žŠzMlx3z‹Ž3!°6‚wýA©›ŽO–åzSÙ5 {8=.R�DQ°{£4’Qm=‘EÚ
-9+a"©Àƒ>‹œûT§‘s âÐÕ<ÎÀIÍPjGëðt"æyÕØœ˜H`&8`áÊÃ[Ý'…|P$>†?g‡Óå‘IdßPµ ¿æHHÁ…“t:/jjÜYz‹¹`hvôÜžk8Å]¹¶4mgä@U*Q¼è¶^ÌÃŒÎîŽÙÌ@ïFùìW¶ó<Œ¯áH‰þR”uÅà«3ðƒ…	O0�¤�£(³w(‰ˆ§·+Ž!ëàðp¬‹Ì-—†H;¦
-fÄ/qÂŒ“<µšüy3îS�6ã@ÅŽf5«¿.š5ç@#Ц¤Ï/¨FÖ±ˆÀtÕ��Q#6€ƒÜŸ³aݳal8&�tl*…Ó“{ø¸›WBžä®D#�sN¾r8ö�Å·)!…Å(Qɧ×ÿøñÓÏW×ôÆðaÞÉ¶Ì  C¦-—ôd|ÈntäÕ(¼Œ‘¹>¨�gÕ
-ß÷öªõ¸½
--5eßn°o½´�××”¤:fèA˜�–\^Ó.·AK;F3‡oñý©Ùñ=àË®å
-�~þ…LÞ(ÓC­Úu³}"r
-£ÍÂ:+£\$
ä
-ßÇIH6½£w÷+NAüx,æáX\"	€9�
dt_Ö\ÚCš=q#èê!M½(ÁGÁ	5pèÂOT¦…É¥›„à„Uw£÷IL3w×Baq—+1!(CÇ'×#±oˆÜÕ›EŠEý9¬±å½àbÌpÜ ˜…mãi]¢­’ŸTbƒÆ
-ïÌjžÓÝo¼ß»ÄdéξĪ
H¨¨^ÑkÃÕ3‰Øv;æ{ú2Œxe‹mwæ9ó3�yÞ$Ò©ògƒÝ”œ®š�]îñÂëb·åÈ/½_C†¸�uhã
Z2ïEÕ2„hw\“¿j=Ú6Ðvžl½Y”ƒH°.*jóù++¬ñû³H™%QžëïÌ"ÁMå)¤Q‰–(oG#a  ‡BâÞI×µ2>¡
ÈÇhFÑèHÄÐåªNð<ˆÐzêKõã9šH5ÀÇ�5?”öq„™F"ÖiÏ@F7¥“€ËOäørP‘FTàJT.aqàÕ‡C`ŸÃ!n¤£gó@Ž`Æ‚×1ìÀTE·åâ;ÞWÍ]°ÿÁ¥!Ì�«üô‘dz¨Ö¾ˆQW‡ÚwwÚß
-…’¶œ“Ót¿	¾¨D 寎†S„ÄÚ\ít½Î}A«Ùuƒ™¯?Ý^}ø'µéþ±³-Ó8‡HµÍÃeªâÁŽV±ÄËÇËŠè¶UܶAçµÃ”0Éð,–÷÷ŽÛŒõ€
–Bæi‰GÛõn}çIZ§éœ£ì�vœQYỞ‡’Ý|F¸ÉQ‚×
G:ºÝàQ
-Q5�!±	&ËõÓT�~¹Äã§Ìžnï�Àt}²Ôuí¯Xû°‘*ô‡>*äÁá‚Ä©¼í'ÅÇwa
?z…ð)MF—ÌÃÝž7‚0M®jFA½
-=.‡…gÛíîö£0Þf|ý6œÓ@lÓ
tö"ÜÁ
+xÚ¥]sÛ6òÝ¿B÷y&BðA€€óä$NÏ�Öé9¾éÍ´} )*âE"]‘²£ÞÜ¿],@‘e·sÎL,–Àb¿wI1áðOL´aÆI7I]Â4z’¯Ïøä¬}w&Î,"ÍúXïîÎÞ|TéÄ1g¤™Ü-z{YÆ­“»ù/SÃ$;‡øôý§›�×ßýóöò<M¦wןnÎgRóéÇë®hôÝíå�?^ޞτÕbúþï—?Ý]ÝÒ’	{¼»¾ù@G?'6½½úxu{uóþêü·»ïϮôï+¸Â‹ü~öËo|2‡kÆ™rVOž`™pNNÖg‰VL'JEÈêìóÙ?º
{«þÑQþ	Τ2r„�RöhÓÎéIª3J*ÏÀ«,_â-
+‡’,qt œ×…VáÀ my#â½&‡*XF«ñ&ŒÀj7°¼#]Xíž\tG¨¡/ëë1up)KOÿŒ:¨ÄEÏydéáȪƪ”fÜp34V4cžSO-XšHÝ9è2
éÿ6îÍ�ÔÑççèÀqûlÕ }òŽéù+{ó0x8xîúJ¼“m²rå�¢bv
+~Ö�É[ãrOgi	÷
yí¦ïvÄË™1�#ð%ç‚wðÃ@‡ä{¯�`"QÇ|«
+ž¦Ñ±mŠ|»iÊÇbVW«Ý'Œe)71•ÞÁËÀáDt¡,“FDcÙ�á°C11vç`ã.&‰i³«PÔñÈàæaÁSêaK`&x¯¢¢é‚Â�Œ¾Áß×	úû¶Ø”*œ¶ÚK³c¬ròÀ¿v*ç#w3rËD±D˜hVU=®F0:ÐÚy‚i±UzZRÀyc¢ î7Eöu	[SäcbÌ&iOJ|œ—Æ¥”0%­}^J)ãJ¤„ûE_Žg쥄Óy`„²AÁà¸xô#î(ì¾ß*¨=°Œ#Æc¶*çY‹þØßêí*fn•¦z(±<Ûz¿ SU¥E2?_½'PØŽ0Ìà·¶t8*¨F\i—^ådLq	J°4h¾´ã<•Fb¡�>«	³6�<ý•küF•`s´$zTXúð©O‡�t¤ÓH`õY¦)Óö0«Íëu—»¢!t™ ÅÖy?»ôY÷¼*¥ºŸ¯¿¡¬>Ì’}ÈγûU1�_wèáÁ¾ÚèNmúñ˜ô‡>0¼”Y‰1Sq–(ò¡60N^äÂ	K“ÿÐ�àoìÛ0„âDûF˜HðFÈ0ÿïÛèJcz½¯”<‚I.>~tï..Þ8OÁ'ˆ¬ÿœC"Sa´èQã³ùƒ³úÏÄÑ{äoáVo_ÚAò“þ}²ÃÃø»àðçÿÛ¯ŒyÆ¢üŸ%”ÙèµéùA
‹f’Hô‰òTÅKH³>¼b¤cÐa	�kœmÐiÌÖ5¥g}„æjähè°Fˆ˜1øñ4áTx'¢tt"Jï�Œ#ŒŒW…
+Ú°²Ït`>k[„]#† ,ð^×ÚeÕbÖ{ìs€±B[ãC '£Ÿ?¨\S¡*A²vÅÈyPYBªf»ãš¼ÅñaPÃI–¦Bu"ð
+£
+YÛ¦‹Û».ÎSÁ‘ùf­•
­øöPnBŽåKjñ©Âd¦´
Õ½LÆÞ9ÀoÇ7�Y�ù?¡�í²­Ù¦ˆr:t€Š¥ÎÆ‚•Çê“Êã˜\¼¬;Út� ;@©'À�²ò*᯹¹Úqª„´ÝoÛØþÁûBq¾,æÛUl’xÅ)ª¬Êc§#´7ŽtˆªOÙ`Â6ÑÏçÃY¸dZ”>3ôcÜZ8ëpA<CEkÆZ'B£¬~‘�’9Ù5<‰�¸5Qþop¢4ï¼'¡&`F?áAdˆûäsOAíÅ@vp<TThH›ÅA7¼‘Ï·“^ƒAbo,§þf^ª€²­²G¨*(	Æ…ÑA@öâÜKÜà€£L¯ÿ „g—´óÃ*«(dâ1Ë’t‡È [z=j/‚)Õµ�Šo¿÷ý%y”b§=sÙWàpbÐœÀ™ÐÌeN™P&=hTF_
+Jg{Î^Ú$8>«c8Ça,Úp¢ÎÓ÷Î,µuý6ÛûuÙ¶Ex´¿[€äŽ£Ç2€æ»¬ZQ�°ßÌ%k#ùn4”®&Ù±!°~XkÈìÁz|¤‰¢ ÷Ž#7ÀS8eU÷^K¡M@Â=}W׫"îò“\s*s–ðDfñ|æÜÇ:�9wX!tÕO3pR3äÚÑùèF¸ç	è°F(¤Íþ­�RCbÿcبãL
+¥^jP8%ûŠjE(3•¦LÁ‡úž:¼ÀÎô|N.†-ýnÎ-Xq[úwð8êΈ;é•êZhÕ<ïvôz7Òž
¹»$>Aa
+I×öy5îc�Vã+8šå¬ú:ÿ‡JIjâùã;¬‘ó‡J,XÂe2$`T‰äŠߟÓaÛÓaÙé0·±±sØ}ÔL&iTŒËËñ«6"¢ÜãëGÅC	ß�®ž²]SAŠou+Üüëç/¯oh¶
ÚM �zz~Ãý†ü{SŸ:†Ó(¼B#S{Ð' Ïj!ÎÛ-%Û~¢¬7@°
 endobj
-1669 0 obj <<
+1681 0 obj <<
 /Type /Page
-/Contents 1670 0 R
-/Resources 1668 0 R
+/Contents 1682 0 R
+/Resources 1680 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1673 0 R
-/Annots [ 1672 0 R ]
+/Parent 1685 0 R
+/Annots [ 1684 0 R ]
 >> endobj
-1672 0 obj <<
+1684 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [406.7896 606.2096 476.0457 618.2692]
+/Rect [406.7896 405.8617 476.0457 417.9213]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_policies) >>
 >> endobj
-1671 0 obj <<
-/D [1669 0 R /XYZ 56.6929 794.5015 null]
+1683 0 obj <<
+/D [1681 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-466 0 obj <<
-/D [1669 0 R /XYZ 56.6929 471.6981 null]
+474 0 obj <<
+/D [1681 0 R /XYZ 56.6929 269.7565 null]
 >> endobj
-1360 0 obj <<
-/D [1669 0 R /XYZ 56.6929 446.7352 null]
+1370 0 obj <<
+/D [1681 0 R /XYZ 56.6929 244.2549 null]
 >> endobj
-1668 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F21 930 0 R /F22 953 0 R /F48 1228 0 R >>
+1680 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F48 1238 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1676 0 obj <<
-/Length 3392      
+1688 0 obj <<
+/Length 3421      
 /Filter /FlateDecode
 >>
 stream
-xÚÍZÝsã¶÷_¡·Ê3GŸ$ðx¹ø®Îô|�Ï™Nšæ�'Q™tDÊ>÷¯ï. H‘’®i:½ñx`±Ø�ß.)fþÄÌÆ•Ó³Ìif¸0³ÅßÝÃØ»h’H”ô©¾½»øæ­ÊfŽ¹T¦³»Uo-˸µbv·üyþæϯÿzwu{™HÃç)»LLÊçß^ß|G=Ž~Þ|¸y{ýîÇÛ×—™žß]¸¡îÛ«·W·W7o®.a�€ù2¬pdÂÛë¿\QëÝíë÷ï_ß^þr÷ýÅÕ]w–þyWx�ß.~þ…Ï–pìï/8SΚÙ3<p&œ“³‡m3Z©Ø³¹øxñC·`oÔO�’ŸQ–+³	
JÙ àÐÖé,3Ž¥J*/À·eUl/%Ý|QWíöRØy½	yE�Oü*>Ïë²x*–¡÷…~wMYÝ£$¾y«m¿,c2Õ¸Ä�ªº-W/D7àK9&4Ì$²çu¹XÓÂuµ	[4Eµl¨yóáîúíOÔ~(š&¿/šW“»ƒÈ,·¿{‚„³DÙ”eN¥³D挑žä1ošò©˜àP&•jÞñ¥Åž/èŽ|ÑH^-õîñцã`».h°ª·ù†:‰hhÃ^¿íŠm9}V˜ÃŒ
õ ·0§�rääáDÂ�yľÈ¶G¬a'ͨ0UÁ÷ùSûIFG'‡sÑÃ󺨨…‚¡ˆÁIQ×]<éºÈ·í§"o“²j‹íp9uè8)š\Gñù±œ¼"£F–ÇÂ5†Yë\Øñ„’h¦x¬�’à²ÿÜ5-µ–e“ÚàYñ)ŠÛ#É`çP¬ìÐÙ	§áJÌ2nYÊaë/p7*sÌ
-ã†îæ÷ÍŠŒð½6å€æqX+4ãŒáRIw¨$u)Kµ=æ̤e2ƒu2ÎÉ8QêË2ßìIzõMËjsZÒŠEŠ” &¡™ÊFT{—Ö¿ðÀLInfýüwRAùk‘éÿ� ­f©Sj/h1%èÔú†îtÂ=
àÜðe±Êw›šâ2ÑÒšù*¿åFâ
-‰UV…¥¦Hœé¯]€™d™²òœ
-C'd-LÊ4ëçq£|N	Ç$ø¥Ä8 vR�Nç¸ýT+ã%}S·a“v½G){ô³”1¼¤¾²Ã¦ar¾B¢U±h1íÞO/¸\BŠ¤]/<à°±^HS–Å\oi-gÜ@jo ¡�DúH½ %}ª±æÆ\¼£ÂWù¯ERbÊ1‚mÒh‘ºìôæÕÄîC,¤˜0b¸û5ä6ˆ‚B�Âê¹ÅÔÃi¸-/y«Û²®h´¨0]XÒ@S>ì6yKWÏ>sDªúSSo
-ïÐýÝÍGjÐ!=EûòF¯øñêö ìO—B¸€
?fîB‚¬Zâ I¬ ó߆<¦Ž9Lo=ÿ™¬«£w«Á´åúôÝö©ŽßmGåï¶hëä~³+ÆWËajjOïÝQMl>¸ZeÀðú'ÁÝïèS»¿Á4›w}áŽ@à*U¤Ð-;YÀÜS[k½&)çG0$døÊ`ÅÈÏYä»ÆkìA\5�*û»ÄΚ~ó¶-["ˆ�~GR	èfV¹¡N/ÒÙ�05õÎ7ƒÞEí±
-€�eK¿ËrYý)´×ùS˜B
-Ÿ©�ü”Ë‚–Î0>1Ï0žï‹	¾1ªFNRÙ7p! —gìeOtÂ\åg\íšuò¯º*š¤®’f½k—õsuȆ„¸,µt'ùèˆÆŒÜ?O!þi9àäoþÆ•R¡¦
-œSФÖW›±ÿáqS<
-ŠçðÛ;ƒ'ZÕÛ0õ‰`/4ñ°Ãd(¼oñQBLX*¢!hû×ù‚,lR2.Evð¶¤l×ÁÛßÄ4ià2|G5ŠþGoð	¾:8ƒˆûTÇo»£BNÑVZøOÊÏTÊN>å̓©»TŸf#�Ù
-°±9à#‚*½ÇÆЦ>µÏ_&°¬e&㮋a�?‹ùuKó½ÇF@¸¸dX:J,ÚÃZx\Â>Û‡’B·F°	
-±¥‡œ~Úm^5 à·;V7õ=)„09Rá9ÑTÕ#hh‘>BãºZP<@íð`:ÿNàAsŒ
-åfC3è?öA>G�qÎt¤ˆ½åò]x—ï4„}wP«h×5€r\ >ebJSFL%(eT"¦Œ
õ‡*-â"ÄuSû·]¹Ï�ßxìÞÛzšMqï+!^õ•
³ÂgŸçõ@Vø†ŒMÙä>}È_ºPC…»§®ÒWÄüd»ÂZ_µˆ–º: —üÌÙte 8ìAq£ÿ€œC€_ÙÓfק:nv•7;8B	‘8YøréSNšÓtT›¦LeÊY7æz•<hS„piŒUÐU†¡àê¡e‰Äë:<æ›�/=`“~úõT
¿@o¤�5Ó‰�(ßܼ~EÆY’ÆwIcœTÄ�”󧲦zu{�‚nÒ(è r#ô
-H(­2þ=

nïgÔ¸íßK¤Oú&îe´.òõ1V5‘7ÍĨL§8~§dÜŒët‘êãÕ
+xÚÍ]sã¶ñÝ¿Âo•gŽñA|¼$öÕ™Æig:i’Z¤,ö$R)ûÜ_ß]ì‚%JrÓ›é�Çøû�]ˆËþÄ¥‰ÃHeú2ÍtG"¾œ¯/¢Ë'x÷áB0Nà�ë뇋¯nTz™…Y"“ˇ…7—	#cÄåCñë웿¾ÿûÃõýU ãh–„WAœD³¯oï¾¥‘Œßüpwsûáçû÷W©ž=ÜþpGÃ÷×7×÷×wß\_Âľ—<ÑnnÿvMЇû÷ßÿþþê÷‡ï.®ú½øû‘Â�üqñëïÑe
Ûþî"
+UfâËø…"ËäåúBÇ*ŒµRnduñÓÅ�ý„Þ[ûéÿtlÂXêä2ˆeh"9Íä(Œb`Z�j&Y60YŠ)&;,drQå«Ýf¯Bè0©¼ôg<X·ÇšXXz‘…w8Zùv�«~u£�Oc˜ YŒ×²%”ñli˜)içÈLD³nYÖ é,C†¢hÖ–Ûçr˃Û+afeÞµô._­èÅ¿›ºtc-
Uú
½ÒHN_ÓpÑTõÓð1ãnóº]”[ž"ŸÛ/šÖMMÃÈë ©ƒ¢\çu�[»T:�fÈÌ0‹cé%Pq<[UõGؤ2rö²¬æK�ç5
�%>“Ù#­¸{ZvôÂ}ÿøJO q�(¿E‘œÓ7Ͷzªê¼³BœM²æ/–UK³ìlÄ0{è_-ó–&+*;=0Á2«îìþ"·12é’qæ(%4pjÞØ
+"†º†žÄ];òºaÙ
+Ö<B	i;2�ÃT)t_Ö‘¤ö%.<!¦,L´Éx‚ÁUî­£À5kðj„Ölºª
Å‘™�M£XÐ#¬,‹a
Ÿí¦œW¸÷² �ª&Ônš:Qn‘çª|™ DÆšLìéÈ䦌2Šq¬€&&‚h�DN?Ûìl
öÖ¾#99ZÙ#!ùó¼å�¡Má³y&_0ã!Lés
_�¶Ua°¯@O«æ±7
ŸôfHuúy¨ÄŒåÁÒÊJɱô!�ƒ�Ù‡
+©¢óŒ²aÂJ )M’³¾BÅ©v8àÄ‚£óé,”qoœÎÛf°Š6ÆÙ›éíM&.@
Àb
Èrž9>D/W�<Á>Ûn÷8|…!7‰Ù
+r¬‚G_é¹k™ ½”A¤i(}Þ22ÐYíR—uÃÄ$„p×-�½ãx
Z•?•&§V‡sžé8Z�c£2I˜f*óm“·-ø�)[‹C©úÌÆQ¨£ž.-º`ØÑEo(‹ÖÑ~ºg_’ÿÖC‡ƒ„Ô+1!°Oí¾	ã¸Á[ø?;ÜÈÁÎ¥¿#‘ÒˆcŽ4„HÃA6sø†OkíÚÎH<:úqo˜øã…–ÑsSè¦OþÞdnAÿÑhÓžá½ã¸ãœòˆ¹q“¹¬ô„’èP)•Ž•§ý×®å(STmþ¸r	˜Ÿ¸pÇl
ªvAj­3ˆÆÈ·ÔHT
+ù¨ˆ³q�äÏ}åñ‚îQ
+è»æbЉb<UÐo*Ð&
5ž¦‹�I0�†ø‰,�äí	¨)lÒ¦ãÓœV‘P¤H
jÒ,‘ªô
+á`/†Ä]BþŒ5¦ÀDpö…<ñTÓô(û’gãËg˜¤p\ÌÔ‰b[¦ÃtHêz
\ãϦ¹å‘ñy¹õyíGq’&ç¸~WÄZžÎÆ›Ð®“ó(ù’Õ¤DH}ŽaZá„g2€³vÊ=B¾d~É4LâTžã—¡ÔÊœ	ëGö&÷åò%¤ˆC8ÀŠsü‚Ó©4&õÓé?϶“véô¹ø64}þä'!`dX–®'£ÆÒA£GYN+ÊÖU–ê#)P0pÄǘ/³iÊ�þø‡Ãý´Ý/�€€9)î{'Ë ÎHp>[,”À¦¡Ž|�ÓºÞ$Ò¡Š�:Ý€ó±Ž7àz,[È?–A…gŽƒ¼M(Š2É“‹÷X«�“!pDZ¯~‹§yHƒ¸­jôÌàÙ#ÓÜýÁw}AÞ–5ž
+zÑVëÝŠÛGÒ%«yl›UiåÃßÞýD
+rÙ_®„Ø`òé‰gŸ�Uˆ–8:0Õ%xð Ó¸CŒ7•Ô˜H.
Oɶ‹6pZ´ÒqÉ:$+ز›/ƒ§Õ®<”k_&æäÂ=ÒáÊ#©ªlÎÛu3¨ŒfÙaÇ�±t°ž™(R
f–d&Ë�þh£\ùÂÛ]�DÑ‘ôÝE¬\¯ažïZ«;°WÝR¯Lg¸¦dfyוëMçš­Èe&t0j¯iJ´`ã�IÍÎóѨk7¶ã^EQõ_^RÉ ®µaw£©Ûn{ef»9ë{æö
+¥ûó	™ì»aÂ$Óâ|?VžµØpŽtr残�u\Çz,[œËa«"˜¯*ìe¸e8}e˜
+œ$ Çš `´Ù8�ÝfbL·ßÒ¤÷Ì¿ä<X]‰Y
.Š5©³åf_oV¶
kKÝ8À_’A#„q[GÜI°(nΧºéý<Â"¯ûŸgØ4föp•�j’îé4Œ„í”{N‰KîCMÔ¶·_”\a®yÐïf1¥l�yjÝ'hÂÙS±Ä€Óú
—ƒRïrP$©Õ¾xÝ#¹{i\=x“ãE¦ÕÊeÒ:4^…Óß|×-ƒúSÑà͆	r!¸Š0ÊöLwšl	ÎGövwªçbév1—*2
&RbŠY²}Ò5°?veä
+â[™Ç�²ÇDsÆ(=¬F鰬ܛ¶ð‚AÕvÕüÐ(5˜‘Iôiz¬	
+ÆF	¢HÒtL‚Í€báEG›ÇÂ%Á
+îþŠ™·‹´°
Küô™Ò^
+¾K¥É�#Àyn¬™ëºç:°h
º¦ !*ƒ|×…n�)'(Ä–~äô°·AÀo÷¤®n¹ŠX"E{׳ˆ-@Um
é#
+ctŸ‘¯ü)ˆ+¼
@ÍèáDÉåôp´¡0€„Z
+]ž-M¾õæñp-B¼kÔzKɱ‘X ¢�ðDTÉ63e:Aú
 endobj
-1675 0 obj <<
+1687 0 obj <<
 /Type /Page
-/Contents 1676 0 R
-/Resources 1674 0 R
+/Contents 1688 0 R
+/Resources 1686 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1673 0 R
-/Annots [ 1680 0 R ]
->> endobj
-1680 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [182.6146 117.0296 231.8861 129.0892]
-/Subtype /Link
-/A << /S /GoTo /D (notify) >>
+/Parent 1685 0 R
 >> endobj
-1677 0 obj <<
-/D [1675 0 R /XYZ 85.0394 794.5015 null]
+1689 0 obj <<
+/D [1687 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1678 0 obj <<
-/D [1675 0 R /XYZ 85.0394 720.9574 null]
+1690 0 obj <<
+/D [1687 0 R /XYZ 85.0394 511.7419 null]
 >> endobj
-1679 0 obj <<
-/D [1675 0 R /XYZ 85.0394 709.0022 null]
+1691 0 obj <<
+/D [1687 0 R /XYZ 85.0394 499.7867 null]
 >> endobj
-1674 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F48 1228 0 R /F21 930 0 R /F39 1151 0 R >>
+1686 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F48 1238 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1683 0 obj <<
-/Length 3771      
+1694 0 obj <<
+/Length 3774      
 /Filter /FlateDecode
 >>
 stream
-xÚ­]sÛ6òÝ¿Bo'ÏD(ñMÌ=¥‰“sçâÜ9î\oÚ>ÐesB‰ŠHEõýúÛÅ)QR2íhFÄÇbw
,öà“~|¢
3N¸‰uŠé„ëI¾¼J&OÐ÷þŠ˜Yšõ¡~|¸úá�´Çœfò°èáJY’¦|ò0ÿuj˜`×€!™¾ùx÷îöýÏ÷¯¯­š>Ü~¼»ž	�LßÝþó†Jïï_øðúþzÆSͧoþñú_7÷ÔeŽoïÞR‹£Ï	¤÷7ïnîoîÞÜ\ÿþðÓÕÍC7—þ|y"q"_®~ý=™ÌaÚ?]%LºTOvPIwNL–WJK¦•”±¥ºútõïa¯×]?ž0!�Y@!z˜r¦�Ó«3RH¿€ÏN@yT$ÌÀ“x˜UÝ–‹—
-»ç2¦bž5�Ÿ²¥oýµØlÊyÑœãf&”d‰2°ìœ3§µèMFŠÔ�^.c™U‡,‚è)a¦·-
ÞÕÛjNÅzU½`)õKç1yÑ4Ùæ…ªmMÝív³
-C×<�.B÷s8Š;ƒÀeè-Á<Û6Åœúš*ûZ4r˜ÁdFLf›o²æ™É>g–s3±‰Yu'D•`f= T>vÒÐ^gm=kêì�4犥‰’giw@ÇÄû›Ä¹c6Õv@ývAÛ©Òþy‚…qQø_`ÝFÄ2aIb\€™ã~%)Î…
-ùs‘Æ¢óâF�Ù²hŠ
cC
(¼øí î>Ñ÷þ¾)Z�=eåªi
-¾4(4 ÇX’$’ÐB<@�x€‚ç�Š¿%:éÚ?Þß¾¿½ƒ&Nõ, /Û!±f»^×$©ˆ¿&zy
”ù4ó‹„ôéÔ‚‡‘™ÀE
-
Üô¹Þ_	"´d4ÒŸ*z–
uUk€oNU?³=iÖ
-qmp슀ŸËù¼X
çB»Xœ	›âôQ“>m7YT@­æÔí‘Y”ˆ¬¥.R{ØöRo©°«�KR:XËüVÚ(Fv°BÐÜ'ïw
 š¶¬*jQ˜‚øŒÍ€„©!cê‘À7ó(°Á†Âð(@CU†Õ„²Ÿ[Ú4Îx,Nj'#,Z«óê©uZ?uP8©M‘o7
ªÙÊÎ1™{žr¡<PN‰b"UCÊ£ÊÉ1�&ú¬râ–9)Ò
-å]Ùq‹µãÓ·~Y¡þe[x»Å
™š¶!(j	0ÁƬž¶È¡žÀͤ!;¤Ô‚%\·Ôì¥
çáKR�É®Þ|&å¥Ñe²éP¸"s%p6‰"´‰„é5;Ï
¶‘žTajœs<ôÂ)\Qß1˜!ðgºö–*´h‰Ü£ìf
-åyíEºƒâ‡
¡Îæ/ÔóyUï¸
-¬EÃ%jÄ‘ÃÖQ¤�Ûà@=ë7/À¹É€ÍFÁh³H_§Óy±ÈàÀS¥lF$–œImù7È–
0žˆÓÓ*A!	PEÛ–«§WÜÕD§Ñ_Úô¶A 	!ªÁ"ÛŽ±°ì"Ú[(¬iæ_Ñ\y	’Z3.´Z‹¼*
Â+S=]ø1õ’jO�]¨˜é<k³1  9u'°‡khLž�Ñÿ{pÅZŽ”zò«bwžØcøÑ„{NàY3&,™·.ÄÁKo‘·}«¨ÃÌ©íËìB±)‹ÆoŸ™¾
ôD ½ƒ�…¨ûK{D­dët hê½
<\"‰ñ
-„ø²n(‹‹z<˜â	d÷k3¯Ñ£ô=DÇe¯rÑ­U¹±[ÞÅ£Ê/Ò�÷`ûcð¯œd*•ö[R2õ™–t<5
çÏBüŸ}�K
-8m	ø?’üŸ»Þjh£89JLËîä~¼ž>}€1=ÊÙ¤pÈ-™’°•Üù¤Íäˬ�rPó@½²Ÿë~
|÷K1y[ÃŒ&ýIij>f?)3<J’	q©R’ÁÑ££tW7üåZ$Ó"TÊåºòYƒâÀÙ+(¹£­WÆ�ÓèÒIqÿÜ~IØãPû¼ÔŸ“&ð»XšâAŠIuÉA—à„p)åyíØAኂʘ•óÙº®«#ݘ€ç�X=é£=Ö�꘺tƒ“Š� lñ.CÇ�Ú›º*Ú1Ë˦´I{®ÉTfÕ.{iºHªÎ!`Õè¹Cñömhëù8€>¸4'­–c˜†œæ™}éA�Ù—3z3L‡ApWæÍÑÞ€H
·çè F86ÍR8kNPNæ÷P1ºwºìè.ØQ±WyAgí�hNžCŸ�¾!þÑ~™Â�ù“íª"¯ÑÄŒjî;¾
Ã
-âçe
-ª=+¼°!YyhÎÂ÷î�¾~jð}ûñ–þv‰î#Óém
-¥Ï®H1Ö˜�qá±
ö<ÏÙ×ÒG�οLðßl¾0ÇzƒŠ
/¢(€LK4z}ƒ\KPÁJ`o(ÁÃ¥•W$Ø�Éä%ƒ |ž‹Ïþõ“Ð-$õ`NCY#ý¡ïcO¦‹ºªê]‡ý
=„"ºó±—\oÃS)Ø1P†åªax„Æ’•þ�' ¹êK~]¸Ï%RÒ�÷ÖÚ;1ÇŠYç¡Çî.¹Å·ç¯.9Kðõ`8p`¤B‚LÄ4#OÙßRrJ¿[!a�-e`.Üòt5n¶Oæûþm0IÜa²òPkïE
t–‹gXNä1£Æ`%p�»fÝkè/WñÑV°ß1g�szuÐÓ—ï©E?&ø«¾±SDqíÚÐRèÐñ8úÄÏÛ³ŠRÞŽ\—†<©oŠ¹õ´ù
í  ”¦OŽŠïíÒîi|åãã;9çèù>çÕšì´5õ2ô6e»íéùa^#:2ÍcÏÈ¥fjü2*éÒÌú‰ùþý½²L¦©8í•«�¦üë{q¬ÁÃ[ôcÖÿΠendstream
+xÚ¥]sÛ¸ñÝ¿BoGÏœxø8}Ê%ÎÕ7�Ó:îL;×{ )Úæ„"‘ŠÏýõ]`
ˆ_’“ÞxÆ�åîb±ß ]ø£+©R•±l¥3‘JBåªØ^�Õ#¬ýrA=Ì:
+šË“â)o€Ë0µ1«œy)S¦„X)n#)q	.îW8¸z”
+slèÅ×BŒ–�Á�‘A\´KþÀ`d}“]îŸâ’=�ê
+¬qƒ•ß]„´GûƒÇî榮Ê�$e$Í7cOà¢ðE¹³œpáñ ¸
+
«‘¥{äÀ©2lR—Û�ŽîKüíveq´bŸgÙ…eۂЗ2yqñd!¼ÉTr©N_naç )ÁY¤ðüTO8,òÎóSõøiú~>¦;ÇÍ"’M<éXµpëVþ&;-.¥Ó¨<‘Eëµ™J®{|ù¹=Ôú’Ë':‡¹,¬Oß¿à£Ë+a¹?ìÿʃ=ú¿Œ‰®�‰.
+â3›¸ËSú�Ú±Ï(ð¡ò9?î#›ý;Å<–Ìó
+“WŸ…Ó8¦§®óáƒYŽ
§A+dl
+“PÊÆíÌÂö1­YœôQ‚‹”q&Ïû¨!Ôi¡\y[‡}g�í„rÕaú<å
+¿5J©5z–¹ŒÖ-Œ¶…œmÃÒ1Þá…*$;wjÛŒ­SuXöŽ^¨u¾yÁ•Ï�ë'
¹ò¬zGCy‚ÙóÔ˜¼™ñÜú”
+|i~%ÅÉĔƜ›ó!hu:E(g#ãĬû—]Içi²N	Uü<ùµ@dßDŸi5fàS°N´/Bܨ]p#
+j_õJ„²Ý#“ù£§³]娔¨�±_„Ý/&#v„]*=o¨ÛWóº
L?W¶-=@¬}g‰¨É»¡Á¥R*t¶Ð«tÌñ>É5²­Gï¾ÿ^‡J(Jh¬5þŸ{ð¦ÒÞÁqBR¡Hö-·¸Ü¸Ki³|‹ö§iªˆ’§qá{pùaxcŒj¸³^:5Rˆ¡ÖEÉBLÐ)¤–lÅì€ûîçÍ@R	êã’GËýx¹V4¹ƒÿ,™]o0r
Jæêûw³ú²‚è#²Œ#Ð`ìöz”�›øézËVïZØÑj¸)�x=Äì6¥Æ¦ÄSÅ¡2e6ŸMé¦õiøË%#Iéªí®v½ƒr’áûëe³£*ƒ¤13«¡pÿÜyq�¿Ê¸‰ãþŸÓ&È»Rc¬!1‘r!Åyï	RJG]ò%DÁe¬«Íz׶õÌ7Ȉ–«!Ú¹oPsê<Y"¨Ýèˆüñš8ödÐÜqî¾kë²_Š, 6!Õ¤�8û¨#ÞÕa%ÕörCæÃëw~n�CØüå4ˆædÔ¢š§ÚèW
+§!Ôés‰P¡¯·¶M1(îªb~'AÀ(ªÏ3¡8›L
ØÚˆƒ”ËüÞ*T÷ÙàkŠ,~M
¥EÑÖ5fA$ìÚ%;ö“<{CÝÄ›f¸Ž;â°ý“CScVcÑ„¾já;xóe@¸ÎµŠ‹X`ÑÚ5Î]óV1¼ºcö+ûÆ:\á±ä>ï\4W<¹Á)GõáåDÃ\
+p~š
z·Ã3vØ
WIcÏ·ò|-·dÁehNå«ýa¨Xè´ùŠŸs¬•PþÚv±%¹ˆ!íašëïÄ+Ûèß>me—ÇP‘Œ„C…o£ÃÀ5Ï)(Ba;À®s³'/*´€Xï˜öͦ8â_ÒaH߈RtxûBb·ÞóI0°±õÀv‡p [p¹
7qTø»{Ç‹4ê/ÒðÕÅö:5à,©šÜÜD±¬=Þ…²⬒ÙØAÎrû‘O�|C
©fìµâ
+p6ôóâ
+§NMy™iY:ÏÂ×·:®ìŸä[Á_agŠu&HŸg
+·ª3H<Sîó}6·’2H*Xÿ~£¸endstream
 endobj
-1682 0 obj <<
+1693 0 obj <<
 /Type /Page
-/Contents 1683 0 R
-/Resources 1681 0 R
+/Contents 1694 0 R
+/Resources 1692 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1673 0 R
-/Annots [ 1685 0 R 1686 0 R 1687 0 R 1688 0 R 1689 0 R ]
+/Parent 1685 0 R
+/Annots [ 1696 0 R 1697 0 R 1698 0 R 1699 0 R 1700 0 R ]
 >> endobj
-1685 0 obj <<
+1696 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [180.4479 329.7693 244.1386 339.1988]
+/Rect [154.2681 635.4049 203.5396 647.4645]
+/Subtype /Link
+/A << /S /GoTo /D (notify) >>
+>> endobj
+1697 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [180.4479 136.7465 244.1386 146.176]
 /Subtype /Link
 /A << /S /GoTo /D (statsfile) >>
 >> endobj
-1686 0 obj <<
+1698 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [265.4578 284.861 326.6578 296.9207]
+/Rect [265.4578 91.8382 326.6578 103.8979]
 /Subtype /Link
 /A << /S /GoTo /D (server_statement_definition_and_usage) >>
 >> endobj
-1687 0 obj <<
+1699 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [367.5441 284.861 416.2908 296.9207]
+/Rect [367.5441 91.8382 416.2908 103.8979]
 /Subtype /Link
 /A << /S /GoTo /D (incremental_zone_transfers) >>
 >> endobj
-1688 0 obj <<
+1700 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [280.9692 254.5381 342.1692 266.5977]
+/Rect [280.9692 61.5153 342.1692 73.5749]
 /Subtype /Link
 /A << /S /GoTo /D (server_statement_definition_and_usage) >>
 >> endobj
-1689 0 obj <<
+1695 0 obj <<
+/D [1693 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1692 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F48 1238 0 R /F62 1361 0 R /F39 1161 0 R >>
+/XObject << /Im2 1350 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1704 0 obj <<
+/Length 3894      
+/Filter /FlateDecode
+>>
+stream
+xÚ­]sã6î=¿"�ÎÌZI‘’ÓÝl›ÎmÚKҹδ}Pl:Ö¬,¹’7÷ë @Z²e·7wÉ)$
Ä-®cø×™Žb•'×ižD:úz±¹Š¯_aì»+Á8s�4b}û|õÍg•^çQn¤¹~^
ÖÊ¢8ËÄõóò×ÙÇïoz¾{¼™KÏLt3×&ž}{ÿð‰ 95|ø|ÿÝÏ�·7i2{¾ÿñ�À�wŸïï>ÞÝÌE¦Ì—¼Â™	ŸïÿqG½ïo¿|¹}¼ùýù‡«»çÀË�_+dä�«_�¯—ÀöWq¤òL_ïá#ŽDžËëÍU¢U¤¥<¤ºzºúgXp0ê¦NÉ/ÑY¤eb®ç:‰²4>#å8Š5Hmžª<2J!K1%dFB·ö��íúyùçª=fX¨,:7׃UO¶H§{ËÁÞ"Q‘HÄhï'kIàýš;KÛ-ÚrÛ—MM€f…Dñ‘§Q,“öŸâàhc­##✑Ëú˜IÀMFLÒXûzM�Ç
»
ý2»'«¿‹g¨�";¡Æ˜H¤R\y@úŽ×B¢­fÕIã42)P|Y¿XÌcáŽ}k‹~¾hoD6›ݼÛ{¢j:�²L›Ëd¬	:FÊfd”“�	y^—È>³Ækô÷w�]b/F%q65Ð˨éj7ÅW˧¹0§³í›mèx®ésQ´mY¼òëw-oò[¬ãߤLHuE2<@™D*ŽÖÝzâ*$Qž	�0¥þ
+Œ†VŒ€ûÀ~‚éZm±˜ã$ЩÌDqš�ŒE”k-éèl‹ÂI
󙦳®ØXí‹wê8
ÂPAŸt¾®Û´4Ò/ -aY4½
+é°×ì*væîrìËΆ«çÚ-Ý€·’ÎJsÔ?ôþÇמ/û‘Á&š>£VAŠÌ›­SxÃÅX!4C³ˆƒl±[t_;ê­šÌ
+ZSûåjYµ¯¸ÖÊoµnºž�û0p�JEi–§l¸WM1QÑ¢ÙLú²C£|”É”;ÍÅ]œ8pßSZ�ö�Çc0W‘%Zéñ™BËälú‚L›8ž‰˜ÚMQV�ôÚö¤%"›l:úå‚´MQUNÚ±gÂ�)«MG€1WDGrˈ¿xväðð‹¯Õ±èA%dêÝêˆ~Ž6Qªsy®Nñ†êu8¾Œ"!
†öHƒ
âŒ*´{[U(ˆBP
ôµnö5Ã웳¹
+'QªÔe­ÀÄ3˜}‰
+Ï«àJyí]”«wÖ׉] ›†bãb×vòÁ"“›ê,JáàÇ�…6nIÇ° e
2Ì ¾H
+/=
+ˆ×g˜ÃVÍ+CØ#mMÑ|lÀü¯vR™ž.I#É¢LŸL§œëÊ3§!ÒHáíc±€x²¢èX¯lâ¯!tHd‰äèz02Ú­g¤Ú/G3á‹	ŠLw“Ò
+££ü¸ÖEV]óu·Å;¤!PC}A(éö(fÅAĤ¬À!�²$ã/0VºÀ*BŠÌH*yõ]Ç@`˜èÂæ�!‡ÙP BëOEvS×�¢Ö4(ÙaM$¡Ó`Ú§5#,ür”
+
ê#E¨—t;{!¹už†\OM5E‘ˆœ
8TÏ™*¼zoÖq"²ï£óhÁ³xMå}èÂ:ÞÏû´É{pLÓÖþI=Ç8®X¿¨[NY2´ÞhUæÌ·’ñ 
+¼™¨»e¯R÷ôíVñŽ;>÷‡.ê~’ΞÊza�0ý•“¬Ò’äa0ËÊ
+’Cƒ}2ÔÊ›•j! p¹öœô¡_SœŒ)f�3§FU	e9ô/ZUuΪÎÃü¿k
ê˜p×
̈st”…b>©0ɇijpP#8òÈB¡Âçݶ!·’qî•ûL ¡ F3]qï>ÿüt÷)"8?½àĵOÍ2¾‡:gÏ8eÌê÷Qºç°a;Ó‘Baw$ûCfdRæ�=⻃¹uÁVÓ™¼�jîå&i
†òl!XB¼Ÿ)ñ�¶C¬ó…à€E¹E¿XÏ7Åvk—sLj€
+Ê–GåÞ8ŽL–ä—éX„Œ
‰"6#JîWFtx·š./B,�+9Ì:)Ôq®!#7íýOo	ó‰€
†Q†¹|Ž”“xüBï;A U%¥Ò }RBFyH_IÁÚy%�½CÁ8ŠW˜ô¡îÖ„�ùeOǤ{<Ü•ÃóCÆÏ”ÚU.Iñ–»)lnå¾i¿:©;eç8RPóÕ¶µ­üÅ-	›k�:ÔúÜÖ«EÏäü’ÆDxðÕ�,ÓÇh‘Ÿ?þämv]SÅ%¹`;âLGÈ”9?Ñ‚×\q‘³çsIÏàç‚6#¢XO°×5‹¯˜ÉôôÉUåò>§WS†çpH®ø–dÚ‡oqFL/©?R+ÝÃ1T+ž‚1ÝkM“òÙ
+èqÎ9νœb2®Ø®Š²¢1qk2ß7{ûæ_P'¼IžF&Q>ÈF¼œôo\ŠpñšW,«…÷ÁÝÀû¢Y*åâ!ºJĘ�²eöe·Cé—šz[ƒ`ÑìZHMο­áo
+Êÿr@É(ϵ+
+pª¨…ž#¼hîðÙ�[®Ù'.&>z¼á÷k÷˜¸ÙðkF2«èÝ=�é¾'=$ƒª‡[»¡vm«íÑnÎØ”r†/$‰·Þ¹/E€ÅfFFVƒ}Sl¨¾§i
+}�–ŽÍ
:¡ýôðD8‹ª÷㻺"ÿ˜ÕRÑ>èýQF–ñxEâu´ÿ½»¾¶Ÿ,Ï°½Óü†§}`¬e¨šn6¾¦@Oö‹,¹\ÍÍ´'m0F28Êï‰a³SMT"�{b.Öz˜ô˜ç¶8µ‘Ë"üšàüÅ?1šZGRÈdªãC‚wÿCƒ®?9Âïðâ0QpRY”f©¿"X=›ºGX•J}¹³Ã_ÍlXKÐÊòÎø^Öºe¢¼VÍÕBŽ÷NÀÅ¡Øõ÷“ê(I>ºÖÑá‡EJ™|\ešŒs|
ÿ]ÔˆCéX1wg°Cw†úNy½J)%(@€oö»Jo!¯8}2ÀI’ªäœt&ÈMà˜™ŒÉ¥Çr¤lEm ÿ8vY6–ɧ»‡¦¼^T»¥/	ê<Še~T9<Ý}ć´t†aGѳ
Eþdn|œ
ýñ¥î}ƒz'O"/äOð±´•¥KøXJøâ7¿tÄg)½[ƒA/;2‰¸üv[�<÷‰Ñs_á_χ+—=Cfw(|?‰¯�û�¯Òþ8w½ÇÁØüÏ¿
>ü@îžÊ2yþ÷¤ž3…‚1ê˜r
¶Cg2� ý?ÿ¸Ï“endstream
+endobj
+1703 0 obj <<
+/Type /Page
+/Contents 1704 0 R
+/Resources 1702 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1685 0 R
+/Annots [ 1706 0 R ]
+>> endobj
+1706 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [277.6219 224.2151 338.8219 236.2748]
+/Rect [305.9683 735.8254 367.1684 747.885]
 /Subtype /Link
 /A << /S /GoTo /D (server_statement_definition_and_usage) >>
 >> endobj
-1684 0 obj <<
-/D [1682 0 R /XYZ 56.6929 794.5015 null]
+1705 0 obj <<
+/D [1703 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1681 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F48 1228 0 R /F62 1351 0 R /F39 1151 0 R /F14 956 0 R >>
-/XObject << /Im2 1340 0 R >>
+1702 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F14 964 0 R /F48 1238 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1693 0 obj <<
-/Length 3838      
+1709 0 obj <<
+/Length 3804      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥Ërã6òî¯ðm骈!
-Òðf•¤QðÍý§oRðçÃOŸ>Þ÷ËçÛ›,îúÄàÏwï>ß}úpw³Ry¢`¾–Þ˜ðñþïwÜúîóí�?Þ~¾ùãᇫ»–éyUdð ^ýöGt]Á±¸ŠBSäÉõt¢P…¾Þ]ʼn	“Øi®¾\ýÃ/8¥©KüKL&¹Î¨õ„�*‚vœ^gI¦Fbà±­l_ÊÇÆ~u³2‘	úãz‡,tPöø5ÁËÖ¶¶öp£òÀò@Ý3xݵk{œî84ØnüÀÓÖCk{YµÛø5«\o�,QË¢½=À²#=B°x°R*,’DÓ�ú¦<á‚iü«ƒÝ°™»ò•a�2VV•­x¬l+†íºªþ=Š´•þã+#ÛápŸ~p#ö&
-d…}yjÛƒð˜4
n›¾ƒch�òÔÕUÝ>1Ÿ¦÷¶¤éÄhèoà¸G�]�ü\#µõPwmÙ`_U9”<òR7ë÷–ÈàqÏ_æw{{(q
·äÀ_&
-ö]ß× ¶ímÛË]Õ:øóhpî9í¬˜CÇŠÂÕw
]
-
- $ðeª¡1#	ú=ÈtCOSÆ)èÒô¥
-”Wîö$ð:*‚zƒP�ÄC½r³ìŸ{nmºÈì²åï�ÿ䯈vç$×Ú¸­¶]? -_ŒÕDµ1a–�ˆ”mº.¢Âu·ã	3åÍAgSãð…r’\Ü…Ø�û^Ò‚´^ÍwµíÁ´Äsyû]ëx�Ö8,redg<tE�Šø»+ëÆ“ÞÚa�teX¥´�p¢_mwØ•MCÜŽÜ!èNElzÌO%Àߣ$º•	|¾(¸…?€+î‰Z�³^G¡Î”P3£_˜“¤!ØH=gÎòÙ`­(5¹,&ʨb–`øžI0@ȨÂ÷Å6
²A+@=·ÝK+0{"›ÐaÛŸÐP(²¨¯²Œ·ÃÐi»�µŸ##S¡"
-2D‘rd^–Í5iTŸDÌ6šîI âËCËÑtv`þÊ'»(L_ÞãFœ‡¹òæv”ùÕæÐíVeÁ±~ã6TªT9ûX®‡#›hœ1QÙØ©!4˜eР@a:2Ûm¤Ö-ÇŠ‹b‚ ³nUš„Ev¦‰¬°&EÖuÏÇ=êP�ÊBY^°Å1+"&1Á!�¤¤ÀæƒULM
zŠv‡jYýØè'RØLP	ÞlÑäÖ­¿-©!G/"i(�±ö4â¹¦1€Úœc!ãEÌÄÌ%|$–@×ï�ËöëÖùŸ’]O[îħx"•d
-‹Þ“ôÅ[x_Ppt¼Ç;-á˜Ntª`�µ"¹ê¸fQ-¼>¾t‡gFgAç¼GJþ<ÛCk§²5cRô(ØÈÖëå €±W0;!±@”v±@Ã'F[üðágg­Û–Ë'”>J,ýž‘9"q
-¦&Œc°¼3RÄ=r	ÚS.½
HyIá°»RF‡–<P@«à9n=ˆ—öuCv'°£6Ú…Kgf\gE©3ä«•mq·Õ¦FF­¤šetX‰9S ø[*g¥an
-gõýéŠ8p_©ÖÇ
ƒÁÀky:²Šqü‹ƒpŽg¹Ðij*9ÅÝ⇃xRï µ;þnm³?Û�ŒM=’3F“Øë]¸"¸L9ÈìÐ⛢”+ûQ&1
-�=äùv'R‚VVvÆ—²%'³å©é¹
-r¾wœ…QäË\ÿ=c²$,T\ÌÔÚ»ó44&-æAÎbÔXà;€úߢF”NäÀŠ‘Î`ƒu†Û$¼†ß£˜B
- /~×è©ÊŠË7'‰3¿Å�rc¸¦XÇsrÉneþzúÇÀ±HÕY!ŸuMy»nŽ•+&Eé"›$ðáËÝ|BË;ÊA(žO©‹³a¸ä×½Œ^6¸uñBx>s‚NeËO•Ð™XJèÉk_6;g­�[ƒAÇ;6‰¸ü~ßü‡‡>¦tLÃhåó‚§Ïéƒ׬¶°Âbþ†|f…§z<ØòyUµ`¹×K¡ÂÌaxñšk‚*@ñSFø�­~#p¬ÚCÇó’|y¸A°” �É v-+°¯Æ?.òàV ýñéÉÒ;3?G¨0ÑúÌwó³´r¯ \Á¡ê@ì_QÔø\âÕ™
-Ëó\ÚÕ¨F'[Ù¶vþÕq:Zâtä^@ÑoÜ£›9ÿ1MN&$"ßÎ*�†LˆNhÇ¢³�«¦eDun¡Ï![WA3b-übŽ:?$þÒÒÅ[žã="½¦¸WÙè"~ua._/´8’v’±0ØaÈ@+†N„Ž#g§;иÔ
-Òç¶sÁöùç¬YÝÔöNoFV¾¯z´õÉÝËL¹ßLþó"„lÖ¼ŸûO�ÞNý´þ‹c®´W`
 ³±Û®/ª
-ö‰!wz—�tIÌ,šjâHψùÕ?ÌSñ«ûæÝàX+ÈÖ�—¥03‘�Ì$ùøÎ
À¦+)ÔHègIi!Ñ >Ši3BéagDÚ•ýà–�JNž^
-o 5ç”ûŸ´^’þo\o«2endstream
+xÚ­]sÛ6òÝ¿Âo'ÏD,
$ñè¦N/�Kҳݻδ} %Êâ…"]’²ãþúÛÅ.ø%Hj®ÏDÀb	,û
ˆËþÄ¥ŽƒØHs™˜(СЗ«ÝExùcß_ÆY:¤åëÛû‹oÞ©äÒ&–ñåýf4W„i*.ï׿,â@W0C¸xûéã»÷ßÿt{}•D‹û÷Ÿ>^-¥ïÞÿã†Zßß^øp}{µ©‹·¿þñþæ–†bžãÛ÷¿#ˆ¡Ÿ#“ÞÞ¼»¹½ùøöæê·û.nîû½Œ÷+B…ùýâ—ßÂË5lû‡‹0P&Õ—/Ð	aŒ¼Ü]DZ:RÊAÊ‹»‹öŽFí§^þ‰0�*–J9b`*mŒ¾L´	b%•eàû
îá›wQ:Â4AbD³#ÆC“gŸ—ëªmóáNfMD�(Á¸o®–JšE·Í¯Ä¢‚ŽP‹køG­æJ¤‹|UÛßuKÀŒ ÔYçeÞåkìÈEþœó/[×b2l»àò*{(ó5œadÒÅ5CÛýãcÞâd@óå7/aÏK!£µ¤­½ÂyÆÂÒ
¹¨²]þ›Àp~ÝeŸóv‚(x+íS]µîÓº£¡ç¼)6¯WBˆOõ�¯²}›ÏÖúîãÝÝÍ[>Ùùê®^Õ%AÜâë¼-+d	~³î¬:»£pº˹È	úÑ$0&Iíè=mFÇ‹]¾ÚfUÑî°««¬"xÞ	U^ïÛò•€Žl@¬�mÞÀy¾®¦qÚ>
+?°çd‘�(=¶˜Yµ/y3fèëôf`åiÕc`üX{”;8 À›
+_jô¡³ö;|BZŽ±ÈßOÀÔcá^‹/KÓrÓÔ»åt6y“W«¼�S#´Â$R§Éé±<ôŒ#¡“ Ô:žôo>”Y"M�øœâŠW¢m6¡Ad\˜b
»Ò	iŽÒi¯9,ëÌ
+!Þ\m©Å6I6âá¬z´¡@ÉEìÊ
gWt6òµ3Ô4°®_ª¶#ú³¯ƒgÎ3¡ŸD˜�úEµ"äXHK$öb9?§‘HÌL¿±ߢ%TšÜ
+…Ð;\CÅ,h8ìfm¹[Óïƒ[S‹,(|‹N~ý
+‘w±¢œ¬ÅÐY¥.FhýÔ‘ç…vëX/@”–¾ƒz)Öý©RŒŽ~ùx!cøò”ÛÀ]…˘6–µ$jñöÇŸx†Š!»|W7¯Ô†P±Ýï˜,Ï:‘3–Á ­àÅÔ¬+Pð…L08;¦NRKÒAlô:ˆ�zC¿ýðA@‹¢9i•“*òkjГ+HQü§Ff
¿ë×�ª±]³²IÒÉjì@�ò«#"XsãÙ'ŵ†'0´!³h‹?ì@ÊÖ	S=¡
+”‰ã‘??œJ@X !4%òžÀ d¨ø‰©ð�ö¸MÊÇ
+ ².-uJH˜Jn¿lk×MBÙ°o`ˆT M<ó÷_ÍØ$Hñ¸Ówé9fÑgFr7£'5ö'tœß202vÖ��Ý"Hc�c·…5*‹eÍ÷8úmŸ0¡~F„ELí„¿³¬³&öð®_]’»Éöew4LŽDD:’§Ãä1Öñ0¹Ç²LƒU‹åÀºIT,4iÀÉÕ{,Ïò“¨X†�’*™®ßWŸÚm½/¹üóÀ5$²¶Ð Â¶^ë=álmHhëV¸‡§Òõì^ZB"
ŠmÀ…?lözCË¡Ô•­×|Ž­+ƒQcÍ_,]¸Ti�ÈHÌ
+S3ã„”'Y¯¶`¬m¡Çˆ#eÈò…8:™ %S2éë�ë(ÑO‚¾µßö$Z:æj�I¹u‚	Ä#5˜å‰³'‰-ˆ™û`¿{°|�v=EÒ	lÛóʼn�¯-«8
+´	ÓÓª<Æ:®Ê=–@[2^’
=Ðeо4æôò=–gý©.ë ÕJN	¸©8hIGE_h·û'ˆ:ê•ÏüÂÙF¡‘çÎ6o®’žÃË’³Ÿ*–¬ÔEg©ÓÔÙ!ÆàžµQ]Í  8+„iØ;¦‡|Ëq|J%?ˇ
ÿ2ÅëÚa *’™‘2Pjª/AT‰É
u¾Fš#`wÚG §8‘žg 2½<#Î#¬âì°Fâüœ•Å:³¹Ç\¤U~]èÓ$ôX&Û�€Ë!ìwB„i¥’^¤±=¢ÊöýR
KÇBXæR­±øXw¹gJŒ¿’Ä	Ö�ÆÏfŽ“@÷S
+4p(7xU$‘‘S™<R´
+!6�ÇQžLɱKô©ä+m¼P®ø~Cc¤ÄÐðÒ Â0€Bœ·Är¸«ƒ¸u°H0óøø°o}ü®‹Ö]±}EiÄaä(Êö��&©ƒ7¥†&Ò~•!ÊÅ4Öƃ3Æ…É0O¤bNÛ
•ó`´7
Øéš«t±o»eV­¶¶ˆjpž‡
 …†(;®ùk.­A‹–Nmi”èÄ2A$6Æø„NBÆ_ixí¾˜?tI¨Yê1ÑÃ8"áw`�2jñ°ïœÑ�ã[ ½ë¡V#’U{È>^©·ª+¬…=î)ªX”/’h�ÒjÓG.]³ÇëÚåçüÕLj8ÂXŸÌV Ò6ÀQôÓc=R³ÇC>«ûì¥í ÇÒÖÿÁ¢R‹¯9Ï£îC‚+‚øÁœvc¬ãî£ÇÙFJÖ—ù—§¢!ë;­ûC�¤éi2z,“-ÇÀ—8SB®-hUÅÂ’ÑKŽ
+xç�u,M-!ñ#
+ô
+g½™¡L&ƺê#ÖS=\�¤'U½2¹§G
+Jž³×hã Q;s_;Æ:.ù=–ÍÔñú~‰ÂЩC�Y¼Çò¬î©CÍ–wï<LoŸÂè6G±Å@ŸP׫ŽG¬ñ…¡Õ6k²_§†E\„ÇFûZuÙµ—2øQÞtYÁË®ëµa€8BÔTãòS4•ÊþÂ&º®k©Ë~Só
+°';¼PüdÂ,…î.3C…Oäâ�7JÂ@C¨ô'ÊíBšdVµMœ2%#w‰ÐÂçkÒ4�Q_ÛÙdEés”:ˆŒ%r
+æö“Ù@b’ä|½Ù¨ÞÅý?(ɚʟœÈHz(·‹Ð‘–…ÂHm´ô>U=ÿ_²�ìÖð
:¿†:ôVƒd Ñ‘9�{~è1åöµ¨3Z0�˜-ç
f'‹aQh°�UÕ�÷(L ”™„³àguÆ5Tó'cüðÑf%Õ’•+EKhm`ÛºíXÁq„kÒ
+d¹(ù!¤5<ÅðôÇ>‘l˜ÛXç¸
x·ïÞΉ¿tÕnR‹T
+^”'ßÕëbé»°$w7uU4
4„
+«Žœ@Ûuh<’ˆìm⮚
P¿TÖÌ
̙Ƅï¶á÷ú

ñ[Ü$b« ?àðÙUœ
+{KƒX\%Á2“Y2ìÑ;’'ÌÙm™hG6ˆµV/n¿£wÖøß5�¬ƒ‡ß�wo¨q÷éš[~æ"ŽÝ^i½øu÷£RM·Nø
][&1îÒÃ΄Ÿ¥ž§êÈÃo¶N)Ÿ#û„á/?
+^ÌG	ƒé‘›%ÈÍ È‡I˜(û^>:Œ`øõø!éÿßö!Ïendstream
 endobj
-1692 0 obj <<
+1708 0 obj <<
 /Type /Page
-/Contents 1693 0 R
-/Resources 1691 0 R
+/Contents 1709 0 R
+/Resources 1707 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1673 0 R
+/Parent 1685 0 R
 >> endobj
-1694 0 obj <<
-/D [1692 0 R /XYZ 85.0394 794.5015 null]
+1710 0 obj <<
+/D [1708 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1691 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F41 1208 0 R /F21 930 0 R /F48 1228 0 R >>
+1707 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F48 1238 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1697 0 obj <<
-/Length 3717      
+1713 0 obj <<
+/Length 3410      
 /Filter /FlateDecode
 >>
 stream
-xÚ­]sÛFîÝ¿Â�ôLÄr¿H8=w.NÎqo:Óö�–(‹ŠTEÊŠûëX`ù!ÑRr½x&w¡‹ï¥¸ŒàO\š8Œ­´—‰Õ¡‰„¹œ¯/¢Ë'˜ûéB0ÎÌ#͆X?>\üð^%—6´±Œ/–ƒµÒ0JSqù°ø-ˆC^Á
-QðöãÝûÛŸ~¹¿¾Jtðpûñîj&M¼¿ýç
A?Ý_øp}5©ÁÛ\z¸¹§©˜×øñöî�Xz¼²èýÍû›û›»·7W<ü|qóÐíe¸_)ÜÈŸ¿ý].`Û?_D¡²©¹ÜÃK
-kååúB­”)/>_ü«[p0ë~:)?…RÅrB€R˜ŠÐXk.cÃXIåøŸz·­²ö¥£à÷(’W"(szmvóAí*k
R žœ¯²ê)ohtžU4ú˜3Ú6«šuѶù‚W¨ibQ﫦Ý^‰4ȳ5Ó)³g¿RÖИ[Þ‹jNÈë¼j=ŸÕUŽ¢‡ýÏ„­1ÒmÆQ]æ[<­°C°¡Jy·?¾àª&ÈʲÞÕ½ÓP1ÑpÓ~Õ†_kz>òô®q{„Ÿ,ë-
Uu5[¼TÙº˜Ó
-ìc*ÅJ—/…T+Þ.iŽŒ€ID…Z¤â¼'–�cÞÚ{$Xyx|øîb<Eã²Ïïã(�Â8Òž£l×Nñ$Uh±ùó-<‘õ«$ŒP/ƹ6œµ>M†u´Š¹lÇ<Ÿf;€/íö*
vM;軝
-ó!D\ÀuÀMQu\ó¯)cBˆH§®µ
JLâ„C¤6ÖNHÅ:”ñw:^·/–']JŽ“®‘Æšx„g/eUð¸ki8£‡—z±
-!ðS¨²ÓÓltX|Œ¶ƒ\âHŒ¹v W�c£ÓMñTe-kSCH”xãì3äÛËÒ-˜è�8ø!
#èq¶·x™<ÃYbÃ8ÿ<îãœ÷¦¬.Ÿó¶¥Vé¨_Ó5/©¯3Qê
-7Hù}=ö²i¨ã®Ë3äÁÂ@^™.±-øj�
-`ÜbÆ!ŒÄ¨è°Ý…ÀÅÒý¼ê ¼ÀÌP`ƒÐ"‡âxí;¸}¨[€;ÑMßᬗ(£…±¯ú„ýÔ	©@Ñ“ªÎ˜�µbÒè\c@ÉsþZáÕ“
-â*¦Ü÷<W~úÓ~!£�HÓà~•wjªýò
-²õ¦¥Nz`¸cYg-~0òäY{ª·E»Z
Lb0õžÈ\D¤4%3mRßψ°%‹_>ò·›`CÝÍ›ûðËöq9¢Oh›n…œz¯
+xÚÅZÝsÛ6÷_áGy&äA€wOnâ´n'gû¾ÚëmQ'éˆT÷¯¿]ì%JN¦�9û�ËÅX`û
@â4�qjTœÈ";ÕE«D¨ÓûõIrú
+¥ÈJb
+æN
+§r¿¬î?Fóíc´AÁlv4yÄÉQ¼Ô„#¤h€oŠP	•x�JœER›Ùºìz
+ª
¬®ÅU‚q×"Z@=]Ή‡X jÐÓŠXå;j²ÎO"lw B»q¨
+ü‹¬žå³G*i’éQí—q]н¢¶rÕµD¹’=ó!˜n>–Íyض¢úÐm2€;X„'óŽÌaK'Œü32õ•½`ÉPê°%½”-ÙªM5mÔµeÔ÷«ýÂÜ¿æ¸^jBƒ±-!Hh)Æ*°-…«Bû-lr ¶–
+pJÔÇêy¬ø¼¢C'ÞÕ¥©ŽUó­¥ÝG†ñÈöc#Ѳݮ8jÝU~+Çœ'ŠÔ¸¬šjŽac4Þ2_ß\~ÏeÍÂÝ&–>º
gŒŠÎib¿÷6P‘:¦}OQ´nÊM
`
Ñ÷]wá'Pn<4v@©$jÜE÷¤öŒÃÞ¼¢›³A੆`»åvZ^ hy� åPÀg*xóàoïà…V@ò=…•]v:¬š¾nåvÎp¶
+)`k{a
+;Š\©¯ˆ×&ˆ×Æ"gˆÙl½µç¤0à]EÏ’Ç]U¥kêŸZn»§‚Û]”R|Â
+úÊ3µ—)ØBC>FnÇiâ¬3‚´ÓÛ�e2ÊÆå4 œk#m]û¯g‘Ÿ$ôÄs:i͉EK èX9lúÅ5=ÚÃl¨
`Ó"ÅS
+o1Õ
S>PJ		s+^ºš	¥—R^*p?x`6�ZÊûÝzªHciòÔðRzŒ|ïÂs½£ïãlØ ¨¢‚ûÖüÀ%6t¥ü=ÜTY¸{",c‘ú˜^†Aó®µIR²ß[M¦ü>—±Á;âo*ÓRéÓ(&núy@VÄfçö–Ó·VA�{3ªQ œßµûù””4×Èò»ýÂâÛùÎ	šªAû
å�
½ú¼4åuÛ^ö;£s$Š2ù„ƒþ2*ÊÒÂeHÕKT`øBC\�!A,‚
+Œ>²Ävþ€'È».û
M0ì•@Yã
6±ìž>”¡blbJwÛ~'\øÙ/œ­vAS¿/wQÄ=‡Lìæ§3iŠK…3)|}™ò€§.\æúŠŠY?Ntš�é7œ*äi¬ð÷/ß°«´4y,ðçYþMnŸæþw^~©«~|”š�ø«4O_®ÓÀÍ&oæ!ć~#ã/'blâ‡üÃ?›~SœáO“Ì�ͯLrw…vJáDsµ«¹ÿ}í¾êÿc|‘endstream
 endobj
-1696 0 obj <<
+1712 0 obj <<
 /Type /Page
-/Contents 1697 0 R
-/Resources 1695 0 R
+/Contents 1713 0 R
+/Resources 1711 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1673 0 R
+/Parent 1685 0 R
 >> endobj
-1698 0 obj <<
-/D [1696 0 R /XYZ 56.6929 794.5015 null]
+1714 0 obj <<
+/D [1712 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1695 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F48 1228 0 R >>
+1711 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1701 0 obj <<
-/Length 3652      
+1717 0 obj <<
+/Length 3445      
 /Filter /FlateDecode
 >>
 stream
-xÚÍÛvÛ6òÝ_ᷕω¸Ä�·Onê¤i§k»{éå�–h›'éŠT÷ëw3€@‰’âÓ>¬srÀ`î3¤8MáŸ8µ&IU¡OóB'&æt¶<IOïaîí‰`œ©GšÆX_ßœüý�ÊO‹¤Èdvzsíe“ÔZqz3ÿeòúÛóo.®Î¦Ò¤“,9›š,�|ýîò‚ôóúÃå›woº:?Ëõäæ݇K_]¼¹¸º¸|}q6ÖX/y‡=Þ¼ûá‚Fo¯Îß¿?¿:ûí滓‹›p—ø¾"Ux‘ßO~ù-=�õ¿;IUXsúi"ŠBž.O´Q‰ÑJyÈâäúäŸaÃhÖ-ãŸ661Rg§S¥›Á£\N“Ô
-äNÖ]…à-›y’
-¡
qpñ|êNt»~¬ÁvL¥a|”pEš¹’ŠÉå5þŽÈ'ùþ0í¯ÀÛjÑ>´oñŽ
-.Œ˜â4\j!T1”§?Ýx}‡
)ŽfmÓ�‚TÍì™
Þb`¼��àßseþ#•@;e*æÕ]¹^ôôPw#‡æ"ÑVðÏU7rŒÐI¡•eœdÇ©³çÌ` s-»×k¿{
X÷ºü<�!Kv¼k–&Vƒ{?x~À!`p×Ì$VšbHÁ»»ÎUÒŒ¹2¶vFF›Üs±fcî*Ž5àˆª†@we½xEñT®èíµ¾oÚ�eöÙ¸§`Çh‘Cu-�__ž¿¿¸NHÉ…Êk¬jù^Ur¿°ÑˆJ©$Ϥ÷î»ì�*‘ZæG•J剰û2£ TÖ
¥òX�u«OµÊ& `�P0¢UvH­R:/^¢U HkUfY«²Âk€¼VåÊk
-�D
y4Hr
Þæ/ˆ<&“	¤(êˆ$#¬’ôX.e«Ví´i§][Nû~±›ØƒùÂ& `�P0”%8‰\‰!	,Ká³Ð~½jjȇ�$
-™‹aº8ôdÖ›[T©6xïü•8qêªY_·Mð
-î$ƒµ/Ox$dYÒü5)�î•Q¼ë€ây¬Å›ÎJ°Éõ˨¢!ª$#`�Ð1¸²ÕIjs1$„ÔO@.‚$8û…š”Ûh>ÅšFh(-œat§oG}{&˜Ó68ñã¤Ó6áÕ‘¬e!HÖ÷²v
-RZˆa„U
-x—ÀÅzQшÜ\‹
�ðZ›'¼�Hf0pÀ�»
--Žø7'€`k�.ûRAû¸'1+…g%'çHK(æ_í€Ës‡á*ôzblzŖ镸VåÄ
…i§³<€<Ua;€ÿL§(ß0Ðæ8€²aäÄÓ¤‘òÀ›Dé&Èð@&Æ78‘’ί_Ö‹r5Ü´ëß(
…x]æë¼éÀÄ�³üa‡é#ò˜†•Û˜µËeè,-ê†ýéĨ§`×m«�2:¨B	fر=®BB¦‰ÉŒùm#m�ælüƒž,×®C
-ÞVô[ò¹‹ªôSýSËs3J%pÞ{)ýU ­<Ól¹¸ÇüðaI3täãÔך6ÑÅvƒs½sYVSÔ°>¦ÁÀ›6Ž�iÿãljÀc:ší†f:q‼%¨¡Oýì§]ÛFdƒ²åBbýï)\CÂ:¿åó¨sÙ\~UÀ}bø#oå‹hÚ÷÷5ëûî?¬²›–
˪µ½:xܾ^,†ñ/ò
[¤pш¡nså=I”’2y~$…Ž±ö§Q
+2?øÁh‰”söÛÉT!Áz²#d¬:6Qä‰Êò-B¸‚snƒ¼ŠÙpX3ËRÁMæ’Ík,'Üî«DÈàÓËØiÞ¶.H*¶{GɘÝg*±ÒÚ—¥iR…0
-Ä�ÛY£ÒEbíЯqøÎM”£@UF9
-¸Á�ã{Îù((åœÿ!dßÝ
-§§8Ï8&ä”
ºr½Ù5ÄuS\wóe¿u:{rQ$1ПI™,|R†£({)¢舂30Ћ(£Eî‚8Ïø‚\o¹tÁxWv
-äðbè±íê¾]=o|¶IõÐiS.'5ûUÈø7ïOµKrêv^ÏÊUTÔ½A´®ª@Õ
å5n¦©žâë9=y(?Uþ”ŠË/\2Ÿûƒ\ŽïâÐ\(ÒVcê¥C[îr�,ëpkáL÷º¬À#‘áÍé
}6^bK•¤
™CÊ.Ѻ­tïinuJƒ«H§<ú4ÆQ©í]#톻ÝW
’c]8Ø"H)¸¢²ù€¢ÝXGQø±¾ÕP¹ÊàX£cÒüKð�°³o
-ªÄ[íå…V)%ó"`!ew·è}»–Æ…‹‘(V SØ*ƒ‹b[ãÎÀßlõ-#÷µÍ‹/|ü¦¡¸K%:}´îÔ÷^
-åàú…Ò7	�õr½¤‡QbÐ3*mýIb„–jr9$ÅoˆŽå¯‰Âù|òçcçk›Ø"|? ´c‡Ì)LÑ 5mŠ7ï�†¯°¯'ɺ‰úþÁ8:³žÐô"Mre·å]½€ÒpñW�óõì@(‚!FG¾öˆ±ö‡ò€…¤ô«çi?{œ®ª»UÕ=Œ½sS ‡	X#l¿sÝRpsV
-aô‰&®±€Tölõ¶^à{±Ð­(÷Ne[Ÿ(Ï^5d0"ËþŠ—a"‰°Ù‘O5b¬á±>¶^USÈ~ê†Æ;!VI	ÕéARÖ-Ãì.KdºEËùÂ}g¦Dá²;	ÂsS.�…×AmdœîWe.•¼4ÀIƒÚ%ÍÆï
+xÚ¥Z_sÛ6÷§Ð[å™%
¦OnâäÜ»º9Ç�›NÛš„,N(R);¾O»X€")ÊîÌM&&¸X
+ˆ§	(Q�EùÏÆÖ—+¡“eF�ÿ6µ¥VÙÒ3oê?¢ˆ?ö—±^Ú‚¨Ïe·Ay'û�“œ
§Ï]³¢íÒ°m›…ÿ?ø±#
£„Ii”[v^
+û­l»²~<Îó�_½Ü"÷M6b»¬È:8®5,ˆ+kÖÒaÝnExù#J"ÜÁÄŒ8OY¬@¯©HXÊcƒöA�ûÇ5îÕó¯†N
êtÞ�qÃöm�iøOe8¢�é†Kœ˜vÏõ†$"RL*iÆ’duq²,‡IñwUÑó¿%ÀɼU´¶ƒ¶gu!#Δsó×tÑs½!Êél(
+®QYòdy¿±3ŽË
j:õ¾7�PÞ×À¹Ult°QÊÃè5U‹f’›ÄOÚ캲Áhqp4çÝ‘XvK¤5¹÷_[ç/Ô׬©ÃHÖ•9½M€ãtþݾƒ—"—_¼êÐÙ÷­´Û·#v�ªŽ^ Ê9¹åPB)f$D\EsÑJB3
�7&-IÉE@ÏÈ“7Ía�‡€"&ÜïZ8ËíaK/³Â`XR‡•âYãš�E	“ƒË¢K¸¿~
ùÛ[ëKÍ´‰‚iÄRΩb
�5��KšwÞ¢?À{Ê)ºŽòqc÷Ôû9Ø¡†LÄR¡ã±Û²²uçâ6 Ÿ’¹-Ø	xðZÁaJ%¯§ñ!×ù4Þs¡(ÝþeÕå»ÕÞ®÷¶Ýœdob딿.@Ï5#ÁÈÜ Â¥ÕX„ûKJ@}Ã$&z¥xw¹¨Ó84|‚¾Cë’ïߦæ=ìûõƒ'€;îKÛÒË:++ð&óåGLoH#�‡c4òf»g}(«²{¹Œãx‰Æ—*'y´šøGï”x¬ÁGg “±
+öbÛ3N)…ö<çM”™K¼a®WL"p�"~~ØÛ`Ÿ²¦ö)´ãL§J¼.JÏ5#ËÚ¥L'©sUUÍ3FDãÀ�–ÅK�m]š7h9Ã�înŸÕT)H�L¨ÙR¯Ûˆ³©Á(xú-†àDï/™exîB�Ë>Ö6â
™€�|™LÉ¡&N—#
ð¥Ëü4Ge	9!`5\z€n²m |¸ýòÏëߨMå�{˜RÎ}pS¢½]‚cÐû¬É‰(fZë�êfÎäbL·¢79·ÌÍš„€4çElæ,«×ÿûýSxã0é×é]K€%ˆ�fɹ‚^8Ë»;'63÷ôÉ
+t3
WYŽ]>T8^ÒIäg•âИ`ð>ËKï9£Q^sÐò6êÏ)¸ù-b{*Æ‘Ôç<ÒÇÌ	
ä~ºÚ~ëü
+PVÍèwâ-�ól1W�
+(k•€ŠgE-¿*^%¦féPI
Р0Œ­?
+ü«á€™ïF'ó:§8éò:}Lç2ÏT c˜Œ Jç?ý~¸Þãd¶þútZ	ÏFÅl
$|
ôá�U+(¤ò¯´‡/e¿Y
º«Cˆ¹¬¥÷¬¿f}@$kìěЫÌ!¾·Í¾£*A’ås³ÿ:œ¿9Ðg¨¦]EÔÄ[¿Š+HE¨©
{f¡PƒÉŠƒïÌ­UÕkÅy3ÚÛa·s2�@¶-»M@¼7ŸŸäØž�¢‚‡L 2 w?×d+ëóÈ8Ž3&1¯§Ë!×ù|Ùs9\Öãª=ý(q
+Ãb!^!0͈0¾"E£•r,Ã(s
+™x½`áª' º‚
+oõÆY¹œýÈ$hÑpW:®¿/õ¤/Á±¤k¨7ñGæ¦vÆ�îÌ\žSœ%±œ\ÒºÛw4w±f]"§ÚÕãP£ü¾<N5¡s ¢ XŽ®‡¾€¼°Ÿ~
+�TW'%£ë�T“Ô©éý¢z
+ÏÖÃuJðWN›/2RsÎÊûÍ ºãt‰
+ÏMæ¾ÆF)ÝÈêp÷
¯fÏßÒ
	[bé¬ÉƒÌ¨GÂ<¬?½aƒzÉ®ÖçíqšKÆ“8ñ5¨Æú‡žÖ'²ÜïåPWxþt�&‹µ‘“è-Ĺg3º£êÇU¼m¸â´uHœ-žTqÆËóf»íkèª7áÃ,{œÝ\¦Ò(|@£[17h%gÔ!ÁÿµàǺ1;÷ó,‘0üMÕŒG‹`ÿ÷O·Ž¿k¸ ´æg~”’j@Ñ0‰Êe'u
#Æ…â3¢ÿH§ç
endstream
 endobj
-1700 0 obj <<
+1716 0 obj <<
 /Type /Page
-/Contents 1701 0 R
-/Resources 1699 0 R
+/Contents 1717 0 R
+/Resources 1715 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1673 0 R
-/Annots [ 1703 0 R 1704 0 R ]
+/Parent 1724 0 R
+/Annots [ 1719 0 R 1720 0 R 1722 0 R ]
 >> endobj
-1703 0 obj <<
+1719 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [254.5198 207.8764 332.9349 219.9361]
+/Rect [226.1733 731.9163 304.5885 743.9759]
 /Subtype /Link
 /A << /S /GoTo /D (man.dnssec-keygen) >>
 >> endobj
-1704 0 obj <<
+1720 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [353.5545 207.8764 431.9695 219.9361]
+/Rect [325.208 731.9163 403.623 743.9759]
 /Subtype /Link
 /A << /S /GoTo /D (man.dnssec-settime) >>
 >> endobj
-1702 0 obj <<
-/D [1700 0 R /XYZ 85.0394 794.5015 null]
+1722 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [339.2005 220.4734 400.4005 232.3736]
+/Subtype /Link
+/A << /S /GoTo /D (zone_statement_grammar) >>
 >> endobj
-1699 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+1718 0 obj <<
+/D [1716 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+478 0 obj <<
+/D [1716 0 R /XYZ 56.6929 471.141 null]
+>> endobj
+1721 0 obj <<
+/D [1716 0 R /XYZ 56.6929 438.6197 null]
+>> endobj
+482 0 obj <<
+/D [1716 0 R /XYZ 56.6929 198.1284 null]
+>> endobj
+1723 0 obj <<
+/D [1716 0 R /XYZ 56.6929 170.5486 null]
+>> endobj
+1715 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1707 0 obj <<
-/Length 3137      
+1728 0 obj <<
+/Length 2602      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥ZYsÛF~ׯà[¨*s‚9pÕ>)ŽœUj£xeíÃV’ˆ%”A€!@)Ú_¿}
ˆ‹tÕnR6†===�ž>¾X/ø_/ÂHE©IqêTèp±Þ]‹g˜ûéJÏÊ3­ú\?<^}ÿÉÆ‹T¥‘‰�Ûž¬DI¢�›ß–‘2ê$Ë�¿Þºûé_7×±[>Þýz½2a°üt÷�[ýôpóË/7×+�„zùñï7Ÿox*?ÜÝÿÈ””g„>Ü~º}¸½ÿx{ýÇãÏW·�Ý»ôßW_äÏ«ßþxퟯeÓ$\¼Á�@é45‹Ý•­
-�µžR^}¹úg'°7KKgí§eldfhLÏ€‰Vaš†‹8LUd�%Þmá•\´l_rü§®h.�MÞ0íþËíGû
Ç12VL-Zy6ÌŸ•MÍ”*_çM“ÞE¶�7y™·ù`¿�e¾NÍòˆ'š\„o×:YÖ»9-Áø`�•Ö*
CC¯“íó¿þv½r&
-“ÐvÉYÃ_�rƒ
-fZõ¹TèTÖq¡�8h7ã}SȬ&/ïë™föíç
- æûI}:iãŒr±3ÓÏÙXP¥’8¾ê=¦ó‘î™z�Ž~1ÚW´"Ç—6; ¼¯K Øû[éì‹÷Ák Ôî>3!Ûl¶7OÍ,„—á7C±·¤z8Ð;¬c8‚%®˜µïÌy€hœ-p„]@%ûn¹CXÉ�R`Ûáyö6GH®üÙ6Š¢!4—3È›p ݘa\DS$ŽÔÚóócŸ³†›š 1ÈšAŽ±ºÝØjÆÇžËú	!‹ÌNôãÄÜȪz9�¾Ø‡A�ŠÍ†B²©ƒ}?^3(Àdn˜«·L„‚�À!𿱧¬�Lg³
->ʶ€<9EFœË¤›Šœâj«Ä)«´ÓÅ÷>O“Rb´ ZV>å b$hC>ÈúÃ[ôÞE�…Ç(eùÁC™|ç
-©õW~‡/‚²¿ÙõZ+­Ö²†g¾¯ÇÒ

Éš;ó†|Á
Ä2#DÉ“õ¡ånAÂå[}øÚ—_©­†ß{ª£H‚žx'»PCj}O
Ø3{ò�ÛE=_ÑFq_vV¡hF;î÷¤Ó
-µK†Ž
mtÕ #ÐÅZÑ¥¥�êÇ¡Fý¥="¡s b XÖ×ÃœG^8¿;Ò[•úd d|½Ò:N»¸(_ýÄ‹ðúýpŸb�ÚIø%MFœN½\_Ñ�áKTx¾dør.ˆùF(�7³ð7üDG‘]’7	È:$lüþã¶ú%
+xÚÕZ_sܸ
÷§Ð[×3‘ŽÿIÍ=å'õMϹÚîÓÝ=(»²­ÉZJVë¸î§/@�\I«]»Mn¦�ÌD� ü
+æÏ®W¿-Þüõõ¯×g—§¹ÐlaŠÓ\¶øéüâ-QJz¼ùpñîüý?._ŸZµ¸>ÿpAä˳wg—goÎNsî4‡ïE�pàƒwç;£ÑûË׿üòúòô�ëŸOήÓ^†ûåLâF¾œüöËV°íŸOX!K§³Gxa/K‘ÝŸ(-­¤Œ”õÉÕÉß“ÀÁ¬ÿtÎ~ZºB;ag(øœ
uY)¤7 î™›B�	c‹×ËeÝ÷Áj]»ÝtkÜ#HI,Ë‚Ò¥—‘>Rb±íðÉÛ»š}½ùZoh¼¬Zšý&7§Ü-ê~»i–ÛzE´�UOC¾èÚ 4
+;ÿ•&ªÕ*|–ínFœ<Hþò
+áq¸(
+öŒ´%·Ñ`”}š-ðY@8¤M³B“ãëö”/fÕ´¢°¦ŒÛï>ãy„ož1™c§ª–«çA�&ëÚõ�îëªü»yXã;§x÷ëÑÃ;
ÑhQÞ
‘@Ú>·¬(¥cÒ«€~=œÜTë-½4ýE>ûhèv™&9?Œï�Z‘÷z$Zú
}t0‡¨ó_+¹(ÆÊaè
è³�úž
Ÿ
×ø‰\;·‡l³™ÁðyÇÕñÅ×ÌêcÒœƒ/?F¡�W&Â0K(ô
+aTu�Ø"BçYWM[mžhêíÅMQNÇ�QêB'Fp�ì2ÙŒv…àFÑ@D4 ¨s€-ŒóqÔùâ
Žy„HðPÏyŒpd©òˆP
+p›
 ÖF
+& Ï=œ‘À
 ’sÏÔÉk¼9Õ|#'ÓÞD6”¼Ÿ“"׌£œ„U3f¬Á8'É]N‚áº[VÒ›‡ÈH]¢$ø¼¥ñ$!
…ˆ$$èìÌâšÊg‰Uë§(´	r>w}N@©AkÃ̤¤i>®±°–
+q˜ _°{Â'd¨ïëM[­ó›jéÛP¢‘ÿãÖ«¦ÈW¿¬ÿ¤ù
°qVŒ+PÕT÷
Õ›í]÷À¼­1¢ªM‹ªOm÷˜¾J	À+ØVëøÑö±Û|ŠeÖèÀæJ
+ˆe(yŸÉ÷rð\¶��ße{ž²=ÙžƒÒ_èb¡ÝÒÜLR=åëRa”Ù±¾ÄjÖ} ˆ³£“øÓk€xm�²ÿ¾¯ÌU
R#‚Áà³
+PPÁ²â¹*@*^8¦äw­&3K7‰ß¹
+Š>RH¦€
ö÷«€?9ñ‡“ÿ÷‰_h–„ð=šø×8ÈTS×2®Ð¥|6›û#׌£Üoe¡­±c%F¹_Êt+†ÃÐ�â0õ£þ%ö£RÒ ñ¶Þ†Ù¶¬7á»]¯�ot[¿]¼À×±n†¡8(
+§,'ËQ(ᨹIëúB,+o›~6%
ImÕKu§™zÉÒ8�‹‡v�¼¿,Ô1àÛL©qñ²Û70h°á�s—‡
+âŠñ¡ÀKkÂÀßß)“|
Hñþnzc	}A´cuÁÜb¦ŒÐu¸n�kÊ�qýy!,Ÿ2'RgšÍ^WÂØÉ(Ý—ÃPfõ?ÂW¥¤wŒ“9Å@y!Ò",Àé£&ÔŠ«B81ñaTüàµwa³G¯Å†\‡Á(qÍ‚Ñ\/`­ñÇ‘£Z$®5Fxà«Tõ#=ƽ³©¤ƒn!ö"l¿�YêE`î¶Á{R$%(BòàÚ¦(I
9B‘(
•]0IeLŽÊ.*×@i«&­È\‹N)ËÚ§½²ìÕÜžäWÌM½sÆ•(œM±Tµ«9g/hF¾Ž¾='�aÅü°»*
ú‰òwpq×Èu
 endobj
-1706 0 obj <<
+1727 0 obj <<
 /Type /Page
-/Contents 1707 0 R
-/Resources 1705 0 R
+/Contents 1728 0 R
+/Resources 1726 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1714 0 R
-/Annots [ 1710 0 R 1713 0 R ]
+/Parent 1724 0 R
+/Annots [ 1731 0 R ]
 >> endobj
-1710 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [339.2005 435.097 400.4005 446.9972]
-/Subtype /Link
-/A << /S /GoTo /D (zone_statement_grammar) >>
->> endobj
-1713 0 obj <<
+1731 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [455.0966 226.9165 511.2325 238.9762]
+/Rect [483.4431 727.7808 539.579 739.8404]
 /Subtype /Link
 /A << /S /GoTo /D (address_match_lists) >>
 >> endobj
-1708 0 obj <<
-/D [1706 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-470 0 obj <<
-/D [1706 0 R /XYZ 56.6929 674.0471 null]
->> endobj
-1709 0 obj <<
-/D [1706 0 R /XYZ 56.6929 644.6731 null]
->> endobj
-474 0 obj <<
-/D [1706 0 R /XYZ 56.6929 417.7762 null]
->> endobj
-1711 0 obj <<
-/D [1706 0 R /XYZ 56.6929 393.3438 null]
+1729 0 obj <<
+/D [1727 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-478 0 obj <<
-/D [1706 0 R /XYZ 56.6929 274.0842 null]
+486 0 obj <<
+/D [1727 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1712 0 obj <<
-/D [1706 0 R /XYZ 56.6929 249.8112 null]
+1730 0 obj <<
+/D [1727 0 R /XYZ 85.0394 751.4533 null]
 >> endobj
-1705 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R >>
+1726 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F63 1364 0 R /F62 1361 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1718 0 obj <<
-/Length 3041      
+1734 0 obj <<
+/Length 3385      
 /Filter /FlateDecode
 >>
 stream
-xÚÕZÝoã6Ï_á·s€5ËoJèÓ¶›mS\Ó^š{jû ØJ,¬-¥–¼iîpÿûÍpHZ’eoŠm�».ÐP£áp8üÍe1ãðOÌ2øÊõÌåš.Ìl¹½à³Gx÷Í…<‹È´ès}uwñÅ{åf9Ë­´³»‡ž¬Œñ,³»ÕÏó¯¿}ûãÝÕíåB>·ìra,Ÿu}óŽ(9ýùú‡›÷×ßüóöí¥Óó»ënˆ|{õþêöêæë«Ë…ÈŒ€ù2H81áýõ߯hôÍíÛï¿{{ùëÝwWwi/ýý
-®p#¿]üü+Ÿ­`Ûß]p¦òÌÌžá�3‘çr¶½ÐF1£•Š”ÍÅOÿH{oýÔ)ûi™1«¬›�fLq#^³¬Ê¼³ée9†`V[}ZÍã +㌡¨…àp†ÚÎ6wÌWÊ™,7Fâé
-a˜•ÚÍœ1pä–Ž÷
ìYsf¬ž“3£¤áÈñÃåŠùü_ίÆÇ�B•4¨&X¦$®=ûm&×y®ˆ©7ö[=˜À¾¸ÞÊÙ»64ëï)
-^ô$û]YÕƒ¬0°ÁŒãúpYãU.6›æR˜ùóâ·}¹ìñùËbY,/a°.iÇVö‘Ÿ#dØqÕ]6¯I=ìÛrE£®¡¿íS¹¬^è¡X.˶2t°–ÀÒ0Yll?
'ÈR³ÃÑ}TspŒÅ
ÏŸ‡Ô…̾\HͬÐÙt„áŒãaY'
;à)	ƒb"À$®xXtP/‹¦>˜ñ8�³¾ä£åׄýsöÏ­jðä/œËPeóçuµ\ÓpÓ,‹
ݼX­v—"›Ã9GÆeQÓ
-—°·ÿ[Õ—bÞ•»ºØ,ŠeU?F:�ùï÷
VUÛ“	@ß–¿i~<j.½æqóM]¶ohø\uëÀ‡ºD*vÕæ…êæ9Í"Ï‚�W°ö'ä'uÏÍîÃßZz�®�GÔ#»“'�8‚€F¢Ä¶@Í„†imC£û’þ¶	P+"T¡¼ÞÇj)P	ÿl2±¸TÌŇܕ۲îÐtRù:
†Ë¢
Úx<Áßæc¹ÛU+3x<¡‹³‡„
5O®Cp]ô27<Í×XÍ9ˆÌ#Õ	�o'qý´	pèYôÍ«ò¡Øo_ŽÞ‡`„
-}) Ä ÷+%bÅáºi»@-(8„Ta¡E$>–]x[·Ïå.Ì{ðóš-=ydàÀo;!£0Ö‡a(˜Ò)höMb±fár‹“ǹ#ƒ°'xÀ¶2’¢+Ú2@ÁzBˆz`¯| Ì®\îwm5ñ5
-í¬‰kB	9j↧�C—•)µ(™RRG©ßúÔâß…k.$ŽÝUºè®XØjî³	2R™)GÙÄW áb>1f§×f“‘&ŸÛìÇ“–à¸6×æ<ú\§á�¸pØ?­Šî¸çÑÐô™Ÿ_=qM,?
-¼Ò€–õ¼ïö¸ÎønäûîÔy.v+ÊØæh›�W$qMh207LÈþ¶ŽÝتäÆ0ŒnÃãCrcx ßQ7†ñÁ�ñÁ»1z>Õ›¶)>ÍA¿LŽÂ·÷l<®0ºnAÏd8ÿ™Ä+ƒWM`]ž$¨¦SÂùèàßôòBl&¿xY±g0i:Vòÿ†¢�óÐ@ûá¦jÅ\žÅÚá
‰�6E…J观²)€XµC4÷oèP¸©‘.g™�fhœ¸}
-2’q僓ÎÈH@y*w i‹äû|~w™ËyC<e]Üo_ZZ»¾aAòbŽ7–vÊ¡2R
jÃIpãm`à„°`ZhØ¢e¿<iZ•Ú¥L'ü>¼ÐÇ&Åç‹ÍžnáBý.ØÖE=¡:^Lp'Ý;b‡÷�Q8¦	¹’Y«Gb{Û›’
-†�*»
£°Ô܃=_èaÙìñKÕ¥£Õ~¯ñXFõÓPÇ`…ÄÁɪz‰g›GÏ
-Ùã/o”ƒñ&y–Š_"]¼´ÊÒÞp<D{ •E·O]'è¦*DQËSÂüØÍóËþþÔ´e$ÒvÌíT§Õ6/½�šÇiœ(PŒ+P"IJßÅË’¦îW¿üíºbù¡=]¨<wÍ´S¤rŸ(ÿ¢?á8Ë}Mq ¡`Íxk_øñïl"×'tÐﳕê�ŠƒmÓ7ù§J…,gÜð|¥Ðc:](D¦C(ýhíK
Øm)M
[>½Y~^�Ät¬Á°á3ð–›�
-áÇ΄¯¸4~.<Ñâ§ó�¨½7Á„ÎÄoXfÞn›Æ‡
$î 
VQ”×fþþ|M Xú‹—mÃ	Ôó�ΙåÅ_¤ÔuuOÉ
¦lŠûrÓ"•žI¶›ßÇŸW$Ì’Y>ÿê›C\’Ù!„ç}Ø‹
ºÙ¨Û”@?—	LÎÒ�ç_•O¡ï„pnGGq�î§|@x:x€oGÛ&B´/Ë—;*F�oÛÝê±
--iÝXs£2f2é&Tÿ/`ßendstream
+xÚ­Ërã6òî¯ÐžV®!xƒ¨œ&;ñÖf2ñxkI”D�X‘H�HÙÑní¿o
€¤DÉ“JìƒÀF³Ñhôd
+ÿl¢4Ñ–Û‰±’(ÊÔd±½¡“O0÷Ý
8³ˆ4ëc}ótóÕ½0K¬æzò´êÑÊÍ26yZþ<Õ„“[ @§ï~|ÿðÝ¿ßÞ9}zøñýíŒ+:½ø玾{|ûÃoog,Slúîû·žîqJß<¼ÿ!.}¼»¿{¼{ÿîîöקÜÜ=¥½ô÷˨pù|óó¯t²„mÿã†a35y�J˜µ|²½‘J%…ˆ�ÍÍÇ›ŸÁÞ¬uL~ReDq©'3!Ië�K™Ã e‰\$)s6&åˆå¤œo6õËì°[æmqºeÆ¡TËIŸîÙê	kdyÞ[žqFlfÌpý�»bQþB)/8
+ìó¡hZ·UPò¿‡·>ø�ÑáŽòå_i´„2þVM±8àÜ×jŠs]É1L×7`Ö)
Nî?MpðØךˆ?ë¿0¢5gt½Ö‹¶ô[n§ÜpÁ‰Ì@ÅúÄÏ47a½Âã³ÆYNŸÔ XY´y¹�#<õÁ,
•ÄX-^±ÝÖÛ�X§¶;v^òýÒ)ÊéÑF2
+.ë*#	k„“Á�MLÖßÖ¹k‘̆ьaØ™±{Hfh;¢3cwfì¼àgS½×6ùs°W«Ë8j··lw\áŧóŸQpŽ¯¥g¦Ec‚Ap`DÎP™ñÞÁÏtŽ
+
+#mÜ>:i¦/¥wN2C!
dWì�Ò¶XºýS;}ºµ|Z#NQåóMÀKKKÓ,P~ƒÈ�S”ÕqLN–¦@
+ô5å†} ®rm^£d¿~U´.=€œá#²å% �>盃S7®A
ö8YW#¬3a	/õǎظ\'nŽi„.'ZK3$ÛÛÞU£:¼R†-šÈóˆ‹úP�6ï0-‹ ‚�d„K6úBmËçâ�;t0²²Z¸³µÑ2@BÌØÕUSÎËMÙ
½# $�
+t·Á05H$¨åæ:	k„‰AŠ 5É29dâi�i²šÖ»pB0~É=Pƒz¶ÉyåƒI”#ÐæaÐlëÚ;ÜC,#)=H¯Õô-ü¼:@4þæÕòäïý´"<“rèü~á\Våü²ÉçŦqP|FÚf:/«|ìã¸8™Ùé÷�átž‰g�ÌyØ‹¼éÈÛA¿I£Üòë¢Büe�î¼X€CZ¾óí:fôé
+¤|�óPn¹‘?EOò®]>û2’ê¬Ù¯(|–ȱ¸u€ÀA½y."»X8I’Y}åÜÇ[ÆØ4(ÕOqEwÚ½¸ŠÊÔgycÄ
…c_ç
»+–1R´uXïé’†ž—DÌAk¢ê²Ñ»&m¬ñ.©ª D3­_QÕÖU�X>o
+gžÕÕìYŽ�Qp4Òö
+TÏÁn·)}ïõ꣖(È€b ªŽ#kB6oE*Ï/ªƒ‹lÚ²ëÚÐCº¬ÉWdh†(oj³¶Üõ¡=S
+�©Ö™¸ÊHB:çd°e
¬H«¬x¹ºöM¾u=
+¨ßîÒ
+Û¾�=Áâ÷|\¼1¤Y&ˆ¢*‹|Ëv|Ó?Ü@yNɧWº'o¢ôÜ*g9 ö7¾ª�@ž¾búÚ%
+uúL,Wºa¸‘Ýe�‰­z
+úEå ~Vþa=�\é
¤ƒUtý‹„s#Œ3©AððáYFñDBR›Õ¸«ôÁžŸÆ;*|’<ÛíìY�Ý{AºË„t_B'4ax©!CmûM«c
+á”Ù
‡—²¨¸�ŽÕBøðÉ\ÈT]¡ë©¾nt�›�Ñ9Ç«%¯Ñ@%–uüü
+]!€æ·.©�*_Ùåûð=š«,‘ü´aÚÔ‹ß¼ËY°gpà9öp3o8JÖŒ�C_/‚–
+z½‰E‘A!1ˆ­Â‚ë@®ÞÀ(š<6G×Çë<Ð)ªúð)ðõöÃCÀ<ì¼¹§	ÁÏÆMdtúÔÆɾx“ï0<?î·E¼E]¹¯4„z±
 endobj
-1717 0 obj <<
+1733 0 obj <<
 /Type /Page
-/Contents 1718 0 R
-/Resources 1716 0 R
+/Contents 1734 0 R
+/Resources 1732 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1714 0 R
-/Annots [ 1720 0 R 1721 0 R ]
+/Parent 1724 0 R
+/Annots [ 1736 0 R 1737 0 R ]
 >> endobj
-1720 0 obj <<
+1736 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [213.0783 238.2538 261.825 249.0382]
+/Rect [184.7318 733.1915 233.4785 743.9759]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_security) >>
 >> endobj
-1721 0 obj <<
+1737 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [398.1622 116.018 446.9089 128.0776]
+/Rect [369.8158 610.2892 418.5625 622.3488]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_security) >>
 >> endobj
-1719 0 obj <<
-/D [1717 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1716 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F63 1354 0 R /F62 1351 0 R /F21 930 0 R /F48 1228 0 R >>
-/XObject << /Im2 1340 0 R >>
-/ProcSet [ /PDF /Text ]
->> endobj
-1725 0 obj <<
-/Length 2695      
-/Filter /FlateDecode
->>
-stream
-xÚ­ZÍrÛ8¾û)´7¹*B
-$WàcÀá´hP#ÇË–(5j»œá‘�Ð&ËEbó`±zÓ.ëª	[í˜/­3ðËÍçdfö7
-B¨Nògá 0Bdú8t¸NÀ!páŠ[òD²Ž÷¶I»\—õ}{€0kšæú´.‘k@™Þ¾SÐƸ´¯�·®–�–Öõ}ÕÒØG/x¢^<
-l�X²%
-,éSv5ci-$&ÈzÕþ¾¦Ãì‡"dìŠ�Þo¬a|t‚€+¡pŠN *…X2¯Ce„ïób¹‚õ°ê�´/ GÔh•íPÓG/T©6
-J?kC-Šq¸¬ Pì|yùT§ª,Ø3¨>�}�h£
–:p¶ÅW_Zh:*zÒ"‚ÅXoÒ0?‹Œ.¨T§Áa ¥@:Ù�o
-~?ìö�O¼me¶W
É|\ðD,…zëf™Heì�*¿Öy:JœÆÀà¯æá(qÒy˜‡UæDî¿[ùh±�()¥Õ�S2J|FIà‰T®¯ä±b
Úî,
Í×îéô‹IH…»‹ÕçýÊá¬çwZB³äѼ
-·�ëiÖθW0,ø:^ºwÀÑ;»–`÷ìW"­Ã«î�ñÑ*öáÞòqQ‚ÆÛƒŸ9š%}É‚	�"Œñq´‰!Üý˜þáhÐÌTdÞýX‹ûÓ<ìe^Þ@8hˆ�>Ò@ :ݪ¿“ëO÷ñÃS-D"¥z3»Ëß¼y­“·Ã+¼¤‹ÐÒÆ.BKî"-wHŠª%Ðø®(X—"Åã	x1ììI0·ïI0‰1öqÙ.˜�ˆX\EzA�f=Ê1j¢ƒ
�®IH«
ƒ’ŽÊY6ŸrÆã)¤ŽötC&
-+8¹dŠÏŸžPÑÓ›	g6ô1z×wšê�‘v›ÅO¢'û9Ú¯ã�ˆTr^ùR¨|6®£Y¼èöÜ%ã:Ü|-O4"±_êCü¡†ª÷XÁßÆž+|�ºþ¾ÔCïÐ_Ih+ðOnêe¼ãýËA±ûóƒ^y2|åŸd¹09a¥ü•k~ø‹”˜:MTÿ?Úá¹øendstream
-endobj
-1724 0 obj <<
-/Type /Page
-/Contents 1725 0 R
-/Resources 1723 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1714 0 R
->> endobj
-1726 0 obj <<
-/D [1724 0 R /XYZ 56.6929 794.5015 null]
+1735 0 obj <<
+/D [1733 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-482 0 obj <<
-/D [1724 0 R /XYZ 56.6929 566.8844 null]
+490 0 obj <<
+/D [1733 0 R /XYZ 56.6929 355.3526 null]
 >> endobj
-1727 0 obj <<
-/D [1724 0 R /XYZ 56.6929 542.8644 null]
+1738 0 obj <<
+/D [1733 0 R /XYZ 56.6929 331.517 null]
 >> endobj
-1723 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F48 1228 0 R /F41 1208 0 R >>
+1732 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F48 1238 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1730 0 obj <<
-/Length 3232      
+1742 0 obj <<
+/Length 3221      
 /Filter /FlateDecode
 >>
 stream
-xÚ­Zßsã¶~÷_¡·Ê�ˆÅo€½''¹K�iœäêÌ´“ä�’ ›s©ˆ”·Óÿ½»X€"%Jç»tü@z±
-h	¸²¬}Sý©¥†Uý|¤[TÍ3é‚°¦>ýûÛÞ7˜H�/Òêi‰N%4»Ô0`·¦oG3æÀ‚L
-�‚!Œ4kêýnáG<ëÔ£—	€¡ƒ›bL\•ÑÃdÄ–¢ZÒKÜtÐÙ7>ÊVõŽ^šýâ‘Ñ Òƒé3£íô]Rˆâ¨í«8TMîú+×Óà´�tÊdIê¼-vEëÇ#¤K}ߌ£¤†±vˆ~mÁhª*ELFõâl˜I›)ÇÕ!_OGÊ3«:˜úó˜iSˆÿÂ4+ weó
Þ9Ĺ‘Sô->Ê5­7eÛJ“»°‚n¹(‚?—¤vûµq8Ëü1EN§åÜÞÝ|ýõI
Õ,‡rÆ- ™Cíü5UTd¹ƒl­¡³nÄYH*�}ó4™†‚w˜­¼¹û׈S¡4š\ÙƒWy,šeB€»‡å€JÃÜÓ#?$eµ‚á€$c{&™8YHŸ‹xfsy)R ¢±ÜäCEæ–§ Æ ÈEž÷‚Ê]
-hÜAV×RØ^ajã?Õ~3÷q„UˆŽ¤{n)df‹ºBüxØÓÿKR‚qüpþm¹ø@ÍnºßƱª(ˆÑÜÇ�pPkµn
N°‰–g§¾@ÀAa)‡ÅAæóšÞ?F¶qY–ìÂðnbötZ@›¢%É  •*©øQZ 3éLÊ0rö¤fûåv†�á‚c™’Jö’z•¶àO%ÛlpÐQ
-6©¾I
-ï^CÖ‰È3çl>ÒKk´¦ßé
m·2;Á8k85OÉLçQç¬S—¬Sg¬S뎙Ïy&Â�Qrà‚_*<š;þI¸1Ú« #Á"2Á»SJÄž×�ÀÖ
u¬ÇÉŒ3}L={X‘pz3npXÁá�~ñ
_Í´\‘ˆ«ðRo=ÐÆ
-ë‡t”LåÃ=®Ÿ«!,�!Úó;I¯€ÿ¡GäCøÊ¡ÜÒ›ÑZê7ôþß7Ããéõcžž|û°qW·
-·Ål̃�“¢:hŧó=Æð—g‰V€k4Å´îE½Ùø@MA£Œ=€è¶E ‚ðO`ŠÐ¸öp#7Ò)z�{…
-H¨xÏK’æTß¡Fر}A¢…'NfžÄiÖMMo�œŽä,%O0† 
ðÜËhJdäáb+#•æ¸ï/Ô8�CµuM‚f®qPFü”#¸
-c*0»\û3EBIþqôᢇCî®áRU€0ˆ¢³VM+ÿU’Ù
B 4×ôO±oë
T�EŒP�ǾÅv».VŸ¹EöÏôç�á¹®‹e:~Γ$ßÑæmwCO_-€Ç‰‰‡ZÏ£ÓÛX½´È…ŸD"Œ±æãœüøóúAýïàæEIhËhâr(öèíä@Â=%ÇI”OX{t!6‚gXzxˆnˆöãíÓÿ¢©+À°Ø±¬»ÂM
-z§ét‹úF;ÓíB¼oˆ£ÄËÁ0#†Ø¢¬{xaûˆÞQŽg¢<`ך‡}/袅ÏÝuÛH8“q¨‹Z�6±Cʱ†F™�/‘.=–s„V”�£ú^ѳ©7Q’
è2…þ÷b³�Äøx�vÄ×~º»ý'f¸ˆÙÐ?‘À}¦€Hçúy”ò:X{w\¿�±‚;X{E&Ì×>Öû4=Èiúí®|˜!€Š)Šbâ,Ø«
-¼®éª.¥‹ŠÞ�„Âé«.	Ñ8J͇±”BÂX
- ~ží	*t<´«”QúøX¯B�£;d«-~ý2Ý
-çþŒ!eÀ�Žs¹_19·x�ÁM÷-‹rÈ9´̪×ã÷oÌuxß}5æô%MiöÛxý
-‚da° Á
O:šb[w#
ÒìGæN(�8«¥:΀À‘€=wF0úb„²ðÑ.4Î!Ó} ×Ð<÷‹‚àšh—÷
!6K„Ôšð9E	‚ᵌSD-“Å¡†6ª, ™G�Qv�3à©(Ì*œ	î,ÛÇïØd¼8Gü(_¶ýÏö|pÂÁž1ª‡uü
-?\ÉO>ž§ß‚�šþ?oã.ßendstream
+xÚµZKsãƾëW0'S©%Œyá±{Rl­#W,¯7rUR¶ 9QK4
’VRùïéžî

p¤•�Jé€QÏ«§§_÷PLbø“ÌD±Êõ$Íudba&‹íU<y„¾o®�™ùA³þ¨¿<\}ù^¥“<Ê™LV½µ²(Î21yXþ4ýê¯7n?^Ϥ‰§It=3I<ýËÝý×DÉéóÕ÷÷ïï¾ùñãÍuª§wßßùãíûÛ�·÷_Ý^ÏDfÌ—¼Â3Þßýí–Zß|¼ùî»›�׿<|{uûÐ�¥^+<ȯW?ýO–pìo¯âHå™™œàŸ8y.'Û+mTd´Rž²¹úûÕÝ‚½^75$?£²Èd2
P�
+Ôý7´´îó1ËÓHi•
UmÀÏ,‰ãé¿éSTOï¨õŸw¡k¼œHÆ…-!•,ö'Çâírž½}û¥’ïÂ;ŒD
û)]B~áTn6pÖØLmUÌ7¨�±fÅbå¬I�ŠÕi%Ј3¤E§xH
+„Çú“s¬€sðÞ.—Ot¤ÒüÅC‰`[>ZzÚ”Ìð^B짂@š½Šý„G±„]ü%âÎ
� PœŠï)hZæýŸ“@k÷«báœô@tW u 2“C³^ÚU
Á/
+œM
+uV ‘ÉàugDÊûÕó
+Àò²¶MõEKŸªú4[T͉Ʊ¦9ýûëÁ6hFè¨S𚼋” «8¥&d�TŽ9MH
+‚†ª5¨ŽâáųJ¦ÒHg¢ç‚.WÊ£TÃ#þb-Šµñœa-À
+÷eóÉ…:Pb5u
¾ÎÇ%Ý·eÛ’�&qaçHà°»Ô3ôº@À]BÎ/N së<êÝýÍ×__$†&Î!GéDƒ…‚3Ó¯I
e”gYNgÝŠ³þ’”õõÙ3BFÂÝyg—ñÜÿ3 TŒI®Ó³TGRšl( ] ä
+ÈvÏJá²:ê܃U×[°ƒ,”²Xø§:lç–WX9íðÃx&¾Ù¢®Ð<Î‚uípÿ]	
+0Ç	¸!â•*ðè€
DñL{/Žu¹üœ sÀxZ{ɇ¥‰“<.Ûɬ*—Ê¡Ç‹+RéAý
+#Jž
8·-„P„Î�-î‰Ê45ùªp
+DÀÎ-
+°T”É<õL¹—¢ü¢^íStÉú
§Î¿endstream
 endobj
-1729 0 obj <<
+1741 0 obj <<
 /Type /Page
-/Contents 1730 0 R
-/Resources 1728 0 R
+/Contents 1742 0 R
+/Resources 1740 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1714 0 R
+/Parent 1724 0 R
 >> endobj
-1731 0 obj <<
-/D [1729 0 R /XYZ 85.0394 794.5015 null]
+1743 0 obj <<
+/D [1741 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-486 0 obj <<
-/D [1729 0 R /XYZ 85.0394 717.6707 null]
+494 0 obj <<
+/D [1741 0 R /XYZ 85.0394 503.9183 null]
 >> endobj
-1732 0 obj <<
-/D [1729 0 R /XYZ 85.0394 688.5432 null]
+1744 0 obj <<
+/D [1741 0 R /XYZ 85.0394 475.3477 null]
 >> endobj
-1728 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R >>
+1740 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1735 0 obj <<
-/Length 2542      
+1747 0 obj <<
+/Length 2403      
 /Filter /FlateDecode
 >>
 stream
-xÚÝZÝoÛ8Ï_¡·“�šË‘¢pOÝ6íeq›ôZ/w»û Øt"T–\KN6û×ß‡’%Gv»h÷�á�Î‡¿銈Ã?iÃL&³(ͦ¹ÐÑrsÁ£;øööBžyÇ4r}¿¸øî�J£ŒeFšh±ȲŒ[+¢ÅêçØ0Éf �ǯn®ß\½ýéýËYšÄ‹«›ëÙ\j¿¹úë%Qoß¿üñÇ—ïgsaµˆ_ýåå»Åå{úd‚Œï¯®_ÓHFÍ	¡ï/ß\¾¿¼~u9ûuñÃÅå¢_Ëp½‚+\ȧ‹ŸåÑ
-–ýÃg*³:z„g"Ëd´¹H´b:Qª)/>\ü­8øê§Nù¯ç™'–I
2¾D­�,Ët2­–Gs«˜ITvZÍã +�ÝŒ±¨Ãö#™Q6é·WÊH–i-qá«J…‰R¥Ç!ØÞkt°g̘6‰@>Á™V÷7³¹ñþÊøÙv€HžÊ42Ö²LXT}ŠãI–)âÐ~¥ø�ï®62z]Ãz¢Á’:¹ó�`¿"#€œS¥<¦,óö.îÝlžÈ$ÎW«�k쨸ٺeñçÒ­èkQQÛ»w�QÉB%Ì DòÁ§½Û
¬yü4oêýn&y¼ì¦

2)“*ÑaV½m‹:¨)‚û¦3`=S<®wÔ¹­Û{¢~zýŽ8ój…¢¹ä‚Y�$Ñœö’ârñ
-ø¤M:Ût\¸fÍ6ñ-¹o±£ý"=óÖ+äqÏ·Û§ùouU>öšF¼-8p¬¢YuÂ’\>"cŽ‹|
-
-`í~E¼[	A0‡¯©�w3ð/,ºÞP_mƒÌ‡¢twè6îWÀŽ±˜˜ŒI›Ùh_YÃ:3Z‡ìðÕq/
Klª¾‰¬B?•ú¬”f˜“9Dë’?ŸÉ!F‚g¤Tß2‰èÔ2e­úöYd(ùtÑøM'_ê2øø*ËcX0Dblzˆ¢�¬jø«º%¢ÙoqçG\ÛÕtÒŒ‚Ó�BjYºO^ØéSv0è&¢¨©—ññ�kC”žŠ�á&nþû#D0c„ú#+õ3’“’„¶úL€h
—I¾e|$iÂþÑq�{:6+XjC±á%ã¼lê‰Ó3è 4¬­ÝåU³ÆìîüÉyþM5S‰1an8�Oç¢¹aV¬?w.H¸êÎåÓq1Øگ˷‹1þV=
-Œõ:L¨óiiïóv*it¢7‚ÉH¢l©r¢yjZ·Á€¼èF×uYÖ�>•ûY¾âÒ°¸z
-Rjjïßk~F
�& �(
{–R\>¿Ñ¦ù�ë4z.S´sŠšcÝ‚k–%îg•÷\Ú‡Ø�ãžií°
-¯ü!)-J¦ñ]Yßæ%
•EÓå7¾^½Ìp(΄�á`¤ùi`±q•oQ�Û=ŠdØxšK3Có–gh\®oWoþAô4äw®	8¤™%cè<Þ»Ê=øSHàë`Þ=�.ëíQIÑá•÷¸çT^À'D«[½ÀCÞ† òe@A—ìQ
¤Ö
-ô›[G7¤ïOAÓõ‡q,PÁC¦/kß®
-÷8
׫êù´¦Öý—ôeцSe˜_t‡U7eGí¦îÂ{˜WSÀ…:ÊÕ
w“CpM
*…š,ëÊ'Ì3ሻÌÃÞrÿ¼Á:¦L
-ia�"¡â
-ÅñucÒ |�”_HP�Š�M$Øo"´wŃß(
-m>¡ÒXf
^AŒÏÊÏuIÅŒ��Ÿ¬^6pn ÷…ŒýÎpL%7Ô©!1튕#Íý#ÓH·PœIiÕè¹(˜~ñ6Eƒô±AÁóÊâûž•c„ý�€›Mû
¶Xôi)”)ÀzÚýpæ&9¶€fù=€Ö—nH´õ„J+Ñõ²/ã'´€ý@u³‘w¤bYà×3.¼~©ÞP`Lm 31úË@‡…ŒÖcÐ�t:Æ‚ÃÂ&¤–q¥²ñ&tqBeR]ÙáÃö�­|m¹ëjм=Ô�Ç%è aS11*[ÝfÛ†"4˜Ô/\ó*”¤]ååEHbËœjŽnð‹“uªä†)-²óuê�ët�ÚsQ>úmޕɸ½ó¶Ø¸yQ=+Z5\Úìy;Ï„#¸
ª5>Œì¸ªnáná|’®njx_±
-Ê'|²¬èU>—uuGoBI8f‰¢×$,<ª'š¹)ª}ëÂp(ˆ,$~ŠÛmŠ9�*U`«8:Ù+ˆ½Õ¡BH€Ö©ìÐ ‰¼‡KtC»={Qlöê<äåÞ�%KÔæO©	WGÏ"I…6ÜýÏ"iÈuI=×$’ŠU9‰¤$en7ç-é¹&L£I²»Ùr@“èÑ$ÆhˆŽ�„$�…µ[o{}w¨‹pÔWú¢G–è‘%4:N¤
-ÊÄySz®	[FØ2°Y‘:4æfßpI¸æ…SgèSö±l	ÙÊsÓ¥ÀSE˜B˜òT¿½Ð	çP·�ª! 2(çxöš­R(oS#Î#jÀtPÓéT5‰'…Eùy;z¦ç†Œ3•eJñ±%0
¾ºLÅù(SqqÈT@ûLíD¦‚‰>SñU4×g*N¨š!z—�©8
ËÏ
-þÐ2,…ü5ÎU ä<[õÏu,Q“oo¼ÿ©á«ÿãÃàA9ÅÇä46à’ÅB‚Qèè”?
-¸Ê(#'LÿNAcùendstream
+xÚÍ]sã¶ñÝ¿Bo¥gN¾I6OÎ�}u¦ñ]|ÊC›æ�– ‹s©I»¾Nÿ{v± MÊ”/©ýÐñŒ±»‹Å~BbÆáOÌŒe6•é,N53\˜Ùr{Âg·°öþDœy‡4bý°8ùîBų”¥VÚÙb= •0ž$b¶XýY&Ù)PàÑÛW—ï¹>;�u´¸üpu:—†G—?'èýõÙO?�]ŸÎEbDôöogç×´d�.¯ÞÑLJâ×çç×çWoÏO[üxr¾èÏ2<¯à
+òåä×ßølÇþñ„3•&fvœ‰4•³í‰6Š­T7Sœ|:ù¹'8Xõ['õ'8“ÊÊ	J9¥@“2«¤ò
+\l�iåÖY[45}UkX†3%1 ”h� ‰ì®ÊWó;=oW»ù®Ú
Ú2dž
+3¤~«Uzœíã@+€ÝŽ1©ÇªU(¿¤Ž‡éƒDEÉTŒ×-9T]	U]Wƒg,T'hdœ%»òçT"ZÀ=)3�&�e<Ó±…zOû:söe&×iªi
+¹´úù‚\òê˜ðƆ�”²+ΣVehA§BˆÈßô™ÓÏF2fk�½)k£MV°uËMVæõ6|cy…ã®È|H«
+eãh�-óS
!³ÉGS_½(©—ÂR 
+’÷(pÙ9ùÌ“FÂVªÁÙŸãÜ#=e=êW!Ʋ~ç°
+/}’”	JÆÑmQÝ@S觊¼nòW«—2$EÿbU×´?(ITú7-„jè/É~d¸rÚK;Æ,�P»2 \}X\^üƒà-pÈn]
+pˆ42=¨¿ï7®tw>ë[ÿ6© ~¯ƒxš]V»‚ÈEg©¼·xê?q	íÔ­Þ`’O‚ûø2 §&¿ÈƒTÏ
+¨7·"Œnÿˆß_§«OS^@¢/+?®À"!;˜Ð3+c¢�+v
ôrÀèʺíÕŠó¤m€àä¾@ØŸÝ„&
”%¬ÝçEAЗ6_~FO¡í%ª(߆=^0³{%ÿAÇgS]Åï„þ郛ß4ô©û‡Gž[
ð¯¬0ŽEœ¸Ï‘B.[n&%+�µê²ÕØ·ü€L‘˜þÇ…Gƒ&ôzªÑ,ûðj«CŠRwö9Ú”s5’Y“ÆãëížÁ«€äž@¸°²ƒ
á÷—€º¦Ñ(yJEg
½
+Ú¥¯Å§Ë÷}v,;ÂäjÝc
ÃDаIHôm¤°š2Úî	Þ»z
+ßo•î~€i’}€<ÖmA0ú}Ø
wD1?0õg:`µ]æ»"ºËÝý´¹^–O“Oxvÿ¦å�O†1ðM—¦º-{·Uç–þýbãÔ]Pï±ÄªÎp·8×dú‡ð­tÚUNgBr·ÌÃÝúWíÕÑ4eþ„8‘Px_@¿ø—ÊÁƒH�$GR®L'@$…‹ùÓ,~Ò|*úïÉ}U~endstream
 endobj
-1734 0 obj <<
+1746 0 obj <<
 /Type /Page
-/Contents 1735 0 R
-/Resources 1733 0 R
+/Contents 1747 0 R
+/Resources 1745 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1714 0 R
+/Parent 1724 0 R
 >> endobj
-1736 0 obj <<
-/D [1734 0 R /XYZ 56.6929 794.5015 null]
+1748 0 obj <<
+/D [1746 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-490 0 obj <<
-/D [1734 0 R /XYZ 56.6929 437.1956 null]
+498 0 obj <<
+/D [1746 0 R /XYZ 56.6929 223.2735 null]
 >> endobj
-1361 0 obj <<
-/D [1734 0 R /XYZ 56.6929 414.1392 null]
+1371 0 obj <<
+/D [1746 0 R /XYZ 56.6929 199.7072 null]
 >> endobj
-1733 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F62 1351 0 R /F63 1354 0 R /F21 930 0 R >>
-/XObject << /Im2 1340 0 R >>
+1745 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R /F62 1361 0 R /F63 1364 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1739 0 obj <<
-/Length 3616      
+1751 0 obj <<
+/Length 3599      
 /Filter /FlateDecode
 >>
 stream
-xÚ­]sÛ6òÝ¿Bo'ÍD(>	â1mœž;×$—¸ss×ö�’h›‰tEÊ®ï×ß.vI‘e;ÓϘ`
,û
©™„?5K��&Ø™V8©Ül½»�³[ûñB1βEZö±¾¿¾øî½ñ³ B¢“ÙõMo­TÈ4U³ëͯóþþöÓõåçÅR;9OÄbé9ÿþêÃ;ê	ôùáã‡÷W?þòùíÂÛùõÕÇÔýùòýåçË?\.–*u
-æk^áÌ„÷Wÿ¸$èÇÏoþùíçÅï×?]\^wgéŸWIƒùãâ×ßålÇþéB
-R7{„†*=Û]Xg„³Æ´=Û‹/ÿìì�Æ©Sü³.NÛd¶tVH¥Ã4—¥�¸¶ôV
-›¦IÇe­¦¸Üb!—ë|_dÛå‡|ÿ´ÜgM>>·J¤Ð!q³þâ'$tX4è
*qB{Ÿ‰ø²Írà¾ÑHÏC¾¯±¡æ�ÅvKÝ÷@fµ)ÖÙvûDc‘bÜeu“ï©»7_Ï›Š¾¿I©Ë
!T‡†:‹êøoU÷^\v+\¸
Ìw•Â1•ÎéHôÑœ†ùú.+oó
˜ÕÉü2[ßQ}h¡–X
-ÜP9Þú:*
-<†T|x‰úg±;ì¨A’E-¹ÇÓKLÝ÷-^�¯«r¹`#¢X‚©K†—»Éo²Ã¶![)�¯–GABY°¾ˆ{…G0~žm6žŒZ¤5é¶lâETÛmQÞò`<
-¦­mÑé<EÝ2æŒb'x0Ðòý£M+´µv Õ´a�7´Iôuz;Ý…�¨»:ªÉú°§‹�—aOBs–¬¯^‰7×3 �¢Ž`»­Q9p¿«œ¾àÂêä%*eÄnh +Ÿ¸-ò’Æšb—cèãsÇ}6íDV
¡³?ˆÛÞñ~í©qN=áQ‘Ñfœ˜ö(æ
-3¥"•¡ÕŠ(>¯7©àF�n…†"
U!×ÓRÀ\†|î*Çb§„KR36±.å˜ÄÇ’zÚV¡´ç}êF„Š¾›†!nfôÎ5{¾
Þˆ¿p•ò¢£s…w’öî„Y#Sá$«?{_’KÕÅß›x,´Ÿ@Ô»_¨‡ƒê�Áö²¬XçýÞ5ÙÈ
MiYOc›©3i— ß¾R2‚°Êµ’qŸ­¿2íYM;â|Ž—
ŠgG
Ó)íZùí5ufü½¯êºXm¢çŠÇéÃ<“r¨1|­Ô§�1›6Ø/x÷]uÌ-<«Ø@¼.@‹£k0óUL‘8žT•1ë¨>ÜßWû&ß°+€´7
nÄ”za%™
Û¬
oŒ‰iÚ#
r˜AÊYaw£-g�Ø/A¶Qö„ˆÓyrKÅŸŒŒŽ�ã˜A8ê¬ÊÇŒoÓTH§UÝ„
-“‡'ˆ‰vçõG:‘$‰AzXÏèO‹5d<VNOj
‚H™>¿}‡5±ÿP�R¡ 75Ȫ^&Ž�Vƒ¬–ñÒ°d©B=BtR!ˆ*„ÀŠ1û*„¨gTˆ4ˆõÉÈõS‚ï°5éTOŠK@¢V7u+ôÍÿ\CÄÃ÷3¾®Îbý‰já=ƒÏå6Œ£yùëvÞ ÈÌõÀS
6Î@Š­ô·¨ð)Ä 1Qú)ìc�—Âk(…­+OSúú4$ÏSÑaM�1|©PÂ{†tpZöÊBÐ8–t¹,¤äÑœcƒß”ìËblÞQTIJˆ]+Æ<‘½Áü=MȃÁ
-
àÃU!iÙ]ËÐÆ°‰ öè`¡ã{Fà#‡¾P…£P…3B¥­…Pª«Ýê)›-‚÷IÏ+ù*¯
-'^a(ãÀÉ‚“Ký r£FïÀÊ,Áwû£ÏP\È7JOøEE|ì"zuôÚ³ÏÀg�†ðÈ;`ù)¥GÞ¡·¥bï€HèÔô/è#)½K<åáèÍäµLëz±1’žjŠ>R3?±¿âoFÃãð3N¥ð3‚O„Æá'v�	?-ä4&1c
˜ ¼Nb»ÉýÝž˜‹´ÝÐnÓ[€a€üߺ¡,üß"]�]Á¨çmdë¼�ì°N’LÉק�¹N‹ íDtX/P¡œAº×‘1–&àšOÛÚKWЉïDÇÇs�ŒÂg*®7´hü>ÌF¿ls
›ž±À¤|z°]ÿð‰
-ž	î?kFB ¯õf
-ñæí°s`öa �/ÃNãûx´§€3 	‘v‡vÍìþ>ÏöÔ[”¼Ï¯5\ÛàÚ›¬”¨D8•„î¡u[=.;ÍŸ(Æya¥—ƒq”)vÁFÈ¥¦^d�
}f–ÜXåü ­ÇÊŸ	þq‡™w¿íˆuè
-…N+G”�:±c÷ÙÊ6‹æ®(Ÿ+RY/<>îÓ¢ñħ;kˆ
-µo©­öSgˆ­×ù3¹Žô¡
dWà°¾S¼.�Óƒ¢w{Øgí{ˆŒÕçm~.(	;Øòšf^õƒ3“ÆßÏ¥Ó?8#ã‘x�œ_‹æIX‹ÁvÆp©eKÝ2H‘Z9È¡:iEþA"¯­��{%D}èñÐ%f "„ßF·Œþ¸X&j~
ÿõüò„1°¦
¿
+xÚÝ[ÝsÛ¸÷_¡·Ê3‹~
+›&™�Ùlµ»³{ûîJ2ÍÂ-bªoî®þøV3›Ø\å³»M4—I„1rv·þyþæO¯?ÜÝ|¼^¨LÌóäz‘åbþÍí»o©ÇÒÏ›÷ïÞÞ~÷ãÇ××E:¿»}ÿŽº?Þ¼½ùxóîÍÍõBšLÂûŠg8óÂÛÛ?ßPë»�¯øáõÇë_﾿º¹{‰÷+…Æ�üýêç_Ål
ÛþþJ$Úšlö"‘ÖªÙî*Ít’¥ZûžíÕ§«¿„	£Q÷ê”ü2m’̨bB€JE”Úi>+2›äZi'ÀÛ
lHèyÙà^à
½¡$N§`$-·]»hÚ¾Þ<3m<{&UÉ´Ûºëi⺣ßûúsÕpÿ–Kæ&1*3<Í?Ú¦šXKé$—°
"êú²¯vUÓ¿‚i¥š×nåtþTo¯å|Kíçj¿¯×­Ü?TkK-¥ŒŸ·}ìë¶aö/oÞÈP6f(AÒÙB�8¡ÙBÊÄf™rT?=8yØi9è"‘Y‹Á‘ž€ËÓ1ô–;øí*îèÛ‰%�BÑûÓnÚ‰U€hy
�¼5ˆ…éf½ýÀûY¯÷×ÒÌ«®«xewä6¢½ß¶Ër;y6‘iž½t*‘E–
A³ÃÑoƒÀø
+0ZÛá!,+ÒçŽd­wïïnßþ•Ú;ØAyïö
+ÚÎFÁï„�‚��[ô®³QBm”ðð–³QÂÁˉ„
–'X®!À`’ÿ;…9•0òQTLu
`žÊEæÕ¾.·‹¿ªýóbÂ:
VIˆ…ø÷"�j‚‡
°òÒ2¡L|Ú–ŸQjZ!?ŸÉ8é`R ûØl×õªÜnŸiÌqLƒ»²ë�Á‚îè}…i…ûŘÕYB @Ýq�õ†:Ø4ÒÚuÉ6‡ÝçqØ‚dFëq`õ@<;_�‘¼w(KU>¿)WÔß|Ë3Íå Ð*野Ÿ»v _ÈŸ
eÙP…ê8Ý6¬H»¼^éü<[SõOíþ7zX–Íú©^÷”ñ‰¡VÜ][5GÑ€£ßÖ;—ŸB@A_àÚŽüŒD»Xcz«¤¯n
+Ž9ì&È5gtðDZcæ°dOf{»¥ø
+­Oï_s—;µ
Ûøê<n
¦<,ŒÔ]w¨ÖÌA?u\6KŒ‘Å×�W®„Ž’uš?ÚKçóo
É(ª
i1ïZ>µ¸:¬^LÉ�ûäð$’–}IJí¼ë`Ã…¯:…¯±šs:ß�õ	©`–tzÙ'ÄTç}B 	OnìÒ¦þâú�j‚��C
+Ö#$@ÏQw¡7è.8ÝUNMV‡=¼;p7
{z‡C	™TäF|ÅË
+‰¿.ð�_pa]x¡(©{ à	\ÜÄ1Ì>°Š\d,M·ô³ni=ãÊRŽœý�[ö�×ó»ÆqØõÀì’ÑpDF›pbÚÌ1?½oZ¶GW1Q~C„ÚLÅÑJ
ÍøhÙ{Ü6 m%¹-®Ê¼•¯/co•²ú»cT©…„¸°gLÇq»ç
BÙù@Ô…&«þ¡#
r�nB…I2É×YÄ"-ÌH gLŠÎ±`ÿ‹�7(žÈ‰&N`6í~Wž¦/YŠï™‹¢S†&Å&üð€‡¿¹(OÚ,ÎVðq…~K§S‡{é©¥ÆÂFØï&�Ò®ºWS^L‰±ÁØ4ÕÖ‚÷'ÊÇÀ¯ѪʔB$FX¯˜/ñ|“Ú
+
“§\ð	ðBüG¹&ÿ9¾Í�x&&:�0I!e6´ngÏK牒!Ú È^»m¡å¦¾}÷‰z8L ^Öa/Û?H,±±ªâÞYÇ5½âEOcë©=©,O€ÿô…È°I*ÃMÅc¹ú�y/;ZÑeâ)å
+Ô.…J§¼+YŒx勉äßǶëêå–I!nnyœ~XFÉ$F‚/E=„¸Rû0¿æÕwí1«( LÅw™QóU�Òó¥K‘9~©m\¾	­îðøØîûjÍN
+˜ =Ñ x®IÙ*^\©”óEìw‡ |üƒ=ÖÑc&ù�‰©j,¢±4±IF�móTòi`‚
+Éá´ªkkÁV¤61Ÿ¿™PŠ)ñk0¿&@+è%¦Jýr\.t$U7€òÃ_†QH„~¨WBw톻~ºÎ2Àк}âѦ
++¿Ö¦¦á•]Évþ²�ï’×_Éù«¹’~yö£=…WËÎç†Ëç
+Ì�Þ‰g›€HdžOß=OÅ
+Ìx4y9舩ÎG�*m7u�Ç”H-/®¨&–D©J2pyƒåúP­C�!–VT[Áß:\ý¨põ£†W?*å[^l¹�K¦Ü."Á %
$¥œc Õ±z U’ëbë (Zø"‹kz�Iå”F§éRLßÏ»¹½2,Ò"…8œ”¹*â&¢¡ó‘†øc<ýÐ ÃïT"Ý@Ž»ÇÊ¥OÐ<<Fß`ˆç3éÄ}Õ¬¸Ó¾ÈÖš.ýF»”Î38Qðý=D}x-VŒ¬"Y6—Û³^ÕÇíV£Ë÷m[®‡*
­ü­{÷1Ñî¼þ@Ìbuú…»‡˜ê‚þxª¡à§îR
A¤0——TëÈ$²²!NƒRåàøà5(UÂöµáfŸH…°©’“
+á€S!l,™2V!$=£BüýL"‹|äú)ÁpgèM:U’Ü�¢u}ç
ÁŸ^ü¾r7!îü7ãóçº,Vž¨
+|.´a}ñjcxqªÁ:Ó�\‡ª^¤ÂgP(sð{�y]FaLu…�jˆBïÇšÓ’„¾…±ùe.ÕÃ;
+™…°C>¸öß÷Àñ˜Ë!)ŽæøvAnÉÜ#}´#‹ØµdÊì
Þ߳ќ-20Àj™DµFK!
+\lÅÆîË$ÅŸ éAø‰ý-ÿ–4<?Ý«~º&çÄá'v�	?SÈitøØï¨N§ƒ×ÉÓP#y|Ø“p‘·
­6½¤º�ÿ§Ùÿ±H×ØDi©/›Èˆè¼…ôD'æã«Ó;ÜL%V¥—9D—Y�Y‘X‘½ˆ‡1Ž@^…ñU—PÊqwCÇ}~´Œ¿Ýd2¾fs‰¿lm�š®®À˜|øœRëîÍj€7ÕŠ¾ ¥
+k¨ø¡6åKN›ª§“!åæÑaA†ëNÁòg–󪨶5°¯ZC Ìe*4š¡LïÆuxæ
Â2‘€^M•æù^)çJ_ Ã3Ï]Ìüöõ`&þjX¢+üW¦�>Ÿ¸æƒÎ¨ê�ׄ—}õÁÏ·~cU¯hüð¸¥Á|]+Cß~	#;õ!»Îüú|¿"D*ÿöGîÇÿ
 endobj
-1738 0 obj <<
+1750 0 obj <<
 /Type /Page
-/Contents 1739 0 R
-/Resources 1737 0 R
+/Contents 1751 0 R
+/Resources 1749 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1714 0 R
+/Parent 1724 0 R
 >> endobj
-1740 0 obj <<
-/D [1738 0 R /XYZ 85.0394 794.5015 null]
+1752 0 obj <<
+/D [1750 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1737 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F62 1351 0 R >>
-/XObject << /Im2 1340 0 R >>
+1749 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1743 0 obj <<
-/Length 2918      
+1755 0 obj <<
+/Length 2735      
 /Filter /FlateDecode
 >>
 stream
-xÚÅZÝsÛ6÷_¡·£g"ß/OiêôÜi�œë<Ü´} EÊæD&U‘²Î½¹ÿýv±
-ÀLjTà[µ„ݶìØáÅ9ÁL–™™Í,
-ŒçCÎþPvdt¢´šYƒ8”t¨KÄ3çÉÓ¹äI³¥�¢ÁV$uÓÑÀ®jï©G¸‡Ž·ÄAL'
F0€:W<ñ&\ªˆ¢¡ö6|D‹Wصc	Úûf»*B¿ìHóV
ŽÃÇ8ŽX'<£°=0ô˜ÆNÄõX'
-?v›/ðŸèÕè[¼
ìüιܴ}lÊå¦ÄÃ�?·t(;(óÈ`µÍ˜t™›
Mâë¬L�ùØbÖ|j¾ÎÌeÆœK!°KÈû|\2`Î(ñ|\ê©ž‰KóG{š Ž*
Nd¸ËqhŠTÂŒW)îÆÒ¼ñHàÃЄŸûЄ_ÃÐ$SáC“§ºä>4a'†&ìO‡&î˜
-&÷�jiº	àÜz4ãÎ<Vå®
,ýšÀ°]—‹
-Ý‘Ìv÷U`V”Ë|»êÂ*ðaÇÁ�rè��P7—. /6—ÞÀ
7¦Jºûª£v°¥áÓ[BrÍR™ÙÀè	Ž>±YÊ´Ò&ÐüÎ
_zÕ˜a¦ï¨Y4뼫n«UÕ=
©8�BÎqëô¨žAa¤"…uÕòéîà0ü¥Ý#Ñ»	×”�å>¿ý�6ªÆŠ Í¢D>T5bNq�ìî«…Ï6L²jùŠFG‰8LåEA°k[L „£(�¤Íº«š:_aøÆï�?| 5ëfÓâ]µ
-ŒoË ¢Ùa^�\-Å\l[Ü•M“«÷7—ïþE£ G~W¶`%Öªäƃ'rÊ-Æi?µ^—ù†úUM<)¿ÂmVùcì–›G´P(ÿÖN XA²ÏBrðö›)+¬îTô“a|þ¶6½ÕQZ¬ò-Ú“RÚû
l½˜Jaªr,ˆ¡­ˆ†úovs‚„,&ciª¢EÑ^¾vQy°]Û�£z(ë.|–]˜@5M˜²†:³‘égÀÐj×WñŒ¹GtPA\P²
2,ò�Ð�XæøA=u²nlSErºÆ·�JÒç:D†¿BŒžv0ƒþ•–Üæ­÷ ˜>Q[Õ‹Õ¶Ø'ŽS!=ÿh´ý|]ðŒGê�Þ‘ÿ®'0­yДL”0ÒF„ØÁfR3žöN>q•‚9k"¤½2&ùX™Æë¾oñ)¸ÿ:8üû2úäcÒÝv“£o AY•'KX-9ËH¿I	›‚›N¥ý‚ä:®8UÂ*ŒóʈJX´m‘¦ú[–°
-ÑñðÛ—°CÎÏ”°*5ŒcƇ"ÿÚ¬òP³y›%’A•@]
-
-Ð)ͪòõŒMè©Î…N»]¯Ñ5@'ŒÄ
?‚sÎö%-î
-ɳuYü‰Âœ½‹yIþØTÅK<
ÌJÏÏå饴_$å\ªìD‹ñËéyŸçî ÝÄW,’üõ*ëSh°HÇžIš%�À½ê�kXiöa®á}›”.@fáæ`ˆäðÝî>ï¨GI/Òù4F(½ÅžÏ? õ¾IöSy`4zp
-Úâà*NA¡ì5¬¤ðV‡CdL8²÷»8N~Ç—þ.š‡©´‚/Âè—êü¡,¦
-1ÈÍ��¿§„ZT†gqØÁ—Y2¼à
…£eØß#Ž{µ´‡Ìň¨{$óE+Ì«þ{EÎD|uzø�J㸢iáÏûCª> ó<mðš¡45B}�c‡"R»¨šiÿ
Ú¥*ýBÿ;`»ðOí\�ä2:;NÑ5Ü#Þú±¤g¦'¯’YÎc}ÒÃÆﳸoš–ìvó.F+oï0
+xÚÕZÝoÛ8Ï_á·s€šËo‘�Ù6íe±›öR÷á°ÝÅ–¡¶åZrr¹¿þf8¤-Ù²“¢
îª9‡?ÎW,þ‰�±Ìzé™×Ìpa“ÅÜÁ܇3yF‰iÔæúu|öË{•
<óVÚÁxÖ’åwNÆÓ?‡–IvøðíÇë÷W¾Ü\œgz8¾úx}>’†ß_ý~IÔ‡›‹?þ¸¸9	gÄðíß/>�/ohÊF¿^]¿£O�#Bo.ß_Þ\^¿½<ÿküÛÙåx»—ö~W¸‘ïgþÅSØöogœ)ïÌà^8ÞËÁâLÅŒV*�ÌÏ>Ÿýc+°5>íµŸàL*+{(eË€N0ã½dÆ3«¤
+¬‹æ
lJºaÙàS§Å,ßÌ›šÞšŠž9=ꧺ)DOªe³>nXÍçÅ”Æòù¦ òñ¾œÜG²œÏ‰ÚÔ›|>¢—ÛÈÙÜG"ŸNƒÀ¢Ž«W3|*à8ÂèrÙëY>‰ß|•ROæU=³
+š(–SØb|_ÖÄÓQ	™›$3_­Š|M£å2®seue+”ý·U„C­CQÂ2#¬ÍQa0Nõ8jÖù²žëÈß>D›1Í¥ŽìÕª)«¸ô¬
+üƒ‘rŠyáU×dd¥†ÿ®–�Bû—Ë;lÀ¾qQÒ|Š¨PvXΈaûêU1)¿r.4šâ:-Ì59 ¤X6ô	`,N =6à’Yi➶›5FuµYOŠ;d€y.dü÷ÈÐ`MÜeý&$“ÌI¼ dr·<Ga†“-(lÀ#T`…r:-–ñ=ÎçôºŠº=”ÅcdXCš!ãÌm^$!ùDLår2ßLƒåq8ïÜcù£ŒK›�±;‚ˆ	~Äù.&Ëæ‘‹>­ÿhtÆ2әÎW–Ž/KÚVë9°ª³&)ìÓ+‡gÞF¦Ûy5ùFºµu¸„ÞÝf�ÓÀA™lß''·g£‚	^à”•1Æõ;ep28ú´>*‹¾ã +’é‹®¨QÒnd¹bÎXÕöÝÛ³ç�1™99°à
+ã]¸B e‘£¢çm|ˆb… ¸íjPßW›ù4ÒEC–‡p·ÛÎ^MX'<£°<˜F"áºk!™4&yY¨ÄÖÕ*&
°+,0µ¤Ëê(ü°‚gCIM¤ƒ±�˜«b7«jI×o»TçúÝ¥<3
+-»‘)(Þ™ÀQf<kE&ºšÃÉÊl¯Ép"KØWÃ0Ž|AdJèP
+a�a¸gPØâ:�ÂÄEkÊÙÓ1ÜÁføs«'¦gVŽÉÃÍ=½ü~YP5VDkN@ä¢\†Š›ëÔëU
+òj’Ïi´“ƒÃT«—Š¹ƒp±œVjdRkß¿¼ûDß@ýÞDfê"ãìmc3âÀ¨½®æ&X¾S¸Åg]PÛ ^_½ÿ'�.@�ü®¨á–X«RÏ&º=_䤞/N¥ž/СçkSI�ËÌó‡D뼡™ö·}!z¹M@9xûuŠ¡Ê5RɽÆú_ˆÕÚØn65™ç¼OJijJÂ3¨‰­Ñ¾(jh+l§ûLPèÑÅxH4TºQ´VøˉHƃåZ½ßðz¿Hõ7…†äÙÛ$ô0´Ú¹vÛe‡¶/±íŽWÇ/Nò˜Ë�˜w|¯”º�¹X»íÞÃ3ú€×ns70¬»3ÔÆObÛ7$€Oôlµ}C®ØÒ3ð�FÛ—Û‚{n¾Aþ¶µkÞ¿­TKÚÈ®5^Ô›}A�÷E½â×îñJe˜Åšêõz¼æ{¼nçÝ´²§z•�ÑCM(^³zä$ÜÄ«W¯mÉ'ªWá9Ô+ÜÿôxåOôxÛ§ü¿ÞãÕ§ó¡àºúgÒ˜Ätà³z{»œ9ð-Á=ÝAâ9\½,¸êNÕYþ÷ò[ÑÛÁƒDlj—úU0«T¢ÛÁ
Á$tiW+Àã.;
Ï2�ÒŠTÑ,›./öo£¨]ž�YH�‹V0iætà7Û=Ë wœsÊ•PÞ'È•ˆúªÇ:!\®×±†µÎƒm¦«fV}Gy³u~»ýžšü¼K)IþP•ÓçdŽ5ªðB™AKûCZžý‘C—Ó{úž–î Ói…V¬�ÂñªðG`|`}Ž”¡ß(Àœ«Ži†5�aï§Á­á-"
+êô€£µÆ,}¾U •+®†Ÿ‹ƒDk…ÙŸÀæ”Þž¦Öw1TÜ´îð–{´c?¼Ãû2Ch(&1܃Zéö°‹?yÙI?p#ÛŸÎ�Ïëõ5|~ú—:»Ÿ1éŒ�–ý[†hYaÍÏPn9“G÷¹ZªÿŸ«úÒendstream
 endobj
-1742 0 obj <<
+1754 0 obj <<
 /Type /Page
-/Contents 1743 0 R
-/Resources 1741 0 R
+/Contents 1755 0 R
+/Resources 1753 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1747 0 R
-/Annots [ 1746 0 R ]
+/Parent 1759 0 R
+/Annots [ 1758 0 R ]
 >> endobj
-1746 0 obj <<
+1758 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [442.7768 238.521 511.2325 250.5807]
+/Rect [442.7768 61.5153 511.2325 73.5749]
 /Subtype /Link
 /A << /S /GoTo /D (query_address) >>
 >> endobj
-1744 0 obj <<
-/D [1742 0 R /XYZ 56.6929 794.5015 null]
+1756 0 obj <<
+/D [1754 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-494 0 obj <<
-/D [1742 0 R /XYZ 56.6929 297.3553 null]
+502 0 obj <<
+/D [1754 0 R /XYZ 56.6929 117.3409 null]
 >> endobj
-1745 0 obj <<
-/D [1742 0 R /XYZ 56.6929 273.254 null]
+1757 0 obj <<
+/D [1754 0 R /XYZ 56.6929 95.0296 null]
 >> endobj
-1741 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F62 1351 0 R /F63 1354 0 R /F41 1208 0 R >>
-/XObject << /Im2 1340 0 R >>
+1753 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F62 1361 0 R /F63 1364 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1750 0 obj <<
-/Length 3455      
+1762 0 obj <<
+/Length 3352      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥ZÝsÛ6÷_¡·£g*ñA�œ{JÓ$—N›ôlßÜC¯EÙ¼H¤*RIÜ¿þv±”(¹™ŽÇCXbÀîo? ±HàO,ò4NT¡Y¡ã4é¢ÚÝ$‹G{w#˜f鈖!Õ÷7«²EFšÅÃ&˜+�“<‹‡õ¯Ñë¾úåáÍÝíR¦IdâÛej’èû÷~ ž‚¯?~xûþÝ¿ï^Ýf:zxÿñuß½yûæî͇×on—"O|/y†¼}ÿÓj½»{õóϯîn{øñæ̓_K¸^‘(\Èï7¿þ–,Ö°ìo’Xyºø/I,ŠB.v7:Uqª•r=Û›û›ù	ƒQûéÜþ¥*�Ó\f3(ÅܦEl”TvqÍÂÄ°Q"I’èã¾>”CÓ>Ò2ïŸû¡ÞñnÕ}w<T5½ýÔìš¡ÇõpI0ò¤ÒÎÿð„È<êëÃçúp»„
ý[O]Ǿ|äÑnƒÏ"Ú•í3Ó;ÖÐ>ÜŠ<²ì±QÕü}U¶ÔXñ,[ª^Ã!ªDE÷U¹­×4ò¹ÜÝg%MÇ/Ûm÷…¨Šè+¢–^ú}]5›gÜX%®Kˆ¸Hy]§"!KIôÀ_½íØ+¢úk¹Ûoëïx·Â3JÅ"…³Hì¬âÝÌŽÂñÈ<s$vÑÈkÅ<�=Š�­¦…-+ùvt†]"c•™c—d*Ó"—z†m*ã\&9“MË»B/e°jZ*ž£åÞ²t�Íc¹zêxF бщp[K6}lùg„ÒYœ�Ô,Âïp²ž­Jƒo鵇]‡(Ø�z«�ÐØ•_›ÝqG/åç²Ù–«-�•»îØs"K#âÜhͬëMyÜ3‚*yn˜äèOøó¦Q_É­/%“5­Uº¥Ò`Ñpp¢|›ÎkÚ"¨mK-šÎÚì°�;‡òÀæ!À¶ëúä£uÝW‡f?4O7«C0§*Kyi}óG}
-ƒ
-P+Ïr¹0€Õ"æÏ
-©.»%O…Rü7Iä¶îϼRKÓyv�±§šá<ñJIçjʘƒÛ,Ì
-³¨=îVkf¤/ðt"Ú—Á}6F¥#¤œO_øñÞ&hЪºŽ�°£
-—rj:dŠ«¿=NT i>¦žß'žÖP4ÀBjŒÆZA-²žH¸®wÈþ
-yJaþ§°rç�Çlþ‡
—ÎYŠ–ú7ÃI)»\RÊTÔ`
-5†J‡JØ·ê»m=ÔÿÀª¨¶ÑG8\VU½·™«}k×<üØr<Æ#¶(€
ªî#MNU·ÛÃq¬šm3x@Í
+xÚ¥ËrÛFò®¯àm©ªÁ¼ë““ØY§;k)µ‡l 	IX“
+òûÕ¯¿¥³5û‡«4Q™7³'˜¤‰È29Û^i££•Š�ÍÕÍÕ?»
«áÕ)ùå㥛 ”S4Yb•TA€ù²>´t¦‡ú‰íCAƒü1/7ùrÃÓ]½o^Ù_?gøºh‹ý¶¬Š5ˆO	�S½§•âs¾ÝmŠ¯höT¶Gîêͦ~*«{š®êêßi*ïû¼-ë
+Åûõ[-‡Hg™%ÞûÀý¡)�vqXïÌœMÓùé±Ï«û‚†J:ëih�Qæ�ÿ÷
+)àžB$™1¤Sùc]®Ïo«Sø{uB ˜I0ˆÄÑMÄC¸,ü廟An²°’b^ßèÝÏ�– Û¢iòû¢!xST-ÁïÂUÔ[¦3–p Ò>í	tª|[¬'ØQ ¬ÞF¬§r³!Ë‚(”Íëª3®1ðÐ_#ƒXš¿_/4XËÑÚšÖU_Ù/¤HíŒ�w (dÁºRÓSÓK¤~ÕšMþ/\p2!
¼f—dJúá5ëÁ5ŸŠÆg‰Ö>ŠÉNHÙ'Þ)qNµçܶš_Yå `™Š p™JTë5A¡
+Ž dC
Ù6Å+¾Þ‡ây¼9p|ÁQFZCWS?–ëb#=çË|õé‰vXǨ¿Ý�.ËMÙ>9øèÕwuÓ”Ë
/7%¤åÝóQ6Á^
+¡Iã¡ø~BœS§†!i-™&9y•È+ç	ˆs‚\
+÷î²hI"uÊiᥞ ‹Ê-ÓhMÁÃÁ¶,šäƒSÓQC~„Ô+æϗÏm1¥‡€ «Syä™*¾Ä	¦´KpÍLÑ%€ÓmB¸Vfð.M›��+OQ d10ØæŸËíaK“aº�Óm}¨Ú)–¥‰·Ú0ëâ.?lÚéÌ2óÞô~±9¢ÏB#XΣ§œÑÊŠS
u�Un¬|èQbÆ�ÕéìÐDSË9—.M›ïÛ®T¹)Š£— $­öep›˜Ô!XHŒrñhMùGq\*¨Ý¼órfR“	µÝŸ(%
+ÌOƒ‹nÇÅpKªô†Ì)cá~\O8°:;qER&:51w$‰�N‘A~nS7:-îïg4ø8¨F;ü	Gªq²/Ò¿)V½àm"Ž¹ÑÊ%RèlÄÍIEÜa½ÀÃénÈCÂJ¦/œ1ãª�ܸR£Ê¦]œ•È›¢�Ð>ŠÀ´så0>u�ø&¹ÎHaOƒ6Ò¤\Œ(°f”c-Dƒ&8|=¿©#^ÏÀD¡Kì`nà!««¿¡ûò�èvœ§¼	{á(8rx†È„xÁÍù˜Íù�ãw©™¨xƒÃê�GD|Åà6
©@E…#N¨öôT
+!¤lšCðì8ЛF‡Š�)Gt.0,Ùø1L$']ÈÞŒGåRh‘Ó:‘C¬SÓ‹M–+D«z_Ly!ø5ùåk‚ô(BJ‹½¢#ڷѯõ®>$P�w£Œ+æb£ÎÎa»cGyÛûGòöQ®§=	§ÞÛÆ0¢•`¼ó÷’ªÄ@Ð~á^Xî%bÎò6Ÿ¾0}DºH¹Ãš =¾—¤™0cÚ$ÏLî&sin&K—ŒZlk¬¬pÜÆ÷;WöâUÐsÌ¿”ìéô÷“É{S 7.s_~o¨˜@(Y·9†™8o�›pecWd}
+âÊ3Í—“ß2&oÜC½ãîJ=n‘R<kV´1ƒzú²Y
±Î›U‡ƒJù™>g-6õýbÒĬ€T4Í.³ÑaMð1îEÚÄY
+c䆿�NK�òJ)«ÍÑg®|ÇÍ7LjQÕ]̆`Ð}ƒ
+é4àî0oöŠ»jawøZ½YMËÀ}^5ù*&¥Ž>Ñ�Ð;ŽqÂe&Œ–¼œÚzna"ÀD�DÞe[?v-ñ/ˆà"u‰&ûÓÙ—ê{D*6æºL‚>ö†…]HŠJ5r&;ªX„Ï,ôi±)›³^ùD:+.;�
ÒyŸ‘ð$uÓ. gjˤÜ,ÀZO½F–©äE:¤SF>Ãá/Ë´ñðc}ô�ÖÍ=ꙓl…ô}h)¾å’žx0ZíOG+�²ïKÚÐQ¥iùÓ#<?AK¨*_·d<x6ÞŽ?á[þvÿ§#@¬—L‚¿Š›$ügýË?¾ë™¨8ês}W(Ì�?ˆa¦ðpNsÞýJï”õÿm¬Uõendstream
 endobj
-1749 0 obj <<
+1761 0 obj <<
 /Type /Page
-/Contents 1750 0 R
-/Resources 1748 0 R
+/Contents 1762 0 R
+/Resources 1760 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1747 0 R
-/Annots [ 1753 0 R 1755 0 R ]
+/Parent 1759 0 R
+/Annots [ 1765 0 R 1767 0 R ]
 >> endobj
-1753 0 obj <<
+1765 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [389.4645 694.3759 438.2112 706.4356]
+/Rect [389.4645 501.3235 438.2112 513.3831]
 /Subtype /Link
 /A << /S /GoTo /D (configuration_file_elements) >>
 >> endobj
-1755 0 obj <<
+1767 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [375.4723 314.3269 432.5882 326.3865]
+/Rect [375.4723 127.2687 432.5882 139.3283]
 /Subtype /Link
 /A << /S /GoTo /D (journal) >>
 >> endobj
-1751 0 obj <<
-/D [1749 0 R /XYZ 85.0394 794.5015 null]
+1763 0 obj <<
+/D [1761 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-498 0 obj <<
-/D [1749 0 R /XYZ 85.0394 769.5949 null]
+506 0 obj <<
+/D [1761 0 R /XYZ 85.0394 581.0594 null]
 >> endobj
-1752 0 obj <<
-/D [1749 0 R /XYZ 85.0394 749.7681 null]
+1764 0 obj <<
+/D [1761 0 R /XYZ 85.0394 556.2775 null]
 >> endobj
-502 0 obj <<
-/D [1749 0 R /XYZ 85.0394 443.842 null]
+510 0 obj <<
+/D [1761 0 R /XYZ 85.0394 254.8253 null]
 >> endobj
-1754 0 obj <<
-/D [1749 0 R /XYZ 85.0394 420.887 null]
+1766 0 obj <<
+/D [1761 0 R /XYZ 85.0394 232.5141 null]
 >> endobj
-1748 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+1760 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F41 1218 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1758 0 obj <<
-/Length 3289      
+1770 0 obj <<
+/Length 3413      
 /Filter /FlateDecode
 >>
 stream
-xÚ­Ùrã6òÝ_¡·•«"ÏGgâÉ:•Lfeó�Í-A6k(R#RÖ(_Ÿ¾Àâ”TeËUf£Ñh4€>
陂?=‹â ÎL6K²0ˆ”Žf«í�š=Cßw7Zhžh1¤úfyóõ{›Ì² ‹M<[n¼Ò@¥©ž-׿ÍãÀ·ÀAÍßýôáýÃw¿<ÞÝ&á|ùðÓ‡Û…‰ÔüýÃ÷}÷x÷ã�w�·�Fzþîßw—÷�Ü�o>|˘Œ?˜>Þ¿¿¼ÿðîþö÷å÷7÷Ën-Ãõjeq!Ÿo~û]ÍÖ°ìïoT`³4š¡¡�ef¶½	#D¡µSÞü|óŸŽá —†NîŸV�±±™Ø@c˜ê ʲh–DY[ci—/E˪wmQW¿ä‚,‹¶-Ãns«ÓùÆ­Z Ä¿ÞFѼ¨Öõ±	Î6D‰Öñ,1i�¦pžÓ`¢Å�Šå×S
-à©Pþmþe±ÊW/nѸ·ÓkI˜ØëówT7P›,
-CÈða›P˜LôÔfz`�€•}G<  ¬Y<áé!|¨šâ¹¢­
Š¢p{aø?)õ…ÝÝõ@©áÜB“ÀŽ«/lj¡j�zÙGjú’¿¢€©’
-Þ|âæ„Œ=ø¹æ’�F
-´ÚD‘ó©.›hG…b®JN…ˆpn¤P~Ä:½.BG5!ÃØL³@‡V�…XŠ›y'·ÛÇ/
-”U
-«ÚÔ°¹
žU
{†ª0‘�p²Á†Øˆ)Š> (y
-¢Ë‚jýÖK5m½óWê8S—½ø|c¸nv{yëS–WñÏì<q†cÎÉòE§ZÄ&µ×�Þ�ê²Óë¨pÙMËÅÔ°¹ZÄiöBtTR¼­?âD½ãß”
‚;á°Ý•ÂÐó$ÔeýÌ¢*½œ¿gQ`3ãýÕ…Odð±�Î|\˜ZÉTŸ%°Ãƒ
ˆL’¼±'Q€X½½ êã6Þ"ùkåþ®ˆâ6^‘pÜŽÔ(n#ƒqÜÞŸä¶ã«,õÕ8MnìX³ŸD
-ÞØ3}ô¯N`?°XÈÏþƛڛJ!ÎM¾‰�ÿ�ð«8ºÌ‹Ç)à% 1fµðÒ-t™±#ìN7	L’ˆ}©q
-Áo'¡ÆÇ

£å
Ñîó�^ˆÂÈ¿Í0±cÊ®äꥮ',rþTä-±·§äË8ÄaÀ>1ª¿ôèFÉ	IÐ
cˆßD2ÀÜéZ_U°êŸí6üÀ[¹
ÀÇÇÊyL.Ä…§ám,VÔOܵ*qa­ïú¶qåK«°K&ßÆzZ‹M¶—�'Ö=pû¤ó2dxù''ÒåÕÄ< œ!¦ñ<>_/ä	/Т$oÕz�·œçÞR¥ÚÌR°«ÿÖL�]Unâ·0<×íÖ�tsò³z»z9ëÚ@‰mÓÿ›tÃëâi
áØ
+xÚ¥]sÛ6òÝ¿Âo'ÏT,¾H‚�NÎé¹Ó¦9ǽ>´} HHæ˜"U‘Š£þúÛÅ )QÊÍÜdb.€åb±ØoŠß2øÇoã$J2‘ݦ™ŠbÆãÛb{Ãn7°öÃ
w8K�´c½{¾ùþƒLo³(KDrû¼ÑÒÓšß>—¿/’HDw@�-ÞÿòñÃã¿>ÝߥjñüøËÇ»¥ˆÙâÃãOýðtÿóÏ÷OwK®c¾xÿ¯ûOÏO´”8ï?þ“f2z\ úôðááéáãû‡»?Ÿ¼yxgŸ—3‰ùëæ÷?Ùm	Çþñ†E2ÓñíXijLÜnoT,£XIégê›Ï7ÿG«öÕ9ù©XG±P	HRDl=/e¥œRª8 ¤àŒ”=JyoŠÃ¾«¾˜eQW¦é»ÓssÉ#©
{LüŒ…€5ÃñÀeÉDª)Ï/†¤¿Í¿VÛÃ|Ѷ+³§…vMÏ–ë>oL{èkÇõ‚�ê¶}=ì:ôD›/:³ÿâɽUuMÐÎì×íÞíØ6xz¨ŠÒDj8�²8–É•yÉkdCsbG³…“è˜bÒ¦K³Î�M­¬H¿ÿ øDY¤3®@zH›3Æk"-!£Œ3�dw‹w¦È�!â&/^É¡ÙŒ¹£ex£#(§Åu^íibUõãSñÅÖlÛýñŽs¾øgtOd¤’¡ë³"–°}k™(QÊ’§–NFãתnWÇÞt@UÊØ¿—.¾äõÁ“XÓ®‘@&bÓ:Rœ%N"³Ê{"Ã4�tZOo´»¾‚ÃØ­¶ù‘özÉ¿¸Ýû–fVn\š‚äšw¦t‡r¢	8¨DÆS%yi»¾ó:Ö¿8}¬¶U�ï[„�ùgÈIGqÆåukc]¶ö€eoªØ]´s&£”%âúæ
kf÷‰�3%:�§Û“�dÉÈÎaì`«‚ð<±s˜	ÊðóûOn²mSà•:¬þ%ï=d÷J»‡Ig÷
+§¬ª
+äÛ滺
+T 	�ãÄêOˆ«,RŠyÍÌÝ7c-âgèàj±³Ò~©JC4n·$@ÉÁãÓa¯LH¸òC¿i)BIoÈ
+K6MÄ7‰‡WCö
+kIâãH„P5(-r¼OÔÔÕMÚÙt�Á4ö¶8F�ŒOF[„i¬ø‹—
+nº1�'•»7ºÃn×îÝ`Ûå $÷¾ô¹8VXš
Þ
+Ií 
ƒ›Nƒ›>Îéæ®íª¾¢BP’ð‘ W.*"䶅uñó;šŸ
+²ÈgÛ{Ê»W>b}
+î®»d§’cw$ã×ítŒuÙN²YÔ”),+ǹ¡*8ãWYX3<ˆ“–+W’O™xv*,�¹Ù!ŒAl°ÉL¶«®­
&XT’Å'Rš/U{èêÐ:µ�
+�C&‰ð[{¨K‡ºÈm2“2„ÞXÉäD%( ´”FÖ«d3YLŽ²¦Ø;
+
+m¦Ž(6Ðó™̻^dšLTaÆÊ)Û Cìœ):}˜~ˆl‹âpݹw,Òo|c]¶Ä€…<†õKô$�¯ó°f˜˜Z"ƒ¸¢õ”WGd£–Ë ˜-¨’y—ñÃôP™¿f8­aÞMÐ¥è& Á�U滼óB8oà9΢›””ÅS<e‘ŒÓ©³â™mLÛ'š>B2H+>þHƳð‰tü:ê7>I¿é÷ˆ®ïÕmÔo\±ú�
 endobj
-1757 0 obj <<
+1769 0 obj <<
 /Type /Page
-/Contents 1758 0 R
-/Resources 1756 0 R
+/Contents 1770 0 R
+/Resources 1768 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1747 0 R
->> endobj
-1759 0 obj <<
-/D [1757 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-506 0 obj <<
-/D [1757 0 R /XYZ 56.6929 561.2205 null]
+/Parent 1759 0 R
 >> endobj
-1760 0 obj <<
-/D [1757 0 R /XYZ 56.6929 534.995 null]
+1771 0 obj <<
+/D [1769 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-510 0 obj <<
-/D [1757 0 R /XYZ 56.6929 154.3399 null]
+514 0 obj <<
+/D [1769 0 R /XYZ 56.6929 372.197 null]
 >> endobj
-1761 0 obj <<
-/D [1757 0 R /XYZ 56.6929 129.2851 null]
+1772 0 obj <<
+/D [1769 0 R /XYZ 56.6929 346.9751 null]
 >> endobj
-1756 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F48 1228 0 R /F62 1351 0 R >>
-/XObject << /Im2 1340 0 R >>
+1768 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1764 0 obj <<
-/Length 3180      
+1775 0 obj <<
+/Length 3072      
 /Filter /FlateDecode
 >>
 stream
-xÚ­]sÛ6òÝ¿B÷tôŒã“'Oiê´î´NëøæÚ>Ðeq"‘ŽHÅÉtúßoP EÙ½I&ãp
,‹Åb¿ 1ãðO̬a\åz–åš.Ìl±=ã³ûáLxœy@šÇXßÝ�]¾UÙ,gy*ÓÙÝ*¢e·VÌî–¿'o~|ýëÝÕíù\ž¤ì|nRž|w}ó=õäôyóîæíõÿ¹}}žéäîúÝ
uß^½½º½ºysu>Ö˜/=…Þ^ÿ|Eз¯ùåõíùŸw?�]Ýõ{‰÷+¸Â�|<ûýO>[¶:ãLåÖÌž Á™Ès9Ûži£˜ÑJ…žÍÙû³ßz‚Ѩ›:%?£,3Vf”rJ€&g©’Ê	°hÛê¡.—çs%ó¤[—
-kUÊlFJOZ%&
-Úº!UÂÑféñÚu³ß,c¼b·+ê‡è
-èä}ÑäÆÓê‘iÿn©�
-šD‰N¦jÃT'Ôôã¾ò¸žR/5’@¼Š³§“ÖØå!£ëú06dieHÝ�Ívܪa\2°q—¤©áVï"�
œ‚L\XslàøX´ªÎ˜b㾄ÔÅû¥¯ø€{Ç‘¢žâ@¹¸6õ”Q¶˜%Ù'ÅLf³™Rè™sñO¢ˆ1,„šÓ1FOq“<2ØK“fæ°2²é²ü#&)z“ß�É@ñ%&uƬäbÈ䉣ƒP�c·§SA$¹ó¶©ó'Vutˆ`pjêÙ6}ñZíc¹¨PŸÎÏ“åµ°­ìP‡}%!'œ-j
§“ò€{ôqRÈ	O´—�»g�- Jy]•C> A‰ aK!t|Éíüy<aÂïÑ:ÞTôŽW+6gVØ
K~—�^àãˆVäuA“’«ÂeÐxÍ#
8Ù
Il$ÊêÙã p*ï•ç
‡P½…ÙîÛ@¿kËÍŠTFs ÆµªZr•Iî)p†åçÇMµ¨º	vRÍ4 >oC„Õ�„)r‚L ¯¾ž=ÅyLòøz
-H¶r	béÑNÚ‰ZbMþí˜ì)¾À¤_ 2Ôâ˜ÉS6ÄBêkÃu¥ÊžUS—tXE`G÷ÔàK…è1ÁšRˆˆh=v¨R1ÜW}pÌ%RÜû™¤2¹þ•´H	A¸FC‘¯Æ¢,D
-%}�Å¢ÛcÖ
+xÚ­]sÛ6òÝ¿B÷tòL„à›àäÉM�Ö7mÒs|smh‰¶9¡HG¤âx:÷ßoP DÙéÄ㱉�ÝÅb±Ø/XÌ8üˆ™3Œ«\ϲ\3Ã…™-×'|vs?�ˆ
+“Y¦¬pQ_‚¿i›ESÞÞþ"y¤–úM5Ô�$iðºè"ZÛ
++0€<°¼éi-
…97pay×nz¿nJ%Ù:“àÓþ¡,©Â*A+’e‚}„èÊ´™ŸÑøNô
+Eó&éÃÞ»‘.Ne�*Ë„ÔÙ7¥�ä¦õ“¹œ7—CŒ½bHÕ!Íd™Íä‘\.çÒ1Sò`ãÔK¤r@S`
œã 6/–ÉE‹”òD"'3Æ3�@é�
+ùmA–ÀB
+Jσë¾o›Î�P2„3u|ÿ‘ú!³Ãæºx¤É% Ñò0êÍ®ÁÈTpŽ£Ú­o,G£ËÖW!¢Í¼¼ì¼÷P7ífíÓVœ-þ½	ƒÙùD®ã2e��{×`�I0IÙ-¶bv‹íàqX¢,{!ôßnê“ÉÍèGLÌÂG³zîW§fœó± V�6«"QØ9'�†}
;Þ
÷s½EzòŒ²¤F?™¾Â†�11-Ýl€�E»	„÷TÆp&…˜Ha‘|Õì_C°)Œ;“R0‘
	ÐošÛÜët™ô"ø"…�V6qBûT‘—�å2à$^½Ï�šIíƨg9¤d�*$sTZÖÕ ¦¨­5©ζ«
+S>xGô˜Ýxø6ÄWËÞßg?ÔüÁ¹¼Ý†ÀÙãùü¿¾Jæ	åáˆupbð�b�Pn˜NSÁW‘·ÀšpDœ¸Ø´!—a:è¿÷åM"ÅÏTb�ÎÆH;Û[t2äê8×Z0íáŸõ’SA“(ÑÉT]DõòqQM?o«
+Ü`ùõ¾®–U?Áä“@Ÿ¶ÂiH¿”c#˜Ì…ýþÊy¤¸HINTÎ]Ær‰¹p;j@$j‰3ùË19P|†I	^@d¨Å)“Çlˆƒ¤×ÅëJõ <+zRÂðeCýCK�X0Ç·¢ÌP쇀h=6¾h¿Š3†‡ZÎù
+×
“ôBÎ/~#-FBø­÷b½�—Æ2,ø~�frDóß`ò��¯{ go¡å8Øòû2TŸ5X˜îzª6íKSb	Øgš�¼
+�9_)k^À_Š‹”ä”ÃÐ`G!·ÀŽû´äê´zA&#Åç˜ÌÀ™eJŒ™<¦’š
||f¤ÐßØ
}Kz3‚–·~؈GØÄ4Ò«¡	U|ø.ïÊå§PL§™å¢Œõ붨šXNèwU†$ÙÆ -­ø§È
#Ö
+ ¹mú*Ät}‹ǨÒßn›ÕDíò½dèø‚�”¥åÞóƒ¦wåF`�ïŠ
 endobj
-1763 0 obj <<
+1774 0 obj <<
 /Type /Page
-/Contents 1764 0 R
-/Resources 1762 0 R
+/Contents 1775 0 R
+/Resources 1773 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1747 0 R
-/Annots [ 1767 0 R 1768 0 R ]
+/Parent 1759 0 R
+/Annots [ 1779 0 R 1780 0 R ]
 >> endobj
-1767 0 obj <<
+1779 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [242.0197 397.9224 315.2448 409.9821]
+/Rect [242.0197 217.3669 315.2448 229.4266]
 /Subtype /Link
 /A << /S /GoTo /D (rrset_ordering) >>
 >> endobj
-1768 0 obj <<
+1780 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [238.0484 319.7982 311.8142 331.8579]
+/Rect [238.0484 139.4411 311.8142 151.5008]
 /Subtype /Link
 /A << /S /GoTo /D (topology) >>
 >> endobj
-1765 0 obj <<
-/D [1763 0 R /XYZ 85.0394 794.5015 null]
+1776 0 obj <<
+/D [1774 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-514 0 obj <<
-/D [1763 0 R /XYZ 85.0394 465.7379 null]
+518 0 obj <<
+/D [1774 0 R /XYZ 85.0394 676.5153 null]
 >> endobj
-1766 0 obj <<
-/D [1763 0 R /XYZ 85.0394 443.8076 null]
+1777 0 obj <<
+/D [1774 0 R /XYZ 85.0394 652.4057 null]
 >> endobj
-1762 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F41 1208 0 R /F62 1351 0 R /F63 1354 0 R /F21 930 0 R >>
-/XObject << /Im2 1340 0 R >>
+522 0 obj <<
+/D [1774 0 R /XYZ 85.0394 284.6926 null]
+>> endobj
+1778 0 obj <<
+/D [1774 0 R /XYZ 85.0394 263.0537 null]
+>> endobj
+1773 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F62 1361 0 R /F21 938 0 R /F41 1218 0 R /F63 1364 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1771 0 obj <<
-/Length 2229      
+1783 0 obj <<
+/Length 2399      
 /Filter /FlateDecode
 >>
 stream
-xÚÅYÝsÛ6÷_¡É}SÁø™<¹9;u§uîÝÜܤy`$Úæ”"‘ŽãÞÜÿ~,@ñK¶§ÓÉ8ÁÅb÷·‹ý€ØŒÂ?6Sšè„'3“H¢(S³ÕæˆÎ®áÛ›#æiæ�hÞ¥úqytr.Ì,!‰æz¶¼êðŠ	�c6[®ßGšprhôúíåùÅ›-N��Œ–o/�ç\Ñèüâ—3½YœþúëéâxÎbÅ¢×?�þcy¶ÀOÚóøñâòï8“àã
-«È§£÷èl
jÿ|D‰Hb5»ƒJX’ðÙæH*A”"ÌGïŽþÙ2ì|uK'ñc”p¡ù€’u
-
-ñ\àøw:ªDtUCœ¶»ì*ó_››´Á£¼i ¿˯zòOp
-Z >²¯~<9ç¼A-CÁcG³¼
ûr­£«ª(ª»¼¼Æ×ìKºÙþÛ]^8ºÎ?û¹Ý1‹£,­«2ýè>f7éçÜ‚„ý 	{¸
-¼<¢­¯v‡�t›™`ÀOâ§t­„‹ãéžuλQÅ~?J‰6Fí7vFßf«	ÇàœHªÂiÊ}bXgöà`P²~觱«_ú 6M¨ê×nﱎw)ÑÝH¥)óµT]ÀÈk(ÈщaÏF¬å8ï²t�õ„c`NÃ
²–Ì•n6çN@æëZÔäBó¾¹ßfjCdcš?	D=­À‘Æú;j8>¦u’€»ù­÷Ä}­eˆç/ÖÕ&ÍËÑÁ¦Œh&Ô÷S¼åøˆâ‚J¢)cÅ_Liž8uI_ó}öœÐžnÏi'6L×6Úg¨îº°5±‚J×V°*�±�Ê!©û¡=Ϲ=¥Ùš`ûÌn¬³«òŽ_ROF/èã´	:½üÏthЉjd‡ÂÅ^8(³ïA¤mÖîå>”-éÊ�Í"y›Ô’M?,›sÎÎF€7$L³Á•D_Ü�n} ôâÚ—ã\N	Ncp*¼P›[‚f"œ!ÇREÓº
7©‡1óéÈF/A…駣e�­È®S_¾N‹Û¬
Ò»	áâ8(ñ¸OB
-4I[^ùjõå(hÑ„0ø¤m&žt%+dL”ÞýÓûm«‚ 4Ü3< 
®£ÀËÊaÜJÍ9˜’#ˉüÊ‘6K
#%ZźÏ¼

-½‰ó4tÑë$íô’
û
øìêI<Hºe;Îß�õ8,p¡ÑU™MuŠvU‘‘¡¹¥2D2(w:À<kkUÈQñ~û§³+šÏ&@.Mü°ýlú‹…Än—–k¼Þø
-ó©.êm-ßšOѶ¨«M Á�IÄÈè0è]užÑu¼b4_Á2¬8Œ:0—¼“s§Q‡ÙÝmu¿*òÕŸ†ºoÂü.{âê¶\Ïqô1ÐŽm1<¾-ôWj¶çug˜wM'ŠïˆïòæfÐHÚ�:s”s4æ®áõéÀv¤ÛЮò(m¦ïUµÙ殫p¨mU°Élê®û.ý¼Û•CZ.ó&w©BÐa»Ëñ®G.AD{C“›´YÝLÁÒæJRÐÙ÷ù´o�–ô�–ö±€Óuªç9êÞ÷÷¿ùý‹é„Ãm§
-©VÝígG}-7 ,¸Å¢€>ÐÖ†H!RCµ3Ìyåïüü½ùË—y	‘‰T£›—Î}^¨N{vïü`sáppí��úß\fG/ì•ñ’ðßá׋v/ŒŒ¯ýö=…Ä:c�=šCžú»ðþGsi+ŘOÃí­"‚P£G’‡�Ç¢ÿBK„–endstream
+xÚÅZQoã6~ϯ0úäÖŒHŠÕ}J÷’mŠ6Ûz]Û}Pl:*K®¤$,î¿ß�CÊ”L;¹f�Ã" 9g>g†ÔÒIÿèD$$ÉX6I³˜ˆˆŠÉrsMnaîý	µ<3Ç4ó¹~Xœœ]òt’‘,aÉd±ödIII'‹Õ§iB9	Ñô݇ëË«÷¿ÏÏOÓxº¸úp}:c"š^^ý|�½÷óó_~9ŸŸÎ¨túîÇó_sœJ¬Œ®®ÿ‰”›Bç—ó‹ëw§Ÿ?�\,z[|{iĵ!�|úMV`öO'ᙓGD„f›lNbÁ‰ˆ9w”òäãÉo½@oÖü4ˆ�ã	
+gÚ|c{¹ã…)@Ö¥ÞºTJ’Æ€FdVÌW«Fµí:&#"eæ©÷ðɤ”aèf½Ä™/qñõc’™‚˜
0›¼[Þ�•ä”3ñí”ì%>£$§‚PNùPɲh;‹¸¿Ó4§aÒ^Tv—{Ã"Q润«·uYß>DÆà‡2Î,cÛ�?h_чÆÓ‹°B嘆¸Z©T©��<#"•ñdF)É„`FFïmNžö6–P𤶸­´«ijŽÍ
+¬Ì«¥²Äj…¼Æ
<Ê8iÛZi¶–ƒNíô¶®Zû›Ç¢»1mŠªØÜoBkVð¦~PnõÚ
�Ba"nÔmQUEu‹Ãz�m?ïkDzIö8•FÒ•Þ5)íqƒÎº.ËúÑHä2�ª/ùf[ª7§³˜q
+rÙÁj6´
+ÑPÙH¢²‘
—š@38é	ìð‹qÊj[Èhbýóu§ìvwy‡¼
+üuGUHt"™	«6ÃÞÏØÅp`¼?°7U
[Ç©„iÍ9Ðôö®~¬°{ò”2¦5j-¬‚o!øô·Þ1�ä˜Àí9&Œrl¬‡A¯¶«¢ó�„
š!Kœ¹\¤Î'¡çfÆ5¢ª»c—¸‡z
+·A÷b»ÚM+ì÷Ã5¹UŒ7Dßáp§Z"£%Çæs$Z´€€z»£
+·zlWÏŒ£YÄXAœvjPô
Ó´!˜™3°㳬bÕÄ¢Á†væÅ?Á0 vvû‰l=ÛºéLrœ%Q4ýj”bœdº(¨vv†,W—Ø<tÇ„ì`f¹ß.~¼¸ÆÞºhÜšëÂv´¥É^ ×C°ª
¹ÀWO­Á[ψQ*õYµ¸·‡íõÏÍÛ#Ëú®üvHâ;Òö[“ñã”HCÇ¡vÀ,Ë\'nÝ}7\‰Žñ½o-†„¾±BK`£1íØȸ#XéK¸ùQÙÿWàØaàØ8z¸#^ñœ?âæ/Ø”WGÿ&pü0pü9àØ<ŽÿOÀñCÀÑǾ‘Ç‘xd«ã´m0`¤Ë»>¶
e¤¼¯¿èðKgEбprt‘%ŠVÿ‰•õЖ×8Àä§{·�ƒ±g¯Åm]å7ŽïFÝå…©ÁŒDÛéÜ6§è.&kݳ÷$µØ5ÙÚQJÊ.%.ztÉÅ™œ^éD‚·¨AÚbS”yƒD]¼˜o$åa„ozxÉ‚N±(×\·€âžO’iL2òÅj1÷j}ý3¼óyôW-«¯l]®à2épÔ]W"ö
+‡ê(0å
ñ†s{�¶—1„VS¼jCýú5M|3ô,ša$ÖØîn^0ðËYÔ"༶ød’÷{/î=�rlF.
+=Þê·ÄX8,Ü9Ü�Ç$³7{O¨,!�Ä„Æ—šÇjœln'Ø™{¯Û=ÿÌÿÁþëö¾\­ÇG”…»kºcÈ÷tÊR’I8¬þ{ïì=×sšìIÓšûƒfIìÂ[f&Ï«ô	‰@–E´÷U_qX)‘25Þ�È,yõs´8ó%î¿FC#I
+–õlfÓ·jpÆH	wš
+›VJœÊÝísKÆ2¬ýÞF\ØÓ,Ã\ð	Ëw³�àþB	IDíB=—¥œ¤\#ûòÕˆõg¾HÙ@9
+Û™jgèÙLŦn
+˜
[@æüÄ1
¬Î
+é.ÄšTœÒ©íêó\èSªVoô“~â^µVëòŽýIŒ^p}KR·Aç×ÿ‡†$‹�Å¡rÒ*ö¨´UýZfò n™¯›< [ÊIÌú¤vL·ä¸n~íšèO%„KšsöPÝÁ— ^]=pÑñ†ÏÚ{qW‚£ôŸRÿúP–qw†Œ‰(o;p“öOèS›Ž´wòˆ§¡K1üªT·¹­Ýòò^õAº	('%ɸàÏû$¤À4ëË+[ª~è[:tý
<�‘áÏBüêïì»ÿ„ëí“,œÚY*I,AˆUJëŸ&{š»òûªÿ=�endstream
 endobj
-1770 0 obj <<
+1782 0 obj <<
 /Type /Page
-/Contents 1771 0 R
-/Resources 1769 0 R
+/Contents 1783 0 R
+/Resources 1781 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1747 0 R
-/Annots [ 1773 0 R ]
+/Parent 1759 0 R
+/Annots [ 1785 0 R ]
 >> endobj
-1773 0 obj <<
+1785 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [325.3322 327.1569 398.9856 339.2165]
+/Rect [325.3322 146.0218 398.9856 158.0814]
 /Subtype /Link
 /A << /S /GoTo /D (the_sortlist_statement) >>
 >> endobj
-1772 0 obj <<
-/D [1770 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-518 0 obj <<
-/D [1770 0 R /XYZ 56.6929 397.747 null]
->> endobj
-1294 0 obj <<
-/D [1770 0 R /XYZ 56.6929 370.1557 null]
+1784 0 obj <<
+/D [1782 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1774 0 obj <<
-/D [1770 0 R /XYZ 56.6929 244.467 null]
+526 0 obj <<
+/D [1782 0 R /XYZ 56.6929 217.1183 null]
 >> endobj
-1775 0 obj <<
-/D [1770 0 R /XYZ 56.6929 232.5118 null]
+1304 0 obj <<
+/D [1782 0 R /XYZ 56.6929 189.2257 null]
 >> endobj
-1769 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R /F21 930 0 R /F53 1303 0 R >>
+1781 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1778 0 obj <<
-/Length 3007      
+1788 0 obj <<
+/Length 2754      
 /Filter /FlateDecode
 >>
 stream
-xÚ­ZÝsÛ6÷_¡Gi¦dðIsOnj÷Üi�;[w/mh	¶9•HE¤â¨3÷¿ß.à‡D;é¤É$�Åb±Øýí.(>cð—Ïr�2iÕÌX•jÆõlµ½`³'ûñ‚š$%Cªï—ﮥ™ÙÔf"›-¼ò”å9Ÿ-׿Îßÿóò_Ë«»E"4›gé"Ñ›sûõXz¼ÿp{}óãî.FÍ—7n©ûîêúêîêöýÕ"á¹æ0_¯L¸¾ùùŠZ?Þ]þòËåÝâ÷åOWËn/Ãýr&q#/~ý�ÍÖ°íŸ.X*m®g/ðÂRn­˜m/”–©VRÆžÍÅýÅ¿;†ƒQ?uJZæ©Î…™P âr&RkŸmÓL
-é5Xï×n¿H2Ææ«ãjS®þ�›š%ܤV"SÎS«µðÄÿóƒï®…ðe³DòTY:‘—r³
eÙ|UGÍ¢:Rc¿àùÜ5»ºj\ƒ]fþXïi¬=îùå�xUû纡β
-Ü7Eºnn‰Sû\´Ôó\|
-¬~B‘Ì#]+Ri8èÕý\7mê>ÛÝÆ¥«z;±K«ÓLu<[ÚZ¢ GsxDicL|þºŸ·5iTæ`¸¸�TZl^ŠcCVõàèIoûÊ­©ÇïGŠj
âùvÐœ)®äl~é•�ƒí3kÏm¨Fè,¨÷Kë‘IL®‡{‚£ç6ÕRç~/7�D¹=lÚTÔ8T¼²)ÏTÔ¸ß7®MÈÏU®˜)xÑ6mѺ­«Ú¸ƒÝÎ^–ï¨v|œØ\U·a/õö¡ìv'hºyÔ
-¤uåºE6¥kÒ×=Ó<Í4¾ÆÓ9øŸÕjÚÓA•¹“öu^4�
¯ÐŒ3ƬzDÕYêÖ= €~;ã›f©á€¤"ˆ	|;8	
&OÐ
‡,âI|
-'|©éIa[,J)ë-Ã+#“Ã5K™ÈlgØBv¼lÞÙòH0­@Õ*;µeZo]» ˜7Vl4‡Ý�Q�}RBŽ‡•…ds·ŽÀ†¼�bŒ+
×abY=!6ÙùŠw¤öÚ="Ÿ<¡Cñùu8ÁÄüUQFŽž®*<ÏMœDøkÑÕvå&PµåÖ�Ðìܪ|<"óˆ$^zÞá+üËú’ÁÞ�
ƒMîJOòdhàЪ®pÊÓaïzJlJ/@<»3ïVÖ
-�åsFýë²)6.pEntùü)PýÆ4[zÀòLš‰X*a+–w°|ûa9D
AtêÍdˆ1'Ø­Ý:…Õ8eË

!B>ÐL$Q\ªÔæÝú�BN¬�ç#d¤Á]q²„²:´®¡¥}°­Ö'y[|.·‡�ï|*6÷–8ƤrÖ°ϧåÉRÅø@y.N6È“ù8Ãù9+œŠ‚Ü­©©öÑz�Öb:më=¶É T„Dhýp{õžÚ°Árí-…X<åæ2æÀ«KlpM4Àu0—%¦{ýX''Ø[™Œq–ì SnR·¨�Þä»,(N’Õ"tDG€&D´}é¬òñ,¿ê”GgVjÇŒÁ'š8³¨&ÅJ_E)®R†0û6J
¨Þ@©HåU|N*¿ÓI¬›QÂÚ·×ï¨&a•åPkŒ$X., ¨Aèà¾ëÃ
-5+Ô¼ríK½ÿƒÛ}ÑÕ +'ÏËW4×g?سs{¨À (®æцóºG1àдuo‰0V¹'°ÔO�²¨š·§c9Ñf¢`3™–'vw¦Î@à….†·!çPP®©å�žd=Ð(HÎ1 /Ô5`•äS8�<ZTwb׳kB_ؽ”U7׊úˆƒŠ`;Øä,‰‚�Ò™
-ÔÆÛ¦W!I‚ÅÔÛ�4¤z’:ª¨é×IAÔW"{ùŽjbý1"A~*²'�EˆÏ†
[G_ƒnò5h¼<—«çÑœ
Ìàx8Ƭ�*Y¼x(«b¤4Í]Ý”m	®÷ÉÅ"ë�(‘ÂE²¨Ø¤ÉùØ)û'
žTùçzþâÜÔ…‹j¢‘�
-<ùíc×%üywIí“k§�aú5‰À
--Jº¢Ê?Ê�IÐhpÓœ�®§rM{Bœ×ŽVÍOV­‰ä!8¡P€5§NX¬Vn×Rûåê#]ggi®M¼†Sˆ©5&Þ¹œg@©²T'xÇþ5¹¿ÂÍóüÕ+<Ãé"íëïhÆYq…Kxá5Íà
-�s�f¼ÍÌüwxÈTÂú’Š›Üüm·xçdÈzâ0Öæ$ÈèIg´-ogÌ/êñþÌ…«œ2Ü
-Óãtz\3]
-hðÓ�‡câH,í¡«{
æ®"’®°†^ØvU´ƒRÆ‹C[o¡„¡²81,Í…<¹C]A�ÆÈ
õõ“«Ü>$�ðê¿ú0Jc]C€Å&Ãs}¬Š­ÿ~/‡÷.LÄÐzªxÌlA¯Ü_VAÝ—£Nipÿ<ënp}2œp~ç|){[…²Ä�Ðs&
x‰IsfÕ—d8ãî_8	?h¹Ï»• &›�®6Xa¨ú z½Ãma6U0!àhXooG‡ê
oƒ©ã1Åf3´Jìx®_¨±©ñ[²à»—õHm
-²Ô
-çvçWô%fô¤áÎÀ0·Ì¤ÿ–†£¾:Šò%Swå$ôRB©M̪Î�^J‡Ñ‡@u²8‘ù�À §¨Aé"Ìò×HÁÃ07·ýª¤ßî5�š@Щ9P•“_ôzM嘉jÐ !üPD0zÆõ™‡o+0dèÑ3÷ŸI_ÊŽa;f5–V¤§/ˆ1g�$|Á¨ÏY¢”ÈlóéÂ]™T@h‘ZN•í\¥Vð˜û„ý
+xÚÅZÝsÛ6÷_¡é5!ÄI\ŸœÄι“:w¶î^š>ÐmsJ‘ŠHÅq:÷¿ß.à—('®çæÚi
`±Øýío‘òYÿòY¢Y(�šÅF1r=[mNÂÙŒ½?áNfá…}©7Ë“×ç2žf"Í–·½µ&	Ÿ-׿oÿ~ú�åÙÕ|!tDl¾ÐQ¼¹¸|G=†>o?^ž_¼ÿ×Õé<VÁòâã%u_��Ÿ]�]¾=›/x¢9Ìn…#Î/>œQëýÕ鯿ž^Í_þrr¶lÏÒ?/%äóÉo¿‡³5û—“�I“èÙü7FÌ6'JK¦•”¾§8¹>ùg»`oÔN�²Ÿ
+9ãBËÙB*–D°Æl+UÂâ0mû×fyMÂÙBHfx¨Žk@óBXË5i†-µà2fJÇèR³XpÓz…à=¯àJ²DJ=‹5g"�A·ø†âk¶Æë
yÑ“�43Zã6(w•­ªÝœ'Áº†{Ua�Ú_þà
µ›ý®„¥ìp^Ò·¹w"nv¶kû
+ar«ðñ*að­*3Ô-È9*(Úc{™7‹£HÌú¦y™¹ñb%D•ßŸ?cI¯ññ„MAßä{7(b&µTöè»´\W›g^ îÛ~Œ.P»„o]m¼mdÛÝmBØ?aöÞy^f£Îì*f‰ãg,ég5{ƒ©TÄ¿gv®qò¸ÕãªÈWÿ3³§ôq»tÂÕ¾\/¨uãe/c·>Òã=´rÆ"XU%ÆÎÝžTYÓèCÞÜSËEž>	¡à¿(+Ó›"[8ÜXìvuÖàIUÛ&¯JZ:m†ªPZU›m^à¢â:Ÿó`“½Â_
+÷*]¿ÝU0GÞäiA½í9óòŽ†«Û‘üÕ¨C}yQPç&mV÷Sf¡ihÁÒ5êm¶ÊñlãûhE¿µ²ßÃœ¾W½ÌS;çï’Ûÿ#mñÈ0	1
	¦LdúYö ÛÊ0‚Ó˜â"(Ô³_b‚®D
+çvʤþ"^bý'5¦Ðgeø�°â‚£ÕÑ* ‘àòò9´ÔÏ¥ˆ¶4”äG}¬mƒ
b,d1‡’PÉŠ
+N4ëÊ/¼è¯lõ�FXƒÓ
+"5¨!
ùà�nE
ñ¨+j�4TŒöÆ´w(Ú@©ÞP›JyL„Ö»Ëëë³·Ô†æëÔ×Í:¸Mó•ãµ[«{"Sä€kç.K¤ ÝXî'ÐJp¶|1´­q+G'½5:—o™™¿œÊèÔuø@À
¬�gnV~{ÀùZãѺ�šáµŸ™–“j±£(˜)�–ßA©žÔ(奬¡Ò¯‹Òžt«�
+
+cžÞ¿•šP`€U|”Cý3Ð`97€Hø�¡]ø®÷+ûÚ¡‚2kªÝ4ØìÒ¶.ZÑ8E–Àd¾¢¹–þ`Ï6ÛAUYqe__„ño(ºC1X¡nªÎa¬ÌîÀS¿8É´¬²]ËÈš‡‰ð©}àwæ?ž%,â-lX_2€"wM-ë,ð%ï�FJzvˆ
}ŽíƒWRLá<Š<hQ-,ìËVíúÜ9èG^¶ã~/o?¨È!
¶×¾nñŠŽë@5nAõÐNk‡å?b£…èìsˆ‡†E@^<†Ópˆï7ÊhOL»¨�	©y_íw2Žãh
+VjÏÒÜ#0�JW4ÆAöu•ÊÄAììåêõغ0¡2—iî€ïº§�^a_-›ÂUŒ€Î	HÄcs•éº}ð¸u
+u3™$bÚÚ¿$qJ¡âq<Ö\Ë„éDĪÿÛ@Bíendstream
 endobj
-1777 0 obj <<
+1787 0 obj <<
 /Type /Page
-/Contents 1778 0 R
-/Resources 1776 0 R
+/Contents 1788 0 R
+/Resources 1786 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1747 0 R
-/Annots [ 1781 0 R ]
+/Parent 1759 0 R
 >> endobj
-1781 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [315.1789 121.2911 363.5077 133.3508]
-/Subtype /Link
-/A << /S /GoTo /D (dynamic_update) >>
+1789 0 obj <<
+/D [1787 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1779 0 obj <<
-/D [1777 0 R /XYZ 85.0394 794.5015 null]
+1790 0 obj <<
+/D [1787 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-522 0 obj <<
-/D [1777 0 R /XYZ 85.0394 543.8411 null]
+1791 0 obj <<
+/D [1787 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1780 0 obj <<
-/D [1777 0 R /XYZ 85.0394 517.875 null]
+530 0 obj <<
+/D [1787 0 R /XYZ 85.0394 343.0471 null]
 >> endobj
-1776 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R /F21 930 0 R /F62 1351 0 R /F63 1354 0 R /F48 1228 0 R >>
-/XObject << /Im2 1340 0 R >>
+1792 0 obj <<
+/D [1787 0 R /XYZ 85.0394 316.7826 null]
+>> endobj
+1786 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F62 1361 0 R /F63 1364 0 R /F48 1238 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1784 0 obj <<
-/Length 3794      
+1795 0 obj <<
+/Length 3406      
 /Filter /FlateDecode
 >>
 stream
-xÚ½ksãÆí»…¿Už‰î‹��—;_zisIm§3�$(‰¶XS¤"’Ö9¿>À»|ˆ’Óv¦ã‚»X
-¯ŸàÙ·W‚i–Žh9¤úæáêë�*¾Nƒ4’ÑõÃã`®$“D\?l~^D�n`†pñþ‡Ï?}ûÓÝ»›X/>ýðùf)M¸øøéï·}{÷îûïßÝÝ,EbÄâý_ßýøp{G�"žã›OŸ?&¥Ÿ3“ÞÝ~¼½»ýüþöæׇï®nü^†û¡Â�üvõó¯áõ¶ýÝU¨41×G„�HSy½»ÒFF+å0åÕýÕ?ü„ƒ§öÕYù‰0�*’3”r ÀD&MÍulÒ RRY
>lsØ“”‹¦xª²¶;܈dÁ¨¢Zçû¶¨+¶ÅÎ=hè·«Öuµ)�$+ËWDªE“·L_Óo]ñkÛ¦·Ð*¬‡+µŽ‹uw |ÕN¥éÔ"+oÄ¢¬�4Ây@	 ‰¥AjŒ´ÛÊHQe±+Ú|CƒlWwvZ€ëGú]—õú™Àæ9?Þ¤røù�¹ôR,T*Ò@…z@àò%+�Ç벨Úü
-Úʉ¦ËÐùªÌ	g§ÍÖl+€Xåí1ÏyÀl…‹—ìPÔ]ÃXÐ,O™U¬"Ëî+Á›¬Í›à䄉 "ºŽ’(HŸ9D´RÑ�3ÅS95âY(ª§eUo@Ä„ÿ£by™O5ÃÃЄVAiÌÄý>_�(³ø@è»ìK±ëv„­ºÝÊÊ`«  ~饚~Wünþ%Û•=
-€-*Æfë-a~벪us·9 $–d‘´HÒ±U€”X…ôó;v€ŽE»=ªò#
>ßÿíö_7B8kóàd“?f`ÚlT
�=Ô™ALBòéa8sÂD¤J&LsÞ„´¢„¼ôP]0!G55!çVgìÈ
-åd}h9[ç8Xˆÿg‹áD&Þ­‹Yã#ð–……2Pqò†�õD싉¦æÕ¾îóS‰ÖòâòžètýÑF•	ï�ÞªRme?ûCñBF
-µß›Èüdì6¬;ËçrÇ]Ö®·vÈÓÈôè¬C;ÍSˆ‹	T*d	UÓí1s™1m§Š	)o�f”2ˆBá¬êPmÖ´¶ß–kÈ3@!”ŽÉüq'�kü—Ó§
Vô2š‹rVVG%
-$°¯¨{(”‚M™PŽ…|Ì8Í£4X…O›|øhhV€ôF3#E#úÃYT%d>ÎeÎl,ŠÁQÄšÉÑRÎç�:)$�€\ôéCªóNÝSY«+ªå!„Da»ÄÔø+Ú&ä|³hKÝ^Oirº	\Fúò<Õ̆2SQ˜Š„Ñ&؈*,[964€2±%}•„°fƒ@åz:ˆiÈ`d¢!NÄØ`Vù6{)l¢Ôº3ø%Óxt
�{Àgôç^éÅ/¡	¡ìù­Ë¯L¥¹¦
:ª—
-Í⧦³5–­‰•>õ4”òвi
-…QÙÙ$`b*MØw
†w
Pæ=60p‚æd9«®%œ;5“9ï%\ võê_"`å&(tÁó>/mÓESf/Lç”f§Þ,g�hQ
ˆ¥­�«ÅÛÖÕ‹#{°õø‹«�™âÐSåUÛ\ˆ:*R½¥©Hskñäš·pÃÏjúµ²°44FB[bY–¥ë
-/LLnBêí„ðî NÅ“6ü.%$,{ŠÃKT3žd­=ꥠž„E2F-Oe½²ÆÅ®
-†õ@ 8èUÛŸ �Ì
-MB…f”­~Ÿ£‘ËÐuV
È6àbÛ‚Š-ßB‘LÐO~$`Õ=ây|´Ž)Ï€¬Û'¶Â@Š×6w×ô;våÃû×mO
&ÜgëgÏguy
u
-RŸ1[	ÂìýTuµì·ÚŽÝÜ+O9Ó�Uá$Us„̈s;¨›�”b60«ì£iâ&UÝ=m	±¢ñ3vpŒ‘€¤r„HèßÂjÚ’S_ÁÇCö´½¡áÓ"l„8
-JsØÑîÊA›É•}ËQÄÑî6jÏù¸¢å‹�Í(±i×¾%B
-E
-L’úÛ˜ìø'>eXFà­?d¹Ú±NíDÉîíó˜<÷ÌÒJ‰LÅZŠûvKŸ£À"íë¾XS‡ý¥¦}XÓù6—Ƕílɶçr3“úÛ››ñW*Õ�ÂËè‘lñúb�öŒÃƒ(”ÊguÉ
)÷9Ó¦Ûí]ÎNJâ Ò¡~+W„0„ìè>B
~™§FUÝçÚ^“+é‚1@|ó
PF?îâBy—†ØbL´)F…PÅ“9ÇÇKÌéËð$ô™Õ9ýC–,½ñQ—DB¸Ë6xñ0Ó7„L‡ñ[’ÂKòHø¤î•¦­wóÜÔ;ޯ͔ô¥”d
-3B5±€m¾~nè{@>£øÁà‘¿¬,]=ÛV;J'ßôZÒŒÆ^Ö
+xÚ½ZÝsã¶÷_¡·Ê3Ÿ$ñx¹ó¥N›»Ôv:ÓIò@I”ÅžD*"i�ï¯ïX€")Ú×if:ž1�ÅXì.öâ3†?>Óqaf‰Q‘f\ÏVû+6{ÄØWÜã,Ò¢�õýÃÕ›2™™ÈÄ"ž=lzk¥KS>{Xÿ:�#]c6÷éã‡Û~¹{{�¨ùÃí§�סÙüÃíßo¨õÃÝÛŸ~z{w½à©æów}ûóÃÍ
Å~�ïo?¾'ˆ¡Ï‹ÞÝ|¸¹»ùøîæú÷‡¯nº³ôÏË™´ùãê×ßÙl�cÿxÅ"iR=;¡Ã"nŒ˜í¯”–‘VRÈîêþêÝ‚½Q7uŠJ¤Q,ã­4küÛÊÔq1�Þ–A<Ò‰á/¯EóÖòMš1^j‘lŒž-âDE	“¢¯3Î#£µ°òM“H$)–‘2bñ~´vˆ&Ò±â�³HK¡°¸Åøt½ˆùü
ÿÅüBiˆbã°†§vãÙ31eŒ$œ^Û�ôÌ
xs»³÷Î3ëɯ»è-ìN‹žÂr!!%g±Ñ‘‘ÊБªJ”¤óbØåû¼lòµ”ôõZˆ–‰Æ'R±‰DjÒYŸ™N>Œ�
”uqÖ±?§=a¢4Mp£ˆLd:}íy”pƒ‰
+•̜õ‚O\ûË2±.OÙ®XÍó¢
+gÏ…„ª6¿¢oUúiVºÔê_x‡¨XµG‚—ÍxÓ°v²Äne™¸¹�{Wìr+èdûªuk¢íƒïjW­>S³þœŸ®�˜¿È#Ò•¾:qD>ZzUy1
+‘D‘\°/.DB×åRá
+[@òÁCëeÓÞa9­+ÊÅ1ß `Ø.lˆü±ß$Øa7ÇçKÜ
+)?Ù.@ü)Ðê•Œs�¶D…hgÙ6·f´æ ”@Y: Ëçn5öH;!ȯ{.~˜y½Ëž<^š[z½˜4¢EYÔ`KSë�“7MÈúàòò§�‚˜âxÆÊ˦~ÍíÈXžUMÆ*Ô,œl“…­{äø±Š¾Ž‡úÑåZæên20ÛéܵS‚‡›8æO^8¼ˆYä‰VÎö*+Õ�ž
+*N8°&mTbþ¸«–N»|¨+YÚùaÕcˆíœe�Ž+TP“ô� X‹ërlP7í’@Îúíý0®É.Û¦ŽÕ¥ü¾Á.¹5Hü{Ü
+µ�z躇•CWU°
+þ’rX¦$8¤Uòm¬«'Ö4˜'¼¢_•òàNÇöyÊA²HÅ»*#£m¨€^î¡S¸F<ÏØÖOmÁ‘£ˆ°63b´�wºZG‰§ZÖ*ŸDåùggæ¦ÈRq”0¥'ﻕ±ÿ4‘Ri`”f¾øØ�»ùD@‚�Tð\:°ÑN	‹‹C¬Å3ñh7ê؃ŠÑA_té¼JU*^wé}¬—]z‡åîøº¬íú€Ðãëeª&�„%ܼ¾}‡5±ÿð�£ZŠ!
÷yãžvB•�l
KÛ”u¡ƒœ™Z¿¼ÿ™ËvcoåÆ™'û`©w#.Ó°ÏþÉÍ—fñZôþŽçéô€{—­>w”ùà./žìC�S^¥lyuT‡ü§5ƒÞzÉžwS¬gá0 ¹ †££
+JB«Ý<ô«¶©‹uNh>
øhC
+¸qWñPŒòŒ×ðûeã\»Ý|ýï¶n€–¯IËÜe¤º�ϧòkòÁÉn�rG«MdYx
+ˆ°ÒUðšÁ«¢}†,š"<9 ïÔŽðuÄg
+´¯ÇØ„‘Ž5`®{´¥Ç_4–o§,«×Ç�¼\U-dî@ê‚öéaXÝùÒ= PÐiÆeé•Éü~Ÿíüˉ·˜h‘n»Å¿†Å½Ðü|Á=Áœk&L@þÅÕNCúÛ†ä7¼X=¼ûùš3Qtô®Ç†+RNyÖÕ-ÿô�Àο�SI$Ó—Ü‘HR[‘�({À$½tÀ,¶¤pIú
 endobj
-1783 0 obj <<
+1794 0 obj <<
 /Type /Page
-/Contents 1784 0 R
-/Resources 1782 0 R
+/Contents 1795 0 R
+/Resources 1793 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1787 0 R
-/Annots [ 1786 0 R ]
+/Parent 1798 0 R
+/Annots [ 1797 0 R ]
 >> endobj
-1786 0 obj <<
+1797 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [324.9335 139.6832 381.8296 151.7428]
+/Rect [286.8324 633.77 335.1613 645.8296]
 /Subtype /Link
-/A << /S /GoTo /D (zonefile_format) >>
+/A << /S /GoTo /D (dynamic_update) >>
 >> endobj
-1785 0 obj <<
-/D [1783 0 R /XYZ 56.6929 794.5015 null]
+1796 0 obj <<
+/D [1794 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1782 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R >>
+1793 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F62 1361 0 R /F21 938 0 R /F41 1218 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1791 0 obj <<
-/Length 3621      
+1801 0 obj <<
+/Length 4019      
 /Filter /FlateDecode
 >>
 stream
-xÚ­Zmsã¶þî_áo•gN,^	`ÒéÌåΗ8ÓøZÛí´Mò�–h‹ŠÔ‰”ç×w@¤DÙ×iç<Gpñ¶Xì>ûBñsÿø¹Õ“N�§2͸>_¬ÏØù#ô}wÆØy4Žúöîì�Ÿ¤9w™ËE~~÷0XËfÌZ~~·üiöáû÷½»¼¹˜Ífyv1×9›}{uý‘(Ž>_ºúîï7ï/ŒšÝ]}¾&òÍå§Ë›Ëë—sn5‡ù"¬pb§«¿\Rë»›÷?þøþæâ—»Î.ïÒY†çåLâA¾œýô;_±8c™tVŸ?Ã˸sâ|}¦´Ì´’2Rê³Û³¿¥½~ê”ü´´™¶ÂLPˆ�
-z«¢y,;’€à†
xБÅ=á5<ëöñ±\¢ãá�¨Ëò¡
-Ü­0–õÌù%ÖEÕ�2ªê®!˜XN*v"–É >KÑë)§|M0ž´I÷©e@95û�–i½Û×A,Ø
­=ÔÈ´@æÕÕº
-KµûaL²3ìL|"7±7ú?0Ìï@±¥°ÆÈf¨se`š4ëH¼ö´x9ˈ*E§¯>Gy�Ê@¡2VÂ’Œ•0^ÆHÈ¢à¨zÂeŒ¯q�¦¥ù»�’îÛÊ›­Ÿæ

­Ö›¶+Èû—©Ô„s
I8¤mf⡧‚
o­‹áûÉ8UúÆBšõjœ:u:NM£Îúêáe¾,ëâ(üä
-oÏÉ×wO£&¶]¨Ò™ƒˆp¼?yeé9à�¡¹XIÎÌ`T
-�ýÒ'gV�6öÏe™ºš%á,òGhy»€n:ÑÖe×�^»Mô¦@.è�à�ðkÝ�¡&ÀK"	g0êÀ%`ŽñTÆ|C3‚:x
ÌOL
-H0­,¢¹m= RbýÖõ绫Oÿ
-ÉÃþ ‡!K—r8:öÇe}‚¼`—ò¥žŒ§®ËäLª·_lŒŽ±D¥��áÎ=»j
„ÖCµ>´«:_Q’
-„Ês?«;<‡¿‹9\löí®ªûyÌõR@ìó?ÊoSªGG<æÄ.tf4dšIìÒî“RwÄSµôN{}†­UYov5
\VÅcÓ‚ã[Pçˆ$ô+Zj÷¸¢Ñ#p#	i÷épø®
-;-«®¸¯G+‡J
dØÒäcô‰UR™ÛÙΛ°
-¡)6’�¤Òà§áØNÌüpã+¡H_
ÂÌK&=qÿBáÍØ· †C
-ÂÕW
p8ê´¦QÈë
-Âʨ›#„xKrùúÆqÐÄÆ#ƒX[8u°3ažïYðo}$'+Ì•M
-4•|°"ˆ&$ö@�)­3Qãôg!àiÙ†^ýžÌ9Z]O/$ÿY–*F~Ä¢ß�s~‰ã»gàÍ£¼B´µ¥Ö¾ˆ+Ü[ðº%¬Ð:Në ¾}3åpÀy"²°1®Q
-ûßb
-ÚÐõíÕÇ`GÖðŒ1G!4­LŸ'àPˆPG5\ÐTî¨ÈÀ]¸j$œ@\„PÍ£2^}Ìn/oþqy3•¬è,wù8æÁ…OÅ<2Ó.9ñ¯CY\îdxcPÉ¿eó=Êâ’w$¶!¤& „”B$í§r	‘Çn&­á¹‡&|ЄM�×ð,è1
-Dþs�Ë6Äo®H©ÛE¬Ô?¹áOÜ Îwy¬Gí_\ø�‹?ÂUÓ—Û¦ìÿÖ! ˆPC`Rô%ùTÁVgøƒÊ	·ÏΣUþÏ¿ÛÜ×{Aù¤µb:~�,Ï,xàÈ
-ݸCÎÓ<�Yÿ×nžendstream
+xÚ¥Zmsܶþ®_¡�§ƒ‚ §�Î8Žœ(Ó8©­tÚIó�:R:Ö<ò|$-+¿¾»ØŽäñ$g:Öø@`	,ûòì‚òRÀ?y™šHè,¾´Y!Íåfw!.`ìûÉ4kO´S}{{ñÍ[m/³(KTry{?š+�DšÊËÛâ·Õ›^ÿr{ýþj­ŒX%ÑÕÚ$bõíÍ»ï¨'£Ÿ7?¿{{óý¯ï__Ùxu{óó;ê~ýöúýõ»7×Wk™	ï+žáÌooþ~M­ïß¿þé§×ï¯~¿ýñâú6ìe¼_)4näÓÅo¿‹Ë¶ýã…ˆt–šËGx‘Ì2u¹»ˆ�ŽL¬µï©/>\ü#L8u¯.É/6idTœ\®�Š2“êe)‹H�ÚÚƧTAÊJ.IÙS¡”wù—õPì×]õG9ß²Œ“8°—ãyOVTË«ÑòÒÈ(ž­þ¡ì»«µNŪߖØ�ÈPu?ÃŽž¯¿{÷�H~ýîjìÊ®ËJzðŒÏ6«¹�1ðˆ5ù®,˜lÌ”Ž#›*ÉT�U]ó¬eSÐúÈLCÍ»§¾ì@�¬�«^ej•×UAôŸóz(;\àr­RÅÖ�„C3´Õüp%Ó2�Ä+#6̪o©#YB­ÿ#x6÷Ü}W%“o+î>äÍOÆ\CëŽÉºª.›¾~¢Þ¼øïÐõe
3Kà>1zu»åw‹ò>êžܲԤeŒã+rÛ~;d�4ƒ4«¡òšš´Ã¼kz¾oÔèʾ¯š‡…c’ÊF©å‹Ú8;­œˆ
Á±“ÌžÓOÓ6ëãv Ãošn;Ò„WJ¦!�ÂIšî±<ÌÈöyÇg*38S�¨é™ö[·åvxØ‚ïzuGÏËŸñ0…"©<æuÝQ¿Í{&¯ÛÍGjÞò‡h©{sŸo>:ãÀÁ¼)¾AYNÞ‰‰y웧*‡Ä|:}y˜ž§ßJÞ�ÿsº‰
¯îZ
+8n!ö†ß¦(÷`%À3u´÷ôë,yñ¹<ôUç¶ÏÄÀ¦¬>3ÁÝp�]÷å�žQõtDe`P|ìeÑt/(‰´“λ#uŽ¤JÀOIŒ2™w@N3™s¿9T
+‰Ž¥Óç™T\L¢B’F‰
+ðüfŠÆî,žøl¡#�­÷Âå—~Á
+•Ž2„IDôŠL0VI$ÍŒ=Ïã¶Ú€ûÔ1Gø¥ÓŽ!pôàúÈ�<ËQÀ�ò({ú��Ýç(ßWº ã˦Ü÷DH‘]�.©‰šÒ1mÕP߈æa"cSâáI¡Ø}¼:ä�‚’6Ê´J™ã38ë·inìY†Ô$½wã–÷ÂÒZF©Êä§d#mïY�éŸöÕ‚Ö=–_À$]trƒ-ýÞ1ñCÙ”‡œ‡-D&Ûžƒf&aÜA³5ûh
+Nç‚�	2„ž~ŸÚuîBú’T3ð•Âx
v{]; °¬íi’fcÚÎÛNyX2K;
+´Tc
£3É*ßï�MCyEcÏH 3Q’*õ¬÷R�Ó¥&�ï?Ñ2âô»Ð5¯N=¥¡#Äsèu®î,;ÒjúÏóÃL@DKÞñrG§Eò±¹ :vë�U�º¦�(mW]NÊ›’ô©³.?—5õæ��LÞh¦ !²r{Î?Ê8J´Ê¾ÂÊá·ºi\á
€(a\‡„ëôÑxÝUûrÇÞ$Åì¬{ŽŸµŠ-º>;Õ¬3PqÆeêB =f#2g”–P!
++	ùõÐÓèÆå"ÐpV
¿-
+ÅÚ™+œáC3ìî8ׇl8H +žè4ßÌ'æá£Ôº:˜§ð]¶;
–
“C#ož¨ñ
+¥.·Uð w6…ïÇäes<“I`šÝ–!!´iRðC2êÚºBŽDKqŠ-ÔÖÊ1"
f<‘srðKš.rÁ¯çÐlò91é6ª0Ä+÷ùÇ’ÙugøëÚúsy¦"çD%ÝBN–jusO]ì{¥·òQNŽ¶˜Sö#G.'²%,Š¦™¦ÓälYéâlV7ÇÀ4‡]éWËù¬+ÞHÅ<e^³EH±\µ�”Ü¥Æ6–wYbû¶ñž*	y”e…�.fº¼ýQÿÄöt8z‡�­æÓÉÛÑÑëp^¸º_ñ¾'/‘Ì-yöW‹Õ„¢YÆœÆB
+‰Ð¹÷£>üí]˜[� e¾�ÍXFæ*|iЬ?#^)¢D5ºVùZKcEc$ãX¥$ãXY'cìÉ@°W=•ŽeŒ�~‚¦¥÷‡½vݵÊ›\Ü¢÷ó†H«Ý¾u—Žx©pb4�Ô,<–ñ›^€nÓL�«9K0UxE$éó0uLu¦*rg}uÿ´.Ê::½wÅÓËô󫪅å'›(@8]Ÿ‚²é8��~¡¹¤\±J
×.7Kñj±,Ë0Ôäç`N¡åì†ioÔÇwµ�P4…îœ~Ðy£ûM³1C%ÀCå‹°{¬K†pBù»$Dš†1�žùEƒ	x³ÊÜ›ÛÁ9TÊk|Üz÷óíÍÛsîpÜȱt!…»÷5Ç0­Ëo§7gÀYOÆS×ÏÖ%5Äbk�‡v
+�õX­ç6ì™û(‚xBSø�„Làïj
xK¬¾ªº_ûT/àa—þQz2=Úâ)/ v…æ9¾0N�sá�:•îÛÏUQòw
+‚ú¾+‡¢]÷í~íJ>ë¢Å°¸X€WQb¬qwUS,à••Þ
9–Î×…°ÔÎöͯþ°0#z…4d9.YÂÛðÑœpâ~ÏX®
+EÜ^~è©åd…Ãô8<Q5Eë³÷jÞåÉÌFKëÏ_«…Ï„Æô§žìdÖÉ¥š’™ÓbeNý©Ž²X¨	;þ”©^àât¶Q:	<8/¿£<ujÕ Û4yá�*•ÊgȾæ
ÓRÒƒ)*ù,Ž‡´Gcœ‡d#_
+\ó,Â[çXT"�â$8ž›wK8
ü…�½æþ%,LêäÓ`Œ*á2
<Ôí]îÓiîMËY¡-¸šAmGÝàD�Y¬°.!¼ð
+%pÀíãY�+kh±FŽ+¸96¸FŽk‘(3‡k:n:ë
£Š
⹬
úžÚ�÷¥+g¾bs4”€eto†¿EÕåwõdf®Ó@~­í,Î�o*‡®œÝO!áýä]‰ß*djåÈíŠî=ÍjKŸ�ß&½pþ*Æ“I_r5ðO¨<°SÀ™ŸhÑ“oÕ8¤€ý9ß²–_öuµ©ønÖ¿gÈç@Ï9µ\«ÄD/T'óŒ'”2ƒ!ªCØØlC ÷�z\ˆYB‚x¡ª´x¡`9¦:�•“[	XµmNœ@–T¨øù…ÕÂÊSkÕ 9m§K3æJî¡÷½Á±í+Ðæk÷öÐóÛUN
þñ�MŽætE“…Û6Èù
„¯KÄOt&jZü˜T˜P}pë'
 endobj
-1790 0 obj <<
+1800 0 obj <<
 /Type /Page
-/Contents 1791 0 R
-/Resources 1789 0 R
+/Contents 1801 0 R
+/Resources 1799 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1787 0 R
-/Annots [ 1794 0 R ]
+/Parent 1798 0 R
+/Annots [ 1803 0 R 1805 0 R ]
 >> endobj
-1794 0 obj <<
+1803 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [84.0431 392.8958 144.9365 404.9555]
+/Rect [353.2799 641.7836 410.176 653.8433]
 /Subtype /Link
-/A << /S /GoTo /D (view_statement_grammar) >>
->> endobj
-1792 0 obj <<
-/D [1790 0 R /XYZ 85.0394 794.5015 null]
+/A << /S /GoTo /D (zonefile_format) >>
 >> endobj
-526 0 obj <<
-/D [1790 0 R /XYZ 85.0394 462.0446 null]
+1805 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [84.0431 193.3347 144.9365 205.3944]
+/Subtype /Link
+/A << /S /GoTo /D (view_statement_grammar) >>
 >> endobj
-1793 0 obj <<
-/D [1790 0 R /XYZ 85.0394 438.9195 null]
+1802 0 obj <<
+/D [1800 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-530 0 obj <<
-/D [1790 0 R /XYZ 85.0394 121.3391 null]
+534 0 obj <<
+/D [1800 0 R /XYZ 85.0394 261.5013 null]
 >> endobj
-1795 0 obj <<
-/D [1790 0 R /XYZ 85.0394 93.113 null]
+1804 0 obj <<
+/D [1800 0 R /XYZ 85.0394 238.9605 null]
 >> endobj
-1789 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F11 1441 0 R /F41 1208 0 R >>
+1799 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F11 1451 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1799 0 obj <<
-/Length 1773      
+1810 0 obj <<
+/Length 2395      
 /Filter /FlateDecode
 >>
 stream
-xÚ½š]oÛ6†ïý+|é
-¨4‰û–÷,}¢”/ótmô„m³Í�l³­äèå!_>Øþeiºms÷�m3Û,ÒÇlû”.³zƒM5`¶{Þvýìïëï'Ó™]²k·Oe±µ˜±J»!óûs¶É³­9,‚ÊÑ´°�§t³Ë—ãªèÆ|ÌÑJñ½Æó:ÝTÇè�Iêv¨$jv:QU¯í³;Q9fvÍ�ƒ	Ü—õ&éjUïñ¶Y·ï(m`~{e»™fIMoú$Ó¢îK‹•í«Wª‘ŠEl%‹G‹‡ìÕg•®·¥Ý</–ëçUÖØÙÆ¡‡éh<ªEUk˜þéÝ�ȶÖår˜«]jÝlÇ'ªè~ýúµNl·ù×"[™ìMu,)/¾uÆìÔëÍ¡“½bíΛ‹¨É´Öeùô%]~³K‡»UuìKgžMŸ‹oEùRmItBdÌl9g¦:ÕP\Œ^òõÚ¶ÒÝ.{|ÚÙ…ý©h^WÙ.Û<æEfóûêÕÔÃ.~yÎ×»q^Ø¥KKן®^mGöO¾Ýmm{(ª±êåt¹ËÔV…·çiµy½‹_^ æX¾¤ûÀj\kïù2yñÕe•-͵‘îò²¨c§¤uL«(w¶±¬%v™ËÚתJ¯¶Y+›V^¸C“ºÍÓmÖ©¾=ðwô–Ï‹(êMÖ¦J¶UÞ{Yõ‰�o=5áF¦a&H¾ÁÀÔ~~dÌ�13Óbƪöúeq›ñXÂÃP:†LÊ	#Jku5út6ž\_ÏÉd~w¡ùhrRÜL"š›½‹ƒT@Ü¥Pñ´ïBýâÊ"Âb~¾<ÓD*• ò �w)T>må»P¿<„²¸Ÿ<¥D'2BäA* ïR¨|ÚÊw¡~y53Ey•p¢˜@(aê´|“ÂäƒÐFþê•?€š³ —|$	•\ ò �w)T>må»P¿<„rÚO^*¢ª;zX¤ò.…ʇ ­|ê—‡PÎúÉs3G æ.ÐÞGP瓬Vø€å·mXœ÷S¥	‰x‚Ìí0v)Ô9mµ»P¿9„rÑK^jsQ¨8ËÃÔiù&…É¡�üÔ+
-•A[ù.Ô/¡¼ßóœ’ÄR"s;Lä]
-•A[ù.Ô/¡¼ßóœ4¿<Æ|
-¨×!Ô<@lÅ;D¿7 ò~OrBÇ$¡yS§Å›f„6êGP¯û
”÷{’±&BPdž‡©€¼K¡ò!h+ß…úå!Tô{’%‰ÒÈ<S
y—BåCÐV¾õËC¨è÷$'$'"I$"R
y—BåCÐV¾õËC(‹ÌE¯{Ø›ç!mʅ؃TÀÞ¥Pû´µïBýözþ§5‚*"e„<ÂÃTÀÛ¥Pï´õîBýÞÊÌî\sžDDÇ™æaê´y“ẪÐÆüê5?€rei#}¾½¹>È<S
{—BíCÐÖ¾õÛC('´×ÕÎ%Tpä“*˜
-Ø»j‚¶ö]¨ßB¥D™É^'çÀÜTÄ�ɦp)´
-õA[ÿ.Ôï¡\)ÿÏ­ÓÒ@52ùÃÔé*4)¬
-AhS…#¨·
-PsEüÔßô.Â+fv�ɹiÀT b.…V,m+Ö…ú+¡ìÿ¨˜ŠIGȧf0¨˜K¡AÛŠu¡þŠAhB.Éuu³Ùûóó* ´™›r³�©@\
-­@ÚV õW
+xÚ¥šÛr㸆ïýº‹\5Â'’H®¼c{¢­Œ<k+©­ìì-Ñ6kdR+Rã(OŸ !G•Úš"
+†¨í`H0×Ô™kNa)”£v€vÑOY•ùßL'w�N™RÓg]ÔÙãfHϸâ$Q|¾EâU^×8^Øœ-6<q¡Ð
{¸Y)I(�'I$I"ÒäÄæB£™k…{‹ú§µÒ£Ã¹Ö#œ롺Š‰¢4	«[#�º;q4¢$UüXwešLç×øllƒ–_ªýf�åv¨ù¶Ú5X{ÉK÷Í*/¾ã4CS†�®*”¯óvÿ~�"f[ô
Z<̯Í!‚½,‡KJéôƒÞPÉ´ÚYÏíŠ38ÕŠËãÇN3ªh»ÎT™uÖ
íkw•p—&…Ð!©Ý‰ókòpsÿ/ˆ|ï÷Ÿ”°ˆ±4–oEó‚Ž›Ã6÷ìq
¡I%‰1_þ¶ô¸„c Ðäº[m²ºöøc‰ÞáÜC€¾{ðxä	‰Yjqº\âD}Ò­]Òopº¨‰@ºÅF œíX&Tw¾ðzÑ
‚G¬�KúÙÇ%]3qIµwýÌðáD¢£·6éJ‰ZÇæÙG"´ï"‘®b$Ò¥>‰x$
Båñ™„°’œG‚À¦}ŽÚ>ÃÀ£ÛZJeΙ.ô£L$�’QØL©ÝKžAÚꨂ}±ÇnÛÍ»¬²}íÛ·3žrÂâ˜ÏŒö¾öm8
1HØ=Üî%¦ÚµÊ–V81^7g5¶šûU7éûU7™Ü¿¶�úû5înݾΟ²ý¦ñÝ7‚!•ðNà{&
é	Wö¾Ó8òÚ <z³x2¡C¤Ý©ôùƒƒQ
ÓÏ	sÑåo4&4�#E��í‹M3+J¼¹n^·Í
‹ÿÝÚ#Û›IÅ1ýE»ˆ3.ùô¥])¦uÕ.
+4=vÞu-GïÚä¿­÷¶U¯ÄÃݶg¥q¶xÀ§¹ªö¹6U¹9èŃåŠY»\µÌÐ+O:ÀÔš—¬1£Ä‹è(»±S¾{5Ù	¤�9>16´î×ز©VÖLâÈu«Mž Ø§\Pé.>(—Us켆0‡¥6#xyBülò]™71~0X&¨éÀÙšÞ¸žt
ôÑ·ãªÈà°2Î�¼Œ‹nÌоªðRåíIkÓI(ê#So³Un:à<4û]‰ï¿]ß}¾š/°†oëmUÖØ�#®Ï>ZñH
+b@ûüË÷KíÆ4CêÙ°A7gã‚Ü(Ïe¾Öêƒ^éz*ÊoŸƒùúà[©.6ž ´©ªíc¶ú†µãaé†vêÜ,ºïº/¿•Õ[ù®'é¤á•¦n<bŒ›‹I—²¦Ñ±+íN„ç:‡sõZ”9V�Å3Ѧ™Ì�\º¦ˆqµAõl}À†ü?EÝÔXnWBû2uH.Šï¦£žwܦ6‚0¼¡QXÊ7Œ`뙎q¾©ulº/�u)Þ.Ó7˜IwÝ5ó
+íᇢ~xWÅ9ð<U$rÞµ:
ßY�ÁE;øw¢^ø#Qø.?^�œ%cðŽU
+À[«Qø�h?õû¢ð™z<HH™Çà«
+íᇢ~xW”�—á1°)ƒw¬ðÖj>$ÚÃEýð®(;/Ãc‘""†ïÚ0¼c€·V£ð!Ñ~(ê‡wEÙyU”‘ŒÀ»V§á;«1ø hÿNÔ$ÊÏËðh‰`jÞ±
+À[«Qø�h?õû¢ü¼�JI¥tÞ±
+À[«Qø�h?õû¢4†C¯Î ç	áŠ�Ñ;V
zk5Jí釢~zWôÇÅ¡ðÈ9ÆíX¸­Õ(wH´çŠú¹]Q
+aÿ‡É#J¸ùÇ1
+p£Qì€bO=PôC;ŠLBJ«æN9á\…±{›ÓÔÆf: ×1ä¼ÈŽ#ÑYg;–„³‘ÞÛœ&66cÄ
¹Žx ç%vähA"Ðé¿VáÏ¥àŸùáþÿþ³4ç×>ˆ>izâzbIŠÙ˜”FJ£÷‡dþ~íýÐÿ†.„endstream
 endobj
-1798 0 obj <<
+1809 0 obj <<
 /Type /Page
-/Contents 1799 0 R
-/Resources 1797 0 R
+/Contents 1810 0 R
+/Resources 1808 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1787 0 R
+/Parent 1798 0 R
 >> endobj
-1800 0 obj <<
-/D [1798 0 R /XYZ 56.6929 794.5015 null]
+1811 0 obj <<
+/D [1809 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1797 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F14 956 0 R >>
+538 0 obj <<
+/D [1809 0 R /XYZ 56.6929 630.4083 null]
+>> endobj
+1812 0 obj <<
+/D [1809 0 R /XYZ 56.6929 602.8709 null]
+>> endobj
+1808 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R /F14 964 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1803 0 obj <<
-/Length 3228      
+1815 0 obj <<
+/Length 2674      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥]sÛ6òÝ¿BÓ—£f" ’¸{J§uçêÜ9¾éCÛŠ¢lÎQ¤"RvÜ_»Ø	J”“¹Lf¢åb
,û
Ë…€r‘éP(/R‡ZH½(vWbñ
-Á$|Tã_'|—2èªæ�¾èH³Ù•UK@òæ¡d¸À;±£B8uyƒ×—Ž;u�í±fš¼&š|ƒzbtð˜?ñf4
-÷UPXôAª@“ïJÆU
ýÂÒ�›³‡‹Î‹²CKUð±%<qìOÚ‚tÜôœ¡./Ö�‹*¯g˜x.}þš²ÜXÕÀ5Ú¹[³µlÊ}ݾ8ômñ1oëS}ËB‰¾°iµ9OÉŸsÆynÍŸuIŒ0Ä'/…³D$¡Ò_Ïd£ãùx§Ï ¢¥`ï×¢yÖb�fœ.5æ
:ŠÂ4M"?ì
2Þ.¸
-”‡NÒÐÈŒŽtoï9Í‚CIŠi‚}~(›ž°pÅè’‚§e1Š´5¶K@‘Ù˜ÑF²à¯¥
Ý%“
Þ¨¬#^FèÕi0¯k\ä"7ŸŽÍ¦<xÁm
œfÚŸ›‘O€Í^èkz
-$D#Nâàýp�ÌÅT
-é`¢¾}›e¢Ð&1‹Õ˜¶~›ßXÅ`R-VQ¦ñx^HˆPè‰ñHÚσåL<Pá
Q^AŽðTB2ŽÃLÆÉÂ_÷l÷�jfû‰ùÆ&L�6Óý?b‚¸Å�©LðlÃ
BÌ�…1¬ñ¸U"„(RŒWŽ¿—
 :Ô`\AÌÇoý¡¢µ¿<hã'¬ÚÚü‹"Ð HŸPµWÊ„8·©7C"Xqò饼o†PÔœ%\ÿo<�·	@.<Bî²9O|ß±í0Qò¥ð¨^Q
-G5*EÑ6=fgZaÂ(úÒöÕÌþ­€ÑHœ20hú Ò
-t8Ž#‹f±
šÅ–ŃZ ì{ÅøD-pȪÅ84ªRZ•�…€N-b¨ÇœZ€úG‰Š¿E-þˆÀ¼ñ¿ÿO
Àƒ(¥¾¤Õ+jà¨F5°g^¡×®Ë3]H“Ј8~�‡�j†‰‰.d2Ì2�N¹¸nÆjÌQ“-wÒrå*<Œ‘/~xq©æ6?Öý(}Æç~JHç¼,l<&‘É^¶OuYØÕ…BïLØ:Œb‘¼ÎÃ@5ÃÄTØTš)ïÁ*¬6ÕSµ9Úd¾‡_Žò1Épž|m— áe¼æ�
-q;W¹AEXÀC}5<}R5Ö”8­R`7Õfš_LÛp};` ÚÅ{µ+)»?¹
§F$($
N=¥Õ°&“PfË•Pc¿Ýl*ì*ä¬_Ë¢'±·–�XÓ�×à�E°Š‚P1$¨*ÖX£Ë©8†ÇËá`
ËÙê9Á̲k‰¤
-¨j·§Úê‰�Ò;
-.º÷mÓñdb[ò£+º¸HÆ¡�ºLnªÎ¢¤¤Ùöh²¡}	ƒÚa²à7ò�0†²õn#£øpFÁ·aG�²#�Í™]oúq‘C¸S#2ç5G±ØíÛC¿*Žýl
-3Ñ(åX€×=faÃ¥ýðAa€8 â¼éžKÆÞÝ…ܶ}é6Éû•
-C»ËòªÛq:$ 
-˜›NšŽÜpózÑìp©5êEÄÆ5ÓH‰ê¼?méÒ»Û�®IçÊw.þ��•ðX†dagB|CV©ñ,ÏW·¼imÇÐÔöÁñGl|LzŸšS½G‚õ@Aí½â÷B‹òsQîû“©ww]Ùó&œppK±1àôË}®Q¯ÔàC¬ÏE-+	½.ëö8�v 
ÖǞحž˜4ŽpCöÔ¤C&í,»ºha
õƒò¦¯_–RÊ€{·7¼WÅ=`(rûª8Öù
èfŠD(î`Ç-žä©t)_ÉÙëà—¦Eßq²çŠÕ†¿�=ØhÕçn=jù\ÎÕ+×Ú±ëreØ‘äµ¹)¨MY—¹k.g®×‡C–hæ’ê#ë-Üõ¬BÚFd�÷OŸÖß"zÝç“°Þ KŸ«ÝqG“+A„wŸ;ÒA@Ž1üšÄŸT“îÀE’!hg 2± ×�1¾Éi|›WÉÕöÐîV—üŽq˜ÄÊÅ"jž†µ(L¤q¾©iç–ѡ֙ﾔÑC¿ƒÃo¬¿�•mk[ù'F ,Ž"¶B2Öj+³œ}P·Û9ƒÃKLúE« .4³G1Úzª "&"Ò'¹Ì`&/ùIÒùIHÕX-z ÿé:¯yŸÏ*燆ŸfÚõSÕ»ñµgóÆž?¸á9!I%BGê+¢P¤DäG!•8Kć(þ¥»út¬Ø-vw´±¡vÌ.1DÁ7¿B‘½«d|jòb|YÎøUj”ÅJ&*”éx9®ËxÄ#I>‘©D¸g€³X
-2yÊùðGAç¬ÿêàendstream
+xÚ½]sÛ6òÝ¿BÓ—R3B	Þ=9±�s§ur²;÷Ðô�– ˜3©ˆ”]÷×ß. A‰¢’ËÌMçNËÅû�ý„Ã'!üÇ'J²Pdñ$Íb&C.'‹ÍE8ùk.¸¥™9¢™Oõîáâí�H'Ë’(™<¬¼³•â“‡åÁû]~z¸žOg‘ƒ„Mg2	ƒw·wW„ÉèçýÇ»›Û¿Ï/§i<Ü~¼#ôüúæz~}÷þz:ãJrØÙNl¸¹ýõš óËß~»œOÿ|øåâú¡ÕÅ×—‡ùzñÇŸád	jÿr2‘)9y���ñ,‹&›‹X
+&c!f}qñïö@oÕl²_K31S	œ1ne™±DD¢µ2�=+g
+v{7»¼ºš³Ëù§i—'ís°SrÆ
+»âTç;û�‘Š¿%^8�†Þú-"ym¡—¢y"h“—¯}݃ØN˜Gm4 Š¥ö9ÈS:åj—×Ínª‚ý¢Ù·–rÈK;4}�_
PæmqEI¿ptíöl§<ȺÆøJEp_ž$ö7­À:n{n¡:_ìL/Š|= Ä‹öå+µ^×À3ª¾rÔ£=ÚPYêíºzuQi²#âS^–&¡úa…}µqUåvKþ’[œ—Óü]§ÌKVvªDÆÔ—(VßôòÁ#–e2~ù
+€,¢ç…sש
+všœ3¶ùN—
aáš1-ÏÓŠy¬
+VS@Qèd]œ¨àï©©ÝÚ’µ¨L&žF˜Öi1_¯	p¥ˆÜ~ZØ—K½#ð(Ì)ZI•ô÷*ÊÀ앾úZ !r7­"ÊU
+r
+±/ÖÍÌ$ÕzOâšHct2à¥hÍUöíRo,T¹›ÄP…(
J‡0}À”CÔ¯ë>ýRë­3tQv'`§u+ŸïÎq–²D$bâ‡Ò�E'F›Ì’l2ë9,wÌ yU\˜.6âB
7ì0èK…UŸ§Lå½Lò�gç–
+oˆJ†G�{3Å¡×öÏ=nÜÕ
+Ÿê´S´T�S,ª²ÁnàÈ+2EçØ·Tü{^!Á±ÃC
Z¯ÀD^�	ÇIdÐÖl€¶fSq뻄e³b|à¸dÜ¢[êÜ©µRÝä s‹2çàþQsð¸ÅçÂÿïs! ìžz½kÝÀ£qGÕ¹�Ñy†Y{­�|!M`¸ŽãqZª
!z¾ 8SJ¦})®ËnsSToFË�µÜE¹k$Ô‹w¯®Ý\åûuÓYßâs¿-$=GŒFLI‘œ1¶G5blGubÒ;2¶dQujT†–j@ˆ¾±CPžõ¥¸j
+p&XÏÅroš	øng|ÞÙ7ŒÉ¾€óìkž	J{Œ÷zÀÛIÜì®ANð0£ÀOŸ4ŽÃ†Gjœf)ˆ›Ê¬ß?õßàú6 @±m§÷b£©Ã?¸�îQHÄŒAý1þÕ”'Œ«éŒ‡0d_.—>+äÖ¿îõ¢!
ñ/±ùâ	çºã!z ˜„{�7
ªˆ%Ωíq"Ž¡ÆÙãpq
Ç™	:Áβ®ˆd
¾
ª+ÀÈ)aûöÜl�%‚š•¦™%³ç›‘*‰KQ6zgŲ’ЂR
Ul¶4_=[UGaïmUÖv	:±åÑ™}ã1Cèä{	&Ï…¦¦Ù<Ò¨ö�Ý€ÉÐ;2ü‡2$¬¡íÀ=ÚÛPag>ܱ°·aV�²&І³mt=ôã*Gè´FdnÏìÌbØ=U»f¶Ø7C}¼éD£ÔÖ
+leó”I:³ÂÒFãh^ÔÛ…)Äö¦½WGûâæýË›pémÔ«ˆ¥{M#'ZçÍáS@Û.]ÝÝ»W:'P;ÂÛ€}i,Ü�!æµ—šL?�Ešy‘绎€[^VæÕÐôôƒëOøøE0ù}šú=:œjî¿?‡2Ô-ô¶9Ø:Ÿ×º±LlÃa߸„
Ü~b`ìù•hsˆÉ¹èešÐ�z]½€Ü,¤Á㾡›VBWì‹ìaH#†BÚE,>ëb„})éM(/›õë”sØÇÛ[Ë«°�À0ä6Åb¿Îw@wâµEH†ÿîc  …í³Æÿ”îõ$†	D©_aÂT”¥N(ó§5~(¹ŠI¥¢ÿ=µ—áendstream
 endobj
-1802 0 obj <<
+1814 0 obj <<
 /Type /Page
-/Contents 1803 0 R
-/Resources 1801 0 R
+/Contents 1815 0 R
+/Resources 1813 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1787 0 R
+/Parent 1798 0 R
 >> endobj
-1804 0 obj <<
-/D [1802 0 R /XYZ 85.0394 794.5015 null]
+1816 0 obj <<
+/D [1814 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-534 0 obj <<
-/D [1802 0 R /XYZ 85.0394 349.7668 null]
+542 0 obj <<
+/D [1814 0 R /XYZ 85.0394 172.192 null]
 >> endobj
-1271 0 obj <<
-/D [1802 0 R /XYZ 85.0394 323.7864 null]
+1281 0 obj <<
+/D [1814 0 R /XYZ 85.0394 146.9642 null]
 >> endobj
-1801 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F41 1208 0 R /F62 1351 0 R /F21 930 0 R >>
-/XObject << /Im2 1340 0 R >>
+1813 0 obj <<
+/Font << /F37 1026 0 R /F14 964 0 R /F22 961 0 R /F41 1218 0 R /F62 1361 0 R /F21 938 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1807 0 obj <<
-/Length 3609      
+1819 0 obj <<
+/Length 3877      
 /Filter /FlateDecode
 >>
 stream
-xÚ­Z[wÛ6~÷¯ÐéKås"7‚d³—ã¶N×Ý$í:îîCÛJ¤ln(R)Ëîžýï;ƒ
(P¢ìlû
â2Ìå›�Ąÿ˜D†™T¦“8Õ,â"š,Vg|rß¾;nÌÌš…£¾¾9{ùZÅ“”¥FšÉÍ2X+a<IÄä&ÿyj˜dç°Ÿ~óû×Wßýt}qëéÍÕïÎg2âÓ×Wo.©öÝõÅÛ·×ç3‘DbúÍß.~¼¹¼¦OÆ­ñõÕ»o©'¥âÄ¢×—¯/¯/ß}syþëÍ÷g—7ýYÂó
-®ð ¿�ýü+ŸäpìïÏ8SiMvÐàL¤©œ¬Ît¤X¤•ò=ÕÙû³ô_íÔQþ	Τ2r„�RŒ10J™QRYn6mÑÍšM^lð00ESt„NØÇ"—x:½¹+ÎgJ˜i±<ÉtY,:lÇÓfIýÝ]ÙRO{×l«œzçnÖª¬›
òó´•šÞ5»â¾{Ú²^´@VÓ¤ëk “ªeMŸ:OF–çeW6uVQ»‚ éF=®gx°ÉÌŸe&K£HÚ#•‹¬ªa(òk_[4u—•uK­ŒŠvC©ZoWs ˜f-©
-©ò�xVçÔ°ÄB¹Êj¿vÖndÙ}ÜÆe}[~X^¼.¾»+wö�|x:Ü‹$Ö2+Àz¸3¸mX”zòéÁZÝtTYe]‡ç³õíâŽõ‹',æqb¿ñK.›ªjvýz¥[-£¢Ý®VÙæÑí¾tåoÈ
´UÖ¹#¶q¢J¯1ã,Éb¶È@À±ÈÊ”%q¼ÙC
,ÂLLb˜ŠÄ	…¢1³`ÐiuòƒöTÍŠ:›WÅáÖB‚K-žÜ»t¼yxJ!#¦x¤»_-Gø–2a"ãØñW}Ì2¡Yª•gÙw}�VÙ{ôZ…
<æÑ…Ó©s†ŠÇ÷â‘Ël[9ɺϪmÑO¹e#X"têh©›1rƒšzö†£ˆÐ÷§ox?è‰vƒ‚^TEVfe
š§:ºlýÄòI2úAÇtK¦Xÿ�â¯Láb6÷VY¡¾+ÑDa�”jÕÜûQ]†6D*º<×[Ôݦ,Z¼r°»s09}°
eæÊ7×?Ñä`LVÝ6›²»[½ ›r«$š 4í�£Í®£�6�sõèö%K¤ð3Á›l»¢¡“©sM|À^èÀX
…Né=œsµ¤¯ÖÁàg0?¶ƒ#[¤F!´í5Í&/4ÊÓJg*E¡ôg'}t·�ön±ØZwZZ¹`Bh󌸣ž�W?Ê2({˜9ö¶åï#F)e±Lž! 5BÁàr”‘�@€�+¤¥\mWÔÈVͶî¨NN€Än©NÞ
¤ò±#‡©ìÍ`¹mÝ‚Ëfã¾ø-¼6
-u/2šä‹ª+rÚ~«Û[j¶my_T�n‘Æï•u{Ú˜€„Ò’€#„3ÜÒû}1-E‘;®§W5ugTìé”@gwG½+P³rmm´îËbgÍ	Œqá–Ùz]•Ä\p�mÀíÓ$)ô÷÷\•x	#Ùì<ì|žÊé“îÇû-E€ËÒYaÞŽ™�˜¥J`Å�öÍD ßpP�¾ò´�P„
l�çR
-‘fœ~LÌ*Yš`T8±Îúgá’ÖWè
a"Ž¢ýÎä®:ŠeDBìfŒŸ‘H¿âsD‚ë5ڀȪl»±Ð#b©T™X±v5ŠÀGz›“õãÌ	9ÜøÌ]Ö(ZÚc¦ŠB*ôr`d®PÄîd?
KZY‘ð¡@û›wo/©jEÊo÷]Ç�VâTBå€IYUf-V¨«ÎVm�ZU²‚YµŒ÷“‚�íÜ�qì½è”ívÞve·¥XÑðéoÛ—¦ßÒˆincÃÉ£w"§Ç†“�Y�2þ0ë¤"™°jê#OÜæ„
-¸{¨þšcÚ!U­Ä?R²ú÷+ÎÂ%�Õ_c¬™&b¿óSê3¥^ý‹ªX�Ÿomj1±QFÀÐâD2iô¨ûÀgȨ.>1%…©Ž=”Š€èe‘S‡…pÇrƒÓ½°#"\w³å`ÀÈN�bŸ8PjÄdØÍî‹Ù…ò‹½N¤ Ök$6’ÑÄhG¬Í½Áô¹ãŸ”pÌH„›ÙéµÆAKGÊmF¤Täèµ$ÍÔ.jÀŽ=:ÂD‚xhD<™¾)?»²-^Ðœòp®7^PujZḙ̀¸W‘ýþއð2ôè`9ü…D}¤hÉ"eô2)²O™¼
-Àðkñ�­ 
-pôhIí`Ë.øŽfÆŽ9‡x `‹få|…qÌ‚±Å¸úÐV1ƒsÊáÕÿç͹íÅöX×f~ˆËx’ÛßívÌ�
-7
Óqtæd•T
ó[š�¹õ®~tí0)†PPhÓdúØl7TkvžŽ¢Û5›®×Ó[�áW”#ü1î—Ç^Z{íò6ån�ŒH\‚ŒùÉ彟]Ì©oNçܵ>‘Þ¸•ÚŦ\»Œø‚~Œà’ïu�}§NOA¯hº­{Q¹(—�}Ø'A/³ýS8÷Ï<Ú‹‡mYy‡òÖ¾8qmÁš�M‚�–®­4SÞ{ë&wKRz©gôTÍ¢æoÅ®HOÜ1 þ²£þ¹[Éfv-€;fM?�)wd¢ba«�Óm00²ïh`Š‚>ØSce�­ñÈvê}VVöQœš•w]·þêåËu³é²Še‹#‹{ûrQv™Mh-–«¿–ùŸ…;¯#fË4!ã.Ä
²¤íO‡Ê ñ7

-kx±20¼ØQºåHìd²KXí�úWÛ®‡¤�@ØžÐY«ã¨¶)çÀ鲃ùÅè£ÓPy‚wbì´`à(²ö>#.4ôïØS•úŸ]•OË)ª'g$»p1”/ñ|JÁ:kÿ…ÿx¦�g&I¦ïÝíÂÑíSœr�sôÝ«þÍç÷¨süý
-t{vg¸«©¿AÀ&mK9xÇAÆ/Ü}˜¥„Ž?`üsûØÕÃÑC”?ösN±šRc¿ŒàOÌ'ÿÔsÿ;X3…Æ|ô'2†€0�EQÈ„Dÿ¬Äý&ô˜ôÿ
)þWendstream
+xÚ­ZKsÛF¾ëWè¶T•8‹y¨œGN”²�¬¬lI 	IXƒ
+k“0¤€KÑ©�øƒæóz	‡_ä<ƒ–“¦ þ¤��0r¾YÓ`Ï$h
+©ð{d#Öª˜ˆ…_Š;üÚY“óHåÏÙ.´ÌÃ.°¼¼.¾},
+'ïÂ’÷uYÖÛn½‚WË×n–Ë,øÀàëU¼ BÂ]f­ÇHì˜óW`®#©ã¿g®ÅQ-ÁXKwn#YmêN„½4hÚEQ¯‰z»Q£8§¿»Tl+#_Þ¾5²ÿ
+él
+@Nòg¦lÈ�ÏlbsF?{:UHœBëÔ¬XyÛµ§"ßzscø€²¿e¶Z•ñ\ek€
+žÇS\o—9‘îý˜Ù‰EªÕ
+T#b
.KDV@…«áIì¿–€)ç
+ŽiåA¸™Í‘^oŒO¡Eši8jÀ†=:Â'Tý+C2yW|Ê·E“_Òœâpn0^Pd%­aTÆ+îUd¿ðá0¬ƒ:Aø‘áÌ	“b”°Ú™dRT—>ëñŒ"$.D	Ž0üî,Çœb‡Þü9÷w¦/ò©{ìÙýhfü˜ˆr1¯—ì+3ÆD;põ1 ­c
çTCöü�ó‚æ©î9írDצaÈ û¹ÝnŸ
+-erò¨xaÔ×”önÅWŽj
+¦-cÄGÑD"ÒøÂÐw˜KÊbÞoÊo‚Ý“…Ø
+¢M	Û¨(‰¿\׊Óþ’#ÊŒI$„CÝ0‡‹ñçåSͦ(
²•l�‹‡Šo‹ð=‘Œ„uæÀ-xh—ø4þ|B-KPJÿ¥V<ë†aæ
YÂQ|Άc _.™¿èë t
½E‡ëOíµ(š9ƒ °¢?ÊAe–Ÿ€ô]UxªƒW¾�×·ø
Æßbbûêæ¿’©Oz¦c—Gy¿Þƒå¼,à\'^ ý¡Ü€)Ô@ÊVÑA3~)a†À¤åùàI)�åRœœšÁþ¬m³ù§æ’$Ü ¢_z{õó²ª?xÿ¢�¤ÝèÃOÊI0yŒå
òì¾ɨÞEYÐÄÐ9JzŸˆ´íæL?…ï<0G—Qú�
+”î1¿¡Ù¯wó3×ûI1ÿM	
+mšLvõfM¥zèÈÛm½þÄ­Ý&c±{
 endobj
-1806 0 obj <<
+1818 0 obj <<
 /Type /Page
-/Contents 1807 0 R
-/Resources 1805 0 R
+/Contents 1819 0 R
+/Resources 1817 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1787 0 R
-/Annots [ 1810 0 R ]
+/Parent 1798 0 R
 >> endobj
-1810 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[0 1 1]
-/Rect [63.4454 217.2504 65.4379 226.8901]
-/Subtype/Link/A<</Type/Action/S/URI/URI()>>
->> endobj
-1808 0 obj <<
-/D [1806 0 R /XYZ 56.6929 794.5015 null]
+1820 0 obj <<
+/D [1818 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-538 0 obj <<
-/D [1806 0 R /XYZ 56.6929 548.0867 null]
+546 0 obj <<
+/D [1818 0 R /XYZ 56.6929 364.9053 null]
 >> endobj
-1809 0 obj <<
-/D [1806 0 R /XYZ 56.6929 519.5161 null]
+1821 0 obj <<
+/D [1818 0 R /XYZ 56.6929 335.1548 null]
 >> endobj
-1805 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F11 1441 0 R >>
+1817 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1813 0 obj <<
-/Length 3824      
+1824 0 obj <<
+/Length 3482      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥ksÛ6ò»…?Ò3JíÜ;vzî´ŽëøÆ7}| (Zâ˜"U‘²âüúÛHJ¢{7sÉ$\.€Åbw±/JŸûðWŸ'Vù&
Ïã4TÖ×ö<_ŸùçKûñLËœ™›4Ϻz<ûÏS•FAtþø<¢•(?Iôùãâwïã?/ïo.f�õ½H]Ìlä{W·w׌IùññóݧÛÿõpy‡Þãíç;F?Ü|ºy¸¹ûxs1Ó‰Õ°>
-ï,øtûó
C?>\þòËåÃÅŸ�?�Ý<ögŸWûò×Ùïúç8öOg¾2ibÏ÷ðâ+�¦Áùú,´FÙЇ©Î¾œýÚ�ÒÒ)ùY“(›ñ„
-b¯[4
-uYﲂ¬/ÜA0l!
-Ÿ8ÑÃÀÂ�䤆@ÞlYöyÇ3øÃ1�²?€W²)g³¬-çU!˶Œ]4t“Qa�P\g/²Y[°K$9>œ_týÖûU!ñ`àÐ�¯eOÐç„U²	øñ ã'Ä0"Ç:Áw2.'þ±/ñ–0²'Ö¤zdû–Õ¼¬°�X2ÌqW§­w­ÞlaÛm‰f„¯s¡#ZÁsƒZ&ÔF>%vA!Ö«*ó¬+ÉMĽß
hײ¼G³™uD}b­ødž0Re´õ²`l[vlšÖ[5ûâu¤÷HôîƒLߘù„g ò‡ïùîˆvŒg�úããÉæH`Fo1SgŽ(†žÉ]l ÎЭ0 ŠRq÷
-ü‰\
-D¬x&¬³L¼7œ®¶¨È»_þåòöµù�ï�P…yLPUÂ3��òb|?ñV<Rã½K;~¾æþw9Ú—WXw[d+rûz ½Ñà�=�ï9ϽȺlÒOS¦@~
鳸ŸÄ@°ÌŽ½	Ú¥Ìà±£R9Á¬RîÀßønÀ¼Ã»‘Œ}e".ÏíÐ@üæ
-‡ÚŸà°G¶MõZ8R
ïÆeõG´‹¯ú°gŠRH#‰&°„;ïv£(4=” N€˜D‘®ì1Ÿ‡}Ù¾ëæ$eýqÉ•!ù{-¿½Û¸…�þ.(bÿÜÍ‚M�Š±ÄyâøLŽùDCIbÎœaEg˜4DÉwÐÉ`År)f.{ÏeÝq„GgêãÌÌ1y	¦6k§»áè²�ô2¸¼ûò„ŸM)ô¡‚O�؃d=;”ÓÔ„±>4˜‰2
-Õ•QW�ºÒê]qêĂöºwãTCðU‹¹Á&ÐWÄDçQnÀ!4/ܳÛÜ°ž¾k9€	$JÖ(?�>\R÷Êh
-Gf0ªxlTŽ0ÔƒÇ3¦SÃCi/ì…Ý—Bدí@ê™øøÉò†ø�ðÒ_)ƒr¥éHTæ˜0k
¤ Jˆ§ìú)QO±zŠÔ“UO¡z2ê)POcãÀ·òM4²ñ®æMF-`�ô
-ì=%”Rž´\Ï(Q&ð“ÓUúü Âi(á!�Ýð×xY€»é\_³Þ°QïÖóâ Œ	†{ë0¢#~ÎËNjòä�Ô¶°¤‰§ƒÏ;
¹iG­y_{b›¬³(}Gg<F‚‹R§kläŽmOr1n�õ¤^‹mËž:í¿Î”Òÿó>°mfÏ
- é#7ƒ.5Á&ó3?³”qÛ­˜rlsÓw™'•»v•»v™ª‘Lõ~ç$i¸N<ÐgÐÑ6ïü~¡Ïz�£…`Æ��®š±ò‘Ïnh¼

?�V¼R1
-T#;Œœþ¸7„T[FŽ3!{j²øå>Ñ�«ÑËÖ­|/>5ÝY?ýààÿsfï`’§‰Ðß1ÊÍ´’tLUIÆÙŽ»5ÇQ†ø¦JÊ5e€šêDq^Pߤ€ÜÌä E¸® ¹u¡%	AĪÈ_
-¡™-qͤƒê-žîب‰}tºãë˜�›0R¹tr}G"[º–cï‘ŠàÍã�¼ÝÄ¡ŠÃ¾Àæ1†ÃX%Áqà e#ž406ýå;êbñ ÷¹FRÅ'UZCD‹Í+¼¹¤5
£º½
+xÚ¥Ûrã¶õÝ_áÉKè™M¼f›vì];uÚõn¼î´“¤IS¤"RÖ:�þ{Ï
$ÑM¦M&!p
+†WÜÞýõ†Gß=\}øpõpñÏÇïÏn^\~U ‘‘_Î~úgp>¶¿?|�gñù&�¯ò<<_�E±öãHk©Ï>Ÿý0 tVéè˜üb�ùq¦#Ã1
ƹŸèP“
+ü­) óvÃŽ±bÖ
Ïf¦‰u<)¦í¶ç!›ÂȤ:Ÿt6Q©Ÿ�*ó#g„ú–Pë4\¬ÖµA�B¯š3,‡ím-œ<Ÿµ«¢jxÜ+T8ÃH0ù``8•cÍlÀ(7:V‹Hs„ÝÛÎt.䎻OÏ‚‰}Êüá—1cT d�ž\†Ñ–s�ò«KR·6e59’ؼÝ;'L7™·­M÷
«(:¶%G�3Ó¼LŠ¦Û™Í¤˜Í6èÀCÞ¿øãö–Aÿæ�ùRšu?™oÚÕÁ‰¯Q~e�¼cúàöº*Žï~Ó‘á
^
Ñ0åp7_løKa€TÆj#ÎjÓwçÏÎLy0å(¸ëìÖJб-ÐaŽK8�á­Œ¶ëCRØ Ò&“èäþV¨Fëh„Tã[!”í
+×ÞŒIòÈy�d8úµxÙûûÏb>fólÄ+w2­Á !ývÓÜ­Û¦ìuõd¬íU¿Ç¾,9.>+òêоԸZ]d¨
+˜Æq�쪺æÑT Õ¢‘ˆ;ó‡9~D5‡©
(áá0ñ–òðR-ÑÔÝvà¸í¼ã54tüü©Í¢ê+ˆu¢&œ#Cð`�0FÛÞívy¸7ù}0FÔŒ… ¹�DÁcIÊÍ݈PiâFÔ“rQ(ýMƒ\êÇm=ü¶Ž
?ÔV»0"íÂk•uO”‡¡×±¡ã‚èIcÖc¡jJr<ú
ñê½õZ\L£Ë«c?Lu&	ÞM
+}
Ò´½«u®ùp¡h܈É㶱hŒ9
²¶a“ªB­ ”ËÞyQöƒ›·ÒqHXf¹c'¢)ž¶E’%‡EÃÞBÊ­\W\"2\�rÅ‹óU±^sœ‰eÍÖÑ8B|ÖYñ¸ïî¯d$´Þ`«&„Ù«coÎŒ¬„�¥P@ÃõuW	¢9Ÿ+ÈA:òîú1ælµ“d`êýV–äì
+žD<±Ý¬ÛŽªÄT{ݶ\
+þŽ�Éyúfº],@W¨ã$ö®:AÈú”xeWAã)·Ÿ²	SdÉJ
�t$ûô¼ƒ}Vˆèœã
Lɦ`�Í
+ú¤g@‚UD¹½
+„~%1…¤Ø•‹{¦|¹†Q%‚e¥‡Þ¶©ùI`Ü¢¡i<Ã4(è»­v/‹g
5r�­ÀRd»­JkqTòÀ¥{d�Ãã⽨mf’yo;ÆÍÐdÚä¨~4ß¾Û3kKÛ?()<Á²ŠM_•[°o’/@z:
©œŒ­`°+(žÄ"tøn;AdÓ8f-îc!Z¹™ÊÈ>=p¬ÂÊ,ø÷2£\aðèFkÆcLQä¨&íô¹j·×§	”Þ ûÒF„é·‘�GŽaˆožÁJÉ~->¾ÊθúˆHƒ€Uj�ÈI10Òîˆ÷v-U{qnë>±ls›õb[øä.ï(&�x·ÕÞ™aƒ<Íä¶Ì�:¤Ž�ÀXõÁpÌ*/?¬(ˆÈă<ñ¨¥e*æ9jÙ–ô=*Pñ ‚R2¢søv«à
4Ö
”ßÝÀ§PÉKÊ�m#Pì÷>ýÈM=›Ý07Z³CEœˆô¹g€{âgYogÔ†üì‰_N¤ƒàƺZUTÑãúʔЄUÝŠ§TÅÁžU;£‡„q�·Çéx9É~­Ünº
+£ÍôËÖt}7*h°Ÿç´óÒªÂT5	31#|K�R°f¸o5éÖÅŠWØHðᤆUWp˜UÕþÞB\g¥ç’Ê
+éÀFl~ïØ:ÆÆË!b
+`×ÖÏÆ¢jù6n„è…DÙ«_MéçÏD2
+á7‰Wߣ(=Íš+@¬£HWqpòÊî¾ÌïnVRqà —jÊ¿çê×WŸná¢ÿ–ñ¢ÎŒM�Š¡DyféÌŽéDCÉR®�Óœ34lÚgÊWg°�b±3—»§rî8Ëg�dhz7Æ�…%ò
+þ»¬ÇÈ­å5W÷ŸÿŽ�cù½„â0s�Ѓ‚<4Ôô>kC†Ð#�
+¾FA/µhèGÀ’=„øáà+3¤¡’Ôzì/|à?‘Íÿý÷Dû?¶ŠR_gY8þ§B:Hü,ÌSKê$ÓÇ”xtJú
 endobj
-1812 0 obj <<
+1823 0 obj <<
 /Type /Page
-/Contents 1813 0 R
-/Resources 1811 0 R
+/Contents 1824 0 R
+/Resources 1822 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1787 0 R
+/Parent 1798 0 R
+/Annots [ 1826 0 R ]
 >> endobj
-1814 0 obj <<
-/D [1812 0 R /XYZ 85.0394 794.5015 null]
+1826 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[0 1 1]
+/Rect [91.7919 734.3362 93.7844 743.9759]
+/Subtype/Link/A<</Type/Action/S/URI/URI()>>
 >> endobj
-542 0 obj <<
-/D [1812 0 R /XYZ 85.0394 508.2432 null]
+1825 0 obj <<
+/D [1823 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1815 0 obj <<
-/D [1812 0 R /XYZ 85.0394 482.0152 null]
+550 0 obj <<
+/D [1823 0 R /XYZ 85.0394 317.2431 null]
 >> endobj
-1811 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F41 1208 0 R /F21 930 0 R /F14 956 0 R /F48 1228 0 R >>
+1827 0 obj <<
+/D [1823 0 R /XYZ 85.0394 291.7515 null]
+>> endobj
+1822 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F11 1451 0 R /F41 1218 0 R /F21 938 0 R /F14 964 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1818 0 obj <<
-/Length 3375      
+1830 0 obj <<
+/Length 3778      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥]oã6ò=¿"è“SÔª$êÅ=¸Iv›¢›Ý&îÝáº}P,ÙV–\KN6[ô¿ßg(Qßí‚XÔpÈ!ç›CY—&üY—®gx¡^ú¡c¸¦å^næåúÞ^XŒ³THKëûõÅ·o„¡g{—ë­6W`˜A`]®ã_žaW0ƒ¹¸~ÿæîí/«+ßY¬ïÞß_-m×\¼¹ûé–ZoVïÞ­®–VàZ‹ëVÖ·ÔåñßßÝß$¤ÇȤ·onnï¯o¯~[ÿxq»®÷¢ï×2nä÷‹_3/cØö�¦!ÂÀ½|�Ó°Âо<\8®0\GÉ./~®'ÔzåÐ!þÕ8Ká
ПᲞ°EÍeËѸì[ÐéÁrù£iùÝ­ú0ŸØ—út=¢
-©OÔ¶5¢�e¸a趉®E¾#~GÇc–n¢§,¡÷/Ež”ßPû\2°ÚsãáÃ$ªê	’èTÒËGÓ´O%÷¤ygôéÊ
-Iy,ò2Y ûJűJ‹Ü¹cÎçÊÛ%Ê,ÏGi5oÑævMëmz›œh«?߯ޱÕT=ï>´ßïoúH÷�
-MgM¾)ä3.Û|�èQ¦ù.Óä7Æd[–çû3|Ö°&X­°f¹=E´ax—è0Ïu¢JÃC¯­áðÞ°^jfB»ÃL0a‹£.@À"mžª¥‰@ëU›}RvÆgÉgXV–½"s`ÇKË2B×µåúËô$Ê’òè�ŒÉ
~Œ00Å´Üt¬q¹ÕXsr›$ZË­GtPn-¢šgRú^œþ†°ç:v¬®ã‚4A
ì%­ö´VQsŸ'CßöyÔGy¾cøN0#…iBŒ4+ƒ	Š�:‡% QTðÂ
ç@f–¯˜ µS¶j¶¦÷,ÉwÕe1¾%}¼+<¥ áÉ‚ö5A÷VC061h5&Æ3ÏÚ”R¦(Ž9.•R¸—KÛ1BÓó`p`ئÁÿÚ'èV-Ÿ×

ÚP±�‘©äÀŠ->é{áU�xIËVO�ª$æ‰Ë]Å•µÈž‚)—…$Nô¼n@}I
0ÊcÕà55Žp€;�;°’
-ò9J3
-çNEž½RÇ‹4QlÑa{Ó’ Oç4«Mz0áÖ~âÛ7àû¯h[ž
nÎ’ör™äHmy:~Y‚„Ž4¤åH-Ó…3I¨†ÀîúÓZ6 \kxÖXEøÎÄÈ#-¿ÍÊ—9Ý+ºiöGÛv@™PwwgŽ]
-Ð(%@õz”^‡n	tƒºÕ'D�ÉçMr¬¨Ÿlb@½¤]	gz¼½6Hoy$v°fA+¢Ç=”2+§GaRóÔAù†@ ©Z¡á•Ü
à<1 áA÷
M$â¥HÖ�QGìTã.…OÔO‰
AÀ_jIßψ0Èýc”Þr¬�ÍhÕÂój"Æ–‚{
-±}ê7à•‡�³ÓdïØVg^á[dEì»@mtDÉáh†€Pðéq½3©ÊäH5ó¶FMOÔ,^ò„›Ò=ÈÖK£:Ž?–éü~NN¯ÍÑ
åa™‹5zWŠ…5ã¤G8¦IÜ>mÙy,»�8Ý€ƒWŸ^ë�©Ê¹ÑTGóe'°
Ûóg
-*:ÖxÆ\cͥ̓D뜹Gt0in]á–íZu¡ù²/ˆc`²Äî�´ è’) <™É61¹(¸;.”ÁÐ�¦kðc¡=r±è×m
-Š–Á<ËÀãs¬¹ÿ÷Íûw«»û�øâAtq¬€Ù&,ËZ|Cô_öéfO¤v	h#œ²¬¥°]Ã÷»›mñYM‘ì)ѸB¸¶aúáLýAÇšP…5«SD…èV�(*„éÕ
-
M¥¦ÛVÓ#…0Ui
-kV§¦ˆ6:Õ%:¬S:цUKé”ðL¥SÕu
-ßeúáÉ" ¾¶5
-!0´â°håíá2 Áók#ùŽYbld^�sBÖýã •§ƒ¬bÑh8#œ†B…@
A»¬`°¾Oô.Õ—]¼ÊÓ¥€l�•"í8fÑFÒ„>NáE¨¦
TÈC‡<×w1䕉>KëHhq0Îå™7"šC8œÀcê–D‡³Gœ1Í#s¥„Tv~®Ê4îÖÑõ
-–Ì>z!z£\éSRã·çŒÚ[eY±Û¥ùnÔ
-¯i>Z�JUp¨uüúî†ïŸ²bó©]¥óÛçÖµd·ëà\èdh:´Å
-©
Ui€ñyœ>§ñO®ïû	‰DO*Ü:cƒK9�ÝàY<'§:Ê8N¸KP…â°¦ßVɾæ
-AEëM¦*Gjmb$Ì/Eç{�
-©s
ק细hªº¥‚yÉc�ËžoåéU#虪¡Ø”Ìqf
-ü¦#’KÖ%Qy,–øÃÒݾR46^e'Ö¤¬D‡dgÜ´<´³
-’qœ²¬¹"LIUÙF•v)ù;ä¬"ó±gÇ!5¿¼´C×p<gæþRÇwÁ5Öœž$Z»àÑ–æ(Ü"úöC	á
¬‡µ¥Œ^˦3+ÉÝ +¥�ĉ!=Âß|ŸìzšoÖßÖ,ߦˆ6|ëæ›NôæîqõýO·7C!É7L3T¬S.\„fíÄ^éµï™BÒS„d² ¢üžìó犠�'äEOÖ_	¦ìJÖöeÁV·¥Á¥o‡ìT•B-ÉòÔ²ÛW,ueâ•9uEŦBBT®æȼ4£Ö«£¾D›M�^íôim*	"@^ýÔÝM]Ç*áX\>’“7•Š…1)NKŒÚ1°Â	üÅ5»RÞFMVhòøf“*v4Â�n¹¾ª
Oé„gØf ršr_œ³˜¦¦Ï-¨Í_[`åÊƤ®ÌPIW®ErW)ã5O
~ÓsÝö	­6Ч¤I/•«Ã•öUÁ”FÝ®òͤçI¾ÈpÓ:¤ŸUå™—>î5ñ2_ÌzM
kÂúÖ¬õOm¬¿KtØúu¢sI©oø¶×õ
-k–¡SD†v‰3T'zÝ|Ç%Ï�ƒ
-UÇþ’Ï~;§t:R.F]w¤�»âñºåKWª§5«m®]{7dÒYZ¦c˜Nè´¿Cx£N¾\€ãoš^‹3j(_ë|¡©‚,�ÔØ2ñ†æ€_Ð}t«l‚æoŠ6éî±pé™æâz|‘—„Øúê)Š³´¬¾úŽÞÿünèêz�@}õÜ,˜æýŸ–;°$^2Ýcbó•Urâ•nÓL
 ø·�­€Ê/KNPåL9ÐøîÏ¿¿SÝšû[Åü'ý¦²3üèxÀšàŸãêÿýý³V
-[-
-÷ôOm–	[÷ì�¥ÿàrwÄendstream
+xÚ¥Ùrã6òÝ_áG95BH‚gªöAc{&ÞÊxÛYom&´DI¬¡DE¤|Ì×o_ AŠ’jkí²	6h /t7èž;ðëž¡
+/9�_ŽœOWgÎùú>Ÿ¹‚36HcëããÙÏŸttž¨$ôÂóǹ5W¬œ8vÏgŽB婘Á]~½ýtóù�ûÉEä�o¾Þ^Œ½À}ºùíš[Ÿï'_¾Lî/Æn¸£Ë_'w�×÷ÜÊon¯’ðãÀ¤÷ן®ï¯o/¯/þzüçÙõc³{¿®£q#Ÿýù—s>ƒmÿóÌQ:‰ƒóWxq”›$ÞùêÌ´
+|­
¤8{8û½™ÐꥡƒüsåéÐ` ç
10HT¨=M¬—î)ÝܽøÜJg³í…�²ª€<ó5>ãÑÍíxruuáŽÔäþî"ñF%=w/áÞ$™™†
ü’­§å,›Ù?æåv•ÖÜ®òU^ÀHz©Kyò¢ãQU§ëÏ;CY
+–Ó׶Ó÷äTÑ£j÷<+Wi¾®ši÷UVÇ®Š]8³XÑË®+6 ºã½³q^J�\Ïd"o>Ss¦Àá~÷n€„¹h	2ê€ZÜÜ¡jëF'<×Û×	D�À~3¦JB[ŠMc
ž|& øáÖý}•Õ2€”�-
Z/éð4]3ˆÔ
Ëlú=“9ÓŽtP�Æ“�™ÝA»·»¾9Z"wl‘ƒYæßL0Óæ!8­KÄYÖUç€zD¾Š|'ê¨Çà1ìG*öDéØ÷<„®oDR'mHûº1>ß—­WôÒÜIG±oq_WiLŠBA³ð8Ò!„5%ƒêWi�Åòª4ÜChãg ½ïg|.Ùl
+A¬eÊ”{*p™Å #°7ƒBÔîèc6Mw•ÄhW·Ø;ˆ̱VAãY�ç¼Z�™pnjVK‘a¿K—„w«’�shb?Y-µ[�‹z»'•ôÆD¶Öâ‘T‚•o�½§Æu¸–~ÄŽJàëÇÕÍÃäão×WŠ*ôL4gÔX¼ÁSgº,!c¹ëè}Çb�ÛÆý4Îi^Eù*ìDEìȶ¿ÊD‚0P~©ÈáÌËÆ¢Ä
l¡ÝjäB¾Zsá–¿9nÔ'Á|.åG‰¤}¢þ‚@]¢“Ui¶Ž
+ŸOSŽ>àýÁìA[4xÈ©‹_ä	²t[åp¼­‘Ø×mýÛ:Un0U™ïCå{Ñ	æ[XG˜o°N2ÿÑ–ù}¢ÃÌ·‰Þ1æÆ‚~oOsˆ·nÞ;GHìxÿáC¥+‰T΂Æ9°D±B8�ø8Û-¬#l7X'Ù~ŒhËö>Ña¶ÛD�ÎCŽØÑyxoÙ/
3“°ÏL<tœØÄÉ,@̉—Ù©¡‘ŒZÃ�Û²ÇÙ,«€hà”© Ù,2c[H’›ŸD°Ï?.7ë°Ü¬Sr;J´‘ÛÑA¹uˆZ¾Êè{¹ý,àC'¹™·çV6„Î0Jøºh�“-îÛ™ÒA¯åG±J|?9!ëˆÖI1#ÚŠ¡OtX6Q#†&õŸvóvaYdX 
+uÔNáçÙ¿s^)%…Ždìñ$\¬Llù)âŽ,qï­†abhXNhMf>iYF¥¬œBÂ[ÏW‰†ÝèöIJ¦š
ÞP9…‘a
+ÿëhßèx$µm_Q x“Ms,”c�1M8'-N:©oÚ„ž s†¦ëwÔïòò8tÎ N»÷qgS"ÑƇØ
Ù•öq¦‡ëKźx-#±C4Z)?6è¡ŒYù{”FšgF´…BQV-
+
¯ì
+ƃˆÁU7˜§^2²Pùž¯Mda&6ªÆÃH{è§öfr8Û ~G®´/ÎÙ­RQØäÂ:2%d?ªµ£S~S´oBw×µZôÞ¤m=Œ/	uÞ æ[n–¯ëLšä¨õÚªŽ�,Y›J¬©8¾PÊM~°ºÛ`¬Bã,Ÿ‚ƒ7Ÿß›�¹‰¼ÑTFÍ^ì«ØñNDÍ6ÖᨹÁ:5%ÚDÍ{D£æщUÓçæ+–¥¸B_3»dAÐE!`à&Kù»,¥[Êô4‹pŠ«dÚ
ÙÅ¢_Ϭ)ö‹r^èª<¾œ5·ÿ¾úúers;p¾„pºønl—åÞ/\×É•Æë2§<�Zd � ðJ.Z½@E¡ïõ#ÉØÉ=%:¬�¯<ØÚ	…°°Ž(„Á:©Lj¶
+Ñ':¬6QT'lšF!œ «NÈ
+á˜
âæÅlš6çv•›q‘½dÏÐèt¡Žü¤ÌÝa_Iœà€’hO+_7–·_¯&x}ûHw¸Ã7
^èøêâ¢*¬‘⊇ªçXð6eÜ#N¦©}áªð[ü7éV&·—_ÿ¸}ü‡{X¥`‹A�(�ØXGTÊ`�T©cD[•êV)›èOUר”£RµU
+ß)ú©ˆ¯]…B­åT	ñÖˆ®_
Nç<RÙ[ºÚ™šRX�sBÐ#½rÄAk�Ÿ‚ãhH¶C'Ÿ€¿¨a°¾ïüNÚ+^)¹Ô¬qN‰ î==öI¯3mÜÜ9
LN¼ 
+ðÄ«2{–NF[Ç6`ìª�lD·98$à3î6ôCªæÊ&5G.IÈ绺Êgýòº]Æ¢àcï„žOj®C€ãó]an5¶¦XµXäëÅApA‘�œøŽÌÆ:l
+†*„ÄO®ÛhN�±!•ŸS7x–/Ù–üÛl–I—©7 
+
Ã!lD77좒ûš«]ù¡`MS8òÉ+¥áƒ~¬0º(ìÕ¶½º}’Q täc1wwã 
£Ä&ç·H×ùS%èŽë¡Ø4÷íÌ1
+
âGÿïïÕíûA¥ãø@ŠéE10‰,
+™ï[�ù°}éÿp_ endstream
 endobj
-1817 0 obj <<
+1829 0 obj <<
 /Type /Page
-/Contents 1818 0 R
-/Resources 1816 0 R
+/Contents 1830 0 R
+/Resources 1828 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1820 0 R
+/Parent 1832 0 R
 >> endobj
-1819 0 obj <<
-/D [1817 0 R /XYZ 56.6929 794.5015 null]
+1831 0 obj <<
+/D [1829 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1816 0 obj <<
-/Font << /F37 1018 0 R /F14 956 0 R /F22 953 0 R /F48 1228 0 R /F21 930 0 R /F41 1208 0 R >>
+1828 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F48 1238 0 R /F21 938 0 R /F14 964 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1823 0 obj <<
-/Length 1361      
+1835 0 obj <<
+/Length 1873      
 /Filter /FlateDecode
 >>
 stream
-xÚµX[SÛ8~ϯðÃ>ÀÎXXßè˺
--$mâÎìËtVÀÓøRÙ�ÀnÿûJ–ìX‰¡L“Ë’ÎÑw>�‹,hXü
Ïö‰áúØ´�›t`·|ìÃ
-sŠwsÒmÆwüÛÀsl»KÂÙç­¹¡	ë¨Ï
¸ªFV>P¦&Ïrø¹žlÒå
-ª¶[9|�‹x@EŸÄŠ'3)4FšŒÐï
¸)ºžL´YªO±Ð8ô¦:\éE¤Kàhz¼Ê°Q7½ÏÛ—²Ê®g	²2éS
}†ÉñÀÓ/Û"Е¼`¡“÷:Â'­ôLèò|`$Måº\@PXRv/ò¹(öÓ*ªhJ³JÕ~¥iĤF­Âr…<Ã`î¢B_£Bp�ߢ8f—£³d9§Ù•ø·¶ª‰SͶK9ã:¿](G{¤å·œ}kJ”Ú‹«>f•pÁòû$¦f²œ±WèÐ
-þ=H“Œ«ÞGó­ºÚã�†êç»mwü8-.$zn"¬–Ñ7ß{¬.…Ïiž‡Ú+
„:.l9ÀC¾Û€ªÔö:òö‚dúÿ‚z¨Dendstream
+xÚ¥X[sÚ8~çW0;û@vjU’ïíËÒ„´é&�:³³i¦ã`
ž‚íÚ¦¹ìö¿ïÑÍÈ`HÓ†™XÖå\>}çɤ‹áGº�‹°:]?t�‹‰Û�®:¸;‡±·¢æXz’eÎz3é¼<µýnˆB�zÝÉÌ� ¤;‰¯{Çïú—“ÁÕ‘E]ÜóБåz¸÷ælx"{Bù8
OÏÞ~¼êùNor6Êî«Áéàj0<Y$p	¬§Jž§gçÙz{Õ¿¸è_ÝLÞw“ÚÓ_‚mîÈ×Îõ
îÆàöûFv¸Ý;xÁˆ„!í®:Žk#×±mݳìŒ;j�ƨXÚ†ŸkÈ
¨ß ¥€CÛñº¾"Ϧ¶
+e]‹Ú.²=×íZ„ Ðu©Ð“f•Ü¾[&ŸËl>g±l'3ùŒäc‘̬�í¼8"A�M
+ŲL1
+„$ŠIÙ]ªI•F+QgÜ›(Ã5Ó²ŠM«z­lHËË<KKÕ3“sWšÒI:—Íé"Jç<¤÷pÏâø>ösÏœµŸ{õ¬'¹wPë†{;j[¹×P;üûdtÑ?¶ðγQHÂ`‡wXóªÀå?&Â
n`E:Ü+s6Mfj—j…›L�°r?Þ
A~øD¨“ ­&=
ö
•Ö[:Û¡6tG'ý£�ö&ü_¿obc�·*rg«…@^cEúhdÖ}`–‡Ñ4f€SÏzÏCZ
@·Õ¶#jª­“îÅÙ*JÒTyYuè�±Ø¬Ké•ÍXÕÙÈL£PÒ(u¦<k™ÖòÎVeH&KŽ
vø–…¾+#ö4SI�ÝG«|É^È·‡l-+(¾ÊºµNwÕB—Ù,¯’,UqYE[±´’°9&Þ”?œÂ”jO¨.Tµ4Pƽ僟xdë·Û(^&eõÛkùþýu˶X[
+¤o‘>l–rÊÜ“”ÉÕC®FVQY±BY:K–z�ì¹å
+P&»³¾®Y¡�OAÇëïÏ÷ÔŒç]Wù	LÙõ7=ü}29—ªÉ;Áܬ¬ÂéÜ`x<êËyç£ãþù»Ñx‚ä;çdl­æRtBS^ùÐ'ça%}¡ž®³q,t
ÓˆÐM9ÕÈKÆp&ЦbIn=[Â#ZáøAÆ5ošL+x„ðè�¡òj»"ÝH3µŒIÆ£V;‚„™r2uÙ¹”7ÔÙB#¢"7}IïeÜ"õHÙÖ¨DD8Ô`^Èû”/›zg¸Ó²UiGUÔíÐZ´À7$ˆŠ»
+Ç–Uå1ä%|¯kôƒ�cX
µbÒß±Á"¡�¨'ÈiجoâqúÊ ‚ÿ~éÙ((Xœâä%pUÛÉÇÄ
S„™GE¬n­„éÃ
·´‘WôÕ+ò4câLï¥í¹+’Šmp©ØŒþBrkÐñè¢m¿³/M¼­�nŒ×Œ1­»å!ÝÜÓ`KˆÄÃŒ¾-I¶égæ{´«À„wíª«=·‘ÞVIZôÙ^“¤pŒ°
bERç°¸}μ„ËhÀ/£g—{sƒë¨�¢à‹FZByV“g™
+|Bý—�l²û)Ë«º[¾…"
RÑ
+¡ph‚%+¾é»â¸>6ȯOE´ZÁUµµ¶R8cG’SËà $ùç(Ž‹ë—yÁfÉý’¥7úðÃÝÚTxùk9ã6›¯ÓXù9+>ë¥6ã¦
µ8/²op°’ûYñÄ”Q08¯”Õse4ì`qZþÊZkçV™<ê*½^ÝjhÀƒUtÿl

ª"~VGüO®¶ ÆV:±ð’¢Ž)³dB‘ïÿi£Ó«‘h6•G+=äôöP6ØeUˆ¯†€ëý#¡ÅÑïÏ÷´ÌÖÅÔ(žIîˆ
+hèk£D)p·-¯?.ïšþ?H‹åwendstream
 endobj
-1822 0 obj <<
+1834 0 obj <<
 /Type /Page
-/Contents 1823 0 R
-/Resources 1821 0 R
+/Contents 1835 0 R
+/Resources 1833 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1820 0 R
+/Parent 1832 0 R
 >> endobj
-1824 0 obj <<
-/D [1822 0 R /XYZ 85.0394 794.5015 null]
+1836 0 obj <<
+/D [1834 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-546 0 obj <<
-/D [1822 0 R /XYZ 85.0394 404.1851 null]
+554 0 obj <<
+/D [1834 0 R /XYZ 85.0394 229.8452 null]
 >> endobj
-1825 0 obj <<
-/D [1822 0 R /XYZ 85.0394 358.6015 null]
+1837 0 obj <<
+/D [1834 0 R /XYZ 85.0394 202.6332 null]
 >> endobj
-1821 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F21 930 0 R /F22 953 0 R >>
+1833 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F14 964 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1828 0 obj <<
-/Length 4295      
+1840 0 obj <<
+/Length 3578      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥;Ms㸱wÿ
-åªC
-ç–ÛwÑ«þ®D–+é€!§¢Ù—Ôlw<ËÓÔÑ°€jÓ"�HË(Ui¶ú¹©©�RãÐvýlå
¡‰Ò€¨êâÜñŒâx¬«’× üûÂÿnë²c€0Ük6I2@«‚Ì´4>[ÕЙgcÑ
-Œ	.�ÛpDÓ.ñÇ°�à<^æOî¬\â�†ö†‹Lö6_Kd‰´™ü­k-ðÌΖÁqS�a
-Ñô¼æ’UR6Ÿíø Ë%ùcâ2ÆðÊó�“I
-Q@.Ørœ
-ƒW™
-ä°…D/‡‚ÿ÷Ë>*›ù0°
dj¡g”Mg
'to¹›ÄÇ��ÇöĽbÞÀŠsß ‰Õ¤Ä;[íÈÎCë¶ðÌ­ûP$Ô¼	Lܵ�™
-IqöRš)לÓß�ÖqÔ„Ý]{®‘JˆÀ‹ú¡xì¨ýО¾¢Vä9Ç
-ŒHŽ†N™éùNKᦇ©
ð×+A]]m©ß‡h¥yC
:´�%ñs+;s‚Ü>ö$ßnõ÷T§cí¹§ò(vöwƒ¹zŽ@rDH¬jpÑ?z"¶ÿ<ƒáÚf‘,Y‘š¥ÃQ*·
-0P’ݹ&³ \ƒÂ¨»£N¿­,N°#xAà-7`ÆŽ=?… óGA-~¼ÑèÈ´`âHº²X
-$-„j‘œq@¼Bøˆ|yy{\—ïæFpˆW&–��%µ©û¡á`ˆàž·	U_ÎýhÁ1B�qaMR´Ÿ ò—o³ÂF»`EÅ·ïê7ßÀÍô;uA¿Ej0袿U‡ó�>‚!MYÙ±¿ìüÕÍœ–d"2m^Öçt¸!a¹÷T5¾ÌlíTÓ Œ\q#gå<?Ž+%©¨”|Ñ
-1|¬âÞ5 |X¼<Ð2ÑFê¡z–	_Ìéh•H)”''è|¹Œ^%ˆ%—ÕµgßØøX9\rnøÒaiÜq¼«Y°'ÕÑr4�¼©¥@$·I³
-È;ZÚ§õ°Ü�î–"1ß'q6yùc-‡rº°FÜÄŸ¥-¬…Ã[T=u/o2ŒáZÀ§€ñ¾$¤µøá/›+ÐftdÄx�‚ƒi’—r
-ôaø±è7w¡"È[˜^kÂ*TŒÁj0æøK8±‘d¢Aæs—­þ�©wôÐáo†±áoØw�ôÁ©³¿"ðúBmïÇMˆ°¡á],6
-Fôqðe�}®–eÁAxÊgµx¿¼°K	uœ5½¯ôÆ”�ÅõbºŽ%Ìôm‹™¤6^
-ûÐ%uTaA/4}
¡döÌF­Ãüâ¿Xy´‘€R¼õÓõŒÍβ‰Ÿ_¼"3‰r‘ÿ£;o\Âû6¾¿H!*7³'!·å,mœÃ3ÙöØL%íX'Mª‡†½6@êêàË&Ä_Ðh·[º_à÷&àfs>
ñ(ªæ¶={m2i,‹i8�”�G‹Lø�Ó¦™]ƒS*É[™°jùæL—Œ¯:^`�R©�ßG{ö,gŸž�G—(6Á$Goîh—KB>9Tx"Íë#‹ó¢”™,‘YT¼ ¨º‰$uþ²|$*Ϧ²BËÀ¯¯åã3õ�ær^oÈ íÙ‚(�:‚,½±*ÉZa‘ù#:™Â¹:Ðau’cÔùŠgt2qÖÚåGtëˆq=F^È�÷&Üæù°²W–¥€JÈÄÇ miÛÞtdÏUÁµX¥g˜39EÛôÄl 	äA¿3žŸH@‹|.�‚ƒ×>>ýÈ0Ð}Å—#ý#ßyALŸºyL�
úÍ—ëŸÞÍOÅÚ$‡ÌæRT*#‘ƒÔwÚ_RãóèQb¾�'Ž�÷ù+Òð¥t[NUÏI*OLžë	-OžEÆQ/�ðóA
œ¸Û|Õ5¿ãÀ;È–)¸5Ób‡Í§öËÈtõ¿ŒÈxGgð%›â‹IšÚôß_ôß’ù“µp°‚ýi²ƒµ›­©1­Ü7EŽÕKš~÷eSžè­$~ž;bƒÕ˜„rL'Ž
-—rpÚÚæo:òuœ5Bÿ–W2áwdÕøJýD}uq•CU¸žÂûu?ß„3“³Ç
röÊÊ?å^Þ–Ô”h©ß,qøz:0ãûùH¤›ÉS[à�²�ÔY=lÙUݽÆs~w¿-»Í©:ÿ,°üÌâÿI¼UI‡×¾Ï+©6ê7(©* ¦÷ãÀC`�‚!×`(Ä!P½†?
?æ8'
ýsŠÓ‘˜91xë�ƒMó$Šc¾KÂS,.ýk‹Òxý½´Zÿ×ä¿þ·—á‚2ÈŸ­}&t“Æâ+ˆBÂmþ„òðÿ1OIÿÎH¬Qendstream
+xÚµ]sÛ6òÝ¿Â�òMÄ_0}J›¤—›kÚKÝ›»I3Z¢l^$R);îÜý÷ÛÅ.øeÊNÚéè�ÀXì.ö�8Oá'ÎM–d^úsëubRaÎW»³ôüƾ;<g'-‡³¾¹<ûꕲç>ñ™ÌÎ/7\.I�ç—ëw‹,‘É`HßþðæÕëï~~ûüÂêÅåëÞ\,¥I¯^ÿý%µ¾{ûüû½X
+gÄâÛ¿>ÿñòå[ÊÇ7¯ß¼ ˆ§Ï	¤o_¾zùöå›o_^¼¿üÛÙËËŽ—!¿"UÈȯgïÞ§çk`ûogi¢¼3çwÐIá½<ß�i££•Š�íÙOgÿèFÃÒYù‰4‘*“3Ôb @—&Y
+¨¬ñI¦¤
+|w±ÌÒtÑòªÙ‡eS«by›ü—Ô¤å>û�¯×‚üy>Þ&2KaO‘X­LÀõ—0domv>€A‹ßíëCKÍrÿ
;ï©÷5}ÞK™*àÈ‚J‘xcä�ÔªnËÍ=:¤R?¤2³‰²Rÿ9T
+«Xû$�OÓ™DÁîL¦>A¦þ�dz‘H'm$T	ýõXƲä
¤±hšžðn£)õRŠDØ4›r”̬”#yÚ'ZùlVŽ=‡#z0P€•X-N’ N�0U;ŸHaô,)CIu'úåÂRƒž9ê¥úó„%þaÉÏ–´‰ÐNÎ
+ëØË 0Ü|¹¯ë-Áï‹æC}øPÕ#\éi�wë—Øb	WÇÝUq˜G!Aqܯó¶(«¶8ÜæÛ“¸–R%^¤5øß×8øÕ+):1�O…}µK²ÌöáH81)`k`›â@ã§vÞUKÝÅ/i*«²-ëŠ yµ¦ÆÏM~]ðVrà½a'i’Lë,ìtyStôô“ÐâÀÓ0‡	xˆKB
+D¾ë‚šõ†WššQ­j¤iY¥*Õ‹ªí=�
Rjìê¦�ì¼"4�6 ªmBí|¿ß–ïAø¯óð]oƒOÁÅ@ØŒ–Ó® 35Í�ÊVVtæ£è‰„·™ç3Gù¯“U]mfÔòIOMØõ€Û°F:h¹DaSC�ÙŠ~J
&5V̨¡U‹U^Q£^­Žjæ<FŒƒÊ´õž Ûâ¶ØòüÍh`ª+<‡ëã!g{ B¶<¡fôeÕ”kƜϰ¥„I„QŽ	¾-‹»9ãÒ‰3î
W¨3Ö“vŸÀ¿TÎ'.µÏsz›B÷PzÆ"Ïmü`Ï-êª pà
+s1„õ©
+Ø˪߅( ì8O€ïõ¶¾Bk°°´¡Î˜íGFàY¸~RàÉü$�ÉÙ©æ#:‰/úñ¬R;£Ü�Ìå$Û&ñ½Nt	·“ä™Ø-I'z·„ƒ,ÝÂF,}ï–p^àÊQ1�sÙ¨¥óQyœš7­šµ:8V�úÉ…ù i³±›Å†¬mǃ¤Í&:"„�ÛLø`ša^ïQÑ2]Æ–™±¶†•í³¡|`,j+ŒÖ›ž†Ï
+¨e´ž>6—™Ú
+ØKvß�sBNäÕXLD—4Q‡eF:�N‡Öé0D–”„à8eGÉ’S·ÓVpÁrñº%è.¿çYÛ¦f¤Ly5™‘•I)ŒQeB
+/Ñ•žÄ0ð
äjadPN눆×<Lj†óŽ{º¬ÂÑ1³°üØÖ;(âÀ4©òÖ‹
ùyh]åA˜ƒ}ŸŠ„š—Qˆ›:
+à¶î\.H•¿Ç _·¨Š 
+ >Êiª‹§�.$Q¼ïtZyq§8ÙÄYWu¸T{ìÐ&Ý�F=48)w¼YÍ£�æA§¤äC°¥ã~ŸòæÍ‘Æ’)"_åTG"ãÔTz-Çr‰¿WÇëëûÉõæê�77±¾Š~fUnqÜ·<€åû5bZ,œ
~ôÖ_–?8-b *ÖUsâVEwúØU4áz­Ï°‚ïËá¸
+‚
+J3‰�|é:tú£À¤ãËÖÓílí‰�i©újŒX~: 2ä>yuˆå§ìLiy\ï—MùÛÜ¥8�äAD“tAÙ�`‡‚1Öh¶“-€~~ñ#ÏB´¡Åw˜h4É× ª¶¤ûè_ÝÏ‘'¡2ã†×ªs¥=jU—�òÑÎð@Á%n—@�ÉÐѩɓݨ°~|˜
+×ÌÎ��1�ÆÈ7®à䜜ÖÇÝÁJI&*%¿´
€L!l¢š(u&Šƒ¤¹Ž/\
 endobj
-1827 0 obj <<
+1839 0 obj <<
 /Type /Page
-/Contents 1828 0 R
-/Resources 1826 0 R
+/Contents 1840 0 R
+/Resources 1838 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1820 0 R
-/Annots [ 1830 0 R 1831 0 R ]
+/Parent 1832 0 R
 >> endobj
-1830 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [87.6538 169.9215 137.7628 181.9812]
-/Subtype /Link
-/A << /S /GoTo /D (tsig) >>
->> endobj
-1831 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [370.941 61.5153 439.613 73.5749]
-/Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
->> endobj
-1829 0 obj <<
-/D [1827 0 R /XYZ 56.6929 794.5015 null]
+1841 0 obj <<
+/D [1839 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-550 0 obj <<
-/D [1827 0 R /XYZ 56.6929 769.5949 null]
+558 0 obj <<
+/D [1839 0 R /XYZ 56.6929 611.8175 null]
 >> endobj
-1690 0 obj <<
-/D [1827 0 R /XYZ 56.6929 749.2538 null]
+1701 0 obj <<
+/D [1839 0 R /XYZ 56.6929 581.0004 null]
 >> endobj
-1826 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+1838 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F21 938 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1834 0 obj <<
-/Length 3040      
+1844 0 obj <<
+/Length 3547      
 /Filter /FlateDecode
 >>
 stream
-xÚÅË’Û¸ñ>_¡[4)Á›ÀúäµÇ^oe½ÎX{Z»\”ı,‘2IÙ;IößÓ@|ˆÔx;•šñh4ºýÖ°…?63ŠPaå,±’(ÊÔl½¿ ³[Ø{qÁÌ"-úP?./þö\$3K¬æz¶¼éá2„ÃfËÍïó§?=y½¼º¾\pEçš\.”¦ó_¾z†+?O}õüå‹ß®Ÿ\&r¾|ùë+\¾¾z~u}õêéÕå‚Åà<ÎxþòïW8zqýä—_ž\_¾[þ|qµlyéó˨pŒ|¼øý�m€íŸ/(Ö¨Ùg˜P¬å³ý…T‚()D\Ù]¼¹øG‹°·ë�NÉO	C”áÉ„
-ã5@í9É=e"	ä–=>øöÕÁÍ;Êœ5 ¥ƒ
¹#îaÝ70×L#
:æðž3 x(&[/ùåWU:Ñ}ýr—­²`H\’„å‚áíÿh@ÜùßD=\ü«fµ]«7`N¤©„†‘!\1ëñ¸�Ì Š3J
G“6yÝäëz±Þ¦E‘íjDþ6²=º[œ«t¿O+¼Fö¹¢³ð%8Ec�D¨á¦ùGa	±‚›¡ªþŽy‘58zK
k‡÷Þüä߈‚AüN€†#‰Ê£økØÂwîm
-áa¾ÉÀÝׄ+ër¿?ù:EÚrǪðî¾Þ}“·ºÃ•ú®†;pœnöy
DVé"<UÄ(s¢MYIút¾·Y�eº^c"ÔÛì8Çy^€—Ù§�¸Ë›p`L¼H÷#'CZUÄÈÜ!eº/*7Í‹&+6aÏÂô 0‡çÙùj—õ÷
Çñ€–á&ûã®ÉäDÐnéà_¢lÊu¹«ã­
¡gn¼96ß2ç#9¼Ã±Á�5®/†‚òÅE³óÉ BÇêG?-—¯qÔ
-ÆyøúÑÃÈc}ÒcÝÇcÞꎃn¶iƒ£PåÀÈâÇ
-¾Àõ!ßùôfŸóf‹£]¾úc¿ã`´ÜÏíXû%£0j¬þ!LÅý�o¸Ç4¤ \r66
n4ŠÀ@ oòÝ—œ„�'6²OY@o·Á<
-ñó˜ïÂ’ã´<Ôø˜°
-\WiÕ…K«ÂsÂ^ZÜ!tx¡p]G„‘ª›4ßÅ„ù<}�q/
-V|vŠ+G½‚
¼žäêŒ9hàjÚ³‚åJ¦-°G5qõзʵE¸èa‹•+ÉjbÛ{€rNFs…¨9NKAžòß�$Ê.I<Í3 ¬CÎÔƒrÉg
-æ[åõÌ�xÑ9ZO+ŒxYð© ûº
-ð~Xªžg>:â®wÁ~á¿¡U!ÅùK�p±´n2§=ÚÈùòÒòy‰ûèÎðÞÒCkX5äu"œ÷®	•da­“몶àÛ“ó~�iI,ƒd]8Ó5&ùf]m1.ú(ÇÊÊ4$æàŸº›ï×VÅÛ6È9må2‰ ?ü0¢‚ „ÄrÅe…ÆÁ—!�,BÞr9—qÖ£ÒñÑ)Œ¡CØжë×Ä!¶Ã(¦)¡”^ÆÄ5ÎÞr.'¸PÉIMí¸’;á]›@�ß/ëF¤
-FÙä
-ƒ¡Q0Є»öÎ&ÍÃ…Àb�»n°›rLˆœyûMßÒ8[Ïc¯#Dœü$&móÛ­/ïÛ«ë5dÅ&úòØFé{�“~Éà7©^Ce ´ÅÇ#`	·§‡ÐÆ8T9Ôm§{¢Ìì…ש&/x4ùu­.PpÕ*W=ìÉEé|A¿,'I[gœS/
áÖȘú‡RÜ3.s� æcwQrÃ~Ï æO5�¹�DiÃbÓÙtýHú‘Mu„ô`³ø�Ýý×ÝftCL]›ÙîÇâŸ_ù(çÀŠã~•U÷�ûð�ïéß~^ìMBÞ…žï$íîùò‡ÊøØì•:‰Ú< c"±³@±QS­,:ß …¾MÓg¯Þ¼¹zŠã:[«¼¹ÃnÙø—²
d^GdõºÊWX±¹Ö먡à~z²ÒøߘdÚ…#ܬng8¸îý‹@¿èÿ‹À¯cõMë�€IÌ8ÉH; fü_
-
èŒpÅØjò$ÊsÑýfï{ZŠFaÖ
-g˜	²ö­|H矷ޑˆ\`p8®vùÇ 
8ÀŠ)~Š²X¤Çf[Â}iˆ1°üϲÈq¼ïCQ~ö�DÄÞ#,¶¥
+xÚÅZÝsÛ6÷_¡·“o"ñ
4Oiš¤î\ÓœãÎ=´�-Ñ6'©ŠTRß]ÿ÷ÛÅHQv|éÌ�„Ïv±ûÃî‚l–Ã�ͬÊráäÌ8™©œ©Ùrs–Ïn¡ïÍcqÐ"õõÕÙß^3s™Ó\Ï®nZ6Ë­e³«ÕOó—ß¾xwõêò|ÁU>×ÙùBé|þõÅÛo¨ÅÑßËÞ¾¾xóãå‹s#çW?¼¥æËW¯_]¾zûòÕù‚YÅ`>NLx}ñ÷WTzsùâûï_\žÿrõÝÙ««ž—”_–dä·³Ÿ~Ég+`û»³<ΪÙ'¨äsŽÏ6gR‰LI!bËúìýÙ?z‚I¯Ÿ:%?%l¦,7älJ€ÊeZpáØ튺½)w-²x2AòL	 ›û‘U¬›|¾oË–ؼk¨e]mªŽŠÝ]I…z¿¹.w4®¹¡¶eS/÷»Ý9³ó²ªúºÙ×+ªü«©Ë@ºß–ï¸ñ“šÍh‘v[.«ŸóœÇµåî#¬
+‡)`ÄÅ
ò5[DVŒeN)î9ª›Àt*%&2íL?"!rF.×H†´Ã‹J
ö÷ŒZhëê ³ttŠå²ñ¯ªú6Ìkó�÷ÌyžçÆ{^lKOfQOmßÈŒË<Nj¶]ÕÔIK(–åÎ�n1“9¡ÉÖ®¦×½U<ÊëCy?µG½Ô|$*!ݼZ�*�ŒZj)&±"“‡½Â"cÃãDJ>3Üe‡~†éñÌYk§
oÑS\¤$�­Š
j Øaeo,«	)0žÙÃ1­JäºFÕE¶¯ïéú„µÍ¬P#
Œ…œ.ò¨�mWtå„û-Ax
òëÁ“cé”�–FÅ)–¨ÔЖ`¯ ¦l~OŠ
*Š
Ðìˆãç\åWï/Þ<Ÿ
+c:sNë™
=2VY!uîngT¸L�¬¿H'�Ì‚<¢‹Ûx_Æ­[3…;Ú�Vcb°™#0�ƒÛÁ˜V�£Õ?Ý•~zÞëÞŠ±ÙŸ
þ#
+`�°pÓt%�à—áùüŸ��
³Hfü¶/ÛŽ=hjÝ=¸
+œb\È$=£“µp°Fè!@âšÊ�Ö„†¶º­‹nèB“�ªÖkêô
+ÿ·e]î@WTÝ·$åÂÆ`ê1L�îÊq€„:4ÛmY¯â TÌf@ÒÍ7eÛ·%ˆO3á™Ë‡ê:`AµÙU·0Ô£mrݤ˜�ž
¶â
+×wuQS'é
+À¬ÓtõiN¤6C5C*2˜dUê  Ðzñ&o1¡I‡)
ì²CV+’YhzÝ„Žë@Íß$tW¥`r(tº7rÜ6‘«k¾ýSÕÝ…vožÐ4
+¸#jÄ/¶éÊcºM½¾Ÿ8
N±VV?éÈý¬
®,q[œ
‚jèŽæ|þ¼¾u±l¡O(ÉÇÓ|ÏZˆÃõ�-œ{‚-®$ì‹«'kœÈœ‰Âø~^ÓÖ
Ü,
¯É„ˆÄqp·ú²*»¢Z·Ï"x–#x]•írWmé÷¸|3	Zà¯alõT#5J>j¤ÊˆÿÁH9‘tU�½
+À…^] /‹
+‹�¶ƒµ„s;íçæ˜N .øS 7õ4}SÌ
+š==1¼„±~0 ŒaN�ÒÁ€pŠwX„Ž
+s‚htXÔi‡ŠÉ%?U¥‡:.v]Ƭ8Ó¹9ÓÿG∿F}¾†)8WÍ>×~ür=«èÈå M…a¯Pèú{2þÚtç–cÒA\ØvÕ²],.×!6{ó+!!Â.¿ŠL™‚ÈÄ줖}^戠†•þíÏÄ›5·C¸ÿ‰FT5f±„—жýÕ‚¯ü‡H0‘)#1™‘)è>þkè"¢I%-pvX£¦žö¡òK0%wb¨2aª#704'+ýuStË»_×Æܾã�@öyJ>Ÿ${à;˲çÃíxq™¡¸þx>uØ@[š,7æpÊ<â)C9»êàcѵ…ñžPÑÑñŸt}Œ:IÝ�w3áxÂM`¤§ûÐb9øÒ
+‹m…I`¬rr…а}§ÏdL„ñ½^Á¾Ã]3þ.𮺽‹_5Ðf1žƒI³')ÞŒÒ$ƒ§¨$�2ZòÕ
+P	«Û�½Øî*ˆ£×|‘’\¬S¹]À2ù´è·²v"ŒO¤óˆ~9ž™>È8¥^.Z+£ß"ðôc¼¢'v%7Lónû©\32SÚ²£\3g!Ùíöà¬þCœ/J2)²ËàÛù@ùPaðzÃañ³Ý‡Êéø秾€ñ³å‰‡å¼—Ê}øt\Bxn-Ÿ~¡¹Î,`QÜ2m�^ÅûϨ�·þ_2¯Ò7endstream
 endobj
-1833 0 obj <<
+1843 0 obj <<
 /Type /Page
-/Contents 1834 0 R
-/Resources 1832 0 R
+/Contents 1844 0 R
+/Resources 1842 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1820 0 R
-/Annots [ 1840 0 R ]
+/Parent 1832 0 R
+/Annots [ 1846 0 R 1847 0 R ]
 >> endobj
-1840 0 obj <<
+1846 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [461.1985 109.336 510.2452 121.3956]
+/Rect [116.0003 713.9801 166.1092 726.0398]
 /Subtype /Link
-/A << /S /GoTo /D (DNSSEC) >>
->> endobj
-1835 0 obj <<
-/D [1833 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-554 0 obj <<
-/D [1833 0 R /XYZ 85.0394 672.7429 null]
->> endobj
-1836 0 obj <<
-/D [1833 0 R /XYZ 85.0394 647.0238 null]
+/A << /S /GoTo /D (tsig) >>
 >> endobj
-558 0 obj <<
-/D [1833 0 R /XYZ 85.0394 551.2038 null]
+1847 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [399.2874 606.3768 467.9594 618.4364]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1837 0 obj <<
-/D [1833 0 R /XYZ 85.0394 519.7104 null]
+1845 0 obj <<
+/D [1843 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 562 0 obj <<
-/D [1833 0 R /XYZ 85.0394 269.9108 null]
+/D [1843 0 R /XYZ 85.0394 508.4868 null]
 >> endobj
-1838 0 obj <<
-/D [1833 0 R /XYZ 85.0394 241.2269 null]
+1848 0 obj <<
+/D [1843 0 R /XYZ 85.0394 484.1422 null]
 >> endobj
 566 0 obj <<
-/D [1833 0 R /XYZ 85.0394 160.3269 null]
+/D [1843 0 R /XYZ 85.0394 391.452 null]
 >> endobj
-1839 0 obj <<
-/D [1833 0 R /XYZ 85.0394 128.8335 null]
+1849 0 obj <<
+/D [1843 0 R /XYZ 85.0394 361.3331 null]
 >> endobj
-1832 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R >>
+570 0 obj <<
+/D [1843 0 R /XYZ 85.0394 119.3418 null]
+>> endobj
+1850 0 obj <<
+/D [1843 0 R /XYZ 85.0394 92.0323 null]
+>> endobj
+1842 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1843 0 obj <<
-/Length 3508      
+1853 0 obj <<
+/Length 3265      
 /Filter /FlateDecode
 >>
 stream
-xÚ­ZÝsã¶÷_¡·Ò3'†
-z-‹¶ËyDQ£T`m1Z[Ø$Lmª�c\µÛíqÀÒ-J½�85ÐÙ¦Ü9#höužW~¥®¡gþ–'’º>Ò�u™·¼§æ�ž‡MÆ=·<mÝ!8W��MÕb)Dh“DºµÝ>a@¬ƒ6{>B +*²ÁmQe¶+ŸéëC³#"s‚
-T/ ç¥“‚JKs²pŒ1–;7µç Û4m>]z�¼ì[Ï…“<Ÿ²²Xg]îg`âÛ÷·»üËEéÐ
-m�årsÓæJBDÁ�f1ˆô/-µ|{˃݉<N@@Õ
7Ýóxä/t«F°š�eãÔ­†+ÌéT%‰=]jB{ýk;Øt…gû³Á*«‘0 íu—5µVû²+¶eNo0/0jWäí•òlµéǶpÐl"–UβTi'è»nª~™:«ò7$ë4
M*“cQÿE*{ÄõTœ['â¦kVMÉMYùØìŠnS¹÷8p¶«$Ÿ'ßdm¾Ô1½ÐmÙªa7YW45}Cž�Fº]+™ %zI`þv›­rÏO—Ý{²ÎeáÌG"þ(ÝnÈa¯²Ý®Èùĉ‰n¿«Ya}…—â±nè}Í
5=;¯qt(@ {oˆl›I'8�¡|Üïx§ØXeÏÇÊ×nË‚õq¿õËu<×HàÍí2œÑȉÚ~Y%­ˆ$«$1bžd1@8�{E‚†®ÙQæOyI$œœ[!>²	~%�¼Ö£¦­CÇÃ7Z†0�ðneGÓ@¯œÔ‘z<ùáÜÊ€­ÿú�šæ¶h'ìÓpÜ7݆Z¶%+�ÛÌÎ�<MlC)ÍÄÓŒ<˜²õºèŠ§ükôÁƒŸ“ðˆkòoŠE&½È¤™D&�g.êMFDÈàþ™'*¹3îšXVÁý¾#â•õ%ïY’Èhð‹5ùî#¡-³ŸvÎ’Åïô9cýNÀ«`?Úé 2
-žÒÙÑKÖ—NÏÄ&>Ö¬/KI%Ï9¸ÕÇAåS¾�ÄQuáÑî;@]±_CóÍ`ü;ëcQ¾{‚èUâ�$PM¢Çõ¦|B¥Æ–f›Cä�9Á«¥gû(\Ýî·[€�°z%hÉ?g„>n&/„í=!Ÿ‹
-ü¿µêäŒÃ‚G›É8ض'œÖ#0¨%…¤ c%L”Úcc½~@/!e°i9î
ÄÊ-4£Hø‘:ä=>Ú¡xΩ©Ðà£Ò'Œ(êuz¼_·,™­yÙ^ÙØ‘\‘~9þÖë£ 	Ù_jÄ$W’2†•ëõòþéIêF3¤d¼*P>ËÖO„Œp6KW¡°i:FÓ3r
-´“”Ù‚‘f¶ìr1g"Tª/º|É%
-"Êùjßí‡r–wN%ú‰–Z¸…¬túFñWJX³’©fá7"&ðµã�n¸B|ÈKð"uÖõ\:ˆ÷*lþu_�r�Ìx…wÖ~Ý“Æq¤Rq:‹ Ò8”Jžì,„4sç'á ¶Û<ÛµôÒRé}ìNÍ<€Q�p_bû£ù(îjÈ&ÙSAŸì”M0ÔRW‚c	ÆLÕ‡ÎŒRÌh? �B^:'úÃZJkCªÇ�`Äz®àgÓP¢/û“Ö©ÈáBsi4¶-³xØð§¬�l‹=541Ò$X¢U)3�%wY9|>¬R'gIjðK£ÄÀJ²$x:K²�éìÎM°gí>q°’Ê‘ÄQo»Ö§ƒUóDCÄ�}¿<„¦ˆ3N(ºÓiš˜‘ÊE°0‹dâd ¥‡xJ§�êI­¢Çõ	ãYxÎÉ5NBȯNw«qÛ¹4ÆRMž°06;Ñž‹ÀüWWÊáꤿlØd&‹
-Øž•¾Ó×dfH1vóªèÝ.¹¥`¾ºìSÎM,
Y4‹†½¸õ;§—
>Çxåj'·0xÁpïÞQ9䱛®›«wD$‘Ð…×>]^gT•Â;3Ò£UÞ¶¯^}-…•hÀ
3ê”h­¾„Ý!ŸŒú«0w^†q^LÂÙ£{ô"¬~ŽnTüíŒpú:ç‘R�ü9k�QìŽgÈ»Õ&g>;/¾©t4]2’}È8BÙc_³æð¶"¬¤Í¸†¦}Z§…ãNþù
Á.:shóÀ½¥W§sÚxÔ4�;í6_ÎÅó$Î>õkÀGI†©9ÙD¥^”jŠ@Ntí!
Ä­…œ…4Q/ÉÉumÁj·é’µ|o³ÞsE²˜Œî1²vb#`J¾×ƒ/Åd“:ÈÈ<£`¨•{Kœ5—«þ@•Œúì̬)j&›ý,¤Ï˜Q»ÒÉp
-®€ÜÎߣa¸FfTˆo¬e|#|¡ˆãõWn…z弄ŽÂ$R )1ýlÁܸ> Aâkè9ª
-å«oéb¿àQ$xÑË7±ß[å±Ñ]ù?XÌ›Óýók7éÞƒëëV¯ÝÂÿC¥\Wã¿>w\©™j
Ĩ
-RJ¾j8oöйôI^&!jã«bN”3pEŠPpegxС”=ãØ’¼¢LqÆÑÉÆoðÏ]zîFNÛ¡pÖÿcké±¢/5½×ý�+í^jüßsRþ‚¿hë¡ojÇK}¬bЂÔôÅÓk�»ßãkl'”£¤ÔGËÔ²«
é�´9ÆfŒ¼æ5º xù‡¢I�ÊdäfÂ×þ§’ÿw7󇻨¿çýŸÿÞ7ü÷1N1a”óÿÜá€5Ã$ÌîÛ˜œûÿ
¾dý¿�,îÊendstream
+xÚµZKsã6¾ûWè¶tÕˆCIdNÎÄžu“]ÛÙª­É(¶XÇ"RVœ­ýïÛ�nð!q2Jv·t`�Fãë.ø…û±z‘èÈWA¨ëê"X<Á»w!�YºAËñ¨¯.^ßÈd¡}‹xñð8â•úAš†‹‡üƒû¿�÷öÇ÷7·ï~º»ºL"ïáöÇ÷—K¡ïæöûk¢ÞÝ]ýðÃÕÝå2LUè½ýëÕß®ïèUÌ<¾¾}ÿ
õhz|†éÝõÍõÝõû·×—¾½¸~è÷2ÞoHÜÈ/>‹¶ýíEàK�ªÅ
�j-ÕE¤¤¯")]Oyqñ÷žáè­�:«¿0ð…ŒÅŒ£p¤À4ðã
++·c�–¶·ÚPXÓ+¢L
[Ù½2ëlßj>•�x˜~.ƒÊ°E›Aª™gÇ|¶É]ŸÌs+íë¶xÙýéÆèÌ~¬×8¯6>XéØÞd-õ¬žv­›Ïï‰U•óD—Q³Û]¦ž½ÑÔF†az¨ „õ èˆpVG¼²nÊ<Ò
+,NY\£Þ¶)Ÿñ-äu
+v£�´00¤fYЉ!MÀw‚ÙÊOtŸ	Ú)Ö	f%î¹
ü敺†žæWXžHúDSòÒ´¼'« x6�Y>yEîY'rzsí>aB{mF–ˆghﾨŠ2Û•/ô–@:> X¡@õÚ
z^;	8Y‘ž­œ4M�ûkj'

+8=H£�ê"_Ö’TX
bçVO�Ê'³=ò)ΣpÔ…G»ï èŠ5`MŸë¸Ëßì»Þ™ä#ƒI<’ª#owš‚4[ž=‰2 ™g±'îê~¿ÝBù
+“vE
­„)æ׬×ÇÝ„BØŸÑÃfŒ¡‡‘
6AOKLí5â"Y7G1U
HÇŒ)j�×{8Ζ‚4Ü°4”Çá°fh÷ÏÍ'œ‰øm¹ÁQzê eÄ]\¯R�Å
+	@=U#Ž;l
+õ�$!ÆLš2¸YaÛJ0ck2ˆü$ŠÔÙ%¬TE3¡«•ªÙ»¥W†WƘÉèp
+Âû:[a
+íK|Ø�¹¾íK¯Š¡å:MgÀB¨Ñ±PµOMQ
+<êùfßí‡r–§q¢¥.B!‚•ÖÞˆ¿¥T�-K[¾°³ÁcÒG#ËÑÚ†-TÀSŠÔY×KiC¼Ï†Í¿ì"Po¾µƒTx‹ÁÚ/{²8÷i&Jf#ˆ$ò…gƒE(Ò¹ópPÛ­Év-5Z*½�á4�`d
+‘p_bû£ù(îjÈ&Œ© …OåÔj©k‚ÃÂ2̇?>ÆD‚mcýt"(˜Ò‚Ø[)­9LIÑ<Fäs?�ø±ìOÞNI„Í¥ÑØ_´,âaï²öh[ŒÔÐÅ‘&…%±ô™ù_wi1|à>´”ggIrÀ¥Qb Ý$xÚ›¤ÃÉGFìw‰ƒTŽ$‰ú»«]:X5Ï4%²ïÓCÀÐãŒ3Š® t’¨tdr
,Ì*9èéC<'�ÆGµŠ>®WÏÂsN¯‘ò!¿:V£(ÒsiŒ¦š
+<ÙaÅîûíe蹃}#õ$~ýXõ¾2G‹†°=-Ü ¯èš‘#�é/®JŽÞî’{
+–«Ë>î¢À"‹&cÕ0Šk·sjás„ÿêÑjzwñÃÊFx“rècwvÝÝð^„áQÐ…Ÿ}:SgT•ÂofdGkÓÒ…¹?,Iåã¿ŒfþŸô%ÇÿúÏLÃ?½¢±ë3ô	ØC
+LX(ÔMzòç’þ_O§¢ÿšŒ>endstream
 endobj
-1842 0 obj <<
+1852 0 obj <<
 /Type /Page
-/Contents 1843 0 R
-/Resources 1841 0 R
+/Contents 1853 0 R
+/Resources 1851 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1820 0 R
->> endobj
-1844 0 obj <<
-/D [1842 0 R /XYZ 56.6929 794.5015 null]
+/Parent 1832 0 R
+/Annots [ 1856 0 R ]
 >> endobj
-570 0 obj <<
-/D [1842 0 R /XYZ 56.6929 632.4244 null]
+1856 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [432.8521 670.5036 481.8988 682.5632]
+/Subtype /Link
+/A << /S /GoTo /D (DNSSEC) >>
 >> endobj
-1845 0 obj <<
-/D [1842 0 R /XYZ 56.6929 601.0274 null]
+1854 0 obj <<
+/D [1852 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 574 0 obj <<
-/D [1842 0 R /XYZ 56.6929 519.984 null]
+/D [1852 0 R /XYZ 56.6929 719.8738 null]
 >> endobj
-1472 0 obj <<
-/D [1842 0 R /XYZ 56.6929 488.4276 null]
+1855 0 obj <<
+/D [1852 0 R /XYZ 56.6929 689.3447 null]
 >> endobj
-1841 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R /F39 1151 0 R >>
+578 0 obj <<
+/D [1852 0 R /XYZ 56.6929 484.1038 null]
+>> endobj
+1857 0 obj <<
+/D [1852 0 R /XYZ 56.6929 453.7341 null]
+>> endobj
+582 0 obj <<
+/D [1852 0 R /XYZ 56.6929 375.0298 null]
+>> endobj
+1482 0 obj <<
+/D [1852 0 R /XYZ 56.6929 344.5007 null]
+>> endobj
+1851 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1848 0 obj <<
-/Length 3757      
+1860 0 obj <<
+/Length 3647      
 /Filter /FlateDecode
 >>
 stream
-xÚ­ksܶñ»~…¾õ4ãC‰õ'%±u%µ•v¦ŽÇCÝñ,&<òräIV:ýïÝÅ.@òYj�¹¹!¸
-‘e6pHÛŽ§¾«‡›ºerèq[Wwg…Zâ�ÒZ¤9HÒRfÀMÚv�ߤ)“�Õa¿?“ùö‘
-"üÏ›
-ø£ýÖj°(€„ ãúð
ׇÏÕMÙÂ\(ûYê¿Jx
ã@¹8ì
-•Rº‰pr©™”žàwuÓPëºbȾ·<x
ÐQ«¤Ç/Ýaß–ü	1ýE„ÓÊfBÉ •8-~i›·•+ÔÈm“êÅÕ�ã-A2‚/ÀÒnËj¬s%2cýòI‚·¸4N*_¸EàÓñ]^žЋ¶QìðÙw]K#=d×õ}}Æmàó;"g�†.Í5Á“ä ‡=·@ǧóOM'|@¢£FˉeptíìбÜÒž©<_úÈú=½t+ÐQj­‡¶NèÙW`@Ö=òTÙÅÛÕµÈw Ê`Œöé´„ÝH§F(æ>´ÈS#y”ÓgG8
-j–‡¡�EIÄW·Zl8Sµe»ª-¸à®¯Ø*¥Ü`"ç+î:42~Ïp®¬
-¼¶a<Ê@Ù泑å4O[!³<wc1�Qrš$á¸Î÷²jK‘f0ûr»-÷ñ€HQd’2Â�2®ÈPÇ-˜2O­�óêݪ)ûþ=�ÿwÌ–�¬n–«¦Jz?Î=Êõz[þÁ�øÐ8»Œðÿ¼Œù;³®ú¡n]¤ùåÈöøʾ¾­–¾ãøûªÿÐí?´½¾Œ-éÝ„=d™^Dñ>6€Šú¡÷ÛrüÍ2Ê`¢ÿX
-ί
õ!C)é3ÿ”2ÿ4X¨’«aŽÕ	²ûº¯öëPgÛß…6=¾¹|K
ÈWÉýB¾Ropú
§l>ÐdÅ\8(Å¥¢ÚUí:D>2¸»áø…BŒ71pá…^\óÎ]¹rhʽG6—˜í�D(ƒÉÃtý®©­aÕpØ1b»Ã“×›ò–иl•žû3˜™åf{h†zׄLÙÙ‹€i’A¾*W7±pÀ@\gŸ�+”‘ÅC‰ÑR
k�,»FR^P}l¹X[JŽµ
àX€ƒ~W®Nƒ-N‚$'A
-ðŸúXùªYšŒ™4º/1¥„µ. c}<ZÎ{
-À}\~
-’ã¼
6œ¬acâm	€Âæ†N…

AØðåaBsf~TØ´ÐäZa$`øracŒË)ʘ°áöM&þŒ¬¥"7�œüa4ŒOÐöPä¸{3"“µÓ49‘5¿9®ñ¨¬A$
-�kúlY›ÅdÑÒ¤,B“ËîÑcΨµ¦B%6zHÙk´ìT$³fq
És,æÐã	9#òq¡O��iá£ÿ2ùfò	[“Û9Æ'–Và'ÁE­«Myhx%®ØO‡Ç§ùKØ:aÊâ4d(]Æü˜¨UÕsæj°Ô"7ŸmPº×,�Ÿ?FðÄ–
-þ7ËCæû$÷´0:QŸå¦1Öþ/ÜËñ,QéÚô¼¸¡Œ
@˜’�
-ö¬‚=¸*w7õ
-k¨©ñYç-Ö
-‚¨¹øÃ� F¯UH	±‹«&~ÐdZ§7LêLk&ÌÕ‰åj…¶:BX» _7ôŒ×¥Š\äJÛ'sJQ!í	oÍϾþغ
ƒMô³R¶ÕyìùA{Â,ø‘¥rCÒwÍ-Õ†,•,µ/"âU×Õ§!,•Nx¼$9Ò�pþ„DîƒÇ˜¹@`³–ÿ3™œÊ<Ë|•,j~r(ÀKàLòTÊyVð¯ÎEî*1!�Ç&z¬Y'È´ˆ™Iì…~:Ù”ij"É& e>Ãd,Ì	i�›r…E(ªðãgf3‘ÕÄø%':Èjb+{šâ6“=A®‚T>�œ.)È ¾º§9˜A£
ãg�<ª‰cb’J’”&äîSŸ
-³9£ž¥˜‰|&:-1Ò0s3ò�3k±Öã<‹O¶ñÅUÖ©9.™�ƒ;lƒ'Ñó±5?½ð*i¦Ý—óaÐqغ›ˆ÷²xvïäRÎNÜdíÒ~;½=¸©èÜ]¡˜ñf#v‡m,_EpV¶÷'\£	ÑÊÅ¥·Ý´ÄRrcÕmwuS­—~GñåÉâUIÇ>‹Å¿j¬*O.`_;k‚L(O’gXFcŠX¼x‰ToP
-åý•l,õáGä™äm⬾sv&é$3Ï1s;2Ë+>Îvçç² ²e!ý6 èâRPã¼�3'F(<NŽN)�Ï`Mñð\€§˜Yœ¾k©ÃqÏ5ð2öðe*„¡Kž’�Ň=ײ°×ßøÀvØy�‡Òþ&‡Ô™ÈìQÞî¢Ãœ�ብzjQa/ñ×ò©df£‡zÁw#œ³Ì³@2S`�ŠgùŽ¤(bg,yî‹$ÁåæIX
 =™g \ô>õ¥IBŠ“óý#lTŸ lZÕC47M Á/ŠìK|
+xÚ­Z_sܶקÐ[O3>”
+g�ò$`þj‚1`¿(Œã¡Ïà$³|Öð–Wu¿¸­™Ï>JåÕ›·;ÿµ//}Ý#ÙÓ¹Vp¾R—§s)Ei`y¤¸lˆßE¿†�(ëf«ÐÑmè-PÅƯ]Ë­j[BF
+=«Ú%õÝUëfYõȾ"ƒøÜû¦½9"$†
¿­
ʬf" ¬4ôóƒÔªRQ|
+s ç'äfA¿´Îy°ï�·MÝö`+Ú泋ˤ,„µR�eB¬‚ÅDIÃ’ÍÆÓ3l:ˆ
^|sÓÖËgôZ{4gïÃn¡Uù4–ו�£VÝŽÑ£­ï©‘t_ÂÖCD_ÁôZ„me°�ìF¹°�×é@µÂ媞ZÛ®i¹ÙµÀ¸ÖnvŒ×wõnBþRÂÉÜ<eI eN«±%1õ†—ó5*
+q3uÔ…Êšâ+O¶j”:>i^ìcñ1.ÖÑsS}¬™¶VÖ™-�kÃåë—08×3ðR[lôص©@„u[µ‹š:nñTqHµ&ÊÕ’‡^רø©i›¾
ÕùÏ?…ÓÆFP22
ü²ìp)Ü“µdu�ÒŠ¾úŽ¿
cG³Ù‚bFe»¡à³éî‚쥆CkÈË’ü)öо 1^:Ð4ñ9}^ÒfàÓµ=mš¥Ë¢¯m˜›¶ë©Aëè�½U­¿¯wþ9î”\!ö’àe’3nb¿­Ã!Ìéx8�ÜåãÓ…Å¢9]?$y*hDk<œï»äçƒy·Gs‹¡^‘‹4`îŸzj=Ô,ˆ{2¨iŒ™Ÿ5¤[­úzÇM^ˆP+ˆR�—¢d!jN[I!Mq ‹r@½šä

+	A=ƒ›§r¤ª_ðþ‡³ëZŽ:+ˆyøGͪö"8X×Ô•$…HRØ%…Ö®-‚,_ÿ²‡ÊRJDZ)Ðëuóq4H%Œ,£‚ô»½ï×&cE®‹2�­	4)lY¨#Ý$�Ê3'
+)‹±¿}d%YɃ’GGÓF8�+�ŽxDÉÃôÝ–Oöšç¯¦à¦
 îò߆6|t¼4"áèè˜Ü5€L
+v±èr€yV–2й¸ÎFs„cܳ9¶=u`¸ª7 ÜÐSõM€#ªÈ3†/lHЊêÁT¸wäœÑÃqiùž˜À¦b"Àµ!­XGV«õ:jz~lø:ðSâºi§ŒCfRXé¢~Aôµ ÂÿXQÇ£Õ�ÔQ„z¡ž‹Û
+챦.lœ•ñål¿Å°¹ä…^ðtJh°Uµ4°";:ÂÄä8Mx
+¯M:‚H2�ôêÇ¢pÒa°E™åa,V’•9
+GÆËK—/6y(ÉU?¦Êu˜íëÝe×–‹R£�¯Þ¼¥ä«~!_iV¸üjT—Ê1~åX9(Å%QoëA]""ƒû[Æ/
W*�@ À=»èÇ·ÕBÈ~]í"Yð¹$h¯"¡DOËùíºaZ´#ì«ûýÖÇâ ­}?¥¯·Õ‘1ûõŒ«P\#Û¯ûf»N™.ŠÓOVÆΫÅíÈ
×™'4Æ•Ëòs�ÑR�hƒ.SE”òè%ÕÇVÀÚR2Ö–ŠD€=¨~[-¸Ÿ«êRÅ$Hr=ž+’*Tëøýu@ÕØÅʬ™½`
ÁË/{”’ÑHDƒ9¢
+—Crò‡ñ˜(>Á#øCáðôFL>¦k¦ir kñpBãQ]$
+ÀÕ~…®Ñò#L6Yš”eªb’Âá/
+mft…° _Wôœ®K•N8¥Í“¹KžJQ	ˆz¢ÛðFµ§®Ÿ”*°•S�Ç�´¢ŽX82TnHC|·¦ÛJ\¬=l&^tmOwδUº	Pñ²Ì<òã˜ø㫉R
+ˆY'Ïÿ…LNQd‡+Èøƒ†|±ÁÄY)ÇYÁ¿»€ÜñQÈã3}¨Yg(´	7“)8ýt²)­Í'’M ËrÎtT挬.,¹À"UøqDp³Y>ÐÕ,�[ÎtÒÕ,¬ì™;Àmyñ»JHm·K
+2ˆoh
Ð!„€ó3¹<ª‰cbbe¼I²…{ hø�þ⧖[’.+ì0ŸÃ^ä2üðǹ£¼—½Þan+ˆ;3NŸ ãw‘—”Óä’+k–ÁáNT]êOæ¸|·	¶•cï¡°}TÐÀ.°‹£Ï‡cüòƒ/DcºL¿Kw¸û­xìw—b¹ÖS¿’ÌR­æwÿ&óðƒÕ¼p"júç–:³Xª."S(0Wsž~¼ù9ëÿ Ã.Iendstream
 endobj
-1847 0 obj <<
+1859 0 obj <<
 /Type /Page
-/Contents 1848 0 R
-/Resources 1846 0 R
+/Contents 1860 0 R
+/Resources 1858 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1820 0 R
+/Parent 1832 0 R
 >> endobj
-1849 0 obj <<
-/D [1847 0 R /XYZ 85.0394 794.5015 null]
+1861 0 obj <<
+/D [1859 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-578 0 obj <<
-/D [1847 0 R /XYZ 85.0394 598.2464 null]
+586 0 obj <<
+/D [1859 0 R /XYZ 85.0394 452.7705 null]
 >> endobj
-1796 0 obj <<
-/D [1847 0 R /XYZ 85.0394 573.7174 null]
+1807 0 obj <<
+/D [1859 0 R /XYZ 85.0394 426.6554 null]
 >> endobj
-582 0 obj <<
-/D [1847 0 R /XYZ 85.0394 445.1049 null]
+590 0 obj <<
+/D [1859 0 R /XYZ 85.0394 294.4314 null]
 >> endobj
-1850 0 obj <<
-/D [1847 0 R /XYZ 85.0394 414.9611 null]
+1862 0 obj <<
+/D [1859 0 R /XYZ 85.0394 262.7015 null]
 >> endobj
-1846 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F48 1228 0 R >>
+1858 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R /F39 1161 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1853 0 obj <<
-/Length 1101      
+1865 0 obj <<
+/Length 1845      
 /Filter /FlateDecode
 >>
 stream
-xÚ­W]W£8¾ï¯àxÕ^ù(ŽWŽ[]ç¬Îl§{åzz"Í&	ý˜qþû’P¨¨­z¸ 	Éó~>ïKlÃ�mx>ðC'4&áx–íQ6°Œ{ñíb`«=¦Þd¶w}šŽÏ݉‚Ðw|cž´°`�mÌ㛡0ÖðìËõùåÅ?³ÓÑd<œ_~¹™Žg
Ï/ÿšÊÑÅìôêêt62íÀ³‡gž~�Ogò“¯0>]^ÿ!WBùzt6=ŸÎ¦×gÓÑíüó`:oliÛk[neÈ�ÁÍ­eÄÂìϸaà+1±€†Ž‘
Æž¼±ëê•tðmðwØúZíõŸm
Çõ�Ží>z!ð]Ç­¸Äh52}Ëáœ#šÃôHÎUÆ®ßóÓ¶AèyN}èøXn™?`&Gì�”i,Çäу’’Ê�Æ–³ñ¡ß¨EX]ðú¸¥åœiUê—°³~Žƒ¹ðûD8.+‡·µûJÉÇHN(ŠJÊðRM¢K©	';Jöh¥A;z‘<ÝìØ ÓRI#¹Ü·AlGÓñóšB%ˆdEŠ¸Z܆‰$Jéõ	­aµˆ}ªh?IŽ´™QZÆ8¿Wòâ˜"Æëâw#ö@ï×÷¨¥Éë9Ä7Òù„¨“>åœî€›Z/ßÉ3f/þï=>î$N‹h}(®¶YÓ´'YrÂ[ü@Š,w›m8_ˆ^AÑ“’m³á@îÀ|³if()Ù
œÑŽêÜ«Û'r²?y¡Ö‡qŠ#®}÷R8Ï�""9‡8oXQQ[¹¾¼Kq¤g0ŠYð�ÎËwÃ	ALÂnÈ_!†ó1t$ZÄØÁ‘vëãñ¹cÍ™¤>žˆÎ2q›¦ëLD#µV]ñ‡e"þªßR˜e�J¼N#ªBî
ÛõÜGU£E35½‰RÈØmÇc*U/%7
7ÉÊüQ"ºéòCVÁEÍ EŠoØR¿oû¢ðÓÔéýa°œÂœ%ˆ¾¶ÇeCÝ\>@W	gDPE96%‘.�9rïBî]ÐRgò

-§qiÜüÑ,]TE|Ouª¾}O1ßì
-Ð⿸陯ëbwuY›ê¼ÉðOm�-X�¢=¤VM +ª^÷˜`ÊøAV(D»OŸ~GàuBÍ;ÈÞÒútBIfÆ8åå‘æß!¹]Ãð¬0_Ï­¾{¢èÁÕå®çVg5ý÷ÝwÈí[4q7œæzè8­®ìL0ˆRª²2´žh®/›OUÿå‹&çendstream
+xÚ­XKsÛ6¾ëWhr’gJ
+ÁæçË‹ED89
+À0!‘Ï}à;YÜk§üE¹Âg{«ìFÕfeÑàâ&Û¨ɬØ2‚ÿ …
´° ","°MËwB�qhŽáÃò5­lÕZ-ÊN¥U"ó¦DêÚšÕ5j‰Ô]ÖÞ:cä”)¡ ±ˆ}«b“©»	;x@¢Pìšñ�,d±ì�-ôËsÏ�"ø ÈcŒ$aÈÍ‹²ªr
d’,ÊÂQw·3 ê&ª)óMVÜàÖŸ�ª3ÕXNpESÉ÷Œ½	_@ra¼ø£V”[¯©Tš}¤”§vSæ�B2³ÂMìÀ!Ÿ1Ý>ôŒŽ=ÚÞˆÄAüxpcƒ‰Ð&�µ*pqJÚ‰�¥ZÉ.oµÛ
_AhÛi¸ø«,²lS˜+@ÜÊ�‰À…ñÔòöh9Ý™}wÚ[Ê/±†=–G<w�>Ä–
ò…äðÁ¦µ¸±Üò“e®0sRµTEj÷Ê�ª�ÔÒIÅB {ñ¹n 
RURïzAlîF÷
+OrµQ9îéy<`b=Ä]-uõâ)"�tyËÝdK›K‰ñ˜ÄÐÞÇ}^WŸ 8_áYɺEÊÜ„Îb¼ff¼�O:ÌBØQ)öu sè@Iò”ÑA“DL�}—™:Ê
\­°Ü*˜y
+8

]džëG5D s°Ø¶§>Ëu•»º²‡¶‘ÞWºÚm«…hY~8ý`÷TÛUV®–¢mÁ{"…›†¾t=t®[àhüm~~�¼Á(YàV
ÿM‚·±ÙE�y/ ™«º�ù\ÿmÀòC"¢0gØË—ÈrnŠOSÍmÙåK¤M¯D²Ô
Õ„“�«Bµweýi0:ÂÍë¶ÖÆ™bð_Âü^ŠCÜøçÐ	
+öØHá徯»PÕú“ìÄ·XÚWôþò»ý,®Û‚|ú£.�á+@ˆ5J{�Ж»OÄMÿÅ”3ýendstream
 endobj
-1852 0 obj <<
+1864 0 obj <<
 /Type /Page
-/Contents 1853 0 R
-/Resources 1851 0 R
+/Contents 1865 0 R
+/Resources 1863 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1855 0 R
+/Parent 1867 0 R
 >> endobj
-1854 0 obj <<
-/D [1852 0 R /XYZ 56.6929 794.5015 null]
+1866 0 obj <<
+/D [1864 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-586 0 obj <<
-/D [1852 0 R /XYZ 56.6929 373.5272 null]
+594 0 obj <<
+/D [1864 0 R /XYZ 56.6929 217.9621 null]
 >> endobj
-1715 0 obj <<
-/D [1852 0 R /XYZ 56.6929 346.1843 null]
+1725 0 obj <<
+/D [1864 0 R /XYZ 56.6929 190.7072 null]
 >> endobj
-1851 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F21 930 0 R /F22 953 0 R >>
+1863 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1858 0 obj <<
-/Length 1190      
+1870 0 obj <<
+/Length 1211      
 /Filter /FlateDecode
 >>
 stream
-xÚÝX]s£6}÷¯à1îŒ(Ÿ&OÙÔI³ÓÍn]÷Éõx‰@¬$'vâýï½|Ù`ãœô¥ãa�{uïѵtEƒŸ®¸¶ª™ž¥8ž¥Úšn+~<Д{xw=ÐËoPõªõi:øùÊtOõFÆH™†5,WÕ\WW¦Áììò׋oÓñdˆ[;©Cd�´³O7·¿=^q»üz{usýçäbèXgÓ›¯·E÷d|5žŒo/ÇC¤»¶ã�áÈ€«›ßÆEëzrñåËÅd8Ÿ~Œ§[[êöêš™ò}0›kJ
-$Âå A|–¢'Y$ïqî0<]Þ=’õ¡›Žµ…ä4¹ïkŸ`Kî—
ò—fk4µ8xå¿@9ªé 1ºêX¦�Ãü”¿²UÏql¥Ö z1x–2^®MÙü…ÒS5-Ï{ˇKô4ª1aþcDGï#ê骑+EÑ–$$–THê‹©ÛXAïÑŽh@å�O‡k=+æ�c1Ã…+�A	ˆ8)ýê(ÙË%弄’딜Ä'Àï„òß ©J µœ„`ÀC.J'‹ä) -L$_¿"çÑ¢a
-ˆ

-('¾d¼”�ˇE‚cÒ�
^‚Љ
-M"š%R�D³aÄá<S\$etê*§8BË"Œ ˜ÈT}Nb’ÈÍ2¡«ÌÙM‘0LÕËj—ê�ój®êuÖ›IÆN<r?—ÙíGXˆ2¹_ó¡­°»¼~"çoø%_Tß>_Ë ¡DˆEŒ¥ÿ°ˆ@½Šþ]–<…ʇÿ'˜°_¿¶Åþªù`¶e˜„Œ?clãöðKdÿ�ø�èQ<öOˆ"#·‘Ò¿ÛB›ug£b‚Ò�…Û¯õ.z\L·LL€ï®âêSù”0Ã
àˆÖ}°»épÁ.••a4)Ú§ªB.¯~Z	~Ãp$X#	�V¯‡«”•°¢?›í¸¼ÊëÛV-Ý1öÜÑ2IÇmµ	�ùnÝª:o‹_´?wÃð"€3…;à Y’Mˆi´�8cœLöæâ‚>/Óz{ÁRI+Éè°!�N,ò¥È†g)i½3I’•ÜpüÜË”¿¡¸MªèîÍe…ÊñµzYk!RâwqC¡Z;²œÝ„”ÙËŠb´Á³f”vª·!ƪù:+åÞŸæžnÌG‡œÅP
…°A�Ä'¢¿Øæ02NÑ;bëã
rÁøŸéLÛq‘	dL³íp®râw%íÎÙ,ø3ìºÆö”È0j§D¦6R]Ãs*R™Áž¾Ï|{ætHýéoFõendstream
+xÚ­Xßs£6~÷_ÁcÜ©ˆæžr©sÍM/wuݧÔãQ@8j
+ËHŽkC×±íz$ü5øsØx[N=e?×ö¡ë[Þ	:¨a@dú0pÏðÜ
+ï*A¶h¸W¶Lï	ï壒ãL(é°aKùv$IÓ^H-Í2&i|š|¶º!ë<¡!•­Aú ‘ÎBë¥@D\M$dY$ú"HÃý½2_Þ?’ͱ™^ê÷tÙJ:¡X(${¡¹Óùm	€F´=KzŽí–0¿”¯\xžk4Æ÷ìó_hé
+ÊØ“Giç*ºÃ1«²bêIØ}܈?‘?Û�b3@3}V…^A¡Dˆ¹ª‡Ã‡y¢Ø«{ñ¦AUåÃß„‰^Àõ©àÝD­‹�w†­Ü¤*¥w~ûÖ¨�õáëQ<ö‘;OVÔ¿O¡íº³U1©RB«(Ü}�º/¦š‚L”¼ûŠ«OåSÁ$G
+GœÌƒÝ¥Q•¥Š2Œfº.+”ôæ5á÷W'‚µ‚ðÅÊãÇñ.%¬hø϶}D+ë×…ò¬éO,rJÉ]µ©:³ý¾·Ìs§y'�wàpmt|{P0œx§ûŒ	§îƒl%¬mŸº½Qÿjµ7ßí/ÒU@û¾µ»²¬Æ5�mŽ o^-T¡e€%ß]*‹þ? A*endstream
 endobj
-1857 0 obj <<
+1869 0 obj <<
 /Type /Page
-/Contents 1858 0 R
-/Resources 1856 0 R
+/Contents 1870 0 R
+/Resources 1868 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1855 0 R
+/Parent 1867 0 R
 >> endobj
-1859 0 obj <<
-/D [1857 0 R /XYZ 85.0394 794.5015 null]
+1871 0 obj <<
+/D [1869 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1856 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R >>
+1868 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1862 0 obj <<
-/Length 1091      
+1874 0 obj <<
+/Length 1124      
 /Filter /FlateDecode
 >>
 stream
-xÚíX]sÚ8}çWøvFŠ%Y–5yJ³$›Î6ÝeéeD¢©±©$š�’ÿ¾²Í‡�˜à
-�‡3j‘ óÍ€~ËQÈó�B¿AùàÞ4QË•�ÓAzÓ¯à—fHì Jžñ?ü"Uÿ%UÎ ¶Áú>T±KlÂ`¼’jð&Yh)'oWo_®bDiåòWpÝ)-Æ"æúõ¥Íx0™øÏ$«é‡á~¥Þ3-ÀVÍw„ZU¬×ŠŸA°·MzX$0‰Çùkù¤nl‚ê=B–#ˆÌ*‰>&±
-µ§Ú²èüܘYVðËE™p¶iS
-=Äðîo¥*yÖå‚mô×ó—…íY“+�ÏçFï_žRTþ_ýGåÑáßð˜BŠ9©[‡¼©f:z}W®™ð/ª™ýÀÇ{ÖLz~uR2ô�_uÔGlÂ!¤ê`Îþ—S|¸9#õlåx}‡qᄳ
+xÚÍX[sâ6~çWø:#Eß4û”MIš�.ÛRú”fÇ–w}[I4!Ëþ÷ÊÀ$&ØÐm;cY²>}çÓ9Ò‘°�ô–
mF˜á0Z[†Ÿ�q¯Û®¸þ¬?ͯÞÏg—Ô1d6±�YØÀr!r]lÌ‚›¡
	i4¼ø4¹¼¾ú}z>rÌáìúÓdˆ…†—×?�«ÒÕôüãÇóé`×Â˟Ι�§U“]c¼¿žüXÕ°ê±t:¾OÇ“‹ñèvöa0žmliÚ‹-ù2¸¹EF Íþ0@�2×2õ‚˜1b$Ó¢Ð2)]×ăß¿n
+©ÉØa–‡ã`Tß!0Ã�¸Äi�—ç,å@*Oéý<òå±ÙDà)ïèì*ÑùŒà¡àò¡ÜrŽÞK�
ia¢Äòˆ’G_ˆ]S±Š@µ;!Ï\d -·3 T|
+.×âšN®ê1ÖÍEmá4[÷™§ÞÚÐ?ö¤ÜäŽåBÔ«–yÝãAç³ïÚ´Ø—"¿áƒ<æ÷Ú‘³´‘=ôWÎàþgPØ$·Q«�.é*ô¢xݧ™à-GŸòqvV='Y˜×I󄧊°Ugܪ³yªÎø…ÎR-îÞÏ‹ãì|Yp±ÜÉü‹¥ŠK9×ÇXÿ¡‘õë dSÏÈ)°øŸ˜ 7<'òâEÞ,ϳ¼p¤îGûþ_Þ9œpêÇÿí©ÿß:ä¶ÝqQ}ô¤´íFJÿkv'ßm/M�Þ¸.Ù\mÒ¸Ú"ŽMWƒÔ¤
+UyÅ|}Qöšúß–\Y¥endstream
 endobj
-1861 0 obj <<
+1873 0 obj <<
 /Type /Page
-/Contents 1862 0 R
-/Resources 1860 0 R
+/Contents 1874 0 R
+/Resources 1872 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1855 0 R
+/Parent 1867 0 R
 >> endobj
-1863 0 obj <<
-/D [1861 0 R /XYZ 56.6929 794.5015 null]
+1875 0 obj <<
+/D [1873 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1860 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R >>
+1872 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1866 0 obj <<
-/Length 943       
+1878 0 obj <<
+/Length 1177      
 /Filter /FlateDecode
 >>
 stream
-xÚÅWÝsÚ8÷_áé<XÕ‡eKÃSšB.�kzGÝ—£c°ž16•E(wíÿ~²“:	
½¹áÁ«•ö·»¿ÕÇ‚\¨Èe@Â}7ä> Qw±v {«ç®T­ñêE^{Õ›Èy="¡Ë
pàFË�1äFɤwùÛÅÑpÜ÷0…½
-9Ë‹ÀÍn9Jèû v`§ýƒöï"¯B2Ò,�ë'‹,.Ë©üs0í„UûMSãX¥¯TÛùà‰\â,+vÞ—­�ûÜê“D—ªœ­cµXͲ´TVÿý~J!ï„ô*Q
WkÒÍÌÌñ
-àH,5�åÏ×wÖ™œ[gü ÎËBîb™žà¨ZbŸ!…Eží¿-SY*=B'ïû
-GÈç+:ÙR5z3˜¾¤ÔG[]�"÷LÿÕÉ{^½ôÌI‘¤R,Tç�[¦YçõûÔUencçiêõI¼¯ _Õ7ïž«úugýÚߪ>x6–×#ŒÜF½4¡ébK…i0Ó
¬‚³þG}ÐÅZäÊߊÏâ<5n­&Î+|*ã[Ñø¹~
¾~€iù
¨òôWã)ês½k7ú¶zÐ\ 
D$pqˆ
-3Þ‹í¸~¬�¼(6{+K»HÕ¦M²’>pVhæªÍb0{A«vi–Yi.ºÎq<Ϫª«Â~7²�X¯¸K“j"ÞªU!SóÎÜÕª¼ÜîX3°qh!UàᎡHÓ†Ü6·çÕË7;6„¦^:�Ðg¼«#…Íé:»ÿ½ÿs s ŒáfœÀ
+xÚÅX[sÚ8~çWxú;#U˲&OiJ²élÓ-¥/K3Œ
‘xÖØÔ¡ìfÿ{%Ë6Æ1	�éìä�c]¾sô�‹t‚¤ÿ°ã3ˆ¨p.\ÈfÎtÑAÎ�ž»êàb
(�úªwÃÎÛKÊ
…G<g8¯aùù>v†³Q÷â÷ó?‡ýA†ºì
æ¡î»ë›÷vDØŸ‹O7—×W_ç=îv‡×Ÿnìð Ùôo.ú=€}†õ~R ìÙpyýGßJWƒó�ϽÛá‡NX�¥~^Œ¨9È÷Îè93}ì©ð™³Öb!ˆ³è¸ŒBæRZŽD�/�Ï`m6ßÚÆ£>d>á-º¸F ñ\H=O8œ	èQBsGË$U=à!Ô
—cóqkN¥¡
ÆP0F첿åƮҭ•¾!†­tfFÂbî¿bÈ‚
Ìt1'
P»fü
+6†aM›æqKíë¼åšxÍŸÐ̃”bÞÖb£*µ^ÝÐoÿÛáj·û>©¢cÇÝ:  Ow¨î›©­/‚>!£ìü‹U5Ó�_endstream
 endobj
-1865 0 obj <<
+1877 0 obj <<
 /Type /Page
-/Contents 1866 0 R
-/Resources 1864 0 R
+/Contents 1878 0 R
+/Resources 1876 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1855 0 R
+/Parent 1867 0 R
 >> endobj
-1867 0 obj <<
-/D [1865 0 R /XYZ 85.0394 794.5015 null]
+1879 0 obj <<
+/D [1877 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-590 0 obj <<
-/D [1865 0 R /XYZ 85.0394 337.9712 null]
+598 0 obj <<
+/D [1877 0 R /XYZ 85.0394 182.554 null]
 >> endobj
-1868 0 obj <<
-/D [1865 0 R /XYZ 85.0394 307.8573 null]
+1880 0 obj <<
+/D [1877 0 R /XYZ 85.0394 152.4401 null]
 >> endobj
-594 0 obj <<
-/D [1865 0 R /XYZ 85.0394 307.8573 null]
+602 0 obj <<
+/D [1877 0 R /XYZ 85.0394 152.4401 null]
 >> endobj
-1869 0 obj <<
-/D [1865 0 R /XYZ 85.0394 283.4459 null]
+1881 0 obj <<
+/D [1877 0 R /XYZ 85.0394 128.0287 null]
 >> endobj
-1870 0 obj <<
-/D [1865 0 R /XYZ 85.0394 283.4459 null]
+1882 0 obj <<
+/D [1877 0 R /XYZ 85.0394 128.0287 null]
 >> endobj
-1871 0 obj <<
-/D [1865 0 R /XYZ 85.0394 271.4908 null]
+1883 0 obj <<
+/D [1877 0 R /XYZ 85.0394 116.0736 null]
 >> endobj
-1864 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F21 930 0 R /F22 953 0 R >>
+1876 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F21 938 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1874 0 obj <<
+1886 0 obj <<
 /Length 2618      
 /Filter /FlateDecode
 >>
@@ -8678,21 +8740,21 @@ xÚ¥ËrÛFò®¯àª²ày
 º%Ðp}D(ø¾Ð=
geزÛ×_¥µ€-Œ8û?ùeìgS5ów.z¸ý¨�óˤì
 
¶
^$“9÷Ê+‰Ï…þÀ¹àŽ“Óëò}f­âº½B!âr¿+gjxac¨Ú~„ös,̺´d +õAFÞjß–
S‰JÝä9MÃ=/‡±ÚvÚМښ¢åø™Ý˜9ùVÃ>¿9wMç™ïœ‘ð·�áDlÒ$¶N빟€àOnôÝ?8�K`àÏs†²Óù=Ëã$&6�‘j²H^ý
 endobj
-1873 0 obj <<
+1885 0 obj <<
 /Type /Page
-/Contents 1874 0 R
-/Resources 1872 0 R
+/Contents 1886 0 R
+/Resources 1884 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1855 0 R
+/Parent 1867 0 R
 >> endobj
-1875 0 obj <<
-/D [1873 0 R /XYZ 56.6929 794.5015 null]
+1887 0 obj <<
+/D [1885 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1872 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R /F21 930 0 R >>
+1884 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1878 0 obj <<
+1890 0 obj <<
 /Length 3312      
 /Filter /FlateDecode
 >>
@@ -8711,29 +8773,29 @@ xÚµÛrÛÆõ]_ÁGhÆ„±»X\ÚéƒbËŽ21•Jò4Ó$ 
’hA€!@Éê×÷ÜIpêÔ­=š={öìíÜÏ‚jÀ5I¬˜4œÄièÛ
 ˜Õ’—¸}�MñÅÉSæ¢{1Z>V!À;1¼ÎäU˜ÏWmå#ôÞÏoßñƒ¯0›¸\æ`ôþþ/Jr
÷Œw´Ùìç阥²�O:ôÀ×Ç/ÚrEÏè’#ÈP-ùb»Ÿ·]Ùí=äñÅÅ´8½Kö?´­ÿ‘ý§Pý…�ýŠ<Ã\ö
  ÐRiŸB0»År •oTVKj®½¢–Ú�²Nëb	ŒœîFH¬)ö²§ì¿Pí2Ðýk¨Ý~ðþ>æpn HÁðmÓ_Qåzïî?½á¡Ù-=øQ/ðî>¢ú<vC%TˆËb¤dê�hW úø]>ãk^ÎH¬Ö›}7^™qÝV|ÙVå‚ÐÃÄsõ`¹bl‘Ñú¨Lúox¯Œo‹…#Núú3F_2b<ŸœŸ¸24b•š¡óD4K¡¼)„¤ÆàLsø1A”2ŽÑáÁΔ©Š/Ä{Å«�%
À¯*w¦)Ÿ(çbɸKÙ›°nUdƒ"°GŽ:bý•:�‚ZãÒbvkâ+°=ßØWô^glpj¦wD¨ä±é?‹ã¤ã÷+·ãéóÕQÅrz‘Ç¢pßeŸA€­ûz{ê¥t¢ÀK	Õ©Jbô
 endobj
-1877 0 obj <<
+1889 0 obj <<
 /Type /Page
-/Contents 1878 0 R
-/Resources 1876 0 R
+/Contents 1890 0 R
+/Resources 1888 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1855 0 R
-/Annots [ 1880 0 R ]
+/Parent 1867 0 R
+/Annots [ 1892 0 R ]
 >> endobj
-1880 0 obj <<
+1892 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [280.2146 145.3358 375.7455 158.0731]
 /Subtype /Link
 /A << /S /GoTo /D (root_delegation_only) >>
 >> endobj
-1879 0 obj <<
-/D [1877 0 R /XYZ 85.0394 794.5015 null]
+1891 0 obj <<
+/D [1889 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1876 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R /F21 930 0 R >>
+1888 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1884 0 obj <<
+1896 0 obj <<
 /Length 3121      
 /Filter /FlateDecode
 >>
@@ -8756,125 +8818,125 @@ xÚµ[Isã6¾ûWè¹*B°ÄÑé¸;N¥ÝÛ9Ì$9Ðm+-‘ŠHµãùõóŠ›@wÅS]]‚À�oLJåÉlFᛩ„$†›™6’(Ê
 	ëx­ñxü„ÏC¹¯ç[ÂHªÕÄØ7¨	C†Ò¢|³áØ5ñk°è4ÛÈîó=°U™-êz3Loœ(©DT{ªï’MÅÝÑÿ6\ñ¢Ï¶¸‚E²›„™ÀUÛÑhróð¸Ë©_‘Ú(Ñ	3ÑÀ7 	+ú²¢<K`­âYíˆ9Í2�iU]Fø\}°Lh"ÕÝ`Ê»?•åD*ÚÑþ6è˜=åpÂzG~#!à<:­-:pÔÝžÄW³Ëa0!ðµ /iœZ¡g}1º-„ÿþ:ãÿ¡Æñ¯X¤†ý{ÊO,¸¿LAˆ7
 
7ÉpRø¿èšþ?t­êhendstream
 endobj
-1883 0 obj <<
+1895 0 obj <<
 /Type /Page
-/Contents 1884 0 R
-/Resources 1882 0 R
+/Contents 1896 0 R
+/Resources 1894 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1901 0 R
-/Annots [ 1888 0 R 1889 0 R 1890 0 R 1891 0 R 1892 0 R 1893 0 R 1894 0 R 1895 0 R 1896 0 R 1897 0 R 1898 0 R 1899 0 R 1900 0 R ]
+/Parent 1913 0 R
+/Annots [ 1900 0 R 1901 0 R 1902 0 R 1903 0 R 1904 0 R 1905 0 R 1906 0 R 1907 0 R 1908 0 R 1909 0 R 1910 0 R 1911 0 R 1912 0 R ]
 >> endobj
-1888 0 obj <<
+1900 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [284.2769 576.5908 352.9489 588.6504]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1889 0 obj <<
+1901 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [282.0654 546.6312 350.7374 558.6908]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1890 0 obj <<
+1902 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [311.9531 516.6716 380.6251 528.7313]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1891 0 obj <<
+1903 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [299.7586 486.712 368.4306 498.7717]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1892 0 obj <<
+1904 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [292.0084 456.7525 360.6804 468.8121]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1893 0 obj <<
+1905 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [330.7921 426.7929 399.4641 438.8525]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_policies) >>
 >> endobj
-1894 0 obj <<
+1906 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [401.5962 396.8333 470.2682 408.8929]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1895 0 obj <<
+1907 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [257.6971 211.3132 326.3691 223.3728]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1896 0 obj <<
+1908 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [310.7975 181.3536 379.4695 193.4133]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1897 0 obj <<
+1909 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [308.6055 151.394 377.2775 163.4537]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1898 0 obj <<
+1910 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [294.1999 121.4345 362.8719 133.4941]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1899 0 obj <<
+1911 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [303.0862 91.4749 371.7582 103.5345]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1900 0 obj <<
+1912 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [332.9347 61.5153 401.6067 73.5749]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1885 0 obj <<
-/D [1883 0 R /XYZ 56.6929 794.5015 null]
+1897 0 obj <<
+/D [1895 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-598 0 obj <<
-/D [1883 0 R /XYZ 56.6929 769.5949 null]
+606 0 obj <<
+/D [1895 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-1886 0 obj <<
-/D [1883 0 R /XYZ 56.6929 752.4108 null]
+1898 0 obj <<
+/D [1895 0 R /XYZ 56.6929 752.4108 null]
 >> endobj
-602 0 obj <<
-/D [1883 0 R /XYZ 56.6929 632.5933 null]
+610 0 obj <<
+/D [1895 0 R /XYZ 56.6929 632.5933 null]
 >> endobj
-1887 0 obj <<
-/D [1883 0 R /XYZ 56.6929 607.7857 null]
+1899 0 obj <<
+/D [1895 0 R /XYZ 56.6929 607.7857 null]
 >> endobj
-1882 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+1894 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1904 0 obj <<
+1916 0 obj <<
 /Length 3094      
 /Filter /FlateDecode
 >>
@@ -8890,99 +8952,99 @@ xÚµ[[oã6~ϯ0úR¨¹"Åëã´ÍtSlgv3)v�¶Š-'jdɵäIÓ_¿‡WëJMÑ)Kä'žsÈ�çB)x•À?¼’%©¢+¡(b
 	‰£HÇ£Sð)á!²Ù‚V§%”ã>*m:¦Y®wbÒ.ä×次—Cþqɽ«Ý /L�N-Mš9•ùÛyböHcž–4AœÑ…„¼‹ŠÐÒ£L¦úûÞh³™;�ÅÄÅÔ„üáyO×Wà¿×Š˜´
 ½]{†¾O¿�Š}Ùª(L˜`]“£Äsð¸ñ£Qÿñ$°ˆ®€ÇÄuŽ´ð‰J	^úÀËcbŸwŒ=Òlõ¹Ø¨Z& Kcf$²ÿz]hò®ÌÏï‹æÃeM`Í8Ÿ¹5{"˜ì{µîÑQ3‡cþ‰×ê0‹,>Ó
Ua8Ò4“ü©.Cúûý	iðß�üå?¸ü
ï�è’ÅŽ$QÂ+¥W£-ÇR‰˜$bBõÿ\‘¡‰endstream
 endobj
-1903 0 obj <<
+1915 0 obj <<
 /Type /Page
-/Contents 1904 0 R
-/Resources 1902 0 R
+/Contents 1916 0 R
+/Resources 1914 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1901 0 R
-/Annots [ 1906 0 R 1907 0 R 1908 0 R 1909 0 R 1910 0 R 1911 0 R 1912 0 R 1913 0 R 1914 0 R 1915 0 R 1916 0 R ]
+/Parent 1913 0 R
+/Annots [ 1918 0 R 1919 0 R 1920 0 R 1921 0 R 1922 0 R 1923 0 R 1924 0 R 1925 0 R 1926 0 R 1927 0 R 1928 0 R ]
 >> endobj
-1906 0 obj <<
+1918 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [387.8612 737.8483 449.0612 749.9079]
 /Subtype /Link
 /A << /S /GoTo /D (options) >>
 >> endobj
-1907 0 obj <<
+1919 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [414.4213 707.9148 483.0933 719.9744]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1908 0 obj <<
+1920 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [330.3165 677.9813 398.9885 690.0409]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1909 0 obj <<
+1921 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [259.4835 522.3818 328.1555 534.4414]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1910 0 obj <<
+1922 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [172.152 462.6742 267.6829 474.4748]
 /Subtype /Link
 /A << /S /GoTo /D (root_delegation_only) >>
 >> endobj
-1911 0 obj <<
+1923 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [352.4539 211.1828 426.1073 223.2424]
 /Subtype /Link
 /A << /S /GoTo /D (server_resource_limits) >>
 >> endobj
-1912 0 obj <<
+1924 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [387.5019 181.2493 456.1739 193.3089]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1913 0 obj <<
+1925 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [381.9629 151.3158 450.6349 163.3754]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1914 0 obj <<
+1926 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [398.5803 121.3823 467.2523 133.4419]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1915 0 obj <<
+1927 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [393.0412 91.4488 461.7132 103.5084]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1916 0 obj <<
+1928 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [255.0796 61.5153 323.7516 73.5749]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1905 0 obj <<
-/D [1903 0 R /XYZ 85.0394 794.5015 null]
+1917 0 obj <<
+/D [1915 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1902 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F48 1228 0 R /F41 1208 0 R >>
+1914 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F48 1238 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1919 0 obj <<
+1931 0 obj <<
 /Length 2875      
 /Filter /FlateDecode
 >>
@@ -8998,64 +9060,64 @@ m3;H¡“8EF¨ú­8�}3R3'«28سsÓU¹-uº*'©^ø\Çegz›Ok�¤FTè’A G"“]¨"+Ë;YÙèTd
 ´cZ7­F’Ñ£s*0’i(ß=þÞ7´<fÎSÖô?´
 uQþŒÝÃy¿uÜ2Lvz’ÔM†³M/iK¿‹9�»–ÐiØE¡þVÅ|#Ð3r>j?¡DjÑ
е\)ÛQãÛã®kL_®˜3§±ç4Ër«ÚæNA/ŠO>˜õ+€§-3ƉIÿ'¡i5sMÿ|À0%řϯIfâó+Éôwiÿú\óg™†ƒÝÄÚIf°x÷#˜�³.%Z«{¤Eú_
Àr-&œäÌfpd8Z0…±(=ipίø5T.™Ò<Ÿrz’™Ö¡7Ó8¼,`ƒðz#«Á_à™û‡€Ç_I)ƒâk½tÝ`’ *žgÃÀà@—¬QýÄ÷D'endstream
 endobj
-1918 0 obj <<
+1930 0 obj <<
 /Type /Page
-/Contents 1919 0 R
-/Resources 1917 0 R
+/Contents 1931 0 R
+/Resources 1929 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1901 0 R
-/Annots [ 1921 0 R 1922 0 R 1923 0 R 1924 0 R 1925 0 R 1926 0 R ]
+/Parent 1913 0 R
+/Annots [ 1933 0 R 1934 0 R 1935 0 R 1936 0 R 1937 0 R 1938 0 R ]
 >> endobj
-1921 0 obj <<
+1933 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [283.1811 736.3425 356.8344 748.4021]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1922 0 obj <<
+1934 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [287.6042 704.9032 356.2762 716.9628]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1923 0 obj <<
+1935 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [352.879 155.8332 426.5323 167.8928]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1924 0 obj <<
+1936 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [334.0699 124.3939 407.7232 136.4535]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1925 0 obj <<
+1937 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [373.9 92.9546 447.5533 105.0142]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1926 0 obj <<
+1938 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [319.6839 61.5153 393.3372 73.5749]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1920 0 obj <<
-/D [1918 0 R /XYZ 56.6929 794.5015 null]
+1932 0 obj <<
+/D [1930 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1917 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F48 1228 0 R /F41 1208 0 R >>
+1929 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F48 1238 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1929 0 obj <<
+1941 0 obj <<
 /Length 3362      
 /Filter /FlateDecode
 >>
@@ -9074,113 +9136,113 @@ xÚµ[[“Û¶~ß_¡·hg*”¸É“ã¬Sw§µ7ÓN“<p%îŠ�D:"µÎö×÷àºI�Û‰3ž‚àáÁ¹|8PÆ«þá•â¨ š­¤fˆ
 »dôʇï_%Ê—Ë(Æ¡
|ÿy
í¨KµP[ûZÀ³Ï`†'ó§®X
 ”›¶an5øó;ûwÿ' çÿ!Å$¢PÊ\¼H™3"/”\ëéAšB\9#úÿ
 endobj
-1928 0 obj <<
+1940 0 obj <<
 /Type /Page
-/Contents 1929 0 R
-/Resources 1927 0 R
+/Contents 1941 0 R
+/Resources 1939 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1901 0 R
-/Annots [ 1931 0 R 1932 0 R 1933 0 R 1934 0 R 1935 0 R 1936 0 R 1937 0 R 1938 0 R 1939 0 R 1940 0 R 1941 0 R 1942 0 R 1943 0 R ]
+/Parent 1913 0 R
+/Annots [ 1943 0 R 1944 0 R 1945 0 R 1946 0 R 1947 0 R 1948 0 R 1949 0 R 1950 0 R 1951 0 R 1952 0 R 1953 0 R 1954 0 R 1955 0 R ]
 >> endobj
-1931 0 obj <<
+1943 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [335.4973 737.5313 404.1693 749.5909]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1932 0 obj <<
+1944 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [363.1733 707.2808 431.8453 719.3404]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1933 0 obj <<
+1945 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [365.365 677.0302 434.037 689.0899]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1934 0 obj <<
+1946 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [393.041 646.7797 461.713 658.8394]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1935 0 obj <<
+1947 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [402.9837 616.5292 471.6557 628.5889]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1936 0 obj <<
+1948 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [320.374 586.2787 389.046 598.3384]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1937 0 obj <<
+1949 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [348.05 556.0282 416.722 568.0879]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1938 0 obj <<
+1950 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [488.512 525.7777 561.5676 537.8373]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1939 0 obj <<
+1951 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [397.3443 495.5272 467.1586 507.5868]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1940 0 obj <<
+1952 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [321.49 453.3215 382.69 465.3812]
 /Subtype /Link
 /A << /S /GoTo /D (options) >>
 >> endobj
-1941 0 obj <<
+1953 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [357.6499 350.6148 436.0651 362.6745]
 /Subtype /Link
 /A << /S /GoTo /D (man.dnssec-keygen) >>
 >> endobj
-1942 0 obj <<
+1954 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [455.3558 350.6148 533.7708 362.6745]
 /Subtype /Link
 /A << /S /GoTo /D (man.dnssec-settime) >>
 >> endobj
-1943 0 obj <<
+1955 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [317.0267 61.5153 385.6987 73.5749]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1930 0 obj <<
-/D [1928 0 R /XYZ 85.0394 794.5015 null]
+1942 0 obj <<
+/D [1940 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1927 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F48 1228 0 R /F55 1311 0 R /F41 1208 0 R >>
+1939 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F48 1238 0 R /F55 1321 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1946 0 obj <<
+1958 0 obj <<
 /Length 3449      
 /Filter /FlateDecode
 >>
@@ -9201,42 +9263,42 @@ G±CÌÓe·²´Ã‚Sœox./ê²à¹^ZZ| (€®šq½qï›qXå�©{>Ÿ¤”O¹$ëq´fä8@äÚ‘Ãl	$veT¢æ§áìê�
 ö.ˆñá.+Ñ	ïìäk5*aÁ‡ìRBA¾Û6£8œÕŲéJÈÐígBU8ºçâûÃííõ‹+iן�!h
 ì©Îé+îà‹ÚØsõufV­�|0[gØ".܇²ª©—¾Ç~ê)ëX&~áìþçŸ
ö¿‘Œ!3æÈOeB¸$Øœ8¢Pr2²ˆHsHû
 endobj
-1945 0 obj <<
+1957 0 obj <<
 /Type /Page
-/Contents 1946 0 R
-/Resources 1944 0 R
+/Contents 1958 0 R
+/Resources 1956 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1901 0 R
-/Annots [ 1948 0 R 1949 0 R ]
+/Parent 1913 0 R
+/Annots [ 1960 0 R 1961 0 R ]
 >> endobj
-1948 0 obj <<
+1960 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [328.5503 736.8562 402.2036 748.9158]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1949 0 obj <<
+1961 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [403.748 705.9305 472.42 717.9902]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1947 0 obj <<
-/D [1945 0 R /XYZ 56.6929 794.5015 null]
+1959 0 obj <<
+/D [1957 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-606 0 obj <<
-/D [1945 0 R /XYZ 56.6929 689.3081 null]
+614 0 obj <<
+/D [1957 0 R /XYZ 56.6929 689.3081 null]
 >> endobj
-1317 0 obj <<
-/D [1945 0 R /XYZ 56.6929 663.0018 null]
+1327 0 obj <<
+/D [1957 0 R /XYZ 56.6929 663.0018 null]
 >> endobj
-1944 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F53 1303 0 R /F48 1228 0 R >>
+1956 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F53 1313 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1952 0 obj <<
+1964 0 obj <<
 /Length 2974      
 /Filter /FlateDecode
 >>
@@ -9250,28 +9312,28 @@ xÚÝZKsǾóWà�˜FóžÙœBK”BǦš)–ÀRÜÀÂØ¥håק{zv1.2)Ç•bçÝ3Óóõ+FþÄÈÆU¦G.Ó
 Íœ±pâ
0Òó%–”óöbç7UÎ2«¿(ÖoWl¡´;ÞÄŠ¾“ ëîy;’’3­Œ…”†•ô;Ìe‚OcÑ
 ñZ,ìA|bY¯*Êmè„î�'IÃJ

 endobj
-1951 0 obj <<
+1963 0 obj <<
 /Type /Page
-/Contents 1952 0 R
-/Resources 1950 0 R
+/Contents 1964 0 R
+/Resources 1962 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1901 0 R
+/Parent 1913 0 R
 >> endobj
-1953 0 obj <<
-/D [1951 0 R /XYZ 85.0394 794.5015 null]
+1965 0 obj <<
+/D [1963 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1954 0 obj <<
-/D [1951 0 R /XYZ 85.0394 746.113 null]
+1966 0 obj <<
+/D [1963 0 R /XYZ 85.0394 746.113 null]
 >> endobj
-1955 0 obj <<
-/D [1951 0 R /XYZ 85.0394 734.1579 null]
+1967 0 obj <<
+/D [1963 0 R /XYZ 85.0394 734.1579 null]
 >> endobj
-1950 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F53 1303 0 R /F41 1208 0 R /F21 930 0 R /F62 1351 0 R >>
-/XObject << /Im2 1340 0 R >>
+1962 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F53 1313 0 R /F41 1218 0 R /F21 938 0 R /F62 1361 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1958 0 obj <<
+1970 0 obj <<
 /Length 2662      
 /Filter /FlateDecode
 >>
@@ -9290,40 +9352,40 @@ b·-û)äžÊ
 ¦è‚Ì*͇©
qrSša9ROÅ.¹g.Ýv®·ƒj­ ÃÏnI…öÌyÊüÙ[”Å�KrG(bÐm
œHùXѹ[šm‡«[ÑõcÉw* Û|ÂÆÛ«˜
 Bû‚A™žÄ�™p± üÚÔn÷«¢4ǩǧ$œÊY‰x|Ÿnò‰šVûÊl\�ãZ c>è[;Iÿ».«Ãõãð8gm5“K@	÷*¨«§x¸YÂ<áÛGRwú%YõÁ”qçÞ6›'´®Ò'� Ð¿¹º$¶à*p‹ä¦ËÚâÎtÔãyñæ[Ø‘k/î½o›¤8®œ¹Ñ›‰ƒpÆÕfCŒ�øüD”îcWB¦Ã½…tÀVB9, ¯p}ûÎäŒnO7Ô†¸$-LØíïÊb¸Ça�•¾¤2ƒÊŸ¸ òðƃüÚ<Ñ›�Ûj›>ºåïÌ ]¾]²™{•ü]T»ÒT0xÀ÷�ÇÇÀx»¾a#
 endobj
-1957 0 obj <<
+1969 0 obj <<
 /Type /Page
-/Contents 1958 0 R
-/Resources 1956 0 R
+/Contents 1970 0 R
+/Resources 1968 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1962 0 R
+/Parent 1974 0 R
 >> endobj
-1959 0 obj <<
-/D [1957 0 R /XYZ 56.6929 794.5015 null]
+1971 0 obj <<
+/D [1969 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-610 0 obj <<
-/D [1957 0 R /XYZ 56.6929 247.636 null]
+618 0 obj <<
+/D [1969 0 R /XYZ 56.6929 247.636 null]
 >> endobj
-1960 0 obj <<
-/D [1957 0 R /XYZ 56.6929 215.5303 null]
+1972 0 obj <<
+/D [1969 0 R /XYZ 56.6929 215.5303 null]
 >> endobj
-614 0 obj <<
-/D [1957 0 R /XYZ 56.6929 215.5303 null]
+622 0 obj <<
+/D [1969 0 R /XYZ 56.6929 215.5303 null]
 >> endobj
-1240 0 obj <<
-/D [1957 0 R /XYZ 56.6929 185.6746 null]
+1250 0 obj <<
+/D [1969 0 R /XYZ 56.6929 185.6746 null]
 >> endobj
-618 0 obj <<
-/D [1957 0 R /XYZ 56.6929 129.296 null]
+626 0 obj <<
+/D [1969 0 R /XYZ 56.6929 129.296 null]
 >> endobj
-1961 0 obj <<
-/D [1957 0 R /XYZ 56.6929 106.9848 null]
+1973 0 obj <<
+/D [1969 0 R /XYZ 56.6929 106.9848 null]
 >> endobj
-1956 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R /F62 1351 0 R /F21 930 0 R /F53 1303 0 R >>
-/XObject << /Im2 1340 0 R >>
+1968 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R /F62 1361 0 R /F21 938 0 R /F53 1313 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1965 0 obj <<
+1977 0 obj <<
 /Length 3190      
 /Filter /FlateDecode
 >>
@@ -9342,48 +9404,48 @@ lŠ$qýúŠ¶¶3®»,²™ã2à}ßÔø†`œkÇÖPž%ÎÁĪÇw É<	ªô {Ù�°uOøŠke	¥v,×–†…‘¿F8y|~*Îl
 
É.ÕÚ–^B²Òèó'„zCfبÿ…B2Ò†BÈÚÀ!y	ÎwÁi¶!P	ã5a³â®t×&²Ç` qê.bÏL@ðØDž´ï”ùÛÙø+¾æ‹âP0=æL-Š	r%¿€®kËŸè:Æ0|HÈ%²œ FÙé�t½¹ðÆ	mÇ�Þ	Ù,Ó~š°�¢w;BŸ¿Ÿ£ïŠbÞ~ÍÓ•a^>8›‹ýg©1~lVCÒã¯Úà�>¨p*€£_éI›…it•�¨æYŽqüùæÈ='
 ”S2j²H0')-Çm+ÿ©päÉÇëÍyx²ÎÞÿL±ñendstream
 endobj
-1964 0 obj <<
+1976 0 obj <<
 /Type /Page
-/Contents 1965 0 R
-/Resources 1963 0 R
+/Contents 1977 0 R
+/Resources 1975 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1962 0 R
-/Annots [ 1967 0 R 1968 0 R ]
+/Parent 1974 0 R
+/Annots [ 1979 0 R 1980 0 R ]
 >> endobj
-1967 0 obj <<
+1979 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [341.1654 743.8714 414.8187 755.9311]
 /Subtype /Link
 /A << /S /GoTo /D (the_sortlist_statement) >>
 >> endobj
-1968 0 obj <<
+1980 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [434.6742 743.8714 508.3275 755.9311]
 /Subtype /Link
 /A << /S /GoTo /D (rrset_ordering) >>
 >> endobj
-1966 0 obj <<
-/D [1964 0 R /XYZ 85.0394 794.5015 null]
+1978 0 obj <<
+/D [1976 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1969 0 obj <<
-/D [1964 0 R /XYZ 85.0394 726.9349 null]
+1981 0 obj <<
+/D [1976 0 R /XYZ 85.0394 726.9349 null]
 >> endobj
-1970 0 obj <<
-/D [1964 0 R /XYZ 85.0394 714.9798 null]
+1982 0 obj <<
+/D [1976 0 R /XYZ 85.0394 714.9798 null]
 >> endobj
-1971 0 obj <<
-/D [1964 0 R /XYZ 85.0394 534.8553 null]
+1983 0 obj <<
+/D [1976 0 R /XYZ 85.0394 534.8553 null]
 >> endobj
-1972 0 obj <<
-/D [1964 0 R /XYZ 85.0394 522.9001 null]
+1984 0 obj <<
+/D [1976 0 R /XYZ 85.0394 522.9001 null]
 >> endobj
-1963 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F39 1151 0 R >>
+1975 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1975 0 obj <<
+1987 0 obj <<
 /Length 2766      
 /Filter /FlateDecode
 >>
@@ -9403,27 +9465,27 @@ T
›WݸH—IÅMèæÉJ·H&£F©\€þ°°Ê~Ÿ
v;Î~íOÅÚk?¯½Â†óåÆt¤b
  „ò”
 tB¤
 endobj
-1974 0 obj <<
+1986 0 obj <<
 /Type /Page
-/Contents 1975 0 R
-/Resources 1973 0 R
+/Contents 1987 0 R
+/Resources 1985 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1962 0 R
+/Parent 1974 0 R
 >> endobj
-1976 0 obj <<
-/D [1974 0 R /XYZ 56.6929 794.5015 null]
+1988 0 obj <<
+/D [1986 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1977 0 obj <<
-/D [1974 0 R /XYZ 56.6929 133.9784 null]
+1989 0 obj <<
+/D [1986 0 R /XYZ 56.6929 133.9784 null]
 >> endobj
-1978 0 obj <<
-/D [1974 0 R /XYZ 56.6929 122.0233 null]
+1990 0 obj <<
+/D [1986 0 R /XYZ 56.6929 122.0233 null]
 >> endobj
-1973 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F39 1151 0 R /F41 1208 0 R >>
+1985 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F39 1161 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1981 0 obj <<
+1993 0 obj <<
 /Length 3138      
 /Filter /FlateDecode
 >>
@@ -9447,39 +9509,39 @@ w÷Š*þ÷’å	�§u“Õ6žšS£ÊóŒiè\GclÉšLº`ê<'­b"˛Ŷ˜ç™èÄ‹…Õ*éÅH³ÎS²„ŽCrá˜	 =¢ |y™QÇ
 �H�WÌaË¿°Ÿ%«’çüÄD¸€®—�`PAøô¸ÿ…u ÈÝqôœshg5T
ŽB@^ß5@RP‹ŠÏ«¥·á_8d$¸x¢Âç\C)FV»†}^	=ö_H	Ÿñ#åŸPêdBµ±ös¤” ‘0Ã�ÿH)c-¸�·ðghLÙZ
HX¥<D¯¤O –ûñÚC-ìðOY8•ß=™½
 
fGS0ÇóÕë¾"äø '¤BÑÎj¤·ÙÒÈçÔ„/ï²âp›I
 endobj
-1980 0 obj <<
+1992 0 obj <<
 /Type /Page
-/Contents 1981 0 R
-/Resources 1979 0 R
+/Contents 1993 0 R
+/Resources 1991 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1962 0 R
+/Parent 1974 0 R
 >> endobj
-1982 0 obj <<
-/D [1980 0 R /XYZ 85.0394 794.5015 null]
+1994 0 obj <<
+/D [1992 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-622 0 obj <<
-/D [1980 0 R /XYZ 85.0394 513.3136 null]
+630 0 obj <<
+/D [1992 0 R /XYZ 85.0394 513.3136 null]
 >> endobj
-1983 0 obj <<
-/D [1980 0 R /XYZ 85.0394 488.6113 null]
+1995 0 obj <<
+/D [1992 0 R /XYZ 85.0394 488.6113 null]
 >> endobj
-1984 0 obj <<
-/D [1980 0 R /XYZ 85.0394 303.0671 null]
+1996 0 obj <<
+/D [1992 0 R /XYZ 85.0394 303.0671 null]
 >> endobj
-1985 0 obj <<
-/D [1980 0 R /XYZ 85.0394 291.112 null]
+1997 0 obj <<
+/D [1992 0 R /XYZ 85.0394 291.112 null]
 >> endobj
-1986 0 obj <<
-/D [1980 0 R /XYZ 85.0394 122.9426 null]
+1998 0 obj <<
+/D [1992 0 R /XYZ 85.0394 122.9426 null]
 >> endobj
-1987 0 obj <<
-/D [1980 0 R /XYZ 85.0394 110.9875 null]
+1999 0 obj <<
+/D [1992 0 R /XYZ 85.0394 110.9875 null]
 >> endobj
-1979 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R >>
+1991 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1990 0 obj <<
+2002 0 obj <<
 /Length 2942      
 /Filter /FlateDecode
 >>
@@ -9494,45 +9556,45 @@ xÚÍ]sÛ8î=¿Â÷ ÌÔ\~éëÞ²m²—�6ÝK³3�Ûîƒ,+±feÉ'ÉMs¿þ
 „†¯O‡N˜ð!áa¿£/93r@í�C„NY`^_»€px:A˜ˆÃ½—¦£¾�nq؆wrrçääØÉIÞ;Œâ èU>¥
#Ù~+
xyâóWܤ*…¸;ÖRËj¢^˜ø(™c�ùžáG±ÐqDZvæ*ð)?Òk
Æï"ÍCàŸŸØÄRCa"ˆæ«Q„i�j¶w«dEG�³¼TñeS•yé‚!„�ªªŽRD·8åy5‘?ÜWjeäTZ9g’Ä>ËÇ~59
þÔeâ7.röléॿ¨ÙýªÈböžèé£Ó â09òL¹íÉèëJ
 �U’ǼÿGÛ÷'endstream
 endobj
-1989 0 obj <<
+2001 0 obj <<
 /Type /Page
-/Contents 1990 0 R
-/Resources 1988 0 R
+/Contents 2002 0 R
+/Resources 2000 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1962 0 R
+/Parent 1974 0 R
 >> endobj
-1991 0 obj <<
-/D [1989 0 R /XYZ 56.6929 794.5015 null]
+2003 0 obj <<
+/D [2001 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-626 0 obj <<
-/D [1989 0 R /XYZ 56.6929 723.7047 null]
+634 0 obj <<
+/D [2001 0 R /XYZ 56.6929 723.7047 null]
 >> endobj
-1992 0 obj <<
-/D [1989 0 R /XYZ 56.6929 699.3651 null]
+2004 0 obj <<
+/D [2001 0 R /XYZ 56.6929 699.3651 null]
 >> endobj
-1993 0 obj <<
-/D [1989 0 R /XYZ 56.6929 499.5106 null]
+2005 0 obj <<
+/D [2001 0 R /XYZ 56.6929 499.5106 null]
 >> endobj
-1994 0 obj <<
-/D [1989 0 R /XYZ 56.6929 487.5554 null]
+2006 0 obj <<
+/D [2001 0 R /XYZ 56.6929 487.5554 null]
 >> endobj
-630 0 obj <<
-/D [1989 0 R /XYZ 56.6929 352.0214 null]
+638 0 obj <<
+/D [2001 0 R /XYZ 56.6929 352.0214 null]
 >> endobj
-1995 0 obj <<
-/D [1989 0 R /XYZ 56.6929 324.7169 null]
+2007 0 obj <<
+/D [2001 0 R /XYZ 56.6929 324.7169 null]
 >> endobj
-1996 0 obj <<
-/D [1989 0 R /XYZ 56.6929 283.2444 null]
+2008 0 obj <<
+/D [2001 0 R /XYZ 56.6929 283.2444 null]
 >> endobj
-1997 0 obj <<
-/D [1989 0 R /XYZ 56.6929 271.2892 null]
+2009 0 obj <<
+/D [2001 0 R /XYZ 56.6929 271.2892 null]
 >> endobj
-1988 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F41 1208 0 R /F21 930 0 R /F39 1151 0 R >>
+2000 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F41 1218 0 R /F21 938 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2000 0 obj <<
+2012 0 obj <<
 /Length 2486      
 /Filter /FlateDecode
 >>
@@ -9550,52 +9612,52 @@ zXÆ»°¬ª¡½SoqìX
‚<´¶7
 ˆ;5¯Œ¨È?GœP7™W˜Ë¾¯Ë²~²'ñ	Ìšr›e÷Ø·¬[ãd$h
 Þ	í×0Ù~!3‚<ö¾Úä6%ó±Âº·>.y÷NÂ<,‚ÑS�%…¹rÀ-ˆ3eέ¬ñ›UÏ8ØUŸ
 endobj
-1999 0 obj <<
+2011 0 obj <<
 /Type /Page
-/Contents 2000 0 R
-/Resources 1998 0 R
+/Contents 2012 0 R
+/Resources 2010 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1962 0 R
+/Parent 1974 0 R
 >> endobj
-2001 0 obj <<
-/D [1999 0 R /XYZ 85.0394 794.5015 null]
+2013 0 obj <<
+/D [2011 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-634 0 obj <<
-/D [1999 0 R /XYZ 85.0394 769.5949 null]
+642 0 obj <<
+/D [2011 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-2002 0 obj <<
-/D [1999 0 R /XYZ 85.0394 749.4437 null]
+2014 0 obj <<
+/D [2011 0 R /XYZ 85.0394 749.4437 null]
 >> endobj
-2003 0 obj <<
-/D [1999 0 R /XYZ 85.0394 660.1505 null]
+2015 0 obj <<
+/D [2011 0 R /XYZ 85.0394 660.1505 null]
 >> endobj
-2004 0 obj <<
-/D [1999 0 R /XYZ 85.0394 648.1953 null]
+2016 0 obj <<
+/D [2011 0 R /XYZ 85.0394 648.1953 null]
 >> endobj
-638 0 obj <<
-/D [1999 0 R /XYZ 85.0394 449.4639 null]
+646 0 obj <<
+/D [2011 0 R /XYZ 85.0394 449.4639 null]
 >> endobj
-2005 0 obj <<
-/D [1999 0 R /XYZ 85.0394 424.0768 null]
+2017 0 obj <<
+/D [2011 0 R /XYZ 85.0394 424.0768 null]
 >> endobj
-642 0 obj <<
-/D [1999 0 R /XYZ 85.0394 352.0618 null]
+650 0 obj <<
+/D [2011 0 R /XYZ 85.0394 352.0618 null]
 >> endobj
-2006 0 obj <<
-/D [1999 0 R /XYZ 85.0394 323.4047 null]
+2018 0 obj <<
+/D [2011 0 R /XYZ 85.0394 323.4047 null]
 >> endobj
-646 0 obj <<
-/D [1999 0 R /XYZ 85.0394 272.2519 null]
+654 0 obj <<
+/D [2011 0 R /XYZ 85.0394 272.2519 null]
 >> endobj
-2007 0 obj <<
-/D [1999 0 R /XYZ 85.0394 246.3845 null]
+2019 0 obj <<
+/D [2011 0 R /XYZ 85.0394 246.3845 null]
 >> endobj
-1998 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R /F41 1208 0 R /F62 1351 0 R /F63 1354 0 R /F11 1441 0 R /F53 1303 0 R >>
-/XObject << /Im2 1340 0 R >>
+2010 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R /F41 1218 0 R /F62 1361 0 R /F63 1364 0 R /F11 1451 0 R /F53 1313 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2010 0 obj <<
+2022 0 obj <<
 /Length 2114      
 /Filter /FlateDecode
 >>
@@ -9611,40 +9673,40 @@ v™O…ºU×'ZB~<ø-Wmx~Ke!m

\ 	I©z·}IÁÊ.µ«i“…+[Z<®,�æqelÞB$š
 !דÀÔ‘�ì$"v9­}bÈÈ÷÷¥½A9Ž»[>pÙ\w¬Ê÷RA‘V]˜µ¹Ël£²ÏqÕ|›ß¾’ãXìsЙ�¥5>QÀôŸÃóó)N?Yc¿°
éx´xž�ýµu !%ÂMº	N|‡¤«ø´éÏ®cŽÀq˜Üàx3šþ>šž’ÑÃ�Ÿ®FocÅxŒà)g“áG?yJhw‚mjJ‡=E¸ÔbùÄ7€oZàËZ±Wµz#þ*#ö£†i�î›Ç‡
ÈßÈ”¿�)JJH·<~«
 žò…ýŽO]PØF£J—û°çxW°¾ÿÄó1ôÓî€�àø,Øg³D÷&eà‡µß-øO…,�î–+¿ÁjϲÊžÖ9âA˜‡°[ 9\ròâÎm£|‡(<ûÇ|½î:º[_-‡ûûý³Ù*¼ì»”­Î=“žÎ÷ÒÜù¢içV¾øgqýËõÍlàƒ{¼—CgvúÏù؃´ãGòÃ÷&Š®·#èФ€Ö ãç
 endobj
-2009 0 obj <<
+2021 0 obj <<
 /Type /Page
-/Contents 2010 0 R
-/Resources 2008 0 R
+/Contents 2022 0 R
+/Resources 2020 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2015 0 R
+/Parent 2027 0 R
 >> endobj
-2011 0 obj <<
-/D [2009 0 R /XYZ 56.6929 794.5015 null]
+2023 0 obj <<
+/D [2021 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-650 0 obj <<
-/D [2009 0 R /XYZ 56.6929 769.5949 null]
+658 0 obj <<
+/D [2021 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-2012 0 obj <<
-/D [2009 0 R /XYZ 56.6929 750.9871 null]
+2024 0 obj <<
+/D [2021 0 R /XYZ 56.6929 750.9871 null]
 >> endobj
-654 0 obj <<
-/D [2009 0 R /XYZ 56.6929 522.5618 null]
+662 0 obj <<
+/D [2021 0 R /XYZ 56.6929 522.5618 null]
 >> endobj
-2013 0 obj <<
-/D [2009 0 R /XYZ 56.6929 498.7164 null]
+2025 0 obj <<
+/D [2021 0 R /XYZ 56.6929 498.7164 null]
 >> endobj
-658 0 obj <<
-/D [2009 0 R /XYZ 56.6929 412.0682 null]
+666 0 obj <<
+/D [2021 0 R /XYZ 56.6929 412.0682 null]
 >> endobj
-2014 0 obj <<
-/D [2009 0 R /XYZ 56.6929 383.338 null]
+2026 0 obj <<
+/D [2021 0 R /XYZ 56.6929 383.338 null]
 >> endobj
-2008 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F53 1303 0 R /F41 1208 0 R /F62 1351 0 R /F63 1354 0 R >>
-/XObject << /Im2 1340 0 R >>
+2020 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F53 1313 0 R /F41 1218 0 R /F62 1361 0 R /F63 1364 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2018 0 obj <<
+2030 0 obj <<
 /Length 3334      
 /Filter /FlateDecode
 >>
@@ -9661,33 +9723,33 @@ r4¡90ǶP…¨4ŒxtL"t(1àYë3E<åÆ„
 +×Y·¼£AL_°âìñý˜qw¦ílkÇGŠó&·#�ø^rëHõr�nÇa¹…P/IEôœÜ
 *�ÚÐîqóüû…©Ù"½ |*]„�Plt•oCoŸbü»RŒAOBïŠ
Z‘PôâAö<f	3=OÒ¢«øP¤4b6ú8ÄjvôÏ]Ó{Š�ÐstÑïEÏá%øñ†‡‘düÅ6Ç�ŒŸ¤Ÿ<MKò$ À›
‘žV|`™ð<M‹<�²2î¯Ú‚�á±îÓ•7×ïM
äæÂWŸ��‡K‚æ¥5ÂÅ'##iãÃáÅ箨1¶µóuîk^!š¶½fµL´2äTn±»¾Ðƒ¡�Ú+ÛÇâLÖÙü(@ È#ç<	•°æ}¸OBMÞ¸¿¿Héuãî2±Vx÷Bš�×oÏ?|˜$£¨¦wÆ=È8Ô¨wx!ü'„>�s†�Öy^Ž¹,b—1Ÿž
8…q¬¢Qþײ èË<NIæò¿}‚š)àÏŽJ=ŽŽ¦äXˆÃ©ÝLôi÷`f}z3:Ѧ’ö*Û
 endobj
-2017 0 obj <<
+2029 0 obj <<
 /Type /Page
-/Contents 2018 0 R
-/Resources 2016 0 R
+/Contents 2030 0 R
+/Resources 2028 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2015 0 R
+/Parent 2027 0 R
 >> endobj
-2019 0 obj <<
-/D [2017 0 R /XYZ 85.0394 794.5015 null]
+2031 0 obj <<
+/D [2029 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2020 0 obj <<
-/D [2017 0 R /XYZ 85.0394 652.0358 null]
+2032 0 obj <<
+/D [2029 0 R /XYZ 85.0394 652.0358 null]
 >> endobj
-2021 0 obj <<
-/D [2017 0 R /XYZ 85.0394 640.0806 null]
+2033 0 obj <<
+/D [2029 0 R /XYZ 85.0394 640.0806 null]
 >> endobj
-662 0 obj <<
-/D [2017 0 R /XYZ 85.0394 217.1748 null]
+670 0 obj <<
+/D [2029 0 R /XYZ 85.0394 217.1748 null]
 >> endobj
-1788 0 obj <<
-/D [2017 0 R /XYZ 85.0394 192.112 null]
+1806 0 obj <<
+/D [2029 0 R /XYZ 85.0394 192.112 null]
 >> endobj
-2016 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F21 930 0 R /F22 953 0 R /F14 956 0 R >>
+2028 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F21 938 0 R /F22 961 0 R /F14 964 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2024 0 obj <<
+2036 0 obj <<
 /Length 2961      
 /Filter /FlateDecode
 >>
@@ -9705,47 +9767,47 @@ JlµÒC¿a©þÀ‚'hr–'“Â×ËH³$UÙ+°Ô’)	;Êÿî‚
¡èl†-M¹°Ÿ�ÍÁ€'ÃæÑIôØÎb›z›:@ðÁ_2
 Ÿ(è)/‰ ŠYöñP¾›1eMc–$RÚX‡“Ò¢;¶vÖ"%`
­2z =(í–* ›×XûRèlLéÔy'TV?L(q3i7¬ÿòVÐÕr[7=b‡Ø9ØR³}n„pŒvØ9Ø�ºZ¯pqØ›³‡ÎÑ?\½ÀQº­YAmÅûð@ØC}ˆI÷Ø»gBßç£G¯/B/&Ú� E
¡p!aß.£ª† »‡<Üs;ÌfáS€ƒý&$?Ø�ÌmÏÊ}óÍ7ãÓx×�ØUAÜd‰J²4‹²�èäX÷ƒ�ðrú§Cž�Ýâ)ž|¼Å
©ñ…þkè³,„­~-ó�°•>¾ç6‡� 5ëÍ:¤À!«ÙvGla|—�ÕX†Lî®1ù£)·. +‹7cn¡ÈîgÞâ1">tAáû¨c¨
 íâ�wîÎ~ôLäãCà´LGÒ7¹Ü”A»á"‘¿Þ„‚¥mu>·!ff^=ZF“»8xîòáoCüË ³àŽ`œéˆšÂÏËò‹ÃY{³ƒ^Dš¾p—!Ð÷Òž)·†‚°_yÿ?\²«endstream
 endobj
-2023 0 obj <<
+2035 0 obj <<
 /Type /Page
-/Contents 2024 0 R
-/Resources 2022 0 R
+/Contents 2036 0 R
+/Resources 2034 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2015 0 R
-/Annots [ 2029 0 R ]
+/Parent 2027 0 R
+/Annots [ 2041 0 R ]
 >> endobj
-2029 0 obj <<
+2041 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [55.6967 179.2302 116.8967 190.6223]
 /Subtype /Link
 /A << /S /GoTo /D (statschannels) >>
 >> endobj
-2025 0 obj <<
-/D [2023 0 R /XYZ 56.6929 794.5015 null]
+2037 0 obj <<
+/D [2035 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-666 0 obj <<
-/D [2023 0 R /XYZ 56.6929 686.6711 null]
+674 0 obj <<
+/D [2035 0 R /XYZ 56.6929 686.6711 null]
 >> endobj
-2026 0 obj <<
-/D [2023 0 R /XYZ 56.6929 654.5655 null]
+2038 0 obj <<
+/D [2035 0 R /XYZ 56.6929 654.5655 null]
 >> endobj
-2027 0 obj <<
-/D [2023 0 R /XYZ 56.6929 592.2384 null]
+2039 0 obj <<
+/D [2035 0 R /XYZ 56.6929 592.2384 null]
 >> endobj
-2028 0 obj <<
-/D [2023 0 R /XYZ 56.6929 580.2832 null]
+2040 0 obj <<
+/D [2035 0 R /XYZ 56.6929 580.2832 null]
 >> endobj
-670 0 obj <<
-/D [2023 0 R /XYZ 56.6929 165.8291 null]
+678 0 obj <<
+/D [2035 0 R /XYZ 56.6929 165.8291 null]
 >> endobj
-1657 0 obj <<
-/D [2023 0 R /XYZ 56.6929 142.8503 null]
+1674 0 obj <<
+/D [2035 0 R /XYZ 56.6929 142.8503 null]
 >> endobj
-2022 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R /F48 1228 0 R >>
+2034 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2032 0 obj <<
+2044 0 obj <<
 /Length 2826      
 /Filter /FlateDecode
 >>
@@ -9766,39 +9828,39 @@ t ØÝÞ"¨
$)u‚´yÜÀòÔÝê
 ¬ùÖÑ}Èâ?��½Â6�ÑR`ÁäqzE!†’ûÝJ
 !ãáÿ&Å«µÆþë{<•endstream
 endobj
-2031 0 obj <<
+2043 0 obj <<
 /Type /Page
-/Contents 2032 0 R
-/Resources 2030 0 R
+/Contents 2044 0 R
+/Resources 2042 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2015 0 R
+/Parent 2027 0 R
 >> endobj
-2033 0 obj <<
-/D [2031 0 R /XYZ 85.0394 794.5015 null]
+2045 0 obj <<
+/D [2043 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-674 0 obj <<
-/D [2031 0 R /XYZ 85.0394 652.2128 null]
+682 0 obj <<
+/D [2043 0 R /XYZ 85.0394 652.2128 null]
 >> endobj
-2034 0 obj <<
-/D [2031 0 R /XYZ 85.0394 627.6341 null]
+2046 0 obj <<
+/D [2043 0 R /XYZ 85.0394 627.6341 null]
 >> endobj
-678 0 obj <<
-/D [2031 0 R /XYZ 85.0394 520.1907 null]
+686 0 obj <<
+/D [2043 0 R /XYZ 85.0394 520.1907 null]
 >> endobj
-2035 0 obj <<
-/D [2031 0 R /XYZ 85.0394 497.8795 null]
+2047 0 obj <<
+/D [2043 0 R /XYZ 85.0394 497.8795 null]
 >> endobj
-2036 0 obj <<
-/D [2031 0 R /XYZ 85.0394 497.8795 null]
+2048 0 obj <<
+/D [2043 0 R /XYZ 85.0394 497.8795 null]
 >> endobj
-2037 0 obj <<
-/D [2031 0 R /XYZ 85.0394 485.9243 null]
+2049 0 obj <<
+/D [2043 0 R /XYZ 85.0394 485.9243 null]
 >> endobj
-2030 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R >>
+2042 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2040 0 obj <<
+2052 0 obj <<
 /Length 2582      
 /Filter /FlateDecode
 >>
@@ -9816,50 +9878,50 @@ iÃZ,joü¼×ïXà*³þ×èÆ%Cë$«Æe¾6n…‚5	¬7ò—_Q`Kï
 Qáq°Q�‘f:
 1E™»7„ªCîͨU
 endobj
-2039 0 obj <<
+2051 0 obj <<
 /Type /Page
-/Contents 2040 0 R
-/Resources 2038 0 R
+/Contents 2052 0 R
+/Resources 2050 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2015 0 R
-/Annots [ 2042 0 R ]
+/Parent 2027 0 R
+/Annots [ 2054 0 R ]
 >> endobj
-2042 0 obj <<
+2054 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [305.1296 588.4542 384.9596 600.5139]
 /Subtype /Link
 /A << /S /GoTo /D (clients-per-query) >>
 >> endobj
-2041 0 obj <<
-/D [2039 0 R /XYZ 56.6929 794.5015 null]
+2053 0 obj <<
+/D [2051 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-682 0 obj <<
-/D [2039 0 R /XYZ 56.6929 352.0981 null]
+690 0 obj <<
+/D [2051 0 R /XYZ 56.6929 352.0981 null]
 >> endobj
-2043 0 obj <<
-/D [2039 0 R /XYZ 56.6929 326.9775 null]
+2055 0 obj <<
+/D [2051 0 R /XYZ 56.6929 326.9775 null]
 >> endobj
-2044 0 obj <<
-/D [2039 0 R /XYZ 56.6929 326.9775 null]
+2056 0 obj <<
+/D [2051 0 R /XYZ 56.6929 326.9775 null]
 >> endobj
-2045 0 obj <<
-/D [2039 0 R /XYZ 56.6929 315.0223 null]
+2057 0 obj <<
+/D [2051 0 R /XYZ 56.6929 315.0223 null]
 >> endobj
-686 0 obj <<
-/D [2039 0 R /XYZ 56.6929 102.2008 null]
+694 0 obj <<
+/D [2051 0 R /XYZ 56.6929 102.2008 null]
 >> endobj
-2046 0 obj <<
-/D [2039 0 R /XYZ 56.6929 77.0802 null]
+2058 0 obj <<
+/D [2051 0 R /XYZ 56.6929 77.0802 null]
 >> endobj
-2047 0 obj <<
-/D [2039 0 R /XYZ 56.6929 77.0802 null]
+2059 0 obj <<
+/D [2051 0 R /XYZ 56.6929 77.0802 null]
 >> endobj
-2038 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R >>
+2050 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2051 0 obj <<
+2063 0 obj <<
 /Length 3443      
 /Filter /FlateDecode
 >>
@@ -9882,36 +9944,36 @@ eÄp-—ãnóèÀ¾@Ïï'bÝv4ç> K”U¼1O	Ɉ³úÄâ¯ÿx‚3�!¯Ax±Xnâ/=6¾øTË«Öx¶_‹-õç(ÚsT?ma
 š¢m¶ërp4—“qšžx•s7‡PŒŠ­½âõåKu4¬!#(/m
 Žö�ý`¸}[íèãõb^æÃÌ߬Re
a£öUx²\,*O†‹Qô`ˆÃu•ns¥k¿ ’ÇÉh4y	¬t¨JT¼²5ojÀZ¨eXøϦƒe`l�[ÿ¿®È@%µ¬}ò¿š#W
 endobj
-2050 0 obj <<
+2062 0 obj <<
 /Type /Page
-/Contents 2051 0 R
-/Resources 2049 0 R
+/Contents 2063 0 R
+/Resources 2061 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2015 0 R
+/Parent 2027 0 R
 >> endobj
-2052 0 obj <<
-/D [2050 0 R /XYZ 85.0394 794.5015 null]
+2064 0 obj <<
+/D [2062 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2053 0 obj <<
-/D [2050 0 R /XYZ 85.0394 769.5949 null]
+2065 0 obj <<
+/D [2062 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-690 0 obj <<
-/D [2050 0 R /XYZ 85.0394 224.1778 null]
+698 0 obj <<
+/D [2062 0 R /XYZ 85.0394 224.1778 null]
 >> endobj
-2054 0 obj <<
-/D [2050 0 R /XYZ 85.0394 199.0572 null]
+2066 0 obj <<
+/D [2062 0 R /XYZ 85.0394 199.0572 null]
 >> endobj
-2055 0 obj <<
-/D [2050 0 R /XYZ 85.0394 142.6288 null]
+2067 0 obj <<
+/D [2062 0 R /XYZ 85.0394 142.6288 null]
 >> endobj
-2056 0 obj <<
-/D [2050 0 R /XYZ 85.0394 130.6736 null]
+2068 0 obj <<
+/D [2062 0 R /XYZ 85.0394 130.6736 null]
 >> endobj
-2049 0 obj <<
-/Font << /F37 1018 0 R /F39 1151 0 R /F21 930 0 R /F22 953 0 R /F11 1441 0 R >>
+2061 0 obj <<
+/Font << /F37 1026 0 R /F39 1161 0 R /F21 938 0 R /F22 961 0 R /F11 1451 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2059 0 obj <<
+2071 0 obj <<
 /Length 1752      
 /Filter /FlateDecode
 >>
@@ -9926,27 +9988,27 @@ xÚÍYÛnÛ8}÷WèÑÖ,¯"	,HS§u�¦iâ»èöA‘•FXÇr-¹Aÿ¾Ã›LÛ²Ý4i°‰Ôp†œsf8¤I‚á�$"E©¦:‘š#�
 ¤!5ÔÈfËŽYyŸ-í-aÇ$áP'XÈ!YݵZp­NɃêOÐrºŸm€Çî¦÷
 üC¨:d/ˆìØÛ "v÷=‘½#îkwŠ(ÕÙ_ö§:¨•„"ò!ѯÃöTl›Í76¾h·ûâRáúv\Sî.k?d1ËòݲµÅ
 endobj
-2058 0 obj <<
+2070 0 obj <<
 /Type /Page
-/Contents 2059 0 R
-/Resources 2057 0 R
+/Contents 2071 0 R
+/Resources 2069 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2065 0 R
+/Parent 2077 0 R
 >> endobj
-2060 0 obj <<
-/D [2058 0 R /XYZ 56.6929 794.5015 null]
+2072 0 obj <<
+/D [2070 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-694 0 obj <<
-/D [2058 0 R /XYZ 56.6929 557.9661 null]
+702 0 obj <<
+/D [2070 0 R /XYZ 56.6929 557.9661 null]
 >> endobj
-2064 0 obj <<
-/D [2058 0 R /XYZ 56.6929 530.3748 null]
+2076 0 obj <<
+/D [2070 0 R /XYZ 56.6929 530.3748 null]
 >> endobj
-2057 0 obj <<
-/Font << /F37 1018 0 R /F11 1441 0 R /F21 930 0 R /F22 953 0 R /F67 2063 0 R /F39 1151 0 R >>
+2069 0 obj <<
+/Font << /F37 1026 0 R /F11 1451 0 R /F21 938 0 R /F22 961 0 R /F67 2075 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2068 0 obj <<
+2080 0 obj <<
 /Length 1242      
 /Filter /FlateDecode
 >>
@@ -9960,33 +10022,33 @@ xÚ•WÝoÛ6Ï_aäÉ
*Z¤¨¯å©M×-C1kö´î�‘iKˆ,j•Ôú¿�Ç#e)V³†ÁÓéø»ï#EW¡ùÑU“0Êù*Í9‰C¯
 óÈ Žñm1ÚªÅëé$³þõÌfB�ú{z_šZéMÿŽItñFó
 €�:]C¦ˆcq¿h“‡ž‡-ÖXd¹_UãT]º9GLs^¾jw…9¶nßAôæ_ôqWy?.›)ü!=χhŽs·_òïâÇ»ñ[ËAÁ¥É|�-}�y‘à$ƒŸb³;Yh>‡¢œz ;
 endobj
-2067 0 obj <<
+2079 0 obj <<
 /Type /Page
-/Contents 2068 0 R
-/Resources 2066 0 R
+/Contents 2080 0 R
+/Resources 2078 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2065 0 R
+/Parent 2077 0 R
 >> endobj
-2069 0 obj <<
-/D [2067 0 R /XYZ 85.0394 794.5015 null]
+2081 0 obj <<
+/D [2079 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-698 0 obj <<
-/D [2067 0 R /XYZ 85.0394 769.5949 null]
+706 0 obj <<
+/D [2079 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-2070 0 obj <<
-/D [2067 0 R /XYZ 85.0394 571.259 null]
+2082 0 obj <<
+/D [2079 0 R /XYZ 85.0394 571.259 null]
 >> endobj
-702 0 obj <<
-/D [2067 0 R /XYZ 85.0394 571.259 null]
+710 0 obj <<
+/D [2079 0 R /XYZ 85.0394 571.259 null]
 >> endobj
-2071 0 obj <<
-/D [2067 0 R /XYZ 85.0394 538.9404 null]
+2083 0 obj <<
+/D [2079 0 R /XYZ 85.0394 538.9404 null]
 >> endobj
-2066 0 obj <<
-/Font << /F21 930 0 R /F22 953 0 R /F39 1151 0 R /F41 1208 0 R >>
+2078 0 obj <<
+/Font << /F21 938 0 R /F22 961 0 R /F39 1161 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2074 0 obj <<
+2086 0 obj <<
 /Length 3284      
 /Filter /FlateDecode
 >>
@@ -10004,53 +10066,53 @@ xÚ¥ZëoÛFÿî¿Bߎ,Šû ¹,¸‰su¯Hz‰�»¢íZ¤-^(RáÃŽú×ßÌÎ,EJt b.g‡³¯yüfVbÀ?±#?Jd²ˆ
 `µŠAV£@ßò¯¤["@ó™R;NÀFR—‚/´{ϦÄqJ»r±fNñ7TÐ&7#C0Z,ksú	ä´ëðl3ê¼gj;d‚¡3óP�TC34s&»êKjøN
W+z¼Fꢋ–Q¼þÞ
 B¼T<±lR\¼^'°N§†
 endobj
-2073 0 obj <<
+2085 0 obj <<
 /Type /Page
-/Contents 2074 0 R
-/Resources 2072 0 R
+/Contents 2086 0 R
+/Resources 2084 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2065 0 R
-/Annots [ 2079 0 R ]
+/Parent 2077 0 R
+/Annots [ 2091 0 R ]
 >> endobj
-2079 0 obj <<
+2091 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
 /Rect [63.4454 707.8911 452.088 718.0529]
 /Subtype/Link/A<</Type/Action/S/URI/URI(ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos)>>
 >> endobj
-2075 0 obj <<
-/D [2073 0 R /XYZ 56.6929 794.5015 null]
+2087 0 obj <<
+/D [2085 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-706 0 obj <<
-/D [2073 0 R /XYZ 56.6929 690.9391 null]
+714 0 obj <<
+/D [2085 0 R /XYZ 56.6929 690.9391 null]
 >> endobj
-2080 0 obj <<
-/D [2073 0 R /XYZ 56.6929 656.5891 null]
+2092 0 obj <<
+/D [2085 0 R /XYZ 56.6929 656.5891 null]
 >> endobj
-710 0 obj <<
-/D [2073 0 R /XYZ 56.6929 517.028 null]
+718 0 obj <<
+/D [2085 0 R /XYZ 56.6929 517.028 null]
 >> endobj
-2081 0 obj <<
-/D [2073 0 R /XYZ 56.6929 489.6469 null]
+2093 0 obj <<
+/D [2085 0 R /XYZ 56.6929 489.6469 null]
 >> endobj
-714 0 obj <<
-/D [2073 0 R /XYZ 56.6929 373.2709 null]
+722 0 obj <<
+/D [2085 0 R /XYZ 56.6929 373.2709 null]
 >> endobj
-2082 0 obj <<
-/D [2073 0 R /XYZ 56.6929 344.9674 null]
+2094 0 obj <<
+/D [2085 0 R /XYZ 56.6929 344.9674 null]
 >> endobj
-718 0 obj <<
-/D [2073 0 R /XYZ 56.6929 184.6919 null]
+726 0 obj <<
+/D [2085 0 R /XYZ 56.6929 184.6919 null]
 >> endobj
-1722 0 obj <<
-/D [2073 0 R /XYZ 56.6929 151.8489 null]
+1739 0 obj <<
+/D [2085 0 R /XYZ 56.6929 151.8489 null]
 >> endobj
-2072 0 obj <<
-/Font << /F37 1018 0 R /F71 2078 0 R /F22 953 0 R /F39 1151 0 R /F11 1441 0 R /F41 1208 0 R /F21 930 0 R /F53 1303 0 R /F48 1228 0 R /F62 1351 0 R /F63 1354 0 R >>
-/XObject << /Im2 1340 0 R >>
+2084 0 obj <<
+/Font << /F37 1026 0 R /F71 2090 0 R /F22 961 0 R /F39 1161 0 R /F11 1451 0 R /F41 1218 0 R /F21 938 0 R /F53 1313 0 R /F48 1238 0 R /F62 1361 0 R /F63 1364 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2085 0 obj <<
+2097 0 obj <<
 /Length 846       
 /Filter /FlateDecode
 >>
@@ -10061,41 +10123,41 @@ Zí¶ïaeaÕœ©Ûl]¥I–:\$ ŽÝPÇÊŒ¤)ÈtŽYësŒÕyô-ÑYBJV¬Çk^IdŽúÔ5¼k�®GÂœ䇶ïê‚°b‘
 “ÚZ¬8‹ê£ÖÆ›­v«
 Íe�=N¤omƒk÷:Ìi%Jí€n¼jNûF÷­àrð'Õ©ƒ›Œ�ÓvÅÇKí�ð3ååT£F9¡+ÐþÒƒ"xIªcky–/]J¯]»ÕcÜ)hâËY”j=Xˆ×¯O­»óպاúˆ’ô¡¼ïÍm¼4ÀÀå\(p<ía°�gµ÷cŠ„QW~‡’QÓ5™ëœ)ps�GÜDÑ7Î�^Jļ`ɽÔ\÷¼.¼«ð÷yÿïWüåû–¦(’åšÓ”p^²kRŽ/Æòש?¿÷ÿÎýo�Êàaendstream
 endobj
-2084 0 obj <<
+2096 0 obj <<
 /Type /Page
-/Contents 2085 0 R
-/Resources 2083 0 R
+/Contents 2097 0 R
+/Resources 2095 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2065 0 R
+/Parent 2077 0 R
 >> endobj
-2086 0 obj <<
-/D [2084 0 R /XYZ 85.0394 794.5015 null]
+2098 0 obj <<
+/D [2096 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2083 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R >>
+2095 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2089 0 obj <<
+2101 0 obj <<
 /Length 69        
 /Filter /FlateDecode
 >>
 stream
 xÚ3T0
 endobj
-2088 0 obj <<
+2100 0 obj <<
 /Type /Page
-/Contents 2089 0 R
-/Resources 2087 0 R
+/Contents 2101 0 R
+/Resources 2099 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2065 0 R
+/Parent 2077 0 R
 >> endobj
-2090 0 obj <<
-/D [2088 0 R /XYZ 56.6929 794.5015 null]
+2102 0 obj <<
+/D [2100 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2087 0 obj <<
+2099 0 obj <<
 /ProcSet [ /PDF ]
 >> endobj
-2093 0 obj <<
+2105 0 obj <<
 /Length 1965      
 /Filter /FlateDecode
 >>
@@ -10109,84 +10171,84 @@ i	·¥Ý3éÀ–yíˆùðŠ&�Â8K<æc�ø¡›‚hïCû™<»úÐŒ­êhüýÔï Æס\@�•‰ó÷w= vV
 ¥Ìrcø-Š¼ûãËü
 “¤%œ¡i±Iæ² —â~ÚøÑŸ/¯6³Âv¡ámÒ¥ß;»è½‡CÀê/aïoã�ã<,EQ^Çsór4ÝÅpµö;[ÃïVÎy
7G)JΑOü©5­�¿|hW°hpk·IQ„"é5¶ÏÍŽûª‡]Ù)C™‹_Ú‘Âõ%KÄQXDñ¯oʬ±]ªÜïʽe×SX{üâññ|>‡¼+�¾,}�w¸ÉÀdñ:Æ›�š¥îãºÊǽµÿ¶Uø]5èTíŠË°ç§�ð6hÿ�˜ÈŸ%×"ö"Û‹½H.ƒH"h<H#a(B”·îæÎ{ÿ
úÀ�endstream
 endobj
-2092 0 obj <<
+2104 0 obj <<
 /Type /Page
-/Contents 2093 0 R
-/Resources 2091 0 R
+/Contents 2105 0 R
+/Resources 2103 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2065 0 R
-/Annots [ 2100 0 R 2101 0 R ]
+/Parent 2077 0 R
+/Annots [ 2112 0 R 2113 0 R ]
 >> endobj
-2100 0 obj <<
+2112 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
 /Rect [348.3486 128.9523 463.9152 141.0119]
 /Subtype/Link/A<</Type/Action/S/URI/URI(mailto:info@isc.org)>>
 >> endobj
-2101 0 obj <<
+2113 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
 /Rect [147.3629 116.9971 364.5484 129.0567]
 /Subtype/Link/A<</Type/Action/S/URI/URI(http://www.isc.org/services/support/)>>
 >> endobj
-2094 0 obj <<
-/D [2092 0 R /XYZ 85.0394 794.5015 null]
+2106 0 obj <<
+/D [2104 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-722 0 obj <<
-/D [2092 0 R /XYZ 85.0394 769.5949 null]
+730 0 obj <<
+/D [2104 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-2095 0 obj <<
-/D [2092 0 R /XYZ 85.0394 576.7004 null]
+2107 0 obj <<
+/D [2104 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
-726 0 obj <<
-/D [2092 0 R /XYZ 85.0394 576.7004 null]
+734 0 obj <<
+/D [2104 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
-2096 0 obj <<
-/D [2092 0 R /XYZ 85.0394 548.3785 null]
+2108 0 obj <<
+/D [2104 0 R /XYZ 85.0394 548.3785 null]
 >> endobj
-730 0 obj <<
-/D [2092 0 R /XYZ 85.0394 548.3785 null]
+738 0 obj <<
+/D [2104 0 R /XYZ 85.0394 548.3785 null]
 >> endobj
-2097 0 obj <<
-/D [2092 0 R /XYZ 85.0394 518.5228 null]
+2109 0 obj <<
+/D [2104 0 R /XYZ 85.0394 518.5228 null]
 >> endobj
-734 0 obj <<
-/D [2092 0 R /XYZ 85.0394 460.6968 null]
+742 0 obj <<
+/D [2104 0 R /XYZ 85.0394 460.6968 null]
 >> endobj
-2098 0 obj <<
-/D [2092 0 R /XYZ 85.0394 425.0333 null]
+2110 0 obj <<
+/D [2104 0 R /XYZ 85.0394 425.0333 null]
 >> endobj
-738 0 obj <<
-/D [2092 0 R /XYZ 85.0394 260.2468 null]
+746 0 obj <<
+/D [2104 0 R /XYZ 85.0394 260.2468 null]
 >> endobj
-2099 0 obj <<
-/D [2092 0 R /XYZ 85.0394 224.698 null]
+2111 0 obj <<
+/D [2104 0 R /XYZ 85.0394 224.698 null]
 >> endobj
-2091 0 obj <<
-/Font << /F21 930 0 R /F22 953 0 R /F11 1441 0 R /F41 1208 0 R >>
+2103 0 obj <<
+/Font << /F21 938 0 R /F22 961 0 R /F11 1451 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2104 0 obj <<
+2116 0 obj <<
 /Length 69        
 /Filter /FlateDecode
 >>
 stream
 xÚ3T0
 endobj
-2103 0 obj <<
+2115 0 obj <<
 /Type /Page
-/Contents 2104 0 R
-/Resources 2102 0 R
+/Contents 2116 0 R
+/Resources 2114 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2106 0 R
+/Parent 2118 0 R
 >> endobj
-2105 0 obj <<
-/D [2103 0 R /XYZ 56.6929 794.5015 null]
+2117 0 obj <<
+/D [2115 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2102 0 obj <<
+2114 0 obj <<
 /ProcSet [ /PDF ]
 >> endobj
-2109 0 obj <<
+2121 0 obj <<
 /Length 2544      
 /Filter /FlateDecode
 >>
@@ -10200,39 +10262,39 @@ FXЭ‚dƒ\#åS¯ÐyOpBŒšÈª†¨n4\Tòi¹^¿È�=õvÂÀ3v·Ù”¹<ƒ
ZˆLPO–`š8I9³€øQ&ŽÀ6
CÆg”ñ
 D¤<ÐÎÿ—yÇ‘sU@E…ÎqÌ*Š‘×8P”Ì Ë¿/@f4
áRÊ}^º¦ÖÒRº#›Úv�°/×ˈÖFtÅŒ‚þ[åSr Òéú@Øèªé)Ž�L½"Ÿûæ¢@ù<ñpJ�µÙ>~æÜpËLtGY­Fgá±[A
—(-Ì
ƒÅÙ¶Ä� ˜Þ�°)Ëx™AaíF¼¨‚ÕáPâ¥V)§8·º>@ÌÔ4ûôÜÄP‰BÍÞ(d�vP&máªëæßFD3zœ`·“¢ÂEàÛ=ÃBj{
†rh®ÔÐq½ ‘®³«zß�&Å(uùJ¸8…B×ò5ø?Š²9Òp#ªf'Ë’•ú&_æùM_—¢±J6iðU£ª#E}ïãÏ^5X*‰eÃÏÖJ©>KF\¢P¯SSŒo&Œ>Ï! ·LÝ–è@±¸ˆ¤�ægH@Ä9³ZI(�	Ž:ž()6Sq
 
UŸiQc
¢õFêƆ�EiX*×5ÔÏ]OÕ-ãÖXXE p³Í‚¥¢o¹‡šMÔºõÁùˆ4òs®øbðج–×
 endobj
-2108 0 obj <<
+2120 0 obj <<
 /Type /Page
-/Contents 2109 0 R
-/Resources 2107 0 R
+/Contents 2121 0 R
+/Resources 2119 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2106 0 R
+/Parent 2118 0 R
 >> endobj
-2110 0 obj <<
-/D [2108 0 R /XYZ 85.0394 794.5015 null]
+2122 0 obj <<
+/D [2120 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-742 0 obj <<
-/D [2108 0 R /XYZ 85.0394 769.5949 null]
+750 0 obj <<
+/D [2120 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-2111 0 obj <<
-/D [2108 0 R /XYZ 85.0394 573.5449 null]
+2123 0 obj <<
+/D [2120 0 R /XYZ 85.0394 573.5449 null]
 >> endobj
-746 0 obj <<
-/D [2108 0 R /XYZ 85.0394 573.5449 null]
+754 0 obj <<
+/D [2120 0 R /XYZ 85.0394 573.5449 null]
 >> endobj
-2112 0 obj <<
-/D [2108 0 R /XYZ 85.0394 539.0037 null]
+2124 0 obj <<
+/D [2120 0 R /XYZ 85.0394 539.0037 null]
 >> endobj
-750 0 obj <<
-/D [2108 0 R /XYZ 85.0394 539.0037 null]
+758 0 obj <<
+/D [2120 0 R /XYZ 85.0394 539.0037 null]
 >> endobj
-2113 0 obj <<
-/D [2108 0 R /XYZ 85.0394 510.2426 null]
+2125 0 obj <<
+/D [2120 0 R /XYZ 85.0394 510.2426 null]
 >> endobj
-2107 0 obj <<
-/Font << /F21 930 0 R /F22 953 0 R >>
+2119 0 obj <<
+/Font << /F21 938 0 R /F22 961 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2116 0 obj <<
+2128 0 obj <<
 /Length 2811      
 /Filter /FlateDecode
 >>
@@ -10252,64 +10314,64 @@ cåàföí÷¹àRõvùÀw²½šÈöëvuyùòò‚*p
 ]8*?\ÕÂXé[}ãú�&?�kÚþù+üM\O:‰p-’Ó~å‡1ÎCN("ÛÿùøÓ‰øN”±iÙE˜øô­ƒ–¿ÌìèÇþ»G·c1Üb¾{øÃO)�Ô1T~ß!¯½<æÏGþã8:âïè[L‡uÊÓH§Ô�§¿Lå]ÀĈ90&ºÒK÷ðxj7ˆ†žÄ˜-t|×âÚv ª{ô^Ù¶Ä>±t‹à-Ö‹i¦'¾}¤¥¶Ÿ4žÓÂ>©]¶£÷OtJµùï‘ÊøÙJ„b¤‡7
 }Ç÷èUHÇÁ{‘Ý°î8u¢º¦Nh{'RíÚ©›Íe³ÎN|Çs#'qå1WG¾Óa�²2RÄ)µ·|'r"?Ž†<ÇéÜ4†`“6MKÎü=B¿õ…S~–œ�Ãíóÿüõ³ÿ
 endobj
-2115 0 obj <<
+2127 0 obj <<
 /Type /Page
-/Contents 2116 0 R
-/Resources 2114 0 R
+/Contents 2128 0 R
+/Resources 2126 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2106 0 R
-/Annots [ 2120 0 R 2121 0 R ]
+/Parent 2118 0 R
+/Annots [ 2132 0 R 2133 0 R ]
 >> endobj
-2120 0 obj <<
+2132 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
 /Rect [253.7995 149.3637 417.685 161.4234]
 /Subtype/Link/A<</Type/Action/S/URI/URI(ftp://www.isi.edu/in-notes/)>>
 >> endobj
-2121 0 obj <<
+2133 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
 /Rect [63.4454 110.455 208.8999 120.6168]
 /Subtype/Link/A<</Type/Action/S/URI/URI(http://www.ietf.org/rfc/)>>
 >> endobj
-2117 0 obj <<
-/D [2115 0 R /XYZ 56.6929 794.5015 null]
+2129 0 obj <<
+/D [2127 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-754 0 obj <<
-/D [2115 0 R /XYZ 56.6929 662.0717 null]
+762 0 obj <<
+/D [2127 0 R /XYZ 56.6929 662.0717 null]
 >> endobj
-2118 0 obj <<
-/D [2115 0 R /XYZ 56.6929 624.1661 null]
+2130 0 obj <<
+/D [2127 0 R /XYZ 56.6929 624.1661 null]
 >> endobj
-758 0 obj <<
-/D [2115 0 R /XYZ 56.6929 624.1661 null]
+766 0 obj <<
+/D [2127 0 R /XYZ 56.6929 624.1661 null]
 >> endobj
-1513 0 obj <<
-/D [2115 0 R /XYZ 56.6929 593.0972 null]
+1531 0 obj <<
+/D [2127 0 R /XYZ 56.6929 593.0972 null]
 >> endobj
-762 0 obj <<
-/D [2115 0 R /XYZ 56.6929 294.2701 null]
+770 0 obj <<
+/D [2127 0 R /XYZ 56.6929 294.2701 null]
 >> endobj
-2119 0 obj <<
-/D [2115 0 R /XYZ 56.6929 255.4568 null]
+2131 0 obj <<
+/D [2127 0 R /XYZ 56.6929 255.4568 null]
 >> endobj
-766 0 obj <<
-/D [2115 0 R /XYZ 56.6929 255.4568 null]
+774 0 obj <<
+/D [2127 0 R /XYZ 56.6929 255.4568 null]
 >> endobj
-1241 0 obj <<
-/D [2115 0 R /XYZ 56.6929 226.1045 null]
+1251 0 obj <<
+/D [2127 0 R /XYZ 56.6929 226.1045 null]
 >> endobj
-2122 0 obj <<
-/D [2115 0 R /XYZ 56.6929 53.5688 null]
+2134 0 obj <<
+/D [2127 0 R /XYZ 56.6929 53.5688 null]
 >> endobj
-2123 0 obj <<
-/D [2115 0 R /XYZ 56.6929 53.5688 null]
+2135 0 obj <<
+/D [2127 0 R /XYZ 56.6929 53.5688 null]
 >> endobj
-2114 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F39 1151 0 R /F53 1303 0 R /F11 1441 0 R /F41 1208 0 R >>
+2126 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F39 1161 0 R /F53 1313 0 R /F11 1451 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2126 0 obj <<
+2138 0 obj <<
 /Length 2825      
 /Filter /FlateDecode
 >>
@@ -10330,690 +10392,690 @@ Zî–ÁÅ“ž„N(ËEHq¤;#UO«E;õ4�:É$£ÇgöHm)7™FJ“>2½Ð-™'ØÃdvÀ›
 ·‘�÷A�ŸWÏÙ6}ÍE5#P}m kkôÓÒ9áBŸÔ6"²€ÑÛÇ×H^MÖêD2ì #FEÐ|X|Ö~ѼJyÈ«m^§DRãKá%Jæ./öY®�P¯ÙÙC²7Ü…¤jñ	î€j“Ûÿò—¾ÖÎaŒh’8Ó(4Ÿ”r¬_Jü
 LhÿÕÍ7Á§ïþ_$Gb’endstream
 endobj
-2125 0 obj <<
+2137 0 obj <<
 /Type /Page
-/Contents 2126 0 R
-/Resources 2124 0 R
+/Contents 2138 0 R
+/Resources 2136 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2106 0 R
->> endobj
-2127 0 obj <<
-/D [2125 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-2128 0 obj <<
-/D [2125 0 R /XYZ 85.0394 752.3015 null]
->> endobj
-2129 0 obj <<
-/D [2125 0 R /XYZ 85.0394 752.3015 null]
->> endobj
-2130 0 obj <<
-/D [2125 0 R /XYZ 85.0394 752.3015 null]
->> endobj
-2131 0 obj <<
-/D [2125 0 R /XYZ 85.0394 746.3107 null]
->> endobj
-2132 0 obj <<
-/D [2125 0 R /XYZ 85.0394 731.5461 null]
->> endobj
-2133 0 obj <<
-/D [2125 0 R /XYZ 85.0394 728.1497 null]
->> endobj
-2134 0 obj <<
-/D [2125 0 R /XYZ 85.0394 713.3851 null]
->> endobj
-2135 0 obj <<
-/D [2125 0 R /XYZ 85.0394 709.9887 null]
->> endobj
-2136 0 obj <<
-/D [2125 0 R /XYZ 85.0394 651.9592 null]
->> endobj
-1371 0 obj <<
-/D [2125 0 R /XYZ 85.0394 651.9592 null]
->> endobj
-2137 0 obj <<
-/D [2125 0 R /XYZ 85.0394 651.9592 null]
->> endobj
-2138 0 obj <<
-/D [2125 0 R /XYZ 85.0394 648.8377 null]
+/Parent 2118 0 R
 >> endobj
 2139 0 obj <<
-/D [2125 0 R /XYZ 85.0394 634.0731 null]
+/D [2137 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 2140 0 obj <<
-/D [2125 0 R /XYZ 85.0394 630.6767 null]
+/D [2137 0 R /XYZ 85.0394 752.3015 null]
 >> endobj
 2141 0 obj <<
-/D [2125 0 R /XYZ 85.0394 615.9121 null]
+/D [2137 0 R /XYZ 85.0394 752.3015 null]
 >> endobj
 2142 0 obj <<
-/D [2125 0 R /XYZ 85.0394 612.5156 null]
+/D [2137 0 R /XYZ 85.0394 752.3015 null]
 >> endobj
 2143 0 obj <<
-/D [2125 0 R /XYZ 85.0394 585.7959 null]
+/D [2137 0 R /XYZ 85.0394 746.3107 null]
 >> endobj
 2144 0 obj <<
-/D [2125 0 R /XYZ 85.0394 582.3994 null]
+/D [2137 0 R /XYZ 85.0394 731.5461 null]
 >> endobj
 2145 0 obj <<
-/D [2125 0 R /XYZ 85.0394 567.6349 null]
+/D [2137 0 R /XYZ 85.0394 728.1497 null]
 >> endobj
 2146 0 obj <<
-/D [2125 0 R /XYZ 85.0394 564.2384 null]
+/D [2137 0 R /XYZ 85.0394 713.3851 null]
 >> endobj
 2147 0 obj <<
-/D [2125 0 R /XYZ 85.0394 549.5337 null]
+/D [2137 0 R /XYZ 85.0394 709.9887 null]
 >> endobj
 2148 0 obj <<
-/D [2125 0 R /XYZ 85.0394 546.0774 null]
+/D [2137 0 R /XYZ 85.0394 651.9592 null]
+>> endobj
+1381 0 obj <<
+/D [2137 0 R /XYZ 85.0394 651.9592 null]
 >> endobj
 2149 0 obj <<
-/D [2125 0 R /XYZ 85.0394 531.3128 null]
+/D [2137 0 R /XYZ 85.0394 651.9592 null]
 >> endobj
 2150 0 obj <<
-/D [2125 0 R /XYZ 85.0394 527.9163 null]
+/D [2137 0 R /XYZ 85.0394 648.8377 null]
 >> endobj
 2151 0 obj <<
-/D [2125 0 R /XYZ 85.0394 513.1518 null]
+/D [2137 0 R /XYZ 85.0394 634.0731 null]
 >> endobj
 2152 0 obj <<
-/D [2125 0 R /XYZ 85.0394 509.7553 null]
+/D [2137 0 R /XYZ 85.0394 630.6767 null]
 >> endobj
 2153 0 obj <<
-/D [2125 0 R /XYZ 85.0394 483.0356 null]
+/D [2137 0 R /XYZ 85.0394 615.9121 null]
 >> endobj
 2154 0 obj <<
-/D [2125 0 R /XYZ 85.0394 479.6391 null]
+/D [2137 0 R /XYZ 85.0394 612.5156 null]
 >> endobj
 2155 0 obj <<
-/D [2125 0 R /XYZ 85.0394 464.8745 null]
+/D [2137 0 R /XYZ 85.0394 585.7959 null]
 >> endobj
 2156 0 obj <<
-/D [2125 0 R /XYZ 85.0394 461.4781 null]
+/D [2137 0 R /XYZ 85.0394 582.3994 null]
 >> endobj
 2157 0 obj <<
-/D [2125 0 R /XYZ 85.0394 446.7135 null]
+/D [2137 0 R /XYZ 85.0394 567.6349 null]
 >> endobj
 2158 0 obj <<
-/D [2125 0 R /XYZ 85.0394 443.3171 null]
+/D [2137 0 R /XYZ 85.0394 564.2384 null]
 >> endobj
 2159 0 obj <<
-/D [2125 0 R /XYZ 85.0394 428.5525 null]
+/D [2137 0 R /XYZ 85.0394 549.5337 null]
 >> endobj
 2160 0 obj <<
-/D [2125 0 R /XYZ 85.0394 425.156 null]
+/D [2137 0 R /XYZ 85.0394 546.0774 null]
 >> endobj
 2161 0 obj <<
-/D [2125 0 R /XYZ 85.0394 355.0758 null]
+/D [2137 0 R /XYZ 85.0394 531.3128 null]
 >> endobj
 2162 0 obj <<
-/D [2125 0 R /XYZ 85.0394 355.0758 null]
+/D [2137 0 R /XYZ 85.0394 527.9163 null]
 >> endobj
 2163 0 obj <<
-/D [2125 0 R /XYZ 85.0394 355.0758 null]
+/D [2137 0 R /XYZ 85.0394 513.1518 null]
 >> endobj
 2164 0 obj <<
-/D [2125 0 R /XYZ 85.0394 352.0499 null]
+/D [2137 0 R /XYZ 85.0394 509.7553 null]
 >> endobj
 2165 0 obj <<
-/D [2125 0 R /XYZ 85.0394 337.3452 null]
+/D [2137 0 R /XYZ 85.0394 483.0356 null]
 >> endobj
 2166 0 obj <<
-/D [2125 0 R /XYZ 85.0394 333.8889 null]
+/D [2137 0 R /XYZ 85.0394 479.6391 null]
 >> endobj
 2167 0 obj <<
-/D [2125 0 R /XYZ 85.0394 309.8192 null]
+/D [2137 0 R /XYZ 85.0394 464.8745 null]
 >> endobj
 2168 0 obj <<
-/D [2125 0 R /XYZ 85.0394 303.7727 null]
+/D [2137 0 R /XYZ 85.0394 461.4781 null]
 >> endobj
 2169 0 obj <<
-/D [2125 0 R /XYZ 85.0394 278.3282 null]
+/D [2137 0 R /XYZ 85.0394 446.7135 null]
 >> endobj
 2170 0 obj <<
-/D [2125 0 R /XYZ 85.0394 273.6565 null]
+/D [2137 0 R /XYZ 85.0394 443.3171 null]
 >> endobj
 2171 0 obj <<
-/D [2125 0 R /XYZ 85.0394 246.9367 null]
+/D [2137 0 R /XYZ 85.0394 428.5525 null]
 >> endobj
 2172 0 obj <<
-/D [2125 0 R /XYZ 85.0394 243.5403 null]
+/D [2137 0 R /XYZ 85.0394 425.156 null]
 >> endobj
 2173 0 obj <<
-/D [2125 0 R /XYZ 85.0394 173.5556 null]
+/D [2137 0 R /XYZ 85.0394 355.0758 null]
 >> endobj
 2174 0 obj <<
-/D [2125 0 R /XYZ 85.0394 173.5556 null]
+/D [2137 0 R /XYZ 85.0394 355.0758 null]
 >> endobj
 2175 0 obj <<
-/D [2125 0 R /XYZ 85.0394 173.5556 null]
+/D [2137 0 R /XYZ 85.0394 355.0758 null]
 >> endobj
 2176 0 obj <<
-/D [2125 0 R /XYZ 85.0394 170.4341 null]
+/D [2137 0 R /XYZ 85.0394 352.0499 null]
 >> endobj
 2177 0 obj <<
-/D [2125 0 R /XYZ 85.0394 144.9896 null]
+/D [2137 0 R /XYZ 85.0394 337.3452 null]
 >> endobj
 2178 0 obj <<
-/D [2125 0 R /XYZ 85.0394 140.3179 null]
+/D [2137 0 R /XYZ 85.0394 333.8889 null]
 >> endobj
 2179 0 obj <<
-/D [2125 0 R /XYZ 85.0394 113.5982 null]
+/D [2137 0 R /XYZ 85.0394 309.8192 null]
 >> endobj
 2180 0 obj <<
-/D [2125 0 R /XYZ 85.0394 110.2017 null]
+/D [2137 0 R /XYZ 85.0394 303.7727 null]
 >> endobj
 2181 0 obj <<
-/D [2125 0 R /XYZ 85.0394 95.4372 null]
+/D [2137 0 R /XYZ 85.0394 278.3282 null]
 >> endobj
 2182 0 obj <<
-/D [2125 0 R /XYZ 85.0394 92.0407 null]
+/D [2137 0 R /XYZ 85.0394 273.6565 null]
 >> endobj
-2124 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R >>
-/ProcSet [ /PDF /Text ]
+2183 0 obj <<
+/D [2137 0 R /XYZ 85.0394 246.9367 null]
 >> endobj
-2185 0 obj <<
-/Length 2889      
-/Filter /FlateDecode
->>
-stream
-xÚµšMsÛ8†ïþ:JU1†
-<
-}w„°i5LX[iÂ�ã¶J7„O´{	·´Xøé«M|§–=w¦í½˜A;ˆ‚ÈÀöHü¿HiþM|˜øh²÷²ÈX–%òž.w˜C
-†•…‚²Ò`¯·P°IºÚýLíù&?ýã⯲s¬Ø,¯dSšwç]ù?ý
-?â7?Òù1Щsàží’º(
-ü6¡¹$´HÊ*K^˜l¦µ£ïÞ©s±ðûgM,&†af0�†•…˜²2ˆb6iƒXW»Ÿ˜©½ÞÄÜÎ=ØYE�Xž(E�_q@ü¿Ø&ÁFQã�‚Z}ƒ¤Æ¯G¨ù
-\'4v¹@`ã£Ø\ÇÄÆ?5ØÄaF�ÔÊ'­0ÝÐA>Lº¦i5S[0-»�Uº�y¢Ý³¥½©ŠC½KáˆN/ÙAlapød%osk†¼¯fÈCÞ(ò+Å�[Œ0$aH;†ü~Î�ßkºžã)†Â¦^aüâ“4¾:îöG8ÔÊÃ�¹Å´‰´ÿÄs]8Ç4 #°
+leeÀŽ,°mÒì®v?lS›ÃNÄ>Šs�ÁÙô©>µœ_³º2#zas,E*[dè
�ÐéС7[
-id„ý4¦Õ0m¥Ñ¡¥
-°I+ «Ý¿Lí{Ôu]î‹5e×¥ÓøX=ö[½‰®»"ååÑÇ¡®â»ûµðOÞ_3æ}í¬“wÉä¤?ÈúžÛð†hÁSÃú.•®‘Wä‘ÊïlEÕ
{…ø¡Ó;G
-ÛðÈ‘·±±06Š ÅØ^-¢¿¶j?½F•t7×ñ90d6BäQ—Â-D‹L^àJj±ªÞ£z‹uõ7
®G¶Ëx8›c°ˆ¿¤uæåE\#þò‚tò&™ª1ZP�"¦}ÄÇ�‘…£4j@KÝΦk�ì÷£4„ã&]ÉøZ?$üÑ`'¿¿IËJ¦ž"ö:íbo¸ùáé+�‡²w7Jcðì
··T#ôB^UlŸOj4V`qÅ‘˜a4Li`^d)
Øt`]á^`¦°¨¡†p"üU±¼¬ŸTÂ숚*ü/�¯¯Å¡FË;ÑøƒJQ6‡F¿¯2`äø‘±ºÄ›n�¸ãþ¹Ø‹|�·^ÊÖëc
-¾šÈÖϺ`]Ë4OòJv‰šU
N«µƒiqLË2í«ÿ
-ŒÛÏiueK×±ôƒƒ
æ�ÏBŽãŒÄaÓj˜¹¶jÞLpð0s«tÃüD»—yK[ÏÇ"ß»ø+Vý,/MÓ­~‚é;üd'DÄñCK˜ýl~h½u Äë!ÍTò'/Ø‹PˆÇª¦•…’²j(ÙöK«´A©«ÝOÉÔ^³ïÇTìq{–«íPo‘Í#/þéºÐ湚»×,Ý…ô¦¬+#wŸ[�<¹�ÂùÅ!Ù±�r¹

-…º#õ:ÓÊEYi(^ds›´
¥«ÝÅÔOï7ÕḭD˜d�™7žmôl�‘‡ü€ºíÉÿ �ã
-.Wçñ|¾FñZD—øw¦~TЙìkUUIw9SAèJ6î$Í«z꾅щlÍ£ü~dÃÏu1dwGÛ›VdÊJ#‰å4i•6�uµû‘™ÚËøBm¼DÁ¶Ï9„§L½Î´ç1NîC݇MyúýȺ‡ лéz~ÐÛ–±D
ÇÊŽ§^I§‚ö;•“~f8ö–…a4LK5eb©TÛtV]á^T¦°Žqn¨bœñ7ƒ´ºsnÔ©b‚å2^Åâêr…tÇÉÐû�¼¤é“ÖÓ?±N©áv3¥†f#¥æ�Òè¢.lå¹x	òüßµ·eYšìÕ‹Z¤uö×ÎÚyÍnð i©³xˆ¿OÛ3ùŽ>“þϯíUñ
-endobj
 2184 0 obj <<
-/Type /Page
-/Contents 2185 0 R
-/Resources 2183 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 2106 0 R
+/D [2137 0 R /XYZ 85.0394 243.5403 null]
+>> endobj
+2185 0 obj <<
+/D [2137 0 R /XYZ 85.0394 173.5556 null]
 >> endobj
 2186 0 obj <<
-/D [2184 0 R /XYZ 56.6929 794.5015 null]
+/D [2137 0 R /XYZ 85.0394 173.5556 null]
 >> endobj
 2187 0 obj <<
-/D [2184 0 R /XYZ 56.6929 748.5056 null]
+/D [2137 0 R /XYZ 85.0394 173.5556 null]
 >> endobj
 2188 0 obj <<
-/D [2184 0 R /XYZ 56.6929 748.5056 null]
+/D [2137 0 R /XYZ 85.0394 170.4341 null]
 >> endobj
 2189 0 obj <<
-/D [2184 0 R /XYZ 56.6929 748.5056 null]
+/D [2137 0 R /XYZ 85.0394 144.9896 null]
 >> endobj
 2190 0 obj <<
-/D [2184 0 R /XYZ 56.6929 743.7078 null]
+/D [2137 0 R /XYZ 85.0394 140.3179 null]
 >> endobj
 2191 0 obj <<
-/D [2184 0 R /XYZ 56.6929 719.6381 null]
+/D [2137 0 R /XYZ 85.0394 113.5982 null]
 >> endobj
 2192 0 obj <<
-/D [2184 0 R /XYZ 56.6929 711.8197 null]
+/D [2137 0 R /XYZ 85.0394 110.2017 null]
 >> endobj
 2193 0 obj <<
-/D [2184 0 R /XYZ 56.6929 697.0552 null]
+/D [2137 0 R /XYZ 85.0394 95.4372 null]
 >> endobj
 2194 0 obj <<
-/D [2184 0 R /XYZ 56.6929 691.8868 null]
->> endobj
-2195 0 obj <<
-/D [2184 0 R /XYZ 56.6929 665.1671 null]
+/D [2137 0 R /XYZ 85.0394 92.0407 null]
 >> endobj
-2196 0 obj <<
-/D [2184 0 R /XYZ 56.6929 659.9987 null]
+2136 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
 2197 0 obj <<
-/D [2184 0 R /XYZ 56.6929 635.929 null]
+/Length 2889      
+/Filter /FlateDecode
+>>
+stream
+xÚµšMsÛ8†ïþ:JU1†
+<
+}w„°i5LX[iÂ�ã¶J7„O´{	·´Xøé«M|§–=w¦í½˜A;ˆ‚ÈÀöHü¿HiþM|˜øh²÷²ÈX–%òž.w˜C
+†•…‚²Ò`¯·P°IºÚýLíù&?ýã⯲s¬Ø,¯dSšwç]ù?ý
+?â7?Òù1Щsàží’º(
+ü6¡¹$´HÊ*K^˜l¦µ£ïÞ©s±ðûgM,&†af0�†•…˜²2ˆb6iƒXW»Ÿ˜©½ÞÄÜÎ=ØYE�Xž(E�_q@ü¿Ø&ÁFQã�‚Z}ƒ¤Æ¯G¨ù
+\'4v¹@`ã£Ø\ÇÄÆ?5ØÄaF�ÔÊ'­0ÝÐA>Lº¦i5S[0-»�Uº�y¢Ý³¥½©ŠC½KáˆN/ÙAlapød%osk†¼¯fÈCÞ(ò+Å�[Œ0$aH;†ü~Î�ßkºžã)†Â¦^aüâ“4¾:îöG8ÔÊÃ�¹Å´‰´ÿÄs]8Ç4 #°
+leeÀŽ,°mÒì®v?lS›ÃNÄ>Šs�ÁÙô©>µœ_³º2#zas,E*[dè
�ÐéС7[
+id„ý4¦Õ0m¥Ñ¡¥
+°I+ «Ý¿Lí{Ôu]î‹5e×¥ÓøX=ö[½‰®»"ååÑÇ¡®â»ûµðOÞ_3æ}í¬“wÉä¤?ÈúžÛð†hÁSÃú.•®‘Wä‘ÊïlEÕ
{…ø¡Ó;G
+ÛðÈ‘·±±06Š ÅØ^-¢¿¶j?½F•t7×ñ90d6BäQ—Â-D‹L^àJj±ªÞ£z‹uõ7
®G¶Ëx8›c°ˆ¿¤uæåE\#þò‚tò&™ª1ZP�"¦}ÄÇ�‘…£4j@KÝΦk�ì÷£4„ã&]ÉøZ?$üÑ`'¿¿IËJ¦ž"ö:íbo¸ùáé+�‡²w7Jcðì
··T#ôB^UlŸOj4V`qÅ‘˜a4Li`^d)
Øt`]á^`¦°¨¡†p"üU±¼¬ŸTÂ숚*ü/�¯¯Å¡FË;ÑøƒJQ6‡F¿¯2`äø‘±ºÄ›n�¸ãþ¹Ø‹|�·^ÊÖëc
+¾šÈÖϺ`]Ë4OòJv‰šU
N«µƒiqLË2í«ÿ
+ŒÛÏiueK×±ôƒƒ
æ�ÏBŽãŒÄaÓj˜¹¶jÞLpð0s«tÃüD»—yK[ÏÇ"ß»ø+Vý,/MÓ­~‚é;üd'DÄñCK˜ýl~h½u Äë!ÍTò'/Ø‹PˆÇª¦•…’²j(ÙöK«´A©«ÝOÉÔ^³ïÇTìq{–«íPo‘Í#/þéºÐ湚»×,Ý…ô¦¬+#wŸ[�<¹�ÂùÅ!Ù±�r¹

+…º#õ:ÓÊEYi(^ds›´
¥«ÝÅÔOï7ÕḭD˜d�™7žmôl�‘‡ü€ºíÉÿ �ã
+.Wçñ|¾FñZD—øw¦~TЙìkUUIw9SAèJ6î$Í«z꾅щlÍ£ü~dÃÏu1dwGÛ›VdÊJ#‰å4i•6�uµû‘™ÚËøBm¼DÁ¶Ï9„§L½Î´ç1NîC݇MyúýȺ‡ лéz~ÐÛ–±D
ÇÊŽ§^I§‚ö;•“~f8ö–…a4LK5eb©TÛtV]á^T¦°Žqn¨bœñ7ƒ´ºsnÔ©b‚å2^Åâêr…tÇÉÐû�¼¤é“ÖÓ?±N©áv3¥†f#¥æ�Òè¢.lå¹x	òüßµ·eYšìÕ‹Z¤uö×ÎÚyÍnð i©³xˆ¿OÛ3ùŽ>“þϯíUñ
+endobj
+2196 0 obj <<
+/Type /Page
+/Contents 2197 0 R
+/Resources 2195 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 2118 0 R
 >> endobj
 2198 0 obj <<
-/D [2184 0 R /XYZ 56.6929 628.1106 null]
+/D [2196 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 2199 0 obj <<
-/D [2184 0 R /XYZ 56.6929 601.3909 null]
+/D [2196 0 R /XYZ 56.6929 748.5056 null]
 >> endobj
 2200 0 obj <<
-/D [2184 0 R /XYZ 56.6929 596.2225 null]
+/D [2196 0 R /XYZ 56.6929 748.5056 null]
 >> endobj
 2201 0 obj <<
-/D [2184 0 R /XYZ 56.6929 569.5028 null]
+/D [2196 0 R /XYZ 56.6929 748.5056 null]
 >> endobj
 2202 0 obj <<
-/D [2184 0 R /XYZ 56.6929 564.3344 null]
+/D [2196 0 R /XYZ 56.6929 743.7078 null]
 >> endobj
 2203 0 obj <<
-/D [2184 0 R /XYZ 56.6929 549.6297 null]
+/D [2196 0 R /XYZ 56.6929 719.6381 null]
 >> endobj
 2204 0 obj <<
-/D [2184 0 R /XYZ 56.6929 544.4015 null]
+/D [2196 0 R /XYZ 56.6929 711.8197 null]
 >> endobj
 2205 0 obj <<
-/D [2184 0 R /XYZ 56.6929 529.6968 null]
+/D [2196 0 R /XYZ 56.6929 697.0552 null]
 >> endobj
 2206 0 obj <<
-/D [2184 0 R /XYZ 56.6929 524.4686 null]
+/D [2196 0 R /XYZ 56.6929 691.8868 null]
 >> endobj
 2207 0 obj <<
-/D [2184 0 R /XYZ 56.6929 500.3989 null]
+/D [2196 0 R /XYZ 56.6929 665.1671 null]
 >> endobj
 2208 0 obj <<
-/D [2184 0 R /XYZ 56.6929 492.5805 null]
+/D [2196 0 R /XYZ 56.6929 659.9987 null]
 >> endobj
 2209 0 obj <<
-/D [2184 0 R /XYZ 56.6929 467.136 null]
+/D [2196 0 R /XYZ 56.6929 635.929 null]
 >> endobj
 2210 0 obj <<
-/D [2184 0 R /XYZ 56.6929 460.6924 null]
+/D [2196 0 R /XYZ 56.6929 628.1106 null]
 >> endobj
 2211 0 obj <<
-/D [2184 0 R /XYZ 56.6929 436.6227 null]
+/D [2196 0 R /XYZ 56.6929 601.3909 null]
 >> endobj
 2212 0 obj <<
-/D [2184 0 R /XYZ 56.6929 428.8043 null]
+/D [2196 0 R /XYZ 56.6929 596.2225 null]
 >> endobj
 2213 0 obj <<
-/D [2184 0 R /XYZ 56.6929 414.0996 null]
+/D [2196 0 R /XYZ 56.6929 569.5028 null]
 >> endobj
 2214 0 obj <<
-/D [2184 0 R /XYZ 56.6929 408.8714 null]
+/D [2196 0 R /XYZ 56.6929 564.3344 null]
 >> endobj
 2215 0 obj <<
-/D [2184 0 R /XYZ 56.6929 382.1516 null]
+/D [2196 0 R /XYZ 56.6929 549.6297 null]
 >> endobj
 2216 0 obj <<
-/D [2184 0 R /XYZ 56.6929 376.9833 null]
+/D [2196 0 R /XYZ 56.6929 544.4015 null]
 >> endobj
 2217 0 obj <<
-/D [2184 0 R /XYZ 56.6929 350.2636 null]
+/D [2196 0 R /XYZ 56.6929 529.6968 null]
 >> endobj
 2218 0 obj <<
-/D [2184 0 R /XYZ 56.6929 345.0952 null]
+/D [2196 0 R /XYZ 56.6929 524.4686 null]
 >> endobj
 2219 0 obj <<
-/D [2184 0 R /XYZ 56.6929 321.0255 null]
+/D [2196 0 R /XYZ 56.6929 500.3989 null]
 >> endobj
 2220 0 obj <<
-/D [2184 0 R /XYZ 56.6929 313.2071 null]
+/D [2196 0 R /XYZ 56.6929 492.5805 null]
 >> endobj
 2221 0 obj <<
-/D [2184 0 R /XYZ 56.6929 298.5024 null]
+/D [2196 0 R /XYZ 56.6929 467.136 null]
 >> endobj
 2222 0 obj <<
-/D [2184 0 R /XYZ 56.6929 293.2742 null]
+/D [2196 0 R /XYZ 56.6929 460.6924 null]
 >> endobj
 2223 0 obj <<
-/D [2184 0 R /XYZ 56.6929 267.8297 null]
+/D [2196 0 R /XYZ 56.6929 436.6227 null]
 >> endobj
 2224 0 obj <<
-/D [2184 0 R /XYZ 56.6929 261.3861 null]
+/D [2196 0 R /XYZ 56.6929 428.8043 null]
 >> endobj
 2225 0 obj <<
-/D [2184 0 R /XYZ 56.6929 199.468 null]
+/D [2196 0 R /XYZ 56.6929 414.0996 null]
 >> endobj
 2226 0 obj <<
-/D [2184 0 R /XYZ 56.6929 199.468 null]
+/D [2196 0 R /XYZ 56.6929 408.8714 null]
 >> endobj
 2227 0 obj <<
-/D [2184 0 R /XYZ 56.6929 199.468 null]
+/D [2196 0 R /XYZ 56.6929 382.1516 null]
 >> endobj
 2228 0 obj <<
-/D [2184 0 R /XYZ 56.6929 191.7053 null]
+/D [2196 0 R /XYZ 56.6929 376.9833 null]
 >> endobj
 2229 0 obj <<
-/D [2184 0 R /XYZ 56.6929 176.9408 null]
+/D [2196 0 R /XYZ 56.6929 350.2636 null]
 >> endobj
 2230 0 obj <<
-/D [2184 0 R /XYZ 56.6929 171.7724 null]
+/D [2196 0 R /XYZ 56.6929 345.0952 null]
 >> endobj
 2231 0 obj <<
-/D [2184 0 R /XYZ 56.6929 157.0677 null]
+/D [2196 0 R /XYZ 56.6929 321.0255 null]
 >> endobj
 2232 0 obj <<
-/D [2184 0 R /XYZ 56.6929 151.8395 null]
+/D [2196 0 R /XYZ 56.6929 313.2071 null]
 >> endobj
 2233 0 obj <<
-/D [2184 0 R /XYZ 56.6929 137.1348 null]
+/D [2196 0 R /XYZ 56.6929 298.5024 null]
 >> endobj
 2234 0 obj <<
-/D [2184 0 R /XYZ 56.6929 131.9066 null]
+/D [2196 0 R /XYZ 56.6929 293.2742 null]
 >> endobj
 2235 0 obj <<
-/D [2184 0 R /XYZ 56.6929 117.2018 null]
+/D [2196 0 R /XYZ 56.6929 267.8297 null]
 >> endobj
 2236 0 obj <<
-/D [2184 0 R /XYZ 56.6929 111.9736 null]
+/D [2196 0 R /XYZ 56.6929 261.3861 null]
 >> endobj
 2237 0 obj <<
-/D [2184 0 R /XYZ 56.6929 97.2091 null]
+/D [2196 0 R /XYZ 56.6929 199.468 null]
 >> endobj
 2238 0 obj <<
-/D [2184 0 R /XYZ 56.6929 92.0407 null]
+/D [2196 0 R /XYZ 56.6929 199.468 null]
 >> endobj
-2183 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R >>
-/ProcSet [ /PDF /Text ]
+2239 0 obj <<
+/D [2196 0 R /XYZ 56.6929 199.468 null]
 >> endobj
-2241 0 obj <<
-/Length 2542      
-/Filter /FlateDecode
->>
-stream
-xÚ¥Z[w£º~ϯð£½Ö˜Jqé›'Og’ÔÎô´kÎy ¶â°ŠÁœ9s~}·Ð�‘<=]yH>Øß¾c<Að‡'1õI‚I”E˜N¶‡+4ÙÃÞý–2s%47¥®Ÿ¯þrG¢Iâ%¡Nž_�{ÅŠc<yÞ}›.žžn–«Îæ>EÓ…7›S„ÔêÍíf6�„o¾¢éõêúóêñ~½xúø/qѯˆ¢ÅÃRœl¾Þßßnžoåéúv±\=܃žýöüéêöY?¶ùjþÌÿ¹úöšìà
?]!�$1�|‡äá$ñ'‡«€�„¨•üjsõw}Cc·½tLU”Ä�ýhDW>ž`ì%”ú=eÑĉOZe-6âµ�¬J›¬,jë[Oq�.-#À#KÈpôoë»Pùmˆ‰)òâžß
ªe†¨pØ¡bJ½8"Ô„]–‡4+Ä{§»CVdu/_VµX+;]´çûS¶cÆÁ+á�zAÆð@ü¾„øOüÿ\6pÏY¨�‡ò�^X%ÎpGžUÙ@œ/mÈ¡nCÊ¡p%¥UNIäP¹ÚPúÛ¢vü¦<J©xmyË´IÅÑ]–3qtS¿"äïO‚±x[U3O9M#T€2ƒ0 }*žfØO¦’�kƪ†R¹÷¸mJƒŒ„XÉèB¨2¥ìdh)MF‚};N莌3ìq2zà£dè0�æÒ?ŠÝŸ¥ÄÇÔãØïS²Tl¤•éw쥚ÅÓSZýÐŒ„vF"xsŠâŒRF””bÄG9qAŒ±-Œ˜àgÊ¿©²†U™t�×Rëº,QÒƒô˜
«ÞYU�F©(ŒÃ>×’‡/iQdÅ~ÀvÏqþ1£tšýž1‹ç8x}„¾@S'ä`I
-i’|œ8Hrà
€-È_k©îòuà8‹<KkV˜z`Í÷²úwGQ¶eã…±ùA0žI>¦‡,o”Ói’ÖrûîGU¶k,E
-²WÌ}’x”B]1|DXáª
-)ÒI�8²×à|
-D}��`k°ùzH‹v;–<óç‘<k˜¹
mP7,ÏKÍt²}Ó|Û«"
-é�ÿBp7¥Œ+)ƒrì Ümp>Ķ�n‚sF…‹±#ø4¥	w}
vÓT`j�¯
K‚^ñÒ•‹µ±Ÿï�ÄQ¾¯Ì‡‹è8:4‰8�Œmúp€ÂŽq~ƒqq¯–p¾óE®nÒ#ü:O‹íkþáAL ƒº”ÍM);áZÊ ÜQ;¡;ÂÏ°Ç	ï�?�ŠÛrÇx
-ÈLíª¯ÝƒïüÂÙ)óWy�~„{¹ÿý_ýò£
Šòr�,4æ0[ÄV>ýˆzQx)]˜Rv>µTÇ'u�NèŽÏ3ìq>{à=}gE7½S.%«‚�ó©ê�ÏrjÇtå¬Q„Gõ1þYoÓm»›x1xé„´H!]Ò£ÈÑùp
RÀNä5ƒnŒ°­Q3+ZÄpEdôºP•:¢	þ0yCA»/ÁóêÁЯ%k”"J¼8õ÷'IQ猣o(À±�&B½
-endobj
 2240 0 obj <<
-/Type /Page
-/Contents 2241 0 R
-/Resources 2239 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 2106 0 R
+/D [2196 0 R /XYZ 56.6929 191.7053 null]
+>> endobj
+2241 0 obj <<
+/D [2196 0 R /XYZ 56.6929 176.9408 null]
 >> endobj
 2242 0 obj <<
-/D [2240 0 R /XYZ 85.0394 794.5015 null]
+/D [2196 0 R /XYZ 56.6929 171.7724 null]
 >> endobj
 2243 0 obj <<
-/D [2240 0 R /XYZ 85.0394 748.4854 null]
+/D [2196 0 R /XYZ 56.6929 157.0677 null]
 >> endobj
 2244 0 obj <<
-/D [2240 0 R /XYZ 85.0394 748.4854 null]
+/D [2196 0 R /XYZ 56.6929 151.8395 null]
 >> endobj
 2245 0 obj <<
-/D [2240 0 R /XYZ 85.0394 748.4854 null]
+/D [2196 0 R /XYZ 56.6929 137.1348 null]
 >> endobj
 2246 0 obj <<
-/D [2240 0 R /XYZ 85.0394 743.3452 null]
+/D [2196 0 R /XYZ 56.6929 131.9066 null]
 >> endobj
 2247 0 obj <<
-/D [2240 0 R /XYZ 85.0394 728.6405 null]
+/D [2196 0 R /XYZ 56.6929 117.2018 null]
 >> endobj
 2248 0 obj <<
-/D [2240 0 R /XYZ 85.0394 723.1655 null]
+/D [2196 0 R /XYZ 56.6929 111.9736 null]
 >> endobj
 2249 0 obj <<
-/D [2240 0 R /XYZ 85.0394 708.4607 null]
+/D [2196 0 R /XYZ 56.6929 97.2091 null]
 >> endobj
 2250 0 obj <<
-/D [2240 0 R /XYZ 85.0394 702.9857 null]
+/D [2196 0 R /XYZ 56.6929 92.0407 null]
 >> endobj
-2251 0 obj <<
-/D [2240 0 R /XYZ 85.0394 688.2211 null]
->> endobj
-2252 0 obj <<
-/D [2240 0 R /XYZ 85.0394 682.8059 null]
+2195 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
 2253 0 obj <<
-/D [2240 0 R /XYZ 85.0394 668.0414 null]
+/Length 2542      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥Z[w£º~ϯð£½Ö˜Jqé›'Og’ÔÎô´kÎy ¶â°ŠÁœ9s~}·Ð�‘<=]yH>Øß¾c<Að‡'1õI‚I”E˜N¶‡+4ÙÃÞý–2s%47¥®Ÿ¯þrG¢Iâ%¡Nž_�{ÅŠc<yÞ}›.žžn–«Îæ>EÓ…7›S„ÔêÍíf6�„o¾¢éõêúóêñ~½xúø/qѯˆ¢ÅÃRœl¾Þßßnžoåéúv±\=܃žýöüéêöY?¶ùjþÌÿ¹úöšìà
?]!�$1�|‡äá$ñ'‡«€�„¨•üjsõw}Cc·½tLU”Ä�ýhDW>ž`ì%”ú=eÑĉOZe-6âµ�¬J›¬,jë[Oq�.-#À#KÈpôoë»Pùmˆ‰)òâžß
ªe†¨pØ¡bJ½8"Ô„]–‡4+Ä{§»CVdu/_VµX+;]´çûS¶cÆÁ+á�zAÆð@ü¾„øOüÿ\6pÏY¨�‡ò�^X%ÎpGžUÙ@œ/mÈ¡nCÊ¡p%¥UNIäP¹ÚPúÛ¢vü¦<J©xmyË´IÅÑ]–3qtS¿"äïO‚±x[U3O9M#T€2ƒ0 }*žfØO¦’�kƪ†R¹÷¸mJƒŒ„XÉèB¨2¥ìdh)MF‚};N莌3ìq2zà£dè0�æÒ?ŠÝŸ¥ÄÇÔãØïS²Tl¤•éw쥚ÅÓSZýÐŒ„vF"xsŠâŒRF””bÄG9qAŒ±-Œ˜àgÊ¿©²†U™t�×Rëº,QÒƒô˜
«ÞYU�F©(ŒÃ>×’‡/iQdÅ~ÀvÏqþ1£tšýž1‹ç8x}„¾@S'ä`I
+i’|œ8Hrà
€-È_k©îòuà8‹<KkV˜z`Í÷²úwGQ¶eã…±ùA0žI>¦‡,o”Ói’ÖrûîGU¶k,E
+²WÌ}’x”B]1|DXáª
+)ÒI�8²×à|
+D}��`k°ùzH‹v;–<óç‘<k˜¹
mP7,ÏKÍt²}Ó|Û«"
+é�ÿBp7¥Œ+)ƒrì Ümp>Ķ�n‚sF…‹±#ø4¥	w}
vÓT`j�¯
K‚^ñÒ•‹µ±Ÿï�ÄQ¾¯Ì‡‹è8:4‰8�Œmúp€ÂŽq~ƒqq¯–p¾óE®nÒ#ü:O‹íkþáAL ƒº”ÍM);áZÊ ÜQ;¡;ÂÏ°Ç	ï�?�ŠÛrÇx
+ÈLíª¯ÝƒïüÂÙ)óWy�~„{¹ÿý_ýò£
Šòr�,4æ0[ÄV>ýˆzQx)]˜Rv>µTÇ'u�NèŽÏ3ìq>{à=}gE7½S.%«‚�ó©ê�ÏrjÇtå¬Q„Gõ1þYoÓm»›x1xé„´H!]Ò£ÈÑùp
RÀNä5ƒnŒ°­Q3+ZÄpEdôºP•:¢	þ0yCA»/ÁóêÁЯ%k”"J¼8õ÷'IQ猣o(À±�&B½
+endobj
+2252 0 obj <<
+/Type /Page
+/Contents 2253 0 R
+/Resources 2251 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 2118 0 R
 >> endobj
 2254 0 obj <<
-/D [2240 0 R /XYZ 85.0394 662.6262 null]
+/D [2252 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 2255 0 obj <<
-/D [2240 0 R /XYZ 85.0394 599.7666 null]
+/D [2252 0 R /XYZ 85.0394 748.4854 null]
 >> endobj
 2256 0 obj <<
-/D [2240 0 R /XYZ 85.0394 599.7666 null]
+/D [2252 0 R /XYZ 85.0394 748.4854 null]
 >> endobj
 2257 0 obj <<
-/D [2240 0 R /XYZ 85.0394 599.7666 null]
+/D [2252 0 R /XYZ 85.0394 748.4854 null]
 >> endobj
 2258 0 obj <<
-/D [2240 0 R /XYZ 85.0394 591.7571 null]
+/D [2252 0 R /XYZ 85.0394 743.3452 null]
 >> endobj
 2259 0 obj <<
-/D [2240 0 R /XYZ 85.0394 565.0374 null]
+/D [2252 0 R /XYZ 85.0394 728.6405 null]
 >> endobj
 2260 0 obj <<
-/D [2240 0 R /XYZ 85.0394 559.6222 null]
+/D [2252 0 R /XYZ 85.0394 723.1655 null]
 >> endobj
 2261 0 obj <<
-/D [2240 0 R /XYZ 85.0394 534.1777 null]
+/D [2252 0 R /XYZ 85.0394 708.4607 null]
 >> endobj
 2262 0 obj <<
-/D [2240 0 R /XYZ 85.0394 527.4872 null]
+/D [2252 0 R /XYZ 85.0394 702.9857 null]
 >> endobj
 2263 0 obj <<
-/D [2240 0 R /XYZ 85.0394 502.0427 null]
+/D [2252 0 R /XYZ 85.0394 688.2211 null]
 >> endobj
 2264 0 obj <<
-/D [2240 0 R /XYZ 85.0394 495.3523 null]
+/D [2252 0 R /XYZ 85.0394 682.8059 null]
 >> endobj
 2265 0 obj <<
-/D [2240 0 R /XYZ 85.0394 420.5376 null]
+/D [2252 0 R /XYZ 85.0394 668.0414 null]
 >> endobj
 2266 0 obj <<
-/D [2240 0 R /XYZ 85.0394 420.5376 null]
+/D [2252 0 R /XYZ 85.0394 662.6262 null]
 >> endobj
 2267 0 obj <<
-/D [2240 0 R /XYZ 85.0394 420.5376 null]
+/D [2252 0 R /XYZ 85.0394 599.7666 null]
 >> endobj
 2268 0 obj <<
-/D [2240 0 R /XYZ 85.0394 412.5281 null]
+/D [2252 0 R /XYZ 85.0394 599.7666 null]
 >> endobj
 2269 0 obj <<
-/D [2240 0 R /XYZ 85.0394 388.4584 null]
+/D [2252 0 R /XYZ 85.0394 599.7666 null]
 >> endobj
 2270 0 obj <<
-/D [2240 0 R /XYZ 85.0394 380.3932 null]
+/D [2252 0 R /XYZ 85.0394 591.7571 null]
 >> endobj
 2271 0 obj <<
-/D [2240 0 R /XYZ 85.0394 365.6884 null]
+/D [2252 0 R /XYZ 85.0394 565.0374 null]
 >> endobj
 2272 0 obj <<
-/D [2240 0 R /XYZ 85.0394 360.2134 null]
+/D [2252 0 R /XYZ 85.0394 559.6222 null]
 >> endobj
 2273 0 obj <<
-/D [2240 0 R /XYZ 85.0394 345.4488 null]
+/D [2252 0 R /XYZ 85.0394 534.1777 null]
 >> endobj
 2274 0 obj <<
-/D [2240 0 R /XYZ 85.0394 340.0336 null]
+/D [2252 0 R /XYZ 85.0394 527.4872 null]
 >> endobj
 2275 0 obj <<
-/D [2240 0 R /XYZ 85.0394 325.269 null]
+/D [2252 0 R /XYZ 85.0394 502.0427 null]
 >> endobj
 2276 0 obj <<
-/D [2240 0 R /XYZ 85.0394 319.8539 null]
+/D [2252 0 R /XYZ 85.0394 495.3523 null]
 >> endobj
 2277 0 obj <<
-/D [2240 0 R /XYZ 85.0394 295.7842 null]
+/D [2252 0 R /XYZ 85.0394 420.5376 null]
 >> endobj
 2278 0 obj <<
-/D [2240 0 R /XYZ 85.0394 287.7189 null]
+/D [2252 0 R /XYZ 85.0394 420.5376 null]
 >> endobj
 2279 0 obj <<
-/D [2240 0 R /XYZ 85.0394 272.9543 null]
+/D [2252 0 R /XYZ 85.0394 420.5376 null]
 >> endobj
 2280 0 obj <<
-/D [2240 0 R /XYZ 85.0394 267.5392 null]
+/D [2252 0 R /XYZ 85.0394 412.5281 null]
 >> endobj
 2281 0 obj <<
-/D [2240 0 R /XYZ 85.0394 252.7746 null]
+/D [2252 0 R /XYZ 85.0394 388.4584 null]
 >> endobj
 2282 0 obj <<
-/D [2240 0 R /XYZ 85.0394 247.3594 null]
+/D [2252 0 R /XYZ 85.0394 380.3932 null]
 >> endobj
 2283 0 obj <<
-/D [2240 0 R /XYZ 85.0394 223.2897 null]
+/D [2252 0 R /XYZ 85.0394 365.6884 null]
 >> endobj
 2284 0 obj <<
-/D [2240 0 R /XYZ 85.0394 215.2245 null]
+/D [2252 0 R /XYZ 85.0394 360.2134 null]
 >> endobj
 2285 0 obj <<
-/D [2240 0 R /XYZ 85.0394 149.4956 null]
+/D [2252 0 R /XYZ 85.0394 345.4488 null]
 >> endobj
 2286 0 obj <<
-/D [2240 0 R /XYZ 85.0394 149.4956 null]
+/D [2252 0 R /XYZ 85.0394 340.0336 null]
 >> endobj
 2287 0 obj <<
-/D [2240 0 R /XYZ 85.0394 149.4956 null]
+/D [2252 0 R /XYZ 85.0394 325.269 null]
 >> endobj
 2288 0 obj <<
-/D [2240 0 R /XYZ 85.0394 144.3554 null]
+/D [2252 0 R /XYZ 85.0394 319.8539 null]
 >> endobj
 2289 0 obj <<
-/D [2240 0 R /XYZ 85.0394 120.2857 null]
+/D [2252 0 R /XYZ 85.0394 295.7842 null]
 >> endobj
 2290 0 obj <<
-/D [2240 0 R /XYZ 85.0394 112.2205 null]
+/D [2252 0 R /XYZ 85.0394 287.7189 null]
 >> endobj
 2291 0 obj <<
-/D [2240 0 R /XYZ 85.0394 97.4559 null]
+/D [2252 0 R /XYZ 85.0394 272.9543 null]
 >> endobj
 2292 0 obj <<
-/D [2240 0 R /XYZ 85.0394 92.0407 null]
+/D [2252 0 R /XYZ 85.0394 267.5392 null]
 >> endobj
-2239 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R >>
-/ProcSet [ /PDF /Text ]
+2293 0 obj <<
+/D [2252 0 R /XYZ 85.0394 252.7746 null]
 >> endobj
-2295 0 obj <<
-/Length 2928      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZKs㸾ûWèºjÅ
-á
-/ágP´¸hmÞŠ†—ö´z,¾j枧Dãª;®cÝ"±ts/r/êë¾®Ö2//§¾Çœ;¹Î°Å�ù®i³5Q÷„#7?Ú¬lòªTÇt°;37Š£Ö…²‚)¡p®]=U6m!_³KN#¾#êK;Ò#KݸÒüŸåöe-K-å“,·²Þ¡VزQ4%Øi/`W‘{=§Ä}ïz×z†«C�‹h½1Õz‡º‡Ñ³u+lð3mÕMlšÊÄ5šŠcWÊužRç·ÍB¶Ù�	w}/±€Ts]ú 5Y£¨{³M�ÔÅ#Œ…ÂÆÇñ°¹NãÑquxbÄ›FUïñ8Ò=ˆGO÷ùóqoŠ„›$Áÿ€Á¯RuÓU‡Cr‡Ðw!žFgp°¸Fp0\ÁX<‚Øj‡CÝÃ8غ
"Ž5Ø28¨v‡ƒˆ#çd„ùÍ´¸æÈ—e^.©3Û¶«Jñãä…’Vb=Ïs>¸4ñŸ—�^³¢
-þU6M¶#šªÔ’\­£j0 
-p¹ë,µ]ÌÈœve"ù˜wÒ ö]Á‚3õ‚ÍuÒŽ«ƒ4F U½‡ôH÷ ¤=Ý�Ù"Cç)srq¾ÊÿDÄT¬ËÊ6ÃjY�ÉVR¡›]ë(	ýç¼Â�ÅnÁ"÷1‘qŠ‰0§‰FXBã^3ý²]¬·å¢i0jˆFhÄ.–/§!…K†ŸÐueR‹kRÃeA:’êFU[�ê†ÔÖ}�ÙÒŠ…˜¶Ìi¨´6'°Ôí¦ç•D!¯4Ü'½’Ç¡ëû1ïÇÍ{7{`Q�büï/À"|¸¦±3• Í5‹áê`‰F=mLµË¡îaXlÝ_
-*Ñ"§¬Z­ºêoƒP¡™Ki^Ü<0À‚R}…cn<ù›,Жb"UÿYUÛBS•Vl<gôýc[Ñ+0ª¬´4×$_��ÒXja/hõm|¡»-8fÍŸ¦Õz:„ÏF–¹’Ιó¼£/Y4y“2_«ªdÛ±hæ½Bç›çùhs
uÕráK(VKbmùhˆ+ù¦…HúùKÖÀò¨§¬¾MþƒëªlWz.Ø»Yâû*‡+çÀFõŠ{ÅÐYdÖ«vwdØV�{zàYO!¹®'¤zÒhƒ;
-B…{aª/;ÏÕVÇ
-õkD'. ~ØÉõ\°«H_G^²ýèä›»y.‹#<›Ø\ÇÙ„sæ›ØSé„ŸN$£Z÷‰äHí`"éi¥DÂíW,´�Ê^tÙ'Vȇ9r[ФY
÷®?$]�Y8yúª ô¿ä[œÈ}(97»:_®Tv™ð(†
ø1þÖÂô-"¥%
-اÅ÷�ñ`èv
-`+•Z1†^ž@¼lÐÛeg˜sŠ÷Ó�¬[M”›M‘ÓëY3gÖU^
-â§.|Rƒ¶Im3ìê\ñ–/²ƒI/UQTïT�`7“­.›ŸO@6�á™Ë±Í¥"QÏ‘#÷ÒÐ’¥=9:T�<{ãJ
Ó±ÒžÓÄÜ
ð׋žÒ'uIâ”Ù»:_h¦t4  ñ�‹âh‘£e�=A]-¶…ªÙ‚H{"’ÍWÒgÁNe)hXXQÌ�º€–…–Qj‘è˜/2Õ+.«Jº>
-®,¸è«ªíEšN¡hKÂsÚZ–�LµYÃÈ{Þ®¨%éƒÞš§ÛBÖÔo²úm_áóAÖ¢û9Ø(ããûÃ÷VSì¡Á
ø9-]@
v´tŸa€¢Á†ÂbC=¹x“�¯Á§D°�ØLÀ'sŬ(žCW$¢Ae™/¤y}æÝσ€ug¹ÄÚ7JÙÁà„ð“ÿìW¦*œªÕ/õÍ®LWkYm›ƒ»­¹ÙÉ+mœ¸p¼gž
-¦Óh˜Î9à˜ÆÎÿ5ºŸ­QyŸz5Яnçä^Š€W´Rå# >f-„·7ÌQØ¥‡ýýBgQιƒÿ9ÁÕ¥¥¡¾w!Ej™–wa#»š ëÆ�ÌjÁ_+ÊjUq²7â7ZHZ•/4‚Þh3"Ñf€Ä}–Þ6ë…ú}ÎW¹¤Ùd)ýÐD, {ËmmNæ@´zÄC"-|¿¤–zꢗ0Ê{¡d#ÓW¸î_šì0�À)¦u¾Ù¿v‡{–²Ñ['1´>å p½|§{ÂÎEàâ¿àë.ÿ÷úXo@‘+âøÄO'^¸094‹Ru¥-ÝüOÐñÚÿÔy
Lendstream
-endobj
 2294 0 obj <<
-/Type /Page
-/Contents 2295 0 R
-/Resources 2293 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 2328 0 R
+/D [2252 0 R /XYZ 85.0394 247.3594 null]
+>> endobj
+2295 0 obj <<
+/D [2252 0 R /XYZ 85.0394 223.2897 null]
 >> endobj
 2296 0 obj <<
-/D [2294 0 R /XYZ 56.6929 794.5015 null]
+/D [2252 0 R /XYZ 85.0394 215.2245 null]
 >> endobj
 2297 0 obj <<
-/D [2294 0 R /XYZ 56.6929 749.0089 null]
+/D [2252 0 R /XYZ 85.0394 149.4956 null]
 >> endobj
 2298 0 obj <<
-/D [2294 0 R /XYZ 56.6929 749.0089 null]
+/D [2252 0 R /XYZ 85.0394 149.4956 null]
 >> endobj
 2299 0 obj <<
-/D [2294 0 R /XYZ 56.6929 749.0089 null]
+/D [2252 0 R /XYZ 85.0394 149.4956 null]
 >> endobj
 2300 0 obj <<
-/D [2294 0 R /XYZ 56.6929 745.2843 null]
+/D [2252 0 R /XYZ 85.0394 144.3554 null]
 >> endobj
 2301 0 obj <<
-/D [2294 0 R /XYZ 56.6929 721.2146 null]
+/D [2252 0 R /XYZ 85.0394 120.2857 null]
 >> endobj
 2302 0 obj <<
-/D [2294 0 R /XYZ 56.6929 714.4694 null]
+/D [2252 0 R /XYZ 85.0394 112.2205 null]
 >> endobj
 2303 0 obj <<
-/D [2294 0 R /XYZ 56.6929 699.7048 null]
+/D [2252 0 R /XYZ 85.0394 97.4559 null]
 >> endobj
 2304 0 obj <<
-/D [2294 0 R /XYZ 56.6929 695.6096 null]
->> endobj
-2305 0 obj <<
-/D [2294 0 R /XYZ 56.6929 680.9049 null]
+/D [2252 0 R /XYZ 85.0394 92.0407 null]
 >> endobj
-2306 0 obj <<
-/D [2294 0 R /XYZ 56.6929 676.7499 null]
+2251 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
 2307 0 obj <<
-/D [2294 0 R /XYZ 56.6929 652.6802 null]
+/Length 2928      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZKs㸾ûWèºjÅ
+á
+/ágP´¸hmÞŠ†—ö´z,¾j枧Dãª;®cÝ"±ts/r/êë¾®Ö2//§¾Çœ;¹Î°Å�ù®i³5Q÷„#7?Ú¬lòªTÇt°;37Š£Ö…²‚)¡p®]=U6m!_³KN#¾#êK;Ò#KݸÒüŸåöe-K-å“,·²Þ¡VزQ4%Øi/`W‘{=§Ä}ïz×z†«C�‹h½1Õz‡º‡Ñ³u+lð3mÕMlšÊÄ5šŠcWÊužRç·ÍB¶Ù�	w}/±€Ts]ú 5Y£¨{³M�ÔÅ#Œ…ÂÆÇñ°¹NãÑquxbÄ›FUïñ8Ò=ˆGO÷ùóqoŠ„›$Áÿ€Á¯RuÓU‡Cr‡Ðw!žFgp°¸Fp0\ÁX<‚Øj‡CÝÃ8غ
"Ž5Ø28¨v‡ƒˆ#çd„ùÍ´¸æÈ—e^.©3Û¶«Jñãä…’Vb=Ïs>¸4ñŸ—�^³¢
+þU6M¶#šªÔ’\­£j0 
+p¹ë,µ]ÌÈœve"ù˜wÒ ö]Á‚3õ‚ÍuÒŽ«ƒ4F U½‡ôH÷ ¤=Ý�Ù"Cç)srq¾ÊÿDÄT¬ËÊ6ÃjY�ÉVR¡›]ë(	ýç¼Â�ÅnÁ"÷1‘qŠ‰0§‰FXBã^3ý²]¬·å¢i0jˆFhÄ.–/§!…K†ŸÐueR‹kRÃeA:’êFU[�ê†ÔÖ}�ÙÒŠ…˜¶Ìi¨´6'°Ôí¦ç•D!¯4Ü'½’Ç¡ëû1ïÇÍ{7{`Q�büï/À"|¸¦±3• Í5‹áê`‰F=mLµË¡îaXlÝ_
+*Ñ"§¬Z­ºêoƒP¡™Ki^Ü<0À‚R}…cn<ù›,Жb"UÿYUÛBS•Vl<gôýc[Ñ+0ª¬´4×$_��ÒXja/hõm|¡»-8fÍŸ¦Õz:„ÏF–¹’Ιó¼£/Y4y“2_«ªdÛ±hæ½Bç›çùhs
uÕráK(VKbmùhˆ+ù¦…HúùKÖÀò¨§¬¾MþƒëªlWz.Ø»Yâû*‡+çÀFõŠ{ÅÐYdÖ«vwdØV�{zàYO!¹®'¤zÒhƒ;
+B…{aª/;ÏÕVÇ
+õkD'. ~ØÉõ\°«H_G^²ýèä›»y.‹#<›Ø\ÇÙ„sæ›ØSé„ŸN$£Z÷‰äHí`"éi¥DÂíW,´�Ê^tÙ'Vȇ9r[ФY
÷®?$]�Y8yúª ô¿ä[œÈ}(97»:_®Tv™ð(†
ø1þÖÂô-"¥%
+اÅ÷�ñ`èv
+`+•Z1†^ž@¼lÐÛeg˜sŠ÷Ó�¬[M”›M‘ÓëY3gÖU^
+â§.|Rƒ¶Im3ìê\ñ–/²ƒI/UQTïT�`7“­.›ŸO@6�á™Ë±Í¥"QÏ‘#÷ÒÐ’¥=9:T�<{ãJ
Ó±ÒžÓÄÜ
ð׋žÒ'uIâ”Ù»:_h¦t4  ñ�‹âh‘£e�=A]-¶…ªÙ‚H{"’ÍWÒgÁNe)hXXQÌ�º€–…–Qj‘è˜/2Õ+.«Jº>
+®,¸è«ªíEšN¡hKÂsÚZ–�LµYÃÈ{Þ®¨%éƒÞš§ÛBÖÔo²úm_áóAÖ¢û9Ø(ããûÃ÷VSì¡Á
ø9-]@
v´tŸa€¢Á†ÂbC=¹x“�¯Á§D°�ØLÀ'sŬ(žCW$¢Ae™/¤y}æÝσ€ug¹ÄÚ7JÙÁà„ð“ÿìW¦*œªÕ/õÍ®LWkYm›ƒ»­¹ÙÉ+mœ¸p¼gž
-¦Óh˜Î9à˜ÆÎÿ5ºŸ­QyŸz5Яnçä^Š€W´Rå# >f-„·7ÌQØ¥‡ýýBgQιƒÿ9ÁÕ¥¥¡¾w!Ej™–wa#»š ëÆ�ÌjÁ_+ÊjUq²7â7ZHZ•/4‚Þh3"Ñf€Ä}–Þ6ë…ú}ÎW¹¤Ùd)ýÐD, {ËmmNæ@´zÄC"-|¿¤–zꢗ0Ê{¡d#ÓW¸î_šì0�À)¦u¾Ù¿v‡{–²Ñ['1´>å p½|§{ÂÎEàâ¿àë.ÿ÷úXo@‘+âøÄO'^¸094‹Ru¥-ÝüOÐñÚÿÔy
Lendstream
+endobj
+2306 0 obj <<
+/Type /Page
+/Contents 2307 0 R
+/Resources 2305 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 2340 0 R
 >> endobj
 2308 0 obj <<
-/D [2294 0 R /XYZ 56.6929 645.935 null]
+/D [2306 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 2309 0 obj <<
-/D [2294 0 R /XYZ 56.6929 631.2303 null]
+/D [2306 0 R /XYZ 56.6929 749.0089 null]
 >> endobj
 2310 0 obj <<
-/D [2294 0 R /XYZ 56.6929 627.0752 null]
+/D [2306 0 R /XYZ 56.6929 749.0089 null]
 >> endobj
 2311 0 obj <<
-/D [2294 0 R /XYZ 56.6929 603.0055 null]
+/D [2306 0 R /XYZ 56.6929 749.0089 null]
 >> endobj
 2312 0 obj <<
-/D [2294 0 R /XYZ 56.6929 596.2603 null]
+/D [2306 0 R /XYZ 56.6929 745.2843 null]
 >> endobj
 2313 0 obj <<
-/D [2294 0 R /XYZ 56.6929 572.1906 null]
+/D [2306 0 R /XYZ 56.6929 721.2146 null]
 >> endobj
 2314 0 obj <<
-/D [2294 0 R /XYZ 56.6929 565.4454 null]
+/D [2306 0 R /XYZ 56.6929 714.4694 null]
 >> endobj
 2315 0 obj <<
-/D [2294 0 R /XYZ 56.6929 550.7407 null]
+/D [2306 0 R /XYZ 56.6929 699.7048 null]
 >> endobj
 2316 0 obj <<
-/D [2294 0 R /XYZ 56.6929 546.5857 null]
+/D [2306 0 R /XYZ 56.6929 695.6096 null]
 >> endobj
 2317 0 obj <<
-/D [2294 0 R /XYZ 56.6929 531.8211 null]
+/D [2306 0 R /XYZ 56.6929 680.9049 null]
 >> endobj
 2318 0 obj <<
-/D [2294 0 R /XYZ 56.6929 527.7259 null]
+/D [2306 0 R /XYZ 56.6929 676.7499 null]
 >> endobj
 2319 0 obj <<
-/D [2294 0 R /XYZ 56.6929 501.0062 null]
+/D [2306 0 R /XYZ 56.6929 652.6802 null]
 >> endobj
 2320 0 obj <<
-/D [2294 0 R /XYZ 56.6929 496.911 null]
->> endobj
-770 0 obj <<
-/D [2294 0 R /XYZ 56.6929 464.7873 null]
+/D [2306 0 R /XYZ 56.6929 645.935 null]
 >> endobj
 2321 0 obj <<
-/D [2294 0 R /XYZ 56.6929 439.0859 null]
->> endobj
-774 0 obj <<
-/D [2294 0 R /XYZ 56.6929 352.4521 null]
+/D [2306 0 R /XYZ 56.6929 631.2303 null]
 >> endobj
 2322 0 obj <<
-/D [2294 0 R /XYZ 56.6929 326.7507 null]
+/D [2306 0 R /XYZ 56.6929 627.0752 null]
 >> endobj
 2323 0 obj <<
-/D [2294 0 R /XYZ 56.6929 290.6891 null]
+/D [2306 0 R /XYZ 56.6929 603.0055 null]
 >> endobj
 2324 0 obj <<
-/D [2294 0 R /XYZ 56.6929 290.6891 null]
+/D [2306 0 R /XYZ 56.6929 596.2603 null]
 >> endobj
 2325 0 obj <<
-/D [2294 0 R /XYZ 56.6929 290.6891 null]
+/D [2306 0 R /XYZ 56.6929 572.1906 null]
 >> endobj
 2326 0 obj <<
-/D [2294 0 R /XYZ 56.6929 290.6891 null]
+/D [2306 0 R /XYZ 56.6929 565.4454 null]
+>> endobj
+2327 0 obj <<
+/D [2306 0 R /XYZ 56.6929 550.7407 null]
+>> endobj
+2328 0 obj <<
+/D [2306 0 R /XYZ 56.6929 546.5857 null]
+>> endobj
+2329 0 obj <<
+/D [2306 0 R /XYZ 56.6929 531.8211 null]
+>> endobj
+2330 0 obj <<
+/D [2306 0 R /XYZ 56.6929 527.7259 null]
+>> endobj
+2331 0 obj <<
+/D [2306 0 R /XYZ 56.6929 501.0062 null]
+>> endobj
+2332 0 obj <<
+/D [2306 0 R /XYZ 56.6929 496.911 null]
 >> endobj
 778 0 obj <<
-/D [2294 0 R /XYZ 56.6929 241.4457 null]
+/D [2306 0 R /XYZ 56.6929 464.7873 null]
 >> endobj
-2327 0 obj <<
-/D [2294 0 R /XYZ 56.6929 201.7704 null]
+2333 0 obj <<
+/D [2306 0 R /XYZ 56.6929 439.0859 null]
 >> endobj
-2293 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R /F14 956 0 R >>
+782 0 obj <<
+/D [2306 0 R /XYZ 56.6929 352.4521 null]
+>> endobj
+2334 0 obj <<
+/D [2306 0 R /XYZ 56.6929 326.7507 null]
+>> endobj
+2335 0 obj <<
+/D [2306 0 R /XYZ 56.6929 290.6891 null]
+>> endobj
+2336 0 obj <<
+/D [2306 0 R /XYZ 56.6929 290.6891 null]
+>> endobj
+2337 0 obj <<
+/D [2306 0 R /XYZ 56.6929 290.6891 null]
+>> endobj
+2338 0 obj <<
+/D [2306 0 R /XYZ 56.6929 290.6891 null]
+>> endobj
+786 0 obj <<
+/D [2306 0 R /XYZ 56.6929 241.4457 null]
+>> endobj
+2339 0 obj <<
+/D [2306 0 R /XYZ 56.6929 201.7704 null]
+>> endobj
+2305 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R /F14 964 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2331 0 obj <<
+2343 0 obj <<
 /Length 2293      
 /Filter /FlateDecode
 >>
@@ -11033,45 +11095,45 @@ P#¢�
&6æ0wV}-±b]íO«–í%9µ2¶žTû¾Ò�“žAäíEÑѣ̀~ãÊ»Ì^¹¾'åe	±)ìúŸ`ÖnqaSx¿áÄ«¶´
 qï"qù
 uä…gÿ/JD»æendstream
 endobj
-2330 0 obj <<
+2342 0 obj <<
 /Type /Page
-/Contents 2331 0 R
-/Resources 2329 0 R
+/Contents 2343 0 R
+/Resources 2341 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2328 0 R
+/Parent 2340 0 R
 >> endobj
-2332 0 obj <<
-/D [2330 0 R /XYZ 85.0394 794.5015 null]
+2344 0 obj <<
+/D [2342 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-782 0 obj <<
-/D [2330 0 R /XYZ 85.0394 662.3711 null]
+790 0 obj <<
+/D [2342 0 R /XYZ 85.0394 662.3711 null]
 >> endobj
-2333 0 obj <<
-/D [2330 0 R /XYZ 85.0394 634.4781 null]
+2345 0 obj <<
+/D [2342 0 R /XYZ 85.0394 634.4781 null]
 >> endobj
-786 0 obj <<
-/D [2330 0 R /XYZ 85.0394 566.8617 null]
+794 0 obj <<
+/D [2342 0 R /XYZ 85.0394 566.8617 null]
 >> endobj
-2334 0 obj <<
-/D [2330 0 R /XYZ 85.0394 536.3186 null]
+2346 0 obj <<
+/D [2342 0 R /XYZ 85.0394 536.3186 null]
 >> endobj
-790 0 obj <<
-/D [2330 0 R /XYZ 85.0394 411.7882 null]
+798 0 obj <<
+/D [2342 0 R /XYZ 85.0394 411.7882 null]
 >> endobj
-2335 0 obj <<
-/D [2330 0 R /XYZ 85.0394 386.7645 null]
+2347 0 obj <<
+/D [2342 0 R /XYZ 85.0394 386.7645 null]
 >> endobj
-794 0 obj <<
-/D [2330 0 R /XYZ 85.0394 230.2565 null]
+802 0 obj <<
+/D [2342 0 R /XYZ 85.0394 230.2565 null]
 >> endobj
-2336 0 obj <<
-/D [2330 0 R /XYZ 85.0394 203.9874 null]
+2348 0 obj <<
+/D [2342 0 R /XYZ 85.0394 203.9874 null]
 >> endobj
-2329 0 obj <<
-/Font << /F37 1018 0 R /F14 956 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R >>
+2341 0 obj <<
+/Font << /F37 1026 0 R /F14 964 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2339 0 obj <<
+2351 0 obj <<
 /Length 2527      
 /Filter /FlateDecode
 >>
@@ -11090,47 +11152,47 @@ A!zBΪª	zÊaÄwI�l3H’ ²R7IK#«pˆ1‚¾‡JʤM.“]²È‹¼=Ð<QÊF,\zÔya`,öºu1ƒâA
 H¨ã
 e0ì>Ùr${ÑÁãÍðÍtÜŠzéÙüDñùîÏ¡9rP#nß�Ô“±ÏOè(
µ”GµMo£g~ÿÑèþ�¾–Ž¥4úøôyyyI´î	KyÅK�¶˜¦C7c§±¯ë)ÆãØ£�‘8hyøí�Î,|¦ïO ðOcŸ�õ;²2ˆ�m–h	CnÚwš‡i3ÁEHèówUfÿ4ûðU‚ð`¡É×%Ý(í6O!•î‰%[VÏ¥!Ø£Ò``Û.X»+ÛÚÐÝU�ù‡ž×]DÎï�a38îÈË­�-Õ6oé+ª&i6‰ ‰yÊÄ_ì��E\áê⃣òþR5âѼ«ÃÿïÄŽ/—T•Ñ¥^A†Ð±Ä06B¡„ŒÎ#©ùéì\öÿ=k-¢endstream
 endobj
-2338 0 obj <<
+2350 0 obj <<
 /Type /Page
-/Contents 2339 0 R
-/Resources 2337 0 R
+/Contents 2351 0 R
+/Resources 2349 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2328 0 R
-/Annots [ 2342 0 R ]
+/Parent 2340 0 R
+/Annots [ 2354 0 R ]
 >> endobj
-2342 0 obj <<
+2354 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [344.9397 501.3201 406.1397 512.7122]
 /Subtype /Link
 /A << /S /GoTo /D (trusted-keys) >>
 >> endobj
-2340 0 obj <<
-/D [2338 0 R /XYZ 56.6929 794.5015 null]
+2352 0 obj <<
+/D [2350 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-798 0 obj <<
-/D [2338 0 R /XYZ 56.6929 609.3932 null]
+806 0 obj <<
+/D [2350 0 R /XYZ 56.6929 609.3932 null]
 >> endobj
-2341 0 obj <<
-/D [2338 0 R /XYZ 56.6929 583.208 null]
+2353 0 obj <<
+/D [2350 0 R /XYZ 56.6929 583.208 null]
 >> endobj
-802 0 obj <<
-/D [2338 0 R /XYZ 56.6929 484.1849 null]
+810 0 obj <<
+/D [2350 0 R /XYZ 56.6929 484.1849 null]
 >> endobj
-2343 0 obj <<
-/D [2338 0 R /XYZ 56.6929 454.463 null]
+2355 0 obj <<
+/D [2350 0 R /XYZ 56.6929 454.463 null]
 >> endobj
-806 0 obj <<
-/D [2338 0 R /XYZ 56.6929 405.4622 null]
+814 0 obj <<
+/D [2350 0 R /XYZ 56.6929 405.4622 null]
 >> endobj
-2344 0 obj <<
-/D [2338 0 R /XYZ 56.6929 378.8348 null]
+2356 0 obj <<
+/D [2350 0 R /XYZ 56.6929 378.8348 null]
 >> endobj
-2337 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F14 956 0 R /F22 953 0 R /F21 930 0 R >>
+2349 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F14 964 0 R /F22 961 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2347 0 obj <<
+2359 0 obj <<
 /Length 2458      
 /Filter /FlateDecode
 >>
@@ -11141,39 +11203,39 @@ xÚÍZ[oÛ:~ϯðÛq€c–w‰yKÛì"»9Ù&vÑöA±åD¨,¹’œË¿ß!‡TD[¶Hv±(ZÓähøif8ó
k6¡ð‡MRE¨0r’
 ¤px—�í¾¾ã bzéQ×Nñˆk¡!µíïÛŒbÓeÑùb
q¥‘Gåþ`…¸Þ=·,M‰N(
 É)´ ½�
n»v—?d�EÈ€Ò‰£~v›.û™±)8�±sY©F)á ¨
 endobj
-2346 0 obj <<
+2358 0 obj <<
 /Type /Page
-/Contents 2347 0 R
-/Resources 2345 0 R
+/Contents 2359 0 R
+/Resources 2357 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2328 0 R
+/Parent 2340 0 R
 >> endobj
-2348 0 obj <<
-/D [2346 0 R /XYZ 85.0394 794.5015 null]
+2360 0 obj <<
+/D [2358 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-810 0 obj <<
-/D [2346 0 R /XYZ 85.0394 650.8348 null]
+818 0 obj <<
+/D [2358 0 R /XYZ 85.0394 650.8348 null]
 >> endobj
-2349 0 obj <<
-/D [2346 0 R /XYZ 85.0394 625.7398 null]
+2361 0 obj <<
+/D [2358 0 R /XYZ 85.0394 625.7398 null]
 >> endobj
-814 0 obj <<
-/D [2346 0 R /XYZ 85.0394 378.0874 null]
+822 0 obj <<
+/D [2358 0 R /XYZ 85.0394 378.0874 null]
 >> endobj
-2350 0 obj <<
-/D [2346 0 R /XYZ 85.0394 350.2627 null]
+2362 0 obj <<
+/D [2358 0 R /XYZ 85.0394 350.2627 null]
 >> endobj
-818 0 obj <<
-/D [2346 0 R /XYZ 85.0394 153.7325 null]
+826 0 obj <<
+/D [2358 0 R /XYZ 85.0394 153.7325 null]
 >> endobj
-2351 0 obj <<
-/D [2346 0 R /XYZ 85.0394 128.6375 null]
+2363 0 obj <<
+/D [2358 0 R /XYZ 85.0394 128.6375 null]
 >> endobj
-2345 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R >>
+2357 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2354 0 obj <<
+2366 0 obj <<
 /Length 2394      
 /Filter /FlateDecode
 >>
@@ -11186,28 +11248,28 @@ j[áëÉϾh’Y²¨¡ò«?ú—ê£çE›Ì€ÈWL+¸½zØ;�þF6¼¹ÙùÒÍ›¬¦øç…°c­GÈ\™Jõ7ÝÁZÀ-l�¾…¡pq
 �ÔGÏ^¬×›zí¿éú¨
™"ù<–&qp‰¬¡që?ÖÉW4`Vö·!ŒîÇÊ�é@5Nßfy
 —„oÍ98ŒÍ již–î�•.¡UÔè
jӑ
й^�ÖQ›ENj¾×¡ËÚB-3s½h˜£üG®ù…ßQ‹GC.ý9òÃtRr.Îçwùù9”ªúG
½ÿ«dZgNÂ_
 endobj
-2353 0 obj <<
+2365 0 obj <<
 /Type /Page
-/Contents 2354 0 R
-/Resources 2352 0 R
+/Contents 2366 0 R
+/Resources 2364 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2328 0 R
+/Parent 2340 0 R
 >> endobj
-2355 0 obj <<
-/D [2353 0 R /XYZ 56.6929 794.5015 null]
+2367 0 obj <<
+/D [2365 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-822 0 obj <<
-/D [2353 0 R /XYZ 56.6929 740.3318 null]
+830 0 obj <<
+/D [2365 0 R /XYZ 56.6929 740.3318 null]
 >> endobj
-2356 0 obj <<
-/D [2353 0 R /XYZ 56.6929 714.7319 null]
+2368 0 obj <<
+/D [2365 0 R /XYZ 56.6929 714.7319 null]
 >> endobj
-2352 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F14 956 0 R /F62 1351 0 R /F41 1208 0 R >>
-/XObject << /Im2 1340 0 R >>
+2364 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F14 964 0 R /F62 1361 0 R /F41 1218 0 R >>
+/XObject << /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2359 0 obj <<
+2371 0 obj <<
 /Length 1890      
 /Filter /FlateDecode
 >>
@@ -11219,53 +11281,53 @@ xÚ­ÉnÛ8ôî¯ðQj–›¶™SÚ¦ƒE›IR`i²DÇBµ¸’'óõóÈGÊ’­$t’ƒžÉÇ·o$›SøgóÈ'TÄrÆ’ø”ùó´œÑ
 `4‰i_õÞÛ‡XxŸª|.ò9ºõ
€2°ÅÖZUe¦„¦óÁ–­Å°ós§šÜ¤,›á&èZ…û‡«.¬c±Ö¤ëÒî�ŽæBËMdghR½‹é7M»*s“T?öj‡þ~4¥IQàÄ{̲þɺç0%ýÜκÛv´f'Ìì$28z¯ñ=�PW…O È†ýCGhŸ9>»¯™£ÕZ5ªJQá—_'δ·1ýµY# 5y
 jm¥	-·Çª¿k7„ÂA­k™T»¤°Z�È[xC[úê1UÛ	8tIMw%D­EÚ¨�%\±nÝŸšH˜p°™�µ}k²Iò
 endobj
-2358 0 obj <<
+2370 0 obj <<
 /Type /Page
-/Contents 2359 0 R
-/Resources 2357 0 R
+/Contents 2371 0 R
+/Resources 2369 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2328 0 R
+/Parent 2340 0 R
 >> endobj
-2360 0 obj <<
-/D [2358 0 R /XYZ 85.0394 794.5015 null]
+2372 0 obj <<
+/D [2370 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-826 0 obj <<
-/D [2358 0 R /XYZ 85.0394 741.6375 null]
+834 0 obj <<
+/D [2370 0 R /XYZ 85.0394 741.6375 null]
 >> endobj
-2361 0 obj <<
-/D [2358 0 R /XYZ 85.0394 716.9352 null]
+2373 0 obj <<
+/D [2370 0 R /XYZ 85.0394 716.9352 null]
 >> endobj
-830 0 obj <<
-/D [2358 0 R /XYZ 85.0394 420.5643 null]
+838 0 obj <<
+/D [2370 0 R /XYZ 85.0394 420.5643 null]
 >> endobj
-2362 0 obj <<
-/D [2358 0 R /XYZ 85.0394 393.2598 null]
+2374 0 obj <<
+/D [2370 0 R /XYZ 85.0394 393.2598 null]
 >> endobj
-2357 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R >>
+2369 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2365 0 obj <<
+2377 0 obj <<
 /Length 69        
 /Filter /FlateDecode
 >>
 stream
 xÚ3T0
 endobj
-2364 0 obj <<
+2376 0 obj <<
 /Type /Page
-/Contents 2365 0 R
-/Resources 2363 0 R
+/Contents 2377 0 R
+/Resources 2375 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2367 0 R
+/Parent 2379 0 R
 >> endobj
-2366 0 obj <<
-/D [2364 0 R /XYZ 56.6929 794.5015 null]
+2378 0 obj <<
+/D [2376 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2363 0 obj <<
+2375 0 obj <<
 /ProcSet [ /PDF ]
 >> endobj
-2370 0 obj <<
+2382 0 obj <<
 /Length 1945      
 /Filter /FlateDecode
 >>
@@ -11283,42 +11345,42 @@ c˜�"v¨¯]¿x
/¨¦zŠ©,ƒ‡“�jì^MÈ=n´B$ŽÌÿ/Š™AÃozrm@�	£óÀ’O#°ã—_ØäƒcÒú:ƒÄl²«Ö
 iô¦?ÿûãçOþóš
Þn1�˜)f3+�NAÍï7QUÊñ§êgCí r õ�(G§ÀM¡É\3-äY=òaoø‰ëà¤m!.cÖAs/ç˜S¤à¬“içÞ7˜P²nïèK]-Þ}¤/ýÞà[fÌ)Qˆéªhij;Œú«p}ÓXåž\E4z%d˜^§ÙüCIMÒ©sgLü¬
 §g=42¾ûùÁC#j*u[øa;xs»icŸì½‡ÁKØù;üø<fø³ìäC;°$GúEöÔfГ/UJ�7üÀûò¼ÿTÆžvendstream
 endobj
-2369 0 obj <<
+2381 0 obj <<
 /Type /Page
-/Contents 2370 0 R
-/Resources 2368 0 R
+/Contents 2382 0 R
+/Resources 2380 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2367 0 R
+/Parent 2379 0 R
 >> endobj
-2371 0 obj <<
-/D [2369 0 R /XYZ 85.0394 794.5015 null]
+2383 0 obj <<
+/D [2381 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-834 0 obj <<
-/D [2369 0 R /XYZ 85.0394 769.5949 null]
+842 0 obj <<
+/D [2381 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-2372 0 obj <<
-/D [2369 0 R /XYZ 85.0394 573.0107 null]
+2384 0 obj <<
+/D [2381 0 R /XYZ 85.0394 573.0107 null]
 >> endobj
-838 0 obj <<
-/D [2369 0 R /XYZ 85.0394 573.0107 null]
+846 0 obj <<
+/D [2381 0 R /XYZ 85.0394 573.0107 null]
 >> endobj
-2373 0 obj <<
-/D [2369 0 R /XYZ 85.0394 538.4209 null]
+2385 0 obj <<
+/D [2381 0 R /XYZ 85.0394 538.4209 null]
 >> endobj
-2374 0 obj <<
-/D [2369 0 R /XYZ 85.0394 504.6118 null]
+2386 0 obj <<
+/D [2381 0 R /XYZ 85.0394 504.6118 null]
 >> endobj
-2375 0 obj <<
-/D [2369 0 R /XYZ 85.0394 432.7569 null]
+2387 0 obj <<
+/D [2381 0 R /XYZ 85.0394 432.7569 null]
 >> endobj
-2376 0 obj <<
-/D [2369 0 R /XYZ 85.0394 303.3232 null]
+2388 0 obj <<
+/D [2381 0 R /XYZ 85.0394 303.3232 null]
 >> endobj
-2368 0 obj <<
-/Font << /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F53 1303 0 R >>
+2380 0 obj <<
+/Font << /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2379 0 obj <<
+2391 0 obj <<
 /Length 3825      
 /Filter /FlateDecode
 >>
@@ -11340,27 +11402,27 @@ bÎDü…îR
 "BV˜ñ�I§ë†¾xÀfHÏqàÛw/çï^%cÁ8`–Y(bOud)ú	O¨&y¢álD
 ×Tˆc÷Âà)†Ì‰HÉ´õ0QÉÓÁù âþ“I‘r5Æ|Äï4K‹0AN�EÞóTS_Q-ëÁ'ïÑþ´ôŸõnx’»¢ÂK2œvE”'0«
 ‚ÕrœÀ4d‹VM}­°¢Æ¾ÌáK‰ÿù{éã×àÚDÊÚ‰o|b‰amfÊ¡¥O¿eâ/«Oyÿ/eRÈpendstream
 endobj
-2378 0 obj <<
+2390 0 obj <<
 /Type /Page
-/Contents 2379 0 R
-/Resources 2377 0 R
+/Contents 2391 0 R
+/Resources 2389 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2367 0 R
+/Parent 2379 0 R
 >> endobj
-2380 0 obj <<
-/D [2378 0 R /XYZ 56.6929 794.5015 null]
+2392 0 obj <<
+/D [2390 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2381 0 obj <<
-/D [2378 0 R /XYZ 56.6929 752.1413 null]
+2393 0 obj <<
+/D [2390 0 R /XYZ 56.6929 752.1413 null]
 >> endobj
-2382 0 obj <<
-/D [2378 0 R /XYZ 56.6929 501.191 null]
+2394 0 obj <<
+/D [2390 0 R /XYZ 56.6929 501.191 null]
 >> endobj
-2377 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F48 1228 0 R /F53 1303 0 R /F11 1441 0 R >>
+2389 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F48 1238 0 R /F53 1313 0 R /F11 1451 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2385 0 obj <<
+2397 0 obj <<
 /Length 3125      
 /Filter /FlateDecode
 >>
@@ -11379,24 +11441,24 @@ V!fù–+·»*ïÊ	¯K!�iÍÅMx]BgŠep²é@Å©•aW¥€*’$±bXµ
€´d/á{´°P‹ˆ»àÁ²©'FvH
 ŒgKo<Yí>ç@Ý6ß±ãE-Ù‹Pð­zÍ[;¢·˜S±·).+q^ri ÍòÌ^ñÓ¾Ö~ú«ÉÞ¸JØçÉÉ—:MNNÊ‘Óò<9�UÞ“Ó‘öir¨7ä[š“¼Ì¢!“LNX¢u‚‡z"9-Wåò™6ÔU‹gÉ‚ž
 š†üfaßËý
 endobj
-2384 0 obj <<
+2396 0 obj <<
 /Type /Page
-/Contents 2385 0 R
-/Resources 2383 0 R
+/Contents 2397 0 R
+/Resources 2395 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2367 0 R
+/Parent 2379 0 R
 >> endobj
-2386 0 obj <<
-/D [2384 0 R /XYZ 85.0394 794.5015 null]
+2398 0 obj <<
+/D [2396 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2387 0 obj <<
-/D [2384 0 R /XYZ 85.0394 679.319 null]
+2399 0 obj <<
+/D [2396 0 R /XYZ 85.0394 679.319 null]
 >> endobj
-2383 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F41 1208 0 R /F21 930 0 R /F48 1228 0 R /F53 1303 0 R >>
+2395 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F41 1218 0 R /F21 938 0 R /F48 1238 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2390 0 obj <<
+2402 0 obj <<
 /Length 2873      
 /Filter /FlateDecode
 >>
@@ -11409,21 +11471,21 @@ xÚ¥ZÝsÛ¸÷_¡Gy£
‚dgú�LÒL®½Ô=»“vr~ DÚâ„"‘ŠÏ÷×w�Å'ERioü@Xb»¿ý‚LWüÑU"ˆÈã|•æœ
 Rß½ù]k²ÑþŸ¯Z<ál¶îÅ`«Ú’Y0P‘š\ê}ªy8X*‹wÅþkBL8l™¹¥:ç>
 í©,ŽÒ�ý;¿<÷Pݘ<,\aZ5ÅJ1¶úŸ~¼ezÔzÁ0PÌfâR»èS-ÆP9ÃèŸfÏo ȱ4§Ëü-Õ¹
 endobj
-2389 0 obj <<
+2401 0 obj <<
 /Type /Page
-/Contents 2390 0 R
-/Resources 2388 0 R
+/Contents 2402 0 R
+/Resources 2400 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2367 0 R
+/Parent 2379 0 R
 >> endobj
-2391 0 obj <<
-/D [2389 0 R /XYZ 56.6929 794.5015 null]
+2403 0 obj <<
+/D [2401 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2388 0 obj <<
-/Font << /F37 1018 0 R /F48 1228 0 R /F22 953 0 R /F21 930 0 R /F53 1303 0 R >>
+2400 0 obj <<
+/Font << /F37 1026 0 R /F48 1238 0 R /F22 961 0 R /F21 938 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2394 0 obj <<
+2406 0 obj <<
 /Length 3204      
 /Filter /FlateDecode
 >>
@@ -11441,21 +11503,21 @@ jA®åxFz�')axŸQ
Tœ¿R¡öÞ M5q¥ž*\)¤…u¾<&™Ÿb€ûxLè°ÿ%‡¼¶Æ;¢©Œ i¼¿{iǃ†Ú.�y
 v_¨j[DLåˆBØjª½iÏ)G,&Y¢
ï^Ô¢$‘4é0ÿ¯­>ÍD™ëÐôÀàE?€QÀìØU­v’ÙÏá4s×m¦¦#Y¬²Æ¶ÖXšö�8K�Í%%:–I7'ùgèèJüË%	gôÛ±å÷›Ÿ6AزLz®Ó¸òÅ-ÄÍñŒ$žy«ýæ?<ýY¤HÇŸYFÀcA8O©
 
 endobj
-2393 0 obj <<
+2405 0 obj <<
 /Type /Page
-/Contents 2394 0 R
-/Resources 2392 0 R
+/Contents 2406 0 R
+/Resources 2404 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2367 0 R
+/Parent 2379 0 R
 >> endobj
-2395 0 obj <<
-/D [2393 0 R /XYZ 85.0394 794.5015 null]
+2407 0 obj <<
+/D [2405 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2392 0 obj <<
-/Font << /F37 1018 0 R /F48 1228 0 R /F22 953 0 R /F53 1303 0 R /F41 1208 0 R /F21 930 0 R >>
+2404 0 obj <<
+/Font << /F37 1026 0 R /F48 1238 0 R /F22 961 0 R /F53 1313 0 R /F41 1218 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2398 0 obj <<
+2410 0 obj <<
 /Length 2352      
 /Filter /FlateDecode
 >>
@@ -11466,36 +11528,36 @@ xÚ¥]oÛ8ò=¿Âœ‚Ö,?õ±oé&íy‘¦Ù&vÑíƒ,1‰PYr-9iöpÿýf8¤,;Êf?�Ž†ó=CZÌ8üÄÌÄ,Îd6K2Í
 Ýèäá| 8“¤§½½:wa™êdw2²xº¸:y{~6•€ãZ‡De›ûŠÌÖе•pŸƒç.kw—–¡B�òœÎ�>½ÎÝÂUaØ?Á�J½!¨W(&3ÐMdÜp%¶ª;h¶].Ÿ¨)З	ùbþÒJ‹mŽÓhÛtϤ[Ð ×ÉAº}·8o}‡½û8¿¾±}ñfc»¶¾gâ7S7âüû_?œýç
V7Å|ÿì«3ÿäxr~õñå÷Æ»¶ë1Û
 Ì£¯w¨%Ó°lºÎóoöñÖ6£Mw‚ÊÆê‹¡Óƒþ>½ûYpe¦Zƒ”%fÀ›V°„$ª³l_Æ·Ÿß_½\¾À÷B®sw´ñ§Ù%8PxiýcÅê/^@ØsÏûÊ0|“Ÿxëæƒ8ÿ÷Óÿî�
�6•Ó�æ21>ŽS¨¡Ò'¬¸«XNðþ_Q¯t"endstream
 endobj
-2397 0 obj <<
+2409 0 obj <<
 /Type /Page
-/Contents 2398 0 R
-/Resources 2396 0 R
+/Contents 2410 0 R
+/Resources 2408 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2405 0 R
+/Parent 2417 0 R
 >> endobj
-2399 0 obj <<
-/D [2397 0 R /XYZ 56.6929 794.5015 null]
+2411 0 obj <<
+/D [2409 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2400 0 obj <<
-/D [2397 0 R /XYZ 56.6929 684.0581 null]
+2412 0 obj <<
+/D [2409 0 R /XYZ 56.6929 684.0581 null]
 >> endobj
-2401 0 obj <<
-/D [2397 0 R /XYZ 56.6929 374.4503 null]
+2413 0 obj <<
+/D [2409 0 R /XYZ 56.6929 374.4503 null]
 >> endobj
-2402 0 obj <<
-/D [2397 0 R /XYZ 56.6929 253.2552 null]
+2414 0 obj <<
+/D [2409 0 R /XYZ 56.6929 253.2552 null]
 >> endobj
-2403 0 obj <<
-/D [2397 0 R /XYZ 56.6929 159.1805 null]
+2415 0 obj <<
+/D [2409 0 R /XYZ 56.6929 159.1805 null]
 >> endobj
-2404 0 obj <<
-/D [2397 0 R /XYZ 56.6929 85.8061 null]
+2416 0 obj <<
+/D [2409 0 R /XYZ 56.6929 85.8061 null]
 >> endobj
-2396 0 obj <<
-/Font << /F37 1018 0 R /F48 1228 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R /F53 1303 0 R /F39 1151 0 R >>
+2408 0 obj <<
+/Font << /F37 1026 0 R /F48 1238 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R /F53 1313 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2408 0 obj <<
+2420 0 obj <<
 /Length 3447      
 /Filter /FlateDecode
 >>
@@ -11513,36 +11575,36 @@ B_gœOൟC95Òky©šž¼4”Ã
Ä;:ò½ËP)w­Í¼3é¤1T^�Þ�Cˆ;�;ÄàO>³Ç(Ι
ê%â8¡kÈwØ9†
 6š3¹{Iâovçû3ÚšºGi:{r�RZ `vŽ!Œ³÷ÄøÖy€Ç�„ û}Äô6éj*E‹ã“€Ø>ž*!Ýo„˜-0#Êz=áÎIH¯¾
 ¼R‰;åèâ]xù¾4„D¦×#G¢Ûb[,Y&V)
XÈj]—Zù±<©*’ÞÅ6Ê CÊ¢‘ŠÚh’¡~�q$x•}jÈ€Æ%+†›GèTÌÌÿv©Ý·–i�ªaÜèd›á¬vc{
 endobj
-2407 0 obj <<
+2419 0 obj <<
 /Type /Page
-/Contents 2408 0 R
-/Resources 2406 0 R
+/Contents 2420 0 R
+/Resources 2418 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2405 0 R
+/Parent 2417 0 R
 >> endobj
-2409 0 obj <<
-/D [2407 0 R /XYZ 85.0394 794.5015 null]
+2421 0 obj <<
+/D [2419 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-842 0 obj <<
-/D [2407 0 R /XYZ 85.0394 769.5949 null]
+850 0 obj <<
+/D [2419 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-2410 0 obj <<
-/D [2407 0 R /XYZ 85.0394 747.9963 null]
+2422 0 obj <<
+/D [2419 0 R /XYZ 85.0394 747.9963 null]
 >> endobj
-2411 0 obj <<
-/D [2407 0 R /XYZ 85.0394 712.4426 null]
+2423 0 obj <<
+/D [2419 0 R /XYZ 85.0394 712.4426 null]
 >> endobj
-2412 0 obj <<
-/D [2407 0 R /XYZ 85.0394 646.5299 null]
+2424 0 obj <<
+/D [2419 0 R /XYZ 85.0394 646.5299 null]
 >> endobj
-2413 0 obj <<
-/D [2407 0 R /XYZ 85.0394 574.5487 null]
+2425 0 obj <<
+/D [2419 0 R /XYZ 85.0394 574.5487 null]
 >> endobj
-2406 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F53 1303 0 R >>
+2418 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2416 0 obj <<
+2428 0 obj <<
 /Length 2772      
 /Filter /FlateDecode
 >>
@@ -11560,45 +11622,45 @@ xÚÍZ_sÛ8ϧðÛ*31Ë?"%ÝÌ=¤MÒñn›æâìíÞtû Ø²£©,y-9Ùܧ?€ Ka›v÷næÚQ‚ ð@GL8üm˜Éd
 `Ùµn¡8�.ÛÕ®Ù|.}Ü@’Y©å¾_ì b±SìIÅ=J£”-eB#úÕÃ�çô¼¾veqQ»Üu ¶Phª—�÷X7Û¶lÇñ§lª V„n1�h
 üv
É9““sø‡
–�þy ây¸ùß5z®‘)œ˜úãô>T"H¬¤3_#TPÞUÁ¶j„Þ}?y‰¢É~”VÁ`‹û’&¯Ö!TK™æÜŒ—¨B=ø „ry)pñ9`ë%Þ¼(ñææ]XAÀæx(Ì»*«â‹ 9ÓIbþŠˆøŠx®/;
 endobj
-2415 0 obj <<
+2427 0 obj <<
 /Type /Page
-/Contents 2416 0 R
-/Resources 2414 0 R
+/Contents 2428 0 R
+/Resources 2426 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2405 0 R
+/Parent 2417 0 R
 >> endobj
-2417 0 obj <<
-/D [2415 0 R /XYZ 56.6929 794.5015 null]
+2429 0 obj <<
+/D [2427 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2418 0 obj <<
-/D [2415 0 R /XYZ 56.6929 523.9144 null]
+2430 0 obj <<
+/D [2427 0 R /XYZ 56.6929 523.9144 null]
 >> endobj
-2419 0 obj <<
-/D [2415 0 R /XYZ 56.6929 414.7474 null]
+2431 0 obj <<
+/D [2427 0 R /XYZ 56.6929 414.7474 null]
 >> endobj
-2420 0 obj <<
-/D [2415 0 R /XYZ 56.6929 353.4012 null]
+2432 0 obj <<
+/D [2427 0 R /XYZ 56.6929 353.4012 null]
 >> endobj
-846 0 obj <<
-/D [2415 0 R /XYZ 56.6929 315.6213 null]
+854 0 obj <<
+/D [2427 0 R /XYZ 56.6929 315.6213 null]
 >> endobj
-2421 0 obj <<
-/D [2415 0 R /XYZ 56.6929 279.563 null]
+2433 0 obj <<
+/D [2427 0 R /XYZ 56.6929 279.563 null]
 >> endobj
-2422 0 obj <<
-/D [2415 0 R /XYZ 56.6929 248.0689 null]
+2434 0 obj <<
+/D [2427 0 R /XYZ 56.6929 248.0689 null]
 >> endobj
-2423 0 obj <<
-/D [2415 0 R /XYZ 56.6929 183.8008 null]
+2435 0 obj <<
+/D [2427 0 R /XYZ 56.6929 183.8008 null]
 >> endobj
-2424 0 obj <<
-/D [2415 0 R /XYZ 56.6929 95.2626 null]
+2436 0 obj <<
+/D [2427 0 R /XYZ 56.6929 95.2626 null]
 >> endobj
-2414 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F41 1208 0 R /F21 930 0 R /F53 1303 0 R /F39 1151 0 R >>
+2426 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F41 1218 0 R /F21 938 0 R /F53 1313 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2427 0 obj <<
+2439 0 obj <<
 /Length 2481      
 /Filter /FlateDecode
 >>
@@ -11617,30 +11679,30 @@ DÙ÷þ2«!„
 ¤¹œ:nY�Š˜Ö-0ŽI׶Ã[ÿàgk[HŒè©èÕ'{ÂiŽ—þvDü–øhs”èf}<Z-©#ÑòR&ZO±hÄxâ9}™?åå0Z�"	lüŽZ¤"¦u£dNÈ®i³¼¤æw»û{K=àÑX†mý2
 ý1ZpÊC^˜ŠÙV•¶´Öš%œsêÍÜ1ÇÐ
 endobj
-2426 0 obj <<
+2438 0 obj <<
 /Type /Page
-/Contents 2427 0 R
-/Resources 2425 0 R
+/Contents 2439 0 R
+/Resources 2437 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2405 0 R
+/Parent 2417 0 R
 >> endobj
-2428 0 obj <<
-/D [2426 0 R /XYZ 85.0394 794.5015 null]
+2440 0 obj <<
+/D [2438 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2429 0 obj <<
-/D [2426 0 R /XYZ 85.0394 752.0063 null]
+2441 0 obj <<
+/D [2438 0 R /XYZ 85.0394 752.0063 null]
 >> endobj
-2430 0 obj <<
-/D [2426 0 R /XYZ 85.0394 259.1933 null]
+2442 0 obj <<
+/D [2438 0 R /XYZ 85.0394 259.1933 null]
 >> endobj
-2431 0 obj <<
-/D [2426 0 R /XYZ 85.0394 114.6417 null]
+2443 0 obj <<
+/D [2438 0 R /XYZ 85.0394 114.6417 null]
 >> endobj
-2425 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F55 1311 0 R /F41 1208 0 R /F48 1228 0 R >>
+2437 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F55 1321 0 R /F41 1218 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2434 0 obj <<
+2446 0 obj <<
 /Length 2045      
 /Filter /FlateDecode
 >>
@@ -11653,48 +11715,48 @@ xÚµY[sÚF~çWð3a»W]úFl’8ul×�N;IdiÁš‰"—þúž½		Ö&�6“™è ={ö\¾sY™1ü#C  ¦ñ0Œ9˜ˆa
 ‰	 û*U�>€A“'ŒG�$÷Ä„ˆŽ§R“>í¤Ï;£À›¼6Ïz#Ó\Y 

 ³uO½¹, Ï)ßRj½„IÇÕ6Ù@œÌ«VI�¢±«¾%ÅÎ’ÕÒWÞ ¿	¸âø纞†à@L\_µp±N|y8G?ïçÓ—â•íú�YpVØïúÀ27UÙÌ]ΧŠ‚ªz5€õõ«Ç=”,½NE 9˜&«â«/íŠsvqñöv¾‡|„ÌpN-ÛŒïàZ;Ë"9éV�4©¥+-µ,ë¼�úé-WÊø0••zƇê×:OàµÎø±©Œ2SÕ,Ò)Y6kºá}ʋ¼֮†ç®Ö…ÖöæM&—É®h¬ ]	Õ¶6+�·Š1£îY6šæ»|ÂE•¶sqµ±w©#+&6¾
“‹¾CóÖ>Ž]–Y(lyѤq¬¢º!·lÚnE=Xc7ƒHB™@i™‘Ð�âÊ‹î(„ñ‚¼h¥€²€þ•eÝ“„ílš°ÏCDÕOsU`†8'¬ðNeå¾÷$ö¶Ý…ü´aÖEÔ¢îQ¦_]O[¶¡ªõîµy‘7{·U5xEi/"Õ!}༩i"G~íƒØioŒ| LÖHÂ} º°'æ¡R¢‡pÍÚXÄçëM!ײlŽ@KmVç̧± À$˜7ñå&HÌl/9˜uÍR}^™E`Jxg]¼k*h‡yš…õU­¤Þ—·É×öKVè¹&†0šäåÔaz¾9¦(»çê3	‰^<Ïñœž×ŶúF2Ò;dtd¾e2™Išl’‡*’4o{à¤&¸ðtMÝŠ0¼‡™�ꉀ¢K-	M9TûÍœT[G`£{gë™Vʺ~öôP�@€iÇE¦vM7EžæM'Ò†h?
¹€¦)ø¡¦©W�ì9@Þ›”NWlj¯>uíEÏ}6‡9G}ëö„·Ñþ¤~ø\ÔXQ?"h(
 endobj
-2433 0 obj <<
+2445 0 obj <<
 /Type /Page
-/Contents 2434 0 R
-/Resources 2432 0 R
+/Contents 2446 0 R
+/Resources 2444 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2405 0 R
+/Parent 2417 0 R
 >> endobj
-2435 0 obj <<
-/D [2433 0 R /XYZ 56.6929 794.5015 null]
+2447 0 obj <<
+/D [2445 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2436 0 obj <<
-/D [2433 0 R /XYZ 56.6929 752.3006 null]
+2448 0 obj <<
+/D [2445 0 R /XYZ 56.6929 752.3006 null]
 >> endobj
-2437 0 obj <<
-/D [2433 0 R /XYZ 56.6929 691.1408 null]
+2449 0 obj <<
+/D [2445 0 R /XYZ 56.6929 691.1408 null]
 >> endobj
-2438 0 obj <<
-/D [2433 0 R /XYZ 56.6929 618.0258 null]
+2450 0 obj <<
+/D [2445 0 R /XYZ 56.6929 618.0258 null]
 >> endobj
-850 0 obj <<
-/D [2433 0 R /XYZ 56.6929 580.3755 null]
+858 0 obj <<
+/D [2445 0 R /XYZ 56.6929 580.3755 null]
 >> endobj
-2439 0 obj <<
-/D [2433 0 R /XYZ 56.6929 544.374 null]
+2451 0 obj <<
+/D [2445 0 R /XYZ 56.6929 544.374 null]
 >> endobj
-2440 0 obj <<
-/D [2433 0 R /XYZ 56.6929 512.9368 null]
+2452 0 obj <<
+/D [2445 0 R /XYZ 56.6929 512.9368 null]
 >> endobj
-2441 0 obj <<
-/D [2433 0 R /XYZ 56.6929 448.8551 null]
+2453 0 obj <<
+/D [2445 0 R /XYZ 56.6929 448.8551 null]
 >> endobj
-2442 0 obj <<
-/D [2433 0 R /XYZ 56.6929 354.7947 null]
+2454 0 obj <<
+/D [2445 0 R /XYZ 56.6929 354.7947 null]
 >> endobj
-2443 0 obj <<
-/D [2433 0 R /XYZ 56.6929 251.5616 null]
+2455 0 obj <<
+/D [2445 0 R /XYZ 56.6929 251.5616 null]
 >> endobj
-2432 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R /F41 1208 0 R /F53 1303 0 R /F55 1311 0 R >>
+2444 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R /F41 1218 0 R /F53 1313 0 R /F55 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2446 0 obj <<
+2458 0 obj <<
 /Length 3068      
 /Filter /FlateDecode
 >>
@@ -11708,21 +11770,21 @@ xÚ¥ZKsãƾëW°*SUKx<œ“VË]ËZK‘NâØ>@$$¢
J‘}º§{@
 QaèžÁîŸ(6Û
—¼8²7æ0C%
 5i€”Õvm9Þp»÷«6J˜žä\/ßi&!:+c ˜{x ª4ŒÉËÀsy\ž,hOACvΆܢ�oXþ'«jJ§€Ì›…—¸@hòÂØV‡¸X`oYÇ!Ú�{ßuá¥Æ„:«ºèÔ){Õ·ˆE侑»' àÃEð*MñY”ÅPÓQ–T„¡½¬ËWçz1µ9┆`¨´:íÚ¨ãn¡AY·°9ë6Û².e~´�|R¸}ùPºÁ>rG<ö
®ÔP’
°HvŠ›Â8$�à+×íN2T½\'
 endobj
-2445 0 obj <<
+2457 0 obj <<
 /Type /Page
-/Contents 2446 0 R
-/Resources 2444 0 R
+/Contents 2458 0 R
+/Resources 2456 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2405 0 R
+/Parent 2417 0 R
 >> endobj
-2447 0 obj <<
-/D [2445 0 R /XYZ 85.0394 794.5015 null]
+2459 0 obj <<
+/D [2457 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2444 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F55 1311 0 R /F22 953 0 R /F41 1208 0 R >>
+2456 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F55 1321 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2450 0 obj <<
+2462 0 obj <<
 /Length 2624      
 /Filter /FlateDecode
 >>
@@ -11737,33 +11799,33 @@ s�<9J‰×“8ýdê	*à¡çžà&ã�&
 _ñ‘'uÂINêU/�štç¦ýIûýäO
 HïóFªíÉ<pT¹]ëM>ïðÔî=ÒC­9…þȬx¨6y³Zu/Ä2L)•œv¯/uܽ­Ôkî=9iëÞƒI{ÝÛ™ô‰@Ô&¿ŠÄè�;áQàÎÿ²ªÃx°VÆW Mä*0*�ãÿŒ�»PbNûk_ì!ålž
ã%ŽrÌݤÜû8à!ªId–Õ½ý"p¸G[h0K 5¶DÇú¨:‚ØF%ɪftyÃÅÍR†]z¶ÏR½0Û°‹Ïþݽ0¯dóݾx1¦"‡vr¼zù1+a±øÒÐc
#0X$¯˜cÇwì±k)‡íŽyw»§+Ýg%�€h�ÉŽ8(†jàžh§1æŠ=ëðW†E‚ŸÃè·	*°B¨™WîÄ6›z¢¼ó°b²†
 endobj
-2449 0 obj <<
+2461 0 obj <<
 /Type /Page
-/Contents 2450 0 R
-/Resources 2448 0 R
+/Contents 2462 0 R
+/Resources 2460 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2456 0 R
+/Parent 2468 0 R
 >> endobj
-2451 0 obj <<
-/D [2449 0 R /XYZ 56.6929 794.5015 null]
+2463 0 obj <<
+/D [2461 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2452 0 obj <<
-/D [2449 0 R /XYZ 56.6929 751.4875 null]
+2464 0 obj <<
+/D [2461 0 R /XYZ 56.6929 751.4875 null]
 >> endobj
-2453 0 obj <<
-/D [2449 0 R /XYZ 56.6929 391.2154 null]
+2465 0 obj <<
+/D [2461 0 R /XYZ 56.6929 391.2154 null]
 >> endobj
-2454 0 obj <<
-/D [2449 0 R /XYZ 56.6929 154.5087 null]
+2466 0 obj <<
+/D [2461 0 R /XYZ 56.6929 154.5087 null]
 >> endobj
-2455 0 obj <<
-/D [2449 0 R /XYZ 56.6929 85.0025 null]
+2467 0 obj <<
+/D [2461 0 R /XYZ 56.6929 85.0025 null]
 >> endobj
-2448 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F55 1311 0 R /F41 1208 0 R /F14 956 0 R /F39 1151 0 R >>
+2460 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F55 1321 0 R /F41 1218 0 R /F14 964 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2459 0 obj <<
+2471 0 obj <<
 /Length 2718      
 /Filter /FlateDecode
 >>
@@ -11786,39 +11848,39 @@ E´Xœä×gH*@{ðáú¡n•7óû=ùö´õÒE(†Ûó(â£ý¨JGYÏAâé¾°bó{¶¶+(ÜeÌLQÞõ³ˆ~¢=ø`ƒ{rТ9
 g²:…²iØIÎ;
áÅ÷l¥KÖ¤±fîÜ/tg#!R×c
 �¹“K Á�up5Ô.¯Ð×�v®øÃÓÞAàÒ}ˆ¹’"ÁÑ~8(ˆ
:m«¾¸þÝz¢f¿Onþáo˜¤\y0rHÎ|¦¯	¾AÁ6¡Ç»®�máý 
€¿•:Üà{J?ÜÏÏ“›¬è}íÄcE*P¦ª'ói	"ጂÇ^˜ää·²�¤«dð4nVżh°~à{ÿâa½C
’½€ù„–‘dY‹ùò�ÚÎç‰Å)èp)	ö߆pG¯š»’u\Gú測ë`ca�­Y	|ïÓY9/ÀU
 endobj
-2458 0 obj <<
+2470 0 obj <<
 /Type /Page
-/Contents 2459 0 R
-/Resources 2457 0 R
+/Contents 2471 0 R
+/Resources 2469 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2456 0 R
+/Parent 2468 0 R
 >> endobj
-2460 0 obj <<
-/D [2458 0 R /XYZ 85.0394 794.5015 null]
+2472 0 obj <<
+/D [2470 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-854 0 obj <<
-/D [2458 0 R /XYZ 85.0394 769.5949 null]
+862 0 obj <<
+/D [2470 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1444 0 obj <<
-/D [2458 0 R /XYZ 85.0394 744.4533 null]
+1454 0 obj <<
+/D [2470 0 R /XYZ 85.0394 744.4533 null]
 >> endobj
-2461 0 obj <<
-/D [2458 0 R /XYZ 85.0394 712.504 null]
+2473 0 obj <<
+/D [2470 0 R /XYZ 85.0394 712.504 null]
 >> endobj
-2462 0 obj <<
-/D [2458 0 R /XYZ 85.0394 646.744 null]
+2474 0 obj <<
+/D [2470 0 R /XYZ 85.0394 646.744 null]
 >> endobj
-2463 0 obj <<
-/D [2458 0 R /XYZ 85.0394 527.0948 null]
+2475 0 obj <<
+/D [2470 0 R /XYZ 85.0394 527.0948 null]
 >> endobj
-2464 0 obj <<
-/D [2458 0 R /XYZ 85.0394 409.8795 null]
+2476 0 obj <<
+/D [2470 0 R /XYZ 85.0394 409.8795 null]
 >> endobj
-2457 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F53 1303 0 R /F55 1311 0 R >>
+2469 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F53 1313 0 R /F55 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2467 0 obj <<
+2479 0 obj <<
 /Length 3241      
 /Filter /FlateDecode
 >>
@@ -11834,21 +11896,21 @@ xÚ¥]sÛ6òÝ¿B3÷z.b	€àÇåÉuÜÔuꤖs½»¶´ÙœP¤*RvÝ_ß]ì‚&)RîÌ�ÇC`±À.€ý†Ä,€?1Ó‘¥2�Åiè
 C÷Æåî�ªYÎýAãðºe´Ì´h‰§ƒÚ¹J¼3‚¿ñßP#ï¼ÙlÐq*—º²>æ‚À—±H)<›:
 ïÁ!Ú<*Ñ01{›×…/9@·YM!H(ø21Λ<+Xç†^’À6™º�;zGøæŸo¼1YÉÔ2‚ŒrÒ£äÖ.ï‹Ñ·N:Ý}ûì»<ÿRCÑü&»s�ÏX�Èè¡Þb¿X<Ï=Co!Ì¡&sM«âY÷ÖoÝ´íìò¼lgôj½LAj£ïÑm:�’s‡z�urº/7ñ0¥}üáÖˆIfîøþï߇½ü.Œ}•L=mA´éÃäÈ1…[atèBø—d‡¼ÿpÊ¡Uendstream
 endobj
-2466 0 obj <<
+2478 0 obj <<
 /Type /Page
-/Contents 2467 0 R
-/Resources 2465 0 R
+/Contents 2479 0 R
+/Resources 2477 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2456 0 R
+/Parent 2468 0 R
 >> endobj
-2468 0 obj <<
-/D [2466 0 R /XYZ 56.6929 794.5015 null]
+2480 0 obj <<
+/D [2478 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2465 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R /F55 1311 0 R >>
+2477 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R /F55 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2471 0 obj <<
+2483 0 obj <<
 /Length 3040      
 /Filter /FlateDecode
 >>
@@ -11869,24 +11931,24 @@ f•?ç«Ì8dÁù¤f×€jýÛHRÇ}Õòf?eœçÓöé©NV3Æ·D?dà@ÅÁÂ"Žñ墻¢g˜ÇÛ»Û{ŽbŸ¿<Þ~¾€=
 kø‡'É�]Õ&MÍIÝ:¦Cåö/jÈkEO;ÎW©D£ç«XȡͤìòUŸ‹2VÉ/À’ßb%¿Õ¤y¾Êé–Æ¿´pI©a“R^Ɉf@.Ÿ¯Tô‹´«ª|Ê·Ý��÷³¸Oâ°šsan�½ú‘p�å
¤cǹ©ê¢©¶T„1\—Pz?ƒ²I4ìð‘?ARàéjðXÃî)ç/ÿyÒîÏ°¢s$ì¨0ŸC„S
 M*¢d_u­L �Ltÿ¶ÎUÇendstream
 endobj
-2470 0 obj <<
+2482 0 obj <<
 /Type /Page
-/Contents 2471 0 R
-/Resources 2469 0 R
+/Contents 2483 0 R
+/Resources 2481 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2456 0 R
+/Parent 2468 0 R
 >> endobj
-2472 0 obj <<
-/D [2470 0 R /XYZ 85.0394 794.5015 null]
+2484 0 obj <<
+/D [2482 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2473 0 obj <<
-/D [2470 0 R /XYZ 85.0394 384.6993 null]
+2485 0 obj <<
+/D [2482 0 R /XYZ 85.0394 384.6993 null]
 >> endobj
-2469 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F55 1311 0 R /F22 953 0 R /F41 1208 0 R >>
+2481 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F55 1321 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2476 0 obj <<
+2488 0 obj <<
 /Length 2399      
 /Filter /FlateDecode
 >>
@@ -11901,33 +11963,33 @@ T
 rÇùïO7Z�Þ"?¬6æ»ÝÀ�ß�r#Uw8
挃&'ª¾-ï©ýÉ^q._EZh~Ê^÷mÈ–å
‹Ç~»¯{Zœ$†–^Šÿ|ð̲]íí´6Ü%
…1À‘‹ÌƒÕ‘=Á0¡ÁXh­N‚z‚·Å¸Uà>g89«=lÞS~¢÷�
 …` ½Q¸9hÓL0IõØþÔ'*ãendstream
 endobj
-2475 0 obj <<
+2487 0 obj <<
 /Type /Page
-/Contents 2476 0 R
-/Resources 2474 0 R
+/Contents 2488 0 R
+/Resources 2486 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2456 0 R
+/Parent 2468 0 R
 >> endobj
-2477 0 obj <<
-/D [2475 0 R /XYZ 56.6929 794.5015 null]
+2489 0 obj <<
+/D [2487 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2478 0 obj <<
-/D [2475 0 R /XYZ 56.6929 585.9293 null]
+2490 0 obj <<
+/D [2487 0 R /XYZ 56.6929 585.9293 null]
 >> endobj
-2479 0 obj <<
-/D [2475 0 R /XYZ 56.6929 316.6498 null]
+2491 0 obj <<
+/D [2487 0 R /XYZ 56.6929 316.6498 null]
 >> endobj
-2480 0 obj <<
-/D [2475 0 R /XYZ 56.6929 154.9076 null]
+2492 0 obj <<
+/D [2487 0 R /XYZ 56.6929 154.9076 null]
 >> endobj
-2481 0 obj <<
-/D [2475 0 R /XYZ 56.6929 85.0711 null]
+2493 0 obj <<
+/D [2487 0 R /XYZ 56.6929 85.0711 null]
 >> endobj
-2474 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F55 1311 0 R /F22 953 0 R /F41 1208 0 R /F14 956 0 R /F48 1228 0 R /F39 1151 0 R >>
+2486 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F55 1321 0 R /F22 961 0 R /F41 1218 0 R /F14 964 0 R /F48 1238 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2484 0 obj <<
+2496 0 obj <<
 /Length 1604      
 /Filter /FlateDecode
 >>
@@ -11940,54 +12002,54 @@ qMÔÁáwì}˜<œ8µŸ‡ÀÑÂä_°À
 þÁ�¾Èt;qqÈœ_onï½®´w—dp&(Êmý—§ÃÌ�›Z>óúç»x‹H…¨„nЙ
 0Ì«S1©ƒª˜"\†Þ|U;Žý?�bØSendstream
 endobj
-2483 0 obj <<
+2495 0 obj <<
 /Type /Page
-/Contents 2484 0 R
-/Resources 2482 0 R
+/Contents 2496 0 R
+/Resources 2494 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2456 0 R
+/Parent 2468 0 R
 >> endobj
-2485 0 obj <<
-/D [2483 0 R /XYZ 85.0394 794.5015 null]
+2497 0 obj <<
+/D [2495 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-858 0 obj <<
-/D [2483 0 R /XYZ 85.0394 769.5949 null]
+866 0 obj <<
+/D [2495 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-2486 0 obj <<
-/D [2483 0 R /XYZ 85.0394 748.2826 null]
+2498 0 obj <<
+/D [2495 0 R /XYZ 85.0394 748.2826 null]
 >> endobj
-2487 0 obj <<
-/D [2483 0 R /XYZ 85.0394 713.6257 null]
+2499 0 obj <<
+/D [2495 0 R /XYZ 85.0394 713.6257 null]
 >> endobj
-2488 0 obj <<
-/D [2483 0 R /XYZ 85.0394 650.7148 null]
+2500 0 obj <<
+/D [2495 0 R /XYZ 85.0394 650.7148 null]
 >> endobj
-2489 0 obj <<
-/D [2483 0 R /XYZ 85.0394 593.6907 null]
+2501 0 obj <<
+/D [2495 0 R /XYZ 85.0394 593.6907 null]
 >> endobj
-2490 0 obj <<
-/D [2483 0 R /XYZ 85.0394 521.7466 null]
+2502 0 obj <<
+/D [2495 0 R /XYZ 85.0394 521.7466 null]
 >> endobj
-2491 0 obj <<
-/D [2483 0 R /XYZ 85.0394 246.5646 null]
+2503 0 obj <<
+/D [2495 0 R /XYZ 85.0394 246.5646 null]
 >> endobj
-2492 0 obj <<
-/D [2483 0 R /XYZ 85.0394 186.5756 null]
+2504 0 obj <<
+/D [2495 0 R /XYZ 85.0394 186.5756 null]
 >> endobj
-862 0 obj <<
-/D [2483 0 R /XYZ 85.0394 149.7581 null]
+870 0 obj <<
+/D [2495 0 R /XYZ 85.0394 149.7581 null]
 >> endobj
-1445 0 obj <<
-/D [2483 0 R /XYZ 85.0394 117.6525 null]
+1455 0 obj <<
+/D [2495 0 R /XYZ 85.0394 117.6525 null]
 >> endobj
-2493 0 obj <<
-/D [2483 0 R /XYZ 85.0394 82.9956 null]
+2505 0 obj <<
+/D [2495 0 R /XYZ 85.0394 82.9956 null]
 >> endobj
-2482 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F53 1303 0 R /F55 1311 0 R /F39 1151 0 R >>
+2494 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F53 1313 0 R /F55 1321 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2496 0 obj <<
+2508 0 obj <<
 /Length 3008      
 /Filter /FlateDecode
 >>
@@ -12010,33 +12072,33 @@ LT�m|kªBèüþî©‡"YKýõ×»»ñ˜Q'¥îA+‡²­Åve}Ž°þª/‡n‹ŠÏßœÛZÆFç&|f¦ÌhtQ§³¬&¶'¦
 ÛUßÖà|ü™„A£mш0³b±{Ù|© Æ9¦NçG#˜R¶5å×-Óñøe™Ü�y'Â×Á7äN
ä\�T®az©]'‚‰˜áï2\íLÔ�­O¢ØÞ‹
 ­ÆékL÷8˜ü¼ÔýI%4gendstream
 endobj
-2495 0 obj <<
+2507 0 obj <<
 /Type /Page
-/Contents 2496 0 R
-/Resources 2494 0 R
+/Contents 2508 0 R
+/Resources 2506 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2502 0 R
+/Parent 2514 0 R
 >> endobj
-2497 0 obj <<
-/D [2495 0 R /XYZ 56.6929 794.5015 null]
+2509 0 obj <<
+/D [2507 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2498 0 obj <<
-/D [2495 0 R /XYZ 56.6929 749.2278 null]
+2510 0 obj <<
+/D [2507 0 R /XYZ 56.6929 749.2278 null]
 >> endobj
-2499 0 obj <<
-/D [2495 0 R /XYZ 56.6929 666.0142 null]
+2511 0 obj <<
+/D [2507 0 R /XYZ 56.6929 666.0142 null]
 >> endobj
-2500 0 obj <<
-/D [2495 0 R /XYZ 56.6929 495.229 null]
+2512 0 obj <<
+/D [2507 0 R /XYZ 56.6929 495.229 null]
 >> endobj
-2501 0 obj <<
-/D [2495 0 R /XYZ 56.6929 173.6231 null]
+2513 0 obj <<
+/D [2507 0 R /XYZ 56.6929 173.6231 null]
 >> endobj
-2494 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F41 1208 0 R /F53 1303 0 R /F22 953 0 R /F55 1311 0 R >>
+2506 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F41 1218 0 R /F53 1313 0 R /F22 961 0 R /F55 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2505 0 obj <<
+2517 0 obj <<
 /Length 2675      
 /Filter /FlateDecode
 >>
@@ -12053,30 +12115,30 @@ V\ofì
 f´d_ôÅßIí[§P›Ã�äßãyÝà䵪úålljR2¡Ž}l½üyU½Bö¨¦à¢üG¸»Ÿ×ä?üغ¬°Zùó?Ð66!XdSµàõ^âìwßí—Wu­‡´ƒdI¯ýjp­&JÂÞZ»:Ý…fO_"Nñsï~rËü-µ;J]I>Lœ·)r(4èò„4ÛÐàîè8Tî˜q-‰¬ÿV1\Hð‰Áö’
 ¾|»¾&+.¿ÿ4 Ùa·.€œû˜—xyšàå&¯Ã
Åc‰W¬�×N,´å�툥ñÖš,~7¹¹"!)[3‡‚ ¨èsýFÜ媗órÆŽü˜•›lÈø§?®C@µ”´`¼ûðž$Z©Ô€<£Dˆ‰ã˜ubDœ†Iß¿—Ÿ§ÿtwı\qM°,sÆÎýkÝä+Nïï«šœ¦Ø¬ý¿
 endobj
-2504 0 obj <<
+2516 0 obj <<
 /Type /Page
-/Contents 2505 0 R
-/Resources 2503 0 R
+/Contents 2517 0 R
+/Resources 2515 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2502 0 R
+/Parent 2514 0 R
 >> endobj
-2506 0 obj <<
-/D [2504 0 R /XYZ 85.0394 794.5015 null]
+2518 0 obj <<
+/D [2516 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2507 0 obj <<
-/D [2504 0 R /XYZ 85.0394 317.3568 null]
+2519 0 obj <<
+/D [2516 0 R /XYZ 85.0394 317.3568 null]
 >> endobj
-2508 0 obj <<
-/D [2504 0 R /XYZ 85.0394 151.6417 null]
+2520 0 obj <<
+/D [2516 0 R /XYZ 85.0394 151.6417 null]
 >> endobj
-2509 0 obj <<
-/D [2504 0 R /XYZ 85.0394 84.5094 null]
+2521 0 obj <<
+/D [2516 0 R /XYZ 85.0394 84.5094 null]
 >> endobj
-2503 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F55 1311 0 R /F22 953 0 R /F41 1208 0 R /F39 1151 0 R >>
+2515 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F55 1321 0 R /F22 961 0 R /F41 1218 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2512 0 obj <<
+2524 0 obj <<
 /Length 2560      
 /Filter /FlateDecode
 >>
@@ -12098,39 +12160,39 @@ ICŠiU®t¶“±U:
 èÖGµú¿Ç=å>Ö&ýƒ“jTA Íܾl
 5ìËÒ„o.*×v]Ô„üeÐLäëMã
 endobj
-2511 0 obj <<
+2523 0 obj <<
 /Type /Page
-/Contents 2512 0 R
-/Resources 2510 0 R
+/Contents 2524 0 R
+/Resources 2522 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2502 0 R
+/Parent 2514 0 R
 >> endobj
-2513 0 obj <<
-/D [2511 0 R /XYZ 56.6929 794.5015 null]
+2525 0 obj <<
+/D [2523 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-866 0 obj <<
-/D [2511 0 R /XYZ 56.6929 769.5949 null]
+874 0 obj <<
+/D [2523 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-2514 0 obj <<
-/D [2511 0 R /XYZ 56.6929 743.9934 null]
+2526 0 obj <<
+/D [2523 0 R /XYZ 56.6929 743.9934 null]
 >> endobj
-2515 0 obj <<
-/D [2511 0 R /XYZ 56.6929 710.6034 null]
+2527 0 obj <<
+/D [2523 0 R /XYZ 56.6929 710.6034 null]
 >> endobj
-2516 0 obj <<
-/D [2511 0 R /XYZ 56.6929 640.1221 null]
+2528 0 obj <<
+/D [2523 0 R /XYZ 56.6929 640.1221 null]
 >> endobj
-2517 0 obj <<
-/D [2511 0 R /XYZ 56.6929 503.7965 null]
+2529 0 obj <<
+/D [2523 0 R /XYZ 56.6929 503.7965 null]
 >> endobj
-2518 0 obj <<
-/D [2511 0 R /XYZ 56.6929 412.3267 null]
+2530 0 obj <<
+/D [2523 0 R /XYZ 56.6929 412.3267 null]
 >> endobj
-2510 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F53 1303 0 R /F55 1311 0 R >>
+2522 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F53 1313 0 R /F55 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2521 0 obj <<
+2533 0 obj <<
 /Length 3602      
 /Filter /FlateDecode
 >>
@@ -12146,21 +12208,21 @@ fâ]¾m˜�%.Š•�¢djÔ�ìlƒ,š
c¡îöú
Qˆ¦î{éà’%±"AYVî!àzº='cö«º¢n*}á|Ö�ôÞiä¬6ÅyƒŸpä
 ÖWÉ0cÃC,EW\®öxFìO°öC?íÁHÛ‚Ð&kúïß ¹[î×kü=mÆ1U¨—]ª3f¨¼¯†Kbš§õ…%ÑÈ’Ý#ƒDK3XòÍ®(›º'°zUíX,õ~³ÉvO'nè¦)¼\òiÐÑ<ì7y;qвž¤v�J·j¶(kˆ]f¨/^OŽU.ÕQ✾²2…˜Ì(qþtºT§O§¥ò§S\º”Qæ;ˆŽës ÈÈÎòÖR�0ׯÏ%ÐNEŸ»ŸÚ„/£Ÿ-bï‹j_¯ŸfÁqˆ['{Û¬®ÃhÆ}˜Ðªb9ž!úÛElÜçÝ<’Vâ‚ÝÝ*C8{'µ‘Û`³3ea·dÞÃÚpÉÙ¯+×Ãb÷Ó|ªëa	ÿ”1eÆSPÞ´¤ìuP<‡pÜMéÆëçÔÂp¬({¥xŒi|q]¶ÅõŒæ	W;ÐÓ—íXzH¡9ÐÊ–¼ØP„FجífŸQS4ÜÍoÓTèFý1iÀÞ0},êüÄ+°›ºXäôæ‚W®è÷žWõ\zÇŒOuUùðѺS)hÑÄö¥‚£ür»Îæ\ˆä‘wT‘PlN
`ÿá´ýSM¬õjúçb¹|Gk8Ú´“¤
¼ÛrÎý÷y󘓑u¨i3våTŽ‘¡.ÓÖG±y¸NÊãÖ×&€Ý%Ýå–|-wl>Æ
 £§oªº.î×9Ñd5ç--8Š®¬L…$
ãÙ’gü19	Rs&˜(:2FVºõK…ü¨oÛXQº³Ê.{<µ¦VS©ɃTŠKÄνãr1ünwD¥Åú‰»ËPÀ'ºNJH?][Kv†Í‹'H±Š9=„¸Ûx
 endobj
-2520 0 obj <<
+2532 0 obj <<
 /Type /Page
-/Contents 2521 0 R
-/Resources 2519 0 R
+/Contents 2533 0 R
+/Resources 2531 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2502 0 R
+/Parent 2514 0 R
 >> endobj
-2522 0 obj <<
-/D [2520 0 R /XYZ 85.0394 794.5015 null]
+2534 0 obj <<
+/D [2532 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2519 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F55 1311 0 R /F22 953 0 R /F41 1208 0 R >>
+2531 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F55 1321 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2525 0 obj <<
+2537 0 obj <<
 /Length 3441      
 /Filter /FlateDecode
 >>
@@ -12180,21 +12242,21 @@ R7[0ÌÔ”÷çtÃLŽŒ›]­%èr@F{bàíÝý‡wÿ&ä¡ÑŽ™èÆn«1ŒØÑnÊwES´ƒvg`WK7õ–J«
 Ôå3
à]ñ2 ’—ú
ìž~4_™ÛEÓÅcoYaº€áOÛÙ‹yÄ@L=€¬ÙÓ
µ�¦;Ò¿¸ÎÆuÙ÷î±FÅ°5—‰�¾èAªªynOÞ.g�f¬,xb‘kêÏ;(ß´2.‹-ã_feÙìLÙŽié¢ÍA‚J£“¶±õ÷©-»^zxù%…�*L_bÑÁ½hOJêÚ×ë†};Zã„I,]U»ªÁ˜—Öâ­T.Içy(\A4¼`>�f7Ýìw�FùÅ�Mú8
…A¤²ôº�ëcMû8�eEµéÍè0S¾N ìmU>]ôe°Í›'ùuæ<ÖwõÄi(ÒlÈÝðZ/rÕn4ÌÔpÂöj"÷Ñ
 $-~z±ïýz°0wö{º¦BGH„·4µjÜ>¶[‡ÓÜpx2+^^Œ˜ŸL�w;ó{
ÂzMõœÄ\*Qjx€9!©Ð >‚ÔøÔL°s”œ3Û?ÇËq o–ÖIwÑi¡\/á’�xU½ˆt'ÒüÒ¢)Ø�Òºëpìe¥½óRcæqö:�æ'¡’êìz}øÙÒé†^rA¤OþŠ 	–›b_,é£&À#	0æžž¾!‡èÜ�#%K_�àPßúÂsÁ»ó'PXó×`ÅjÈÊD2Är?/_íK§ïQ£~K¤a*RçiX«ñË7)|KÊÔ+ùqyý‡z¤¯©¸Ý,mšƒó¯ýï&½øµ8Ï^øŽ ‡4ís’u9÷SU̵ý|s±ßX
Óßï~[ìQ*w%#vv¸ÐòþÊ�e7ðkõ5a ͆�
 endobj
-2524 0 obj <<
+2536 0 obj <<
 /Type /Page
-/Contents 2525 0 R
-/Resources 2523 0 R
+/Contents 2537 0 R
+/Resources 2535 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2502 0 R
+/Parent 2514 0 R
 >> endobj
-2526 0 obj <<
-/D [2524 0 R /XYZ 56.6929 794.5015 null]
+2538 0 obj <<
+/D [2536 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2523 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F41 1208 0 R /F21 930 0 R /F55 1311 0 R >>
+2535 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F41 1218 0 R /F21 938 0 R /F55 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2529 0 obj <<
+2541 0 obj <<
 /Length 2970      
 /Filter /FlateDecode
 >>
@@ -12210,21 +12272,21 @@ XØ	÷¯,Ëç‚GWÅgšQTózaÝ°¸/,?³(¸¤áEÞ0ô?VŒö-¦b8Æ&hf°�PCe#�ÿÐ…?2�»=ØRäÑ–]uÍU‘
#
 ¯£e‚Ò™0qôFèS�ðJGe½ò/c^‰ßß]aY¶víuÕ¸¦�v&ƒœ\]G5²¼žkBÉ$ÒÞú~9ªÄ¼×áEg§lgªMwE½¨ÛÄží«7wÑàŽéQËÈš;©ß°ŒGuÂ2ŽÊZæò KÆh–ä´HG4"²z•�iÖÉÊÎt_Ùöû
 úÚ—žö^…aK´
 endobj
-2528 0 obj <<
+2540 0 obj <<
 /Type /Page
-/Contents 2529 0 R
-/Resources 2527 0 R
+/Contents 2541 0 R
+/Resources 2539 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2502 0 R
+/Parent 2514 0 R
 >> endobj
-2530 0 obj <<
-/D [2528 0 R /XYZ 85.0394 794.5015 null]
+2542 0 obj <<
+/D [2540 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2527 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F21 930 0 R /F55 1311 0 R /F41 1208 0 R /F53 1303 0 R >>
+2539 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F21 938 0 R /F55 1321 0 R /F41 1218 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2533 0 obj <<
+2545 0 obj <<
 /Length 1715      
 /Filter /FlateDecode
 >>
@@ -12237,42 +12299,42 @@ xÚ¥X[wÚ8~çWðÒ³pku—õHÚ¦mÒlIÏéž6˜à-Ø,6ié¯ß‘%”¤»{x@–Fsù4óilÒÇð#}!‘ÔT÷•æH`"úÓ
 A:õ!û¦i"ž>¾:³9f, �D¹ 
i;S-P¬›ÎT×¢£O7o>||·‹J"O]fNvЈ¬#�y	b¶]íÍrĸlŽ+†—|í?*#‚!Mjšˆ¦‹túÍs…‘eF–Úã¿‘°gÐ/¸lö|ÓRdY’ReGõró:lç~»ñ-Ì!Ÿîà}ù‡6
 ÷oÎE±ü•dÜåźÆ:x•eðfKÖ—Åá¯â£Â÷“oÖ{õ;.½W;™ 6¦@¿D‹[?zhF5#× �3{ÝkD�èýe–m+ºN�k“ŠNë<[¦ÆocÝXûyûØÇ!&�ù¢À7Gð¿?í?‘q¸~☆¿P%l–Þ)òø3	01ƒÄ?öýä‹ë@endstream
 endobj
-2532 0 obj <<
+2544 0 obj <<
 /Type /Page
-/Contents 2533 0 R
-/Resources 2531 0 R
+/Contents 2545 0 R
+/Resources 2543 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2541 0 R
+/Parent 2553 0 R
 >> endobj
-2534 0 obj <<
-/D [2532 0 R /XYZ 56.6929 794.5015 null]
+2546 0 obj <<
+/D [2544 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2535 0 obj <<
-/D [2532 0 R /XYZ 56.6929 632.0206 null]
+2547 0 obj <<
+/D [2544 0 R /XYZ 56.6929 632.0206 null]
 >> endobj
-2536 0 obj <<
-/D [2532 0 R /XYZ 56.6929 347.9691 null]
+2548 0 obj <<
+/D [2544 0 R /XYZ 56.6929 347.9691 null]
 >> endobj
-2537 0 obj <<
-/D [2532 0 R /XYZ 56.6929 276.6265 null]
+2549 0 obj <<
+/D [2544 0 R /XYZ 56.6929 276.6265 null]
 >> endobj
-870 0 obj <<
-/D [2532 0 R /XYZ 56.6929 231.9008 null]
+878 0 obj <<
+/D [2544 0 R /XYZ 56.6929 231.9008 null]
 >> endobj
-2538 0 obj <<
-/D [2532 0 R /XYZ 56.6929 196.3498 null]
+2550 0 obj <<
+/D [2544 0 R /XYZ 56.6929 196.3498 null]
 >> endobj
-2539 0 obj <<
-/D [2532 0 R /XYZ 56.6929 158.2476 null]
+2551 0 obj <<
+/D [2544 0 R /XYZ 56.6929 158.2476 null]
 >> endobj
-2540 0 obj <<
-/D [2532 0 R /XYZ 56.6929 83.9832 null]
+2552 0 obj <<
+/D [2544 0 R /XYZ 56.6929 83.9832 null]
 >> endobj
-2531 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F48 1228 0 R /F41 1208 0 R /F39 1151 0 R /F53 1303 0 R >>
+2543 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F48 1238 0 R /F41 1218 0 R /F39 1161 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2544 0 obj <<
+2556 0 obj <<
 /Length 1973      
 /Filter /FlateDecode
 >>
@@ -12289,45 +12351,45 @@ gWdŽ¯o-þU4eî²ÀÅ~V·ÜTÕÕI0$Ñ4˜}©Ó`¶RêdÆnånõpã—Óº[©僞‚Js¸¦´ëÏ
 ÈÞúê¢È«¢¬³fß©…|ç�»TÂÙy˜}Ô÷á…O0>ÂO熺‚¡éQV–rŽmc@g“Ã�U
ÝSì³]ª˜îƒÒ°cä~Gb{Ðx—m²ºíÍaÓ–Ê�k 1 U­Ûõº(v§>o3¸+06F‹¸õÎþôÝ}å‡ËSÍÚ(¿2Õ3IœQ
 <"ÂCÓÛ�äǶÿ>éÃendstream
 endobj
-2543 0 obj <<
+2555 0 obj <<
 /Type /Page
-/Contents 2544 0 R
-/Resources 2542 0 R
+/Contents 2556 0 R
+/Resources 2554 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2541 0 R
+/Parent 2553 0 R
 >> endobj
-2545 0 obj <<
-/D [2543 0 R /XYZ 85.0394 794.5015 null]
+2557 0 obj <<
+/D [2555 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2546 0 obj <<
-/D [2543 0 R /XYZ 85.0394 751.9581 null]
+2558 0 obj <<
+/D [2555 0 R /XYZ 85.0394 751.9581 null]
 >> endobj
-2547 0 obj <<
-/D [2543 0 R /XYZ 85.0394 608.6139 null]
+2559 0 obj <<
+/D [2555 0 R /XYZ 85.0394 608.6139 null]
 >> endobj
-2548 0 obj <<
-/D [2543 0 R /XYZ 85.0394 322.9834 null]
+2560 0 obj <<
+/D [2555 0 R /XYZ 85.0394 322.9834 null]
 >> endobj
-2549 0 obj <<
-/D [2543 0 R /XYZ 85.0394 258.3082 null]
+2561 0 obj <<
+/D [2555 0 R /XYZ 85.0394 258.3082 null]
 >> endobj
-2550 0 obj <<
-/D [2543 0 R /XYZ 85.0394 193.633 null]
+2562 0 obj <<
+/D [2555 0 R /XYZ 85.0394 193.633 null]
 >> endobj
-874 0 obj <<
-/D [2543 0 R /XYZ 85.0394 153.54 null]
+882 0 obj <<
+/D [2555 0 R /XYZ 85.0394 153.54 null]
 >> endobj
-2551 0 obj <<
-/D [2543 0 R /XYZ 85.0394 120.0237 null]
+2563 0 obj <<
+/D [2555 0 R /XYZ 85.0394 120.0237 null]
 >> endobj
-2552 0 obj <<
-/D [2543 0 R /XYZ 85.0394 83.956 null]
+2564 0 obj <<
+/D [2555 0 R /XYZ 85.0394 83.956 null]
 >> endobj
-2542 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F55 1311 0 R /F39 1151 0 R >>
+2554 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F55 1321 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2555 0 obj <<
+2567 0 obj <<
 /Length 2605      
 /Filter /FlateDecode
 >>
@@ -12351,30 +12413,30 @@ Dbõºh½ÌÝOO¬+ו®ZÔªn"sÜ«/My¯ñ5®S5Õ¤Ò󫪮s›þ
¥Q¢vT‰ïÏ&Ê2CYªÃ̓±´�…µÖ8nQJ
 ˜´—j–ƒýŒÎ·b,“Ƹ€[µW*Ž-4M^»›‘á×í¨D{È‹ô€{$¹$/ro²×½�Å�ìÙ¾Î´ávª®–Ypz¨¬¤{·É—uî¾pvÚû¯†lóVܬ`jÅqwÍ=Òp¹•t ïÃÁ^ϊ͘·¿¸xnIÄUœª1ˆâäåÕ�ÛÂ7ÍkÄØÜh^h
 D?endstream
 endobj
-2554 0 obj <<
+2566 0 obj <<
 /Type /Page
-/Contents 2555 0 R
-/Resources 2553 0 R
+/Contents 2567 0 R
+/Resources 2565 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2541 0 R
+/Parent 2553 0 R
 >> endobj
-2556 0 obj <<
-/D [2554 0 R /XYZ 56.6929 794.5015 null]
+2568 0 obj <<
+/D [2566 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2557 0 obj <<
-/D [2554 0 R /XYZ 56.6929 749.1077 null]
+2569 0 obj <<
+/D [2566 0 R /XYZ 56.6929 749.1077 null]
 >> endobj
-2558 0 obj <<
-/D [2554 0 R /XYZ 56.6929 598.1922 null]
+2570 0 obj <<
+/D [2566 0 R /XYZ 56.6929 598.1922 null]
 >> endobj
-2559 0 obj <<
-/D [2554 0 R /XYZ 56.6929 456.267 null]
+2571 0 obj <<
+/D [2566 0 R /XYZ 56.6929 456.267 null]
 >> endobj
-2553 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F41 1208 0 R /F53 1303 0 R /F22 953 0 R /F55 1311 0 R >>
+2565 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F41 1218 0 R /F53 1313 0 R /F22 961 0 R /F55 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2562 0 obj <<
+2574 0 obj <<
 /Length 3286      
 /Filter /FlateDecode
 >>
@@ -12391,21 +12453,21 @@ xÚí[[sÛÆ~ׯàCgÍ„›½ØvúàÈrê$VÜHi2Mò
 Yºð‡úÑ€pü[�”HÓ	K&À¦¡™g
 gJYW"… Œ'#¼ÿ¿
 endobj
-2561 0 obj <<
+2573 0 obj <<
 /Type /Page
-/Contents 2562 0 R
-/Resources 2560 0 R
+/Contents 2574 0 R
+/Resources 2572 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2541 0 R
+/Parent 2553 0 R
 >> endobj
-2563 0 obj <<
-/D [2561 0 R /XYZ 85.0394 794.5015 null]
+2575 0 obj <<
+/D [2573 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2560 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F55 1311 0 R /F22 953 0 R /F41 1208 0 R >>
+2572 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F55 1321 0 R /F22 961 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2566 0 obj <<
+2578 0 obj <<
 /Length 1900      
 /Filter /FlateDecode
 >>
@@ -12417,48 +12479,48 @@ xÚÝYKoÛF¾ëWÈE¬Í¾É=:±ÒºH×’Ói´DID(RåÃNúë;ËÝ¥Ij%¥(z)˜#r8�ogg¾eÈÃ?2IEÕ8P
 \z« ë²[ò¿¯þ?ªL
öp¦
 :Z'ªÀi5�;®/zß/eDø©~p¬ÔéøZ-O€=¼X€¤
 endobj
-2565 0 obj <<
+2577 0 obj <<
 /Type /Page
-/Contents 2566 0 R
-/Resources 2564 0 R
+/Contents 2578 0 R
+/Resources 2576 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2541 0 R
+/Parent 2553 0 R
 >> endobj
-2567 0 obj <<
-/D [2565 0 R /XYZ 56.6929 794.5015 null]
+2579 0 obj <<
+/D [2577 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2568 0 obj <<
-/D [2565 0 R /XYZ 56.6929 668.1414 null]
+2580 0 obj <<
+/D [2577 0 R /XYZ 56.6929 668.1414 null]
 >> endobj
-2569 0 obj <<
-/D [2565 0 R /XYZ 56.6929 606.9834 null]
+2581 0 obj <<
+/D [2577 0 R /XYZ 56.6929 606.9834 null]
 >> endobj
-2570 0 obj <<
-/D [2565 0 R /XYZ 56.6929 545.8253 null]
+2582 0 obj <<
+/D [2577 0 R /XYZ 56.6929 545.8253 null]
 >> endobj
-878 0 obj <<
-/D [2565 0 R /XYZ 56.6929 508.1763 null]
+886 0 obj <<
+/D [2577 0 R /XYZ 56.6929 508.1763 null]
 >> endobj
-2571 0 obj <<
-/D [2565 0 R /XYZ 56.6929 475.7331 null]
+2583 0 obj <<
+/D [2577 0 R /XYZ 56.6929 475.7331 null]
 >> endobj
-2572 0 obj <<
-/D [2565 0 R /XYZ 56.6929 440.7387 null]
+2584 0 obj <<
+/D [2577 0 R /XYZ 56.6929 440.7387 null]
 >> endobj
-2573 0 obj <<
-/D [2565 0 R /XYZ 56.6929 376.6588 null]
+2585 0 obj <<
+/D [2577 0 R /XYZ 56.6929 376.6588 null]
 >> endobj
-2574 0 obj <<
-/D [2565 0 R /XYZ 56.6929 294.5553 null]
+2586 0 obj <<
+/D [2577 0 R /XYZ 56.6929 294.5553 null]
 >> endobj
-2575 0 obj <<
-/D [2565 0 R /XYZ 56.6929 191.3244 null]
+2587 0 obj <<
+/D [2577 0 R /XYZ 56.6929 191.3244 null]
 >> endobj
-2564 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R /F41 1208 0 R /F53 1303 0 R /F55 1311 0 R >>
+2576 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R /F41 1218 0 R /F53 1313 0 R /F55 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2578 0 obj <<
+2590 0 obj <<
 /Length 2926      
 /Filter /FlateDecode
 >>
@@ -12474,22 +12536,22 @@ xÚÅZmoÛHþž_a`?œÔê¼j$àp@Úf‹ìµÙÞ&EØÝŠ<NtÑ‹kIMs¿þÈy‘%Y¶{h�Ûjj†âp8äCrº ð?]Ä2$<
 "𡟘ELl\8–ó¨6ç¬WG3«5’È®,#îgðëÄIP®»ÂŽÜé,5Q„löãŒ*7;`7Utn¾}|Ë,÷u9§r¦Q€ N´€¶«È˼M­Þ8�»”{¶^ik±âÙÜŠálóumi.>\…vôꜭ%Ñ$n�­vãVltë–Â$8ÒÒ~>~2.‰œ@¬¬[£â@VWh�{üãNœ@ó5–¶–x€‘ݼÙ‘x?ÁŠ^z“9§Ø´õÖ½í.¤¦6´‡1†Ù·_<Åóƒ`Ív¾­«Ò´„Èiü&+“…Ÿ*;lzg¶ßZpÑÀ½Ð¯1>xà­pE×Ê%Ö³_oêÕxÄðk‰uj¨zƒëº5Ç
 ˆµ·P5æDû5‰9ðD"«ËÒöðPØ«!óÎ}‡8e®�8
î:§ç�^ïþ°
žýõJ7ÞMÞ$Cû¼ŽöÊÝãsêûâ&<ô·=àÅ‚Ï~"%}•ôÝ÷³ûÃ&8WðÜ’8Á"5¡^)ÜÔÑSÕ%Ô/2fjF÷ÿKÒendstream
 endobj
-2577 0 obj <<
+2589 0 obj <<
 /Type /Page
-/Contents 2578 0 R
-/Resources 2576 0 R
+/Contents 2590 0 R
+/Resources 2588 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2541 0 R
+/Parent 2553 0 R
 >> endobj
-2579 0 obj <<
-/D [2577 0 R /XYZ 85.0394 794.5015 null]
+2591 0 obj <<
+/D [2589 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2576 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F55 1311 0 R /F22 953 0 R /F53 1303 0 R /F41 1208 0 R /F62 1351 0 R /F63 1354 0 R >>
-/XObject << /Im2 1340 0 R /Im3 1505 0 R >>
+2588 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F55 1321 0 R /F22 961 0 R /F53 1313 0 R /F41 1218 0 R /F62 1361 0 R /F63 1364 0 R >>
+/XObject << /Im2 1350 0 R /Im3 1515 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2582 0 obj <<
+2594 0 obj <<
 /Length 2519      
 /Filter /FlateDecode
 >>
@@ -12509,25 +12571,25 @@ B¡À	!“Œä{¨cP+1¤5�4µœ”ðˆmƈᙈ¤OÕþ£ÿâ\j½Ÿ1“º|YÇ
ïcT¥ÈÇVU¤.ÊEµ
Aì{/ßbc—/>º¦Æ…U
 ›�|]åQA˼ɱµ
 à·ÚN
 endobj
-2581 0 obj <<
+2593 0 obj <<
 /Type /Page
-/Contents 2582 0 R
-/Resources 2580 0 R
+/Contents 2594 0 R
+/Resources 2592 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2585 0 R
+/Parent 2597 0 R
 >> endobj
-2583 0 obj <<
-/D [2581 0 R /XYZ 56.6929 794.5015 null]
+2595 0 obj <<
+/D [2593 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2584 0 obj <<
-/D [2581 0 R /XYZ 56.6929 171.7883 null]
+2596 0 obj <<
+/D [2593 0 R /XYZ 56.6929 171.7883 null]
 >> endobj
-2580 0 obj <<
-/Font << /F37 1018 0 R /F22 953 0 R /F62 1351 0 R /F41 1208 0 R /F21 930 0 R /F55 1311 0 R /F53 1303 0 R /F63 1354 0 R >>
-/XObject << /Im3 1505 0 R /Im2 1340 0 R >>
+2592 0 obj <<
+/Font << /F37 1026 0 R /F22 961 0 R /F62 1361 0 R /F41 1218 0 R /F21 938 0 R /F55 1321 0 R /F53 1313 0 R /F63 1364 0 R >>
+/XObject << /Im3 1515 0 R /Im2 1350 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2588 0 obj <<
+2600 0 obj <<
 /Length 1911      
 /Filter /FlateDecode
 >>
@@ -12540,48 +12602,48 @@ C<áÞ¡G~áI2fHp„¢8Iæ!“(ÁÒÚëãòˆÓÜ�Á²PgœHˆ_/‡±Lª†Üz^¼:,ýê[Õfo�\òææô}scv��
 ½v&½É£Ždÿp}ÿþny;È”K½ÎÒÈÎ’ÂAâ®>VÓW}_nZÕ�«�ý¦¯Úºï.{»§—Í�l�♵̟=}ÆeßFê�k>õ&	Ò#tdP³t§û!}>j35`²Í$	®’\ž§ 1z}=oUéÞئåã$Cû4WlÆ'øæ/@½ÈìF+°ñB	¬Ð#‚Èb6Í%THð:!ãqÆ+›ã!
§r9Õ0é[¢‡2éj©D 7v³Ê|sS©î‘õ*ÍóÂ
i°ÓùSs“\Ý8Ü!Á,¦:¿ž?£¥¤±�áð¡(ÓÚñ£]!m
t·«ž‹òѹ^’žk¤†Î
 4ò�¬´ý2ìíóaz€nÙt»'êœ]z�µm‹FÕOª¶ˆE3¤jºeO4Ý´+u·Ç6¯ž=S‚à›Õi³Õó“Á»s�ËŸª‡c‹åãœzå¢ ÝQ…°é¢0
¿
 endobj
-2587 0 obj <<
+2599 0 obj <<
 /Type /Page
-/Contents 2588 0 R
-/Resources 2586 0 R
+/Contents 2600 0 R
+/Resources 2598 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2585 0 R
+/Parent 2597 0 R
 >> endobj
-2589 0 obj <<
-/D [2587 0 R /XYZ 85.0394 794.5015 null]
+2601 0 obj <<
+/D [2599 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2590 0 obj <<
-/D [2587 0 R /XYZ 85.0394 751.7498 null]
+2602 0 obj <<
+/D [2599 0 R /XYZ 85.0394 751.7498 null]
 >> endobj
-2591 0 obj <<
-/D [2587 0 R /XYZ 85.0394 629.733 null]
+2603 0 obj <<
+/D [2599 0 R /XYZ 85.0394 629.733 null]
 >> endobj
-2592 0 obj <<
-/D [2587 0 R /XYZ 85.0394 519.6713 null]
+2604 0 obj <<
+/D [2599 0 R /XYZ 85.0394 519.6713 null]
 >> endobj
-2593 0 obj <<
-/D [2587 0 R /XYZ 85.0394 440.9022 null]
+2605 0 obj <<
+/D [2599 0 R /XYZ 85.0394 440.9022 null]
 >> endobj
-882 0 obj <<
-/D [2587 0 R /XYZ 85.0394 399.3232 null]
+890 0 obj <<
+/D [2599 0 R /XYZ 85.0394 399.3232 null]
 >> endobj
-2594 0 obj <<
-/D [2587 0 R /XYZ 85.0394 361.5964 null]
+2606 0 obj <<
+/D [2599 0 R /XYZ 85.0394 361.5964 null]
 >> endobj
-2595 0 obj <<
-/D [2587 0 R /XYZ 85.0394 328.4339 null]
+2607 0 obj <<
+/D [2599 0 R /XYZ 85.0394 328.4339 null]
 >> endobj
-2596 0 obj <<
-/D [2587 0 R /XYZ 85.0394 258.6981 null]
+2608 0 obj <<
+/D [2599 0 R /XYZ 85.0394 258.6981 null]
 >> endobj
-2597 0 obj <<
-/D [2587 0 R /XYZ 85.0394 194.8491 null]
+2609 0 obj <<
+/D [2599 0 R /XYZ 85.0394 194.8491 null]
 >> endobj
-2586 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R /F41 1208 0 R /F48 1228 0 R /F53 1303 0 R >>
+2598 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R /F41 1218 0 R /F48 1238 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2600 0 obj <<
+2612 0 obj <<
 /Length 2703      
 /Filter /FlateDecode
 >>
@@ -12593,42 +12655,42 @@ xÚ¥Y[oÛ¸~ϯðÛQ€Z•Hê¶oÙ$m³Û¦9µ‹séöA¶[¨,y%9AûãÏg¨‹#§
Dä�çòÍ�ögüù³ tÃD$³(Q
 ­ÞªÐaY9<B¯>3ªïøÙà‚9êsK¨ƒ¸«_6q(›¶éKc�
 hG&®@�!@8@r¢»8`Ñ	æp¶1?ÐSú4[FÌŒ†ñFnú-�sqbfr%íª4E	Ì7Ž”eõÈœ-(ßƆWì—JE^ÄaKÀ­¤MÀÒÂïóÌ;—‡š»Z�Ï÷}ãH©~1	nöˆ{šÙër]?Yˆ€~Zlª`bGÝûŠ«
R,’¨¸�·O—s¾„±èãzõ*0RÄÎã6_#î@ʤÅñð*ˆ]sQì(Øø懇KœÏô‚Ī%¸�f'&óSϘóbs†7$Gº‡¸>‡°Æ£7D|Ì‹‚f–ZgS~jŠ³8
­5‡nÇØ„Ð�4ºÐ¦þŽ¹FÄFº‡�¸FØ×9%t¤”�݆¾�ÚÈÇ¥ãôƒöA�ê’WõÀDh‹ò¥Fá±Õ¹Š‚ô»ªŒü2/›6E¿ÁkeN’·«h
E›bƒ:èo:@„…­Æ”ÑPÿ‘æ­˜�­à¡9™9Eº¡êjµ·º]¿5ÏÅ.\iî'b%PÛu�2Mż)f½ÀBš¢ ¡,AæÄ÷ð‘AíA|À“°‘6Mµ&+a×0ƒäŽN3¶!Ž�ûFY†*Ë4z+c—’ðˆñÍÏÌ2†ü†˜3AF
 endobj
-2599 0 obj <<
+2611 0 obj <<
 /Type /Page
-/Contents 2600 0 R
-/Resources 2598 0 R
+/Contents 2612 0 R
+/Resources 2610 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2585 0 R
+/Parent 2597 0 R
 >> endobj
-2601 0 obj <<
-/D [2599 0 R /XYZ 56.6929 794.5015 null]
+2613 0 obj <<
+/D [2611 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2602 0 obj <<
-/D [2599 0 R /XYZ 56.6929 752.0715 null]
+2614 0 obj <<
+/D [2611 0 R /XYZ 56.6929 752.0715 null]
 >> endobj
-2603 0 obj <<
-/D [2599 0 R /XYZ 56.6929 688.5597 null]
+2615 0 obj <<
+/D [2611 0 R /XYZ 56.6929 688.5597 null]
 >> endobj
-886 0 obj <<
-/D [2599 0 R /XYZ 56.6929 649.2752 null]
+894 0 obj <<
+/D [2611 0 R /XYZ 56.6929 649.2752 null]
 >> endobj
-2604 0 obj <<
-/D [2599 0 R /XYZ 56.6929 612.6707 null]
+2616 0 obj <<
+/D [2611 0 R /XYZ 56.6929 612.6707 null]
 >> endobj
-2605 0 obj <<
-/D [2599 0 R /XYZ 56.6929 580.4012 null]
+2617 0 obj <<
+/D [2611 0 R /XYZ 56.6929 580.4012 null]
 >> endobj
-2606 0 obj <<
-/D [2599 0 R /XYZ 56.6929 513.9676 null]
+2618 0 obj <<
+/D [2611 0 R /XYZ 56.6929 513.9676 null]
 >> endobj
-2607 0 obj <<
-/D [2599 0 R /XYZ 56.6929 429.5104 null]
+2619 0 obj <<
+/D [2611 0 R /XYZ 56.6929 429.5104 null]
 >> endobj
-2598 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R /F41 1208 0 R /F53 1303 0 R >>
+2610 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R /F41 1218 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2610 0 obj <<
+2622 0 obj <<
 /Length 3963      
 /Filter /FlateDecode
 >>
@@ -12658,24 +12720,24 @@ B¤ž:Ðôné¡ýJt¨ýå,^%œ¹Ÿ&e™/aY¹„%Û„oà‰ÛÕF7Qð"·ñ1*«¿÷Â!Œàè¦±«é·üº@E®Œm?@í]±Ä€¸ˆ
 ò¹Çòƒb$gï½ë	JïJ
  ÌÑØb£ð•ðá5Û'\qOa ÚPù\h°“´eˆáŠjúî8�qÞø*ëL
 endobj
-2609 0 obj <<
+2621 0 obj <<
 /Type /Page
-/Contents 2610 0 R
-/Resources 2608 0 R
+/Contents 2622 0 R
+/Resources 2620 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2585 0 R
+/Parent 2597 0 R
 >> endobj
-2611 0 obj <<
-/D [2609 0 R /XYZ 85.0394 794.5015 null]
+2623 0 obj <<
+/D [2621 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2612 0 obj <<
-/D [2609 0 R /XYZ 85.0394 271.339 null]
+2624 0 obj <<
+/D [2621 0 R /XYZ 85.0394 271.339 null]
 >> endobj
-2608 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F53 1303 0 R >>
+2620 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2615 0 obj <<
+2627 0 obj <<
 /Length 3234      
 /Filter /FlateDecode
 >>
@@ -12694,21 +12756,21 @@ wµ¡›ØÜÇeZ;ê¸?\xÀ}ZxîK›Åã|ÄýáRÈýEÈ	)eÁú¨d@d_ŸM,Úÿ’`€
åª8‘:¡&ÃC!6»ª\»„öÚö
 ÷
 J ꓉'2ûøÉU#
�¦áýÍëâO¿zÓº�¨{Ün×õàò(eÂ4%œR¿¾!H�ŸÉcò#â÷M늄o|]aŠŽÊÜø¶ÏþÈö¢ß^lÁrÝÖëº9g`ÆÇ_¥æ„çÙ‰+ó
ÐÄ›TtlYÊÕjĨ„·ßUêÚö
èýØRg RCü/VFl5Ø›¦z¶�„Äkv”jᘭ/bϹyv*Ù‚¨¶�…œ”0}Z„*ÅT®Åb_óºôe*Ù'ŒIT!c/ì…"ø,>Á1î¯øõýþÈÂͱkžC ¡¡ï�BÄY–ëŠ{§Œû
 endobj
-2614 0 obj <<
+2626 0 obj <<
 /Type /Page
-/Contents 2615 0 R
-/Resources 2613 0 R
+/Contents 2627 0 R
+/Resources 2625 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2585 0 R
+/Parent 2597 0 R
 >> endobj
-2616 0 obj <<
-/D [2614 0 R /XYZ 56.6929 794.5015 null]
+2628 0 obj <<
+/D [2626 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2613 0 obj <<
-/Font << /F37 1018 0 R /F53 1303 0 R /F22 953 0 R /F21 930 0 R /F41 1208 0 R >>
+2625 0 obj <<
+/Font << /F37 1026 0 R /F53 1313 0 R /F22 961 0 R /F21 938 0 R /F41 1218 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2619 0 obj <<
+2631 0 obj <<
 /Length 2047      
 /Filter /FlateDecode
 >>
@@ -12722,27 +12784,27 @@ xÚíYQoã6~ϯ0p/Z3¤(QÔK
w“ÝÛvähÑöA‘h[XYòšr²é¯¿!g¤H¶ì졯‡–Cr43üæã�tÄ„Ã?1Ñã2
 Ó¡ßÎ
 ÞQìÈž›QôV@­�QŠIÅÂX¨óéè´Žóq@1
T„‡÷ !�©53¶?TeuÞýŒÐ¾Øþ};7»½Ž˜–a%Äší…hwteá¶:Å•©ü5¶»µŽþ¨£™�<|ã7�W¥ÓLk•þO´sDÛîŠ'zȦ8“Z$góÑ)%dH518CƒAF:¦‰¤Ï4×sLsí+Ó\Ï3Í	¦¹�GšøV¦?¤«±rla¼;¹ÿñ_B^ÿâÆ€•>ñË( Â¤LD”CH¨ø0ôHjé ‰ý¿gíyIendstream
 endobj
-2618 0 obj <<
+2630 0 obj <<
 /Type /Page
-/Contents 2619 0 R
-/Resources 2617 0 R
+/Contents 2631 0 R
+/Resources 2629 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2585 0 R
+/Parent 2597 0 R
 >> endobj
-2620 0 obj <<
-/D [2618 0 R /XYZ 85.0394 794.5015 null]
+2632 0 obj <<
+/D [2630 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2621 0 obj <<
-/D [2618 0 R /XYZ 85.0394 561.3238 null]
+2633 0 obj <<
+/D [2630 0 R /XYZ 85.0394 561.3238 null]
 >> endobj
-2622 0 obj <<
-/D [2618 0 R /XYZ 85.0394 195.858 null]
+2634 0 obj <<
+/D [2630 0 R /XYZ 85.0394 195.858 null]
 >> endobj
-2617 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F48 1228 0 R /F14 956 0 R >>
+2629 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F48 1238 0 R /F14 964 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2625 0 obj <<
+2637 0 obj <<
 /Length 2558      
 /Filter /FlateDecode
 >>
@@ -12763,45 +12825,45 @@ $GB
-ê̦R¥Ï‚Ãâ

 „‰0û:{¦÷ΞiŸŠ'æš@{¡F†”I±½+,ì«‘cjßuìFýÛ‚ö¿´¸1(v«ÒÕ›Ðó"ÅÜI'OAvÔ>ÙÇ_.`lÕ¸OÓPv»A[<Ù¡ø‰8Ó¡+þk6øe ÊÀ̇?pô™Íà
'½†$!:ñε¿}šÄ/4’©½¡–.8)]ptPIýh:õ34È>¨Ž˜îk‡_þ‰zÿ<·9±>‘êP%,–Q({^"õ±
 ?fËþ¾�ìÐendstream
 endobj
-2624 0 obj <<
+2636 0 obj <<
 /Type /Page
-/Contents 2625 0 R
-/Resources 2623 0 R
+/Contents 2637 0 R
+/Resources 2635 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2634 0 R
+/Parent 2646 0 R
 >> endobj
-2626 0 obj <<
-/D [2624 0 R /XYZ 56.6929 794.5015 null]
+2638 0 obj <<
+/D [2636 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2627 0 obj <<
-/D [2624 0 R /XYZ 56.6929 752.2803 null]
+2639 0 obj <<
+/D [2636 0 R /XYZ 56.6929 752.2803 null]
 >> endobj
-2628 0 obj <<
-/D [2624 0 R /XYZ 56.6929 678.9572 null]
+2640 0 obj <<
+/D [2636 0 R /XYZ 56.6929 678.9572 null]
 >> endobj
-890 0 obj <<
-/D [2624 0 R /XYZ 56.6929 629.2071 null]
+898 0 obj <<
+/D [2636 0 R /XYZ 56.6929 629.2071 null]
 >> endobj
-2629 0 obj <<
-/D [2624 0 R /XYZ 56.6929 596.6999 null]
+2641 0 obj <<
+/D [2636 0 R /XYZ 56.6929 596.6999 null]
 >> endobj
-2630 0 obj <<
-/D [2624 0 R /XYZ 56.6929 561.6414 null]
+2642 0 obj <<
+/D [2636 0 R /XYZ 56.6929 561.6414 null]
 >> endobj
-2631 0 obj <<
-/D [2624 0 R /XYZ 56.6929 497.3516 null]
+2643 0 obj <<
+/D [2636 0 R /XYZ 56.6929 497.3516 null]
 >> endobj
-2632 0 obj <<
-/D [2624 0 R /XYZ 56.6929 426.9933 null]
+2644 0 obj <<
+/D [2636 0 R /XYZ 56.6929 426.9933 null]
 >> endobj
-2633 0 obj <<
-/D [2624 0 R /XYZ 56.6929 245.5268 null]
+2645 0 obj <<
+/D [2636 0 R /XYZ 56.6929 245.5268 null]
 >> endobj
-2623 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F39 1151 0 R /F22 953 0 R /F41 1208 0 R /F53 1303 0 R /F55 1311 0 R >>
+2635 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F39 1161 0 R /F22 961 0 R /F41 1218 0 R /F53 1313 0 R /F55 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2637 0 obj <<
+2649 0 obj <<
 /Length 2197      
 /Filter /FlateDecode
 >>
@@ -12820,45 +12882,45 @@ s ¬4›ÌÚ»´«Ç:v/›b±±kŽÓÒ1N‰Ú‰²­!2îÑ+m±
 ô‘BF7f,2“·	4ós?Žg�]8NøR6µc뤺ý�r¸oöæ†&l§Ü|zµ‡Òká	`]ŸþS·Ú»@o\‡²~²SÊÕ–öÃUpÃ�?¶\
Ûîc»ïøÊ¢ÊÏý	»r!B¸B;(øî?�ÿ>$"ÒôÌ'hA±„¡åtJ¡Å,Ö'Ÿ]DJT
 �yªûÿ
 endobj
-2636 0 obj <<
+2648 0 obj <<
 /Type /Page
-/Contents 2637 0 R
-/Resources 2635 0 R
+/Contents 2649 0 R
+/Resources 2647 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2634 0 R
+/Parent 2646 0 R
 >> endobj
-2638 0 obj <<
-/D [2636 0 R /XYZ 85.0394 794.5015 null]
+2650 0 obj <<
+/D [2648 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2639 0 obj <<
-/D [2636 0 R /XYZ 85.0394 546.7712 null]
+2651 0 obj <<
+/D [2648 0 R /XYZ 85.0394 546.7712 null]
 >> endobj
-2640 0 obj <<
-/D [2636 0 R /XYZ 85.0394 448.103 null]
+2652 0 obj <<
+/D [2648 0 R /XYZ 85.0394 448.103 null]
 >> endobj
-2641 0 obj <<
-/D [2636 0 R /XYZ 85.0394 386.1077 null]
+2653 0 obj <<
+/D [2648 0 R /XYZ 85.0394 386.1077 null]
 >> endobj
-894 0 obj <<
-/D [2636 0 R /XYZ 85.0394 347.8768 null]
+902 0 obj <<
+/D [2648 0 R /XYZ 85.0394 347.8768 null]
 >> endobj
-2642 0 obj <<
-/D [2636 0 R /XYZ 85.0394 315.1782 null]
+2654 0 obj <<
+/D [2648 0 R /XYZ 85.0394 315.1782 null]
 >> endobj
-2643 0 obj <<
-/D [2636 0 R /XYZ 85.0394 279.9283 null]
+2655 0 obj <<
+/D [2648 0 R /XYZ 85.0394 279.9283 null]
 >> endobj
-2644 0 obj <<
-/D [2636 0 R /XYZ 85.0394 215.0111 null]
+2656 0 obj <<
+/D [2648 0 R /XYZ 85.0394 215.0111 null]
 >> endobj
-2645 0 obj <<
-/D [2636 0 R /XYZ 85.0394 155.9807 null]
+2657 0 obj <<
+/D [2648 0 R /XYZ 85.0394 155.9807 null]
 >> endobj
-2635 0 obj <<
-/Font << /F37 1018 0 R /F53 1303 0 R /F21 930 0 R /F55 1311 0 R /F22 953 0 R /F41 1208 0 R /F39 1151 0 R /F48 1228 0 R >>
+2647 0 obj <<
+/Font << /F37 1026 0 R /F53 1313 0 R /F21 938 0 R /F55 1321 0 R /F22 961 0 R /F41 1218 0 R /F39 1161 0 R /F48 1238 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2648 0 obj <<
+2660 0 obj <<
 /Length 2684      
 /Filter /FlateDecode
 >>
@@ -12872,24 +12934,24 @@ xÚ­YKsÛ8¾ûW¨fC×F<LNNâÌ:5yìÆS5U³s %Êâ†�HÙëlÍßn4@‘gj·t Ø
 n™•·ÍNSÍ9$g¡ú{´Cë‹õEùT¤”Œòzµ{8&LÝë&8óèò@$
 �ûë‰ð×M;Yœ;¨¯ÙÝc«–&”2¾3:	ƒý‘ëìÒtôOÃÒpýÇi&ðžï®=RÖ—Í*+±M{1‡�‡Ï�x80¼¿ð­îÜNôÌ "[h¢FÿØá¶_‘Zôø`ÀÿokHÔÝðý©½eì?êwžÔ™CwàùÍ��zi¥ÕþñgNb"™¡6ž´û
 endobj
-2647 0 obj <<
+2659 0 obj <<
 /Type /Page
-/Contents 2648 0 R
-/Resources 2646 0 R
+/Contents 2660 0 R
+/Resources 2658 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2634 0 R
+/Parent 2646 0 R
 >> endobj
-2649 0 obj <<
-/D [2647 0 R /XYZ 56.6929 794.5015 null]
+2661 0 obj <<
+/D [2659 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2650 0 obj <<
-/D [2647 0 R /XYZ 56.6929 368.0049 null]
+2662 0 obj <<
+/D [2659 0 R /XYZ 56.6929 368.0049 null]
 >> endobj
-2646 0 obj <<
-/Font << /F37 1018 0 R /F53 1303 0 R /F22 953 0 R /F41 1208 0 R /F21 930 0 R >>
+2658 0 obj <<
+/Font << /F37 1026 0 R /F53 1313 0 R /F22 961 0 R /F41 1218 0 R /F21 938 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2653 0 obj <<
+2665 0 obj <<
 /Length 1905      
 /Filter /FlateDecode
 >>
@@ -12899,42 +12961,42 @@ xÚ¥XÝsÛ6×_¡ÉËÑ3!ŠO‚¸›>(Ž“¸­•ÔV:�&y IÚâ„"U‘ªêÞÝÿ~,HQ}v¦£
‹Åb?°¿]�M)üØ4V„
  (®lQý UCÅ0Ø8ý„Ðß@žS«m©ø&_ºÑ-Z¤Äð†€Ë�â}—ÑXP=E
Él»Þ
]/3‘Ù}èEÞå7ˆ\ö£¯#¡�Öªïx@xÕ߆ç_?©¯köOåq
@Oű¼Íˆ<x“
 ¢¸<úx‚­ü#¾@ÜŽ�Å7Oª›dÙ&ošç{ }RdºÜÔu›cý¼¿˜ê+c/tû¤PxÙ�Éã
 endobj
-2652 0 obj <<
+2664 0 obj <<
 /Type /Page
-/Contents 2653 0 R
-/Resources 2651 0 R
+/Contents 2665 0 R
+/Resources 2663 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2634 0 R
+/Parent 2646 0 R
 >> endobj
-2654 0 obj <<
-/D [2652 0 R /XYZ 85.0394 794.5015 null]
+2666 0 obj <<
+/D [2664 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2655 0 obj <<
-/D [2652 0 R /XYZ 85.0394 449.4646 null]
+2667 0 obj <<
+/D [2664 0 R /XYZ 85.0394 449.4646 null]
 >> endobj
-2656 0 obj <<
-/D [2652 0 R /XYZ 85.0394 355.3738 null]
+2668 0 obj <<
+/D [2664 0 R /XYZ 85.0394 355.3738 null]
 >> endobj
-2657 0 obj <<
-/D [2652 0 R /XYZ 85.0394 285.1933 null]
+2669 0 obj <<
+/D [2664 0 R /XYZ 85.0394 285.1933 null]
 >> endobj
-898 0 obj <<
-/D [2652 0 R /XYZ 85.0394 241.275 null]
+906 0 obj <<
+/D [2664 0 R /XYZ 85.0394 241.275 null]
 >> endobj
-2658 0 obj <<
-/D [2652 0 R /XYZ 85.0394 202.5209 null]
+2670 0 obj <<
+/D [2664 0 R /XYZ 85.0394 202.5209 null]
 >> endobj
-2659 0 obj <<
-/D [2652 0 R /XYZ 85.0394 168.3311 null]
+2671 0 obj <<
+/D [2664 0 R /XYZ 85.0394 168.3311 null]
 >> endobj
-2660 0 obj <<
-/D [2652 0 R /XYZ 85.0394 95.2288 null]
+2672 0 obj <<
+/D [2664 0 R /XYZ 85.0394 95.2288 null]
 >> endobj
-2651 0 obj <<
-/Font << /F37 1018 0 R /F41 1208 0 R /F22 953 0 R /F21 930 0 R /F48 1228 0 R /F39 1151 0 R /F53 1303 0 R >>
+2663 0 obj <<
+/Font << /F37 1026 0 R /F41 1218 0 R /F22 961 0 R /F21 938 0 R /F48 1238 0 R /F39 1161 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2663 0 obj <<
+2675 0 obj <<
 /Length 3175      
 /Filter /FlateDecode
 >>
@@ -12952,27 +13014,27 @@ P{/	ˆJña¯[ƒã#WÓ¾êv¾Ê[5ÎiJ•wç§ömÏÕªôÙN?ш¥ã£w«òù]x¯LôR™z«®¬„UmÅ	¾Ò7ÞaX¢Z–
 ¨±\Ñ-‚4åÁ_O'!ÎGt[BDÎO‡—f¼ìÈœЬ]z)±[ð?ôŒ`¦ª
ÅÊO{ÙÆ|ÇéÇiù*Ç+²TצÐç1×h¥\CiÙÏá­Vù><'2µ(ê•ë@ˆžz$#Â=§ÃЪ1
 iÍF¨½ëÇC¬µï>éЈ&¶Õq%ÑíSM;´DåZ{µÊ)V«C€s¶Ê¹ÈÛ©Ê9g.[å¸fS4"€’ùÝ?a™óçË�âR\$ñ0”Q×[ÁDk9Ž‹vu߈‚ýOÍrŠ{ÍrŠ‡Ó=31)¤Ô°¿1Ã&„‰ñ	ÿdÞ6îe7ûÇbù{¨tÕ¶B~d�LÚCvr�=ªhŒT�]6¼šzZËÍ¡iºp 5Lî!i.3—¨2Ü
àH¡23šÙE·1±è6fªèH3-®ôꨒ|\t›ðE\OE·ñm]£{°æî\D¼°çËœ\G¼Q飉—j»õK§/`’w8n\ïmÁÁÑ¿·ŠUøðÊ&(€ÇgU«Ê¾›÷ËìcÿÚ™lâ{
ŽS+ú¦ãRÎ’¹æaYT˜û0æ¶kGÃ/¬mü„Æ2ÐDFœ­ØP?3Ül‘wü̘a7¨¶°þh×ustîÁN½žb!±ÇÖ£MfÙp®÷«ìIæUß…‘1)�´`
®Å•ü¸G4m¿‘ÈáüxµÌ‚(w˜*³.1•Ê¬3¦reVŸ©`´NOÎh%Ÿî”)%È•N™¡ÄŒ�6a(~"PíÍKí2);\�ö汌¢ÓþWÏ™óÂé¼Æ¦F€©»uæ=•@§R<úÜ¡ à”ôg`ñbÛÆ—ìí‡Y›Üã‘á7õöu{ú_ÐTãCÖ“ôXeè†mâ)@»YQ²éŒ.“@¥²·e …Óç4ÿøÓÈÓ' Üµji¥
 endobj
-2662 0 obj <<
+2674 0 obj <<
 /Type /Page
-/Contents 2663 0 R
-/Resources 2661 0 R
+/Contents 2675 0 R
+/Resources 2673 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2634 0 R
+/Parent 2646 0 R
 >> endobj
-2664 0 obj <<
-/D [2662 0 R /XYZ 56.6929 794.5015 null]
+2676 0 obj <<
+/D [2674 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2665 0 obj <<
-/D [2662 0 R /XYZ 56.6929 751.0357 null]
+2677 0 obj <<
+/D [2674 0 R /XYZ 56.6929 751.0357 null]
 >> endobj
-2666 0 obj <<
-/D [2662 0 R /XYZ 56.6929 641.026 null]
+2678 0 obj <<
+/D [2674 0 R /XYZ 56.6929 641.026 null]
 >> endobj
-2661 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F55 1311 0 R >>
+2673 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F55 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2669 0 obj <<
+2681 0 obj <<
 /Length 2076      
 /Filter /FlateDecode
 >>
@@ -12991,48 +13053,48 @@ C|B ‘w°ó‡‚
¡úÛoÄaPÆU’¢q¿eëÍ
Ü:Á¬ÏZó,1

|,Σ&¹âwPpSW”ß
>à‰VS' ìàV×÷ÉNP
 åm¾™ &KÜ
 ™8Þ±Z^|ÄQò·ôfq†ï@f%„låi×wM¹23ò+†%×ó»m¶^lsƒÑ¨M}ÒÀ	¬4Óœiï²p¿ïIaî�}¼bìÁŠr:t/ùôÜPoÁç«;gy±Éö•¿S—í3Þ쥸†]‰ª'š—cÊÓôuw(,ÕLkýSa�ä™°q„À%Iãýw$ì_íüy3ŸswÍÎ[¢ÝCmÛù{ß�ãE=­¹G$j¬L¾¾Ýû/ºÚÇðÂZJ™¼n%3ÊŒ±;öÜ·J|#ŽˆÐñ¯Ÿ¢ŸžÜu‚ø#ãƆHÇWN”BÅE¢U­ŸëþÉ=÷zendstream
 endobj
-2668 0 obj <<
+2680 0 obj <<
 /Type /Page
-/Contents 2669 0 R
-/Resources 2667 0 R
+/Contents 2681 0 R
+/Resources 2679 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2634 0 R
+/Parent 2646 0 R
 >> endobj
-2670 0 obj <<
-/D [2668 0 R /XYZ 85.0394 794.5015 null]
+2682 0 obj <<
+/D [2680 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2671 0 obj <<
-/D [2668 0 R /XYZ 85.0394 752.2293 null]
+2683 0 obj <<
+/D [2680 0 R /XYZ 85.0394 752.2293 null]
 >> endobj
-2672 0 obj <<
-/D [2668 0 R /XYZ 85.0394 623.4383 null]
+2684 0 obj <<
+/D [2680 0 R /XYZ 85.0394 623.4383 null]
 >> endobj
-2673 0 obj <<
-/D [2668 0 R /XYZ 85.0394 561.5469 null]
+2685 0 obj <<
+/D [2680 0 R /XYZ 85.0394 561.5469 null]
 >> endobj
-902 0 obj <<
-/D [2668 0 R /XYZ 85.0394 523.3883 null]
+910 0 obj <<
+/D [2680 0 R /XYZ 85.0394 523.3883 null]
 >> endobj
-2674 0 obj <<
-/D [2668 0 R /XYZ 85.0394 487.1636 null]
+2686 0 obj <<
+/D [2680 0 R /XYZ 85.0394 487.1636 null]
 >> endobj
-2675 0 obj <<
-/D [2668 0 R /XYZ 85.0394 455.5032 null]
+2687 0 obj <<
+/D [2680 0 R /XYZ 85.0394 455.5032 null]
 >> endobj
-2676 0 obj <<
-/D [2668 0 R /XYZ 85.0394 390.69 null]
+2688 0 obj <<
+/D [2680 0 R /XYZ 85.0394 390.69 null]
 >> endobj
-2677 0 obj <<
-/D [2668 0 R /XYZ 85.0394 319.8083 null]
+2689 0 obj <<
+/D [2680 0 R /XYZ 85.0394 319.8083 null]
 >> endobj
-2678 0 obj <<
-/D [2668 0 R /XYZ 85.0394 137.601 null]
+2690 0 obj <<
+/D [2680 0 R /XYZ 85.0394 137.601 null]
 >> endobj
-2667 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F48 1228 0 R /F41 1208 0 R /F39 1151 0 R /F53 1303 0 R /F55 1311 0 R >>
+2679 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F48 1238 0 R /F41 1218 0 R /F39 1161 0 R /F53 1313 0 R /F55 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2681 0 obj <<
+2693 0 obj <<
 /Length 2272      
 /Filter /FlateDecode
 >>
@@ -13045,45 +13107,45 @@ X¹®sÛ6p•Õ}ÕÅϨ�6Tù·­š²eGˆpÍdšÙÔˆ×Á¯Ïõ2øí¹|Úiã6{ãÈÈ4qd?tj–�ŽüuW¹àðuS
 .©3z»
 
 endobj
-2680 0 obj <<
+2692 0 obj <<
 /Type /Page
-/Contents 2681 0 R
-/Resources 2679 0 R
+/Contents 2693 0 R
+/Resources 2691 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2690 0 R
+/Parent 2702 0 R
 >> endobj
-2682 0 obj <<
-/D [2680 0 R /XYZ 56.6929 794.5015 null]
+2694 0 obj <<
+/D [2692 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2683 0 obj <<
-/D [2680 0 R /XYZ 56.6929 436.7599 null]
+2695 0 obj <<
+/D [2692 0 R /XYZ 56.6929 436.7599 null]
 >> endobj
-2684 0 obj <<
-/D [2680 0 R /XYZ 56.6929 377.1162 null]
+2696 0 obj <<
+/D [2692 0 R /XYZ 56.6929 377.1162 null]
 >> endobj
-906 0 obj <<
-/D [2680 0 R /XYZ 56.6929 340.6441 null]
+914 0 obj <<
+/D [2692 0 R /XYZ 56.6929 340.6441 null]
 >> endobj
-2685 0 obj <<
-/D [2680 0 R /XYZ 56.6929 305.0954 null]
+2697 0 obj <<
+/D [2692 0 R /XYZ 56.6929 305.0954 null]
 >> endobj
-2686 0 obj <<
-/D [2680 0 R /XYZ 56.6929 273.8816 null]
+2698 0 obj <<
+/D [2692 0 R /XYZ 56.6929 273.8816 null]
 >> endobj
-2687 0 obj <<
-/D [2680 0 R /XYZ 56.6929 211.3161 null]
+2699 0 obj <<
+/D [2692 0 R /XYZ 56.6929 211.3161 null]
 >> endobj
-2688 0 obj <<
-/D [2680 0 R /XYZ 56.6929 154.6374 null]
+2700 0 obj <<
+/D [2692 0 R /XYZ 56.6929 154.6374 null]
 >> endobj
-2689 0 obj <<
-/D [2680 0 R /XYZ 56.6929 83.0386 null]
+2701 0 obj <<
+/D [2692 0 R /XYZ 56.6929 83.0386 null]
 >> endobj
-2679 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F55 1311 0 R /F22 953 0 R /F41 1208 0 R /F53 1303 0 R /F39 1151 0 R >>
+2691 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F55 1321 0 R /F22 961 0 R /F41 1218 0 R /F53 1313 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2693 0 obj <<
+2705 0 obj <<
 /Length 1193      
 /Filter /FlateDecode
 >>
@@ -13097,60 +13159,60 @@ mG‘{�1]»©yšQœÄÉ«7·YDEt8É�?ã¡@\„VCÓ}’nó8?A
 eµfܬ®�‘�%ŒuÙv�ê0Þ"’*Ä@‚më³6[-U´U5*óI÷`#±JwëE»d¿eqQ褳8úœ#2yÔfŒFvéðóôþRŸfoFãŠIVfòÑ…4²—
·nÖoßS ÚŠßÔ2×RìºÃ8Ÿû«M4÷M~ì¶ÿ»I<Ùè¨W,§µóöãÝðÚå…ÞçíL¨BéîÎt½¨®Ìï:Ëc8g;ï®Æ“›ßÐG
´âºÈÃç{H‡iñµŒíÇÝ#|>¬º¢õk
 ¢^™†“hŸæèà̇‘97c]îâš¡_þh:|ò1)iwú3lÊ„"•Sæ0$ǮןW§¾ÿoØ~=endstream
 endobj
-2692 0 obj <<
+2704 0 obj <<
 /Type /Page
-/Contents 2693 0 R
-/Resources 2691 0 R
+/Contents 2705 0 R
+/Resources 2703 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2690 0 R
+/Parent 2702 0 R
 >> endobj
-2694 0 obj <<
-/D [2692 0 R /XYZ 85.0394 794.5015 null]
+2706 0 obj <<
+/D [2704 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2695 0 obj <<
-/D [2692 0 R /XYZ 85.0394 752.36 null]
+2707 0 obj <<
+/D [2704 0 R /XYZ 85.0394 752.36 null]
 >> endobj
-910 0 obj <<
-/D [2692 0 R /XYZ 85.0394 715.133 null]
+918 0 obj <<
+/D [2704 0 R /XYZ 85.0394 715.133 null]
 >> endobj
-2696 0 obj <<
-/D [2692 0 R /XYZ 85.0394 679.3174 null]
+2708 0 obj <<
+/D [2704 0 R /XYZ 85.0394 679.3174 null]
 >> endobj
-2697 0 obj <<
-/D [2692 0 R /XYZ 85.0394 648.0662 null]
+2709 0 obj <<
+/D [2704 0 R /XYZ 85.0394 648.0662 null]
 >> endobj
-2698 0 obj <<
-/D [2692 0 R /XYZ 85.0394 584.5937 null]
+2710 0 obj <<
+/D [2704 0 R /XYZ 85.0394 584.5937 null]
 >> endobj
-2699 0 obj <<
-/D [2692 0 R /XYZ 85.0394 527.008 null]
+2711 0 obj <<
+/D [2704 0 R /XYZ 85.0394 527.008 null]
 >> endobj
-2700 0 obj <<
-/D [2692 0 R /XYZ 85.0394 454.5022 null]
+2712 0 obj <<
+/D [2704 0 R /XYZ 85.0394 454.5022 null]
 >> endobj
-2701 0 obj <<
-/D [2692 0 R /XYZ 85.0394 310.0583 null]
+2713 0 obj <<
+/D [2704 0 R /XYZ 85.0394 310.0583 null]
 >> endobj
-2702 0 obj <<
-/D [2692 0 R /XYZ 85.0394 249.5076 null]
+2714 0 obj <<
+/D [2704 0 R /XYZ 85.0394 249.5076 null]
 >> endobj
-914 0 obj <<
-/D [2692 0 R /XYZ 85.0394 212.2807 null]
+922 0 obj <<
+/D [2704 0 R /XYZ 85.0394 212.2807 null]
 >> endobj
-2703 0 obj <<
-/D [2692 0 R /XYZ 85.0394 176.5798 null]
+2715 0 obj <<
+/D [2704 0 R /XYZ 85.0394 176.5798 null]
 >> endobj
-2704 0 obj <<
-/D [2692 0 R /XYZ 85.0394 145.2139 null]
+2716 0 obj <<
+/D [2704 0 R /XYZ 85.0394 145.2139 null]
 >> endobj
-2705 0 obj <<
-/D [2692 0 R /XYZ 85.0394 81.7414 null]
+2717 0 obj <<
+/D [2704 0 R /XYZ 85.0394 81.7414 null]
 >> endobj
-2691 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F41 1208 0 R /F53 1303 0 R /F55 1311 0 R >>
+2703 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F41 1218 0 R /F53 1313 0 R /F55 1321 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2708 0 obj <<
+2720 0 obj <<
 /Length 1934      
 /Filter /FlateDecode
 >>
@@ -13164,51 +13226,51 @@ xÚ¥XK“7¾ó+¸eHE�yñîÆKcgÁ©¤lf
S
a†Åäק[-
°ÌÚ•Jq˜V«ÕjõãSÑçðý(fq&³~’…,â"ê
 ~¾¡I)xØ®×µÕŸ¤¥ÖN$m{ƒR@ÈýH×-ð\¹t”=áÑgʘü<£ó¢ÐÛ&o;ŒGŸ›m©è¯Í.'²…5Läj¿~^3u¹4.¡
¶KTÆ%[^ëgª{S¸ÎW7$‡{0<ù·jA¹R¸£µ£ß¦ïH\e/ç=µ/(Ÿ¹eóMi
 ¿�½wá»o7°Ý5|‹•.¾8–k#†þ7ÁS¾.çöIbßZ‹«toBjÓçµG:‡©'4ô×þ?6¢ßÏØÑÛoï&³ë¿Y\ÂÅS’gßNÊ3!ÿŸÈuNz¡6Ñží˜H–ÀÃë›;z™ëÏ“$IÀ.u¹ã¬íÄlŽSŸd¯é§rî½fãv~aœ@¢-öÒR€Cø/R‡Ù¼
Àÿþ³êô�\QLSÙí
™@=e@;£Ð"‰¯ƒìþÖº¶ý_‹¼cendstream
 endobj
-2707 0 obj <<
+2719 0 obj <<
 /Type /Page
-/Contents 2708 0 R
-/Resources 2706 0 R
+/Contents 2720 0 R
+/Resources 2718 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2690 0 R
+/Parent 2702 0 R
 >> endobj
-2709 0 obj <<
-/D [2707 0 R /XYZ 56.6929 794.5015 null]
+2721 0 obj <<
+/D [2719 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-2710 0 obj <<
-/D [2707 0 R /XYZ 56.6929 752.0914 null]
+2722 0 obj <<
+/D [2719 0 R /XYZ 56.6929 752.0914 null]
 >> endobj
-2711 0 obj <<
-/D [2707 0 R /XYZ 56.6929 555.924 null]
+2723 0 obj <<
+/D [2719 0 R /XYZ 56.6929 555.924 null]
 >> endobj
-2712 0 obj <<
-/D [2707 0 R /XYZ 56.6929 468.7059 null]
+2724 0 obj <<
+/D [2719 0 R /XYZ 56.6929 468.7059 null]
 >> endobj
-2713 0 obj <<
-/D [2707 0 R /XYZ 56.6929 405.3981 null]
+2725 0 obj <<
+/D [2719 0 R /XYZ 56.6929 405.3981 null]
 >> endobj
-918 0 obj <<
-/D [2707 0 R /XYZ 56.6929 366.2553 null]
+926 0 obj <<
+/D [2719 0 R /XYZ 56.6929 366.2553 null]
 >> endobj
-2714 0 obj <<
-/D [2707 0 R /XYZ 56.6929 333.1561 null]
+2726 0 obj <<
+/D [2719 0 R /XYZ 56.6929 333.1561 null]
 >> endobj
-2715 0 obj <<
-/D [2707 0 R /XYZ 56.6929 297.5057 null]
+2727 0 obj <<
+/D [2719 0 R /XYZ 56.6929 297.5057 null]
 >> endobj
-2716 0 obj <<
-/D [2707 0 R /XYZ 56.6929 231.276 null]
+2728 0 obj <<
+/D [2719 0 R /XYZ 56.6929 231.276 null]
 >> endobj
-2717 0 obj <<
-/D [2707 0 R /XYZ 56.6929 170.9331 null]
+2729 0 obj <<
+/D [2719 0 R /XYZ 56.6929 170.9331 null]
 >> endobj
-2718 0 obj <<
-/D [2707 0 R /XYZ 56.6929 95.6701 null]
+2730 0 obj <<
+/D [2719 0 R /XYZ 56.6929 95.6701 null]
 >> endobj
-2706 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R /F41 1208 0 R /F53 1303 0 R >>
+2718 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R /F41 1218 0 R /F53 1313 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2721 0 obj <<
+2733 0 obj <<
 /Length 811       
 /Filter /FlateDecode
 >>
@@ -13219,40 +13281,40 @@ a_—áõyö(M(«Ó-œ:äý±%4OøMì5|·"¡Ü‹¾hËDè+ìre…I’L3‹7V²,O«N=»ÏVXÕºl6‰±íêsº
 Z�Ú¼ú¦[¹>ƒ;FÀ�ë3�ÁAë>�š�ÑåüÚlcjÀ
 ›æ„·ðÃóÙ±Á+»-ɳ"«j(»®nÓUjo’¥¥u
¼aµ“t 
‚
 endobj
-2720 0 obj <<
+2732 0 obj <<
 /Type /Page
-/Contents 2721 0 R
-/Resources 2719 0 R
+/Contents 2733 0 R
+/Resources 2731 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 2690 0 R
+/Parent 2702 0 R
 >> endobj
-2722 0 obj <<
-/D [2720 0 R /XYZ 85.0394 794.5015 null]
+2734 0 obj <<
+/D [2732 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-2723 0 obj <<
-/D [2720 0 R /XYZ 85.0394 615.679 null]
+2735 0 obj <<
+/D [2732 0 R /XYZ 85.0394 615.679 null]
 >> endobj
-2724 0 obj <<
-/D [2720 0 R /XYZ 85.0394 555.6269 null]
+2736 0 obj <<
+/D [2732 0 R /XYZ 85.0394 555.6269 null]
 >> endobj
-2719 0 obj <<
-/Font << /F37 1018 0 R /F21 930 0 R /F22 953 0 R /F39 1151 0 R >>
+2731 0 obj <<
+/Font << /F37 1026 0 R /F21 938 0 R /F22 961 0 R /F39 1161 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-2048 0 obj
-[922 0 R /Fit]
+2060 0 obj
+[930 0 R /Fit]
 endobj
-1881 0 obj
-[922 0 R /Fit]
+1893 0 obj
+[930 0 R /Fit]
 endobj
-1578 0 obj
-[922 0 R /Fit]
+1590 0 obj
+[930 0 R /Fit]
 endobj
-2725 0 obj <<
+2737 0 obj <<
 /Type /Encoding
 /Differences [ 0 /.notdef 1/dotaccent/fi/fl/fraction/hungarumlaut/Lslash/lslash/ogonek/ring 10/.notdef 11/breve/minus 13/.notdef 14/Zcaron/zcaron/caron/dotlessi/dotlessj/ff/ffi/ffl/notequal/infinity/lessequal/greaterequal/partialdiff/summation/product/pi/grave/quotesingle/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde 127/.notdef 128/Euro/integral/quotesinglbase/florin/quotedblbase/ellipsis/dagger/daggerdbl/circumflex/perthousand/Scaron/guilsinglleft/OE/Omega/radical/approxequal 144/.notdef 147/quotedblleft/quotedblright/bullet/endash/emdash/tilde/trademark/scaron/guilsinglright/oe/Delta/lozenge/Ydieresis 160/.notdef 161/exclamdown/cent/sterling/currency/yen/brokenbar/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine/guillemotright/onequarter/onehalf/threequarters/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]
 >> endobj
-2077 0 obj <<
+2089 0 obj <<
 /Length1 1628
 /Length2 8040
 /Length3 532
@@ -13262,7 +13324,7 @@ endobj
 stream
 xÚíte\Ôí¶6Ò ˆtÃÐÝÝÝÝ¡Ä000Ì ÝÝÝÝ’‚R"‚´t	ÒÈ‹>ïÞûüž³?�³?½¿w¾Ìÿ^×Z׺î7�¶‡Œ5Ü
 ¬‡¹rðpr‹t�´�P(ÐWç�…C­
�f
L9g0ЇÉ]Á¢
-Äü{fXE
+Äü{fXE
 0Üú÷äè¹aÖ�ÃöOÃoäæìüØã?ûÿxýœÿŒ=ì	a.ÌÁAb¡ö™9Y®
Ä£ò/z{x�Âœ*Þè—ÖÁ»2#×Dj,ïêÃ8›ÇEµyÍî;Ýoª²n
öA™ºÓÁß‹(üèX>ã.3v±ms™W`gÅúϨ¯"›
 rn­�êèš—ß¡RŽwð9£_²Ò¹Ð_8=óe4%v>oFÀk(Ù?`LÙ½¼`êú4ð±ûåÃ&9[~ƒ˜;26cLà«|r)Sƒj…×Íl(ßÛ
 b¬Å7ÎßÊçÏVð™h9�Žù,¢I‚°RÊ• e®äß·RÆ%=²ìÙ
êt›œ(†Ì%³LÇ�î)®Ž>1Ù¥‘„µ…^Ñ2¼éˆO£Ý	%õ‰>•pjÕr{2–Âw�Í<–g¬™-j—!3cäáakIè,AŒ$ÁLˆÇÆ‹J¯³nöùU»Ïm›Þ‰D3
@@ -13285,35 +13347,35 @@ $O�íœàÅ€DÈ
 t�‡Í=žÝbóÆÃwî6ß"£“˵?�”JËOP2RÐoQo+†â1)©w†¦ÜèådîI½ÈZ¿VÍ�­(e÷åû È
"QÔüFØs(úF�$'‘qL ®/¶!õÔ
¤HvkÖ‰Œh¼È‰¬ê؉á¶o?Ùa:Šÿ±qêcŒ°gã!_QÇ~ÏWê¡1üaœ¯UÝGmã§Yñmn%ìRãr9÷¬ß0qˆ5†/‚E…(êÚ“�†,W‚˜$Ù½ï¶åçLxËÎÔ|ú奕£w†Z|ÂV€ãž÷,éOd
 ÞyŠGÝ
 ŽÎ¨Ý3lÍ4©¿Î\×T2Zª½Ag—.7Ù#ÏPæï™v¼eŦQLÞ»±Oþ¼Ô\’	¬ÿĵJÅñ¾(š3Ç].Å*,MÎ>ÛBx�(ÃSÃó|D³uû‚Þ¡ï†{:Ò‘Á¨2G9¡Cê{É•<|?�ÒK áéá@F)Ø,êw÷ó?�È ¸¢Ëa„Çh%Ù±o^Œñ{‹6™Ý@¥-«ä%
Å~jÉwXjz1�îi´·î¬%uÕ3^¿±g�¸`d+ÎK[ŽDe—„]âò†Yè�ÖýÇ?Ï>£³HjË,èkѸÍhÔ8Š”™v_Å
[ªJÖ®²9m=·�âú?\‹k>¼à¬‡¤*³Ñ³ž,Y
ê<‹ý¹uÓZ/ZV$S·é#ƒmNOš¨5M@¿§rãÝ0Hõ7¬&7[àçŽAØñêOõƧÈêÚ5±pE6~d»Ž^.x¨T1¬µ¤$£Í7¿ÿ4òÆêüj§‹G1¬èípoóÌ3³QýÐZ:œNÍÆéç,0½‹Š‡Zg‹ðâ£à)‹Q©¯³‹X""œÛÆ0�ÏÁ¾äBvFA‚)Y9(ÎYÖý…ì¬S…|¸Ôü¾“qbæÇN.LÔX§…_�ï‚¿œ%�%½¥åŒìé|°
D>W²7}C–Í#—ZR¸
­$º`bÛGο…a¿9gÝS%\”Á/œîñ�hC|�?s§Ø…šg¯ÎÙÈ)ª¬m}ÐvÖËk†Ÿ.bÉ&O
 üõí+uqfº`Îa‡„°£â,I§ã¯½/‘�˜÷�ÇÝ›Á¤'P6ߢH‚
Ú?÷›½šÙ¹˜Žà9¦ŠmHr7:pMRYŸ#£ 'æW¥¿ðKCß|-¡mWÝ躖nᲶË0–«ÞÐ3äÛÙ=j’
¸Ë-,n–³e±€¢üb½iÙ;‘˜Hâ°l<)žL.ßÐYÖÿ°Ú·)�wL=(‚Œ£± L|�)=å'ÀÆ-Å@²öò¾µ<ÃNrä³6îµEôʃ3±d¶kÓ»¬ÿ‹%ôµøü·(kD~ô(¬_yñ‡Í;¯åä²fùOî{&*‰äyÒ¯9Û�B±T¨d>è.<Sâ¢éX3p7«Á~ª"럽Ÿ“lË´ÍÔDQÿfŒ°Ì
-*s"}Y
;Ò‰¢ú{YÌÝÇí]p¶Òݯ€Ž¶Xo³êÙ}
+*s"}Y
;Ò‰¢ú{YÌÝÇí]p¶Òݯ€Ž¶Xo³êÙ}
 endobj
-2078 0 obj <<
+2090 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2725 0 R
+/Encoding 2737 0 R
 /FirstChar 67
 /LastChar 85
-/Widths 2726 0 R
-/BaseFont /ROKKYO+URWPalladioL-Bold-Slant_167
-/FontDescriptor 2076 0 R
+/Widths 2738 0 R
+/BaseFont /YZQMAF+URWPalladioL-Bold-Slant_167
+/FontDescriptor 2088 0 R
 >> endobj
-2076 0 obj <<
+2088 0 obj <<
 /Ascent 708
 /CapHeight 672
 /Descent -266
-/FontName /ROKKYO+URWPalladioL-Bold-Slant_167
+/FontName /YZQMAF+URWPalladioL-Bold-Slant_167
 /ItalicAngle -9
 /StemV 123
 /XHeight 471
 /FontBBox [-152 -301 1000 935]
 /Flags 4
 /CharSet (/C/D/E/H/I/O/R/S/T/U)
-/FontFile 2077 0 R
+/FontFile 2089 0 R
 >> endobj
-2726 0 obj
+2738 0 obj
 [722 833 611 0 0 833 389 0 0 0 0 0 833 0 0 722 611 667 778 ]
 endobj
-2062 0 obj <<
+2074 0 obj <<
 /Length1 1630
 /Length2 6133
 /Length3 532
@@ -13325,7 +13387,7 @@ xÚíVuTÔí¶VA�!¤†n†n”.IéÎ
†˜
f(‘N)én$†�FJ	Á!¤[:%•$.úÝï|g}÷üuÏùë®;kͬ߻Ÿ½Ÿýìø½
 Òy¦§aáèha
…«pJí•�Ž H
 ±@Bá0Y$D¤±ÉB¬@¼¼ 
 µµC‚XnxXÙÙ9þ²ür
Yzý‰ÜD" ¶0Ó̓;Äîì�!o(þ×�Zi
Ù@! u
%5‹‚šH
ƒ¸Þ¡áf鵩@­ 0„dw9þq
-³rt³þ%àÆnÿ-ÈÙ~ãátƒÝ�iÀH„•+Ô	ºÉª!+ÿ‡N¤�òWnôÁmn<­áVn¿Jú�ÝÐÜ H(
BB<‘¿rYB@ÖP„³£…×Mî2gWèon(Ìö/ Wˆ­…«µ#�¸¡¹áþÕ�¿êýSõÎÎŽ^¿£á¿½þ¡
ŠD@m¸
+³rt³þ%àÆnÿ-ÈÙ~ãátƒÝ�iÀH„•+Ô	ºÉª!+ÿ‡N¤�òWnôÁmn<­áVn¿Jú�ÝÐÜ H(
BB<‘¿rYB@ÖP„³£…×Mî2gWèon(Ìö/ Wˆ­…«µ#�¸¡¹áþÕ�¿êýSõÎÎŽ^¿£á¿½þ¡
ŠD@m¸
 ÿóü{é!Oˆ`zn%lŸš‘†¬"Ïéé—5úÐÁƒÑâ\\£ý:ß¿Þî—¾(Rf~QÂU;(zÕä5¾í|¹ªÌ¶ÖÛAæÈÜžÙË£ò¡g}ŸO4ÏôNˆ}-lZŒŸöU/Ê{Le
ÓP�[wm©_ó™iÑÅ=àà;>WìýSVz÷|R†g_«”·¯´ÖÞ"®*ØþÊ”°yzÂÜÕ÷±§»ýðîûUJöìW8Œbî˜øL‘þ.Ù”OuJåÊߪݎË;BbubÁï<_^Ë¿Å`�i¢KÙÅy¨yc@–‰Ÿ'\;ø$·®Q;S-”âs/,
9D¦Ô#,9ƦïKv²±SÐúê¿»èçö‰%…÷²õ-âÁ]3ëãÝ“±Ñ][™CæºÊlëŠÑLü‹¦ëÀ¢€5‘ؽrô›ìç3üÜ°�˜üDÑSjÛðôä)Wï�8Ž*öÜŸèž“3@'}~+Ï�Ý6‘žˆ•Ø\Žpµ<züuÚ>AbåPó�بLbZ÷a3ÒYÍEœVÁ= ¾‹­{·^®2<¿}5aq€©ÿ_5¹Ûðòµ÷>›À¥´ê$C}ÀXŠ¹­œÕ÷ji�—û­€�G‡/§Œdû-!j¹;Ë6#ÔÜŠ.Oé­×ôÎc´¼�$z¾I(ñ�ØÇ/Wj®½"¹ßKÒÿ¾ð{Lš¿ÞH¥hԻí�:iÓFRF<g]Û39}—ÞÞF™8|à0­‰å
 b݇a›yKÜ£%t×TcaÖ�ËF˨?B:äÐ	3ÚZP‚ÌÆŠ}
fñφôˆƒ�TU‡J鉽žj:»«Ï‹ºôN)/ÂÕ	äE½¬^gº‹ ^/«k¯&6Ö7%³"”-ήQËòÍ“ñÆ‘r¾“'#
 ñÀèHvo»Vüy½¼Òç³³�”ÎjÁÕŸ,_Âh^§–p³/â#Ó„HÊÀç„»ûÄŒ[‡¤Ê»B8Ò¬’%�PË ™#¹&}Ô7uo(à–îu•úµÒ95À�Œ¾?ËêcÕ8—Äñ�âθÑ,™ê:f”†.‡Ðà¡ÝõÁ41hÀ›3):«;Ícƒ·ú�‘¶Þ,èðY½:Nç5u…QEð‰rŸ–²ÌûŠ!&.ÜYâü×Éú;á$¤`×yme~b©@{•3*¹
@@ -13343,35 +13405,35 @@ d ¯òˆ¦:ôw
 ÕB¾ª\h~8©$‰¼¼·ý˜7!g;É¥�ƒ\®cf>}7›ùâžÐÙZسãÁÖ–�Ü^-Už&(
 ÖËÓ»ÜIFÙØS­˜õOV_ºhýÐn-®
 X{$¢½‰¼û£@–rlZ™âɞˊ1o(­¶¨mèö¡Ðé»÷Ýõ�äIŒ]Œ_-ô‹¸Þûò'zŸT¶n76Gت–·&úìIĆ‹7ÎÔ‰‰f¾<B‡›&ª½úŒ×ž´)„Æc+¤ œ?µÆ(
_¹à™ñ0áNZ¬/ˆ_c24íŒË¢—'{.ö¥dÖî§Çz̓¯ÛKÃ{u`‡:s±¹ Á<º'—0—	HMq±LåRnC@x›ôs̈W6ß>uä3¾õˆ;)EO4,Źk&l‰#õŽ¾„˜¬Ù¶³	½höâiF�]	‹œx'´ÅfÊb\ñê{Ý?¬¹¶=ê3�¤XTÕW©*®§‰\Ee¶©x‘@†Dz:ƒ!¡X¾ÂK”G½èß>c{�BŒÍCŒ±¹0šUÕ¼ƒ¿ªÝ•5xfœéÉU“Nhèò�ã»Z–$8û훎·òБÞåú¸;ß¾2~%~QÍ÷*|6οÀ.©ó¶H&l]ážçµÐ[èù%¥κƬ!ÙrOxÆ!.B˜“zuW,Ôêr‹9å™ÊT°CHÖ‘_e‘‰ÿð
:û5r€û3.ñ4v—W”ò]ª[)ïó–äÙÀ—݈H¾�ÌûùSŽ¸+¹ºfS4çHõ¿
ÞzyàÂ*/ç%Šâ׻͠Ï8ôæãmº'7…\ì°Å÷K)8ÐÁ@£bÅî\ç±ÄÝÊ‚×[g“©»5é«ÅÖ¡’'¯ÔíÌ¥ºégˆ<
‚â¢Ï8TŠqùœ_Uå=¢¦#fœÞ*ª6í¶²*�æ›\oi›�–•`ûlj[ÛW*ˆ»ºœ2Ž(ËtŒp{ˆ¥6Í]š†}„¯>{?'CÆà§5zíEëÝÚÓÞ&vø¾öŠ
÷dYcØL‰8àÇÉu°à•GËÝšÎñtûëV²­ˆ’eÓëû­&KÅàჃ‘oS*.m•»8ÕîŒWQì3ÊDÌûj	OpHY
²ï®f>×¼ù‰_ôŸö‘Ƥ‰´»ø|EÀ’=P�zêîXDƒ%½+C£ˆ1_ù¶‡=AýYœ:&Aaú;æ¬U¾ö��Ý*“ÍXJ·=à²ùˆ
1¦¬ý<�ð»©,|#
O'Cƒµë“M]í¼æf°ºÜS4‡AÇ÷Mj€“Ò·ÐökxõÊáž™ËG‡ÞÕéú,óÔ92‚¬
߸gp0o9)ÁM£«&ChVF=Vv¯ñõ­Åž�¡üÜÈT·Žïvä(Ê´ãé¿7jzä­ ¾¹�Â6]E³ÚŸÉÞeI�G�OIùç…&˜+ÊZ Sl©
-Í`ƒ©c�½G¯Lsé:JθÿÍàÿ	þOX9B,\‘p'WÀ
ºry‡endstream
+Í`ƒ©c�½G¯Lsé:JθÿÍàÿ	þOX9B,\‘p'WÀ
Bèy²endstream
 endobj
-2063 0 obj <<
+2075 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2725 0 R
+/Encoding 2737 0 R
 /FirstChar 66
 /LastChar 78
-/Widths 2727 0 R
-/BaseFont /ECBWGF+URWPalladioL-BoldItal
-/FontDescriptor 2061 0 R
+/Widths 2739 0 R
+/BaseFont /SUWELI+URWPalladioL-BoldItal
+/FontDescriptor 2073 0 R
 >> endobj
-2061 0 obj <<
+2073 0 obj <<
 /Ascent 728
 /CapHeight 669
 /Descent -256
-/FontName /ECBWGF+URWPalladioL-BoldItal
+/FontName /SUWELI+URWPalladioL-BoldItal
 /ItalicAngle -9.9
 /StemV 114
 /XHeight 469
 /FontBBox [-170 -300 1073 935]
 /Flags 4
 /CharSet (/B/D/I/N)
-/FontFile 2062 0 R
+/FontFile 2074 0 R
 >> endobj
-2727 0 obj
+2739 0 obj
 [667 0 778 0 0 0 0 389 0 0 0 0 778 ]
 endobj
-1440 0 obj <<
+1450 0 obj <<
 /Length1 771
 /Length2 1151
 /Length3 532
@@ -13379,168 +13441,160 @@ endobj
 /Filter /FlateDecode
 >>
 stream
-xÚíRiTSבª¡¬2©¤j=,Œy5„„!
£soÈ-ɽôrID¨¤*Ë"6ºd¥Âª"P”Zb^
'Ò*Â#,ŸEªVEÀ©¬««ôgûë­wΟ³¿ý�½¿ó�Ms‹”1D¶
ÆP‚Áar„ P*•pØ€<³Ù-‡å‚¡ArŽ@àVkÕ€»°ùBÞ
-!�O¡�@,]�#©*xÒ'I| ÒÀ8¢�£@*'T°†¬¡�«�S 0¡g‘Z
ÖNÞÈ
-xLɤR$„¡j=€`%…�‘Ý`RË?!kzñ`­Z!×L–Ÿrê/y¹Qëg`št-
ã@ŠA0ŽN§ÆÂoÄIaÑj¦g%„\�(DhªÎJ&{åÉFt0‰
-PÊÕð£Ðt%¤S:Xa!á±"Ïß¿v*)GP"JŸö쩘óGLš„#:�Àf²Ù’Hî·§¤iÍĨƒ4py^@Žãr=…"2â�l@PÖ
XG*f1QŒ ¯
-.`pyd+öJoÀç±sÿDThqF‰©ñ!
z+ÒSÖÁ
-Šù¦ðÙòñÞSÛjóÄÕ]Gmé�‡·tœÛzÒèÃîóqº†7ýð«ãVÇ�‘c¥#a_± %¯ŸzJ”cÊ–±¶ö:šì]è•ûd³(†“g\*oo{Os`û]óbKz“çƒÝŸÞÉ<g[~�ͬ½yãåã¼´��ýf»/!÷¡RJRùéð=pÌï_™¸‚UcæšKó÷=u~e¦¶ÝîI»eoÊ¥6×�¾/æ°é:å@'…³?m±9®L°Z&œ½ÐëZL…X½ïëfŒóki“þ2{°›.t3¾Û#)È-
�•D�.8Z館] ö
©¡ZÃ
mëZ5~è…BKÚ§´†.®o	'½immÊøKÚ¯KvÌ|’ôüyß³×jëE¶›•ëñ±žÞûý3=<‡élªíÕÏLnñrÕw	‘hŸÝ*C»æßþ9-cR'¸žïrãÈgîf.åžp\³·â_Òuž_7›v'ŠuV‚ø‹è‡U¾ØjØÏMLèK9uÓóR]ãùê çºÂ™I¦æààê%ͳ±ÞÁ€ùn~Î}æ:ˆ-Q@µÓ|¡GW|_u6lj71¾è˜Ðë@ÏŸ¡J£MM#‡½åÙm^�¶“y?jy¶÷/6çÂêRô]Þu'LßÏ[¶ŠÊa¬Ù›v¬6¬v›FÿH0gÏQAÃCŽMEÎÙ'¢æï”åx1¨÷Ûøt9½�¶þrÝ#¡8òyU
-�÷?ÓÚ†â¨åøxv&÷ÌGëy>‰©¯zü¯=X“½kãƒG7W.Ú¾ž"´èPÓÅŸ–æ½Þ2Ú¢µs7w$˜Ñ»G�·¿ïGƒ›ÏtÔºûÆ}µÔ¯•Zþ?c«Ö0¸ŽÊ¨l¶:Þ³Èz`‚µTiê\h�‹åR€<ÕÃìj’:+y⊚ZÒ
Û‚	Ú¡—'ªKcXy–ÞU'½Üˆð±*!*[*9¥^n5ãö̱ǥ®–§ø¦WCù�;!ÿ[•‘ëF+'|ïtOhó�/�uþtz…T)}� Û“2_™¥×uÍËjî.[àP¡dxl9ýQöçÜ/Nš6YÍÃ#$‘Ð7ÖªŽmל¯„ÆØk8›c:î³#q�6ïæ­¦R?A
KëÇtûêCË,ýGv\ÌŠ~¿ÐtÇ#ƵL\úÊ:>¦~¨Ãº<ñWèÔ¤hj0ì¾PUbÿaŒ:/‹*P´ßJÞ¼zXZßx|—ÝvÎAUNI÷Ü–YwlúÑåѲLYå—ëüÎñ2cÎóúýç|뾸XE@ɹ'†ŠÅ5RïŠ{Csžù÷ôŽmÐè’DZgŒE…Ï-ª¾ÓÞ%’áË]¢›m»iuÝêæš²ÂÝÒ¹µNëß	q8ÔqYxÕÁwWGIï“öqê2âÅ«„“Ë]¾Ö§s‚zCZó ôp+dÑ×äÔîÏÌÏ•t_ß9¢Jnì¼Vžÿ-k¤N´Wï›Ã‰ÎgùµÏÂlfÝûàJü§ß¤ÔðÇ΋[“®ö~>ºfÿ…9‰EO*fȉU=¼yæ
O²"TSëØsQþ_ࢀB
ËqÓÈñ4Êo‡
-Œ”endstream
+xÚíRiTSבª¡¬2©¤j=,Œy5„„ 
£soÈ-ɽôrID¨¤*Ë"6ºd¥Âª"P”Zb^
'Ò*Â#,ŸEªVEÀ©¬««ôgûë­wΟ³¿ý�½¿ó�Ms‹”1D¶
ÆP‚Áar„ P*•pØ€<³Ù-‡å‚¡ArŽ@à´jÀ]
Ø|!o…�ǧÐ@ –®Ç‘T
<é“$>i`QÈQ •*XCÖPÈÕ@†)˜Ð3�H­k'od€µpŒg“Âá
+¸</ Çq¹žBñ@6 (ë
+åR›ëFßsØt�r “ÂÙŸ¶ØW&“	g/ôºSaVïûºãüZšÃ¥¿Ìì¦ÝŒïöH
+rKCc%Ñ£ŽV:)j¨}Cj¨ÖpCÛºV�z¡ÐÒ°¦À)­¡‹ë[ÂIoÚC[›2þ’öë’3Ÿ$=Þ÷ìµ�Úú@‘ífåz|F¬§÷~ÿLÏaz›j{õ3“[¼\õÅ]BäÚg·ÊЮù·ÿ@N˘Ä	®ç»Ü8ò™»™K¹'×ì­ø—t�ç×ͦ݉b�• þ"úá@Õß/¶ös“ƒúRÎDÝô¼T×x¾:ȹ®pf’©98¸zIól¬w0`¾›ŸóBŸ¹¢DKPí4_èÑßW�ÍqâMŒ/:&ô:ÐóÂgè‡ÒhSÓÈa¯Ey¶C›¤ídÞ�Zžíý‹Í¹ðº}—wÝ	Ó÷ó–í…¢rkö¦«
¯Ý¦Ñ?ÌÙsTÐð�cS‘sö‰¨ù;e9^ê=Â7>]No§­¿\÷ˆp(Ž|^•ÂÄãýÏ´¶¡8j9>ž�É=óÑzžObê«¿ÃkÖdïÚøàÑÍ•‹¶¯§ízÔtñ§¥y¯·Œö†híÅÍ	fôîQãíïûÁàæ³µî¾q_-õk¥ÖŸÿÏت5®£2*›­Ž÷,²˜ A-Uš:äb¹ Oõ0»š¤ÎßJž¸¢¦–tö`‚vèå‰êÒVž¥wÕI/7"b¬JˆÊ–JN©—[͸=sìq©«å)¾éÀÕP~cÅNÈÿVeäºÑÊ	ß;ÝÚ|çË#E�?�^!UJ_'Èö¤ÌWféu]󲚻Ë8Tè[N”ý9÷‹S†¦MVóðÕ’HèkUǶkÎWBcì5œÍ±÷Ù‘¸Î›ws‹Â¨ÔOPÃÒú1ݾúÐ2Kÿ‘³¢ß/4Ýñˆq-—¾²Ž�©ê°.O<Ä:5)š»/T•Ø£ÄË¢
+í·’7‡
Kë�ï²ÛÎ9¨Ê)éž[Ø2káŽM?º<Z–)«ür�ß9~AfÌÙ`^¿ÿœoÝ«(9÷ÄP±¸æ@ê]qohÎ3ÿïÞƒÞ±
]ò8öŒ±¨ð¹EÕwÚ»¢D2|¹Kt³m7­®[Ý\SV¸[:·Öiý;!‡:.¯:øîê(éà}Ò>N]F¼x•pr¹Ë×ú”bNP�áaHkD„nÅ‚ìW÷59µû3óóEe
Ý×wŽ¨’;¯•çÿ„FË©íÕûæp¢óY~í³ðÅ›Y÷>¸ÿé7)5üÁ±óâÖ¤«½Ÿ�®ÙÁaNbÑ“ŠrbUožyÓ¬ÈCÕÔº
öß\”ÿøŸ( PÃrœÀ4r<�òÓ¡Œžendstream
 endobj
-1441 0 obj <<
+1451 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2728 0 R
+/Encoding 2740 0 R
 /FirstChar 60
 /LastChar 62
-/Widths 2729 0 R
-/BaseFont /KGNLWA+CMMI10
-/FontDescriptor 1439 0 R
+/Widths 2741 0 R
+/BaseFont /JEWILS+CMMI10
+/FontDescriptor 1449 0 R
 >> endobj
-1439 0 obj <<
+1449 0 obj <<
 /Ascent 694
 /CapHeight 683
 /Descent -194
-/FontName /KGNLWA+CMMI10
+/FontName /JEWILS+CMMI10
 /ItalicAngle -14.04
 /StemV 72
 /XHeight 431
 /FontBBox [-32 -250 1048 750]
 /Flags 4
 /CharSet (/less/greater)
-/FontFile 1440 0 R
+/FontFile 1450 0 R
 >> endobj
-2729 0 obj
+2741 0 obj
 [778 0 778 ]
 endobj
-2728 0 obj <<
+2740 0 obj <<
 /Type /Encoding
 /Differences [ 0 /.notdef 60/less 61/.notdef 62/greater 63/.notdef]
 >> endobj
-1429 0 obj <<
+1439 0 obj <<
 /Length1 1199
 /Length2 2269
 /Length3 544
-/Length 3059      
+/Length 3058      
 /Filter /FlateDecode
 >>
 stream
-xÚíWi<”k�2e$[–ƒxÈ2Â,vSÙ
:a4v*cæ™1Œf±d�(N¶²´I–Ù*E‹%ÑbJ¡¡T”D)Ê�z:Õ{z}{¿½¿÷y><÷}ý¯ë]×ÿ¾î�º
-ž kIfúƒ8&ƒ£‹A¢±€-ØŸË&Ûuw€T®‡H À�WWw¥qèà².h͉“aCä@>®
\À‘ÈôÐ
-¡AȆdS��ƒÒ‚Šµe�­™Á‹lø¢~64H‚‹D-§aƒΈZ¢Ðä¥öÈÜ”ƒÊlþ€LðŸ6*È
ÑzhS´	
-
*#@œßË$mÞX³¯aB¸îËûú­Fn3_¹Êð4ºÀ0R°ÅI.茂Aá´IN¾
þn€YµÏJÇ•É™
-¶iÆáA¦V�ÈÕ’RI’‚ö)òo�¶8a×¾_ƒèœD·Êg”Ë+xmyËþ�JÅŒ—º™õ=IB2S:nÃœ÷«ÑPg˜‚REq•°óh¯–©Ì|„³==Ö{Èk²A&ìÏÙv­îÁ'ÍmÞ"uof¥ª%ýzzoX‰Æ=L¶ƒsjÞû+x�1Æ6Ý»¦7P^O™?Ç)6ܦ¿3d@§ã‚"í]B“•öÑõ縯ÞÈ%zî­Pm)‰)/™h.{Rx¯VKóRCéÑBóþfQI~c³�4t &_?©¯ð”shMž³Š±1Üb9o•‡Ô#ä�=í{Zî¸ÒǼX¨’E J~;®-£M�}Ù=Öî�¼0!Àü†Î‰®çãžתO_ó"¬S0Wsa“±f˜ø­JmR¨Âº¤Ò»#_ùš®D;GªQvÿ…ý°Q²êÝš‹G›ÛŽí™’kÜ÷EDª7eÜ]%Zá+â6“èÞ’ôö‘Ïø…L
�MoÖÊɈ3“X«³»z½dY-�
-ѯÊ÷ÊE5’šzˆɅ7Z”ñ"ÆVr/£Ç‹ÜMøïw¬‹8Ž2½+Dímd5‡5„	ûø½Ý•ðÁìd—ÍF8�
-·Ô¼Ã
ç&vÄ;•Õ
e½Ú;ý$$ãu-ÿD‹_d¦öäØ>ß[oxìþŽ|÷°ü«
íÊÑ6ÎKÈêmùâçiàùÚüRn‰Å´Ü�ŽQÜäíwVÉŒ\ÄUÞÛ TRšp(™³`òÇya‡¨	e8qŒ¿ï©Plªæ”‘@»úxqú£¹û+›Œlg½ëEŠzïìÇ�úÊ�‚U„{ÎV~
-°g>Aæš­¥:÷wP¸8ö®�TÔû /�Ó k&®³®c¡3pu¡ªüØÂAž¸Öu¯ó*3á¼ò¿žï?jiØÅQx<sÑIE4šüæxvf.
›ýÂSÓûc,îñµ3‹0špÐkÆ Ê×*y,Ìf^¬‘¸(ý
-‹»Ê�üx:Õ·DR±÷Ï?UûíLð lãÕѾ¦…Á­:ûZcýñ·ýg»kØ_äÆ­FÒÊ1cñØüòŒ¾‰�‰Q	ÞëV¬ó¸$¡
-§˜LŒ4&ê>9XѱçØ®�2Œ�/•ûÛ‹ÕgõOÈÛe‚c̾ө8º?ú®wFRbÎ.xM(ÁïH¼Õþ~áwß4 6#Ä»R•T<øc^¸®g„OðŽQ6•lÅ�èüe”sL"N6˜�Ÿl°Úãô Î²4üÇ`÷Õu9�òY yc`v£ê®¾Šp¿ÐTѨß6‡[¸k§2§Š9öjí²«
-/#J®8Å?7Eź̿´üP¼�.Bž^Þå+^d…íìN‰’O¬.`H
-×ÏTKÄluÕ¼±†*‘5–aAË1Oš:ÐLv)ôI™|Tr^PÈõêâœú¤�ßà%Ù©J¶PfÆ»bcšö_ìçÏs[x[ÇpÉÇÃ*•K?6®ëö¡öhÔ‰š­…—s×lÌ,®ÅßéSIê)l—Eÿ—üÿÿ$:Hdq˜ÁDV<Š²¡ÊÅ3ø¿
+xÚíWi<Tm�2e$[–qÈ2˜±›²�­'ŒÆNeÌœ‡1Ã,ö-¢x²•¥M²ä‘­RT¶D‹‰"B£=¥¢�²DO½G=Õûôúö~{ï9Î}_ÿëú_×õ¿¯ûÃQW!u­)Ì@ОÉàèbÑà…rÙDc‹îV�Æuâ�è
+Âd,›
Œ�ýwàŸ;$P 2ið‘üd‡Í õÛÞ™ÄaAQ€�Á`
Ìâûcµ
>\
+“A�þéîB
+
=owo¢öRýÿð´±a´ºXS@WßÔÀbá>ÍŒ~eý¡Çw-¾Z	$èïZ1?)�T&`ö­%XËïmE€,6<«
+Ñ£—ˆûÕÑüv!þ¦ûþÆnÍ ÑA@«ÿͱí¡(�B€8ä o³ó]nÊ×
+˜lhñŠÃ!FØ_0÷ ˆÂ
+®ßÕ2wÊZ!R÷ÙMƒNc�™/\eCd&]`-Øá"rBÁ°dÚ4¿O貨ó[î¼\ -GÁ.Ó$2Ä̦½RR*URÐ1]þúÌ&Üêw«P}“˜Nùܽr…Å/m£¯:¾U©žñQ·°½!ILcJ'®›ó}þ"Ü¡ T]V+ìúbHËLf>ù�«#=Á
‡¸ÍkÃc‚“wŠl¾Øxë£æf_‘ÆW³Rµ­’
ƒC—mD�o§9 9õï|N˜àÚn\ÔŸªj¦ÎŸâ…•m6ØvW§÷Œ*ómr›�öÁµ§¸Ï_É¥xï¬Ví(�¯*Ó^y¿äFƒ–:ö™†Ò�…öÝí¢’üÖv!iø@M¿|T_æ-çÔ™6g�7Úd=oSˆÖ'ž<î\î°Ò‡ÂbD¸’U°JQ�}Wv—û¼g‚Ã9"eá�üËË:GúOx¯s^­>-|ч¸v\À6 &,œ°ƒÈ«5Úäp…5©Ýc_øšî$gšqÞș݈tQŠjwýÙƒí]‡b¦äZw}‘JŸðÁÔŠVû‹x̤xv¤¾¾ã·	ùY!GÀkëÕÆûò³-dî®ÖE84]*G×Iè‰Ôùèµ’Û#Hi%—;”	"&6rÏâ&J=Mùﶮ‰:¬gÖ-DjeµG´Dû¼ÞžüÞâh?þc{�j�ŒÂýA§&�¶í%¸T6>É}¾sú~XöËþ‘Ž€èíÉñ]þW_ñØ#½{øžEM-=Êqø3§%dõ7}ð6ô~iy® Üê)FîrïûÉkG®¯�;k_sc�PyEò¾4΂駅�bß(#ù¨Cü]…24§ŒzÔ'ʲîËÝ\Þfl7ëÛ,R:t}·ý±� Ü°–xÃÕ&;@
ñÈ/ÄR³³BçæVê÷»Î†ÖF+ê¿——Îoѵ�‰ÔYӻм²DU~|a/O\ë’Ïi•™H^Õ_�w´6êç(Ü›9‹GÓP­¦¿9_Fœ˜ËÄå=õÖôý�@Cz}Ä΢Œß8é·cõªV+>ñZ˜Í9[/qV*ùò9ξ‰!ùáx†¹¤âПª8�8˜@Äú¦Ã-L+ë�ŽïµÆGî&9]œ¨g–¿�¸¡PÔÏb&â	EUÙÃo>¤Ä&û®Y¶Æ뜄**6}3Öš¢|ouoÌ¡íw+±2<¾TÁoOWž48"ï�Ž3‡�gØÓ1ݾ٩)ùÛ‘õáÄ€I6»G„ou¿jAmD‰÷g(Ý]PñÞˆ}ê¾–ù†wˆº¡Üœ0¦ó—qþ!‰DÙPZV|²Å&ÆåV£uEäŽáŽ¦5ùÁò¹ e}p^«êöáêÈ€ð+ÑØß6FZyjg0§Ê8Žj=²+JΕ¡Ê/¸$=6ÓKp›fý¾l!K„2½0ºÝ_¼Ô×7�+ŸRWÌ�2Þží—E_Mºw9hcîêXf x›dôãÚe¹þÄÚ¿
Lâ¥ýŠ‰W+%Íånâ)¿tèg-?’Œ€,zºÎÜN‰÷'áucFÝ--®t:õ‹n¹Ðü@w Ò9£Vbñ@Ô»AØW&?੯04shç/kž™Ñ™®jR»9žsQ=ÞËãB‡ÚÂ,¯­šŸé϶uâÝ©{�áל%L\,Z{ÒÒøáŽáQ°°@ÜÒOÀ<ý^È™œ?[k�ëŸ+:¾k0“~Ò„ngZŠpÐ}6ïNÌÝ�kkÈR¢D|þcìxˆË‹O
û\fqùÌë…1^ûó-ÔÍó1{Õb^²óHäËÖ"M@[®Éo÷m6ô¾fŽ	>�Ì.tëúÔÕÓ$1ð–¯íÙYåz£)5ÕgÁþ¤:—uÒÂ*¥ç(å’ ¶ÂWóÆüÛŠP4qÇHɲ6VŠÙˆýë’ÏíždI½T|€x#¸1M
l+¨sj“ÊqΦ‘Ô×õf욶è›ðÒíã*ÖxõMò2ПJJd¥Ì_b#JÂ�jç­Ô5	Ž¾wŽ·©‰�6mßðDM)ó„Ý
H9¿2g«FÍæ
+Ü‚
+QSDñÁë¨æ¨BEÞÎlžÃ�B¢ÀØã¶c¤£JÍáC2n“
+TêÍ9˜+‡~°/ÿÐR?§§ühó¨´Êë,�G§‰Ç¾è¹úÌú»Š•‹yFxm½ÄÙc5°ã¡à-w
HK�<½ãbWž¡YPhÌlöGÞ.·	»ZPâ.×QÛÄJóÎ'Í»
sý'”r‡=_FEº]9v«…·r®"3]%u‡šeˆÑÓàÞ£Zç“jÆù¨‡(E½ã1rõ¬ð£©æߟ0E�·½‚#½öE‚åq¯
+·¤FºŠø8„Gx=EvŠÉ?UÜ©±e�õù‹Ù�þy—D+‚¹ÅV ´õ…>Þ¡‚ú÷˜iY¦ôNÙA=Og
’�çý“’·¦Ò0ïiÏ=æS÷U¦{Œ	ú\ÑÂ5«ô=ªÕŠë·E%„·”UÆ÷ïôüè.–<‡9Á­ÿøðVá
 endobj
-1430 0 obj <<
+1440 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2725 0 R
+/Encoding 2737 0 R
 /FirstChar 97
 /LastChar 110
-/Widths 2730 0 R
-/BaseFont /VWHTWF+NimbusSanL-ReguItal
-/FontDescriptor 1428 0 R
+/Widths 2742 0 R
+/BaseFont /XGUTXS+NimbusSanL-ReguItal
+/FontDescriptor 1438 0 R
 >> endobj
-1428 0 obj <<
+1438 0 obj <<
 /Ascent 712
 /CapHeight 712
 /Descent -213
-/FontName /VWHTWF+NimbusSanL-ReguItal
+/FontName /XGUTXS+NimbusSanL-ReguItal
 /ItalicAngle -12
 /StemV 88
 /XHeight 523
 /FontBBox [-178 -284 1108 953]
 /Flags 4
 /CharSet (/a/c/n)
-/FontFile 1429 0 R
+/FontFile 1439 0 R
 >> endobj
-2730 0 obj
+2742 0 obj
 [556 0 500 0 0 0 0 0 0 0 0 0 0 556 ]
 endobj
-1353 0 obj <<
+1363 0 obj <<
 /Length1 1608
 /Length2 7939
 /Length3 532
-/Length 8790      
+/Length 8789      
 /Filter /FlateDecode
 >>
 stream
-xÚívgPTݶ-HPPÉIhrM‘œirNlèZº›,Q@¢ 9G%#A2HÎ9ƒäŒd� âC¿{ιõ½óëÞóëÕÛU»j¯9çsÌ9æZµY´tyd K¨"Â
ÍäåЀÙ[:£tÁj<²8pk&`a‘CBÁhÂAŒ†>B!
- ³‚:  
-uû
€¡
-	sDn³jÉ+þÅmFÿÎ�‚ݺ
ëÛHÂÊùwI|·0·^4怠¡nèß¹,¡
-a%ð21%	]F‘Ñ5 ÿ¼­ˆÕè˜÷Iï}¶ïGD³Obð²hÑ‹ëÒ@ÞÊ¡g7uî“;Ž?×U87zZÈálÍñЃ,Z/&ŽÖìG¬
"\þ|æy„I»†áž‡jKØ&Oø
6V´uÌs¯ï>jDâ~çðerÉö%e>w$ò¶J¨ˆ$k|X‰A\–³³Ëóõû9[GowWgó1Në:
Wz$>‹˜6!k˜¯S:�”‰~‘g„e.0¦ãclKP«>»àÂÌ1yÕ’ ÀdÿS¡Õ¬çn9´éçï©|e>·'ëC‹›f§—ЛÙq€úYšµ«„8ë$f
ÚõSëÁ·RÞoÛ@*¾«ʹAÔguG…*|«eB‰;}ƒv©¢]ùßÖÒï6”�‡yÛ}sx/Gj¢T«$Jñ£•H
âQ–®‹B~RlEÛ1w.ì*Çbr|¬½}$nÖ‡·Gs]> Ã?V1ò�x£+w¿³\õ9’e‡Ð†ŠØ¥ÍäÊv””7œœ¸äN­Ñ÷«/ùŠö.‹ú…&Ð)âá0äPùÝÚ…k¥èé¹éÛR§ö
-^8³÷&sݱ­|&éŸî#6cÕ¯‡‹úœ‚œEë=öÚÊÔïƒ.Œ
}(pÚéc8hXÔêëeM±¸ÄÈpefI­|š
-8xÏŽo‚¹
Lœ¸
-R!ß1Âr<;Þâ
$ûg2³£§Ä¯Cǥs‹©Ï¹å‹E#‡„2‰ó9[ª«eÖb	äBñÇ›;qäë4‹¦y,'�X
È.ó¹^Ûû¾çm}l3S@+'éY“W[ZTç¤a�y þR#ÁWeôùì¯w<Ààø!ËêHô‘ªÝ°a2Y'ŸxVc[ЃÖ̺«P‘�|m÷L¨3X´•¢|FSp	õ6!wˆ¥qi­ÍÖ)/)y4ž^ÉdÏ—“¦'»À+Oð+Wë³Ã�/HŽõ°8³:̨%¾0€°nô™¦RºNSX)šÄ©wo¸Vá"n®¡U®�uë.ýe‡°ƒ5­†�âÁ„v0äÓ=Ì­²Ðµ”ž²­ÔÂtwï‡tKy…‰	ö€À›Á²Ãí/hÆnfÔÛYÏß35|\Ã)͹b€½^s$�QÛ<.'DÑ
-(^‹òp߬h7š” ~Ý¢ñí‚…Ë.^,°�‰ðzÈî§D€×û3ÊZú’|JRA.KÞ&[å�/0õî¼2³–ÛOy«ó�CúÒB«e€öžt‹:¹ïäCA2µÅËV‘ÀP½'Ûz”êÅŒ~,ÁÑ’ØAkQè
-
Çö7=s`[šzþáÞ•M�åME÷¿€uG–h‰+÷ÜKI•9º¶Z¶ý3h#`+]¥J¢æ·šõ¬¥¸¦4G‹Æä5ÍɦŸñ
¨/„~
2…°ëIš%ƒR*µÈ¹ï¥‚CSž[çm•&ê�,œ^ˆ®ül™ò‰0¼3F£!âù2°gáȺÝYzñ‚Ä^˜X@°æ¨Í›#díQ�¿¸ ˜ßÈ?'ty…Š,ÿˆbx_¸Âæ••ÌDC«½¬}�F0j|{¯Õ\þ˜ßsžù¬—}8$QŒáinúAµ$o<½öR•eµ#�"Uòe¥rÞ‰KÿñÃ=Û`GS"“H®bʘ#6W?³æ—å‰ÖÎ+ëíø ·¯ô–-ÝI{ˆQe
Y:BøÂb¢÷‘>:_/!€ÐéË@íáÞÑȬýu¢‡3èµ+òLn¯óqŠq`Uúm�ò'ÄaeG-
-óŠW¯C鶰€®ô
-„©ÊìiÝÇ.h™³
6'�¢È6
-VÍŠ2Û71sz8o+VPÚ^­M£õ‚¨‰J®ÆÕe/ýéœGÎ>Î
-òÎqE„¹¯øç*+nû…Æ—²;OeŸöY:«*š“ïgœò'\Ý7"µkûl‡ÉqèËÑÌ'ð9‘Tgeix¿qVV^­ÐÅnOiêlÄ&Àh1ÿ¥n†	Šo-R’È!î±~x“ýè‘·ÞøyoÏõÏ4íÙ{¦Å\4X²‰¤÷•�Ï´±ÝÈ/å�µ½¸N%{’;4u)Ç!‹=íè¡ç"Â3¬¶Ðœ�š®`¬õ<xö¡Øà
- 1±#-@ëÓóÄ<ì¾âæ©)[‰Ø“9QuC—̨é-ûFæÉ€?›ëþYû|96£àj’òÖåUNºnî…XÓ°‰Ä·ÏGÑÅk'uÁêFd×É>0¼f»åæ6ç-#vƒl|¯göÕšŽù�í:qÄÔyN¿3-y„¨Å–UÇâ${Læ6¬ÆÚRøÉ™¼ó¥?"áZ¾þþË\øQ>È”	§{õîû7l]
-™mÜtW?e‡ÌŠØÇRXÝŸ¶«
qÐNøb%2t)(	æß-Ö§9¢A¸‰�Éš2žŠŸ±;Njf:¯ƒ9NÃïÊœT)š…ùïš=l“'v!V‚»ú7?êÑš\“Äk=ò†º¦ù^š-2~ë‰Uïs‘.»o¨ËªüaMfsÍ%W2b+¯ø¾
-(Ì°?ø6|Kú‘œ™µÁ86<6zlDÌ)®VésF¢¹¦GfôZ¸èøJü
P!Hl�Æ<¼H›8ºîeg©õ/¶D-¾ú‰¤÷ ã›UêYœqáÕ±ÇøË
-*�Ïp›Â¤AwÓ'v•ù7Vš4¶¨ž+jÙÚN9dB<o¬L©oÝÌ#%páÔn³òäAH41ס
tö.	Zm½0ë¼r˜$‰®XrJJ&¼è
¢—Ë™¯`¾eM¹»3µ¤¯û_ê÷ðö�}d½)(A=À_D‰ÔôÛòbN¿Ø}® ÆÿÄ5,¢Ó�c9A7!ô{•K*J^ŸÀ~™j'÷%U­YÜ{ñ•Ý‡å]ä"Lžïxiå2¬Ž/�ï�b…U¸ƒjå×)4§"ò§ªÓ
+xÚívgPTݶ-HPPÉ™&çÐÉ™–œƒº�–††î&K�(HÎQÉH�’sÎ 9#$ˆ€øÐïžsn}ïüº÷üzõvÕ®ÚkιÆsŽ¹VmVF-]^Yª„p@óùž4`ö–Î(]°ƒ¯
ÜEXYå‘P0†pP
+G8ÚCзÿã�ºP(
+�²BÂÑ€Û¬Z
+JñDÛ‚Ñ¿s£`·n
+uƒZ|™BX‰¼LLIB—Qdt
(<ok
bu:æ}Ò{ŸíûÑ쓼,Vôâº4�¯rèéM�ûäŽãÏõg\=-äpöæxèA­3gkö£¶Qî
~ó<¤]ÃpÏÃ	µ%l“Ç+Ú:æ¹×w醄�x‡ß9}™]²}IYΉ¼­*"ÉVb—åìì²Å|ý~ÎÞÑÛÝÕÙ|ŒÓºNÃ�‰Ï*î‚MÈæë”N#m¢_äa™ŒéøÛÔªÏ!´0sL^µ$0ÙÂÿTh5ë¹[­Fúù{ª\™ÏíßÉúÐâ¦Ùé%üföC ~–fí*!Î:‰E�výÔzð­´÷Û6гßÕ•Ü 곺£�Âgü«e‰;}ƒv©b]ùßÖÒï6”�‡ùÚ}sø.Gj¢T«$Kñ£•I
âQ–®‹Â~ÒìEÛ1w.ì*Çbr|¬½}$oÖ‡·Gs]> Ã?V1ñŸx£+w¿³^õ9’e‡Ð†ŠÚ¥ÍäÊu””7œœ¸äN­Ñ÷ˆ¨/ùŠõ.‹ú…'Ð)á0äPùÝÚ…ke
+¸éÛR§ö
+]8sô&sß±­|*åŸî#>cÕ¯‡‹úœ‚œEëÑymeê÷AÆ€>8m„1œ4¬jõõr¦XÜâd8„²³¤¿V>M¼çÀ7ÁÜ&N\€*ÄJÒÜOµøï8•^Ýçôáö¼J%qõ‡  ‘®.µ&у;ìXBÒ0ÊÚcVKŸ0-SÛ·ߌG?óí·Eƒòñ(€(§¸Ëš’=´øô•ú
+y\J6.æꔋ‚œÞ»ó^eúÞ‚·V„(õb*$Ã=AÁžéÌmEé�ïa9žoñ€Rý3™ÙÑS×!÷8ÎãÒ9‹ÅÕçÜrƒÅ£‘C™Äù\‹-ÕÕ²k±ò¡øáÃÍ�8
+ušÅ?Ó<–“G¬
+hEá$=k
+jK‹ê\ô#Œ²Ô_j$ø>Û}~';Äë08~Ⱥ:{¤j7l˜ŒEÖÉ/‘ÕØô 5³î*Tô#ÛýêŒm¥(Ÿ¡\B½MÈb\Zk³u
+ÂKJ^�'�W²Ù3FÁå¤éÉ.ðÊüÊÕúìðã‹
’c=,®¬3jÉ/Ì ¬}橃”.‡Ó6Š&	êÝîU¸¨Û�kh•kgݺKÙ!ì`M«a'�x0¡�ƒÌ	ùts«,t-¥§†ìC+µýÝû¡ÝÒ^aâBý"
 ðf°Üpûš±›õvV¥³ƒÃ÷Ì
×pJs®a¯—ÀœÉAgÔ6tå„è/Z
ÅkQ^î›íF“’Ô¯[t#¾]°rÛÅ‹60^Ùý”ðzFYËP’OI*ÄmÉ×d«òñ¦¾â�WfÖòûé!ou¾qÊÜCZhµÐÞ“iQ'÷�|(D¦¶xÙ*
ª÷d_�R½˜Ñ�%8Z?Èb+
+à‹)קw&¬��š>òÕäø° DxùAt€næ£`öVk�øqvëð1']/¸t¡yô8,TÎ.a Os%/i5
+ÉzY`yÖP@-ª¤9¯ŸÇæžÓçý¤>Vo€Ì¢éªd>Í/ˆöõÏ}êY
+³¸~h—•¸8˸ƒŒFF¹õ•Šû?ih�
+vžj ×`�­Ú[­›öÇ|-…>°ë=].žàŽJ,}”›­ûÈi±ð!æÛ‹õÛ‰ÌJ«—–r•øœEk±9,ð”ˆO’ܽ…n®Ðq!páxÓ“1¶¥©~à]ÙDXÞÑTtÿXwd‰–¸rϽ”T…³k«eÛ?ƒ6òg
¶òõPªj~«YÏZš{JÃÁp´hü@AÓœlú)ÿ€úBè×@aS‡ž”Y2(õ¡r‹¼û^*84å¹uÞVi¢¾¡HÑÂé…ØÊÏ–)ŸÃ;c4¢ž/{Ž¬Û�e/HìEˆ…jŽÚ¼9CÖ•
Š‚ŒüsB—W¨Èò�è!&�÷E*l.\ÙÈL4´ÚËÚ÷h„¢Æ·GñZÍŽ<çYÎz9†CÅŸäá¦TKñÅ3c/ÕQYV;Ò+Q%_Vªdá�¸ô¿ð‘8ܳ
v4e$2i�ä*õ Œ9csõ3k~YžØaí¼zf¡äö•Á’±¥;Éb1ª"(GO_XLô>ÅGçë%:}¨=Â[#™µ¿Nôp½vCžªÂíu>N1
¬Ê¼íQù„8¬ì¨`æWn-aö­§m+´Y¬~5A”XĽh§"hV לÞ_9æJqB—¡Ìh'·ïžrs)¤<ÃÑ!]‚�ŒšÙZ~\ÍHÒzU´NÏh“[€Hái3
+�RgT­$vÊ®é�ï9‡á�׺ù§ßWŸa|…psØ´"ÀÅÑÁñgð~¸¿Õxy¿oA‹z¾Â¼âÕëPúí
+GZ÷±Z6ÂlƒÝI§(²‡
 ?Uôü¬Ë÷
-žä²�5Äõv!.[7$›\ÉÌù ö)%Ü-DÇ9øÓ\¯äͯø7F Oâ×ÏžÅÚÅ8i“£òÅf&\†

--â×6™…ÈXÓØø,ï¾ÆÇ„Ék}YÆ
ð”êA±<‘‹?qâoYêL�Áoȯü¸"‚˜‰œñµŠýVw$€ÇÞ5-M¶Ãú&š{ŸQ}2Ñ»5ãùáö¶xĽuéBÿ;¤»¥ªïÕ\rþhüæx¿Í?‚^iºÇ&‹	ÕCžËQµ
b\¸THüe%¤¼®QÕ�E²üO¥}¿:y´ÀJ ÛAHù åP¤-´á€[kN�Ô/ˆ<Í©ÁEÁ‹zHÃ('¿8/ÖÈ><ï·NZN,±$�íŽÝ\ë|.ʳ�4
-Úu&IFlµPÈ‹˜<>ê¼çO}ö•>ݧ·ðgžF±;YuQTˆ §ÿ�æ‡	¬ßôtD¤ûfP˜{s“cÞ·+J�	.>xi¾’²È¦{¹3Åš®Þ~—ÛãŒd@ãa‚äÄ·Ž„kï887Kp¥ôRXŠCãóÑ°áTîEQæü^w~@³ßG±¸½Kë3rÎN¡À�K’jùÚ
-}~ÏLcÄçt>í	ÔN$c÷¬¤úœ ú=nÆ©ngþõžåÆIE^ÕÖŠ
-!dÌFæö/¨˜õpŽI^ø©Ý©²‰µ([|«F�v/f»H/>_!üËê¹ocG¥%ÅÉs5“•ŽnÇ5¾Z‚ÏÝŸ¤±ðJ©ýšžÇÝ\UËúö¡
î[Ÿ2Êíß2û²Qx„úûs‘½¯Ø«PU XäxŠnO
-IÇ�äœ÷îÍóÍè	v ó4ýð
CihTðÞ�²° ÇÒf%’2Ž
-Oyâ|g܇;Òðh¬Ù#1|éôë6Ög²›œ·UëáÇ	rk_‹öw€º«¹j!:/œ*¼È_Ô¦¶S+³�(#>û­pKÕs%ìÛø“hj£ê·ßN
-\O–ˆuõ–.½½h8¤Ëµ[%-n&í—o{Ø,OJ‹ä k ƒ$4Œsz!¼¢‡bÃ7Ú‡vçˆemÝÊ5Hcý™’W¤uÊT�ãO³‰³7	�†³Ê;B¥È†“ŸÌõáõý"¡dËUŒtúÀóñ[í¹0!Ã<Ú—(U½›È>ä9íÁ;˜Ö€7¤ÊÞ­:À¤Õ²y£7À­ÔÁT}I”C¶–�‘Qîì¹È\·ÞWõ3›Ã½ZÆ™&ÝhÄlÊÞK\o`~~çt!•†ó(à'¤§tq	Y†¶�bëÑ4r3ÛDZëòa[ö_ó>(ÁÔE7	bO;8�<0�¹8Ô4;Õª>*ËVëu?+«h–H½~šq»x/·}$ãºÊá+¡V8|ýƒ!Ù‘`Ç©³Mò×ÎàåÇøQÝ'ï³eò^JYõžâ7:¯?¾kñs”ÛqWç®fa Š’Œý4>§ ÇZ'úy]Ü;_GdRÁú	È•†bn¥æf§çƒ\Qù²1³7›
-3ú·<Ȉ›h¥=¯`·�C-ãZ*¾•‘Û3ØJ`+>…p˜;w	cÁ¿ù\å�µdf؆:îÉVÂÊ£QÏ
-Ló¶Ú±{iC¤üD8þú�ñ7.4ß=£Nƒ~ØA�·™Y¼ŸíQíì
-;dÕÚÞùYÌú.�ëÅ3¬m
-Œ·Ò'OܧZM•�ÈkÚEä»óÔAøV¿F+áÖØ\7H”ÕÁ¬–ÞÙ‹s±
-A7µ¢¿�ï?å151"yU�F�„I×íòÏfwÊ*Q�;1WG¬ä‡üÖWG9
-dòú“¢Ï¡ã6–±hò¶þ|áç RÖ/?‚jïVÈttf=]«­mîXCh-»E²`?|(“躃Øçw¹©”]“RÉÆè·¸¿½ú‚[O÷^Üä'^m[ñ™4]aÄ‘þÖ9ö5QºÄ”ÔbcÅ‘
n"¾ÿ]½GF&<ç
¤3dRµ°%‘	”Ê.Óµ­ÉÂÆWòQmw)‡GÒDa™e¹ÔÖl�NA|¦Z–ýÒ½‹Lýƒ÷ÛE}b\ÝîL» &épƒ·gr[‹÷šßžz÷ìòdÈÄº‚íüë£-«‡Z‹ÎîpnöŒ´Ð|˨)	2xqô¦S=w¶Æß
jIž6a›�6Ä.OSy]ÆñþS§oa¶Ô«ˆÌ±â£Š51r»%ob2üpȈEÐ&â§ÜÈÕöIòÊp¤ì‚è¯ôV²í­NæçiX¯Ô²»Íæá‡A$­Ñe$D{òD¾Ÿû‡‡';,Ög¦•k\�Ü Gái3¼q¸Qþ¥L�
-Xæ"¢Úbò3¸ý]ub7¾‚夨õù-ÅsÅK>ˆ<–!!’=j‰Á
bê÷](åÏi·t9ù
-KÆ.Ha½+-Ε[å�òÿÑÒñx Ciif|-i�s \‹¦ÿ€|�6±m¦ÍñŠ =“1ä`K^!y9ÊÌßIjX÷žXHO~ûLýì«œÈF7v—")òï@µW™[zb™®ÕÚ4“*ý÷L´ªŽœ0–¯z$¹Š/‚„à{>UiO³ýE©²5êæ÷”t¦=Ä;î
-€¯À4?œt€sTeù›!4J%h¹‰¸—ŽQÏ:µ¿yÓ´(kY¸³½M>X‹–
sôqÀirÐÀ³8!ÂùÕÏS€¤Sì$óÅ­$R÷Ñ•amPÍ$?çÔg•ËŸ˜V�d[ƒ�1ËiÇO°<Ø_¥¶%y�ÐœáZ�.›eˆô¤Xþ*Iò{()õŠ_¼¾êW÷ºÛ£x}kã¾ããVÔ³Ö–I͵'EÜöGi‚õÂV;áåÏ¿Ø×6™+Ý$É�ž	{ýTö"1Ðœä5v-V$ÍlÂÞ¯«ª›
bݦ´³ã)º§ÊoS6”hLGñ…îÇ,v%¹u©I~®]%¾)Ñ}ú‚¸2¸ âoJ°]^¯ÿRÓ HmØ;Âúž
-8>Ô
-²©
-3ã½+ôÞÊ•÷�aˆlª Ïn×–OBw:ëÌDöƒ^ቃ€¸Rn¹šd¢¯ÅÓò;SÓtd®ÌA~zM“èRVt}õÚ+'˜	†4~}µ÷°}³íÚš[T:áµ%|Å’Q"èXê³ÚÎÝ9"áòç0Tw�³È‹d·¿Pô@åÉ@ÅìÓEâòxOæî¹Ã	åÏIXUb_4²üQ
¨:ù©^\õ47ãÇU¸µ&�²ð�c
óŒA«`á0Ôýµ˜—™žÌ‘¥ˆß·%¢y†.Sz¾M²hàž·ãý°óg
#$SÿçÅOÁëÏàBø[yã¦5åž Šq(OÜâƒL
#‘'Þ/ãØ«*ûü©¯ð5X1œæ)ol×Ós[2L&³d´/øÿ—ÁÿøÀ
-#Ñ{0ÒŽàÿ
+žä¶�5Äõv!.[7$›\ÙÌù ö	%Ü-DÇ9øÓ\¯ÔÍŸÄ7& Oâ×ÏžÅÚÅ8“£òÅff\Æ

+-â×6™…ÈXÓØø¬ï¾ÆÇ„)h}YÆ
ð–êA±>–�?qhYêJ�Áoȯü¸"Š˜‰œñµŠýVw$ˆÇÑ5-C¶Ãö&šgŸI}2Ñ»5ãùáö¶DăuéBÿ;¤»¥ªïÕ\rþhüæx�€Í?‚^z:“Å„ê!Ïå�¨Ú
+DЃqB[äßTœB<ug(°Ø˦×ý9J~¿|º#ß*ý2üÌ‘ÔLÉ{¾OO±ÏïùƒiÌ‚øœÎ'=�Ú‰dž•TŸT¿ÇÍ8ÕíÌ¿Þó£œÁ8©È«ÚÁZ±€,m³2ÓDŽñC£{p›®
Î>*«ic:5uª ÍÐåS;ùEÑÎÙÀ�HoÑÏWçx	×ØÄИ0uÎlPÎ5—¢ú�½»<>ÕW:‹ƒoY2’˜HJyf€ÇòTcª§Y½ªÄæ'Jçx{êI_Í[¾ÆuE^n¥ñÙ±pmËISDx°ñ¸U
+JŠ+
Y–¾^#Y%ÿ	�GpXŽÒ0Nãˆ&^-`iªiðŸ;ÐNU‡UîS’7K±Åüð[Ž�ç&“vñ�;ÁsZ§â�§u‰ö´{§¸àôò‡ëòÔˆBW
×B�‹CóáiòT£ÊÚÿ“±'ŒÒÞÚ¾
ZwÕ¢‰?UÛ.[
h‡)qŒÐÇ
+¯5�Áƒ ¨“¹Ýa%µxkÐÏ_WÃp)Éâ�üdÃS<C&�fåc—ÅoFÏT±Õ„ú°
+)è@#{ë>Y]K¢þäWOk‹à0�É
+m›Hi‘œô
d�„†q.� „WôâPløFûÐÀî±Ü"“­[¹É`¬?sòŠô£NÙêqüiv	Ž&#‘ÑPb6G¨4Ùpòã¹>¼¾_$”ì¹J‘Nx?~«=!ädœGû¥ªw³
+‡¯0&;ì8u¶IýÚ¼ü?"¦ûø}¶lÞK©#«ÞÓBüFçõ'Ã÷bc-~Žò8îêÜÕ,|¦,k�Ï%äq†Ö‰~^÷ŽÓ×™E°~r¥¡˜[©¹Ùéù _T¾lÌâÍî
+ù¡M½Þöxhá,ÿ
+áHQ þY»Bå<GJÞ,6]JOU?ÀÕ«�Uh´\ï	MNñÂçzŽùy¬˜�+߸+¤„#äoàùØÈ)ÏøÅPØ
+Û9ÔB1®¥Ò[Yù=cÁ­öâS§¹óp—ü›ÏUÞYKf†mˆ¡ãž\%¬,Ü1õ È<o«»—ÆØ1D*@„ã¯O‡¿q¡ùî)uô¼ÍÌâýük�jgWØ!›ÖöÎÏb¶wéÜ/žbmS`¼•9yì>ÕjªâD^ûÐ."ß�·ƽú5Zï°Æ溱@²¬®fµ4ðÎ^‚›M²¸©ým|ÿ	¯©‰É«ê4
+$L¦nW`6»SN™’h܉¥::`í ?ä·¾:*Q “ן”„y·±,ˆÅ’·õç?‘²}ùT{·BV°£3ëÉZmmsÇBkÙ-’Ãøá+@™d׾€ËM¥Üšô³lŒ~‹ûÛ«/xôñTpïÅM~âÓ¶•˜IÓAéo�c_3¥KNI/6Và&âûßÕ{´adÂ{Þ@:C&][�°A=Ûe¾¶5YØøJ>ªí®(íPãHš(b"»,ŸÚšíÑ)„Ï\˺_ºw‘©¿cð>b»¨Oœ»Û�ybôÃ$N`ðöL~kñ^óÛSïž]ÞÙXƒ‚AW°�}´e•!]¨µØìà×fÏHÍ·Œš’ ƒGïa:Õsg«1ì8ñÍÑ –äiöÉñhCìò´g¯Ë8ßêô-Ì–~‘9V|T±&Nn·äML†‘§ÚDü”¹Ú>I^Ž”[û•ÞJ¶½ÕÉò<
ë•Zv·yÁ<ü0ˆ¤5ºŒ„hO!ƒÈ÷sÿððd‡åÁúÌ´Jb�+"�ä(2mfƒ77Ê¿”Í
+8*v4ºÏÄ^±ûà+h5zê2¶;šÞþ,-õQü!	C$yw9†CšJO ™ňq\`±"H,Þ)T<icº ¿ª}ZþK§{«Þ®ûªè&4CSQ~åâ7ê
+QH;ǘ¢&šùŸe“ô¿žUÙ|µ°S�c0R2YE]¨
+�‡á{__bçâ.°ßþ
+LóÃI8GU–¿Bã¡\‚–Ÿˆ{éõ´Sû›7M‹Š–…;ûÛ䃵h¹0GQœ&÷

<‹"œ_ý¼ÈAze‰ÀN2ÿPÜJ"u]©¶ÕLòs.}æQùü‰iõHö5¨ñ‹‚‘öqLðëƒýUj[’
	=Á®…1Ñè²YÆHOŠåoq ’„!¿‡RÒ¯¸ð%ê«~u¯³¿0Š×·6î;>nE=m½a�Ô\{\ÄcïQq”&T/bµ^þü‹}m“¹ò
A’ü陈×O/ÍI>c×b%ÒÌ&ìýºªú· ¶mJ;û7žb{ª6eC‰Æô_è<@ÀbW’+Q'‘šäçÚU›‚ݧ/ˆ+ƒË°a
+<¤þdÑ
_IÒõ.˜ê¢Ï\9¾§é-xÚÖ-9?›
ìÐv_wóý}¾éH`…Ñ'>Êß4¬�>äŽT‹¬ÌÛúGäµGÔà…$Í	ï‚7LI›u`žUJ2ì„΃79ç¯~f´lá­ÊΚìïW5�?|¸':U—.ûrJoÇÓlÔË5áAÜçxE ³º×ا‰3Ç•ÚTñ#åKþtâ•.iKW@ö/É›ÔÑ÷ û�j&Q �¦Œ²È˜¥t°Èð§Äh-ؤ1íý b?e¾™F	Š– ÉXrÙ/&Šjz©�¨rAÁM°re.�2Òe%ÉÍ£™6"�5[¹(H4:\mdb“™[i:ýP½2“�¿Ýä÷ö0JÑ»pÕh¯QšQ¨ý±�Q�ó_»Ã7;mþã«÷Aú^ÁÐ;Óèvñ¡Õñ¥ã«*’Hóß�¹,QëtT½�}…ÁbWý€�g”ùxÔ$Ó¬GÞ×™®'}¡uÞói õ´’D§ùõ; ¼xðÞÔ¡Æ°~.
°öâ%ÅÅ4O”˜»ª¡Þ»Bï­\ÿÆÈæ 
+†ìvm…$t§³ÎLd?莑ˆ+í–«I&VñZ"-¿35MGöÊìä§7À Ñ4‰>ÅauA×W¯½r‚…`Hã×W{Ûw1Û®­¹E¥^["W¬%BŽ… >«íÜMÑ#nNCuy‹¼Hû%Tž,TÜþ0]4.�ïdîžk0œPañœ„5ðYÓë�F–?ª
U'?Õ‹«žäfü¸Š·Ö¤qCr®až1j,†º¿÷2Ó“=²õáÿ¶D4ÏØeÊÀ¿I
Üóv¼vþ´
b„dîÿ¼ø)xý)\+"oÜ´¦ÜD1å�[|�)h$úØûeGUeŸ?õ¾†Ó<å�ízznKB†Éd–¬ö…Àÿò!øÿ
 endobj
-1354 0 obj <<
+1364 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2725 0 R
+/Encoding 2737 0 R
 /FirstChar 36
 /LastChar 121
-/Widths 2731 0 R
-/BaseFont /JDBSRO+NimbusSanL-Bold
-/FontDescriptor 1352 0 R
+/Widths 2743 0 R
+/BaseFont /NDETBY+NimbusSanL-Bold
+/FontDescriptor 1362 0 R
 >> endobj
-1352 0 obj <<
+1362 0 obj <<
 /Ascent 722
 /CapHeight 722
 /Descent -217
-/FontName /JDBSRO+NimbusSanL-Bold
+/FontName /NDETBY+NimbusSanL-Bold
 /ItalicAngle 0
 /StemV 141
 /XHeight 532
 /FontBBox [-173 -307 1003 949]
 /Flags 4
 /CharSet (/dollar/hyphen/semicolon/C/D/E/F/G/I/L/N/O/R/T/U/Y/a/c/d/e/f/g/h/i/l/m/n/o/p/q/r/s/t/u/w/y)
-/FontFile 1353 0 R
+/FontFile 1363 0 R
 >> endobj
-2731 0 obj
+2743 0 obj
 [556 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 722 722 667 611 778 0 278 0 0 611 0 722 778 0 0 722 0 611 722 0 0 0 667 0 0 0 0 0 0 0 556 0 556 611 556 333 611 611 278 0 0 278 889 611 611 611 611 389 556 333 611 0 778 0 556 ]
 endobj
-1350 0 obj <<
+1360 0 obj <<
 /Length1 1166
 /Length2 8911
 /Length3 544
@@ -13552,7 +13606,7 @@ xÚízU\\kö%‚»înA‚»»;PHî®!x 8îîîîîÁƒ<$ýý¿ÝÓ·{žæm~Sõp¾o­}ÖÞ{}ûœz)
 U
1Kˆ9Pveá`e
 „8
 l)
qøCÀùÏ$AÎ@‹×¦¼Øþî›â
öùØ
-¶ü³%K7G6-0ÈÉ
('ù?Á¯ò¿0k +€‡�“�Ÿ�
+¶ü³%K7G6-0ÈÉ
('ù?Á¯ò¿0k +€‡�“�Ÿ�
 q
ýñ$X8x8þÆiÚ€,ìÀ@—׳ø“‚-ÿ–R
 l
±�­
®¯SiælùOàÚÂÍÙùÕž?èõÞ¿öV ×�@O òÊ"ÄB0Ô¶6´ý¡ZŒØƒe’«�Wëî·97rŒ=ô7V˜^e»bîÜÛwŸ³$UÇl„+
`•`¡Ã㉥bø<ìøÅ;X°°Ã°`d#‰NYë„”P/駯Øûˆ¢	R¾Kx
Ê^P”ÝéÑKL`i„CpHô�œTà‰ÉÊò+�TŽøñž‚ÏUdíýÕàçG:%Ùmƒ#RPä»géäõQOï±+:°LûÅÑxæÃe�]k/͉õJø:'º8ŸlJÛ¬žªGóy乌טò
Q�K6‡
Ñ+íLvþ˜ð‰Å16(ÎñkX„Éßš†+…¨pœº–QÄ´Ôß^î)RêÔ[W,,¨Þ‘õÉ»ãp%n×)iuGYÖÇš�Ï€ñZ¬Õˆv4¹›îµ:®uľõ­«G�ZýÖ:„<=Ÿ@‡ª˜yÝ—l:G�BÎÚOAs½À:rÁUuiw™ª�¨,w‘ʽVç±ÌwZ6ç]ºš½žWßÆe͹�„縤h£öÙ�8âØYWÑtÔ¸c}ü5æ?°5&Jt”ùËÞ
¨—OÉËÛò�ÁHÌîZ‚pr_‘\OœÅ±„4šß²~òIÝbâí‡�y"ûÊ“¬4ò�ŽZ¦¿;‚Àždz™RÑ�t[^cíÆ=ðàæ÷Ÿ‘øÜÏ•ä
=X}§^ÍóâÓÌ:Ë;}ß%[µ, ýÉЛ>µÞܱ^4AXç%ä#¬wÛ±�W:eÅNã¥S¶SÈ“�Hf÷Ö�ϦŠKuP·}.óF!Ö§•"k¯“/ågö«ÉФÁ
  ê2³Õ°"Ý ÝkÇÃñJ
@@ -13582,35 +13636,35 @@ g~nM"up^ÅÃÓíÓêè”� ,{!5ÿ8¿UËn
 Ðú‡ä9¬PjK¢!zóÙ!ñHaŸ´Þãïÿ¼£êOß,?€úVÐz¾’¢Œ¤ñ¸gTW-Š«XÑèƒðN¨PÊ94X}chAc~‡^ÅûI8Y½-°Ji¾á.˜<®¯ÇIâšo,¦ÙNì¥#ÊÍ�½ÊûÊàùk¤lùnýh2³ÒþÝu<Aíâ$FŒþ¦ÏD!þ:ƒêj%FDõŠ‚QúPÀ„´èÖ#מbG¡³°ï\ùe%mËf›‘g�'CÕ䦨Ñ)Ê$‰‡x`A%*›H«¶#Ì'å;…p‘ûÚ9ß/iÔ¤N…ï#‰yàE×Óz˜8ƒÄÛ¼êpXe€N®Ñ	†µ§r%ç˜û7¯¼Çé&ï`Foùª’׬ó›}tW™ë',4Ó‘õÊ™‘8‘À`Z*\-šðú[Ü‚J�åÕ®{i!Ux„T
û•ˆ¼‘‡ôm
Ù85û)îÛ¼e¢ý¾KµÔÌ;¨žè{ÜÈ¡¾è{´Ñe¼Žò»~!–±l�˜×R¡^n`žTG�?ÂŽÎCMž—û[©s¬ ;ZWÀá¤ì`±3iSw-iUÉCW
 ÚVâ>xj„E‹ŒwêIo³}‚üH—ã
 Örú ãkÑnT‚e¿S< ¢x
K»«-1…‹54ËÆa«÷-ÕÜ@ÚUóªîÐsL/}8ÀѶ›Ñl¡ò‰ó9È+ß©O¹È¨qD‹£RKˆ7hëÀûÚë,l³Ž[‹x³#‹³
ÆÒ4
-¶ÿ�Ú®½–ZJS•ñ~´õÓp+S!¨yWC6Æjy.Lä�“X5­^g˜Â£˜ýÿòƒüÿþŸ°°š9»BÌœí�}œ�.®ç?þ€‡ü¿
+¶ÿ�Ú®½–ZJS•ñ~´õÓp+S!¨yWC6Æjy.Lä�“X5­^g˜Â£˜ýÿòƒüÿþŸ°°š9»BÌœí�}œ�.®ç?þ€‡ü¿
 endobj
-1351 0 obj <<
+1361 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2725 0 R
+/Encoding 2737 0 R
 /FirstChar 2
 /LastChar 151
-/Widths 2732 0 R
-/BaseFont /ABTPQO+NimbusSanL-Regu
-/FontDescriptor 1349 0 R
+/Widths 2744 0 R
+/BaseFont /PKKJVG+NimbusSanL-Regu
+/FontDescriptor 1359 0 R
 >> endobj
-1349 0 obj <<
+1359 0 obj <<
 /Ascent 712
 /CapHeight 712
 /Descent -213
-/FontName /ABTPQO+NimbusSanL-Regu
+/FontName /PKKJVG+NimbusSanL-Regu
 /ItalicAngle 0
 /StemV 85
 /XHeight 523
 /FontBBox [-174 -285 1001 953]
 /Flags 4
 /CharSet (/fi/quoteright/parenleft/parenright/comma/hyphen/period/slash/zero/one/two/three/five/seven/eight/nine/semicolon/A/B/C/D/E/F/G/H/I/L/M/N/O/P/R/S/T/U/W/Y/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/quotedblright/endash/emdash)
-/FontFile 1350 0 R
+/FontFile 1360 0 R
 >> endobj
-2732 0 obj
+2744 0 obj
 [500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 222 333 333 0 0 278 333 278 278 556 556 556 556 0 556 0 556 556 556 0 278 0 0 0 0 0 667 667 722 722 667 611 778 722 278 0 0 556 833 722 778 667 0 722 667 611 722 0 944 0 667 0 0 0 0 0 0 222 556 556 500 556 556 278 556 556 222 222 500 222 833 556 556 556 556 333 500 278 556 500 722 500 500 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 556 1000 ]
 endobj
-1310 0 obj <<
+1320 0 obj <<
 /Length1 1624
 /Length2 10098
 /Length3 532
@@ -13624,7 +13678,7 @@ xÚíweP\í–.n	ÁIã.�Kp'¸kH
4Ö¸»×àîîAƒk‚»îù¾{æL�;¿fί[wWõ®ý®g­gù[Õ4*ê,b¦Pc
 ù“š#ë—˜#
 ÃÙbkþϘ
`s�ƒ©5ØÑñ…æ…ûOuþ™'à¿d²³³vÿËú—ÖÆ
 ÄÉÄ`²~©Ö_rM[S°ƒ5ÄüÒÕ¿
-úbÄÎþ/˜†ÄÄÊöOù¹ÿ†À¶¦ÿûK£þŠœM\GZ^Qžé¿»[ÿÒTy™
'
w;0àÿ¸ÑV„šþçá�¸8Ô
àÉ°pðò
ø¸Ø
|¼@ïÿÆã_4ÀžAN7€>;+;;ðòþÇïŸ'ᑲ5�šþ™u'�­é˘ý§àlâìàðÒÝ¿6ÿ%éœÿx0Ø
l‚¶85²LIOuª!È“ÔïíÂÛ×käùUA»|S>mð—|¨fm˜xjuŸýi÷¸#ϸ;ÔýÆš®+	|œKêMÅГ‡½JÛÎË´Àö¡=õP;ÒódFaA�‡]kwsLUíCÑÙD;§ÊÉ5ƒ•Kžõ•†�Ir]~VNMþÏCÚ„ýë+º¯Ãƒý]¿{vH˜²bPi]Ði#üì³HDô4Ë=è…¥†G±_$ˆMP.{¢û„¹ðþ]æR͹ÄþVJn]•¾�‹,Œe0¢Lß9$Kr
C½�Òó›õ’ý4í|zÚÙ9¥½••"�ŠX­/=ÉbðM‚|@Ag@çêð™éÑ-Û�ð~oPˆûpÛ@bòµ²œ†«ëîK”À'æé³ÀœÏÀx}ˆd¼�GþVvþC'ýs\m°¥fÍ9Kô4I¿læoÙL­ßzðâœ�‚J%EI�“
¾Ï‰:yeNšÕ<>ϳ–;ÕÄ’Ž[ö$�áwiµðmչ �ƒW1¨Ý$Ld5Ôú— Ÿ¥Å½bÓ©íßJ—xuüJxD(Q¦`¥ª8-ID'BÞÖµw‘¡GìiGá¹p¸éb|ÄkYÞÃ7S
1ˆ–Tš‘.[Ÿ$-��ë=û ožyÜÀËÛÐV±X¡®QŽÒ’ÆŠEº×T�sMCN:¯£èÐ�ve–
+úbÄÎþ/˜†ÄÄÊöOù¹ÿ†À¶¦ÿûK£þŠœMQVWJL�é¿»[ÿÒTy™
'
w;0àÿ¸ÑV„šþçá�¸8Ô
àÉ°pðò
ø¸Ø
|¼@ïÿÆã_4ÀžAN7€>;+;;ðòþÇïŸ'ᑲ5�šþ™u'�­é˘ý§àlâìàðÒÝ¿6ÿ%éœÿx0Ø
l‚¶85²LIOuª!È“ÔïíÂÛ×käùUA»|S>mð—|¨fm˜xjuŸýi÷¸#ϸ;ÔýÆš®+	|œKêMÅГ‡½JÛÎË´Àö¡=õP;ÒódFaA�‡]kwsLUíCÑÙD;§ÊÉ5ƒ•Kžõ•†�Ir]~VNMþÏCÚ„ýë+º¯Ãƒý]¿{vH˜²bPi]Ði#üì³HDô4Ë=è…¥†G±_$ˆMP.{¢û„¹ðþ]æR͹ÄþVJn]•¾�‹,Œe0¢Lß9$Kr
C½�Òó›õ’ý4í|zÚÙ9¥½••"�ŠX­/=ÉbðM‚|@Ag@çêð™éÑ-Û�ð~oPˆûpÛ@bòµ²œ†«ëîK”À'æé³ÀœÏÀx}ˆd¼�GþVvþC'ýs\m°¥fÍ9Kô4I¿læoÙL­ßzðâœ�‚J%EI�“
¾Ï‰:yeNšÕ<>ϳ–;ÕÄ’Ž[ö$�áwiµðmչ �ƒW1¨Ý$Ld5Ôú— Ÿ¥Å½bÓ©íßJ—xuüJxD(Q¦`¥ª8-ID'BÞÖµw‘¡GìiGá¹p¸éb|ÄkYÞÃ7S
1ˆ–Tš‘.[Ÿ$-��ë=û ožyÜÀËÛÐV±X¡®QŽÒ’ÆŠEº×T�sMCN:¯£èÐ�ve–
 ÿØ×@”U:W*­6=F>ŽHv	;¹ÓòRUK\µþ$y¶_beXO>j®’Zݲ<ýÑã›0Œ�ž‘Ñë9¾‰¶ö/UŠzŸ –¿72?¿y¸=Á_
RJò¦+z˜ú¥Iaã_†J8²ˆ¥àØѤњ%`G¶ï¹¶›âxHt—: ¥,¬ä“~2 üÒ€7¤64ú5¢&¦¬?p3–¨ËP¥¬T12·íu™“È~·«mÇxŸ
´�`?tƒ~èÎï{k–:šQN—ÌßZ%´’»¨²qª„÷-.—çnª—‘àm| 'ùR��­PŠ­ë,WoÕOýL° 
 ï`~óêå=Y2þÀ¸$R÷Òþ¼Sòñý*+ÿ0¥ß9¢ç<9Ã[|ÇCJÜ…šP{¼úÜ~ûÙ®H9êhèè‚»NîÝ*7®H�Ø¥/jSk­H–z´	¶�–ú‚|LxGï‰n–T”DÊËÏÖY¢º>$Àa°Ÿ’Ü?åž
 7v2Åh·dy¡¶hð&Jܾ“ÚiùÙ34h+k«ù	ý”µÂ;™­&�æÕ9?[AD•Z’ÔŠF‡_í¾QC廯}êw€Ë.�ñPQØt•É»Å¨o}åBjF6ÅhœÌ c‘Ò&
`Ìä6ÔÛÅØx	Å!CzH•º{
”ƒl*íí%2®y®k	AÝ÷‡z‰‡*5µMb+$3%ÆŽU+”_ðì}QŸ(Ԇس»s&!ÒiÏcIïlbRìb_ÜÛ”O„üú
@@ -13661,39 +13715,39 @@ Pó,h‰*Ë!A–üF×âJ ¹/D“—
 Ð+_?üÐ_MC}c�§¡‚)vŸ�téuênÉAקQ]1V/' ‹‡g^Œƒ¹¬CNöTcˆÐós»R@Êäbë#έ¯ñ–2,ÂttæF�ùrx‚9¦iœþø aÅÌ.|«fíqjëT¢A"…
’U2GÜÑÎM!͇R…Ç6Öì->žÁ¼ì`¨äY“Ûò[ÃÏùÞiæž8¦¢«Ð‘lïÛ D™ñ÷Iøáëå÷œ%f3²
 �Á‚ºùëI·ÀF»šamlÉ 7itœsÇ2? +ÜSGï˵ؓê²M½ï[!Ù_? ,#)cŽïQz0iwbÍAŠÂHÙ­ïÏ«‰�ä	¦ÜM �²Zp¯&a+
ËÙõVfäÀÆ×ÛÆ6=‰1ÊÎð3kË’éÒÖ13©Oå»8“¨�$~[�bY$¦T¡\ÇoÉã¿{£R
„L÷~õt¬g+­í;'N}þöN¿¤MýX$|è‘Åì¡ÑŒP-<â[U¿óƒ�+
Uýö¨GžAA
 C×ìÖ›P6�üM˜rzÞ	§®-.æB[&í=pí°*^‡`�G$1¨9åiÙ¢\ÑÞì“)¾ ­Ã‡¬¥¹l$É�hœ"ɼðV/—aJ…pbÓ²éö™4Ъ˂y9÷G2,¦+�`+µ…mZ@Z.Mæ»qç•Ÿqäݯ92¯›Šà1Íc/šë
-_Ö˜…ßó:œ.Rk+í3�ÒíF¢×‘|uÎûGÚQç'ÑÐ~>1ιtÂS–®Pº±WiSHA«ëŒîêËß“a¨
ê» ÙÎâF³~â÷J¥.™\ˆñ¢9ßëó7¶¿àà™?—¡YîºF0îÓfŸmbÑQR³J^8|?
éÀÒS¦xP¡кpƒ”ª®Û35Ø\Jr¤¨aÒ]É—Z½¶˜À@D’Þ(þm×Ë)ü-ÖUä;Kà´yFäDý
S}_çê
«œ
+_Ö˜…ßó:œ.Rk+í3�ÒíF¢×‘|uÎûGÚQç'ÑÐ~>1ιtÂS–®Pº±WiSHA«ëŒîêËß“a¨
ê» ÙÎâF³~â÷J¥.™\ˆñ¢9ßëó7¶¿àà™?—¡YîºF0îÓfŸmbÑQR³J^8|?
éÀÒS¦xP¡кpƒ”ª®Û35Ø\Jr¤¨aÒ]É—Z½¶˜À@D’Þ(þm×Ë)ü-ÖUä;Kà´yFäDý
S}_çê
«œ
 endobj
-1311 0 obj <<
+1321 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2725 0 R
+/Encoding 2737 0 R
 /FirstChar 35
 /LastChar 122
-/Widths 2733 0 R
-/BaseFont /BXFJMJ+NimbusMonL-BoldObli
-/FontDescriptor 1309 0 R
+/Widths 2745 0 R
+/BaseFont /MHYEAZ+NimbusMonL-BoldObli
+/FontDescriptor 1319 0 R
 >> endobj
-1309 0 obj <<
+1319 0 obj <<
 /Ascent 624
 /CapHeight 552
 /Descent -126
-/FontName /BXFJMJ+NimbusMonL-BoldObli
+/FontName /MHYEAZ+NimbusMonL-BoldObli
 /ItalicAngle -12
 /StemV 103
 /XHeight 439
 /FontBBox [-61 -278 840 871]
 /Flags 4
 /CharSet (/numbersign/hyphen/period/slash/A/C/D/I/L/P/R/T/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/r/s/t/u/v/w/x/y/z)
-/FontFile 1310 0 R
+/FontFile 1320 0 R
 >> endobj
-2733 0 obj
+2745 0 obj
 [600 0 0 0 0 0 0 0 0 0 600 600 600 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 600 0 600 600 0 0 0 0 600 0 0 600 0 0 0 600 0 600 0 600 0 0 0 0 0 0 0 0 0 0 0 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 ]
 endobj
-1302 0 obj <<
+1312 0 obj <<
 /Length1 1630
 /Length2 11374
 /Length3 532
-/Length 12247     
+/Length 12248     
 /Filter /FlateDecode
 >>
 stream
@@ -13702,85 +13756,76 @@ xÚíveTœÝ’.îwk‚».Á=¸Ó@ã4�C€àîÜÝ‚;	îîÁ݃C.ßwfæÌ:w~Í̯»n¯Õ½Þ]OÕSUû©½ß¦¡TQg3w0
 ˜ƒœmM<Þr¿‘9‚A—áâ²·ügÌ
 ÿ½AôÍÃ[&æö¶
 ›’ä-%€þ¿§2ëÿžÈÿÿ¯ü¿"ïÿLÜÕè?âÿéyþWji[[%»·
øÇ%x»e
-€¿î[0௻ÆÉø…™Ø�l=þ‹ÀuÔþ£ØãûWXbò¶)bö–o°pp²²ÿÃr–¹ÍU@3+€…‰íÛžým×´7‚mAöÀ7mÿÞÖ· vöÁ4¬@f6ö‰ðáÐÞü_Ë“ëïâÙÄÔTt”ä™þ«öoO•·I€hx8
ÿ–FKÑÁü?ñˆ‹;¸¼Xx8
-pº<ìŸw�ªª=#��·q�‘Îïü¨\óüp©oß}1Kùƒ×ŽY…]“tL›ppwK×7ôs ¿ë¾g‡„)+™FÐ�6ÂÏ)‹DDW³Ü+Œi¦v—"º'>›ÇÛâLú!)Ì?u¶,GÕNSãŠçK{–w†</lQR‡Ú>R‘áïLk¼¶tB±ëðjϾ-š/RkÜ‹F[Þ&ÑÝñRE©Ò$‘°>)”·–	~g6Àü~I±,ƒô·mGÄnK–&ø=�È«ºŒóîqZ¸yÓ
.·h¬æèú‡t~Z
ÖFX­ÓÝü8ê#�؃qØ[×ò¨BÊB
³-nÁžìtLàß÷móE¡zÍ•Hy.Jl§¼�²[–ê™hT¸®ªõ£r#0‰¼ŠW�³N»4È!øv(Õ²î)I-ÚVš©À²©`ž!ˆä…	ÞŠ›©NÊÞYqv›6¢áäc¸©+ÂÆÁC5Š“«Ñ¤^p½PûÚ¶@VÛåÁ%Â@šº+žæ›Z§EyË°cÑÛzl7ƒõ"n§h·‚¢Î)v½Œ<�Ã,JðM"iúnïð‹¦2ô1sþ”p5]p\m�ÇþJ*haû:¯^ëbaþºg‚ç�ŽâvÃû!ü^A:€c±%ónìO©µ°©#ÿœSµî‡+w+žÉe*£vÅàjYDÑLg_é�ë9wêB'³=º
-9À �;Û�>s¸ÞdþN+3ü”粋c›æŃä	ší‚(WñV9º±5±õ‹„̈Ökc2“*+vÒ÷tƒ¿­‘Ä

-<A½ë\)»g�5x´KÄÂøpLXÆÏ«?Š¹áÎÆÌmI² qr»ãŸøRì| Œ¿I5JL8*tô<FÙD)l•k0°P­ˆ-éóØ$ùÁÓ@%÷º!×R]9HÈ©Ìì@“!aÎv=ÒïkÞ˜:ì9Bi‡Ù6YÁx—ˆÓ
-_=õÛ�㻚cïY5{¼’õꀷ&AÏõyWƒŠS´16£>ÇÔñbØÞ­¤”—éíW8¬oÃüáÍ�}-ŸU¿1ÙèT´öÕ°—ìب–nïŠ�A3Y’Yù;ºY×YVð°T—¥•hΪÑòÏ›�	,	ZÍȸ�åË+á$¦Œpº_PµŠ’´sø™ÔÜzMÔ®¬)Ò#ÕýÚïAϳ‡²Dpý¼û¦ïûføFxêc%Ë´P`ñ·D?ìþfzU’˜,ÏdeÌx~
·qdœº•°öûfOd<]j½$¨•nA3¦ž•À|sE늨õnÄŠ~IÍÉŠâèÀ2v΀R(zlLµ±³~	`AW¶.žïr3ÒÀ¼Î­Ò'†ªlîE@ŠÓˆAެƔ.,k·M¸š€Úrª~µýѯUÁU4K1ÕMËâæ¨Å«Cly~>ËÒ¥Xi¢[Î秕sÖ?eÖÏf‹t‹ù}+Ð`tm sF£]®XžÎÌ�½¾§äw`Áû=�AWÝ¡môÁäYû»6jÀ*4¾)¨ÜZTKo~»U³2ÆŠ¢þ©}Ìß`ù|·q§v¤‡øш¸{]ñœ¢‘�E)v>¨»œMw܃
ž'0­69dþ¶lNKxt¤æ«sÉm<~¶i²5¾
Õ®©:ë�H7ßWˆÞ±ìqÑò̓
-ÙèyÑ·JæÛ$‹/1ŒÒÍ”“ôAB«*NÝ{)£Þþ^wê3VJq¹}‰¨C½’»ëáY°ÿo†åæwFë]Jm¹ÜÆ:BFÂRR÷6;ÏûóÎjíÞÉØÃÊïeÒº›0µí„?nÐ+~vÐW§ÑåüÐIÇ1ƒ*Èd�¦á~áTÑÖÆ2x?}ÑbZ=�ô#¥Ó�@´§,-x“lÊØW>ª«sq\/õ–CÑ`'WéIÿ•…‹ŸÙ‰9¶KÀw
-ì‚LæVÝæöÿ¾2~Ò[’´ÊSqµo-ã]Áér¬Õ�[PÊïaçîÛ×¢©´1̱O1±æ*•ŽaŒ.G!ŸRs¿Ú1ùêÄük„ƒ+|Ž$I~G½N§;´ëv†¯À!Qì{s¯û#”c@
9lίØùbŽÜtÎÇÕ¢®Ú…&}‹·õÑÐ.Þ›ÜV”h*Ññ]1¼a™Žúù²ÍQÕ£€-“q×¼“c·BQ¦×KtLµÁñHS¿B�g[!M0«ÒÏ'¯	Ò¸äßÛw/±æq?#áø.qœv–y—}Ë'ч>ó„Uœ‘ñEéKý0óàÅÓ,¨UÎPŠ/ÀÂJð«ËE<Š³¬/rŠôz‘Ú
½»/öO¥‘wQ;ÒÇZ÷¸mÿ­ÎœÝsÎD'M¹x½síPƒ�–w{n´¶GÅ"ò'R3ï+•yæQ®(»üO`üï|[ó�ÞO¯?ù®U8®Éµ«>£I_<ää>R¾Û2‚„o:ö]¨¬_ ½<û`#¿`#¦å¥7ŒÊŠ�GGSX1í·£0Àä
ñdÎqßf¶ŽéÆ+ðDÖ)s34ììÖÊ0£SípÁ¥l‘þ©¶¡ÚÂ¬�T÷oÄi&׬ØLóؘã¸_´|¤FtË¡
E
-̆ݘšÊyù�ðâÓÐ óÄb¶‡°„$–;ó'`œ-žP#P™—ï>—h~ˆ^ƒ·[¢%FQƒ†’C:¥ü@N7D('ŸÞüÊtöV!NMŸ¬›^
-Ë�ßÄñ±‚“NC³ÃˆÌà�ƒØ|°g$4¸SŠùø.›Å!jfT:j8d²Q\º �Ò£7˜‰mñÙzžÉë.·æ€h^¢QçNüè20±Ø(ôì·"›èÒc{
-ßO½#'¥‘Â=ëj[$9Çñ6nªÎ?;:ëý{Ëϲ^âˆ3³9ÅOºÆÙh­ZïÕ¿7nóå}*Gäc_‚“¢.½aW™¤EÃÒÒÔ¤Ÿ6…Ѥ¦ùdþŒ!ÐǶï„a„Ùy…8’Îc]âUó²ÊbÓ�¬¿Š·Aüɳ­mk+Ì�8Tû%M&ä…�b®ÞƨÂmüıѸL
-£X8AáÞçÈÑãêO¶0§&
z”)¬Á”·Ô ­¨Ì2H ûÆôØ€h
ãÌÉ·„Ù
0*ß‘6Lü&ÐïtDKq™L- F½E+
-(³Ô•%�^ÊL·™	�¤Æ�m 
=(Dp,Óm„þŒææà’©ci÷nÇÝÁBú_Þ‡¤NTêÕƒg1Ž±jÆy|§\�§\n6–[¯Œç¬’µË‡‰—óœ¤_Hñ	h,#;“³¬&w
ˬïéÆ%ÉN˜÷Ó®sY<�”:œ„2¹'¬*‚s‚׸k<5†¨„G"íhýó³‰êÅŒZúq¯¬·K‰H~srÅÑÃs‰wì@ðÛ>Ä©â7;?ä}°sÐ9,ǯcA¿öÀƒuÙõµ¸°ÃHj®÷2Om-�	à�V’^£ Õ†§™(Ãó•,Õœ#Ä\ûÁ¹ÌîàÀÐÇ
~%ýnç¥Hc
-$f#çe” ¡ÅüÃ;_O2ÍŒ<XVŽúª¦šÂÚ¥,Ø\g�zL—µÚW–èÎAƒ�¨c– �À’=¤à&vo
‡µiSüöYùãD`|ÖêŪé©N¤S阮�–1w¤õA&ïl�Úr?³ºwNáè")ð¼0�á·œþ8fªÑÝábŠy½ Õ,ˆåò:E1Ñ�Û8MõŽXÚsãQ�¡
-�ϵÉpªì©6ï”­¨ð0WΓ‡}/N(O‡}.„3Ù
-š~C{ëHK¯Œ›IB¥O÷­·6ßð}óǶÇt¼Ân¼Nç“(‰UU6õÂtöÇ ‹Ï[zÖ@å˜sÞÃQ+�ùóÜq,)Ü8öíŽÑvßmÛa‡-Î2A&ôn6´N„/†Zæ‚0u (vg…Ë�:´ú%#£™ÍŒaŽu‹M=IÇ{(èhÏKGfó¿ÅF#W°
¢ÒFü+Ö�­@ÚäPŒ‘ƒóéÒÆp
|£ˆbm‡5¼�G—V«ÊN2UóÄCyžBí-ùÛO	ÍsŒ@éù/Åã÷%¾~¬èœçè÷Àsƒœù ¸¹„ó«>¸¥%¨µñžˆìmDqô	'�,Z0U(A /j�¡@Io‹|?µÑn›WxŠ¥ŒëzøOxa
-·(úíVÞØV�mε™6ûì²Xœ•¨.—çÛ7
_xá’«Á;ƒ¨ƒx?¿ÿ�©Üx"}õwS‡†û‚0ÍAý¡È°S‰°�îFBDblý“L¦œí›‘!¯­øDJàyšoôŒ}ÒßÛwG´û9ª„ï°þµå±½´4ø¶ƒ;¯¯»â"yiSz¨àÛA\Û¯Ì+Öp"JV}‹Íî6åñ½B
-l¡þö†þ¹Óë¨j#Ÿ"Î'«îôã1©éTTG÷Ä_+crÖZ¸]#*ãÜD!„\’2äË̓ý.ŒuúáDÉYŸƒmÛl†›K�ç�‡ÿè�^wQ˜Xö�¼½œšNp0ðçÈ=O<IXƤ—ˆŒ‚ŠÚ¤ãÓëZ
--‘~“úlYd,K¹ÕÒ¹–zÞíª%¶
Cr§(—S¬ü”˜ZûEóça‰9õ	Š’ƒ­!¶g¬ÄŸ*�’¬æI÷œ"eÄác~ö‘#å˜�û'*h¥•¹c“žŒ^`�ÌʺÅ?Ð}2x=°�(f�Ý©Ì~—üEN§M‘62ÚB¬-µ¶¶WŒÙâýÆ­

-gP<‘¿mšÕ¢ÐsäC>”ÄÆEd,¯¦hwäd½§G×�¸áÿ)$UÛꜿn™µ†µÞt3ÜÞ*qœÊ­;©kCˆ�öq±€‹*íŽìØM3E”Y?/â¼ý¬ZóÄQÎÊ×UúŽPùsvøFðtOÃ4¾ÝÈȽ4»:W @2
r3N?é�èh�ã«·|ÒxâGëŒRøƒÑ%ßM0<‚œù`ÜǪzÝŠœê�jB`àü©>”…g¦çÕÄøËÊVá
ITY&—L-C
�;Î}Ø;R	�N
-rlM(MwV[Ú®nlõ¡hè8‰dsÔ‰ßh
-=À—|j�óîI·�³S•Þ³u?Tú/W&?g¹¾—‹œYÔ ü2ÑÒ9Ææ&VüøðZY�¨kMq³¾çx‰Zye[ç[àz´›ØÀ_Ó¼Ò1\T˜­kÎ\νª\>�Ä�Á“f¬±,¤m)L_�öA¸%Ô°ÔPV=Q3 5 ü*øã§ûˆ+Ck8î‰â
-æÍ„LåIšŽ RbBý°éag¨vxwس«RÕ/j³ý૱ …ªæ
-‘A©�wô“RbM”ÐÆY£2g{ùŒniò\èôï’Ã
-õ´©mó–2Òx¶uÒŒV ÎDM8,×zŸqwØx!ãÁ�ƒœã¸ x~ÈñùÂ
-§‘Ó/"éš¼,mì�aµ!Ò¤?Ã
-	„/%°ÂBÃçÛr%wÍ
ÚlKÁí4Ð÷Ö¬Rªk÷’_èUܤvòÄ&RYC¯[6¡ßÙc1>%:k}VˆƒZø­õÌ+"´‚/ž‰)+©¨ésH± ,›§—Ås	P}J7Ê< ÔHËíÊWY‡n´ŠŒ²¨¯3:�¢dØð�W7>ÅgÒ¥wëÍ8]íD~rZ+ŠAF§«Ùg£©,¤#Ÿ0ŸÖu¹Âl#ú¡…>è!)­"dŠ"ùN’…)ïS¾ÅÜÖr(] 	¬’6f;ç •üÝWÞ¡£È½1•X�M©X0n<å—Ù‚«Ã¼ü½�X#×’VcôÙÓz
¹ÇRNQÑÇkŠOŽù@
°ºL�'
õ6p5%ý‚[2/d^Š\”«KSµ‰._!Ôk^\N^(Žþ¢‚my;"\îÀÐ'AP&,›;’
-
-•1µ]³¯gè'WÆZÇ
-få‡ï©=‹+é”1î­õ#m¾‚h<y¡8ç'ˆ*)ýw­+É‹>éÒˆy¡–È:° F|ì\¤œÎÁƒÊí}—)~øRFdty[e+açç~µ™fÒõMžxâ(�.#ÚÑ7¾	OäOqï×UÎ
-WŠß�b·ñ�˜^SÞ4é`�»Õ8˼Š‘²ø'¦DwSþGgEØudµÆT=×jìXkÊt®›�ÄAÔï0É噓SY­ï¡ƒíA%µêkÚd韮¢OÊviÍx{~Ä÷a¶hºÎÑ#²h¸÷*HÚ±
-ÜðËEƒã}Ú…eýé>ûR7Á-“õv­Öìמo»Ø[®º©¹ÃÑ8~g«íÅßr12uR°>ÐœéêªÀÀñZ=¼Ó¼Tüa\+NB±‡ù�ñ´ã½ËP–и=¹ˆPö@š…ÁjXc-÷PõJÏ`�¿ÿ0…ž{$$­„û³ì§å�”VjùÈ»MÅð�–¡E´lySm¡$¹çs®—kp­:èë*AÄ×Jˆy>æ(
-:úÕ!m*áòêƒÀýKøUJûeÐ<ŠxVÿ16Z„€6Ò^ÒèÒ£'
Ù!’¨ü·ý_cS?f[uÅSOqÌóѦnh~6ýºú˜ËN°¾)ÄuÄÉd�ì�#›Ë¨ñ¾óì{c“Þ9¡¼ÒºFd[
Ž«AU£ãDž‹+'ÚX�rå
-Ôñg*`Ø¡éO“d-½ðYwI{yoÔ€|ãéÒØ;÷ƒ»°§c1ßm‡o'·~ª-ä+.9“ŒÔ¦×öAÚÅRÉ3‡éªæævxyO†�-ºƒJh&>.ŽY¿~NF<�B/ß%ù�S„€ãƒk+GªÆ‹*1|ŸÞÑfB“bŠ™v¥¹°ó5S!WLìíz~³3ä¾|6Ö‹ÞˆFÈ\ÿL0Ã’›¿g3eí43ï‚u“Q7¸–ã -X{èŠãé¤Ø€>c^M„Eû9O,œÿî#éò­¢í6
-Ó1Ý¡§úSßÄ—¬WÔ1XF‰×é*ø–’Ú
)‘æh¥É•kd™²ɇÄÖƼsÎKK�×Þ�¿¯�IPv–`Õ}
»ˆH"áÌçÌÉ[_ýX	vFô@.¨Gñþ(éƈΌ“IŒBE<7w‰¶%oŒ˜Ác-j‚UV~-‚€b«2Ò/6GC½ÜÏÕg¡X«ÎÛ5Ó}Ò
Ž'¨;A«8úU•Ôæ‹‹\ªt4¶ã¯ŠÄ,³µz¯Áj5å�hL±EJåÅ1‘AR_
-ĆÞ>dbõ=Í+}Nð
-²B"ó�Q7²=Ö8ú$3¸€~á·KóìeQ‚Dq÷#h¹Ç|Œ_/~MÁ„{|P1…úR?"ê7q½Ý°HÎP¯„Gì6H	t¤AîÌÔcË/‰÷¨øƒקXG$?3â;QWÛú=03ÍCq«©¬°ákß
-7Åâ±ÿ[jŠë0Þo"‡[ì ºäSŠîÎBU8Ü|ؼ.D	}¨&Ò©›Mp†óMRJH
‚ÌoOM.ÎœMñ#3D¹CáB�—jùùÃ
™˜Ñël�)æ9ìÁøÖÍ�cìBN¸2ˉ€‹Ë‡ó…¸ÐI¿¥
]•ï*
¿
-Wƒ‘~Œ�RlnbT¿þéµ.ïz¨¾Ôî
Û%ue¹ß[¼Üæ™Õ‘pA@ ÚÁ-6­½hœx½û	<¡ô©ª`GqzàK{kðóË	âò~ØÛŠŽ/È°°ˆ>XÊ	{õþæÏXý„ú\—lk@œW²'C†»ÎÎùOɇƫ\çqi¯é—OáÍö‹ŸPÆ…5£ymK­ó{ÔâÃÏr÷H†ªNš-ñ•8œ]†äë,6û5\5ùÜûżÚ4­?¢¥®À„â°.;ÁÉ`�zëAãð,ÞÓS¦Çô?z‘=­Ð©ÈF'.Î…Xç.™äÓtª²TpQär9lß|˜ÄÈ'ôJâ.-u¬H¦IÞ]fXsÃœÎxÏÁ©JaÖNèÎ~åú2{jÐIø–*g½0ÌÖ|¿#G‰ó{R¸�ë¾5of$6o°õ
¡¹ðùÎ3Ÿ“×G¬v‰Å¨[^W#šp\kû[4ìó“O´ÛâJ¿[N&îC¿ô�ꥨùRœú«þ)b¦“wàðƒ\¢^yÄÑfœ—^ΆB[„�~©’8�Ø:'u²í”èWp\Ça@OçËü’cFHø»":·Bý}ï<
ÿI=çNeŸž�w&8ùrÓG¾ò˜¢–QÕPÛo{¬­Ò7ôEtÞ6÷››ì1ò5•@ZÁñ…ê§Ðyœ|ô%”ÆPkV!úÖê@�{ôŽÓ愦O‘FÒE�’L
-"2�Òy¢ëPãôÃ�+zóˆ>Nª<ìœ'-ã”í6�ªsqµ‡Å•?Å”Ä{ôÑÂ'kOÕÛÝ0áÁÇî–ÌN)…C—âËlQ(ŒàMÂG¯ŽÇ¡<jÓH]tfÏøáÏÛäcÌwfÆ’xÅŤqFªëûøck‰�K¡°>X +Ë�ß’É—^EÄ—ÎjÍš÷Ð0#8Lœý!j¹½ìsnŽô3wt¹Y�H�ˆ{[ï>Æ¡ÑÃ?6Í‚�qpÌ»BöÌ›e‹É½qÓ‰-qu{ƒõZY
-T3ø $S±�‘’ƒÚTü‚)rÕ¬”qëuÖ´>;q<O÷hIgÞýXàê8
-í?Ù\šjxÄ4|”¹Êè
-á:ÂœÆ%ÏÙ˜‹G—Kê
˜ˆÔÌùm¥¢ºéLsk;xs¡C0ZØ®·›ë^M“uÞ/Ϭ˜Ö„
-kì¨|ýñÜË„!¯‹ðn® |KâæÞþ¿êô­È^†}âI¢jŒ›eð÷.½¤â·�J|ùN’°àaäúë²<f¼77Úð”ú«¬GÌÖן¢mÉÇn;�= …¬ùØ„õë>ù·¹¨~€Œ}Dº˜R�ô¢#Ó*q¦ª$ôPgæIÍA´¶jGózf£ò»¯a…¸ÄèĨæxÙÙ1Œ¸®þ_ö˨Kíc$Ù¹eC	ˆÔaq[Éáu»¯à¼Ì
jñÝ�òúèÎ@öQ¦²Û5ö÷ðby*æm:Ë¢õÌ]¿À<zsFkµÇ0ˆ&rê>åø\ �©Cè^{—¯‚'ïG··°† 9w­<q­ÿ’°!Ï<å�+b^�	—}Ët Ùo¾c‚ƒG
ÃÃPô=8Lm»¾
-
-¤S¹»ã}Ù+Qö’d¸Ov£�²«éŒí!çZ€/†¨F�GaâÒ<ýz:’–'‹ýÆ®
-�	™
-¿(,(p³ò�[ƒ²äŠXù*5R–R™¯‡íD¹ƒÏH
’})ðøÁ½ÅzaÜ‚”Þ_¿$b�T’“×FùŸ§îŽw&&î­ÉŸCâ-§…r–é°/�%úéùH¹àŽ_ôÜaÜæ¬ô‹IWã%F»¬´G¸9ø¼dK²ÁýáƒùQMÉ”µƒ�¦	I7U'àBc�$n7KÚÚnTt%Öd)w)GÙ8©o½*ç3iÌhŒ¿BðšúdxIZ«w'ød9ï#A‰ü@ø.
Çåçº[Œeêeø7¿%NMGŒË&òÖ{iû;ÕB…ñZÕ¡è9í”aÎfù¨eT«ºÓîë¨ðã°!«¥°‰oÄl�l'ôxs„߇=¯«ìq­ŸVÑçp±­ŠœM—¦¤Ši‹øª<~	õ+/ÿõI}�ö³s—ć ŒW•8d¥†,@ÌËö�ûñÂ{«q)©¤#ëŒ:é;l±UF©–Ý…0[„ƒ18ä�AÇ ßïÕqç)ØjP3Æ–§Ò*R«f¾Ð¾%1“‰x5\e^âù’<�‚)‹fÎ׃,P=3\áÂg1qfÑkD¸4D•žó8úiÃ�÷bdšHʾþÕÓœƒÐb½�œ×kߟŽ�Ôz,įáãŸ`†ÛMf·4HBsÊ›oÁïjŸp5nw¢2Üòب»)z‡-Ü–ÐÉ¿‹”+�Þ+züTŠ-øΠ‰5g^úŠ\Š¯`÷Ž1Ö„¥;¨„­lðìw&¼
-rUêŸ=²ñ;Afþz®ªIÈ¿¬ñCëù‘:̾íp<ÌA�0Áùâ‚©„‘ÙYQü�3
-´lÓ)OݧOP¨|ª	�”îSEzé*ÜF+¾ó)˜¢»"3Ò™m{鮪ð¿·?NüÜ÷Í€±B$mŒàpӺ퓊Ž¡\y!iºdì�×Oäpl£u)$Ç4li­þ?�&q}JÂ×ã­=�ßh0‹‘¹
ɉ
§…jM¢?ì^8Å%Ê	/´CøÆž+ù©’†‡?ºÝ
-$íòºG–6tÓ™K
-¥í>;¨Üe™Á�t¨¹éþ¿Ãæ2ó‡gê[¨òf—wœ�€úæÏ�µ4œEyý‡íŽè`ý¯sç—‰Y†¤ ÉÙ’Z/ÔB¦é—Q–¹g¹×Täe1"¾¶`M{¬BŠÆ’Z’ëõñê:+ê©5Jy¨”ëÄN
®ú\Ú>J¶R·ÕäÞ»5²ÿ?(ÿŸàÿ	3[ 	â`g¶Aù?²²¢[endstream
+€¿î[0௻ÆÉø…™Ø�l=þ‹ÀuÔþ£ØãûWXbò¶)bö–o°pp²²ÿÃr–¹ÍU@3+€…‰íÛžým×´7‚mAöÀ7mÿÞÖ· vöÁ4¬@f6ö‰ðáÐÞü_Ë“ëïâÙÄ>kiHJ3ýW7ìßž*o“
+òüªº|SC7ùË�Ÿ«ƒXëÇ^[<æŽ_väw»ñm麒�g¹¤>T=yXk´m¼L»_Ù‹ÑÓŽµ"½Îg6àtyØ?ïþUU3,zF oã#�ß1øQ¹æùáRß:¾ûb–ò=¯³
+»&ÿè˜6áàî–®oèç@×%|Ï	SV2� +:m„ŸS‰ˆ®f¹WÓ6Lí.EtO|6�	¶Å™ôCR þ˜êlYŽª�¦ÆÏ—ö,ïy^Ø¢¤µ}¤"Ãß™Öxmé„b×áÕž}[49^¤Ö¸�¶¼L¢»ã¥ŠR¥/H"`}Rþ(o-üÎl€ùý’þbYéoÛŽ0ˆ#Ü–,Mð{" ‘WuçÝ>â´pó¦\nÑXÍÑõ#è&ü´¬�°Z§»ùqÔG±ã°·®åQ#„”…f[Ü‚=Øé˜À¿ïÛæ‹Bõš+‘ò\”ØNye¶,Õ3Ѩp]UëGåF`-x¯ g�vi*�CðíPªeÝS’Z´­4S�eSÁ<Cɼ7S�”½³âì6mDÃÈÇpSW>„�ƒ †j'W£I½àz¡öµm=€$¬¶ËƒK„�4uW<Í7µN‹ò–aÇ¢'¶õØn0ëEÜNÑnE�Sìzy‡Y”à›D4ÒôÝÞáMeècæü)ájºà¸Ú�ý•>TÐ,Âöu^½ÖÅÂ42üu/2ÎÏ):Åí†÷Cø½>‚t
+È8u)*`í÷ÍžÈxº(ÔzIP/*Ý‚fL=+�ùæŠÖQë݈ý’š“ÅÑ�e윅
¥4PôؘjcgýÀ‚®l]<ßåf¤�y�[¥OUÙÜ‹€§
ƒ†3<Y�)]XÖn›p5
µ'äTýjû£^«‚«h –bª›–ÅÍQ‹W‡Øò8ü,|–¥K±ÒD-¶œÏO!*ç¬+~ʬŸÍéóû6V 9ÀèÚ@æŒF»\±<�™{}OÉïÀ‚÷{ƒ®ºCÛèƒÉ³öwmÔ€Uh|SP¹µ¨–Þüv«fe,ŒDýSû˜¿Áòù nãNíHñ£q÷ºâ9E#;‹R&ì,|Pw9›î¸<O`ZmrÈ.ümÙœ–ðèHÍWç’Ûxü:lÓdk|ª]SuÖ‘*n¾¯,½cÙã¢å›²	Ðó¢o•Ì·I_b¥›)'郄VUœº÷RF½ý¼îÔf¬”âr%úQ‡z%w×ó`þßËÍïŒÖ»”Úr¸�u„Œ„¥¤îmvž÷ç�ÕÚ½“±'†•ßˤu7ajÛ	Ü /Vüì ¯N£Ëù¡“†9bU�É:MÃý©¢-¬�eð~ú¢Å´z:éGJ§�hOYZð&Ù”±¯|TWçâ¸^ê-‡¢ÁN®Ò“þ+!?³%rl; –€ï:ؙ̭ºÍíþ}eü¤·$i•§âjßZÆ»‚ÓåX«· ”ßÃÎÝ·¯ESic˜	bŸbbÍU*Ã]*ŽB>¥æ~µcòÕ‰'øÖWø"I"’"üŽz;œ$Nv0h×í0_�C¢Ø÷æ$^÷G(Ç€rØœ_±óŹÿ*èœ�«9D]µ?
+Múo룡]¼7¹­(ÑT¢ã»bxÃ2õóe›¢ªG
[&â®y&Çn…¢L¯—è˜jƒã‘6¦~…϶Bš`V¥ŸO^¤qÉ¿·ï^bÍ3â~FÂñ]â8?ì,ó.û–O¢}æ	«8#ã‹Ò—úaæÁ‹§YP«œ¡_€…•àW—‹xgY_äéõ"µzw1^ìŸJ#ï¢v¤�#´îqÛ:þ[�9#ºçœ‰N&šrñzçÚ= ;-ïöÜhm)6ŽŠEäO¤fÞW*óÌ£\QvùŸÀøßù¶æ½Ÿ^ò]«p\“kW|F“¾xÈÉ9|¤|·e/ß tì»PY¿@{yöÁF8~ÁFLËKo•�Ž¦°bÚoGa€É,âÉœã¾ÍlÓŒWàˆ¬SæfhØÙ­‡aF§ Úá‚KÙ
+"ýSmCµ…X+¨î߈ÓL®Y±™æ±1Çq¿hùH�è.–C4Š˜
»15•óò!áŧ¡Aæ‰ÅlaÿI,wæOÀ8[<¡F 2/ß}.Ñü½o·DKŒ¢
%‡tJù�œnˆPN>½ù•éì­Bœš>Y7½"–1¾‰ãc'�†f‡™Á±ù:<`ÎHhp!¦óñ]6‹CǪ̂tÔpÈd£¸tA¥Go0Ûâ³õ<?’×]nÍ
ѼD£Î�øÑe`b±QèÙoE6Ѥ9Æö
+5m;bC­Hw´Ú„ïZÒç”G¹âú'¦ÐÑWwë#säÙļ¬gûäPxXºóÃrÍcêTdøHSè;ËÒ߸P· jD€Iš}ß¾ÿžzG&NJ#„{ÖÕ¶H4rŽãlÜT�vtÖû÷–Ÿe½Äf„gsŠŸt�³ÑZµÞ«oÜæËûTŽÈ+ƾ'E]zî2I‹†¥¥©I=>m
+£IM/òÉüC �mß	óó
+q$:œ5ƺīæe•Å¦;Y=nƒø“g[ÛÖV˜q¨öKšLÈÅ\½�Q…Ûø‡	-b£q™
+Pf©+K½”˜4(n3I�Û@zPˆàX¦ÛýÍÍÁ%S+"ÆÒîÝŽ»ƒ3„ô¿¼I�¨Ô«ÏbcÕŒóøN¹+N¹Ül,·^Ï=X%k—/ç9#H¿�âÐXF4v&gY!Lî–Y-ÞÓ�K’�0ï§]ç²x:)u8	erOXUç¯q×x  jQ	�DÚÑúçg;Õ‹µôã^Yo—‘üæäŠ#¢‡5æ8ïØ�à·}ˆSÅov~Èû`ç sXŽ_Ç‚~í�ë²ëkqa‡‘(Ô\ïežÚZÀ­$½FAªO3Q†ç+Y6ª9Gˆ¹öƒs™ÝÁ�¡�ü2JúÝÎK‘ÆHÌFÎË:(AC‹ù‡w¾ždš+y°¬õUM5…µKY6°¹(Îõ˜.kµ¯<,Ñ�ƒQÇ,A�%{
+HÁMìÞkÓ¦øí³òLj Àø¬Õ‹UÓS�H§ÞO
-c>îHë'‚LÞÙ<µå~fu=îœÂÑERàya Ão9ýqÌT£»ÃÅó:zA«YËåuŠb¢/=¶qšê±´çÆ£C
‚Þz™‚$E™ÇwC×Å)UJ
*ÛJÅŸâ&™r¡$™Ú"9,=Œ�ÈüÉú¤‚×¥ö"ʼnH©ÿünæ·€‘¦'!xÛÔš £ù‡jæ•(‰âãLp
+ ‡Õ9ýÂû0½„Wkåǽ	½Ž‹Üì’o’»vÕáûî·ìt¿¢'¥pôNõ˜±b Ø—�135.Úzžùu­ZÂäÁì¼RW3BÊï9±l'5г¢»™ÍlkôÌ©ì'sã–@àñ‹Jø�ff7«Û“ùÅ×�¤«äØI7„%õÁÁ_D‹lË2Ê5‘Hz2ý&‘¶1,	QB‰&¢ÑÓ„Ò¿�ø
+—uhõKFF3›Ãë›z’Ž÷PÐÑž—ŽÌæ#~‹�F®`D¥�øW¬![�´É¡#æÓ¥�áø&FÅÚkx�.­V•�dªæ‰‡ò<…Ú[ò·Ÿšç�Òó^ŠÇïK|ýXÑ9ÏÑï�ç9óAqs	ç…W}pKKPkã=ÙÛˆâèN'X´*`ªP(‚@_ÔC9€’Þù~j¢Ý6;®ðJ×õðžð n
PôÛ­¼±5¬ Ûœk3möÙe±8#*Q].Ï·o¾ðÂ%Wƒ7vQð~~ÿS¹ñDúêï¦
÷ašƒ&úC%�a§`;Ý�„ˆÄØú'™L8Û7;"C^[7*ð‰”Àó4ßè#ú¤¿·+îŽh÷sTÞaýkËc{iiðm3w^_wÅEòÒ¦ôPÁ7¶ƒ¸¶_™W¬áD”¬ú›ÝmÊã{…
+ª
§5çüu½Y‘�›’ëÆöœç®[ëc–÷¢MÂ�x„ŠTBXƒò´q»%´oÉóNï2Óý¥Ãúƒ6óê-ç0™ƒÍOøÙ¦‘�α?e;J¿‡m³8R°ÃÛLàG›àæZ&œå°‹E㧆Ó™¹f1öH¥£
+ô¬b9ŠÉ¤‰}"¾"rß«<Ïã›ÀRéà£ød׊žçuSBÓ�»›oPF×�åK¥Çý	¿Ã
VJGC‚Ý"’UÏ|¥e
+5Ê®ü&=ßîR¯¨§þ×wóŒ”
+û‘S˶©6’ÄáQ1eøå]C»`J©,*Z²W›žoôß’«ÃÔ 6Ma›´/¯Q©¾òW°²ŒPu̵vÀyçšñjo=\œ€
ØBý%ì
ýs§×QÕF>E6œOVÝéÇcRÓ©¨Žî	ˆ¿VÆ䬵p»FT"ƹ‰B¹$5dÈ—›û]ëôÈ’³>Û¶Ù%6—ÏÿÑ;½î0¢0±ì!y{95�à`àÏ‘{žx’°ŒI/µIǧ׵Z"ý&õÙ²ÈX–r«¥s,õ¼7ÚUKl†äNQ.§Xù)1µö‹æÏÃsê%[ClÏX‰?U:%YÍ7’î9EʈÃÇü"ì#GÊ1!÷OTÐJ+sÇ&=½À:™•u‹ ûdðz`QÌ:»R™ý.ù‹œN›"md´…X[jmm¯³ÅûŒ[
+ËBŽ–�Ǩ•c´ý"X$Gì´ÃX EäZøsÒùéΠx"Û4«E¡çȇ|(‰�‹È.X^MÑî:ÈÉzN�®;qÃÿSHª¶9Ô9Ý2k
k½éf¸+ ¼Uâ8•[wR׆1:íãb
*UÚÙ±›fŠ(³~^ÄyûYµ>扣œ•¯	ªô¡òçìð�à鞆i:|»‘‘{ivu®@€däfœ~ÒÑÑÇWoù8¤ñÄ�Ö¥ð£K¾›4`x9óÁ¸�Uõº9ÕÕ„ÀÀùS}(ÏLÏ«‰ñ—•­Â’¨²L.™Z† wœû°w¤:Ý#}�
+‘'’Ž‚4rrä¨*à—Ùà‰øGi	ª�R:ËOçOe6tPóuÍ¢‘?«€›Ƶ¿ųCüF¨­H­±<-XQ¶ÖßÅ&î
×Üh“ÝÄ%ƒèxõèÑ9€¡óáy	«2^†ŒF¡ápcÞânê];Å$‹ñ“|�ðe$Ò1\(œz ¢ê˜³²‡nXMÔM•oÊTÖvNì$Â!vbȧ“@Ÿï!õÎl4,>¡.RÈÚH³Þ£#>,Pè?Æuý @åÜëì®ôEZ],Ö×g�w’\O	îÔ¤<¥s‰<~‹½³ŠBÁ8®“‚ˆyiá]¤£+½‘lD‡ª‰½¸\¢»�>*Ædx7ï1…“wäØšPšî¬¶´]3ÜØêCÑÐqÉ(樿Ñ
+UÍ"ƒRïè'¥Äš(¡�³FeÎöòÝÒä¹Ð3èß%‡
bD!wèì¢4¾×Ä!C8
ßîá�ßÚ²X]JHí
…Î1Tá*OqÕ’•ª\-–¤1ö’o;„ú ÝkiHÖaùAƒ1G
v×¢ft·�º;Éw•º¯q�ȶ°‘´ØAºëÂgÚ­ƒÐO/Ùµt0O8•I¢�Œ0±
+æq¥§>cë’®Ê`òp7£“ÊDK�¡gHOpU…m# Û=aFÆ`îÑKÚëŸ'sþ ½æ>[¢’Vò~ôa9Ijl“%b?PQýüQÈĪ—œMÙ§Ö$á�[W1I8�êiRÛæ-eþ¤ñl뤭@œ‰špX®õ>ãî°ñBƃ;9Çq-@ðü�ãó…
rÚ^êˆ;þwNo›®±�%›n¾ Cd{Ñ~Å
+Ê~FÅ!Û½§xÓ€Úg×–“Ãh‡šN#§_DÒ5yY8ÚØ!ÃjC¤I†_J`……†Ï·åJîš´Ù–‚Ûi ï­Y¥T×î%¿Ð«¸Iìþä‰M¤²†^·lB3$¾³Çb|JtÖú¬µð[ë™1VDh_<S&$VRQÓç�b8@X67N/‹ç ú”n”y>@©‘–Û•¯²ÝheQ_gtþ EÈ°á¯n|ŠÏ¤KïÖ›qºÚ‰üä´VƒŒ:NW³ÏFSYHG>a>­%êr…ÙFô+B}Ð#BRZEÈEò�$ÿ
+SÞ§|‹¹­åPº@X%mÌvÎA*ù»¯¼CG‘{c*±›R±`ÜxÊ/³)W‡
xù{;±F®%­Æ貧õ,rŽ¥œ¢¢�×!žó�`u™OêmàjJú·d^ȼ¹(W—¦j]¾B¨×¼¸œ¼PýEÛòvþD¸Ü�¡O‚ L.X6w$
+ÕÞ<°mZlÖšPgP[5ýf,ÙE|^›YÌt#GTR¼�Ï7ßááAŸ	XYO±ÈÔûÙ[z`oCj8½¢CD‹[@Ùã4GpMÒÿ…™u^�'úªl¨Zû»:J(k™U1>ê~ÕX�ĉeÒ{˜s!ÎÓ´À�ê³{8ÙS¹~/ZŽ„%¨
û1T3z®ññõA2«‘I@FôxŒ^ô—
+ËúÓ}ö¥n‚[&ëìZ­Ù¯<ßv±·\uRs‡£qüÎVÛ‹¾åbdê¤`} 9ÓÕU��ãµzx§y©øøVœ„bóãiÇ
z—¡,¡q{r) ì�4ƒÕ°ÆZî¡ê•0žÁ ÿa
+=÷HHZ	÷gÙN1Ê;)­Ôò‘w›Š	à!-C‹hÙò¦ÚBIrÏç\/×àZuÐ×U‚ˆ¯•ó|6ÌQ
+ïR�‰3wЗÒÉ_‘yVw¡UM¨õ(ò
+"¬8&þcl´
=<l¤½¤Ñ¥GO²C$Qùnû¿Æ¦~̶ꊧžâ˜ç£MÝÐülúuõ1—�`}Sˆëˆ“ÉÙ;G6—Qã}çÙ÷Æ&½sBy¥u�ȶV%‚ªFlj<WN´± åÊ
pŠšÚQâ'¶‡xÃ\Îêã~û]CGªÔ
'¨ãÏTÀ°CÓŸ&ÉZzá³î’öòÞ¨
ùÆÓ¥±v"î-waOÇb¾ÛßNnýT[ÈW\r&¨M¯íƒ´9Š¥’gÓUÍÍíðòž[t”ÐL|\³~ýœŒx:…^¾Kò=¦
Ç×VŽT�Ubø>
¼£Í„&Å3íJsaçk¦B®˜ØÛõüfgÈ}ùl¬½;��¹þ™`†%7ÎfÊÚif>Þë&£np-ÇA[°,öÐÇÓI±
}Ƽš?Šösž4X8ÿÝGÒå[EÛm¦cºCOõ§¾‰/Y¯¨c°>Œ¯-ÒUð-%µR"Í?ÐJ“+×È2e;’‰­�y眗–®½;_=“ ì,Áª)úv‘D™ϙ“·¾ú±ìŒè�\.&P�âýQ>Ò��'“…ŠxnîmK2Þ1ƒÆZÔ«¬üZ
ÅVe¤_lŽ†z¹Ÿ«ÏB±V�·k¦û¤OPw‚Vpô«*©Í1¸TéhlÇ%^‰Yfkõ^ƒÕjÊјb‹”Ê‹c"ƒ¤¾ˆ
½|
+ÈÄê{šWúœàd…Dæ;£nd{¬qôIfp
ýÂo—æÙË¢‰âîGÐr3Žù¿^üš‚	÷ø b
+õ¥~DÔo:âz»a‘œ¡^	�Øm�èHƒÜ™;¨Æ–_ïQñ)®O±2ŽH~f,Äw¢®¶õ{`fš†â&V!RYaÃ×¾
F´‚»/™Ôes¬Žè18Â
+ý»}½
+%-+�
Ô§ò`¬µ¯èÖgt’/ƒWÔû+cE}E?
DYã8„ŠÁ¥¾aðuH·~EP¨—Žé"CÙó‹"NBcÀ
+W®ã ù]nŠÅcÿ/¶Ô×a¼ßD·ØAuɧÝ�…ªp¸%ø°y]ˆúPM¤R7›àç3š¤>”�'˜ßžš\œ9›âGfˆ"r‡Â…<:/Õòó‡21£ÖÙSÌ%r؃ñ­›;ÇØ9„œpe–
—çq¡“~Kºþ*ßU~0®#ý¥ØÜÄ.$¨~ýÓ;j]ÞõP}©Ý¶KêÊr¿·x¹Í3«#á‚€@´ƒ[lZ{Ñ8?<ðz÷.xBéSUÁŽâôÀ—öÖàç—Ä3äý°¶7ÿ
+^�aa}°”öêýÍŸ±ú	õ¹.ÙÖ€8¯dN†w��óŸ’3�W¹Î7âÒ^Ó/ŸÂ›í?¡ŒkFóÚ–Zç÷¨Å‡Ÿåî‘U�4[â+q8»É×Ylök¸jò¹÷‹yµiZDK]�	Åa'\v‚“ÁõÖƒÆáY¼§§LŽéô6>"{Z¡S‘)þŒN\œ±Î]2ɧéTe©.à¢Èår>ؾù0‰‘Oè•Ä]ZêX‘L“¼»Ì°æ†9�ñž	‚S•Â¬œÐ�ýÊõdöÔ “ð-U6Î:za˜­ù~GŽç÷¤p;×!|kÞÌHlÞ`ëB1ráóœ;f>ÿ&¯ŽXí8‹Q·¼®F4á&¸Öö·hØç'Ÿh·Å•~·&œL܇~é3ÔKQó¥8õ=VýRÄL'ïÀá!¹þD½òˆ£Í8.½œ
…¶ýR%q±uNêdÛ)ѯà¸,ŽÃ€žÎ—ù%ÇŒ�ðwEtn…úûÞyþ“0zÎ�Ê>=ïLpòå¦�|å1„E-£ª¡¶ßöX[¥%nè‹è¼m.î77Ù)bäk*�´‚ãÕO¡ó8#øè1J(�¡Ö¬Bô­Õ�÷è§Í	MŸ"�¤‹%™
+‡.Å—Ù¢PÁ›„�^�CyÔ¦3�ºèÌžñ;ž¶ÉǘïÌŒ'4$ñŠ‹IãŒ$T×÷ñÇÖ—Ba}°@V–¿7($“.½*Šˆ/�Õ(š5ï¡aFp˜8ûCÔr{ÙçÜé%fîèr³‘4:÷¶Þ}ŒC£‡lšãà˜w…ì™7Ë“{ã¦[âêöëµ².¨fðAI¦b' #%µ©øSäªY)ãÖë¬i}vâx,žîÑ*’μû±ÀÕq
+Õ±úYq0ÇÚ²¹4Õðˆiø(s•ÑÂu„9�Kž³1�.—Ô0©™ó)ÚJEuÒ™æÖvðæB-†`´4°]o7×
¼š&ë¼_žY1­'ÖØQùúã¹—	C>^áÝ\A/ø–ÄͽýÔé[‘½ûÄ“DÕ	6Ë6àï':\zIÅo!•øò�$aÁÃÈõ×ey*Ìxon´á)õWY�˜­¯?EÛ’�Ýv:{@
+Y5ò±	ë×}òosQý
+q‰Ñ‰QÍñ²³cq]ý¿ì—P—ÚÇH²sˆ©ÃⶒÃëv_Áy5˜((Ôâ»åõÑ��ì!¢L
d·kìï'àÅòTÌ9Út–…Eë™»~�yô0æŒÖj�aMäÔ}Ê ð¹@ S‡Ð½ö.ÿ^OÞ�n
na
ArîZyâZÿ%aCžxÊWļ.û–é@²ß|Ç�†‡¡è{p˜Úv}H§rwÇû²W¢ì%ÉpŸìFe+VÓÚCε
+㵪CÑs(Ú)ÃœÍòQ˨Vu§Ý×Qá
*ÆaCVKaß8ˆÙØN>èñæ¿{^VÙãZ?­¢Ïáb[9›.+LIÓñUyüêW^þë1’úígç<.‰A¯*qÈJ
Y€.˜—í÷'â…÷VãRR%HGÖuÒwØb«ŒR-»a¶cpÈ‚ŽA+0¾ß)ª
âÎS†0Õ f<Œ94,O¥U¤VÍ|¡)|Kb&ñj¸Ê¼Äó%y SÍœ¯Y zf¸Â…Ïbâ̢׈piˆ*#<çqôÓ†ïÅÈ4�”}ý«§9¡Åz9¯×¾?!©õXˆ_ÃÇ?Á ·›Ìni�„æ”7ß‚3ÞÕ>ájÜî„Ee¸å±QwSô[¸
,¡“)W.:½Wôø)¨[ð�Akμô¹_Áîc¬	KwP	[ÙàÙ5îLxäªÔ?{d!âw‚Ìüõ\U“�Yã‡Öó#u˜5|Ûáx˜ƒ(`‚óÅ-S	#³³¢ø;g4hÙ¦S4žºOŸ< PùT )Ý'¦ŠôÒU¸�V|çS0E!vEf¤1 2ÛöÒ]Uáo&œø¹ï=š
c…HÚÁá¦/tÛ'C¹òBÒtÉدŸÈáØFëRHŽiØ6ÒZý Mâú”„¯Ç[{¿Ñ`#s’NÕšDؽpŠ1J”^h‡"ð�=WòS%
t»HÚåu�,mè¦3—
+|mÁšöX…�%µ$×ëãÕuVÔSj”
+òP)%Ö‰�
+\=ô¹´}
+”l¥n«É½wkdÿ~Pþ?Áÿf¶@0ÄÁÎlƒò
 endobj
-1303 0 obj <<
+1313 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2725 0 R
+/Encoding 2737 0 R
 /FirstChar 34
 /LastChar 122
-/Widths 2734 0 R
-/BaseFont /ARPYNK+NimbusMonL-ReguObli
-/FontDescriptor 1301 0 R
+/Widths 2746 0 R
+/BaseFont /AVWTDF+NimbusMonL-ReguObli
+/FontDescriptor 1311 0 R
 >> endobj
-1301 0 obj <<
+1311 0 obj <<
 /Ascent 625
 /CapHeight 557
 /Descent -147
-/FontName /ARPYNK+NimbusMonL-ReguObli
+/FontName /AVWTDF+NimbusMonL-ReguObli
 /ItalicAngle -12
 /StemV 43
 /XHeight 426
 /FontBBox [-61 -237 774 811]
 /Flags 4
 /CharSet (/quotedbl/numbersign/parenleft/parenright/plus/hyphen/period/slash/zero/four/six/colon/equal/B/C/D/F/I/L/N/O/R/T/W/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z)
-/FontFile 1302 0 R
+/FontFile 1312 0 R
 >> endobj
-2734 0 obj
+2746 0 obj
 [600 600 0 0 0 0 600 600 0 600 0 600 600 600 600 0 0 0 600 0 600 0 0 0 600 0 0 600 0 0 0 0 600 600 600 0 600 0 0 600 0 0 600 0 600 600 0 0 600 0 600 0 0 600 0 0 0 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
 endobj
-1227 0 obj <<
+1237 0 obj <<
 /Length1 1606
 /Length2 17489
 /Length3 532
@@ -13788,102 +13833,104 @@ endobj
 /Filter /FlateDecode
 >>
 stream
-xÚ¬µcx¦]Ó%Ûv®Ø¶Ù±m_±mÛ¶ÝI:¶“Ží¤cul»¿¾ŸgfÞ9žo~ͼ?Îã8wUíU«jÕÞ›‚DI•AÄÌÁ(á`ïÊÀÂÈÌP°²3qs‘w°—cu°5ü5rÀQPˆ9�]­ìÅ�]�¼
-`e°ðððÀQ
-ôtý'—	`fåâhkìõ7÷_0Gg«Ñps±²·ø/ô
-ĬsÍXŸë%¹Nf�ß{SÊ*åP„3]lÎ0×Ï4�dîÅ�äOŽHþ¦�	˜Ý(Í hõ%gç”)'ÏOTCã£#Ã}·�‡øtù	°|1�NùøB:êÕ>Q´ËGÙS¶XÂçÌ}#ÒÜXœ‘,‘|[Õ#~WØw'Š„ªð£Ê#$n6ÎÞÁ)óý�xCÉ]ûAÍæ”=$w?º>1$S®ÝdÎ	ÖÙPN<3±ÌWêGâ¤Ý£âò
-ã@]á~?ÅñïVìÁ¢ˆJM†³„‚ô_G)|æ¦jœ:ªSÛbÈ~,˜(£ÜÖº“£xõdñÔ¤3ÂW¢säbÖûº.Ÿ†Ç“Xœ¡f-TûnÝö†hRâ/2z}•wKª{?…†|ëþ÷(¦¤I{Ôħjäß{ôb²4ªR{È2Ý· 5ꮋ®¥o¼WÐÂÜöš¢ª
-¡s,ÀñÙ燨×qZðoñS-Ýì…|­7€°4\±uhò2â·�t–û
-C…Cmkj"úðÝãûò? ¤L›_LM‘>¨J£M&ÂÃ¥¹Ö�›Bnv“EREŸÇæ«ÀZ§*ŒVXpÈqí$~Wóÿ˜\¶œÌÊòz¬©«TX¿Â4›÷T#x0E	òÄ‚ùäNÕœ�jÛEƒ²¾ñâÈø¡Î¥7µ<t“[ß|šytl"†‹÷|ÊÍ6g"„¤j�èŸe¿âûežU~¤ÍúƒŠö!8—q7¢rDìúøÁ‡~Y*ž÷3ó²ô½6"’E/ 3A~uâ„E
9«X¾9y½L45˜>ZÇú~Vr—Ž!^��Qê#®¨çS{„«;B¥9NG
-Y'B
-MüWVM¸òØ
šSöÏsˆÊQ;ôà#tîWôÕd°±ÌêÐãFþY[G5Ó»ÒÝÏtãâ_± ;!µK°æ¾3’ØmÐð¼]ˆÂ:�c
-Fú¼ªF&/0R=5;|¿ê°yöo1ð„­-ÓkÕG#w©V·‡Â6
ùQ®ÇÊæ[Hd/w’#BG8MÌÉ=VÐácn¨¹)Ë�4j†c¢	Û?áØ3fž¾òçƒG/’Am
eDz!*ýáY‘
’áÞR¾£Q�»ÈÞYuÝÍ»	¡O¾:¶ºà¯}uiß¾Øýh;/²kvôâ¿“ÈQýÜÔ¼�ýܳôŸE£ùÕ	gá2vP…——&âÐ{–ë|þVÑŽ@YaJX°e>(§*�³ãay!^™Rq5i—öS·Ý¯¸£ïW]V€Ó±¸ŸmŽZŸúûW†Ùf.
´¬%h§ÿB¶N@—B£(ŸK×k�oZb±3ìó Ê�
ÝâO±‚cõ®wíë¨F9j,¡dÇ*¹´	dÃÃ:ôgý½oZ�úi`Gg|e¶þȯ Ë eX:?æ˜ö•~#3úºéµã<;‘ƒð35&EAžmJ–á6;©Aæ‘;î'’#ÊoÛD]Ñ,À£’}¿wá<˜?&HA%VÅGŒÇÒ›�Ü7³„ÊÒjE� 
-~˜›ñ
Ñ $¡ØAÔ­Ÿü;\F$Ìß<³kNÔÒ5‘~“Oç|ŒmýŠ�FøãR@E_Êw4Þ"X!ižøNq
Ý[åûÄôë'ˆ
-�}ìD"`ž,èÛ˜AfU·oÚà·¨TÛ[³'œM£L²Î;òèeñ	UU=O¤­ÃZÞ4@Z3uò7­ÈñyßÓªsÔÚR0’ö¥1¼7/‚¹R:ðw›�@»Œbâ¬ßÞ>0éÀ©ß�Š‚ß˼n8—¨9KÚ$>NÎŒyJŸ¡ÀE/àoGÂù4°·#îoî–êi7uòý~ý€¨¶Öá÷0\‹@x:ò§tà^c¶Zí=`±óoö"´“BY�7±ÕLf¶û2HöþQZd«‚mßha.—wf÷ û¡ÂF®0ó l8áîcä
-…�Mußɾå" Bû«CŽ¸ß¬Ìqq/سÖn%Œƒ´û°&è
-ÉFl§?Xº„×Jf€^."+«^öyvðKÛú x¬/|äô0“Ëm¡Ù¹ê”_f[5·Î®?°UÄظ‰÷­CÕ�*a…Ç.ð™¢5I�^Yko(m�Oq†!<]ÖÏÐÖFßô�d„š@SÜuýÒ¸íÝ7$PâÀ¹ƒßZ<RÕî�Ü7†vzC3¡,oÁbø§¾˜¢æ\o,fôüÇ7û5Ž_‡�Ý7í¼»'h³P{Ê@sn­½»éõ@‘åe¹}Ø£<WõÁO’XÁñö7ÇbUd¶äFÛqÊn—ú¯E‘¯ÊX*IÈÎØTØ„èûòÚÇÂ%N…Y~ÖÑþÀhYú„áÄ*bÂéyê\’/Ñh¾öc¥æÒÑãÖŸÇ”áÓ#MôI+þ˜gÎs[¸1—�±9¥ú™×„¢�[8|×úÍí%÷ÊJ÷ŒÐÍUÿᙨ‰ã=¹di‘�¸Ô8L5]£°+<õóî Þì+Ö	•‚C´áõ…fiMŽþ<!}>ÖÆHJré|·ï•ó’’*Lö‡]KÈ®w��Û'7/š
-“OÆèï�b”£»$„ß#´ï_åË^BYUÕò£bz•âÁ¾M«Ø)Er)àÆÀ�Q¨¾i—¯J×>¨�F;.@.Œ
-œ¹Ëì™J‘Œ?±¸Â0í ,×fƒš¥‚®Pú±•´a¨ Ž¦&¼/N"Þo,SÙžÚ©¶ Õ~2FN¥r¹#˜Íõm€o¬æCðfÓT…ÉPé¾IÁ~#ˆ)o�Ûå´\s=QÕ
�â/=¤4{	PÎ`ÏYuJN•¼JÄ/à
-%¦j ý–Ïy´c땘ï,ÅàŠ3ž“þc3c$a²…{s†�¶Ïƒ¢Òë6�ùßÜ@¤c™2Ù½’"Ód—§$ºNŒî%З¤K÷"#w>RdÝ<4O‹ñoÞªÏ'¯>{´C=Ñå�Ø?”>WFƒ{ ËÁúydlõ«0U})¸Úl‘pì)¬ýα˜žIÙ<°¤kñÊG!å
tˆ­	?ÚmÈP¢Í8z‘—uw¡Ðêaî¦ß³)ïe¦Ž¸bQëÆvÄ‚VU2㓆ÔÔ k)|j6t¿ße.
ÙË"èŒQƒMWP[ÿ\òHÙõd<½C– Î!›ÉIÉu�ô
ê»Üƒ�}cr$¼´`’“†¦PöX‰¾è—–X-Xü³5V~ºÞVâµF;«ó#ìGÍD¯€ÎàKêM
õ	yû`ÊÂcð…º¿¸´6†çÏ®ß4õìÎfl?£i!e5¿bßg>Õ{�û9A ®� ”rÁ
-Ù*¬×'5öƺiz®„‰Ýf
-+Hê!±
®Ëö'Óä
-ÄŠ§h÷„Ü{É=Âݶ¡øU^–ÀàžèUS­œíê±¼ÛgéE¦oDs?X™W ß^®‹
B¾Óÿ…X÷Y(6ËCÊqZnÁëà¹Ïë-ú1ÿžæxñ˜²[ö©÷VŠ¨d­m1i0½ûùPšÒNövHûs	úat=§
-©gÖ<L®CRÁÐ�öŠn,ÆXcñµ;W«`S¶"Sÿ·ˆò¥“O‡˜E
-eð5²v'úå„a(�»¤Æ#r)†‰çð
øË6-E£Í5øÊ÷5†
ßý+f¨]� ¾Â.ª…¥�ábAðó³òþ7_†«	¡Å=ÚEÎ_k•-ó%AQIH„¦Æ.%í‚Dêä\�n4[*37]ÈÉr4é*–›
V7�m‡n¿‚òF#²À›ô,y*oö#�¨“÷©$Î9f¬ÒÏRÒÙþ\Í�ªL0¥Ü¦Ò>6 1ðòê��/6]³äv®µZ
-_¸¨Àé«ì1ßRmþåEÆ„üPñsKªP=.¸#`@—ˆ>Qô›ð»Â¯
_ƶ„íd¢ôN3×'M˜.ÆFrÔQ?žI$µ_«°úã¸åÓ1æOÊÊ;"ŽÀ�îÈ?²î�wó:FÅ“|/{;þ¯º”ðE*´V÷$ ÷PŸ†¼ï'E›£u!¾$Hù+BŽ:´æô ˆŠ25íøµhÖ¦2Â1¿úO€¼�ŸÙ§hémFƒjË�[ÊÁsFó…ì±\.cá>—ócÛ—Ô+v©Àâ"Tû¸hõÖÉÅýLQH+VÊ
-
jgìzï½È=dql£1ÓÖYkû^PÔ1¦\µU1…$:$a^טôNyãLl˜9‰“Ý\Uäñ’E=Ì«}üñc×(Ÿ²�ä»r¿Á¥E—j/&è;»Rß»•Sé#4¶ÇeQõ\G'.*ÞÁ8@g`ÉWQ>æ‹—qåÍ6K±{ž0BÏM­c×­ûëжÜf¬¬¼ÑQر�!kᣇ‚§›-9\:­	R‘Må‡C¶ Q›ÒRÛdšÔ�$9WzC&Àç=²LƒzWuØ–`…I�L €©
úÀ!Ç	NãCZsüôJ^ã"–ë ÂçíïY @ËA(>S9|]|u
À+‹~³±ïL˜°Pš”ú®W‘€
-õ‘%­ßÅÙ/»"
)´�žTŽÑÙ
^ì¿%.óR/ß2{ß¿)½†ÍŒÖúà
ýÆìuQ̼¶Ç¤±/×ÊWŸµÂ
Ö~¢®¨ªÓDG�ë»+é,®ªÕòº�Y9ç#yÔÊý²ûX£Ì9þMd4u_‹´�ÜÁïy¢¿˜¢Ñ#é©jr¥m—�Ÿ¹iŦ—åŠ��’*Ã!=C˯ëCÍ>*78ö<žã$`V!”¹äÞÜÁš¯Ä®x8ˆ"‡cÍúÆâB“ˆYíHu›ö(
Áz
¢
-ï�à`íír�⺰¹�ò4r–ú¥ÍÃ_»øf¤¤ï§cžç¢&ô˜BoÂÕ¤7YÜ;ôXæëõsb‹W…«L9ž:=\Þ�«jö¾2–œ�ÐÍ¡�§³T®n1‡VtÈÓ¾LÌC�ôŽÕì=Ë÷ù�”°tT¥×ÕÖz…ñ$YZ<*�4<†¯i¤&A&Ùõ.˜n•ÇDÿ,égüáHÄ|‡ñ¶™µ“EÙ:O¹™6§ª ŸHÚVW̨VˆS­Lĺð˜ÖH9%Ä®qdÄÍi²Ý¸faîxqvÅøw»…d%uó¢0ÉÝœÖ|U’vKãº6öøÌ@!wJE÷²t!Ämö�ˆ ûjVÓç[Brøj
'Y×öÂNY
-ˆƒ÷ÎÁõs½/’ÛÖ[0ø´ÊßxÃ/¢µÚô"ü(Nc&uyâEB:\>è³€v¿/èzw–�>Œ¸¸ÙŸ3©å5¶é¿U@<!%^>ÓÁ£*8Ë•ÇN#ü^.¡èFj$eoq`Ì^r�¦è8OoLe¾À´¿öùh	`üLêEW*�«
-uóÁBˆ‹Ûª–õ›ãðü†Ké|^ŸØ$ÉÃö¬:ÿÊêÞYdäÌZõ[nðIZ¥ïƒ&ýMp‰£5ž×@ÄqÙ·dsá×mSY#Oô‡àáiÅÅžØ'u0övFä„ùžP( 1•}äG&ý&Ûrô€ÂŽXtc†BZsÔŒ¹h
Mvi1ž¡!„ÍcýI‚#Z«ÆOv5„±^0)ùû¼™�T8
ÿLñ/÷ßÓª"cÉ\Uå»°8Z›8´ŠÂcçÞ
-Î(ÒÚO¨²?1ÐDµò r8!´õ™D±h’�­ úÓM~ϟǽ²…ë†î~µôqÜEÌ Ã7)e§Ì£ÏâCÆ'C_{/[ߪÆ>O
-ºíää
-ŸNvYÞb¡‘±#Æ�™ui�ÃØþáòD„Jº
õ�JÌ)±ùQ'óŽéE½•+lx—.U!’o4Pe†»> ½güÏ/ hß÷
VŽO~�^ÔÌðåHàj!Ï_®!‰7¡†�:£L[‘xs¡°öJƒu-{—mR” ãÜ>1]ÃdKFq¸�7}æ@,¶¼-Ç¢ÎÀCþ¨Ù³GìAYJ§øÕöú(Í¥ãX¶2À�{ÅõÚ¬Çú=A$ÓbPI²4¯‰x¾V„÷c½áÄUŒì‚ü¸Úº»H!õ�
-.ø@úo‰.Aµˆ¤l”é
-ZC¾“�üxŠ>èï‡P‡ˆ%<ý`TTþ<¸¹Ã¨ò~ROI¯Hµ•·?}ñ7lymþÕ‘¼%�-€†|~‘@˜†l
-û¬D¤AôùÙL—[€EfZæTVû�=ÞžWðó‹OõtG6ódìøÒfÜ_J‡ÁöR*iÖƒ¶_Yx}|!.ü9l½~ÓËöžû–4)¾ÜS¿4ØX½½ï�ü1Xš¹•.Ä!O	8×û…m^üÞ£ql1.	ü‘B&xdûÎ !<ÏH›?©³Kì›ÇAà’°ü‰‡
�3ÌXo²°2fËÔáê.•I¹Fÿqš.ÜJ’ŽŽ�ý¨Ï;µä€Ø”ue½ãV�X ä¯u¢èLJ
{�BÖ´Æ ±ˆèŒ×°ìÇíç&íò-MÁÏÌ b�²á—“­Udf»[{¯â…�LˆÌCü¬¸"ƒƒ‹'‘‡x’cEµõ]G�¶ò¦‘îi­æs*Íd&„ç­•ÝÖskÍ6ÓåøQsèNíË°k—ËìÉ_ßoQƒ.ßaÌ/ÁsœSè×òy® ëW žc.©h–C>½t>!
|x	4oÊ°úÀ׃Õ,o-La�ºA7Í°Í7)äó3�̆VfŽ$0T¸Ÿ9
-ÚŸ¸\@!#^dcÉqæ’ù-$õR‹�ÛGÐÑ‚ÄOL!¢köæV¡Rî6æÎrMˆã'¨_dœjÜõŽ­»¢'Š@z£æìôü,–NÌüua„¥¤|a¬hž~"^$6Â^°|ÒR4€
†ž 0©Vb"óãÏ ž‹#A†L6G²»0…
Â3ê6ùD¿‰‚9È\Dá:Äû�R(¸ë?}=$7z�Oª	‘—?…!<تyë<Í÷Æ
Qš?ab{¹F
-Mp.Þý©\B„$–Aì�Ô‡‡}Õ»X¤ ñé£×B?¢)ÚãŸ@´Æï �4pÒ�SËý
-±5Á
¿Z¶&
-Æ<H)]Ì{Á}꺽î¡›0<aÔÔ.’mWâ#ªš,)=Îܘ’)nÞ ˆ=�@öõÕ<jÔÜId¶QГörº+ž¸7rªXbD¡jºçÆœùaŽG¨¸Y/°kÀµl"%¢�´™º:ô7“ˆucË©èÎi½ÔzZãß'W‚Qn&Z¡gßè!ÕÓ<¤Ý¯/Ú€àuÖXž·0‹f_6ÕaZÀv`M¨¹ª—1bvÕIü‚Jn.ðK5bø½Ï�ÿãΔ<élS+1ïµÁQ¶ì…Æ7õWv[¸!MEXZ3tŠ·`~¶ý¢fìZp‹.fõ»c2p&«7^ö#ô¾èÓÙÖ)xµ¸åí]££Áµnešc›JÛŠÜ|g³v$BÀ�!W’Œ ¸U¯èÎViÝ
-§vÉ×%’Hð«.3„ŠŽX.òï˜ÀlŽ²HñÍ�gÅ«ÊFýri4(}õÑH!çDCOÌ|Iuúà%%Î%³“r)¹X!’=t’¡�“S£*b�¼iV½è6À.?ªQ7¬¦}jRÁšm‘œÇäÖ•ÇpyNL0¤ÝñÜöè@­³Î¾áµ’2רcíågE*É�R™Ò\'›˜bàáÂw½v0Å8<'Ì÷’B'Ýg‚§ îŒÁÒ›=¹Bäw^ûÝ¿`³Ø<9øMä\5ö5ø•ÂñWÈ=˜�XV’¸…�­yô„i� 6-úDA8qN!ÍŸ$öÊ“ó1 	ÔV�¯çÁ¡(³h—µM±wæ=Ò>zoØMé`w%óäû›Õ�
R÷bO飅Žê>‘ÍZtuùª£F&¼O¿NAJȼWêÉïÁJƒ6‹¨�ÌjéE¶~‚ÇÑAxH:ð0î֦̽×A{5ë?]ñ-|Ùë{É·"|ÆÑQÿŠ D™X<èkeà	8êª=§fÀ¦•[ä<wÐÍ$YÆeÀWw©Ž…Nƺä
÷}‡è4×ä+Z—¥dáh½óÙ¢·Ö!WŽt×…³\|çû3[ÇÍÊ´ú«ÃyÓ
-6eœn&`±Òj¿Šäz
M’äÙõDè.TbaY
˜‚ì!Ɖo3��6ðõ‘nFk„§‹pi›ÇýÄŠ»iÈt‹Ç®:
Ó5º²0“¼/ºI´„Sy�ÕïɤrJÝyúì¡áùU4¤éB,¯˜”éZö�}
-Y4=ÊB<7ïm覯üë÷¯Ji/¶Ov¾“…8·-’¿láöiEçh¤3Ókɹ[�x)ŠcÝk™½¸CþÑy…Œ¨Ÿå3j¦§Õ5͈WÝ�ç9XÁ,­2n<ÓK{ (¶P2“ÀŸ^Ši’;VèìVúJ�)'¬ð°<ô¸O±Ó_ì'Ñ«FX7Ó
-4çv웞îãU:ûò¤]ªzrÔîtäÆ?+ÂÀ½ÀÚŸ“rñ\2V,†mg«@bøÂBòØÄ*†N½àgÓb~õÛ_æ<žo²,Bÿ
§X`�`âN¿aÕ)`Ѧàt8hOÐ=Ð
‰CálC4ƒÌN©Éce)Aù1éËua‹¿nôDW“ôÁëªj!±”/À·vy²ôI¾å”®Ý‰¨hß[sÌÌóo|ð›êÃß.£VƒžóG½|VÚš\ä‘®X+¶J`sEsߧ¬Ðû´Ú0§Ø¥‚ÔÑ{8–À}µ‘~
;¶M”¬A­?¨Ȉ
-‘MËÂ)ÚJìyï’盾°+ÛAX•¡<UuÆEÁ°ý”Ï©S«³óõå0þ
-èP…ÃR œüZþ¸»ÈÚ—F*þ/\<>c�43‰0ÿB¯u!u•ŒA¿8ÊNÎØÙùªycPÏ¢/’­ü䄆¬äÊfI˜vÐi}°´ù
1Úd
„fÍ9~%Ù ’Ã"´ÕÅkƒR†à<Q9˜ñ&å÷ìôNJì
-ü•Ä;÷´ìCc6g¨FÏ 6Z¸ñOÉ4nFíÌæ@Ÿ(’j½9ÌRi|ûÄ«ÎÙ	8�-J_ŸW䛉n¤ÜLá J¯:³Úl
j]­)Tʸ—iÉd8r×KÕT˜²†÷A�«—h,‰BuÖ
ƒ}͹‹Sðé€mWõv¬Âë•h
+Úþ�ö…G«I.&â´<¼Xh
-¿ˆi_þ´° z`?ªÃÖRf|°¦ˆŸÆúµ~š^Ú¯x¸m)h³zã%ÚºH—�ªíAéºl…Ý”ç68c`Gàw©XŠï[=Ƹç(à�ï–†ãß/ìת}ÅÙ+�¹†¥!\
-ÒTÅË£A}f–ü™‚Ï$±*AËý¬zï„ži'ɉkê–8º[Î
Â!w@ì�fsñjàd€‡XH+ý�èNY}a
K:Pä
-Š€øÞ à	ÕƒöEñnhóJ×T—öД‡B!p±•ù
¦—l“{^.¯Ð	±LíìØK˜Ê9ˆGxC‹€U¼VX–ììÆ�©škð*û}¡óŽÌTÝF[|¨ÔõÙa—UÃÔÆöIœ¯ÁVÔæé„7½&$¡N‰pˆ®Ç�}E÷År{U­chX•è'Mí¶Ì—ä$,ŸëeÞ·ž1ÍK™•aFïá{, -ÓÀ‹*øg•ŸÚ6`F…LÎsîã$’tdÜÜØy”®Ç¢%šð¶1W´Ë�L
Ñ,uþ©löW' ¸nºó³«öÒpÓºå
ÓfŽ¶ª�¿sKn?]j‚°ÏÓ¿¡gæGˆÀhfÙ{Ô¾	Ô‰í’MPŽEoødx€Q²t•y	Q
”î§V¤óMÇL9‘5òh°À!e­Ÿ•¶¸¶ù8¬«”{†ÔuQ°b‰¹BM‹sÙ²É “ÿÆÌ]ƒ	ÎôvÍ&Ì‹Ï‘'½8«“’ã*I5«6i²Ëiw ®š@¯Œ!�e$}‚s¾{‰ÏÑëŽ!!c�PGÛD<À-€�s_|ù�bò´ùAðËQó‡ú-š"ñŽÓ&”­Ø5‚µ3~�‚Šz½òh!Îi‚é!ƒ³ÈÒ"s‡¹;o˜n¨Ë¼
8þßÆ”$'U©
-v.Z[våe±àÞ¦§°†`G‡·^—‘žÄR…ÒǺOƒò^ØÔ	bŽeõþ™ŠÄÀ.2¿AÏ»bÁ²�¨¹zYÛbÛÙR8ÕohrZG’Äý2
-’k�­~ºk	´,x™
-­å®¬¬HÖìFÉÞ NžŒ„_	ð3¡¬yÀ=ΑYÄ�Cç­²
(/ï?çïIþÝRˆ²¨è‹[_³r'Ÿ‰T™'´7”X‡€*ÿ|xÖrlŒIìèUFìžovñB�W¨é±½5à+[™ƒã·¼Éú×»„&+åœÀ´±Ùg/<R4:ë&ŒCG"ëiŒTâM•3_ßw¥èùiExZÔt»ËŽ´Š<«7@µzi|ÜŽÄmÜb3]²?4¯ƒMÐê)ÀžX~j8«'Œ½sWst’g�9èáѨVóìëî	À–Ës<|ÚËò!Ø!í®©±¡–¸ªŒ6�Õ¸ð‡Ê…²¡ŒîÛÊX©|¨_=›Lè£ØÏÇÿ\RS³îw�Ÿ";Og0N¨ã/Tl0ýu[£HÕú¹ð�λœ}¾f-õaÌâ{ºGüyèQÔïÊ‚´q¨Gγ*{b¦¸¿ŸÞ¤~+6C¡¤Ê�:j]9Ýô¼w©Ûبþ4õ6Ä^
@+µ¡‰¶�°l�;âÌdýdRCúN'æ“DÀUzF9ù ʳ>XJ²éžÿõs.n�oÙa“’cÒ;c»öZ:ckJc£S…
-Ò§ôSëÓ&áî`âìð2«oÜ“ýÛ²z6µÚÚ±]9̲�MŒ¸#úSýª½©@Âs]¥`Þt:õ¢q“ÙtìwnÒä˜×j¡
-Ò¨tWj�¶q,£Oí×Aò*úüßMî´tùó—ã´Q)VÅ1Í�ѽ»y§ÑÁL™¸Áì$Ó~ݯãvÔå\ƒóû ÝÓTùœJ̹`¿ÅŸ
-ÛÎØ,kc4Üò9¨3~`"Q€p
¶¥Î6…y»L3ñ|hk$XÀ­MÁ=3Èš„ƒÆ8¯ó÷øúãÁWæ§ËH‘�þ#9Lñ>Àü‹tú“ïüú†Çåħ­Ù§=Gß™nÚ[ù²kcñ>þþci˜˜0±½ýÖ$dï4
ï–7ƒIÉ=&ß’(LaË­<ü;±!
O$caf%ïâõžvefÁþc›k?2H·Dâ"V•Áó§›#„M韤ãب—ý™Å¨A·”€JJmu`UßK�±ýj”ùŠ÷Þ£Êä€ÛïÖ/ÊÞ?H_]x3áÂýsÞV
-v£–%·;�®ÄÙùÈ[Úãèß(v~݆¥À�¹&=/{±¡MJ‡³ã™#ªCò¤›SOæÈ:I»�ñ£WX{Ì5ö%{›ñp2‚D{j)Ë©‰ë8tT˜FËûU5�6…¸×¤à	6ž]¼�Æ�˜6sÃ2ôk£�ªXÙ?"Wª¨T&ãUÖÒÊŽU&iÃÓØKwzK‘^:àra‚_Ò‡mJ¯Hd—&—q̪·Ïöz—7QÑÂÅ'�ø	¡‘Ô”|w»Xõ­©·>uC·Óè/™¾¨öƒ¦»Úéî–÷üoýËYtpqSù¡l¥®qõãõª9¿"Mq†ï³€xºôEÅŸK·š‚¸x�÷O¢&Sƒ
:À!ÏbÖñP|iÁSG³hlÌ0Ðl†˜/?Êg°‘ê§�4F½ OÒ
-¬5]“–Bþüd?Ã!Èa)±Ÿ UwW¬•×½é·@LôƒoÑ|p¨ôÞŒú˜Ë°Ôð¢‰OØžfŠ\ãà9]ËšJȪÈZ¾P„ðôùPŒ&†®_vǢ噗b;ú­-aéÆÉJ
ºœÕ7ÈZœZ'�ó¥ÂSïtj‹¬¯ÌÉÊ[3Ù
?–¤2ßli|˜µ…Ü©†ÏÉWßg9D‘ÉÞÌŽüß×âÙ¶üô&‹÷‹òBø»&‚áa!ìëky`¢4¬[(TP¤[î_±K"b·q>ë†L�/ozÍ°~ŠFp@8uªÉJ;EFn$Œ©
-€­^�A%CÛåÜLrjùY¢žÜn\4
ìZàT2�'c6ê
-�½‡?„i¬yè-†ÇŹ(Tv–lè4Ä¢TÁÀô>\Jf>jϘøaøÀ1•Ü<m§afæ»'Nê8¹kðèRž;|(¦b.@nz#g[Á°½™­nÙ¸œLz¤�Zõ’Êáa+ÿ|ÿ)\ØÇKΰ‰b0ÕªcÓ,îó5Q5²Fg:Ë$nÅáÕÒõÎ€Ð<‹OŠsº²ÝÙÿDÃO´0yw·„¥ÇÊ2ø½=
Ó{ú¾í‰±Áh%‡òRsÛUc"g×>ÈZô3MÃà^Ò�Ë«gÔQ™¯£—k½5ÖCÍôòíyÇtÛÔ¨Ù`X¼’ã$’¦½$85Éi7�ÍdWꙩ/ABI±Õ燷Ö\šÃbEPE	«Î~øxâ;p6Ú5´£„ÂÄ|�öÊ~Û`¶­\3þ'q¤ÃsáÖZwüÈé.4v/'Áxjµ¾%Y3†
#óÇ6¬æìy|^Aj¯ä–Û4ÒÆÕˆÉé
-V®ØäÊÕtßJ¿Ú™\z?K*¸6¥!ÑH³Á½Ù¥‹Lº|_‹MœMI¹$Ö›­»Zƒ¼¡¹ ’uºKÅ“ž
-·ìÛû'ãD¸Ø“²x};èþÓ–‡úŒ4D�'P{”òeéø÷Ê
ÏÍùøëjˆ¬“q~½©ýë¼ñ<ZxàM>Ê€·ÅV¥V˜OëüÃwK,�-èÄJ„¨Ôq®ÐÍ�°î
-sþo§ý™
-#¶�cër!¡W= „��´*¯g±+¡‘À#es_‹,2™ÊãœP+ÒpuMYÖP/ºÈ˜ü‰‰;°>Û[¼”ZDñ½"ºßoÅq™Ü
-èEHÁU1u”mLz‘ìåÃh p;ÞAåO‚¼ïw2}íÞ–!
F¦†Ÿ’)fmûì‚Àü	M½ÿÌ{<ÇRÚÖ[…§—Ëu
Íc_Tž†t¾Ö“Þ©Û÷ŠUé
„òPZÜ~›…–nX	õCg›
-ÌãR7ù†æ9`ŠÌy8”5bX%2Z}ššÖ<.Ÿ39‹o§œgéJ€’ÏÂá·‡GæõÙ�I°gÙ[ããÅ)d½ T¥1vÙÍÅï<wú¤ãï�WÖLœš‚œ†ÇØâ3:Wª}Ѫìp�H¦Ü­|œ@l¯÷ŸS8±åë�z,††ý;x âMJšÎH#œxå8Ÿˆ„‘Þ¬�ÝçÎ�Qøù—ÈÞyK|8aç*Asabvª†ž˜L)"Ù÷¾¤B,
ƒšqe>>þ$h(O®Ó=Æòè:ià·ãa(×ÆÞc1}œSBª=9›öÁï‰âòí§ÇØã®LYÛÃ%¸ö9¶Z³cçÔ%ו<7oø÷¯÷�pn=¢+‚t³@wFQ´-Zå�§;VIÿòÉòœ›¯ÀémÂYªíÎ)[HZe4;ä]æI�Ú1Ô
-ë¶ÓÍeÖ�åW[�v»óœ¨ý³®è�M�6W(Js:L9þfzoÇÕÊåÄôq7ùX›§¥å;#=)G
MjÓ§§°ó>7W7WB±Ú[·ùÿz¨w&"L>bq\½·„Ѫ~yQÕákÍ«.·úû˜¿W?¬>¥¢¡@#r’ô-”‹Ea]eãò£»JÅ™|šŒ3’ÞR£ˆÉ½ÕÐüJåñDáÃhºÂ’ð‹²wíª[*Øà©r‚kº4\¾`fÜ^î
?d:ÍûEËf™³¤‹M”ÖCÓ„osCü>Kñ•¹4ÉÀOõ62|3ÑÎyõž=¹»ú1¿¾^ž®´—Ÿ5x´ !'„ú÷On,‡ÒoÝy€ùbº…q²{m� Ì�±ÓOkÏx�†E+ÆÖÒ7ó!xìòŒF™³0¬·«H{¨˜þMû¾É^Ù^ÍIös�ìëôòC¨Ÿ/`u¨QwO¸øˆ”zŠãDÆFgÃî43ö¼š…¨{ÑÐ÷É�`²lAoÄšCÅôìc #sˆƒ6>Êjv*AjNeMx‰@³ÓÆÅ£4ìæh7ÀP­–gÂýÿµ3çÿL0
-Áiz“æÚæ†Á‰²ÍÕ²Ïm7ZÄUé×4(ê6•…zÌŒ¢PMpêÑýה¤ù†Ô(Y«»kªWÀî!`Ê�£mbÄ¥„qg��ˆœíF2X3ó£æo_�ÞdõÍd¥:»T˹’E€-ä{.1ëÉ
-dÜp®ÈVã_¨¦1³å{?î:
Wõß~Šœ©"LùQjƒÖ±:KY5bx„6ÚbÿÃÖëlƒx¢¥
~¥,£Y§Ê½I|çȨ!VÃ3µÓÂ�zG#•¦n4’£Ç¦ßÒù»oôu¶Ô~«Ó
-7Ÿ+ó²Vï„(�a=ÔÅ>\M!†rµmè÷È%
-^&ÍËâJ€°—Ô²?\9¼h¢Y§!¥EÇÊ·<§ý#QÇÿ9ÚQ·nºÝ's,ÂøŽ”¢­y–’Þõ¥«½ËÆð›_ÙïϳŠ�5NÒë%Àv<¡¡ûÈ<{šOS*%älõËU¤¿\"•e†tçù›ß©s°tvܘ´t»Ç(Ìv«k‹qµ÷³ƒø™l9^÷k
%}+oµ©´£‹rüR·JôQ3ül^{´v;¥r‡³°åg3¯¢Ɔ’¢Ó¢\[#²Z̉ˆfû½Ç|(„›°ö5ÏL‹d•­ŠîhŠÆ.5TËúé䦆zp׬ó•Ó�rMΩÄq¥r.œðÜ´›‘À4€áÜ
jÿ%®ÿÿ�h
+xÚ¬µcx¦]Ó%ÛfçŠm›ÛöÛ¶mÛ�¤c;éضmwœô×÷óÌÌ;Çóͯ™÷Çy箪½jU­Ú{“+ªÐ›ÚÅíí\虘x
+ŠZRò
+	þÞuû[T9Pƒæ¸‘WÅЯçøÅxqD¹æ�dªw^sÄM]SÏx
.¯‰¹í9I1X0ô®-ƒHG¹æê¢[UØ—DgŸ‡ãµËV«å0çÛ8æ£\¼ÝþZ¯a®¿fm×àaÀ5jî(!ò8�þ
+ƒþ¶­¡^€èÍ{[„ïÃ÷ˆ’<ev99Iò¨"…6‘
+†9ŒÍÈÜ—Ñà£o©¸(J‘Ô«‡¢£Ú>áØÒû§Ÿæ¿òç‚F.“@mô¤…{ *üàY�
a^’>#‘
»È^™éµ]M»ñ!O>Ú6:ì௽µ©ß¿Øüäi:.C³ªwtã~�êËRþÚÐx�ùܳð›A£^ë€3w=¨ÄËM¶ï9Ïqºx+ïˆäš§(·%Ìß2�U‘ÂÙ‚q·¸«H.¿ž°Mý¥Óæ[ÔÞ»V›éïx"æk“­Ú«öþÕ—n:�™C
-c
šÈá7Ÿ¥íß)ß ÂëÜùšï‰–PdÊû<€‡2¨O»ðK4ÿDí€ó]ë&²A–
+K0É¡R6uÙ ]Þ ½ÚIoï»f€^êØ‘é­?rËÈÒhéN¿³MzK¾3üºí±å8?•…ð51"AAžiꘫL’æ2=­Fæ–=éû&û-¯uuY#�RæýÁ)„ã`î„ •H1KwJ,b#DÌÔ*S³=œ2èqvÚD�‚„ŽQ§nî÷ßáB0$fúî‘UMpšà¯š¦�tD6•“ÿ1ºµ…ðÇ9Ÿ’®„÷x¬Y \Â,á�üº§Òç5�qí'�
+!ªUÏš(6ŸN{=GÑZœbIPÔ×â·ß¼<O™�-¸œÕÿ²r‘›ÄªAhøCÎ1Hlt�ÌÇâÚ6TŒ,XÇF¥Ên¾ýF6
+»Ý¬;öh_j%Ûº†@ßs ãµ×Y—K ­áÛ
¼ù[Äv—ªÞ`½¤ˆv¨Ñ7‡+}œ¡HŸÒ|v™ùËÛ¬Ð,!J<¶ÑSqÿ9f°Àï£î�˜•]>�hß#SlîLŸôq6q3H;îÉ¢–ÄÆUTt=�¶kxR
©MTIßý4#Ææ|Î*_ ̤QkJ„�Á܉?Ø?DñÞ<Ý	fKhÁß­wl£1Š¸‰2O}zzqÀ¤&�~”zÞr,R
p·Šœžq—<%@�‹\Âß
‡ñªco‡?ÜÞ/ú×Ñljçù®ý„¨²ÒÅ¡s7X
Gä:ö£°çZe²\é9`¶õkò$4•D™—3¶ÑHb²ý2HôüQ\`­„mÛhf*“sbóà'ý©ÌJ&?ý(d0îæmè…�MùÐÁ¶å̯L³Ö.KÔgZj‹¸¿°äQc»ÊÎÚˆy\•°‡3À44ž•Æ‰×O8SÀÊ›ó‘Ëm¸4"Ñ6yøâÙí
+vJ‘ß¿�p鯛l›:d_gB÷áú Ó~»t
+F�ê^4½¾sŠ5%Bw/k~Ýw½ªˆ˜;ÿ\'’¶a†òñ͇ñ· .’µèN~�T1�”t?9¼lxff�ÌóÌÀ— ¶ÕAÐX-^ØðÙa–ë|“Så;(Ÿô¶JN­m;~@‹°°a-ö{»Š+eü2·mÀ3yK¢<�’æÞ`ê
+Òõæ¶�†‰Ÿ	1ÿª¥û<âÇh^ü„áÀ*dÄé~êX”+Voºñe¡âÔÖåқÔæÕ%
+IðN-ú˜cÊu�¿5“‰¶>¡ü•Ûˆ¢…[0tÛòÝí%÷ÚRçœÐÕEïñù[#û{Rñâ"+Q
¨Q˜JšzAgXʦÝ
¼™Wú-cJyû(ƒ›K�’êD½9Bº<¬��䤒¹.Ÿk§EE˜¬Ûæà]¯@w×O.4~Z¢ÜFµÒEibK<kMâ;(¬Ð0‘P×’h#Ž;·Å›œu�N9À)ƒÃð9˜t§˜¯*YPgb@É:óÏYpè?ž}3¡“ÑìÑQÊR¤'Ã9íû!�ëÎ|óNU²¦[£2É0©„üà{¯	Ñ©#Öû<…Áü4Êþýùa©?ü¼Ú¾A·¸—KƱ¡i}l}‹M¦ú(vr«P"fôŠ*^ }YÞ£K®ðË™p&nä.—þ5FU‚ñF4žk
ò]a£µDb]6ÓìD#0Ú�õ+¹«�ˆb{”^™R£Âj>7 @ÆÆ=óYZ[åTm�WZ2Jî
Q2²Qeì£r›+®¦~"þ•»Íá i)ÃL3œºØj/
:ïñÙÒòЧDx:sIßmšÝ?W\�„¤˜0¼<ai-hT.	‡¿¯g’A–öŠ~�Юo…7keEEÓ—’!LðU’û.µ|§1Ð9Ÿ?Z¾ê¶M®2_n4è 66å0¹H0ÌôoÈøa[ôcñåï˨¶Ë®JÏÛXµ2åwdíÞÔÄí}îîÕÓÜŒ¦µ
+ã{õ{;ŒÛ±Ña"_Ç/„°KÛUàŠè¸Kh¶kj‡w•7ÛÁʤ§^JóÏjVJM¿Úí$å(ž�DЄ¨³ZÇÒéy>‰|GZ5÷tp4.\P,5¿
+.üRø#.c+g÷¯ð”ãlk�Ñ´Eò-P›æO&ûïÓ³ŽfsYÎ5‘²p™¯ë"Aå?©ëÊqf¯²¦+„ÓÿÄà
+Á´�2ߘŒk”¸�CéÅTÐô‡²£‚:˜ó˜¿8
+{½1Odyh¥Ø€TùJ^:–Èæc6±×µB
+íP¾æ~ê=‹âAzò˜3æµvtG4pE9#.‰PUº†Ü»zCçÇ}Æâ �LP
+L÷a.„º¤ƒ­
ÒîBœn]×qÀ~æ‹yçÿ)‹'•ü�D�#s‘&Ç>1˜`ðÀ/kY'c´�¡èÆ�³E ‘1K�±ï{ø<Ùâé§}ô¹ø*i›µ#ÝRüÈ}bÃ1™$ýøsX?üU+·¦‚áæª2|Ų[°*}¿Ïþ5Ô®z`oA'å|³âÎP‘
+7Gjƒ}> >ˆ‘òø—´iÌè@6¤«ÛðkÐÚ­L¤…¢×úN�<
üŸYghi­†ª�Kí
[JA³†sl1œÎ£aÞWsö£ÛWT˶)À¢BT»[¸(µ–‰…ýHKŠru*'ì:¯½ˆ=d1lÃQ“–+»PÔQmÆÕQùDZ$!—è´9£l˜YñŸ]œ•dq…ÝL+½|q£7(Ÿ2�ìd»²GàR"‹5—ãtí	�)ï]J)táê[	c2¨º.#ãý—åï`ì Óö°d+(sEK¸r¦›%	ØÝÏ? g'×±�j×ýtòišïÒ——ýß
+iÉmYÁ�5ñÑCÀÓLí¯Wù	)É'³…BO š‘¨Li¨¬3Œë†�*¼ õás3O�zU¶Û”`…J�#€©xÃ!Ç
+LáCZ±ÿòLZå$’mÿ†ÏÓ×=O€–�Pt®|ø:²ðj?â�Wˆõfm×?n®8!ùC·"ê5<SJ¯“²OfY
+Rp>9,±4%¢£¼ÈoJLú¥N®yæ¡oSj›	­åÑúŒé남xM·qCoŽ¥�K¹=¬ÝxmPE»‘–×	vWÂILE³ùu³bÖ[â*°…ë9x÷wµÇØwá‘”}M’V2Cßçñ¾"ò÷ħʉåÖ]B>¦ÆeëækBz
+ÊXû´0MßÎU»Èœ ˜‹8&ŒSÿùnär�Kx3{+ÞÛnàá
+0ʬpÂt)ÿNðˤ—zÆŠ@̳k�^=]�©õ��nuœ§ü…¤eyÍ„j‰8ÙÂH¤�i…”]LäKjOÔ”*Ó…kê†k[„Ÿ¿[@Z\;'“tÐÅaÅ[)a»8¦cm÷ˆÏt£Pp+MDL×bû|¨b1y¾#4&ƒ¯âw”qi+è�!‡hæÖïxQ»Ðý"¾;e¹ƒO­8Âz©Ñ¢æCq5®Í¥+ÔæôFŸ
´ù~A×¹1×óbÄÆËüšN)«¶I;Rñ€”@xùL�,ç(S=÷}¹‚Χ®–�¸Ã�1}Éqœ|¤å8»5‘þ·×úÚç¥!€ñ5®Y®
+îJêÞ5t*¹D³ã9ŒþÁ�Ô)AV)ýK\Žd@æ0Æ[‚‰00¿ÔÛI”eIõ
Ž¹¥ ŒaØ&oäx¹—ö°ÌëÝñ‡þî…\¼%½š.²™{!µ£ 54\ß!�µÆ�?`wÒ¬E»œSѬ(› uѺ?^|êƒßvkižGäZ³6ž€Ï6Å*Öí…y h�ŽÈõ›\OôÜ`&;\ô­(áü
­:Ç©Ýân´v(Døâô<i®ŠÄ²Ç_ïbÙÑ!dá*7b¬�écñ™GŠÙÖÇŠ´Ùå�›licÈÓ©ÄKVµõ/Jw
+,J•zíÖï´YíRú˜W™ö<ooÑñ+L]rÃÄ3¿Ò°¿C\½±bc·ªd€ßúÌp¸�àR‡;ž×Ç7I†s±=*/¾2»v8òžV|—ê½Wèz¡Iqïâ�ciŒæÔqœ÷-X�ùtZE•WÉü xA¸[p±Ç÷Iì�¼œ…8 ƒÄð«Ofû’J½É4?¢°!Þš¢�T7áD,X
G’\…›�¦©	asY~ãˆÔ¨ò‘^b¬çOH݃7’¥âÿ„)Zs;šRMâ¬,Û…ÅÑÜÄ¡Q½ðØœI˜K?L.!Ç+Åîí¾ž7صª]äàðÀE>�dˆaÖgÙÛ’ñFþ148¹¢ßŒÇ%‰»13#r¨MÔ°4â8‰ÜéTÃÛŽbbÅiïй$Üꢙo¦žRk¢l&ÃÆ«zëKB{¦k&×;ô­Ü"di“ óGî�ÞÏèô•D§�S5}¾ÒØ’Å*ØóNFoï@Š'�}è/矓§¶�Rf}b ‰hæBds@hé1
+7`Q'YBô¥Í]ľ²†
kï×Zü{Ùïç‘á³’çÐgð!ã’ Nn¼–¬îTâžÇ�6™!x
~Áx�¾¾†]¢ìñ$nR“ê
+Ü�QÍàæÃÁ«ñX±Ø%ZxNç¨ç”tºð�à‡Um½_a°HR¶3�Õ"Dd¯q½�›$»!
º[êуA±Ë;]3Ž=ßcR|ëù’”ŸÆ_Ý™ö6æ-þÄ{–2¨2ÏRu6›ããžVX~V±üÖ
+o»˜š=ªk¤íѳ€�ú倥¨ûü
+Åq\`Þ³,‡­1ólw:)*Ü F Ï_ÁÓ+øªÑ"¡8cöFÀ5L¼{ÂrsH¦D"('²—çReLüƨ“sFòZ«ƒg�[�>¸´b‹¤�wW,¼@•© tNlÔÄ{=ãÝ|üS/³Ì?!7vw¾¡Q@ØÒ¢lÎAµÅöö&N¼ÍÈ
+o”ã©J<ÛíŸSš	¤i˜Ê§~Ĭu;àÍbg8³L¥w}²­³,'2iiæýäzºk×Ûº„–~NûºõåßÚø±Ôuʫ Œ�½NÄ·��Ã,Ñ/YÔèO”Û’ïÆ19øC00eÁEc•æ¹v\¿MÛE
ÂÄk%À'½‰´ëžd6$kŽŸüH�Lب¥fà"°ÆèQŽºüqwÞ¨Âõ–ØßHªU-^?P‰1r;Õ0›,9ˆ¢
+#ÞqÔ¹¯WgŠ"=‘H;n&¾³ö–2Y‰BÙ³ç²)î?ÕçŸ}4‹Á�]=F5úË—nÜŒîôwçá,tµ¯kΉœU¾k£ó‡s“VKZsÕ‘/d?‚
ÛÛ;î:êzpµúíÀ´""BÛý`“ô†v℉eÌ"¦>‰~6„¥ï'YRVfåŒY½’Ÿ–óTîèæ‚tÚ«úåÞ,
+R¥G”þSÂ[ñ¨E«ïäß:—’LO-í;¯®It• ñDR¬\$ò³Ï;�•&ë÷ã€^j£nŒüî£?æ}8Î=dÐÉ…¥ç…„
+¬sÉ«t“J¿çî‰ñ&K"’Ý™¬ñ3b¡ùm)�pògõÞ¨Ò@7ZðbùZëë3 $‡–}ÉR?Vô]×s³ëhœHª'H¯œhaVþ|£
+fi§b…¢ÃlùK§Í…ý`èñüªÅÆÒ?ÿà9;¤Kg±'¹	‘[3£!<£n“�7óË›�̆¬C<²ý|1&�‚»ù£ßÛÝN|«‹
ù¤qµñKÂ�µŠ§nÞÃlo,Á
+§n
ªþØü‘¨n9Ñ羘cá*ý®Vó,CêpÍ›„H	hí&.ö}EMÄ¢]زÊ:³š/5C¸À7‡‰å ”Ûñè™7º5¤:êÇÔ‡õ¥
k¼Žjs‹f&1�¬K�ÆZLsØv¬ÀqUµ¢RÌ�ÎZñ5¨¤¦|ßCú£•Ø8ú¼Ÿ÷&d‰ç›š	¹¯õ2¥/Ô>)kY­õà¸s†Öå¡©½LÐÝ(^�øYv1«­À,Út˜•IpÀéÌž8™?ÐÓø~!OÓ¤[gàUbw³´
ú�T:Áh­Ê­Ë²sMZþ÷œ‰Òb–= ;[¥$�´ËZÅ_WHÂA¯:LÊÚ¢9ÈGÑ
Yì¥b›Ï
+×
zeRhPzj#‚N	ú˜yújtA‹Š‹¦§e’²É°‚ÄÙºèÄé‚;§g†•Dê¹S,ºQ­€]>TÃ.X
»”ÄüU›B]8÷‰­k÷¡²ìè HÛa¢Ùk^ì‘þ'í}ƒE%·š«Ïòâ[ÅRÅÙ,VQ…€Ãù®:Wì ò1x˜ÅÉ„ŽÌ:ÏÃŽ�]é%·{²Èï<v»Ã¾A¦1¹²ð›È9Äîªl«ðËc¯�{0;§°,ÆıÝò[sèñSü�¬št	pb‚¿ˆÛí”&æ¢Aã©Äõ-!_/‚BPfÌÃѯjcîͺ¥¼uß°ÓÀî‹çìÉö7«üÝ%DŸÒF
+ÔÚ½#š4ikíóTF�yžÖÎø	AŠI½–ëÈÀJ7)‘Lkè„·~�ÇÒB¸KØs3ì֤̾ÕB{6é=]óÎÙéyʵ üÂÑQû
+÷§@_8èm¡çö? ¢Ç¦‘]ะ×É ^Â¥ÇWs®Š�N¼â	óy‡è0Óà-\—¡`fo¹÷Þ¢³Ò&S
+Šp×�³Xxçý3SËŸ²Öî´©�–´…Wë¦v¸þ¶_úÙ"d–üSe¡ýYêíÃI� íB}¤ÈÜ`”¹ü.�E÷§�íÖì
+‚HåéBÙ+~²�¸Yé"ÑY^ºÈ‹]¶a{P!>h¬Wáæ,@a&##€)E+6R]¡L˜q“Ëó§G8ëBçŸsJйSjú
+–%ˆß®5[/ty§�åVëÚËè©2—f&,b0C”¼q�bÜ*ÚÕ�æWÒ©=n7]7Çm2ÔÚ$Ú7/5^õÔ?S¶ý®„žÈòNòvÍ�O
éC¥ÜC½‡:R×j1ÉK–pùÁÕ¸´î*ÓŠŒlÈ:á4Ñ¿„0L5‘ð3[j¶]Gp¾€Œ¤Jpïz t(23/L@öcEƒ¶‡I�üy{I6£4ýÃÒDò95‰ÌâaÅÞÖg¸ÆaWž‚i…^››J<Þ&ØÀ©¿ÎèugP:¦ì<}vSs¯j8	À+$f¸”~`ŸAN�0ÍÎy¸ê=(­­UHyJ³þ|²õ™(À¹³o–X³�Û§™E –:b¢Ó”u³ñTÃzÐ4}qƒü£ý
+á_
>ÃkØDG£c’§8²Ï1|°
+‚XXÒ§ßz¤•tC�o¡Æg$‚>½Q'µ/ÓÚ.÷#SŒ[âa¹ëÎsœa§½ØM Wå³l¦ækÌîØ5>=Ä)ËwôæJ9Wvg«ÞkËŽ2|–‡‚{‚µ='æà9§/[ÙÌT‚Dó†çʳŠ–žyÂϤF¯õÙ]eÿ¾Ød^"„þ J¶ÔÇ:ÅÄ�zê9�âMÂh³#P7œ¢»£…ÀÙkšžò7(P‘ÅÈP€òaÒ•éÀ}ÝöëŠ,$ê&€×VÖ@b)]‚níòÔgê?Î.
X½VÖz°bŸžãÛøà3у¿[B!¬¸à‹0|ù¬°1¾Ì%Y¶RhÇæüÅõ�¼LçÝbÍ”lsœRK'äîP÷ÕJò5äÐ:^¼lµþ¨æ/-"H:%§`#¾èµKv’cdò¦daYŠòTaØ	ÃløK.»VµÖ"ÔÇ”Ýè ËF0QÃ7šÑájR°
šðð:?­
+�{ó×Zû0'æ^­^TK‰)—&ž×aj ¨%ùìczÉ€a÷ô…¦‰^n¸¾‘³:òÉï&/_!•Æ½:0~¾î»ãÉ„G
su©“4ûºVÔn:-}5Ä}ŠRúãmïåªàªskŽÌÛd‰…(U¡\ÂzµMÄ©
ÑEÅnDµº
“o,zŠþJH0ÿ\™Úkõ»mqWE)×¼Èî�ÐÖ̺þâîocé»Ž[œI“QW$JÛJj¸ºÂ)'Ÿ%Õ)A3uñFéж۵
+õÇ*"Åô»ß8~¡¸à~†‹!‰zךb§Êg´‹æ¯}oÔý¢àÐæaiCÇn/‡‘?,
ÊÊ­æm�»Iƒ¬~©§à¯áâñZyó§ú™Š‡úx®ãª)§øÆRtpÄÌÌUÎ�z+ö$ÎÖÌÇOŠ¯ÏLªh’€¹e�ÒK�Û¡IâGhÒ˜åS”	$¾5(D[	Vx±Ò/¡Ê‘…kTzÏJë À.Ç_N¸wKÍ:4bu‚jðtg¥�+û”HåbÐÊhªôŠð%ªÔ™Á,–ĵ½A¼jŸŸr‚SÛ ôözF¼ëDÈNØ£ô¨1©þÁVG ÒÑœD¥ˆ}™’ˆFV†#s¹RI�)­p¿ÎwŽÂ/Pcé×ßט½<ŸjØtVmÇÈ¿®’RŠTC°p¢íßj]ºç²ç` ¾@ËÁÛƒ…Ô ð÷åΚ
ó"v#ڬ͡F«
+ø©,_ëgi%}
+‡ÛÖ+·ž"-´é¨Zî.K–Ø�¹®ÓúÖàp¾W
+%ø>U£{ü~èð¡É`8~}B¾-Z×=üé«XêBù ùùðž^Q@e¼tœ»|ìלPC
+,ùÒ’j¯þ¹òÁ;çlñ{ªýö„—¯K»pNÀk)Óè²É	÷Y«2Ýœz¯9ó%Þ¥ì7þL³ {¿_­…~¹9Lé>¦œaO*x¢¹Ô¨ÏL¿’ñÅWÄi¸žUÑ3l%Ø"pM|C³FvËØAØeˆÜѬ!^íüõñh¤^¢Ü(
+¡/ÍÂaIú]€�á?êù=à"»Ñ¾Èß
¬_ikS?ýsQÈù/ ¶2>ÀTá’¬s.ªÃää; v€)íÛ¢ñ“Ùqoh±
+JO­›ó0#‚ÆÙ±âIýÚÒ®®lÜŠ7£Qâ�xÛ˜ËZeŽü&è?—Ž;þT4ù©Ü4Þû†ÚVyª»jÞqƒi1EY–ËÝ»&µ�­6BØ内êÝÒ1ñ!„c41ïýÖº
Ў锉WŠAkxg}¸ƒQ0w}+õ¤ì/ÙO)O
â�Šžt$màVg†CÊ\?/iÑwi5ô¶_W.ó®í$gÁu�šã´a•F&;ÂÌY…	ÊðrÉ"Ì�Ë–#¹<¯•”å,N1Ä«2n´Íõn³§ªG¯ˆ&‹a y‚sº‰ËÖíŠ
+¬C@º6¥_ž¼6<K6ÆvÔ
+v÷wÛ8Áß×ý¨iù1�=ÕàË[cw<Iz7»„ÆËeÀ´°Ùf.Ý“Õ;jÇ�B†#ê¨
•ãL”2^ßw%éøh„¹›UùuºJ�5=«6âA5{¨½]OøŬ]c2œ³>4®‚ŒÑêÈÁž˜iê;©Å�¾sU±w�e�ÚëâQ«TqïëìñÖɱ?~ÜËô&Ø!骮¶¦¿®ˆ2™Q¿ôƒÊ�²¦ˆêÝJ_®x¬[9Ÿˆï%ßÏÃÿXTUµês‰›$½H£7Š¯
+å+P¨7ùuW­@Ùò9ÿƒÖ«œm®z5åqÔüGš{ÜEÈOÔæJä4걨ÇN3ôÊ{¢&¸GOo’G
+MP()Ò$š×Ž·Ý/F�†jÖÖ*¿L¼°DüÑJ,Æ@¨£¬!,Zf�92X>À�~Њz'0E–œSL<Šp¯”¯Cºå}ýš�à]²ß¤`ŸðJß®¹‘JÄšTß(ÂT&
+î€þT·bgJÂÿ\[!�;‡Nµ`ÔhH:óƒËž$)úµJÐßù‘ëBXѸq•©eÝ÷Ûp�Ìc¹Û²
+ñlF»ÄË´“î‰Yi	RÔtõ«= :tIBd•Îͼz54fsÁ�¯jÃ-0D¥êÙ›Ö½üpë¨Õ¥œ$2Í…Š¿uËÞðSëu€¬’.ï¨Ñ�†6oîjŒ&r#ùÀ²(º)
+34‹>úË—âl¸ê)8•�C7ðÒƒ¤kUǸ¹€//É×`rHRôHåý5KÅMOÚ�9ýà{/*�ƒæ,¼HÂƶ‡©gþxvç’†"²
+²¦!<]ƒ±�Ë¿í‰HYFù•èŽ^KshšQ’b½Ž=GÕ-=²&‡æéï¹z¡ÉwZÕ–W¦$¥­é,ÿŸ‹’óé¿ßým¨½™4Ý(‡.ÈVÞgØ	â…#“¾™û½¬Æ±nùêNíæóuŽÁÃBØÕÕpÃDÉ«[5“+£H5?¼üÆ.�ÙÆùT¨41ººí1Åú%ÎáØ¡*#å±?ªDúÐaó‰ú00wÛkÇ­Nó ´ß9ÒÁ¡ÂC
+ïåIÐ}¾ËûÈd–@OBrÎ"ˆÉã,#’Ë$OoÞ
+w | »âÂöÛ´Týrˆ/ºËè8ˆÙãÐ8m-,ªŒ£ÛÃåéíZ{[„ðKšçß%[M"
+ú"Aîû˜ƒs†#X}æÌ—¸~6³1*5Å-�:X¦r½U\‹EˆföŸ
+æåS=¼ÒÖP9û;	¶R>Eã¥4ä ñ¥DöLå«ß"­ZìÆ .5à‘Î/è‡û"îØèMÄK²ea°gýç(E	:¿µ#7­‡
+kµ·¡¶Â 3íÇTIøᮿR­´ x�Þä¤~À2KY¸7§FtP‹õ*ZÌÃÀ“ï}Ô÷á…÷`âðER߶@¦Æø"ê^3H*Í�céZG¥~?ŠîÖcÐw¥¶7αÎ_zkBâ½ÈþvÕ¼[Š"e'ä
±ï¡¯‚º&Õ‰ï¶/¾à~áãCºƒÑWÀÆÇŒ~¶ê E—ì	v¥÷‡ß?Æ&*Ï“âsÀlÕHú”í,ôœà×›CâܗWJûmð3º^LrŠt›ì4?æ÷bÙ†Æ`’Ôi(„%|H%"JmŠŠÆ,6�#9“w§Œ{ñŠŸ‚×ÂþÈÝ=óæüçس¹Ì�ÑÉB²$²î4ªÂ»ôöòƒçž+mÂá¨ÿ•%§:¿ÞܧþwLÑ9­å¾HeV˜zcÎVN
+îÛ7ü‡×û
+²VÄÒ`.à›W—û·ëŒÓ²{9?Š/ÄB/�‚@ñ9RW~ÑÀ¥ŽJûáÞ¹¨ÇÓoÚ1À³‹0zhIÊ$@¤¦>Z¸3W\pnŽó�î|#~�PWþó&¶Þ�Uõ§<”s‰,ÊØh>„ªÇ-�WôÙjäkËom=8_
+¸
+Í6Ë<�dÿvÐ7Äëx.#r ]ª’ÆP’}ÀÏ,˜z¤*†—ä&½ò-€M�X=¶©¤'UÍs5rbƒú#&Š;~X�ûª«´Û;sÇÉ­'³zY#Ûf²‰t¤RW'u% 7ÙÅÀħ¸ÇòåOËÔ.ª‰™�ë�21ûZ©lT·B3KÈz_zcŸ{ÞHÅ&e‚ó¶ˆ�Æ{Á”ñE½¼»Üš‘ê‚FÚ±AGB¯Þ-åùçÂèmmz“åïáNQÅ¢6—3poÄõ0òb[×¾«ê´&gtN&=ëõšÀ­çøö�^Ëê&×).•
+4…)Ö
ºÐ1/ÀÞŸwu­ZFpd÷KñÛIÄàŸÊŽ¼°<Ý0’]ù{ÁO èp¦C×¥âHv¿ù7í¤š~JµbìIúzÇYŽí;7@VäÓñ»Í-åpª·~½‰*xÔPdlÕã£?•`ù8n‰’^;+SÄSÐá�ÐdJŸz“8(ö=XX–Á†h\.›Ãá+Þ
Ÿ…xCÖž²JSæmÄ[	h}*;ò­bj�»IÐ#ö\[¦Ü.?3ßø–ÀÕ,úIީПkó‹Húê,­¹>0æÉ2Æ]IÓOÌ v]²H—Îy©JÞ$"ÿþz¢19¤ÍƒƒWÁˤyù@\Éö’‚Zö‡+‡M4ë4¤´èXù–ç´$êø?G;ŠáÖM÷£ûdŽEß‘R´5ÏRÒ»¾tµwÙØ~ó+ûýyVQBÂââ±ÆIz½ØŽ'4t™gOóIbJ¥‚œÍ ~¹Šôá—K¤²ÌÃ�î<ó;Õc–ÎŽ“–n÷…Ùn•am1®ö~`–`?“-Çë~-" £¤oåí£6•vtQŽ¿CêV‰>j†ŸÍk�Ön§tAîp¶üálæUÔ ÀØPRtZ”kkDV‹9Ñl¿÷˜Ï…pÖþ£æ™i‘¬²UÑMñÁØ¥†jY �ÜÔðBîšu¾rš#P®É9•8®TÎ…ž›v3˜p#œ;@í¿Äõÿà"ð
€GFG„Á#C¸þZo|±endstream
 endobj
-1228 0 obj <<
+1238 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2725 0 R
+/Encoding 2737 0 R
 /FirstChar 34
 /LastChar 125
-/Widths 2735 0 R
-/BaseFont /ZQVRUQ+NimbusMonL-Bold
-/FontDescriptor 1226 0 R
+/Widths 2747 0 R
+/BaseFont /INHFQM+NimbusMonL-Bold
+/FontDescriptor 1236 0 R
 >> endobj
-1226 0 obj <<
+1236 0 obj <<
 /Ascent 624
 /CapHeight 552
 /Descent -126
-/FontName /ZQVRUQ+NimbusMonL-Bold
+/FontName /INHFQM+NimbusMonL-Bold
 /ItalicAngle 0
 /StemV 101
 /XHeight 439
 /FontBBox [-43 -278 681 871]
 /Flags 4
 /CharSet (/quotedbl/numbersign/quoteright/parenleft/parenright/plus/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/equal/at/A/B/C/D/E/F/G/H/I/K/M/N/O/R/S/T/W/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright)
-/FontFile 1227 0 R
+/FontFile 1237 0 R
 >> endobj
-2735 0 obj
+2747 0 obj
 [600 600 0 0 0 600 600 600 0 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 0 0 600 600 600 600 600 600 600 600 600 600 0 600 0 600 600 600 0 0 600 600 600 0 0 600 0 0 600 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
 endobj
-1207 0 obj <<
+1217 0 obj <<
 /Length1 1612
 /Length2 18760
 /Length3 532
@@ -13892,7 +13939,7 @@ endobj
 >>
 stream
 xÚ¬·ctåßÖ&›£’Û¶mWœT²cÛ¶m§bÛ¶]±*¶­[ÿsºûíqnß/}ß{Œßšxæ3ç3×c“)ªÐ	ÛþŠÛÚ8Ñ1Ñ3räÍ­:;ÊÙÚÈÒ)M�
�lpdd"@C's[QC' 7@h
˜™
L\\\pd
-ŠšRò
+ŠšRò
 üªm{|ÓÂv¸*Þk‚駹?ÛÜ—Ní>ö¥©F{1­(zR€—ùøÞ$T}¨›ä4
z%ˆégQžW‹²ÛZìŒê»“JÊzÅïPߧ;X`®ž¨üH\
 üÐIí�|ŒRëc1:QA¾Õžž‘'?=RŽ�õÜ@öíãÑäÄÂ’ñ¸@ ’GúÙçà	h©Ux†SA¥7!àÝ´_}jt{êå‘‘â’FX˾*šæ¯Ù´Ë¾'A¦·ð&Ê9H¶îWþÀ¼žŸŽäJœæšËýZw&sÄâmŸ
 ì¿�µ$
œÉ„®'~
@@ -13973,35 +14020,35 @@ i¿5xÑ@>,Ïu> w?tiÓ¶0ûôIÏä#%(ù‰ö
 ^hâŒð·¹ œ£“hZ™Í/øÅ_à7œÀ+P�¸¸&&êåî$+Nȶp®Ô
~I(�–»c¹ÚŸYªÓÅg¶%ø¥p%ö>­’H¾iL¿\ÚõÐß(¦µâ_«8Cƒ—R{‹
 Žµrð¦ëØíû‹0Ê{‡˜ÊQê¸2‰«Zœa‰ƒ†*7Äc¹äJî„I›ÏüìÒ]©æÁ 1=Š¡å©òñS€MX¡¥�GMøªéþP¢‹:*½ÙOT9†ÜD¨*ÀzÞÃ*Úž�“¬ÿ°Ë_hg
 ‚œ«ê9ŸjˆŠ"J7Þ®(ðhT(ìâ ª¦¼ÜðÊ™§Ä‹V¬áÝq
-oò]ç}£¯9B‘7õ·	ö�œH{È­�’ëæi`T&éVÇãs"¹‡‡ªÃßÛçVMo¼iá÷׈â{C„^×;¿_g¿`,·÷þ2
Ún“
RÂɫǶ]ÅjÍuib°ƒãÏV!QÏÆ>²¦aO<ö”ñOÁxƒªH²$áófe°§Åû›ê�¥úКxÇÑiêÅà>ò$­–Ìy"-Ú-ŵ ôý‰¤�Ëq�¸ŠÖˆÕ"™[�Ø m¥cA¸¶¹"t8Q+P�K¥ìó÷Ñ”¶ëÛãh_“	®$��+ƒº‡¼S¾ÎúÜþµ$áØ™éezv~7EhÅZÞ‚¥ÓªãHÝ�åûm®Ý‘(ãŸÄ"Þïòwnúê›�»ÉÕ”^«¦
+oò]ç}£¯9B‘7õ·	ö�œH{È­�’ëæi`T&éVÇãs"¹‡‡ªÃßÛçVMo¼iá÷׈â{C„^×;¿_g¿`,·÷þ2
Ún“
RÂɫǶ]ÅjÍuib°ƒãÏV!QÏÆ>²¦aO<ö”ñOÁxƒªH²$áófe°§Åû›ê�¥úКxÇÑiêÅà>ò$­–Ìy"-Ú-ŵ ôý‰¤�Ëq�¸ŠÖˆÕ"™[�Ø m¥cA¸¶¹"t8Q+P�K¥ìó÷Ñ”¶ëÛãh_“	®$��+ƒº‡¼S¾ÎúÜþµ$áØ™éezv~7EhÅZÞ‚¥ÓªãHÝ�åûm®Ý‘(ãŸÄ"Þïòwnúê›�»ÉÕ”^«¦
 endobj
-1208 0 obj <<
+1218 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2725 0 R
+/Encoding 2737 0 R
 /FirstChar 33
 /LastChar 125
-/Widths 2736 0 R
-/BaseFont /JOHRCV+NimbusMonL-Regu
-/FontDescriptor 1206 0 R
+/Widths 2748 0 R
+/BaseFont /NYTWVE+NimbusMonL-Regu
+/FontDescriptor 1216 0 R
 >> endobj
-1206 0 obj <<
+1216 0 obj <<
 /Ascent 625
 /CapHeight 557
 /Descent -147
-/FontName /JOHRCV+NimbusMonL-Regu
+/FontName /NYTWVE+NimbusMonL-Regu
 /ItalicAngle 0
 /StemV 41
 /XHeight 426
 /FontBBox [-12 -237 650 811]
 /Flags 4
 /CharSet (/exclam/quotedbl/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/less/equal/greater/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/underscore/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright)
-/FontFile 1207 0 R
+/FontFile 1217 0 R
 >> endobj
-2736 0 obj
+2748 0 obj
 [600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
 endobj
-1150 0 obj <<
+1160 0 obj <<
 /Length1 1620
 /Length2 20127
 /Length3 532
@@ -14009,66 +14056,76 @@ endobj
 /Filter /FlateDecode
 >>
 stream
-xÚ¬ºct¤]·.Ûv*I§cul'[£b§bÛ¶mÛ¶­Ží¤cwý¼ï·÷>cŸóëœý£jÜk^s^×Zë5FQ’)ª0›Ø
%ìlA,ŒÌ<
-šþô­¯�œtG
Lz¥ÈéQž7K²;P?8˜Õ�ö¦””õJ>`ˆg:Yánžiü(\
-ü°¾<Ù£ø§6Äbw¡5�aÔž_|M<}~¢î½…î?$¤Ë‰…§äu�Bþéç�C(øC­B¼ªùÕi{Ju¡glŸÏÏìC(»ƒ¢ÈbÓËZÁçjð§fÌÁpC@¶
-¦éÂú”/é�„ÐaF)¹ìÉT_Äü	AÇDF@’_²–
z¿IÂ>^"ò“£œŸpÖj×Ñm¡HNZ¬¹Šù—;Ão{ô«OŠ—©�š}¾ŽÈïqM gÀÁõ@‰Î
-vÌó_ŸäsýðKÞ`zŒ—6$Aïܪ“³ÖUªÔ¼qTÉŒ!ÝNë”›Å/˜4ú#pöpò>ÙMB�ˆÁrêM<õlb®‚‡é‹à\jÑhŽ!··qèš–í:—…u>5±“ª——‡³›G
¿:×MÎ{òεÁéKœJC·Ò@µ¾/)qpgŸ”­µí‚ ¨•Šgý�´»Û]^ÕÞƒÛ1Ü ½û߬Dþµß™á…°ä]xŠ©9
-b¤H#øÕVh@û€€Æjý)ûƒe{’Ó
-3 á"Å8a¶ÌýhC©
Š‚¡|«ßÎ[ÖGÏ3“GDBI‘�Z8«µ¯öºÛK
-’wi¡´NºóoI^0Õ–ÎÈ�!C6פ AÅjc›a˜LÁýäü>wiúÁЧ('Q_´d¶lAS¬Ôæ‡äaí
øîyNM×iÙòD³."KÂ.38°n
-ݱÍAïOÇ4å|cåžä½Ë™à˺_…¤Bcbœp%ÉU™
xíŒ`#Ë}Cºûð¥H"¹ºå)çØÑYi#,ج¿ßÁ;QÝqç·Äjí(^&+
MÌøkRÐ,7÷u¾!+o­¹
-}�iC¼HBbÛ*
1'O. Íþ~6'jïý˜ñ+gt5û¢PVÔÿ¤˜¿T?ÚãÔR¨�s(S¡šq¹"yV‡ôî@v¨„3ëÔHG¹çòšu´ÉÅQ›8Ô%âÛV†w>ðÛe�ã‘[‹}�­H}öA÷4OöÖgí
-„7N•{œP¾©3¹¥Œ�/Ä[Ö]ªp­Cƒ’½f±eB8|*ÿá´%Q0d’hyŽÏË9€œH7þ5'i}=½ó{LXwÜëaä6Aº„ï5Ëo7F—Aµbñ#¹‰…O[?ˆny=¯7…³¾ÏÆ_žMSÑÓ<Ÿj²�¹O-ÄËOrlºÈ|!•¡À�ºüV„,y©+¥,ßê¹2š_Sûà£#üåž·${qÛF2<üm=àmûS}ü{/°¥ÖÌ:i­‚ƒ‹\’³¦ææŒ"×îS©ÄÙM>?gЀñ¤kMí!,£sê-Ð@‘œm
-ï™°H¯Ñq<)XÍe.vUÀŒ‹Ææ6¼j÷(OóÈŠ¨ð"AÏ@ä_ÞžX$#–alxUeh[fdþ.Þ
_lÔæ8-®(˜ÙÉë¾—©)ZóÕŸ
-Ôû´Þܼõz2‹÷¤#‚JÇ_N‚aºäYCÏ>\�z…„–gĈÏs³Ìjd¨¦!X�¸ˆÓwÜ2mö�8Ùp!os´C?yTÿ@[Qc×Üÿq…ÒŽ�¥Á=5(æΡm³×	ÔIìÑ/�Ôa1VGKj]Ø w´Ú}oä¿8A#çÁ°\SêœM,ZkyÀºHí(¨ ·³ÔŠSñçöš]MC~ÌTŸÜ¤Pg}÷p€‡€
J¥'Þ fØ‘Vý"‡øí�bÇdsªÝ�ë~£vz-t±~ŸU²ôn5\±ìÕµIýS«Uÿ	>¢KóHšÃmµ[»nKYݼ øËÈ|(ÚÍs@w³™ >sϽ°V…–šü	®�ÙÞÇ+×Xª‰‘†€9õUW«K8†?é
`(zšŒÜ›×Io_eîÁ‘�Í>&p×$ÏoLòŠJß´/õý…›R-“�ÃOÃÄ,Á‰ þØFá�ÒÓ�ýâùu.Í­Ž©X€²£Ý�F:û�L@¥å߸‰+¸CVçD§›î$2ܘ±­¤�‚Tô¦:‡4Oòü?ŒÙì7ØC*™VBÆò6Vjó­šÛ¾§
÷fÝÆ1÷ídž
¿ô|�ÒÞÞ@OBG��	À§˜«T ˜Ã1=Úuø1&\ÛTĉº(Ð64Ï›§¼ì¥—¿ž6ÇnÚ4~ÆcÅÛ[zFbÆ’RJ»žƒ.¶¡ÖkŽãÃÞDþÈÉ+GâzƒîÔ¹m_C|øþ0�/�–
­Xµ³-`_1+Rå¬Ë¸ƒðžM*&`*ó|ÜTF-ò\<óãT¢
-
-
-à+N‰Ø5ÚNjÔÐY›€¨áà�ݵiï+Zf;ˆ?Çåe³ÙvWà·kŸÒÅ�üµ—¢I¹ë´“F4{½*-5	…)<m‰‘·iîúó…sA€fÌTljò‰¹^›]¿w›H.’îŠI†m¸_|óÚ»b \ÝÛ�è#Úžƒðž1Êê
×åã–μmœh³fË]­Ú¸¤„ž¯\ÇišÒ}EK¶
õ»›�õx}3sŵÈûÔM¿=�i‹ƒ)»o)=26¢QžÉªËC†;ß5T]hQ€Ð^šŸmúà|‰Z›�!ç˜8ºs±S°È¾J¬f?ÝëÞìoåCˆ€ßlOŒ‰¯¸1]§Uxœ<Šzæ�᥀•áç=ˆÎmòò‰¿½PÓ1ú”¢>2x¤iÎ#§·5ž.‰©sVñº^ñ¼ëÓýªÀ›`õVÙÅ¢UR¸¼ûpœ“åæ41$ûFÐ8ªŸ8�lV{v”ƒîÞw©�³î~¯ìýý�«&À꾃~èôÓEKå½ây­
Dj”¹÷-vá'†H=~€Œøä“þܦð!UMÌÆ‚qzÝKs"œÏòçžNIZÇ&s™/í}‡•‚ðQE´¶å
ï¼1àE˜»×AÖö¹›€Ú8!ZŒ�%©u4¶7×)-¹¢þxÏ�ÌŠi#Ò},V{ 3ê™Lk0Ûd±À1èÙýåÇN@ˆ<E¾=\�Ðwö\#·Sä‡ó Ìµì¬j‰um‚Þ>ñ€ÖXzdöi¢ð»†¢”YµÇÙ¹þÕ‚ÅmË.»ÎÅ)6>NSã"jú¦HËèË­LnE™ƒ¦üÂKh°ï_ŽÆˆ\RÙßC*  5¦
T(´eLjÔ9úÞÓ…eñrWtA…¤ÙlõtŽcKª¿ÔL©ÓšïÃÍCm á‚cÆó7ªÓû:³HAÁÏÑ�×$k!å8Õ#[;mñW¨$¥„ÊQã]T”PpÎÊ©j0)¤p)8H‹Ûä—4ÞÌd9ãYVä]mze;ûµª��.ò+ÜôÖƼ9+C­…ŒµÍ7ÈÀaÀõñú%B{PçÑó²ŒG>¦ï\8ÞÓ�>\ùë
-�¾07ÙtîRÝçP{myZí2÷<ijœçâzxÒô£'2ºñÉþD–£,
9tÞ±¾vR§ðSpCŠ%è²³O»¢‘χæhÇeUfL†öH�)”éßѦ"¥2¦TVÞ¤Vx/>’^Ž³Š$pEÚŸºþ<˜÷�|š�‡+œüäî˜j
-º.F5|EKÖ_kß
U­†Ä&“ó"÷•€äûdÎ…#æ›5åØK�"20¬.Fí¢Jà(2\࢚z~"‚*X¸×”•›¹
-=�‰Œ!�‹2ZK
…‹3…~`ÊòJ&qðmvpˆ;¢¬¬Õ¼}ÜtЈD½N¸Q/pÏÐ@Øy)diDÿD¡
-ÛIX¨_QW:ÿµ
]úÐÀï9Lœ`]fd„ú1ØñœÖʨó™¢r
-EþØÜlgøÕ_:jûìe‚¡¡¬
-M
q‚8IoÜ•ªÅö›ÍL-Ô…`€ToÞ½*Pvz:N“x›ÝžÜ™3*IŸeÀ4µô
-;S9Á%]9Ao¢ÁN©‡�’p6/€ôJš6:7õ"élÈ2îqœÞ܃A«ñ)Û«Â!F—?+Íõ­ÙV³d$7ÁÌ&áýWW(Þg0 ÎÜ#Úž8¤;ßJì­¯ý‰Ù¡L¹ŒÙOÝ5oYÖá˜
-AÒà}…a™5‚>ÂÃNFØX4²–€žÞri¸™½‹…:'é‹NÎXªËQ±lC#Ë4’w‰ùŸÈ>ßOºÒLZx¯dTH‘™‡Ø*:ÑP=<Ylc<¢„%V­ù3nË
½H¼!›Å.raìþ“¼ù÷Y:›Îxf‘…H^#ü¡ æh
-ø>@[›CQƒi«m®þ²´!
-ÚÕìΨWtŠã?oAZdævò6I›¼)’þ‰èRUÛÌ(Á@Ú”µ²�âa»¦Ð£ñ	Ûå²ÛšÖ/ì¬ý&Å%é¾ACF÷êÏa¶šƒ;öùZjûâÛQBÙ„ãÇ�‰ÎYIN«ä…{Ïy|—hX®t²RML‡WK&�q¨aEPjÍ�–_ê›Í2ÒÙmYL¡£Ý§ÎŒrêgsÓ¯NãÚ‹+A׃²„7g¨ëÞÊN óké…%¦~aÝ–o¥­~F¼».û#3{9D«Áä1;â´æÍôQôÃZ�Ïú�8w&_a†¶j¡ã÷q ´r©>Ý}~9ÃQ‡“¹ý
ñQËöš‚¸¸ÅÒRß�
-nº_Ø;úáW„ZÏ(œd ÆÅÕ>¤õ„‹ÁêÍ¢*qöŒ‚#röwQ;£œjÚÆ^kNÿyŠÕzÁ<S€\ìæ�¬#
-)¬¹YQkfb
-<Æê>	tjY×rCD[")Q’£#˜Øn]Ìcõ(ð(»CÈ=g}¶F`³k940Œܧk¤ÿe:ä#_tRáYL©£½N‡íAKZ'	KLH§£tvH¶�ÐSÑe6óSò<ø]©k>¿2 GÇNê#u0Uó�QŽÅÕòK»/ó<'\`ÛyæÒ5êLZ íèÄn™çšz‹ˆÆL²˜)ÏvŒX¡�[M5þÉž„�¤´‚o®HõÌLg‡œQäzä<¸±5î6Ýc²±ï.U¨vÉM{bUWåL¼Ù¾Î,mxÙ*û+‚ikX‚â{uõ<„NZ'8ƒ,T¥~Xè%{2Ñ/f>[µª¦Dîïö|Ý¡±šöœ©.q´Ÿ›l¢”„AMãSæKæí3r,ÁãZ<Ë�›¬ïám)œ+h¯zìÏa~¥^�Ø‹Yºxà½M67­
-}¾Q@<gäÍd}ßÜ-âãf††Çª§è·à^.@­uz¥@”M|Ý�°Ìì4ÒÊ
-à™<=²!>°ë_Â!¡nÒ
q£^c7Nh?–Dbk]z‘Zøù·Íà[ÛX=mÅ›P
:žž‰ÍW½G°tC#<áß×�VÂ'¦ŠÒyÞ�Ä1ò\ðÎòˆ¿ƒˆ§9&åŒÂT«âÞ°;¯oQ
-Äd²’Ø[EÜ­°¿�ÈÇ`n—ÅædþǦiBŠFtù£¿
mŽ<{�töJD|Ï;±Æ&G‚iþco§Àå²-çaA3©±W(æ‚2MYÕô(mò¤	œFã³{gþz&V__éa6ÎÇp›¯ØalĺÃuwðnæ�c"8¡n‡:Ñ!1w‡Í‘˜Ý�¿g•Ã
ˆ%ù[ÛÃÞI‘nÓåÙ–~gdº/~û¬ugÉp¡`ÁPþôTiHŸì2\)ÜЙÍàÿ®ºþ0æ‡z�x)œE½ Úéq;7,¦ýs¸ƒ,ª‡izÕ­é
ü*ið¾\~]•mî§Æ Æ
K•!ì†ß�!ou4›¿›û‹†«ðw<«�^UG‰/)cy¯$Ë‹>tä�CÔž•6rеð‚jåº)×ä;æC'17'IÙŬõ1:Ï–¼pV%¤»Ã
-2°ÅѦyWýö¾¥jÖÎŒUËü«üÂ@�¹,íðÊ&�©¾JèS"§oóZ²,¢t
-’úC¡ãa4Ÿ—7C‘ªÜ݃~Z¨‹ˆÃ©µ»*‡‚s·@qp![~_£Œ¿�:[8&‹”ŽËNp€0ËtÃ"�¤�ü4q%¬i¨•�F³høð¡<uÖñ¾î7iÞßÐ�äS)–óãIÌ)¶é¿Õ+[ò5L\Ö*ãÍZóÊgDسö@WÎìÖ1üÊ,o>HÁ81äÑ�˜=Þü2¶ã³âL˜lƒK¯:ÏÂiåsB¢/]ûP6
-Q+ª''a¯¥¯óm@�6úâçòg}»°4ï N–³š¬0ìHñëà´Po|®RÎhkÏ–T…£¿» ”àá€#V‰YR³ŠÅ·R�ßx°îV&£Ìy«úEê¥Äyêî‰;|0üŸ¸Opˆ`Ôæ:5 ×
-dž°Åû€{ò$#ïˆÚrþ÷øúø
-Ažˆ+‰o徑ù^ÄWòó
-þ¤a;åR6¨¹;áD]ëVsGm½˜¤îý�‚(Œ3î}
ìfˆ¦»ÖÔÊËÅ!’uÒPPÝöF5ñ;êO"•—ni2õˆbg+€ã–¦ÜÛ%çŸoÚˣǦÅ|É)–C¹,Å‹ñìSÑ.”Qƒ—#l	)tæúnÙ‡')ó×LMšýLsi|¼�n°Q!gZŠƒp2Äòf;|d·sJ5[èOú»·r•	
-¹0>“Q80ƒÁ˜jU¥9�Ã�üró5½C£öñ²·Ëä—A<Õ¦¡1RÁgó[¼X-	?¼§µebÑ×k^6*ÙJ¬(І¦7Ü1)ºPïNଛ/r§tªX¥õø&™ ¥ƒÆôÏážµÓfÇH­öõŒ’°.ÛJó9øP>µe't§l†ƒì1M¾#,Çä1¾�#Ü­ÕÄš#[ÀN).·E¶/°6~ª§ˆÄ•T1˜�ôY¶#ß:a³áI]ï¡‘g=㟗ì26®�HZÄ+ØÃîk
-z|~ÝX!ö×½’F`à[m”Ý»”}«SqÁM÷]»&ÃÍÝùԛꚥ‘�ü…@ÏHÈúûÓnê
-c—™X�úAÒœü.;
®¯˜›'·Œ©½C�›ˆ^zºnõâ塳ýæzI‡•
-RÐ%åØWÔ糖Î;ÇOÏØŒI“ëö�L%Ç’,úÛ¼F¬>žÜÁ|á™ôaײ�Í4˜m?3’V=·_L=Rx;`‚i<’kav`Äóè
·¶²ú0
-pºs*Å"øVŸûå¦ä!¥`˜nƒ³ß+ó+ŽµÐ
-çøx£ƒ®Ñãz#ú€½ãJÿ
y‘ÃEäºF•“Róª»ÿø†D�¯11tü@Ct´Y$Á¼šGj™¯%?¼äX+å•?L¤ÔÛ˜‡Í”_´Ò#(?Êô\˜ã@¨nw"àYl™À�<”w„ÙY)ª5avQÿÊ%éömŒ—êÆ5=–AâŒ*$$–-Ò{OcŒËüŒÖ3n¡÷j¦&•3ì£Ç€ÄY+÷U&‡Zg\'ãMnÿ@÷W¢4’:zvlAÚ”‘…‡’>é„Üo¦˜Vü_Ù¹šÇ};*ˆux’ÆC,(¨ƒ|ýÜñ¹Ú÷zw¹�
-£fÍ6•9í]ØTÉ°b�µ÷áú1K/š&‘9€‡e×¢hœj4Šß.Î[)Z
-�dCŽREm46¬8Ó¥N¸ «Ô6<É,ÆÐÍÉÎæi:ýx(¥Ët8ÐËn ÿ`’®!
-¼ë0å ®ÏØ¿îZïܪc~[Q7µê4è�©Hšñq‡Ôø°7ò=­³ž‰’§™òÆú˜“duˆ?ÎÕ+r^9kæÖq槜a^NžbÁ�:ÐÞ“ªC=>JÅЕd›dg‡¼]ÕúˆËz@øeaªCšs5z Q/FÐé­Dú÷8È«âX²D›íŽO@Ñ%
U÷Méd>kZ|èdü%ÎÐ?,cYÎMw5ÊÃÃ�P|øTëZBŒåæxM~`Ô•ä×P
-Ïoé†-Ë»ç² ¹
Y¶ñ­Î±‹èÞÛ°ëÙC¼aŸèß7嶸מ
-뜻%CAÌ‚¬UV´‰Maü€¤Ï¹uñçó„áÜêÀ:œð؃CÛ(|#º�É&ÇëéòɼÏÈ8GÙx被Š³p<BÌýÀ�«›[¤Êñ+ÇÕ˳ž8b׈×[ÍT|­¥#NùæQߧC�W�;Gˆ|SmÿFÞÖil±^õãþ™ef C¹‡¸·á¢y	JòëL;˜L]¸îÙÙeÂAÚbˆPAIÛdðIÔPîÅ
-×·³÷ŒAÿÞ]ÿ¹:#¥µIä
-ÑÅÛ±åprkBÙûCzÆaÑÓ3ëÌ"!²2ö
]3¾v{ÌÆY­»G«Œs»Oå×náR¤C2¾&`ñNƒ§Eƒ“\ÙÍ9È
&Bê.üŒ¶Ù· nRV'“BV’äýáú%h:¾.l¶CÑy%4KÉÂ�TÙfÝ4�„T�·:ùÔÖ4_'áULšj�€�žXËÜý¤öiûÃÆûêç”´c§=`²¨øqªe˜ßC´Ü¥îóÚlméòù
-H¦�Ö¼9Gž¸M‡ô�º„�þP¼¡ï
Ò4Š›µ.¾êJøiˆG•Ä$…hÎ�X÷lÕ-DÞßÍ›á/c;§Ü?‚Ë¥9‡l®Ñ{Ä­Æ»òni†n½$›B×:õÒ©~’Xv
-	w/¼ÞU·O§”~EÁÏAç8Q�•|�ðŒGÇ=gý9,?YÁ2Ë<må,*]ß»¹�5HN”¤mf`!”uåIì¦uþÕÕ>2L"ô�ÄEñK‡æPüÚ÷AÍí"I1„'{†§³
úº¿¯c¼NøŒß_lbéøûö—
m„nĜɫí÷Zäo£‚³|t0ó>ú>S‹Â™ÔRú—°zaI�¿ î%ÕA˜">©
•N~ú‚×-†®2-QV�çh-‰úó
ýÞpܹâÛ/–¹"5vÎf—GWnT66þ8éô^úÞu¾4+k‹O
-Òo)³S™2áØ¢c—¶FäKa·\®ó*‡©‘@è�ž›XsIÅXðûh‰ðeýÖ8%W6¤¹¤‹»Ü²yÕŠ½
¢uoUêJP'mͧésŠêø?¹ÄÆŽÞמ+Ü¿eB*£HH�:`rÀL]¿ºH.âØð~}Êη�¡>¼üHÇ8š½D ýâ.ºQÞùÎ_]�Ì—%×Ïت3©W$@2?d…°Õã¾Â`¾²ß³Þ׆>xÊ:ªÔý°™9�•YæÒÊßÞñ˜¥ãë^:?Ü'°‡eIº¼¨-„~ä˦�MÕ7W¥_ÓÞàÁ¥MxqÅß)w¾€Ì}®+È Á‘ÄâGu™.­Y6¸D£‰ý}KCîý§WçRPn"8U+Sœ÷ÂøÌûyvÝôL½3ìüî3QÁš\É–ä>¨UHC{ϊѼ•€Q¹!÷Å“÷.¼?;L9§ZšÒE¾é«v¥Ž}03|­˜6þ–ˆ¶9£,whœ-ÇËŸ­×;?zøpÙÍ„y8àŽ9Ë¥H»Ñ<TÒ>HîÍÄû-q˜˜\—1άÄ.5HLU�c�ß|{�¨8óŒ�òZßÔç`ä�ô³ÁPß½Q5åŽèz”=ûŒW0zúU÷Þ r	còRˆžÿžDC
h-&¦)¬u#Å>"1™k–ôÿ»�žÍÌÃ�á±N”vD#¹¢A窠›`_ÝxXÒÈwgÞ„ÏÙå솋ÛÈK+´CܦA"�Ê
-âc§x~XÃJ�o(¦cé;‚÷ÿ¨š#1âŽøé}SUx °f=”4+ÿ䎧õZ›…H
-—€_úØî�*Ý– ·£ý7<³Y6ªãvl¤ÎݱæŒú‹Ù¸™‡ÈÈc?m·Ò†h¡ˆÕ©Åç•¥RäÍ×”»L|âÊLwõø
Ρò°¤¼AçYKr¼Ï¹ÙÖJÑkW½b%òy�Q·ŠTæ9æ‹Ló"$N¬½ôž‡�9ȯòL¡åùö;û�¿ZÆMú›�¦Ýj{wAÆILTI¨£%èÔ&ë�ö…ôâÞ %§½(1ã:«/h•¶�µôÕ9óUÖô”�‘­Í¡i¬rÝxUæ¸ÂÝPÂ#á61”#,*@Š
–üb±·Tx8ÙÄç{ëG79yçÐê°ÀCþ“væ$Põ`Ò匀V–ƒÿþu6®%…Ùqc†¬Ó:†wtÎì•NôwØÒPÄv©*û&<û'ý�výЊâ¹!ÔA"OýMBð¼"ðÛQܸ…ÍK)	z²>Ç'áØóô-oâŠÌ#°±ÛÓ�­ÀD/&Ësgk7/;ô^D÷‡ÞKÉÁ¤ ŸCH-²oS<ÛõCoõšÂÛw˜´øŒª�"ØK–_Š­"H‘¬ûVpÆsáõpa¡�£_Ì×SÈÚua¯õ°Ü±l|ÚV±{+	wókÎ:¤6=s÷(HfUôRê¸zP¢[E ïcYÄEùºŽsûr~3§Ÿ°3ŸMÆ�?å¦T‚°ÍZ5ÕèR˜±˜rL‰buO[ˆ`×w\ÁU·?‚‹œWà&ó+Дzu(“	Ø!ÌìÅûR% 2ú§8xdßÿó	<ÌЃ|Šˆîç}®rw‚RÕ:Mp’òÛBÿÉ]˜RòöÖ„½®íX((gÿ¶Ä?ɸ‹e»¿è­ÚXÄ
-Ü�¯*�ù V}ÒD¦ÿôð¥ÎÈ
-}ˆÒçq=G/¦8õ6ÙüÍ/]Z?ó{P>yêU•œµú}éË2&@žÊå:Þä®þ;TÆ
-݂Ư9ÎÖïSftt7,�-–‘hV©©<
®ÙÒ]+,àŒA‡Ø  •;…ÔzEå]þ<Ïßý‹�ÌɤC™Ñ6ïð�ÖR®{
ÒºsŽy�ZÍÒ+±êÈÜôÄk´ѤFÈZ‰!FÝmP€×:%•éd
-Ü)„�lk2'¨á"€”Öó±âµ|syùͱÕe€\ûÊJ;Y�ýMªI­‘_£ƒ~Æ1bfÓõÝd=–ÙþÅ|SÅ=UkΫ
-S­‚DÍ0
-G7ôæøÆnuÒ{«ýef‚‰@Æ�ÚJt'�D©Ñeèb
ÕÓþÿkŸ,Ûš
+xÚ¬ºct¤]·.Ûv*I§cul'ÛFÅNÅFǶm۶͎í¤cwý¼ï·÷>cŸóëœý£jÜk^s^×Zë5FQ’)ª0›Ú%ìí@,ŒÌ<
+…ü5Òß1‡PP[­B¼ªùÕy{Ju¡glŸÏßüC(»ƒ¢ÈrÓÛFÁ÷jð§fÌÁpC`¶
+f†é”/–é�„ÐaÆ)¹–ìÉT_ÄAÇDÆ@G’_²V
ú¿IÂ>^"òœ’£\žpÖk×Ñí HNZl¸Š”»Ào{ö«OŠ—©�™}½ŽÈïqM gÀÁõ@‰Î
+vÌó™\Ÿäsi‹ø'o0=ÆK‘ wnÕÉÙë)ÕiÞ8©dÆ�î�¦uË͈âL8{8yŸì'!HÄ`9õ'žz6±�VÁ‹ÃDp.µh4Ç�ÛÛ8ôÌÊv]ÊB‡ºŒŒžš¿ØKÕËËÃÙÏ£€_�ë%ç=ùäÚâô%N¥¡[é¡Zß—”Ž8¸³OÊÖÚvAÔÊ
+ų
Î:]Ní®¯jï‚?Ú1Ü¡}ú߬Eþ·ß™ã…°ä]x‰©9
+¾@�£dJî'�¾T¨×
+z	õÊøjØNE'·M¼¼²_ÉHËq	zÎ9W±O´à¼¢\Y`Gà^ùa“ñóQýÕùÒ^mš¿RDÓyYÕã�ľ¤w§fküV¥_d•ôúÁï¡qUåM»n<%ò„é±D}^õ…ï9ÜÚ™/˜zšâ.Øè×)ú/…0×�Ο·×rþ¦›§›Ü:;Òé:of\ÛsG§ys÷ÌäxQåç!X[EsèAm®¿NB(^WÄÌoÑÎÉ…qeQoP½'“ÀäŠÛ±vÅTäŠËÔ›Ê`Þ£>G}òxeVÈ#E²Á¯¶b@:4ÖëOØ,Û“œÖ˜�	w÷Ý@)Æ	óeîG£J
(På[ývÞ²
zž¹<ú JŠÔÂY­CµŸÐÝ^R°¼ke�MÒ]@KòB ™ŽtFò°…&eð
+îïø`—÷¹K³†>E9‰ú¢%óeKšb¥6$O÷Àw¯sjºN«–'šuYv™Á�uC0=õ�OS‘GQ‰þ¯Âì{êMüqûÊ¿ûw^³4)pD^W¾i
22øQæBæeëðÄø8Ü+Î(ä€#x2dßë~r%³õç:9ÿ8¯�%è5.�Ý‹IáÊ9ƒnò)6Ý(€É7ÇÅåÑ�Ú:T÷	¼$Ó­jæÏI,n›Ýƒ0C5r¦Ð{Ûôù4uJS·1Q¾àIÞ[°šùq™B·ã§�ThBŒ¢$¹*3„
+j)ÔˆÀ9”‰©P͸\‘<«Cz„	w$;48™un¤£Üó
+yÍ:
+Þäâ¨�Mœj‚ñí*Ã;øí3ÈñÈmľÎV¤>û¢{Ž'ûh„³vÁ›¤ÊŒ=N(ßÔ™Þ‡RÆÇâ-ë-U¸Õ¡AÉ^³Ø1!>•…k;oI™&Z�£Åó²A`þH¤Žš“´¹žÞù=&¬;îõ4vŸ ]Â÷žå·£Ë Z±ÔNnbáÓ1¦[^ÏÂëMᬯij
�ç_ÓTô²È§šl`îSñö—›.²XˆGe(p¤.¿¡
CžFêJ)ËÂÀ€z®Œæ×Ô9øè¹'ÆÂ-ÉÆÞGܶ•[|ÛþTÿÞl©5·	BZ«àà"—䬩¹9£ÈµÿT*qq„ÏÏ4dG<éZS{Ëèœz2T$g€E‡úÅ�3P�&�¶ãäQ,À‹é$‡(YÐF¥›Ýúg¾ÙþËœ;HGŸ€UÏ0/ˆF®A¶¢ºhÝÂüÏɬSŠ›?…ð.zì$�ƒþ¾‰OøBw
F9.é»°{IÛÖ]µYÎÙÛö>….¹©i>Öª®¤Á¹º·t’ÞѱûªÜI
r<Xh[_lÒíÅU1î¤â(ÛŸŒÙÂp—)^ðC7¾è£½k¡ú»¥FÑ…ÝL”ŽˆÃSù8Ø'ȸŽô‹òôÝ´à�vÛ\ûƒªH(dÎWs<eúJR�˜)[ÈùÒ;.ŒÛ=õM"%Z
+H;\æ¦oyd÷5/‚ZY¦Øß
Y‚x/	ÜI(ê_SVò÷O”ßmÛQ(±Ò´È{u½î}"ƒª7àú(˜"äa-/ÅGSkA˜M™�É~¥S/D+âˆä5‘<šèaŒÒeÍž€RŠÕªµ«™£Ö½KxfÕ%S_olË+ÇééG~Žá^׎ÉñHž‹cCñ	ûKÅ	r„i/©ÁX¨Eå[-6áËM*µÖ‡ßQ‘ÒY3œœüÎ$c;¸™îÎôœóð!¢¸†„
À×Ü—Ç+šž\[²7¸¹7ÚÆȈ€Cà[VZÉŽ6|íd›®y>vWL«Ýa%´§AX™ée‹ÇX�ço^´¡€KE-éÍBòŸ’Þ®ü1Ò^Þ€8ä„áU„4‡Ü46
+`YzY,lsÿtψSòé’�üZQ”²8!�Êó@¨`öžnBîàñÃ`N€¥Nw§©Ç!ô$ÕæõÎ%¢�ˆ(­ÙâÐκÒC$‚é‹Q
+=öRþ÷y:×S¨‡Î�G~�.Ílñõ¤1Õß«Øg½ ?o�!==çxQWP8?®~|˜Üÿ¸¾x¿¾tW õ/ŸU®kdY¸Åã–�„ ¯iHxºâñ¸l±˜“¾ž?b™qé®yx@cÏ·è£P(&—.!ÕGÑ‚¢™þ=Wc7Ü1WÏ28'ƒ;2[.ˆxý‘×µèÀ�w,ÔEh@¡3§>WYˆ}ðùaæNy´59ƒ‚Oà
+Û#ñ=X6µÈøÌý/ùj¨5§äÕ‰X¦NëxþU¢lµÅ•¬A2fNyë	BåK@z«1ÅÓÅ¿fÍ�ÈnÿÙÒ©ê¹4mmÒmyŸ;þ-áu
+¶Šy­ŒØœX6$ XbLÖ¯Æë6SÅGó´»
k%¾PjãdÉ\c_¼œMMâ›7IJ�Ñ1è‡ÛÒŒÆîC¡oÖ)ëÆ
+‰}
âx†Ü²t¼Væ–67Î5¥ðž)‹ôÇ“‚õ\æb—qå‘!̸øglnëN�ò4�ü ˆ
+/ôÄ@þåí‰e2bƆwU†ŽUöq`æïâðÅFŽÓ⊂™�¼ná{™š¢5¿áPƒ	
+\ÅT»à^7–4N’’Ÿ»$
$Tƒ-L3éΚ¹¼Ìè-h’T8 @½Okè#�ÁMÁ[¯/³xO:"¨4áxüåäL—<kcèyÇÛb¢q¯�ÐRÐŒñyn–yÍ�Õ4ë1q�ÑŽ{¦í¾1'.ämŽNèÇ!�Êâhkjìšû?nP:±³4¸§†ÅÜ9´mºAº‰=¥“º,fÂêhI­ôNÖ»ï�ü'hä<Vk
+Á�³‰Ek-˜B©äöVZq*
Ü
O³«iÈ�™ê“›ê¬ïžŽð°Á©ôÄÄ;Òª_俽Qì˜ÎcNµ{pÝïbÔNÏ£….Öï³J–Þ­†+–½º5©jµÊâ?ÁGtiÉBs¸¯vëÔm)«[™ïE»yŒãn6Ägî¹ÖªÐR“?Áµ7ßûx ãcå«B55Ö°0§¾ê	cu	Çð'}
+
+ä+N‰Ø5ÞNj4xÐ]›€¨áà�ݵmï+Zf;ˆ?Çåe³ÝöPà·oŸÒÃ�üµ—¢I¹ë¼“F<{½*-5	…)ôcÚ
+#oÓÂíçç‚
+
+8À#D=ÐÚ–'¼ËÆ€7aî^MXÛsänjã„h1B–¤ÖÑØÞt\§´äŠúã=/t2K(¦­H÷±X
ì�̨W2­ál“åÇ W÷í�ÀyŠ|¸`¡ïì¹Æî§È…çÁ™kÙYÔë:½	|â�­±ôÈìÓDáw
E)³*j�³sý«‹ÛV]ö�ŠSl|œf&EÔô5L‘VÑ
V	ºZ™ÜŠ2Mù…%VÐ`ß¿�1¹¦²¿‡T@@jLªPèȘ֨s*ô½§Ëâå®è�
+I³ÙêéœÆ–T©-˜Q§5߇[„þÚ@ÂÇŒçoT§÷sa‘‚‚Ÿ£;?®IÖB,$Êq®G¶qÞâ¯PIJ	•£Æ»¨(¡àœ•SÕ`RHáRp”·Í/i¼™É6vÁ³ªÈ»ÚôÎvñoU;]äW¸é­�ysQ†$Zk›o��ÀëãõO„ö¤Î£ýÁË2Uø˜>¼sUàtO?úp '@úÂÜdÛ¹KuŸCí½ìe½oÄÜóÏrž‹ëéEÓ3ŒžÈèÎ#$ûYjŒ²äØyÇúÚI�ÂOÁu)–8 Çúƒ}Ú
�|þ84G'.«2c2´GÂdL¡ÌàŽ6�(­�1¥²ò&µÂgùð‘ôrœ�P$A€+ÒádˆÐíçÁ¼_äÓôèä8\áä'wÇT`S^JkÊ_HÿΡÇÐïK”.±®:¤vìÓîÓcˆä"AŽ¥Øm¤.l¬È¤÷4³å)¸
+4=_A€ï CÎyëºnlT÷SIÆlBŽãÇD‰gÿ¸e‡Ýl‚È¢s›y|œRJ¥sáŸÆ%÷›oßú§gªDT+êg&Ÿ‡
+û
+ÀáRLæÃ2�–6çW0*¯bö"QÛ8Òœ3,´~~ý¨yܵ±®ƒ!èk÷}“IU?û
+^ºö.ÕÊ;â˜<\éæj�B† :æ‹ãk‡o™ùžËýta˜A=«(ÓÔ'ŸÔÐH•ÄN!z^“kðw¢ëKËŽÌ´«öߪ&ZÎØS³_­ž!¡ÑÐ9†˜mx,by5À,Ù{Ô´9s†s_=ªŒBÑ3ú§ÉÅé7˜MgðRSÙ
aÅL4äÆ�Íœdä’¶î¡ÁZ’Ô§q½ ¸‚’6ˆõA3†Švbwq]o§�æö§%¡×+DðXÚ2ˆPvêð7?³Í®=Dø"EL‰ÁÀ}§Û#WYççÕ"ú­Cø(øºÕèa	,Ù`­}Ta¼R›L΋ÜW’ï“9Ž˜oÖ”c/9ŠÈÀ°º·‹*�£Èp�Oˆjêû‹ª`=à^SVnæ¶ô@&2†4.Ê0h-5zPÖz.Îxúƒ)Ë+™ÆÁ·ÙÃ!îˆF°²VóöqÓA#õ:ãF½À=Caç¥�¥…1‰d1xýº¿ìø2ï«9Œ)Cí$§øV„"	Æ1‰F¢r�nêOèó$9žíÞ�ŠòZ
«>’qXøŒúÑú‡¶úIÛ¦Q!yˆ|¨(wàÌh"¾n£K²ñ�úB©
+/5ˆÝï9éŠ1)ëM÷çY¤Ò\Þ5ö£yLU!?䡳ìšýõÀªi›Ž}Ìn‹‘f^;àQbù¸RÿBr	Ï¿I-9:5Å·À2>ÁÐ3d±†Fˆc,<oäæ£Ocî1ü±St~»|Yù51DP!£í¶“°P
¾¢®tþkºô¡�ßk˜8Á¦ÌØ$õc°ã9­•Qæ3EåŠü±¹ÙÞ–q«¿tÔîÙÛCCY
^"fLzJ 
+ÛnÊ÷Ù'Î{ü®ÒÿŒŒ®AiL–Xg…¸N
+£2„‡�Œ°±hdw,
}ýåÒps9KuN4ÒÝœ°T×£bK؆F–i$Ÿ‹‹'p‘}¾Ÿt¥™´ðÞɨ�"3±Ut¢¡úx²Ø&x4D	K¬ZógÜVú‘xC¶‹]äÂØý9¦yóï³t¶�Úxæ‘…HÞ#ü¡ æh
+ø>_@[›cQƒY«]®Á²´%!
+ÚÕìΨwtŠÓ?oAZdævò6I‡¼)’þ‰èRUÇÜ(Á@Ú”µ²�âi·¦Ð£ñ	ÛåºÛšÖ/ì¢ó&Å%é±ACF÷Àa¾šƒ;öùZjûâ×QBÙŒãÏ�‰ÎYIN«ä�{Ïy|—hT®t²RML‡WK&�q¨aMPjÍ�–_ê›Í2ÖÝmYL¡£Ý§ÎŒrîgs7¨NãÚ‹+Aׇ²‚·`¨ëÞÊN óoé…%¦~aÝ–o¥­~F¼».û#3{9D«Áä9;â´æÍôQ¤m£ÆgsHœ;“¯0C[µÐñû8Z¹Ô€î>¿œáƒ¨ÃY„Üá€ø¨e{MA\\ˆbi©O»‚›îöŽÁAø¡Ö3
+'ˆqqµi½á¢C°z³(†Jœ=ã€àˆœý]ÔÞ8§š¶±×†3`žbµ^0Ï »©�uDA"e‰57"jÍLL�ÇXÝ'�N-ëZnˆhK$%JrrÛ­‹y¬ewyä¬ÏÖlv-‡åƒÑ‚ûv�ô¿L‡|ä‹N*<‹c�)u4¢×é²=hIë&a‰	ét•ÎÉV¢z*ºìÃfÞaJž¿+uÍçWâèÚK}¤¦
+cþ1α¼ZÞÃbi÷cžç„Š¢c;Ï\ºFý‚I¤�Ø-óÒF ¡Ù¡·ŒhÌ$‹™òjLjÚ¹ÕTãŸLàIHJ+øæö‡dPßÜlvÈåAÞñ GΓ[ãŽ`Ñ#&ûîR…j—ܬ'VuUÎÔ‡íëÌÒ†·�r€"˜Ž†(¾WwPßSè¤u‚3ØRUê·€¥~²ýbæ³u«jJäþnÏ×íºÁëi¯™ê'‡¹IÀ&JIÔô0>e¾dÞ>#Ç<®å³Ü±éúÞv‘¹‚ΪçñæWêÕ‰½˜¥‹ÞÛd³ªÐçÄsFÞLÖ÷ÍÝ">nfhx¬ºqŠ~K~áåÔZçW
+D9ÐÄ×ý«ÌNc­ü

+4Æg÷ÎüôL¬¾¾Ò?Âlœ�á¶_±Ã؈õ†ëî$àÝ-:ÇDpBÝu£Cbî›#13º;Ï
+*‡Kò·¶‡;¾-’"+ܦ˳-ý<ÎÈôXüöYëÁ’áJÁ‚¡$üé¥Ò.&�>Ùe¸R¸¡3ŸÁÿ]u7üaÂõñ.R8‹zAµÓã~nTLûçpYTÓìª[7ÒøUÒð=|¹üº*ÚÂ_�AŒ/–*CØ¿?CÞúh67÷
Wáïx,V[ýªŽ?RÆò^oH–èÈ;Ǩ=käàkáÕÊu3®ÉẇNbnN’²‹Y)êctž-yá¬JHÇd`‹“mó®úí}KÕ4¬½9«–øWù…�YÚá•M3
|•Ð§DN¿"æµdYDé@ÖáÄúÑ¥õÇ*1öEÒ.úMµü–r± ÒüØ
+Á4õ5’+Äó}†#‘.ç­¤‹R�‹ë
+õS׸­oïÖ‚•fx{ì—?]Ž{øjA}øé{v$õFBÇÃh¾/oF"U¹»ý´P‡SkwUŽçî0
€8â…lù9|�2
öêlá˜,RºÆ,;?…Y¦y$…䯠‰+aÍB•¨ì5šEÇ婳Ž÷õ¾Ióþ†n$ŸJ±šÿHbN±ãHÿ­^Ù’Ÿ¨aêºV§hÞšW>#žµºra·‰áWvdyóEú�C
‰ÙãÃ/c7>+΄É6¸ôªû,,�V>'$úÒµeP¹…'›ð3f3
+J̺6I>ìß
�$‘–HåÇ(�ÃÈ;LØAB¿ªƒKéíqrm”ü¼Ëµ˜+ู؂۾Ó&§døäNÃ0I¿r!7%tj[®†ð¼¸‡¿¬e°¢zñ÷pöZù¹Üv
i3l*.p.&€Ñ·Kóâd¹¨É
+ÃŽ¿NõÆç*匶ölIUQ8(±J	8a•˜· 5«X~+Õø�ëam:Êœ·jP¤^Jœ§î‘¸ÃsÀÿ‰û‡FmA@ [r«@æ	[¼¼'O24ö‰¨-ç�¯�Ô‰Qy"ð빟z¿–2¯\ÅC]õõtQŸ;G@
+ƒmÕ
R¯
Ö$õìÔÛ6Áò´K·8}bS5Û €UÞXÈs^ƒ=$B�ÿ©†Þ�‚€`õ©£X&ýµ§=²w3ØÔ�]ö§ã^êÌNóÊ»Aøðc0ÎäÚ�5¯uÈòtœ)
¼Ã؆Fê|ZEò‹Vjê¹Cç‚¡þË€y·rûÌÂqëBªUèü	õÉK%©BIhs”¨ƒr¾‰Ÿc�\už…L}dþlùÅ#œsþ�µÝ
+­­Ûä¾xP1S'¢Ä”ÀÏ/m*5blð•šZh—E5Ú°ZÊ‚?7/ ö®Ê¼¢¾Ø‡ç]�Ï�|Ö;ŠÔBùú�éí�ôý'rUS”Â
Œ,ù³Ç?»FöÌ’±ÛõÚ$Ämk¥kˆ"ƒVa+±<•šºa¶>Sû%­äù‡¸’øVî™ÏáEü4¬:ÀðÊT?ëðÎhx®‘ÕÓéUDÂãÚ%†è(
+Djà&$ >g÷5«d(
+�x­áO¶S.eƒ›»NÄÑűn5wÔÖ‹IêÞ(ˆÂ8ãÞ×Àn†hºkͬ½�P#éQ'�ÕíîaT¿£þ$RyÉà–&S�(v±8m`iʽ]rþù¦³<zlVlÉ—œÂ`5”ËR¼Ï>íJùQ5x9–�Bgaàž}x’2ÍDÑÔ1 IÐÏ4—ÆÇûèr¶
+´¡é
LŠ.Ô»4,›æË…Ü)]Ã*Vi}¾I&È éà1ƒs¸g�´YÄ1Rë}}ã$¬Ë¶Ò|>”OÙ‰@½)Ûá`LÓïËñyŒoãwk5±ÈVð…SŠËm‘í¬Í‡Ÿê)"q%Uæ#}VíÈ·ŽGØlxR×{häYÏøç%»Œ�k#’–ñ
+°û€‚ß_7ÖˆýõƯ¤øÖe÷®eßêT\qÓýÖ®Épswþ
+Ü$(Wgœî‘·xeµ§²Þ¢Q«:p¶ÐšaBš³·ØÄ ô¥7'‡Î�òÌ[H›†{±_‡*ºŸñ´í�!NTúû�[ìD_lïñ	�(bÂ/Ý}¤)mR¼�™~pÁþØL®†PèK¶	M5”ð?Æ®*äQF2±g™#ªûØ
ºà>~‚;H°‹¨-ƒô9ü·—5ûÎG	9„õKƒ[Óc÷­~@H"…°Î–E(Mõˆ@å4/”š0ù{oNcáKC¹¶un˜íÌ——*ÕˆÏh1+(¸Ôýd0�4—DËÓ`IRïÐðý„ã‚çNÝÝ45öH3‚-]º5û`EJd>¯3Ãæ	B­gÍR™n"éK`~[›J:4qð7v®`=RŽ}EñŽ:è¼süôŒÍ˜4¹nÏñÈôQr,É¢ï°ÍkÄêãÉÌ^Iö-ûØLƒÙ£1#iÕ³q{ÁðÅÔ#…·¦˜&#¹–æÆÌ0�žpk+«£
+†é68û½3¿âØ
€ÙAehD¡–~�ØioÔ�QbØFÈöyÍpR<‰˜ÈfÏâŒ&a›æ(z
+YìT”ÄÐ_ïCŽÆ}	_zA-nuò®Z˜ÄögúvXPô‹•5tºÁúOÌ]šÛæÞÄUhN'u�6V‹3án[ }¶ŽMïm9¤‚Ü.QÒ(Æ‚Ølšõ3EȽ¹²FÕ7CÇ¡¥ŸµÂü‹›¸¡•	Ò†Ô·X>År­V¤«´þœùÈ87‹Ðæ^’Ü#ž³�Ä…*[Ã�00Άºª\-zÂ0³•CÄx:M«»ÄãVNc
ÇICÃOgUÛ¼¬*¶@ÚU·ae’+b˜ÀèÌ¥�¯é¶QñóP/Anžóu–ÇúeÙM"èzpJ™Ïò®­"U‰
ñ+“ãé?§ÙÂf%%í
l¿çkíæ¿„òLO^‰ªãÃFÒò’Âiú,ÞTõg1ª
+l�•�"\\â„o8½²b¯‰{åIPwví ËQæH¶$ÜÉ´¦ÕL`e·�©ѲÂJ»ýT‚Ε^jr˜²:ª×»‹¾n
+¼ë0åà®ÏØÿîZŸÜªc~;Qwµê4è�©HšñqÇÔø°7ò=­³ž‰’ç™òÆú˜“duˆ?.Õ+rÞ9kÃf6q§œaÞÎ^bÁ�;ÐÞ“ªC=?JÅЕd›dg‡|ÜÔúˆËz@øeaªCšs5ú QoFÐé­Dú÷8È«âX²DÛíŽO@Ñ%
U÷Méd>kZ|èdü%Î0 ,cYÎ]o5ÊÓÓˆP|øTëZBŒåæxM~`Ô�ä×P
+Ïoé†-«ûç²`¹
Y¶ñ­Î±‹èÞÛ°ëÙC¼aßèß7åv¸×^
+뜻%CÁÌ‚¬UÖ´‰Maü€¤Ï¹uñçó„áÜê :œð؃C»(|cº�É&§ëéòɼ¯È8'Ùx被Šóp<]BÌý �«›[¤„
+¡à£"Ð<‘gÏ[îD~^ººÓÂÙ?Zn\Æ$ÿM­Œù–1Äœ)Á×�Bň£EGâcQóh¨X*úêÊÊ_>(”�ëw+ÇœðaÚ¨F~¶zñyþþ{‡>gS(êá9‡&IdÑX2)Fžb¡8ÚËp¤«PX,Gæ(xõš2œsPº%	faj�U‰ªh.,w¤Ñ«
+cLÇý2 Ža®
+L­ysN<q›Žé;u	%ý¡xCߥi67k]ýÔ•ðÓ�*‰I
+Ñ\‚°îÙª
[ˆ|¾[4Ã_ÆvNy|ü(—æl²½Fï·ïÊ»i¤ºõ–l
+]ë4PH§rüIbÕ
ä-àIæ<Œf)$Ü=¼ð~WÝ>�Rú?]œã|DuVò=Â+÷œõç°üdË,󴵋¨t}ïæBÖ 9Q’Ž¹¡¥PÖ•g$±»ÖùW7‡È0‰dÐs`Å/]N˜Cñh¿5÷‹$YlÄžìžvÌ6èëZü¾Žñ:á3~|±‰Q¤ãïÛ_6tºs´“WÛïµÈßFgùè`æ}
|5*¦
+…3©	¤0.aõÃ’ AÜÿJ&ªƒ0C|R*�ü(ô¯[\eZ¢¬ ÏÑZ
àú½á´sÅ%¶_,sEjâ’ñƒ]]¹QÙÄäã¤Óoxé{×ùÒT¬¬>
ÔDu±:eƒ„Ž¬‹C5áj¬QjCìé÷¤›ìÐ̆£�Y•Ãé²{G·$7wA”_sïâPs±¢Sš˜=ÍêïxEJI7z˜³LYò>‚Ý'ò.ä?4û™36L®PæØi¸Êfá]Y­IÍuÅSÛÁý²n’YWºjRd�
ú�Aùú†ÄMw¼NÆÒ`´­Š&'"—cxŒ?¦¾©Žd[ºhxB{ü¼ãXæ}•£689®ªíV�3*àV,´NÃIæ®ÎúÄ’Ÿ]ñ]Ì&ßkÏ—Ê­!ØEø>µBGD“ÊÚ	DÄ`ŽÀzë†ÿD9ÜD•^ãP¹¹¡ÒC�`pÞ¸q¶SÏ/@j»_»;Æ),H¿¥ÌNeÊ„cwLˆ^ŒM\Ú‘/Q„Ýr½Î«D¦F¡CzmbÍ$cÁïW %—õÛà”\Ù’æ’.îrËäU+ôŠÖ½U©+A�´5ŸJ¤Ï)ªãÿä;z_{®ðø–	©ŒJ !uêˆÉ
3e|Yüê*¹ˆcËûõ);ß.†úðò#ãDhö€ö‹G¸èFyç;u=2_–\?c«î¤~‘
+ƒÅÊ~Ïz_úà)ë¨R÷Ãfæ4Vf™k+{Çc–®ŸSxéüýpŸÀ–éò¢Žú‘›B6Uß\•AM{ƒo—áŧÜùþ1÷¹ž ƒG‹KÕeºd´fÙà�&ö÷-
¹÷ŸÞ
ŸLHÁ¹‰àT­Lq>ã3ïçÙuÐ3õ.°ó»ÏDkr%[’û V!
�=?(F‹V>Då†TÜ'LÞ»tðþDì0åœjiJWù¦¯:•º?˜ákÅtð·Dt,e¹Cëàì8´­~¶^Wìh÷ðá²›ó&pÀs–K‘v£yª¤}�ÜYhÇû/q˜š\—1άÄ.5HLU�c�ß|{�¨8óŠ�ò^ß4à`ä�ô·ÅPß½Q5ãŽèz”=ûý¯`ôô«î½A$äÆô¥=ÿ7<‰†ÐZLLSXëNŠ}Db6¶Ð,èÿv;=›#˜‡Ãc“(í„FrEƒÎUA7Á¾ºñ°¤‘ïÁ¼	Ÿ³ËÔ
0
+·•—Vh/†¸MƒD:•ÄÇNñú°�•:#Þþ>PLÇÒwðQ5GbÌñ
Ò禪ð@`	Ìf(iVþÉOëµ6‘
+’Yý”:®”èAèÂûXqQ¾®ãÜþŸœß,è'ì-¦E“qàO¹)• ìG³VÍ4ºf,§œR¢X=ÒÄ"Æ
œVpÕŽà"ç¸Éü4¥^Ëdw3{ñ¾T	¨Œþ)þ1²ðùfäI>EÄ÷ó…>W¹;A©j�æG’òÛB¿¶ä®.L)y{kÂ^×ö
,”K@[âŸdOÜŲÝ_tNÖm,b
+É´C™Ñ.ïð�ÖJ®{
Ò¦sŽy�ZÍÊ;±êÈÂìÄk´3ѤFÈZ‰FÝmp ÷:%•Ùd
+Ü)„�lk2'¨á"�”Öë±âµ|syùͱÕu€\çÊZ'Y�ýMªI­‘_£ƒ~Æ)bfÓíÝt=–ÙáÅbSÅ#Uk.`«
+S­‚DÍ(»(ë%ªUÎ)7%g:F—°ÞÆ {¡ßk·1SÊ»„]«
+G7üæôÆn}Ò{«óef‚‰@ƃÚZt'ˆD©Ñuèb
ÕËáÿkŸ,Ûš
 ÅGÕkX:gׂ	še£¤�xu®ôØ\CùqKå1¦g¡lø	7[Ù²Ì4Òÿ¹[PÞÿøç¥ÏFÔ´²ÿšûI#pŒ"­ªºó�öWwxN¥&ÿÊYGúéÆ„¾åoK?\aùt@½=¥¢D#UŠ&ÐmÂ΃:Kó#˜´ÏÙf`ÃN¯Ú¬5}=ÿúfy$V·‹Id”-é%#©¾¯{z²5…رF’oö¾!²’»÷ØIáMØïä†H}ØÝÖR´x`î/Æ]è›Òª^3±Í7é¶ûñâ¬Â^µñŠ
 ·(FLH³~å¶ÞÖ@Õ6Jäó¾xÌ0V?K£ÈÕJÑ}gy,‹¨†/ã©$þ¸Ì�~“Æp\!#…þö/»-ñæ
–Ú3Uv+l•EM ´Dýý_O‰uò!÷¶:)
G‚·Ñ	é91¬ÄdÐ~í@§q&±ÑŸ<¹¥ËŠ)üÁžjÄÆpîp 	ãO`6ÿÓaÌ€“Ê ‰bœ›³ƒø*Ln<rüME‰J¬#Å<ÝþŽð»Z–êÞ§é
 Ö/y³¤¥6f,¹yK@ðcõ�Ï’bÖ3Jca~Äï¬]+)T!¿hê (ò‹gÙ׺Ñ9QÀî/LÆ. |ºy‹ÔOIûè{£dç*ÇU6j—áÅ+”S•ÙÏ=¡ …–›	öHL
@@ -14083,35 +14140,35 @@ K› ÀöYt^¬evQ&57Ñ„t9�Æ©‘;ØQLV2²ûËI2­U^¹¨%Ô~ŸŒ×ˆzW
 p
 íSß»bò7+֘ߠáænÍwˆ'£#µE°nx‹¢PšL~|ö4KQ¦–!¯jn£ÕªîØãVBGE”}œœ Žý­Ð{ƒéV³”Vã0¾ô.
¶Tv‚Ì|`°�SU[¸U!&ýø7 >hI£YÉì0…òÇ*껪¦úݳj€í¨ž¨ß`Ù?8sGx9g3ÎîèñÙt÷:n:—SúluHx‹œ›ÍÉPo·«ÃJAüÕh€ß¾ÅW'ˆÃô´B ¶q…¡Jˆ`“ý kaæ®´bg>–MO”¶æB8uk—ÄþÙ7)Çê®Ü¿5GVQ(ë¿P­m-FG*åTA¸¡WK2z)·	Ž
×?3�Ì�›QOl
 s¹
-�¹ƒ%ÔÕÝÙêj�ýcvâendstream
+�¹ƒ%ÔÕÝÙêj�ý
Øáðendstream
 endobj
-1151 0 obj <<
+1161 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2725 0 R
+/Encoding 2737 0 R
 /FirstChar 2
 /LastChar 151
-/Widths 2737 0 R
-/BaseFont /KXFFVU+URWPalladioL-Ital
-/FontDescriptor 1149 0 R
+/Widths 2749 0 R
+/BaseFont /KFZBPF+URWPalladioL-Ital
+/FontDescriptor 1159 0 R
 >> endobj
-1149 0 obj <<
+1159 0 obj <<
 /Ascent 722
 /CapHeight 693
 /Descent -261
-/FontName /KXFFVU+URWPalladioL-Ital
+/FontName /KFZBPF+URWPalladioL-Ital
 /ItalicAngle -9.5
 /StemV 78
 /XHeight 482
 /FontBBox [-170 -305 1010 941]
 /Flags 4
 /CharSet (/fi/fl/parenleft/parenright/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/emdash)
-/FontFile 1150 0 R
+/FontFile 1160 0 R
 >> endobj
-2737 0 obj
+2749 0 obj
 [528 545 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 333 0 0 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 0 0 0 0 0 0 722 611 667 778 611 556 722 778 333 0 667 556 944 778 778 611 778 667 556 611 778 722 944 722 667 667 0 0 0 0 0 0 444 463 407 500 389 278 500 500 278 0 444 278 778 556 444 500 463 389 389 333 556 500 722 500 500 444 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 ]
 endobj
-1017 0 obj <<
+1025 0 obj <<
 /Length1 1630
 /Length2 16214
 /Length3 532
@@ -14124,7 +14181,7 @@ xÚ¬¹eTœm“-Œ»kðÆÝ‚{pw×Æ¥qwwwBpwwwwn
‚÷/Ïûž™9kÎùu¾ùÕ÷U»jW]µë®^½š’TI•QÄÌÁÄ\ÒÁÄÈ
 R
 �ššÛ»˜Ó,œ
¶ÿ>
 üfîajîøÄ
-hjcÿOó9ÿ
™Û›ý÷úÿÊô¯ê™ee54”Eèÿ�½Ê¨jûw¾Y¹¸ÿ¡ôw@jžŽæ€ÿ•NSÞÁì?ÿð‰Š:x
+hjcÿOó9ÿ
™Û›ý÷úÿÊô¯ê™•ÄedEèÿ�½Ê¨jûw¾Y¹¸ÿ¡ôw@jžŽæ€ÿ•NSÞÁì?ÿð‰Š:x
 2¶7û;nÿiø6uuvþ«ò¿6ÀßëÿÇù_ƒonîanŠ°¾â`Êb�‘�	ªÃÍ™×èc…	u,mT+*¨qèõψØå­4z«
ejšáûh÷\>s|?üFw4Ö‡cKÝ›f~ù�Зœ¶¿ý'U'7ýQ³A)ræ¹fŒ÷Õ’Ü”‹ÆÑÞ”²ŠAÉÑL'»3ÜÕ#m
 ‰ªV�¶ý^]n?É�÷oŠ üÐìæÇÕQÿÑŠ´Këñ¯0AÙ�¬ŒÚ#Ûõ½ü¶Sz_“Ò¶Âæ°Â¯£Z¬4¦×âÚpj~¿H]c}jÇyŒ{ì|yz0Òä$·‘×ù³›'È úKåWµ0wïèåóä»÷ ¦¤†®ßëÓôäNg@«ÔËfR~7øX3X¯§º<†ž‡:;D݇Y‹’‡±ÇƲ ¾qv"©Î.嶱8Á[Ö†¸gÛyŽ
 ‡Ø
@@ -14178,82 +14235,81 @@ T S!õ\¶ZãÒJ)¡#¢:sÌæÀŽ_îR·è¢#Ô¦Bò
 êOqÚô¡9U¤$Ö=6Ððü|Hò‹°s%nS,{¨üˆ&õÊ’—8$²cå’6¿p[Žx7íj£\k@?®ð¶"Ü<4s=3Ña½BÚ_Z¼–âç0h^×IÓ¡gÀDFÌû"�O,v}V%t	ïæûüH¦¼¯¸Êi¹ò¢Œ
 Vº<3ÿiúü`�+zв±ƒõ¤âBy¿e5m¨á^[ÄyaS©aŠ€()ÞŸíÆÜ=7w3ÔV³Md&	ðÑÈå’½Teöä´þe¢QŽh¬õäØîαÿ”øg´>»6¹”¼g´(>\PóÔkºßo†‘vÝ8‹¥‡HZR¯±˜(rÔs•Ì7R¶s×»LíªøŠæüz!ÁÈ 
U[–Õ²69§QŽƒ.[¿’�6çÏhüS—W
se®÷±dß
bfïyîI‡dÁFbNþ%ÕgÔÆGœ¢,bœrü(šÙÂ%+'‹
Òl�£g"îuªrC`Wro¦1€5ÇCÈ…çpû¶šÍÄ]sG¹ÑOnäàrqœìZ�I=…M}…)äCQÊ~	ê!µŸ¾Dz9·%eÞ!­û©ÆÁ”,Ý,>׿¿âb‰lGûrs

RøV0'uV·ƒÔ)É ²;^%!#úㆹå"à÷È“µ‚i4Í p#Öo·¤_Œä%±!¥Óæ`…(`¢ix¸ü={Pìr{[£3þÝɶ*\��ÔvµvÈÆe~0{zŠJ"É®Ñc
 µÄÀ‹í_~ …U¢÷íýwõœÅ6o¸JÚè¨OÊÿ7E®Õ?ÿm]~»úàD¾?œñŽ¹,à¾$ôƒc2‹™‹ãé¸æß‹M|&ìšp{³×Ó�\Ì	�«e
•Œ¤·Æý:®s”CrªÞr±[G^…_x[´?ÒØæå'®Öܬž¥Škv5‰GlŸ뽺>QÄè5ó†…¼~šÒÙŽÝÙvnÂ|*ÑÐaòÝ¥ÉÿÞ^á=tønÚÖ•_ÎïxPðdòùCß•b­RæwWbgÖJ?~årοþC¬[Býäd�Ư{ñ h§úÍwÓ‰Ï'}2~Ñ]Ø6å°âÙŒ9�û²&ÜÔîNÖñûö¡î±`luî‹)G2O=ßùEßCùä”Õùù[
-¹ÓÏ™wŸ˜sìÇÆâ@•»¯M·åöMXvºóEÿÿu9~Û¤k²¹¶…ê¼ª�?yÉg“º”òÌÜ{ç;�OÛ«YŸ$3iÕæ#ÛÏn•8²oväóŽ7¯ã}ËÏë�ÕýÜá?÷þ¹ësÿ„æÕäÈ©Ù÷pö.Õ`¹fýO©a›K<­ÛNîêè=|ˆuÖïD©â¹µßýÝ^Ú(šDªM?T¹CÂxÝ;)ñ´g¥ÙENÓ/Û¾}õ%×ÊÛJ®Q†…
É9©‰E%ù¹‰EÙ\
+¹ÓÏ™wŸ˜sìÇÆâ@•»¯M·åöMXvºóEÿÿu9~Û¤k²¹¶…ê¼ª�?yÉg“º”òÌÜ{ç;�OÛ«YŸ$3iÕæ#ÛÏn•8²oväóŽ7¯ã}ËÏë�ÕýÜá?÷þ¹ësÿ„æÕäÈ©Ù÷pö.Õ`¹fýO©a›K<­ÛNîêè=|ˆuÖïD©â¹µßýÝ^Ú(šDªM?T¹CÂxÝ;)ñ´g¥ÙENÓ/Û¾}õ%×ÊÛJ®Q†…
É9©‰E%ù¹‰EÙ\
 endobj
-1018 0 obj <<
+1026 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2725 0 R
+/Encoding 2737 0 R
 /FirstChar 35
 /LastChar 90
-/Widths 2738 0 R
-/BaseFont /KKVVQA+URWPalladioL-Roma-Slant_167
-/FontDescriptor 1016 0 R
+/Widths 2750 0 R
+/BaseFont /PCOIKA+URWPalladioL-Roma-Slant_167
+/FontDescriptor 1024 0 R
 >> endobj
-1016 0 obj <<
+1024 0 obj <<
 /Ascent 715
 /CapHeight 680
 /Descent -282
-/FontName /KKVVQA+URWPalladioL-Roma-Slant_167
+/FontName /PCOIKA+URWPalladioL-Roma-Slant_167
 /ItalicAngle -9
 /StemV 84
 /XHeight 469
 /FontBBox [-166 -283 1021 943]
 /Flags 4
 /CharSet (/numbersign/parenleft/parenright/comma/hyphen/period/zero/one/two/three/four/five/six/seven/eight/nine/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/X/Y/Z)
-/FontFile 1017 0 R
+/FontFile 1025 0 R
 >> endobj
-2738 0 obj
+2750 0 obj
 [500 0 0 0 0 333 333 0 0 250 333 250 0 500 500 500 500 500 500 500 500 500 500 0 0 0 0 0 0 0 778 611 709 774 611 556 763 832 337 333 726 611 946 831 786 604 786 668 525 613 778 722 0 667 667 667 ]
 endobj
-955 0 obj <<
+963 0 obj <<
 /Length1 862
 /Length2 1251
 /Length3 532
-/Length 1860      
+/Length 1861      
 /Filter /FlateDecode
 >>
 stream
-xÚíUkTgnõJÀ+Å€€¸
-æ2�@	Š,˜–{TP¤2$H20I0@¹,P ‚A…ÊE ÒJi½
-& X¹ê
-ºè±KîþÚ³3æ}žç{¿gž÷;ç33ñbœØHì‚Å�Ò
-¸#l®”úÂËæÜa6O"XÉ2ÄŸÇróa€
-ýÏY'uÑËé_N—è^¸’VTî—Om"ö0ñ‘‰i²5¯¬ÌGòð§
-¾VҚЇg¾Ù¶½wz[\›ÎY¶Š~è\ãÜ`·öFKŸ–¦›ízÏk¼¿	9ð¸sëdm\Þõ�¬‰[÷Ü^x‘Kš¹‚ã¨4
Í>Âp"
-+淪»*åQ}öüzÏô&éãTÓ³g­ÌréLZ¬aôï7Ã4ñwRÇ2Šg¾òÔÂ5Ó¯
Ü–']W’2ã]�ÝŒÚZs_nn³ò�}L´^uq¤Ö =äÑþŸ«À”×*ÍÍe±ÏˡЂš\ã=O¢Â¿«ß9·ŸCü¢úÔÁ§¥õríîz=Pw×Ý^çÌ…ZiwÉ•YY-÷ø	?<nÓÑ}Ûµôa¼à=ƒo¿ò¨ÁexB.¯42Z†�]£h™ÊºìŒÌ¿<𒱺|­¨Äb“¨äbüX"­ÿ(Xu£³¼¯Ï8œ˘d¤éå_M€qäxû*Ëæ�²:½žš32yŸŽ±f¿2+JOa"«ò8§µg3Ó3¼<¼ý¾Ðˆ;Üœ—àðL­î{^ñ´9³clK˜¯:™q¼õÅà„Õ”hœ©M»ØUê—bh	_lp´™)Ðt*?³^ÅP 9í7è~öuq“³¹QS©g3}7øÇäw‹B?F[Mh 7÷fÏÄ�¸œ(ã>SzÖ9T—›{íÇí’zB"pŽ¨,©]¹æ	þ†u`硽÷)ÆáqYGÂÇL¼4t=Ëe—´j®ÛÊBfwèDhÎ?+ÓÂV#êÇ^àšÞ­;öL~¨}©ÀgääŽÕKIë·5ûØ�÷§«÷oz�yàY]?÷£ÐèÎú©_†çÍVSyÊúä—pïç7J¿üñ·¡ÒÉðõùWoʯʉ.„Ö‰Öþ›E¶TÅÑ“Êk•×Ç$
7Ìe$å-Êþ„ÓYlÿÒ<ß?¨=#Y—U�ªš{êæSEaÐ]EÕÇ´y”óÔe¼Âa²²ÔŸö)sï¯qT1ç„Óó_N’^'v?רk••ùÒ«R¦¦K´Z_oõÊjòÔ“ÍYYÒ)Õk${›	@šýî~Ã{8sç—Ú·¬÷U$FÛëø7:ã,?ÔyòÓ�æݯ¸ùO�iD§È‡‹èøÄuþ÷T«TêSFa´{ò€Š1b]aÚù_=v*S’ç#¶ä]k¬Øu �ÑÌly`wlÃlÓËDÕ7™U^¦«�‹ûJ*
ú¶ábuÁÀ$ñö²
÷p}Â(�5ñiQBCG¸×À\—$§!7!ÇC~9Šœù¸)ökµÑ)Ç÷D_uo€£ŒÚjnÿ=Õñh׺™;wáÔúBÙ˜›jU´fŸ�î�N—²QÝÖ…Zöî–[£Ž!CNWµ$Aü6ÍŸd‡š@Â!ß¼tÍ›
‰ˆINzÀxwÁv}ÃuÙF®$ßÖ4�L}0»Õ{Ðv|*›æ”ßt˜!P<Ž>gòÃ×QGT#þkÃGîkÑWÕÕ9ÕÙ•ìëf:×.M9­œÚ¸³½›p|W¶ç#Ɖ¾Ïén§5úçäZ«“ÊcÙ!õ6hÜAIOL¶�F¯Œ[°6°7·‚óžù?|pÿoð?Ñ
+xÚíU}8Tùß­gYC¯VC¨Cײ4/gÖ(e´2›—A¡dsÌœ1ÃÌÎÌh°áb±"D£bó6»Y»½àâzi´)zn“XòVS4C´y­uêi¯ýóÞ¿îsÏùç|?ŸÏïûûœÏ÷÷<?3¦Á‰�Ã.ˆPL
+�íh2�j‡3œ‘ð(”ÂΟ-Šì
+`ÃÉÁö‚1'ÿ
S+›»Hø|H°Ø~)¥?ñ�€Ç�z«@á1ŒîF…+¥~ð²9w˜Í“V²1Ä籜„!| €6D²5u™à‰\xR˜Íä‰Y\€ñEðÙ+­`ñ-!íÛO÷õsµz;×%’	ñ„âýQá0@~¯^ªÁ÷5–Ê“
d"™bBì}÷¸b³/„,„͆
+ÅKg‹ÿ]Íáa#ƒa)ÌÂõv#,‡¤Ð¼êäŠØ/Îßùá#’Ö˶Ju¯f³ml>�}̇zÎË$D\:Z¬¼zBŽSèÉr8¥‹^1ÈðHÿjºD÷âÕ´¢rÿ¬xj±Ç•˜&[óÚÊ|”!�ð=]ð�Ò�Ö„>:ûí¶í½ÓÛâÚtαUôCç绵7ZzŸ´4Ýl×{AsàÃMø¨�'�['kãònìdMܾïÆ`âE.iæ
+Ž£vð44ûȉT(¬¼FœZî©”GõÙóë=Ó›¤O�SMSÌž·ú”KgÒb
c~»®‰¿›:–Q<󵧮ɘ~}àŽ<醒”¿·ÑØͨí‘5÷Õæ6+Ù'!äAëU—Fj
ÚCø¥
+Ly£ÒÜ\û¢
++¨É5Þó4:âûú�sðLjûªO|VZ/×î®×uwÝëuÎ|Y¨åÑ¡‘Fq—\�•ÕrOŒ‘ðÃã6Ýwö–>Š| cðÝ×^�5¸OÈåµFFËðàñëá-SY—�‘ùW¾¯«Ë׊J,6‰J.Å�%Òú�‚U7;»ÀªñŒÃ9±ŒIFš^nȵGŽ·¯²lÞ(«Óë©9+“÷ékö+³¢õ&²Jq�sF{63=ƒèáå¿O#îps^R gàsµºïEų2ä쎱-	c~êdƉ֗ƒVS¢qmÚ¥®RÿCó(øRƒ£ÍL�¦SùÙõ*†Éi¿I÷¿¸¿‹[˜œÍ�žJ=÷Ó—qƒ¿O~¿±(”ðSŒåЄrË5{&nÄÝàd÷¹Ò³Î¡ºÌØ„Øk?n—Ô‰sDeIíÊ5Oñ7­ƒ:¹> GÄe‰3ajèz–Ë®8h'$Ô\·-”…Ìî°‰°œV*¦…­FÔO™àšÞ­;öL~¬}¹À{äÔŽŸÔKIëw5ûÙA¦«lz“éû¼ƒ®ŸûIØßtgýÕ¯"òæ�«�«<e}ò˸ó¥?~ÿËPédÄúük·ä×äDBëDkÿ­"[ªâèÃIåõÊc’†›æ2’ò6å@™,v@ižßÅÕžQ¬+*‹ÇUM�=uó)Aƒ¢…p螢êSÚ<Êyæ2^á0YY@ûÜÇõ×8ª˜sÒéÅßO‘Þ$v¿Ð¨k••ùÑ«R¦¦K´ZßlefµyêÉæ¬,é”ê5×f�f¿»ßpÇÎ܅ߤö-ëÆý‰1ö:Þ!�Î8Ë�užþ|·y÷knþ³ã1)òá":>q]À}Õ*•ú´Q8í¾<°bŒXW˜váW�]…Ê”äùÈ-ùC×+vùæ1š}ZÚß0Ûô*ÑBõmfÓtµqqßBI%@ß6\¬.øˆ$Þ^6à¡O¥±&>/Jhèˆ`ÌuIrrr<äW¢É™OJ‘bÿV�r|qOÌeQ÷8Ú¨­¦!ðÎ_S�v­›¹{N­/”�¹©VÅhöèÞít)Õm]¨eïn¹=ê:ätMKÌoÓüyAv¨)$òËKל±Ù�ˆ˜ä¤Žwl×7\—m´—ÄáàÛæñO¨g·z
ÚŽOeÓœò›3Š'!1çM~ü&úˆj$`mÄè/}-úªºº#§;»’ýbÝLçÚ¥)g”Sw¶wNìÊö|Ì8Ù÷%ÝíŒFÿœ\kuRy,»#´Þ�;(é9–í­Ñ+ã¬
êÍ­à| CþÜÿüO4À®n#
Ãý­úþkendstream
 endobj
-956 0 obj <<
+964 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2739 0 R
+/Encoding 2751 0 R
 /FirstChar 13
 /LastChar 110
-/Widths 2740 0 R
-/BaseFont /GGITSS+CMSY10
-/FontDescriptor 954 0 R
+/Widths 2752 0 R
+/BaseFont /KTBVWH+CMSY10
+/FontDescriptor 962 0 R
 >> endobj
-954 0 obj <<
+962 0 obj <<
 /Ascent 750
 /CapHeight 683
 /Descent -194
-/FontName /GGITSS+CMSY10
+/FontName /KTBVWH+CMSY10
 /ItalicAngle -14.035
 /StemV 85
 /XHeight 431
 /FontBBox [-29 -960 1116 775]
 /Flags 4
 /CharSet (/circlecopyrt/bullet/braceleft/braceright/bar/backslash)
-/FontFile 955 0 R
+/FontFile 963 0 R
 >> endobj
-2740 0 obj
+2752 0 obj
 [1000 0 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 500 0 0 278 0 0 0 500 ]
 endobj
-2739 0 obj <<
+2751 0 obj <<
 /Type /Encoding
 /Differences [ 0 /.notdef 13/circlecopyrt 14/.notdef 15/bullet 16/.notdef 102/braceleft/braceright 104/.notdef 106/bar 107/.notdef 110/backslash 111/.notdef]
 >> endobj
-952 0 obj <<
+960 0 obj <<
 /Length1 1616
 /Length2 25435
 /Length3 532
@@ -14261,7 +14317,7 @@ endobj
 /Filter /FlateDecode
 >>
 stream
-xÚ¬ºc”¤]°%\]î²�,Û¶mÛvuÙ¶mÛ¶»lW—mÛúú}ïܹ³î̯ùæG®õœˆ8;vÄ>'Öz2“„@^‰FÀØÎÐDÔÎÖ‰†�–ž ¢¨&o`mm`la'M£hgc
+xÚ¬ºc”¤]°%\]î²�,Û¶mÛvuÙ¶mÛ¶»lW—mÛúú}ïܹ³î̯ùæG®õœˆ8;vÄ>'Öz2“„@^‰FÀØÎÐDÔÎÖ‰†�–ž ¢¨&o`mm`la'M£hgc
 áàUûZ­RRŽ_&½þ’ÞŸfx¯%Ê3® ôEþsÈC®”ô“‘Bå0²TU’?…šÜ¡ˆhÍÒVù�òýåm»TúÃ8Z§ä‚�Û°ý	³:I?Ôöz"6›Èbœ^%
 
yá×h}×¹­Z ypÓ‚u=jëé 3\xœa(74nŠïRýƒ&cx£aYKÜ¿‰~ػբÉI·X�iêS¨“2�ø	ú›G²¨†lkÕ›$ñé³øIñƒ<½*­;:̽¤PœT�1]š«ÚowŽ0~,A¸ÕO˜Ó%/‡ìdccÅ÷‹k×{GKÌ‘›j™(+ÔBU�ÞD#¡6ª:Mð%¿s¾†I¼;v#wïRUèB&%Ô	øªÕ(cÊïZB™ª³/7í¿'|8¾—}Z�£6Ã*DLi´¯kâ'/rn¶
èXÐ60µ!~Èaïގا*\Dxc(uè³?^NWù±CVØñ Áá´ÅÚQ[´¬5üŠvȈ0Kïø^•vµÚ*V¦°cœ
(p3“¸µMÖiÒ|#Óƒ}5ãBy�E¦Ç•yÖÌÞ¢º<^×<;>3ý
 ÎÈ;V<g5j‡ùôIH›C„ÿæaTÓÂ
€
@@ -14364,35 +14420,35 @@ PÔ3)lmŒ;œ¸
—ü“5|—î”+ÀTÅv‰¼Ô_òF^›bQãLT?yÇ¥ðb²èewïA© !ÅdYò]mÝÏÈÍ[Ÿ
 ‡)Í
1p’}l‹ÈÙ¤û¨¯šð1ônQ“Öü:”ƒ‘96êì(…+õƒ<“4Ã7Q|ÿF1°²¨üñ#\õl1ï,äÝ?7Âeì7®Œ½nØ<É„3ÄÓ›rhNBRòÂÑC
 ^[ÜÀ�!ÄŠxMcOÝ—ÙPFt>l¿��‹JF¢‡ßÂöð1’£†°åïxDÑ
v	hÇÚ
 ¥åã—r¢f�Y—òU·zifÁUÆz*JfU¤ËÞ ½ýä|ÿ:Ð(�Pk<’¥WÝìo*Á]ö…�gP³Šþ,ÚFjî¶%™;ɘ¹á9L9.D�œÇǦÝ@sOµhòÚ³BãtÑsÒ~ˆ®›×)-ÉA
-ÇГ�öÞVMýͲ:“®³m›ÓWBÖþü/�ùÁÿ	�±�©¡“‹½­¡“5Ìÿ
+ÇГ�öÞVMýͲ:“®³m›ÓWBÖþü/�ùÁÿ	�±�©¡“‹½­¡“5Ìÿ
 endobj
-953 0 obj <<
+961 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2725 0 R
+/Encoding 2737 0 R
 /FirstChar 2
 /LastChar 216
-/Widths 2741 0 R
-/BaseFont /OFVVBW+URWPalladioL-Roma
-/FontDescriptor 951 0 R
+/Widths 2753 0 R
+/BaseFont /YLEPES+URWPalladioL-Roma
+/FontDescriptor 959 0 R
 >> endobj
-951 0 obj <<
+959 0 obj <<
 /Ascent 715
 /CapHeight 680
 /Descent -282
-/FontName /OFVVBW+URWPalladioL-Roma
+/FontName /YLEPES+URWPalladioL-Roma
 /ItalicAngle 0
 /StemV 84
 /XHeight 469
 /FontBBox [-166 -283 1021 943]
 /Flags 4
 /CharSet (/fi/fl/exclam/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/equal/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/bracketright/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/circumflex/quotedblleft/quotedblright/endash/emdash/Oslash)
-/FontFile 952 0 R
+/FontFile 960 0 R
 >> endobj
-2741 0 obj
+2753 0 obj
 [605 608 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 500 500 840 0 278 333 333 389 606 250 333 250 606 500 500 500 500 500 500 500 500 500 500 250 250 0 606 0 444 747 778 611 709 774 611 556 763 832 337 333 726 611 946 831 786 604 786 668 525 613 778 722 1000 667 667 667 333 0 333 0 0 278 500 553 444 611 479 333 556 582 291 234 556 291 883 582 546 601 560 395 424 326 603 565 834 516 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 500 500 0 500 1000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 833 ]
 endobj
-929 0 obj <<
+937 0 obj <<
 /Length1 1614
 /Length2 24962
 /Length3 532
@@ -14403,7 +14459,7 @@ stream
 xÚ¬zc�eß³eÙU]¶ÕeÛ¶m[·lÛv—mÛ¶m³ËìrMÿþOoæÓÌûp"ÎÎ̽re®Ü;î�8dD
 Ê´‚&
 CF&ìhjèl	°1t6å"T75!15&db"däää„!#Ø{8Zš[8RüÅ ¤¦¦ù/Ë?!„Fÿáù»ÓÉÒÜŽ�üï‹«©
ÀÞÖÔÎù/ÄÿóFeSSBgSB3KSBayMI9qB
-q9UBqS;SGCB#KcBKcS;'SJB3€#¡Í¿-�
v&–ÿ”æD÷KЉÐ�ÐÉÞÔØòï6SwcSû\4„ö¦Ž¶–NNß	-�Í
íœÿöÀ@higlãbò�¿v3À¿Ù;þFØþõýS
+q9UBqS;SGCB#KcBKcS;'SJB3€#¡Í¿-�
v&–ÿ”æD÷KЉÐ�ÐÉÞÔØòï6SwcSû\4„ö¦Ž¶–NNß	-�Í
íœÿöÀ@higlãbò�¿v3À¿Ù;þFØþõýS
 fH{ð1Ycgl
 ñi0–Wä¯}Ã4¿ðtóE&Åt¶Z \&—Ešà’º››¹
š#/(/25©â¾î‚C‡ã{»ò-o8J<îqæÔ§
-
 㼑a1Š¯@�x×"ÙÍÕƒHQzHÈÈH<àtáŒË{â,ȸ�†ÍÊ·K3”’/Y”Ôty®žˆW"So¼¥¯Úh‰í}oSOw½MOY%9
@@ -14503,548 +14559,563 @@ _ÏfZYX/JÿŠPžUºÐ±;Äó™Ã¾¨5ÃÎ~¢M~;-5”äÖ$„€`3’’˜à0
ßnpöã¤ÒE›­ðÆúb89qÄZ¥| ž
 !µãmYgKà”‹ù÷ÿ•£B}ôçüÂÛZ
= U³W¯Û䉊ù¥tàC½^¦W
 QŒÝ›îl6;¹E& ˆÈš.®*
·Kcî):+©†¸�uó‘=t‹b'´á":
 EúPjAõ¶Õ ª±E@
ûõo`¦iqKQ`_`+§|,33yºGÖÿÚæa#^¸“¯™ÆÀ¤Çð—àBÝ®éãó8OÝòUÐÇ3&]¥§J°Æ$h
�‹YH<(|í	HhtÊc­µ	YjCorpôaá‘Ögnj/#;ÌèâCŠ7±]c¥£ÿ|I4aü½ï¯kÅ3|M&ïæ†Àh¿}®²L¸­¿‚fµÝ¤TíR8g¤=Œë&í‰A¬ >ª¢Ûd�÷C{z‰-6ð7Tœçܧž�
p"ÿ²±(�¯Ÿûº`h/áw»7¢»ªîÈ”
	û½U6´‹°ÚS
+ÑT~¯Tç°Ç&µÖªñ˜ü¶×êI z{çNÊ€‘±6qZü(úX(ø¢ZyÁ´~´ãÅ¥Ù�Ûا°ÞÊ›H#æ
-½¨©5¯O3þU¬–.œ)
@X±®Kàð`ç0’’�A©2ã?Â’§¤1à*\Ü&	Ï×ò•Es”òœ³e»`Ž-Ä_�ø£½—†›}t`òC�;]t:ü#?=*rež‡¾ZNžÿµ×Þ	ÞÏ-aæ:-ƒ;ž""·È¶ êÝ'(ž¶b—PÝò$&¦‰É&ŸydÌG­<‡#
{BŸí’Tdõ/úYýþª·Áè`þÜ(JæsmjžãdàѦÞ#¶«âÝ]¹CÑdH€
Aþ–/“6óN#å
+½¨©5¯O3þU¬–.œ)
@X±®Kàð`ç0’’�A©2ã?Â’§¤1à*\Ü&	Ï×ò•Es”òœ³e»`Ž-Ä_�ø£½—†›}t`òC�;]t:ü#?=*rež‡¾ZNžÿµ×Þ	ÞÏ-aæ:-ƒ;ž""·È¶ êÝ'(ž¶b—PÝò$&¦‰É&ŸydÌG­<‡#
{BŸí’Tdõ/úYýþª·Áè`þÜ(JæsmjžãdàѦÞ#¶«âÝ]¹CÑdH€
Aþ–/“6óN#å
 endobj
-930 0 obj <<
+938 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 2725 0 R
+/Encoding 2737 0 R
 /FirstChar 2
 /LastChar 151
-/Widths 2742 0 R
-/BaseFont /GDXIMF+URWPalladioL-Bold
-/FontDescriptor 928 0 R
+/Widths 2754 0 R
+/BaseFont /WOEMRA+URWPalladioL-Bold
+/FontDescriptor 936 0 R
 >> endobj
-928 0 obj <<
+936 0 obj <<
 /Ascent 708
 /CapHeight 672
 /Descent -266
-/FontName /GDXIMF+URWPalladioL-Bold
+/FontName /WOEMRA+URWPalladioL-Bold
 /ItalicAngle 0
 /StemV 123
 /XHeight 471
 /FontBBox [-152 -301 1000 935]
 /Flags 4
 /CharSet (/fi/fl/exclam/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/equal/question/at/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/quotedblright/emdash)
-/FontFile 929 0 R
+/FontFile 937 0 R
 >> endobj
-2742 0 obj
+2754 0 obj
 [611 611 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 500 500 889 0 278 333 333 444 606 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 250 0 606 0 444 747 778 667 722 833 611 556 833 833 389 0 778 611 1000 833 833 611 833 722 611 667 778 778 1000 667 667 667 333 0 333 0 0 0 500 611 444 611 500 389 556 611 333 333 611 333 889 611 556 611 611 389 444 333 611 556 833 500 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 0 0 1000 ]
 endobj
-931 0 obj <<
+939 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2743 0 R
-/Kids [922 0 R 948 0 R 958 0 R 1013 0 R 1077 0 R 1140 0 R]
+/Parent 2755 0 R
+/Kids [930 0 R 956 0 R 966 0 R 1021 0 R 1085 0 R 1148 0 R]
 >> endobj
-1216 0 obj <<
+1226 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2743 0 R
-/Kids [1202 0 R 1218 0 R 1230 0 R 1243 0 R 1254 0 R 1261 0 R]
+/Parent 2755 0 R
+/Kids [1210 0 R 1228 0 R 1240 0 R 1253 0 R 1264 0 R 1271 0 R]
 >> endobj
-1277 0 obj <<
+1287 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2743 0 R
-/Kids [1273 0 R 1279 0 R 1287 0 R 1296 0 R 1306 0 R 1319 0 R]
+/Parent 2755 0 R
+/Kids [1283 0 R 1289 0 R 1297 0 R 1306 0 R 1316 0 R 1329 0 R]
 >> endobj
-1327 0 obj <<
+1337 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2743 0 R
-/Kids [1323 0 R 1330 0 R 1337 0 R 1342 0 R 1363 0 R 1373 0 R]
+/Parent 2755 0 R
+/Kids [1333 0 R 1340 0 R 1347 0 R 1352 0 R 1373 0 R 1383 0 R]
 >> endobj
-1382 0 obj <<
+1392 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2743 0 R
-/Kids [1379 0 R 1384 0 R 1389 0 R 1398 0 R 1407 0 R 1414 0 R]
+/Parent 2755 0 R
+/Kids [1389 0 R 1394 0 R 1399 0 R 1408 0 R 1417 0 R 1424 0 R]
 >> endobj
-1423 0 obj <<
+1433 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2743 0 R
-/Kids [1420 0 R 1425 0 R 1435 0 R 1447 0 R 1455 0 R 1465 0 R]
+/Parent 2755 0 R
+/Kids [1430 0 R 1435 0 R 1445 0 R 1457 0 R 1465 0 R 1475 0 R]
 >> endobj
-1479 0 obj <<
+1489 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2744 0 R
-/Kids [1474 0 R 1481 0 R 1487 0 R 1494 0 R 1500 0 R 1507 0 R]
+/Parent 2756 0 R
+/Kids [1484 0 R 1491 0 R 1497 0 R 1502 0 R 1511 0 R 1517 0 R]
 >> endobj
-1519 0 obj <<
+1530 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2744 0 R
-/Kids [1515 0 R 1521 0 R 1528 0 R 1532 0 R 1542 0 R 1547 0 R]
+/Parent 2756 0 R
+/Kids [1523 0 R 1533 0 R 1540 0 R 1544 0 R 1554 0 R 1559 0 R]
 >> endobj
-1561 0 obj <<
+1573 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2744 0 R
-/Kids [1554 0 R 1563 0 R 1572 0 R 1580 0 R 1591 0 R 1597 0 R]
+/Parent 2756 0 R
+/Kids [1566 0 R 1575 0 R 1584 0 R 1592 0 R 1603 0 R 1609 0 R]
 >> endobj
-1608 0 obj <<
+1620 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2744 0 R
-/Kids [1603 0 R 1610 0 R 1614 0 R 1621 0 R 1629 0 R 1636 0 R]
+/Parent 2756 0 R
+/Kids [1615 0 R 1622 0 R 1626 0 R 1633 0 R 1638 0 R 1648 0 R]
 >> endobj
-1643 0 obj <<
+1655 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2744 0 R
-/Kids [1640 0 R 1645 0 R 1649 0 R 1653 0 R 1659 0 R 1664 0 R]
+/Parent 2756 0 R
+/Kids [1652 0 R 1657 0 R 1661 0 R 1665 0 R 1669 0 R 1676 0 R]
 >> endobj
-1673 0 obj <<
+1685 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2744 0 R
-/Kids [1669 0 R 1675 0 R 1682 0 R 1692 0 R 1696 0 R 1700 0 R]
+/Parent 2756 0 R
+/Kids [1681 0 R 1687 0 R 1693 0 R 1703 0 R 1708 0 R 1712 0 R]
 >> endobj
-1714 0 obj <<
+1724 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2745 0 R
-/Kids [1706 0 R 1717 0 R 1724 0 R 1729 0 R 1734 0 R 1738 0 R]
+/Parent 2757 0 R
+/Kids [1716 0 R 1727 0 R 1733 0 R 1741 0 R 1746 0 R 1750 0 R]
 >> endobj
-1747 0 obj <<
+1759 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2745 0 R
-/Kids [1742 0 R 1749 0 R 1757 0 R 1763 0 R 1770 0 R 1777 0 R]
+/Parent 2757 0 R
+/Kids [1754 0 R 1761 0 R 1769 0 R 1774 0 R 1782 0 R 1787 0 R]
 >> endobj
-1787 0 obj <<
+1798 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2745 0 R
-/Kids [1783 0 R 1790 0 R 1798 0 R 1802 0 R 1806 0 R 1812 0 R]
+/Parent 2757 0 R
+/Kids [1794 0 R 1800 0 R 1809 0 R 1814 0 R 1818 0 R 1823 0 R]
 >> endobj
-1820 0 obj <<
+1832 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2745 0 R
-/Kids [1817 0 R 1822 0 R 1827 0 R 1833 0 R 1842 0 R 1847 0 R]
+/Parent 2757 0 R
+/Kids [1829 0 R 1834 0 R 1839 0 R 1843 0 R 1852 0 R 1859 0 R]
 >> endobj
-1855 0 obj <<
+1867 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2745 0 R
-/Kids [1852 0 R 1857 0 R 1861 0 R 1865 0 R 1873 0 R 1877 0 R]
+/Parent 2757 0 R
+/Kids [1864 0 R 1869 0 R 1873 0 R 1877 0 R 1885 0 R 1889 0 R]
 >> endobj
-1901 0 obj <<
+1913 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2745 0 R
-/Kids [1883 0 R 1903 0 R 1918 0 R 1928 0 R 1945 0 R 1951 0 R]
+/Parent 2757 0 R
+/Kids [1895 0 R 1915 0 R 1930 0 R 1940 0 R 1957 0 R 1963 0 R]
 >> endobj
-1962 0 obj <<
+1974 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2746 0 R
-/Kids [1957 0 R 1964 0 R 1974 0 R 1980 0 R 1989 0 R 1999 0 R]
+/Parent 2758 0 R
+/Kids [1969 0 R 1976 0 R 1986 0 R 1992 0 R 2001 0 R 2011 0 R]
 >> endobj
-2015 0 obj <<
+2027 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2746 0 R
-/Kids [2009 0 R 2017 0 R 2023 0 R 2031 0 R 2039 0 R 2050 0 R]
+/Parent 2758 0 R
+/Kids [2021 0 R 2029 0 R 2035 0 R 2043 0 R 2051 0 R 2062 0 R]
 >> endobj
-2065 0 obj <<
+2077 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2746 0 R
-/Kids [2058 0 R 2067 0 R 2073 0 R 2084 0 R 2088 0 R 2092 0 R]
+/Parent 2758 0 R
+/Kids [2070 0 R 2079 0 R 2085 0 R 2096 0 R 2100 0 R 2104 0 R]
 >> endobj
-2106 0 obj <<
+2118 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2746 0 R
-/Kids [2103 0 R 2108 0 R 2115 0 R 2125 0 R 2184 0 R 2240 0 R]
+/Parent 2758 0 R
+/Kids [2115 0 R 2120 0 R 2127 0 R 2137 0 R 2196 0 R 2252 0 R]
 >> endobj
-2328 0 obj <<
+2340 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2746 0 R
-/Kids [2294 0 R 2330 0 R 2338 0 R 2346 0 R 2353 0 R 2358 0 R]
+/Parent 2758 0 R
+/Kids [2306 0 R 2342 0 R 2350 0 R 2358 0 R 2365 0 R 2370 0 R]
 >> endobj
-2367 0 obj <<
+2379 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2746 0 R
-/Kids [2364 0 R 2369 0 R 2378 0 R 2384 0 R 2389 0 R 2393 0 R]
+/Parent 2758 0 R
+/Kids [2376 0 R 2381 0 R 2390 0 R 2396 0 R 2401 0 R 2405 0 R]
 >> endobj
-2405 0 obj <<
+2417 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2747 0 R
-/Kids [2397 0 R 2407 0 R 2415 0 R 2426 0 R 2433 0 R 2445 0 R]
+/Parent 2759 0 R
+/Kids [2409 0 R 2419 0 R 2427 0 R 2438 0 R 2445 0 R 2457 0 R]
 >> endobj
-2456 0 obj <<
+2468 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2747 0 R
-/Kids [2449 0 R 2458 0 R 2466 0 R 2470 0 R 2475 0 R 2483 0 R]
+/Parent 2759 0 R
+/Kids [2461 0 R 2470 0 R 2478 0 R 2482 0 R 2487 0 R 2495 0 R]
 >> endobj
-2502 0 obj <<
+2514 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2747 0 R
-/Kids [2495 0 R 2504 0 R 2511 0 R 2520 0 R 2524 0 R 2528 0 R]
+/Parent 2759 0 R
+/Kids [2507 0 R 2516 0 R 2523 0 R 2532 0 R 2536 0 R 2540 0 R]
 >> endobj
-2541 0 obj <<
+2553 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2747 0 R
-/Kids [2532 0 R 2543 0 R 2554 0 R 2561 0 R 2565 0 R 2577 0 R]
+/Parent 2759 0 R
+/Kids [2544 0 R 2555 0 R 2566 0 R 2573 0 R 2577 0 R 2589 0 R]
 >> endobj
-2585 0 obj <<
+2597 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2747 0 R
-/Kids [2581 0 R 2587 0 R 2599 0 R 2609 0 R 2614 0 R 2618 0 R]
+/Parent 2759 0 R
+/Kids [2593 0 R 2599 0 R 2611 0 R 2621 0 R 2626 0 R 2630 0 R]
 >> endobj
-2634 0 obj <<
+2646 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 2747 0 R
-/Kids [2624 0 R 2636 0 R 2647 0 R 2652 0 R 2662 0 R 2668 0 R]
+/Parent 2759 0 R
+/Kids [2636 0 R 2648 0 R 2659 0 R 2664 0 R 2674 0 R 2680 0 R]
 >> endobj
-2690 0 obj <<
+2702 0 obj <<
 /Type /Pages
 /Count 4
-/Parent 2748 0 R
-/Kids [2680 0 R 2692 0 R 2707 0 R 2720 0 R]
+/Parent 2760 0 R
+/Kids [2692 0 R 2704 0 R 2719 0 R 2732 0 R]
 >> endobj
-2743 0 obj <<
+2755 0 obj <<
 /Type /Pages
 /Count 36
-/Parent 2749 0 R
-/Kids [931 0 R 1216 0 R 1277 0 R 1327 0 R 1382 0 R 1423 0 R]
+/Parent 2761 0 R
+/Kids [939 0 R 1226 0 R 1287 0 R 1337 0 R 1392 0 R 1433 0 R]
 >> endobj
-2744 0 obj <<
+2756 0 obj <<
 /Type /Pages
 /Count 36
-/Parent 2749 0 R
-/Kids [1479 0 R 1519 0 R 1561 0 R 1608 0 R 1643 0 R 1673 0 R]
+/Parent 2761 0 R
+/Kids [1489 0 R 1530 0 R 1573 0 R 1620 0 R 1655 0 R 1685 0 R]
 >> endobj
-2745 0 obj <<
+2757 0 obj <<
 /Type /Pages
 /Count 36
-/Parent 2749 0 R
-/Kids [1714 0 R 1747 0 R 1787 0 R 1820 0 R 1855 0 R 1901 0 R]
+/Parent 2761 0 R
+/Kids [1724 0 R 1759 0 R 1798 0 R 1832 0 R 1867 0 R 1913 0 R]
 >> endobj
-2746 0 obj <<
+2758 0 obj <<
 /Type /Pages
 /Count 36
-/Parent 2749 0 R
-/Kids [1962 0 R 2015 0 R 2065 0 R 2106 0 R 2328 0 R 2367 0 R]
+/Parent 2761 0 R
+/Kids [1974 0 R 2027 0 R 2077 0 R 2118 0 R 2340 0 R 2379 0 R]
 >> endobj
-2747 0 obj <<
+2759 0 obj <<
 /Type /Pages
 /Count 36
-/Parent 2749 0 R
-/Kids [2405 0 R 2456 0 R 2502 0 R 2541 0 R 2585 0 R 2634 0 R]
+/Parent 2761 0 R
+/Kids [2417 0 R 2468 0 R 2514 0 R 2553 0 R 2597 0 R 2646 0 R]
 >> endobj
-2748 0 obj <<
+2760 0 obj <<
 /Type /Pages
 /Count 4
-/Parent 2749 0 R
-/Kids [2690 0 R]
+/Parent 2761 0 R
+/Kids [2702 0 R]
 >> endobj
-2749 0 obj <<
+2761 0 obj <<
 /Type /Pages
 /Count 184
-/Kids [2743 0 R 2744 0 R 2745 0 R 2746 0 R 2747 0 R 2748 0 R]
+/Kids [2755 0 R 2756 0 R 2757 0 R 2758 0 R 2759 0 R 2760 0 R]
 >> endobj
-2750 0 obj <<
+2762 0 obj <<
 /Type /Outlines
 /First 7 0 R
-/Last 835 0 R
+/Last 843 0 R
 /Count 10
 >> endobj
+927 0 obj <<
+/Title 928 0 R
+/A 925 0 R
+/Parent 843 0 R
+/Prev 923 0 R
+>> endobj
+923 0 obj <<
+/Title 924 0 R
+/A 921 0 R
+/Parent 843 0 R
+/Prev 919 0 R
+/Next 927 0 R
+>> endobj
 919 0 obj <<
 /Title 920 0 R
 /A 917 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 915 0 R
+/Next 923 0 R
 >> endobj
 915 0 obj <<
 /Title 916 0 R
 /A 913 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 911 0 R
 /Next 919 0 R
 >> endobj
 911 0 obj <<
 /Title 912 0 R
 /A 909 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 907 0 R
 /Next 915 0 R
 >> endobj
 907 0 obj <<
 /Title 908 0 R
 /A 905 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 903 0 R
 /Next 911 0 R
 >> endobj
 903 0 obj <<
 /Title 904 0 R
 /A 901 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 899 0 R
 /Next 907 0 R
 >> endobj
 899 0 obj <<
 /Title 900 0 R
 /A 897 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 895 0 R
 /Next 903 0 R
 >> endobj
 895 0 obj <<
 /Title 896 0 R
 /A 893 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 891 0 R
 /Next 899 0 R
 >> endobj
 891 0 obj <<
 /Title 892 0 R
 /A 889 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 887 0 R
 /Next 895 0 R
 >> endobj
 887 0 obj <<
 /Title 888 0 R
 /A 885 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 883 0 R
 /Next 891 0 R
 >> endobj
 883 0 obj <<
 /Title 884 0 R
 /A 881 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 879 0 R
 /Next 887 0 R
 >> endobj
 879 0 obj <<
 /Title 880 0 R
 /A 877 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 875 0 R
 /Next 883 0 R
 >> endobj
 875 0 obj <<
 /Title 876 0 R
 /A 873 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 871 0 R
 /Next 879 0 R
 >> endobj
 871 0 obj <<
 /Title 872 0 R
 /A 869 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 867 0 R
 /Next 875 0 R
 >> endobj
 867 0 obj <<
 /Title 868 0 R
 /A 865 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 863 0 R
 /Next 871 0 R
 >> endobj
 863 0 obj <<
 /Title 864 0 R
 /A 861 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 859 0 R
 /Next 867 0 R
 >> endobj
 859 0 obj <<
 /Title 860 0 R
 /A 857 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 855 0 R
 /Next 863 0 R
 >> endobj
 855 0 obj <<
 /Title 856 0 R
 /A 853 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 851 0 R
 /Next 859 0 R
 >> endobj
 851 0 obj <<
 /Title 852 0 R
 /A 849 0 R
-/Parent 835 0 R
+/Parent 843 0 R
 /Prev 847 0 R
 /Next 855 0 R
 >> endobj
 847 0 obj <<
 /Title 848 0 R
 /A 845 0 R
-/Parent 835 0 R
-/Prev 843 0 R
+/Parent 843 0 R
 /Next 851 0 R
 >> endobj
 843 0 obj <<
 /Title 844 0 R
 /A 841 0 R
-/Parent 835 0 R
-/Prev 839 0 R
-/Next 847 0 R
+/Parent 2762 0 R
+/Prev 751 0 R
+/First 847 0 R
+/Last 927 0 R
+/Count -21
 >> endobj
 839 0 obj <<
 /Title 840 0 R
 /A 837 0 R
-/Parent 835 0 R
-/Next 843 0 R
+/Parent 787 0 R
+/Prev 811 0 R
 >> endobj
 835 0 obj <<
 /Title 836 0 R
 /A 833 0 R
-/Parent 2750 0 R
-/Prev 743 0 R
-/First 839 0 R
-/Last 919 0 R
-/Count -21
+/Parent 811 0 R
+/Prev 831 0 R
 >> endobj
 831 0 obj <<
 /Title 832 0 R
 /A 829 0 R
-/Parent 779 0 R
-/Prev 803 0 R
+/Parent 811 0 R
+/Prev 827 0 R
+/Next 835 0 R
 >> endobj
 827 0 obj <<
 /Title 828 0 R
 /A 825 0 R
-/Parent 803 0 R
+/Parent 811 0 R
 /Prev 823 0 R
+/Next 831 0 R
 >> endobj
 823 0 obj <<
 /Title 824 0 R
 /A 821 0 R
-/Parent 803 0 R
+/Parent 811 0 R
 /Prev 819 0 R
 /Next 827 0 R
 >> endobj
 819 0 obj <<
 /Title 820 0 R
 /A 817 0 R
-/Parent 803 0 R
+/Parent 811 0 R
 /Prev 815 0 R
 /Next 823 0 R
 >> endobj
 815 0 obj <<
 /Title 816 0 R
 /A 813 0 R
-/Parent 803 0 R
-/Prev 811 0 R
+/Parent 811 0 R
 /Next 819 0 R
 >> endobj
 811 0 obj <<
 /Title 812 0 R
 /A 809 0 R
-/Parent 803 0 R
+/Parent 787 0 R
 /Prev 807 0 R
-/Next 815 0 R
+/Next 839 0 R
+/First 815 0 R
+/Last 835 0 R
+/Count -6
 >> endobj
 807 0 obj <<
 /Title 808 0 R
 /A 805 0 R
-/Parent 803 0 R
+/Parent 787 0 R
+/Prev 803 0 R
 /Next 811 0 R
 >> endobj
 803 0 obj <<
 /Title 804 0 R
 /A 801 0 R
-/Parent 779 0 R
+/Parent 787 0 R
 /Prev 799 0 R
-/Next 831 0 R
-/First 807 0 R
-/Last 827 0 R
-/Count -6
+/Next 807 0 R
 >> endobj
 799 0 obj <<
 /Title 800 0 R
 /A 797 0 R
-/Parent 779 0 R
+/Parent 787 0 R
 /Prev 795 0 R
 /Next 803 0 R
 >> endobj
 795 0 obj <<
 /Title 796 0 R
 /A 793 0 R
-/Parent 779 0 R
+/Parent 787 0 R
 /Prev 791 0 R
 /Next 799 0 R
 >> endobj
 791 0 obj <<
 /Title 792 0 R
 /A 789 0 R
-/Parent 779 0 R
-/Prev 787 0 R
+/Parent 787 0 R
 /Next 795 0 R
 >> endobj
 787 0 obj <<
 /Title 788 0 R
 /A 785 0 R
-/Parent 779 0 R
-/Prev 783 0 R
-/Next 791 0 R
+/Parent 751 0 R
+/Prev 771 0 R
+/First 791 0 R
+/Last 839 0 R
+/Count -7
 >> endobj
 783 0 obj <<
 /Title 784 0 R
 /A 781 0 R
-/Parent 779 0 R
-/Next 787 0 R
+/Parent 771 0 R
+/Prev 779 0 R
 >> endobj
 779 0 obj <<
 /Title 780 0 R
 /A 777 0 R
-/Parent 743 0 R
-/Prev 763 0 R
-/First 783 0 R
-/Last 831 0 R
-/Count -7
+/Parent 771 0 R
+/Prev 775 0 R
+/Next 783 0 R
 >> endobj
 775 0 obj <<
 /Title 776 0 R
 /A 773 0 R
-/Parent 763 0 R
-/Prev 771 0 R
+/Parent 771 0 R
+/Next 779 0 R
 >> endobj
 771 0 obj <<
 /Title 772 0 R
 /A 769 0 R
-/Parent 763 0 R
-/Prev 767 0 R
-/Next 775 0 R
+/Parent 751 0 R
+/Prev 763 0 R
+/Next 787 0 R
+/First 775 0 R
+/Last 783 0 R
+/Count -3
 >> endobj
 767 0 obj <<
 /Title 768 0 R
 /A 765 0 R
 /Parent 763 0 R
-/Next 771 0 R
 >> endobj
 763 0 obj <<
 /Title 764 0 R
 /A 761 0 R
-/Parent 743 0 R
+/Parent 751 0 R
 /Prev 755 0 R
-/Next 779 0 R
+/Next 771 0 R
 /First 767 0 R
-/Last 775 0 R
-/Count -3
+/Last 767 0 R
+/Count -1
 >> endobj
 759 0 obj <<
 /Title 760 0 R
@@ -15054,8 +15125,7 @@ endobj
 755 0 obj <<
 /Title 756 0 R
 /A 753 0 R
-/Parent 743 0 R
-/Prev 747 0 R
+/Parent 751 0 R
 /Next 763 0 R
 /First 759 0 R
 /Last 759 0 R
@@ -15064,75 +15134,77 @@ endobj
 751 0 obj <<
 /Title 752 0 R
 /A 749 0 R
-/Parent 747 0 R
+/Parent 2762 0 R
+/Prev 731 0 R
+/Next 843 0 R
+/First 755 0 R
+/Last 787 0 R
+/Count -4
 >> endobj
 747 0 obj <<
 /Title 748 0 R
 /A 745 0 R
-/Parent 743 0 R
-/Next 755 0 R
-/First 751 0 R
-/Last 751 0 R
-/Count -1
+/Parent 731 0 R
+/Prev 743 0 R
 >> endobj
 743 0 obj <<
 /Title 744 0 R
 /A 741 0 R
-/Parent 2750 0 R
-/Prev 723 0 R
-/Next 835 0 R
-/First 747 0 R
-/Last 779 0 R
-/Count -4
+/Parent 731 0 R
+/Prev 735 0 R
+/Next 747 0 R
 >> endobj
 739 0 obj <<
 /Title 740 0 R
 /A 737 0 R
-/Parent 723 0 R
-/Prev 735 0 R
+/Parent 735 0 R
 >> endobj
 735 0 obj <<
 /Title 736 0 R
 /A 733 0 R
-/Parent 723 0 R
-/Prev 727 0 R
-/Next 739 0 R
+/Parent 731 0 R
+/Next 743 0 R
+/First 739 0 R
+/Last 739 0 R
+/Count -1
 >> endobj
 731 0 obj <<
 /Title 732 0 R
 /A 729 0 R
-/Parent 727 0 R
+/Parent 2762 0 R
+/Prev 707 0 R
+/Next 751 0 R
+/First 735 0 R
+/Last 747 0 R
+/Count -3
 >> endobj
 727 0 obj <<
 /Title 728 0 R
 /A 725 0 R
-/Parent 723 0 R
-/Next 735 0 R
-/First 731 0 R
-/Last 731 0 R
-/Count -1
+/Parent 707 0 R
+/Prev 715 0 R
 >> endobj
 723 0 obj <<
 /Title 724 0 R
 /A 721 0 R
-/Parent 2750 0 R
-/Prev 699 0 R
-/Next 743 0 R
-/First 727 0 R
-/Last 739 0 R
-/Count -3
+/Parent 715 0 R
+/Prev 719 0 R
 >> endobj
 719 0 obj <<
 /Title 720 0 R
 /A 717 0 R
-/Parent 699 0 R
-/Prev 707 0 R
+/Parent 715 0 R
+/Next 723 0 R
 >> endobj
 715 0 obj <<
 /Title 716 0 R
 /A 713 0 R
 /Parent 707 0 R
 /Prev 711 0 R
+/Next 727 0 R
+/First 719 0 R
+/Last 723 0 R
+/Count -2
 >> endobj
 711 0 obj <<
 /Title 712 0 R
@@ -15143,47 +15215,44 @@ endobj
 707 0 obj <<
 /Title 708 0 R
 /A 705 0 R
-/Parent 699 0 R
-/Prev 703 0 R
-/Next 719 0 R
+/Parent 2762 0 R
+/Prev 363 0 R
+/Next 731 0 R
 /First 711 0 R
-/Last 715 0 R
-/Count -2
+/Last 727 0 R
+/Count -3
 >> endobj
 703 0 obj <<
 /Title 704 0 R
 /A 701 0 R
-/Parent 699 0 R
-/Next 707 0 R
+/Parent 683 0 R
+/Prev 699 0 R
 >> endobj
 699 0 obj <<
 /Title 700 0 R
 /A 697 0 R
-/Parent 2750 0 R
-/Prev 355 0 R
-/Next 723 0 R
-/First 703 0 R
-/Last 719 0 R
-/Count -3
+/Parent 683 0 R
+/Prev 695 0 R
+/Next 703 0 R
 >> endobj
 695 0 obj <<
 /Title 696 0 R
 /A 693 0 R
-/Parent 675 0 R
+/Parent 683 0 R
 /Prev 691 0 R
+/Next 699 0 R
 >> endobj
 691 0 obj <<
 /Title 692 0 R
 /A 689 0 R
-/Parent 675 0 R
+/Parent 683 0 R
 /Prev 687 0 R
 /Next 695 0 R
 >> endobj
 687 0 obj <<
 /Title 688 0 R
 /A 685 0 R
-/Parent 675 0 R
-/Prev 683 0 R
+/Parent 683 0 R
 /Next 691 0 R
 >> endobj
 683 0 obj <<
@@ -15191,7 +15260,9 @@ endobj
 /A 681 0 R
 /Parent 675 0 R
 /Prev 679 0 R
-/Next 687 0 R
+/First 687 0 R
+/Last 703 0 R
+/Count -5
 >> endobj
 679 0 obj <<
 /Title 680 0 R
@@ -15202,682 +15273,681 @@ endobj
 675 0 obj <<
 /Title 676 0 R
 /A 673 0 R
-/Parent 667 0 R
-/Prev 671 0 R
+/Parent 363 0 R
+/Prev 619 0 R
 /First 679 0 R
-/Last 695 0 R
-/Count -5
+/Last 683 0 R
+/Count -2
 >> endobj
 671 0 obj <<
 /Title 672 0 R
 /A 669 0 R
-/Parent 667 0 R
-/Next 675 0 R
+/Parent 619 0 R
+/Prev 667 0 R
 >> endobj
 667 0 obj <<
 /Title 668 0 R
 /A 665 0 R
-/Parent 355 0 R
-/Prev 611 0 R
-/First 671 0 R
-/Last 675 0 R
-/Count -2
+/Parent 619 0 R
+/Prev 647 0 R
+/Next 671 0 R
 >> endobj
 663 0 obj <<
 /Title 664 0 R
 /A 661 0 R
-/Parent 611 0 R
+/Parent 647 0 R
 /Prev 659 0 R
 >> endobj
 659 0 obj <<
 /Title 660 0 R
 /A 657 0 R
-/Parent 611 0 R
-/Prev 639 0 R
+/Parent 647 0 R
+/Prev 655 0 R
 /Next 663 0 R
 >> endobj
 655 0 obj <<
 /Title 656 0 R
 /A 653 0 R
-/Parent 639 0 R
+/Parent 647 0 R
 /Prev 651 0 R
+/Next 659 0 R
 >> endobj
 651 0 obj <<
 /Title 652 0 R
 /A 649 0 R
-/Parent 639 0 R
-/Prev 647 0 R
+/Parent 647 0 R
 /Next 655 0 R
 >> endobj
 647 0 obj <<
 /Title 648 0 R
 /A 645 0 R
-/Parent 639 0 R
+/Parent 619 0 R
 /Prev 643 0 R
-/Next 651 0 R
+/Next 667 0 R
+/First 651 0 R
+/Last 663 0 R
+/Count -4
 >> endobj
 643 0 obj <<
 /Title 644 0 R
 /A 641 0 R
-/Parent 639 0 R
+/Parent 619 0 R
+/Prev 639 0 R
 /Next 647 0 R
 >> endobj
 639 0 obj <<
 /Title 640 0 R
 /A 637 0 R
-/Parent 611 0 R
+/Parent 619 0 R
 /Prev 635 0 R
-/Next 659 0 R
-/First 643 0 R
-/Last 655 0 R
-/Count -4
+/Next 643 0 R
 >> endobj
 635 0 obj <<
 /Title 636 0 R
 /A 633 0 R
-/Parent 611 0 R
-/Prev 631 0 R
+/Parent 619 0 R
+/Prev 623 0 R
 /Next 639 0 R
 >> endobj
 631 0 obj <<
 /Title 632 0 R
 /A 629 0 R
-/Parent 611 0 R
+/Parent 623 0 R
 /Prev 627 0 R
-/Next 635 0 R
 >> endobj
 627 0 obj <<
 /Title 628 0 R
 /A 625 0 R
-/Parent 611 0 R
-/Prev 615 0 R
+/Parent 623 0 R
 /Next 631 0 R
 >> endobj
 623 0 obj <<
 /Title 624 0 R
 /A 621 0 R
-/Parent 615 0 R
-/Prev 619 0 R
+/Parent 619 0 R
+/Next 635 0 R
+/First 627 0 R
+/Last 631 0 R
+/Count -2
 >> endobj
 619 0 obj <<
 /Title 620 0 R
 /A 617 0 R
-/Parent 615 0 R
-/Next 623 0 R
+/Parent 363 0 R
+/Prev 395 0 R
+/Next 675 0 R
+/First 623 0 R
+/Last 671 0 R
+/Count -7
 >> endobj
 615 0 obj <<
 /Title 616 0 R
 /A 613 0 R
-/Parent 611 0 R
-/Next 627 0 R
-/First 619 0 R
-/Last 623 0 R
-/Count -2
+/Parent 599 0 R
+/Prev 611 0 R
 >> endobj
 611 0 obj <<
 /Title 612 0 R
 /A 609 0 R
-/Parent 355 0 R
-/Prev 387 0 R
-/Next 667 0 R
-/First 615 0 R
-/Last 663 0 R
-/Count -7
+/Parent 599 0 R
+/Prev 607 0 R
+/Next 615 0 R
 >> endobj
 607 0 obj <<
 /Title 608 0 R
 /A 605 0 R
-/Parent 591 0 R
+/Parent 599 0 R
 /Prev 603 0 R
+/Next 611 0 R
 >> endobj
 603 0 obj <<
 /Title 604 0 R
 /A 601 0 R
-/Parent 591 0 R
-/Prev 599 0 R
+/Parent 599 0 R
 /Next 607 0 R
 >> endobj
 599 0 obj <<
 /Title 600 0 R
 /A 597 0 R
-/Parent 591 0 R
+/Parent 395 0 R
 /Prev 595 0 R
-/Next 603 0 R
+/First 603 0 R
+/Last 615 0 R
+/Count -4
 >> endobj
 595 0 obj <<
 /Title 596 0 R
 /A 593 0 R
-/Parent 591 0 R
+/Parent 395 0 R
+/Prev 591 0 R
 /Next 599 0 R
 >> endobj
 591 0 obj <<
 /Title 592 0 R
 /A 589 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 587 0 R
-/First 595 0 R
-/Last 607 0 R
-/Count -4
+/Next 595 0 R
 >> endobj
 587 0 obj <<
 /Title 588 0 R
 /A 585 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 583 0 R
 /Next 591 0 R
 >> endobj
 583 0 obj <<
 /Title 584 0 R
 /A 581 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 579 0 R
 /Next 587 0 R
 >> endobj
 579 0 obj <<
 /Title 580 0 R
 /A 577 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 575 0 R
 /Next 583 0 R
 >> endobj
 575 0 obj <<
 /Title 576 0 R
 /A 573 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 571 0 R
 /Next 579 0 R
 >> endobj
 571 0 obj <<
 /Title 572 0 R
 /A 569 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 567 0 R
 /Next 575 0 R
 >> endobj
 567 0 obj <<
 /Title 568 0 R
 /A 565 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 563 0 R
 /Next 571 0 R
 >> endobj
 563 0 obj <<
 /Title 564 0 R
 /A 561 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 559 0 R
 /Next 567 0 R
 >> endobj
 559 0 obj <<
 /Title 560 0 R
 /A 557 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 555 0 R
 /Next 563 0 R
 >> endobj
 555 0 obj <<
 /Title 556 0 R
 /A 553 0 R
-/Parent 387 0 R
-/Prev 551 0 R
+/Parent 395 0 R
+/Prev 471 0 R
 /Next 559 0 R
 >> endobj
 551 0 obj <<
 /Title 552 0 R
 /A 549 0 R
-/Parent 387 0 R
+/Parent 471 0 R
 /Prev 547 0 R
-/Next 555 0 R
 >> endobj
 547 0 obj <<
 /Title 548 0 R
 /A 545 0 R
-/Parent 387 0 R
-/Prev 463 0 R
+/Parent 471 0 R
+/Prev 543 0 R
 /Next 551 0 R
 >> endobj
 543 0 obj <<
 /Title 544 0 R
 /A 541 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 539 0 R
+/Next 547 0 R
 >> endobj
 539 0 obj <<
 /Title 540 0 R
 /A 537 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 535 0 R
 /Next 543 0 R
 >> endobj
 535 0 obj <<
 /Title 536 0 R
 /A 533 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 531 0 R
 /Next 539 0 R
 >> endobj
 531 0 obj <<
 /Title 532 0 R
 /A 529 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 527 0 R
 /Next 535 0 R
 >> endobj
 527 0 obj <<
 /Title 528 0 R
 /A 525 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 523 0 R
 /Next 531 0 R
 >> endobj
 523 0 obj <<
 /Title 524 0 R
 /A 521 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 519 0 R
 /Next 527 0 R
 >> endobj
 519 0 obj <<
 /Title 520 0 R
 /A 517 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 515 0 R
 /Next 523 0 R
 >> endobj
 515 0 obj <<
 /Title 516 0 R
 /A 513 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 511 0 R
 /Next 519 0 R
 >> endobj
 511 0 obj <<
 /Title 512 0 R
 /A 509 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 507 0 R
 /Next 515 0 R
 >> endobj
 507 0 obj <<
 /Title 508 0 R
 /A 505 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 503 0 R
 /Next 511 0 R
 >> endobj
 503 0 obj <<
 /Title 504 0 R
 /A 501 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 499 0 R
 /Next 507 0 R
 >> endobj
 499 0 obj <<
 /Title 500 0 R
 /A 497 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 495 0 R
 /Next 503 0 R
 >> endobj
 495 0 obj <<
 /Title 496 0 R
 /A 493 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 491 0 R
 /Next 499 0 R
 >> endobj
 491 0 obj <<
 /Title 492 0 R
 /A 489 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 487 0 R
 /Next 495 0 R
 >> endobj
 487 0 obj <<
 /Title 488 0 R
 /A 485 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 483 0 R
 /Next 491 0 R
 >> endobj
 483 0 obj <<
 /Title 484 0 R
 /A 481 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 479 0 R
 /Next 487 0 R
 >> endobj
 479 0 obj <<
 /Title 480 0 R
 /A 477 0 R
-/Parent 463 0 R
+/Parent 471 0 R
 /Prev 475 0 R
 /Next 483 0 R
 >> endobj
 475 0 obj <<
 /Title 476 0 R
 /A 473 0 R
-/Parent 463 0 R
-/Prev 471 0 R
+/Parent 471 0 R
 /Next 479 0 R
 >> endobj
 471 0 obj <<
 /Title 472 0 R
 /A 469 0 R
-/Parent 463 0 R
+/Parent 395 0 R
 /Prev 467 0 R
-/Next 475 0 R
+/Next 555 0 R
+/First 475 0 R
+/Last 551 0 R
+/Count -20
 >> endobj
 467 0 obj <<
 /Title 468 0 R
 /A 465 0 R
-/Parent 463 0 R
+/Parent 395 0 R
+/Prev 463 0 R
 /Next 471 0 R
 >> endobj
 463 0 obj <<
 /Title 464 0 R
 /A 461 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 459 0 R
-/Next 547 0 R
-/First 467 0 R
-/Last 543 0 R
-/Count -20
+/Next 467 0 R
 >> endobj
 459 0 obj <<
 /Title 460 0 R
 /A 457 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 455 0 R
 /Next 463 0 R
 >> endobj
 455 0 obj <<
 /Title 456 0 R
 /A 453 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 451 0 R
 /Next 459 0 R
 >> endobj
 451 0 obj <<
 /Title 452 0 R
 /A 449 0 R
-/Parent 387 0 R
-/Prev 447 0 R
+/Parent 395 0 R
+/Prev 435 0 R
 /Next 455 0 R
 >> endobj
 447 0 obj <<
 /Title 448 0 R
 /A 445 0 R
-/Parent 387 0 R
+/Parent 435 0 R
 /Prev 443 0 R
-/Next 451 0 R
 >> endobj
 443 0 obj <<
 /Title 444 0 R
 /A 441 0 R
-/Parent 387 0 R
-/Prev 427 0 R
+/Parent 435 0 R
+/Prev 439 0 R
 /Next 447 0 R
 >> endobj
 439 0 obj <<
 /Title 440 0 R
 /A 437 0 R
-/Parent 427 0 R
-/Prev 435 0 R
+/Parent 435 0 R
+/Next 443 0 R
 >> endobj
 435 0 obj <<
 /Title 436 0 R
 /A 433 0 R
-/Parent 427 0 R
+/Parent 395 0 R
 /Prev 431 0 R
-/Next 439 0 R
+/Next 451 0 R
+/First 439 0 R
+/Last 447 0 R
+/Count -3
 >> endobj
 431 0 obj <<
 /Title 432 0 R
 /A 429 0 R
-/Parent 427 0 R
+/Parent 395 0 R
+/Prev 427 0 R
 /Next 435 0 R
 >> endobj
 427 0 obj <<
 /Title 428 0 R
 /A 425 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 423 0 R
-/Next 443 0 R
-/First 431 0 R
-/Last 439 0 R
-/Count -3
+/Next 431 0 R
 >> endobj
 423 0 obj <<
 /Title 424 0 R
 /A 421 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 419 0 R
 /Next 427 0 R
 >> endobj
 419 0 obj <<
 /Title 420 0 R
 /A 417 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 415 0 R
 /Next 423 0 R
 >> endobj
 415 0 obj <<
 /Title 416 0 R
 /A 413 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 411 0 R
 /Next 419 0 R
 >> endobj
 411 0 obj <<
 /Title 412 0 R
 /A 409 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 407 0 R
 /Next 415 0 R
 >> endobj
 407 0 obj <<
 /Title 408 0 R
 /A 405 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 403 0 R
 /Next 411 0 R
 >> endobj
 403 0 obj <<
 /Title 404 0 R
 /A 401 0 R
-/Parent 387 0 R
+/Parent 395 0 R
 /Prev 399 0 R
 /Next 407 0 R
 >> endobj
 399 0 obj <<
 /Title 400 0 R
 /A 397 0 R
-/Parent 387 0 R
-/Prev 395 0 R
+/Parent 395 0 R
 /Next 403 0 R
 >> endobj
 395 0 obj <<
 /Title 396 0 R
 /A 393 0 R
-/Parent 387 0 R
-/Prev 391 0 R
-/Next 399 0 R
+/Parent 363 0 R
+/Prev 367 0 R
+/Next 619 0 R
+/First 399 0 R
+/Last 599 0 R
+/Count -28
 >> endobj
 391 0 obj <<
 /Title 392 0 R
 /A 389 0 R
-/Parent 387 0 R
-/Next 395 0 R
+/Parent 383 0 R
+/Prev 387 0 R
 >> endobj
 387 0 obj <<
 /Title 388 0 R
 /A 385 0 R
-/Parent 355 0 R
-/Prev 359 0 R
-/Next 611 0 R
-/First 391 0 R
-/Last 591 0 R
-/Count -28
+/Parent 383 0 R
+/Next 391 0 R
 >> endobj
 383 0 obj <<
 /Title 384 0 R
 /A 381 0 R
-/Parent 375 0 R
-/Prev 379 0 R
+/Parent 367 0 R
+/Prev 371 0 R
+/First 387 0 R
+/Last 391 0 R
+/Count -2
 >> endobj
 379 0 obj <<
 /Title 380 0 R
 /A 377 0 R
-/Parent 375 0 R
-/Next 383 0 R
+/Parent 371 0 R
+/Prev 375 0 R
 >> endobj
 375 0 obj <<
 /Title 376 0 R
 /A 373 0 R
-/Parent 359 0 R
-/Prev 363 0 R
-/First 379 0 R
-/Last 383 0 R
-/Count -2
+/Parent 371 0 R
+/Next 379 0 R
 >> endobj
 371 0 obj <<
 /Title 372 0 R
 /A 369 0 R
-/Parent 363 0 R
-/Prev 367 0 R
+/Parent 367 0 R
+/Next 383 0 R
+/First 375 0 R
+/Last 379 0 R
+/Count -2
 >> endobj
 367 0 obj <<
 /Title 368 0 R
 /A 365 0 R
 /Parent 363 0 R
-/Next 371 0 R
+/Next 395 0 R
+/First 371 0 R
+/Last 383 0 R
+/Count -2
 >> endobj
 363 0 obj <<
 /Title 364 0 R
 /A 361 0 R
-/Parent 359 0 R
-/Next 375 0 R
+/Parent 2762 0 R
+/Prev 351 0 R
+/Next 707 0 R
 /First 367 0 R
-/Last 371 0 R
-/Count -2
+/Last 675 0 R
+/Count -4
 >> endobj
 359 0 obj <<
 /Title 360 0 R
 /A 357 0 R
-/Parent 355 0 R
-/Next 387 0 R
-/First 363 0 R
-/Last 375 0 R
-/Count -2
+/Parent 351 0 R
+/Prev 355 0 R
 >> endobj
 355 0 obj <<
 /Title 356 0 R
 /A 353 0 R
-/Parent 2750 0 R
-/Prev 343 0 R
-/Next 699 0 R
-/First 359 0 R
-/Last 667 0 R
-/Count -4
+/Parent 351 0 R
+/Next 359 0 R
 >> endobj
 351 0 obj <<
 /Title 352 0 R
 /A 349 0 R
-/Parent 343 0 R
-/Prev 347 0 R
+/Parent 2762 0 R
+/Prev 131 0 R
+/Next 363 0 R
+/First 355 0 R
+/Last 359 0 R
+/Count -2
 >> endobj
 347 0 obj <<
 /Title 348 0 R
 /A 345 0 R
-/Parent 343 0 R
-/Next 351 0 R
+/Parent 339 0 R
+/Prev 343 0 R
 >> endobj
 343 0 obj <<
 /Title 344 0 R
 /A 341 0 R
-/Parent 2750 0 R
-/Prev 131 0 R
-/Next 355 0 R
-/First 347 0 R
-/Last 351 0 R
-/Count -2
+/Parent 339 0 R
+/Next 347 0 R
 >> endobj
 339 0 obj <<
 /Title 340 0 R
 /A 337 0 R
-/Parent 331 0 R
-/Prev 335 0 R
+/Parent 131 0 R
+/Prev 287 0 R
+/First 343 0 R
+/Last 347 0 R
+/Count -2
 >> endobj
 335 0 obj <<
 /Title 336 0 R
 /A 333 0 R
-/Parent 331 0 R
-/Next 339 0 R
+/Parent 287 0 R
+/Prev 331 0 R
 >> endobj
 331 0 obj <<
 /Title 332 0 R
 /A 329 0 R
-/Parent 131 0 R
-/Prev 287 0 R
-/First 335 0 R
-/Last 339 0 R
-/Count -2
+/Parent 287 0 R
+/Prev 327 0 R
+/Next 335 0 R
 >> endobj
 327 0 obj <<
 /Title 328 0 R
 /A 325 0 R
 /Parent 287 0 R
 /Prev 323 0 R
+/Next 331 0 R
 >> endobj
 323 0 obj <<
 /Title 324 0 R
 /A 321 0 R
 /Parent 287 0 R
-/Prev 319 0 R
+/Prev 307 0 R
 /Next 327 0 R
 >> endobj
 319 0 obj <<
 /Title 320 0 R
 /A 317 0 R
-/Parent 287 0 R
+/Parent 307 0 R
 /Prev 315 0 R
-/Next 323 0 R
 >> endobj
 315 0 obj <<
 /Title 316 0 R
 /A 313 0 R
-/Parent 287 0 R
-/Prev 303 0 R
+/Parent 307 0 R
+/Prev 311 0 R
 /Next 319 0 R
 >> endobj
 311 0 obj <<
 /Title 312 0 R
 /A 309 0 R
-/Parent 303 0 R
-/Prev 307 0 R
+/Parent 307 0 R
+/Next 315 0 R
 >> endobj
 307 0 obj <<
 /Title 308 0 R
 /A 305 0 R
-/Parent 303 0 R
-/Next 311 0 R
+/Parent 287 0 R
+/Prev 291 0 R
+/Next 323 0 R
+/First 311 0 R
+/Last 319 0 R
+/Count -3
 >> endobj
 303 0 obj <<
 /Title 304 0 R
 /A 301 0 R
-/Parent 287 0 R
-/Prev 291 0 R
-/Next 315 0 R
-/First 307 0 R
-/Last 311 0 R
-/Count -2
+/Parent 291 0 R
+/Prev 299 0 R
 >> endobj
 299 0 obj <<
 /Title 300 0 R
 /A 297 0 R
 /Parent 291 0 R
 /Prev 295 0 R
+/Next 303 0 R
 >> endobj
 295 0 obj <<
 /Title 296 0 R
@@ -15889,19 +15959,19 @@ endobj
 /Title 292 0 R
 /A 289 0 R
 /Parent 287 0 R
-/Next 303 0 R
+/Next 307 0 R
 /First 295 0 R
-/Last 299 0 R
-/Count -2
+/Last 303 0 R
+/Count -3
 >> endobj
 287 0 obj <<
 /Title 288 0 R
 /A 285 0 R
 /Parent 131 0 R
 /Prev 275 0 R
-/Next 331 0 R
+/Next 339 0 R
 /First 291 0 R
-/Last 327 0 R
+/Last 335 0 R
 /Count -6
 >> endobj
 283 0 obj <<
@@ -16179,11 +16249,11 @@ endobj
 131 0 obj <<
 /Title 132 0 R
 /A 129 0 R
-/Parent 2750 0 R
+/Parent 2762 0 R
 /Prev 91 0 R
-/Next 343 0 R
+/Next 351 0 R
 /First 135 0 R
-/Last 331 0 R
+/Last 339 0 R
 /Count -12
 >> endobj
 127 0 obj <<
@@ -16253,7 +16323,7 @@ endobj
 91 0 obj <<
 /Title 92 0 R
 /A 89 0 R
-/Parent 2750 0 R
+/Parent 2762 0 R
 /Prev 67 0 R
 /Next 131 0 R
 /First 95 0 R
@@ -16296,7 +16366,7 @@ endobj
 67 0 obj <<
 /Title 68 0 R
 /A 65 0 R
-/Parent 2750 0 R
+/Parent 2762 0 R
 /Prev 7 0 R
 /Next 91 0 R
 /First 71 0 R
@@ -16405,2268 +16475,2235 @@ endobj
 7 0 obj <<
 /Title 8 0 R
 /A 5 0 R
-/Parent 2750 0 R
+/Parent 2762 0 R
 /Next 67 0 R
 /First 11 0 R
 /Last 23 0 R
 /Count -4
 >> endobj
-2751 0 obj <<
-/Names [(Access_Control_Lists) 2071 0 R (Bv9ARM.ch01) 1220 0 R (Bv9ARM.ch02) 1264 0 R (Bv9ARM.ch03) 1282 0 R (Bv9ARM.ch04) 1345 0 R (Bv9ARM.ch05) 1524 0 R (Bv9ARM.ch06) 1535 0 R (Bv9ARM.ch07) 2070 0 R (Bv9ARM.ch08) 2095 0 R (Bv9ARM.ch09) 2111 0 R (Bv9ARM.ch10) 2372 0 R (Configuration_File_Grammar) 1558 0 R (DNSSEC) 1411 0 R (Doc-Start) 927 0 R (Setting_TTLs) 1995 0 R (acache) 1271 0 R (access_control) 1712 0 R (acl) 1567 0 R (address_match_lists) 1540 0 R (admin_tools) 1304 0 R (appendix.A) 742 0 R (appendix.B) 834 0 R (bibliography) 2119 0 R (bind9.library) 2327 0 R (boolean_options) 1360 0 R (builtin) 1793 0 R (chapter*.1) 961 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 342 0 R (chapter.6) 354 0 R (chapter.7) 698 0 R (chapter.8) 722 0 R (cite.RFC1033) 2246 0 R (cite.RFC1034) 2131 0 R (cite.RFC1035) 2133 0 R (cite.RFC1101) 2228 0 R (cite.RFC1123) 2230 0 R (cite.RFC1183) 2190 0 R (cite.RFC1464) 2268 0 R (cite.RFC1535) 2176 0 R (cite.RFC1536) 2178 0 R (cite.RFC1537) 2248 0 R (cite.RFC1591) 2232 0 R (cite.RFC1706) 2192 0 R (cite.RFC1712) 2288 0 R (cite.RFC1713) 2270 0 R (cite.RFC1794) 2272 0 R (cite.RFC1876) 2194 0 R (cite.RFC1912) 2250 0 R (cite.RFC1982) 2180 0 R (cite.RFC1995) 2138 0 R (cite.RFC1996) 2140 0 R (cite.RFC2010) 2252 0 R (cite.RFC2052) 2196 0 R (cite.RFC2065) 2300 0 R (cite.RFC2136) 2142 0 R (cite.RFC2137) 2302 0 R (cite.RFC2163) 2198 0 R (cite.RFC2168) 2200 0 R (cite.RFC2181) 2144 0 R (cite.RFC2219) 2254 0 R (cite.RFC2230) 2202 0 R (cite.RFC2240) 2274 0 R (cite.RFC2308) 2146 0 R (cite.RFC2317) 2234 0 R (cite.RFC2345) 2276 0 R (cite.RFC2352) 2278 0 R (cite.RFC2535) 2304 0 R (cite.RFC2536) 2204 0 R (cite.RFC2537) 2206 0 R (cite.RFC2538) 2208 0 R (cite.RFC2539) 2210 0 R (cite.RFC2540) 2212 0 R (cite.RFC2671) 2148 0 R (cite.RFC2672) 2150 0 R (cite.RFC2673) 2290 0 R (cite.RFC2782) 2214 0 R (cite.RFC2825) 2258 0 R (cite.RFC2826) 2236 0 R (cite.RFC2845) 2152 0 R (cite.RFC2874) 2292 0 R (cite.RFC2915) 2216 0 R (cite.RFC2929) 2238 0 R (cite.RFC2930) 2154 0 R (cite.RFC2931) 2156 0 R (cite.RFC3007) 2158 0 R (cite.RFC3008) 2306 0 R (cite.RFC3071) 2280 0 R (cite.RFC3090) 2308 0 R (cite.RFC3110) 2218 0 R (cite.RFC3123) 2220 0 R (cite.RFC3225) 2164 0 R (cite.RFC3258) 2282 0 R (cite.RFC3445) 2310 0 R (cite.RFC3490) 2260 0 R (cite.RFC3491) 2262 0 R (cite.RFC3492) 2264 0 R (cite.RFC3596) 2222 0 R (cite.RFC3597) 2224 0 R (cite.RFC3645) 2160 0 R (cite.RFC3655) 2312 0 R (cite.RFC3658) 2314 0 R (cite.RFC3755) 2316 0 R (cite.RFC3757) 2318 0 R (cite.RFC3833) 2166 0 R (cite.RFC3845) 2320 0 R (cite.RFC3901) 2284 0 R (cite.RFC4033) 2168 0 R (cite.RFC4034) 2170 0 R (cite.RFC4035) 2172 0 R (cite.RFC4074) 2182 0 R (cite.RFC974) 2135 0 R (cite.id2512717) 2325 0 R (clients-per-query) 2048 0 R (configuration_file_elements) 1536 0 R (controls_statement_definition_and_usage) 1328 0 R (diagnostic_tools) 1252 0 R (dnssec.dynamic.zones) 1431 0 R (dynamic_update) 1355 0 R (dynamic_update_policies) 1317 0 R (dynamic_update_security) 1722 0 R (empty) 1795 0 R (historical_dns_information) 2113 0 R (id2466563) 1221 0 R (id2466586) 1222 0 R (id2467317) 1433 0 R (id2467353) 1438 0 R (id2467477) 1223 0 R (id2467486) 1224 0 R (id2467726) 1234 0 R (id2467748) 1235 0 R (id2467782) 1236 0 R (id2467866) 1239 0 R (id2467959) 1232 0 R (id2470264) 1246 0 R (id2470288) 1249 0 R (id2470386) 1250 0 R (id2470407) 1251 0 R (id2470505) 1257 0 R (id2470540) 1258 0 R (id2470567) 1259 0 R (id2470601) 1265 0 R (id2470628) 1266 0 R (id2470709) 1267 0 R (id2470734) 1270 0 R (id2470745) 1276 0 R (id2470777) 1284 0 R (id2470793) 1285 0 R (id2470816) 1290 0 R (id2470833) 1291 0 R (id2471238) 1299 0 R (id2471243) 1300 0 R (id2473501) 1333 0 R (id2473513) 1334 0 R (id2474008) 1370 0 R (id2474026) 1376 0 R (id2474596) 1392 0 R (id2474681) 1393 0 R (id2474720) 1394 0 R (id2474806) 1395 0 R (id2474817) 1396 0 R (id2474853) 1401 0 R (id2474910) 1402 0 R (id2474960) 1404 0 R (id2474973) 1405 0 R (id2475091) 1410 0 R (id2475227) 1412 0 R (id2475374) 1417 0 R (id2475456) 1418 0 R (id2475608) 1432 0 R (id2476195) 1450 0 R (id2476232) 1451 0 R (id2476245) 1452 0 R (id2476278) 1453 0 R (id2476373) 1458 0 R (id2476382) 1459 0 R (id2476392) 1460 0 R (id2476405) 1461 0 R (id2476510) 1462 0 R (id2476520) 1463 0 R (id2476556) 1469 0 R (id2476579) 1471 0 R (id2476680) 1478 0 R (id2476913) 1484 0 R (id2476982) 1485 0 R (id2477156) 1490 0 R (id2477164) 1491 0 R (id2477195) 1492 0 R (id2477251) 1497 0 R (id2477282) 1498 0 R (id2477753) 1503 0 R (id2477799) 1504 0 R (id2477853) 1510 0 R (id2477915) 1512 0 R (id2477937) 1518 0 R (id2478038) 1525 0 R (id2478185) 1537 0 R (id2479078) 1545 0 R (id2479106) 1550 0 R (id2479380) 1551 0 R (id2479395) 1552 0 R (id2479425) 1557 0 R (id2479499) 1559 0 R (id2480040) 1566 0 R (id2480083) 1568 0 R (id2480298) 1570 0 R (id2480589) 1577 0 R (id2480606) 1583 0 R (id2480630) 1584 0 R (id2480653) 1585 0 R (id2480881) 1589 0 R (id2481006) 1594 0 R (id2481059) 1595 0 R (id2481684) 1606 0 R (id2482513) 1617 0 R (id2482574) 1618 0 R (id2482964) 1624 0 R (id2483106) 1625 0 R (id2483170) 1632 0 R (id2483213) 1633 0 R (id2483235) 1634 0 R (id2486741) 1678 0 R (id2488967) 1709 0 R (id2489026) 1711 0 R (id2489645) 1727 0 R (id2490862) 1745 0 R (id2490922) 1752 0 R (id2491276) 1760 0 R (id2491915) 1774 0 R (id2493479) 1809 0 R (id2493738) 1815 0 R (id2494908) 1837 0 R (id2495116) 1839 0 R (id2495163) 1845 0 R (id2495589) 1850 0 R (id2497132) 1868 0 R (id2497140) 1869 0 R (id2497145) 1870 0 R (id2497922) 1886 0 R (id2497955) 1887 0 R (id2500103) 1954 0 R (id2500766) 1960 0 R (id2500785) 1961 0 R (id2500805) 1969 0 R (id2500973) 1971 0 R (id2502212) 1977 0 R (id2502340) 1983 0 R (id2502361) 1984 0 R (id2502792) 1986 0 R (id2502929) 1992 0 R (id2502947) 1993 0 R (id2503488) 1996 0 R (id2503612) 2002 0 R (id2503627) 2003 0 R (id2503739) 2005 0 R (id2503762) 2006 0 R (id2503778) 2007 0 R (id2503838) 2012 0 R (id2503908) 2013 0 R (id2503944) 2014 0 R (id2504088) 2020 0 R (id2504531) 2027 0 R (id2504966) 2035 0 R (id2504971) 2036 0 R (id2506439) 2043 0 R (id2506445) 2044 0 R (id2506890) 2046 0 R (id2506896) 2047 0 R (id2507980) 2054 0 R (id2508012) 2055 0 R (id2508422) 2064 0 R (id2508732) 2080 0 R (id2508813) 2081 0 R (id2508873) 2082 0 R (id2509021) 2096 0 R (id2509027) 2097 0 R (id2509038) 2098 0 R (id2509056) 2099 0 R (id2509117) 2112 0 R (id2509289) 2118 0 R (id2509477) 2123 0 R (id2509479) 2129 0 R (id2509556) 2134 0 R (id2509579) 2130 0 R (id2509603) 2132 0 R (id2509639) 2143 0 R (id2509666) 2145 0 R (id2509691) 2137 0 R (id2509716) 2139 0 R (id2509739) 2141 0 R (id2509795) 2147 0 R (id2509821) 2149 0 R (id2509848) 2151 0 R (id2509910) 2153 0 R (id2509940) 2155 0 R (id2510038) 2157 0 R (id2510065) 2159 0 R (id2510139) 2162 0 R (id2510147) 2163 0 R (id2510173) 2165 0 R (id2510210) 2167 0 R (id2510275) 2169 0 R (id2510340) 2171 0 R (id2510405) 2174 0 R (id2510413) 2175 0 R (id2510439) 2177 0 R (id2510507) 2179 0 R (id2510542) 2181 0 R (id2510583) 2188 0 R (id2510588) 2189 0 R (id2510646) 2191 0 R (id2510683) 2199 0 R (id2510718) 2193 0 R (id2510773) 2195 0 R (id2510811) 2197 0 R (id2510837) 2201 0 R (id2510931) 2203 0 R (id2510957) 2205 0 R (id2510984) 2207 0 R (id2511024) 2209 0 R (id2511053) 2211 0 R (id2511083) 2213 0 R (id2511126) 2215 0 R (id2511159) 2217 0 R (id2511186) 2219 0 R (id2511209) 2221 0 R (id2511267) 2223 0 R (id2511291) 2226 0 R (id2511299) 2227 0 R (id2511324) 2229 0 R (id2511347) 2231 0 R (id2511370) 2233 0 R (id2511416) 2235 0 R (id2511440) 2237 0 R (id2511490) 2244 0 R (id2511497) 2245 0 R (id2511521) 2247 0 R (id2511547) 2249 0 R (id2511574) 2251 0 R (id2511610) 2253 0 R (id2511651) 2256 0 R (id2511656) 2257 0 R (id2511688) 2259 0 R (id2511734) 2261 0 R (id2511769) 2263 0 R (id2511796) 2266 0 R (id2511814) 2267 0 R (id2511836) 2269 0 R (id2511862) 2271 0 R (id2511888) 2273 0 R (id2511911) 2275 0 R (id2511957) 2277 0 R (id2511980) 2279 0 R (id2512007) 2281 0 R (id2512101) 2283 0 R (id2512138) 2286 0 R (id2512145) 2287 0 R (id2512202) 2289 0 R (id2512229) 2291 0 R (id2512265) 2298 0 R (id2512277) 2299 0 R (id2512316) 2301 0 R (id2512343) 2303 0 R (id2512373) 2305 0 R (id2512398) 2307 0 R (id2512493) 2309 0 R (id2512530) 2311 0 R (id2512566) 2313 0 R (id2512593) 2315 0 R (id2512619) 2317 0 R (id2512664) 2319 0 R (id2512706) 2322 0 R (id2512715) 2324 0 R (id2512717) 2326 0 R (id2512805) 2333 0 R (id2512814) 2334 0 R (id2512907) 2335 0 R (id2512938) 2336 0 R (id2513015) 2341 0 R (id2513042) 2343 0 R (id2513050) 2344 0 R (id2513141) 2349 0 R (id2513262) 2350 0 R (id2513395) 2351 0 R (id2513410) 2356 0 R (id2513541) 2361 0 R (id2513673) 2362 0 R (incremental_zone_transfers) 1367 0 R (internet_drafts) 2321 0 R (ipv6addresses) 1513 0 R (journal) 1366 0 R (lwresd) 1526 0 R (man.arpaname) 2685 0 R (man.ddns-confgen) 2674 0 R (man.dig) 2373 0 R (man.dnssec-dsfromkey) 2421 0 R (man.dnssec-keyfromlabel) 2439 0 R (man.dnssec-keygen) 1444 0 R (man.dnssec-revoke) 2486 0 R (man.dnssec-settime) 1445 0 R (man.dnssec-signzone) 2514 0 R (man.genrandom) 2696 0 R (man.host) 2410 0 R (man.isc-hmac-fixup) 2703 0 R (man.named) 2571 0 R (man.named-checkconf) 2538 0 R (man.named-checkzone) 2551 0 R (man.named-journalprint) 2594 0 R (man.nsec3hash) 2714 0 R (man.nsupdate) 2604 0 R (man.rndc) 2629 0 R (man.rndc-confgen) 2658 0 R (man.rndc.conf) 2642 0 R (managed-keys) 1472 0 R (notify) 1346 0 R (options) 1316 0 R (page.1) 926 0 R (page.10) 1308 0 R (page.100) 1947 0 R (page.101) 1953 0 R (page.102) 1959 0 R (page.103) 1966 0 R (page.104) 1976 0 R (page.105) 1982 0 R (page.106) 1991 0 R (page.107) 2001 0 R (page.108) 2011 0 R (page.109) 2019 0 R (page.11) 1321 0 R (page.110) 2025 0 R (page.111) 2033 0 R (page.112) 2041 0 R (page.113) 2052 0 R (page.114) 2060 0 R (page.115) 2069 0 R (page.116) 2075 0 R (page.117) 2086 0 R (page.118) 2090 0 R (page.119) 2094 0 R (page.12) 1325 0 R (page.120) 2105 0 R (page.121) 2110 0 R (page.122) 2117 0 R (page.123) 2127 0 R (page.124) 2186 0 R (page.125) 2242 0 R (page.126) 2296 0 R (page.127) 2332 0 R (page.128) 2340 0 R (page.129) 2348 0 R (page.13) 1332 0 R (page.130) 2355 0 R (page.131) 2360 0 R (page.132) 2366 0 R (page.133) 2371 0 R (page.134) 2380 0 R (page.135) 2386 0 R (page.136) 2391 0 R (page.137) 2395 0 R (page.138) 2399 0 R (page.139) 2409 0 R (page.14) 1339 0 R (page.140) 2417 0 R (page.141) 2428 0 R (page.142) 2435 0 R (page.143) 2447 0 R (page.144) 2451 0 R (page.145) 2460 0 R (page.146) 2468 0 R (page.147) 2472 0 R (page.148) 2477 0 R (page.149) 2485 0 R (page.15) 1344 0 R (page.150) 2497 0 R (page.151) 2506 0 R (page.152) 2513 0 R (page.153) 2522 0 R (page.154) 2526 0 R (page.155) 2530 0 R (page.156) 2534 0 R (page.157) 2545 0 R (page.158) 2556 0 R (page.159) 2563 0 R (page.16) 1365 0 R (page.160) 2567 0 R (page.161) 2579 0 R (page.162) 2583 0 R (page.163) 2589 0 R (page.164) 2601 0 R (page.165) 2611 0 R (page.166) 2616 0 R (page.167) 2620 0 R (page.168) 2626 0 R (page.169) 2638 0 R (page.17) 1375 0 R (page.170) 2649 0 R (page.171) 2654 0 R (page.172) 2664 0 R (page.173) 2670 0 R (page.174) 2682 0 R (page.175) 2694 0 R (page.176) 2709 0 R (page.177) 2722 0 R (page.18) 1381 0 R (page.19) 1386 0 R (page.2) 950 0 R (page.20) 1391 0 R (page.21) 1400 0 R (page.22) 1409 0 R (page.23) 1416 0 R (page.24) 1422 0 R (page.25) 1427 0 R (page.26) 1437 0 R (page.27) 1449 0 R (page.28) 1457 0 R (page.29) 1467 0 R (page.3) 1245 0 R (page.30) 1476 0 R (page.31) 1483 0 R (page.32) 1489 0 R (page.33) 1496 0 R (page.34) 1502 0 R (page.35) 1509 0 R (page.36) 1517 0 R (page.37) 1523 0 R (page.38) 1530 0 R (page.39) 1534 0 R (page.4) 1256 0 R (page.40) 1544 0 R (page.41) 1549 0 R (page.42) 1556 0 R (page.43) 1565 0 R (page.44) 1574 0 R (page.45) 1582 0 R (page.46) 1593 0 R (page.47) 1599 0 R (page.48) 1605 0 R (page.49) 1612 0 R (page.5) 1263 0 R (page.50) 1616 0 R (page.51) 1623 0 R (page.52) 1631 0 R (page.53) 1638 0 R (page.54) 1642 0 R (page.55) 1647 0 R (page.56) 1651 0 R (page.57) 1655 0 R (page.58) 1661 0 R (page.59) 1666 0 R (page.6) 1275 0 R (page.60) 1671 0 R (page.61) 1677 0 R (page.62) 1684 0 R (page.63) 1694 0 R (page.64) 1698 0 R (page.65) 1702 0 R (page.66) 1708 0 R (page.67) 1719 0 R (page.68) 1726 0 R (page.69) 1731 0 R (page.7) 1281 0 R (page.70) 1736 0 R (page.71) 1740 0 R (page.72) 1744 0 R (page.73) 1751 0 R (page.74) 1759 0 R (page.75) 1765 0 R (page.76) 1772 0 R (page.77) 1779 0 R (page.78) 1785 0 R (page.79) 1792 0 R (page.8) 1289 0 R (page.80) 1800 0 R (page.81) 1804 0 R (page.82) 1808 0 R (page.83) 1814 0 R (page.84) 1819 0 R (page.85) 1824 0 R (page.86) 1829 0 R (page.87) 1835 0 R (page.88) 1844 0 R (page.89) 1849 0 R (page.9) 1298 0 R (page.90) 1854 0 R (page.91) 1859 0 R (page.92) 1863 0 R (page.93) 1867 0 R (page.94) 1875 0 R (page.95) 1879 0 R (page.96) 1885 0 R (page.97) 1905 0 R (page.98) 1920 0 R (page.99) 1930 0 R (page.i) 960 0 R (page.ii) 1015 0 R (page.iii) 1079 0 R (page.iv) 1142 0 R (page.v) 1204 0 R (pkcs11) 1477 0 R (proposed_standards) 1371 0 R (query_address) 1732 0 R (rfc5011.support) 1468 0 R (rfcs) 1241 0 R (rndc) 1578 0 R (root_delegation_only) 1881 0 R (rrset_ordering) 1294 0 R (sample_configuration) 1283 0 R (section*.10) 2255 0 R (section*.100) 2592 0 R (section*.101) 2593 0 R (section*.102) 2595 0 R (section*.103) 2596 0 R (section*.104) 2597 0 R (section*.105) 2602 0 R (section*.106) 2603 0 R (section*.107) 2605 0 R (section*.108) 2606 0 R (section*.109) 2607 0 R (section*.11) 2265 0 R (section*.110) 2612 0 R (section*.111) 2621 0 R (section*.112) 2622 0 R (section*.113) 2627 0 R (section*.114) 2628 0 R (section*.115) 2630 0 R (section*.116) 2631 0 R (section*.117) 2632 0 R (section*.118) 2633 0 R (section*.119) 2639 0 R (section*.12) 2285 0 R (section*.120) 2640 0 R (section*.121) 2641 0 R (section*.122) 2643 0 R (section*.123) 2644 0 R (section*.124) 2645 0 R (section*.125) 2650 0 R (section*.126) 2655 0 R (section*.127) 2656 0 R (section*.128) 2657 0 R (section*.129) 2659 0 R (section*.13) 2297 0 R (section*.130) 2660 0 R (section*.131) 2665 0 R (section*.132) 2666 0 R (section*.133) 2671 0 R (section*.134) 2672 0 R (section*.135) 2673 0 R (section*.136) 2675 0 R (section*.137) 2676 0 R (section*.138) 2677 0 R (section*.139) 2678 0 R (section*.14) 2323 0 R (section*.140) 2683 0 R (section*.141) 2684 0 R (section*.142) 2686 0 R (section*.143) 2687 0 R (section*.144) 2688 0 R (section*.145) 2689 0 R (section*.146) 2695 0 R (section*.147) 2697 0 R (section*.148) 2698 0 R (section*.149) 2699 0 R (section*.15) 2374 0 R (section*.150) 2700 0 R (section*.151) 2701 0 R (section*.152) 2702 0 R (section*.153) 2704 0 R (section*.154) 2705 0 R (section*.155) 2710 0 R (section*.156) 2711 0 R (section*.157) 2712 0 R (section*.158) 2713 0 R (section*.159) 2715 0 R (section*.16) 2375 0 R (section*.160) 2716 0 R (section*.161) 2717 0 R (section*.162) 2718 0 R (section*.163) 2723 0 R (section*.164) 2724 0 R (section*.17) 2376 0 R (section*.18) 2381 0 R (section*.19) 2382 0 R (section*.2) 2122 0 R (section*.20) 2387 0 R (section*.21) 2400 0 R (section*.22) 2401 0 R (section*.23) 2402 0 R (section*.24) 2403 0 R (section*.25) 2404 0 R (section*.26) 2411 0 R (section*.27) 2412 0 R (section*.28) 2413 0 R (section*.29) 2418 0 R (section*.3) 2128 0 R (section*.30) 2419 0 R (section*.31) 2420 0 R (section*.32) 2422 0 R (section*.33) 2423 0 R (section*.34) 2424 0 R (section*.35) 2429 0 R (section*.36) 2430 0 R (section*.37) 2431 0 R (section*.38) 2436 0 R (section*.39) 2437 0 R (section*.4) 2136 0 R (section*.40) 2438 0 R (section*.41) 2440 0 R (section*.42) 2441 0 R (section*.43) 2442 0 R (section*.44) 2443 0 R (section*.45) 2452 0 R (section*.46) 2453 0 R (section*.47) 2454 0 R (section*.48) 2455 0 R (section*.49) 2461 0 R (section*.5) 2161 0 R (section*.50) 2462 0 R (section*.51) 2463 0 R (section*.52) 2464 0 R (section*.53) 2473 0 R (section*.54) 2478 0 R (section*.55) 2479 0 R (section*.56) 2480 0 R (section*.57) 2481 0 R (section*.58) 2487 0 R (section*.59) 2488 0 R (section*.6) 2173 0 R (section*.60) 2489 0 R (section*.61) 2490 0 R (section*.62) 2491 0 R (section*.63) 2492 0 R (section*.64) 2493 0 R (section*.65) 2498 0 R (section*.66) 2499 0 R (section*.67) 2500 0 R (section*.68) 2501 0 R (section*.69) 2507 0 R (section*.7) 2187 0 R (section*.70) 2508 0 R (section*.71) 2509 0 R (section*.72) 2515 0 R (section*.73) 2516 0 R (section*.74) 2517 0 R (section*.75) 2518 0 R (section*.76) 2535 0 R (section*.77) 2536 0 R (section*.78) 2537 0 R (section*.79) 2539 0 R (section*.8) 2225 0 R (section*.80) 2540 0 R (section*.81) 2546 0 R (section*.82) 2547 0 R (section*.83) 2548 0 R (section*.84) 2549 0 R (section*.85) 2550 0 R (section*.86) 2552 0 R (section*.87) 2557 0 R (section*.88) 2558 0 R (section*.89) 2559 0 R (section*.9) 2243 0 R (section*.90) 2568 0 R (section*.91) 2569 0 R (section*.92) 2570 0 R (section*.93) 2572 0 R (section*.94) 2573 0 R (section*.95) 2574 0 R (section*.96) 2575 0 R (section*.97) 2584 0 R (section*.98) 2590 0 R (section*.99) 2591 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.10) 274 0 R (section.4.11) 286 0 R (section.4.12) 330 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 346 0 R (section.5.2) 350 0 R (section.6.1) 358 0 R (section.6.2) 386 0 R (section.6.3) 610 0 R (section.6.4) 666 0 R (section.7.1) 702 0 R (section.7.2) 706 0 R (section.7.3) 718 0 R (section.8.1) 726 0 R (section.8.2) 734 0 R (section.8.3) 738 0 R (section.A.1) 746 0 R (section.A.2) 754 0 R (section.A.3) 762 0 R (section.A.4) 778 0 R (section.B.1) 838 0 R (section.B.10) 874 0 R (section.B.11) 878 0 R (section.B.12) 882 0 R (section.B.13) 886 0 R (section.B.14) 890 0 R (section.B.15) 894 0 R (section.B.16) 898 0 R (section.B.17) 902 0 R (section.B.18) 906 0 R (section.B.19) 910 0 R (section.B.2) 842 0 R (section.B.20) 914 0 R (section.B.21) 918 0 R (section.B.3) 846 0 R (section.B.4) 850 0 R (section.B.5) 854 0 R (section.B.6) 858 0 R (section.B.7) 862 0 R (section.B.8) 866 0 R (section.B.9) 870 0 R (server_resource_limits) 1754 0 R (server_statement_definition_and_usage) 1690 0 R (server_statement_grammar) 1825 0 R (statistics) 2026 0 R (statistics_counters) 2034 0 R (statschannels) 1836 0 R (statsfile) 1657 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.10.1) 278 0 R (subsection.4.10.2) 282 0 R (subsection.4.11.1) 290 0 R (subsection.4.11.2) 302 0 R (subsection.4.11.3) 314 0 R (subsection.4.11.4) 318 0 R (subsection.4.11.5) 322 0 R (subsection.4.11.6) 326 0 R (subsection.4.12.1) 334 0 R (subsection.4.12.2) 338 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.10) 258 0 R (subsection.4.9.11) 262 0 R (subsection.4.9.12) 266 0 R (subsection.4.9.13) 270 0 R (subsection.4.9.2) 226 0 R (subsection.4.9.3) 230 0 R (subsection.4.9.4) 234 0 R (subsection.4.9.5) 238 0 R (subsection.4.9.6) 242 0 R (subsection.4.9.7) 246 0 R (subsection.4.9.8) 250 0 R (subsection.4.9.9) 254 0 R (subsection.6.1.1) 362 0 R (subsection.6.1.2) 374 0 R (subsection.6.2.1) 390 0 R (subsection.6.2.10) 426 0 R (subsection.6.2.11) 442 0 R (subsection.6.2.12) 446 0 R (subsection.6.2.13) 450 0 R (subsection.6.2.14) 454 0 R (subsection.6.2.15) 458 0 R (subsection.6.2.16) 462 0 R (subsection.6.2.17) 546 0 R (subsection.6.2.18) 550 0 R (subsection.6.2.19) 554 0 R (subsection.6.2.2) 394 0 R (subsection.6.2.20) 558 0 R (subsection.6.2.21) 562 0 R (subsection.6.2.22) 566 0 R (subsection.6.2.23) 570 0 R (subsection.6.2.24) 574 0 R (subsection.6.2.25) 578 0 R (subsection.6.2.26) 582 0 R (subsection.6.2.27) 586 0 R (subsection.6.2.28) 590 0 R (subsection.6.2.3) 398 0 R (subsection.6.2.4) 402 0 R (subsection.6.2.5) 406 0 R (subsection.6.2.6) 410 0 R (subsection.6.2.7) 414 0 R (subsection.6.2.8) 418 0 R (subsection.6.2.9) 422 0 R (subsection.6.3.1) 614 0 R (subsection.6.3.2) 626 0 R (subsection.6.3.3) 630 0 R (subsection.6.3.4) 634 0 R (subsection.6.3.5) 638 0 R (subsection.6.3.6) 658 0 R (subsection.6.3.7) 662 0 R (subsection.6.4.1) 674 0 R (subsection.7.2.1) 710 0 R (subsection.7.2.2) 714 0 R (subsection.8.1.1) 730 0 R (subsection.A.1.1) 750 0 R (subsection.A.2.1) 758 0 R (subsection.A.3.1) 766 0 R (subsection.A.3.2) 770 0 R (subsection.A.3.3) 774 0 R (subsection.A.4.1) 782 0 R (subsection.A.4.2) 786 0 R (subsection.A.4.3) 790 0 R (subsection.A.4.4) 794 0 R (subsection.A.4.5) 798 0 R (subsection.A.4.6) 802 0 R (subsection.A.4.7) 830 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.11.1.1) 294 0 R (subsubsection.4.11.1.2) 298 0 R (subsubsection.4.11.2.1) 306 0 R (subsubsection.4.11.2.2) 310 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 366 0 R (subsubsection.6.1.1.2) 370 0 R (subsubsection.6.1.2.1) 378 0 R (subsubsection.6.1.2.2) 382 0 R (subsubsection.6.2.10.1) 430 0 R (subsubsection.6.2.10.2) 434 0 R (subsubsection.6.2.10.3) 438 0 R (subsubsection.6.2.16.1) 466 0 R (subsubsection.6.2.16.10) 502 0 R (subsubsection.6.2.16.11) 506 0 R (subsubsection.6.2.16.12) 510 0 R (subsubsection.6.2.16.13) 514 0 R (subsubsection.6.2.16.14) 518 0 R (subsubsection.6.2.16.15) 522 0 R (subsubsection.6.2.16.16) 526 0 R (subsubsection.6.2.16.17) 530 0 R (subsubsection.6.2.16.18) 534 0 R (subsubsection.6.2.16.19) 538 0 R (subsubsection.6.2.16.2) 470 0 R (subsubsection.6.2.16.20) 542 0 R (subsubsection.6.2.16.3) 474 0 R (subsubsection.6.2.16.4) 478 0 R (subsubsection.6.2.16.5) 482 0 R (subsubsection.6.2.16.6) 486 0 R (subsubsection.6.2.16.7) 490 0 R (subsubsection.6.2.16.8) 494 0 R (subsubsection.6.2.16.9) 498 0 R (subsubsection.6.2.28.1) 594 0 R (subsubsection.6.2.28.2) 598 0 R (subsubsection.6.2.28.3) 602 0 R (subsubsection.6.2.28.4) 606 0 R (subsubsection.6.3.1.1) 618 0 R (subsubsection.6.3.1.2) 622 0 R (subsubsection.6.3.5.1) 642 0 R (subsubsection.6.3.5.2) 646 0 R (subsubsection.6.3.5.3) 650 0 R (subsubsection.6.3.5.4) 654 0 R (subsubsection.6.4.0.1) 670 0 R (subsubsection.6.4.1.1) 678 0 R (subsubsection.6.4.1.2) 682 0 R (subsubsection.6.4.1.3) 686 0 R (subsubsection.6.4.1.4) 690 0 R (subsubsection.6.4.1.5) 694 0 R (subsubsection.A.4.6.1) 806 0 R (subsubsection.A.4.6.2) 810 0 R (subsubsection.A.4.6.3) 814 0 R (subsubsection.A.4.6.4) 818 0 R (subsubsection.A.4.6.5) 822 0 R (subsubsection.A.4.6.6) 826 0 R (table.1.1) 1225 0 R (table.1.2) 1233 0 R (table.3.1) 1292 0 R (table.3.2) 1335 0 R (table.6.1) 1538 0 R (table.6.10) 1970 0 R (table.6.11) 1972 0 R (table.6.12) 1978 0 R (table.6.13) 1985 0 R (table.6.14) 1987 0 R (table.6.15) 1994 0 R (table.6.16) 1997 0 R (table.6.17) 2004 0 R (table.6.18) 2021 0 R (table.6.19) 2028 0 R (table.6.2) 1560 0 R (table.6.20) 2037 0 R (table.6.21) 2045 0 R (table.6.22) 2053 0 R (table.6.23) 2056 0 R (table.6.3) 1569 0 R (table.6.4) 1607 0 R (table.6.5) 1619 0 R (table.6.6) 1679 0 R (table.6.7) 1775 0 R (table.6.8) 1871 0 R (table.6.9) 1955 0 R (the_category_phrase) 1601 0 R (the_sortlist_statement) 1766 0 R (topology) 1761 0 R (trusted-keys) 1838 0 R (tsig) 1387 0 R (tuning) 1780 0 R (types_of_resource_records_and_when_to_use_them) 1240 0 R (view_statement_grammar) 1796 0 R (zone_statement_grammar) 1715 0 R (zone_transfers) 1361 0 R (zonefile_format) 1788 0 R]
+2763 0 obj <<
+/Names [(Access_Control_Lists) 2083 0 R (Bv9ARM.ch01) 1230 0 R (Bv9ARM.ch02) 1274 0 R (Bv9ARM.ch03) 1292 0 R (Bv9ARM.ch04) 1355 0 R (Bv9ARM.ch05) 1536 0 R (Bv9ARM.ch06) 1547 0 R (Bv9ARM.ch07) 2082 0 R (Bv9ARM.ch08) 2107 0 R (Bv9ARM.ch09) 2123 0 R (Bv9ARM.ch10) 2384 0 R (Configuration_File_Grammar) 1570 0 R (DNSSEC) 1421 0 R (Doc-Start) 935 0 R (Setting_TTLs) 2007 0 R (acache) 1281 0 R (access_control) 1730 0 R (acl) 1579 0 R (address_match_lists) 1552 0 R (admin_tools) 1314 0 R (appendix.A) 750 0 R (appendix.B) 842 0 R (bibliography) 2131 0 R (bind9.library) 2339 0 R (boolean_options) 1370 0 R (builtin) 1804 0 R (chapter*.1) 969 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 350 0 R (chapter.6) 362 0 R (chapter.7) 706 0 R (chapter.8) 730 0 R (cite.RFC1033) 2258 0 R (cite.RFC1034) 2143 0 R (cite.RFC1035) 2145 0 R (cite.RFC1101) 2240 0 R (cite.RFC1123) 2242 0 R (cite.RFC1183) 2202 0 R (cite.RFC1464) 2280 0 R (cite.RFC1535) 2188 0 R (cite.RFC1536) 2190 0 R (cite.RFC1537) 2260 0 R (cite.RFC1591) 2244 0 R (cite.RFC1706) 2204 0 R (cite.RFC1712) 2300 0 R (cite.RFC1713) 2282 0 R (cite.RFC1794) 2284 0 R (cite.RFC1876) 2206 0 R (cite.RFC1912) 2262 0 R (cite.RFC1982) 2192 0 R (cite.RFC1995) 2150 0 R (cite.RFC1996) 2152 0 R (cite.RFC2010) 2264 0 R (cite.RFC2052) 2208 0 R (cite.RFC2065) 2312 0 R (cite.RFC2136) 2154 0 R (cite.RFC2137) 2314 0 R (cite.RFC2163) 2210 0 R (cite.RFC2168) 2212 0 R (cite.RFC2181) 2156 0 R (cite.RFC2219) 2266 0 R (cite.RFC2230) 2214 0 R (cite.RFC2240) 2286 0 R (cite.RFC2308) 2158 0 R (cite.RFC2317) 2246 0 R (cite.RFC2345) 2288 0 R (cite.RFC2352) 2290 0 R (cite.RFC2535) 2316 0 R (cite.RFC2536) 2216 0 R (cite.RFC2537) 2218 0 R (cite.RFC2538) 2220 0 R (cite.RFC2539) 2222 0 R (cite.RFC2540) 2224 0 R (cite.RFC2671) 2160 0 R (cite.RFC2672) 2162 0 R (cite.RFC2673) 2302 0 R (cite.RFC2782) 2226 0 R (cite.RFC2825) 2270 0 R (cite.RFC2826) 2248 0 R (cite.RFC2845) 2164 0 R (cite.RFC2874) 2304 0 R (cite.RFC2915) 2228 0 R (cite.RFC2929) 2250 0 R (cite.RFC2930) 2166 0 R (cite.RFC2931) 2168 0 R (cite.RFC3007) 2170 0 R (cite.RFC3008) 2318 0 R (cite.RFC3071) 2292 0 R (cite.RFC3090) 2320 0 R (cite.RFC3110) 2230 0 R (cite.RFC3123) 2232 0 R (cite.RFC3225) 2176 0 R (cite.RFC3258) 2294 0 R (cite.RFC3445) 2322 0 R (cite.RFC3490) 2272 0 R (cite.RFC3491) 2274 0 R (cite.RFC3492) 2276 0 R (cite.RFC3596) 2234 0 R (cite.RFC3597) 2236 0 R (cite.RFC3645) 2172 0 R (cite.RFC3655) 2324 0 R (cite.RFC3658) 2326 0 R (cite.RFC3755) 2328 0 R (cite.RFC3757) 2330 0 R (cite.RFC3833) 2178 0 R (cite.RFC3845) 2332 0 R (cite.RFC3901) 2296 0 R (cite.RFC4033) 2180 0 R (cite.RFC4034) 2182 0 R (cite.RFC4035) 2184 0 R (cite.RFC4074) 2194 0 R (cite.RFC974) 2147 0 R (cite.id2512985) 2337 0 R (clients-per-query) 2060 0 R (configuration_file_elements) 1548 0 R (controls_statement_definition_and_usage) 1338 0 R (diagnostic_tools) 1262 0 R (dnssec.dynamic.zones) 1441 0 R (dynamic_update) 1365 0 R (dynamic_update_policies) 1327 0 R (dynamic_update_security) 1739 0 R (empty) 1812 0 R (historical_dns_information) 2125 0 R (id2466566) 1231 0 R (id2466589) 1232 0 R (id2467480) 1233 0 R (id2467490) 1234 0 R (id2467730) 1244 0 R (id2467751) 1245 0 R (id2467785) 1246 0 R (id2467869) 1249 0 R (id2467962) 1242 0 R (id2470267) 1256 0 R (id2470291) 1259 0 R (id2470389) 1260 0 R (id2470410) 1261 0 R (id2470508) 1267 0 R (id2470544) 1268 0 R (id2470570) 1269 0 R (id2470604) 1275 0 R (id2470631) 1276 0 R (id2470712) 1277 0 R (id2470738) 1280 0 R (id2470748) 1286 0 R (id2470780) 1294 0 R (id2470796) 1295 0 R (id2470819) 1300 0 R (id2470836) 1301 0 R (id2471241) 1309 0 R (id2471246) 1310 0 R (id2473573) 1343 0 R (id2473585) 1344 0 R (id2474148) 1380 0 R (id2474166) 1386 0 R (id2474599) 1402 0 R (id2474616) 1403 0 R (id2474654) 1404 0 R (id2474741) 1405 0 R (id2474752) 1406 0 R (id2474788) 1411 0 R (id2474845) 1412 0 R (id2474894) 1414 0 R (id2474908) 1415 0 R (id2475026) 1420 0 R (id2475230) 1422 0 R (id2475378) 1427 0 R (id2475459) 1428 0 R (id2475611) 1442 0 R (id2475649) 1443 0 R (id2475685) 1448 0 R (id2476061) 1460 0 R (id2476099) 1461 0 R (id2476112) 1462 0 R (id2476145) 1463 0 R (id2476240) 1468 0 R (id2476249) 1469 0 R (id2476259) 1470 0 R (id2476272) 1471 0 R (id2476309) 1472 0 R (id2476318) 1473 0 R (id2476355) 1479 0 R (id2476514) 1481 0 R (id2476615) 1488 0 R (id2476779) 1494 0 R (id2476917) 1495 0 R (id2477034) 1500 0 R (id2477253) 1505 0 R (id2477261) 1506 0 R (id2477293) 1507 0 R (id2477398) 1508 0 R (id2477446) 1509 0 R (id2477477) 1514 0 R (id2477812) 1520 0 R (id2477858) 1521 0 R (id2477912) 1526 0 R (id2478042) 1528 0 R (id2478064) 1529 0 R (id2478097) 1537 0 R (id2478244) 1549 0 R (id2479273) 1557 0 R (id2479301) 1562 0 R (id2479438) 1563 0 R (id2479453) 1564 0 R (id2479483) 1569 0 R (id2479558) 1571 0 R (id2480099) 1578 0 R (id2480210) 1580 0 R (id2480357) 1582 0 R (id2480716) 1589 0 R (id2480733) 1595 0 R (id2480757) 1596 0 R (id2480780) 1597 0 R (id2480871) 1601 0 R (id2481065) 1606 0 R (id2481254) 1607 0 R (id2481742) 1618 0 R (id2482572) 1629 0 R (id2482634) 1630 0 R (id2483092) 1636 0 R (id2483165) 1641 0 R (id2483229) 1644 0 R (id2483273) 1645 0 R (id2483294) 1646 0 R (id2486869) 1690 0 R (id2489095) 1721 0 R (id2489154) 1723 0 R (id2489773) 1738 0 R (id2490990) 1757 0 R (id2491050) 1764 0 R (id2491609) 1772 0 R (id2492180) 1790 0 R (id2493678) 1821 0 R (id2493938) 1827 0 R (id2495176) 1849 0 R (id2495384) 1855 0 R (id2495431) 1857 0 R (id2495857) 1862 0 R (id2497468) 1880 0 R (id2497476) 1881 0 R (id2497481) 1882 0 R (id2498189) 1898 0 R (id2498222) 1899 0 R (id2500371) 1966 0 R (id2501102) 1972 0 R (id2501121) 1973 0 R (id2501141) 1981 0 R (id2501309) 1983 0 R (id2502480) 1989 0 R (id2502608) 1995 0 R (id2502629) 1996 0 R (id2503060) 1998 0 R (id2503196) 2004 0 R (id2503214) 2005 0 R (id2503687) 2008 0 R (id2503812) 2014 0 R (id2503895) 2015 0 R (id2504075) 2017 0 R (id2504098) 2018 0 R (id2504114) 2019 0 R (id2504174) 2024 0 R (id2504244) 2025 0 R (id2504280) 2026 0 R (id2504356) 2032 0 R (id2504935) 2039 0 R (id2505234) 2047 0 R (id2505239) 2048 0 R (id2506843) 2055 0 R (id2506850) 2056 0 R (id2507226) 2058 0 R (id2507232) 2059 0 R (id2508248) 2066 0 R (id2508348) 2067 0 R (id2508690) 2076 0 R (id2508932) 2092 0 R (id2509013) 2093 0 R (id2509073) 2094 0 R (id2509221) 2108 0 R (id2509226) 2109 0 R (id2509238) 2110 0 R (id2509255) 2111 0 R (id2509385) 2124 0 R (id2509557) 2130 0 R (id2509745) 2135 0 R (id2509747) 2141 0 R (id2509824) 2146 0 R (id2509847) 2142 0 R (id2509870) 2144 0 R (id2509907) 2155 0 R (id2509933) 2157 0 R (id2509959) 2149 0 R (id2509984) 2151 0 R (id2510007) 2153 0 R (id2510131) 2159 0 R (id2510157) 2161 0 R (id2510184) 2163 0 R (id2510246) 2165 0 R (id2510276) 2167 0 R (id2510306) 2169 0 R (id2510332) 2171 0 R (id2510407) 2174 0 R (id2510414) 2175 0 R (id2510441) 2177 0 R (id2510477) 2179 0 R (id2510542) 2181 0 R (id2510608) 2183 0 R (id2510673) 2186 0 R (id2510681) 2187 0 R (id2510707) 2189 0 R (id2510843) 2191 0 R (id2510878) 2193 0 R (id2510919) 2200 0 R (id2510924) 2201 0 R (id2510982) 2203 0 R (id2511019) 2211 0 R (id2511054) 2205 0 R (id2511109) 2207 0 R (id2511147) 2209 0 R (id2511173) 2213 0 R (id2511198) 2215 0 R (id2511225) 2217 0 R (id2511252) 2219 0 R (id2511291) 2221 0 R (id2511321) 2223 0 R (id2511351) 2225 0 R (id2511394) 2227 0 R (id2511427) 2229 0 R (id2511453) 2231 0 R (id2511477) 2233 0 R (id2511534) 2235 0 R (id2511559) 2238 0 R (id2511566) 2239 0 R (id2511592) 2241 0 R (id2511614) 2243 0 R (id2511638) 2245 0 R (id2511684) 2247 0 R (id2511707) 2249 0 R (id2511757) 2256 0 R (id2511765) 2257 0 R (id2511788) 2259 0 R (id2511815) 2261 0 R (id2511842) 2263 0 R (id2511878) 2265 0 R (id2511918) 2268 0 R (id2511924) 2269 0 R (id2511956) 2271 0 R (id2512002) 2273 0 R (id2512037) 2275 0 R (id2512064) 2278 0 R (id2512082) 2279 0 R (id2512104) 2281 0 R (id2512130) 2283 0 R (id2512224) 2285 0 R (id2512247) 2287 0 R (id2512293) 2289 0 R (id2512316) 2291 0 R (id2512343) 2293 0 R (id2512369) 2295 0 R (id2512406) 2298 0 R (id2512412) 2299 0 R (id2512538) 2301 0 R (id2512565) 2303 0 R (id2512601) 2310 0 R (id2512613) 2311 0 R (id2512652) 2313 0 R (id2512679) 2315 0 R (id2512709) 2317 0 R (id2512734) 2319 0 R (id2512761) 2321 0 R (id2512797) 2323 0 R (id2512834) 2325 0 R (id2512860) 2327 0 R (id2512887) 2329 0 R (id2512932) 2331 0 R (id2512973) 2334 0 R (id2512983) 2336 0 R (id2512985) 2338 0 R (id2513141) 2345 0 R (id2513150) 2346 0 R (id2513175) 2347 0 R (id2513206) 2348 0 R (id2513283) 2353 0 R (id2513378) 2355 0 R (id2513386) 2356 0 R (id2513545) 2361 0 R (id2513598) 2362 0 R (id2513662) 2363 0 R (id2513677) 2368 0 R (id2513809) 2373 0 R (id2513941) 2374 0 R (incremental_zone_transfers) 1377 0 R (internet_drafts) 2333 0 R (ipv6addresses) 1531 0 R (journal) 1376 0 R (lwresd) 1538 0 R (man.arpaname) 2697 0 R (man.ddns-confgen) 2686 0 R (man.dig) 2385 0 R (man.dnssec-dsfromkey) 2433 0 R (man.dnssec-keyfromlabel) 2451 0 R (man.dnssec-keygen) 1454 0 R (man.dnssec-revoke) 2498 0 R (man.dnssec-settime) 1455 0 R (man.dnssec-signzone) 2526 0 R (man.genrandom) 2708 0 R (man.host) 2422 0 R (man.isc-hmac-fixup) 2715 0 R (man.named) 2583 0 R (man.named-checkconf) 2550 0 R (man.named-checkzone) 2563 0 R (man.named-journalprint) 2606 0 R (man.nsec3hash) 2726 0 R (man.nsupdate) 2616 0 R (man.rndc) 2641 0 R (man.rndc-confgen) 2670 0 R (man.rndc.conf) 2654 0 R (managed-keys) 1482 0 R (notify) 1356 0 R (options) 1326 0 R (page.1) 934 0 R (page.10) 1318 0 R (page.100) 1959 0 R (page.101) 1965 0 R (page.102) 1971 0 R (page.103) 1978 0 R (page.104) 1988 0 R (page.105) 1994 0 R (page.106) 2003 0 R (page.107) 2013 0 R (page.108) 2023 0 R (page.109) 2031 0 R (page.11) 1331 0 R (page.110) 2037 0 R (page.111) 2045 0 R (page.112) 2053 0 R (page.113) 2064 0 R (page.114) 2072 0 R (page.115) 2081 0 R (page.116) 2087 0 R (page.117) 2098 0 R (page.118) 2102 0 R (page.119) 2106 0 R (page.12) 1335 0 R (page.120) 2117 0 R (page.121) 2122 0 R (page.122) 2129 0 R (page.123) 2139 0 R (page.124) 2198 0 R (page.125) 2254 0 R (page.126) 2308 0 R (page.127) 2344 0 R (page.128) 2352 0 R (page.129) 2360 0 R (page.13) 1342 0 R (page.130) 2367 0 R (page.131) 2372 0 R (page.132) 2378 0 R (page.133) 2383 0 R (page.134) 2392 0 R (page.135) 2398 0 R (page.136) 2403 0 R (page.137) 2407 0 R (page.138) 2411 0 R (page.139) 2421 0 R (page.14) 1349 0 R (page.140) 2429 0 R (page.141) 2440 0 R (page.142) 2447 0 R (page.143) 2459 0 R (page.144) 2463 0 R (page.145) 2472 0 R (page.146) 2480 0 R (page.147) 2484 0 R (page.148) 2489 0 R (page.149) 2497 0 R (page.15) 1354 0 R (page.150) 2509 0 R (page.151) 2518 0 R (page.152) 2525 0 R (page.153) 2534 0 R (page.154) 2538 0 R (page.155) 2542 0 R (page.156) 2546 0 R (page.157) 2557 0 R (page.158) 2568 0 R (page.159) 2575 0 R (page.16) 1375 0 R (page.160) 2579 0 R (page.161) 2591 0 R (page.162) 2595 0 R (page.163) 2601 0 R (page.164) 2613 0 R (page.165) 2623 0 R (page.166) 2628 0 R (page.167) 2632 0 R (page.168) 2638 0 R (page.169) 2650 0 R (page.17) 1385 0 R (page.170) 2661 0 R (page.171) 2666 0 R (page.172) 2676 0 R (page.173) 2682 0 R (page.174) 2694 0 R (page.175) 2706 0 R (page.176) 2721 0 R (page.177) 2734 0 R (page.18) 1391 0 R (page.19) 1396 0 R (page.2) 958 0 R (page.20) 1401 0 R (page.21) 1410 0 R (page.22) 1419 0 R (page.23) 1426 0 R (page.24) 1432 0 R (page.25) 1437 0 R (page.26) 1447 0 R (page.27) 1459 0 R (page.28) 1467 0 R (page.29) 1477 0 R (page.3) 1255 0 R (page.30) 1486 0 R (page.31) 1493 0 R (page.32) 1499 0 R (page.33) 1504 0 R (page.34) 1513 0 R (page.35) 1519 0 R (page.36) 1525 0 R (page.37) 1535 0 R (page.38) 1542 0 R (page.39) 1546 0 R (page.4) 1266 0 R (page.40) 1556 0 R (page.41) 1561 0 R (page.42) 1568 0 R (page.43) 1577 0 R (page.44) 1586 0 R (page.45) 1594 0 R (page.46) 1605 0 R (page.47) 1611 0 R (page.48) 1617 0 R (page.49) 1624 0 R (page.5) 1273 0 R (page.50) 1628 0 R (page.51) 1635 0 R (page.52) 1640 0 R (page.53) 1650 0 R (page.54) 1654 0 R (page.55) 1659 0 R (page.56) 1663 0 R (page.57) 1667 0 R (page.58) 1671 0 R (page.59) 1678 0 R (page.6) 1285 0 R (page.60) 1683 0 R (page.61) 1689 0 R (page.62) 1695 0 R (page.63) 1705 0 R (page.64) 1710 0 R (page.65) 1714 0 R (page.66) 1718 0 R (page.67) 1729 0 R (page.68) 1735 0 R (page.69) 1743 0 R (page.7) 1291 0 R (page.70) 1748 0 R (page.71) 1752 0 R (page.72) 1756 0 R (page.73) 1763 0 R (page.74) 1771 0 R (page.75) 1776 0 R (page.76) 1784 0 R (page.77) 1789 0 R (page.78) 1796 0 R (page.79) 1802 0 R (page.8) 1299 0 R (page.80) 1811 0 R (page.81) 1816 0 R (page.82) 1820 0 R (page.83) 1825 0 R (page.84) 1831 0 R (page.85) 1836 0 R (page.86) 1841 0 R (page.87) 1845 0 R (page.88) 1854 0 R (page.89) 1861 0 R (page.9) 1308 0 R (page.90) 1866 0 R (page.91) 1871 0 R (page.92) 1875 0 R (page.93) 1879 0 R (page.94) 1887 0 R (page.95) 1891 0 R (page.96) 1897 0 R (page.97) 1917 0 R (page.98) 1932 0 R (page.99) 1942 0 R (page.i) 968 0 R (page.ii) 1023 0 R (page.iii) 1087 0 R (page.iv) 1150 0 R (page.v) 1212 0 R (pkcs11) 1487 0 R (proposed_standards) 1381 0 R (query_address) 1744 0 R (rfc5011.support) 1478 0 R (rfcs) 1251 0 R (rndc) 1590 0 R (root_delegation_only) 1893 0 R (rrset_ordering) 1304 0 R (sample_configuration) 1293 0 R (section*.10) 2267 0 R (section*.100) 2604 0 R (section*.101) 2605 0 R (section*.102) 2607 0 R (section*.103) 2608 0 R (section*.104) 2609 0 R (section*.105) 2614 0 R (section*.106) 2615 0 R (section*.107) 2617 0 R (section*.108) 2618 0 R (section*.109) 2619 0 R (section*.11) 2277 0 R (section*.110) 2624 0 R (section*.111) 2633 0 R (section*.112) 2634 0 R (section*.113) 2639 0 R (section*.114) 2640 0 R (section*.115) 2642 0 R (section*.116) 2643 0 R (section*.117) 2644 0 R (section*.118) 2645 0 R (section*.119) 2651 0 R (section*.12) 2297 0 R (section*.120) 2652 0 R (section*.121) 2653 0 R (section*.122) 2655 0 R (section*.123) 2656 0 R (section*.124) 2657 0 R (section*.125) 2662 0 R (section*.126) 2667 0 R (section*.127) 2668 0 R (section*.128) 2669 0 R (section*.129) 2671 0 R (section*.13) 2309 0 R (section*.130) 2672 0 R (section*.131) 2677 0 R (section*.132) 2678 0 R (section*.133) 2683 0 R (section*.134) 2684 0 R (section*.135) 2685 0 R (section*.136) 2687 0 R (section*.137) 2688 0 R (section*.138) 2689 0 R (section*.139) 2690 0 R (section*.14) 2335 0 R (section*.140) 2695 0 R (section*.141) 2696 0 R (section*.142) 2698 0 R (section*.143) 2699 0 R (section*.144) 2700 0 R (section*.145) 2701 0 R (section*.146) 2707 0 R (section*.147) 2709 0 R (section*.148) 2710 0 R (section*.149) 2711 0 R (section*.15) 2386 0 R (section*.150) 2712 0 R (section*.151) 2713 0 R (section*.152) 2714 0 R (section*.153) 2716 0 R (section*.154) 2717 0 R (section*.155) 2722 0 R (section*.156) 2723 0 R (section*.157) 2724 0 R (section*.158) 2725 0 R (section*.159) 2727 0 R (section*.16) 2387 0 R (section*.160) 2728 0 R (section*.161) 2729 0 R (section*.162) 2730 0 R (section*.163) 2735 0 R (section*.164) 2736 0 R (section*.17) 2388 0 R (section*.18) 2393 0 R (section*.19) 2394 0 R (section*.2) 2134 0 R (section*.20) 2399 0 R (section*.21) 2412 0 R (section*.22) 2413 0 R (section*.23) 2414 0 R (section*.24) 2415 0 R (section*.25) 2416 0 R (section*.26) 2423 0 R (section*.27) 2424 0 R (section*.28) 2425 0 R (section*.29) 2430 0 R (section*.3) 2140 0 R (section*.30) 2431 0 R (section*.31) 2432 0 R (section*.32) 2434 0 R (section*.33) 2435 0 R (section*.34) 2436 0 R (section*.35) 2441 0 R (section*.36) 2442 0 R (section*.37) 2443 0 R (section*.38) 2448 0 R (section*.39) 2449 0 R (section*.4) 2148 0 R (section*.40) 2450 0 R (section*.41) 2452 0 R (section*.42) 2453 0 R (section*.43) 2454 0 R (section*.44) 2455 0 R (section*.45) 2464 0 R (section*.46) 2465 0 R (section*.47) 2466 0 R (section*.48) 2467 0 R (section*.49) 2473 0 R (section*.5) 2173 0 R (section*.50) 2474 0 R (section*.51) 2475 0 R (section*.52) 2476 0 R (section*.53) 2485 0 R (section*.54) 2490 0 R (section*.55) 2491 0 R (section*.56) 2492 0 R (section*.57) 2493 0 R (section*.58) 2499 0 R (section*.59) 2500 0 R (section*.6) 2185 0 R (section*.60) 2501 0 R (section*.61) 2502 0 R (section*.62) 2503 0 R (section*.63) 2504 0 R (section*.64) 2505 0 R (section*.65) 2510 0 R (section*.66) 2511 0 R (section*.67) 2512 0 R (section*.68) 2513 0 R (section*.69) 2519 0 R (section*.7) 2199 0 R (section*.70) 2520 0 R (section*.71) 2521 0 R (section*.72) 2527 0 R (section*.73) 2528 0 R (section*.74) 2529 0 R (section*.75) 2530 0 R (section*.76) 2547 0 R (section*.77) 2548 0 R (section*.78) 2549 0 R (section*.79) 2551 0 R (section*.8) 2237 0 R (section*.80) 2552 0 R (section*.81) 2558 0 R (section*.82) 2559 0 R (section*.83) 2560 0 R (section*.84) 2561 0 R (section*.85) 2562 0 R (section*.86) 2564 0 R (section*.87) 2569 0 R (section*.88) 2570 0 R (section*.89) 2571 0 R (section*.9) 2255 0 R (section*.90) 2580 0 R (section*.91) 2581 0 R (section*.92) 2582 0 R (section*.93) 2584 0 R (section*.94) 2585 0 R (section*.95) 2586 0 R (section*.96) 2587 0 R (section*.97) 2596 0 R (section*.98) 2602 0 R (section*.99) 2603 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.10) 274 0 R (section.4.11) 286 0 R (section.4.12) 338 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 354 0 R (section.5.2) 358 0 R (section.6.1) 366 0 R (section.6.2) 394 0 R (section.6.3) 618 0 R (section.6.4) 674 0 R (section.7.1) 710 0 R (section.7.2) 714 0 R (section.7.3) 726 0 R (section.8.1) 734 0 R (section.8.2) 742 0 R (section.8.3) 746 0 R (section.A.1) 754 0 R (section.A.2) 762 0 R (section.A.3) 770 0 R (section.A.4) 786 0 R (section.B.1) 846 0 R (section.B.10) 882 0 R (section.B.11) 886 0 R (section.B.12) 890 0 R (section.B.13) 894 0 R (section.B.14) 898 0 R (section.B.15) 902 0 R (section.B.16) 906 0 R (section.B.17) 910 0 R (section.B.18) 914 0 R (section.B.19) 918 0 R (section.B.2) 850 0 R (section.B.20) 922 0 R (section.B.21) 926 0 R (section.B.3) 854 0 R (section.B.4) 858 0 R (section.B.5) 862 0 R (section.B.6) 866 0 R (section.B.7) 870 0 R (section.B.8) 874 0 R (section.B.9) 878 0 R (server_resource_limits) 1766 0 R (server_statement_definition_and_usage) 1701 0 R (server_statement_grammar) 1837 0 R (statistics) 2038 0 R (statistics_counters) 2046 0 R (statschannels) 1848 0 R (statsfile) 1674 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.10.1) 278 0 R (subsection.4.10.2) 282 0 R (subsection.4.11.1) 290 0 R (subsection.4.11.2) 306 0 R (subsection.4.11.3) 322 0 R (subsection.4.11.4) 326 0 R (subsection.4.11.5) 330 0 R (subsection.4.11.6) 334 0 R (subsection.4.12.1) 342 0 R (subsection.4.12.2) 346 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.10) 258 0 R (subsection.4.9.11) 262 0 R (subsection.4.9.12) 266 0 R (subsection.4.9.13) 270 0 R (subsection.4.9.2) 226 0 R (subsection.4.9.3) 230 0 R (subsection.4.9.4) 234 0 R (subsection.4.9.5) 238 0 R (subsection.4.9.6) 242 0 R (subsection.4.9.7) 246 0 R (subsection.4.9.8) 250 0 R (subsection.4.9.9) 254 0 R (subsection.6.1.1) 370 0 R (subsection.6.1.2) 382 0 R (subsection.6.2.1) 398 0 R (subsection.6.2.10) 434 0 R (subsection.6.2.11) 450 0 R (subsection.6.2.12) 454 0 R (subsection.6.2.13) 458 0 R (subsection.6.2.14) 462 0 R (subsection.6.2.15) 466 0 R (subsection.6.2.16) 470 0 R (subsection.6.2.17) 554 0 R (subsection.6.2.18) 558 0 R (subsection.6.2.19) 562 0 R (subsection.6.2.2) 402 0 R (subsection.6.2.20) 566 0 R (subsection.6.2.21) 570 0 R (subsection.6.2.22) 574 0 R (subsection.6.2.23) 578 0 R (subsection.6.2.24) 582 0 R (subsection.6.2.25) 586 0 R (subsection.6.2.26) 590 0 R (subsection.6.2.27) 594 0 R (subsection.6.2.28) 598 0 R (subsection.6.2.3) 406 0 R (subsection.6.2.4) 410 0 R (subsection.6.2.5) 414 0 R (subsection.6.2.6) 418 0 R (subsection.6.2.7) 422 0 R (subsection.6.2.8) 426 0 R (subsection.6.2.9) 430 0 R (subsection.6.3.1) 622 0 R (subsection.6.3.2) 634 0 R (subsection.6.3.3) 638 0 R (subsection.6.3.4) 642 0 R (subsection.6.3.5) 646 0 R (subsection.6.3.6) 666 0 R (subsection.6.3.7) 670 0 R (subsection.6.4.1) 682 0 R (subsection.7.2.1) 718 0 R (subsection.7.2.2) 722 0 R (subsection.8.1.1) 738 0 R (subsection.A.1.1) 758 0 R (subsection.A.2.1) 766 0 R (subsection.A.3.1) 774 0 R (subsection.A.3.2) 778 0 R (subsection.A.3.3) 782 0 R (subsection.A.4.1) 790 0 R (subsection.A.4.2) 794 0 R (subsection.A.4.3) 798 0 R (subsection.A.4.4) 802 0 R (subsection.A.4.5) 806 0 R (subsection.A.4.6) 810 0 R (subsection.A.4.7) 838 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.11.1.1) 294 0 R (subsubsection.4.11.1.2) 298 0 R (subsubsection.4.11.1.3) 302 0 R (subsubsection.4.11.2.1) 310 0 R (subsubsection.4.11.2.2) 314 0 R (subsubsection.4.11.2.3) 318 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 374 0 R (subsubsection.6.1.1.2) 378 0 R (subsubsection.6.1.2.1) 386 0 R (subsubsection.6.1.2.2) 390 0 R (subsubsection.6.2.10.1) 438 0 R (subsubsection.6.2.10.2) 442 0 R (subsubsection.6.2.10.3) 446 0 R (subsubsection.6.2.16.1) 474 0 R (subsubsection.6.2.16.10) 510 0 R (subsubsection.6.2.16.11) 514 0 R (subsubsection.6.2.16.12) 518 0 R (subsubsection.6.2.16.13) 522 0 R (subsubsection.6.2.16.14) 526 0 R (subsubsection.6.2.16.15) 530 0 R (subsubsection.6.2.16.16) 534 0 R (subsubsection.6.2.16.17) 538 0 R (subsubsection.6.2.16.18) 542 0 R (subsubsection.6.2.16.19) 546 0 R (subsubsection.6.2.16.2) 478 0 R (subsubsection.6.2.16.20) 550 0 R (subsubsection.6.2.16.3) 482 0 R (subsubsection.6.2.16.4) 486 0 R (subsubsection.6.2.16.5) 490 0 R (subsubsection.6.2.16.6) 494 0 R (subsubsection.6.2.16.7) 498 0 R (subsubsection.6.2.16.8) 502 0 R (subsubsection.6.2.16.9) 506 0 R (subsubsection.6.2.28.1) 602 0 R (subsubsection.6.2.28.2) 606 0 R (subsubsection.6.2.28.3) 610 0 R (subsubsection.6.2.28.4) 614 0 R (subsubsection.6.3.1.1) 626 0 R (subsubsection.6.3.1.2) 630 0 R (subsubsection.6.3.5.1) 650 0 R (subsubsection.6.3.5.2) 654 0 R (subsubsection.6.3.5.3) 658 0 R (subsubsection.6.3.5.4) 662 0 R (subsubsection.6.4.0.1) 678 0 R (subsubsection.6.4.1.1) 686 0 R (subsubsection.6.4.1.2) 690 0 R (subsubsection.6.4.1.3) 694 0 R (subsubsection.6.4.1.4) 698 0 R (subsubsection.6.4.1.5) 702 0 R (subsubsection.A.4.6.1) 814 0 R (subsubsection.A.4.6.2) 818 0 R (subsubsection.A.4.6.3) 822 0 R (subsubsection.A.4.6.4) 826 0 R (subsubsection.A.4.6.5) 830 0 R (subsubsection.A.4.6.6) 834 0 R (table.1.1) 1235 0 R (table.1.2) 1243 0 R (table.3.1) 1302 0 R (table.3.2) 1345 0 R (table.6.1) 1550 0 R (table.6.10) 1982 0 R (table.6.11) 1984 0 R (table.6.12) 1990 0 R (table.6.13) 1997 0 R (table.6.14) 1999 0 R (table.6.15) 2006 0 R (table.6.16) 2009 0 R (table.6.17) 2016 0 R (table.6.18) 2033 0 R (table.6.19) 2040 0 R (table.6.2) 1572 0 R (table.6.20) 2049 0 R (table.6.21) 2057 0 R (table.6.22) 2065 0 R (table.6.23) 2068 0 R (table.6.3) 1581 0 R (table.6.4) 1619 0 R (table.6.5) 1631 0 R (table.6.6) 1691 0 R (table.6.7) 1791 0 R (table.6.8) 1883 0 R (table.6.9) 1967 0 R (the_category_phrase) 1613 0 R (the_sortlist_statement) 1778 0 R (topology) 1777 0 R (trusted-keys) 1850 0 R (tsig) 1397 0 R (tuning) 1792 0 R (types_of_resource_records_and_when_to_use_them) 1250 0 R (view_statement_grammar) 1807 0 R (zone_statement_grammar) 1725 0 R (zone_transfers) 1371 0 R (zonefile_format) 1806 0 R]
 /Limits [(Access_Control_Lists) (zonefile_format)]
 >> endobj
-2752 0 obj <<
-/Kids [2751 0 R]
+2764 0 obj <<
+/Kids [2763 0 R]
 >> endobj
-2753 0 obj <<
-/Dests 2752 0 R
+2765 0 obj <<
+/Dests 2764 0 R
 >> endobj
-2754 0 obj <<
+2766 0 obj <<
 /Type /Catalog
-/Pages 2749 0 R
-/Outlines 2750 0 R
-/Names 2753 0 R
+/Pages 2761 0 R
+/Outlines 2762 0 R
+/Names 2765 0 R
 /PageMode /UseOutlines 
-/OpenAction 921 0 R
+/OpenAction 929 0 R
 >> endobj
-2755 0 obj <<
+2767 0 obj <<
 /Author()/Title()/Subject()/Creator(LaTeX with hyperref package)/Producer(pdfeTeX-1.21a)/Keywords()
-/CreationDate (D:20111222180957Z)
+/CreationDate (D:20120129010411Z)
 /PTEX.Fullbanner (This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4)
 >> endobj
 xref
-0 2756
+0 2768
 0000000001 65535 f 
 0000000002 00000 f 
 0000000003 00000 f 
 0000000004 00000 f 
 0000000000 00000 f 
 0000000009 00000 n 
-0000347892 00000 n 
-0001193795 00000 n 
+0000348646 00000 n 
+0001196901 00000 n 
 0000000054 00000 n 
 0000000086 00000 n 
-0000348019 00000 n 
-0001193723 00000 n 
+0000348773 00000 n 
+0001196829 00000 n 
 0000000133 00000 n 
 0000000173 00000 n 
-0000348147 00000 n 
-0001193637 00000 n 
+0000348901 00000 n 
+0001196743 00000 n 
 0000000221 00000 n 
 0000000273 00000 n 
-0000348275 00000 n 
-0001193551 00000 n 
+0000349029 00000 n 
+0001196657 00000 n 
 0000000321 00000 n 
 0000000377 00000 n 
-0000352561 00000 n 
-0001193441 00000 n 
+0000353315 00000 n 
+0001196547 00000 n 
 0000000425 00000 n 
 0000000478 00000 n 
-0000352688 00000 n 
-0001193367 00000 n 
+0000353442 00000 n 
+0001196473 00000 n 
 0000000531 00000 n 
 0000000572 00000 n 
-0000352816 00000 n 
-0001193280 00000 n 
+0000353570 00000 n 
+0001196386 00000 n 
 0000000625 00000 n 
 0000000674 00000 n 
-0000352943 00000 n 
-0001193193 00000 n 
+0000353697 00000 n 
+0001196299 00000 n 
 0000000727 00000 n 
 0000000757 00000 n 
-0000357240 00000 n 
-0001193069 00000 n 
+0000357994 00000 n 
+0001196175 00000 n 
 0000000810 00000 n 
 0000000861 00000 n 
-0000357368 00000 n 
-0001192995 00000 n 
+0000358122 00000 n 
+0001196101 00000 n 
 0000000919 00000 n 
 0000000964 00000 n 
-0000357496 00000 n 
-0001192908 00000 n 
+0000358250 00000 n 
+0001196014 00000 n 
 0000001022 00000 n 
 0000001062 00000 n 
-0000357624 00000 n 
-0001192834 00000 n 
+0000358378 00000 n 
+0001195940 00000 n 
 0000001120 00000 n 
 0000001162 00000 n 
-0000360609 00000 n 
-0001192710 00000 n 
+0000361363 00000 n 
+0001195816 00000 n 
 0000001215 00000 n 
 0000001260 00000 n 
-0000360737 00000 n 
-0001192649 00000 n 
+0000361491 00000 n 
+0001195755 00000 n 
 0000001318 00000 n 
 0000001355 00000 n 
-0000360865 00000 n 
-0001192575 00000 n 
+0000361619 00000 n 
+0001195681 00000 n 
 0000001408 00000 n 
 0000001463 00000 n 
-0000363812 00000 n 
-0001192450 00000 n 
+0000364566 00000 n 
+0001195556 00000 n 
 0000001509 00000 n 
 0000001556 00000 n 
-0000363940 00000 n 
-0001192376 00000 n 
+0000364694 00000 n 
+0001195482 00000 n 
 0000001604 00000 n 
 0000001648 00000 n 
-0000364068 00000 n 
-0001192289 00000 n 
+0000364822 00000 n 
+0001195395 00000 n 
 0000001696 00000 n 
 0000001735 00000 n 
-0000364196 00000 n 
-0001192202 00000 n 
+0000364950 00000 n 
+0001195308 00000 n 
 0000001783 00000 n 
 0000001825 00000 n 
-0000364323 00000 n 
-0001192115 00000 n 
+0000365077 00000 n 
+0001195221 00000 n 
 0000001873 00000 n 
 0000001936 00000 n 
-0000365400 00000 n 
-0001192041 00000 n 
+0000366154 00000 n 
+0001195147 00000 n 
 0000001984 00000 n 
 0000002034 00000 n 
-0000367059 00000 n 
-0001191913 00000 n 
+0000367813 00000 n 
+0001195019 00000 n 
 0000002080 00000 n 
 0000002126 00000 n 
-0000367186 00000 n 
-0001191800 00000 n 
+0000367940 00000 n 
+0001194906 00000 n 
 0000002174 00000 n 
 0000002218 00000 n 
-0000367314 00000 n 
-0001191724 00000 n 
+0000368068 00000 n 
+0001194830 00000 n 
 0000002271 00000 n 
 0000002323 00000 n 
-0000367442 00000 n 
-0001191647 00000 n 
+0000368196 00000 n 
+0001194753 00000 n 
 0000002377 00000 n 
 0000002436 00000 n 
-0000369891 00000 n 
-0001191556 00000 n 
+0000370645 00000 n 
+0001194662 00000 n 
 0000002485 00000 n 
 0000002523 00000 n 
-0000373229 00000 n 
-0001191439 00000 n 
+0000373983 00000 n 
+0001194545 00000 n 
 0000002572 00000 n 
 0000002618 00000 n 
-0000373357 00000 n 
-0001191321 00000 n 
+0000374111 00000 n 
+0001194427 00000 n 
 0000002672 00000 n 
 0000002739 00000 n 
-0000373485 00000 n 
-0001191242 00000 n 
+0000374239 00000 n 
+0001194348 00000 n 
 0000002798 00000 n 
 0000002842 00000 n 
-0000373614 00000 n 
-0001191163 00000 n 
+0000374368 00000 n 
+0001194269 00000 n 
 0000002901 00000 n 
 0000002949 00000 n 
-0000390212 00000 n 
-0001191084 00000 n 
+0000390966 00000 n 
+0001194190 00000 n 
 0000003003 00000 n 
 0000003036 00000 n 
-0000396313 00000 n 
-0001190951 00000 n 
+0000397067 00000 n 
+0001194057 00000 n 
 0000003083 00000 n 
 0000003126 00000 n 
-0000396442 00000 n 
-0001190872 00000 n 
+0000397196 00000 n 
+0001193978 00000 n 
 0000003175 00000 n 
 0000003205 00000 n 
-0000396571 00000 n 
-0001190740 00000 n 
+0000397325 00000 n 
+0001193846 00000 n 
 0000003254 00000 n 
 0000003292 00000 n 
-0000401080 00000 n 
-0001190675 00000 n 
+0000401834 00000 n 
+0001193781 00000 n 
 0000003346 00000 n 
 0000003388 00000 n 
-0000401209 00000 n 
-0001190582 00000 n 
+0000401963 00000 n 
+0001193688 00000 n 
 0000003437 00000 n 
 0000003496 00000 n 
-0000401338 00000 n 
-0001190450 00000 n 
+0000402092 00000 n 
+0001193556 00000 n 
 0000003545 00000 n 
 0000003578 00000 n 
-0000405256 00000 n 
-0001190385 00000 n 
+0000406010 00000 n 
+0001193491 00000 n 
 0000003632 00000 n 
 0000003681 00000 n 
-0000408270 00000 n 
-0001190253 00000 n 
+0000409024 00000 n 
+0001193359 00000 n 
 0000003730 00000 n 
 0000003758 00000 n 
-0000411050 00000 n 
-0001190135 00000 n 
+0000411804 00000 n 
+0001193241 00000 n 
 0000003812 00000 n 
 0000003881 00000 n 
-0000411179 00000 n 
-0001190056 00000 n 
+0000411933 00000 n 
+0001193162 00000 n 
 0000003940 00000 n 
 0000003988 00000 n 
-0000411307 00000 n 
-0001189977 00000 n 
+0000412061 00000 n 
+0001193083 00000 n 
 0000004047 00000 n 
 0000004092 00000 n 
-0000411436 00000 n 
-0001189884 00000 n 
+0000412190 00000 n 
+0001192990 00000 n 
 0000004146 00000 n 
 0000004214 00000 n 
-0000411565 00000 n 
-0001189791 00000 n 
+0000412319 00000 n 
+0001192897 00000 n 
 0000004268 00000 n 
 0000004338 00000 n 
-0000415234 00000 n 
-0001189698 00000 n 
+0000415988 00000 n 
+0001192804 00000 n 
 0000004392 00000 n 
 0000004455 00000 n 
-0000415363 00000 n 
-0001189605 00000 n 
+0000416117 00000 n 
+0001192711 00000 n 
 0000004509 00000 n 
 0000004564 00000 n 
-0000415491 00000 n 
-0001189526 00000 n 
+0000416245 00000 n 
+0001192632 00000 n 
 0000004618 00000 n 
 0000004650 00000 n 
-0000415619 00000 n 
-0001189433 00000 n 
+0000416373 00000 n 
+0001192539 00000 n 
 0000004699 00000 n 
 0000004727 00000 n 
-0000419388 00000 n 
-0001189340 00000 n 
+0000420142 00000 n 
+0001192446 00000 n 
 0000004776 00000 n 
 0000004808 00000 n 
-0000419517 00000 n 
-0001189208 00000 n 
+0000420271 00000 n 
+0001192314 00000 n 
 0000004857 00000 n 
 0000004887 00000 n 
-0000419646 00000 n 
-0001189129 00000 n 
+0000420400 00000 n 
+0001192235 00000 n 
 0000004941 00000 n 
 0000004982 00000 n 
-0000423444 00000 n 
-0001189036 00000 n 
+0000424198 00000 n 
+0001192142 00000 n 
 0000005036 00000 n 
 0000005078 00000 n 
-0000423573 00000 n 
-0001188957 00000 n 
+0000424327 00000 n 
+0001192063 00000 n 
 0000005132 00000 n 
 0000005177 00000 n 
-0000428896 00000 n 
-0001188824 00000 n 
+0000429650 00000 n 
+0001191930 00000 n 
 0000005226 00000 n 
 0000005294 00000 n 
-0000429025 00000 n 
-0001188745 00000 n 
+0000429779 00000 n 
+0001191851 00000 n 
 0000005348 00000 n 
 0000005408 00000 n 
-0000429154 00000 n 
-0001188652 00000 n 
+0000429908 00000 n 
+0001191758 00000 n 
 0000005462 00000 n 
 0000005513 00000 n 
-0000433421 00000 n 
-0001188559 00000 n 
+0000434175 00000 n 
+0001191665 00000 n 
 0000005567 00000 n 
 0000005621 00000 n 
-0000436403 00000 n 
-0001188466 00000 n 
+0000437157 00000 n 
+0001191572 00000 n 
 0000005675 00000 n 
 0000005721 00000 n 
-0000436532 00000 n 
-0001188373 00000 n 
+0000437286 00000 n 
+0001191479 00000 n 
 0000005775 00000 n 
 0000005817 00000 n 
-0000436661 00000 n 
-0001188280 00000 n 
+0000437415 00000 n 
+0001191386 00000 n 
 0000005871 00000 n 
 0000005922 00000 n 
-0000436790 00000 n 
-0001188187 00000 n 
+0000437544 00000 n 
+0001191293 00000 n 
 0000005976 00000 n 
 0000006025 00000 n 
-0000439549 00000 n 
-0001188094 00000 n 
+0000440303 00000 n 
+0001191200 00000 n 
 0000006079 00000 n 
 0000006136 00000 n 
-0000439678 00000 n 
-0001188001 00000 n 
+0000440432 00000 n 
+0001191107 00000 n 
 0000006190 00000 n 
 0000006245 00000 n 
-0000439807 00000 n 
-0001187908 00000 n 
+0000440561 00000 n 
+0001191014 00000 n 
 0000006300 00000 n 
 0000006356 00000 n 
-0000439935 00000 n 
-0001187815 00000 n 
+0000440689 00000 n 
+0001190921 00000 n 
 0000006411 00000 n 
 0000006472 00000 n 
-0000440063 00000 n 
-0001187722 00000 n 
+0000440817 00000 n 
+0001190828 00000 n 
 0000006527 00000 n 
 0000006573 00000 n 
-0000440192 00000 n 
-0001187643 00000 n 
+0000440946 00000 n 
+0001190749 00000 n 
 0000006628 00000 n 
 0000006671 00000 n 
-0000444056 00000 n 
-0001187511 00000 n 
+0000444810 00000 n 
+0001190617 00000 n 
 0000006721 00000 n 
 0000006777 00000 n 
-0000444185 00000 n 
-0001187432 00000 n 
+0000444939 00000 n 
+0001190538 00000 n 
 0000006832 00000 n 
 0000006878 00000 n 
-0000444314 00000 n 
-0001187353 00000 n 
+0000445068 00000 n 
+0001190459 00000 n 
 0000006933 00000 n 
 0000006980 00000 n 
-0000447572 00000 n 
-0001187221 00000 n 
+0000448472 00000 n 
+0001190327 00000 n 
 0000007030 00000 n 
 0000007087 00000 n 
-0000447701 00000 n 
-0001187103 00000 n 
+0000448601 00000 n 
+0001190209 00000 n 
 0000007142 00000 n 
 0000007182 00000 n 
-0000450372 00000 n 
-0001187024 00000 n 
+0000451269 00000 n 
+0001190130 00000 n 
 0000007242 00000 n 
 0000007315 00000 n 
-0000450501 00000 n 
-0001186945 00000 n 
+0000451398 00000 n 
+0001190037 00000 n 
 0000007375 00000 n 
 0000007448 00000 n 
-0000452785 00000 n 
-0001186813 00000 n 
-0000007503 00000 n 
-0000007561 00000 n 
-0000452914 00000 n 
-0001186734 00000 n 
-0000007621 00000 n 
+0000454115 00000 n 
+0001189958 00000 n 
+0000007508 00000 n 
+0000007565 00000 n 
+0000456507 00000 n 
+0001189826 00000 n 
+0000007620 00000 n 
 0000007678 00000 n 
-0000453043 00000 n 
-0001186655 00000 n 
+0000456636 00000 n 
+0001189747 00000 n 
 0000007738 00000 n 
-0000007797 00000 n 
-0000455868 00000 n 
-0001186562 00000 n 
-0000007852 00000 n 
-0000007896 00000 n 
-0000455997 00000 n 
-0001186469 00000 n 
-0000007951 00000 n 
-0000007991 00000 n 
-0000459066 00000 n 
-0001186376 00000 n 
-0000008046 00000 n 
-0000008114 00000 n 
-0000459195 00000 n 
-0001186297 00000 n 
-0000008169 00000 n 
-0000008240 00000 n 
-0000463213 00000 n 
-0001186179 00000 n 
-0000008290 00000 n 
-0000008337 00000 n 
-0000463342 00000 n 
-0001186100 00000 n 
-0000008392 00000 n 
-0000008453 00000 n 
-0000464625 00000 n 
-0001186021 00000 n 
-0000008508 00000 n 
-0000008578 00000 n 
-0000467053 00000 n 
-0001185888 00000 n 
-0000008625 00000 n 
-0000008678 00000 n 
-0000467182 00000 n 
-0001185809 00000 n 
+0000007815 00000 n 
+0000456765 00000 n 
+0001189654 00000 n 
+0000007875 00000 n 
+0000007952 00000 n 
+0000456894 00000 n 
+0001189575 00000 n 
+0000008012 00000 n 
+0000008071 00000 n 
+0000457023 00000 n 
+0001189482 00000 n 
+0000008126 00000 n 
+0000008170 00000 n 
+0000459655 00000 n 
+0001189389 00000 n 
+0000008225 00000 n 
+0000008265 00000 n 
+0000462464 00000 n 
+0001189296 00000 n 
+0000008320 00000 n 
+0000008388 00000 n 
+0000462593 00000 n 
+0001189217 00000 n 
+0000008443 00000 n 
+0000008514 00000 n 
+0000466654 00000 n 
+0001189099 00000 n 
+0000008564 00000 n 
+0000008611 00000 n 
+0000466783 00000 n 
+0001189020 00000 n 
+0000008666 00000 n 
 0000008727 00000 n 
-0000008783 00000 n 
-0000467311 00000 n 
-0001185730 00000 n 
-0000008832 00000 n 
-0000008881 00000 n 
-0000471581 00000 n 
-0001185597 00000 n 
-0000008928 00000 n 
-0000008980 00000 n 
-0000471710 00000 n 
-0001185479 00000 n 
-0000009029 00000 n 
-0000009080 00000 n 
-0000476402 00000 n 
-0001185361 00000 n 
-0000009134 00000 n 
-0000009179 00000 n 
-0000476530 00000 n 
-0001185282 00000 n 
-0000009238 00000 n 
-0000009272 00000 n 
-0000480123 00000 n 
-0001185203 00000 n 
-0000009331 00000 n 
-0000009379 00000 n 
-0000480252 00000 n 
-0001185085 00000 n 
-0000009433 00000 n 
-0000009473 00000 n 
-0000480381 00000 n 
-0001185006 00000 n 
-0000009532 00000 n 
-0000009566 00000 n 
-0000483233 00000 n 
-0001184927 00000 n 
-0000009625 00000 n 
-0000009673 00000 n 
-0000483362 00000 n 
-0001184794 00000 n 
-0000009722 00000 n 
-0000009772 00000 n 
-0000486468 00000 n 
+0000466912 00000 n 
+0001188941 00000 n 
+0000008782 00000 n 
+0000008852 00000 n 
+0000469397 00000 n 
+0001188808 00000 n 
+0000008899 00000 n 
+0000008952 00000 n 
+0000469526 00000 n 
+0001188729 00000 n 
+0000009001 00000 n 
+0000009057 00000 n 
+0000469655 00000 n 
+0001188650 00000 n 
+0000009106 00000 n 
+0000009155 00000 n 
+0000473925 00000 n 
+0001188517 00000 n 
+0000009202 00000 n 
+0000009254 00000 n 
+0000474054 00000 n 
+0001188399 00000 n 
+0000009303 00000 n 
+0000009354 00000 n 
+0000478746 00000 n 
+0001188281 00000 n 
+0000009408 00000 n 
+0000009453 00000 n 
+0000478874 00000 n 
+0001188202 00000 n 
+0000009512 00000 n 
+0000009546 00000 n 
+0000482467 00000 n 
+0001188123 00000 n 
+0000009605 00000 n 
+0000009653 00000 n 
+0000482596 00000 n 
+0001188005 00000 n 
+0000009707 00000 n 
+0000009747 00000 n 
+0000482725 00000 n 
+0001187926 00000 n 
+0000009806 00000 n 
+0000009840 00000 n 
+0000485577 00000 n 
+0001187847 00000 n 
+0000009899 00000 n 
+0000009947 00000 n 
+0000485706 00000 n 
+0001187714 00000 n 
+0000009996 00000 n 
+0000010046 00000 n 
+0000488812 00000 n 
+0001187635 00000 n 
+0000010100 00000 n 
+0000010147 00000 n 
+0000488940 00000 n 
+0001187542 00000 n 
+0000010201 00000 n 
+0000010261 00000 n 
+0000489199 00000 n 
+0001187449 00000 n 
+0000010315 00000 n 
+0000010367 00000 n 
+0000494381 00000 n 
+0001187356 00000 n 
+0000010421 00000 n 
+0000010486 00000 n 
+0000494510 00000 n 
+0001187263 00000 n 
+0000010540 00000 n 
+0000010591 00000 n 
+0000497987 00000 n 
+0001187170 00000 n 
+0000010645 00000 n 
+0000010709 00000 n 
+0000498116 00000 n 
+0001187077 00000 n 
+0000010763 00000 n 
+0000010810 00000 n 
+0000498245 00000 n 
+0001186984 00000 n 
+0000010864 00000 n 
+0000010924 00000 n 
+0000498374 00000 n 
+0001186891 00000 n 
+0000010978 00000 n 
+0000011029 00000 n 
+0000502392 00000 n 
+0001186759 00000 n 
+0000011084 00000 n 
+0000011149 00000 n 
+0000502521 00000 n 
+0001186680 00000 n 
+0000011209 00000 n 
+0000011256 00000 n 
+0000509342 00000 n 
+0001186587 00000 n 
+0000011316 00000 n 
+0000011364 00000 n 
+0000515898 00000 n 
+0001186508 00000 n 
+0000011424 00000 n 
+0000011478 00000 n 
+0000519125 00000 n 
+0001186415 00000 n 
+0000011533 00000 n 
+0000011583 00000 n 
+0000522025 00000 n 
+0001186322 00000 n 
+0000011638 00000 n 
+0000011701 00000 n 
+0000522154 00000 n 
+0001186229 00000 n 
+0000011756 00000 n 
+0000011808 00000 n 
+0000522283 00000 n 
+0001186136 00000 n 
+0000011863 00000 n 
+0000011928 00000 n 
+0000522412 00000 n 
+0001186043 00000 n 
+0000011983 00000 n 
+0000012035 00000 n 
+0000530133 00000 n 
+0001185910 00000 n 
+0000012090 00000 n 
+0000012155 00000 n 
+0000547248 00000 n 
+0001185831 00000 n 
+0000012215 00000 n 
+0000012259 00000 n 
+0000573333 00000 n 
+0001185738 00000 n 
+0000012319 00000 n 
+0000012358 00000 n 
+0000573461 00000 n 
+0001185645 00000 n 
+0000012418 00000 n 
+0000012465 00000 n 
+0000576765 00000 n 
+0001185552 00000 n 
+0000012525 00000 n 
+0000012568 00000 n 
+0000581080 00000 n 
+0001185459 00000 n 
+0000012628 00000 n 
+0000012667 00000 n 
+0000584829 00000 n 
+0001185366 00000 n 
+0000012727 00000 n 
+0000012769 00000 n 
+0000587747 00000 n 
+0001185273 00000 n 
+0000012829 00000 n 
+0000012872 00000 n 
+0000595219 00000 n 
+0001185180 00000 n 
+0000012932 00000 n 
+0000012975 00000 n 
+0000599488 00000 n 
+0001185087 00000 n 
+0000013035 00000 n 
+0000013096 00000 n 
+0000599617 00000 n 
+0001184994 00000 n 
+0000013157 00000 n 
+0000013209 00000 n 
+0000603545 00000 n 
+0001184901 00000 n 
+0000013270 00000 n 
+0000013323 00000 n 
+0000607493 00000 n 
+0001184808 00000 n 
+0000013384 00000 n 
+0000013422 00000 n 
+0000607622 00000 n 
 0001184715 00000 n 
-0000009826 00000 n 
-0000009873 00000 n 
-0000486596 00000 n 
+0000013483 00000 n 
+0000013535 00000 n 
+0000610784 00000 n 
 0001184622 00000 n 
-0000009927 00000 n 
-0000009987 00000 n 
-0000486855 00000 n 
+0000013596 00000 n 
+0000013640 00000 n 
+0000614197 00000 n 
 0001184529 00000 n 
-0000010041 00000 n 
-0000010093 00000 n 
-0000492037 00000 n 
+0000013701 00000 n 
+0000013737 00000 n 
+0000623179 00000 n 
 0001184436 00000 n 
-0000010147 00000 n 
-0000010212 00000 n 
-0000492166 00000 n 
+0000013798 00000 n 
+0000013861 00000 n 
+0000626103 00000 n 
 0001184343 00000 n 
-0000010266 00000 n 
-0000010317 00000 n 
-0000495643 00000 n 
+0000013922 00000 n 
+0000013972 00000 n 
+0000629305 00000 n 
 0001184250 00000 n 
-0000010371 00000 n 
-0000010435 00000 n 
-0000495772 00000 n 
+0000014033 00000 n 
+0000014089 00000 n 
+0000633752 00000 n 
 0001184157 00000 n 
-0000010489 00000 n 
-0000010536 00000 n 
-0000495901 00000 n 
-0001184064 00000 n 
-0000010590 00000 n 
-0000010650 00000 n 
-0000496030 00000 n 
-0001183971 00000 n 
-0000010704 00000 n 
-0000010755 00000 n 
-0000500048 00000 n 
-0001183839 00000 n 
-0000010810 00000 n 
-0000010875 00000 n 
-0000500177 00000 n 
-0001183760 00000 n 
-0000010935 00000 n 
-0000010982 00000 n 
-0000506998 00000 n 
-0001183667 00000 n 
-0000011042 00000 n 
-0000011090 00000 n 
-0000514107 00000 n 
-0001183588 00000 n 
-0000011150 00000 n 
-0000011204 00000 n 
-0000517704 00000 n 
-0001183495 00000 n 
-0000011259 00000 n 
-0000011309 00000 n 
-0000517833 00000 n 
-0001183402 00000 n 
-0000011364 00000 n 
-0000011427 00000 n 
-0000519834 00000 n 
-0001183309 00000 n 
-0000011482 00000 n 
-0000011534 00000 n 
-0000519963 00000 n 
-0001183216 00000 n 
-0000011589 00000 n 
-0000011654 00000 n 
-0000520092 00000 n 
-0001183123 00000 n 
-0000011709 00000 n 
-0000011761 00000 n 
-0000525241 00000 n 
-0001182990 00000 n 
-0000011816 00000 n 
-0000011881 00000 n 
-0000545686 00000 n 
-0001182911 00000 n 
-0000011941 00000 n 
-0000011985 00000 n 
-0000571723 00000 n 
-0001182818 00000 n 
-0000012045 00000 n 
-0000012084 00000 n 
-0000571852 00000 n 
-0001182725 00000 n 
-0000012144 00000 n 
-0000012191 00000 n 
-0000571981 00000 n 
-0001182632 00000 n 
-0000012251 00000 n 
-0000012294 00000 n 
-0000579045 00000 n 
-0001182539 00000 n 
-0000012354 00000 n 
-0000012393 00000 n 
-0000582806 00000 n 
-0001182446 00000 n 
-0000012453 00000 n 
-0000012495 00000 n 
-0000585863 00000 n 
-0001182353 00000 n 
-0000012555 00000 n 
-0000012598 00000 n 
-0000593565 00000 n 
-0001182260 00000 n 
-0000012658 00000 n 
-0000012701 00000 n 
-0000597951 00000 n 
-0001182167 00000 n 
-0000012761 00000 n 
-0000012822 00000 n 
-0000598080 00000 n 
-0001182074 00000 n 
-0000012883 00000 n 
-0000012935 00000 n 
-0000601882 00000 n 
-0001181981 00000 n 
-0000012996 00000 n 
-0000013049 00000 n 
-0000602010 00000 n 
-0001181888 00000 n 
-0000013110 00000 n 
-0000013148 00000 n 
-0000606096 00000 n 
-0001181795 00000 n 
-0000013209 00000 n 
-0000013261 00000 n 
-0000609088 00000 n 
-0001181702 00000 n 
-0000013322 00000 n 
-0000013366 00000 n 
-0000612935 00000 n 
-0001181609 00000 n 
-0000013427 00000 n 
-0000013463 00000 n 
-0000621695 00000 n 
-0001181516 00000 n 
-0000013524 00000 n 
-0000013587 00000 n 
-0000621824 00000 n 
-0001181423 00000 n 
-0000013648 00000 n 
-0000013698 00000 n 
-0000627724 00000 n 
-0001181330 00000 n 
-0000013759 00000 n 
-0000013815 00000 n 
-0000632063 00000 n 
-0001181237 00000 n 
-0000013876 00000 n 
-0000013923 00000 n 
-0000636416 00000 n 
-0001181158 00000 n 
-0000013984 00000 n 
-0000014052 00000 n 
-0000642107 00000 n 
-0001181065 00000 n 
-0000014107 00000 n 
-0000014158 00000 n 
-0000647256 00000 n 
-0001180972 00000 n 
-0000014213 00000 n 
-0000014277 00000 n 
-0000650985 00000 n 
-0001180879 00000 n 
-0000014332 00000 n 
-0000014396 00000 n 
-0000651114 00000 n 
-0001180786 00000 n 
-0000014451 00000 n 
-0000014528 00000 n 
-0000651243 00000 n 
-0001180693 00000 n 
-0000014583 00000 n 
-0000014640 00000 n 
-0000651372 00000 n 
-0001180600 00000 n 
-0000014695 00000 n 
-0000014765 00000 n 
-0000655395 00000 n 
-0001180507 00000 n 
-0000014820 00000 n 
-0000014877 00000 n 
-0000655524 00000 n 
-0001180414 00000 n 
-0000014932 00000 n 
-0000015002 00000 n 
-0000659809 00000 n 
-0001180321 00000 n 
-0000015057 00000 n 
-0000015106 00000 n 
-0000659938 00000 n 
-0001180228 00000 n 
-0000015161 00000 n 
-0000015223 00000 n 
-0000661568 00000 n 
-0001180135 00000 n 
-0000015278 00000 n 
-0000015327 00000 n 
-0000666053 00000 n 
-0001180017 00000 n 
-0000015382 00000 n 
-0000015444 00000 n 
-0000666182 00000 n 
-0001179938 00000 n 
-0000015504 00000 n 
-0000015543 00000 n 
-0000679084 00000 n 
-0001179845 00000 n 
-0000015603 00000 n 
-0000015637 00000 n 
-0000679213 00000 n 
-0001179752 00000 n 
-0000015697 00000 n 
-0000015738 00000 n 
-0000699171 00000 n 
-0001179673 00000 n 
-0000015798 00000 n 
-0000015850 00000 n 
-0000705922 00000 n 
-0001179541 00000 n 
-0000015899 00000 n 
-0000015932 00000 n 
-0000706050 00000 n 
-0001179423 00000 n 
-0000015986 00000 n 
-0000016058 00000 n 
-0000706179 00000 n 
-0001179344 00000 n 
-0000016117 00000 n 
-0000016161 00000 n 
-0000717356 00000 n 
-0001179265 00000 n 
-0000016220 00000 n 
-0000016273 00000 n 
-0000721072 00000 n 
-0001179172 00000 n 
-0000016327 00000 n 
-0000016377 00000 n 
-0000721331 00000 n 
-0001179079 00000 n 
-0000016431 00000 n 
-0000016469 00000 n 
-0000724476 00000 n 
-0001178986 00000 n 
-0000016523 00000 n 
-0000016572 00000 n 
-0000724735 00000 n 
-0001178854 00000 n 
-0000016626 00000 n 
-0000016678 00000 n 
-0000724864 00000 n 
-0001178775 00000 n 
-0000016737 00000 n 
-0000016782 00000 n 
-0000724993 00000 n 
-0001178682 00000 n 
-0000016841 00000 n 
-0000016893 00000 n 
-0000727721 00000 n 
-0001178589 00000 n 
+0000014150 00000 n 
+0000014197 00000 n 
+0000637921 00000 n 
+0001184078 00000 n 
+0000014258 00000 n 
+0000014326 00000 n 
+0000644527 00000 n 
+0001183985 00000 n 
+0000014381 00000 n 
+0000014432 00000 n 
+0000648633 00000 n 
+0001183892 00000 n 
+0000014487 00000 n 
+0000014551 00000 n 
+0000653039 00000 n 
+0001183799 00000 n 
+0000014606 00000 n 
+0000014670 00000 n 
+0000653168 00000 n 
+0001183706 00000 n 
+0000014725 00000 n 
+0000014802 00000 n 
+0000653296 00000 n 
+0001183613 00000 n 
+0000014857 00000 n 
+0000014914 00000 n 
+0000657250 00000 n 
+0001183520 00000 n 
+0000014969 00000 n 
+0000015039 00000 n 
+0000657379 00000 n 
+0001183427 00000 n 
+0000015094 00000 n 
+0000015151 00000 n 
+0000657508 00000 n 
+0001183334 00000 n 
+0000015206 00000 n 
+0000015276 00000 n 
+0000661684 00000 n 
+0001183241 00000 n 
+0000015331 00000 n 
+0000015380 00000 n 
+0000661813 00000 n 
+0001183148 00000 n 
+0000015435 00000 n 
+0000015497 00000 n 
+0000664201 00000 n 
+0001183055 00000 n 
+0000015552 00000 n 
+0000015601 00000 n 
+0000668974 00000 n 
+0001182937 00000 n 
+0000015656 00000 n 
+0000015718 00000 n 
+0000669102 00000 n 
+0001182858 00000 n 
+0000015778 00000 n 
+0000015817 00000 n 
+0000682004 00000 n 
+0001182765 00000 n 
+0000015877 00000 n 
+0000015911 00000 n 
+0000682133 00000 n 
+0001182672 00000 n 
+0000015971 00000 n 
+0000016012 00000 n 
+0000702091 00000 n 
+0001182593 00000 n 
+0000016072 00000 n 
+0000016124 00000 n 
+0000708842 00000 n 
+0001182461 00000 n 
+0000016173 00000 n 
+0000016206 00000 n 
+0000708970 00000 n 
+0001182343 00000 n 
+0000016260 00000 n 
+0000016332 00000 n 
+0000709099 00000 n 
+0001182264 00000 n 
+0000016391 00000 n 
+0000016435 00000 n 
+0000720276 00000 n 
+0001182185 00000 n 
+0000016494 00000 n 
+0000016547 00000 n 
+0000723992 00000 n 
+0001182092 00000 n 
+0000016601 00000 n 
+0000016651 00000 n 
+0000724251 00000 n 
+0001181999 00000 n 
+0000016705 00000 n 
+0000016743 00000 n 
+0000727396 00000 n 
+0001181906 00000 n 
+0000016797 00000 n 
+0000016846 00000 n 
+0000727655 00000 n 
+0001181774 00000 n 
+0000016900 00000 n 
 0000016952 00000 n 
-0000017005 00000 n 
-0000727850 00000 n 
-0001178510 00000 n 
-0000017064 00000 n 
-0000017113 00000 n 
-0000727979 00000 n 
-0001178417 00000 n 
+0000727784 00000 n 
+0001181695 00000 n 
+0000017011 00000 n 
+0000017056 00000 n 
+0000727913 00000 n 
+0001181602 00000 n 
+0000017115 00000 n 
 0000017167 00000 n 
-0000017247 00000 n 
-0000732028 00000 n 
-0001178338 00000 n 
-0000017301 00000 n 
-0000017350 00000 n 
-0000735697 00000 n 
-0001178220 00000 n 
-0000017399 00000 n 
-0000017439 00000 n 
-0000735956 00000 n 
-0001178141 00000 n 
-0000017498 00000 n 
-0000017545 00000 n 
-0000739311 00000 n 
-0001178023 00000 n 
-0000017599 00000 n 
-0000017644 00000 n 
-0000739440 00000 n 
-0001177944 00000 n 
-0000017703 00000 n 
-0000017762 00000 n 
-0000742853 00000 n 
-0001177851 00000 n 
-0000017821 00000 n 
-0000017885 00000 n 
-0000743112 00000 n 
-0001177758 00000 n 
-0000017944 00000 n 
-0000018000 00000 n 
-0000747198 00000 n 
-0001177665 00000 n 
-0000018059 00000 n 
-0000018117 00000 n 
-0000749609 00000 n 
-0001177586 00000 n 
-0000018176 00000 n 
-0000018238 00000 n 
-0000751394 00000 n 
-0001177453 00000 n 
-0000018285 00000 n 
-0000018337 00000 n 
-0000751522 00000 n 
-0001177374 00000 n 
-0000018386 00000 n 
-0000018430 00000 n 
-0000755557 00000 n 
-0001177242 00000 n 
-0000018479 00000 n 
-0000018520 00000 n 
-0000755686 00000 n 
-0001177163 00000 n 
-0000018574 00000 n 
-0000018622 00000 n 
-0000755814 00000 n 
-0001177084 00000 n 
-0000018676 00000 n 
-0000018727 00000 n 
-0000755943 00000 n 
-0001177005 00000 n 
-0000018776 00000 n 
-0000018823 00000 n 
-0000760542 00000 n 
-0001176872 00000 n 
-0000018870 00000 n 
-0000018907 00000 n 
-0000760671 00000 n 
-0001176754 00000 n 
-0000018956 00000 n 
-0000018995 00000 n 
-0000760800 00000 n 
-0001176689 00000 n 
-0000019049 00000 n 
-0000019127 00000 n 
-0000760929 00000 n 
-0001176596 00000 n 
-0000019176 00000 n 
-0000019243 00000 n 
-0000761058 00000 n 
-0001176517 00000 n 
-0000019292 00000 n 
-0000019337 00000 n 
-0000764499 00000 n 
-0001176384 00000 n 
-0000019385 00000 n 
-0000019417 00000 n 
-0000764628 00000 n 
-0001176266 00000 n 
-0000019466 00000 n 
-0000019505 00000 n 
-0000764757 00000 n 
-0001176201 00000 n 
-0000019559 00000 n 
-0000019620 00000 n 
-0000768439 00000 n 
-0001176069 00000 n 
-0000019669 00000 n 
-0000019726 00000 n 
-0000768568 00000 n 
-0001176004 00000 n 
-0000019780 00000 n 
-0000019829 00000 n 
-0000768697 00000 n 
-0001175872 00000 n 
-0000019878 00000 n 
-0000019940 00000 n 
-0000768826 00000 n 
-0001175793 00000 n 
-0000019994 00000 n 
-0000020049 00000 n 
-0000793668 00000 n 
-0001175700 00000 n 
+0000730641 00000 n 
+0001181509 00000 n 
+0000017226 00000 n 
+0000017279 00000 n 
+0000730770 00000 n 
+0001181430 00000 n 
+0000017338 00000 n 
+0000017387 00000 n 
+0000730899 00000 n 
+0001181337 00000 n 
+0000017441 00000 n 
+0000017521 00000 n 
+0000734948 00000 n 
+0001181258 00000 n 
+0000017575 00000 n 
+0000017624 00000 n 
+0000738617 00000 n 
+0001181140 00000 n 
+0000017673 00000 n 
+0000017713 00000 n 
+0000738876 00000 n 
+0001181061 00000 n 
+0000017772 00000 n 
+0000017819 00000 n 
+0000742231 00000 n 
+0001180943 00000 n 
+0000017873 00000 n 
+0000017918 00000 n 
+0000742360 00000 n 
+0001180864 00000 n 
+0000017977 00000 n 
+0000018036 00000 n 
+0000745773 00000 n 
+0001180771 00000 n 
+0000018095 00000 n 
+0000018159 00000 n 
+0000746032 00000 n 
+0001180678 00000 n 
+0000018218 00000 n 
+0000018274 00000 n 
+0000750118 00000 n 
+0001180585 00000 n 
+0000018333 00000 n 
+0000018391 00000 n 
+0000752529 00000 n 
+0001180506 00000 n 
+0000018450 00000 n 
+0000018512 00000 n 
+0000754314 00000 n 
+0001180373 00000 n 
+0000018559 00000 n 
+0000018611 00000 n 
+0000754442 00000 n 
+0001180294 00000 n 
+0000018660 00000 n 
+0000018704 00000 n 
+0000758477 00000 n 
+0001180162 00000 n 
+0000018753 00000 n 
+0000018794 00000 n 
+0000758606 00000 n 
+0001180083 00000 n 
+0000018848 00000 n 
+0000018896 00000 n 
+0000758734 00000 n 
+0001180004 00000 n 
+0000018950 00000 n 
+0000019001 00000 n 
+0000758863 00000 n 
+0001179925 00000 n 
+0000019050 00000 n 
+0000019097 00000 n 
+0000763462 00000 n 
+0001179792 00000 n 
+0000019144 00000 n 
+0000019181 00000 n 
+0000763591 00000 n 
+0001179674 00000 n 
+0000019230 00000 n 
+0000019269 00000 n 
+0000763720 00000 n 
+0001179609 00000 n 
+0000019323 00000 n 
+0000019401 00000 n 
+0000763849 00000 n 
+0001179516 00000 n 
+0000019450 00000 n 
+0000019517 00000 n 
+0000763978 00000 n 
+0001179437 00000 n 
+0000019566 00000 n 
+0000019611 00000 n 
+0000767419 00000 n 
+0001179304 00000 n 
+0000019659 00000 n 
+0000019691 00000 n 
+0000767548 00000 n 
+0001179186 00000 n 
+0000019740 00000 n 
+0000019779 00000 n 
+0000767677 00000 n 
+0001179121 00000 n 
+0000019833 00000 n 
+0000019894 00000 n 
+0000771359 00000 n 
+0001178989 00000 n 
+0000019943 00000 n 
+0000020000 00000 n 
+0000771488 00000 n 
+0001178924 00000 n 
+0000020054 00000 n 
 0000020103 00000 n 
-0000020144 00000 n 
-0000793797 00000 n 
-0001175621 00000 n 
-0000020198 00000 n 
-0000020250 00000 n 
-0000794186 00000 n 
-0001175503 00000 n 
-0000020299 00000 n 
-0000020349 00000 n 
-0000797007 00000 n 
-0001175424 00000 n 
-0000020403 00000 n 
-0000020441 00000 n 
-0000797136 00000 n 
-0001175331 00000 n 
-0000020495 00000 n 
-0000020532 00000 n 
-0000797265 00000 n 
-0001175238 00000 n 
-0000020586 00000 n 
-0000020624 00000 n 
-0000797394 00000 n 
-0001175145 00000 n 
-0000020678 00000 n 
-0000020730 00000 n 
-0000800630 00000 n 
-0001175052 00000 n 
-0000020784 00000 n 
-0000020827 00000 n 
-0000800758 00000 n 
-0001174920 00000 n 
-0000020881 00000 n 
-0000020926 00000 n 
-0000800886 00000 n 
-0001174841 00000 n 
-0000020985 00000 n 
-0000021051 00000 n 
-0000803872 00000 n 
-0001174748 00000 n 
-0000021110 00000 n 
-0000021198 00000 n 
-0000804001 00000 n 
-0001174655 00000 n 
-0000021257 00000 n 
-0000021332 00000 n 
-0000804130 00000 n 
-0001174562 00000 n 
-0000021391 00000 n 
-0000021476 00000 n 
-0000807039 00000 n 
-0001174469 00000 n 
-0000021535 00000 n 
-0000021616 00000 n 
-0000809500 00000 n 
-0001174390 00000 n 
-0000021675 00000 n 
-0000021759 00000 n 
-0000809629 00000 n 
-0001174311 00000 n 
-0000021813 00000 n 
-0000021857 00000 n 
-0000812458 00000 n 
-0001174191 00000 n 
-0000021905 00000 n 
-0000021939 00000 n 
-0000812587 00000 n 
-0001174112 00000 n 
-0000021988 00000 n 
-0000022015 00000 n 
-0000834724 00000 n 
-0001174019 00000 n 
-0000022064 00000 n 
-0000022092 00000 n 
-0000838415 00000 n 
-0001173926 00000 n 
-0000022141 00000 n 
-0000022181 00000 n 
-0000844481 00000 n 
-0001173833 00000 n 
-0000022230 00000 n 
-0000022273 00000 n 
-0000854793 00000 n 
-0001173740 00000 n 
-0000022322 00000 n 
-0000022359 00000 n 
-0000867443 00000 n 
-0001173647 00000 n 
-0000022408 00000 n 
-0000022445 00000 n 
-0000867962 00000 n 
-0001173554 00000 n 
-0000022494 00000 n 
-0000022532 00000 n 
-0000878107 00000 n 
-0001173461 00000 n 
-0000022581 00000 n 
-0000022620 00000 n 
-0000892047 00000 n 
-0001173368 00000 n 
-0000022669 00000 n 
-0000022708 00000 n 
-0000895030 00000 n 
-0001173275 00000 n 
-0000022758 00000 n 
-0000022798 00000 n 
-0000904628 00000 n 
-0001173182 00000 n 
-0000022848 00000 n 
-0000022878 00000 n 
-0000914095 00000 n 
-0001173089 00000 n 
-0000022928 00000 n 
-0000022971 00000 n 
-0000917680 00000 n 
-0001172996 00000 n 
-0000023021 00000 n 
-0000023054 00000 n 
-0000931756 00000 n 
-0001172903 00000 n 
-0000023104 00000 n 
-0000023133 00000 n 
-0000934964 00000 n 
-0001172810 00000 n 
-0000023183 00000 n 
-0000023217 00000 n 
-0000940979 00000 n 
-0001172717 00000 n 
-0000023267 00000 n 
-0000023304 00000 n 
-0000947639 00000 n 
-0001172624 00000 n 
-0000023354 00000 n 
-0000023391 00000 n 
-0000950869 00000 n 
-0001172531 00000 n 
-0000023441 00000 n 
-0000023474 00000 n 
-0000952941 00000 n 
-0001172438 00000 n 
-0000023524 00000 n 
-0000023558 00000 n 
-0000953458 00000 n 
-0001172345 00000 n 
-0000023608 00000 n 
-0000023647 00000 n 
-0000956323 00000 n 
-0001172266 00000 n 
-0000023697 00000 n 
-0000023731 00000 n 
-0000024104 00000 n 
-0000024226 00000 n 
-0000289027 00000 n 
-0000023784 00000 n 
-0000288901 00000 n 
-0000288964 00000 n 
-0001166471 00000 n 
-0001140329 00000 n 
-0001166297 00000 n 
-0001167517 00000 n 
-0000025535 00000 n 
-0000025728 00000 n 
-0000025808 00000 n 
-0000025845 00000 n 
-0000025926 00000 n 
-0000026050 00000 n 
-0000026309 00000 n 
-0000026668 00000 n 
-0000026700 00000 n 
-0000026794 00000 n 
-0000027827 00000 n 
-0000038963 00000 n 
-0000104553 00000 n 
-0000170143 00000 n 
-0000235733 00000 n 
-0000290455 00000 n 
-0000290270 00000 n 
-0000289127 00000 n 
-0000290392 00000 n 
-0001139093 00000 n 
-0001112474 00000 n 
-0001138919 00000 n 
-0001111789 00000 n 
-0001109645 00000 n 
-0001111625 00000 n 
-0000302181 00000 n 
-0000293506 00000 n 
-0000290540 00000 n 
-0000302055 00000 n 
-0000302118 00000 n 
-0000294052 00000 n 
-0000294206 00000 n 
-0000294363 00000 n 
-0000294520 00000 n 
-0000294677 00000 n 
-0000294834 00000 n 
-0000294996 00000 n 
-0000295158 00000 n 
-0000295319 00000 n 
-0000295481 00000 n 
-0000295648 00000 n 
-0000295815 00000 n 
-0000295980 00000 n 
-0000296142 00000 n 
-0000296308 00000 n 
-0000296470 00000 n 
-0000296624 00000 n 
-0000296781 00000 n 
-0000296938 00000 n 
-0000297094 00000 n 
-0000297250 00000 n 
-0000297407 00000 n 
-0000297562 00000 n 
-0000297719 00000 n 
-0000297881 00000 n 
-0000298043 00000 n 
-0000298200 00000 n 
-0000298355 00000 n 
-0000298516 00000 n 
-0000298683 00000 n 
-0000298850 00000 n 
-0000299011 00000 n 
-0000299166 00000 n 
-0000299323 00000 n 
-0000299480 00000 n 
-0000299642 00000 n 
-0000299799 00000 n 
-0000299956 00000 n 
-0000300117 00000 n 
-0000300275 00000 n 
-0000300438 00000 n 
-0000300606 00000 n 
-0000300774 00000 n 
-0000300937 00000 n 
-0000301100 00000 n 
-0000301263 00000 n 
-0000301425 00000 n 
-0000301588 00000 n 
-0000301744 00000 n 
-0000301900 00000 n 
-0000315700 00000 n 
-0000305637 00000 n 
-0000302266 00000 n 
-0000315635 00000 n 
-0001109057 00000 n 
-0001091636 00000 n 
-0001108871 00000 n 
-0000306287 00000 n 
-0000306451 00000 n 
-0000306614 00000 n 
-0000306778 00000 n 
-0000306937 00000 n 
-0000307101 00000 n 
-0000307265 00000 n 
-0000307429 00000 n 
-0000307593 00000 n 
-0000307757 00000 n 
-0000307921 00000 n 
-0000308085 00000 n 
-0000308249 00000 n 
-0000308413 00000 n 
-0000308578 00000 n 
-0000308743 00000 n 
-0000308908 00000 n 
-0000309073 00000 n 
-0000309233 00000 n 
-0000309398 00000 n 
-0000309562 00000 n 
-0000309722 00000 n 
-0000309887 00000 n 
-0000310057 00000 n 
-0000310227 00000 n 
-0000310392 00000 n 
-0000310561 00000 n 
-0000310730 00000 n 
-0000310895 00000 n 
-0000311060 00000 n 
-0000311224 00000 n 
-0000311389 00000 n 
-0000311549 00000 n 
-0000311714 00000 n 
-0000311879 00000 n 
-0000312035 00000 n 
-0000312194 00000 n 
-0000312353 00000 n 
-0000312510 00000 n 
-0000312669 00000 n 
-0000312833 00000 n 
-0000313002 00000 n 
-0000313171 00000 n 
-0000313335 00000 n 
-0000313504 00000 n 
-0000313673 00000 n 
-0000313832 00000 n 
-0000313996 00000 n 
-0000314160 00000 n 
-0000314324 00000 n 
-0000314488 00000 n 
-0000314652 00000 n 
-0000314816 00000 n 
-0000314979 00000 n 
-0000315143 00000 n 
-0000315305 00000 n 
-0000315467 00000 n 
-0000329843 00000 n 
-0000319307 00000 n 
-0000315800 00000 n 
-0000329778 00000 n 
-0000319975 00000 n 
-0000320144 00000 n 
-0000320312 00000 n 
-0000320476 00000 n 
-0000320639 00000 n 
-0000320803 00000 n 
-0000320967 00000 n 
-0000321131 00000 n 
-0000321295 00000 n 
-0000321464 00000 n 
-0000321632 00000 n 
-0000321801 00000 n 
-0000321970 00000 n 
-0000322138 00000 n 
-0000322307 00000 n 
-0000322476 00000 n 
-0000322644 00000 n 
-0000322813 00000 n 
-0000322983 00000 n 
-0000323153 00000 n 
-0000323323 00000 n 
-0000323493 00000 n 
-0000323663 00000 n 
-0000323833 00000 n 
-0000324003 00000 n 
-0000324173 00000 n 
-0000324343 00000 n 
-0000324513 00000 n 
-0000324682 00000 n 
-0000324846 00000 n 
-0000325009 00000 n 
-0000325173 00000 n 
-0000325337 00000 n 
-0000325501 00000 n 
-0000325665 00000 n 
-0000325829 00000 n 
-0000325992 00000 n 
-0000326156 00000 n 
-0000326320 00000 n 
-0000326483 00000 n 
-0000326647 00000 n 
-0000326816 00000 n 
-0000326985 00000 n 
-0000327154 00000 n 
-0000327323 00000 n 
-0000327481 00000 n 
-0000327644 00000 n 
-0000327812 00000 n 
-0000327979 00000 n 
-0000328142 00000 n 
-0000328304 00000 n 
-0000328467 00000 n 
-0000328630 00000 n 
-0000328798 00000 n 
-0000328966 00000 n 
-0000329134 00000 n 
-0000329301 00000 n 
-0000329462 00000 n 
-0000329622 00000 n 
-0000343010 00000 n 
-0000333437 00000 n 
-0000329943 00000 n 
-0000342945 00000 n 
-0000334069 00000 n 
-0000334237 00000 n 
-0000334400 00000 n 
-0000334568 00000 n 
-0000334736 00000 n 
-0000334904 00000 n 
-0001090745 00000 n 
-0001069411 00000 n 
-0001090569 00000 n 
-0000335072 00000 n 
-0000335239 00000 n 
-0000335395 00000 n 
-0000335553 00000 n 
-0000335710 00000 n 
-0000335872 00000 n 
-0000336035 00000 n 
-0000336193 00000 n 
-0000336349 00000 n 
-0000336507 00000 n 
-0000336670 00000 n 
-0000336828 00000 n 
-0000336986 00000 n 
-0000337142 00000 n 
-0000337300 00000 n 
-0000337463 00000 n 
-0000337621 00000 n 
-0000337784 00000 n 
-0000337942 00000 n 
-0000338105 00000 n 
-0000338268 00000 n 
-0000338431 00000 n 
-0000338589 00000 n 
-0000338752 00000 n 
-0000338915 00000 n 
-0000339078 00000 n 
-0000339241 00000 n 
-0000339404 00000 n 
-0000339567 00000 n 
-0000339735 00000 n 
-0000339903 00000 n 
-0000340071 00000 n 
-0000340239 00000 n 
-0000340406 00000 n 
-0000340573 00000 n 
-0000340736 00000 n 
-0000340893 00000 n 
-0000341051 00000 n 
-0000341209 00000 n 
-0000341367 00000 n 
+0000771617 00000 n 
+0001178792 00000 n 
+0000020152 00000 n 
+0000020214 00000 n 
+0000771746 00000 n 
+0001178713 00000 n 
+0000020268 00000 n 
+0000020323 00000 n 
+0000796588 00000 n 
+0001178620 00000 n 
+0000020377 00000 n 
+0000020418 00000 n 
+0000796717 00000 n 
+0001178541 00000 n 
+0000020472 00000 n 
+0000020524 00000 n 
+0000797106 00000 n 
+0001178423 00000 n 
+0000020573 00000 n 
+0000020623 00000 n 
+0000799927 00000 n 
+0001178344 00000 n 
+0000020677 00000 n 
+0000020715 00000 n 
+0000800056 00000 n 
+0001178251 00000 n 
+0000020769 00000 n 
+0000020806 00000 n 
+0000800185 00000 n 
+0001178158 00000 n 
+0000020860 00000 n 
+0000020898 00000 n 
+0000800314 00000 n 
+0001178065 00000 n 
+0000020952 00000 n 
+0000021004 00000 n 
+0000803550 00000 n 
+0001177972 00000 n 
+0000021058 00000 n 
+0000021101 00000 n 
+0000803678 00000 n 
+0001177840 00000 n 
+0000021155 00000 n 
+0000021200 00000 n 
+0000803806 00000 n 
+0001177761 00000 n 
+0000021259 00000 n 
+0000021325 00000 n 
+0000806792 00000 n 
+0001177668 00000 n 
+0000021384 00000 n 
+0000021472 00000 n 
+0000806921 00000 n 
+0001177575 00000 n 
+0000021531 00000 n 
+0000021606 00000 n 
+0000807050 00000 n 
+0001177482 00000 n 
+0000021665 00000 n 
+0000021750 00000 n 
+0000809959 00000 n 
+0001177389 00000 n 
+0000021809 00000 n 
+0000021890 00000 n 
+0000812420 00000 n 
+0001177310 00000 n 
+0000021949 00000 n 
+0000022033 00000 n 
+0000812549 00000 n 
+0001177231 00000 n 
+0000022087 00000 n 
+0000022131 00000 n 
+0000815378 00000 n 
+0001177111 00000 n 
+0000022179 00000 n 
+0000022213 00000 n 
+0000815507 00000 n 
+0001177032 00000 n 
+0000022262 00000 n 
+0000022289 00000 n 
+0000837644 00000 n 
+0001176939 00000 n 
+0000022338 00000 n 
+0000022366 00000 n 
+0000841335 00000 n 
+0001176846 00000 n 
+0000022415 00000 n 
+0000022455 00000 n 
+0000847401 00000 n 
+0001176753 00000 n 
+0000022504 00000 n 
+0000022547 00000 n 
+0000857713 00000 n 
+0001176660 00000 n 
+0000022596 00000 n 
+0000022633 00000 n 
+0000870363 00000 n 
+0001176567 00000 n 
+0000022682 00000 n 
+0000022719 00000 n 
+0000870882 00000 n 
+0001176474 00000 n 
+0000022768 00000 n 
+0000022806 00000 n 
+0000881027 00000 n 
+0001176381 00000 n 
+0000022855 00000 n 
+0000022894 00000 n 
+0000894967 00000 n 
+0001176288 00000 n 
+0000022943 00000 n 
+0000022982 00000 n 
+0000897950 00000 n 
+0001176195 00000 n 
+0000023032 00000 n 
+0000023072 00000 n 
+0000907548 00000 n 
+0001176102 00000 n 
+0000023122 00000 n 
+0000023152 00000 n 
+0000917015 00000 n 
+0001176009 00000 n 
+0000023202 00000 n 
+0000023245 00000 n 
+0000920600 00000 n 
+0001175916 00000 n 
+0000023295 00000 n 
+0000023328 00000 n 
+0000934676 00000 n 
+0001175823 00000 n 
+0000023378 00000 n 
+0000023407 00000 n 
+0000937884 00000 n 
+0001175730 00000 n 
+0000023457 00000 n 
+0000023491 00000 n 
+0000943899 00000 n 
+0001175637 00000 n 
+0000023541 00000 n 
+0000023578 00000 n 
+0000950559 00000 n 
+0001175544 00000 n 
+0000023628 00000 n 
+0000023665 00000 n 
+0000953789 00000 n 
+0001175451 00000 n 
+0000023715 00000 n 
+0000023748 00000 n 
+0000955861 00000 n 
+0001175358 00000 n 
+0000023798 00000 n 
+0000023832 00000 n 
+0000956378 00000 n 
+0001175265 00000 n 
+0000023882 00000 n 
+0000023921 00000 n 
+0000959243 00000 n 
+0001175186 00000 n 
+0000023971 00000 n 
+0000024005 00000 n 
+0000024378 00000 n 
+0000024500 00000 n 
+0000289301 00000 n 
+0000024058 00000 n 
+0000289175 00000 n 
+0000289238 00000 n 
+0001169391 00000 n 
+0001143249 00000 n 
+0001169217 00000 n 
+0001170437 00000 n 
+0000025809 00000 n 
+0000026002 00000 n 
+0000026082 00000 n 
+0000026119 00000 n 
+0000026200 00000 n 
+0000026324 00000 n 
+0000026583 00000 n 
+0000026942 00000 n 
+0000026974 00000 n 
+0000027068 00000 n 
+0000028101 00000 n 
+0000039237 00000 n 
+0000104827 00000 n 
+0000170417 00000 n 
+0000236007 00000 n 
+0000290731 00000 n 
+0000290546 00000 n 
+0000289401 00000 n 
+0000290668 00000 n 
+0001142013 00000 n 
+0001115394 00000 n 
+0001141839 00000 n 
+0001114709 00000 n 
+0001112564 00000 n 
+0001114545 00000 n 
+0000302473 00000 n 
+0000293782 00000 n 
+0000290816 00000 n 
+0000302347 00000 n 
+0000302410 00000 n 
+0000294336 00000 n 
+0000294490 00000 n 
+0000294647 00000 n 
+0000294804 00000 n 
+0000294961 00000 n 
+0000295118 00000 n 
+0000295280 00000 n 
+0000295442 00000 n 
+0000295603 00000 n 
+0000295765 00000 n 
+0000295932 00000 n 
+0000296099 00000 n 
+0000296264 00000 n 
+0000296426 00000 n 
+0000296592 00000 n 
+0000296754 00000 n 
+0000296908 00000 n 
+0000297065 00000 n 
+0000297222 00000 n 
+0000297378 00000 n 
+0000297534 00000 n 
+0000297691 00000 n 
+0000297846 00000 n 
+0000298003 00000 n 
+0000298165 00000 n 
+0000298327 00000 n 
+0000298484 00000 n 
+0000298639 00000 n 
+0000298800 00000 n 
+0000298967 00000 n 
+0000299134 00000 n 
+0000299296 00000 n 
+0000299452 00000 n 
+0000299610 00000 n 
+0000299768 00000 n 
+0000299931 00000 n 
+0000300089 00000 n 
+0000300247 00000 n 
+0000300409 00000 n 
+0000300567 00000 n 
+0000300730 00000 n 
+0000300898 00000 n 
+0000301066 00000 n 
+0000301229 00000 n 
+0000301392 00000 n 
+0000301555 00000 n 
+0000301717 00000 n 
+0000301880 00000 n 
+0000302036 00000 n 
+0000302192 00000 n 
+0000315983 00000 n 
+0000305914 00000 n 
+0000302558 00000 n 
+0000315918 00000 n 
+0001111976 00000 n 
+0001094555 00000 n 
+0001111790 00000 n 
+0000306564 00000 n 
+0000306728 00000 n 
+0000306891 00000 n 
+0000307055 00000 n 
+0000307214 00000 n 
+0000307378 00000 n 
+0000307542 00000 n 
+0000307706 00000 n 
+0000307870 00000 n 
+0000308034 00000 n 
+0000308198 00000 n 
+0000308362 00000 n 
+0000308526 00000 n 
+0000308690 00000 n 
+0000308855 00000 n 
+0000309020 00000 n 
+0000309185 00000 n 
+0000309350 00000 n 
+0000309510 00000 n 
+0000309675 00000 n 
+0000309839 00000 n 
+0000309999 00000 n 
+0000310164 00000 n 
+0000310334 00000 n 
+0000310504 00000 n 
+0000310674 00000 n 
+0000310838 00000 n 
+0000311007 00000 n 
+0000311177 00000 n 
+0000311347 00000 n 
+0000311511 00000 n 
+0000311676 00000 n 
+0000311841 00000 n 
+0000312006 00000 n 
+0000312166 00000 n 
+0000312331 00000 n 
+0000312496 00000 n 
+0000312653 00000 n 
+0000312812 00000 n 
+0000312971 00000 n 
+0000313127 00000 n 
+0000313286 00000 n 
+0000313450 00000 n 
+0000313619 00000 n 
+0000313788 00000 n 
+0000313952 00000 n 
+0000314121 00000 n 
+0000314290 00000 n 
+0000314449 00000 n 
+0000314613 00000 n 
+0000314777 00000 n 
+0000314941 00000 n 
+0000315105 00000 n 
+0000315269 00000 n 
+0000315433 00000 n 
+0000315595 00000 n 
+0000315756 00000 n 
+0000330144 00000 n 
+0000319595 00000 n 
+0000316083 00000 n 
+0000330079 00000 n 
+0000320263 00000 n 
+0000320427 00000 n 
+0000320596 00000 n 
+0000320765 00000 n 
+0000320933 00000 n 
+0000321097 00000 n 
+0000321261 00000 n 
+0000321425 00000 n 
+0000321589 00000 n 
+0000321753 00000 n 
+0000321916 00000 n 
+0000322085 00000 n 
+0000322254 00000 n 
+0000322422 00000 n 
+0000322591 00000 n 
+0000322760 00000 n 
+0000322929 00000 n 
+0000323098 00000 n 
+0000323267 00000 n 
+0000323435 00000 n 
+0000323605 00000 n 
+0000323775 00000 n 
+0000323945 00000 n 
+0000324115 00000 n 
+0000324285 00000 n 
+0000324455 00000 n 
+0000324625 00000 n 
+0000324795 00000 n 
+0000324965 00000 n 
+0000325135 00000 n 
+0000325304 00000 n 
+0000325468 00000 n 
+0000325632 00000 n 
+0000325796 00000 n 
+0000325960 00000 n 
+0000326124 00000 n 
+0000326287 00000 n 
+0000326451 00000 n 
+0000326615 00000 n 
+0000326778 00000 n 
+0000326942 00000 n 
+0000327106 00000 n 
+0000327270 00000 n 
+0000327439 00000 n 
+0000327608 00000 n 
+0000327776 00000 n 
+0000327945 00000 n 
+0000328103 00000 n 
+0000328265 00000 n 
+0000328433 00000 n 
+0000328600 00000 n 
+0000328763 00000 n 
+0000328926 00000 n 
+0000329089 00000 n 
+0000329252 00000 n 
+0000329420 00000 n 
+0000329587 00000 n 
+0000329753 00000 n 
+0000329918 00000 n 
+0000343324 00000 n 
+0000333749 00000 n 
+0000330244 00000 n 
+0000343259 00000 n 
+0000334381 00000 n 
+0000334544 00000 n 
+0000334702 00000 n 
+0000334870 00000 n 
+0000335033 00000 n 
+0000335201 00000 n 
+0000335369 00000 n 
+0000335536 00000 n 
+0001093664 00000 n 
+0001072330 00000 n 
+0001093488 00000 n 
+0000335703 00000 n 
+0000335870 00000 n 
+0000336026 00000 n 
+0000336183 00000 n 
+0000336341 00000 n 
+0000336504 00000 n 
+0000336667 00000 n 
+0000336825 00000 n 
+0000336981 00000 n 
+0000337139 00000 n 
+0000337302 00000 n 
+0000337460 00000 n 
+0000337618 00000 n 
+0000337775 00000 n 
+0000337933 00000 n 
+0000338096 00000 n 
+0000338254 00000 n 
+0000338417 00000 n 
+0000338575 00000 n 
+0000338738 00000 n 
+0000338901 00000 n 
+0000339064 00000 n 
+0000339222 00000 n 
+0000339385 00000 n 
+0000339548 00000 n 
+0000339711 00000 n 
+0000339874 00000 n 
+0000340037 00000 n 
+0000340200 00000 n 
+0000340368 00000 n 
+0000340536 00000 n 
+0000340703 00000 n 
+0000340870 00000 n 
+0000341038 00000 n 
+0000341206 00000 n 
+0000341369 00000 n 
 0000341525 00000 n 
 0000341683 00000 n 
 0000341841 00000 n 
 0000341999 00000 n 
 0000342157 00000 n 
 0000342315 00000 n 
-0000342474 00000 n 
+0000342473 00000 n 
 0000342631 00000 n 
-0000342788 00000 n 
-0000345410 00000 n 
-0000343865 00000 n 
-0000343124 00000 n 
-0000345345 00000 n 
-0000344075 00000 n 
-0001068443 00000 n 
-0001048473 00000 n 
-0001068268 00000 n 
-0000344234 00000 n 
-0000344393 00000 n 
-0000344550 00000 n 
-0000344709 00000 n 
-0000344868 00000 n 
-0000345027 00000 n 
-0000345186 00000 n 
-0001167638 00000 n 
-0000348533 00000 n 
-0000347766 00000 n 
-0000345511 00000 n 
-0000347954 00000 n 
-0000348082 00000 n 
-0000348210 00000 n 
-0000348338 00000 n 
-0000348403 00000 n 
-0000348468 00000 n 
-0001047631 00000 n 
-0001028931 00000 n 
-0001047456 00000 n 
-0000353070 00000 n 
-0000351929 00000 n 
-0000348661 00000 n 
-0000352431 00000 n 
-0000352496 00000 n 
-0000352623 00000 n 
-0000352751 00000 n 
-0000352879 00000 n 
-0000352085 00000 n 
-0000352279 00000 n 
-0000353005 00000 n 
-0000706114 00000 n 
-0000768890 00000 n 
-0000357752 00000 n 
-0000356694 00000 n 
-0000353198 00000 n 
-0000357175 00000 n 
-0000357303 00000 n 
-0000356850 00000 n 
-0000357013 00000 n 
-0000357431 00000 n 
-0000357559 00000 n 
-0000357687 00000 n 
-0000373549 00000 n 
-0000360993 00000 n 
-0000360418 00000 n 
-0000357880 00000 n 
-0000360544 00000 n 
-0000360672 00000 n 
-0000360800 00000 n 
-0000360928 00000 n 
-0000364451 00000 n 
-0000363285 00000 n 
-0000361107 00000 n 
-0000363747 00000 n 
-0000363875 00000 n 
-0000364003 00000 n 
-0000364131 00000 n 
-0000364259 00000 n 
-0000363441 00000 n 
-0000363594 00000 n 
-0000364386 00000 n 
-0000627788 00000 n 
-0000365528 00000 n 
-0000365209 00000 n 
-0000364537 00000 n 
-0000365335 00000 n 
-0000365463 00000 n 
-0001167763 00000 n 
-0000367571 00000 n 
-0000366868 00000 n 
-0000365628 00000 n 
-0000366994 00000 n 
-0000367122 00000 n 
-0000367249 00000 n 
-0000367377 00000 n 
-0000367506 00000 n 
-0000370150 00000 n 
-0000369520 00000 n 
-0000367671 00000 n 
-0000369826 00000 n 
-0000369955 00000 n 
-0000370020 00000 n 
-0000370085 00000 n 
-0000369667 00000 n 
-0000609151 00000 n 
-0000373743 00000 n 
-0000373038 00000 n 
-0000370264 00000 n 
-0000373164 00000 n 
-0000373293 00000 n 
-0000373420 00000 n 
-0001028225 00000 n 
-0001015676 00000 n 
-0001028046 00000 n 
-0000373678 00000 n 
-0000378398 00000 n 
-0000377508 00000 n 
-0000373871 00000 n 
-0000378333 00000 n 
-0001015095 00000 n 
-0001003829 00000 n 
-0001014916 00000 n 
-0000377682 00000 n 
-0000377837 00000 n 
-0000378007 00000 n 
-0000378162 00000 n 
-0000525305 00000 n 
-0000699235 00000 n 
-0000381999 00000 n 
-0000381808 00000 n 
-0000378567 00000 n 
-0000381934 00000 n 
-0000386570 00000 n 
-0000386174 00000 n 
-0000382154 00000 n 
-0000386505 00000 n 
-0000386321 00000 n 
-0001167888 00000 n 
-0000492101 00000 n 
-0000390469 00000 n 
-0000390021 00000 n 
-0000386726 00000 n 
-0000390147 00000 n 
-0000390276 00000 n 
-0000390341 00000 n 
-0000390405 00000 n 
-0000391357 00000 n 
-0000391166 00000 n 
-0000390597 00000 n 
-0000391292 00000 n 
-0000394110 00000 n 
-0000396700 00000 n 
-0000393945 00000 n 
-0000391457 00000 n 
-0000396248 00000 n 
-0000396377 00000 n 
-0000396506 00000 n 
-0000395753 00000 n 
-0000395915 00000 n 
-0001002923 00000 n 
-0000992903 00000 n 
-0001002749 00000 n 
-0000992339 00000 n 
-0000983252 00000 n 
-0000992164 00000 n 
-0000396635 00000 n 
-0000396077 00000 n 
-0000395582 00000 n 
-0000395640 00000 n 
-0000395730 00000 n 
-0000545750 00000 n 
-0000585927 00000 n 
-0000401467 00000 n 
-0000400531 00000 n 
-0000396871 00000 n 
-0000401015 00000 n 
-0000401144 00000 n 
-0000401273 00000 n 
-0000400687 00000 n 
-0000400853 00000 n 
-0000401402 00000 n 
-0000772921 00000 n 
-0000405385 00000 n 
-0000404876 00000 n 
-0000401623 00000 n 
-0000405191 00000 n 
-0000405320 00000 n 
-0000405023 00000 n 
-0000406533 00000 n 
-0000406342 00000 n 
-0000405526 00000 n 
-0000406468 00000 n 
-0001168013 00000 n 
-0000408399 00000 n 
-0000408079 00000 n 
-0000406634 00000 n 
-0000408205 00000 n 
-0000408334 00000 n 
-0000411694 00000 n 
-0000410859 00000 n 
-0000408513 00000 n 
-0000410985 00000 n 
-0000411114 00000 n 
-0000411243 00000 n 
-0000411371 00000 n 
-0000411500 00000 n 
-0000411629 00000 n 
-0000415748 00000 n 
-0000414852 00000 n 
-0000411836 00000 n 
-0000415169 00000 n 
-0000415298 00000 n 
-0000415426 00000 n 
-0000414999 00000 n 
-0000415554 00000 n 
-0000415683 00000 n 
-0000419775 00000 n 
-0000419197 00000 n 
-0000415889 00000 n 
-0000419323 00000 n 
-0000419452 00000 n 
-0000419581 00000 n 
-0000419710 00000 n 
-0000423702 00000 n 
-0000423253 00000 n 
-0000419917 00000 n 
-0000423379 00000 n 
-0000423508 00000 n 
-0000423637 00000 n 
-0000426015 00000 n 
-0000425824 00000 n 
-0000423830 00000 n 
-0000425950 00000 n 
-0001168138 00000 n 
-0000429283 00000 n 
-0000428705 00000 n 
-0000426159 00000 n 
-0000428831 00000 n 
-0000982977 00000 n 
-0000979617 00000 n 
-0000982798 00000 n 
-0000428960 00000 n 
-0000429089 00000 n 
-0000429218 00000 n 
-0000433550 00000 n 
-0000432871 00000 n 
-0000429454 00000 n 
-0000433356 00000 n 
-0000433485 00000 n 
-0000979262 00000 n 
-0000977265 00000 n 
-0000979097 00000 n 
-0000433027 00000 n 
-0000433191 00000 n 
-0000854857 00000 n 
-0000868026 00000 n 
-0000436916 00000 n 
-0000436212 00000 n 
-0000433678 00000 n 
-0000436338 00000 n 
-0000436467 00000 n 
-0000436596 00000 n 
-0000436725 00000 n 
-0000436852 00000 n 
-0000440321 00000 n 
-0000439358 00000 n 
-0000437030 00000 n 
-0000439484 00000 n 
-0000439613 00000 n 
-0000439742 00000 n 
-0000439870 00000 n 
-0000439999 00000 n 
-0000440127 00000 n 
-0000440256 00000 n 
-0000444443 00000 n 
-0000443684 00000 n 
-0000440449 00000 n 
-0000443991 00000 n 
-0000444120 00000 n 
-0000444249 00000 n 
-0000443831 00000 n 
-0000444378 00000 n 
-0000655587 00000 n 
-0000447830 00000 n 
-0000447381 00000 n 
-0000444557 00000 n 
-0000447507 00000 n 
-0000447636 00000 n 
-0000447765 00000 n 
-0001168263 00000 n 
-0000450629 00000 n 
-0000450181 00000 n 
-0000448000 00000 n 
-0000450307 00000 n 
-0000450436 00000 n 
-0000450564 00000 n 
-0000453172 00000 n 
-0000452594 00000 n 
-0000450786 00000 n 
-0000452720 00000 n 
-0000452849 00000 n 
-0000452978 00000 n 
-0000453107 00000 n 
-0000456126 00000 n 
-0000455677 00000 n 
-0000453286 00000 n 
-0000455803 00000 n 
-0000455932 00000 n 
-0000456061 00000 n 
-0000459324 00000 n 
-0000458875 00000 n 
-0000456240 00000 n 
-0000459001 00000 n 
-0000459130 00000 n 
-0000459259 00000 n 
-0000462061 00000 n 
-0000463470 00000 n 
-0000461914 00000 n 
-0000459452 00000 n 
-0000463148 00000 n 
-0000463277 00000 n 
-0000462987 00000 n 
-0000463405 00000 n 
-0000768632 00000 n 
-0000464754 00000 n 
-0000464434 00000 n 
-0000463641 00000 n 
-0000464560 00000 n 
-0000464689 00000 n 
-0001168388 00000 n 
-0000467440 00000 n 
-0000466862 00000 n 
-0000464868 00000 n 
-0000466988 00000 n 
-0000467117 00000 n 
-0000467246 00000 n 
-0000467375 00000 n 
-0000467881 00000 n 
-0000467690 00000 n 
-0000467540 00000 n 
-0000467816 00000 n 
-0000471968 00000 n 
-0000471202 00000 n 
-0000467923 00000 n 
-0000471516 00000 n 
-0000471645 00000 n 
-0000471773 00000 n 
-0000471838 00000 n 
-0000471903 00000 n 
-0000471349 00000 n 
-0000476466 00000 n 
-0000476658 00000 n 
-0000476211 00000 n 
-0000472068 00000 n 
-0000476337 00000 n 
-0000476593 00000 n 
-0000480510 00000 n 
-0000479932 00000 n 
-0000476786 00000 n 
-0000480058 00000 n 
-0000480187 00000 n 
-0000480316 00000 n 
-0000480445 00000 n 
-0000483620 00000 n 
-0000483042 00000 n 
-0000480651 00000 n 
-0000483168 00000 n 
-0000483297 00000 n 
-0000483426 00000 n 
-0000483491 00000 n 
-0000483555 00000 n 
-0001168513 00000 n 
-0000486981 00000 n 
-0000486277 00000 n 
-0000483777 00000 n 
-0000486403 00000 n 
-0000486532 00000 n 
-0000486660 00000 n 
-0000486725 00000 n 
-0000486790 00000 n 
-0000486916 00000 n 
-0000492294 00000 n 
-0000491506 00000 n 
-0000487095 00000 n 
-0000491972 00000 n 
-0000491662 00000 n 
-0000491813 00000 n 
-0000492230 00000 n 
-0000958244 00000 n 
-0000496159 00000 n 
-0000494888 00000 n 
-0000492435 00000 n 
-0000495578 00000 n 
-0000495707 00000 n 
-0000495836 00000 n 
-0000495965 00000 n 
-0000495053 00000 n 
-0000495205 00000 n 
-0000495391 00000 n 
-0000496094 00000 n 
-0000500306 00000 n 
-0000499857 00000 n 
-0000496287 00000 n 
-0000499983 00000 n 
-0000500112 00000 n 
-0000500241 00000 n 
-0000504212 00000 n 
-0000503833 00000 n 
-0000500434 00000 n 
-0000504147 00000 n 
-0000503980 00000 n 
-0000507062 00000 n 
-0000507257 00000 n 
-0000506807 00000 n 
-0000504326 00000 n 
-0000506933 00000 n 
-0000507127 00000 n 
-0000507192 00000 n 
-0001168638 00000 n 
-0000510818 00000 n 
-0000510627 00000 n 
-0000507371 00000 n 
-0000510753 00000 n 
-0000514365 00000 n 
-0000513916 00000 n 
-0000510932 00000 n 
-0000514042 00000 n 
-0000514170 00000 n 
-0000514235 00000 n 
-0000514300 00000 n 
-0000517961 00000 n 
-0000517178 00000 n 
-0000514479 00000 n 
-0000517639 00000 n 
-0000517768 00000 n 
-0000517896 00000 n 
-0000517334 00000 n 
-0000517487 00000 n 
-0000520221 00000 n 
-0000519643 00000 n 
-0000518075 00000 n 
-0000519769 00000 n 
-0000519898 00000 n 
-0000520027 00000 n 
-0000520156 00000 n 
+0000342789 00000 n 
+0000342945 00000 n 
+0000343102 00000 n 
+0000346164 00000 n 
+0000344283 00000 n 
+0000343438 00000 n 
+0000346099 00000 n 
+0000344511 00000 n 
+0000344670 00000 n 
+0000344829 00000 n 
+0001071362 00000 n 
+0001051392 00000 n 
+0001071187 00000 n 
+0000344987 00000 n 
+0000345146 00000 n 
+0000345305 00000 n 
+0000345464 00000 n 
+0000345623 00000 n 
+0000345782 00000 n 
+0000345940 00000 n 
+0001170558 00000 n 
+0000349287 00000 n 
+0000348520 00000 n 
+0000346265 00000 n 
+0000348708 00000 n 
+0000348836 00000 n 
+0000348964 00000 n 
+0000349092 00000 n 
+0000349157 00000 n 
+0000349222 00000 n 
+0001050550 00000 n 
+0001031850 00000 n 
+0001050375 00000 n 
+0000353824 00000 n 
+0000352683 00000 n 
+0000349415 00000 n 
+0000353185 00000 n 
+0000353250 00000 n 
+0000353377 00000 n 
+0000353505 00000 n 
+0000353633 00000 n 
+0000352839 00000 n 
+0000353033 00000 n 
+0000353759 00000 n 
+0000709034 00000 n 
+0000771810 00000 n 
+0000358506 00000 n 
+0000357448 00000 n 
+0000353952 00000 n 
+0000357929 00000 n 
+0000358057 00000 n 
+0000357604 00000 n 
+0000357767 00000 n 
+0000358185 00000 n 
+0000358313 00000 n 
+0000358441 00000 n 
+0000374303 00000 n 
+0000361747 00000 n 
+0000361172 00000 n 
+0000358634 00000 n 
+0000361298 00000 n 
+0000361426 00000 n 
+0000361554 00000 n 
+0000361682 00000 n 
+0000365205 00000 n 
+0000364039 00000 n 
+0000361861 00000 n 
+0000364501 00000 n 
+0000364629 00000 n 
+0000364757 00000 n 
+0000364885 00000 n 
+0000365013 00000 n 
+0000364195 00000 n 
+0000364348 00000 n 
+0000365140 00000 n 
+0000629368 00000 n 
+0000366282 00000 n 
+0000365963 00000 n 
+0000365291 00000 n 
+0000366089 00000 n 
+0000366217 00000 n 
+0001170683 00000 n 
+0000368325 00000 n 
+0000367622 00000 n 
+0000366382 00000 n 
+0000367748 00000 n 
+0000367876 00000 n 
+0000368003 00000 n 
+0000368131 00000 n 
+0000368260 00000 n 
+0000370904 00000 n 
+0000370274 00000 n 
+0000368425 00000 n 
+0000370580 00000 n 
+0000370709 00000 n 
+0000370774 00000 n 
+0000370839 00000 n 
+0000370421 00000 n 
+0000610848 00000 n 
+0000374497 00000 n 
+0000373792 00000 n 
+0000371018 00000 n 
+0000373918 00000 n 
+0000374047 00000 n 
+0000374174 00000 n 
+0001031144 00000 n 
+0001018594 00000 n 
+0001030965 00000 n 
+0000374432 00000 n 
+0000379152 00000 n 
+0000378262 00000 n 
+0000374625 00000 n 
+0000379087 00000 n 
+0001018013 00000 n 
+0001006747 00000 n 
+0001017834 00000 n 
+0000378436 00000 n 
+0000378591 00000 n 
+0000378761 00000 n 
+0000378916 00000 n 
+0000530197 00000 n 
+0000702155 00000 n 
+0000382753 00000 n 
+0000382562 00000 n 
+0000379321 00000 n 
+0000382688 00000 n 
+0000387324 00000 n 
+0000386928 00000 n 
+0000382908 00000 n 
+0000387259 00000 n 
+0000387075 00000 n 
+0001170808 00000 n 
+0000494445 00000 n 
+0000391223 00000 n 
+0000390775 00000 n 
+0000387480 00000 n 
+0000390901 00000 n 
+0000391030 00000 n 
+0000391095 00000 n 
+0000391159 00000 n 
+0000392111 00000 n 
+0000391920 00000 n 
+0000391351 00000 n 
+0000392046 00000 n 
+0000394864 00000 n 
+0000397454 00000 n 
+0000394699 00000 n 
+0000392211 00000 n 
+0000397002 00000 n 
+0000397131 00000 n 
+0000397260 00000 n 
+0000396507 00000 n 
+0000396669 00000 n 
+0001005841 00000 n 
+0000995821 00000 n 
+0001005667 00000 n 
+0000995257 00000 n 
+0000986171 00000 n 
+0000995082 00000 n 
+0000397389 00000 n 
+0000396831 00000 n 
+0000396336 00000 n 
+0000396394 00000 n 
+0000396484 00000 n 
+0000547312 00000 n 
+0000587811 00000 n 
+0000402221 00000 n 
+0000401285 00000 n 
+0000397625 00000 n 
+0000401769 00000 n 
+0000401898 00000 n 
+0000402027 00000 n 
+0000401441 00000 n 
+0000401607 00000 n 
+0000402156 00000 n 
+0000775841 00000 n 
+0000406139 00000 n 
+0000405630 00000 n 
+0000402377 00000 n 
+0000405945 00000 n 
+0000406074 00000 n 
+0000405777 00000 n 
+0000407287 00000 n 
+0000407096 00000 n 
+0000406280 00000 n 
+0000407222 00000 n 
+0001170933 00000 n 
+0000409153 00000 n 
+0000408833 00000 n 
+0000407388 00000 n 
+0000408959 00000 n 
+0000409088 00000 n 
+0000412448 00000 n 
+0000411613 00000 n 
+0000409267 00000 n 
+0000411739 00000 n 
+0000411868 00000 n 
+0000411997 00000 n 
+0000412125 00000 n 
+0000412254 00000 n 
+0000412383 00000 n 
+0000416502 00000 n 
+0000415606 00000 n 
+0000412590 00000 n 
+0000415923 00000 n 
+0000416052 00000 n 
+0000416180 00000 n 
+0000415753 00000 n 
+0000416308 00000 n 
+0000416437 00000 n 
+0000420529 00000 n 
+0000419951 00000 n 
+0000416643 00000 n 
+0000420077 00000 n 
+0000420206 00000 n 
+0000420335 00000 n 
+0000420464 00000 n 
+0000424456 00000 n 
+0000424007 00000 n 
+0000420671 00000 n 
+0000424133 00000 n 
+0000424262 00000 n 
+0000424391 00000 n 
+0000426769 00000 n 
+0000426578 00000 n 
+0000424584 00000 n 
+0000426704 00000 n 
+0001171058 00000 n 
+0000430037 00000 n 
+0000429459 00000 n 
+0000426913 00000 n 
+0000429585 00000 n 
+0000985896 00000 n 
+0000982537 00000 n 
+0000985717 00000 n 
+0000429714 00000 n 
+0000429843 00000 n 
+0000429972 00000 n 
+0000434304 00000 n 
+0000433625 00000 n 
+0000430208 00000 n 
+0000434110 00000 n 
+0000434239 00000 n 
+0000982182 00000 n 
+0000980185 00000 n 
+0000982017 00000 n 
+0000433781 00000 n 
+0000433945 00000 n 
+0000857777 00000 n 
+0000870946 00000 n 
+0000437670 00000 n 
+0000436966 00000 n 
+0000434432 00000 n 
+0000437092 00000 n 
+0000437221 00000 n 
+0000437350 00000 n 
+0000437479 00000 n 
+0000437606 00000 n 
+0000441075 00000 n 
+0000440112 00000 n 
+0000437784 00000 n 
+0000440238 00000 n 
+0000440367 00000 n 
+0000440496 00000 n 
+0000440624 00000 n 
+0000440753 00000 n 
+0000440881 00000 n 
+0000441010 00000 n 
+0000445197 00000 n 
+0000444438 00000 n 
+0000441203 00000 n 
+0000444745 00000 n 
+0000444874 00000 n 
+0000445003 00000 n 
+0000444585 00000 n 
+0000445132 00000 n 
+0000657572 00000 n 
+0000448730 00000 n 
+0000448281 00000 n 
+0000445311 00000 n 
+0000448407 00000 n 
+0000448536 00000 n 
+0000448665 00000 n 
+0001171183 00000 n 
+0000451526 00000 n 
+0000451078 00000 n 
+0000448900 00000 n 
+0000451204 00000 n 
+0000451333 00000 n 
+0000451461 00000 n 
+0000454244 00000 n 
+0000453924 00000 n 
+0000451683 00000 n 
+0000454050 00000 n 
+0000454179 00000 n 
+0000457152 00000 n 
+0000456316 00000 n 
+0000454358 00000 n 
+0000456442 00000 n 
+0000456571 00000 n 
+0000456700 00000 n 
+0000456829 00000 n 
+0000456958 00000 n 
+0000457087 00000 n 
+0000459784 00000 n 
+0000459464 00000 n 
+0000457266 00000 n 
+0000459590 00000 n 
+0000459719 00000 n 
+0000465502 00000 n 
+0000462722 00000 n 
+0000462273 00000 n 
+0000459898 00000 n 
+0000462399 00000 n 
+0000462528 00000 n 
+0000462657 00000 n 
+0000467041 00000 n 
+0000465355 00000 n 
+0000462850 00000 n 
+0000466589 00000 n 
+0000466718 00000 n 
+0000466428 00000 n 
+0000466847 00000 n 
+0000466976 00000 n 
+0001171308 00000 n 
+0000771552 00000 n 
+0000469784 00000 n 
+0000469206 00000 n 
+0000467212 00000 n 
+0000469332 00000 n 
+0000469461 00000 n 
+0000469590 00000 n 
+0000469719 00000 n 
+0000470225 00000 n 
+0000470034 00000 n 
+0000469884 00000 n 
+0000470160 00000 n 
+0000474312 00000 n 
+0000473546 00000 n 
+0000470267 00000 n 
+0000473860 00000 n 
+0000473989 00000 n 
+0000474117 00000 n 
+0000474182 00000 n 
+0000474247 00000 n 
+0000473693 00000 n 
+0000478810 00000 n 
+0000479002 00000 n 
+0000478555 00000 n 
+0000474412 00000 n 
+0000478681 00000 n 
+0000478937 00000 n 
+0000482854 00000 n 
+0000482276 00000 n 
+0000479130 00000 n 
+0000482402 00000 n 
+0000482531 00000 n 
+0000482660 00000 n 
+0000482789 00000 n 
+0000485964 00000 n 
+0000485386 00000 n 
+0000482995 00000 n 
+0000485512 00000 n 
+0000485641 00000 n 
+0000485770 00000 n 
+0000485835 00000 n 
+0000485899 00000 n 
+0001171433 00000 n 
+0000489325 00000 n 
+0000488621 00000 n 
+0000486121 00000 n 
+0000488747 00000 n 
+0000488876 00000 n 
+0000489004 00000 n 
+0000489069 00000 n 
+0000489134 00000 n 
+0000489260 00000 n 
+0000494638 00000 n 
+0000493850 00000 n 
+0000489439 00000 n 
+0000494316 00000 n 
+0000494006 00000 n 
+0000494157 00000 n 
+0000494574 00000 n 
+0000961164 00000 n 
+0000498503 00000 n 
+0000497232 00000 n 
+0000494779 00000 n 
+0000497922 00000 n 
+0000498051 00000 n 
+0000498180 00000 n 
+0000498309 00000 n 
+0000497397 00000 n 
+0000497549 00000 n 
+0000497735 00000 n 
+0000498438 00000 n 
+0000502650 00000 n 
+0000502201 00000 n 
+0000498631 00000 n 
+0000502327 00000 n 
+0000502456 00000 n 
+0000502585 00000 n 
+0000506556 00000 n 
+0000506177 00000 n 
+0000502778 00000 n 
+0000506491 00000 n 
+0000506324 00000 n 
+0000509406 00000 n 
+0000509601 00000 n 
+0000509151 00000 n 
+0000506670 00000 n 
+0000509277 00000 n 
+0000509471 00000 n 
+0000509536 00000 n 
+0001171558 00000 n 
+0000512553 00000 n 
+0000512362 00000 n 
+0000509715 00000 n 
+0000512488 00000 n 
+0000516153 00000 n 
+0000515707 00000 n 
+0000512667 00000 n 
+0000515833 00000 n 
+0000515960 00000 n 
+0000516025 00000 n 
+0000516089 00000 n 
+0000519254 00000 n 
+0000518934 00000 n 
+0000516267 00000 n 
+0000519060 00000 n 
+0000519189 00000 n 
+0000522541 00000 n 
+0000521500 00000 n 
+0000519368 00000 n 
+0000521960 00000 n 
+0000522089 00000 n 
+0000521656 00000 n 
 0000521809 00000 n 
-0000521618 00000 n 
-0000520335 00000 n 
-0000521744 00000 n 
-0000523353 00000 n 
-0000523162 00000 n 
-0000521910 00000 n 
-0000523288 00000 n 
-0001168763 00000 n 
-0000525369 00000 n 
-0000525050 00000 n 
-0000523454 00000 n 
-0000525176 00000 n 
-0000528896 00000 n 
-0000528705 00000 n 
-0000525483 00000 n 
-0000528831 00000 n 
-0000533257 00000 n 
-0000532888 00000 n 
-0000529038 00000 n 
-0000533192 00000 n 
-0000533035 00000 n 
-0000736020 00000 n 
-0000537193 00000 n 
-0000536811 00000 n 
-0000533385 00000 n 
-0000537128 00000 n 
-0000536958 00000 n 
-0000541711 00000 n 
-0000541346 00000 n 
-0000537321 00000 n 
-0000541646 00000 n 
-0000541493 00000 n 
-0000545815 00000 n 
-0000545303 00000 n 
-0000541853 00000 n 
-0000545621 00000 n 
-0000545450 00000 n 
-0001168888 00000 n 
-0000549912 00000 n 
-0000549416 00000 n 
-0000545943 00000 n 
-0000549717 00000 n 
-0000549782 00000 n 
-0000549847 00000 n 
-0000549563 00000 n 
-0000555024 00000 n 
-0000553892 00000 n 
-0000550040 00000 n 
-0000554959 00000 n 
-0000554075 00000 n 
-0000554232 00000 n 
-0000554416 00000 n 
-0000554589 00000 n 
-0000554774 00000 n 
-0000647320 00000 n 
-0000559318 00000 n 
-0000559127 00000 n 
-0000555208 00000 n 
-0000559253 00000 n 
-0000563435 00000 n 
-0000563244 00000 n 
-0000559446 00000 n 
-0000563370 00000 n 
-0000567834 00000 n 
-0000567282 00000 n 
-0000563549 00000 n 
-0000567769 00000 n 
-0000567438 00000 n 
-0000567603 00000 n 
-0000572110 00000 n 
-0000571166 00000 n 
-0000567948 00000 n 
-0000571658 00000 n 
-0000571787 00000 n 
-0000571322 00000 n 
-0000571916 00000 n 
-0000572045 00000 n 
-0000571491 00000 n 
-0001169013 00000 n 
-0000661632 00000 n 
-0000575907 00000 n 
-0000575346 00000 n 
-0000572224 00000 n 
-0000575842 00000 n 
-0000575502 00000 n 
-0000575672 00000 n 
-0000756007 00000 n 
-0000579174 00000 n 
-0000578854 00000 n 
-0000576078 00000 n 
-0000578980 00000 n 
-0000579109 00000 n 
-0000582935 00000 n 
-0000582615 00000 n 
-0000579302 00000 n 
-0000582741 00000 n 
-0000582870 00000 n 
-0000585992 00000 n 
-0000585672 00000 n 
-0000583049 00000 n 
-0000585798 00000 n 
-0000590037 00000 n 
-0000589846 00000 n 
-0000586149 00000 n 
-0000589972 00000 n 
-0000593693 00000 n 
-0000593193 00000 n 
-0000590194 00000 n 
-0000593500 00000 n 
-0000593629 00000 n 
-0000593340 00000 n 
-0001169138 00000 n 
-0000598207 00000 n 
-0000597400 00000 n 
-0000593864 00000 n 
-0000597886 00000 n 
-0000598015 00000 n 
-0000597556 00000 n 
-0000598143 00000 n 
-0000597731 00000 n 
-0000602139 00000 n 
-0000601691 00000 n 
-0000598321 00000 n 
-0000601817 00000 n 
-0000601946 00000 n 
-0000602074 00000 n 
-0000606225 00000 n 
-0000605557 00000 n 
-0000602296 00000 n 
-0000606031 00000 n 
-0000606160 00000 n 
-0000605713 00000 n 
-0000605875 00000 n 
-0000609345 00000 n 
-0000608706 00000 n 
-0000606396 00000 n 
-0000609023 00000 n 
-0000608853 00000 n 
-0000609216 00000 n 
-0000609280 00000 n 
-0000613063 00000 n 
-0000612561 00000 n 
-0000609473 00000 n 
-0000612870 00000 n 
-0000612999 00000 n 
-0000612708 00000 n 
-0000617498 00000 n 
-0000617123 00000 n 
-0000613248 00000 n 
-0000617433 00000 n 
-0000617270 00000 n 
-0001169263 00000 n 
-0000732092 00000 n 
-0000621951 00000 n 
-0000621314 00000 n 
-0000617612 00000 n 
-0000621630 00000 n 
-0000621759 00000 n 
-0000621461 00000 n 
-0000621888 00000 n 
-0000659873 00000 n 
-0000624124 00000 n 
-0000623933 00000 n 
-0000622079 00000 n 
-0000624059 00000 n 
-0000627853 00000 n 
-0000627533 00000 n 
-0000624224 00000 n 
-0000627659 00000 n 
-0000632192 00000 n 
-0000631700 00000 n 
-0000628010 00000 n 
-0000631998 00000 n 
-0000632127 00000 n 
-0000631847 00000 n 
-0000636545 00000 n 
-0000636225 00000 n 
-0000632320 00000 n 
-0000636351 00000 n 
-0000636480 00000 n 
-0000640333 00000 n 
-0000640142 00000 n 
-0000636686 00000 n 
-0000640268 00000 n 
-0001169388 00000 n 
-0000642236 00000 n 
-0000641916 00000 n 
-0000640474 00000 n 
-0000642042 00000 n 
-0000642171 00000 n 
-0000647385 00000 n 
-0000646726 00000 n 
-0000642350 00000 n 
-0000647191 00000 n 
-0000646882 00000 n 
-0000647033 00000 n 
-0000651501 00000 n 
-0000650620 00000 n 
-0000647499 00000 n 
-0000650920 00000 n 
-0000651049 00000 n 
-0000651178 00000 n 
-0000651307 00000 n 
-0000651436 00000 n 
-0000650767 00000 n 
-0000655652 00000 n 
-0000655204 00000 n 
-0000651615 00000 n 
-0000655330 00000 n 
-0000655459 00000 n 
-0000660067 00000 n 
-0000659618 00000 n 
-0000655780 00000 n 
-0000659744 00000 n 
-0000660002 00000 n 
-0000661697 00000 n 
-0000661377 00000 n 
-0000660195 00000 n 
-0000661503 00000 n 
-0001169513 00000 n 
-0000663273 00000 n 
-0000663082 00000 n 
-0000661811 00000 n 
-0000663208 00000 n 
-0000664737 00000 n 
-0000664546 00000 n 
-0000663374 00000 n 
-0000664672 00000 n 
-0000666441 00000 n 
+0000522218 00000 n 
+0000522347 00000 n 
+0000522476 00000 n 
+0000524034 00000 n 
+0000523843 00000 n 
+0000522655 00000 n 
+0000523969 00000 n 
+0000525627 00000 n 
+0000525436 00000 n 
+0000524135 00000 n 
+0000525562 00000 n 
+0001171683 00000 n 
+0000527074 00000 n 
+0000526883 00000 n 
+0000525728 00000 n 
+0000527009 00000 n 
+0000530262 00000 n 
+0000529942 00000 n 
+0000527175 00000 n 
+0000530068 00000 n 
+0000534536 00000 n 
+0000534345 00000 n 
+0000530390 00000 n 
+0000534471 00000 n 
+0000539009 00000 n 
+0000538461 00000 n 
+0000534678 00000 n 
+0000538944 00000 n 
+0000538617 00000 n 
+0000538774 00000 n 
+0000738940 00000 n 
+0000543239 00000 n 
+0000542874 00000 n 
+0000539137 00000 n 
+0000543174 00000 n 
+0000543021 00000 n 
+0000547377 00000 n 
+0000546865 00000 n 
+0000543381 00000 n 
+0000547183 00000 n 
+0000547012 00000 n 
+0001171808 00000 n 
+0000551328 00000 n 
+0000551007 00000 n 
+0000547505 00000 n 
+0000551133 00000 n 
+0000551198 00000 n 
+0000551263 00000 n 
+0000556409 00000 n 
+0000555311 00000 n 
+0000551456 00000 n 
+0000556344 00000 n 
+0000555494 00000 n 
+0000555648 00000 n 
+0000555804 00000 n 
+0000555988 00000 n 
+0000556161 00000 n 
+0000648697 00000 n 
+0000560951 00000 n 
+0000560555 00000 n 
+0000556580 00000 n 
+0000560886 00000 n 
+0000560702 00000 n 
+0000565168 00000 n 
+0000564977 00000 n 
+0000561092 00000 n 
+0000565103 00000 n 
+0000568964 00000 n 
+0000568773 00000 n 
+0000565282 00000 n 
+0000568899 00000 n 
+0000573590 00000 n 
+0000572604 00000 n 
+0000569078 00000 n 
+0000573268 00000 n 
+0000572769 00000 n 
+0000572934 00000 n 
+0000573396 00000 n 
+0000573098 00000 n 
+0000573525 00000 n 
+0001171933 00000 n 
+0000664265 00000 n 
+0000576894 00000 n 
+0000576387 00000 n 
+0000573704 00000 n 
+0000576700 00000 n 
+0000576829 00000 n 
+0000576534 00000 n 
+0000581208 00000 n 
+0000580517 00000 n 
+0000577051 00000 n 
+0000581015 00000 n 
+0000580673 00000 n 
+0000580844 00000 n 
+0000581144 00000 n 
+0000758927 00000 n 
+0000584958 00000 n 
+0000584638 00000 n 
+0000581336 00000 n 
+0000584764 00000 n 
+0000584893 00000 n 
+0000587876 00000 n 
+0000587556 00000 n 
+0000585072 00000 n 
+0000587682 00000 n 
+0000591918 00000 n 
+0000591727 00000 n 
+0000588047 00000 n 
+0000591853 00000 n 
+0000595347 00000 n 
+0000594848 00000 n 
+0000592032 00000 n 
+0000595154 00000 n 
+0000595283 00000 n 
+0000594995 00000 n 
+0001172058 00000 n 
+0000599746 00000 n 
+0000598937 00000 n 
+0000595504 00000 n 
+0000599423 00000 n 
+0000599552 00000 n 
+0000599093 00000 n 
+0000599681 00000 n 
+0000599268 00000 n 
+0000603673 00000 n 
+0000603354 00000 n 
+0000599860 00000 n 
+0000603480 00000 n 
+0000603608 00000 n 
+0000607751 00000 n 
+0000606954 00000 n 
+0000603801 00000 n 
+0000607428 00000 n 
+0000607557 00000 n 
+0000607686 00000 n 
+0000607110 00000 n 
+0000607272 00000 n 
+0000610913 00000 n 
+0000610402 00000 n 
+0000607922 00000 n 
+0000610719 00000 n 
+0000610549 00000 n 
+0000614326 00000 n 
+0000613876 00000 n 
+0000611041 00000 n 
+0000614002 00000 n 
+0000614067 00000 n 
+0000614132 00000 n 
+0000614261 00000 n 
+0000618370 00000 n 
+0000617998 00000 n 
+0000614511 00000 n 
+0000618305 00000 n 
+0000618145 00000 n 
+0001172183 00000 n 
+0000623308 00000 n 
+0000622627 00000 n 
+0000618527 00000 n 
+0000623114 00000 n 
+0000622783 00000 n 
+0000623243 00000 n 
+0000622945 00000 n 
+0000735012 00000 n 
+0000661748 00000 n 
+0000626232 00000 n 
+0000625912 00000 n 
+0000623436 00000 n 
+0000626038 00000 n 
+0000626167 00000 n 
+0000629433 00000 n 
+0000629114 00000 n 
+0000626359 00000 n 
+0000629240 00000 n 
+0000633881 00000 n 
+0000633561 00000 n 
+0000629603 00000 n 
+0000633687 00000 n 
+0000633816 00000 n 
+0000638050 00000 n 
+0000637558 00000 n 
+0000633995 00000 n 
+0000637856 00000 n 
+0000637705 00000 n 
+0000637985 00000 n 
+0000642255 00000 n 
+0000642064 00000 n 
+0000638205 00000 n 
+0000642190 00000 n 
+0001172308 00000 n 
+0000644656 00000 n 
+0000644336 00000 n 
+0000642382 00000 n 
+0000644462 00000 n 
+0000644591 00000 n 
+0000648762 00000 n 
+0000648442 00000 n 
+0000644783 00000 n 
+0000648568 00000 n 
+0000653424 00000 n 
+0000652504 00000 n 
+0000648876 00000 n 
+0000652974 00000 n 
+0000652660 00000 n 
+0000652812 00000 n 
+0000653103 00000 n 
+0000653231 00000 n 
+0000653360 00000 n 
+0000657637 00000 n 
+0000656884 00000 n 
+0000653538 00000 n 
+0000657185 00000 n 
+0000657314 00000 n 
+0000657031 00000 n 
+0000657443 00000 n 
+0000661942 00000 n 
+0000661493 00000 n 
+0000657765 00000 n 
+0000661619 00000 n 
+0000661877 00000 n 
+0000664330 00000 n 
+0000664010 00000 n 
+0000662084 00000 n 
+0000664136 00000 n 
+0001172433 00000 n 
+0000665927 00000 n 
+0000665736 00000 n 
+0000664444 00000 n 
 0000665862 00000 n 
-0000664838 00000 n 
-0000665988 00000 n 
-0000666117 00000 n 
-0000666246 00000 n 
-0000666311 00000 n 
-0000666376 00000 n 
-0000669445 00000 n 
-0000669254 00000 n 
-0000666555 00000 n 
-0000669380 00000 n 
-0000673332 00000 n 
-0000672952 00000 n 
-0000669559 00000 n 
-0000673267 00000 n 
-0000673099 00000 n 
-0000958211 00000 n 
-0000679342 00000 n 
-0000676648 00000 n 
-0000673446 00000 n 
-0000679019 00000 n 
-0000679148 00000 n 
-0000679277 00000 n 
-0000676903 00000 n 
-0000677065 00000 n 
-0000677227 00000 n 
-0000677389 00000 n 
-0000677550 00000 n 
-0000677712 00000 n 
-0000677883 00000 n 
-0000678045 00000 n 
-0000678208 00000 n 
-0000678371 00000 n 
-0000678533 00000 n 
-0000678696 00000 n 
-0000678858 00000 n 
-0001169638 00000 n 
-0000684722 00000 n 
-0000682631 00000 n 
-0000679456 00000 n 
-0000684657 00000 n 
-0000682868 00000 n 
-0000683023 00000 n 
-0000683186 00000 n 
-0000683349 00000 n 
-0000683512 00000 n 
-0000683679 00000 n 
-0000683849 00000 n 
-0000684011 00000 n 
-0000684173 00000 n 
-0000684335 00000 n 
-0000684496 00000 n 
-0000688989 00000 n 
-0000687806 00000 n 
-0000684850 00000 n 
-0000688924 00000 n 
-0000687998 00000 n 
-0000688152 00000 n 
-0000688315 00000 n 
-0000688468 00000 n 
-0000688622 00000 n 
-0000688772 00000 n 
-0000694964 00000 n 
-0000692560 00000 n 
-0000689117 00000 n 
-0000694899 00000 n 
-0000692815 00000 n 
-0000692977 00000 n 
-0000693139 00000 n 
-0000693299 00000 n 
-0000693459 00000 n 
-0000693621 00000 n 
-0000693781 00000 n 
-0000693940 00000 n 
-0000694093 00000 n 
-0000694256 00000 n 
-0000694407 00000 n 
-0000694572 00000 n 
-0000694738 00000 n 
-0000699300 00000 n 
-0000698636 00000 n 
-0000695106 00000 n 
-0000699106 00000 n 
-0000698792 00000 n 
-0000698946 00000 n 
-0000702817 00000 n 
-0000702497 00000 n 
-0000699442 00000 n 
-0000702623 00000 n 
-0000702688 00000 n 
-0000702752 00000 n 
-0000706307 00000 n 
-0000705731 00000 n 
-0000702988 00000 n 
-0000705857 00000 n 
-0000705985 00000 n 
-0000706242 00000 n 
-0001169763 00000 n 
-0000710562 00000 n 
-0000709749 00000 n 
-0000706478 00000 n 
-0000710237 00000 n 
-0000709905 00000 n 
-0000710075 00000 n 
-0000710302 00000 n 
-0000710367 00000 n 
-0000710432 00000 n 
-0000710497 00000 n 
-0000713831 00000 n 
-0000713510 00000 n 
-0000710663 00000 n 
-0000713636 00000 n 
-0000713701 00000 n 
-0000713766 00000 n 
-0000717744 00000 n 
-0000717165 00000 n 
-0000713946 00000 n 
-0000717291 00000 n 
-0000717420 00000 n 
-0000717485 00000 n 
-0000717550 00000 n 
-0000717614 00000 n 
-0000717679 00000 n 
-0000721590 00000 n 
-0000720881 00000 n 
-0000717858 00000 n 
-0000721007 00000 n 
-0000721136 00000 n 
-0000721201 00000 n 
-0000721266 00000 n 
-0000721395 00000 n 
-0000721460 00000 n 
-0000721525 00000 n 
-0000725122 00000 n 
-0000724285 00000 n 
-0000721718 00000 n 
-0000724411 00000 n 
-0000724540 00000 n 
-0000724605 00000 n 
-0000724670 00000 n 
-0000724799 00000 n 
-0000724928 00000 n 
-0000725057 00000 n 
-0000728107 00000 n 
-0000727530 00000 n 
-0000725335 00000 n 
-0000727656 00000 n 
-0000727785 00000 n 
-0000727914 00000 n 
-0000728043 00000 n 
-0001169888 00000 n 
-0000732156 00000 n 
-0000731707 00000 n 
-0000728292 00000 n 
-0000731833 00000 n 
-0000731898 00000 n 
-0000731963 00000 n 
-0000736085 00000 n 
-0000735325 00000 n 
-0000732283 00000 n 
-0000735632 00000 n 
-0000735761 00000 n 
-0000735826 00000 n 
-0000735891 00000 n 
-0000735472 00000 n 
-0000739699 00000 n 
-0000739120 00000 n 
-0000736213 00000 n 
-0000739246 00000 n 
-0000739375 00000 n 
-0000739504 00000 n 
-0000739569 00000 n 
-0000739634 00000 n 
-0000743304 00000 n 
-0000742476 00000 n 
-0000739813 00000 n 
-0000742788 00000 n 
-0000742623 00000 n 
-0000742917 00000 n 
-0000742982 00000 n 
-0000743047 00000 n 
-0000743176 00000 n 
-0000743240 00000 n 
-0000958178 00000 n 
-0000747457 00000 n 
-0000746942 00000 n 
-0000743418 00000 n 
-0000747068 00000 n 
-0000747133 00000 n 
-0000747262 00000 n 
-0000747327 00000 n 
-0000747392 00000 n 
-0000749738 00000 n 
-0000749418 00000 n 
-0000747585 00000 n 
-0000749544 00000 n 
-0000976984 00000 n 
-0000969700 00000 n 
-0000976804 00000 n 
-0000749673 00000 n 
-0001170013 00000 n 
-0000751650 00000 n 
-0000751203 00000 n 
-0000749880 00000 n 
-0000751329 00000 n 
-0000751458 00000 n 
-0000751585 00000 n 
-0000756072 00000 n 
-0000755129 00000 n 
-0000751764 00000 n 
-0000755492 00000 n 
-0000969379 00000 n 
-0000960166 00000 n 
-0000969193 00000 n 
-0000755276 00000 n 
-0000755621 00000 n 
-0000755749 00000 n 
-0000755878 00000 n 
-0000757431 00000 n 
-0000757240 00000 n 
-0000756313 00000 n 
-0000757366 00000 n 
-0000757872 00000 n 
-0000757681 00000 n 
-0000757531 00000 n 
-0000757807 00000 n 
-0000761186 00000 n 
-0000759960 00000 n 
-0000757914 00000 n 
-0000760477 00000 n 
-0000760606 00000 n 
-0000760735 00000 n 
-0000760864 00000 n 
-0000760993 00000 n 
-0000761122 00000 n 
-0000760116 00000 n 
-0000760288 00000 n 
-0000761641 00000 n 
-0000761450 00000 n 
-0000761300 00000 n 
-0000761576 00000 n 
-0001170138 00000 n 
-0000764886 00000 n 
-0000764308 00000 n 
-0000761683 00000 n 
-0000764434 00000 n 
-0000764563 00000 n 
-0000764692 00000 n 
-0000764821 00000 n 
-0000769083 00000 n 
-0000767864 00000 n 
-0000764972 00000 n 
-0000768374 00000 n 
-0000768503 00000 n 
-0000768761 00000 n 
-0000768020 00000 n 
-0000768199 00000 n 
-0000768955 00000 n 
-0000769019 00000 n 
-0000775973 00000 n 
-0000772145 00000 n 
-0000769239 00000 n 
-0000772271 00000 n 
-0000772336 00000 n 
-0000772401 00000 n 
-0000772466 00000 n 
-0000772531 00000 n 
-0000772596 00000 n 
-0000772661 00000 n 
-0000772726 00000 n 
-0000772791 00000 n 
-0000772856 00000 n 
-0000772986 00000 n 
-0000773051 00000 n 
-0000773116 00000 n 
-0000773181 00000 n 
-0000773246 00000 n 
-0000773311 00000 n 
-0000773376 00000 n 
-0000773441 00000 n 
-0000773506 00000 n 
-0000773571 00000 n 
-0000773636 00000 n 
-0000773701 00000 n 
-0000773766 00000 n 
-0000773831 00000 n 
-0000773896 00000 n 
-0000773961 00000 n 
-0000774026 00000 n 
-0000774091 00000 n 
-0000774156 00000 n 
-0000774221 00000 n 
-0000774286 00000 n 
-0000774351 00000 n 
-0000774416 00000 n 
-0000774481 00000 n 
-0000774545 00000 n 
-0000774610 00000 n 
-0000774675 00000 n 
-0000774740 00000 n 
-0000774805 00000 n 
-0000774870 00000 n 
-0000774935 00000 n 
-0000775000 00000 n 
+0000667424 00000 n 
+0000667233 00000 n 
+0000666028 00000 n 
+0000667359 00000 n 
+0000669361 00000 n 
+0000668783 00000 n 
+0000667525 00000 n 
+0000668909 00000 n 
+0000669037 00000 n 
+0000669166 00000 n 
+0000669231 00000 n 
+0000669296 00000 n 
+0000672365 00000 n 
+0000672174 00000 n 
+0000669475 00000 n 
+0000672300 00000 n 
+0000676252 00000 n 
+0000675872 00000 n 
+0000672479 00000 n 
+0000676187 00000 n 
+0000676019 00000 n 
+0000961131 00000 n 
+0000682262 00000 n 
+0000679568 00000 n 
+0000676366 00000 n 
+0000681939 00000 n 
+0000682068 00000 n 
+0000682197 00000 n 
+0000679823 00000 n 
+0000679985 00000 n 
+0000680147 00000 n 
+0000680309 00000 n 
+0000680470 00000 n 
+0000680632 00000 n 
+0000680803 00000 n 
+0000680965 00000 n 
+0000681128 00000 n 
+0000681291 00000 n 
+0000681453 00000 n 
+0000681616 00000 n 
+0000681778 00000 n 
+0001172558 00000 n 
+0000687642 00000 n 
+0000685551 00000 n 
+0000682376 00000 n 
+0000687577 00000 n 
+0000685788 00000 n 
+0000685943 00000 n 
+0000686106 00000 n 
+0000686269 00000 n 
+0000686432 00000 n 
+0000686599 00000 n 
+0000686769 00000 n 
+0000686931 00000 n 
+0000687093 00000 n 
+0000687255 00000 n 
+0000687416 00000 n 
+0000691909 00000 n 
+0000690726 00000 n 
+0000687770 00000 n 
+0000691844 00000 n 
+0000690918 00000 n 
+0000691072 00000 n 
+0000691235 00000 n 
+0000691388 00000 n 
+0000691542 00000 n 
+0000691692 00000 n 
+0000697884 00000 n 
+0000695480 00000 n 
+0000692037 00000 n 
+0000697819 00000 n 
+0000695735 00000 n 
+0000695897 00000 n 
+0000696059 00000 n 
+0000696219 00000 n 
+0000696379 00000 n 
+0000696541 00000 n 
+0000696701 00000 n 
+0000696860 00000 n 
+0000697013 00000 n 
+0000697176 00000 n 
+0000697327 00000 n 
+0000697492 00000 n 
+0000697658 00000 n 
+0000702220 00000 n 
+0000701556 00000 n 
+0000698026 00000 n 
+0000702026 00000 n 
+0000701712 00000 n 
+0000701866 00000 n 
+0000705737 00000 n 
+0000705417 00000 n 
+0000702362 00000 n 
+0000705543 00000 n 
+0000705608 00000 n 
+0000705672 00000 n 
+0000709227 00000 n 
+0000708651 00000 n 
+0000705908 00000 n 
+0000708777 00000 n 
+0000708905 00000 n 
+0000709162 00000 n 
+0001172683 00000 n 
+0000713482 00000 n 
+0000712669 00000 n 
+0000709398 00000 n 
+0000713157 00000 n 
+0000712825 00000 n 
+0000712995 00000 n 
+0000713222 00000 n 
+0000713287 00000 n 
+0000713352 00000 n 
+0000713417 00000 n 
+0000716751 00000 n 
+0000716430 00000 n 
+0000713583 00000 n 
+0000716556 00000 n 
+0000716621 00000 n 
+0000716686 00000 n 
+0000720664 00000 n 
+0000720085 00000 n 
+0000716866 00000 n 
+0000720211 00000 n 
+0000720340 00000 n 
+0000720405 00000 n 
+0000720470 00000 n 
+0000720534 00000 n 
+0000720599 00000 n 
+0000724510 00000 n 
+0000723801 00000 n 
+0000720778 00000 n 
+0000723927 00000 n 
+0000724056 00000 n 
+0000724121 00000 n 
+0000724186 00000 n 
+0000724315 00000 n 
+0000724380 00000 n 
+0000724445 00000 n 
+0000728042 00000 n 
+0000727205 00000 n 
+0000724638 00000 n 
+0000727331 00000 n 
+0000727460 00000 n 
+0000727525 00000 n 
+0000727590 00000 n 
+0000727719 00000 n 
+0000727848 00000 n 
+0000727977 00000 n 
+0000731027 00000 n 
+0000730450 00000 n 
+0000728255 00000 n 
+0000730576 00000 n 
+0000730705 00000 n 
+0000730834 00000 n 
+0000730963 00000 n 
+0001172808 00000 n 
+0000735076 00000 n 
+0000734627 00000 n 
+0000731212 00000 n 
+0000734753 00000 n 
+0000734818 00000 n 
+0000734883 00000 n 
+0000739005 00000 n 
+0000738245 00000 n 
+0000735203 00000 n 
+0000738552 00000 n 
+0000738681 00000 n 
+0000738746 00000 n 
+0000738811 00000 n 
+0000738392 00000 n 
+0000742619 00000 n 
+0000742040 00000 n 
+0000739133 00000 n 
+0000742166 00000 n 
+0000742295 00000 n 
+0000742424 00000 n 
+0000742489 00000 n 
+0000742554 00000 n 
+0000746224 00000 n 
+0000745396 00000 n 
+0000742733 00000 n 
+0000745708 00000 n 
+0000745543 00000 n 
+0000745837 00000 n 
+0000745902 00000 n 
+0000745967 00000 n 
+0000746096 00000 n 
+0000746160 00000 n 
+0000961098 00000 n 
+0000750377 00000 n 
+0000749862 00000 n 
+0000746338 00000 n 
+0000749988 00000 n 
+0000750053 00000 n 
+0000750182 00000 n 
+0000750247 00000 n 
+0000750312 00000 n 
+0000752658 00000 n 
+0000752338 00000 n 
+0000750505 00000 n 
+0000752464 00000 n 
+0000979904 00000 n 
+0000972620 00000 n 
+0000979724 00000 n 
+0000752593 00000 n 
+0001172933 00000 n 
+0000754570 00000 n 
+0000754123 00000 n 
+0000752800 00000 n 
+0000754249 00000 n 
+0000754378 00000 n 
+0000754505 00000 n 
+0000758992 00000 n 
+0000758049 00000 n 
+0000754684 00000 n 
+0000758412 00000 n 
+0000972299 00000 n 
+0000963086 00000 n 
+0000972113 00000 n 
+0000758196 00000 n 
+0000758541 00000 n 
+0000758669 00000 n 
+0000758798 00000 n 
+0000760351 00000 n 
+0000760160 00000 n 
+0000759233 00000 n 
+0000760286 00000 n 
+0000760792 00000 n 
+0000760601 00000 n 
+0000760451 00000 n 
+0000760727 00000 n 
+0000764106 00000 n 
+0000762880 00000 n 
+0000760834 00000 n 
+0000763397 00000 n 
+0000763526 00000 n 
+0000763655 00000 n 
+0000763784 00000 n 
+0000763913 00000 n 
+0000764042 00000 n 
+0000763036 00000 n 
+0000763208 00000 n 
+0000764561 00000 n 
+0000764370 00000 n 
+0000764220 00000 n 
+0000764496 00000 n 
+0001173058 00000 n 
+0000767806 00000 n 
+0000767228 00000 n 
+0000764603 00000 n 
+0000767354 00000 n 
+0000767483 00000 n 
+0000767612 00000 n 
+0000767741 00000 n 
+0000772003 00000 n 
+0000770784 00000 n 
+0000767892 00000 n 
+0000771294 00000 n 
+0000771423 00000 n 
+0000771681 00000 n 
+0000770940 00000 n 
+0000771119 00000 n 
+0000771875 00000 n 
+0000771939 00000 n 
+0000778893 00000 n 
 0000775065 00000 n 
-0000775130 00000 n 
-0000775195 00000 n 
-0000775260 00000 n 
-0000775325 00000 n 
-0000775390 00000 n 
-0000775455 00000 n 
-0000775520 00000 n 
-0000775585 00000 n 
-0000775650 00000 n 
-0000775715 00000 n 
-0000775780 00000 n 
-0000775845 00000 n 
-0000775909 00000 n 
-0000782621 00000 n 
-0000779057 00000 n 
-0000776087 00000 n 
-0000779183 00000 n 
-0000779248 00000 n 
-0000779313 00000 n 
-0000779378 00000 n 
-0000779443 00000 n 
-0000779508 00000 n 
-0000779573 00000 n 
-0000779638 00000 n 
-0000779703 00000 n 
-0000779768 00000 n 
-0000779833 00000 n 
-0000779898 00000 n 
-0000779962 00000 n 
-0000780027 00000 n 
-0000780092 00000 n 
-0000780157 00000 n 
-0000780222 00000 n 
-0000780287 00000 n 
-0000780352 00000 n 
-0000780417 00000 n 
-0000780482 00000 n 
-0000780547 00000 n 
-0000780612 00000 n 
-0000780677 00000 n 
-0000780741 00000 n 
-0000780806 00000 n 
-0000780871 00000 n 
-0000780936 00000 n 
-0000781001 00000 n 
-0000781066 00000 n 
-0000781131 00000 n 
-0000781196 00000 n 
-0000781261 00000 n 
-0000781326 00000 n 
-0000781391 00000 n 
-0000781456 00000 n 
-0000781521 00000 n 
-0000781586 00000 n 
-0000781651 00000 n 
-0000781716 00000 n 
-0000781780 00000 n 
-0000781844 00000 n 
-0000781908 00000 n 
-0000781973 00000 n 
-0000782038 00000 n 
+0000772159 00000 n 
+0000775191 00000 n 
+0000775256 00000 n 
+0000775321 00000 n 
+0000775386 00000 n 
+0000775451 00000 n 
+0000775516 00000 n 
+0000775581 00000 n 
+0000775646 00000 n 
+0000775711 00000 n 
+0000775776 00000 n 
+0000775906 00000 n 
+0000775971 00000 n 
+0000776036 00000 n 
+0000776101 00000 n 
+0000776166 00000 n 
+0000776231 00000 n 
+0000776296 00000 n 
+0000776361 00000 n 
+0000776426 00000 n 
+0000776491 00000 n 
+0000776556 00000 n 
+0000776621 00000 n 
+0000776686 00000 n 
+0000776751 00000 n 
+0000776816 00000 n 
+0000776881 00000 n 
+0000776946 00000 n 
+0000777011 00000 n 
+0000777076 00000 n 
+0000777141 00000 n 
+0000777206 00000 n 
+0000777271 00000 n 
+0000777336 00000 n 
+0000777401 00000 n 
+0000777465 00000 n 
+0000777530 00000 n 
+0000777595 00000 n 
+0000777660 00000 n 
+0000777725 00000 n 
+0000777790 00000 n 
+0000777855 00000 n 
+0000777920 00000 n 
+0000777985 00000 n 
+0000778050 00000 n 
+0000778115 00000 n 
+0000778180 00000 n 
+0000778245 00000 n 
+0000778310 00000 n 
+0000778375 00000 n 
+0000778440 00000 n 
+0000778505 00000 n 
+0000778570 00000 n 
+0000778635 00000 n 
+0000778700 00000 n 
+0000778765 00000 n 
+0000778829 00000 n 
+0000785541 00000 n 
+0000781977 00000 n 
+0000779007 00000 n 
 0000782103 00000 n 
 0000782168 00000 n 
 0000782233 00000 n 
@@ -18674,531 +18711,576 @@ xref
 0000782363 00000 n 
 0000782428 00000 n 
 0000782493 00000 n 
-0000782557 00000 n 
-0000788796 00000 n 
-0000785358 00000 n 
-0000782735 00000 n 
-0000785484 00000 n 
-0000785549 00000 n 
-0000785614 00000 n 
-0000785679 00000 n 
-0000785744 00000 n 
-0000785809 00000 n 
-0000785874 00000 n 
-0000785939 00000 n 
-0000786004 00000 n 
-0000786069 00000 n 
-0000786134 00000 n 
-0000786199 00000 n 
-0000786264 00000 n 
-0000786329 00000 n 
-0000786394 00000 n 
-0000786459 00000 n 
-0000786524 00000 n 
-0000786589 00000 n 
-0000786654 00000 n 
-0000786719 00000 n 
-0000786784 00000 n 
-0000786849 00000 n 
-0000786914 00000 n 
-0000786979 00000 n 
-0000787044 00000 n 
-0000787109 00000 n 
-0000787174 00000 n 
-0000787239 00000 n 
-0000787304 00000 n 
-0000787369 00000 n 
-0000787434 00000 n 
-0000787499 00000 n 
-0000787564 00000 n 
-0000787629 00000 n 
-0000787693 00000 n 
-0000787758 00000 n 
-0000787823 00000 n 
-0000787888 00000 n 
-0000787953 00000 n 
-0000788018 00000 n 
-0000788083 00000 n 
-0000788148 00000 n 
-0000788213 00000 n 
+0000782558 00000 n 
+0000782623 00000 n 
+0000782688 00000 n 
+0000782753 00000 n 
+0000782818 00000 n 
+0000782882 00000 n 
+0000782947 00000 n 
+0000783012 00000 n 
+0000783077 00000 n 
+0000783142 00000 n 
+0000783207 00000 n 
+0000783272 00000 n 
+0000783337 00000 n 
+0000783402 00000 n 
+0000783467 00000 n 
+0000783532 00000 n 
+0000783597 00000 n 
+0000783661 00000 n 
+0000783726 00000 n 
+0000783791 00000 n 
+0000783856 00000 n 
+0000783921 00000 n 
+0000783986 00000 n 
+0000784051 00000 n 
+0000784116 00000 n 
+0000784181 00000 n 
+0000784246 00000 n 
+0000784311 00000 n 
+0000784376 00000 n 
+0000784441 00000 n 
+0000784506 00000 n 
+0000784571 00000 n 
+0000784636 00000 n 
+0000784700 00000 n 
+0000784764 00000 n 
+0000784828 00000 n 
+0000784893 00000 n 
+0000784958 00000 n 
+0000785023 00000 n 
+0000785088 00000 n 
+0000785153 00000 n 
+0000785218 00000 n 
+0000785283 00000 n 
+0000785348 00000 n 
+0000785413 00000 n 
+0000785477 00000 n 
+0000791716 00000 n 
 0000788278 00000 n 
-0000788343 00000 n 
-0000788408 00000 n 
-0000788473 00000 n 
-0000788538 00000 n 
-0000788603 00000 n 
-0000788668 00000 n 
-0000788732 00000 n 
-0000794315 00000 n 
-0000791919 00000 n 
-0000788910 00000 n 
-0000792045 00000 n 
-0000792110 00000 n 
-0000792175 00000 n 
-0000792240 00000 n 
-0000792305 00000 n 
-0000792370 00000 n 
-0000792435 00000 n 
-0000792500 00000 n 
-0000792565 00000 n 
-0000792630 00000 n 
-0000792695 00000 n 
-0000792760 00000 n 
-0000792825 00000 n 
-0000792889 00000 n 
-0000792954 00000 n 
-0000793019 00000 n 
-0000793084 00000 n 
-0000793149 00000 n 
-0000793214 00000 n 
-0000793279 00000 n 
-0000793344 00000 n 
-0000793409 00000 n 
-0000793474 00000 n 
-0000793539 00000 n 
-0000793604 00000 n 
-0000793732 00000 n 
-0000793861 00000 n 
-0000793926 00000 n 
-0000793991 00000 n 
-0000794056 00000 n 
-0000794121 00000 n 
-0000794250 00000 n 
-0001170263 00000 n 
-0000797523 00000 n 
-0000796816 00000 n 
-0000794442 00000 n 
-0000796942 00000 n 
-0000797071 00000 n 
-0000797200 00000 n 
-0000797329 00000 n 
-0000797458 00000 n 
-0000801015 00000 n 
-0000800258 00000 n 
-0000797650 00000 n 
-0000800565 00000 n 
-0000800694 00000 n 
-0000800405 00000 n 
-0000800822 00000 n 
-0000800950 00000 n 
-0000804259 00000 n 
-0000803681 00000 n 
-0000801142 00000 n 
-0000803807 00000 n 
-0000803936 00000 n 
-0000804065 00000 n 
-0000804194 00000 n 
-0000807168 00000 n 
-0000806848 00000 n 
-0000804373 00000 n 
-0000806974 00000 n 
-0000807103 00000 n 
-0000809758 00000 n 
-0000809309 00000 n 
-0000807338 00000 n 
-0000809435 00000 n 
-0000809564 00000 n 
-0000809693 00000 n 
-0000810199 00000 n 
-0000810008 00000 n 
-0000809858 00000 n 
-0000810134 00000 n 
-0001170388 00000 n 
-0000812911 00000 n 
-0000812267 00000 n 
-0000810241 00000 n 
-0000812393 00000 n 
-0000812522 00000 n 
-0000812651 00000 n 
-0000812716 00000 n 
-0000812781 00000 n 
-0000812846 00000 n 
-0000817251 00000 n 
-0000816931 00000 n 
-0000813025 00000 n 
-0000817057 00000 n 
-0000817122 00000 n 
-0000817187 00000 n 
-0000820868 00000 n 
-0000820613 00000 n 
-0000817407 00000 n 
-0000820739 00000 n 
-0000820804 00000 n 
-0000824155 00000 n 
-0000823964 00000 n 
-0000821010 00000 n 
-0000824090 00000 n 
-0000827759 00000 n 
-0000827568 00000 n 
-0000824283 00000 n 
-0000827694 00000 n 
-0000830849 00000 n 
-0000830334 00000 n 
-0000827901 00000 n 
-0000830460 00000 n 
-0000830525 00000 n 
-0000830590 00000 n 
-0000830655 00000 n 
-0000830720 00000 n 
-0000830785 00000 n 
-0001170513 00000 n 
-0000835048 00000 n 
-0000834533 00000 n 
-0000831005 00000 n 
-0000834659 00000 n 
-0000834788 00000 n 
-0000834853 00000 n 
-0000834918 00000 n 
-0000834983 00000 n 
-0000838737 00000 n 
-0000838029 00000 n 
-0000835176 00000 n 
-0000838155 00000 n 
-0000838220 00000 n 
-0000838285 00000 n 
-0000838350 00000 n 
-0000838479 00000 n 
-0000838543 00000 n 
-0000838608 00000 n 
-0000838673 00000 n 
-0000841827 00000 n 
-0000841441 00000 n 
-0000838879 00000 n 
-0000841567 00000 n 
-0000841632 00000 n 
-0000841697 00000 n 
-0000841762 00000 n 
-0000844869 00000 n 
-0000844095 00000 n 
-0000841969 00000 n 
-0000844221 00000 n 
-0000844286 00000 n 
-0000844351 00000 n 
-0000844416 00000 n 
-0000844545 00000 n 
-0000844609 00000 n 
-0000844674 00000 n 
-0000844739 00000 n 
-0000844804 00000 n 
-0000848365 00000 n 
-0000848174 00000 n 
-0000845025 00000 n 
-0000848300 00000 n 
-0000851648 00000 n 
-0000851198 00000 n 
-0000848493 00000 n 
-0000851324 00000 n 
-0000851389 00000 n 
-0000851454 00000 n 
-0000851519 00000 n 
-0000851584 00000 n 
-0001170638 00000 n 
-0000855180 00000 n 
-0000854602 00000 n 
-0000851803 00000 n 
-0000854728 00000 n 
-0000854922 00000 n 
-0000854986 00000 n 
-0000855050 00000 n 
-0000855115 00000 n 
-0000858835 00000 n 
-0000858644 00000 n 
-0000855322 00000 n 
-0000858770 00000 n 
-0000862340 00000 n 
-0000862084 00000 n 
-0000858963 00000 n 
-0000862210 00000 n 
-0000862275 00000 n 
-0000865398 00000 n 
-0000864948 00000 n 
-0000862468 00000 n 
-0000865074 00000 n 
-0000865139 00000 n 
-0000865204 00000 n 
-0000865269 00000 n 
-0000865334 00000 n 
-0000868155 00000 n 
-0000867252 00000 n 
-0000865567 00000 n 
-0000867378 00000 n 
-0000867507 00000 n 
-0000867572 00000 n 
-0000867637 00000 n 
-0000867702 00000 n 
-0000867767 00000 n 
-0000867832 00000 n 
-0000867897 00000 n 
-0000868091 00000 n 
-0000871850 00000 n 
-0000871400 00000 n 
-0000868311 00000 n 
-0000871526 00000 n 
-0000871591 00000 n 
-0000871656 00000 n 
-0000871721 00000 n 
-0000871785 00000 n 
-0001170763 00000 n 
-0000875133 00000 n 
-0000874748 00000 n 
-0000871992 00000 n 
-0000874874 00000 n 
-0000874939 00000 n 
-0000875004 00000 n 
-0000875069 00000 n 
-0000878496 00000 n 
-0000877916 00000 n 
-0000875275 00000 n 
-0000878042 00000 n 
-0000878171 00000 n 
-0000878236 00000 n 
-0000878301 00000 n 
-0000878366 00000 n 
-0000878431 00000 n 
-0000882512 00000 n 
-0000882321 00000 n 
-0000878638 00000 n 
-0000882447 00000 n 
-0000886353 00000 n 
-0000886162 00000 n 
-0000882640 00000 n 
-0000886288 00000 n 
-0000889723 00000 n 
-0000889532 00000 n 
-0000886481 00000 n 
-0000889658 00000 n 
-0000892305 00000 n 
-0000891661 00000 n 
-0000889865 00000 n 
-0000891787 00000 n 
-0000891852 00000 n 
-0000891917 00000 n 
-0000891982 00000 n 
-0000892111 00000 n 
-0000892176 00000 n 
-0000892241 00000 n 
-0001170888 00000 n 
-0000895220 00000 n 
-0000894515 00000 n 
-0000892461 00000 n 
-0000894641 00000 n 
-0000894706 00000 n 
-0000894771 00000 n 
-0000894836 00000 n 
-0000894901 00000 n 
-0000894966 00000 n 
-0000895092 00000 n 
-0000895157 00000 n 
-0000898433 00000 n 
-0000898048 00000 n 
-0000895362 00000 n 
-0000898174 00000 n 
-0000898239 00000 n 
-0000898304 00000 n 
-0000898369 00000 n 
-0000902133 00000 n 
-0000901942 00000 n 
-0000898575 00000 n 
-0000902068 00000 n 
-0000905017 00000 n 
-0000904242 00000 n 
-0000902261 00000 n 
-0000904368 00000 n 
-0000904433 00000 n 
-0000904498 00000 n 
-0000904563 00000 n 
-0000904692 00000 n 
-0000904757 00000 n 
-0000904822 00000 n 
-0000904887 00000 n 
-0000904952 00000 n 
-0000908371 00000 n 
-0000908180 00000 n 
-0000905173 00000 n 
-0000908306 00000 n 
-0000911440 00000 n 
-0000911184 00000 n 
-0000908584 00000 n 
-0000911310 00000 n 
-0000911375 00000 n 
-0001171013 00000 n 
-0000914419 00000 n 
-0000913645 00000 n 
-0000911653 00000 n 
-0000913771 00000 n 
-0000913836 00000 n 
-0000913901 00000 n 
-0000913965 00000 n 
-0000914030 00000 n 
-0000914159 00000 n 
-0000914224 00000 n 
-0000914289 00000 n 
-0000914354 00000 n 
-0000918004 00000 n 
-0000917359 00000 n 
-0000914575 00000 n 
-0000917485 00000 n 
-0000917550 00000 n 
-0000917615 00000 n 
-0000917744 00000 n 
-0000917809 00000 n 
-0000917874 00000 n 
-0000917939 00000 n 
-0000922445 00000 n 
-0000922190 00000 n 
-0000918146 00000 n 
-0000922316 00000 n 
-0000922381 00000 n 
-0000926079 00000 n 
-0000925888 00000 n 
-0000922573 00000 n 
-0000926014 00000 n 
-0000928655 00000 n 
-0000928335 00000 n 
-0000926207 00000 n 
-0000928461 00000 n 
-0000928526 00000 n 
-0000928591 00000 n 
-0000932145 00000 n 
-0000931435 00000 n 
-0000928796 00000 n 
-0000931561 00000 n 
-0000931626 00000 n 
-0000931691 00000 n 
-0000931820 00000 n 
-0000931885 00000 n 
-0000931950 00000 n 
-0000932015 00000 n 
-0000932080 00000 n 
-0001171138 00000 n 
-0000935288 00000 n 
-0000934579 00000 n 
-0000932301 00000 n 
-0000934705 00000 n 
-0000934770 00000 n 
-0000934835 00000 n 
-0000934899 00000 n 
-0000935028 00000 n 
-0000935093 00000 n 
-0000935158 00000 n 
-0000935223 00000 n 
-0000938479 00000 n 
-0000938223 00000 n 
-0000935458 00000 n 
-0000938349 00000 n 
-0000938414 00000 n 
-0000941236 00000 n 
-0000940593 00000 n 
-0000938607 00000 n 
-0000940719 00000 n 
-0000940784 00000 n 
-0000940849 00000 n 
-0000940914 00000 n 
-0000941042 00000 n 
-0000941107 00000 n 
-0000941172 00000 n 
-0000944968 00000 n 
-0000944648 00000 n 
-0000941392 00000 n 
-0000944774 00000 n 
-0000944839 00000 n 
-0000944904 00000 n 
-0000948025 00000 n 
-0000947253 00000 n 
-0000945096 00000 n 
-0000947379 00000 n 
-0000947444 00000 n 
-0000947509 00000 n 
-0000947574 00000 n 
-0000947703 00000 n 
-0000947768 00000 n 
-0000947833 00000 n 
-0000947896 00000 n 
-0000947961 00000 n 
-0000951257 00000 n 
-0000950548 00000 n 
-0000948195 00000 n 
-0000950674 00000 n 
-0000950739 00000 n 
-0000950804 00000 n 
-0000950933 00000 n 
-0000950998 00000 n 
-0000951063 00000 n 
-0000951128 00000 n 
-0000951193 00000 n 
-0001171263 00000 n 
-0000953716 00000 n 
-0000952687 00000 n 
-0000951413 00000 n 
-0000952813 00000 n 
-0000952878 00000 n 
-0000953004 00000 n 
-0000953069 00000 n 
-0000953134 00000 n 
-0000953199 00000 n 
-0000953263 00000 n 
-0000953328 00000 n 
-0000953393 00000 n 
-0000953522 00000 n 
-0000953587 00000 n 
-0000953652 00000 n 
-0000956710 00000 n 
-0000955873 00000 n 
-0000953858 00000 n 
-0000955999 00000 n 
-0000956064 00000 n 
-0000956129 00000 n 
-0000956193 00000 n 
-0000956258 00000 n 
-0000956387 00000 n 
-0000956452 00000 n 
-0000956517 00000 n 
-0000956581 00000 n 
-0000956646 00000 n 
-0000958064 00000 n 
-0000957744 00000 n 
-0000956852 00000 n 
-0000957870 00000 n 
-0000957935 00000 n 
-0000957999 00000 n 
-0000958277 00000 n 
-0000969621 00000 n 
-0000977210 00000 n 
-0000979509 00000 n 
-0000979478 00000 n 
-0000983197 00000 n 
-0000992638 00000 n 
-0001003373 00000 n 
-0001015405 00000 n 
-0001028628 00000 n 
-0001048126 00000 n 
-0001069026 00000 n 
-0001091174 00000 n 
-0001109430 00000 n 
-0001112276 00000 n 
-0001112046 00000 n 
-0001139694 00000 n 
-0001167023 00000 n 
-0001171370 00000 n 
-0001171495 00000 n 
-0001171621 00000 n 
-0001171747 00000 n 
-0001171873 00000 n 
-0001171999 00000 n 
-0001172079 00000 n 
-0001172189 00000 n 
-0001193905 00000 n 
-0001218010 00000 n 
-0001218051 00000 n 
-0001218091 00000 n 
-0001218225 00000 n 
+0000785655 00000 n 
+0000788404 00000 n 
+0000788469 00000 n 
+0000788534 00000 n 
+0000788599 00000 n 
+0000788664 00000 n 
+0000788729 00000 n 
+0000788794 00000 n 
+0000788859 00000 n 
+0000788924 00000 n 
+0000788989 00000 n 
+0000789054 00000 n 
+0000789119 00000 n 
+0000789184 00000 n 
+0000789249 00000 n 
+0000789314 00000 n 
+0000789379 00000 n 
+0000789444 00000 n 
+0000789509 00000 n 
+0000789574 00000 n 
+0000789639 00000 n 
+0000789704 00000 n 
+0000789769 00000 n 
+0000789834 00000 n 
+0000789899 00000 n 
+0000789964 00000 n 
+0000790029 00000 n 
+0000790094 00000 n 
+0000790159 00000 n 
+0000790224 00000 n 
+0000790289 00000 n 
+0000790354 00000 n 
+0000790419 00000 n 
+0000790484 00000 n 
+0000790549 00000 n 
+0000790613 00000 n 
+0000790678 00000 n 
+0000790743 00000 n 
+0000790808 00000 n 
+0000790873 00000 n 
+0000790938 00000 n 
+0000791003 00000 n 
+0000791068 00000 n 
+0000791133 00000 n 
+0000791198 00000 n 
+0000791263 00000 n 
+0000791328 00000 n 
+0000791393 00000 n 
+0000791458 00000 n 
+0000791523 00000 n 
+0000791588 00000 n 
+0000791652 00000 n 
+0000797235 00000 n 
+0000794839 00000 n 
+0000791830 00000 n 
+0000794965 00000 n 
+0000795030 00000 n 
+0000795095 00000 n 
+0000795160 00000 n 
+0000795225 00000 n 
+0000795290 00000 n 
+0000795355 00000 n 
+0000795420 00000 n 
+0000795485 00000 n 
+0000795550 00000 n 
+0000795615 00000 n 
+0000795680 00000 n 
+0000795745 00000 n 
+0000795809 00000 n 
+0000795874 00000 n 
+0000795939 00000 n 
+0000796004 00000 n 
+0000796069 00000 n 
+0000796134 00000 n 
+0000796199 00000 n 
+0000796264 00000 n 
+0000796329 00000 n 
+0000796394 00000 n 
+0000796459 00000 n 
+0000796524 00000 n 
+0000796652 00000 n 
+0000796781 00000 n 
+0000796846 00000 n 
+0000796911 00000 n 
+0000796976 00000 n 
+0000797041 00000 n 
+0000797170 00000 n 
+0001173183 00000 n 
+0000800443 00000 n 
+0000799736 00000 n 
+0000797362 00000 n 
+0000799862 00000 n 
+0000799991 00000 n 
+0000800120 00000 n 
+0000800249 00000 n 
+0000800378 00000 n 
+0000803935 00000 n 
+0000803178 00000 n 
+0000800570 00000 n 
+0000803485 00000 n 
+0000803614 00000 n 
+0000803325 00000 n 
+0000803742 00000 n 
+0000803870 00000 n 
+0000807179 00000 n 
+0000806601 00000 n 
+0000804062 00000 n 
+0000806727 00000 n 
+0000806856 00000 n 
+0000806985 00000 n 
+0000807114 00000 n 
+0000810088 00000 n 
+0000809768 00000 n 
+0000807293 00000 n 
+0000809894 00000 n 
+0000810023 00000 n 
+0000812678 00000 n 
+0000812229 00000 n 
+0000810258 00000 n 
+0000812355 00000 n 
+0000812484 00000 n 
+0000812613 00000 n 
+0000813119 00000 n 
+0000812928 00000 n 
+0000812778 00000 n 
+0000813054 00000 n 
+0001173308 00000 n 
+0000815831 00000 n 
+0000815187 00000 n 
+0000813161 00000 n 
+0000815313 00000 n 
+0000815442 00000 n 
+0000815571 00000 n 
+0000815636 00000 n 
+0000815701 00000 n 
+0000815766 00000 n 
+0000820171 00000 n 
+0000819851 00000 n 
+0000815945 00000 n 
+0000819977 00000 n 
+0000820042 00000 n 
+0000820107 00000 n 
+0000823788 00000 n 
+0000823533 00000 n 
+0000820327 00000 n 
+0000823659 00000 n 
+0000823724 00000 n 
+0000827075 00000 n 
+0000826884 00000 n 
+0000823930 00000 n 
+0000827010 00000 n 
+0000830679 00000 n 
+0000830488 00000 n 
+0000827203 00000 n 
+0000830614 00000 n 
+0000833769 00000 n 
+0000833254 00000 n 
+0000830821 00000 n 
+0000833380 00000 n 
+0000833445 00000 n 
+0000833510 00000 n 
+0000833575 00000 n 
+0000833640 00000 n 
+0000833705 00000 n 
+0001173433 00000 n 
+0000837968 00000 n 
+0000837453 00000 n 
+0000833925 00000 n 
+0000837579 00000 n 
+0000837708 00000 n 
+0000837773 00000 n 
+0000837838 00000 n 
+0000837903 00000 n 
+0000841657 00000 n 
+0000840949 00000 n 
+0000838096 00000 n 
+0000841075 00000 n 
+0000841140 00000 n 
+0000841205 00000 n 
+0000841270 00000 n 
+0000841399 00000 n 
+0000841463 00000 n 
+0000841528 00000 n 
+0000841593 00000 n 
+0000844747 00000 n 
+0000844361 00000 n 
+0000841799 00000 n 
+0000844487 00000 n 
+0000844552 00000 n 
+0000844617 00000 n 
+0000844682 00000 n 
+0000847789 00000 n 
+0000847015 00000 n 
+0000844889 00000 n 
+0000847141 00000 n 
+0000847206 00000 n 
+0000847271 00000 n 
+0000847336 00000 n 
+0000847465 00000 n 
+0000847529 00000 n 
+0000847594 00000 n 
+0000847659 00000 n 
+0000847724 00000 n 
+0000851285 00000 n 
+0000851094 00000 n 
+0000847945 00000 n 
+0000851220 00000 n 
+0000854568 00000 n 
+0000854118 00000 n 
+0000851413 00000 n 
+0000854244 00000 n 
+0000854309 00000 n 
+0000854374 00000 n 
+0000854439 00000 n 
+0000854504 00000 n 
+0001173558 00000 n 
+0000858100 00000 n 
+0000857522 00000 n 
+0000854723 00000 n 
+0000857648 00000 n 
+0000857842 00000 n 
+0000857906 00000 n 
+0000857970 00000 n 
+0000858035 00000 n 
+0000861755 00000 n 
+0000861564 00000 n 
+0000858242 00000 n 
+0000861690 00000 n 
+0000865260 00000 n 
+0000865004 00000 n 
+0000861883 00000 n 
+0000865130 00000 n 
+0000865195 00000 n 
+0000868318 00000 n 
+0000867868 00000 n 
+0000865388 00000 n 
+0000867994 00000 n 
+0000868059 00000 n 
+0000868124 00000 n 
+0000868189 00000 n 
+0000868254 00000 n 
+0000871075 00000 n 
+0000870172 00000 n 
+0000868487 00000 n 
+0000870298 00000 n 
+0000870427 00000 n 
+0000870492 00000 n 
+0000870557 00000 n 
+0000870622 00000 n 
+0000870687 00000 n 
+0000870752 00000 n 
+0000870817 00000 n 
+0000871011 00000 n 
+0000874770 00000 n 
+0000874320 00000 n 
+0000871231 00000 n 
+0000874446 00000 n 
+0000874511 00000 n 
+0000874576 00000 n 
+0000874641 00000 n 
+0000874705 00000 n 
+0001173683 00000 n 
+0000878053 00000 n 
+0000877668 00000 n 
+0000874912 00000 n 
+0000877794 00000 n 
+0000877859 00000 n 
+0000877924 00000 n 
+0000877989 00000 n 
+0000881416 00000 n 
+0000880836 00000 n 
+0000878195 00000 n 
+0000880962 00000 n 
+0000881091 00000 n 
+0000881156 00000 n 
+0000881221 00000 n 
+0000881286 00000 n 
+0000881351 00000 n 
+0000885432 00000 n 
+0000885241 00000 n 
+0000881558 00000 n 
+0000885367 00000 n 
+0000889273 00000 n 
+0000889082 00000 n 
+0000885560 00000 n 
+0000889208 00000 n 
+0000892643 00000 n 
+0000892452 00000 n 
+0000889401 00000 n 
+0000892578 00000 n 
+0000895225 00000 n 
+0000894581 00000 n 
+0000892785 00000 n 
+0000894707 00000 n 
+0000894772 00000 n 
+0000894837 00000 n 
+0000894902 00000 n 
+0000895031 00000 n 
+0000895096 00000 n 
+0000895161 00000 n 
+0001173808 00000 n 
+0000898140 00000 n 
+0000897435 00000 n 
+0000895381 00000 n 
+0000897561 00000 n 
+0000897626 00000 n 
+0000897691 00000 n 
+0000897756 00000 n 
+0000897821 00000 n 
+0000897886 00000 n 
+0000898012 00000 n 
+0000898077 00000 n 
+0000901353 00000 n 
+0000900968 00000 n 
+0000898282 00000 n 
+0000901094 00000 n 
+0000901159 00000 n 
+0000901224 00000 n 
+0000901289 00000 n 
+0000905053 00000 n 
+0000904862 00000 n 
+0000901495 00000 n 
+0000904988 00000 n 
+0000907937 00000 n 
+0000907162 00000 n 
+0000905181 00000 n 
+0000907288 00000 n 
+0000907353 00000 n 
+0000907418 00000 n 
+0000907483 00000 n 
+0000907612 00000 n 
+0000907677 00000 n 
+0000907742 00000 n 
+0000907807 00000 n 
+0000907872 00000 n 
+0000911291 00000 n 
+0000911100 00000 n 
+0000908093 00000 n 
+0000911226 00000 n 
+0000914360 00000 n 
+0000914104 00000 n 
+0000911504 00000 n 
+0000914230 00000 n 
+0000914295 00000 n 
+0001173933 00000 n 
+0000917339 00000 n 
+0000916565 00000 n 
+0000914573 00000 n 
+0000916691 00000 n 
+0000916756 00000 n 
+0000916821 00000 n 
+0000916885 00000 n 
+0000916950 00000 n 
+0000917079 00000 n 
+0000917144 00000 n 
+0000917209 00000 n 
+0000917274 00000 n 
+0000920924 00000 n 
+0000920279 00000 n 
+0000917495 00000 n 
+0000920405 00000 n 
+0000920470 00000 n 
+0000920535 00000 n 
+0000920664 00000 n 
+0000920729 00000 n 
+0000920794 00000 n 
+0000920859 00000 n 
+0000925365 00000 n 
+0000925110 00000 n 
+0000921066 00000 n 
+0000925236 00000 n 
+0000925301 00000 n 
+0000928999 00000 n 
+0000928808 00000 n 
+0000925493 00000 n 
+0000928934 00000 n 
+0000931575 00000 n 
+0000931255 00000 n 
+0000929127 00000 n 
+0000931381 00000 n 
+0000931446 00000 n 
+0000931511 00000 n 
+0000935065 00000 n 
+0000934355 00000 n 
+0000931716 00000 n 
+0000934481 00000 n 
+0000934546 00000 n 
+0000934611 00000 n 
+0000934740 00000 n 
+0000934805 00000 n 
+0000934870 00000 n 
+0000934935 00000 n 
+0000935000 00000 n 
+0001174058 00000 n 
+0000938208 00000 n 
+0000937499 00000 n 
+0000935221 00000 n 
+0000937625 00000 n 
+0000937690 00000 n 
+0000937755 00000 n 
+0000937819 00000 n 
+0000937948 00000 n 
+0000938013 00000 n 
+0000938078 00000 n 
+0000938143 00000 n 
+0000941399 00000 n 
+0000941143 00000 n 
+0000938378 00000 n 
+0000941269 00000 n 
+0000941334 00000 n 
+0000944156 00000 n 
+0000943513 00000 n 
+0000941527 00000 n 
+0000943639 00000 n 
+0000943704 00000 n 
+0000943769 00000 n 
+0000943834 00000 n 
+0000943962 00000 n 
+0000944027 00000 n 
+0000944092 00000 n 
+0000947888 00000 n 
+0000947568 00000 n 
+0000944312 00000 n 
+0000947694 00000 n 
+0000947759 00000 n 
+0000947824 00000 n 
+0000950945 00000 n 
+0000950173 00000 n 
+0000948016 00000 n 
+0000950299 00000 n 
+0000950364 00000 n 
+0000950429 00000 n 
+0000950494 00000 n 
+0000950623 00000 n 
+0000950688 00000 n 
+0000950753 00000 n 
+0000950816 00000 n 
+0000950881 00000 n 
+0000954177 00000 n 
+0000953468 00000 n 
+0000951115 00000 n 
+0000953594 00000 n 
+0000953659 00000 n 
+0000953724 00000 n 
+0000953853 00000 n 
+0000953918 00000 n 
+0000953983 00000 n 
+0000954048 00000 n 
+0000954113 00000 n 
+0001174183 00000 n 
+0000956636 00000 n 
+0000955607 00000 n 
+0000954333 00000 n 
+0000955733 00000 n 
+0000955798 00000 n 
+0000955924 00000 n 
+0000955989 00000 n 
+0000956054 00000 n 
+0000956119 00000 n 
+0000956183 00000 n 
+0000956248 00000 n 
+0000956313 00000 n 
+0000956442 00000 n 
+0000956507 00000 n 
+0000956572 00000 n 
+0000959630 00000 n 
+0000958793 00000 n 
+0000956778 00000 n 
+0000958919 00000 n 
+0000958984 00000 n 
+0000959049 00000 n 
+0000959113 00000 n 
+0000959178 00000 n 
+0000959307 00000 n 
+0000959372 00000 n 
+0000959437 00000 n 
+0000959501 00000 n 
+0000959566 00000 n 
+0000960984 00000 n 
+0000960664 00000 n 
+0000959772 00000 n 
+0000960790 00000 n 
+0000960855 00000 n 
+0000960919 00000 n 
+0000961197 00000 n 
+0000972541 00000 n 
+0000980130 00000 n 
+0000982429 00000 n 
+0000982398 00000 n 
+0000986116 00000 n 
+0000995556 00000 n 
+0001006291 00000 n 
+0001018323 00000 n 
+0001031547 00000 n 
+0001051045 00000 n 
+0001071945 00000 n 
+0001094093 00000 n 
+0001112349 00000 n 
+0001115196 00000 n 
+0001114966 00000 n 
+0001142614 00000 n 
+0001169943 00000 n 
+0001174290 00000 n 
+0001174415 00000 n 
+0001174541 00000 n 
+0001174667 00000 n 
+0001174793 00000 n 
+0001174919 00000 n 
+0001174999 00000 n 
+0001175109 00000 n 
+0001197011 00000 n 
+0001221224 00000 n 
+0001221265 00000 n 
+0001221305 00000 n 
+0001221439 00000 n 
 trailer
 <<
-/Size 2756
-/Root 2754 0 R
-/Info 2755 0 R
-/ID [<1FAE46A3CCD607FC33BF8CE807861AEB> <1FAE46A3CCD607FC33BF8CE807861AEB>]
+/Size 2768
+/Root 2766 0 R
+/Info 2767 0 R
+/ID [<35F90285AF7E785B998738F11C46D894> <35F90285AF7E785B998738F11C46D894>]
 >>
 startxref
-1218483
+1221697
 %%EOF
diff --git a/doc/arm/man.arpaname.html b/doc/arm/man.arpaname.html
index 324f575b..bf1f2b32 100644
--- a/doc/arm/man.arpaname.html
+++ b/doc/arm/man.arpaname.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.arpaname.html,v 1.67 2011-12-22 18:10:11 tbox Exp $ -->
+<!-- $Id: man.arpaname.html,v 1.70 2012-01-17 01:15:03 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,20 +50,20 @@
 <div class="cmdsynopsis"><p><code class="command">arpaname</code>  {<em class="replaceable"><code>ipaddress </code></em>...}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2618193"></a><h2>DESCRIPTION</h2>
+<a name="id2617779"></a><h2>DESCRIPTION</h2>
 <p>
       <span><strong class="command">arpaname</strong></span> translates IP addresses (IPv4 and
       IPv6) to the corresponding IN-ADDR.ARPA or IP6.ARPA names.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2618208"></a><h2>SEE ALSO</h2>
+<a name="id2617794"></a><h2>SEE ALSO</h2>
 <p>
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2618221"></a><h2>AUTHOR</h2>
+<a name="id2617808"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.ddns-confgen.html b/doc/arm/man.ddns-confgen.html
index 4c67101d..beeac0fc 100644
--- a/doc/arm/man.ddns-confgen.html
+++ b/doc/arm/man.ddns-confgen.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.ddns-confgen.html,v 1.103 2011-12-22 18:10:10 tbox Exp $ -->
+<!-- $Id: man.ddns-confgen.html,v 1.106 2012-01-17 01:15:00 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">ddns-confgen</code>  [<code class="option">-a <em class="replaceable"><code>algorithm</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>keyname</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomfile</code></em></code>] [ -s <em class="replaceable"><code>name</code></em>  |   -z <em class="replaceable"><code>zone</code></em> ] [<code class="option">-q</code>] [name]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2644567"></a><h2>DESCRIPTION</h2>
+<a name="id2648113"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">ddns-confgen</strong></span>
       generates a key for use by <span><strong class="command">nsupdate</strong></span>
       and <span><strong class="command">named</strong></span>.  It simplifies configuration
@@ -77,7 +77,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2644654"></a><h2>OPTIONS</h2>
+<a name="id2648200"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt>
 <dd><p>
@@ -144,7 +144,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2649634"></a><h2>SEE ALSO</h2>
+<a name="id2652633"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">nsupdate</span>(1)</span>,
       <span class="citerefentry"><span class="refentrytitle">named.conf</span>(5)</span>,
       <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
@@ -152,7 +152,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2649672"></a><h2>AUTHOR</h2>
+<a name="id2652672"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.dig.html b/doc/arm/man.dig.html
index 655babff..27ca9412 100644
--- a/doc/arm/man.dig.html
+++ b/doc/arm/man.dig.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.dig.html,v 1.187 2011-11-24 01:14:51 tbox Exp $ -->
+<!-- $Id: man.dig.html,v 1.190 2012-01-17 01:15:01 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -52,7 +52,7 @@
 <div class="cmdsynopsis"><p><code class="command">dig</code>  [global-queryopt...] [query...]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2610554"></a><h2>DESCRIPTION</h2>
+<a name="id2611096"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">dig</strong></span>
       (domain information groper) is a flexible tool
       for interrogating DNS name servers.  It performs DNS lookups and
@@ -98,7 +98,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2610990"></a><h2>SIMPLE USAGE</h2>
+<a name="id2611191"></a><h2>SIMPLE USAGE</h2>
 <p>
       A typical invocation of <span><strong class="command">dig</strong></span> looks like:
       </p>
@@ -144,7 +144,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2611238"></a><h2>OPTIONS</h2>
+<a name="id2611575"></a><h2>OPTIONS</h2>
 <p>
       The <code class="option">-b</code> option sets the source IP address of the query
       to <em class="parameter"><code>address</code></em>.  This must be a valid
@@ -248,7 +248,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2663053"></a><h2>QUERY OPTIONS</h2>
+<a name="id2663322"></a><h2>QUERY OPTIONS</h2>
 <p><span><strong class="command">dig</strong></span>
       provides a number of query options which affect
       the way in which lookups are made and the results displayed.  Some of
@@ -599,7 +599,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2664124"></a><h2>MULTIPLE QUERIES</h2>
+<a name="id2664461"></a><h2>MULTIPLE QUERIES</h2>
 <p>
       The BIND 9 implementation of <span><strong class="command">dig </strong></span>
       supports
@@ -645,7 +645,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2664210"></a><h2>IDN SUPPORT</h2>
+<a name="id2664615"></a><h2>IDN SUPPORT</h2>
 <p>
       If <span><strong class="command">dig</strong></span> has been built with IDN (internationalized
       domain name) support, it can accept and display non-ASCII domain names.
@@ -659,14 +659,14 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2664238"></a><h2>FILES</h2>
+<a name="id2664644"></a><h2>FILES</h2>
 <p><code class="filename">/etc/resolv.conf</code>
     </p>
 <p><code class="filename">${HOME}/.digrc</code>
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2664260"></a><h2>SEE ALSO</h2>
+<a name="id2664665"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">host</span>(1)</span>,
       <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
@@ -674,7 +674,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2664297"></a><h2>BUGS</h2>
+<a name="id2664702"></a><h2>BUGS</h2>
 <p>
       There are probably too many query options.
     </p>
diff --git a/doc/arm/man.dnssec-dsfromkey.html b/doc/arm/man.dnssec-dsfromkey.html
index c0c9eb80..c5224b26 100644
--- a/doc/arm/man.dnssec-dsfromkey.html
+++ b/doc/arm/man.dnssec-dsfromkey.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.dnssec-dsfromkey.html,v 1.100 2011-11-24 01:14:51 tbox Exp $ -->
+<!-- $Id: man.dnssec-dsfromkey.html,v 1.103 2012-01-17 01:15:00 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -51,14 +51,14 @@
 <div class="cmdsynopsis"><p><code class="command">dnssec-dsfromkey</code>  {-s} [<code class="option">-1</code>] [<code class="option">-2</code>] [<code class="option">-a <em class="replaceable"><code>alg</code></em></code>] [<code class="option">-K <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-l <em class="replaceable"><code>domain</code></em></code>] [<code class="option">-s</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-T <em class="replaceable"><code>TTL</code></em></code>] [<code class="option">-f <em class="replaceable"><code>file</code></em></code>] [<code class="option">-A</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] {dnsname}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2612568"></a><h2>DESCRIPTION</h2>
+<a name="id2612769"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">dnssec-dsfromkey</strong></span>
       outputs the Delegation Signer (DS) resource record (RR), as defined in
       RFC 3658 and RFC 4509, for the given key(s).
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2612582"></a><h2>OPTIONS</h2>
+<a name="id2612782"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-1</span></dt>
 <dd><p>
@@ -134,7 +134,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2613499"></a><h2>EXAMPLE</h2>
+<a name="id2613768"></a><h2>EXAMPLE</h2>
 <p>
       To build the SHA-256 DS RR from the
       <strong class="userinput"><code>Kexample.com.+003+26160</code></strong>
@@ -149,7 +149,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2613536"></a><h2>FILES</h2>
+<a name="id2613804"></a><h2>FILES</h2>
 <p>
       The keyfile can be designed by the key identification
       <code class="filename">Knnnn.+aaa+iiiii</code> or the full file name
@@ -163,13 +163,13 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2613577"></a><h2>CAVEAT</h2>
+<a name="id2613846"></a><h2>CAVEAT</h2>
 <p>
       A keyfile error can give a "file not found" even if the file exists.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2613587"></a><h2>SEE ALSO</h2>
+<a name="id2613856"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
@@ -179,7 +179,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2613626"></a><h2>AUTHOR</h2>
+<a name="id2613895"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.dnssec-keyfromlabel.html b/doc/arm/man.dnssec-keyfromlabel.html
index 31c3d053..d7f76959 100644
--- a/doc/arm/man.dnssec-keyfromlabel.html
+++ b/doc/arm/man.dnssec-keyfromlabel.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.dnssec-keyfromlabel.html,v 1.137 2011-11-24 01:14:51 tbox Exp $ -->
+<!-- $Id: man.dnssec-keyfromlabel.html,v 1.140 2012-01-17 01:15:00 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">dnssec-keyfromlabel</code>  {-l <em class="replaceable"><code>label</code></em>} [<code class="option">-3</code>] [<code class="option">-a <em class="replaceable"><code>algorithm</code></em></code>] [<code class="option">-A <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-D <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-E <em class="replaceable"><code>engine</code></em></code>] [<code class="option">-f <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-G</code>] [<code class="option">-I <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-k</code>] [<code class="option">-K <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-L <em class="replaceable"><code>ttl</code></em></code>] [<code class="option">-n <em class="replaceable"><code>nametype</code></em></code>] [<code class="option">-P <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-p <em class="replaceable"><code>protocol</code></em></code>] [<code class="option">-R <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-y</code>] {name}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2613912"></a><h2>DESCRIPTION</h2>
+<a name="id2614659"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">dnssec-keyfromlabel</strong></span>
       gets keys with the given label from a crypto hardware and builds
       key files for DNSSEC (Secure DNS), as defined in RFC 2535
@@ -63,7 +63,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2614274"></a><h2>OPTIONS</h2>
+<a name="id2614679"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt>
 <dd>
@@ -191,7 +191,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2616444"></a><h2>TIMING OPTIONS</h2>
+<a name="id2616645"></a><h2>TIMING OPTIONS</h2>
 <p>
       Dates can be expressed in the format YYYYMMDD or YYYYMMDDHHMMSS.
       If the argument begins with a '+' or '-', it is interpreted as
@@ -238,7 +238,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2616679"></a><h2>GENERATED KEY FILES</h2>
+<a name="id2616880"></a><h2>GENERATED KEY FILES</h2>
 <p>
       When <span><strong class="command">dnssec-keyfromlabel</strong></span> completes
       successfully,
@@ -277,7 +277,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2655548"></a><h2>SEE ALSO</h2>
+<a name="id2667832"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
@@ -285,7 +285,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2655581"></a><h2>AUTHOR</h2>
+<a name="id2667865"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.dnssec-keygen.html b/doc/arm/man.dnssec-keygen.html
index 208bb33d..5b4250d8 100644
--- a/doc/arm/man.dnssec-keygen.html
+++ b/doc/arm/man.dnssec-keygen.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.dnssec-keygen.html,v 1.206 2011-11-24 01:14:51 tbox Exp $ -->
+<!-- $Id: man.dnssec-keygen.html,v 1.209 2012-01-17 01:15:00 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">dnssec-keygen</code>  [<code class="option">-a <em class="replaceable"><code>algorithm</code></em></code>] [<code class="option">-b <em class="replaceable"><code>keysize</code></em></code>] [<code class="option">-n <em class="replaceable"><code>nametype</code></em></code>] [<code class="option">-3</code>] [<code class="option">-A <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-C</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-D <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-E <em class="replaceable"><code>engine</code></em></code>] [<code class="option">-e</code>] [<code class="option">-f <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-G</code>] [<code class="option">-g <em class="replaceable"><code>generator</code></em></code>] [<code class="option">-h</code>] [<code class="option">-I <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-i <em class="replaceable"><code>interval</code></em></code>] [<code class="option">-K <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-L <em class="replaceable"><code>ttl</code></em></code>] [<code class="option">-k</code>] [<code class="option">-P <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-p <em class="replaceable"><code>protocol</code></em></code>] [<code class="option">-q</code>] [<code class="option">-R <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-S <em class="replaceable"><code>key</code></em></code>] [<code class="option">-s <em class="replaceable"><code>strength</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-z</code>] {name}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2615458"></a><h2>DESCRIPTION</h2>
+<a name="id2615795"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">dnssec-keygen</strong></span>
       generates keys for DNSSEC (Secure DNS), as defined in RFC 2535
       and RFC 4034.  It can also generate keys for use with
@@ -64,7 +64,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2615478"></a><h2>OPTIONS</h2>
+<a name="id2615815"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt>
 <dd>
@@ -275,7 +275,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2666880"></a><h2>TIMING OPTIONS</h2>
+<a name="id2669401"></a><h2>TIMING OPTIONS</h2>
 <p>
       Dates can be expressed in the format YYYYMMDD or YYYYMMDDHHMMSS.
       If the argument begins with a '+' or '-', it is interpreted as
@@ -346,7 +346,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2667069"></a><h2>GENERATED KEYS</h2>
+<a name="id2669591"></a><h2>GENERATED KEYS</h2>
 <p>
       When <span><strong class="command">dnssec-keygen</strong></span> completes
       successfully,
@@ -392,7 +392,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2667245"></a><h2>EXAMPLE</h2>
+<a name="id2669767"></a><h2>EXAMPLE</h2>
 <p>
       To generate a 768-bit DSA key for the domain
       <strong class="userinput"><code>example.com</code></strong>, the following command would be
@@ -413,7 +413,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2667302"></a><h2>SEE ALSO</h2>
+<a name="id2669892"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
       <em class="citetitle">RFC 2539</em>,
@@ -422,7 +422,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2667333"></a><h2>AUTHOR</h2>
+<a name="id2669923"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.dnssec-revoke.html b/doc/arm/man.dnssec-revoke.html
index b33fbf0d..72d09b9c 100644
--- a/doc/arm/man.dnssec-revoke.html
+++ b/doc/arm/man.dnssec-revoke.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.dnssec-revoke.html,v 1.90 2011-11-24 01:14:52 tbox Exp $ -->
+<!-- $Id: man.dnssec-revoke.html,v 1.93 2012-01-17 01:15:02 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">dnssec-revoke</code>  [<code class="option">-hr</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-K <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-E <em class="replaceable"><code>engine</code></em></code>] [<code class="option">-f</code>] [<code class="option">-R</code>] {keyfile}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2615676"></a><h2>DESCRIPTION</h2>
+<a name="id2616286"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">dnssec-revoke</strong></span>
       reads a DNSSEC key file, sets the REVOKED bit on the key as defined
       in RFC 5011, and creates a new pair of key files containing the
@@ -58,7 +58,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2615690"></a><h2>OPTIONS</h2>
+<a name="id2616300"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-h</span></dt>
 <dd><p>
@@ -96,14 +96,14 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2615811"></a><h2>SEE ALSO</h2>
+<a name="id2616421"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
       <em class="citetitle">RFC 5011</em>.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2615835"></a><h2>AUTHOR</h2>
+<a name="id2616445"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.dnssec-settime.html b/doc/arm/man.dnssec-settime.html
index f1929d25..e797f735 100644
--- a/doc/arm/man.dnssec-settime.html
+++ b/doc/arm/man.dnssec-settime.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.dnssec-settime.html,v 1.86 2011-11-24 01:14:52 tbox Exp $ -->
+<!-- $Id: man.dnssec-settime.html,v 1.89 2012-01-17 01:15:01 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">dnssec-settime</code>  [<code class="option">-f</code>] [<code class="option">-K <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-L <em class="replaceable"><code>ttl</code></em></code>] [<code class="option">-P <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-A <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-R <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-I <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-D <em class="replaceable"><code>date/offset</code></em></code>] [<code class="option">-h</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-E <em class="replaceable"><code>engine</code></em></code>] {keyfile}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2616004"></a><h2>DESCRIPTION</h2>
+<a name="id2617092"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">dnssec-settime</strong></span>
       reads a DNSSEC private key file and sets the key timing metadata
       as specified by the <code class="option">-P</code>, <code class="option">-A</code>,
@@ -76,7 +76,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2616062"></a><h2>OPTIONS</h2>
+<a name="id2617150"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-f</span></dt>
 <dd><p>
@@ -118,7 +118,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2616730"></a><h2>TIMING OPTIONS</h2>
+<a name="id2617340"></a><h2>TIMING OPTIONS</h2>
 <p>
       Dates can be expressed in the format YYYYMMDD or YYYYMMDDHHMMSS.
       If the argument begins with a '+' or '-', it is interpreted as
@@ -197,7 +197,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2616937"></a><h2>PRINTING OPTIONS</h2>
+<a name="id2617547"></a><h2>PRINTING OPTIONS</h2>
 <p>
       <span><strong class="command">dnssec-settime</strong></span> can also be used to print the
       timing metadata associated with a key.
@@ -223,7 +223,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2617017"></a><h2>SEE ALSO</h2>
+<a name="id2618856"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
@@ -231,7 +231,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2617050"></a><h2>AUTHOR</h2>
+<a name="id2618889"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.dnssec-signzone.html b/doc/arm/man.dnssec-signzone.html
index 3257623c..3dcbbb7e 100644
--- a/doc/arm/man.dnssec-signzone.html
+++ b/doc/arm/man.dnssec-signzone.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.dnssec-signzone.html,v 1.211 2011-12-22 18:10:10 tbox Exp $ -->
+<!-- $Id: man.dnssec-signzone.html,v 1.214 2012-01-17 01:15:00 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">dnssec-signzone</code>  [<code class="option">-a</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-d <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-D</code>] [<code class="option">-E <em class="replaceable"><code>engine</code></em></code>] [<code class="option">-e <em class="replaceable"><code>end-time</code></em></code>] [<code class="option">-f <em class="replaceable"><code>output-file</code></em></code>] [<code class="option">-g</code>] [<code class="option">-h</code>] [<code class="option">-K <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-k <em class="replaceable"><code>key</code></em></code>] [<code class="option">-L <em class="replaceable"><code>serial</code></em></code>] [<code class="option">-l <em class="replaceable"><code>domain</code></em></code>] [<code class="option">-i <em class="replaceable"><code>interval</code></em></code>] [<code class="option">-I <em class="replaceable"><code>input-format</code></em></code>] [<code class="option">-j <em class="replaceable"><code>jitter</code></em></code>] [<code class="option">-N <em class="replaceable"><code>soa-serial-format</code></em></code>] [<code class="option">-o <em class="replaceable"><code>origin</code></em></code>] [<code class="option">-O <em class="replaceable"><code>output-format</code></em></code>] [<code class="option">-P</code>] [<code class="option">-p</code>] [<code class="option">-R</code>] [<code class="option">-r <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-S</code>] [<code class="option">-s <em class="replaceable"><code>start-time</code></em></code>] [<code class="option">-T <em class="replaceable"><code>ttl</code></em></code>] [<code class="option">-t</code>] [<code class="option">-u</code>] [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-X <em class="replaceable"><code>extended end-time</code></em></code>] [<code class="option">-x</code>] [<code class="option">-z</code>] [<code class="option">-3 <em class="replaceable"><code>salt</code></em></code>] [<code class="option">-H <em class="replaceable"><code>iterations</code></em></code>] [<code class="option">-A</code>] {zonefile} [key...]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2667472"></a><h2>DESCRIPTION</h2>
+<a name="id2672724"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">dnssec-signzone</strong></span>
       signs a zone.  It generates
       NSEC and RRSIG records and produces a signed version of the
@@ -61,7 +61,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2667491"></a><h2>OPTIONS</h2>
+<a name="id2672743"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-a</span></dt>
 <dd><p>
@@ -464,7 +464,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2668853"></a><h2>EXAMPLE</h2>
+<a name="id2674105"></a><h2>EXAMPLE</h2>
 <p>
       The following command signs the <strong class="userinput"><code>example.com</code></strong>
       zone with the DSA key generated by <span><strong class="command">dnssec-keygen</strong></span>
@@ -494,14 +494,14 @@ db.example.com.signed
 %</pre>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2668932"></a><h2>SEE ALSO</h2>
+<a name="id2674252"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
       <em class="citetitle">RFC 4033</em>.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2668956"></a><h2>AUTHOR</h2>
+<a name="id2674277"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.genrandom.html b/doc/arm/man.genrandom.html
index acf6e744..9ef88316 100644
--- a/doc/arm/man.genrandom.html
+++ b/doc/arm/man.genrandom.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.genrandom.html,v 1.69 2011-12-22 18:10:10 tbox Exp $ -->
+<!-- $Id: man.genrandom.html,v 1.72 2012-01-17 01:15:00 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">genrandom</code>  [<code class="option">-n <em class="replaceable"><code>number</code></em></code>] {<em class="replaceable"><code>size</code></em>} {<em class="replaceable"><code>filename</code></em>}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2649787"></a><h2>DESCRIPTION</h2>
+<a name="id2652855"></a><h2>DESCRIPTION</h2>
 <p>
       <span><strong class="command">genrandom</strong></span>
       generates a file or a set of files containing a specified quantity
@@ -59,7 +59,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2649802"></a><h2>ARGUMENTS</h2>
+<a name="id2652870"></a><h2>ARGUMENTS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-n <em class="replaceable"><code>number</code></em></span></dt>
 <dd><p>
@@ -77,14 +77,14 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2649863"></a><h2>SEE ALSO</h2>
+<a name="id2652931"></a><h2>SEE ALSO</h2>
 <p>
       <span class="citerefentry"><span class="refentrytitle">rand</span>(3)</span>,
       <span class="citerefentry"><span class="refentrytitle">arc4random</span>(3)</span>
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2649890"></a><h2>AUTHOR</h2>
+<a name="id2652957"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.host.html b/doc/arm/man.host.html
index dbb911d3..9ee42877 100644
--- a/doc/arm/man.host.html
+++ b/doc/arm/man.host.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.host.html,v 1.185 2011-11-24 01:14:52 tbox Exp $ -->
+<!-- $Id: man.host.html,v 1.188 2012-01-17 01:15:01 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">host</code>  [<code class="option">-aCdlnrsTwv</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-N <em class="replaceable"><code>ndots</code></em></code>] [<code class="option">-R <em class="replaceable"><code>number</code></em></code>] [<code class="option">-t <em class="replaceable"><code>type</code></em></code>] [<code class="option">-W <em class="replaceable"><code>wait</code></em></code>] [<code class="option">-m <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-4</code>] [<code class="option">-6</code>] {name} [server]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2611777"></a><h2>DESCRIPTION</h2>
+<a name="id2611772"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">host</strong></span>
       is a simple utility for performing DNS lookups.
       It is normally used to convert names to IP addresses and vice versa.
@@ -202,7 +202,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2612154"></a><h2>IDN SUPPORT</h2>
+<a name="id2612491"></a><h2>IDN SUPPORT</h2>
 <p>
       If <span><strong class="command">host</strong></span> has been built with IDN (internationalized
       domain name) support, it can accept and display non-ASCII domain names. 
@@ -216,12 +216,12 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2612320"></a><h2>FILES</h2>
+<a name="id2612520"></a><h2>FILES</h2>
 <p><code class="filename">/etc/resolv.conf</code>
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2612333"></a><h2>SEE ALSO</h2>
+<a name="id2612534"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">dig</span>(1)</span>,
       <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>.
     </p>
diff --git a/doc/arm/man.isc-hmac-fixup.html b/doc/arm/man.isc-hmac-fixup.html
index c372d078..897a65e6 100644
--- a/doc/arm/man.isc-hmac-fixup.html
+++ b/doc/arm/man.isc-hmac-fixup.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.isc-hmac-fixup.html,v 1.66 2011-12-22 18:10:10 tbox Exp $ -->
+<!-- $Id: man.isc-hmac-fixup.html,v 1.69 2012-01-17 01:15:01 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">isc-hmac-fixup</code>  {<em class="replaceable"><code>algorithm</code></em>} {<em class="replaceable"><code>secret</code></em>}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2618398"></a><h2>DESCRIPTION</h2>
+<a name="id2619077"></a><h2>DESCRIPTION</h2>
 <p>
       Versions of BIND 9 up to and including BIND 9.6 had a bug causing
       HMAC-SHA* TSIG keys which were longer than the digest length of the
@@ -76,7 +76,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2618426"></a><h2>SECURITY CONSIDERATIONS</h2>
+<a name="id2619105"></a><h2>SECURITY CONSIDERATIONS</h2>
 <p>
       Secrets that have been converted by <span><strong class="command">isc-hmac-fixup</strong></span>
       are shortened, but as this is how the HMAC protocol works in
@@ -87,14 +87,14 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2651005"></a><h2>SEE ALSO</h2>
+<a name="id2653390"></a><h2>SEE ALSO</h2>
 <p>
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
       <em class="citetitle">RFC 2104</em>.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2651022"></a><h2>AUTHOR</h2>
+<a name="id2653408"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.named-checkconf.html b/doc/arm/man.named-checkconf.html
index 7dea3ec6..abf51853 100644
--- a/doc/arm/man.named-checkconf.html
+++ b/doc/arm/man.named-checkconf.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.named-checkconf.html,v 1.206 2011-12-22 18:10:10 tbox Exp $ -->
+<!-- $Id: man.named-checkconf.html,v 1.209 2012-01-17 01:15:01 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">named-checkconf</code>  [<code class="option">-h</code>] [<code class="option">-v</code>] [<code class="option">-j</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] {filename} [<code class="option">-p</code>] [<code class="option">-z</code>]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2617842"></a><h2>DESCRIPTION</h2>
+<a name="id2618588"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">named-checkconf</strong></span>
       checks the syntax, but not the semantics, of a
       <span><strong class="command">named</strong></span> configuration file.  The file is parsed
@@ -70,7 +70,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2617912"></a><h2>OPTIONS</h2>
+<a name="id2618659"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-h</span></dt>
 <dd><p>
@@ -109,21 +109,21 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2618661"></a><h2>RETURN VALUES</h2>
+<a name="id2618930"></a><h2>RETURN VALUES</h2>
 <p><span><strong class="command">named-checkconf</strong></span>
       returns an exit status of 1 if
       errors were detected and 0 otherwise.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2618675"></a><h2>SEE ALSO</h2>
+<a name="id2618944"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">named-checkzone</span>(8)</span>,
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2618705"></a><h2>AUTHOR</h2>
+<a name="id2618973"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.named-checkzone.html b/doc/arm/man.named-checkzone.html
index 34363623..575deadc 100644
--- a/doc/arm/man.named-checkzone.html
+++ b/doc/arm/man.named-checkzone.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.named-checkzone.html,v 1.215 2011-12-22 18:10:10 tbox Exp $ -->
+<!-- $Id: man.named-checkzone.html,v 1.218 2012-01-17 01:15:02 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -51,7 +51,7 @@
 <div class="cmdsynopsis"><p><code class="command">named-compilezone</code>  [<code class="option">-d</code>] [<code class="option">-j</code>] [<code class="option">-q</code>] [<code class="option">-v</code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-C <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-n <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-L <em class="replaceable"><code>serial</code></em></code>] [<code class="option">-r <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-w <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-D</code>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {<code class="option">-o <em class="replaceable"><code>filename</code></em></code>} {zonename} {filename}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2619896"></a><h2>DESCRIPTION</h2>
+<a name="id2622827"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">named-checkzone</strong></span>
       checks the syntax and integrity of a zone file.  It performs the
       same checks as <span><strong class="command">named</strong></span> does when loading a
@@ -71,7 +71,7 @@
      </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2671146"></a><h2>OPTIONS</h2>
+<a name="id2675579"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-d</span></dt>
 <dd><p>
@@ -281,14 +281,14 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2672027"></a><h2>RETURN VALUES</h2>
+<a name="id2676392"></a><h2>RETURN VALUES</h2>
 <p><span><strong class="command">named-checkzone</strong></span>
       returns an exit status of 1 if
       errors were detected and 0 otherwise.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2672041"></a><h2>SEE ALSO</h2>
+<a name="id2676406"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">named-checkconf</span>(8)</span>,
       <em class="citetitle">RFC 1035</em>,
@@ -296,7 +296,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2672074"></a><h2>AUTHOR</h2>
+<a name="id2676439"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.named-journalprint.html b/doc/arm/man.named-journalprint.html
index b98ca2e8..4854d5d7 100644
--- a/doc/arm/man.named-journalprint.html
+++ b/doc/arm/man.named-journalprint.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.named-journalprint.html,v 1.66 2011-12-22 18:10:10 tbox Exp $ -->
+<!-- $Id: man.named-journalprint.html,v 1.69 2012-01-17 01:15:02 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">named-journalprint</code>  {<em class="replaceable"><code>journal</code></em>}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2614037"></a><h2>DESCRIPTION</h2>
+<a name="id2614306"></a><h2>DESCRIPTION</h2>
 <p>
       <span><strong class="command">named-journalprint</strong></span>
       prints the contents of a zone journal file in a human-readable
@@ -76,7 +76,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2627941"></a><h2>SEE ALSO</h2>
+<a name="id2639337"></a><h2>SEE ALSO</h2>
 <p>
       <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">nsupdate</span>(8)</span>,
@@ -84,7 +84,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2627972"></a><h2>AUTHOR</h2>
+<a name="id2639368"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.named.html b/doc/arm/man.named.html
index dfddf855..c44c8168 100644
--- a/doc/arm/man.named.html
+++ b/doc/arm/man.named.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.named.html,v 1.218 2011-12-22 18:10:10 tbox Exp $ -->
+<!-- $Id: man.named.html,v 1.221 2012-01-17 01:15:01 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">named</code>  [<code class="option">-4</code>] [<code class="option">-6</code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-d <em class="replaceable"><code>debug-level</code></em></code>] [<code class="option">-E <em class="replaceable"><code>engine-name</code></em></code>] [<code class="option">-f</code>] [<code class="option">-g</code>] [<code class="option">-m <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-n <em class="replaceable"><code>#cpus</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-s</code>] [<code class="option">-S <em class="replaceable"><code>#max-socks</code></em></code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] [<code class="option">-U <em class="replaceable"><code>#listeners</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>] [<code class="option">-v</code>] [<code class="option">-V</code>] [<code class="option">-x <em class="replaceable"><code>cache-file</code></em></code>]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2622072"></a><h2>DESCRIPTION</h2>
+<a name="id2634151"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">named</strong></span>
       is a Domain Name System (DNS) server,
       part of the BIND 9 distribution from ISC.  For more
@@ -65,7 +65,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2622103"></a><h2>OPTIONS</h2>
+<a name="id2634182"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-4</span></dt>
 <dd><p>
@@ -255,7 +255,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2640232"></a><h2>SIGNALS</h2>
+<a name="id2676682"></a><h2>SIGNALS</h2>
 <p>
       In routine operation, signals should not be used to control
       the nameserver; <span><strong class="command">rndc</strong></span> should be used
@@ -276,7 +276,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2640282"></a><h2>CONFIGURATION</h2>
+<a name="id2676732"></a><h2>CONFIGURATION</h2>
 <p>
       The <span><strong class="command">named</strong></span> configuration file is too complex
       to describe in detail here.  A complete description is provided
@@ -293,7 +293,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2640331"></a><h2>FILES</h2>
+<a name="id2676781"></a><h2>FILES</h2>
 <div class="variablelist"><dl>
 <dt><span class="term"><code class="filename">/etc/named.conf</code></span></dt>
 <dd><p>
@@ -306,7 +306,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2676761"></a><h2>SEE ALSO</h2>
+<a name="id2676825"></a><h2>SEE ALSO</h2>
 <p><em class="citetitle">RFC 1033</em>,
       <em class="citetitle">RFC 1034</em>,
       <em class="citetitle">RFC 1035</em>,
@@ -319,7 +319,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2676832"></a><h2>AUTHOR</h2>
+<a name="id2676964"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.nsec3hash.html b/doc/arm/man.nsec3hash.html
index bf321e79..83c33a6a 100644
--- a/doc/arm/man.nsec3hash.html
+++ b/doc/arm/man.nsec3hash.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.nsec3hash.html,v 1.69 2011-12-22 18:10:10 tbox Exp $ -->
+<!-- $Id: man.nsec3hash.html,v 1.72 2012-01-17 01:15:01 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -48,7 +48,7 @@
 <div class="cmdsynopsis"><p><code class="command">nsec3hash</code>  {<em class="replaceable"><code>salt</code></em>} {<em class="replaceable"><code>algorithm</code></em>} {<em class="replaceable"><code>iterations</code></em>} {<em class="replaceable"><code>domain</code></em>}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2651478"></a><h2>DESCRIPTION</h2>
+<a name="id2619252"></a><h2>DESCRIPTION</h2>
 <p>
       <span><strong class="command">nsec3hash</strong></span> generates an NSEC3 hash based on
       a set of NSEC3 parameters.  This can be used to check the validity
@@ -56,7 +56,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2651493"></a><h2>ARGUMENTS</h2>
+<a name="id2653537"></a><h2>ARGUMENTS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">salt</span></dt>
 <dd><p>
@@ -80,14 +80,14 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2651555"></a><h2>SEE ALSO</h2>
+<a name="id2653598"></a><h2>SEE ALSO</h2>
 <p>
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
       <em class="citetitle">RFC 5155</em>.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2651572"></a><h2>AUTHOR</h2>
+<a name="id2653616"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.nsupdate.html b/doc/arm/man.nsupdate.html
index 8d9cdefa..8ac35883 100644
--- a/doc/arm/man.nsupdate.html
+++ b/doc/arm/man.nsupdate.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.nsupdate.html,v 1.144 2011-12-22 18:10:11 tbox Exp $ -->
+<!-- $Id: man.nsupdate.html,v 1.147 2012-01-17 01:15:02 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">nsupdate</code>  [<code class="option">-d</code>] [<code class="option">-D</code>] [[<code class="option">-g</code>] |  [<code class="option">-o</code>] |  [<code class="option">-l</code>] |  [<code class="option">-y <em class="replaceable"><code>[<span class="optional">hmac:</span>]keyname:secret</code></em></code>] |  [<code class="option">-k <em class="replaceable"><code>keyfile</code></em></code>]] [<code class="option">-t <em class="replaceable"><code>timeout</code></em></code>] [<code class="option">-u <em class="replaceable"><code>udptimeout</code></em></code>] [<code class="option">-r <em class="replaceable"><code>udpretries</code></em></code>] [<code class="option">-R <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-v</code>] [filename]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2639147"></a><h2>DESCRIPTION</h2>
+<a name="id2639553"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">nsupdate</strong></span>
       is used to submit Dynamic DNS Update requests as defined in RFC 2136
       to a name server.
@@ -210,7 +210,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2639549"></a><h2>INPUT FORMAT</h2>
+<a name="id2640364"></a><h2>INPUT FORMAT</h2>
 <p><span><strong class="command">nsupdate</strong></span>
       reads input from
       <em class="parameter"><code>filename</code></em>
@@ -498,7 +498,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2679868"></a><h2>EXAMPLES</h2>
+<a name="id2678021"></a><h2>EXAMPLES</h2>
 <p>
       The examples below show how
       <span><strong class="command">nsupdate</strong></span>
@@ -552,7 +552,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2679918"></a><h2>FILES</h2>
+<a name="id2678071"></a><h2>FILES</h2>
 <div class="variablelist"><dl>
 <dt><span class="term"><code class="constant">/etc/resolv.conf</code></span></dt>
 <dd><p>
@@ -575,7 +575,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2680070"></a><h2>SEE ALSO</h2>
+<a name="id2678154"></a><h2>SEE ALSO</h2>
 <p>
       <em class="citetitle">RFC 2136</em>,
       <em class="citetitle">RFC 3007</em>,
@@ -590,7 +590,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2680128"></a><h2>BUGS</h2>
+<a name="id2678280"></a><h2>BUGS</h2>
 <p>
       The TSIG key is redundantly stored in two separate files.
       This is a consequence of nsupdate using the DST library
diff --git a/doc/arm/man.rndc-confgen.html b/doc/arm/man.rndc-confgen.html
index 2519d911..1eb643f3 100644
--- a/doc/arm/man.rndc-confgen.html
+++ b/doc/arm/man.rndc-confgen.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.rndc-confgen.html,v 1.223 2011-12-22 18:10:11 tbox Exp $ -->
+<!-- $Id: man.rndc-confgen.html,v 1.226 2012-01-17 01:15:02 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">rndc-confgen</code>  [<code class="option">-a</code>] [<code class="option">-b <em class="replaceable"><code>keysize</code></em></code>] [<code class="option">-c <em class="replaceable"><code>keyfile</code></em></code>] [<code class="option">-h</code>] [<code class="option">-k <em class="replaceable"><code>keyname</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-r <em class="replaceable"><code>randomfile</code></em></code>] [<code class="option">-s <em class="replaceable"><code>address</code></em></code>] [<code class="option">-t <em class="replaceable"><code>chrootdir</code></em></code>] [<code class="option">-u <em class="replaceable"><code>user</code></em></code>]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2642197"></a><h2>DESCRIPTION</h2>
+<a name="id2643626"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">rndc-confgen</strong></span>
       generates configuration files
       for <span><strong class="command">rndc</strong></span>.  It can be used as a
@@ -66,7 +66,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2642263"></a><h2>OPTIONS</h2>
+<a name="id2643692"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-a</span></dt>
 <dd>
@@ -173,7 +173,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2643400"></a><h2>EXAMPLES</h2>
+<a name="id2644215"></a><h2>EXAMPLES</h2>
 <p>
       To allow <span><strong class="command">rndc</strong></span> to be used with
       no manual configuration, run
@@ -190,7 +190,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2653219"></a><h2>SEE ALSO</h2>
+<a name="id2644272"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
       <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
@@ -198,7 +198,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2653257"></a><h2>AUTHOR</h2>
+<a name="id2653321"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.rndc.conf.html b/doc/arm/man.rndc.conf.html
index d8194140..eba641af 100644
--- a/doc/arm/man.rndc.conf.html
+++ b/doc/arm/man.rndc.conf.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.rndc.conf.html,v 1.224 2011-12-22 18:10:11 tbox Exp $ -->
+<!-- $Id: man.rndc.conf.html,v 1.227 2012-01-17 01:15:02 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">rndc.conf</code> </p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2616586"></a><h2>DESCRIPTION</h2>
+<a name="id2615899"></a><h2>DESCRIPTION</h2>
 <p><code class="filename">rndc.conf</code> is the configuration file
       for <span><strong class="command">rndc</strong></span>, the BIND 9 name server control
       utility.  This file has a similar structure and syntax to
@@ -135,7 +135,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2641675"></a><h2>EXAMPLE</h2>
+<a name="id2642558"></a><h2>EXAMPLE</h2>
 <pre class="programlisting">
       options {
         default-server  localhost;
@@ -209,7 +209,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2641933"></a><h2>NAME SERVER CONFIGURATION</h2>
+<a name="id2643226"></a><h2>NAME SERVER CONFIGURATION</h2>
 <p>
       The name server must be configured to accept rndc connections and
       to recognize the key specified in the <code class="filename">rndc.conf</code>
@@ -219,7 +219,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2641959"></a><h2>SEE ALSO</h2>
+<a name="id2643252"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">rndc-confgen</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">mmencode</span>(1)</span>,
@@ -227,7 +227,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2641997"></a><h2>AUTHOR</h2>
+<a name="id2643290"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/man.rndc.html b/doc/arm/man.rndc.html
index 80552d59..769cdf40 100644
--- a/doc/arm/man.rndc.html
+++ b/doc/arm/man.rndc.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2011 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2012 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.rndc.html,v 1.222 2011-12-22 18:10:10 tbox Exp $ -->
+<!-- $Id: man.rndc.html,v 1.225 2012-01-17 01:15:02 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">rndc</code>  [<code class="option">-b <em class="replaceable"><code>source-address</code></em></code>] [<code class="option">-c <em class="replaceable"><code>config-file</code></em></code>] [<code class="option">-k <em class="replaceable"><code>key-file</code></em></code>] [<code class="option">-s <em class="replaceable"><code>server</code></em></code>] [<code class="option">-p <em class="replaceable"><code>port</code></em></code>] [<code class="option">-V</code>] [<code class="option">-y <em class="replaceable"><code>key_id</code></em></code>] {command}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2639699"></a><h2>DESCRIPTION</h2>
+<a name="id2642016"></a><h2>DESCRIPTION</h2>
 <p><span><strong class="command">rndc</strong></span>
       controls the operation of a name
       server.  It supersedes the <span><strong class="command">ndc</strong></span> utility
@@ -79,7 +79,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2639749"></a><h2>OPTIONS</h2>
+<a name="id2642066"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-b <em class="replaceable"><code>source-address</code></em></span></dt>
 <dd><p>
@@ -151,7 +151,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2641408"></a><h2>LIMITATIONS</h2>
+<a name="id2642291"></a><h2>LIMITATIONS</h2>
 <p><span><strong class="command">rndc</strong></span>
       does not yet support all the commands of
       the BIND 8 <span><strong class="command">ndc</strong></span> utility.
@@ -165,7 +165,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2641438"></a><h2>SEE ALSO</h2>
+<a name="id2642322"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
       <span class="citerefentry"><span class="refentrytitle">rndc-confgen</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
@@ -175,7 +175,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2641835"></a><h2>AUTHOR</h2>
+<a name="id2642377"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/doc/arm/pkcs11.xml b/doc/arm/pkcs11.xml
index 23bf5fdb..5e1ef62c 100644
--- a/doc/arm/pkcs11.xml
+++ b/doc/arm/pkcs11.xml
@@ -2,7 +2,7 @@
                "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
                [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2010  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2010, 2012  Internet Systems Consortium, Inc. ("ISC")
  -
  - Permission to use, copy, modify, and/or distribute this software for any
  - purpose with or without fee is hereby granted, provided that the above
@@ -17,7 +17,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: pkcs11.xml,v 1.3 2010-02-06 07:42:02 marka Exp $ -->
+<!-- $Id: pkcs11.xml,v 1.7 2012-01-16 22:50:12 each Exp $ -->
 
 <sect1 id="pkcs11">
   <title>PKCS #11 (Cryptoki) support</title>
@@ -68,12 +68,15 @@
         is an example of such a device.</para>
       </listitem>
     </itemizedlist>
-    <para>The modified OpenSSL code is included in the BIND 9.7.0
-    release, in the form of a context diff against the latest OpenSSL.
+    <para>The modified OpenSSL code is included in the BIND 9 release,
+        in the form of a context diff against the latest verions of
+        OpenSSL.  OpenSSL 0.9.8 and 1.0.0 are both supported; there are
+        separate diffs for each version.  In the examples to follow,
+        we use OpenSSL 0.9.8, but the same methods work with OpenSSL 1.0.0.
     </para>
     <note>
-      The latest OpenSSL version at the time of the BIND release
-      is 0.9.8l.
+      The latest OpenSSL versions at the time of the BIND release
+      are 0.9.8s and 1.0.0f.
       ISC will provide an updated patch as new versions of OpenSSL
       are released. The version number in the following examples
       is expected to change.</note>
@@ -82,18 +85,18 @@
     necessary to build OpenSSL with this patch in place and inform
     it of the path to the HSM-specific PKCS #11 provider
     library.</para>
-    <para>Obtain OpenSSL 0.9.8l:</para>
+    <para>Obtain OpenSSL 0.9.8s:</para>
     <screen>
-$ <userinput>wget <ulink>http://www.openssl.org/source/openssl-0.9.8l.tar.gz</ulink></userinput>
+$ <userinput>wget <ulink>http://www.openssl.org/source/openssl-0.9.8s.tar.gz</ulink></userinput>
 </screen>
     <para>Extract the tarball:</para>
     <screen>
-$ <userinput>tar zxf openssl-0.9.8l.tar.gz</userinput>
+$ <userinput>tar zxf openssl-0.9.8s.tar.gz</userinput>
 </screen>
     <para>Apply the patch from the BIND 9 release:</para>
     <screen>
-$ <userinput>patch -p1 -d openssl-0.9.8l \
-            &lt; bind-9.7.0/bin/pkcs11/openssl-0.9.8l-patch</userinput>
+$ <userinput>patch -p1 -d openssl-0.9.8s \
+            &lt; bind9/bin/pkcs11/openssl-0.9.8s-patch</userinput>
 </screen>
     <note>(Note that the patch file may not be compatible with the
     "patch" utility on all operating systems. You may need to
@@ -124,7 +127,7 @@ $ <userinput>cp pkcs11.GCC4.0.2.so.4.05 /opt/pkcs11/usr/lib/libpkcs11.so</userin
       <para>Finally, the Keyper library requires threads, so we
       must specify -pthread.</para>
       <screen>
-$ <userinput>cd openssl-0.9.8l</userinput>
+$ <userinput>cd openssl-0.9.8s</userinput>
 $ <userinput>./Configure linux-generic32 -m32 -pthread \
             --pk11-libname=/opt/pkcs11/usr/lib/libpkcs11.so \
             --pk11-flavor=sign-only \
@@ -145,7 +148,7 @@ $ <userinput>./Configure linux-generic32 -m32 -pthread \
       <para>In this example, we are building on Solaris x86 on an
       AMD64 system.</para>
       <screen>
-$ <userinput>cd openssl-0.9.8l</userinput>
+$ <userinput>cd openssl-0.9.8s</userinput>
 $ <userinput>./Configure solaris64-x86_64-cc \
             --pk11-libname=/usr/lib/64/libpkcs11.so \
             --pk11-flavor=crypto-accelerator \
@@ -156,36 +159,74 @@ $ <userinput>./Configure solaris64-x86_64-cc \
       <para>After configuring, run 
       <command>make</command> and 
       <command>make test</command>.</para>
-      <para>Once you have built OpenSSL, run
-      "<command>apps/openssl engine pkcs11</command>" to confirm
-      that PKCS #11 support was compiled in correctly. The output
-      should be one of the following lines, depending on the flavor
-      selected:</para>
+    </sect3>
+    <sect3>
+      <!-- Example 3 -->
+      <title>Building OpenSSL for SoftHSM</title>
+      <para>SoftHSM is a software library provided by the OpenDNSSEC
+      project (http://www.opendnssec.org) which provides a PKCS#11
+      interface to a virtual HSM, implemented in the form of encrypted
+      data on the local filesystem.  It uses the Botan library for
+      encryption and SQLite3 for data storage.  Though less secure
+      than a true HSM, it can provide more secure key storage than
+      traditional key files, and can allow you to experiment with
+      PKCS#11 when an HSM is not available.</para>
+      <para>The SoftHSM cryptographic store must be installed and
+      initialized before using it with OpenSSL, and the SOFTHSM_CONF
+      environment variable must always point to the SoftHSM configuration
+      file:</para>
       <screen>
-        (pkcs11) PKCS #11 engine support (sign only)
+$ <userinput> cd softhsm-1.3.0 </userinput>
+$ <userinput> configure --prefix=/opt/pkcs11/usr </userinput>
+$ <userinput> make </userinput>
+$ <userinput> make install </userinput>
+$ <userinput> export SOFTHSM_CONF=/opt/pkcs11/softhsm.conf </userinput>
+$ <userinput> echo "0:/opt/pkcs11/softhsm.db" > $SOFTHSM_CONF </userinput>
+$ <userinput> /opt/pkcs11/usr/bin/softhsm --init-token 0 --slot 0 --label softhsm </userinput>
 </screen>
-      <para>Or:</para>
+      <para>SoftHSM can perform all cryptographic operations, but
+      since it only uses your system CPU, there is no need to use it
+      for anything but signing.  Therefore, we choose the 'sign-only'
+      flavor when building OpenSSL.</para>
       <screen>
-        (pkcs11) PKCS #11 engine support (crypto accelerator)
+$ <userinput>cd openssl-0.9.8s</userinput>
+$ <userinput>./Configure linux-x86_64 -pthread \
+            --pk11-libname=/opt/pkcs11/usr/lib/libpkcs11.so \
+            --pk11-flavor=sign-only \
+            --prefix=/opt/pkcs11/usr</userinput>
 </screen>
-      <para>Next, run
-      "<command>apps/openssl engine pkcs11 -t</command>". This will
-      attempt to initialize the PKCS #11 engine. If it is able to
-      do so successfully, it will report
-      <quote><literal>[ available ]</literal></quote>.</para>
-      <para>If the output is correct, run
-      "<command>make install</command>" which will install the
-      modified OpenSSL suite to 
-      <filename>/opt/pkcs11/usr</filename>.</para>
+      <para>After configuring, run "<command>make</command>"
+      and "<command>make test</command>".</para>
     </sect3>
+    <para>Once you have built OpenSSL, run
+    "<command>apps/openssl engine pkcs11</command>" to confirm
+    that PKCS #11 support was compiled in correctly. The output
+    should be one of the following lines, depending on the flavor
+    selected:</para>
+    <screen>
+        (pkcs11) PKCS #11 engine support (sign only)
+</screen>
+    <para>Or:</para>
+    <screen>
+        (pkcs11) PKCS #11 engine support (crypto accelerator)
+</screen>
+    <para>Next, run
+    "<command>apps/openssl engine pkcs11 -t</command>". This will
+    attempt to initialize the PKCS #11 engine. If it is able to
+    do so successfully, it will report
+    <quote><literal>[ available ]</literal></quote>.</para>
+    <para>If the output is correct, run
+    "<command>make install</command>" which will install the
+    modified OpenSSL suite to 
+    <filename>/opt/pkcs11/usr</filename>.</para>
   </sect2>
   <sect2>
     <title>Building BIND 9 with PKCS#11</title>
     <para>When building BIND 9, the location of the custom-built
     OpenSSL library must be specified via configure.</para>
     <sect3>
-      <!-- Example 3 -->
-      <title>Configuring BIND 9 for Linux</title>
+      <!-- Example 4 -->
+      <title>Configuring BIND 9 for Linux with the AEP Keyper</title>
       <para>To link with the PKCS #11 provider, threads must be
       enabled in the BIND 9 build.</para>
       <para>The PKCS #11 library for the AEP Keyper is currently
@@ -193,19 +234,19 @@ $ <userinput>./Configure solaris64-x86_64-cc \
       64-bit host, we must force a 32-bit build by adding "-m32" to
       the CC options on the "configure" command line.</para>
       <screen>
-$ <userinput>cd ../bind-9.7.0</userinput>
+$ <userinput>cd ../bind9</userinput>
 $ <userinput>./configure CC="gcc -m32" --enable-threads \
            --with-openssl=/opt/pkcs11/usr \
            --with-pkcs11=/opt/pkcs11/usr/lib/libpkcs11.so</userinput>
 </screen>
     </sect3>
     <sect3>
-      <!-- Example 4 -->
-      <title>Configuring BIND 9 for Solaris</title>
+      <!-- Example 5 -->
+      <title>Configuring BIND 9 for Solaris with the SCA 6000</title>
       <para>To link with the PKCS #11 provider, threads must be
       enabled in the BIND 9 build.</para>
       <screen>
-$ <userinput>cd ../bind-9.7.0</userinput>
+$ <userinput>cd ../bind9</userinput>
 $ <userinput>./configure CC="cc -xarch=amd64" --enable-threads \
             --with-openssl=/opt/pkcs11/usr \
             --with-pkcs11=/usr/lib/64/libpkcs11.so</userinput>
@@ -217,10 +258,22 @@ $ <userinput>./configure CC="cc -xarch=amd64" --enable-threads \
       same as the --prefix argument to the OpenSSL
       Configure).</para>
     </sect3>
+    <sect3>
+      <!-- Example 6 -->
+      <title>Configuring BIND 9 for SoftHSM</title>
+      <screen>
+$ <userinput>cd ../bind9</userinput>
+$ <userinput>./configure --enable-threads \
+           --with-openssl=/opt/pkcs11/usr \
+           --with-pkcs11=/opt/pkcs11/usr/lib/libpkcs11.so</userinput>
+</screen>
+    </sect3>
     <para>After configuring, run
     "<command>make</command>",
     "<command>make test</command>" and
     "<command>make install</command>".</para>
+    <para>(Note: If "make test" fails in the "pkcs11" system test, you may
+    have forgotten to set the SOFTHSM_CONF environment variable.)</para>
   </sect2>
   <sect2>
     <title>PKCS #11 Tools</title>
diff --git a/doc/draft/draft-faltstrom-uri-06.txt b/doc/draft/draft-faltstrom-uri-06.txt
deleted file mode 100644
index cf4fd832..00000000
--- a/doc/draft/draft-faltstrom-uri-06.txt
+++ /dev/null
@@ -1,729 +0,0 @@
-
-
-
-Network Working Group                                       P. Faltstrom
-Internet-Draft                                                     Cisco
-Updates: 3404, 3959                                           O. Kolkman
-(if approved)                                                      NLNet
-Intended status: Standards Track                        October 11, 2010
-Expires: April 14, 2011
-
-
-       The Uniform Resource Identifier (URI) DNS Resource Record
-                       draft-faltstrom-uri-06.txt
-
-Abstract
-
-   This document defines a new DNS resource record, called the Uniform
-   Resource Identifier (URI) RR, for publishing mappings from hostnames
-   to URIs.
-
-Status of this Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at http://datatracker.ietf.org/drafts/current/.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   This Internet-Draft will expire on April 14, 2011.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-
-Faltstrom & Kolkman      Expires April 14, 2011                 [Page 1]
-
-Internet-Draft             URI Resource Record              October 2010
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  3
-   3.  DNS considerations . . . . . . . . . . . . . . . . . . . . . .  4
-   4.  The format of the URI RR . . . . . . . . . . . . . . . . . . .  4
-     4.1.  Ownername, class and type  . . . . . . . . . . . . . . . .  4
-     4.2.  Priority . . . . . . . . . . . . . . . . . . . . . . . . .  5
-     4.3.  Weight . . . . . . . . . . . . . . . . . . . . . . . . . .  5
-     4.4.  Target . . . . . . . . . . . . . . . . . . . . . . . . . .  5
-     4.5.  URI RDATA Wire Format  . . . . . . . . . . . . . . . . . .  6
-   5.  Definition of the flag 'D' for NAPTR records . . . . . . . . .  6
-   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-     6.1.  Homepage at one domain, but two domains in use . . . . . .  7
-   7.  Relation to S-NAPTR  . . . . . . . . . . . . . . . . . . . . .  7
-   8.  Relation to U-NAPTR  . . . . . . . . . . . . . . . . . . . . .  7
-   9.  Relation to SRV  . . . . . . . . . . . . . . . . . . . . . . .  8
-   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-     10.1. Registration of the URI Resource Record Type . . . . . . .  8
-     10.2. Registration of services . . . . . . . . . . . . . . . . .  8
-   11. Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
-   Appendix A.  RRTYPE Allocation Request . . . . . . . . . . . . . .  9
-   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     13.1. Normative References . . . . . . . . . . . . . . . . . . . 12
-     13.2. Non-normative references . . . . . . . . . . . . . . . . . 12
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom & Kolkman      Expires April 14, 2011                 [Page 2]
-
-Internet-Draft             URI Resource Record              October 2010
-
-
-1.  Introduction
-
-   This document explains the use of the Domain Name System (DNS) for
-   the storage of URIs, and how to resolve hostnames to such URIs that
-   can be used by various applications.  For resolution the application
-   need to know both the hostname and the protocol that the URI is to be
-   used for.  The protocol is registered by IANA.
-
-   Currently, looking up URIs given a hostname uses the DDDS [RFC3401]
-   application framework with the DNS as a database as specified in RFC
-   3404 [RFC3404].  This has a number of implications such as the
-   inability to select what NAPTR records that match the query are
-   interesting.  The RRSet returned will always consist of all URIs
-   "connected" with the domain in question.
-
-   The URI resource record specified in this document enables the
-   querying party to select which ones of the NAPTR records one is
-   interested in.  This because data in the service field of the NAPTR
-   record is included in the owner part of the URI resource record type.
-
-   Querying for URI resource records is not replacing querying for NAPTR
-   resource records (or use of S-NAPTR [RFC3958]).  Instead, the URI
-   resource record type provides a complementary mechanism to use when
-   one already knows what service field is interesting.  With it, one
-   can directly query for the specific subset of the otherwise possibly
-   large RRSet given back when querying for NAPTR resource records.
-
-   This document updates RFC 3958 and RFC 3404 by adding the flag "D" to
-   the list of defined terminal flags in section 2.2.3 of RFC 3958 and
-   4.3 of RFC 3404.
-
-   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].
-
-
-2.  Applicability Statement
-
-   In general, it is expected that URI records will be used by clients
-   for applications where the relevant protocol to be used is known,
-   but, for example, an extra abstraction is needed in order to separate
-   a domain name from a point of service (as addressed by the URI).  One
-   example of such a situation is when an organisation has many domain
-   names, but only one official web page.
-
-   Applications MUST know the specific service fields to prepend the
-   hostname with.  Using repetitive queries for URI records MUST NOT be
-
-
-
-Faltstrom & Kolkman      Expires April 14, 2011                 [Page 3]
-
-Internet-Draft             URI Resource Record              October 2010
-
-
-   a replacement for querying for NAPTR records according to the NAPTR
-   (DDDS) or S-NAPTR algorithms.  NAPTR records serve the purpose to
-   discover the various services and URIs for looking up access points
-   for a given service.  Those are two very different kinds of needs.
-
-
-3.  DNS considerations
-
-   Using prefix labels, such as underscored service tags, prevents the
-   use of wildcards, as constructs as _s2._s1.*.example.net. are not
-   possible in the DNS, see RFC 4592 [RFC4592].  Besides, underscored
-   service tags used for the URI RR (based on the NAPTR service
-   descriptions) may have slightly different semantics than service tags
-   used for underscored prefix labels that are used in combination with
-   other (yet unspecified) RR types.  This may cause subtle management
-   problems when delegation structure that has developed within the
-   context of URI RRs is also to be used for other RR types.  Since the
-   service labels might be overloaded, applications should carefully
-   check that the application level protocol is indeed the protocol they
-   expect.
-
-   Subtle management issues may also arise when the delegations from
-   service to sub service label involves several parties and different
-   stake holders.
-
-
-4.  The format of the URI RR
-
-   This is the presentation format of the URI RR:
-
-
-       Ownername TTL Class URI Priority Weight Target
-
-
-   The URI RR does not cause any kind of Additional Section processing.
-
-4.1.  Ownername, class and type
-
-   The URI ownername is subject to special conventions.
-
-   Just like the SRV RR [RFC2782] the URI RR has service information
-   encoded in its ownername.  In order to encode the service for a
-   specific owner name one uses service parameters.  Valid service
-   parameters used are those used for SRV resource records, or
-   registered by IANA for Enumservice Registrations.  The Enumservice
-   Registration parameters are reversed (subtype(s) before type),
-   prepended with an underscore (_) and prepended to the owner name in
-   separate labels.  The underscore is prepended to the service
-
-
-
-Faltstrom & Kolkman      Expires April 14, 2011                 [Page 4]
-
-Internet-Draft             URI Resource Record              October 2010
-
-
-   parameters to avoid collisions with DNS labels that occur in nature,
-   and the order is reversed to make it possible to do delegations, if
-   needed, to different zones (and therefore providers of DNS).
-
-   It should be noted that the usage of a prefix must be described in
-   detail in for example the Enumservice Registration documentation, or
-   in a specific document that clarifies potential overload of
-   parameters in the same URI.  Specifically, registered URI schemes are
-   not automatically acceptable as a service.  With the HTTP scheme, one
-   can for example have multiple methods (GET, PUT, etc), and this with
-   the same URI.
-
-   For example, suppose we are looking for the URI for a service with
-   Service Parameter "A:B:C" for host example.com..  Then we would query
-   for (QNAME,QTYPE)=("_C._B._A.example.com","URI")
-
-   The type number for the URI record is TBD1 (to be assigned by IANA).
-
-   The URI resource record is class independent.
-
-   The URI RR has no special TTL requirements.
-
-4.2.  Priority
-
-   The priority of the target URI in this RR.  Its range is 0-65535.  A
-   client MUST attempt to contact the URI with the lowest-numbered
-   priority it can reach; URIs with the same priority SHOULD be tried in
-   the order defined by the weight field.
-
-4.3.  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.
-
-4.4.  Target
-
-   The URI of the target, enclosed in double-quote characters ('"').
-   Resolution of the URI is according to the definitions for the Scheme
-   of the URI.
-
-   The URI is encoded as one or more <character-string> RFC1035 section
-   3.3 [RFC1035].
-
-
-
-
-
-
-
-Faltstrom & Kolkman      Expires April 14, 2011                 [Page 5]
-
-Internet-Draft             URI Resource Record              October 2010
-
-
-4.5.  URI RDATA Wire Format
-
-   The RDATA for a URI RR consists of a 2 octet Priority field, a two
-   octet Weight field, and a variable length target field.
-
-   Priority and Weight are unsigned integers in network byte order.
-
-   The Target field contains the URI (without the enclosing double-
-   quote characters used in the presentation format), encoded as a
-   sequence of one or more <character-string> (as specified in section
-   3.3 of RFC 1035 [RFC1035]), where all but the last <character-string>
-   are filled up to the maximum length of 255 octets.
-
-   The Target field can also contain an IRI, but with the additional
-   requirements that it is in UTF-8 [RFC3629] and possible to convert to
-   a URI according to section 3.1 of RFC 3987 [RFC3987] and back again
-   to an IRI according to section 3.2.  Other character sets than UTF-8
-   are not allowed.  The domain name part of the IRI can be either an
-   U-LABEL or A-LABEL as defined in RFC 5890 [RFC5890].
-
-
-                        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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |          Priority             |          Weight               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                                                               /
-   /                             Target                            /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-5.  Definition of the flag 'D' for NAPTR records
-
-   This document specifies the flag "D" for use as a flag in NAPTR
-   records.  The flag indicate a terminal NAPTR record because it
-   denotes the end of the DDDS/NAPTR processing rules.  In the case of a
-   "D" flag, the Replacement field in the NAPTR record, prepended with
-   the service flags, is used as the Owner of a DNS query for URI
-   records, and normal URI processing as defined in this document is
-   applied.
-
-   The replacement field MUST NOT include any of the service parameters.
-   Those are to be prepended (together with underscore) as described in
-   other places in this document.
-
-   The Regexp field in the NAPTR record MUST be empty when the 'D' flag
-
-
-
-Faltstrom & Kolkman      Expires April 14, 2011                 [Page 6]
-
-Internet-Draft             URI Resource Record              October 2010
-
-
-   is in use.
-
-
-6.  Examples
-
-6.1.  Homepage at one domain, but two domains in use
-
-   An organisation has the domain names example.com and example.net, but
-   the official URI http://www.example.com/.  Given the service type
-   "web" and subtype "http" (from the IANA registry), the following URI
-   Resource Records could be made available in the respective zones
-   (example.com and example.net):
-
-
-   $ORIGIN example.com.
-   _http._web    IN URI 10 1 "http://www.example.com/"
-
-   $ORIGIN example.net.
-   _http._web    IN URI 10 1 "http://www.example.com/"
-
-
-
-7.  Relation to S-NAPTR
-
-   The URI resource record type is not a replacement for the S-NAPTR.
-   It is instead an extension and the seond step of the S-NAPTR
-   resolution can resolve a URI resource record instead of using SRV
-   records and yet another algorithm for how to use SRV records for the
-   specific protocol.
-
-
-   $ORIGIN example.com.
-   ;;       order pref flags
-     IN NAPTR 100   10   "s"   "EM:ProtA"               ( ; service
-                               ""                         ; regexp
-                               _ProtA._tcp.example.com.   ; replacement
-   _ProtA._tcp IN URI "schemeA:service.example.com/example"
-
-
-
-8.  Relation to U-NAPTR
-
-   The URI Resource Record Type, together with S-NAPTR, can be viewed as
-   a replacement for the U-NAPTR.  The URI Resource Record Type is
-   though only interesting when one know a base domain name, a protocol
-   and service so that one can compose the record to look up.  NAPTR
-   records of any kind are used to look up what services exists for a
-   certain domain, which is one step before the URI resource record is
-
-
-
-Faltstrom & Kolkman      Expires April 14, 2011                 [Page 7]
-
-Internet-Draft             URI Resource Record              October 2010
-
-
-   used.
-
-
-9.  Relation to SRV
-
-   The URI Resource Record Type can be viewed as a replacement for the
-   SRV record.  This because it like the SRV record can only be looked
-   up if one know the base domain, the protocol and the service.  It has
-   a similar functionality, but instead of returning a hostname and port
-   number, the URI record return a full URI.  As such, it can be viewed
-   as a more powerful resource record than SRV.
-
-
-10.  IANA Considerations
-
-10.1.  Registration of the URI Resource Record Type
-
-   IANA has assigned Resource Record Type TBD1 for the URI Resource
-   Record Type and added the line depicted below to the registry named
-   Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395
-   [RFC5395] and located at
-   http://www.iana.org/assignments/dns-parameters.
-
-
-   TYPE         Value and meaning                              Reference
-   -----------  ---------------------------------------------  ---------
-   URI          TBD1 a URI for a service (per the owner name)  [RFCXXXX]
-
-
-10.2.  Registration of services
-
-   No new registry is needed for the registration of services as the
-   Enumservice Registrations registry is used also for the URI resource
-   record type.
-
-
-11.  Security Considerations
-
-   The authors do not believe this resource record cause any new
-   security problems.  Deployment must though be done in a proper way as
-   misconfiguration of this resource record might make it impossible to
-   reach the service that was originally intended to be accessed.
-
-   Using the URI resource record together with security mechanisms that
-   relies on verification of authentication of hostnames, like TLS,
-   makes it important to choose the correct domain name when doing the
-   comparison.
-
-
-
-
-Faltstrom & Kolkman      Expires April 14, 2011                 [Page 8]
-
-Internet-Draft             URI Resource Record              October 2010
-
-
-   The basic mechanism works as follows:
-
-   1.   Announce the fact example.com is hosted at example.org (with
-        some URL) in DNS
-   2.   Secure the URI resource record with DNSSEC.
-   3.   Verify the TLS (for example) certificate for the connection to
-        example.org matches, i.e. use the hostname in the URI and not
-        the hostname used originally when looking up the URI resource
-        record.
-   4.   If needed, do application layer authentication etc over the then
-        encrypted connection.
-
-   What also can happen is that the URI in the resource record type has
-   errors in it.  Applications using the URI resource record type for
-   resolution should behave similarly as if the user typed (or copy and
-   pasted) the URI.  At least it must be clear to the user that the
-   error is not due to any error from his side.
-
-   One SHOULD not include userinfo (see User Information, Section 3.2.1,
-   in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record
-   as DNS data must be viewed as publicly available information.
-
-
-12.  Acknowledgements
-
-   Ideas on how to split the two different kind of queries "What
-   services exists for this domain name" and "What is the URI for this
-   service" came from Scott Bradner and Lawrence Conroy.  Other people
-   that have contributed to this document include Richard Barnes, Leslie
-   Daigle, Olafur Gudmundsson, Ted Hardie, Peter Koch and Penn Pfautz.
-
-
-Appendix A.  RRTYPE Allocation Request
-
-   A.   Submission Date:
-
-        May 23, 2009
-
-   B.   Submission Type:
-
-        [X] New RRTYPE
-        [ ] Modification to existing RRTYPE
-
-   C.   Contact Information for submitter:
-
-        Name: Patrik Faltstrom
-        Email Address: paf@cisco.com
-        International telephone number: +46-8-6859131
-
-
-
-Faltstrom & Kolkman      Expires April 14, 2011                 [Page 9]
-
-Internet-Draft             URI Resource Record              October 2010
-
-
-        Other contact handles:
-        (Note: This information will be publicly posted.)
-
-   D.   Motivation for the new RRTYPE application?
-
-        There is no easy way to get from a domain name to a URI (or
-        IRI).  Some mechanisms exists via use of the NAPTR [RFC3403]
-        resource record.  That implies quite complicated rules that are
-        simplified via the S-NAPTR [RFC3958] specification.  But, the
-        ability to directly look up a URI still exists.  This
-        specification uses a prefix based naming mechanism originated in
-        the definition of the SRV [RFC2782] resource record, and the
-        RDATA is a URI, encoded as one text field.
-
-        See also above (Section 1).
-
-   E.   Description of the proposed RR type.
-
-        The format of the URI resource record is as follows:
-
-
-        Ownername TTL Class URI Priority Weight Target
-
-
-        The URI RR has service information encoded in its ownername.  In
-        order to encode the service for a specific owner name one uses
-        service parameters.  Valid service parameters used are either
-        Enumservice Registrations registered by IANA, or prefixes used
-        for the SRV resource record.
-
-        The wire format of the RDATA 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
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |          Priority             |          Weight               |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       /                                                               /
-       /                             Target                            /
-       /                                                               /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-
-
-Faltstrom & Kolkman      Expires April 14, 2011                [Page 10]
-
-Internet-Draft             URI Resource Record              October 2010
-
-
-   F.   What existing RRTYPE or RRTYPEs come closest to filling that
-        need and why are they unsatisfactory?
-
-        The RRTYPE that come closest is the NAPTR resource record.  It
-        is for example used in the DDDS and S-NAPTR algorithms.  The
-        main problem with the NAPTR is that selection of what record (or
-        records) one is interested in is based on data stored in the
-        RDATA portion of the NAPTR resource record.  This, as explained
-        in RFC 5507 [RFC5507], is not optimal for DNS lookups.  Further,
-        most applications using NAPTR resource records uses regular
-        expression based rewrite rules for creation of the URI, and that
-        has shown be complicated to implement.
-
-        The second closest RRTYPE is the SRV record that given a
-        prefixed based naming just like is suggested for the URI
-        resource record, one get back a port number and domain name.
-        This can also be used for creation of a URI, but, only URIs
-        without path components.
-
-   G.   What mnemonic is requested for the new RRTYPE (optional)?
-
-        URI
-
-   H.   Does the requested RRTYPE make use of any existing IANA Registry
-        or require the creation of a new IANA sub-registry in DNS
-        Parameters?
-
-        Yes, partially.
-
-        One of the mechanisms to select a service is to use the
-        Enumservice Registry managed by IANA.  Another is to use
-        services and protocols used for SRV records.
-
-   I.   Does the proposal require/expect any changes in DNS servers/
-        resolvers that prevent the new type from being processed as an
-        unknown RRTYPE (see [RFC3597])?
-
-        No
-
-   J.   Comments:
-
-        None
-
-
-
-13.  References
-
-
-
-
-
-Faltstrom & Kolkman      Expires April 14, 2011                [Page 11]
-
-Internet-Draft             URI Resource Record              October 2010
-
-
-13.1.  Normative References
-
-   [E164]     ITU-T, "The International Public Telecommunication Number
-              Plan", Recommendation E.164, May 1997.
-
-   [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.
-
-   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
-              10646", STD 63, RFC 3629, November 2003.
-
-   [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application
-              Service Location Using SRV RRs and the Dynamic Delegation
-              Discovery Service (DDDS)", RFC 3958, January 2005.
-
-   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
-              Identifiers (IRIs)", RFC 3987, January 2005.
-
-   [RFC5395]  Eastlake, D., "Domain Name System (DNS) IANA
-              Considerations", BCP 42, RFC 5395, November 2008.
-
-   [RFC5890]  Klensin, J., "Internationalized Domain Names for
-              Applications (IDNA): Definitions and Document Framework",
-              RFC 5890, August 2010.
-
-13.2.  Non-normative references
-
-   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-              specifying the location of services (DNS SRV)", RFC 2782,
-              February 2000.
-
-   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
-              Part One: The Comprehensive DDDS", RFC 3401, October 2002.
-
-   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
-              Part Three: The Domain Name System (DNS) Database",
-              RFC 3403, October 2002.
-
-   [RFC3404]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
-              Part Four: The Uniform Resource Identifiers (URI)",
-              RFC 3404, October 2002.
-
-   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-              Resource Identifier (URI): Generic Syntax", STD 66,
-              RFC 3986, January 2005.
-
-
-
-Faltstrom & Kolkman      Expires April 14, 2011                [Page 12]
-
-Internet-Draft             URI Resource Record              October 2010
-
-
-   [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
-              System", RFC 4592, July 2006.
-
-   [RFC4848]  Daigle, L., "Domain-Based Application Service Location
-              Using URIs and the Dynamic Delegation Discovery Service
-              (DDDS)", RFC 4848, April 2007.
-
-   [RFC5507]  IAB, Faltstrom, P., Austein, R., and P. Koch, "Design
-              Choices When Expanding the DNS", RFC 5507, April 2009.
-
-
-Authors' Addresses
-
-   Patrik Faltstrom
-   Cisco Systems
-
-   Email: paf@cisco.com
-
-
-   Olaf Kolkman
-   NLnet Labs
-
-   Email: olaf@NLnetLabs.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom & Kolkman      Expires April 14, 2011                [Page 13]
-
-
diff --git a/doc/draft/draft-ietf-6man-text-addr-representation-07.txt b/doc/draft/draft-ietf-6man-text-addr-representation-07.txt
deleted file mode 100644
index 3a9f1112..00000000
--- a/doc/draft/draft-ietf-6man-text-addr-representation-07.txt
+++ /dev/null
@@ -1,785 +0,0 @@
-
-
-
-IPv6 Maintenance Working Group                               S. Kawamura
-Internet-Draft                                         NEC BIGLOBE, Ltd.
-Updates: 4291 (if approved)                                 M. Kawashima
-Intended status: Standards Track                NEC AccessTechnica, Ltd.
-Expires: August 29, 2010                               February 25, 2010
-
-
-         A Recommendation for IPv6 Address Text Representation
-              draft-ietf-6man-text-addr-representation-07
-
-Abstract
-
-   As IPv6 deployment increases there will be a dramatic increase in the
-   need to use IPv6 addresses in text.  While the IPv6 address
-   architecture in RFC 4291 section 2.2 describes a flexible model for
-   text representation of an IPv6 address this flexibility has been
-   causing problems for operators, system engineers, and users.  This
-   document defines a canonical textual representation format.  It does
-   not define a format for internal storage, such as within an
-   application or database.  It is expected that the canonical format is
-   followed by humans and systems when representing IPv6 addresses as
-   text, but all implementations must accept and be able to handle any
-   legitimate RFC 4291 format.
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 29, 2010.
-
-Copyright Notice
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 1]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 2]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
-   2.  Text Representation Flexibility of RFC4291 . . . . . . . . . .  4
-     2.1.  Leading Zeros in a 16 Bit Field  . . . . . . . . . . . . .  4
-     2.2.  Zero Compression . . . . . . . . . . . . . . . . . . . . .  5
-     2.3.  Uppercase or Lowercase . . . . . . . . . . . . . . . . . .  5
-   3.  Problems Encountered with the Flexible Model . . . . . . . . .  6
-     3.1.  Searching  . . . . . . . . . . . . . . . . . . . . . . . .  6
-       3.1.1.  General Summary  . . . . . . . . . . . . . . . . . . .  6
-       3.1.2.  Searching Spreadsheets and Text Files  . . . . . . . .  6
-       3.1.3.  Searching with Whois . . . . . . . . . . . . . . . . .  6
-       3.1.4.  Searching for an Address in a Network Diagram  . . . .  7
-     3.2.  Parsing and Modifying  . . . . . . . . . . . . . . . . . .  7
-       3.2.1.  General Summary  . . . . . . . . . . . . . . . . . . .  7
-       3.2.2.  Logging  . . . . . . . . . . . . . . . . . . . . . . .  7
-       3.2.3.  Auditing: Case 1 . . . . . . . . . . . . . . . . . . .  7
-       3.2.4.  Auditing: Case 2 . . . . . . . . . . . . . . . . . . .  8
-       3.2.5.  Verification . . . . . . . . . . . . . . . . . . . . .  8
-       3.2.6.  Unexpected Modifying . . . . . . . . . . . . . . . . .  8
-     3.3.  Operating  . . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.3.1.  General Summary  . . . . . . . . . . . . . . . . . . .  8
-       3.3.2.  Customer Calls . . . . . . . . . . . . . . . . . . . .  8
-       3.3.3.  Abuse  . . . . . . . . . . . . . . . . . . . . . . . .  9
-     3.4.  Other Minor Problems . . . . . . . . . . . . . . . . . . .  9
-       3.4.1.  Changing Platforms . . . . . . . . . . . . . . . . . .  9
-       3.4.2.  Preference in Documentation  . . . . . . . . . . . . .  9
-       3.4.3.  Legibility . . . . . . . . . . . . . . . . . . . . . .  9
-   4.  A Recommendation for IPv6 Text Representation  . . . . . . . .  9
-     4.1.  Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10
-     4.2.  "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
-       4.2.1.  Shorten As Much As Possible  . . . . . . . . . . . . . 10
-       4.2.2.  Handling One 16 Bit 0 Field  . . . . . . . . . . . . . 10
-       4.2.3.  Choice in Placement of "::"  . . . . . . . . . . . . . 10
-     4.3.  Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10
-   5.  Text Representation of Special Addresses . . . . . . . . . . . 10
-   6.  Notes on Combining IPv6 Addresses with Port Numbers  . . . . . 11
-   7.  Prefix Representation  . . . . . . . . . . . . . . . . . . . . 12
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
-   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
-     11.2. Informative References . . . . . . . . . . . . . . . . . . 13
-   Appendix A.  For Developers  . . . . . . . . . . . . . . . . . . . 13
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
-
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 3]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-1.  Introduction
-
-   A single IPv6 address can be text represented in many ways.  Examples
-   are shown below.
-
-      2001:db8:0:0:1:0:0:1
-
-      2001:0db8:0:0:1:0:0:1
-
-      2001:db8::1:0:0:1
-
-      2001:db8::0:1:0:0:1
-
-      2001:0db8::1:0:0:1
-
-      2001:db8:0:0:1::1
-
-      2001:db8:0000:0:1::1
-
-      2001:DB8:0:0:1::1
-
-   All of the above examples represent the same IPv6 address.  This
-   flexibility has caused many problems for operators, systems
-   engineers, and customers.  The problems are noted in Section 3.
-   Also, a canonical representation format to avoid problems is
-   introduced in Section 4.
-
-1.1.  Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-2.  Text Representation Flexibility of RFC4291
-
-   Examples of flexibility in Section 2.2 of [RFC4291] are described
-   below.
-
-2.1.  Leading Zeros in a 16 Bit Field
-
-      'It is not necessary to write the leading zeros in an individual
-      field.'
-
-   Conversely it is also not necessary to omit leading zeros.  This
-   means that, it is possible to select from such as the following
-   example.  The final 16 bit field is different, but all these
-   addresses represent the same address.
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 4]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
-
-2.2.  Zero Compression
-
-      'A special syntax is available to compress the zeros.  The use of
-      "::" indicates one or more groups of 16 bits of zeros.'
-
-   It is possible to select whether or not to omit just one 16 bits of
-   zeros.
-
-      2001:db8:aaaa:bbbb:cccc:dddd::1
-
-      2001:db8:aaaa:bbbb:cccc:dddd:0:1
-
-   In case where there is more than one zero fields, there is a choice
-   of how many fields can be shortened.
-
-      2001:db8:0:0:0::1
-
-      2001:db8:0:0::1
-
-      2001:db8:0::1
-
-      2001:db8::1
-
-   In addition, [RFC4291] in section 2.2 notes,
-
-      'The "::" can only appear once in an address.'
-
-   This gives a choice on where in a single address to compress the
-   zero.
-
-      2001:db8::aaaa:0:0:1
-
-      2001:db8:0:0:aaaa::1
-
-2.3.  Uppercase or Lowercase
-
-   [RFC4291] does not mention any preference of uppercase or lowercase.
-
-
-
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 5]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
-
-
-3.  Problems Encountered with the Flexible Model
-
-3.1.  Searching
-
-3.1.1.  General Summary
-
-   A search of an IPv6 address if conducted through a UNIX system is
-   usually case sensitive and extended options to allow for regular
-   expression use will come in handy.  However, there are many
-   applications in the Internet today that do not provide this
-   capability.  When searching for an IPv6 address in such systems, the
-   system engineer will have to try each and every possibility to search
-   for an address.  This has critical impacts especially when trying to
-   deploy IPv6 over an enterprise network.
-
-3.1.2.  Searching Spreadsheets and Text Files
-
-   Spreadsheet applications and text editors on GUI systems, rarely have
-   the ability to search for a text using regular expression.  Moreover,
-   there are many non-engineers (who are not aware of case sensitivity
-   and regular expression use) that use these application to manage IP
-   addresses.  This has worked quite well with IPv4 since text
-   representation in IPv4 has very little flexibility.  There is no
-   incentive to encourage these non-engineers to change their tool or
-   learn regular expression when they decide to go dual-stack.  If the
-   entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was
-   conducted as 2001:db8:0:0:1::1, this will show a result of no match.
-   One example where this will cause problem is, when the search is
-   being conducted to assign a new address from a pool, and a check was
-   being done to see if it was not in use.  This may cause problems to
-   the end-hosts or end-users.  This type of address management is very
-   often seen in enterprise networks and also in ISPs.
-
-3.1.3.  Searching with Whois
-
-   The "whois" utility is used by a wide range of people today.  When a
-   record is set to a database, one will likely check the output to see
-   if the entry is correct.  If an entity was recorded as 2001:db8::/48,
-   but the whois output showed 2001:0db8:0000::/48, most non-engineers
-   would think that their input was wrong and will likely retry several
-   times or make a frustrated call to the database hostmaster.  If there
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 6]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   was a need to register the same address on different systems, and
-   each system showed a different text representation, this would
-   confuse people even more.  Although this document focuses on
-   addresses rather than prefixes, this is worth mentioning since the
-   problems encountered are mostly equal.
-
-3.1.4.  Searching for an Address in a Network Diagram
-
-   Network diagrams and blueprints often show what IP addresses are
-   assigned to a system devices.  In times of trouble shooting there may
-   be a need to search through a diagram to find the point of failure
-   (for example, if a traceroute stopped at 2001:db8::1, one would
-   search the diagram for that address).  This is a technique quite
-   often in use in enterprise networks and managed services.  Again, the
-   different flavors of text representation will result in a time-
-   consuming search leading to longer MTTR in times of trouble.
-
-3.2.  Parsing and Modifying
-
-3.2.1.  General Summary
-
-   With all the possible methods of text representation each application
-   must include a module, object, link, etc. to a function that will
-   parse IPv6 addresses in a manner that no matter how it is
-   represented, they will mean the same address.  Many system engineers
-   who integrate complex computer systems for corporate customers will
-   have difficulties finding that their favorite tool will not have this
-   function, or will encounter difficulties such as having to rewrite
-   their macros or scripts for their customers.
-
-3.2.2.  Logging
-
-   If an application were to output a log summary that represented the
-   address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
-   the output would be highly unreadable compared to the IPv4 output.
-   The address would have to be parsed and reformed to make it useful
-   for human reading.  Sometimes logging for critical systems is done by
-   mirroring the same traffic to two different systems.  Care must be
-   taken so that no matter what the log output is the logs should be
-   parsed so they will mean the same.
-
-3.2.3.  Auditing: Case 1
-
-   When a router or any other network appliance machine configuration is
-   audited, there are many methods to compare the configuration
-   information of a node.  Sometimes auditing will be done by just
-   comparing the changes made each day.  In this case if configuration
-   was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 7]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   0000:0000:0000:0001 just because the new engineer on the block felt
-   it was better, a simple diff will show that a different address was
-   configured.  If this was done on a wide scale network people will be
-   focusing on 'why the extra zeros were put in' instead of doing any
-   real auditing.  Lots of tools are just plain diffs that do not take
-   into account address representation rules.
-
-3.2.4.  Auditing: Case 2
-
-   Node configurations will be matched against an information system
-   that manages IP addresses.  If output notation is different there
-   will need to be a script that is implemented to cover for this.  The
-   result of an SNMP GET operation, converted to text and compared to a
-   textual address written by a human is highly unlikely to match on the
-   first try.
-
-3.2.5.  Verification
-
-   Some protocols require certain data fields to be verified.  One
-   example of this is X.509 certificates.  If an IPv6 address field in a
-   certificate was incorrectly verified by converting it to text and
-   making a simple textual comparison to some other address, the
-   certificate may be mistakenly shown as being invalid due to a
-   difference in text representation methods.
-
-3.2.6.  Unexpected Modifying
-
-   Sometimes, a system will take an address and modify it as a
-   convenience.  For example, a system may take an input of
-   2001:0db8:0::1 and make the output 2001:db8::1.  If the zeros were
-   input for a reason, the outcome may be somewhat unexpected.
-
-3.3.  Operating
-
-3.3.1.  General Summary
-
-   When an operator sets an IPv6 address of a system as 2001:db8:0:0:1:
-   0:0:1, the system may take the address and show the configuration
-   result as 2001:DB8::1:0:0:1.  Someone familiar with IPv6 address
-   representation will know that the right address is set, but not
-   everyone may understand this.
-
-3.3.2.  Customer Calls
-
-   When a customer calls to inquire about a suspected outage, IPv6
-   address representation should be handled with care.  Not all
-   customers are engineers nor have the same skill in IPv6 technology.
-   The network operations center will have to take extra steps to
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 8]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   humanly parse the address to avoid having to explain to the customers
-   that 2001:db8:0:1::1 is the same as 2001:db8::1:0:0:0:1.  This is one
-   thing that will never happen in IPv4 because IPv4 address cannot be
-   abbreviated.
-
-3.3.3.  Abuse
-
-   Network abuse reports generally include the abusing IP address.  This
-   'reporting' could take any shape or form of the flexible model.  A
-   team that handles network abuse must be able to tell the difference
-   between a 2001:db8::1:0:1 and 2001:db8:1::0:1.  Mistakes in the
-   placement of the "::" will result in a critical situation.  A system
-   that handles these incidents should be able to handle any type of
-   input and parse it in a correct manner.  Also, incidents are reported
-   over the phone.  It is unnecessary to report if the letter is an
-   uppercase or lowercase.  However, when a letter is spelled uppercase,
-   people tend to clarify that it is uppercase, which is unnecessary
-   information.
-
-3.4.  Other Minor Problems
-
-3.4.1.  Changing Platforms
-
-   When an engineer decides to change the platform of a running service,
-   the same code may not work as expected due to the difference in IPv6
-   address text representation.  Usually, a change in a platform (e.g.
-   Unix to Windows, Cisco to Juniper) will result in a major change of
-   code anyway, but flexibility in address representation will increase
-   the work load.
-
-3.4.2.  Preference in Documentation
-
-   A document that is edited by more than one author may become harder
-   to read.
-
-3.4.3.  Legibility
-
-   Capital case D and 0 can be quite often misread.  Capital B and 8 can
-   also be misread.
-
-
-4.  A Recommendation for IPv6 Text Representation
-
-   A recommendation for a canonical text representation format of IPv6
-   addresses is presented in this section.  The recommendation in this
-   document is one that, complies fully with [RFC4291], is implemented
-   by various operating systems, and is human friendly.  The
-   recommendation in this section SHOULD be followed by systems when
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 9]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   generating an address to represent as text, but all implementations
-   MUST accept and be able to handle any legitimate [RFC4291] format.
-   It is advised that humans also follow these recommendations when
-   spelling an address.
-
-4.1.  Handling Leading Zeros in a 16 Bit Field
-
-   Leading zeros MUST be suppressed.  For example 2001:0db8::0001 is not
-   acceptable and must be represented as 2001:db8::1.  A single 16 bit
-   0000 field MUST be represented as 0.
-
-4.2.  "::" Usage
-
-4.2.1.  Shorten As Much As Possible
-
-   The use of symbol "::" MUST be used to its maximum capability.  For
-   example, 2001:db8::0:1 is not acceptable, because the symbol "::"
-   could have been used to produce a shorter representation 2001:db8::1.
-
-4.2.2.  Handling One 16 Bit 0 Field
-
-   The symbol "::" MUST NOT be used to shorten just one 16 bit 0 field.
-   For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
-   2001:db8::1:1:1:1:1 is not correct.
-
-4.2.3.  Choice in Placement of "::"
-
-   When there is an alternative choice in the placement of a "::", the
-   longest run of consecutive 16 bit 0 fields MUST be shortened (i.e.
-   the sequence with three consecutive zero fields is shortened in 2001:
-   0:0:1:0:0:0:1).  When the length of the consecutive 16 bit 0 fields
-   are equal (i.e. 2001:db8:0:0:1:0:0:1), the first sequence of zero
-   bits MUST be shortened.  For example 2001:db8::1:0:0:1 is correct
-   representation.
-
-4.3.  Lower Case
-
-   The characters "a", "b", "c", "d", "e", "f" in an IPv6 address MUST
-   be represented in lower case.
-
-
-5.  Text Representation of Special Addresses
-
-   Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
-   IPv4-translatable addresses [I-D.ietf-behave-address-format] have
-   IPv4 addresses embedded in the low-order 32 bits of the address.
-   These addresses have special representation that may mix hexadecimal
-   and dot decimal notations.  The decimal notation may be used only for
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010               [Page 10]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   the last 32 bits of the address.  For these addresses, mixed notation
-   is RECOMMENDED if the following condition is met: The address can be
-   distinguished as having IPv4 addresses embedded in the lower 32 bits
-   solely from the address field through the use of a well known prefix.
-   Such prefixes are defined in [RFC4291] and [RFC2765] at the time of
-   writing.  If it is known by some external method that a given prefix
-   is used to embed IPv4, it MAY be represented as mixed notation.
-   Tools that provide options to specify prefixes that are (or are not)
-   to be represented as mixed notation may be useful.
-
-   There is a trade-off here where a recommendation to achieve exact
-   match in a search (no dot decimals whatsoever) and recommendation to
-   help the readability of an addresses (dot decimal whenever possible)
-   does not result in the same solution.  The above recommendation is
-   aimed at fixing the representation as much as possible while leaving
-   the opportunity for future well known prefixes to be represented in a
-   human friendly manner as tools adjust to newly assigned prefixes.
-
-   The text representation method noted in Section 4 should be applied
-   for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of
-   0:0:0:0:0:ffff:192.0.2.1).
-
-
-6.  Notes on Combining IPv6 Addresses with Port Numbers
-
-   When IPv6 addresses and port numbers are represented in text combined
-   together, there are many different ways to do so.  Examples are shown
-   below.
-
-   o  [2001:db8::1]:80
-
-   o  2001:db8::1:80
-
-   o  2001:db8::1.80
-
-   o  2001:db8::1 port 80
-
-   o  2001:db8::1p80
-
-   o  2001:db8::1#80
-
-   The situation is not much different in IPv4, but the most ambiguous
-   case with IPv6 is the second bullet.  This is due to the "::"usage in
-   IPv6 addresses.  This style is NOT RECOMMENDED for its ambiguity.
-   The [] style as expressed in [RFC3986] SHOULD be employed, and is the
-   default unless otherwise specified.  Other styles are acceptable when
-   there is exactly one style for the given context and cross-platform
-   portability does not become an issue.  For URIs containing IPv6
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010               [Page 11]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   address literals, [RFC3986] MUST be followed, as well as the rules in
-   this document.
-
-
-7.  Prefix Representation
-
-   Problems with prefixes are just the same as problems encountered with
-   addresses.  The text representation method of IPv6 prefixes should be
-   no different from that of IPv6 addresses.
-
-
-8.  Security Considerations
-
-   This document notes some examples where IPv6 addresses are compared
-   in text format.  The example on Section 3.2.5 is one that may cause a
-   security risk if used for access control.  The common practice of
-   comparing X.509 data is done in binary format.
-
-
-9.  IANA Considerations
-
-   None.
-
-
-10.  Acknowledgements
-
-   The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami,
-   Toshimitsu Matsuura for their generous and helpful comments in kick
-   starting this document.  We also would like to thank Brian Carpenter,
-   Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler,
-   Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki
-   Vatiainen ,Dan Wing, and Doug Barton for their input.  Also a very
-   special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert
-   Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing
-   this document to the light of IETF working groups.
-
-
-11.  References
-
-11.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
-              (SIIT)", RFC 2765, February 2000.
-
-   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010               [Page 12]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-              Resource Identifier (URI): Generic Syntax", STD 66,
-              RFC 3986, January 2005.
-
-   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
-              Architecture", RFC 4291, February 2006.
-
-11.2.  Informative References
-
-   [I-D.ietf-behave-address-format]
-              Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
-              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
-              draft-ietf-behave-address-format-04 (work in progress),
-              January 2010.
-
-   [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
-              Castro, "Application Aspects of IPv6 Transition",
-              RFC 4038, March 2005.
-
-   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
-              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
-              March 2008.
-
-
-Appendix A.  For Developers
-
-   We recommend that developers use display routines that conform to
-   these rules.  For example, the usage of getnameinfo() with flags
-   argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output,
-   except for the special addresses notes in Section 5.  The function
-   inet_ntop() of FreeBSD7.0 is a good C code reference, but should not
-   be called directly.  See [RFC4038] for details.
-
-
-Authors' Addresses
-
-   Seiichi Kawamura
-   NEC BIGLOBE, Ltd.
-   14-22, Shibaura 4-chome
-   Minatoku, Tokyo  108-8558
-   JAPAN
-
-   Phone: +81 3 3798 6085
-   Email: kawamucho@mesh.ad.jp
-
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010               [Page 13]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   Masanobu Kawashima
-   NEC AccessTechnica, Ltd.
-   800, Shimomata
-   Kakegawa-shi, Shizuoka  436-8501
-   JAPAN
-
-   Phone: +81 537 23 9655
-   Email: kawashimam@necat.nec.co.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010               [Page 14]
-
-
diff --git a/doc/draft/draft-ietf-behave-address-format-07.txt b/doc/draft/draft-ietf-behave-address-format-07.txt
deleted file mode 100644
index 9c35be27..00000000
--- a/doc/draft/draft-ietf-behave-address-format-07.txt
+++ /dev/null
@@ -1,1009 +0,0 @@
-
-
-
-Network Working Group                                             C. Bao
-Internet-Draft                         CERNET Center/Tsinghua University
-Obsoletes: 2765 (if approved)                                 C. Huitema
-Updates: 4291 (if approved)                        Microsoft Corporation
-Intended status: Standards Track                              M. Bagnulo
-Expires: October 11, 2010                                           UC3M
-                                                            M. Boucadair
-                                                          France Telecom
-                                                                   X. Li
-                                       CERNET Center/Tsinghua University
-                                                           April 9, 2010
-
-
-                IPv6 Addressing of IPv4/IPv6 Translators
-                draft-ietf-behave-address-format-07.txt
-
-Abstract
-
-   This document discusses the algorithmic translation of an IPv6
-   address to a corresponding IPv4 address, and vice versa, using only
-   statically configured information.  It defines a well-known prefix
-   for use in algorithmic translations, while allowing organizations to
-   also use network-specific prefixes when appropriate.  Algorithmic
-   translation is used in IPv4/IPv6 translators, as well as other types
-   of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.
-
-Status of this Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at http://datatracker.ietf.org/drafts/current/.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   This Internet-Draft will expire on October 11, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-
-
-
-Bao, et al.             Expires October 11, 2010                [Page 1]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  Applicability Scope  . . . . . . . . . . . . . . . . . . .  3
-     1.2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . .  4
-     2.1.  Well Known Prefix  . . . . . . . . . . . . . . . . . . . .  4
-     2.2.  IPv4-Embedded IPv6 Address Format  . . . . . . . . . . . .  4
-     2.3.  Address Translation Algorithms . . . . . . . . . . . . . .  6
-     2.4.  Text Representation  . . . . . . . . . . . . . . . . . . .  6
-   3.  Deployment Guidelines and Choices  . . . . . . . . . . . . . .  7
-     3.1.  Restrictions on the use of the Well-Known Prefix . . . . .  7
-     3.2.  Impact on Inter-Domain Routing . . . . . . . . . . . . . .  8
-     3.3.  Choice of Prefix for Stateless Translation Deployments . .  8
-     3.4.  Choice of Prefix for Stateful Translation Deployments  . . 11
-     3.5.  Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 11
-     3.6.  Choice of the Well-Known Prefix  . . . . . . . . . . . . . 12
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
-     4.1.  Protection Against Spoofing  . . . . . . . . . . . . . . . 13
-     4.2.  Secure Configuration . . . . . . . . . . . . . . . . . . . 14
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
-   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-
-
-Bao, et al.             Expires October 11, 2010                [Page 2]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-1.  Introduction
-
-   This document is part of a series of IPv4/IPv6 translation documents.
-   A framework for IPv4/IPv6 translation is discussed in
-   [I-D.ietf-behave-v6v4-framework], including a taxonomy of scenarios
-   that will be used in this document.  Other documents specify the
-   behavior of various types of translators and gateways, including
-   mechanisms for translating between IP headers and other types of
-   messages that include IP addresses.  This document specifies how an
-   individual IPv6 address is translated to a corresponding IPv4
-   address, and vice versa, in cases where an algorithmic mapping is
-   used.  While specific types of devices are used herein as examples,
-   it is the responsibility of the specification of such devices to
-   reference this document for algorithmic mapping of the addresses
-   themselves.
-
-   Section 2 describes the prefixes and the format of "IPv4-Embedded
-   IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an
-   IPv4 address.  This format is common to both "IPv4-Converted" and
-   "IPv4-Translatable" IPv6 addresses.  This section also defines the
-   algorithms for translating addresses, and the text representation of
-   IPv4-Embedded IPv6 addresses.
-
-   Section 3 discusses the choice of prefixes, the conditions in which
-   they can be used, and the use of IPv4-Embedded IPv6 addresses with
-   stateless and stateful translation.
-
-   Section 4 discusses security concerns.
-
-   In some scenarios, a dual-stack host will unnecessarily send its
-   traffic through an IPv6/IPv4 translator.  This can be caused by
-   host's default address selection algorithm [RFC3484], referrals, or
-   other reasons.  Optimizing these scenarios for dual-stack hosts is
-   for future study.
-
-1.1.  Applicability Scope
-
-   This document is part of a series defining address translation
-   services.  We understand that the address format could also be used
-   by other interconnection methods between IPv6 and IPv4, e.g., methods
-   based on encapsulation.  If encapsulation methods are developed by
-   the IETF, we expect that their descriptions will document their
-   specific use of IPv4-Embedded IPv6 addresses.
-
-1.2.  Conventions
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-
-
-
-Bao, et al.             Expires October 11, 2010                [Page 3]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-1.3.  Terminology
-
-   This document makes use of the following terms:
-
-   IPv4/IPv6 translator:  an entity that translates IPv4 packets to IPv6
-      packets, and vice versa.  It may do "stateless" translation,
-      meaning that there is no per-flow state required, or "stateful"
-      translation where per-flow state is created when the first packet
-      in a flow is received.
-   Address translator:  any entity that has to derive an IPv4 address
-      from an IPv6 address or vice versa.  This applies not only to
-      devices that do IPv4/IPv6 packet translation, but also to other
-      entities that manipulate addresses, such as name resolution
-      proxies (e.g.  DNS64 [I-D.ietf-behave-dns64]) and possibly other
-      types of Application Layer Gateways (ALGs).
-   Well-Known Prefix:  the IPv6 prefix defined in this document for use
-      in an algorithmic mapping.
-   Network-Specific Prefix:  an IPv6 prefix assigned by an organization
-      for use in algorithmic mapping.  Options for the Network Specific
-      Prefix are discussed in Section 3.3 and Section 3.4.
-   IPv4-Embedded IPv6 addresses:  IPv6 addresses in which 32 bits
-      contain an IPv4 address.  Their format is described in
-      Section 2.2.
-   IPv4-Converted IPv6 addresses:  IPv6 addresses used to represent IPv4
-      nodes in an IPv6 network.  They are a variant of IPv4-Embedded
-      IPv6 addresses, and follow the format described in Section 2.2.
-   IPv4-Translatable IPv6 addresses:  IPv6 addresses assigned to IPv6
-      nodes for use with stateless translation.  They are a variant of
-      IPv4-Embedded IPv6 addresses, and follow the format described in
-      Section 2.2.
-
-
-2.  IPv4-Embedded IPv6 Address Prefix and Format
-
-2.1.  Well Known Prefix
-
-   This document reserves a "Well-Known Prefix" for use in an
-   algorithmic mapping.  The value of this IPv6 prefix is:
-
-      64:FF9B::/96
-
-2.2.  IPv4-Embedded IPv6 Address Format
-
-   IPv4-Converted IPv6 addresses and IPv4-Translatable IPv6 addresses
-   follow the same format, described here as the IPv4-Embedded IPv6
-   address Format.  IPv4-Embedded IPv6 addresses are composed of a
-
-
-
-Bao, et al.             Expires October 11, 2010                [Page 4]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-   variable length prefix, the embedded IPv4 address, and a variable
-   length suffix, as presented in the following diagram, in which PL
-   designates the prefix length:
-
-
-    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-|
-    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    |32|     prefix    |v4(32)         | u | suffix                    |
-    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    |40|     prefix        |v4(24)     | u |(8)| suffix                |
-    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    |48|     prefix            |v4(16) | u | (16)  | suffix            |
-    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    |56|     prefix                |(8)| u |  v4(24)   | suffix        |
-    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    |64|     prefix                    | u |   v4(32)      | suffix    |
-    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    |96|     prefix                                    |    v4(32)     |
-    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
-                                 Figure 1
-
-   In these addresses, the prefix shall be either the "Well-Known
-   Prefix", or a "Network-Specific Prefix" unique to the organization
-   deploying the address translators.  The prefixes can only have one of
-   the following lengths: 32, 40, 48, 56, 64 or 96.  (The Well-Known
-   prefic is 96 bits long, and can only be used in the last form of the
-   table.)
-
-   Various deployments justify different prefix lengths with Network-
-   Specific prefixes.  The tradeoff between different prefix lengths are
-   discussed in Section 3.3 and Section 3.4.
-
-   Bits 64 to 71 of the address are reserved for compatibility with the
-   host identifier format defined in the IPv6 addressing architecture
-   [RFC4291].  These bits MUST be set to zero.  When using a /96
-   Network-Specific Prefix, the administrators MUST ensure that the bits
-   64 to 71 are set to zero.  A simple way to achieve that is to
-   construct the /96 Network-Specific Prefix by picking a /64 prefix,
-   and then adding four octets set to zero.
-
-   The IPv4 address is encoded following the prefix, most significant
-   bits first.  Depending of the prefix length, the 4 octets of the
-   address may be separated by the reserved octet "u", whose 8 bits MUST
-   be set to zero.  In particular:
-
-
-
-
-Bao, et al.             Expires October 11, 2010                [Page 5]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-   o  When the prefix is 32 bits long, the IPv4 address is encoded in
-      positions 32 to 63.
-   o  When the prefix is 40 bits long, 24 bits of the IPv4 address are
-      encoded in positions 40 to 63, with the remaining 8 bits in
-      position 72 to 79.
-   o  When the prefix is 48 bits long, 16 bits of the IPv4 address are
-      encoded in positions 48 to 63, with the remaining 16 bits in
-      position 72 to 87.
-   o  When the prefix is 56 bits long, 8 bits of the IPv4 address are
-      encoded in positions 56 to 63, with the remaining 24 bits in
-      position 72 to 95.
-   o  When the prefix is 64 bits long, the IPv4 address is encoded in
-      positions 72 to 103.
-   o  When the prefix is 96 bits long, the IPv4 address is encoded in
-      positions 96 to 127.
-
-   There are no remaining bits, and thus no suffix, if the prefix is 96
-   bits long.  In the other cases, the remaining bits of the address
-   constitute the suffix.  These bits are reserved for future
-   extensions, and SHOULD be set to zero.
-
-2.3.  Address Translation Algorithms
-
-   IPv4-Embedded IPv6 addresses are composed according to the following
-   algorithm:
-   o  Concatenate the prefix, the 32 bits of the IPv4 address and the
-      null suffix if needed to obtain a 128 bit address.
-   o  If the prefix length is less than 96 bits, insert the null octet
-      "u" at the appropriate position, thus causing the least
-      significant octet to be excluded, as documented in Figure 1.
-
-   The IPv4 addresses are extracted from the IPv4-Embedded IPv6
-   addresses according to the following algorithm:
-   o  If the prefix is 96 bit long, extract the last 32 bits of the IPv6
-      address;
-   o  for the other prefix lengths, extract the "u" octet to obtain a
-      120 bit sequence, then extract the 32 bits following the prefix.
-
-2.4.  Text Representation
-
-   IPv4-Embedded IPv6 addresses will be represented in text in
-   conformity with section 2.2 of [RFC4291].  IPv4-Embedded IPv6
-   addresses constructed using the Well-Known Prefix or a /96 Network-
-   Specific Prefix may be represented using the alternative form
-   presented in section 2.2 of [RFC4291], with the embedded IPv4 address
-   represented in dotted decimal notation.  Examples of such
-   representations are presented in Table 1 and Table 2.
-
-
-
-
-Bao, et al.             Expires October 11, 2010                [Page 6]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-   +-----------------------+------------+------------------------------+
-   | Network-Specific      |    IPv4    | IPv4-Embedded IPv6 address   |
-   | Prefix                |   address  |                              |
-   +-----------------------+------------+------------------------------+
-   | 2001:DB8::/32         | 192.0.2.33 | 2001:DB8:C000:221::          |
-   | 2001:DB8:100::/40     | 192.0.2.33 | 2001:DB8:1C0:2:21::          |
-   | 2001:DB8:122::/48     | 192.0.2.33 | 2001:DB8:122:C000:2:2100::   |
-   | 2001:DB8:122:300::/56 | 192.0.2.33 | 2001:DB8:122:3C0:0:221::     |
-   | 2001:DB8:122:344::/64 | 192.0.2.33 | 2001:DB8:122:344:C0:2:2100:: |
-   | 2001:DB8:122:344::/96 | 192.0.2.33 | 2001:DB8:122:344::192.0.2.33 |
-   +-----------------------+------------+------------------------------+
-
-    Table 1: Text representation of IPv4-Embedded IPv6 addresses using
-                         Network-Specific Prefixes
-
-     +-------------------+--------------+----------------------------+
-     | Well Known Prefix | IPv4 address | IPv4-Embedded IPv6 address |
-     +-------------------+--------------+----------------------------+
-     | 64:FF9B::/96      |  192.0.2.33  | 64:FF9B::192.0.2.33        |
-     +-------------------+--------------+----------------------------+
-
-    Table 2: Text representation of IPv4-Embedded IPv6 addresses using
-                           the Well-Known Prefix
-
-   The Network-Specific Prefix examples in Table 1 are derived from the
-   IPv6 prefix reserved for documentation in [RFC3849].  The IPv4
-   address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for
-   documentation in [RFC5735].
-
-
-3.  Deployment Guidelines and Choices
-
-3.1.  Restrictions on the use of the Well-Known Prefix
-
-   The Well-Known Prefix MAY be used by organizations deploying
-   translation services, as explained in Section 3.4.
-
-   The Well-Known Prefix SHOULD NOT be used to construct IPv4-
-   Translatable addresses.  The nodes served by IPv4-Translatable IPv6
-   addresses should be able to receive global IPv6 traffic bound to
-   their IPv4-Translatable IPv6 address without incurring intermediate
-   protocol translation.  This is only possible if the specific prefix
-   used to build the IPv4-Translatable IPv6 addresses is advertized in
-   inter-domain routing, but the advertisement of more specific prefixes
-   derived from the Well-Known Prefix is not supported, as explained in
-   Section 3.2.  Network-Specific Prefixes SHOULD be used in these
-   scenarios, as explained in Section 3.3.
-
-
-
-
-Bao, et al.             Expires October 11, 2010                [Page 7]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-   The Well-Known Prefix MUST NOT be used to represent non global IPv4
-   addresses, such as those defined in [RFC1918].
-
-3.2.  Impact on Inter-Domain Routing
-
-   The Well-Known Prefix MAY appear in inter-domain routing tables, if
-   service providers decide to provide IPv6-IPv4 interconnection
-   services to peers.  Advertisement of the Well-Known Prefix SHOULD be
-   controlled either by upstream and/or downstream service providers
-   owing to inter-domain routing policies, e.g., through configuration
-   of BGP [RFC4271].  Organizations that advertize the Well-Known Prefix
-   in inter-domain routing MUST be able to provide IPv4/IPv6 translation
-   service.
-
-   When the IPv4/IPv6 translation relies on the Well-Known Prefix,
-   embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be
-   advertised in BGP (especially e-BGP) [RFC4271] because this leads to
-   importing the IPv4 routing table into the IPv6 one and therefore
-   induces scalability issues to the global IPv6 routing table.
-   Administrators of BGP nodes SHOULD configure filters that discard
-   advertisements of embedded IPv6 prefixes longer than the Well-Known
-   Prefix.
-
-   When the IPv4/IPv6 translation service relies on Network-Specific
-   Prefixes, the IPv4-Translatable IPv6 prefixes used in stateless
-   translation MUST be advertised with proper aggregation to the IPv6
-   Internet.  Similarly, if translators are configured with multiple
-   Network-Specific Prefixes,these prefixes MUST be advertised to the
-   IPv6 Internet with proper aggregation.
-
-3.3.  Choice of Prefix for Stateless Translation Deployments
-
-   Organizations may deploy translation services using stateless
-   translation.  In these deployments, internal IPv6 nodes are addressed
-   using IPv4-Translatable IPv6 addresses, which enable them to be
-   accessed by IPv4 nodes.  The addresses of these external IPv4 nodes
-   are then represented in IPv4-Converted IPv6 addresses.
-
-   Organizations deploying stateless IPv4/IPv6 translation SHOULD assign
-   a Network-Specific Prefix to their IPv4/IPv6 translation service.
-   IPv4-Translatable and IPv4-Converted IPv6 addresses MUST be
-   constructed as specified in Section 2.2.  IPv4-Translatable IPv6
-   addresses MUST use the selected Network-Specific Prefix.  Both IPv4-
-   Translatable IPv6 addresses and IPv4-Converted IPv6 addresses SHOULD
-   use the same prefix.
-
-   Using the same prefix ensures that IPv6 nodes internal to the
-   organization will use the most efficient paths to reach the nodes
-
-
-
-Bao, et al.             Expires October 11, 2010                [Page 8]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-   served by IPv4-Translatable IPv6 addresses.  Specifically, if a node
-   learns the IPv4 address of a target internal node without knowing
-   that this target is in fact located behind the same translator that
-   the node also uses, translation rules will ensure that the IPv6
-   address constructed with the Network-Specific prefix is the same as
-   the IPv4-Translatable IPv6 address assigned to the target.  Standard
-   routing preference (more specific wins) will then ensure that the
-   IPv6 packets are delivered directly, without requiring "hair-pinning"
-   at the translator.
-
-   The intra-domain routing protocol must be able to deliver packets to
-   the nodes served by IPv4-Translatable IPv6 addresses.  This may
-   require routing on some or all of the embedded IPv4 address bits.
-   Security considerations detailed in Section 4 require that routers
-   check the validity of the IPv4-Translatable IPv6 source addresses,
-   using some form of reverse path check.
-
-   The management of stateless address translation can be illustrated
-   with a small example.  We will consider an IPv6 network with the
-   prefix 2001:DB8:122::/48.  The network administrator has selected the
-   Network-Specific prefix 2001:DB8:122:344::/64 for managing stateless
-   IPv4/IPv6 translation.  The IPv4-Translatable address block is 2001:
-   DB8:122:344:C0:2::/96 and this block is visible in IPv4 as the subnet
-   192.0.2.0/24.  In this network, the host A is assigned the IPv4-
-   Translatable IPv6 address 2001:DB8:122:344:C0:2:2100::, which
-   corresponds to the IPv4 address 192.0.2.33.  Host A's address is
-   configured either manually or through DHCPv6.
-
-   In this example, host A is not directly connected to the translator,
-   but instead to a link managed by a router R. The router R is
-   configured to forward to A the packets bound to 2001:DB8:122:344:C0:
-   2:2100::.  To receive these packets, R will advertise reachability of
-   the prefix 2001:DB8:122:344:C0:2:2100::/104 in the intra-domain
-   routing protocol -- or perhaps a shorter prefix if many hosts on link
-   have IPv4-Translatable IPv6 addresses derived from the same IPv4
-   subnet.  If a packet bound to 192.0.2.33 reaches the translator, the
-   destination address will be translated to 2001:DB8:122:344:C0:2:
-   2100::, and the packet will be routed towards R and then to A.
-
-   Let's suppose now that a host B of the same domain learns the IPv4
-   address of A, maybe through an application-specific referral.  If B
-   has translation-aware software, B can compose a destination address
-   by combining the Network-Specific Prefix 2001:DB8:122:344::/64 and
-   the IPv4 address 192.0.2.33, resulting in the address 2001:DB8:122:
-   344:C0:2:2100::.  The packet sent by B will be forwarded towards R,
-   and then to A, avoiding protocol translation.
-
-   Forwarding, and reverse path checks, should be performed on the
-
-
-
-Bao, et al.             Expires October 11, 2010                [Page 9]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-   combination of the prefix and the IPv4 address.  In theory, routers
-   should be able to route on prefixes of any length.  However, routing
-   on prefixes larger than 64 bits may be slower on some routers.  But
-   routing efficiency is not the only consideration in the choice of a
-   prefix length.  Organizations also need to consider the availability
-   of prefixes, and the potential impact of all-zeroes identifiers.
-
-   If a /32 prefix is used, all the routing bits are contained in the
-   top 64 bits of the IPv6 address, leading to excellent routing
-   properties.  These prefixes may however be hard to obtain, and
-   allocation of a /32 to a small set of IPv4-Translatable IPv6
-   addresses may be seen as wasteful.  In addition, the /32 prefix and a
-   zero suffix leads to an all-zeroes interface identifier, an issue
-   that we discuss in Section 3.5.
-
-   Intermediate prefix lengths such as /40, /48 or /56 appear as
-   compromises.  Only some of the IPv4 bits are part of the /64
-   prefixes.  Reverse path checks, in particular, may have a limited
-   efficiency.  Reverse path checks limited to the most significant bits
-   of the IPv4 address will reduce the possibility of spoofing external
-   IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4-
-   Translatable IPv6 addresses.
-
-   We propose here a compromise, based on using no more than 1/256th of
-   an organization's allocation of IPv6 addresses for the IPv4/IPv6
-   translation service.  For example, if the organization is an Internet
-   Service Provider with an allocated IPv6 prefix /32 or shorter, the
-   ISP could dedicate a /40 prefix to the translation service.  An end
-   site with a /48 allocation could dedicate a /56 prefix to the
-   translation service, or possibly a /96 prefix if all IPv4-
-   Translatable IPv6 addresses are located on the same link.
-
-   The recommended prefix length is also a function of the deployment
-   scenario.  The stateless translation can be used for Scenario 1,
-   Scenario 2, Scenario 5, and Scenario 6 defined in
-   [I-D.ietf-behave-v6v4-framework].  For different scenarios, the
-   prefix length recommendations are:
-   o  For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario
-      2 (the IPv4 Internet to an IPv6 network), we recommend using a /40
-      prefix for an ISP holding a /32 allocation, and a /56 prefix for a
-      site holding a /48 allocation.
-   o  For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6
-      (an IPv4 network to an IPv6 network), we recommend using a /64 or
-      a /96 prefix.
-
-   IPv4-Translatable IPv6 addresses SHOULD follow the IPv6 address
-   architecture and SHOULD be compatible with the IPv4 address
-   architecture.  The first IPv4-translatable address is the subnet-
-
-
-
-Bao, et al.             Expires October 11, 2010               [Page 10]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-   router anycast address in IPv6 and network identifier in IPv4, the
-   last IPv4-translatable address is the subnet broadcast addresses in
-   IPv4.  Both of them SHOULD NOT be used for IPv6 nodes.  In addition,
-   the minimum IPv4 subnet can be used for hosts is /30 (the router
-   interface needs a valid address for the same subnet) and this rule
-   SHOULD also be applied to the corresponding subnet of the IPv4-
-   translatable addresses.
-
-3.4.  Choice of Prefix for Stateful Translation Deployments
-
-   Organizations may deploy translation services based on stateful
-   translation technology.  An organization may decide to use either a
-   Network-Specific Prefix or the Well-Known Prefix for its stateful
-   IPv4/IPv6 translation service.
-
-   When these services are used, IPv6 nodes are addressed through
-   standard IPv6 addresses, while IPv4 nodes are represented by IPv4-
-   Converted IPv6 addresses, as specified in Section 2.2.
-
-   The stateful nature of the translation creates a potential stability
-   issue when the organization deploys multiple translators.  If several
-   translators use the same prefix, there is a risk that packets
-   belonging to the same connection may be routed to different
-   translators as the internal routing state changes.  This issue can be
-   avoided either by assigning different prefixes to different
-   translators, or by ensuring that all translators using same prefix
-   coordinate their state.
-
-   Stateful translation can be used in scenarios defined in
-   [I-D.ietf-behave-v6v4-framework].  The Well Known Prefix SHOULD be
-   used in these scenarios, with two exceptions:
-   o  In all scenarios, the translation MAY use a Network-Specific
-      Prefix, if deemed appropriate for management reasons.
-   o  The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6
-      Internet to an IPv4 network), as this would lead to using the
-      Well-Known Prefix with non-global IPv4 addresses.  That means a
-      Network-Specific Prefix MUST be used in that scenario, for example
-      a /96 prefix compatible with the Well-Known prefix format.
-
-3.5.  Choice of Suffix
-
-   The address format described in Section 2.2 recommends a zero suffix.
-   Before making this recommendation, we considered different options:
-   checksum neutrality; the encoding of a port range; and a value
-   different than 0.
-
-   In the case of stateless translation, there would be no need for the
-   translator to recompute a one's complement checksum if both the IPv4-
-
-
-
-Bao, et al.             Expires October 11, 2010               [Page 11]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-   Translatable and the IPv4-Converted IPv6 addresses were constructed
-   in a "checksum-neutral" manner, that is if the IPv6 addresses would
-   have the same one's complement checksum as the embedded IPv4 address.
-   In the case of stateful translation, checksum neutrality does not
-   eliminate checksum computation during translation, as only one of the
-   two addresses would be checksum neutral.  We considered reserving 16
-   bits in the suffix to guarantee checksum neutrality, but declined
-   because it would not help with stateful translation, and because
-   checksum neutrality can also be achieved by an appropriate choice of
-   the Network-Specific Prefix, as was done for example with the Well-
-   Known Prefix.
-
-   There have been proposals to complement stateless translation with a
-   port-range feature.  Instead of mapping an IPv4 address to exactly
-   one IPv6 prefix, the options would allow several IPv6 nodes to share
-   an IPv4 address, with each node managing a different range of ports.
-   If a port range extension is needed, it could be defined later, using
-   bits currently reserved as null in the suffix.
-
-   When a /32 prefix is used, an all-zero suffix results in an all-zero
-   interface identifier.  We understand the conflict with Section 2.6.1
-   of RFC4291, which specifies that all zeroes are used for the subnet-
-   router anycast address.  However, in our specification, there would
-   be only one node with an IPv4-Translatable IPv6 address in the /64
-   subnet, and the anycast semantic would not create confusion.  We thus
-   decided to keep the null suffix for now.  This issue does not exist
-   for prefixes larger than 32 bits, such as the /40, /56, /64 and /96
-   prefixes that we recommend in Section 3.3.
-
-3.6.  Choice of the Well-Known Prefix
-
-   Before making our recommendation of the Well-Known Prefix, we were
-   faced with three choices:
-   o  reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC
-      2765 Section 2.1;
-   o  request IANA to allocate a /32 prefix,
-   o  or request allocation of a new /96 prefix.
-
-   We weighted the pros and cons of these choices before settling on the
-   recommended /96 Well-Known Prefix.
-
-   The main advantage of the existing IPv4-mapped prefix is that it is
-   already defined.  Reusing that prefix would require minimal
-   standardization efforts.  However, being already defined is not just
-   an advantage, as there may be side effects of current
-   implementations.  When presented with the IPv4-mapped prefix, current
-   versions of Windows and MacOS generate IPv4 packets, but will not
-   send IPv6 packets.  If we used the IPv4-mapped prefix, these nodes
-
-
-
-Bao, et al.             Expires October 11, 2010               [Page 12]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-   would not be able to support translation without modification.  This
-   will defeat the main purpose of the translation techniques.  We thus
-   eliminated the first choice, and decided to not reuse the IPv4-mapped
-   prefix, ::FFFF:0:0/96.
-
-   A /32 prefix would have allowed the embedded IPv4 address to fit
-   within the top 64 bits of the IPv6 address.  This would have
-   facilitated routing and load balancing when an organization deploys
-   several translators.  However, such destination-address based load
-   balancing may not be desirable.  It is not compatible with STUN in
-   the deployments involving multiple stateful translators, each one
-   having a different pool of IPv4 addresses.  STUN compatibility would
-   only be achieved if the translators managed the same pool of IPv4
-   addresses and were able to coordinate their translation state, in
-   which case there is no big advantage to using a /32 prefix rather
-   than a /96 prefix.
-
-   According to Section 2.2 of [RFC4291], in the legal textual
-   representations of IPv6 addresses, dotted decimal can only appear at
-   the end.  The /96 prefix is compatible with that requirement.  It
-   enables the dotted decimal notation without requiring an update to
-   [RFC4291].  This representation makes the address format easier to
-   use, and log files easier to read.
-
-   The prefix that we recommend has the particularity of being "checksum
-   neutral".  The sum of the hexadecimal numbers "0064" and "FF9B" is
-   "FFFF", i.e. a value equal to zero in one's complement arithmetic.
-   An IPv4-Embedded IPv6 address constructed with this prefix will have
-   the same one's complement checksum as the embedded IPv4 address.
-
-
-4.  Security Considerations
-
-4.1.  Protection Against Spoofing
-
-   By and large, IPv4/IPv6 translators can be modeled as special
-   routers, are subject to the same risks, and can implement the same
-   mitigations.  There is however a particular risk that directly
-   derives from the practice of embedding IPv4 addresses in IPv6:
-   address spoofing.
-
-   An attacker could use an IPv4-Embedded IPv6 address as the source
-   address of malicious packets.  After translation, the packets will
-   appear as IPv4 packets from the specified source, and the attacker
-   may be hard to track.  If left without mitigation, the attack would
-   allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses.
-
-   The mitigation is to implement reverse path checks, and to verify
-
-
-
-Bao, et al.             Expires October 11, 2010               [Page 13]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-   throughout the network that packets are coming from an authorized
-   location.
-
-4.2.  Secure Configuration
-
-   The prefixes used for address translation are used by IPv6 nodes to
-   send packets to IPv6/IPv4 translators.  Attackers could attempt to
-   fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong
-   values for these parameters, resulting in network disruption, denial
-   of service, and possible information disclosure.  To mitigate such
-   attacks, network administrators need to ensure that prefixes are
-   configured in a secure way.
-
-   The mechanisms for achieving secure configuration of prefixes are
-   beyond the scope of this document.
-
-
-5.  IANA Considerations
-
-   The IANA is requested to add a note to the documentation of the
-   0000::/8 address block in
-   http://www.iana.org/assignments/ipv6-address-space to document the
-   assignment by the IETF of the Well Known Prefix.  For example:
-
-      The "Well Known Prefix" 64:FF9B::/96 used in an algorithmic
-      mapping between IPv4 to IPv6 addresses is defined out of the
-      0000::/8 address block, per (this document).
-
-
-6.  Acknowledgements
-
-   Many people in the Behave WG have contributed to the discussion that
-   led to this document, including Andrew Sullivan, Andrew Yourtchenko,
-   Brian Carpenter, Dan Wing, Ed Jankiewicz, Fred Baker, Hiroshi Miyata,
-   Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus
-   Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip
-   Matthews, Remi Denis-Courmont, Remi Despres and William Waites.
-
-   Marcelo Bagnulo is partly funded by Trilogy, a research project
-   supported by the European Commission under its Seventh Framework
-   Program.
-
-
-7.  Contributors
-
-   The following individuals co-authored drafts from which text has been
-   incorporated, and are listed in alphabetical order.
-
-
-
-
-Bao, et al.             Expires October 11, 2010               [Page 14]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-       Congxiao Bao
-       CERNET Center/Tsinghua University
-       Room 225, Main Building, Tsinghua University
-       Beijing,   100084
-       China
-       Phone: +86 62785983
-       Email: congxiao@cernet.edu.cn
-
-       Dave Thaler
-       Microsoft Corporation
-       One Microsoft Way
-       Redmond, WA  98052
-       USA
-       Phone: +1 425 703 8835
-       Email: dthaler@microsoft.com
-
-       Fred Baker
-       Cisco Systems
-       Santa Barbara, California  93117
-       USA
-       Phone: +1-408-526-4257
-       Fax:   +1-413-473-2403
-       Email: fred@cisco.com
-
-       Hiroshi Miyata
-       Yokogawa Electric Corporation
-       2-9-32 Nakacho
-       Musashino-shi, Tokyo  180-8750
-       JAPAN
-       Email: h.miyata@jp.yokogawa.com
-
-       Marcelo Bagnulo
-       Universidad Carlos III de Madrid
-       Av. Universidad 30
-       Leganes, Madrid  28911
-       ESPANA
-       Email: marcelo@it.uc3m.es
-
-       Xing Li
-       CERNET Center/Tsinghua University
-       Room 225, Main Building, Tsinghua University
-       Beijing,   100084
-       China
-       Phone: +86 62785983
-       Email: xing@cernet.edu.cn
-
-
-
-
-
-
-Bao, et al.             Expires October 11, 2010               [Page 15]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-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.
-
-   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
-              Architecture", RFC 4291, February 2006.
-
-8.2.  Informative References
-
-   [I-D.ietf-behave-dns64]
-              Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
-              "DNS64: DNS extensions for Network Address Translation
-              from IPv6 Clients to IPv4 Servers",
-              draft-ietf-behave-dns64-04 (work in progress),
-              December 2009.
-
-   [I-D.ietf-behave-v6v4-framework]
-              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
-              IPv4/IPv6 Translation",
-              draft-ietf-behave-v6v4-framework-03 (work in progress),
-              October 2009.
-
-   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
-              E. Lear, "Address Allocation for Private Internets",
-              BCP 5, RFC 1918, February 1996.
-
-   [RFC3484]  Draves, R., "Default Address Selection for Internet
-              Protocol version 6 (IPv6)", RFC 3484, February 2003.
-
-   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
-              Reserved for Documentation", RFC 3849, July 2004.
-
-   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
-              Protocol 4 (BGP-4)", RFC 4271, January 2006.
-
-   [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
-              BCP 153, RFC 5735, January 2010.
-
-
-
-
-
-
-
-
-
-
-
-Bao, et al.             Expires October 11, 2010               [Page 16]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-Authors' Addresses
-
-   Congxiao Bao
-   CERNET Center/Tsinghua University
-   Room 225, Main Building, Tsinghua University
-   Beijing,   100084
-   China
-
-   Phone: +86 10-62785983
-   Email: congxiao@cernet.edu.cn
-
-
-   Christian Huitema
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052-6399
-   U.S.A.
-
-   Email: huitema@microsoft.com
-
-
-   Marcelo Bagnulo
-   UC3M
-   Av. Universidad 30
-   Leganes, Madrid  28911
-   Spain
-
-   Phone: +34-91-6249500
-   Fax:
-   Email: marcelo@it.uc3m.es
-   URI:   http://www.it.uc3m.es/marcelo
-
-
-   Mohamed Boucadair
-   France Telecom
-   3, Av Francois Chateaux
-   Rennes  350000
-   France
-
-   Email: mohamed.boucadair@orange-ftgroup.com
-
-
-
-
-
-
-
-
-
-
-
-Bao, et al.             Expires October 11, 2010               [Page 17]
-
-Internet-Draft  IPv6 Addressing of IPv4/IPv6 Translators      April 2010
-
-
-   Xing Li
-   CERNET Center/Tsinghua University
-   Room 225, Main Building, Tsinghua University
-   Beijing,   100084
-   China
-
-   Phone: +86 10-62785983
-   Email: xing@cernet.edu.cn
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bao, et al.             Expires October 11, 2010               [Page 18]
-
-
diff --git a/doc/draft/draft-ietf-behave-dns64-11.txt b/doc/draft/draft-ietf-behave-dns64-11.txt
deleted file mode 100644
index 3c5ac813..00000000
--- a/doc/draft/draft-ietf-behave-dns64-11.txt
+++ /dev/null
@@ -1,1792 +0,0 @@
-
-
-
-BEHAVE WG                                                     M. Bagnulo
-Internet-Draft                                                      UC3M
-Intended status: Standards Track                             A. Sullivan
-Expires: April 4, 2011                                          Shinkuro
-                                                             P. Matthews
-                                                          Alcatel-Lucent
-                                                          I. van Beijnum
-                                                          IMDEA Networks
-                                                         October 1, 2010
-
-
-DNS64: DNS extensions for Network Address Translation from IPv6 Clients
-                            to IPv4 Servers
-                       draft-ietf-behave-dns64-11
-
-Abstract
-
-   DNS64 is a mechanism for synthesizing AAAA records from A records.
-   DNS64 is used with an IPv6/IPv4 translator to enable client-server
-   communication between an IPv6-only client and an IPv4-only server,
-   without requiring any changes to either the IPv6 or the IPv4 node,
-   for the class of applications that work through NATs.  This document
-   specifies DNS64, and provides suggestions on how it should be
-   deployed in conjunction with IPv6/IPv4 translators.
-
-Status of this Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at http://datatracker.ietf.org/drafts/current/.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   This Internet-Draft will expire on April 4, 2011.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                 [Page 1]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                 [Page 2]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   3.  Background to DNS64-DNSSEC interaction . . . . . . . . . . . .  8
-   4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . 10
-   5.  DNS64 Normative Specification  . . . . . . . . . . . . . . . . 11
-     5.1.  Resolving AAAA queries and the answer section  . . . . . . 11
-       5.1.1.  The answer when there is AAAA data available . . . . . 12
-       5.1.2.  The answer when there is an error  . . . . . . . . . . 12
-       5.1.3.  Dealing with timeouts  . . . . . . . . . . . . . . . . 12
-       5.1.4.  Special exclusion set for AAAA records . . . . . . . . 13
-       5.1.5.  Dealing with CNAME and DNAME . . . . . . . . . . . . . 13
-       5.1.6.  Data for the answer when performing synthesis  . . . . 13
-       5.1.7.  Performing the synthesis . . . . . . . . . . . . . . . 14
-       5.1.8.  Querying in parallel . . . . . . . . . . . . . . . . . 14
-     5.2.  Generation of the IPv6 representations of IPv4
-           addresses  . . . . . . . . . . . . . . . . . . . . . . . . 15
-     5.3.  Handling other Resource Records and the Additional
-           Section  . . . . . . . . . . . . . . . . . . . . . . . . . 16
-       5.3.1.  PTR Resource Record  . . . . . . . . . . . . . . . . . 16
-       5.3.2.  Handling the additional section  . . . . . . . . . . . 17
-       5.3.3.  Other Resource Records . . . . . . . . . . . . . . . . 17
-     5.4.  Assembling a synthesized response to a AAAA query  . . . . 18
-     5.5.  DNSSEC processing: DNS64 in validating resolver mode . . . 18
-   6.  Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 19
-     6.1.  DNS resolvers and DNS64  . . . . . . . . . . . . . . . . . 19
-     6.2.  DNSSEC validators and DNS64  . . . . . . . . . . . . . . . 20
-     6.3.  DNS64 and multihomed and dual-stack hosts  . . . . . . . . 20
-       6.3.1.  IPv6 multihomed hosts  . . . . . . . . . . . . . . . . 20
-       6.3.2.  Accidental dual-stack DNS64 use  . . . . . . . . . . . 21
-       6.3.3.  Intentional dual-stack DNS64 use . . . . . . . . . . . 21
-   7.  Deployment scenarios and examples  . . . . . . . . . . . . . . 22
-     7.1.  Example of An-IPv6-network-to-IPv4-Internet setup with
-           DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 22
-     7.2.  An example of an-IPv6-network-to-IPv4-Internet setup
-           with DNS64 in stub-resolver mode . . . . . . . . . . . . . 24
-     7.3.  Example of IPv6-Internet-to-an-IPv4-network setup
-           DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 25
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
-   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
-   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
-   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
-     12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
-     12.2. Informative References . . . . . . . . . . . . . . . . . . 29
-   Appendix A.  Motivations and Implications of synthesizing AAAA
-                Resource Records when real AAAA Resource Records
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                 [Page 3]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-                exist . . . . . . . . . . . . . . . . . . . . . . . . 30
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                 [Page 4]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-1.  Introduction
-
-   This document specifies DNS64, a mechanism that is part of the
-   toolbox for IPv6-IPv4 transition and co-existence.  DNS64, used
-   together with an IPv6/IPv4 translator such as stateful NAT64
-   [I-D.ietf-behave-v6v4-xlate-stateful], allows an IPv6-only client to
-   initiate communications by name to an IPv4-only server.
-
-   DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
-   from A RRs.  A synthetic AAAA RR created by the DNS64 from an
-   original A RR contains the same owner name of the original A RR but
-   it contains an IPv6 address instead of an IPv4 address.  The IPv6
-   address is an IPv6 representation of the IPv4 address contained in
-   the original A RR.  The IPv6 representation of the IPv4 address is
-   algorithmically generated from the IPv4 address returned in the A RR
-   and a set of parameters configured in the DNS64 (typically, an IPv6
-   prefix used by IPv6 representations of IPv4 addresses and optionally
-   other parameters).
-
-   Together with an IPv6/IPv4 translator, these two mechanisms allow an
-   IPv6-only client to initiate communications to an IPv4-only server
-   using the FQDN of the server.
-
-   These mechanisms are expected to play a critical role in the IPv4-
-   IPv6 transition and co-existence.  Due to IPv4 address depletion, it
-   is likely that in the future, many IPv6-only clients will want to
-   connect to IPv4-only servers.  In the typical case, the approach only
-   requires the deployment of IPv6/IPv4 translators that connect an
-   IPv6-only network to an IPv4-only network, along with the deployment
-   of one or more DNS64-enabled name servers.  However, some features
-   require performing the DNS64 function directly in the end-hosts
-   themselves.
-
-   This document is structured as follows: section 2 provides a non-
-   normative overview of the behaviour of DNS64.  Section 3 provides a
-   non-normative background required to understand the interaction
-   between DNS64 and DNSSEC.  The normative specification of DNS64 is
-   provided in sections 4, 5 and 6.  Section 4 defines the terminology,
-   section 5 is the actual DNS64 specification and section 6 covers
-   deployments issues.  Section 7 is non-normative and provides a set of
-   examples and typical deployment scenarios.
-
-
-2.  Overview
-
-   This section provides an introduction to the DNS64 mechanism.
-
-   We assume that we have one or more IPv6/IPv4 translator boxes
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                 [Page 5]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   connecting an IPv4 network and an IPv6 network.  The IPv6/IPv4
-   translator device provides translation services between the two
-   networks enabling communication between IPv4-only hosts and IPv6-only
-   hosts.  (NOTE: By IPv6-only hosts we mean hosts running IPv6-only
-   applications, hosts that can only use IPv6, as well as cases where
-   only IPv6 connectivity is available to the client.  By IPv4-only
-   servers we mean servers running IPv4-only applications, servers that
-   can only use IPv4, as well as cases where only IPv4 connectivity is
-   available to the server).  Each IPv6/IPv4 translator used in
-   conjunction with DNS64 must allow communications initiated from the
-   IPv6-only host to the IPv4-only host.
-
-   To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to
-   learn the address of the responder, DNS64 is used to synthesize a
-   AAAA record from an A record containing a real IPv4 address of the
-   responder, whenever the DNS64 cannot retrieve a AAAA record for the
-   queried name.  The DNS64 service appears as a regular DNS server or
-   resolver to the IPv6 initiator.  The DNS64 receives a AAAA DNS query
-   generated by the IPv6 initiator.  It first attempts a resolution for
-   the requested AAAA records.  If there are no AAAA records available
-   for the target node (which is the normal case when the target node is
-   an IPv4-only node), DNS64 performs a query for A records.  For each A
-   record discovered, DNS64 creates a synthetic AAAA RR from the
-   information retrieved in the A RR.
-
-   The owner name of a synthetic AAAA RR is the same as that of the
-   original A RR, but an IPv6 representation of the IPv4 address
-   contained in the original A RR is included in the AAAA RR.  The IPv6
-   representation of the IPv4 address is algorithmically generated from
-   the IPv4 address and additional parameters configured in the DNS64.
-   Among those parameters configured in the DNS64, there is at least one
-   IPv6 prefix.  If not explicitly mentioned, all prefixes are treated
-   equally and the operations described in this document are performed
-   using the prefixes available.  So as to be general, we will call any
-   of these prefixes Pref64::/n, and describe the operations made with
-   the generic prefix Pref64::/n.  The IPv6 address representing IPv4
-   addresses included in the AAAA RR synthesized by the DNS64 contain
-   Pref64::/n and they also embed the original IPv4 address.
-
-   The same algorithm and the same Pref64::/n prefix(es) must be
-   configured both in the DNS64 device and the IPv6/IPv4 translator(s),
-   so that both can algorithmically generate the same IPv6
-   representation for a given IPv4 address.  In addition, it is required
-   that IPv6 packets addressed to an IPv6 destination address that
-   contains the Pref64::/n be delivered to an IPv6/IPv4 translator that
-   has that particular Pref64::/n configured, so they can be translated
-   into IPv4 packets.
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                 [Page 6]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs
-   are passed back to the IPv6 initiator, which will initiate an IPv6
-   communication with the IPv6 address associated with the IPv4
-   receiver.  The packet will be routed to an IPv6/IPv4 translator which
-   will forward it to the IPv4 network.
-
-   In general, the only shared state between the DNS64 and the IPv6/IPv4
-   translator is the Pref64::/n and an optional set of static
-   parameters.  The Pref64::/n and the set of static parameters must be
-   configured to be the same on both; there is no communication between
-   the DNS64 device and IPv6/IPv4 translator functions.  The mechanism
-   to be used for configuring the parameters of the DNS64 is beyond the
-   scope of this memo.
-
-   The prefixes to be used as Pref64::/n and their applicability are
-   discussed in [I-D.ietf-behave-address-format].  There are two types
-   of prefixes that can be used as Pref64::/n.
-
-      The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved
-      by [I-D.ietf-behave-address-format] for the purpose of
-      representing IPv4 addresses in IPv6 address space.
-
-      The Pref64::/n can be a Network-Specific Prefix (NSP).  An NSP is
-      an IPv6 prefix assigned by an organization to create IPv6
-      representations of IPv4 addresses.
-
-   The main difference in the nature of the two types of prefixes is
-   that the NSP is a locally assigned prefix that is under control of
-   the organization that is providing the translation services, while
-   the Well-Known Prefix is a prefix that has a global meaning since it
-   has been assigned for the specific purpose of representing IPv4
-   addresses in IPv6 address space.
-
-   The DNS64 function can be performed in any of three places.  The
-   terms below are more formally defined in Section 4.
-
-   The first option is to locate the DNS64 function in authoritative
-   servers for a zone.  In this case, the authoritative server provides
-   synthetic AAAA RRs for an IPv4-only host in its zone.  This is one
-   type of DNS64 server.
-
-   Another option is to locate the DNS64 function in recursive name
-   servers serving end hosts.  In this case, when an IPv6-only host
-   queries the name server for AAAA RRs for an IPv4-only host, the name
-   server can perform the synthesis of AAAA RRs and pass them back to
-   the IPv6-only initiator.  The main advantage of this mode is that
-   current IPv6 nodes can use this mechanism without requiring any
-   modification.  This mode is called "DNS64 in DNS recursive resolver
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                 [Page 7]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   mode".  This is a second type of DNS64 server, and it is also one
-   type of DNS64 resolver.
-
-   The last option is to place the DNS64 function in the end hosts,
-   coupled to the local (stub) resolver.  In this case, the stub
-   resolver will try to obtain (real) AAAA RRs and in case they are not
-   available, the DNS64 function will synthesize AAAA RRs for internal
-   usage.  This mode is compatible with some functions like DNSSEC
-   validation in the end host.  The main drawback of this mode is its
-   deployability, since it requires changes in the end hosts.  This mode
-   is called "DNS64 in stub-resolver mode".  This is the second type of
-   DNS64 resolver.
-
-
-3.  Background to DNS64-DNSSEC interaction
-
-   DNSSEC ([RFC4033], [RFC4034], [RFC4035]) presents a special challenge
-   for DNS64, because DNSSEC is designed to detect changes to DNS
-   answers, and DNS64 may alter answers coming from an authoritative
-   server.
-
-   A recursive resolver can be security-aware or security-oblivious.
-   Moreover, a security-aware recursive resolver can be validating or
-   non-validating, according to operator policy.  In the cases below,
-   the recursive resolver is also performing DNS64, and has a local
-   policy to validate.  We call this general case vDNS64, but in all the
-   cases below the DNS64 functionality should be assumed needed.
-
-   DNSSEC includes some signaling bits that offer some indicators of
-   what the query originator understands.
-
-   If a query arrives at a vDNS64 device with the "DNSSEC OK" (DO) bit
-   set, the query originator is signaling that it understands DNSSEC.
-   The DO bit does not indicate that the query originator will validate
-   the response.  It only means that the query originator can understand
-   responses containing DNSSEC data.  Conversely, if the DO bit is
-   clear, that is evidence that the querying agent is not aware of
-   DNSSEC.
-
-   If a query arrives at a vDNS64 device with the "Checking Disabled"
-   (CD) bit set, it is an indication that the querying agent wants all
-   the validation data so it can do checking itself.  By local policy,
-   vDNS64 could still validate, but it must return all data to the
-   querying agent anyway.
-
-   Here are the possible cases:
-
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                 [Page 8]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   1.  A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with
-       the DO bit clear.  In this case, DNSSEC is not a concern, because
-       the querying agent does not understand DNSSEC responses.  The
-       DNS64 can do validation of the response, if dictated by its local
-       policy.
-
-   2.  A security-oblivious DNS64 receives a query with the DO bit set,
-       and the CD bit clear or set.  This is just like the case of a
-       non-DNS64 case: the server doesn't support it, so the querying
-       agent is out of luck.
-
-   3.  A security-aware and non-validating DNS64 receives a query with
-       the DO bit set and the CD bit clear.  Such a resolver is not
-       validating responses, likely due to local policy (see [RFC4035],
-       section 4.2).  For that reason, this case amounts to the same as
-       the previous case, and no validation happens.
-
-   4.  A security-aware and non-validating DNS64 receives a query with
-       the DO bit set and the CD bit set.  In this case, the DNS64 is
-       supposed to pass on all the data it gets to the query initiator
-       (see section 3.2.2 of [RFC4035]).  This case will not work with
-       DNS64, unless the validating resolver is prepared to do DNS64
-       itself.  If the DNS64 modifies the record, the client will get
-       the data back and try to validate it, and the data will be
-       invalid as far as the client is concerned.
-
-   5.  A security-aware and validating DNS64 resolver receives a query
-       with the DO bit clear and CD clear.  In this case, the resolver
-       validates the data.  If it fails, it returns RCODE 2 (Server
-       failure); otherwise, it returns the answer.  This is the ideal
-       case for vDNS64.  The resolver validates the data, and then
-       synthesizes the new record and passes that to the client.  The
-       client, which is presumably not validating (else it should have
-       set DO and CD), cannot tell that DNS64 is involved.
-
-   6.  A security-aware and validating DNS64 resolver receives a query
-       with the DO bit set and CD clear.  This works like the previous
-       case, except that the resolver should also set the "Authentic
-       Data" (AD) bit on the response.
-
-   7.  A security-aware and validating DNS64 resolver receives a query
-       with the DO bit set and CD set.  This is effectively the same as
-       the case where a security-aware and non-validating recursive
-       resolver receives a similar query, and the same thing will
-       happen: the downstream validator will mark the data as invalid if
-       DNS64 has performed synthesis.  The node needs to do DNS64
-       itself, or else communication will fail.
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                 [Page 9]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-4.  Terminology
-
-   This section provides definitions for the special terms used in the
-   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 [RFC2119].
-
-   Authoritative server:  A DNS server that can answer authoritatively a
-      given DNS request.
-
-   DNS64:  A logical function that synthesizes DNS resource records (e.g
-      AAAA records containing IPv6 addresses) from DNS resource records
-      actually contained in the DNS (e.g., A records containing IPv4
-      addresses).
-
-   DNS64 recursive resolver:  A recursive resolver that provides the
-      DNS64 functionality as part of its operation.  This is the same
-      thing as "DNS64 in recursive resolver mode".
-
-   DNS64 resolver:  Any resolver (stub resolver or recursive resolver)
-      that provides the DNS64 function.
-
-   DNS64 server:  Any server providing the DNS64 function.  This
-      includes the server portion of a recursive resolver when it is
-      providing the DNS64 function.
-
-   IPv4-only server:  Servers running IPv4-only applications, servers
-      that can only use IPv4, as well as cases where only IPv4
-      connectivity is available to the server.
-
-   IPv6-only hosts:  Hosts running IPv6-only applications, hosts that
-      can only use IPv6, as well as cases where only IPv6 connectivity
-      is available to the client.
-
-   Recursive resolver:  A DNS server that accepts requests from one
-      resolver, and asks another server (of some description) for the
-      answer on behalf of the first resolver.  Full discussion of DNS
-      recursion is beyond the scope of this document; see [RFC1034] and
-      [RFC1035] for full details.
-
-   Synthetic RR:  A DNS resource record (RR) that is not contained in
-      the authoritative servers' zone data, but which is instead
-      synthesized from other RRs in the same zone.  An example is a
-      synthetic AAAA record created from an A record.
-
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 10]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   IPv6/IPv4 translator:  A device that translates IPv6 packets to IPv4
-      packets and vice-versa.  It is only required that the
-      communication initiated from the IPv6 side be supported.
-
-   For a detailed understanding of this document, the reader should also
-   be familiar with DNS terminology from [RFC1034], [RFC1035] and
-   current NAT terminology from [RFC4787].  Some parts of this document
-   assume familiarity with the terminology of the DNS security
-   extensions outlined in [RFC4035].  It is worth emphasizing that while
-   DNS64 is a logical function separate from the DNS, it is nevertheless
-   closely associated with that protocol.  It depends on the DNS
-   protocol, and some behavior of DNS64 will interact with regular DNS
-   responses.
-
-
-5.  DNS64 Normative Specification
-
-   DNS64 is a logical function that synthesizes AAAA records from A
-   records.  The DNS64 function may be implemented in a stub resolver,
-   in a recursive resolver, or in an authoritative name server.  It
-   works within those DNS functions, and appears on the network as
-   though it were a "plain" DNS resolver or name server conforming to
-   [RFC1034], and [RFC1035].
-
-   The implementation SHOULD support mapping of separate IPv4 address
-   ranges to separate IPv6 prefixes for AAAA record synthesis.  This
-   allows handling of special use IPv4 addresses [RFC5735].
-
-   DNS messages contain several sections.  The portion of a DNS message
-   that is altered by DNS64 is the Answer section, which is discussed
-   below in section Section 5.1.  The resulting synthetic answer is put
-   together with other sections, and that creates the message that is
-   actually returned as the response to the DNS query.  Assembling that
-   response is covered below in section Section 5.4.
-
-   DNS64 also responds to PTR queries involving addresses containing any
-   of the IPv6 prefixes it uses for synthesis of AAAA RRs.
-
-5.1.  Resolving AAAA queries and the answer section
-
-   When the DNS64 receives a query for RRs of type AAAA and class IN, it
-   first attempts to retrieve non-synthetic RRs of this type and class,
-   either by performing a query or, in the case of an authoritative
-   server, by examining its own results.  The query may be answered from
-   a local cache, if one is available.  DNS64 operation for classes
-   other than IN is undefined, and a DNS64 MUST behave as though no
-   DNS64 function is configured.
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 11]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-5.1.1.  The answer when there is AAAA data available
-
-   If the query results in one or more AAAA records in the answer
-   section, the result is returned to the requesting client as per
-   normal DNS semantics, except in the case where any of the AAAA
-   records match a special exclusion set of prefixes, considered in
-   Section 5.1.4.  If there is (non-excluded) AAAA data available, DNS64
-   SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A
-   for an analysis of the motivations for and the implications of not
-   complying with this recommendation).  By default DNS64
-   implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
-   exist.
-
-5.1.2.  The answer when there is an error
-
-   If the query results in a response with RCODE other than 0 (No error
-   condition), then there are two possibilities.  A result with RCODE=3
-   (Name Error) is handled according to normal DNS operation (which is
-   normally to return the error to the client).  This stage is still
-   prior to any synthesis having happened, so a response to be returned
-   to the client does not need any special assembly than would usually
-   happen in DNS operation.
-
-   Any other RCODE is treated as though the RCODE were 0 (see sections
-   Section 5.1.6 and Section 5.1.7) and the answer section were empty.
-   This is because of the large number of different responses from
-   deployed name servers when they receive AAAA queries without a AAAA
-   record being available (see [RFC4074]).  Note that this means, for
-   practical purposes, that several different classes of error in the
-   DNS are all treated as though a AAAA record is not available for that
-   owner name.
-
-   It is important to note that, as of this writing, some servers
-   respond with RCODE=3 to a AAAA query even if there is an A record
-   available for that owner name.  Those servers are in clear violation
-   of the meaning of RCODE 3, and it is expected that they will decline
-   in use as IPv6 deployment increases.
-
-5.1.3.  Dealing with timeouts
-
-   If the query receives no answer before the timeout (which might be
-   the timeout from every authoritative server, depending on whether the
-   DNS64 is in recursive resolver mode), it is treated as RCODE=2
-   (Server failure).
-
-
-
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 12]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-5.1.4.  Special exclusion set for AAAA records
-
-   Some IPv6 addresses are not actually usable by IPv6-only hosts.  If
-   they are returned to IPv6-only querying agents as AAAA records,
-   therefore, the goal of decreasing the number of failure modes will
-   not be attained.  Examples include AAAA records with addresses in the
-   ::ffff:0:0/96 network, and possibly (depending on the context) AAAA
-   records with the site's Pref::64/n or the Well-Known Prefix (see
-   below for more about the Well-Known Prefix).  A DNS64 implementation
-   SHOULD provide a mechanism to specify IPv6 prefix ranges to be
-   treated as though the AAAA containing them were an empty answer.  An
-   implementation SHOULD include the ::ffff/96 network in that range by
-   default.  Failure to provide this facility will mean that clients
-   querying the DNS64 function may not be able to communicate with hosts
-   that would be reachable from a dual-stack host.
-
-   When the DNS64 performs its initial AAAA query, if it receives an
-   answer with only AAAA records containing addresses in the excluded
-   range(s), then it MUST treat the answer as though it were an empty
-   answer, and proceed accordingly.  If it receives an answer with at
-   least one AAAA record containing an address outside any of the
-   excluded range(s), then it MAY build an answer section for a response
-   including only the AAAA record(s) that do not contain any of the
-   addresses inside the excluded ranges.  That answer section is used in
-   the assembly of a response as detailed in Section 5.4.
-   Alternatively, it MAY treat the answer as though it were an empty
-   answer, and proceed accordingly.  It MUST NOT return the offending
-   AAAA records as part of a response.
-
-5.1.5.  Dealing with CNAME and DNAME
-
-   If the response contains a CNAME or a DNAME, then the CNAME or DNAME
-   chain is followed until the first terminating A or AAAA record is
-   reached.  This may require the DNS64 to ask for an A record, in case
-   the response to the original AAAA query is a CNAME or DNAME without a
-   AAAA record to follow.  The resulting AAAA or A record is treated
-   like any other AAAA or A case, as appropriate.
-
-   When assembling the answer section, any chains of CNAME or DNAME RRs
-   are included as part of the answer along with the synthetic AAAA (if
-   appropriate).
-
-5.1.6.  Data for the answer when performing synthesis
-
-   If the query results in no error but an empty answer section in the
-   response, the DNS64 attempts to retrieve A records for the name in
-   question, either by performing another query or, in the case of an
-   authoritative server, by examining its own results.  If this new A RR
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 13]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   query results in an empty answer or in an error, then the empty
-   result or error is used as the basis for the answer returned to the
-   querying client.  If instead the query results in one or more A RRs,
-   the DNS64 synthesizes AAAA RRs based on the A RRs according to the
-   procedure outlined in Section 5.1.7.  The DNS64 returns the
-   synthesized AAAA records in the answer section, removing the A
-   records that form the basis of the synthesis.
-
-5.1.7.  Performing the synthesis
-
-   A synthetic AAAA record is created from an A record as follows:
-
-   o  The NAME field is set to the NAME field from the A record.
-
-   o  The TYPE field is set to 28 (AAAA).
-
-   o  The CLASS field is set to the original CLASS field, 1.  Under this
-      specification, DNS64 for any CLASS other than 1 is undefined.
-
-   o  The TTL field is set to the minimum of the TTL of the original A
-      RR and the SOA RR for the queried domain.  (Note that in order to
-      obtain the TTL of the SOA RR, the DNS64 does not need to perform a
-      new query, but it can remember the TTL from the SOA RR in the
-      negative response to the AAAA query.  If the SOA RR was not
-      delivered with the negative response to the AAAA query, then the
-      DNS64 SHOULD use a the minimum of the TTL of the original A RR and
-      600 seconds.  It is possible instead to query explicitly for the
-      SOA RR and use the result of that query, but this will increase
-      query load and time to resolution for little additional benefit.)
-      This is in keeping with the approach used in negative caching
-      ([RFC2308].
-
-   o  The RDLENGTH field is set to 16.
-
-   o  The RDATA field is set to the IPv6 representation of the IPv4
-      address from the RDATA field of the A record.  The DNS64 MUST
-      check each A RR against configured IPv4 address ranges and select
-      the corresponding IPv6 prefix to use in synthesizing the AAAA RR.
-      See Section 5.2 for discussion of the algorithms to be used in
-      effecting the transformation.
-
-5.1.8.  Querying in parallel
-
-   The DNS64 MAY perform the query for the AAAA RR and for the A RR in
-   parallel, in order to minimize the delay.
-
-   Note: Querying in parallel will result in performing unnecessary A RR
-   queries in the case where no AAAA RR synthesis is required.  A
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 14]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   possible trade-off would be to perform them sequentially but with a
-   very short interval between them, so if we obtain a fast reply, we
-   avoid doing the additional query.  (Note that this discussion is
-   relevant only if the DNS64 function needs to perform external queries
-   t fetch the RR.  If the needed RR information is available locally,
-   as in the case of an authoritative server, the issue is no longer
-   relevant.)
-
-5.2.  Generation of the IPv6 representations of IPv4 addresses
-
-   DNS64 supports multiple algorithms for the generation of the IPv6
-   representation of an IPv4 address.  The constraints imposed on the
-   generation algorithms are the following:
-
-      The same algorithm to create an IPv6 address from an IPv4 address
-      MUST be used by both a DNS64 to create the IPv6 address to be
-      returned in the synthetic AAAA RR from the IPv4 address contained
-      in an original A RR, and by a IPv6/IPv4 translator to create the
-      IPv6 address to be included in the source address field of the
-      outgoing IPv6 packets from the IPv4 address included in the source
-      address field of the incoming IPv4 packet.
-
-      The algorithm MUST be reversible; i.e., it MUST be possible to
-      derive the original IPv4 address from the IPv6 representation.
-
-      The input for the algorithm MUST be limited to the IPv4 address,
-      the IPv6 prefix (denoted Pref64::/n) used in the IPv6
-      representations and optionally a set of stable parameters that are
-      configured in the DNS64 and in the NAT64 (such as fixed string to
-      be used as a suffix).
-
-         For each prefix Pref64::/n, n MUST be less than or equal to 96.
-         If one or more Pref64::/n are configured in the DNS64 through
-         any means (such as manually configured, or other automatic
-         means not specified in this document), the default algorithm
-         MUST use these prefixes (and not use the Well-Known Prefix).
-         If no prefix is available, the algorithm MUST use the Well-
-         Known Prefix 64:FF9B::/96 defined in
-         [I-D.ietf-behave-address-format] to represent the IPv4 unicast
-         address range
-
-      [[anchor6: Note in document: The value 64:FF9B::/96 is proposed as
-      the value for the Well-Known prefix and needs to be confirmed
-      whenis published as RFC.]][I-D.ietf-behave-address-format]
-
-   A DNS64 MUST support the algorithm for generating IPv6
-   representations of IPv4 addresses defined in Section 2 of
-   [I-D.ietf-behave-address-format].  Moreover, the aforementioned
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 15]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   algorithm MUST be the default algorithm used by the DNS64.  While the
-   normative description of the algorithm is provided in
-   [I-D.ietf-behave-address-format], a sample description of the
-   algorithm and its application to different scenarios is provided in
-   Section 7 for illustration purposes.
-
-5.3.  Handling other Resource Records and the Additional Section
-
-5.3.1.  PTR Resource Record
-
-   If a DNS64 server receives a PTR query for a record in the IP6.ARPA
-   domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the
-   address portion of the QNAME according to the encoding scheme
-   outlined in section 2.5 of [RFC3596], and examine the resulting
-   address to see whether its prefix matches any of the locally-
-   configured Pref64::/n or the default Well-known prefix.  There are
-   two alternatives for a DNS64 server to respond to such PTR queries.
-   A DNS64 server MUST provide one of these, and SHOULD NOT provide both
-   at the same time unless different IP6.ARPA zones require answers of
-   different sorts:
-
-   1.  The first option is for the DNS64 server to respond
-       authoritatively for its prefixes.  If the address prefix matches
-       any Pref64::/n used in the site, either a NSP or the Well-Known
-       Prefix (i.e. 64:FF9B::/96), then the DNS64 server MAY answer the
-       query using locally-appropriate RDATA.  The DNS64 server MAY use
-       the same RDATA for all answers.  Note that the requirement is to
-       match any Pref64::/n used at the site, and not merely the
-       locally-configured Pref64::/n.  This is because end clients could
-       ask for a PTR record matching an address received through a
-       different (site-provided) DNS64, and if this strategy is in
-       effect, those queries should never be sent to the global DNS.
-       The advantage of this strategy is that it makes plain to the
-       querying client that the prefix is one operated by the (DNS64)
-       site, and that the answers the client is getting are generated by
-       DNS64.  The disadvantage is that any useful reverse-tree
-       information that might be in the global DNS is unavailable to the
-       clients querying the DNS64.
-
-   2.  The second option is for the DNS64 nameserver to synthesize a
-       CNAME mapping the IP6.ARPA namespace to the corresponding IN-
-       ADDR.ARPA name.  In this case, the DNS64 nameserver SHOULD ensure
-       that there is RDATA at the PTR of the corresponding IN-ADDR.ARPA
-       name, and that there is not an existing CNAME at that name.  This
-       is in order to avoid synthesizing a CNAME that makes a CNAME
-       chain longer or that does not actually point to anything.  The
-       rest of the response would be the normal DNS processing.  The
-       CNAME can be signed on the fly if need be.  The advantage of this
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 16]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-       approach is that any useful information in the reverse tree is
-       available to the querying client.  The disadvantage is that it
-       adds additional load to the DNS64 (because CNAMEs have to be
-       synthesized for each PTR query that matches the Pref64::/n), and
-       that it may require signing on the fly.
-
-   If the address prefix does not match any Pref64::/n, then the DNS64
-   server MUST process the query as though it were any other query; i.e.
-   a recursive nameserver MUST attempt to resolve the query as though it
-   were any other (non-A/AAAA) query, and an authoritative server MUST
-   respond authoritatively or with a referral, as appropriate.
-
-5.3.2.  Handling the additional section
-
-   DNS64 synthesis MUST NOT be performed on any records in the
-   additional section of synthesized answers.  The DNS64 MUST pass the
-   additional section unchanged.
-
-      NOTE: It may appear that adding synthetic records to the
-      additional section is desirable, because clients sometimes use the
-      data in the additional section to proceed without having to re-
-      query.  There is in general no promise, however, that the
-      additional section will contain all the relevant records, so any
-      client that depends on the additional section being able to
-      satisfy its needs (i.e. without additional queries) is necessarily
-      broken.  An IPv6-only client that needs a AAAA record, therefore,
-      will send a query for the necessary AAAA record if it is unable to
-      find such a record in the additional section of an answer it is
-      consuming.  For a correctly-functioning client, the effect would
-      be no different if the additional section were empty.The
-      alternative, of removing the A records in the additional section
-      and replacing them with synthetic AAAA records, may cause a host
-      behind a NAT64 to query directly a nameserver that is unaware of
-      the NAT64 in question.  The result in this case will be resolution
-      failure anyway, only later in the resolution operation.  The
-      prohibition on synthetic data in the additional section reduces,
-      but does not eliminate, the possibility of resolution failures due
-      to cached DNS data from behind the DNS64.  See Section 6.
-
-5.3.3.  Other Resource Records
-
-   If the DNS64 is in recursive resolver mode, then considerations
-   outlined in [I-D.ietf-dnsop-default-local-zones] may be relevant.
-
-   All other RRs MUST be returned unchanged.  This includes responses to
-   queries for A RRs.
-
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 17]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-5.4.  Assembling a synthesized response to a AAAA query
-
-   A DNS64 uses different pieces of data to build the response returned
-   to the querying client.
-
-   The query that is used as the basis for synthesis results either in
-   an error, an answer that can be used as a basis for synthesis, or an
-   empty (authoritative) answer.  If there is an empty answer, then the
-   DNS64 responds to the original querying client with the answer the
-   DNS64 received to the original (initiator's) query.  Otherwise, the
-   response is assembled as follows.
-
-   The header fields are set according to the usual rules for recursive
-   or authoritative servers, depending on the role that the DNS64 is
-   serving.  The question section is copied from the original
-   (initiator's) query.  The answer section is populated according to
-   the rules in Section 5.1.7.  The authority and additional sections
-   are copied from the response to the final query that the DNS64
-   performed, and used as the basis for synthesis.
-
-   The final response from the DNS64 is subject to all the standard DNS
-   rules, including truncation [RFC1035] and EDNS0 handling [RFC2671].
-
-5.5.  DNSSEC processing: DNS64 in validating resolver mode
-
-   We consider the case where a recursive resolver that is performing
-   DNS64 also has a local policy to validate the answers according to
-   the procedures outlined in [RFC4035] Section 5.  We call this general
-   case vDNS64.
-
-   The vDNS64 uses the presence of the DO and CD bits to make some
-   decisions about what the query originator needs, and can react
-   accordingly:
-
-   1.  If CD is not set and DO is not set, vDNS64 SHOULD perform
-       validation and do synthesis as needed.  See the next item for
-       rules about how to do validation and synthesis.  In this case,
-       however, vDNS64 MUST NOT set the AD bit in any response.
-
-   2.  If CD is not set and DO is set, then vDNS64 SHOULD perform
-       validation.  Whenever vDNS64 performs validation, it MUST
-       validate the negative answer for AAAA queries before proceeding
-       to query for A records for the same name, in order to be sure
-       that there is not a legitimate AAAA record on the Internet.
-       Failing to observe this step would allow an attacker to use DNS64
-       as a mechanism to circumvent DNSSEC.  If the negative response
-       validates, and the response to the A query validates, then the
-       vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 18]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-       answer to the client.  This is acceptable, because [RFC4035],
-       section 3.2.3 says that the AD bit is set by the name server side
-       of a security-aware recursive name server if and only if it
-       considers all the RRSets in the Answer and Authority sections to
-       be authentic.  In this case, the name server has reason to
-       believe the RRSets are all authentic, so it SHOULD set the AD
-       bit.  If the data does not validate, the vDNS64 MUST respond with
-       RCODE=2 (Server failure).
-       A security-aware end point might take the presence of the AD bit
-       as an indication that the data is valid, and may pass the DNS
-       (and DNSSEC) data to an application.  If the application attempts
-       to validate the synthesized data, of course, the validation will
-       fail.  One could argue therefore that this approach is not
-       desirable, but security aware stub resolvers must not place any
-       reliance on data received from resolvers and validated on their
-       behalf without certain criteria established by [RFC4035], section
-       4.9.3.  An application that wants to perform validation on its
-       own should use the CD bit.
-
-   3.  If the CD bit is set and DO is set, then vDNS64 MAY perform
-       validation, but MUST NOT perform synthesis.  It MUST return the
-       data to the query initiator, just like a regular recursive
-       resolver, and depend on the client to do the validation and the
-       synthesis itself.
-       The disadvantage to this approach is that an end point that is
-       translation-oblivious but security-aware and validating will not
-       be able to use the DNS64 functionality.  In this case, the end
-       point will not have the desired benefit of NAT64.  In effect,
-       this strategy means that any end point that wishes to do
-       validation in a NAT64 context must be upgraded to be translation-
-       aware as well.
-
-
-6.  Deployment notes
-
-   While DNS64 is intended to be part of a strategy for aiding IPv6
-   deployment in an internetworking environment with some IPv4-only and
-   IPv6-only networks, it is important to realise that it is
-   incompatible with some things that may be deployed in an IPv4-only or
-   dual-stack context.
-
-6.1.  DNS resolvers and DNS64
-
-   Full-service resolvers that are unaware of the DNS64 function can be
-   (mis)configured to act as mixed-mode iterative and forwarding
-   resolvers.  In a native IPv4 context, this sort of configuration may
-   appear to work.  It is impossible to make it work properly without it
-   being aware of the DNS64 function, because it will likely at some
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 19]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   point obtain IPv4-only glue records and attempt to use them for
-   resolution.  The result that is returned will contain only A records,
-   and without the ability to perform the DNS64 function the resolver
-   will be unable to answer the necessary AAAA queries.
-
-6.2.  DNSSEC validators and DNS64
-
-   An existing DNSSEC validator (i.e. that is unaware of DNS64) might
-   reject all the data that comes from DNS64 as having been tampered
-   with (even if it did not set CD when querying).  If it is necessary
-   to have validation behind the DNS64, then the validator must know how
-   to perform the DNS64 function itself.  Alternatively, the validating
-   host may establish a trusted connection with a DNS64, and allow the
-   DNS64 recursive resolver to do all validation on its behalf.
-
-6.3.  DNS64 and multihomed and dual-stack hosts
-
-6.3.1.  IPv6 multihomed hosts
-
-   Synthetic AAAA records may be constructed on the basis of the network
-   context in which they were constructed.  If a host sends DNS queries
-   to resolvers in multiple networks, it is possible that some of them
-   will receive answers from a DNS64 without all of them being connected
-   via a NAT64.  For instance, suppose a system has two interfaces, i1
-   and i2.  Whereas i1 is connected to the IPv4 Internet via NAT64, i2
-   has native IPv6 connectivity only.  I1 might receive a AAAA answer
-   from a DNS64 that is configured for a particular NAT64; the IPv6
-   address contained in that AAAA answer will not connect with anything
-   via i2.
-
-             +---------------+                 +-------------+
-             |      i1 (IPv6)+----NAT64--------+IPv4 Internet|
-             |               |                 +-------------+
-             | host          |
-             |               |                 +-------------+
-             |      i2 (IPv6)+-----------------+IPv6 Internet|
-             +---------------+                 +-------------+
-
-                      Figure 1: IPv6 multihomed hosts
-
-   This example illustrates why it is generally preferable that hosts
-   treat DNS answers from one interface as local to that interface.  The
-   answer received on one interface will not work on the other
-   interface.  Hosts that attempt to use DNS answers globally may
-   encounter surprising failures in these cases.
-
-   Note that the issue is not that there are two interfaces, but that
-   there are two networks involved.  The same results could be achieved
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 20]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   with a single interface routed to two different networks.
-
-6.3.2.  Accidental dual-stack DNS64 use
-
-   Similarly, suppose that i1 has IPv6 connectivity and can connect to
-   the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity.
-   In this case, i1 could receive an IPv6 address from a synthetic AAAA
-   that would better be reached via native IPv4.  Again, it is worth
-   emphasising that this arises because there are two networks involved.
-
-             +---------------+                 +-------------+
-             |      i1 (IPv6)+----NAT64--------+IPv4 Internet|
-             |               |                 +-------------+
-             | host          |
-             |               |                 +-------------+
-             |      i2 (IPv4)+-----------------+IPv4 Internet|
-             +---------------+                 +-------------+
-
-                 Figure 2: Accidental dual-stack DNS64 use
-
-   The default configuration of dual-stack hosts is that IPv6 is
-   preferred over IPv4 ([RFC3484]).  In that arrangement the host will
-   often use the NAT64 when native IPv4 would be more desirable.  For
-   this reason, hosts with IPv4 connectivity to the Internet should
-   avoid using DNS64.  This can be partly resolved by ISPs when
-   providing DNS resolvers to clients, but that is not a guarantee that
-   the NAT64 will never be used when a native IPv4 connection should be
-   used.  There is no general-purpose mechanism to ensure that native
-   IPv4 transit will always be preferred, because to a DNS64-oblivious
-   host, the DNS64 looks just like an ordinary DNS server.  Operators of
-   a NAT64 should expect traffic to pass through the NAT64 even when it
-   is not necessary.
-
-6.3.3.  Intentional dual-stack DNS64 use
-
-   Finally, consider the case where the IPv4 connectivity on i2 is only
-   with a LAN, and not with the IPv4 Internet.  The IPv4 Internet is
-   only accessible using the NAT64.  In this case, it is critical that
-   the DNS64 not synthesize AAAA responses for hosts in the LAN, or else
-   that the DNS64 be aware of hosts in the LAN and provide context-
-   sensitive answers ("split view" DNS answers) for hosts inside the
-   LAN.  As with any split view DNS arrangement, operators must be
-   prepared for data to leak from one context to another, and for
-   failures to occur because nodes accessible from one context are not
-   accessible from the other.
-
-
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 21]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-             +---------------+                 +-------------+
-             |      i1 (IPv6)+----NAT64--------+IPv4 Internet|
-             |               |                 +-------------+
-             | host          |
-             |               |
-             |      i2 (IPv4)+---(local LAN only)
-             +---------------+
-
-                Figure 3: Intentional dual-stack DNS64 use
-
-   It is important for deployers of DNS64 to realise that, in some
-   circumstances, making the DNS64 available to a dual-stack host will
-   cause the host to prefer to send packets via NAT64 instead of via
-   native IPv4, with the associated loss of performance or functionality
-   (or both) entailed by the NAT.  At the same time, some hosts are not
-   able to learn about DNS servers provisioned on IPv6 addresses, or
-   simply cannot send DNS packets over IPv6.
-
-
-7.  Deployment scenarios and examples
-
-   In this section we illustrate how the DNS64 behaves in different
-   scenarios that are expected to be common.  In particular we will
-   consider the following scenarios defined in
-   [I-D.ietf-behave-v6v4-framework]: the an-IPv6-network-to-IPv4-
-   Internet scenario (both with DNS64 in DNS server mode and in stub-
-   resolver mode) and the IPv6-Internet-to-an-IPv4-network setup (with
-   DNS64 in DNS server mode only).
-
-   In all the examples below, there is a IPv6/IPv4 translator connecting
-   the IPv6 domain to the IPv4 one.  Also there is a name server that is
-   a dual-stack node, so it can communicate with IPv6 hosts using IPv6
-   and with IPv4 nodes using IPv4.  In addition, we assume that in the
-   examples, the DNS64 function learns which IPv6 prefix it needs to use
-   to map the IPv4 address space through manual configuration.
-
-7.1.  Example of An-IPv6-network-to-IPv4-Internet setup with DNS64 in
-      DNS server mode
-
-   In this example, we consider an IPv6 node located in an IPv6-only
-   site that initiates a communication to an IPv4 node located in the
-   IPv4 Internet.
-
-   The scenario for this case is depicted in the following figure:
-
-
-
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 22]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-             +---------------------+         +---------------+
-             |IPv6 network         |         |    IPv4       |
-             |           |  +-------------+  |  Internet     |
-             |           |--| Name server |--|               |
-             |           |  | with DNS64  |  |  +----+       |
-             |  +----+   |  +-------------+  |  | H2 |       |
-             |  | H1 |---|         |         |  +----+       |
-             |  +----+   |   +------------+  |  192.0.2.1    |
-             |           |---| IPv6/IPv4  |--|               |
-             |           |   | Translator |  |               |
-             |           |   +------------+  |               |
-             |           |         |         |               |
-             +---------------------+         +---------------+
-
-    Figure 4: An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS
-                                server mode
-
-   The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
-   address 192.0.2.1 and FQDN h2.example.com.
-
-   The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to
-   its IPv4 interface and it is using the WKP 64:FF9B::/96 to create
-   IPv6 representations of IPv4 addresses.  The same prefix is
-   configured in the DNS64 function in the local name server.
-
-   For this example, assume the typical DNS situation where IPv6 hosts
-   have only stub resolvers, and they are configured with the IP address
-   of a name server that they always have to query and that performs
-   recursive lookups (henceforth called "the recursive nameserver").
-
-   The steps by which H1 establishes communication with H2 are:
-
-   1.  H1 does a DNS lookup for h2.example.com.  H1 does this by sending
-       a DNS query for a AAAA record for H2 to the recursive name
-       server.  The recursive name server implements DNS64
-       functionality.
-
-   2.  The recursive name server resolves the query, and discovers that
-       there are no AAAA records for H2.
-
-   3.  The recursive name server performs an A-record query for H2 and
-       gets back an RRset containing a single A record with the IPv4
-       address 192.0.2.1.  The name server then synthesizes a AAAA
-       record.  The IPv6 address in the AAAA record contains the prefix
-       assigned to the IPv6/IPv4 Translator in the upper 96 bits and the
-       received IPv4 address in the lower 32 bits i.e. the resulting
-       IPv6 address is 64:FF9B::192.0.2.1.
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 23]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   4.  H1 receives the synthetic AAAA record and sends a packet towards
-       H2.  The packet is sent to the destination address 64:FF9B::
-       192.0.2.1.
-
-   5.  The packet is routed to the IPv6 interface of the IPv6/IPv4
-       translator and the subsequent communication flows by means of the
-       IPv6/IPv4 translator mechanisms.
-
-7.2.  An example of an-IPv6-network-to-IPv4-Internet setup with DNS64 in
-      stub-resolver mode
-
-   This case is depicted in the following figure:
-
-
-             +---------------------+         +---------------+
-             |IPv6 network         |         |    IPv4       |
-             |           |     +--------+    |  Internet     |
-             |           |-----| Name   |----|               |
-             | +-----+   |     | server |    |  +----+       |
-             | | H1  |   |     +--------+    |  | H2 |       |
-             | |with |---|         |         |  +----+       |
-             | |DNS64|   |   +------------+  |  192.0.2.1    |
-             | +----+    |---| IPv6/IPv4  |--|               |
-             |           |   | Translator |  |               |
-             |           |   +------------+  |               |
-             |           |         |         |               |
-             +---------------------+         +---------------+
-
-
-   Figure 5: An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-
-                               resolver mode
-
-   The figure shows an IPv6 node H1 implementing the DNS64 function and
-   an IPv4 node H2 with IPv4 address 192.0.2.1 and FQDN h2.example.com.
-
-   The IPv6/IPv4 Translator has an IPv4 address 203.0.113.1 assigned to
-   its IPv4 interface and it is using the WKP 64:FF9B::/96 to create
-   IPv6 representations of IPv4 addresses.  The same prefix is
-   configured in the DNS64 function in H1.
-
-   For this example, assume the typical DNS situation where IPv6 hosts
-   have only stub resolvers, and they are configured with the IP address
-   of a name server that they always have to query and that performs
-   recursive lookups (henceforth called "the recursive nameserver").
-   The recursive name server does not perform the DNS64 function.
-
-   The steps by which H1 establishes communication with H2 are:
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 24]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   1.  H1 does a DNS lookup for h2.example.com.  H1 does this by sending
-       a DNS query for a AAAA record for H2 to the recursive name
-       server.
-
-   2.  The recursive DNS server resolves the query, and returns the
-       answer to H1.  Because there are no AAAA records in the global
-       DNS for H2, the answer is empty.
-
-   3.  The stub resolver at H1 then queries for an A record for H2 and
-       gets back an A record containing the IPv4 address 192.0.2.1.  The
-       DNS64 function within H1 then synthesizes a AAAA record.  The
-       IPv6 address in the AAAA record contains the prefix assigned to
-       the IPv6/IPv4 translator in the upper 96 bits, then the received
-       IPv4 address i.e. the resulting IPv6 address is 64:FF9B::
-       192.0.2.1.
-
-   4.  H1 sends a packet towards H2.  The packet is sent to the
-       destination address 64:FF9B::192.0.2.1.
-
-   5.  The packet is routed to the IPv6 interface of the IPv6/IPv4
-       translator and the subsequent communication flows using the IPv6/
-       IPv4 translator mechanisms.
-
-7.3.  Example of IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS
-      server mode
-
-   In this example, we consider an IPv6 node located in the IPv6
-   Internet that initiates a communication to an IPv4 node located in
-   the IPv4 site.
-
-   In some cases, this scenario can be addressed without using any form
-   of DNS64 function.  This is so because it is possible to assign a
-   fixed IPv6 address to each of the IPv4 nodes.  Such an IPv6 address
-   would be constructed using the address transformation algorithm
-   defined in [I-D.ietf-behave-address-format] that takes as input the
-   Pref64::/96 and the IPv4 address of the IPv4 node.  Note that the
-   IPv4 address can be a public or a private address; the latter does
-   not present any additional difficulty, since an NSP must be used as
-   Pref64::/96 (in this scenario the usage of the Well-Known prefix is
-   not supported as discussed in [I-D.ietf-behave-address-format]).
-   Once these IPv6 addresses have been assigned to represent the IPv4
-   nodes in the IPv6 Internet, real AAAA RRs containing these addresses
-   can be published in the DNS under the site's domain.  This is the
-   recommended approach to handle this scenario, because it does not
-   involve synthesizing AAAA records at the time of query.
-
-   However, there are some more dynamic scenarios, where synthesizing
-   AAAA RRs in this setup may be needed.  In particular, when DNS Update
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 25]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
-   nodes, there are two options: One option is to modify the DNS server
-   that receives the dynamic DNS updates.  That would normally be the
-   authoritative server for the zone.  So the authoritative zone would
-   have normal AAAA RRs that are synthesized as dynamic updates occur.
-   The other option is modify all the authoritative servers to generate
-   synthetic AAAA records for a zone, possibly based on additional
-   constraints, upon the receipt of a DNS query for the AAAA RR.  The
-   first option -- in which the AAAA is synthesized when the DNS update
-   message is received, and the data published in the relevant zone --
-   is recommended over the second option (i.e. the synthesis upon
-   receipt of the AAAA DNS query).  This is because it is usually easier
-   to solve problems of misconfiguration when the DNS responses are not
-   being generated dynamically.  However, it may be the case where the
-   primary server (that receives all the updates) cannot be upgraded for
-   whatever reason, but where a secondary can be upgraded in order to
-   handle the (comparatively small amount) of AAAA queries.  In such
-   case, it is possible to use the DNS64 as described next.  The DNS64
-   behavior that we describe in this section covers the case of
-   synthesizing the AAAA RR when the DNS query arrives.
-
-   The scenario for this case is depicted in the following figure:
-
-
-              +-----------+          +----------------------+
-              |           |          |   IPv4 site          |
-              |   IPv6    |    +------------+  |   +----+   |
-              | Internet  |----| IPv6/IPv4  |--|---| H2 |   |
-              |           |    | Translator |  |   +----+   |
-              |           |    +------------+  |            |
-              |           |          |         | 192.0.2.1  |
-              |           |    +------------+  |            |
-              |           |----| Name server|--|            |
-              |           |    | with DNS64 |  |            |
-              +-----------+    +------------+  |            |
-                |                    |         |            |
-              +----+                 |                      |
-              | H1 |                 +----------------------+
-              +----+
-
-   Figure 6: IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server
-                                   mode
-
-   The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
-   address 192.0.2.1 and FQDN h2.example.com.
-
-   The IPv6/IPv4 Translator is using a NSP 2001:DB8::/96 to create IPv6
-   representations of IPv4 addresses.  The same prefix is configured in
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 26]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   the DNS64 function in the local name server.  The name server that
-   implements the DNS64 function is the authoritative name server for
-   the local domain.
-
-   The steps by which H1 establishes communication with H2 are:
-
-   1.  H1 does a DNS lookup for h2.example.com.  H1 does this by sending
-       a DNS query for a AAAA record for H2.  The query is eventually
-       forwarded to the server in the IPv4 site.
-
-   2.  The local DNS server resolves the query (locally), and discovers
-       that there are no AAAA records for H2.
-
-   3.  The name server verifies that h2.example.com and its A RR are
-       among those that the local policy defines as allowed to generate
-       a AAAA RR from.  If that is the case, the name server synthesizes
-       a AAAA record from the A RR and the prefix 2001:DB8::/96.  The
-       IPv6 address in the AAAA record is 2001:DB8::192.0.2.1.
-
-   4.  H1 receives the synthetic AAAA record and sends a packet towards
-       H2.  The packet is sent to the destination address 2001:DB8::
-       192.0.2.1.
-
-   5.  The packet is routed through the IPv6 Internet to the IPv6
-       interface of the IPv6/IPv4 translator and the communication flows
-       using the IPv6/IPv4 translator mechanisms.
-
-
-8.  Security Considerations
-
-   DNS64 operates in combination with the DNS, and is therefore subject
-   to whatever security considerations are appropriate to the DNS mode
-   in which the DNS64 is operating (i.e. authoritative, recursive, or
-   stub resolver mode).
-
-   DNS64 has the potential to interfere with the functioning of DNSSEC,
-   because DNS64 modifies DNS answers, and DNSSEC is designed to detect
-   such modification and to treat modified answers as bogus.  See the
-   discussion above in Section 3, Section 5.5, and Section 6.2.
-
-   Additionally, for the correct functioning of the translation
-   services, the DNS64 and the NAT64 need to use the same Pref64.  If an
-   attacker manages to change the Pref64 used by the DNS64, the traffic
-   generated by the host that receives the synthetic reply will be
-   delivered to the altered Pref64.  This can result in either a DoS
-   attack (if resulting IPv6 addresses are not assigned to any device)
-   or in a flooding attack (if the resulting IPv6 addresses are assigned
-   to devices that do not wish to receive the traffic) or in
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 27]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   eavesdropping attack (in case the Pref64 is routed through the
-   attacker).
-
-
-9.  IANA Considerations
-
-   This memo makes no request of IANA.
-
-
-10.  Contributors
-
-      Dave Thaler
-
-      Microsoft
-
-      dthaler@windows.microsoft.com
-
-
-11.  Acknowledgements
-
-   This draft contains the result of discussions involving many people,
-   including the participants of the IETF BEHAVE Working Group.  The
-   following IETF participants made specific contributions to parts of
-   the text, and their help is gratefully acknowledged: Jaap Akkerhuis,
-   Mark Andrews, Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker,
-   Doug Barton, Marc Blanchet, Cameron Byrne, Brian Carpenter, Zhen Cao,
-   Hui Deng, Francis Dupont, Patrik Faltstrom, David Harrington, Ed
-   Jankiewicz, Peter Koch, Suresh Krishnan, Martti Kuparinen, Ed Lewis,
-   Xing Li, Bill Manning, Matthijs Mekking, Hiroshi Miyata, Simon
-   Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler, Mark Townsley,
-   Rick van Rein, Stig Venaas, Magnus Westerlund, Jeff Westhead, Florian
-   Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui.
-
-   Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
-   Trilogy, a research project supported by the European Commission
-   under its Seventh Framework Program.
-
-
-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.
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 28]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
-              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
-              RFC 4787, January 2007.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-   [I-D.ietf-behave-address-format]
-              Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
-              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
-              draft-ietf-behave-address-format-10 (work in progress),
-              August 2010.
-
-12.2.  Informative References
-
-   [I-D.ietf-behave-v6v4-xlate-stateful]
-              Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
-              NAT64: Network Address and Protocol Translation from IPv6
-              Clients to IPv4 Servers",
-              draft-ietf-behave-v6v4-xlate-stateful-12 (work in
-              progress), July 2010.
-
-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
-              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-              RFC 2136, April 1997.
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2308, March 1998.
-
-   [RFC3484]  Draves, R., "Default Address Selection for Internet
-              Protocol version 6 (IPv6)", RFC 3484, February 2003.
-
-   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
-              "DNS Extensions to Support IP Version 6", RFC 3596,
-              October 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.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 29]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4074]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against
-              DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
-
-   [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
-              BCP 153, RFC 5735, January 2010.
-
-   [I-D.ietf-behave-v6v4-framework]
-              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
-              IPv4/IPv6 Translation",
-              draft-ietf-behave-v6v4-framework-10 (work in progress),
-              August 2010.
-
-   [I-D.ietf-dnsop-default-local-zones]
-              Andrews, M., "Locally-served DNS Zones",
-              draft-ietf-dnsop-default-local-zones-14 (work in
-              progress), September 2010.
-
-
-Appendix A.  Motivations and Implications of synthesizing AAAA Resource
-             Records when real AAAA Resource Records exist
-
-   The motivation for synthesizing AAAA RRs when real AAAA RRs exist is
-   to support the following scenario:
-
-      An IPv4-only server application (e.g. web server software) is
-      running on a dual-stack host.  There may also be dual-stack server
-      applications running on the same host.  That host has fully
-      routable IPv4 and IPv6 addresses and hence the authoritative DNS
-      server has an A and a AAAA record.
-
-      An IPv6-only client (regardless of whether the client application
-      is IPv6-only, the client stack is IPv6-only, or it only has an
-      IPv6 address) wants to access the above server.
-
-      The client issues a DNS query to a DNS64 resolver.
-
-   If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
-   then the communication will fail.  Even though there's a real AAAA,
-   the only way for communication to succeed is with the translated
-   address.  So, in order to support this scenario, the administrator of
-   a DNS64 service may want to enable the synthesis of AAAA RRs even
-   when real AAAA RRs exist.
-
-   The implication of including synthetic AAAA RRs when real AAAA RRs
-   exist is that translated connectivity may be preferred over native
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 30]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   connectivity in some cases where the DNS64 is operated in DNS server
-   mode.
-
-   RFC3484 [RFC3484] rules use longest prefix match to select the
-   preferred destination address to use.  So, if the DNS64 resolver
-   returns both the synthetic AAAA RRs and the real AAAA RRs, then if
-   the DNS64 is operated by the same domain as the initiating host, and
-   a global unicast prefix (called an NSP in
-   [I-D.ietf-behave-address-format]) is used, then a synthetic AAAA RR
-   is likely to be preferred.
-
-   This means that without further configuration:
-
-      In the "An IPv6 network to the IPv4 Internet" scenario, the host
-      will prefer translated connectivity if an NSP is used.  If the
-      Well-Known Prefix defined in [I-D.ietf-behave-address-format] is
-      used, it will probably prefer native connectivity.
-
-      In the "IPv6 Internet to an IPv4 network" scenario, it is possible
-      to bias the selection towards the real AAAA RR if the DNS64
-      resolver returns the real AAAA first in the DNS reply, when an NSP
-      is used (the Well-Known Prefix usage is not supported in this
-      case)
-
-      In the "An IPv6 network to IPv4 network" scenario, for local
-      destinations (i.e., target hosts inside the local site), it is
-      likely that the NSP and the destination prefix are the same, so we
-      can use the order of RR in the DNS reply to bias the selection
-      through native connectivity.  If the Well-Known Prefix is used,
-      the longest prefix match rule will select native connectivity.
-
-   The problem can be solved by properly configuring the RFC3484
-   [RFC3484] policy table.
-
-
-Authors' Addresses
-
-   Marcelo Bagnulo
-   UC3M
-   Av. Universidad 30
-   Leganes, Madrid  28911
-   Spain
-
-   Phone: +34-91-6249500
-   Fax:
-   Email: marcelo@it.uc3m.es
-   URI:   http://www.it.uc3m.es/marcelo
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 31]
-
-Internet-Draft                    DNS64                     October 2010
-
-
-   Andrew Sullivan
-   Shinkuro
-   4922 Fairmont Avenue, Suite 250
-   Bethesda, MD  20814
-   USA
-
-   Phone: +1 301 961 3131
-   Email: ajs@shinkuro.com
-
-
-   Philip Matthews
-   Unaffiliated
-   600 March Road
-   Ottawa, Ontario
-   Canada
-
-   Phone: +1 613-592-4343 x224
-   Fax:
-   Email: philip_matthews@magma.ca
-   URI:
-
-
-   Iljitsch van Beijnum
-   IMDEA Networks
-   Av. Universidad 30
-   Leganes, Madrid  28911
-   Spain
-
-   Phone: +34-91-6246245
-   Email: iljitsch@muada.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al.           Expires April 4, 2011                [Page 32]
-
diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-14.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-14.txt
deleted file mode 100644
index f33a3fa9..00000000
--- a/doc/draft/draft-ietf-dnsext-axfr-clarify-14.txt
+++ /dev/null
@@ -1,1571 +0,0 @@
-
-
-
-
-DNS Extensions Working Group                                Edward Lewis
-Internet-Draft                                             NeuStar, Inc.
-Updates: 1034, 1035 (if approved)                         A. Hoenes, Ed.
-Intended status: Standards Track                                  TR-Sys
-Expires: September 26, 2010                               March 26, 2010
-
-
-                    DNS Zone Transfer Protocol (AXFR)
-                    draft-ietf-dnsext-axfr-clarify-14
-
-Abstract
-
-   The standard means within the Domain Name System protocol for
-   maintaining coherence among a zone's authoritative name servers
-   consists of three mechanisms.  Authoritative Transfer (AXFR) is one
-   of the mechanisms and is defined in RFC 1034 and RFC 1035.
-
-   The definition of AXFR has proven insufficient in detail, thereby
-   forcing implementations intended to be compliant to make assumptions,
-   impeding interoperability.  Yet today we have a satisfactory set of
-   implementations that do interoperate.  This document is a new
-   definition of AXFR -- new in the sense that it records an accurate
-   definition of an interoperable AXFR mechanism.
-
-Status of this Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.  This document may contain material
-   from IETF Documents or IETF Contributions published or made publicly
-   available before November 10, 2008.  The person(s) controlling the
-   copyright in some of this material may not have granted the IETF
-   Trust the right to allow modifications of such material outside the
-   IETF Standards Process.  Without obtaining an adequate license from
-   the person(s) controlling the copyright in such materials, this
-   document may not be modified outside the IETF Standards Process, and
-   derivative works of it may not be created outside the IETF Standards
-   Process, except to format it for publication as an RFC or to
-   translate it into languages other than English.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress".
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-
-Lewis & Hoenes         Expires September 26, 2010               [Page 1]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-   This Internet-Draft will expire on September 26, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010               [Page 2]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
-   1.1.  Definition of Terms  . . . . . . . . . . . . . . . . . . .  4
-   1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   1.3.  Context  . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   1.4.  Coverage and Relationship to Original AXFR Specification .  5
-   2.  AXFR Messages  . . . . . . . . . . . . . . . . . . . . . . .  7
-   2.1.  AXFR query . . . . . . . . . . . . . . . . . . . . . . . .  8
-   2.1.1.  Header Values  . . . . . . . . . . . . . . . . . . . . .  9
-   2.1.2.  Question Section . . . . . . . . . . . . . . . . . . . . 10
-   2.1.3.  Answer Section . . . . . . . . . . . . . . . . . . . . . 10
-   2.1.4.  Authority Section  . . . . . . . . . . . . . . . . . . . 10
-   2.1.5.  Additional Section . . . . . . . . . . . . . . . . . . . 10
-   2.2.  AXFR Response  . . . . . . . . . . . . . . . . . . . . . . 11
-   2.2.1.  Header Values  . . . . . . . . . . . . . . . . . . . . . 12
-   2.2.2.  Question Section . . . . . . . . . . . . . . . . . . . . 14
-   2.2.3.  Answer Section . . . . . . . . . . . . . . . . . . . . . 14
-   2.2.4.  Authority Section  . . . . . . . . . . . . . . . . . . . 14
-   2.2.5.  Additional Section . . . . . . . . . . . . . . . . . . . 14
-   2.3.  TCP Connection Aborts  . . . . . . . . . . . . . . . . . . 15
-   3.  Zone Contents  . . . . . . . . . . . . . . . . . . . . . . . 15
-   3.1.  Records to Include . . . . . . . . . . . . . . . . . . . . 15
-   3.2.  Delegation Records . . . . . . . . . . . . . . . . . . . . 16
-   3.3.  Glue Records . . . . . . . . . . . . . . . . . . . . . . . 18
-   3.4.  Name Compression . . . . . . . . . . . . . . . . . . . . . 18
-   3.5.  Occluded Names . . . . . . . . . . . . . . . . . . . . . . 19
-   4.  Transport  . . . . . . . . . . . . . . . . . . . . . . . . . 19
-   4.1.  TCP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
-   4.1.1.  AXFR client TCP  . . . . . . . . . . . . . . . . . . . . 20
-   4.1.2.  AXFR server TCP  . . . . . . . . . . . . . . . . . . . . 21
-   4.2.  UDP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
-   5.  Authorization  . . . . . . . . . . . . . . . . . . . . . . . 22
-   6.  Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23
-   7.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . 24
-   7.1.  Server . . . . . . . . . . ..  . . . . . . . . . . . . . . 24
-   7.2.  Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . 25
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . 25
-   10.  Internationalization Considerations . . . . . . . . . . . . 25
-   11.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
-   12.  References  . . . . . . . . . . . . . . . . . . . . . . . . 26
-   12.1.  Normative References  . ..  . . . . . . . . . . . . . . . 26
-   12.2.  Informative References  . . . . . . . . . . . . . . . . . 28
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
-
-
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010               [Page 3]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-1.  Introduction
-
-   The Domain Name System standard facilities for maintaining coherent
-   servers for a zone consist of three elements.  Authoritative Transfer
-   (AXFR) is defined in "Domain Names - Concepts and Facilities"
-   [RFC1034] (referred to in this document as RFC 1034) and "Domain
-   Names - Implementation and Specification" [RFC1035] (henceforth
-   RFC 1035).  Incremental Zone Transfer (IXFR) is defined in
-   "Incremental Zone Transfer in DNS" [RFC1995].  A mechanism for prompt
-   notification of zone changes (NOTIFY) is defined in "A Mechanism for
-   Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996].  The
-   goal of these mechanisms is to enable a set of DNS name servers to
-   remain coherently authoritative for a given zone.
-
-   This document re-specifies the AXFR mechanism as it is deployed in
-   the Internet at large, hopefully with the precision expected from
-   modern Internet Standards, and thereby updates RFC 1034 and RFC 1035.
-
-1.1.  Definition of Terms
-
-   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 "Key words for use in
-   RFCs to Indicate Requirement Levels" [BCP14].
-
-   Use of "newer"/"new" and "older"/"old" DNS refers to implementations
-   written after and prior to the publication of this document.
-
-   "General purpose DNS implementation" refers to DNS software developed
-   for widespread use.  This includes resolvers and servers freely
-   accessible as libraries and standalone processes.  This also includes
-   proprietary implementations used only in support of DNS service
-   offerings.
-
-   "Turnkey DNS implementation" refers to custom made, single use
-   implementations of DNS.  Such implementations consist of software
-   that employs the DNS protocol message format yet does not conform to
-   the entire range of DNS functionality.
-
-   The terms "AXFR session", "AXFR server" and "AXFR client" will be
-   introduced in the first paragraph of Section 2, after some more
-   context has been established.
-
-1.2.  Scope
-
-   In general terms, authoritative name servers for a given zone can use
-   various means to achieve coherency of the zone contents they serve.
-   For example, there are DNS implementations that assemble answers from
-   data stored in relational databases (as opposed to master files),
-
-
-Lewis & Hoenes         Expires September 26, 2010               [Page 4]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   relying on the database's non-DNS means to synchronize the database
-   instances.  Some of these non-DNS solutions interoperate in some
-   fashion.  However, AXFR, IXFR, and NOTIFY are the only protocol-
-   defined in-band mechanisms to provide coherence of a set of name
-   servers, and they are the only mechanisms specified by the IETF.
-
-   This document does not cover incoherent DNS situations.  There are
-   applications of the DNS in which servers for a zone are designed to
-   be incoherent.  For these configurations, a coherency mechanism as
-   described here would be unsuitable.
-
-   A DNS implementation is not required to support AXFR, IXFR, and
-   NOTIFY, but it should have some means for maintaining name server
-   coherency.  A general purpose DNS implementation will likely support
-   AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS
-   implementations may exist without AXFR.
-
-1.3.  Context
-
-   Besides describing the mechanisms themselves, there is the context in
-   which they operate to consider.  In the initial specifications of
-   AXFR (and IXFR and NOTIFY), little consideration was given to
-   security and privacy issues.  Since the original definition of AXFR,
-   new opinions have appeared on the access to an entire zone's
-   contents.  In this document, the basic mechanisms will be discussed
-   separately from the permission to use these mechanisms.
-
-1.4.  Coverage and Relationship to Original AXFR Specification
-
-   This document concentrates on just the definition of AXFR.  Any
-   effort to update the specification of the IXFR or NOTIFY mechanisms
-   is left to different documents.
-
-   The original "specification" of the AXFR sub-protocol is scattered
-   through RFC 1034 and RFC 1035.  Section 2.2 of RFC 1035 (on page 5)
-   depicts the scenario for which AXFR has been designed.  Section 4.3.5
-   of RFC 1034 describes the zone synchronization strategies in general
-   and rules for the invocation of a full zone transfer via AXFR; the
-   fifth paragraph of that section contains a very short sketch of the
-   AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
-   flaw in that specification.  Section 3.2.3 of RFC 1035 has assigned
-   the code point for the AXFR QTYPE (see Section 2.1.2 below for more
-   details).  Section 4.2 of RFC 1035 discusses how the DNS uses the
-   transport layer and briefly explains why UDP transport is deemed
-   inappropriate for AXFR; the last paragraph of Section 4.2.2 gives
-   details regarding TCP connection management for AXFR.  Finally, the
-   second paragraph of Section 6.3 in RFC 1035 mandates server behavior
-   when zone data changes occur during an ongoing zone transfer using
-   AXFR.
-
-
-Lewis & Hoenes         Expires September 26, 2010               [Page 5]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   This document will update the specification of AXFR.  To this end, it
-   fully specifies the record formats and processing rules for AXFR,
-   largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it
-   details the transport considerations for AXFR, thus amending Section
-   4.2.2 of RFC 1035.  Furthermore, it discusses backward compatibility
-   issues and provides policy/management considerations as well as
-   specific Security Considerations for AXFR.  The goal of this document
-   is to define AXFR as it is understood by the DNS community to exist
-   today.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010               [Page 6]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-2.  AXFR Messages
-
-   An AXFR session consists of an AXFR query message and the sequence of
-   AXFR response messages returned for it.  In this document, the AXFR
-   client is the sender of the AXFR query and the AXFR server is the
-   responder.  (Use of terms such as master, slave, primary, secondary
-   are not important for defining AXFR.)  The use of the word "session"
-   without qualification refers to an AXFR session.
-
-   An important aspect to keep in mind is that the definition of AXFR is
-   restricted to TCP [RFC0793] (see Section 4 for details).  The design
-   of the AXFR process has certain inherent features that are not easily
-   ported to UDP [RFC0768].
-
-   The basic format of an AXFR message is the DNS message as defined in
-   Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the
-   following documents.
-
-   o  The 'Basic' DNS specification:
-
-   -  "A Mechanism for Prompt Notification of Zone Changes (DNS Notify)"
-       [RFC1996]
-   -  "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
-   -  "Clarifications to the DNS Specification" [RFC2181]
-   -  "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
-   -  "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
-   -  "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
-   -  "Obsoleting IQUERY" [RFC3425]
-   -  "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597]
-   -  "HMAC SHA TSIG Algorithm Identifiers" [RFC4635]
-   -  "Domain Name System (DNS) IANA Considerations" [RFC5395]
-
-   o  Further additions related to the DNS Security Extensions (DNSSEC),
-      defined in these base documents:
-
-   -  "DNS Security Introduction and Requirements" [RFC4033]
-   -  "Resource Records for the DNS Security Extensions" [RFC4034]
-   -  "Protocol Modifications for the DNS Security Extensions" [RFC4035]
-   -  "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509]
-   -  "DNS Security Hashed Authenticated Denial of Existence" [RFC5155]
-   -  "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource
-       Records for DNSSEC" [RFC5702]
-   -  "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U]
-
-   These documents contain information about the syntax and semantics of
-   DNS messages.  They do not interfere with AXFR but are also helpful
-   in understanding what will be carried via AXFR.
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010               [Page 7]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   For convenience, the synopsis of the DNS message header from
-   [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is
-   reproduced here informally:
-
-                 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                      ID                       |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |QR|   OpCode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                QDCOUNT/ZOCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                ANCOUNT/PRCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                NSCOUNT/UPCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                    ARCOUNT                    |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   This document makes use of the field names as they appear in this
-   diagram.  The names of sections in the body of DNS messages are
-   capitalized in this document for clarity, e.g., "Additional section".
-
-   The DNS message size limit from [RFC1035] for DNS over UDP (and its
-   extension via the EDNS0 mechanism specified in [RFC2671]) is not
-   relevant for AXFR, as explained in Section 4.  The upper limit on the
-   permissible size of a DNS message over TCP is only restricted by the
-   TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a
-   two-octet message length field, understood to be unsigned, and thus
-   causing a limit of 65535 octets.  This limit is not changed by EDNS0.
-
-   Note that the TC (truncation) bit is never set by an AXFR server nor
-   considered/read by an AXFR client.
-
-2.1.  AXFR query
-
-   An AXFR query is sent by a client whenever there is a reason to ask.
-   This might be because of scheduled or triggered zone maintenance
-   activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996],
-   respectively) or as a result of a command line request, say for
-   debugging.
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010               [Page 8]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-2.1.1.  Header Values
-
-   These are the DNS message header values for an AXFR query.
-
-      ID          Selected by client; see Note a)
-
-      QR          MUST be 0 (Query)
-
-      OPCODE      MUST be 0 (Standard Query)
-
-      Flags:
-         AA       'n/a' -- see Note b)
-         TC       'n/a' -- see Note b)
-         RD       'n/a' -- see Note b)
-         RA       'n/a' -- see Note b)
-         Z        'mbz' -- see Note c)
-         AD       'n/a' -- see Note b)
-         CD       'n/a' -- see Note b)
-
-      RCODE       MUST be 0 (No error)
-
-      QDCOUNT     Number of entries in Question section;   MUST be 1
-
-      ANCOUNT     Number of entries in Answer section;     MUST be 0
-
-      NSCOUNT     Number of entries in Authority section;  MUST be 0
-
-      ARCOUNT     Number of entries in Additional section -- see Note d)
-
-   Notes:
-
-   a) Set to any value that the client is not already using with the
-      same server.  There is no specific means for selecting the value
-      in this field.  (Recall that AXFR is done only via TCP connections
-      -- see Section 4 "Transport".)
-
-      A server MUST reply using messages that use the same message ID to
-      allow a client to have multiple queries outstanding concurrently
-      over the same TCP connection -- see Note a) in Section 2.2.1 for
-      more details.
-
-   b) 'n/a' -- The value in this field has no meaning in the context of
-      AXFR query messages.  For the client, it is RECOMMENDED that the
-      value be zero.  The server MUST ignore this value.
-
-   c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore
-      it.
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010               [Page 9]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   d) The client MUST set this field to the number of resource records
-      it places into the Additional section.  In the absence of explicit
-      specification of new RRs to be carried in the Additional section
-      of AXFR queries, the value MAY be 0, 1 or 2.  See Section 2.1.5
-      "Additional Section" for details on the currently applicable RRs.
-
-2.1.2.  Question Section
-
-   The Question section of the AXFR query MUST conform to Section 4.1.2
-   of RFC 1035, and contain a single resource record with the following
-   values:
-
-      QNAME       the name of the zone requested
-
-      QTYPE       AXFR (= 252), the pseudo-RR type for zone transfer
-                  [DNSVALS]
-
-      QCLASS      the class of the zone requested [DNSVALS]
-
-2.1.3.  Answer Section
-
-   The Answer section MUST be empty.
-
-2.1.4.  Authority Section
-
-   The Authority section MUST be empty.
-
-2.1.5.  Additional Section
-
-   Currently, two kinds of resource records are defined that can appear
-   in the Additional section of AXFR queries and responses: EDNS and DNS
-   transaction security.  Future specifications defining RRs that can be
-   carried in the Additional section of normal DNS transactions need to
-   explicitly describe their use with AXFR, should that be desired.
-
-   The client MAY include one OPT resource record [RFC2671].  If
-   the server does not support EDNS0, the client MUST send this section
-   without an OPT resource record if there is a retry.  However,
-   the protocol does not define an explicit indication that the server
-   does not support EDNS0; that needs to be inferred by the client.
-   Often, the server will return a FormErr(1) which might be related to
-   the OPT resource record.  Note that, at the time of this writing,
-   only the EXTENDED-RCODE field of the OPT RR is meaningful in
-   the context of AXFR; future specifications of EDNS flags and/or
-   EDNS options must describe their usage in the context of AXFR, if
-   applicable.
-
-   The client MAY include one transaction integrity and authentication
-   resource record, currently a choice of TSIG [RFC2845] or SIG(0)
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 10]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   [RFC2931].  If the server has indicated that it does not recognize
-   the resource record, and that the error is indeed caused by the
-   resource record, the client probably should not try again.  Removing
-   the security data in the face of an obstacle ought to only be done
-   with full awareness of the implication of doing so.
-
-   In general, if an AXFR client is aware that an AXFR server does not
-   support a particular mechanism, the client SHOULD NOT attempt to
-   engage the server using the mechanism (or at all).  A client could
-   become aware of a server's abilities via a configuration setting or
-   via some other (as yet) undefined means.
-
-   The range of permissible resource records that MAY appear in the
-   Additional section might change over time.  If either a change to an
-   existing resource record (like the OPT RR for EDNS) is made or a new
-   Additional section record is created, the new definitions ought to
-   include a discussion on the applicability and impact upon AXFR.
-   Future resource records residing in the Additional section might have
-   an effect that is orthogonal to AXFR, so can ride through the session
-   as opaque data.  In this case, a "wise" implementation ought to be
-   able to pass these records through without disruption.
-
-2.2.  AXFR Response
-
-   The AXFR response will consist of one or more messages.  The special
-   case of a server closing the TCP connection without sending an AXFR
-   response is covered in section 2.3.
-
-   An AXFR response that is transferring the zone's contents will
-   consist of a series (which could be a series of length 1) of DNS
-   messages.  In such a series, the first message MUST begin with the
-   SOA resource record of the zone, the last message MUST conclude with
-   the same SOA resource record.  Intermediate messages MUST NOT contain
-   the SOA resource record.  The AXFR server MUST copy the Question
-   section from the corresponding AXFR query message into the first
-   response message's Question section.  For subsequent messages, it MAY
-   do the same or leave the Question section empty.
-
-   The AXFR protocol treats the zone contents as an unordered collection
-   (or to use the mathematical term, a "set") of RRs.  Except for the
-   requirement that the transfer must begin and end with the SOA RR,
-   there is no requirement to send the RRs in any particular order or
-   grouped into response messages in any particular way.  Although
-   servers typically do attempt to send related RRs (such as the RRs
-   forming an RRset, and the RRsets of a name) as a contiguous group or,
-   when message space allows, in the same response message, they are not
-   required to do so, and clients MUST accept any ordering and grouping
-   of the non-SOA RRs.  Each RR SHOULD be transmitted only once, and
-   AXFR clients MUST ignore any duplicate RRs received.
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 11]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   Each AXFR response message SHOULD contain a sufficient number of RRs
-   to reasonably amortize the per-message overhead, up to the largest
-   number that will fit within a DNS message (taking the required
-   content of the other sections into account, as described below).
-   Some old AXFR clients expect each response message to contain only a
-   single RR.  To interoperate with such clients, the server MAY
-   restrict response messages to a single RR.  As there is no standard
-   way to automatically detect such clients, this typically requires
-   manual configuration at the server.
-
-   To indicate an error in an AXFR response, the AXFR server sends a
-   single DNS message when the error condition is detected, with the
-   response code set to the appropriate value for the condition
-   encountered, Such a message terminates the AXFR session; it MUST
-   contain a copy of the Question section from the AXFR query in its
-   Question section, but the inclusion of the terminating SOA resource
-   record is not necessary.
-
-   An AXFR server may send a number of AXFR response messages free of an
-   error condition before it sends the message indicating an error.
-
-2.2.1.  Header Values
-
-   These are the DNS message header values for AXFR responses.
-
-      ID          MUST be copied from request -- see Note a)
-
-      QR          MUST be 1 (Response)
-
-      OPCODE      MUST be 0 (Standard Query)
-
-      Flags:
-         AA       normally 1 -- see Note b)
-         TC       MUST be 0 (Not truncated)
-         RD       RECOMMENDED: copy request's value, MAY be set to 0
-         RA       SHOULD be 0 -- see Note c)
-         Z        'mbz' -- see Note d)
-         AD       'mbz' -- see Note d)
-         CD       'mbz' -- see Note d)
-
-      RCODE       See Note e)
-
-      QDCOUNT     MUST be 1 in the first message;
-                  MUST be 0 or 1 in all following messages;
-                  MUST be 1 if RCODE indicates an error
-
-      ANCOUNT     See Note f)
-
-      NSCOUNT     MUST be 0
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 12]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-      ARCOUNT     See Note g)
-
-   Notes:
-
-   a) Because some old implementations behave differently than is now
-      desired, the requirement on this field is stated in detail.  New
-      DNS servers MUST set this field to the value of the AXFR query ID
-      in each AXFR response message for the session.  AXFR clients MUST
-      be able to manage sessions resulting from the issuance of multiple
-      outstanding queries, whether AXFR queries or other DNS queries.
-      A client SHOULD discard responses that do not correspond (via the
-      message ID) to any outstanding queries.
-
-      Unless the client is sure that the server will consistently set
-      the ID field to the query's ID, the client is NOT RECOMMENDED to
-      issue any other queries until the end of the zone transfer.
-      A client MAY become aware of a server's abilities via a
-      configuration setting.
-
-   b) If the RCODE is 0 (no error), then the AA bit MUST be 1.
-      For any other value of RCODE, the AA bit MUST be set according to
-      the rules for that error code.  If in doubt, it is RECOMMENDED
-      that it be set to 1.  It is RECOMMENDED that the value be ignored
-      by the AXFR client.
-
-   c) It is RECOMMENDED that the server set the value to 0, the client
-      MUST ignore this value.
-
-      The server MAY set this value according to the local policy
-      regarding recursive service, but doing so might confuse the
-      interpretation of the response as AXFR can not be retrieved
-      recursively.  A client MAY note the server's policy regarding
-      recursive service from this value, but SHOULD NOT conclude that
-      the AXFR response was obtained recursively even if the RD bit was
-      1 in the query.
-
-   d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore
-      it.
-
-   e) In the absence of an error, the server MUST set the value of this
-      field to NoError(0).  If a server is not authoritative for the
-      queried zone, the server SHOULD set the value to NotAuth(9).
-      (Reminder, consult the appropriate IANA registry [DNSVALS].)  If a
-      client receives any other value in response, it MUST act according
-      to the error.  For example, a malformed AXFR query or the presence
-      of an OPT resource record sent to an old server will result
-      in a FormErr(1) value.  This value is not set as part of the AXFR-
-      specific response processing.  The same is true for other values
-      indicating an error.
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 13]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   f) The count of answer records MUST equal the number of resource
-      records in the AXFR Answer Section.  When a server is aware that a
-      client will only accept response messages with a single resource
-      record, then the value MUST be 1.  A server MAY be made aware of a
-      client's limitations via configuration data.
-
-   g) The server MUST set this field to the number of resource records
-      it places into the Additional section.  In the absence of explicit
-      specification of new RRs to be carried in the Additional section
-      of AXFR response messages, the value MAY be 0, 1 or 2.  See
-      Section 2.1.5 above for details on the currently applicable RRs
-      and Section 2.2.5 for additional considerations specific to AXFR
-      servers.
-
-2.2.2.  Question Section
-
-   In the first response message, this section MUST be copied from the
-   query.  In subsequent messages, this section MAY be copied from the
-   query or it MAY be empty.  However, in an error response message (see
-   Section 2.2), this section MUST be copied as well.  The content of
-   this section MAY be used to determine the context of the message,
-   that is, the name of the zone being transferred.
-
-2.2.3.  Answer Section
-
-   The Answer section MUST be populated with the zone contents.  See
-   Section 3 below on encoding zone contents.
-
-2.2.4.  Authority Section
-
-   The Authority section MUST be empty.
-
-2.2.5.  Additional Section
-
-   The contents of this section MUST follow the guidelines for the OPT,
-   TSIG, and SIG(0) RRs, or whatever other future record is possible
-   here.  The contents of Section 2.1.5 apply analogously as well.
-
-   The following considerations specifically apply to AXFR responses:
-
-   If the client has supplied an EDNS OPT RR in the AXFR query and if
-   the server supports EDNS as well, it SHOULD include one OPT RR
-   in the first response message and MAY do so in subsequent response
-   messages (see Section 2.2); the specifications of EDNS options to be
-   carried in the OPT RR may impose stronger requirements.
-
-   If the client has supplied a transaction security resource record
-   (currently a choice of TSIG and SIG(0)) and the server supports the
-   method chosen by the client, it MUST place the corresponding resource
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 14]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   record into the AXFR response message(s), according to the rules
-   specified for that method.
-
-2.3.  TCP Connection Aborts
-
-   If an AXFR client sends a query on a TCP connection and the
-   connection is closed at any point, the AXFR client MUST consider the
-   AXFR session terminated.  The message ID MAY be used again on a new
-   connection, even if the question and AXFR server are the same.
-
-   Facing a dropped connection, a client SHOULD try to make some
-   determination as to whether the connection closure was the result of
-   network activity or due to a decision by the AXFR server.  This
-   determination is not an exact science.  It is up to the AXFR client
-   to react, but the implemented reaction SHOULD NOT be either an
-   endless cycle of retries or an increasing (in frequency) retry rate.
-
-   An AXFR server implementor should take into consideration the dilemma
-   described above when a connection is closed with an outstanding query
-   in the pipeline.  For this reason, a server ought to reserve this
-   course of action for situations in which it believes beyond a doubt
-   that the AXFR client is attempting abusive behavior.
-
-
-3.  Zone Contents
-
-   The objective of the AXFR session is to request and transfer the
-   contents of a zone, in order to permit the AXFR client to faithfully
-   reconstruct the zone as it exists at the primary server for the given
-   zone serial number.  The word "exists" here designates the externally
-   visible behavior, i.e., the zone content that is being served (handed
-   out to clients) -- not its persistent representation in a zone file
-   or database used by the server -- and that for consistency should be
-   served subsequently by the AXFR client in an identical manner.
-
-   Over time the definition of a zone has evolved from denoting a static
-   set of records to also cover a dynamically updated set of records,
-   and then a potentially continually regenerated set of records (e.g.,
-   RRs synthesized "on the fly" from rule sets or database lookup
-   results in other forms than RR format) as well.
-
-3.1.  Records to Include
-
-   In the Answer section of AXFR response messages, the resource records
-   within a zone for the given serial number MUST appear.  The
-   definition of what belongs in a zone is described in RFC 1034,
-   Section 4.2, "How the database is divided into zones" (in particular
-   Section 4.2.1, "Technical considerations"), and it has been clarified
-   in Section 6 of RFC 2181.
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 15]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   Zones for which it is impractical to list the entire zone for a
-   serial number are not suitable for AXFR retrieval.  A typical (but
-   not limiting) description of such a zone is a zone consisting of
-   responses generated via other database lookups and/or computed based
-   upon ever changing data.
-
-3.2.  Delegation Records
-
-   In Section 4.2.1 of RFC 1034, this text appears (keep in mind that
-   the "should" in the quotation predates [BCP14], cf. Section 1.1):
-
-      "The RRs that describe cuts ... should be exactly the same as the
-       corresponding RRs in the top node of the subzone."
-
-   There has been some controversy over this statement and the impact on
-   which NS resource records are included in a zone transfer.
-
-   The phrase "that describe cuts" is a reference to the NS set and
-   applicable glue records.  It does not mean that the cut point and
-   apex resource records are identical.  For example, the SOA resource
-   record is only found at the apex.  The discussion here is restricted
-   to just the NS resource record set and glue as these "describe cuts".
-
-   DNSSEC resource records have special specifications regarding their
-   occurrence at a zone cut and the apex of a zone.  This was first
-   described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial
-   specification of DNSSEC), which parts of RFC 2181 now in fact are
-   historical.  The current DNSSEC core document set (see second bullet
-   in Section 2 above) gives the full details for DNSSEC(bis) resource
-   record placement, and Section 3.1.5 of RFC 4035 normatively specifies
-   their treatment during AXFR; the alternate NSEC3 resource record
-   defined later in RFC 5155 behaves identically as the NSEC RR, for the
-   purpose of AXFR.
-   Informally:
-
-   o  The DS RRSet only occurs at the parental side of a zone cut and is
-      authoritative data in the parent zone, not the secure child zone.
-
-   o  The DNSKEY RRSet only occurs at the APEX of a signed zone and is
-      part of the authoritative data of the zone it serves.
-
-   o  Independent RRSIG RRSets occur at the signed parent side of a zone
-      cut and at the apex of a signed zone; they are authoritative data
-      in the respective zone; simple queries for RRSIG resource records
-      may return both RRSets at once if the same server is authoritative
-      for the parent zone and the child zone (Section 3.1.5 of RFC 4035
-      describes how to distinguish these RRs); this seeming ambiguity
-      does not occur for AXFR, since each such RRSIG RRset belongs to a
-      single zone.
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 16]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   o  Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records
-      equally may occur at the parental side of a zone cut and at the
-      apex of a zone; each such resource record belongs to exactly one
-      of these zones and is to be included in the AXFR of that zone.
-
-   One issue is that in operations there are times when the NS resource
-   records for a zone might be different at a cut point in the parent
-   and at the apex of a zone.  Sometimes this is the result of an error
-   and sometimes it is part of an ongoing change in name servers.  The
-   DNS protocol is robust enough to overcome inconsistencies up to (but
-   not including) there being no parent-indicated NS resource record
-   referencing a server that is able to serve the child zone.  This
-   robustness is one quality that has fueled the success of the DNS.
-   Still, the inconsistency is an error state and steps need to be taken
-   to make it apparent (if it is unplanned) and to make it clear once
-   the inconsistency has been removed.
-
-   Another issue is that the AXFR server could be authoritative for a
-   different set of zones than the AXFR client.  It is possible that the
-   AXFR server be authoritative for both halves of an inconsistent cut
-   point and that the AXFR client is authoritative for just the parent
-   side of the cut point.
-
-   When facing a situation in which a cut point's NS resource records do
-   not match the authoritative set, the question arises whether an AXFR
-   server responds with the NS resource record set that is in the zone
-   being transferred or the one that is at the authoritative location.
-
-   The AXFR response MUST contain the cut point NS resource record set
-   registered with the zone whether it agrees with the authoritative set
-   or not.  "Registered with" can be widely interpreted to include data
-   residing in the zone file of the zone for the particular serial
-   number (in zone file environments) or as any data configured to be in
-   the zone (database), statically or dynamically.
-
-   The reasons for this requirement are:
-
-   1) The AXFR server might not be able to determine that there is an
-   inconsistency given local data, hence requiring consistency would
-   mean a lot more needed work and even network retrieval of data.  An
-   authoritative server ought not be required to perform any queries.
-
-   2) By transferring the inconsistent NS resource records from a server
-   that is authoritative for both the cut point and the apex to a client
-   that is not authoritative for both, the error is exposed.  For
-   example, an authorized administrator can manually request the AXFR
-   and inspect the results to see the inconsistent records.  (A server
-   authoritative for both halves would otherwise always answer from the
-   more authoritative set, concealing the error.)
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 17]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   3) The inconsistent NS resource record set might indicate a problem
-   in a registration database.
-
-   4) This requirement is necessary to ensure that retrieving a given
-   (zone,serial) pair by AXFR yields the exact same set of resource
-   records no matter which of the zone's authoritative servers is chosen
-   as the source of the transfer.
-
-   If an AXFR server were allowed to respond with the authoritative NS
-   RRset of a child zone instead of a parent-side NS RRset in the zone
-   being transferred, the set of records returned could vary depending
-   on whether or not the server happened to be authoritative for the
-   child zone as well.
-
-   The property that a given (zone,serial) pair corresponds to a single,
-   well-defined set of records is necessary for the correct operation of
-   incremental transfer protocols such as IXFR [RFC1995].  For example,
-   a client may retrieve a zone by AXFR from one server, and then apply
-   an incremental change obtained by IXFR from a different server.  If
-   the two servers have different ideas of the zone contents, the client
-   can end up attempting to incrementally add records that already exist
-   or to delete records that do not exist.
-
-3.3.  Glue Records
-
-   As quoted in the previous section, Section 4.2.1 of RFC 1034 provides
-   guidance and rationale for the inclusion of glue records as part of
-   an AXFR transfer.  And, as also argued in the previous section of
-   this document, even when there is an inconsistency between the
-   address in a glue record and the authoritative copy of the name
-   server's address, the glue resource record that is registered as part
-   of the zone for that serial number is to be included.
-
-   This applies to glue records for any address family [IANA-AF].
-
-   The AXFR response MUST contain the appropriate glue records as
-   registered with the zone.  The interpretation of "registered with" in
-   the previous section applies here.  Inconsistent glue records are an
-   operational matter.
-
-3.4.  Name Compression
-
-   Compression of names in DNS messages is described in RFC 1035,
-   Section 4.1.4, "Message compression".  The issue highlighted here
-   relates to a comment made in RFC 1034, Section 3.1, "Name space
-   specifications and terminology" which says "When you receive a domain
-   name or label, you should preserve its case."  ("Should" in the quote
-   predates [BCP14].)
-
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 18]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   Since the primary objective of AXFR is to enable the client to serve
-   the same zone content as the server, unlike such normal DNS responses
-   that are expected to preserve the case in the query, the actual zone
-   transfer needs to retain the case of the labels in the zone content.
-   Hence, name compression in an AXFR message SHOULD be performed in a
-   case-preserving manner, unlike how it is done for 'normal' DNS
-   responses.  That is, although when comparing a domain name for
-   matching, "a" equals "A", when comparing for the purposes of message
-   compression for AXFR, "a" is not equal to "A".  Note that this is not
-   the usual definition of name comparison in the DNS protocol and
-   represents a new understanding of the requirement on AXFR servers.
-
-   Rules governing name compression of RDATA in an AXFR message MUST
-   abide by the specification in "Handling of Unknown DNS Resource
-   Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name
-   Compression".
-
-3.5.  Occluded Names
-
-   Dynamic Update [RFC2136] operations, and in particular its
-   interaction with DNAME [RFC2672], can have a side effect of occluding
-   names in a zone.  The addition of a delegation point via dynamic
-   update will render all subordinate domain names to be in a limbo,
-   still part of the zone but not available to the lookup process.  The
-   addition of a DNAME resource record has the same impact.  The
-   subordinate names are said to be "occluded".
-
-   Occluded names MUST be included in AXFR responses.  An AXFR client
-   MUST be able to identify and handle occluded names.  The rationale
-   for this action is based on a speedy recovery if the dynamic update
-   operation was in error and is to be undone.
-
-
-4.  Transport
-
-   AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC
-   1034 that states:  "Because accuracy is essential, TCP or some other
-   reliable protocol must be used for AXFR requests."  The restriction
-   to TCP is also mentioned in Section 6.1.3.2. of "Requirements for
-   Internet Hosts - Application and Support" [RFC1123].
-
-   The most common scenario is for an AXFR client to open a TCP
-   connection to the AXFR server, send an AXFR query, receive the AXFR
-   response, and then close the connection.  But variations of that most
-   simple scenario are legitimate and likely: in particular, sending a
-   query for the zone's SOA resource record first over the same TCP
-   connection, and reusing an existing TCP connection for other queries.
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 19]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   Therefore, the assumption that a TCP connection is dedicated to a
-   single AXFR session is incorrect.  This wrong assumption has led to
-   implementation choices that prevent either multiple concurrent zone
-   transfers or the use of an open connection for other queries.
-
-   Since the early days of the DNS, operators who have sets of name
-   servers that are authoritative for a common set of zones found it
-   desirable to be able to have multiple concurrent zone transfers in
-   progress; this way a name server does not have to wait for one zone
-   transfer to complete before the next can begin.  RFC 1035 did not
-   exclude this possibility, but legacy implementations failed to
-   support this functionality efficiently, over a single TCP connection.
-   The remaining presence of such legacy implementations makes it
-   necessary that new general purpose client implementations still
-   provide options for graceful fallback to the old behavior in their
-   support of concurrent DNS transactions and AXFR sessions on a single
-   TCP connection.
-
-4.1.  TCP
-
-   In the original definition there arguably is an implicit assumption
-   (probably unintentional) that a TCP connection is used for one and
-   only one AXFR session.  This is evidenced in the lack of an explicit
-   requirement to copy the Question section and/or the message ID into
-   responses, no explicit ordering information within the AXFR response
-   messages, and the lack of an explicit notice indicating that a zone
-   transfer continues in the next message.
-
-   The guidance given below is intended to enable better performance of
-   the AXFR exchange as well as provide guidelines on interactions with
-   older software.  Better performance includes being able to multiplex
-   DNS message exchanges including zone transfer sessions.  Guidelines
-   for interacting with older software are generally applicable to new
-   AXFR clients.  In the reverse situation, older AXFR client and newer
-   AXFR server, the server ought to operate within the specification for
-   an older server.
-
-4.1.1.  AXFR client TCP
-
-   An AXFR client MAY request a connection to an AXFR server for any
-   reason.  An AXFR client SHOULD close the connection when there is no
-   apparent need to use the connection for some time period.  The AXFR
-   server ought not have to maintain idle connections; the burden of
-   connection closure ought to be on the client.  "Apparent need" for
-   the connection is a judgment for the AXFR client and the DNS client.
-   If the connection is used for multiple sessions, or if it is known
-   sessions will be coming, or if there is other query/response traffic
-   anticipated or currently on the open connection, then there is
-   "apparent need".
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 20]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   An AXFR client can cancel the delivery of a zone only by closing the
-   connection.  However, this action will also cancel all other
-   outstanding activity using the connection.  There is no other
-   mechanism by which an AXFR response can be cancelled.
-
-   When a TCP connection is closed remotely (relative to the client),
-   whether by the AXFR server or due to a network event, the AXFR client
-   MUST cancel all outstanding sessions and non-AXFR transactions.
-   Recovery from this situation is not straightforward.  If the
-   disruption was a spurious event, attempting to restart the connection
-   would be proper.  If the disruption was caused by a failure that
-   proved to be persistent, the AXFR client would be wise not to spend
-   too many resources trying to rebuild the connection.  Finally, if the
-   connection was dropped because of a policy at the AXFR server (as can
-   be the case with older AXFR servers), the AXFR client would be wise
-   not to retry the connection.  Unfortunately, knowing which of the
-   three cases above (momentary disruption, failure, policy) applies is
-   not possible with certainty, and can only be assessed by heuristics.
-   This exemplifies the general complications for clients in connection-
-   oriented protocols not receiving meaningful error responses.
-
-   An AXFR client MAY use an already opened TCP connection to start an
-   AXFR session.  Using an existing open connection is RECOMMENDED over
-   opening a new connection.  (Non-AXFR session traffic can also use an
-   open connection.)  If in doing so the AXFR client realizes that the
-   responses cannot be properly differentiated (lack of matching query
-   IDs for example) or the connection is terminated for a remote reason,
-   then the AXFR client SHOULD NOT attempt to reuse an open connection
-   with the specific AXFR server until the AXFR server is updated (which
-   is, of course, not an event captured in the DNS protocol).
-
-4.1.2.  AXFR server TCP
-
-   An AXFR server MUST be able to handle multiple AXFR sessions on a
-   single TCP connection, as well as to handle other query/response
-   transactions over it.
-
-   If a TCP connection is closed remotely, the AXFR server MUST cancel
-   all AXFR sessions in place.  No retry activity is necessary; that is
-   initiated by the AXFR client.
-
-   Local policy MAY dictate that a TCP connection is to be closed.  Such
-   an action SHOULD be in reaction to limits such as those placed on the
-   number of outstanding open connections.  Closing a connection in
-   response to a suspected security event SHOULD be done only in extreme
-   cases, when the server is certain the action is warranted.  An
-   isolated request for a zone not on the AXFR server SHOULD receive a
-   response with the appropriate response code and not see the
-   connection broken.
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 21]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-4.2.  UDP
-
-   With the addition of EDNS0 and applications which require many small
-   zones such as in web hosting and some ENUM scenarios, AXFR sessions
-   on UDP would now seem desirable.  However, there are still some
-   aspects of AXFR sessions that are not easily translated to UDP.
-
-   Therefore, this document does not update RFC 1035 in this respect:
-   AXFR sessions over UDP transport are not defined.
-
-
-5.  Authorization
-
-   A zone administrator has the option to restrict AXFR access to a
-   zone.  This was not envisioned in the original design of the DNS but
-   has emerged as a requirement as the DNS has evolved.  Restrictions on
-   AXFR could be for various reasons including a desire (or in some
-   instances, having a legal requirement) to keep the bulk version of
-   the zone concealed or to prevent the servers from handling the load
-   incurred in serving AXFR.  It has been argued that these reasons are
-   questionable, but this document, driven by the desire to leverage the
-   interoperable practice that has evolved since RFC 1035, acknowledges
-   the factual requirement to provide mechanisms to restrict AXFR.
-
-   A DNS implementation SHOULD provide means to restrict AXFR sessions
-   to specific clients.
-
-   An implementation SHOULD allow access to be granted to Internet
-   Protocol addresses and ranges, regardless of whether a source address
-   could be spoofed.  Combining this with techniques such as Virtual
-   Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be
-   effective.
-
-   A general purpose implementation is RECOMMENDED to implement access
-   controls based upon "Secret Key Transaction Authentication for DNS"
-   [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )"
-   [RFC2931].
-
-   A general purpose implementation SHOULD allow access to be open to
-   all AXFR requests.  I.e., an operator ought to be able to allow any
-   AXFR query to be granted.
-
-   A general purpose implementation SHOULD NOT have a default policy for
-   AXFR requests to be "open to all".  For example, a default could be
-   to restrict transfers to addresses selected by the DNS
-   administrator(s) for zones on the server.
-
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 22]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-6.  Zone Integrity
-
-   An AXFR client MUST ensure that only a successfully transferred copy
-   of the zone data can be used to serve this zone.  Previous
-   description and implementation practice have introduced a two-stage
-   model of the whole zone synchronization procedure:  Upon a trigger
-   event (e.g., polling of a SOA resource record detects change in the
-   SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session is
-   initiated, whereby the zone data are saved in a zone file or data
-   base (this latter step is necessary anyway to ensure proper restart
-   of the server); upon successful completion of the AXFR operation and
-   some sanity checks, this data set is 'loaded' and made available for
-   serving the zone in an atomic operation, and flagged 'valid' for use
-   during the next restart of the DNS server; if any error is detected,
-   this data set MUST be deleted, and the AXFR client MUST continue to
-   serve the previous version of the zone, if it did before.  The
-   externally visible behavior of an AXFR client implementation MUST be
-   equivalent to that of this two-stage model.
-
-   If an AXFR client rejects data contained in an AXFR session, it
-   SHOULD remember the serial number and MAY attempt to retrieve the
-   same zone version again.  The reason the same retrieval could make
-   sense is that the reason for the rejection could be rooted in an
-   implementation detail of one AXFR server used for the zone and not
-   present in another AXFR server used for the zone.
-
-   Ensuring that an AXFR client does not accept a forged copy of a zone
-   is important to the security of a zone.  If a zone operator has the
-   opportunity, protection can be afforded via dedicated links, physical
-   or virtual via a VPN among the authoritative servers.  But there are
-   instances in which zone operators have no choice but to run AXFR
-   sessions over the global public Internet.
-
-   Besides best attempts at securing TCP connections, DNS
-   implementations SHOULD provide means to make use of "Secret Key
-   Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and
-   Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients
-   to verify the contents.  These techniques MAY also be used for
-   authorization.
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 23]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-7.  Backwards Compatibility
-
-   Describing backwards compatibility is difficult because of the lack
-   of specifics in the original definition.  In this section some hints
-   at building in backwards compatibility are given, mostly repeated
-   from the relevant earlier sections.
-
-   Backwards compatibility is not necessary, but the greater the extent
-   of an implementation's compatibility the greater its
-   interoperability.  For turnkey implementations this is not usually a
-   concern.  For general purpose implementations this takes on varying
-   levels of importance depending on the implementer's desire to
-   maintain interoperability.
-
-   It is unfortunate that a need to fall back to older behavior cannot
-   be discovered, hence needs to be noted in a configuration file.  An
-   implementation SHOULD, in its documentation, encourage operators to
-   periodically review AXFR clients and servers it has made notes about
-   repeatedly, as old software gets updated from time to time.
-
-7.1.  Server
-
-   An AXFR server has the luxury of being able to react to an AXFR
-   client's abilities with the exception of knowing whether the client
-   can accept multiple resource records per AXFR response message.  The
-   knowledge that a client is so restricted cannot be discovered, hence
-   it has to be set by configuration.
-
-   An implementation of an AXFR server MAY permit configuring, on a per
-   AXFR client basis, the necessity to revert to single resource record
-   per message; in that case, the default SHOULD be to use multiple
-   records per message.
-
-7.2.  Client
-
-   An AXFR client has the opportunity to try other features (i.e., those
-   not defined by this document) when querying an AXFR server.
-
-   Attempting to issue multiple DNS queries over a TCP transport for an
-   AXFR session SHOULD be aborted if it interrupts the original request,
-   and SHOULD take into consideration whether the AXFR server intends to
-   close the connection immediately upon completion of the original
-   (connection-causing) zone transfer.
-
-
-
-
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 24]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-8.  Security Considerations
-
-   This document is a clarification of a mechanism outlined in RFCs 1034
-   and 1035 and as such does not add any new security considerations.
-   RFC 3833 [RFC3833] is devoted entirely to security considerations for
-   the DNS; its Section 4.3 delineates zone transfer security aspects
-   from the security threats addressed by DNSSEC.
-
-   Concerns regarding authorization, traffic flooding, and message
-   integrity are mentioned in "Authorization" (Section 5), "TCP"
-   (Section 4.2) and "Zone Integrity" (Section 6).
-
-
-9.  IANA Considerations
-
-   IANA has added a reference to this RFC in the AXFR (252) row of the
-   "Resource Record (RR) TYPEs" subregistry of the "Domain Name System
-   (DNS) Parameters" registry.
-
-
-10.  Internationalization Considerations
-
-   The AXFR protocol is transparent to the parts of DNS zone content
-   that can possibly be subject to Internationalization considerations.
-   It is assumed that for DNS labels and domain names, the issue has
-   been solved via "Internationalizing Domain Names in Applications
-   (IDNA)" [RFC3490] or its successor(s).
-
-
-11.  Acknowledgments
-
-   Earlier editions of this document have been edited by Andreas
-   Gustafsson.  In his latest version, this acknowledgment appeared:
-
-    "Many people have contributed input and commentary to earlier
-     versions of this document, including but not limited to Bob Halley,
-     Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert
-     Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
-     Trenholme, and Brian Wellington."
-
-   Comments since the -05 version have come from these individuals:
-   Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch,
-   Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly,
-   Bill Manning, and other participants of the DNSEXT working group.
-
-   Edward Lewis served as a patiently listening sole document editor for
-   two years.
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 25]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-12.  References
-
-   All "RFC" references by can be obtained from the RFC Editor web site
-   at the URLs:       http://rfc-editor.org/rfc.html
-   or                 http://rfc-editor.org/rfcsearch.html ;
-   information regarding this organization can be found at the following
-   URL:               http://rfc-editor.org/
-
-12.1.  Normative References
-
-   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
-              RFC 793, September 1981.
-
-   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
-              August 1980.
-
-   [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.
-
-   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-              August 1996.
-
-   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
-              Changes (DNS NOTIFY)", RFC 1996, August 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.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
-              RFC 2672, August 1999.
-
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 26]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-   [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.
-
-   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
-              ( SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC3425]  Lawrence, D., "Obsoleting IQUERY", RFC 3425,
-              November 2002.
-
-   [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.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
-              (DS) Resource Records (RRs)", RFC 4509, May 2006
-
-   [RFC4635]  Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication
-              Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
-              RFC 4635, August 2006.
-
-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-              Security (DNSSEC) Hashed Authenticated Denial of
-              Existence", RFC 5155, March 2008
-
-   [RFC5395]  Eastlake 3rd, "Domain Name System (DNS) IANA
-              Considerations", BCP 42, RFC 5395, November 2008.
-
-   [RFC5702]  Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
-              and RRSIG Resource Records for DNSSEC", RFC 5702,
-              October 2009.
-
-
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 27]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
-
-
-12.2.  Informative References
-
-   [DNSVALS]  IANA Registry "Domain Name System (DNS) Parameters",
-              http://www.iana.org/assignments/dns-parameters
-
-   [IANA-AF]  IANA Registry "Address Family Numbers",
-              http://www.iana.org/assignments/Address-family-numbers/ .
-
-   [RFC2764]  Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
-              Malis, "A Framework for IP Based Virtual Private
-              Networks", RFC 2764, February 2000.
-
-   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
-              "Internationalizing Domain Names in Applications (IDNA)",
-              RFC 3490, March 2003.
-
-   [RFC3833]  Atkins, D., and R. Austein, "Threat Analysis of the Domain
-              Name System (DNS)", RFC 3833, August 2004.
-
-   [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and
-              Implementation Notes for DNSSECbis",
-              draft-ietf-dnsext-dnssec-bis-updates-10 (work in
-              progress), March 2010.
-
-
-Authors' Addresses
-
-   Edward Lewis
-   46000 Center Oak Plaza
-   Sterling, VA, 22033, US
-
-   Email: ed.lewis@neustar.biz
-
-
-   Alfred Hoenes, Editor
-   TR-Sys
-   Gerlinger Str. 12
-   Ditzingen  D-71254
-   Germany
-
-   Email: ah@TR-Sys.de
-
-
-Editorial Note: Discussion  [[ to be removed by RFC-Editor ]]
-
-   Comments on this draft ought to be addressed to the editors and/or to
-   namedroppers@ops.ietf.org.
-
-
-
-
-Lewis & Hoenes         Expires September 26, 2010              [Page 28]
-
diff --git a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt b/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt
deleted file mode 100644
index a6d80baa..00000000
--- a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-
-DNSEXT                                                         R. Bellis
-Internet-Draft                                                Nominet UK
-Updates: 1035, 1123                                       March 22, 2010
-(if approved)
-Intended status: Standards Track
-Expires: September 23, 2010
-
-
-          DNS Transport over TCP - Implementation Requirements
-               draft-ietf-dnsext-dns-tcp-requirements-03
-
-Abstract
-
-   This document updates the requirements for the support of TCP as a
-   transport protocol for DNS implementations.
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 23, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-
-
-
-Bellis                 Expires September 23, 2010               [Page 1]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-
-   2.  Terminology used in this document . . . . . . . . . . . . . . . 3
-
-   3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-
-   4.  Transport Protocol Selection  . . . . . . . . . . . . . . . . . 4
-
-   5.  Connection Handling . . . . . . . . . . . . . . . . . . . . . . 5
-
-   6.  Response re-ordering  . . . . . . . . . . . . . . . . . . . . . 6
-
-   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-
-   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
-
-   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
-
-   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 7
-     10.2.  Informative References . . . . . . . . . . . . . . . . . . 7
-
-   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . . . 8
-
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bellis                 Expires September 23, 2010               [Page 2]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-1.  Introduction
-
-   Most DNS [RFC1035] transactions take place over UDP [RFC0768].  TCP
-   [RFC0793] is always used for zone transfers and is often used for
-   messages whose sizes exceed the DNS protocol's original 512 byte
-   limit.
-
-   Section 6.1.3.2 of [RFC1123] states:
-
-      DNS resolvers and recursive servers MUST support UDP, and SHOULD
-      support TCP, for sending (non-zone-transfer) queries.
-
-   However, some implementors have taken the text quoted above to mean
-   that TCP support is an optional feature of the DNS protocol.
-
-   The majority of DNS server operators already support TCP and the
-   default configuration for most software implementations is to support
-   TCP.  The primary audience for this document is those implementors
-   whose failure to support TCP restricts interoperability and limits
-   deployment of new DNS features.
-
-   This document therefore updates the core DNS protocol specifications
-   such that support for TCP is henceforth a REQUIRED part of a full DNS
-   protocol implementation.
-
-   Whilst this document makes no specific recommendations to operators
-   of DNS servers, it should be noted that failure to support TCP (or
-   blocking of DNS over TCP at the network layer) may result in
-   resolution failure and/or application-level timeouts.
-
-
-2.  Terminology 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].
-
-
-3.  Discussion
-
-   In the absence of EDNS0 (see below) the normal behaviour of any DNS
-   server needing to send a UDP response that would exceed the 512 byte
-   limit is for the server to truncate the response so that it fits
-   within that limit and then set the TC flag in the response header.
-   When the client receives such a response it takes the TC flag as an
-   indication that it should retry over TCP instead.
-
-   RFC 1123 also says:
-
-
-
-Bellis                 Expires September 23, 2010               [Page 3]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-
-      ... 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.
-
-   Existing deployments of DNSSEC [RFC4033] have shown that truncation
-   at the 512 byte boundary is now commonplace.  For example an NXDOMAIN
-   (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155]
-   is almost invariably larger than 512 bytes.
-
-   Since the original core specifications for DNS were written, the
-   Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced.
-   These extensions can be used to indicate that the client is prepared
-   to receive UDP responses larger than 512 bytes.  An EDNS0 compatible
-   server receiving a request from an EDNS0 compatible client may send
-   UDP packets up to that client's announced buffer size without
-   truncation.
-
-   However, transport of UDP packets that exceed the size of the path
-   MTU causes IP packet fragmentation, which has been found to be
-   unreliable in some circumstances.  Many firewalls routinely block
-   fragmented IP packets, and some do not implement the algorithms
-   necessary to reassemble fragmented packets.  Worse still, some
-   network devices deliberately refuse to handle DNS packets containing
-   EDNS0 options.  Other issues relating to UDP transport and packet
-   size are discussed in [RFC5625].
-
-   The MTU most commonly found in the core of the Internet is around
-   1500 bytes, and even that limit is routinely exceeded by DNSSEC
-   signed responses.
-
-   The future that was anticipated in RFC 1123 has arrived, and the only
-   standardised UDP-based mechanism which may have resolved the packet
-   size issue has been found inadequate.
-
-
-4.  Transport Protocol Selection
-
-   All general purpose DNS implementations MUST support both UDP and TCP
-   transport.
-
-   o  Authoritative server implementations MUST support TCP so that they
-      do not limit the size of responses.
-
-
-
-
-
-Bellis                 Expires September 23, 2010               [Page 4]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-   o  Recursive resolver (or forwarder) implementations MUST support TCP
-      so that the do not prevent large responses from a TCP-capable
-      server from reaching its TCP-capable clients.
-   o  Stub resolver implementations (e.g. an operating system's DNS
-      resolution library) MUST support TCP since to do otherwise would
-      limit their interoperability with their own clients and with
-      upstream servers.
-
-   An exception may be made for proprietary stub resolver
-   implementations.  These MAY omit support for TCP if operating in an
-   environment where truncation can never occur, or where DNS lookup
-   failure is acceptable should truncation occur.
-
-   Regarding the choice of when to use UDP or TCP, RFC 1123 says:
-
-      ... a DNS resolver or server that is sending a non-zone-transfer
-      query MUST send a UDP query first.
-
-   That requirement is hereby relaxed.  A resolver SHOULD send a UDP
-   query first, but MAY elect to send a TCP query instead if it has good
-   reason to expect the response would be truncated if it were sent over
-   UDP (with or without EDNS0) or for other operational reasons, in
-   particular if it already has an open TCP connection to the server.
-
-
-5.  Connection Handling
-
-   Section 4.2.2 of [RFC1035] says:
-
-      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.
-
-   Other more modern protocols (e.g.  HTTP [RFC2616]) have support for
-   persistent TCP connections and operational experience has shown that
-   long timeouts can easily cause resource exhaustion and poor response
-   under heavy load.  Intentionally opening many connections and leaving
-   them dormant can trivially create a "denial of service" attack.
-
-   This document therefore RECOMMENDS that the default application-level
-   idle period should be of the order of seconds, but does not specify
-   any particular value.  In practise the idle period may vary
-   dynamically, and servers MAY allow dormant connections to remain open
-   for longer periods as resources permit.
-
-
-
-Bellis                 Expires September 23, 2010               [Page 5]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-   To mitigate the risk of unintentional server overload, DNS clients
-   MUST take care to minimize the number of concurrent TCP connections
-   made to any individual server.  Similarly servers MAY impose limits
-   on the number of concurrent TCP connections being handled for any
-   particular client.
-
-   Further recommendations for the tuning of TCP stacks to allow higher
-   throughput or improved resiliency against denial of service attacks
-   are outside the scope of this document.
-
-
-6.  Response re-ordering
-
-   RFC 1035 is ambiguous on the question of whether TCP queries may be
-   re-ordered - the only relevant text is in Section 4.2.1 which relates
-   to UDP:
-
-      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.
-
-   For the avoidance of future doubt, this requirement is clarified.
-   Client resolvers MUST be able to process responses which arrive in a
-   different order to that in which the requests were sent, regardless
-   of the transport protocol in use.
-
-
-7.  Security Considerations
-
-   Some DNS server operators have expressed concern that wider use of
-   DNS over TCP will expose them to a higher risk of denial of service
-   (DoS) attacks.
-
-   Although there is a higher risk of such attacks against TCP-enabled
-   servers, techniques for the mitigation of DoS attacks at the network
-   level have improved substantially since DNS was first designed.
-
-   At the time of writing the vast majority of TLD authority servers and
-   all of the root name servers support TCP and the author knows of no
-   evidence to suggest that TCP-based DoS attacks against existing DNS
-   infrastructure are commonplace.
-
-   That notwithstanding, readers are advised to familiarise themselves
-   with [CPNI-TCP].
-
-   Operators of recursive servers should ensure that they only accept
-   connections from expected clients, and do not accept them from
-   unknown sources.  In the case of UDP traffic this will help protect
-
-
-
-Bellis                 Expires September 23, 2010               [Page 6]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-   against reflector attacks [RFC5358] and in the case of TCP traffic it
-   will prevent an unknown client from exhausting the server's limits on
-   the number of concurrent connections.
-
-
-8.  IANA Considerations
-
-   This document requests no IANA actions.
-
-
-9.  Acknowledgements
-
-   The author would like to thank the document reviewers from the DNSEXT
-   Working Group, and in particular George Barwood, Alex Bligh, Alfred
-   Hoenes, Fernando Gont, Jim Reid, Paul Vixie and Nicholas Weaver.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
-              August 1980.
-
-   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
-              RFC 793, September 1981.
-
-   [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.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-10.2.  Informative References
-
-   [CPNI-TCP]
-              CPNI, "Security Assessment of the Transmission Control
-              Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/
-              tn-03-09-security-assessment-TCP.pdf>.
-
-   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
-              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
-
-
-
-Bellis                 Expires September 23, 2010               [Page 7]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-              Security (DNSSEC) Hashed Authenticated Denial of
-              Existence", RFC 5155, March 2008.
-
-   [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive
-              Nameservers in Reflector Attacks", BCP 140, RFC 5358,
-              October 2008.
-
-   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
-              BCP 152, RFC 5625, August 2009.
-
-
-Appendix A.  Change Log
-
-   NB: to be removed by the RFC Editor before publication.
-
-   draft-ietf-dnsext-dns-tcp-requirements-03
-      Editorial nits from WGLC
-      Clarification on "general purpose"
-      Fixed ref to UDP (RFC 768)
-      Included more S.4.2.2 text from RFC 1035 and removed some from
-      this draft relating to connection resets.
-      s/long/large/ for packet sizes
-
-   draft-ietf-dnsext-dns-tcp-requirements-02
-      Change of title - more focus on implementation and not operation
-      Re-write of some of the security section
-      Added recommendation for minimal concurrent connections
-      Minor editorial nits from Alfred Hoenes
-
-   draft-ietf-dnsext-dns-tcp-requirements-01
-      Addition of response ordering section
-      Various minor editorial changes from WG reviewers
-
-   draft-ietf-dnsext-dns-tcp-requirements-00
-      Initial draft
-
-
-
-
-
-
-
-
-
-Bellis                 Expires September 23, 2010               [Page 8]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-Author's Address
-
-   Ray Bellis
-   Nominet UK
-   Edmund Halley Road
-   Oxford  OX4 4DQ
-   United Kingdom
-
-   Phone: +44 1865 332211
-   Email: ray.bellis@nominet.org.uk
-   URI:   http://www.nominet.org.uk/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bellis                 Expires September 23, 2010               [Page 9]
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt
deleted file mode 100644
index 7228ad1b..00000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt
+++ /dev/null
@@ -1,785 +0,0 @@
-
-
-
-Network Working Group                                          S. Weiler
-Internet-Draft                                              SPARTA, Inc.
-Updates: 4033, 4034, 4035, 5155                                D. Blacka
-(if approved)                                             VeriSign, Inc.
-Intended status: Standards Track                       November 10, 2010
-Expires: May 14, 2011
-
-
-         Clarifications and Implementation Notes for DNSSECbis
-                draft-ietf-dnsext-dnssec-bis-updates-12
-
-Abstract
-
-   This document is a collection of technical clarifications to the
-   DNSSECbis document set.  It is meant to serve as a resource to
-   implementors as well as a repository of DNSSECbis errata.
-
-Status of this Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at http://datatracker.ietf.org/drafts/current/.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   This Internet-Draft will expire on May 14, 2011.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 1]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-Table of Contents
-
-   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  3
-     1.1.  Structure of this Document . . . . . . . . . . . . . . . .  3
-     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Important Additions to DNSSSECbis  . . . . . . . . . . . . . .  3
-     2.1.  NSEC3 Support  . . . . . . . . . . . . . . . . . . . . . .  3
-     2.2.  SHA-2 Support  . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  Implement a BAD cache  . . . . . . . . . . . . . . . . . .  4
-   4.  Security Concerns  . . . . . . . . . . . . . . . . . . . . . .  4
-     4.1.  Clarifications on Non-Existence Proofs . . . . . . . . . .  4
-     4.2.  Validating Responses to an ANY Query . . . . . . . . . . .  5
-     4.3.  Check for CNAME  . . . . . . . . . . . . . . . . . . . . .  5
-     4.4.  Insecure Delegation Proofs . . . . . . . . . . . . . . . .  5
-   5.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
-     5.1.  Errors in Canonical Form Type Code List  . . . . . . . . .  6
-     5.2.  Unknown DS Message Digest Algorithms . . . . . . . . . . .  6
-     5.3.  Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
-     5.4.  Caution About Local Policy and Multiple RRSIGs . . . . . .  7
-     5.5.  Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
-     5.6.  Setting the DO Bit on Replies  . . . . . . . . . . . . . .  8
-     5.7.  Setting the AD Bit on Queries  . . . . . . . . . . . . . .  8
-     5.8.  Setting the AD Bit on Replies  . . . . . . . . . . . . . .  8
-     5.9.  Handling Queries With the CD Bit Set . . . . . . . . . . .  8
-     5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . .  9
-       5.10.1.  Closest Encloser  . . . . . . . . . . . . . . . . . .  9
-       5.10.2.  Accept Any Success  . . . . . . . . . . . . . . . . .  9
-       5.10.3.  Preference Based on Source  . . . . . . . . . . . . . 10
-   6.  Minor Corrections and Clarifications . . . . . . . . . . . . . 10
-     6.1.  Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . . 10
-     6.2.  Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 11
-     6.3.  Errors in Examples . . . . . . . . . . . . . . . . . . . . 11
-     6.4.  Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
-     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
-   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 13
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 2]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-1.  Introduction and Terminology
-
-   This document lists some additions, clarifications and corrections to
-   the core DNSSECbis specification, as originally described in
-   [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
-   (See section Section 2 for more recent additions to that core
-   document set.)
-
-   It is intended to serve as a resource for implementors and as a
-   repository of items that need to be addressed when advancing the
-   DNSSECbis documents from Proposed Standard to Draft Standard.
-
-1.1.  Structure of this Document
-
-   The clarifications to DNSSECbis are sorted according to their
-   importance, starting with ones which could, if ignored, lead to
-   security problems and progressing down to clarifications that are
-   expected to have little operational impact.
-
-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].
-
-
-2.  Important Additions to DNSSSECbis
-
-   This section lists some documents that should be considered core
-   DNSSEC protocol documents in addition to those originally specified
-   in Section 10 of [RFC4033].
-
-2.1.  NSEC3 Support
-
-   [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
-   records for hashed denial of existence.  Validator implementations
-   are strongly encouraged to include support for NSEC3 because a number
-   of highly visible zones are expected to use it.  Validators that do
-   not support validation of responses using NSEC3 will likely be
-   hampered in validating large portions of the DNS space.
-
-   [RFC5155] should be considered part of the DNS Security Document
-   Family as described by [RFC4033], Section 10.
-
-   Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3-
-   SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512)
-   signal that a zone MAY be using NSEC3, rather than NSEC.  The zone
-   MAY indeed be using either and validators supporting these algorithms
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 3]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   MUST support both NSEC3 and NSEC responses.
-
-2.2.  SHA-2 Support
-
-   [RFC4509] describes the use of SHA-256 as a digest algorithm in
-   Delegation Signer (DS) RRs.  [RFC5702] describes the use of the
-   RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs.
-   Validator implementations are strongly encouraged to include support
-   for these algorithms for DS, DNSKEY, and RRSIG records.
-
-   Both [RFC4509] and [RFC5702] should also be considered part of the
-   DNS Security Document Family as described by [RFC4033], Section 10.
-
-
-3.  Scaling Concerns
-
-3.1.  Implement a BAD cache
-
-   Section 4.7 of RFC4035 permits security-aware resolvers to implement
-   a BAD cache.  Because of scaling concerns not discussed in this
-   document, that guidance has changed: security-aware resolvers SHOULD
-   implement a BAD cache, as described in RFC4035.
-
-
-4.  Security Concerns
-
-   This section provides clarifications that, if overlooked, could lead
-   to security issues.
-
-4.1.  Clarifications on Non-Existence Proofs
-
-   [RFC4035] Section 5.4 under-specifies the algorithm for checking non-
-   existence proofs.  In particular, the algorithm as presented would
-   incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove
-   the non-existence of RRs in the child zone.
-
-   An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:
-
-   o  the NS bit set,
-   o  the SOA bit clear, and
-   o  a signer field that is shorter than the owner name of the NSEC RR,
-      or the original owner name for the NSEC3 RR.
-
-   Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non-
-   existence of any RRs below that zone cut, which include all RRs at
-   that (original) owner name other than DS RRs, and all RRs below that
-   owner name regardless of type.
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 4]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   Similarly, the algorithm would also allow an NSEC RR at the same
-   owner name as a DNAME RR, or an NSEC3 RR at the same original owner
-   name as a DNAME, to prove the non-existence of names beneath that
-   DNAME.  An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used
-   to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's
-   (original) owner name.
-
-4.2.  Validating Responses to an ANY Query
-
-   [RFC4035] does not address how to validate responses when QTYPE=*.
-   As described in Section 6.2.2 of [RFC1034], a proper response to
-   QTYPE=* may include a subset of the RRsets at a given name.  That is,
-   it is not necessary to include all RRsets at the QNAME in the
-   response.
-
-   When validating a response to QTYPE=*, all received RRsets that match
-   QNAME and QCLASS MUST be validated.  If any of those RRsets fail
-   validation, the answer is considered Bogus.  If there are no RRsets
-   matching QNAME and QCLASS, that fact MUST be validated according to
-   the rules in [RFC4035] Section 5.4 (as clarified in this document).
-   To be clear, a validator must not expect to receive all records at
-   the QNAME in response to QTYPE=*.
-
-4.3.  Check for CNAME
-
-   Section 5 of [RFC4035] says little about validating responses based
-   on (or that should be based on) CNAMEs.  When validating a NOERROR/
-   NODATA response, validators MUST check the CNAME bit in the matching
-   NSEC or NSEC3 RR's type bitmap in addition to the bit for the query
-   type.  Without this check, an attacker could successfully transform a
-   positive CNAME response into a NOERROR/NODATA response.
-
-4.4.  Insecure Delegation Proofs
-
-   [RFC4035] Section 5.2 specifies that a validator, when proving a
-   delegation is not secure, needs to check for the absence of the DS
-   and SOA bits in the NSEC (or NSEC3) type bitmap.  The validator also
-   needs to check for the presence of the NS bit in the matching NSEC
-   (or NSEC3) RR (proving that there is, indeed, a delegation), or
-   alternately make sure that the delegation is covered by an NSEC3 RR
-   with the Opt-Out flag set.  If this is not checked, spoofed unsigned
-   delegations might be used to claim that an existing signed record is
-   not signed.
-
-
-5.  Interoperability Concerns
-
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 5]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-5.1.  Errors in Canonical Form Type Code List
-
-   When canonicalizing DNS names, DNS names in the RDATA section of NSEC
-   and RRSIG resource records are not downcased.
-
-   [RFC4034] Section 6.2 item 3 has a list of resource record types for
-   which DNS names in the RDATA are downcased for purposes of DNSSEC
-   canonical form (for both ordering and signing).  That list
-   erroneously contains NSEC and RRSIG.  According to [RFC3755], DNS
-   names in the RDATA of NSEC and RRSIG should not be downcased.
-
-   The same section also erroneously lists HINFO, and twice at that.
-   Since HINFO records contain no domain names, they are not subject to
-   downcasing.
-
-5.2.  Unknown DS Message Digest Algorithms
-
-   Section 5.2 of [RFC4035] includes rules for how to handle delegations
-   to zones that are signed with entirely unsupported public key
-   algorithms, as indicated by the key algorithms shown in those zone's
-   DS RRsets.  It does not explicitly address how to handle DS records
-   that use unsupported message digest algorithms.  In brief, DS records
-   using unknown or unsupported message digest algorithms MUST be
-   treated the same way as DS records referring to DNSKEY RRs of unknown
-   or unsupported public key algorithms.
-
-   The existing text says:
-
-      If the validator does not support any of the algorithms listed in
-      an authenticated DS RRset, then the resolver has no supported
-      authentication path leading from the parent to the child.  The
-      resolver should treat this case as it would the case of an
-      authenticated NSEC RRset proving that no DS RRset exists, as
-      described above.
-
-   To paraphrase the above, when determining the security status of a
-   zone, a validator disregards any DS records listing unknown or
-   unsupported algorithms.  If none are left, the zone is treated as if
-   it were unsigned.
-
-   Modified to consider DS message digest algorithms, a validator also
-   disregards any DS records using unknown or unsupported message digest
-   algorithms.
-
-5.3.  Private Algorithms
-
-   As discussed above, section 5.2 of [RFC4035] requires that validators
-   make decisions about the security status of zones based on the public
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 6]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   key algorithms shown in the DS records for those zones.  In the case
-   of private algorithms, as described in [RFC4034] Appendix A.1.1, the
-   eight-bit algorithm field in the DS RR is not conclusive about what
-   algorithm(s) is actually in use.
-
-   If no private algorithms appear in the DS set or if any supported
-   algorithm appears in the DS set, no special processing will be
-   needed.  In the remaining cases, the security status of the zone
-   depends on whether or not the resolver supports any of the private
-   algorithms in use (provided that these DS records use supported hash
-   functions, as discussed in Section 5.2).  In these cases, the
-   resolver MUST retrieve the corresponding DNSKEY for each private
-   algorithm DS record and examine the public key field to determine the
-   algorithm in use.  The security-aware resolver MUST ensure that the
-   hash of the DNSKEY RR's owner name and RDATA matches the digest in
-   the DS RR.  If they do not match, and no other DS establishes that
-   the zone is secure, the referral should be considered Bogus data, as
-   discussed in [RFC4035].
-
-   This clarification facilitates the broader use of private algorithms,
-   as suggested by [RFC4955].
-
-5.4.  Caution About Local Policy and Multiple RRSIGs
-
-   When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3
-   suggests that "the local resolver security policy determines whether
-   the resolver also has to test these RRSIG RRs and how to resolve
-   conflicts if these RRSIG RRs lead to differing results."  In most
-   cases, a resolver would be well advised to accept any valid RRSIG as
-   sufficient.  If the first RRSIG tested fails validation, a resolver
-   would be well advised to try others, giving a successful validation
-   result if any can be validated and giving a failure only if all
-   RRSIGs fail validation.
-
-   If a resolver adopts a more restrictive policy, there's a danger that
-   properly-signed data might unnecessarily fail validation, perhaps
-   because of cache timing issues.  Furthermore, certain zone management
-   techniques, like the Double Signature Zone-signing Key Rollover
-   method described in section 4.2.1.2 of [RFC4641] might not work
-   reliably.
-
-5.5.  Key Tag Calculation
-
-   [RFC4034] Appendix B.1 incorrectly defines the Key Tag field
-   calculation for algorithm 1.  It correctly says that the Key Tag is
-   the most significant 16 of the least significant 24 bits of the
-   public key modulus.  However, [RFC4034] then goes on to incorrectly
-   say that this is 4th to last and 3rd to last octets of the public key
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 7]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   modulus.  It is, in fact, the 3rd to last and 2nd to last octets.
-
-5.6.  Setting the DO Bit on Replies
-
-   As stated in [RFC3225], the DO bit of the query MUST be copied in the
-   response.  At least one implementation has done something different,
-   so it may be wise for resolvers to be liberal in what they accept.
-
-5.7.  Setting the AD Bit on Queries
-
-   The use of the AD bit in the query was previously undefined.  This
-   document defines it as a signal indicating that the requester
-   understands and is interested in the value of the AD bit in the
-   response.  This allows a requestor to indicate that it understands
-   the AD bit without also requesting DNSSEC data via the DO bit.
-
-5.8.  Setting the AD Bit on Replies
-
-   Section 3.2.3 of [RFC4035] describes under which conditions a
-   validating resolver should set or clear the AD bit in a response.  In
-   order to protect legacy stub resolvers and middleboxes, validating
-   resolvers SHOULD only set the AD bit when a response both meets the
-   conditions listed in RFC 4035, section 3.2.3, and the request
-   contained either a set DO bit or a set AD bit.
-
-5.9.  Handling Queries With the CD Bit Set
-
-   When processing a request with the CD bit set, a resolver SHOULD
-   attempt to return all responsive data, even data that has failed
-   DNSSEC validation.  RFC4035 section 3.2.2 requires a resolver
-   processing a request with the CD bit set to set the CD bit on its
-   upstream queries.
-
-   The guidance in RFC4035 is ambiguous about what to do when a cached
-   response was obtained with the CD bit not set.  In the typical case,
-   no new query is required, nor does the cache need to track the state
-   of the CD bit used to make a given query.  The problem arises when
-   the cached response is a server failure (RCODE 2), which may indicate
-   that the requested data failed DNSSEC validation at an upstream
-   validating resolver.  (RFC2308 permits caching of server failures for
-   up to five minutes.)  In these cases, a new query with the CD bit set
-   is required.
-
-   For efficiency, a validator SHOULD set the CD bit on upstream queries
-   when it has a trust anchor at or above the QNAME (and thus can
-   reasonably expect to be able to validate the response).
-
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 8]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-5.10.  Nested Trust Anchors
-
-   A DNSSEC validator may be configured such that, for a given response,
-   more than one trust anchor could be used to validate the chain of
-   trust to the response zone.  For example, imagine a validator
-   configured with trust anchors for "example." and "zone.example."
-   When the validator is asked to validate a response to
-   "www.sub.zone.example.", either trust anchor could apply.
-
-   When presented with this situation, DNSSEC validators have a choice
-   of which trust anchor(s) to use.  Which to use is a matter of
-   implementation choice.  It is possible and perhaps advisable to
-   expose the choice of policy as a configuration option.  The rest of
-   this section discusses some possible policies.  As a default, we
-   suggest that validators implement the "Accept Any Success" policy
-   described below in Section 5.10.2 while exposing other policies as
-   configuration options.
-
-5.10.1.  Closest Encloser
-
-   One policy is to choose the trust anchor closest to the QNAME of the
-   response.  In our example, that would be the "zone.example." trust
-   anchor.
-
-   This policy has the advantage of allowing the operator to trivially
-   override a parent zone's trust anchor with one that the operator can
-   validate in a stronger way, perhaps because the resolver operator is
-   affiliated with the zone in question.  This policy also minimizes the
-   number of public key operations needed, which may be of benefit in
-   resource-constrained environments.
-
-   This policy has the disadvantage of possibly giving the user some
-   unexpected and unnecessary validation failures when sub-zone trust
-   anchors are neglected.  As a concrete example, consider a validator
-   that configured a trust anchor for "zone.example." in 2009 and one
-   for "example." in 2011.  In 2012, "zone.example." rolls its KSK and
-   updates its DS records, but the validator operator doesn't update its
-   trust anchor.  With the "closest encloser" policy, the validator gets
-   validation failures.
-
-5.10.2.  Accept Any Success
-
-   Another policy is to try all applicable trust anchors until one gives
-   a validation result of Secure, in which case the final validation
-   result is Secure.  If and only if all applicable trust anchors give a
-   result of Insecure, the final validation result is Insecure.  If one
-   or more trust anchors lead to a Bogus result and there is no Secure
-   result, then the final validation result is Bogus.
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 9]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   This has the advantage of causing the fewer validation failures,
-   which may deliver a better user experience.  If one trust anchor is
-   out of date (as in our above example), the user may still be able to
-   get a Secure validation result (and see DNS responses).
-
-   This policy has the disadvantage of making the validator subject to
-   compromise of the weakest of these trust anchors while making its
-   relatively painless to keep old trust anchors configured in
-   perpetuity.
-
-5.10.3.  Preference Based on Source
-
-   When the trust anchors have come from different sources (e.g.
-   automated updates ([RFC5011]), one or more DLV registries
-   ([RFC5074]), and manually configured), a validator may wish to choose
-   between them based on the perceived reliability of those sources.
-   The order of precedence might be exposed as a configuration option.
-
-   For example, a validator might choose to prefer trust anchors found
-   in a DLV registry over those manually configured on the theory that
-   the manually configured ones will not be as aggressively maintained.
-
-   Conversely, a validator might choose to prefer manually configured
-   trust anchors over those obtained from a DLV registry on the theory
-   that the manually configured ones have been more carefully
-   authenticated.
-
-   Or the validator might do something more complicated: prefer a sub-
-   set of manually configured trust anchors (based on a configuration
-   option), then trust anchors that have been updated using the RFC5011
-   mechanism, then trust anchors from one DLV registry, then trust
-   anchors from a different DLV registry, then the rest of the manually
-   configured trust anchors.
-
-
-6.  Minor Corrections and Clarifications
-
-6.1.  Finding Zone Cuts
-
-   Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
-   for a parent zone.  To do that, a resolver may first need to apply
-   special rules to discover what those servers are.
-
-   As explained in Section 3.1.4.1 of [RFC4035], security-aware name
-   servers need to apply special processing rules to handle the DS RR,
-   and in some situations the resolver may also need to apply special
-   rules to locate the name servers for the parent zone if the resolver
-   does not already have the parent's NS RRset.  Section 4.2 of
-
-
-
-Weiler & Blacka           Expires May 14, 2011                 [Page 10]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   [RFC4035] specifies a mechanism for doing that.
-
-6.2.  Clarifications on DNSKEY Usage
-
-   Questions of the form "can I use a different DNSKEY for signing this
-   RRset" have occasionally arisen.
-
-   The short answer is "yes, absolutely".  You can even use a different
-   DNSKEY for each RRset in a zone, subject only to practical limits on
-   the size of the DNSKEY RRset.  However, be aware that there is no way
-   to tell resolvers what a particularly DNSKEY is supposed to be used
-   for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
-   authenticate any RRset in the zone.  For example, if a weaker or less
-   trusted DNSKEY is being used to authenticate NSEC RRsets or all
-   dynamically updated records, that same DNSKEY can also be used to
-   sign any other RRsets from the zone.
-
-   Furthermore, note that the SEP bit setting has no effect on how a
-   DNSKEY may be used -- the validation process is specifically
-   prohibited from using that bit by [RFC4034] section 2.1.2.  It is
-   possible to use a DNSKEY without the SEP bit set as the sole secure
-   entry point to the zone, yet use a DNSKEY with the SEP bit set to
-   sign all RRsets in the zone (other than the DNSKEY RRset).  It's also
-   possible to use a single DNSKEY, with or without the SEP bit set, to
-   sign the entire zone, including the DNSKEY RRset itself.
-
-6.3.  Errors in Examples
-
-   The text in [RFC4035] Section C.1 refers to the examples in B.1 as
-   "x.w.example.com" while B.1 uses "x.w.example".  This is painfully
-   obvious in the second paragraph where it states that the RRSIG labels
-   field value of 3 indicates that the answer was not the result of
-   wildcard expansion.  This is true for "x.w.example" but not for
-   "x.w.example.com", which of course has a label count of 4
-   (antithetically, a label count of 3 would imply the answer was the
-   result of a wildcard expansion).
-
-   The first paragraph of [RFC4035] Section C.6 also has a minor error:
-   the reference to "a.z.w.w.example" should instead be "a.z.w.example",
-   as in the previous line.
-
-6.4.  Errors in RFC 5155
-
-   A NSEC3 record that matches an Empty Non-Terminal effectively has no
-   type associated with it.  This NSEC3 record has an empty type bit
-   map.  Section 3.2.1 of [RFC5155] contains the statement:
-
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                 [Page 11]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-      Blocks with no types present MUST NOT be included.
-
-   However, the same section contains a regular expression:
-
-      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
-
-   The plus sign in the regular expression indicates that there is one
-   or more of the preceding element.  This means that there must be at
-   least one window block.  If this window block has no types, it
-   contradicts with the first statement.  Therefore, the correct text in
-   RFC 5155 3.2.1 should be:
-
-      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
-
-
-7.  IANA Considerations
-
-   This document specifies no IANA Actions.
-
-
-8.  Security Considerations
-
-   This document adds two cryptographic features to the core DNSSEC
-   protocol.  Additionally, it addresses some ambiguities and omissions
-   in the core DNSSEC documents that, if not recognized and addressed in
-   implementations, could lead to security failures.  In particular, the
-   validation algorithm clarifications in Section 4 are critical for
-   preserving the security properties DNSSEC offers.  Furthermore,
-   failure to address some of the interoperability concerns in Section 5
-   could limit the ability to later change or expand DNSSEC, including
-   adding new algorithms.
-
-
-9.  References
-
-9.1.  Normative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
-              RFC 3225, December 2001.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-
-
-
-Weiler & Blacka           Expires May 14, 2011                 [Page 12]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
-              (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-              Security (DNSSEC) Hashed Authenticated Denial of
-              Existence", RFC 5155, March 2008.
-
-   [RFC5702]  Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
-              and RRSIG Resource Records for DNSSEC", RFC 5702,
-              October 2009.
-
-9.2.  Informative References
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer (DS)", RFC 3755, May 2004.
-
-   [RFC4641]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
-              RFC 4641, September 2006.
-
-   [RFC4955]  Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
-              July 2007.
-
-   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
-              Trust Anchors", RFC 5011, September 2007.
-
-   [RFC5074]  Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
-              November 2007.
-
-
-Appendix A.  Acknowledgments
-
-   The editors would like the thank Rob Austein for his previous work as
-   an editor of this document.
-
-   The editors are extremely grateful to those who, in addition to
-   finding errors and omissions in the DNSSECbis document set, have
-   provided text suitable for inclusion in this document.
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                 [Page 13]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   The lack of specificity about handling private algorithms, as
-   described in Section 5.3, and the lack of specificity in handling ANY
-   queries, as described in Section 4.2, were discovered by David
-   Blacka.
-
-   The error in algorithm 1 key tag calculation, as described in
-   Section 5.5, was found by Abhijit Hayatnagarkar.  Donald Eastlake
-   contributed text for Section 5.5.
-
-   The bug relating to delegation NSEC RR's in Section 4.1 was found by
-   Roy Badami.  Roy Arends found the related problem with DNAME.
-
-   The errors in the [RFC4035] examples were found by Roy Arends, who
-   also contributed text for Section 6.3 of this document.
-
-   The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
-   Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
-   and Scott Rose for their substantive comments on the text of this
-   document.
-
-
-Authors' Addresses
-
-   Samuel Weiler
-   SPARTA, Inc.
-   7110 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   Email: weiler@tislabs.com
-
-
-   David Blacka
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Email: davidb@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                 [Page 14]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt
deleted file mode 100644
index 5ef96c42..00000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt
+++ /dev/null
@@ -1,448 +0,0 @@
-
-
-
-DNS Extensions Working Group                                     S. Rose
-Internet-Draft                                                      NIST
-Updates: 2536, 2539, 3110, 4034,                         August 11, 2010
-4398, 5155, 5702, 5933
-(if approved)
-Intended status: Standards Track
-Expires: February 12, 2011
-
-
-  Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA
-                                Registry
-               draft-ietf-dnsext-dnssec-registry-fixes-06
-
-Abstract
-
-   The DNS Security Extensions (DNSSEC) requires the use of
-   cryptographic algorithm suites for generating digital signatures over
-   DNS data.  There is currently an IANA registry for these algorithms
-   that is incomplete in that it lacks the implementation status of each
-   algorithm.  This document provides an applicability statement on
-   algorithm status for DNSSEC implementations.  This document replaces
-   that registry table with a new IANA registry table for Domain Name
-   System Security (DNSSEC) Algorithm Numbers which lists each
-   algorithm's status based on the current reference.  If that status is
-   not defined in the original specification, this document assigns a
-   status.
-
-Status of This Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-
-
-Rose                    Expires February 12, 2011               [Page 1]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-   This Internet-Draft will expire on February 12, 2011.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
-
-   2.  The DNS Security Algorithm Number Subregistry . . . . . . . . . 3
-     2.1.  Individual Changes  . . . . . . . . . . . . . . . . . . . . 3
-     2.2.  Domain Name System (DNS) Security Algorithm Number
-           Registry Table  . . . . . . . . . . . . . . . . . . . . . . 5
-     2.3.  Specifying New Algorithms and Updating Status of
-           Existing Entries  . . . . . . . . . . . . . . . . . . . . . 6
-
-   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
-
-   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-
-   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     5.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     5.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose                    Expires February 12, 2011               [Page 2]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-1.  Introduction
-
-   The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033],
-   [RFC4034], and [RFC4035] uses digital signatures over DNS data to
-   provide source authentication and integrity protection.  DNSSEC uses
-   an IANA registry to allocate codes for digital signature algorithms
-   (consisting of a cryptographic algorithm and one-way hash function).
-
-   The original list of algorithm status is found in [RFC4034].  Other
-   DNSSEC documents have added new algorithms or changed the status of
-   algorithms in the registry.  However, currently implementors must
-   read through all the documents in order to discover the current
-   status of each algorithm in the registry.
-
-   This document replaces the current IANA registry for Domain Name
-   System Security (DNSSEC) Algorithm Numbers with a newly defined
-   registry table.  This new table (Section 2.2 below) contains a column
-   that will list the current status of each digital signature algorithm
-   in the registry at the time of writing and assigns status for some
-   algorithms used with DNSSEC that did not have an identified status in
-   their specification.  This document updates the following: [RFC2536],
-   [RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and
-   [RFC5933].
-
-1.1.  Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  The DNS Security Algorithm Number Subregistry
-
-   The DNS Security Algorithm Number subregistry (part of the Domain
-   Name System (DNS) Security Number registry) will be replaced with the
-   table below.  This table contains a column that contains the current
-   implementation requirements of the given algorithm.
-
-   There are additional differences to entries that are described in
-   sub-section 2.1.  The overall new registry table is in sub-section
-   2.2.  The values for the status were obtained from [RFC4034] with
-   updates for algorithms specified after the original DNSSEC
-   specification.  If no status was listed in the original
-   specification, this document assigns one.
-
-2.1.  Individual Changes
-
-   This document changes three entries in the Domain Name System
-   Security (DNSSEC) Algorithm Registry.  They are:
-
-
-
-Rose                    Expires February 12, 2011               [Page 3]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-   The description for assignment number 4 is changed to "Reserved until
-   2020".
-
-   The description for assignment number 9 is changed to "Reserved until
-   2020".
-
-   The description for assignment number 11 is changed to "Reserved
-   until 2020".
-
-   Registry entries 13-251 remains Unassigned.
-
-   The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are set to
-   RECOMMENDED and OPTIONAL respectively.  The difference is due to the
-   fact that RSA/SHA-1 is REQUIRED and DSA/SHA-1 is only OPTIONAL.  The
-   status of RSA/SHA-256 and RSA/SHA-512 are set to RECOMMENDED as it is
-   believed that these algorithms will replace older algorithms (e.g.
-   RSA/SHA-1) that have a perceived weakness in their hash algorithm
-   (SHA-1).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose                    Expires February 12, 2011               [Page 4]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-2.2.  Domain Name System (DNS) Security Algorithm Number Registry Table
-
-   The Domain Name System (DNS) Security Algorithm Number registry is
-   hereby specified as follows:
-
-                                  Zone  Transaction
-Number  Description    Mnemonic   Sign  Sign     Status       Reference
-------  -----------     ------    ----  -----  ------------   ---------
-  0      Reserved                                             [RFC4398]
-  1      RSA/MD5         RSAMD5     N     Y     MUST NOT      [RFC4034],
-                                                IMPLEMENT     [RFC3110]
-                                                             (this memo)
-  2      Diffie-Hellman   DH        N     Y                   [RFC2539]
-                                                             (this memo)
-  3      DSA/SHA-1       DSASHA1    Y     Y                   [RFC2536],
-                                                              [RFC4034],
-                                                             FIPS 186-3,
-                                                             FIPS 180-3
-                                                             (this memo)
-  4      Reserved until   ECC                                (this memo)
-         2020
-  5      RSA/SHA-1       RSASHA1    Y     Y     REQUIRED      [RFC4034]
-                                                             (this memo)
-  6      DSA-NSEC3-SHA1  DSA-NSEC3  Y     Y                   [RFC5155]
-                         -SHA1                               (this memo)
-  7      RSASHA1-NSEC3   RSASHA1-   Y     Y    RECOMMENDED    [RFC5155]
-         -SHA1           NSEC3-                              (this memo)
-                         SHA1
-  8      RSA/SHA-256     RSASHA256  Y     *    RECOMMENDED     [RFC5702]
-                                                             (this memo)
-  9      Reserved until                                      (this memo)
-         2020
- 10      RSA/SHA-512     RSASHA512  Y     *    RECOMMENDED    [RFC5702]
-                                                             (this memo)
- 11      Reserved until                                      (this memo)
-         2020
- 12      GOST R          GOST-ECC   Y     *                   [RFC5933]
-         34.10-2001                                          (this memo)
-13-251   Unassigned
- 252     Reserved for    INDIRECT   N     N                   [RFC4034]
-         Indirect keys                                       (this memo)
- 253     private         PRIVATE    Y     Y                   [RFC4034]
-         algorithm                                           (this memo)
- 254     private         PRIVATEOID Y     Y                   [RFC4034]
-         algorithm OID                                       (this memo)
- 255     Reserved
-
-
-
-
-
-Rose                    Expires February 12, 2011               [Page 5]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-2.3.  Specifying New Algorithms and Updating Status of Existing Entries
-
-   [I-D.ietf-dnsext-dnssec-alg-allocation] establishes a parallel
-   procedure for obtaining an algorithm number for new algorithms other
-   than a standards track document.  Algorithms entered into the
-   registry using that procedure do not have a listed status.
-   Specifications that follow this path do not need to obsolete or
-   update this document.
-
-   Adding a newly specified algorithm to the registry with a status
-   SHALL entail obsoleting this document and replacing the registry
-   table (with the new algorithm entry).  Altering the status column
-   value of any existing algorithm in the registry SHALL entail
-   obsoleting this document and replacing the registry table.
-
-   This document cannot be updated, only made obsolete and replaced by a
-   successor document.
-
-3.  IANA Considerations
-
-   This document replaces the Domain Name System (DNS) Security
-   Algorithm Numbers registry.  The new registry table is in Section
-   2.2.
-
-   The original Domain Name System (DNS) Security Algorithm Number
-   registry is available at http://www.iana.org/assignments/
-   dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml.
-
-4.  Security Considerations
-
-   This document replaces the Domain Name System (DNS) Security
-   Algorithm Numbers registry.  It is not meant to be a discussion on
-   algorithm superiority.  No new security considerations are raised in
-   this document.
-
-5.  References
-
-5.1.  Normative References
-
-   [I-D.ietf-dnsext-dnssec-alg-allocation]  Hoffman, P., "Cryptographic
-                                            Algorithm Identifier
-                                            Allocation for DNSSEC", draf
-                                            t-ietf-dnsext-dnssec-alg-
-                                            allocation-03 (work in
-                                            progress), March 2010.
-
-   [RFC2119]                                Bradner, S., "Key words for
-                                            use in RFCs to Indicate
-
-
-
-Rose                    Expires February 12, 2011               [Page 6]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-                                            Requirement Levels", BCP 14,
-                                            RFC 2119, March 1997.
-
-   [RFC2536]                                Eastlake, D., "DSA KEYs and
-                                            SIGs in the Domain Name
-                                            System (DNS)", RFC 2536,
-                                            March 1999.
-
-   [RFC2539]                                Eastlake, D., "Storage of
-                                            Diffie-Hellman Keys in the
-                                            Domain Name System (DNS)",
-                                            RFC 2539, March 1999.
-
-   [RFC3110]                                Eastlake, D., "RSA/SHA-1
-                                            SIGs and RSA KEYs in the
-                                            Domain Name System (DNS)",
-                                            RFC 3110, May 2001.
-
-   [RFC4033]                                Arends, R., Austein, R.,
-                                            Larson, M., Massey, D., and
-                                            S. Rose, "DNS Security
-                                            Introduction and
-                                            Requirements", RFC 4033,
-                                            March 2005.
-
-   [RFC4034]                                Arends, R., Austein, R.,
-                                            Larson, M., Massey, D., and
-                                            S. Rose, "Resource Records
-                                            for the DNS Security
-                                            Extensions", RFC 4034,
-                                            March 2005.
-
-   [RFC4035]                                Arends, R., Austein, R.,
-                                            Larson, M., Massey, D., and
-                                            S. Rose, "Protocol
-                                            Modifications for the DNS
-                                            Security Extensions",
-                                            RFC 4035, March 2005.
-
-   [RFC4398]                                Josefsson, S., "Storing
-                                            Certificates in the Domain
-                                            Name System (DNS)",
-                                            RFC 4398, March 2006.
-
-   [RFC5155]                                Laurie, B., Sisson, G.,
-                                            Arends, R., and D. Blacka,
-                                            "DNS Security (DNSSEC)
-                                            Hashed Authenticated Denial
-
-
-
-Rose                    Expires February 12, 2011               [Page 7]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-                                            of Existence", RFC 5155,
-                                            March 2008.
-
-   [RFC5702]                                Jansen, J., "Use of SHA-2
-                                            Algorithms with RSA in
-                                            DNSKEY and RRSIG Resource
-                                            Records for DNSSEC",
-                                            RFC 5702, October 2009.
-
-   [RFC5933]                                Dolmatov, V., Chuprina, A.,
-                                            and I. Ustinov, "Use of GOST
-                                            Signature Algorithms in
-                                            DNSKEY and RRSIG Resource
-                                            Records for DNSSEC",
-                                            RFC 5933, July 2010.
-
-5.2.  Informative References
-
-   [FIPS.180-3.2008]                        National Institute of
-                                            Standards and Technology,
-                                            "Secure Hash Standard",
-                                            FIPS PUB 180-3,
-                                            October 2008, <http://
-                                            csrc.nist.gov/publications/
-                                            fips/fips180-3/
-                                            fips180-3.pdf>.
-
-   [FIPS.186-3.2009]                        National Institute of
-                                            Standards and Technology,
-                                            "Digital Signature
-                                            Standard", FIPS PUB 186-3,
-                                            June 2009, <http://
-                                            csrc.nist.gov/publications/
-                                            fips/fips186-3/
-                                            fips_186-3.pdf>.
-
-Author's Address
-
-   Scott Rose
-   NIST
-   100 Bureau Dr.
-   Gaithersburg, MD  20899
-   USA
-
-   Phone: +1-301-975-8439
-   EMail: scottr.nist@gmail.com
-
-
-
-
-
-Rose                    Expires February 12, 2011               [Page 8]
-
diff --git a/doc/draft/draft-ietf-dnsext-ecc-key-07.txt b/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
deleted file mode 100644
index 2cdcdb16..00000000
--- a/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
+++ /dev/null
@@ -1,928 +0,0 @@
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-Expires: January 2006                                          July 2005
-
-
-
-                     Elliptic Curve KEYs in the DNS
-                     -------- ----- ---- -- --- ---
-                   <draft-ietf-dnsext-ecc-key-07.txt>
-
-                         Richard C. Schroeppel
-                          Donald Eastlake 3rd
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   This draft is intended to be become a Proposed Standard RFC.
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNS mailing list <namedroppers@ops.ietf.org>.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   The standard method for storing elliptic curve cryptographic keys and
-   signatures in the Domain Name System is specified.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005). All Rights Reserved.
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 1]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-Acknowledgement
-
-   The assistance of Hilarie K. Orman in the production of this document
-   is greatfully acknowledged.
-
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-      Copyright Notice...........................................1
-
-      Acknowledgement............................................2
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      2. Elliptic Curve Data in Resource Records.................3
-      3. The Elliptic Curve Equation.............................9
-      4. How do I Compute Q, G, and Y?..........................10
-      5. Elliptic Curve SIG Resource Records....................11
-      6. Performance Considerations.............................13
-      7. Security Considerations................................13
-      8. IANA Considerations....................................13
-      Copyright and Disclaimer..................................14
-
-      Informational References..................................15
-      Normative Refrences.......................................15
-
-      Author's Addresses........................................16
-      Expiration and File Name..................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 2]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information. The DNS has been extended to include digital
-   signatures and cryptographic keys as described in [RFC 4033, 4034,
-   4035].
-
-   This document describes how to store elliptic curve cryptographic
-   (ECC) keys and signatures in the DNS so they can be used for a
-   variety of security purposes.  Familiarity with ECC cryptography is
-   assumed [Menezes].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-
-
-2. Elliptic Curve Data in Resource Records
-
-   Elliptic curve public keys are stored in the DNS within the RDATA
-   portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the
-   structure shown below.
-
-   The research world continues to work on the issue of which is the
-   best elliptic curve system, which finite field to use, and how to
-   best represent elements in the field.  So, representations are
-   defined for every type of finite field, and every type of elliptic
-   curve.  The reader should be aware that there is a unique finite
-   field with a particular number of elements, but many possible
-   representations of that field and its elements.  If two different
-   representations of a field are given, they are interconvertible with
-   a tedious but practical precomputation, followed by a fast
-   computation for each field element to be converted.  It is perfectly
-   reasonable for an algorithm to work internally with one field
-   representation, and convert to and from a different external
-   representation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 3]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |S M -FMT- A B Z|
-       +-+-+-+-+-+-+-+-+
-       |       LP      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        P (length determined from LP)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LF      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        F (length determined from LF)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             DEG               |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             DEGH              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             DEGI              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             DEGJ              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             TRDV              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |S|     LH      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        H (length determined from LH)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |S|     LK      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        K (length determined from LK)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LQ      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        Q (length determined from LQ)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LA      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        A (length determined from LA)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             ALTA              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LB      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        B (length determined from LB)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LC      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        C (length determined from LC)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LG      |
-
-
-R. Schroeppel, et al                                            [Page 4]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        G (length determined from LG)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LY      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        Y (length determined from LY)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   SMFMTABZ is a flags octet as follows:
-
-        S = 1 indicates that the remaining 7 bits of the octet selects
-           one of 128 predefined choices of finite field, element
-           representation, elliptic curve, and signature parameters.
-           MFMTABZ are omitted, as are all parameters from LP through G.
-           LY and Y are retained.
-
-        If S = 0, the remaining parameters are as in the picture and
-           described below.
-
-        M determines the type of field underlying the elliptic curve.
-
-        M = 0 if the field is a GF[2^N] field;
-
-        M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
-
-        FMT is a three bit field describing the format of the field
-           representation.
-
-        FMT = 0  for a (mod P) field.
-            > 0  for an extension field, either GF[2^D] or GF[P^D].
-                The degree D of the extension, and the field polynomial
-                must be specified.  The field polynomial is always monic
-                (leading coefficient 1.)
-
-        FMT = 1  The field polynomial is given explicitly; D is implied.
-
-        If FMT >=2, the degree D is given explicitly.
-
-           = 2  The field polynomial is implicit.
-           = 3  The field polynomial is a binomial.  P>2.
-           = 4  The field polynomial is a trinomial.
-           = 5  The field polynomial is the quotient of a trinomial by a
-                short polynomial.  P=2.
-           = 6  The field polynomial is a pentanomial.  P=2.
-
-        Flags A and B apply to the elliptic curve parameters.
-
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 5]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-        A = 1 When P>=5, the curve parameter A is negated.  If P=2, then
-              A=1 indicates that the A parameter is special.  See the
-              ALTA parameter below, following A.  The combination A=1,
-              P=3 is forbidden.
-
-        B = 1 When P>=5, the curve parameter B is negated.  If P=2 or 3,
-              then B=1 indicates an alternate elliptic curve equation is
-              used.  When P=2 and B=1, an additional curve parameter C
-              is present.
-
-        The Z bit SHOULD be set to zero on creation of an RR and MUST be
-           ignored when processing an RR (when S=0).
-
-   Most of the remaining parameters are present in some formats and
-   absent in others.  The presence or absence of a parameter is
-   determined entirely by the flags.  When a parameter occurs, it is in
-   the order defined by the picture.
-
-   Of the remaining parameters, PFHKQABCGY are variable length.  When
-   present, each is preceded by a one-octet length field as shown in the
-   diagram above.  The length field does not include itself.  The length
-   field may have values from 0 through 110.  The parameter length in
-   octets is determined by a conditional formula: If LL<=64, the
-   parameter length is LL.  If LL>64, the parameter length is 16 times
-   (LL-60).  In some cases, a parameter value of 0 is sensible, and MAY
-   be represented by an LL value of 0, with the data field omitted.  A
-   length value of 0 represents a parameter value of 0, not an absent
-   parameter.  (The data portion occupies 0 space.)  There is no
-   requirement that a parameter be represented in the minimum number of
-   octets; high-order 0 octets are allowed at the front end.  Parameters
-   are always right adjusted, in a field of length defined by LL.  The
-   octet-order is always most-significant first, least-significant last.
-   The parameters H and K may have an optional sign bit stored in the
-   unused high-order bit of their length fields.
-
-   LP defines the length of the prime P.  P must be an odd prime.  The
-   parameters LP,P are present if and only if the flag M=1.  If M=0, the
-   prime is 2.
-
-   LF,F define an explicit field polynomial.  This parameter pair is
-   present only when FMT = 1.  The length of a polynomial coefficient is
-   ceiling(log2 P) bits.  Coefficients are in the numerical range
-   [0,P-1].  The coefficients are packed into fixed-width fields, from
-   higher order to lower order.  All coefficients must be present,
-   including any 0s and also the leading coefficient (which is required
-   to be 1).  The coefficients are right justified into the octet string
-   of length specified by LF, with the low-order "constant" coefficient
-   at the right end.  As a concession to storage efficiency, the higher
-   order bits of the leading coefficient may be elided, discarding high-
-   order 0 octets and reducing LF.  The degree is calculated by
-
-
-R. Schroeppel, et al                                            [Page 6]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-   determining the bit position of the left most 1-bit in the F data
-   (counting the right most bit as position 0), and dividing by
-   ceiling(log2 P).  The division must be exact, with no remainder.  In
-   this format, all of the other degree and field parameters are
-   omitted.  The next parameters will be LQ,Q.
-
-   If FMT>=2, the degree of the field extension is specified explicitly,
-   usually along with other parameters to define the field polynomial.
-
-   DEG is a two octet field that defines the degree of the field
-   extension.  The finite field will have P^DEG elements.  DEG is
-   present when FMT>=2.
-
-   When FMT=2, the field polynomial is specified implicitly.  No other
-   parameters are required to define the field; the next parameters
-   present will be the LQ,Q pair.  The implicit field poynomial is the
-   lexicographically smallest irreducible (mod P) polynomial of the
-   correct degree.  The ordering of polynomials is by highest-degree
-   coefficients first -- the leading coefficient 1 is most important,
-   and the constant term is least important.  Coefficients are ordered
-   by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ...  The first polynomial of
-   degree D is X^D (which is not irreducible).  The next is X^D+1, which
-   is sometimes irreducible, followed by X^D-1, which isn't.  Assuming
-   odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
-   X, X^D + X + 1, X^D + X - 1, etc.
-
-   When FMT=3, the field polynomial is a binomial, X^DEG + K.  P must be
-   odd.  The polynomial is determined by the degree and the low order
-   term K.  Of all the field parameters, only the LK,K parameters are
-   present.  The high-order bit of the LK octet stores on optional sign
-   for K; if the sign bit is present, the field polynomial is X^DEG - K.
-
-   When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
-   K.  When P=2, the H and K parameters are implicitly 1, and are
-   omitted from the representation.  Only DEG and DEGH are present; the
-   next parameters are LQ,Q.  When P>2, then LH,H and LK,K are
-   specified.  Either or both of LH, LK may contain a sign bit for its
-   parameter.
-
-   When FMT=5, then P=2 (only).  The field polynomial is the exact
-   quotient of a trinomial divided by a small polynomial, the trinomial
-   divisor.  The small polynomial is right-adjusted in the two octet
-   field TRDV.  DEG specifies the degree of the field.  The degree of
-   TRDV is calculated from the position of the high-order 1 bit.  The
-   trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1.  If
-   DEGH is 0, the middle term is omitted from the trinomial.  The
-   quotient must be exact, with no remainder.
-
-   When FMT=6, then P=2 (only).  The field polynomial is a pentanomial,
-   with the degrees of the middle terms given by the three 2-octet
-
-
-R. Schroeppel, et al                                            [Page 7]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-   values DEGH, DEGI, DEGJ.  The polynomial is X^DEG + X^DEGH + X^DEGI +
-   X^DEGJ + 1.  The values must satisfy the inequality DEG > DEGH > DEGI
-   > DEGJ > 0.
-
-        DEGH, DEGI, DEGJ  are two-octet fields that define the degree of
-           a term in a field polynomial.   DEGH is present when FMT = 4,
-           5, or 6.  DEGI and DEGJ are present only when FMT = 6.
-
-        TRDV is a two-octet right-adjusted binary polynomial of degree <
-           16.  It is present only for FMT=5.
-
-        LH and H define the H parameter, present only when FMT=4 and P
-           is odd.  The high bit of LH is an optional sign bit for H.
-
-        LK and K define the K parameter, present when FMT = 3 or 4, and
-           P is odd.  The high bit of LK is an optional sign bit for K.
-
-   The remaining parameters are concerned with the elliptic curve and
-   the signature algorithm.
-
-        LQ defines the length of the prime Q.  Q is a prime > 2^159.
-
-   In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
-   member of the pair is an element from the finite field defined
-   earlier.  The length field defines a long octet string.  Field
-   elements are represented as (mod P) polynomials of degree < DEG, with
-   DEG or fewer coefficients.  The coefficients are stored from left to
-   right, higher degree to lower, with the constant term last.  The
-   coefficients are represented as integers in the range [0,P-1].  Each
-   coefficient is allocated an area of ceiling(log2 P) bits.  The field
-   representation is right-justified; the "constant term" of the field
-   element ends at the right most bit.  The coefficients are fitted
-   adjacently without regard for octet boundaries.  (Example: if P=5,
-   three bits are used for each coefficient.  If the field is GF[5^75],
-   then 225 bits are required for the coefficients, and as many as 29
-   octets may be needed in the data area.  Fewer octets may be used if
-   some high-order coefficients are 0.)  If a flag requires a field
-   element to be negated, each non-zero coefficient K is replaced with
-   P-K.  To save space, 0 bits may be removed from the left end of the
-   element representation, and the length field reduced appropriately.
-   This would normally only happen with A,B,C, because the designer
-   chose curve parameters with some high-order 0 coefficients or bits.
-
-   If the finite field is simply (mod P), then the field elements are
-   simply numbers (mod P), in the usual right-justified notation.  If
-   the finite field is GF[2^D], the field elements are the usual right-
-   justified polynomial basis representation.
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 8]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-        LA,A is the first parameter of the elliptic curve equation.
-           When P>=5, the flag A = 1 indicates A should be negated (mod
-           P).  When P=2 (indicated by the flag M=0), the flag A = 1
-           indicates that the parameter pair LA,A is replaced by the two
-           octet parameter ALTA.  In this case, the parameter A in the
-           curve equation is x^ALTA, where x is the field generator.
-           Parameter A often has the value 0, which may be indicated by
-           LA=0 (with no A data field), and sometimes A is 1, which may
-           be represented with LA=1 and a data field of 1, or by setting
-           the A flag and using an ALTA value of 0.
-
-        LB,B is the second parameter of the elliptic curve equation.
-           When P>=5, the flag B = 1 indicates B should be negated (mod
-           P).  When P=2 or 3, the flag B selects an alternate curve
-           equation.
-
-        LC,C is the third parameter of the elliptic curve equation,
-           present only when P=2 (indicated by flag M=0) and flag B=1.
-
-        LG,G defines a point on the curve, of order Q.  The W-coordinate
-           of the curve point is given explicitly; the Z-coordinate is
-           implicit.
-
-        LY,Y is the user's public signing key, another curve point of
-           order Q.  The W-coordinate is given explicitly; the Z-
-           coordinate is implicit.  The LY,Y parameter pair is always
-           present.
-
-
-
-3. The Elliptic Curve Equation
-
-   (The coordinates of an elliptic curve point are named W,Z instead of
-   the more usual X,Y to avoid confusion with the Y parameter of the
-   signing key.)
-
-   The elliptic curve equation is determined by the flag octet, together
-   with information about the prime P.  The primes 2 and 3 are special;
-   all other primes are treated identically.
-
-   If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
-   + A*W + B.  Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
-   If A and/or B is negative (i.e., in the range from P/2 to P), and
-   P>=5, space may be saved by putting the sign bit(s) in the A and B
-   bits of the flags octet, and the magnitude(s) in the parameter
-   fields.
-
-   If M=1 and P=3, the B flag has a different meaning: it specifies an
-   alternate curve equation, Z^2 = W^3 + A*W^2 + B.  The middle term of
-   the right-hand-side is different.  When P=3, this equation is more
-
-
-R. Schroeppel, et al                                            [Page 9]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-   commonly used.
-
-   If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
-   A*W^2 + B.  Z,W,A,B are all elements of the field GF[2^N].  The A
-   parameter can often be 0 or 1, or be chosen as a single-1-bit value.
-   The flag B is used to select an alternate curve equation, Z^2 + C*Z =
-   W^3 + A*W + B.  This is the only time that the C parameter is used.
-
-
-
-4. How do I Compute Q, G, and Y?
-
-   The number of points on the curve is the number of solutions to the
-   curve equation, + 1 (for the "point at infinity").  The prime Q must
-   divide the number of points.  Usually the curve is chosen first, then
-   the number of points is determined with Schoof's algorithm.  This
-   number is factored, and if it has a large prime divisor, that number
-   is taken as Q.
-
-   G must be a point of order Q on the curve, satisfying the equation
-
-        Q * G  =  the point at infinity (on the elliptic curve)
-
-   G may be chosen by selecting a random [RFC 1750] curve point, and
-   multiplying it by (number-of-points-on-curve/Q).  G must not itself
-   be the "point at infinity"; in this astronomically unlikely event, a
-   new random curve point is recalculated.
-
-   G is specified by giving its W-coordinate.  The Z-coordinate is
-   calculated from the curve equation.  In general, there will be two
-   possible Z values.  The rule is to choose the "positive" value.
-
-   In the (mod P) case, the two possible Z values sum to P.  The smaller
-   value is less than P/2; it is used in subsequent calculations.  In
-   GF[P^D] fields, the highest-degree non-zero coefficient of the field
-   element Z is used; it is chosen to be less than P/2.
-
-   In the GF[2^N] case, the two possible Z values xor to W (or to the
-   parameter C with the alternate curve equation).  The numerically
-   smaller Z value (the one which does not contain the highest-order 1
-   bit of W (or C)) is used in subsequent calculations.
-
-   Y is specified by giving the W-coordinate of the user's public
-   signature key.  The Z-coordinate value is determined from the curve
-   equation.  As with G, there are two possible Z values; the same rule
-   is followed for choosing which Z to use.
-
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 10]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-   During the key generation process, a random [RFC 1750] number X must
-   be generated such that 1 <= X <= Q-1.  X is the private key and is
-   used in the final step of public key generation where Y is computed
-   as
-
-        Y = X * G (as points on the elliptic curve)
-
-   If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
-   in the (mod P) case, or the high-order non-zero coefficient of Z >
-   P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
-   GF[2^N] case), then X must be replaced with Q-X.  This will
-   correspond to the correct Z-coordinate.
-
-
-
-5. Elliptic Curve SIG Resource Records
-
-   The signature portion of an RR RDATA area when using the EC
-   algorithm, for example in the RRSIG and SIG [RFC records] RRs is
-   shown below.
-
-                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                   R, (length determined from LQ)           .../
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                   S, (length determined from LQ)           .../
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   R and S are integers (mod Q).  Their length is specified by the LQ
-   field of the corresponding KEY RR and can also be calculated from the
-   SIG RR's RDLENGTH. They are right justified, high-order-octet first.
-   The same conditional formula for calculating the length from LQ is
-   used as for all the other length fields above.
-
-   The data signed is determined as specified in [RFC 2535].  Then the
-   following steps are taken where Q, P, G, and Y are as specified in
-   the public key [Schneier]:
-
-     hash = SHA-1 ( data )
-
-     Generate random [RFC 4086] K such that 0 < K < Q.  (Never sign two
-          different messages with the same K.  K should be chosen from a
-          very large space: If an opponent learns a K value for a single
-          signature, the user's signing key is compromised, and a forger
-          can sign arbitrary messages. There is no harm in signing the
-          same message multiple times with the same key or different
-          keys.)
-
-     R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted
-
-
-R. Schroeppel, et al                                           [Page 11]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-          as an integer, and reduced (mod Q).  (R must not be 0.  In
-          this astronomically unlikely event, generate a new random K
-          and recalculate R.)
-
-     S = ( K^(-1) * (hash + X*R) ) mod Q.
-
-     S must not be 0.  In this astronomically unlikely event, generate a
-          new random K and recalculate R and S.
-
-     If S > Q/2, set S = Q - S.
-
-     The pair (R,S) is the signature.
-
-     Another party verifies the signature as follows:
-
-          Check that 0 < R < Q and 0 < S < Q/2.  If not, it can not be a
-               valid EC sigature.
-
-          hash = SHA-1 ( data )
-
-          Sinv = S^(-1) mod Q.
-
-          U1 = (hash * Sinv) mod Q.
-
-          U2 = (R * Sinv) mod Q.
-
-          (U1 * G + U2 * Y) is computed on the elliptic curve.
-
-          V = (the W-coordinate of this point) interpreted as an integer
-               and reduced (mod Q).
-
-          The signature is valid if V = R.
-
-     The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
-     (R,Q-S) would be valid signatures for the same data.  Note that a
-     signature that is valid for hash(data) is also valid for
-     hash(data)+Q or hash(data)-Q, if these happen to fall in the range
-     [0,2^160-1].  It's believed to be computationally infeasible to
-     find data that hashes to an assigned value, so this is only a
-     cosmetic blemish.  The blemish can be eliminated by using Q >
-     2^160, at the cost of having slightly longer signatures, 42 octets
-     instead of 40.
-
-     We must specify how a field-element E ("the W-coordinate") is to be
-     interpreted as an integer.  The field-element E is regarded as a
-     radix-P integer, with the digits being the coefficients in the
-     polynomial basis representation of E.  The digits are in the ragne
-     [0,P-1].  In the two most common cases, this reduces to "the
-     obvious thing".  In the (mod P) case, E is simply a residue mod P,
-     and is taken as an integer in the range [0,P-1].  In the GF[2^D]
-
-
-R. Schroeppel, et al                                           [Page 12]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-     case, E is in the D-bit polynomial basis representation, and is
-     simply taken as an integer in the range [0,(2^D)-1].  For other
-     fields GF[P^D], it's necessary to do some radix conversion
-     arithmetic.
-
-
-
-  6. Performance Considerations
-
-     Elliptic curve signatures use smaller moduli or field sizes than
-     RSA and DSA.  Creation of a curve is slow, but not done very often.
-     Key generation is faster than RSA or DSA.
-
-     DNS implementations have been optimized for small transfers,
-     typically less than 512 octets including DNS overhead. Larger
-     transfers will perform correctly and and extensions have been
-     standardized to make larger transfers more efficient [RFC 2671].
-     However, it is still advisable at this time to make reasonable
-     efforts to minimize the size of RR sets stored within the DNS
-     consistent with adequate security.
-
-
-
-  7. Security Considerations
-
-     Keys retrieved from the DNS should not be trusted unless (1) they
-     have been securely obtained from a secure resolver or independently
-     verified by the user and (2) this secure resolver and secure
-     obtainment or independent verification conform to security policies
-     acceptable to the user.  As with all cryptographic algorithms,
-     evaluating the necessary strength of the key is essential and
-     dependent on local policy.
-
-     Some specific key generation considerations are given in the body
-     of this document.
-
-
-
-  8. IANA Considerations
-
-     The key and signature data structures defined herein correspond to
-     the value 4 in the Algorithm number field of the IANA registry
-
-     Assignment of meaning to the remaining ECC data flag bits or to
-     values of ECC fields outside the ranges for which meaning in
-     defined in this document requires an IETF consensus as defined in
-     [RFC 2434].
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 13]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-  Copyright and Disclaimer
-
-     Copyright (C) The Internet Society 2005.  This document is subject
-     to the rights, licenses and restrictions contained in BCP 78, and
-     except as set forth therein, the authors retain all their rights.
-
-
-     This document and the information contained herein are provided on
-     an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
-     REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
-     THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
-     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
-     THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
-     ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
-     PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 14]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-  Informational References
-
-     [RFC 1034] - P. Mockapetris, "Domain names - concepts and
-     facilities", 11/01/1987.
-
-     [RFC 1035] - P. Mockapetris, "Domain names - implementation and
-     specification", 11/01/1987.
-
-     [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
-     August 1999.
-
-     [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and
-     S. Rose, "DNS Security Introduction and Requirements", RFC 4033,
-     March 2005.
-
-     [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and
-     S. Rose, "Protocol Modifications for the DNS Security Extensions",
-     RFC 4035, March 2005.
-
-     [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-     "Randomness Requirements for Security", BCP 106, RFC 4086, June
-     2005.
-
-     [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
-     Algorithms, and Source Code in C", 1996, John Wiley and Sons
-
-     [Menezes] - Alfred Menezes, "Elliptic Curve Public Key
-     Cryptosystems", 1993 Kluwer.
-
-     [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
-     Curves", 1986, Springer Graduate Texts in mathematics #106.
-
-
-
-  Normative Refrences
-
-     [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
-     Requirement Levels", March 1997.
-
-     [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
-     IANA Considerations Section in RFCs", October 1998.
-
-     [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and
-     S. Rose, "Resource Records for the DNS Security Extensions", RFC
-     4034, March 2005.
-
-
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 15]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-  Author's Addresses
-
-     Rich Schroeppel
-     500 S. Maple Drive
-     Woodland Hills, UT 84653 USA
-
-     Telephone:   +1-505-844-9079(w)
-     Email:       rschroe@sandia.gov
-
-
-     Donald E. Eastlake 3rd
-     Motorola Laboratories
-     155 Beaver Street
-     Milford, MA 01757 USA
-
-     Telephone:   +1 508-786-7554 (w)
-     EMail:       Donald.Eastlake@motorola.com
-
-
-
-  Expiration and File Name
-
-     This draft expires in January 2006.
-
-     Its file name is draft-ietf-dnsext-ecc-key-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 16]
-
diff --git a/doc/draft/draft-ietf-dnsext-interop3597-02.txt b/doc/draft/draft-ietf-dnsext-interop3597-02.txt
deleted file mode 100644
index 160afc35..00000000
--- a/doc/draft/draft-ietf-dnsext-interop3597-02.txt
+++ /dev/null
@@ -1,334 +0,0 @@
-DNS Extensions Working Group                                 J. Schlyter
-Internet-Draft                                              May 19, 2005
-Expires: November 20, 2005
-
-
-                     RFC 3597 Interoperability Report
-                   draft-ietf-dnsext-interop3597-02.txt
-
-Status of this Memo
-
-    By submitting this Internet-Draft, each author represents that any
-    applicable patent or other IPR claims of which he or she is aware
-    have been or will be disclosed, and any of which he or she becomes
-    aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-    Internet-Drafts are working documents of the Internet Engineering
-    Task Force (IETF), its areas, and its working groups.  Note that
-    other groups may also distribute working documents as Internet-
-    Drafts.
-
-    Internet-Drafts are draft documents valid for a maximum of six months
-    and may be updated, replaced, or obsoleted by other documents at any
-    time.  It is inappropriate to use Internet-Drafts as reference
-    material or to cite them other than as "work in progress."
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/ietf/1id-abstracts.txt.
-
-    The list of Internet-Draft Shadow Directories can be accessed at
-    http://www.ietf.org/shadow.html.
-
-    This Internet-Draft will expire on November 20, 2005.
-
-Copyright Notice
-
-    Copyright (C) The Internet Society (2005).
-
-Abstract
-
-    This memo documents the result from the RFC 3597 (Handling of Unknown
-    DNS Resource Record Types) interoperability testing.
-
-
-
-
-
-
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 1]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-Table of Contents
-
-    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-    2.  Implementations  . . . . . . . . . . . . . . . . . . . . . . .  3
-    3.  Tests  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-      3.1   Authoritative Primary Name Server  . . . . . . . . . . . .  3
-      3.2   Authoritative Secondary Name Server  . . . . . . . . . . .  3
-      3.3   Full Recursive Resolver  . . . . . . . . . . . . . . . . .  4
-      3.4   Stub Resolver  . . . . . . . . . . . . . . . . . . . . . .  4
-      3.5   DNSSEC Signer  . . . . . . . . . . . . . . . . . . . . . .  4
-    4.  Problems found . . . . . . . . . . . . . . . . . . . . . . . .  4
-    5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-    6.  Normative References . . . . . . . . . . . . . . . . . . . . .  4
-        Author's Address . . . . . . . . . . . . . . . . . . . . . . .  4
-    A.  Test zone data . . . . . . . . . . . . . . . . . . . . . . . .  5
-        Intellectual Property and Copyright Statements . . . . . . . .  6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 2]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-1.  Introduction
-
-    This memo documents the result from the RFC 3597 (Handling of Unknown
-    DNS Resource Record Types) interoperability testing.  The test was
-    performed during June and July 2004 by request of the IETF DNS
-    Extensions Working Group.
-
-2.  Implementations
-
-    The following is a list, in alphabetic order, of implementations
-    tested for compliance with RFC 3597:
-
-       DNSJava 1.6.4
-       ISC BIND 8.4.5
-       ISC BIND 9.3.0
-       NSD 2.1.1
-       Net::DNS 0.47 patchlevel 1
-       Nominum ANS 2.2.1.0.d
-
-    These implementations covers the following functions (number of
-    implementations tested for each function in paranthesis):
-
-       Authoritative Name Servers (4)
-       Full Recursive Resolver (2)
-       Stub Resolver (4)
-       DNSSEC Zone Signers (2)
-
-    All listed implementations are genetically different.
-
-3.  Tests
-
-    The following tests was been performed to validate compliance with
-    RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression")
-    and 5 ("Text Representation").
-
-3.1  Authoritative Primary Name Server
-
-    The test zone data (Appendix A) was loaded into the name server
-    implementation and the server was queried for the loaded information.
-
-3.2  Authoritative Secondary Name Server
-
-    The test zone data (Appendix A) was transferred using AXFR from
-    another name server implementation and the server was queried for the
-    transferred information.
-
-
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 3]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-3.3  Full Recursive Resolver
-
-    A recursive resolver was queried for resource records from a domain
-    with the test zone data (Appendix A).
-
-3.4  Stub Resolver
-
-    A stub resolver was used to query resource records from a domain with
-    the test zone data (Appendix A).
-
-3.5  DNSSEC Signer
-
-    A DNSSEC signer was used to sign a zone with test zone data
-    (Appendix A).
-
-4.  Problems found
-
-    Two implementations had problems with text presentation of zero
-    length RDATA.
-
-    One implementation had problems with text presentation of RR type
-    code and classes >= 4096.
-
-    Bug reports were filed for problems found.
-
-5.  Summary
-
-    Unknown type codes works in the tested authoritative servers,
-    recursive resolvers and stub clients.
-
-    No changes are needed to advance RFC 3597 to draft standard.
-
-6.  Normative References
-
-    [1]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-         Types", RFC 3597, September 2003.
-
-
-Author's Address
-
-    Jakob Schlyter
-
-    Email: jakob@rfc.se
-
-
-
-
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 4]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-Appendix A.  Test zone data
-
-    ; A-record encoded as TYPE1
-    a  TYPE1  \# 4 7f000001
-    a  TYPE1  192.0.2.1
-    a  A      \# 4 7f000002
-
-    ; draft-ietf-secsh-dns-05.txt
-    sshfp  TYPE44  \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
-
-    ; bogus test record (from RFC 3597)
-    type731    TYPE731    \# 6 abcd (
-                               ef 01 23 45 )
-
-    ; zero length RDATA (from RFC 3597)
-    type62347  TYPE62347  \# 0
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 5]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-Intellectual Property Statement
-
-    The IETF takes no position regarding the validity or scope of any
-    Intellectual Property Rights or other rights that might be claimed to
-    pertain to the implementation or use of the technology described in
-    this document or the extent to which any license under such rights
-    might or might not be available; nor does it represent that it has
-    made any independent effort to identify any such rights.  Information
-    on the procedures with respect to rights in RFC documents can be
-    found in BCP 78 and BCP 79.
-
-    Copies of IPR disclosures made to the IETF Secretariat and any
-    assurances of licenses to be made available, or the result of an
-    attempt made to obtain a general license or permission for the use of
-    such proprietary rights by implementers or users of this
-    specification can be obtained from the IETF on-line IPR repository at
-    http://www.ietf.org/ipr.
-
-    The IETF invites any interested party to bring to its attention any
-    copyrights, patents or patent applications, or other proprietary
-    rights that may cover technology that may be required to implement
-    this standard.  Please address the information to the IETF at
-    ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-    This document and the information contained herein are provided on an
-    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-    Copyright (C) The Internet Society (2005).  This document is subject
-    to the rights, licenses and restrictions contained in BCP 78, and
-    except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-    Funding for the RFC Editor function is currently provided by the
-    Internet Society.
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 6]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-05.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-05.txt
deleted file mode 100644
index a46655af..00000000
--- a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-05.txt
+++ /dev/null
@@ -1,728 +0,0 @@
-
-
-
-DNSEXT Working Group                                            J. Damas
-Internet-Draft                                                  M. Graff
-Obsoletes: 2671, 2673                                           P. Vixie
-(if approved)                                Internet Systems Consortium
-Intended status: Standards Track                           March 7, 2011
-Expires: September 8, 2011
-
-
-                  Extension Mechanisms for DNS (EDNS0)
-                 draft-ietf-dnsext-rfc2671bis-edns0-05
-
-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 requestors to advertise their capabilities to responders.  This
-   document describes backward compatible mechanisms for allowing the
-   protocol to grow.
-
-   This document updates the EDNS0 specification [RFC2671] based on 10
-   years of deployment experience.
-
-Status of this Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at http://datatracker.ietf.org/drafts/current/.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   This Internet-Draft will expire on September 8, 2011.
-
-Copyright Notice
-
-   Copyright (c) 2011 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-
-
-
-Damas, et al.           Expires September 8, 2011               [Page 1]
-
-Internet-Draft              EDNS0 Extensions                  March 2011
-
-
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  EDNS Support Requirement . . . . . . . . . . . . . . . . . . .  3
-   4.  DNS Message changes  . . . . . . . . . . . . . . . . . . . . .  4
-     4.1.  Message Header . . . . . . . . . . . . . . . . . . . . . .  4
-     4.2.  Label Types  . . . . . . . . . . . . . . . . . . . . . . .  4
-     4.3.  UDP Message Size . . . . . . . . . . . . . . . . . . . . .  4
-   5.  Extended Label Types . . . . . . . . . . . . . . . . . . . . .  4
-   6.  The OPT pseudo-RR  . . . . . . . . . . . . . . . . . . . . . .  5
-     6.1.  OPT Record Definition  . . . . . . . . . . . . . . . . . .  5
-     6.2.  OPT Record Wire Format . . . . . . . . . . . . . . . . . .  5
-     6.3.  Cache behaviour  . . . . . . . . . . . . . . . . . . . . .  7
-     6.4.  Fallback . . . . . . . . . . . . . . . . . . . . . . . . .  7
-     6.5.  Requestor's Payload Size . . . . . . . . . . . . . . . . .  7
-     6.6.  Responder's Payload Size . . . . . . . . . . . . . . . . .  7
-     6.7.  Payload Size Selection . . . . . . . . . . . . . . . . . .  8
-     6.8.  Middleware Boxes . . . . . . . . . . . . . . . . . . . . .  8
-     6.9.  OPT Record TTL Field Use . . . . . . . . . . . . . . . . .  8
-     6.10. Flags  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-     6.11. OPT Options Code Allocation Procedure  . . . . . . . . . .  9
-   7.  Transport Considerations . . . . . . . . . . . . . . . . . . . 10
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   Appendix A.   Document Editing History . . . . . . . . . . . . . . 11
-   Appendix A.1. Changes since RFC2671  . . . . . . . . . . . . . . . 11
-   Appendix A.2. Changes since -02  . . . . . . . . . . . . . . . . . 12
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 12
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-Damas, et al.           Expires September 8, 2011               [Page 2]
-
-Internet-Draft              EDNS0 Extensions                  March 2011
-
-
-1.  Introduction
-
-   DNS [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 limited
-   to 512 bytes.  Many of DNS's protocol limits are too small for uses
-   which are commom or desired to become common.  RFC 1035 does not
-   define any way for implementations to advertise their capabilities.
-
-   [RFC2671] added extension mechanism to DNS, this mechanism is widely
-   supported and number of new DNS uses and protocol extensions depend
-   on the presence of these extensions.  This memo refines that
-   specification and obsoletes [RFC2671].
-
-   Unextended agents will not know how to interpret the protocol
-   extensions defined in [RFC2671] and restated here.  Extended agents
-   must be prepared for handling the interactions with unextended
-   clients in the face of new protocol elements, and fall back
-   gracefully to unextended DNS.  [RFC2671] proposed extensions to the
-   basic DNS protocol to overcome these deficiencies.  This memo refines
-   that specification and obsoletes [RFC2671].
-
-   [RFC2671] specified extended label types.  The only one proposed was
-   in RFC2673 for a label type called "Bitstring Labels."  For various
-   reasons introducing a new label type was found to be extremely
-   difficult, and RFC2673 was moved to Experimental.  This document
-   Obsoletes Extended Labels.
-
-
-2.  Terminology
-
-   "Requestor" is the side which sends a request.  "Responder" is an
-   authoritative, recursive resolver, or other DNS component which
-   responds to questions.
-
-   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].
-
-
-3.  EDNS Support Requirement
-
-   EDNS support is practically mandatory in a modern world.  DNSSEC
-   requires EDNS support, and many other features are made possible only
-   by EDNS support to request or advertise them.  Many organizations are
-   requiring DNSSEC.  Without common interoperability, DNSSEC cannot be
-   as easily deployed.
-
-
-
-
-Damas, et al.           Expires September 8, 2011               [Page 3]
-
-Internet-Draft              EDNS0 Extensions                  March 2011
-
-
-   DNS publishers are wanting to put more data in answers.  DNSSEC
-   DNSKEY records, negative answers, and many other DNSSEC queries cause
-   larger answers to be returned.  In order to support this, DNS
-   servers, middleware, and stub resolvers MUST support larger packet
-   sizes advertised via EDNS0.
-
-
-4.  DNS Message changes
-
-4.1.  Message Header
-
-   The DNS Message Header's second full 16-bit word is divided into a
-   4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see ,
-   section 4.1.1 [RFC1035]).  Some of these were marked for future use,
-   and most these have since been allocated.  Also, most of the RCODE
-   values are now in use.  The OPT pseudo-RR specified below contains
-   extensions to the RCODE bit field as well as additional flag bits.
-
-4.2.  Label Types
-
-   The first two bits of a wire format domain label are used to denote
-   the type of the label.  [RFC1035] allocates two of the four possible
-   types and reserves the other two.  More label types were defined in
-   [RFC2671].  This document obsoletes the use of the 2-bit combination
-   defined by [RFC2671] to identify extended label types.
-
-4.3.  UDP Message Size
-
-   Traditional DNS Messages are limited to 512 octets in size when sent
-   over UDP ([RFC1035]).  Today, many organizations wish to return many
-   records in a single reply, and special tricks are needed to make the
-   responses fit in this 512-byte limit.  Additionally, inclusion of
-   DNSSEC records frequently requires a much larger response than a 512
-   byte message can hold.
-
-   EDNS0 is intended to address these larger packet sizes and continue
-   to use UDP.  It specifies a way to advertise additional features such
-   as larger response size capability, which is intended to help avoid
-   truncated UDP responses which then cause retry over TCP.
-
-
-5.  Extended Label Types
-
-   The first octet in the on-the-wire representation of a DNS label
-   specifies the label type; the basic DNS specification [RFC1035]
-   dedicates the two most significant bits of that octet for this
-   purpose.
-
-
-
-
-Damas, et al.           Expires September 8, 2011               [Page 4]
-
-Internet-Draft              EDNS0 Extensions                  March 2011
-
-
-   [RFC2671] defined DNS label type 0b01 for use as an indication for
-   Extended Label Types.  A specific Extended Label Type is selected by
-   the 6 least significant bits of the first octet.  Thus, Extended
-   Label Types are indicated by the values 64-127 (0b01xxxxxx) in the
-   first octet of the label.
-
-   Extended Label Types are difficult to use due to support in clients
-   and intermediate gateways as described in [RFC3364] which moves them
-   to experimental status and [RFC3363], which describes the pros and
-   cons.
-
-   Therefore, this document moves them from experimental to historical,
-   making them obsoleted.  Additionally, the registry of Extended Label
-   Types is requested to be closed.
-
-
-6.  The OPT pseudo-RR
-
-6.1.  OPT Record Definition
-
-   An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the
-   additional data section of a request.
-
-   The OPT RR has RR type 41.
-
-   If present in requests, compliant responders MUST include an OPT
-   record in their respective responses.
-
-   An OPT record does not carry any DNS data.  It is used only to
-   contain control information pertaining to the question and answer
-   sequence of a specific transaction.  OPT RRs MUST NOT be cached,
-   forwarded, or stored in or loaded from master files.
-
-   The OPT RR MAY be placed anywhere within the additional data section.
-   Only one OPT RR MAY be included within any DNS message.  If a message
-   with more than one OPT RR is received, a FORMERR (RCODE=1) MUST be
-   returned.  The placement flexibility for the OPT RR does not override
-   the need for the TSIG or SIG(0) RRs to be the last in the additional
-   section whenever they are present.
-
-6.2.  OPT Record Wire Format
-
-   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 basic extension elements which we
-   expect to be so popular that it would be a waste of wire space to
-   encode them as {attribute, value} pairs.
-
-
-
-
-Damas, et al.           Expires September 8, 2011               [Page 5]
-
-Internet-Draft              EDNS0 Extensions                  March 2011
-
-
-   The fixed part of an OPT RR is structured as follows:
-
-       +------------+--------------+------------------------------+
-       | Field Name | Field Type   | Description                  |
-       +------------+--------------+------------------------------+
-       | NAME       | domain name  | Must be 0 (root domain)      |
-       | TYPE       | u_int16_t    | OPT (42)                     |
-       | CLASS      | u_int16_t    | requestor's UDP payload size |
-       | TTL        | u_int32_t    | extended RCODE and flags     |
-       | RDLEN      | u_int16_t    | length of all RDATA          |
-       | RDATA      | octet stream | {attribute,value} pairs      |
-       +------------+--------------+------------------------------+
-
-                               OPT RR Format
-
-   The variable part of an OPT RR may contain zero or more options in
-   the RDATA.  Each option must be treated as binary.  Each option is
-   encoded as:
-
-
-                  +0 (MSB)                            +1 (LSB)
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    0: |                          OPTION-CODE                          |
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    2: |                         OPTION-LENGTH                         |
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    4: |                                                               |
-       /                          OPTION-DATA                          /
-       /                                                               /
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-   OPTION-CODE
-         Assigned by Expert Review.
-
-   OPTION-LENGTH
-         Size (in octets) of OPTION-DATA.
-
-   OPTION-DATA
-         Varies per OPTION-CODE.  MUST be treated as binary.
-
-   The order of appearance of option tuples is not defined.  If one
-   option modifies the behavior of another or multiple options are
-   related to one another in some way, they have the same effect
-   regardless of ordering in the RDATA wire encoding.
-
-   Any OPTION-CODE values not understood by a responder or requestor
-   MUST be ignored.  Specifications of such options might wish to
-   include some kind of signaled acknowledgement.  For example, an
-
-
-
-Damas, et al.           Expires September 8, 2011               [Page 6]
-
-Internet-Draft              EDNS0 Extensions                  March 2011
-
-
-   option specification might say that if a responder sees option XYZ,
-   it MUST include option XYZ in its response.
-
-6.3.  Cache behaviour
-
-   The OPT record MUST NOT be cached.
-
-6.4.  Fallback
-
-   If a requestor detects that the remote end does not support EDNS0, it
-   MAY issue queries without an OPT record.  It MAY cache this knowledge
-   for a brief time in order to avoid fallback delays in the future.
-   However, if DNSSEC or any future option using EDNS is required, no
-   fallback should be performed as they are only signaled through EDNS0.
-   If an implementation detects that some servers for the zone support
-   EDNS(0) while others would force the use of TCP to fetch all data,
-   preference SHOULD be given to those support EDNS(0).
-
-6.5.  Requestor's Payload Size
-
-   The requestor's UDP payload size (encoded in the RR CLASS field) is
-   the number of octets of the largest UDP payload that can be
-   reassembled and delivered in the requestor's network stack.  Note
-   that path MTU, with or without fragmentation, could be smaller than
-   this.  Values lower than 512 MUST be treated as equal to 512.
-
-   The requestor SHOULD place a value in this field that it can actually
-   receive.  For example, if a requestor sits behind a firewall which
-   will block fragmented IP packets, a requestor SHOULD not choose a
-   value which will cause fragmentation.  Doing so will prevent large
-   responses from being received, and can cause fallback to occur.
-
-   Note that a 512-octet UDP payload requires a 576-octet IP reassembly
-   buffer.  Choosing between 1280 and 1410 bytes for IP (v4 or v6) over
-   Ethernet would be reasonable.  Choosing a very large value will
-   guarantee fragmentation at the IP layer, and may prevent answers from
-   being received due to a single fragment loss or misconfigured
-   firewalls.
-
-   The requestor's maximum payload size can change over time.  It MUST
-   not be cached for use beyond the transaction in which it is
-   advertised.
-
-6.6.  Responder's Payload Size
-
-   The responder's maximum payload size can change over time, but can be
-   reasonably expected to remain constant between two closely spaced
-   sequential transactions; for example, a meaningless QUERY to discover
-
-
-
-Damas, et al.           Expires September 8, 2011               [Page 7]
-
-Internet-Draft              EDNS0 Extensions                  March 2011
-
-
-   a responder's maximum UDP payload size, followed immediately by an
-   UPDATE which takes advantage of this size.  This is considered
-   preferable 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.
-
-6.7.  Payload Size Selection
-
-   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.
-
-   A requestor MAY choose to implement a fallback to smaller advertised
-   sizes to work around firewall or other network limitations.  A
-   requestor SHOULD choose to use a fallback mechanism which begins with
-   a large size, such as 4096.  If that fails, a fallback around the
-   1280-1410 byte range SHOULD be tried, as it has a reasonable chance
-   to fit within a single Ethernet frame.  Failing that, a requestor MAY
-   choose a 512 byte packet, which with large answers may cause a TCP
-   retry.
-
-6.8.  Middleware Boxes
-
-   Middleware boxes (e.g. firewalls, SOHO routers, load balancers, etc)
-   MUST NOT limit DNS messages over UDP to 512 bytes.
-
-   Middleware boxes which simply forward requests to a recursive
-   resolver MUST NOT modify and MUST NOT delete the OPT record contents
-   in either direction.
-
-   Middleware boxes which have additional functionality, such as
-   answering certain queries or acting like an intelligent forwarder,
-   MUST understand the OPT record.  These boxes MUST consider the
-   incoming request and any outgoing requests as separate transactions
-   if the characteristics of the messages are different.
-
-   A complete discussion of middleware boxes acting as DNS proxies and
-   the impact of EDNS in those implementations is described in
-   [RFC5625].
-
-6.9.  OPT Record TTL Field Use
-
-   The extended RCODE and flags (which OPT stores in the RR TTL field)
-   are structured as follows:
-
-
-
-
-
-
-Damas, et al.           Expires September 8, 2011               [Page 8]
-
-Internet-Draft              EDNS0 Extensions                  March 2011
-
-
-                  +0 (MSB)                            +1 (LSB)
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    0: |         EXTENDED-RCODE        |            VERSION            |
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    2: | DO|                           Z                               |
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-   EXTENDED-RCODE
-         Forms upper 8 bits of extended 12-bit RCODE (together with the
-         4 bits defined in [RFC1035].  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 MAY
-         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
-         MUST be limited in format to the VERSION level of the request,
-         but the VERSION of each response SHOULD 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 and
-         including RCODE=BADVERS.
-
-6.10.  Flags
-
-   DO
-         DNSSEC OK bit as defined by [RFC3225].
-
-   Z
-         Set to zero by senders and ignored by receivers, unless
-         modified in a subsequent specification.
-
-6.11.  OPT Options Code Allocation Procedure
-
-   Allocations assigned by expert review.  Assignment of Option Codes
-   should be liberal, but duplicate functionality is to be avoided.
-
-
-
-
-
-
-
-Damas, et al.           Expires September 8, 2011               [Page 9]
-
-Internet-Draft              EDNS0 Extensions                  March 2011
-
-
-7.  Transport Considerations
-
-   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.
-
-   Lack of presence of an OPT record in a request MUST be taken as an
-   indication that the requestor does not implement any part of this
-   specification and that the responder MUST NOT include an OPT record
-   in its response.
-
-   Responders who do not implement these protocol extensions MUST
-   respond with FORMERR messages without any OPT record.
-
-   If there is a problem with processing the OPT record itself, such as
-   an option value that is badly formatted or includes out of range
-   values, a FORMERR MUST be returned.  If this occurs the response MUST
-   include an OPT record.  This is intended to allow the requestor to to
-   distinguish between servers which do not implement EDNS and format
-   errors within EDNS.
-
-   The minimal response must be the DNS header, question section, and an
-   OPT record.  This must also occur when an truncated response (using
-   the DNS header's TC bit) is returned.
-
-
-8.  Security Considerations
-
-   Requestor-side specification of the maximum buffer size may open a
-   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.
-
-   Announcing very large UDP buffer sizes may result in dropping by
-   middleboxes (see Section 6.8).  This could cause retransmissions with
-   no hope of success.  Some devices have been found to reject
-   fragmented UDP packets.
-
-   Announcing too small UDP buffer sizes may result in fallback to TCP
-   with a corresponding load impact on DNS servers.  This is especially
-   important with DNSSEC, where answers are much larger.
-
-
-9.  IANA Considerations
-
-   The IANA has assigned RR type code 41 for OPT.
-
-
-
-Damas, et al.           Expires September 8, 2011              [Page 10]
-
-Internet-Draft              EDNS0 Extensions                  March 2011
-
-
-   [RFC2671] specified a number of IANA sub-registries within "DOMAIN
-   NAME SYSTEM PARAMETERS:"
-
-   o  EDNS Extended Label Type
-
-   o  EDNS Option Codes
-
-   o  EDNS Version Numbers
-
-   o  Domain System Response Code
-
-   IANA is advised to re-parent these sub-registries to this document.
-
-   [RFC2671] created the "EDNS Extended Label Type Registry".  We
-   request that this registry be closed.
-
-   This document assigns option code 65535 in the "EDNS Option Codes"
-   registry to "Reserved for future expansion."
-
-   [RFC2671] expands the RCODE space from 4 bits to 12 bits.  This
-   allows more than the 16 distinct RCODE values allowed in [RFC1035].
-   IETF Standards Action is required to add a new RCODE.  Adding new
-   RCODEs should be avoided due to the difficulty in upgrading the
-   installed base.
-
-   This document assigns EDNS Extended RCODE 16 to "BADVERS".
-
-   IETF Standards Action is required for assignments of new EDNS0 flags.
-   Flags SHOULD be used only when necessary for DNS resolution to
-   function.  For many uses, a EDNS Option Code may be preferred.
-
-   IETF Standards Action is required to create new entries in the EDNS
-   Version Number registry.  Expert Review is required for allocation of
-   an EDNS Option Code.
-
-
-Appendix A.  Document Editing History
-
-   Following is a list of high-level changes made to the original
-   RFC2671.
-
-Appendix A.1.  Changes since RFC2671
-
-   o  Support for the OPT record is now mandatory.
-
-   o  Extended label types obsoleted and the registry is closed.
-
-
-
-
-
-Damas, et al.           Expires September 8, 2011              [Page 11]
-
-Internet-Draft              EDNS0 Extensions                  March 2011
-
-
-   o  The bitstring label type, which was already moved from draft to
-      experimental, is requested to be moved to historical.
-
-   o  Changes in how EDNS buffer sizes are selected, with
-      recommendations on how to select them.
-
-   o  Front material (IPR notice and such) was updated to current
-      requirements.
-
-Appendix A.2.  Changes since -02
-
-   o  Specified the method for allocation of constants.
-
-   o  Cleaned up a lot of wording, along with quite a bit of document
-      structure changes.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
-              RFC 3225, December 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.
-
-10.2.  Informative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
-              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
-              August 2002.
-
-   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
-              BCP 152, RFC 5625, August 2009.
-
-
-
-
-
-Damas, et al.           Expires September 8, 2011              [Page 12]
-
-Internet-Draft              EDNS0 Extensions                  March 2011
-
-
-Authors' Addresses
-
-   Joao Damas
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, California  94063
-   US
-
-   Phone: +1 650.423.1312
-   Email: joao@isc.org
-
-
-   Michael Graff
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, California  94063
-   US
-
-   Phone: +1 650.423.1304
-   Email: mgraff@isc.org
-
-
-   Paul Vixie
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, California  94063
-   US
-
-   Phone: +1 650.423.1301
-   Email: vixie@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Damas, et al.           Expires September 8, 2011              [Page 13]
-
diff --git a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt
deleted file mode 100644
index 34723c4f..00000000
--- a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt
+++ /dev/null
@@ -1,1008 +0,0 @@
-
-
-
-DNS Extensions Working Group                                     S. Rose
-Internet-Draft                                                      NIST
-Obsoletes: 2672 (if approved)                              W. Wijngaards
-Updates: 3363,4294                                            NLnet Labs
-(if approved)                                             April 20, 2010
-Intended status: Standards Track
-Expires: October 22, 2010
-
-
-                 Update to DNAME Redirection in the DNS
-                 draft-ietf-dnsext-rfc2672bis-dname-19
-
-Abstract
-
-   The DNAME record provides redirection for a sub-tree of the domain
-   name tree in the DNS system.  That is, all names that end with a
-   particular suffix are redirected to another part of the DNS.  This is
-   a revision of the original specification in RFC 2672, also aligning
-   RFC 3363 and RFC 4294 with this revision.
-
-Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-Status of This Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on October 22, 2010.
-
-
-
-Rose & Wijngaards       Expires October 22, 2010                [Page 1]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-   This document may contain material from IETF Documents or IETF
-   Contributions published or made publicly available before November
-   10, 2008.  The person(s) controlling the copyright in some of this
-   material may not have granted the IETF Trust the right to allow
-   modifications of such material outside the IETF Standards Process.
-   Without obtaining an adequate license from the person(s) controlling
-   the copyright in such materials, this document may not be modified
-   outside the IETF Standards Process, and derivative works of it may
-   not be created outside the IETF Standards Process, except to format
-   it for publication as an RFC or to translate it into languages other
-   than English.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010                [Page 2]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-
-   2.  The DNAME Resource Record  . . . . . . . . . . . . . . . . . .  4
-     2.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     2.2.  The DNAME Substitution . . . . . . . . . . . . . . . . . .  5
-     2.3.  DNAME Owner Name Matching the QNAME  . . . . . . . . . . .  7
-     2.4.  Names Next to and Below a DNAME Record . . . . . . . . . .  7
-     2.5.  Compression of the DNAME record. . . . . . . . . . . . . .  7
-
-   3.  Processing . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     3.1.  CNAME synthesis  . . . . . . . . . . . . . . . . . . . . .  8
-     3.2.  Server algorithm . . . . . . . . . . . . . . . . . . . . .  9
-     3.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 11
-     3.4.  Acceptance and Intermediate Storage  . . . . . . . . . . . 11
-
-   4.  DNAME Discussions in Other Documents . . . . . . . . . . . . . 11
-
-   5.  Other Issues with DNAME  . . . . . . . . . . . . . . . . . . . 13
-     5.1.  Canonical hostnames cannot be below DNAME owners . . . . . 13
-     5.2.  Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13
-     5.3.  DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13
-       5.3.1.  Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13
-       5.3.2.  DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14
-       5.3.3.  DNAME Chains as Strong as the Weakest Link . . . . . . 14
-       5.3.4.  Validators Must Understand DNAME . . . . . . . . . . . 14
-         5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error  . . . . 14
-         5.3.4.2.  Valid Name Error Response Involving DNAME in
-                   Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
-         5.3.4.3.  Response With Synthesized CNAME  . . . . . . . . . 15
-
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
-
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
-
-   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
-
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
-     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
-     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010                [Page 3]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-1.  Introduction
-
-   DNAME is a DNS Resource Record type originally defined in RFC 2672
-   [RFC2672].  DNAME provides redirection from a part of the DNS name
-   tree to another part of the DNS name tree.
-
-   The DNAME RR and the CNAME RR [RFC1034] cause a lookup to
-   (potentially) return data corresponding to a domain name different
-   from the queried domain name.  The difference between the two
-   resource records is that the CNAME RR directs the lookup of data at
-   its owner to another single name, a DNAME RR directs lookups for data
-   at descendants of its owner's name to corresponding names under a
-   different (single) node of the tree.
-
-   Take for example, looking through a zone (see RFC 1034 [RFC1034],
-   section 4.3.2, step 3) for the domain name "foo.example.com" and a
-   DNAME resource record is found at "example.com" indicating that all
-   queries under "example.com" be directed to "example.net".  The lookup
-   process will return to step 1 with the new query name of
-   "foo.example.net".  Had the query name been "www.foo.example.com" the
-   new query name would be "www.foo.example.net".
-
-   This document is a revision of the original specification of DNAME in
-   RFC 2672 [RFC2672].  DNAME was conceived to help with the problem of
-   maintaining address-to-name mappings in a context of network
-   renumbering.  With a careful set-up, a renumbering event in the
-   network causes no change to the authoritative server that has the
-   address-to-name mappings.  Examples in practice are classless reverse
-   address space delegations.
-
-   Another usage of DNAME lies in aliasing of name spaces.  For example,
-   a zone administrator may want sub-trees of the DNS to contain the
-   same information.  Examples include punycode alternates for domain
-   spaces.
-
-   This revision to DNAME does not change the wire format or the
-   handling of DNAME Resource Records.  Discussion is added on problems
-   that may be encountered when using DNAME.
-
-2.  The DNAME Resource Record
-
-2.1.  Format
-
-   The DNAME RR has mnemonic DNAME and type code 39 (decimal).  It is
-   not class-sensitive.
-
-
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010                [Page 4]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-   Its RDATA is comprised of a single field, <target>, which contains a
-   fully qualified domain name that must be sent in uncompressed form
-   [RFC1035], [RFC3597].  The <target> field MUST be present.  The
-   presentation format of <target> is that of a domain name [RFC1035].
-
-           <owner> <ttl> <class> DNAME <target>
-
-   The effect of the DNAME RR is the substitution of the record's
-   <target> for its owner name, as a suffix of a domain name.  This
-   substitution is to be applied for all names below the owner name of
-   the DNAME RR.  This substitution has to be applied for every DNAME RR
-   found in the resolution process, which allows fairly lengthy valid
-   chains of DNAME RRs.
-
-   Details of the substitution process, methods to avoid conflicting
-   resource records, and rules for specific corner cases are given in
-   the following subsections.
-
-2.2.  The DNAME Substitution
-
-   When following RFC 1034 [RFC1034], section 4.3.2's algorithm's third
-   step, "start matching down, label by label, in the zone" and a node
-   is found to own a DNAME resource record a DNAME substitution occurs.
-   The name being sought may be the original query name or a name that
-   is the result of a CNAME resource record being followed or a
-   previously encountered DNAME.  As in the case when finding a CNAME
-   resource record or NS resource record set, the processing of a DNAME
-   will happen prior to finding the desired domain name.
-
-   A DNAME substitution is performed by replacing the suffix labels of
-   the name being sought matching the owner name of the DNAME resource
-   record with the string of labels in the RDATA field.  The matching
-   labels end with the root label in all cases.  Only whole labels are
-   replaced.  See the table of examples for common cases and corner
-   cases.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010                [Page 5]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-   In the table below, the QNAME refers to the query name.  The owner is
-   the DNAME owner domain name, and the target refers to the target of
-   the DNAME record.  The result is the resulting name after performing
-   the DNAME substitution on the query name. "no match" means that the
-   query did not match the DNAME and thus no substitution is performed
-   and a possible error message is returned (if no other result is
-   possible).  Thus every line contains one example substitution.  In
-   the examples below, 'cyc' and 'shortloop' contain loops.
-
-    QNAME            owner  DNAME   target         result
-    ---------------- -------------- -------------- -----------------
-    com.             example.com.   example.net.   <no match>
-    example.com.     example.com.   example.net.   [0]
-    a.example.com.   example.com.   example.net.   a.example.net.
-    a.b.example.com. example.com.   example.net.   a.b.example.net.
-    ab.example.com.  b.example.com. example.net.   <no match>
-    foo.example.com. example.com.   example.net.   foo.example.net.
-    a.x.example.com. x.example.com. example.net.   a.example.net.
-    a.example.com.   example.com.   y.example.net. a.y.example.net.
-    cyc.example.com. example.com.   example.com.   cyc.example.com.
-    cyc.example.com. example.com.   c.example.com. cyc.c.example.com.
-    shortloop.x.x.   x.             .              shortloop.x.
-    shortloop.x.     x.             .              shortloop.
-
-   [0] The result depends on the QTYPE.  If the QTYPE = DNAME, then
-       the result is "example.com." else "<no match>"
-
-                   Table 1. DNAME Substitution Examples.
-
-   It is possible for DNAMEs to form loops, just as CNAMEs can form
-   loops.  DNAMEs and CNAMEs can chain together to form loops.  A single
-   corner case DNAME can form a loop.  Resolvers and servers should be
-   cautious in devoting resources to a query, but be aware that fairly
-   long chains of DNAMEs may be valid.  Zone content administrators
-   should take care to insure that there are no loops that could occur
-   when using DNAME or DNAME/CNAME redirection.
-
-   The domain name can get too long during substitution.  For example,
-   suppose the target name of the DNAME RR is 250 octets in length
-   (multiple labels), if an incoming QNAME that has a first label over 5
-   octets in length, the result would be a name over 255 octets.  If
-   this occurs the server returns an RCODE of YXDOMAIN [RFC2136].  The
-   DNAME record and its signature (if the zone is signed) are included
-   in the answer as proof for the YXDOMAIN (value 6) RCODE.
-
-
-
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010                [Page 6]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-2.3.  DNAME Owner Name Matching the QNAME
-
-   Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
-   owner name; the owner name of a DNAME is not redirected itself.  The
-   domain name that owns a DNAME record is allowed to have other
-   resource record types at that domain name, except DNAMEs, CNAMEs or
-   other types that have restrictions on what they can co-exist with.
-   When there is a match of the QTYPE to a type (or types) also owned by
-   the owner name the response is sourced from the owner name.  E.g., a
-   QTYPE of ANY would return the (available) types at the owner name,
-   not the target name.
-
-   DNAME RRs MUST NOT appear at the same owner name as an NS RR unless
-   the owner name is the zone apex as this would constitute data below a
-   zone cut.
-
-   If a DNAME record is present at the zone apex, there is still a need
-   to have the customary SOA and NS resource records there as well.
-   Such a DNAME cannot be used to mirror a zone completely, as it does
-   not mirror the zone apex.
-
-   These rules also allow DNAME records to be queried through RFC 1034
-   [RFC1034] compliant, DNAME-unaware caches.
-
-2.4.  Names Next to and Below a DNAME Record
-
-   Resource records MUST NOT exist at any sub-domain of the owner of a
-   DNAME RR.  To get the contents for names subordinate to that owner
-   name, the DNAME redirection must be invoked and the resulting target
-   queried.  A server MAY refuse to load a zone that has data at a sub-
-   domain of a domain name owning a DNAME RR.  If the server does load
-   the zone, those names below the DNAME RR will be occluded as
-   described in RFC 2136 [RFC2136], section 7.18.  Also a server SHOULD
-   refuse to load a zone subordinate to the owner of a DNAME record in
-   the ancestor zone.  See Section 5.2 for further discussion related to
-   dynamic update.
-
-   DNAME is a singleton type, meaning only one DNAME is allowed per
-   name.  The owner name of a DNAME can only have one DNAME RR, and no
-   CNAME RRs can exist at that name.  These rules make sure that for a
-   single domain name only one redirection exists, and thus no confusion
-   which one to follow.  A server SHOULD refuse to load a zone that
-   violates these rules.
-
-2.5.  Compression of the DNAME record.
-
-   The DNAME owner name can be compressed like any other owner name.
-   The DNAME RDATA target name MUST NOT be sent out in compressed form,
-
-
-
-Rose & Wijngaards       Expires October 22, 2010                [Page 7]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-   so that a DNAME RR can be treated as an unknown type [RFC3597].
-
-   Although the previous DNAME specification [RFC2672] (that is
-   obsoleted by this specification) talked about signaling to allow
-   compression of the target name, such signaling has never been
-   specified and this document also does not specify this signaling
-   behavior.
-
-   RFC 2672 (obsoleted by this document) stated that the EDNS version
-   had a meaning for understanding of DNAME and DNAME target name
-   compression.  This document revises RFC 2672, in that there is no
-   EDNS version signaling for DNAME.
-
-3.  Processing
-
-   The DNAME RR causes type NS additional section processing.  This
-   refers to action at step 6 of the server algorithm outlined in
-   section 3.2.
-
-3.1.  CNAME synthesis
-
-   When preparing a response, a server performing a DNAME substitution
-   will in all cases include the relevant DNAME RR in the answer
-   section.  Relevant includes the following cases:
-
-   1.  The DNAME is being employed as a substitution instruction.
-
-   2.  The DNAME itself matches the QTYPE and the owner name matches
-       QNAME.
-
-   When the owner name name matches the QNAME and the QTYPE matches
-   another type owned there, the DNAME is not included in the answer.
-
-   A CNAME RR with TTL equal to the corresponding DNAME RR is
-   synthesized and included in the answer section when the DNAME is
-   employed as a substitution instruction.  The owner name of the CNAME
-   is the QNAME of the query.  The DNSSEC specification [RFC4033],
-   [RFC4034], [RFC4035] says that the synthesized CNAME does not have to
-   be signed.  The DNAME has an RRSIG and a validating resolver can
-   check the CNAME against the DNAME record and validate the signature
-   over the DNAME RR.
-
-   Servers MUST be able to answer a query for a synthesized CNAME.  Like
-   other query types this invokes the DNAME, and synthesizes the CNAME
-   into the answer.  If the server in question is a cache, the
-   synthesized CNAME's TTL SHOULD be equal to the decremented TTL of the
-   cached DNAME.
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010                [Page 8]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-   Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
-   equal to the TTL of the corresponding DNAME record (as some older
-   authoritative server implementations set the TTL of synthesized
-   CNAMEs to zero).  A TTL of zero means that the CNAME can be discarded
-   immediately after processing the answer.
-
-3.2.  Server algorithm
-
-   Below is the server algorithm, which appeared in RFC 2672 Section
-   4.1.
-
-   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 does not 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 sub-zone 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.
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010                [Page 9]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-       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 [RFC2136] and exit; otherwise
-           perform the substitution and continue.  The server MUST
-           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 or DNAME.  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.  If the data at the node with the "*" label is
-           a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
-           into the answer section of the response changing the owner
-           name to the QNAME, change QNAME to the canonical name in the
-           CNAME RR, and go back to step 1.  Otherwise, 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 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 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.
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010               [Page 10]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-   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.
-
-3.3.  Wildcards
-
-   The use of DNAME in conjunction with wildcards is discouraged
-   [RFC4592].  Thus records of the form "*.example.com DNAME
-   example.net" SHOULD NOT be used.
-
-   The interaction between the expansion of the wildcard and the
-   redirection of the DNAME is non-deterministic.  Because the
-   processing is non-deterministic, DNSSEC validating resolvers may not
-   be able to validate a wildcarded DNAME.
-
-   A server MAY give a warning that the behavior is unspecified if such
-   a wildcarded DNAME is loaded.  The server MAY refuse it, refuse to
-   load the zone or refuse dynamic updates.
-
-3.4.  Acceptance and Intermediate Storage
-
-   Recursive caching name servers can encounter data at names below the
-   owner name of a DNAME RR, due to a change at the authoritative server
-   where data from before and after the change resides in the cache.
-   This conflict situation is a transitional phase that ends when the
-   old data times out.  The caching name server can opt to store both
-   old and new data and treat each as if the other did not exist, or
-   drop the old data, or drop the longer domain name.  In any approach,
-   consistency returns after the older data TTL times out.
-
-   Recursive caching name servers MUST perform CNAME synthesis on behalf
-   of clients.
-
-   If a recursive caching name server encounters a DNAME RR which
-   contradicts information already in the cache (excluding CNAME
-   records), it SHOULD NOT cache the DNAME RR, but it MAY cache the
-   CNAME record received along with it, subject to the rules for CNAME.
-
-4.  DNAME Discussions in Other Documents
-
-   In [RFC2181], in Section 10.3., the discussion on MX and NS records
-   touches on redirection by CNAMEs, but this also holds for DNAMEs.
-
-
-
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010               [Page 11]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-   Excerpt from 10.3.  MX and NS records (in RFC 2181).
-
-           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.
-
-   The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME.
-   The opening premise of this section is demonstrably wrong, and so the
-   conclusion based on that premise is wrong.  In particular, [RFC3363]
-   deprecates the use of DNAME in the IPv6 reverse tree, which is then
-   carried forward as a recommendation in [RFC4294].  Based on the
-   experience gained in the meantime, [RFC3363] should be revised,
-   dropping all constraints on having DNAME RRs in these zones.  This
-   would greatly improve the manageability of the IPv6 reverse tree.
-   These changes are made explicit below.
-
-   In [RFC3363], the paragraph
-
-     "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."
-
-   is to be replaced with the word "DELETED".
-
-   In [RFC4294], the reference to DNAME was left in as an editorial
-   oversight.  The paragraph
-
-     "Those nodes are NOT RECOMMENDED to support the experimental A6 and
-     DNAME Resource Records [RFC3363]."
-
-   is to be replaced by
-
-     "Those nodes are NOT RECOMMENDED to support the experimental
-     A6 Resource Record [RFC3363]."
-
-
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010               [Page 12]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-5.  Other Issues with DNAME
-
-   There are several issues to be aware of about the use of DNAME.
-
-5.1.  Canonical hostnames cannot be below DNAME owners
-
-   The names listed as target names of MX, NS, PTR and SRV [RFC2782]
-   records must be canonical hostnames.  This means no CNAME or DNAME
-   redirection may be present during DNS lookup of the address records
-   for the host.  This is discussed in RFC 2181 [RFC2181], section 10.3,
-   and RFC 1912 [RFC1912], section 2.4.  For SRV see RFC 2782 [RFC2782]
-   page 4.
-
-   The upshot of this is that although the lookup of a PTR record can
-   involve DNAMEs, the name listed in the PTR record can not fall under
-   a DNAME.  The same holds for NS, SRV and MX records.  For example,
-   when punycode alternates for a zone use DNAME then the NS, MX, SRV
-   and PTR records that point to that zone must use names without
-   punycode in their RDATA.  What must be done then is to have the
-   domain names with DNAME substitution already applied to it as the MX,
-   NS, PTR, SRV data.  These are valid canonical hostnames.
-
-5.2.  Dynamic Update and DNAME
-
-   DNAME records can be added, changed and removed in a zone using
-   dynamic update transactions.  Adding a DNAME RR to a zone occludes
-   any domain names that may exist under the added DNAME.
-
-   A server MUST ignore a dynamic update message that attempts to add a
-   non-DNAME/CNAME RR at a name that already has a DNAME RR associated
-   with that name.  Otherwise, replace the DNAME RR with the DNAME (or
-   CNAME) update RR.  This is similar behavior to dynamic updates to an
-   owner name of a CNAME RR [RFC2136].
-
-5.3.  DNSSEC and DNAME
-
-   The following subsections specify the behavior of implementations
-   that understand both DNSSEC and DNAME (synthesis).
-
-5.3.1.  Signed DNAME, Unsigned Synthesized CNAME
-
-   In any response, a signed DNAME RR indicates a non-terminal
-   redirection of the query.  There might or might not be a server
-   synthesized CNAME in the answer section; if there is, the CNAME will
-   never be signed.  For a DNSSEC validator, verification of the DNAME
-   RR and then checking that the CNAME was properly synthesized is
-   sufficient proof.
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010               [Page 13]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-5.3.2.  DNAME Bit in NSEC Type Map
-
-   In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
-   map SHOULD be checked to see that there was no DNAME that could have
-   been applied.  If the DNAME bit in the type bit map is set and the
-   query name is a sub-domain of the closest encloser that is asserted,
-   then DNAME substitution should have been done, but the substitution
-   has not been done as specified.
-
-5.3.3.  DNAME Chains as Strong as the Weakest Link
-
-   A response can contain a chain of DNAME and CNAME redirections.  That
-   chain can end in a positive answer or a negative (no name error or no
-   data error) reply.  Each step in that chain results in resource
-   records added to the answer or authority section of the response.
-   Only if all steps are secure can the AD bit be set for the response.
-   If one of the steps is bogus, the result is bogus.
-
-5.3.4.  Validators Must Understand DNAME
-
-   Below are examples of why DNSSEC validators MUST understand DNAME.
-   In the examples below, SOA records, wildcard denial NSECs and other
-   material not under discussion has been omitted or shortened.
-
-5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error
-
-   ;; Header: QR AA RCODE=3(NXDOMAIN)
-   ;; OPT PSEUDOSECTION:
-   ; EDNS: version: 0, flags: do; udp: 4096
-
-   ;; Question
-   foo.bar.example.com. IN A
-   ;; Authority
-   bar.example.com. NSEC dub.example.com. A DNAME
-   bar.example.com. RRSIG NSEC [valid signature]
-
-   If this is the received response, then only by understanding that the
-   DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to
-   have been redirected by the DNAME, the validator can see that it is a
-   BOGUS reply from an attacker that collated existing records from the
-   DNS to create a confusing reply.
-
-   If the DNAME bit had not been set in the NSEC record above then the
-   answer would have validated as a correct name error response.
-
-
-
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010               [Page 14]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-5.3.4.2.  Valid Name Error Response Involving DNAME in Bitmap
-
-   ;; Header: QR AA RCODE=3(NXDOMAIN)
-   ;; OPT PSEUDOSECTION:
-   ; EDNS: version: 0, flags: do; udp: 4096
-
-   ;; Question
-   cee.example.com. IN A
-   ;; Authority
-   bar.example.com. NSEC dub.example.com. A DNAME
-   bar.example.com. RRSIG NSEC [valid signature]
-
-   This response has the same NSEC records as the example above, but
-   with this query name (cee.example.com), the answer is validated,
-   because 'cee' does not get redirected by the DNAME at 'bar'.
-
-5.3.4.3.  Response With Synthesized CNAME
-
-   ;; Header: QR AA RCODE=0(NOERROR)
-   ;; OPT PSEUDOSECTION:
-   ; EDNS: version: 0, flags: do; udp: 4096
-
-   ;; Question
-   foo.bar.example.com. IN A
-   ;; Answer
-   bar.example.com. DNAME bar.example.net.
-   bar.example.com. RRSIG DNAME [valid signature]
-   foo.bar.example.com. CNAME foo.bar.example.net.
-
-   The response shown above has the synthesized CNAME included.
-   However, the CNAME has no signature, since the server does not sign
-   online.  So this response cannot be trusted.  It could be altered by
-   an attacker to be foo.bar.example.com CNAME bla.bla.example.  The
-   DNAME record does have its signature included, since it does not
-   change.  The validator must verify the DNAME signature and then
-   recursively resolve further to query for the foo.bar.example.net A
-   record.
-
-6.  IANA Considerations
-
-   The DNAME Resource Record type code 39 (decimal) originally has been
-   registered by [RFC2672].  IANA should update the DNS resource record
-   registry to point to this document for RR type 39.
-
-7.  Security Considerations
-
-   DNAME redirects queries elsewhere, which may impact security based on
-   policy and the security status of the zone with the DNAME and the
-
-
-
-Rose & Wijngaards       Expires October 22, 2010               [Page 15]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-   redirection zone's security status.  For validating resolvers, the
-   lowest security status of the links in the chain of CNAME and DNAME
-   redirections is applied to the result.
-
-   If a validating resolver accepts wildcarded DNAMEs, this creates
-   security issues.  Since the processing of a wildcarded DNAME is non-
-   deterministic and the CNAME that was substituted by the server has no
-   signature, the resolver may choose a different result than what the
-   server meant, and consequently end up at the wrong destination.  Use
-   of wildcarded DNAMEs is discouraged in any case [RFC4592].
-
-   A validating resolver MUST understand DNAME, according to [RFC4034].
-   The examples in Section 5.3.4 illustrate this need.
-
-8.  Acknowledgments
-
-   The authors of this draft would like to acknowledge Matt Larson for
-   beginning this effort to address the issues related to the DNAME RR
-   type.  The authors would also like to acknowledge Paul Vixie, Ed
-   Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred
-   Hoenes and Kevin Darcy for their review and comments on this
-   document.
-
-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.
-
-   [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.
-
-   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-              specifying the location of services (DNS SRV)", RFC 2782,
-              February 2000.
-
-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
-
-
-
-Rose & Wijngaards       Expires October 22, 2010               [Page 16]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-              (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.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
-              System", RFC 4592, July 2006.
-
-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-              Security (DNSSEC) Hashed Authenticated Denial of
-              Existence", RFC 5155, March 2008.
-
-9.2.  Informative References
-
-   [RFC1912]  Barr, D., "Common DNS Operational and Configuration
-              Errors", RFC 1912, February 1996.
-
-   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
-              RFC 2672, August 1999.
-
-   [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.
-
-   [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,
-              April 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010               [Page 17]
-
-Internet-Draft              DNAME Redirection                 April 2010
-
-
-Authors' Addresses
-
-   Scott Rose
-   NIST
-   100 Bureau Dr.
-   Gaithersburg, MD  20899
-   USA
-
-   Phone: +1-301-975-8439
-   Fax:   +1-301-975-6238
-   EMail: scottr.nist@gmail.com
-
-
-   Wouter Wijngaards
-   NLnet Labs
-   Science Park 140
-   Amsterdam  1098 XG
-   The Netherlands
-
-   Phone: +31-20-888-4551
-   EMail: wouter@nlnetlabs.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards       Expires October 22, 2010               [Page 18]
-
diff --git a/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt b/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt
deleted file mode 100644
index b5877705..00000000
--- a/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                             A. Gustafsson
-                                          Araneus Information Systems Oy
-                                                       February 24, 2010
-
-Intended status: Draft Standard
-Obsoletes: RFC3597
-
-           Handling of Unknown DNS Resource Record (RR) Types
-                  draft-ietf-dnsext-rfc3597-bis-02.txt
-
-Abstract
-
-   Extending the Domain Name System (DNS) with new Resource Record (RR)
-   types should not requires changes to name server software.  This
-   document specifies how new RR types are transparently handled by DNS
-   software.
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that other
-   groups may also distribute working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document. Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document. Code Components extracted from this document must
-
-
-
-Expires August 2010          Standards Track                    [Page 1]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-1.  Introduction
-
-   The DNS [RFC1034] is designed to be extensible to support new
-   services through the introduction of new resource record (RR) types.
-   Nevertheless, DNS implementations have historically required software
-   changes to support new RR types, not only at the authoritative DNS
-   server 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 DNS software is slow and expensive,
-   this has been a significant impediment to supporting new services in
-   the DNS.
-
-   [RFC3597] defined DNS implementation behavior and procedures for
-   defining new RR types aimed at simplifying the deployment of new RR
-   types by allowing them to be treated transparently by existing
-   implementations.  Thanks to the widespread adoption of that
-   specification, much of the DNS is now capable of handling new record
-   types without software changes.  Another development that has
-   simplified the introduction of new DNS RR types is the adoption of a
-   simpler IANA allocation procedure for RR types [RFC5395].
-
-   This document is a self-contained revised specification supplanting
-   and obsoleting RFC 3597, with the aim of allowing the specification
-   to advance on the Standards Track.
-
-2.  Definitions
-
-   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].
-
-   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 [RFC5395] (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 known to be 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
-
-
-
-Expires August 2010          Standards Track                    [Page 2]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-   To enable new RR types to be deployed without server changes, name
-   servers and resolvers MUST handle RRs of unknown type transparently.
-   The RDATA section of RRs of unknown type must be treated as
-   unstructured binary data, and must be stored and transmitted without
-   change ([RFC1123], section 6.1.3.5).
-
-   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 document.  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".
-
-   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, SRV, and NAPTR to ensure interoperability with implementations
-   predating [RFC3597].
-
-   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,
-
-
-
-Expires August 2010          Standards Track                    [Page 3]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-   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] section 5.1 to both be unambiguously parsed.
-
-   The RDATA section of an RR of unknown type is represented as a
-   sequence of items separated by any combination of tabs and spaces, 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 items of hexadecimal data encoding the actual RDATA
-       field, each item 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.
-
-   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 )
-
-
-
-Expires August 2010          Standards Track                    [Page 4]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-      b.example.   HS          TYPE62347       \# 0
-      e.example.   IN          A               \# 4 C0000201
-      e.example.   CLASS1      TYPE1           192.0.2.1
-
-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.
-
-7.  DNSSEC Considerations
-
-   The rules for the DNSSEC canonical form and ordering were updated to
-   support transparent treatment of unknown types in [RFC3597].  Those
-   updates have subsequently been integrated into the base DNSSEC
-   specification, such that the DNSSEC canonical form and ordering are
-   now specified in [RFC4034] or its successors rather than in this
-   document.
-
-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.
-
-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.
-
-
-
-
-Expires August 2010          Standards Track                    [Page 5]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-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.
-
-   [RFC5395]   Eastlake, D., "Domain Name System (DNS) IANA
-               Considerations", BCP 42, RFC 5395, November 2008.
-
-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.
-
-   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
-               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-               RFC 2136, April 1997.
-
-   [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.
-
-14.  Author's Address
-
-   Andreas Gustafsson
-   Araneus Information Systems Oy
-   PL 110
-   02321 Espoo
-   Finland
-
-   Phone: +358 40 547 2099
-   EMail: gson@araneus.fi
-
-Appendix A. Summary of Changes Since RFC3597
-
-   This section summarizes the major changes between RFC3597 and this
-
-
-
-Expires August 2010          Standards Track                    [Page 6]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-   document.  In addition to the changes listed below, there has also
-   been a number of editorial changes, such as updates to the text in
-   the Abstract and Introduction to better reflect the current state of
-   implementation, updates to boilerplate text, and minor
-   clarifications.
-
-   The reference to the DNS IANA Considerations BCP (BCP42) has been
-   changed from RFC2929 to the current version, RFC5395.
-
-   Downward references have been eliminated; specifically, the document
-   no longer refers to RFC2163 or RFC2535.
-
-   IP addresses in examples have been changed to use the 192.0.2.0/24
-   range per RFC3330.
-
-   The document no longer specifies changes to the DNSSEC canonical form
-   and ordering, as those changes have now been incorporated into the
-   base DNSSEC specification.
-
-Appendix B. Detailed Change Log
-
-   [NOTE TO RFC EDITOR:  PLEASE REMOVE THIS APPENDIX ON PUBLICATION.]
-
-B.1.  Changes between RFC3597 and -00
-
-   The reference to the DNS IANA Considerations BCP (BCP42) has been
-   changed from RFC2929 to the current version, RFC5395.
-
-   Downward references have been eliminated; specifically, the document
-   no longer refers to RFC2163 or RFC2535.
-
-   IP addresses in examples have been changed to use the 192.0.2.0/24
-   range per RFC3330.
-
-   The document no longer specifies changes to the DNSSEC canonical form
-   and ordering, as those changes have now been incorporated into the
-   base DNSSEC specification.
-
-   There has also been a number of editorial changes, such as updates to
-   the text in the Abstract and Introduction to better reflect the
-   current state of implementation.
-
-B.2.  Changes between -00 and -01
-
-   Moved the Abstract to immediately following the document title.
-
-   Updated boilerplate to the current version.
-
-
-
-
-Expires August 2010          Standards Track                    [Page 7]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-   In the Introduction, the text "Another development that has
-   simplified the introduction of new DNS RR types is the adoption of a
-   simpler IANA allocation procedure for RR types" and a reference to
-   [RFC5395] were added.
-
-   In the Introduction, the text "with the aim of allowing the
-   specification to advance on the Standards Track" was added to explain
-   the motivation for the draft.
-
-   In section 2, the text "is class specific" was replaced by "is known
-   to be class specific".
-
-   In section 3, the words "That is" were removed so as not to imply
-   that the transparent treatment of RRs of unknown type is only a
-   matter of how the RDATA field is handled.  The remainder of the
-   sentence was rephrased.
-
-   In section 4, the entries for SRV and NAPTR in the list of RR types
-   to decompress were swapped to make the list consistently ordered by
-   ascending numerical RR type.
-
-   References to RFC 1035 and RFC 1123 now include the specific section
-   numbers being referenced.
-
-   A Change History was added as Appendix A.
-
-B.3. Changes between -01 and -02
-
-   In section 5, the term "white space" was replaced by "any combination
-   of tabs and spaces", and the term "word" was replaced by "item", for
-   consistency with RFC1035 terminology.
-
-   In section 5, hyphens were added to mark the beginning of each item
-   in the the list of items comprising the RDATA text representation.
-
-   The Change History was split into a Summary of Changes Since RFC3597
-   (Appendix A) intended to remain in the document when published as an
-   RFC, and a Detailed Change Log (Appendix B) to be deleted on
-   publication.
-
-
-
-
-
-
-
-
-
-
-
-
-Expires August 2010          Standards Track                    [Page 8]
-
diff --git a/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt b/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt
deleted file mode 100644
index 72d38aa2..00000000
--- a/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt
+++ /dev/null
@@ -1,336 +0,0 @@
-
-
-
-DNSext Working Group                                           F. Dupont
-Internet-Draft                                                       ISC
-Updates: 2845,2930,4635                                      May 8, 2009
-(if approved)
-Intended status: Standards Track
-Expires: November 9, 2009
-
-
-     Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records
-              draft-ietf-dnsext-tsig-md5-deprecated-03.txt
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.  This document may contain material
-   from IETF Documents or IETF Contributions published or made publicly
-   available before November 10, 2008.  The person(s) controlling the
-   copyright in some of this material may not have granted the IETF
-   Trust the right to allow modifications of such material outside the
-   IETF Standards Process.  Without obtaining an adequate license from
-   the person(s) controlling the copyright in such materials, this
-   document may not be modified outside the IETF Standards Process, and
-   derivative works of it may not be created outside the IETF Standards
-   Process, except to format it for publication as an RFC or to
-   translate it into languages other than English.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on November 9, 2009.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-
-
-Dupont                  Expires November 9, 2009                [Page 1]
-
-Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
-
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   The main purpose of this document is to deprecate the use of HMAC-MD5
-   as an algorithm for the TSIG (secret key transaction authentication)
-   resource record in the DNS (domain name system), and the use of MD5
-   in TKEY (secret key establishment for DNS).
-
-
-1.  Introduction
-
-   The secret key transaction authentication for DNS (TSIG, [RFC2845])
-   was defined with the HMAC-MD5 [RFC2104] cryptographic algorithm.
-   When the MD5 [RFC1321] security came to be considered lower than
-   expected, [RFC4635] standardized new TSIG algorithms based on SHA
-   [RFC3174][RFC3874][RFC4634] digests.
-
-   But [RFC4635] did not deprecate the HMAC-MD5 algorithm.  This
-   document is targeted to complete the process, in detail:
-   1.  Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm
-       name registry managed by the IANA under the IETF Review Policy
-       [RFC5226]
-   2.  Make HMAC-MD5.SIG-ALG.REG.INT support "not Mandatory" for
-       implementations
-   3.  Provide a keying material derivation for the secret key
-       establishment for DNS (TKEY, [RFC2930]) using a Diffie-Hellman
-       exchange with SHA256 [RFC4634] in place of MD5 [RFC1321]
-   4.  Finally recommend the use of HMAC-SHA256.
-
-   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.  Implementation Requirements
-
-   The table of section 3 of [RFC4635] is replaced by:
-
-
-
-
-
-
-
-
-
-Dupont                  Expires November 9, 2009                [Page 2]
-
-Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
-
-
-             +-------------------+--------------------------+
-             | Requirement Level | Algorithm Name           |
-             +-------------------+--------------------------+
-             | Optional          | HMAC-MD5.SIG-ALG.REG.INT |
-             | Optional          | gss-tsig                 |
-             | Mandatory         | hmac-sha1                |
-             | Optional          | hmac-sha224              |
-             | Mandatory         | hmac-sha256              |
-             | Optional          | hmac-sha384              |
-             | Optional          | hmac-sha512              |
-             +-------------------+--------------------------+
-
-   Implementations that support TSIG MUST also implement HMAC-SHA1 and
-   HMAC-SHA256 (i.e., algorithms at the "Mandatory" requirement level)
-   and MAY implement GSS-TSIG and the other algorithms listed above
-   (i.e., algorithms at a "not Mandatory" requirement level).
-
-
-3.  TKEY keying material derivation
-
-   When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying
-   material is derived from the shared secret and TKEY resource record
-   data using MD5 [RFC1321] at the end of section 4.1 page 9.
-
-   This is amended into:
-
-         keying material =
-              XOR ( DH value, SHA256 ( query data | DH value ) |
-                              SHA256 ( server data | DH value ) )
-
-   using the same conventions.
-
-
-4.  IANA Consideration
-
-   This document extends the "TSIG Algorithm Names - per [] and
-   [RFC2845]" located at
-   http://www.iana.org/assignments/tsig-algorithm-names by adding a new
-   column to the registry "Compliance Requirement".
-
-   The registry should contain the following:
-
-
-
-
-
-
-
-
-
-
-Dupont                  Expires November 9, 2009                [Page 3]
-
-Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
-
-
-    +--------------------------+------------------------+-------------+
-    | Algorithm Name           | Compliance Requirement | Reference   |
-    +--------------------------+------------------------+-------------+
-    | gss-tsig                 | Optional               | [RFC3645]   |
-    | HMAC-MD5.SIG-ALG.REG.INT | Optional               | [][RFC2845] |
-    | hmac-sha1                | Mandatory              | [RFC4635]   |
-    | hmac-sha224              | Optional               | [RFC4635]   |
-    | hmac-sha256              | Mandatory              | [RFC4635]   |
-    | hmac-sha384              | Optional               | [RFC4635]   |
-    | hmac-sha512              | Optional               | [RFC4635]   |
-    +--------------------------+------------------------+-------------+
-
-   where [] is this document.
-
-
-5.  Availability Considerations
-
-   MD5 is no longer universally available and its use may lead to
-   increasing operation issues.  SHA1 is likely to suffer from the same
-   kind of problem.  In summary MD5 has reached end-of-life and SHA1
-   will likely follow in the near term.
-
-   According to [RFC4635], implementations which support TSIG are
-   REQUIRED to implement HMAC-SHA256.
-
-
-6.  Security Considerations
-
-   This document does not assume anything about the cryptographic
-   security of different hash algorithms.  Its purpose is a better
-   availability of some security mechanisms in a predictable time frame.
-
-   Requirement levels are adjusted for TSIG and related specifications
-   (i.e., TKEY):
-      The support of HMAC-MD5 is changed from mandatory to optional.
-      The use of MD5 and HMAC-MD5 is NOT RECOMMENDED.
-      The use of HMAC-SHA256 is RECOMMENDED.
-
-
-7.  Acknowledgments
-
-   Olafur Gudmundsson kindly helped in the procedure to deprecate the
-   MD5 use in TSIG, i.e., the procedure which led to this memo.  Alfred
-   Hoenes, Peter Koch, Paul Hoffman and Edward Lewis proposed some
-   improvements.
-
-
-8.  References
-
-
-
-Dupont                  Expires November 9, 2009                [Page 4]
-
-Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
-
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, BCP 14, March 1997.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
-              RR)", RFC 2930, September 2000.
-
-   [RFC4635]  Eastlake, D., "HMAC SHA TSIG Algorithm Identifiers",
-              RFC 4635, August 2006.
-
-8.2.  Informative References
-
-   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-              April 1992.
-
-   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
-              (SHA1)", RFC 3174, September 2001.
-
-   [RFC3645]  Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
-              and R. Hall, "Generic Security Service Algorithm for
-              Secret Key Transaction Authentication for DNS (GSS-TSIG)",
-              RFC 3645, October 2003.
-
-   [RFC3874]  Housley, R., "A 224-bit One-way Hash Function: SHA-224",
-              RFC 3874, September 2004.
-
-   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
-              (SHA and HMAC-SHA)", RFC 4634, July 2006.
-
-   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", RFC 5226, BCP 26,
-              May 2008.
-
-
-
-
-
-
-
-
-
-
-Dupont                  Expires November 9, 2009                [Page 5]
-
-Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
-
-
-Author's Address
-
-   Francis Dupont
-   ISC
-
-   Email: Francis.Dupont@fdupont.fr
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dupont                  Expires November 9, 2009                [Page 6]
-
diff --git a/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
deleted file mode 100644
index 0855ba35..00000000
--- a/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-
-DNS Operations                                                 M. Larson
-Internet-Draft                                                 P. Barber
-Expires: August 14, 2006                                        VeriSign
-                                                       February 10, 2006
-
-
-                  Observed DNS Resolution Misbehavior
-                    draft-ietf-dnsop-bad-dns-res-05
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 14, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This memo describes DNS iterative resolver behavior that results in a
-   significant query volume sent to the root and top-level domain (TLD)
-   name servers.  We offer implementation advice to iterative resolver
-   developers to alleviate these unnecessary queries.  The
-   recommendations made in this document are a direct byproduct of
-   observation and analysis of abnormal query traffic patterns seen at
-   two of the thirteen root name servers and all thirteen com/net TLD
-   name servers.
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 1]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [1].
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  A note about terminology in this memo  . . . . . . . . . .  3
-   2.  Observed iterative resolver misbehavior  . . . . . . . . . . .  5
-     2.1.  Aggressive requerying for delegation information . . . . .  5
-       2.1.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  6
-     2.2.  Repeated queries to lame servers . . . . . . . . . . . . .  7
-       2.2.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  7
-     2.3.  Inability to follow multiple levels of indirection . . . .  8
-       2.3.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  9
-     2.4.  Aggressive retransmission when fetching glue . . . . . . .  9
-       2.4.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 10
-     2.5.  Aggressive retransmission behind firewalls . . . . . . . . 10
-       2.5.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 11
-     2.6.  Misconfigured NS records . . . . . . . . . . . . . . . . . 11
-       2.6.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 12
-     2.7.  Name server records with zero TTL  . . . . . . . . . . . . 12
-       2.7.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 13
-     2.8.  Unnecessary dynamic update messages  . . . . . . . . . . . 13
-       2.8.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 14
-     2.9.  Queries for domain names resembling IPv4 addresses . . . . 14
-       2.9.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 14
-     2.10. Misdirected recursive queries  . . . . . . . . . . . . . . 15
-       2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15
-     2.11. Suboptimal name server selection algorithm . . . . . . . . 15
-       2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16
-   3.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
-   4.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 18
-   5.  Security considerations  . . . . . . . . . . . . . . . . . . . 19
-   6.  Internationalization considerations  . . . . . . . . . . . . . 20
-   7.  Informative References . . . . . . . . . . . . . . . . . . . . 20
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
-   Intellectual Property and Copyright Statements . . . . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 2]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-1.  Introduction
-
-   Observation of query traffic received by two root name servers and
-   the thirteen com/net TLD name servers has revealed that a large
-   proportion of the total traffic often consists of "requeries".  A
-   requery is the same question (<QNAME, QTYPE, QCLASS>) asked
-   repeatedly at an unexpectedly high rate.  We have observed requeries
-   from both a single IP address and multiple IP addresses (i.e., the
-   same query received simultaneously from multiple IP addresses).
-
-   By analyzing requery events we have found that the cause of the
-   duplicate traffic is almost always a deficient iterative resolver,
-   stub resolver or application implementation combined with an
-   operational anomaly.  The implementation deficiencies we have
-   identified to date include well-intentioned recovery attempts gone
-   awry, insufficient caching of failures, early abort when multiple
-   levels of indirection must be followed, and aggressive retry by stub
-   resolvers or applications.  Anomalies that we have seen trigger
-   requery events include lame delegations, unusual glue records, and
-   anything that makes all authoritative name servers for a zone
-   unreachable (DoS attacks, crashes, maintenance, routing failures,
-   congestion, etc.).
-
-   In the following sections, we provide a detailed explanation of the
-   observed behavior and recommend changes that will reduce the requery
-   rate.  None of the changes recommended affects the core DNS protocol
-   specification; instead, this document consists of guidelines to
-   implementors of iterative resolvers.
-
-1.1.  A note about terminology in this memo
-
-   To recast an old saying about standards, the nice thing about DNS
-   terms is that there are so many of them to choose from.  Writing or
-   talking about DNS can be difficult and cause confusion resulting from
-   a lack of agreed-upon terms for its various components.  Further
-   complicating matters are implementations that combine multiple roles
-   into one piece of software, which makes naming the result
-   problematic.  An example is the entity that accepts recursive
-   queries, issues iterative queries as necessary to resolve the initial
-   recursive query, caches responses it receives, and which is also able
-   to answer questions about certain zones authoritatively.  This entity
-   is an iterative resolver combined with an authoritative name server
-   and is often called a "recursive name server" or a "caching name
-   server".
-
-   This memo is concerned principally with the behavior of iterative
-   resolvers, which are typically found as part of a recursive name
-   server.  This memo uses the more precise term "iterative resolver",
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 3]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   because the focus is usually on that component.  In instances where
-   the name server role of this entity requires mentioning, this memo
-   uses the term "recursive name server".  As an example of the
-   difference, the name server component of a recursive name server
-   receives DNS queries and the iterative resolver component sends
-   queries.
-
-   The advent of IPv6 requires mentioning AAAA records as well as A
-   records when discussing glue.  To avoid continuous repetition and
-   qualification, this memo uses the general term "address record" to
-   encompass both A and AAAA records when a particular situation is
-   relevant to both types.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 4]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-2.  Observed iterative resolver misbehavior
-
-2.1.  Aggressive requerying for delegation information
-
-   There can be times when every name server in a zone's NS RRset is
-   unreachable (e.g., during a network outage), unavailable (e.g., the
-   name server process is not running on the server host) or
-   misconfigured (e.g., the name server is not authoritative for the
-   given zone, also known as "lame").  Consider an iterative resolver
-   that attempts to resolve a query for a domain name in such a zone and
-   discovers that none of the zone's name servers can provide an answer.
-   We have observed a recursive name server implementation whose
-   iterative resolver then verifies the zone's NS RRset in its cache by
-   querying for the zone's delegation information: it sends a query for
-   the zone's NS RRset to one of the parent zone's name servers.  (Note
-   that queries with QTYPE=NS are not required by the standard
-   resolution algorithm described in section 4.3.2 of RFC 1034 [2].
-   These NS queries represent this implementation's addition to that
-   algorithm.)
-
-   For example, suppose that "example.com" has the following NS RRset:
-
-     example.com.   IN   NS   ns1.example.com.
-     example.com.   IN   NS   ns2.example.com.
-
-   Upon receipt of a query for "www.example.com" and assuming that
-   neither "ns1.example.com" nor "ns2.example.com" can provide an
-   answer, this iterative resolver implementation immediately queries a
-   "com" zone name server for the "example.com" NS RRset to verify it
-   has the proper delegation information.  This implementation performs
-   this query to a zone's parent zone for each recursive query it
-   receives that fails because of a completely unresponsive set of name
-   servers for the target zone.  Consider the effect when a popular zone
-   experiences a catastrophic failure of all its name servers: now every
-   recursive query for domain names in that zone sent to this recursive
-   name server implementation results in a query to the failed zone's
-   parent name servers.  On one occasion when several dozen popular
-   zones became unreachable, the query load on the com/net name servers
-   increased by 50%.
-
-   We believe this verification query is not reasonable.  Consider the
-   circumstances: When an iterative resolver is resolving a query for a
-   domain name in a zone it has not previously searched, it uses the
-   list of name servers in the referral from the target zone's parent.
-   If on its first attempt to search the target zone, none of the name
-   servers in the referral is reachable, a verification query to the
-   parent would be pointless: this query to the parent would come so
-   quickly on the heels of the referral that it would be almost certain
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 5]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   to contain the same list of name servers.  The chance of discovering
-   any new information is slim.
-
-   The other possibility is that the iterative resolver successfully
-   contacts one of the target zone's name servers and then caches the NS
-   RRset from the authority section of a response, the proper behavior
-   according to section 5.4.1 of RFC 2181 [3], because the NS RRset from
-   the target zone is more trustworthy than delegation information from
-   the parent zone.  If, while processing a subsequent recursive query,
-   the iterative resolver discovers that none of the name servers
-   specified in the cached NS RRset is available or authoritative,
-   querying the parent would be wrong.  An NS RRset from the parent zone
-   would now be less trustworthy than data already in the cache.
-
-   For this query of the parent zone to be useful, the target zone's
-   entire set of name servers would have to change AND the former set of
-   name servers would have to be deconfigured or decommissioned AND the
-   delegation information in the parent zone would have to be updated
-   with the new set of name servers, all within the TTL of the target
-   zone's NS RRset.  We believe this scenario is uncommon:
-   administrative best practices dictate that changes to a zone's set of
-   name servers happen gradually when at all possible, with servers
-   removed from the NS RRset left authoritative for the zone as long as
-   possible.  The scenarios that we can envision that would benefit from
-   the parent requery behavior do not outweigh its damaging effects.
-
-   This section should not be understood to claim that all queries to a
-   zone's parent are bad.  In some cases, such queries are not only
-   reasonable but required.  Consider the situation when required
-   information, such as the address of a name server (i.e., the address
-   record corresponding to the RDATA of an NS record), has timed out of
-   an iterative resolver's cache before the corresponding NS record.  If
-   the name of the name server is below the apex of the zone, then the
-   name server's address record is only available as glue in the parent
-   zone.  For example, consider this NS record:
-
-     example.com.        IN   NS   ns.example.com.
-
-   If a cache has this NS record but not the address record for
-   "ns.example.com", it is unable to contact the "example.com" zone
-   directly and must query the "com" zone to obtain the address record.
-   Note, however, that such a query would not have QTYPE=NS according to
-   the standard resolution algorithm.
-
-2.1.1.  Recommendation
-
-   An iterative resolver MUST NOT send a query for the NS RRset of a
-   non-responsive zone to any of the name servers for that zone's parent
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 6]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   zone.  For the purposes of this injunction, a non-responsive zone is
-   defined as a zone for which every name server listed in the zone's NS
-   RRset:
-
-   1.  is not authoritative for the zone (i.e., lame), or,
-
-   2.  returns a server failure response (RCODE=2), or,
-
-   3.  is dead or unreachable according to section 7.2 of RFC 2308 [4].
-
-2.2.  Repeated queries to lame servers
-
-   Section 2.1 describes a catastrophic failure: when every name server
-   for a zone is unable to provide an answer for one reason or another.
-   A more common occurrence is when a subset of a zone's name servers
-   are unavailable or misconfigured.  Different failure modes have
-   different expected durations.  Some symptoms indicate problems that
-   are potentially transient; for example, various types of ICMP
-   unreachable messages because a name server process is not running or
-   a host or network is unreachable, or a complete lack of a response to
-   a query.  Such responses could be the result of a host rebooting or
-   temporary outages; these events don't necessarily require any human
-   intervention and can be reasonably expected to be temporary.
-
-   Other symptoms clearly indicate a condition requiring human
-   intervention, such as lame server: if a name server is misconfigured
-   and not authoritative for a zone delegated to it, it is reasonable to
-   assume that this condition has potential to last longer than
-   unreachability or unresponsiveness.  Consequently, repeated queries
-   to known lame servers are not useful.  In this case of a condition
-   with potential to persist for a long time, a better practice would be
-   to maintain a list of known lame servers and avoid querying them
-   repeatedly in a short interval.
-
-   It should also be noted, however, that some authoritative name server
-   implementations appear to be lame only for queries of certain types
-   as described in RFC 4074 [5].  In this case, it makes sense to retry
-   the "lame" servers for other types of queries, particularly when all
-   known authoritative name servers appear to be "lame".
-
-2.2.1.  Recommendation
-
-   Iterative resolvers SHOULD cache name servers that they discover are
-   not authoritative for zones delegated to them (i.e. lame servers).
-   If this caching is performed, lame servers MUST be cached against the
-   specific query tuple <zone name, class, server IP address>.  Zone
-   name can be derived from the owner name of the NS record that was
-   referenced to query the name server that was discovered to be lame.
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 7]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   Implementations that perform lame server caching MUST refrain from
-   sending queries to known lame servers based on a time interval from
-   when the server is discovered to be lame.  A minimum interval of
-   thirty minutes is RECOMMENDED.
-
-   An exception to this recommendation occurs if all name servers for a
-   zone are marked lame.  In that case, the iterative resolver SHOULD
-   temporarily ignore the servers' lameness status and query one or more
-   servers.  This behavior is a workaround for the type-specific
-   lameness issue described in the previous section.
-
-   Implementors should take care not to make lame server avoidance logic
-   overly broad: note that a name server could be lame for a parent zone
-   but not a child zone, e.g., lame for "example.com" but properly
-   authoritative for "sub.example.com".  Therefore a name server should
-   not be automatically considered lame for subzones.  In the case
-   above, even if a name server is known to be lame for "example.com",
-   it should be queried for QNAMEs at or below "sub.example.com" if an
-   NS record indicates it should be authoritative for that zone.
-
-2.3.  Inability to follow multiple levels of indirection
-
-   Some iterative resolver implementations are unable to follow
-   sufficient levels of indirection.  For example, consider the
-   following delegations:
-
-     foo.example.        IN   NS   ns1.example.com.
-     foo.example.        IN   NS   ns2.example.com.
-
-     example.com.        IN   NS   ns1.test.example.net.
-     example.com.        IN   NS   ns2.test.example.net.
-
-     test.example.net.   IN   NS   ns1.test.example.net.
-     test.example.net.   IN   NS   ns2.test.example.net.
-
-   An iterative resolver resolving the name "www.foo.example" must
-   follow two levels of indirection, first obtaining address records for
-   "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
-   address records for "ns1.example.com" or "ns2.example.com" in order
-   to query those name servers for the address records of
-   "www.foo.example".  While this situation may appear contrived, we
-   have seen multiple similar occurrences and expect more as new generic
-   top-level domains (gTLDs) become active.  We anticipate many zones in
-   new gTLDs will use name servers in existing gTLDs, increasing the
-   number of delegations using out-of-zone name servers.
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 8]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-2.3.1.  Recommendation
-
-   Clearly constructing a delegation that relies on multiple levels of
-   indirection is not a good administrative practice.  However, the
-   practice is widespread enough to require that iterative resolvers be
-   able to cope with it.  Iterative resolvers SHOULD be able to handle
-   arbitrary levels of indirection resulting from out-of-zone name
-   servers.  Iterative resolvers SHOULD implement a level-of-effort
-   counter to avoid loops or otherwise performing too much work in
-   resolving pathological cases.
-
-   A best practice that avoids this entire issue of indirection is to
-   name one or more of a zone's name servers in the zone itself.  For
-   example, if the zone is named "example.com", consider naming some of
-   the name servers "ns{1,2,...}.example.com" (or similar).
-
-2.4.  Aggressive retransmission when fetching glue
-
-   When an authoritative name server responds with a referral, it
-   includes NS records in the authority section of the response.
-   According to the algorithm in section 4.3.2 of RFC 1034 [2], the name
-   server should also "put whatever addresses are available into the
-   additional section, using glue RRs if the addresses are not available
-   from authoritative data or the cache."  Some name server
-   implementations take this address inclusion a step further with a
-   feature called "glue fetching".  A name server that implements glue
-   fetching attempts to include address records for every NS record in
-   the authority section.  If necessary, the name server issues multiple
-   queries of its own to obtain any missing address records.
-
-   Problems with glue fetching can arise in the context of
-   "authoritative-only" name servers, which only serve authoritative
-   data and ignore requests for recursion.  Such an entity will not
-   normally generate any queries of its own.  Instead it answers non-
-   recursive queries from iterative resolvers looking for information in
-   zones it serves.  With glue fetching enabled, however, an
-   authoritative server invokes an iterative resolver to look up an
-   unknown address record to complete the additional section of a
-   response.
-
-   We have observed situations where the iterative resolver of a glue-
-   fetching name server can send queries that reach other name servers,
-   but is apparently prevented from receiving the responses.  For
-   example, perhaps the name server is authoritative-only and therefore
-   its administrators expect it to receive only queries and not
-   responses.  Perhaps unaware of glue fetching and presuming that the
-   name server's iterative resolver will generate no queries, its
-   administrators place the name server behind a network device that
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 9]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   prevents it from receiving responses.  If this is the case, all glue-
-   fetching queries will go answered.
-
-   We have observed name server implementations whose iterative
-   resolvers retry excessively when glue-fetching queries are
-   unanswered.  A single com/net name server has received hundreds of
-   queries per second from a single such source.  Judging from the
-   specific queries received and based on additional analysis, we
-   believe these queries result from overly aggressive glue fetching.
-
-2.4.1.  Recommendation
-
-   Implementers whose name servers support glue fetching SHOULD take
-   care to avoid sending queries at excessive rates.  Implementations
-   SHOULD support throttling logic to detect when queries are sent but
-   no responses are received.
-
-2.5.  Aggressive retransmission behind firewalls
-
-   A common occurrence and one of the largest sources of repeated
-   queries at the com/net and root name servers appears to result from
-   resolvers behind misconfigured firewalls.  In this situation, an
-   iterative resolver is apparently allowed to send queries through a
-   firewall to other name servers, but not receive the responses.  The
-   result is more queries than necessary because of retransmission, all
-   of which are useless because the responses are never received.  Just
-   as with the glue-fetching scenario described in Section 2.4, the
-   queries are sometimes sent at excessive rates.  To make matters
-   worse, sometimes the responses, sent in reply to legitimate queries,
-   trigger an alarm on the originator's intrusion detection system.  We
-   are frequently contacted by administrators responding to such alarms
-   who believe our name servers are attacking their systems.
-
-   Not only do some resolvers in this situation retransmit queries at an
-   excessive rate, but they continue to do so for days or even weeks.
-   This scenario could result from an organization with multiple
-   recursive name servers, only a subset of whose iterative resolvers'
-   traffic is improperly filtered in this manner.  Stub resolvers in the
-   organization could be configured to query multiple recursive name
-   servers.  Consider the case where a stub resolver queries a filtered
-   recursive name server first.  The iterative resolver of this
-   recursive name server sends one or more queries whose replies are
-   filtered, so it can't respond to the stub resolver, which times out.
-   Then the stub resolver retransmits to a recursive name server that is
-   able to provide an answer.  Since resolution ultimately succeeds the
-   underlying problem might not be recognized or corrected.  A popular
-   stub resolver implementation has a very aggressive retransmission
-   schedule, including simultaneous queries to multiple recursive name
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 10]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   servers, which could explain how such a situation could persist
-   without being detected.
-
-2.5.1.  Recommendation
-
-   The most obvious recommendation is that administrators SHOULD take
-   care not to place iterative resolvers behind a firewall that allows
-   queries to pass through but not the resulting replies.
-
-   Iterative resolvers SHOULD take care to avoid sending queries at
-   excessive rates.  Implementations SHOULD support throttling logic to
-   detect when queries are sent but no responses are received.
-
-2.6.  Misconfigured NS records
-
-   Sometimes a zone administrator forgets to add the trailing dot on the
-   domain names in the RDATA of a zone's NS records.  Consider this
-   fragment of the zone file for "example.com":
-
-     $ORIGIN example.com.
-     example.com.      3600   IN   NS   ns1.example.com  ; Note missing
-     example.com.      3600   IN   NS   ns2.example.com  ; trailing dots
-
-   The zone's authoritative servers will parse the NS RDATA as
-   "ns1.example.com.example.com" and "ns2.example.com.example.com" and
-   return NS records with this incorrect RDATA in responses, including
-   typically the authority section of every response containing records
-   from the "example.com" zone.
-
-   Now consider a typical sequence of queries.  An iterative resolver
-   attempting to resolve address records for "www.example.com" with no
-   cached information for this zone will query a "com" authoritative
-   server.  The "com" server responds with a referral to the
-   "example.com" zone, consisting of NS records with valid RDATA and
-   associated glue records.  (This example assumes that the
-   "example.com" zone delegation information is correct in the "com"
-   zone.)  The iterative resolver caches the NS RRset from the "com"
-   server and follows the referral by querying one of the "example.com"
-   authoritative servers.  This server responds with the
-   "www.example.com" address record in the answer section and,
-   typically, the "example.com" NS records in the authority section and,
-   if space in the message remains, glue address records in the
-   additional section.  According to Section 5.4 of RFC 2181 [3], NS
-   records in the authority section of an authoritative answer are more
-   trustworthy than NS records from the authority section of a non-
-   authoritative answer.  Thus the "example.com" NS RRset just received
-   from the "example.com" authoritative server overrides the
-   "example.com" NS RRset received moments ago from the "com"
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 11]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   authoritative server.
-
-   But the "example.com" zone contains the erroneous NS RRset as shown
-   in the example above.  Subsequent queries for names in "example.com"
-   will cause the iterative resolver to attempt to use the incorrect NS
-   records and so it will try to resolve the nonexistent names
-   "ns1.example.com.example.com" and "ns2.example.com.example.com".  In
-   this example, since all of the zone's name servers are named in the
-   zone itself (i.e., "ns1.example.com.example.com" and
-   "ns2.example.com.example.com" both end in "example.com") and all are
-   bogus, the iterative resolver cannot reach any "example.com" name
-   servers.  Therefore attempts to resolve these names result in address
-   record queries to the "com" authoritative servers.  Queries for such
-   obviously bogus glue address records occur frequently at the com/net
-   name servers.
-
-2.6.1.  Recommendation
-
-   An authoritative server can detect this situation.  A trailing dot
-   missing from an NS record's RDATA always results by definition in a
-   name server name that exists somewhere under the apex of the zone the
-   NS record appears in.  Note that further levels of delegation are
-   possible, so a missing trailing dot could inadvertently create a name
-   server name that actually exists in a subzone.
-
-   An authoritative name server SHOULD issue a warning when one of a
-   zone's NS records references a name server below the zone's apex when
-   a corresponding address record does not exist in the zone AND there
-   are no delegated subzones where the address record could exist.
-
-2.7.  Name server records with zero TTL
-
-   Sometimes a popular com/net subdomain's zone is configured with a TTL
-   of zero on the zone's NS records, which prohibits these records from
-   being cached and will result in a higher query volume to the zone's
-   authoritative servers.  The zone's administrator should understand
-   the consequences of such a configuration and provision resources
-   accordingly.  A zero TTL on the zone's NS RRset, however, carries
-   additional consequences beyond the zone itself: if an iterative
-   resolver cannot cache a zone's NS records because of a zero TTL, it
-   will be forced to query that zone's parent's name servers each time
-   it resolves a name in the zone.  The com/net authoritative servers do
-   see an increased query load when a popular com/net subdomain's zone
-   is configured with a TTL of zero on the zone's NS records.
-
-   A zero TTL on an RRset expected to change frequently is extreme but
-   permissible.  A zone's NS RRset is a special case, however, because
-   changes to it must be coordinated with the zone's parent.  In most
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 12]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   zone parent/child relationships we are aware of, there is typically
-   some delay involved in effecting changes.  Further, changes to the
-   set of a zone's authoritative name servers (and therefore to the
-   zone's NS RRset) are typically relatively rare: providing reliable
-   authoritative service requires a reasonably stable set of servers.
-   Therefore an extremely low or zero TTL on a zone's NS RRset rarely
-   makes sense, except in anticipation of an upcoming change.  In this
-   case, when the zone's administrator has planned a change and does not
-   want iterative resolvers throughout the Internet to cache the NS
-   RRset for a long period of time, a low TTL is reasonable.
-
-2.7.1.  Recommendation
-
-   Because of the additional load placed on a zone's parent's
-   authoritative servers resulting from a zero TTL on a zone's NS RRset,
-   under such circumstances authoritative name servers SHOULD issue a
-   warning when loading a zone.
-
-2.8.  Unnecessary dynamic update messages
-
-   The UPDATE message specified in RFC 2136 [6] allows an authorized
-   agent to update a zone's data on an authoritative name server using a
-   DNS message sent over the network.  Consider the case of an agent
-   desiring to add a particular resource record.  Because of zone cuts,
-   the agent does not necessarily know the proper zone to which the
-   record should be added.  The dynamic update process requires that the
-   agent determine the appropriate zone so the UPDATE message can be
-   sent to one of the zone's authoritative servers (typically the
-   primary master as specified in the zone's SOA MNAME field).
-
-   The appropriate zone to update is the closest enclosing zone, which
-   cannot be determined only by inspecting the domain name of the record
-   to be updated, since zone cuts can occur anywhere.  One way to
-   determine the closest enclosing zone entails walking up the name
-   space tree by sending repeated UPDATE messages until success.  For
-   example, consider an agent attempting to add an address record with
-   the name "foo.bar.example.com".  The agent could first attempt to
-   update the "foo.bar.example.com" zone.  If the attempt failed, the
-   update could be directed to the "bar.example.com" zone, then the
-   "example.com" zone, then the "com" zone, and finally the root zone.
-
-   A popular dynamic agent follows this algorithm.  The result is many
-   UPDATE messages received by the root name servers, the com/net
-   authoritative servers, and presumably other TLD authoritative
-   servers.  A valid question is why the algorithm proceeds to send
-   updates all the way to TLD and root name servers.  This behavior is
-   not entirely unreasonable: in enterprise DNS architectures with an
-   "internal root" design, there could conceivably be private, non-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 13]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   public TLD or root zones that would be the appropriate targets for a
-   dynamic update.
-
-   A significant deficiency with this algorithm is that knowledge of a
-   given UPDATE message's failure is not helpful in directing future
-   UPDATE messages to the appropriate servers.  A better algorithm would
-   be to find the closest enclosing zone by walking up the name space
-   with queries for SOA or NS rather than "probing" with UPDATE
-   messages.  Once the appropriate zone is found, an UPDATE message can
-   be sent.  In addition, the results of these queries can be cached to
-   aid in determining closest enclosing zones for future updates.  Once
-   the closest enclosing zone is determined with this method, the update
-   will either succeed or fail and there is no need to send further
-   updates to higher-level zones.  The important point is that walking
-   up the tree with queries yields cacheable information, whereas
-   walking up the tree by sending UPDATE messages does not.
-
-2.8.1.  Recommendation
-
-   Dynamic update agents SHOULD send SOA or NS queries to progressively
-   higher-level names to find the closest enclosing zone for a given
-   name to update.  Only after the appropriate zone is found should the
-   client send an UPDATE message to one of the zone's authoritative
-   servers.  Update clients SHOULD NOT "probe" using UPDATE messages by
-   walking up the tree to progressively higher-level zones.
-
-2.9.  Queries for domain names resembling IPv4 addresses
-
-   The root name servers receive a significant number of A record
-   queries where the QNAME looks like an IPv4 address.  The source of
-   these queries is unknown.  It could be attributed to situations where
-   a user believes an application will accept either a domain name or an
-   IP address in a given configuration option.  The user enters an IP
-   address, but the application assumes any input is a domain name and
-   attempts to resolve it, resulting in an A record lookup.  There could
-   also be applications that produce such queries in a misguided attempt
-   to reverse map IP addresses.
-
-   These queries result in Name Error (RCODE=3) responses.  An iterative
-   resolver can negatively cache such responses, but each response
-   requires a separate cache entry, i.e., a negative cache entry for the
-   domain name "192.0.2.1" does not prevent a subsequent query for the
-   domain name "192.0.2.2".
-
-2.9.1.  Recommendation
-
-   It would be desirable for the root name servers not to have to answer
-   these queries: they unnecessarily consume CPU resources and network
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 14]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   bandwidth.  A possible solution is to delegate these numeric TLDs
-   from the root zone to a separate set of servers to absorb the
-   traffic.  The "black hole servers" used by the AS 112 Project [8],
-   which are currently delegated the in-addr.arpa zones corresponding to
-   RFC 1918 [7] private use address space, would be a possible choice to
-   receive these delegations.  Of course, the proper and usual root zone
-   change procedures would have to be followed to make such a change to
-   the root zone.
-
-2.10.  Misdirected recursive queries
-
-   The root name servers receive a significant number of recursive
-   queries (i.e., queries with the RD bit set in the header).  Since
-   none of the root servers offers recursion, the servers' response in
-   such a situation ignores the request for recursion and the response
-   probably does not contain the data the querier anticipated.  Some of
-   these queries result from users configuring stub resolvers to query a
-   root server.  (This situation is not hypothetical: we have received
-   complaints from users when this configuration does not work as
-   hoped.)  Of course, users should not direct stub resolvers to use
-   name servers that do not offer recursion, but we are not aware of any
-   stub resolver implementation that offers any feedback to the user
-   when so configured, aside from simply "not working".
-
-2.10.1.  Recommendation
-
-   When the IP address of a name server that supposedly offers recursion
-   is configured in a stub resolver using an interactive user interface,
-   the resolver could send a test query to verify that the server indeed
-   supports recursion (i.e., verify that the response has the RA bit set
-   in the header).  The user could be immediately notified if the server
-   is non-recursive.
-
-   The stub resolver could also report an error, either through a user
-   interface or in a log file, if the queried server does not support
-   recursion.  Error reporting SHOULD be throttled to avoid a
-   notification or log message for every response from a non-recursive
-   server.
-
-2.11.  Suboptimal name server selection algorithm
-
-   An entire document could be devoted to the topic of problems with
-   different implementations of the recursive resolution algorithm.  The
-   entire process of recursion is woefully under specified, requiring
-   each implementor to design an algorithm.  Sometimes implementors make
-   poor design choices that could be avoided if a suggested algorithm
-   and best practices were documented, but that is a topic for another
-   document.
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 15]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   Some deficiencies cause significant operational impact and are
-   therefore worth mentioning here.  One of these is name server
-   selection by an iterative resolver.  When an iterative resolver wants
-   to contact one of a zone's authoritative name servers, how does it
-   choose from the NS records listed in the zone's NS RRset?  If the
-   selection mechanism is suboptimal, queries are not spread evenly
-   among a zone's authoritative servers.  The details of the selection
-   mechanism are up to the implementor, but we offer some suggestions.
-
-2.11.1.  Recommendation
-
-   This list is not conclusive, but reflects the changes that would
-   produce the most impact in terms of reducing disproportionate query
-   load among a zone's authoritative servers.  I.e., these changes would
-   help spread the query load evenly.
-
-   o  Do not make assumptions based on NS RRset order: all NS RRs SHOULD
-      be treated equally.  (In the case of the "com" zone, for example,
-      most of the root servers return the NS record for "a.gtld-
-      servers.net" first in the authority section of referrals.
-      Apparently as a result, this server receives disproportionately
-      more traffic than the other 12 authoritative servers for "com".)
-
-   o  Use all NS records in an RRset.  (For example, we are aware of
-      implementations that hard-coded information for a subset of the
-      root servers.)
-
-   o  Maintain state and favor the best-performing of a zone's
-      authoritative servers.  A good definition of performance is
-      response time.  Non-responsive servers can be penalized with an
-      extremely high response time.
-
-   o  Do not lock onto the best-performing of a zone's name servers.  An
-      iterative resolver SHOULD periodically check the performance of
-      all of a zone's name servers to adjust its determination of the
-      best-performing one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 16]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-3.  Acknowledgments
-
-   The authors would like to thank the following people for their
-   comments that improved this document: Andras Salamon, Dave Meyer,
-   Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy,
-   Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein.  We
-   apologize if we have omitted anyone; any oversight was unintentional.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 17]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-4.  IANA considerations
-
-   There are no new IANA considerations introduced by this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 18]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-5.  Security considerations
-
-   The iterative resolver misbehavior discussed in this document exposes
-   the root and TLD name servers to increased risk of both intentional
-   and unintentional denial of service attacks.
-
-   We believe that implementation of the recommendations offered in this
-   document will reduce the amount of unnecessary traffic seen at root
-   and TLD name servers, thus reducing the opportunity for an attacker
-   to use such queries to his or her advantage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 19]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-6.  Internationalization considerations
-
-   There are no new internationalization considerations introduced by
-   this memo.
-
-7.  Informative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Mockapetris, P., "Domain names - concepts and facilities",
-        STD 13, RFC 1034, November 1987.
-
-   [3]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-        RFC 2181, July 1997.
-
-   [4]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-        RFC 2308, March 1998.
-
-   [5]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
-        Queries for IPv6 Addresses", RFC 4074, May 2005.
-
-   [6]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
-        Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-        April 1997.
-
-   [7]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
-        Lear, "Address Allocation for Private Internets", BCP 5,
-        RFC 1918, February 1996.
-
-   [8]  <http://www.as112.net>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 20]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-Authors' Addresses
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   Email: mlarson@verisign.com
-
-
-   Piet Barber
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   Email: pbarber@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 21]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 22]
-
diff --git a/doc/draft/draft-ietf-dnsop-dnssec-key-timing-02.txt b/doc/draft/draft-ietf-dnsop-dnssec-key-timing-02.txt
deleted file mode 100644
index 60d2772b..00000000
--- a/doc/draft/draft-ietf-dnsop-dnssec-key-timing-02.txt
+++ /dev/null
@@ -1,1848 +0,0 @@
-
-
-
-Internet Engineering Task Force                                S. Morris
-Internet-Draft                                                       ISC
-Intended status: Informational                                  J. Ihren
-Expires: September 11, 2011                                       Netnod
-                                                            J. Dickinson
-                                                                 Sinodun
-                                                          March 10, 2011
-
-
-                    DNSSEC Key Timing Considerations
-               draft-ietf-dnsop-dnssec-key-timing-02.txt
-
-Abstract
-
-   This document describes the issues surrounding the timing of events
-   in the rolling of a key in a DNSSEC-secured zone.  It presents
-   timelines for the key rollover and explicitly identifies the
-   relationships between the various parameters affecting the process.
-
-Status of this Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at http://datatracker.ietf.org/drafts/current/.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   This Internet-Draft will expire on September 11, 2011.
-
-Copyright Notice
-
-   Copyright (c) 2011 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-
-
-
-Morris, et al.         Expires September 11, 2011               [Page 1]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  Key Rolling Considerations . . . . . . . . . . . . . . . .  3
-     1.2.  Types of Keys  . . . . . . . . . . . . . . . . . . . . . .  4
-     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.4.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
-   2.  Rollover Methods . . . . . . . . . . . . . . . . . . . . . . .  4
-     2.1.  ZSK Rollovers  . . . . . . . . . . . . . . . . . . . . . .  4
-     2.2.  KSK Rollovers  . . . . . . . . . . . . . . . . . . . . . .  6
-     2.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . .  7
-   3.  Key Rollover Timelines . . . . . . . . . . . . . . . . . . . .  7
-     3.1.  Key States . . . . . . . . . . . . . . . . . . . . . . . .  7
-     3.2.  Zone-Signing Key Timelines . . . . . . . . . . . . . . . .  9
-       3.2.1.  Pre-Publication Method . . . . . . . . . . . . . . . .  9
-       3.2.2.  Double-Signature Method  . . . . . . . . . . . . . . . 11
-       3.2.3.  Double-RRSIG Method  . . . . . . . . . . . . . . . . . 13
-     3.3.  Key-Signing Key Rollover Timelines . . . . . . . . . . . . 15
-       3.3.1.  Double-Signature Method  . . . . . . . . . . . . . . . 15
-       3.3.2.  Double-DS Method . . . . . . . . . . . . . . . . . . . 18
-       3.3.3.  Double-RRset Method  . . . . . . . . . . . . . . . . . 21
-       3.3.4.  Interaction with Configured Trust Anchors  . . . . . . 23
-         3.3.4.1.  Addition of KSK  . . . . . . . . . . . . . . . . . 23
-         3.3.4.2.  Removal of KSK . . . . . . . . . . . . . . . . . . 24
-       3.3.5.  Introduction of First KSK  . . . . . . . . . . . . . . 24
-   4.  Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 24
-   5.  Algorithm Considerations . . . . . . . . . . . . . . . . . . . 25
-   6.  Limitation of Scope  . . . . . . . . . . . . . . . . . . . . . 26
-   7.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
-   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
-   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
-   11. Change History (To be removed on publication)  . . . . . . . . 27
-   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
-     12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
-     12.2. Informative References . . . . . . . . . . . . . . . . . . 29
-   Appendix A.  List of Symbols . . . . . . . . . . . . . . . . . . . 29
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
-
-
-
-
-
-
-
-
-
-Morris, et al.         Expires September 11, 2011               [Page 2]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-1.  Introduction
-
-1.1.  Key Rolling Considerations
-
-   When a zone is secured with DNSSEC, the zone manager must be prepared
-   to replace ("roll") the keys used in the signing process.  The
-   rolling of keys may be caused by compromise of one or more of the
-   existing keys, or it may be due to a management policy that demands
-   periodic key replacement for security or operational reasons.  In
-   order to implement a key rollover, the keys need to be introduced
-   into and removed from the zone at the appropriate times.
-   Considerations that must be taken into account are:
-
-   o  DNSKEY records and associated information (such as the associated
-      DS records or RRSIG records created with the key) are not only
-      held at the authoritative nameserver, they are also cached by
-      resolvers.  The data on these systems can be interlinked, e.g. a
-      validating resolver may try to validate a signature retrieved from
-      a cache with a key obtained separately.
-
-   o  Zone "boot-strapping" events, where a zone is signed for the first
-      time, can be common in configurations where a large number of
-      zones are being served.  Procedures should be able to cope with
-      the introduction of keys into the zone for the first time as well
-      as "steady-state", where the records are being replaced as part of
-      normal zone maintenance.
-
-   o  To allow for an emergency re-signing of the zone as soon as
-      possible after a key compromise has been detected, standby keys
-      (additional keys over and above those used to sign the zone) need
-      to be present.
-
-   o  A query for the DNSKEY RRset returns all DNSKEY records in the
-      zone.  As there is limited space in the UDP packet (even with
-      EDNS0 support), key records no longer needed must be periodically
-      removed.  (For the same reason, the number of standby keys in the
-      zone should be restricted to the minimum required to support the
-      key management policy.)
-
-   Management policy, e.g. how long a key is used for, also needs to be
-   considered.  However, the point of key management logic is not to
-   ensure that a rollover is completed at a certain time but rather to
-   ensure that no changes are made to the state of keys published in the
-   zone until it is "safe" to do so ("safe" in this context meaning that
-   at no time during the rollover process does any part of the zone ever
-   go bogus).  In other words, although key management logic enforces
-   policy, it may not enforce it strictly.
-
-
-
-
-Morris, et al.         Expires September 11, 2011               [Page 3]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-1.2.  Types of Keys
-
-   Although DNSSEC validation treats all keys equally, [RFC4033]
-   recognises the broad classification of zone-signing keys (ZSK) and
-   key-signing keys (KSK).  A ZSK is used to authenticate information
-   within the zone; a KSK is used to authenticate the zone's DNSKEY
-   RRset.  The main implication for this distinction concerns the
-   consistency of information during a rollover.
-
-   During operation, a validating resolver must use separate pieces of
-   information to perform an authentication.  At the time of
-   authentication, each piece of information may be in its cache or may
-   need to be retrieved from the authoritative server.  The rollover
-   process needs to happen in such a way that at all times during the
-   rollover the information is consistent.  With a ZSK, the information
-   is the RRSIG (plus associated RRset) and the DNSKEY.  These are both
-   obtained from the same zone.  In the case of the KSK, the information
-   is the DNSKEY and DS RRset with the latter being obtained from a
-   different zone.
-
-   Although there are similarities in the algorithms to roll ZSKs and
-   KSKs, there are a number of differences.  For this reason, the two
-   types of rollovers are described separately.  It is also possible to
-   use a single key as both the ZSK and KSK.  However, the rolling of
-   this type of key is not treated in this document.
-
-1.3.  Terminology
-
-   The terminology used in this document is as defined in [RFC4033] and
-   [RFC5011].
-
-   A number of symbols are used to identify times, intervals, etc.  All
-   are listed in Appendix A.
-
-1.4.  Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-2.  Rollover Methods
-
-2.1.  ZSK Rollovers
-
-   A ZSK can be rolled in one of three ways:
-
-
-
-
-
-Morris, et al.         Expires September 11, 2011               [Page 4]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   o  Pre-Publication: described in [RFC4641], the new key is introduced
-      into the DNSKEY RRset which is then re-signed.  This state of
-      affairs remains in place for long enough to ensure that any cached
-      DNSKEY RRsets contain both keys.  At that point signatures created
-      with the old key can be replaced by those created with the new
-      key, and the old signatures removed.  During the re-signing
-      process (which may or may not be atomic depending on how the zone
-      is managed), it doesn't matter which key an RRSIG record retrieved
-      by a resolver was created with; cached copies of the DNSKEY RRset
-      will contain both the old and new keys.
-
-      Once the zone contains only signatures created with the new key,
-      there is an interval during which RRSIG records created with the
-      old key expire from caches.  After this, there will be no
-      signatures anywhere that were created using the old key, and it
-      can can be removed from the DNSKEY RRset.
-
-   o  Double-Signature: also mentioned in [RFC4641], this involves
-      introducing the new key into the zone and using it to create
-      additional RRSIG records; the old key and existing RRSIG records
-      are retained.  During the period in which the zone is being signed
-      (again, the signing process may not be atomic), validating
-      resolvers are always able to validate RRSIGs: any combination of
-      old and new DNSKEY RRset and RRSIG allows at least one signature
-      to be validated.
-
-      Once the signing process is complete and enough time has elapsed
-      to allow all old information to expire from caches, the old key
-      and signatures can be removed from the zone.  As before, during
-      this period any combination of DNSKEY RRset and RRSIG will allow
-      validation of at least one signature.
-
-   o  Double-RRSIG: strictly speaking, the use of the term "Double-
-      Signature" above is a misnomer as the method is not only double
-      signature, it is also double key as well.  A true Double-Signature
-      method (here called the Double-RRSIG method) involves introducing
-      new signatures in the zone (while still retaining the old ones)
-      but not introducing the new key.
-
-      Once the signing process is complete and enough time has elapsed
-      to ensure that all caches that may contain an RR and associated
-      RRSIG have a copy of both signatures, the key is changed.  After a
-      further interval during which the old DNSKEY RRset expires from
-      caches, the old signatures are removed from the zone.
-
-   Of three methods, Double-Signature is conceptually the simplest -
-   introduce the new key and new signatures, then approximately one TTL
-   later remove the old key and old signatures.  Pre-Publication is more
-
-
-
-Morris, et al.         Expires September 11, 2011               [Page 5]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   complex - introduce the new key, approximately one TTL later sign the
-   records, and approximately one TTL after that remove the old key.
-   Double-RRSIG is essentially the reverse of Pre-Publication -
-   introduce the new signatures, approximately one TTL later change the
-   key, and approximately one TTL after that remove the old signatures.
-
-2.2.  KSK Rollovers
-
-   For ZSKs, the issue for the validating resolver is to ensure that it
-   has access to the ZSK that corresponds to a particular signature.  In
-   the KSK case this can never be a problem as the KSK is only used for
-   one signature (that over the DNSKEY RRset) and both the key the
-   signature travel together.  Instead, the issue is to ensure that the
-   KSK is trusted.
-
-   Trust in the KSK is either due to the existence of a DS record in the
-   parent zone (which is itself trusted) or an explicitly configured
-   trust anchor.  If the former, the rollover algorithm will need to
-   involve the parent zone in the addition and removal of DS records, so
-   timings are not wholly under the control of the zone manager.  If the
-   latter, [RFC5011] timings will be needed to roll the keys.  (Even in
-   the case where authentication is via a DS record, the zone manager
-   may elect to include [RFC5011] timings in the key rolling process so
-   as to cope with the possibility that the key has also been explicitly
-   configured as a trust anchor.)
-
-   It is important to note that this does not preclude the development
-   of key rollover logic; in accordance with the goal of the rollover
-   logic being able to determine when a state change is "safe", the only
-   effect of being dependent on the parent is that there may be a period
-   of waiting for the parent to respond in addition to any delay the key
-   rollover logic requires.  Although this introduces additional delays,
-   even with a parent that is less than ideally responsive the only
-   effect will be a slowdown in the rollover state transitions.  This
-   may cause a policy violation, but will not cause any operational
-   problems.
-
-   Like the ZSK case, there are three methods for rolling a KSK:
-
-   o  Double-Signature: also known as Double-DNSKEY, the new KSK is
-      added to the DNSKEY RRset which is then signed with both the old
-      and new key.  After waiting for the old RRset to expire from
-      caches, the DS record in the parent zone is changed.  After
-      waiting a further interval for this change to be reflected in
-      caches, the old key is removed from the RRset.  (The name "Double-
-      Signature" is used because, like the ZSK method of the same name,
-      the new key is introduced and immediately used for signing.)
-
-
-
-
-Morris, et al.         Expires September 11, 2011               [Page 6]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   o  Double-DS: the new DS record is published.  After waiting for this
-      change to propagate into caches, the KSK is changed.  After a
-      further interval during which the old DNSKEY RRset expires from
-      caches, the old DS record is removed.
-
-   o  Double-RRset: the new KSK is added to the DNSKEY RRset which is
-      then signed with both the old and new key, and the new DS record
-      added to the parent zone.  After waiting a suitable interval for
-      the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY
-      and DS record are removed.
-
-   In essence, "Double-Signature" means that the new KSK is introduced
-   first and used to sign the DNSKEY RRset.  The DS record is changed,
-   and finally the old KSK removed.  With "Double-DS" it is the other
-   way around.  Finally, Double-RRset does both updates more or less in
-   parallel.
-
-2.3.  Summary
-
-   The methods can be summarised as follows:
-
-   +------------------+------------------+-----------------------------+
-   | ZSK Method       | KSK Method       | Description                 |
-   +------------------+------------------+-----------------------------+
-   | Pre-Publication  | (not applicable) | Publish the DNSKEY before   |
-   |                  |                  | the RRSIG.                  |
-   | Double-Signature | Double-Signature | Publish the DNSKEY and      |
-   |                  |                  | RRSIG at same time. (For a  |
-   |                  |                  | KSK, this happens before    |
-   |                  |                  | the DS is published.)       |
-   | Double-RRSIG     | (not applicable) | Publish RRSIG before the    |
-   |                  |                  | DNSKEY.                     |
-   | (not applicable) | Double-DS        | Publish DS before the       |
-   |                  |                  | DNSKEY.                     |
-   | (not applicable) | Double-RRset     | Publish DNSKEY and DS in    |
-   |                  |                  | parallel.                   |
-   +------------------+------------------+-----------------------------+
-
-                                  Table 1
-
-
-3.  Key Rollover Timelines
-
-3.1.  Key States
-
-   During the rolling process, a key moves through different states.
-   The defined states are:
-
-
-
-
-Morris, et al.         Expires September 11, 2011               [Page 7]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   Generated   The key has been created, but has not yet been used for
-               anything.
-
-   Published   The DNSKEY record - or information associated with it -
-               is published in the zone, but predecessors of the key (or
-               associated information) may be held in caches.
-
-               The idea of "associated information" is used in rollover
-               methods where RRSIG or DS records are published first and
-               the DNSKEY is changed in an atomic operation.  It allows
-               the rollover still to be thought of as moving through a
-               set of states.  In the rest of this section, the term
-               "key data" should be taken to mean "key or associated
-               information".
-
-   Ready       The new key data has been published for long enough to
-               guarantee that any previous versions of it have expired
-               from caches.
-
-   Active      The key has started to be used to sign RRsets.  Note that
-               when this state is entered, it may not be possible for
-               validating resolvers to use the key for validation in all
-               cases: the zone signing may not have finished, or the
-               data might not have reached the resolver because of
-               propagation delays and/or caching issues.  If this is the
-               case, the resolver will have to rely on the key's
-               predecessor instead.
-
-   Retired     The key is in the zone but a successor key has become
-               active.  As there may still be information in caches that
-               that require use of the key, it is being retained until
-               this information expires.
-
-   Dead        The key is published in the zone but there is no longer
-               information anywhere that requires its presence.  Hence
-               the key can be removed from the zone at any time.
-
-   Removed     The key has been removed from the zone.
-
-   There is one additional state, used where [RFC5011] considerations
-   are in effect (see Section 3.3.4):
-
-   Revoked     The key is published for a period with the "revoke" bit
-               set as a way of notifying validating resolvers that have
-               configured it as an [RFC5011] trust anchor that it is
-               about to be removed from the zone.
-
-
-
-
-
-Morris, et al.         Expires September 11, 2011               [Page 8]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-3.2.  Zone-Signing Key Timelines
-
-   The following sections describe the rolling of a ZSK.  They show the
-   events in the lifetime of a key (referred to as "key N") and cover
-   its replacement by its successor (key N+1).
-
-3.2.1.  Pre-Publication Method
-
-   The following diagram shows the timeline of a Pre-Publication
-   rollover.  Time increases along the horizontal scale from left to
-   right and the vertical lines indicate events in the process.
-   Significant times and time intervals are marked.
-
-
-
-            |1|  |2|      |3|   |4|   |5|      |6| |7|      |8|   |9|
-             |    |        |     |     |        |   |        |     |
-     Key N   |    |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->|
-             |    |        |     |     |        |   |        |     |
-     Key N+1 |    |        |     |     |<-Ipub->|<->|<---Lzsk-- - -
-             |    |        |     |     |        |   |        |     |
-            Tgen Tpub     Trdy  Tact  TpubS        Tret     Tdea  Trem
-
-                             ---- Time ---->
-
-
-          Figure 1: Timeline for a Pre-Publication ZSK rollover.
-
-   Event 1: key N is generated at the generate time (Tgen).  Although
-   there is no reason why the key cannot be generated immediately prior
-   to its publication in the zone (Event 2), some implementations may
-   find it convenient to create a pool of keys in one operation and draw
-   from that pool as required.  For this reason, it is shown as a
-   separate event.  Keys that are available for use but not published
-   are said to be generated.
-
-   Event 2: key N's DNSKEY record is put into the zone, i.e. it is added
-   to the DNSKEY RRset which is then re-signed with the current key-
-   signing key.  The time at which this occurs is the key's publication
-   time (Tpub), and the key is now said to be published.  Note that the
-   key is not yet used to sign records.
-
-   Event 3: before it can be used, the key must be published for long
-   enough to guarantee that any cached version of the zone's DNSKEY
-   RRset includes this key.
-
-   This interval is the publication interval (Ipub) and, for the second
-   or subsequent keys in the zone, is given by:
-
-
-
-Morris, et al.         Expires September 11, 2011               [Page 9]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-             Ipub = Dprp + TTLkey
-
-   Here, Dprp is the propagation delay - the time taken in the worst-
-   case situation for a change introduced at the master to replicate to
-   all slave servers - which depends on the depth of the master-slave
-   hierarchy.  TTLkey is the time-to-live (TTL) for the DNSKEY records
-   in the zone.  The sum is therefore the maximum time taken for
-   existing DNSKEY records to expire from caches, regardless of the
-   nameserver from which they were retrieved.
-
-   (The case of introducing the first ZSK into the zone is discussed in
-   Section 3.3.5.)
-
-   After a delay of Ipub, the key is said to be ready and could be used
-   to sign records.  The time at which this event occurs is the key's
-   ready time (Trdy), which is given by:
-
-             Trdy = Tpub + Ipub
-
-   Event 4: at some later time, the key starts being used to sign
-   RRsets.  This point is the activation time (Tact) and after this, the
-   key is said to be active.
-
-   Event 5: at some point thought must be given to its successor (key
-   N+1).  As with the introduction of the currently active key into the
-   zone, the successor key will need to be published at least Ipub
-   before it is activated.  Denoting the publication time of the
-   successor key by TpubS, then:
-
-             TpubS <= Tact + Lzsk - Ipub
-
-   Here, Lzsk is the length of time for which a ZSK will be used (the
-   ZSK lifetime).  It should be noted that unlike the publication
-   interval, Lzsk is not determined by timing logic, but by key
-   management policy.  Lzsk will be set by the operator according to
-   their assessment of the risks posed by continuing to use a key and
-   the risks associated with key rollover.  However, operational
-   considerations may mean a key is active for slightly more or less
-   than Lzsk.
-
-   Event 6: while key N is still active, its successor becomes ready.
-   From this time onwards, key N+1 could be used to sign the zone.
-
-   Event 7: When key N has been in use for an interval equal to the the
-   ZSK lifetime, it is retired (i.e. it will never again be used to
-   generate new signatures) and key N+1 activated and used to sign the
-   zone.  This is the retire time of key N (Tret) and is given by:
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 10]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-             Tret = Tact + Lzsk
-
-   It is also the activation time of the successor key (TactS).  Note
-   that operational considerations may cause key N to remain in use for
-   longer than Lzsk; if so, the retirement actually occurs when the
-   successor key is made active.
-
-   Event 8: the retired key needs to be retained in the zone whilst any
-   RRSIG records created using this key are still published in the zone
-   or held in caches.  (It is possible that a validating resolver could
-   have an unexpired RRSIG record and an expired DNSKEY RRset in the
-   cache when it is asked to provide both to a client.  In this case the
-   DNSKEY RRset would need to be looked up again.)  This means that once
-   the key is no longer used to sign records, it should be retained in
-   the zone for at least the retire interval (Iret) given by:
-
-             Iret = Dsgn + Dprp + TTLsig
-
-   Dsgn is the delay needed to ensure that all existing RRsets have been
-   re-signed with the new key.  Dprp is (as described above) the
-   propagation delay, required to guarantee that the updated zone
-   information has reached all slave servers, and TTLsig is the maximum
-   TTL of all the RRSIG records in the zone.
-
-   The time at which all RRSIG records created with this key have
-   expired from resolver caches is the dead time (Tdea), given by:
-
-             Tdea = Tret + Iret
-
-   ...at which point the key is said to be dead.
-
-   Event 9: at any time after the key becomes dead, it can be removed
-   from the zone and the DNSKEY RRset re-signed with the current key-
-   signing key.  This time is the removal time (Trem), given by:
-
-             Trem >= Tdea
-
-   ...at which time the key is said to be removed.
-
-3.2.2.  Double-Signature Method
-
-   The timeline for a double-signature rollover is shown below.  The
-   diagram follows the convention described in Section 3.2.1
-
-
-
-
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 11]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-                    |1|  |2|           |3|          |4|  |5|
-                     |    |             |            |    |
-             Key N   |    |<----Lzsk--->|<---Iret--->|    |
-                     |    |             |            |    |
-             Key N+1 |    |             |<-----Lzsk------- - -
-                     |    |             |            |    |
-                    Tgen Tact          Tret         Tdea  Trem
-
-                                  ---- Time ---->
-
-
-          Figure 2: Timeline for a Double-Signature ZSK rollover.
-
-   Event 1: key N is generated at the generate time (Tgen).  Although
-   there is no reason why the key cannot be generated immediately prior
-   to its publication in the zone (Event 2), some implementations may
-   find it convenient to create a pool of keys in one operation and draw
-   from that pool as required.  For this reason, it is shown as a
-   separate event.  Keys that are available for use but not published
-   are said to be generated.
-
-   Event 2: key N is added to the DNSKEY RRset and is then used to sign
-   the zone; existing signatures in the zone are not removed.  This is
-   the activation time (Tact), after which the key is said to be active.
-
-   Event 3: after the current key (key N) has been in use for its
-   intended lifetime (Lzsk), the successor key (key N+1) is introduced
-   into the zone and starts being used to sign RRsets: neither the
-   current key nor the signatures created with it are removed.  The
-   successor is key is now active and the current key is said to be
-   retired.  This time is the retire time of the key (Tret); it is also
-   the activation time of the successor key (TactS).
-
-             Tret = Tact + Lzsk
-
-   Event 4: before key N can be withdrawn from the zone, all RRsets that
-   need to be signed must have been signed by the successor key (key
-   N+1) and any old RRsets that do not include the new key or new RRSIGs
-   must have expired from caches.  Note that the signatures are not
-   replaced - each RRset is signed by both the old and new key.
-
-   This takes Iret, the retire interval, given by the expression:
-
-             Iret = Dsgn + Dprp + max(TTLkey, TTLsig)
-
-   As before, Dsgn is the delay needed to ensure that all existing
-   RRsets have been signed with the new key, Dprp is the propagation
-   delay.  The final term (the maximum of TTLkey and TTLsig) is the
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 12]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   period to wait for key and signature data associated with key N to
-   expire from caches.  (TTLkey is the TTL of the DNSKEY RRset and
-   TTLsig is the maximum TTL of all the RRSIG records in the zone
-   created with the ZSK.  The two may be different as although the TTL
-   of an RRSIG is equal to the TTL of the RRs in the associated RRset
-   [RFC4034], the DNSKEY RRset only needs to be signed with the KSK.)
-
-   At the end of this interval, key N is said to be dead.  This occurs
-   at the dead time (Tdea) so:
-
-             Tdea = Tret + Iret
-
-   Event 5: at some later time key N and its signatures can be removed
-   from the zone.  This is the removal time Trem, given by:
-
-             Trem >= Tdea
-
-3.2.3.  Double-RRSIG Method
-
-   The timeline for a double-signature rollover is shown below.  The
-   diagram follows the convention described in Section 3.2.1
-
-
-
-            |1||2|      |3| |4||5|       |6|       |7||8|      |9| |10|
-             |  |        |   |  |         |         |  |        |   |
-     Key N   |  |<-Dsgn->|   |  |<--------Lzsk-------->|<-Iret->|   |
-             |  |<---IpubG-->|  |         |         |  |        |   |
-             |  |        |   |  |         |         |  |        |   |
-     Key N+1 |  |        |   |  |         |<-IpubG->|  |        |   |
-             |  |        |   |  |         |         |  |        |   |
-          Tgen Tpub        Trdy Tact    TpubS    TrdyS Tret   Tdea Trem
-
-                                ---- Time ---->
-
-
-          Figure 3: Timeline for a Double-Signature ZSK rollover.
-
-   Event 1: key N is generated at the generate time (Tgen).  Although
-   there is no reason why the key cannot be generated immediately prior
-   to its publication in the zone (Event 2), some implementations may
-   find it convenient to create a pool of keys in one operation and draw
-   from that pool as required.  For this reason, it is shown as a
-   separate event.  Keys that are available for use but not published
-   are said to be generated.
-
-   Event 2: key N is used to sign the zone but existing signatures are
-   retained.  Although the new ZSK is not published in the zone at this
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 13]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   point, for analogy with the other ZSK rollover methods and because
-   this is the first time that key information is visible (albeit
-   indirectly through the created signatures) this time is called the
-   publication time (Tpub).
-
-   Event 3: after the signing interval, Dsgn, all RRsets that need to be
-   signed have been signed by the new key.  (As a result, all these
-   RRsets are now signed twice, once by the (still-absent) key N and
-   once by its predecessor.
-
-   Event 4: there is now a delay while the old signature information
-   expires from caches.  This interval is given by the expression:
-
-             Dprp + TTLsig
-
-   As before, Dprp is the propagation delay and TTLsig is the maximum
-   TTL of all the RRSIG records in the zone.
-
-   Again in analogy with other key rollover methods, this is defined as
-   key N's ready time (Trdy) and the key is said to be in the ready
-   state.  (Although the key is not in the zone, it is ready to be
-   used.)  The interval between the publication and ready times is the
-   publication interval of the signature, IpubG, i.e.
-
-             Trdy = Tpub + IpubG
-
-   where
-
-             IpubG = Dsgn + Dprp + TTLsig
-
-   Event 5: at some later time the predecessor key is removed and the
-   key N added to the DNSKEY RRset.  As all the signed RRs have
-   signatures created by the old and new keys, the records can still be
-   authenticated.  This time is the activation time (Tact) and the key
-   is now said to be active.
-
-   Event 6: at some point thought must be given to rolling the key.  The
-   first step is to publish signatures created by the successor key (key
-   N+1) early enough for key N to be replaced after it has been active
-   for its scheduled lifetime.  This occurs at TpubS (the publication
-   time of the successor), given by:
-
-             TpubS <= Tact + Lzsk - IpubG
-
-   Event 7: the signatures have propagated and the new key could be
-   added to the zone.  This time is the ready time of the successor key
-   (TrdyS).
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 14]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-             TrdyS = TpubS + IpubG
-
-   ... where IpubG is as defined above.
-
-   Event 8: at some later time key N is removed from the zone and the
-   successor key (key N+1) added.  This is the retire time of the key
-   (Tret).
-
-   Event 9: the signatures must remain in the zone for long enough that
-   the new DNSKEY RRset has had enough time to propagate to all caches.
-   Once caches contain the new DNSKEY, the old signatures are no longer
-   of use and can be considered to be dead.  The time at which this as
-   they can not be validated by any key.  In analogy with other rollover
-   methods, the time at which this occurs is the dead time (Tdea), given
-   by:
-
-             Tdea = Tret + Iret
-
-   ... where Iret is the retire interval, given by:
-
-             Iret = Dprp + TTLkey
-
-   Dprp is as defined earlier and TTLkey is the TTL of the DNSKEY RRset.
-
-   Event 10: at some later time the signatures can be removed from the
-   zone.  In analogy with other rollover methods this time is called the
-   remove time (Trem) and is given by:
-
-             Trem >= Tdea
-
-3.3.  Key-Signing Key Rollover Timelines
-
-   The following sections describe the rolling of a KSK.  They show the
-   events in the lifetime of a key (referred to as "key N") and cover it
-   replacement by its successor (key N+1).
-
-3.3.1.  Double-Signature Method
-
-   The timeline for a double-signature rollover is shown below.  The
-   diagram follows the convention described in Section 3.2.1
-
-
-
-
-
-
-
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 15]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-                   |1|  |2|      |3|   |4|      |5|
-                    |    |        |     |        |
-        Key N       |    |<-Ipub->|<--->|<-Dreg->|<-----Lksk--- - -
-                    |    |        |     |        |
-        Key N+1     |    |        |     |        |
-                    |    |        |     |        |
-                   Tgen Tpub     Trdy  Tsub    Tact
-
-                            ---- Time ---->
-
-        (continued...)
-
-                    |6|      |7|   |8|      |9|      |10|    |11|
-                     |        |     |        |        |       |
-        Key N   - - -------------Lksk------->|<-Iret->|       |
-                     |        |     |        |        |       |
-        Key N+1      |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - -
-                     |        |     |        |        |       |
-                   TpubS    TrdyS  TsubS   Tret      Tdea     Trem
-
-                        ---- Time (cont) ---->
-
-
-          Figure 4: Timeline for a Double-Signature KSK rollover.
-
-   Event 1: key N is generated at the generate time (Tgen).  Although
-   there is no reason why the key cannot be generated immediately prior
-   to its publication in the zone (Event 2), some implementations may
-   find it convenient to create a pool of keys in one operation and draw
-   from that pool as required.  For this reason, it is shown as a
-   separate event.  Keys that are available for use but not published
-   are said to be generated.
-
-   Event 2: key N is introduced into the zone; it is added to the DNSKEY
-   RRset, which is then signed by key N and all currently active KSKs.
-   (So at this point, the DNSKEY RRset is signed by both key N and its
-   predecessor KSK.  If other KSKs were active, it is signed by these as
-   well.)  This is the publication time (Tpub); after this the key is
-   said to be published.
-
-   Event 3: before it can be used, the key must be published for long
-   enough to guarantee that any validating resolver that has a copy of
-   the DNSKEY RRset in its cache will have a copy of the RRset that
-   includes this key: in other words, that any prior cached information
-   about the DNSKEY RRset has expired.
-
-   The interval is the publication interval (Ipub) and, for the second
-   or subsequent KSKs in the zone, is given by:
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 16]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-             Ipub = DprpC + TTLkey
-
-   ... where DprpC is the propagation delay for the child zone (the zone
-   containing the KSK being rolled) and TTLkey the TTL for the DNSKEY
-   RRset.  The time at which this occurs is the key's ready time, Trdy,
-   given by:
-
-             Trdy = Tpub + Ipub
-
-   (The case of introducing the first KSK into the zone is discussed in
-   Section 3.3.5.)
-
-   Event 4: at some later time, the DS record corresponding to the new
-   KSK is submitted to the parent zone for publication.  This time is
-   the submission time, Tsub.
-
-   Event 5: the DS record is published in the parent zone.  As this is
-   the point at which all information for authentication - both DNSKEY
-   and DS record - is available in the two zones, in analogy with other
-   rollover methods, this is called the activation time of the key
-   (Tact):
-
-             Tact = Tsub + Dreg
-
-   ... where Dreg is the registration delay, the time taken after the DS
-   record has been received by the parent zone manager for it to be
-   placed in the zone.  (Parent zones are often managed by different
-   entities, and this term accounts for the organisational overhead of
-   transferring a record.)
-
-   Event 6: while key N is active, thought needs to be given to its
-   successor (key N+1).  At some time before the scheduled end of the
-   KSK lifetime, the successor KSK is published in the zone.  (As
-   before, this means that the DNSKEY RRset is signed by both the
-   current and successor KSK.)  This time is the publication time of the
-   successor key, TpubS, given by:
-
-             TpubS <= Tact + Lksk - Dreg - Ipub
-
-   ... where Lksk is the scheduled lifetime of the KSK.
-
-   Event 7: after an interval Ipub, key N+1 becomes ready (in that all
-   caches that have a copy of the DNSKEY RRset have a copy of this key).
-   This time is the ready time of the successor (TrdyS).
-
-   Event 8: at the submission time of the successor (TsubS), the DS
-   record corresponding to key N+1 is submitted to the parent zone.
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 17]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   Event 9: the successor DS record is published in the parent zone and
-   the current DS record withdrawn.  The current key is said to be
-   retired and the time at which this occurs is Tret, given by:
-
-             Tret = Tact + Lksk
-
-   Event 10: key N must remain in the zone until any caches that contain
-   a copy of the DS RRset have a copy containing the new DS record.
-   This interval is the retire interval, given by:
-
-             Iret = DprpP + TTLds
-
-   ... where DprpP is the propagation delay in the parent zone and TTLds
-   the TTL of a DS record in the parent zone.
-
-   As the key is no longer used for anything, is said to be dead.  This
-   point is the dead time (Tdea), given by:
-
-             Tdea = Tret + Iret
-
-   Event 11: at some later time, key N is removed from the zone (at the
-   remove time Trem); the key is now said to be removed.
-
-             Trem >= Tdea
-
-3.3.2.  Double-DS Method
-
-   The timeline for a double-DS rollover is shown below.  The diagram
-   follows the convention described in Section 3.2.1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 18]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-             |1|  |2|      |3|       |4|  |5|    |6|
-              |    |        |         |    |      |
-      Key N   |    |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - -
-              |    |        |         |    |      |
-      Key N+1 |    |        |         |    |<---->|<--Dreg+IpubP- - -
-              |    |        |         |    |      |
-             Tgen Tsub     Tpub      Trdy Tact  TsubS
-
-                              ---- Time ---->
-
-       (continued...)
-
-                               |7|   |8|      |9|    |10|
-                                |     |        |      |
-      Key N   - - -----Lksk---------->|<-Iret->|      |
-                                |     |        |      |
-      Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - -
-                                |     |        |      |
-                              TrdyS  Tret    Tdea    Trem
-
-                              ---- Time ---->
-
-
-             Figure 5: Timeline for a Double-DS KSK rollover.
-
-   Event 1: key N is generated at the generate time (Tgen).  Although
-   there is no reason why the key cannot be generated immediately prior
-   to its publication in the zone (Event 2), some implementations may
-   find it convenient to create a pool of keys in one operation and draw
-   from that pool as required.  For this reason, it is shown as a
-   separate event.  Keys that are available for use but not published
-   are said to be generated.
-
-   Event 2: the DS RR is submitted to the parent zone for publication.
-   This time is the submission time, Tsub.
-
-   Event 3: after the registration delay, Dreg, the DS record is
-   published in the parent zone.  This is the publication time Tpub,
-   given by:
-
-             Tpub = Tsub + Dreg
-
-   Event 4: at some later time, any cache that has a copy of the DS
-   RRset will have a copy of the DS record for key N. At this point, key
-   N, if introduced into the DNSKEY RRset, could be used to validate the
-   zone.  For this reason, this time is known as the key's ready time,
-   Trdy, and is given by:
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 19]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-             Trdy = Tpub + IpubP
-
-   IpubP is the parent publication interval and is given by the
-   expression:
-
-             IpubP = DprpP + TTLds
-
-   ... where DprpP is the propagation delay for the parent zone and
-   TTLds the TTL assigned to DS records in that zone.
-
-   Event 5: at some later time, the key rollover takes place and the new
-   key (key N) introduced and used to sign the RRset.
-
-   As both the old and new DS records have been in the parent zone long
-   enough to ensure that they are in caches that contain the DS RRset,
-   the zone can be authenticated throughout the rollover - either the
-   resolver has a copy of the DNSKEY RRset authenticated by the
-   predecessor key, or it has a copy of the updated RRset authenticated
-   with the new key.
-
-   This time is key N's activation time (Tact) and at this point the key
-   is said to be active.
-
-   Event 6: at some point thought must be given to key replacement.  The
-   DS record for the successor key must be submitted to the parent zone
-   at a time such that when the current key is withdrawn, any cache that
-   contains the zone's DS records have data about the DS record of the
-   successor key.  The time at which this occurs is the submission time
-   of the successor, given by:
-
-             TsubS <= Tact + Lksk - IpubP - Dreg
-
-   ... where Lksk is the lifetime of key N according to policy.
-
-   Event 7: the successor key (key N+1) enters the ready state i.e. its
-   DS record is now in caches that contain the parent DS RRset.  This is
-   the ready time of the successor key, TrdyS.
-
-   (The interval between events 6 and 7 for the key N+1 correspond to
-   the the interval between events 2 and 4 for key N)
-
-   Event 8: when key N has been active for its lifetime (Lksk), it is
-   removed from the DNSKEY RRset and key N+1 added; the RRset is then
-   signed with the new key.  This is the retire time of the key, Tret,
-   given by:
-
-
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 20]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-             Tret = Tact + Lksk
-
-   Event 9: at some later time, all copies of the old DNSKEY RRset have
-   expired from caches and the old DS record is no longer needed.  In
-   analogy with other rollover methods, this is called the dead time,
-   Tdea, and is given by:
-
-             Tdea = Tret + Iret
-
-   ... where Iret is the retire interval, given by:
-
-             Iret = DprpC + TTLkey
-
-   As before, this term includes DprpC, the time taken to propagate the
-   RRset change through the master-slave hierarchy of the child zone and
-   TTLkey, the time taken for the DNSKEY RRset to expire from caches.
-
-   Event 10: at some later time, the DS record is removed from the
-   parent zone.  In analogy with other rollover methods, this is the
-   removal time (Trem), given by:
-
-             Trem >= Tdea
-
-3.3.3.  Double-RRset Method
-
-   The timeline for a double-RRset rollover is shown below.  The diagram
-   follows the convention described in Section 3.2.1
-
-
-
-                    |1|  |2|      |3|     |4|      |5|      |6|
-                     |    |        |       |        |        |
-             Key N   |    |<-Ipub->|<-----Lksk----->|        |
-                     |    |        |       |        |        |
-             Key N+1 |    |        |       |<-Ipub->|        |
-                     |    |        |       |        |        |
-                   Tgen  Tpub    Tact    TpubS     Tret    Trem
-
-                                 ---- Time ---->
-
-
-            Figure 6: Timeline for a Double-RRset KSK rollover.
-
-   Event 1: key N is generated at the generate time (Tgen).  Although
-   there is no reason why the key cannot be generated immediately prior
-   to its publication in the zone (Event 2), some implementations may
-   find it convenient to create a pool of keys in one operation and draw
-   from that pool as required.  For this reason, it is shown as a
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 21]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   separate event.  Keys that are available for use but not published
-   are said to be generated.
-
-   Event 2: the key is added to and used for signing the DNSKEY RRset
-   and is thereby published in the zone.  At the same time the
-   corresponding DS record is submitted to the parent zone for
-   publication.  This time is the publish time (Tpub) and the key is now
-   said to be published.
-
-   Event 3: at some later time, the DS record is published in the parent
-   zone and at some time after that, the updated information has reached
-   all caches: any cache that holds a DNSKEY RRset from the child zone
-   will have a copy that includes the new KSK, and any cache that has a
-   copy of the parent DS RRset will have a copy that includes the new DS
-   record.
-
-   The time at which this occurs is called the activation time of the
-   new KSK (Tact), given by:
-
-             Tact = Tpub + Ipub
-
-   ... where Ipub is the publication interval, given by:
-
-             Ipub = max(IpubP, IpubC),
-
-   IpubP being the publication interval in the parent zone and IpubC the
-   publication interval in the child zone.  The parent zone's
-   publication interval is given by:
-
-             IpubP = Dreg + DprpP + TTLds
-
-   where Dreg is the registration delay, the time taken for the DS
-   record to be published in the parent zone.  DprpP is the parent
-   zone's propagation delay and TTLds is the TTL of the DS record in
-   that zone.
-
-   The child's publication interval is given by a similar equation:
-
-             IpubC = DprpC + TTLkey
-
-   ... where DprpC is the propagation delay in the child zone and TTLkey
-   the TTL of a DNSKEY record.
-
-   Event 4: at some point we need to give thought to key replacement.
-   The successor key (key N+1) must be introduced into the zone (and its
-   DS record submitted to the parent) at a time such that it becomes
-   active when the current key has been active for its lifetime, Lksk.
-   This time is TpubS, the publication time of the successor key, and is
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 22]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   given by:
-
-             TpubS <= Tact + Lksk - Ipub
-
-   ... where Lksk is the lifetime of the KSK.
-
-   Event 5: key N+1's DNSKEY and DS records are in any caches that
-   contain the child zone DNSKEY and/or the parent zone DS RR, and so
-   the zone can be validated with the new key.  This is the activation
-   time of the successor key (TactS) and by analogy with other rollover
-   methods, it is also the retire time of the current key.  Since at
-   this time the zone can be validated by the successor key, there is no
-   reason to keep the current key in the zone and the time can also be
-   regarded as the current key's dead time.  Thus:
-
-             Tret = Tdea = TactS = Tact + Lksk
-
-   Event 6: at some later time, the key N's DS and DNSKEY records can be
-   removed from their respective zones.  In analogy with other rollover
-   methods, this is the removal time (Trem), given by:
-
-             Trem >= Tdea
-
-3.3.4.  Interaction with Configured Trust Anchors
-
-   Although the preceding sections have been concerned with rolling KSKs
-   where the trust anchor is a DS record in the parent zone, zone
-   managers may want to take account of the possibility that some
-   validating resolvers may have configured trust anchors directly.
-
-   Rolling a configured trust anchor is dealt with in [RFC5011].  It
-   requires introducing the KSK to be used as the trust anchor into the
-   zone for a period of time before use, and retaining it (with the
-   "revoke" bit set) for some time after use.
-
-3.3.4.1.  Addition of KSK
-
-   When the new key is introduced, the publication interval (Ipub) in
-   the Double-Signature and Double-RRset methods should also be subject
-   to the condition:
-
-             Ipub >= Dprp + max(30 days, TTLkey)
-
-   ... where the right hand side of the expression is the time taken for
-   the change to propagate to all nameservers for the zone plus the add
-   hold-down time defined in section 2.4.1 of [RFC5011].
-
-   In the Double-DS method, instead of the changing of the KSK RR being
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 23]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   instantaneous, there must now be a period of overlap.  In other
-   words, the new KSK must be introduced into the zone at least:
-
-             DprpC + max(30 days, TTLkey)
-
-   ... before the switch is made.
-
-3.3.4.2.  Removal of KSK
-
-   The timeline for the removal of the key in all methods is modified by
-   introducing a new state, "revoked".  When the key reaches its dead
-   time, instead of being declared "dead", it is revoked; the "revoke"
-   bit is set on the DNSKEY RR and is published in (and used to sign)
-   the DNSKEY RRset.  The key is maintained in this state for the
-   "revoke" interval, Irev, given by:
-
-             Irev >= 30 days
-
-   ... 30 days being the [RFC5011] remove hold-down time.  After this
-   time, the key is dead and can be removed from the zone.
-
-3.3.5.  Introduction of First KSK
-
-   There is an additional consideration when introducing a KSK into a
-   zone for the first time, and that is that no validating resolver
-   should be in a position where it can access the trust anchor before
-   the KSK appears in the zone.  To do so will cause it to declare the
-   zone to be bogus.
-
-   This is important: in the case of a secure parent, it means ensuring
-   that the DS record is not published in the parent zone until there is
-   no possibility that a validating resolver can obtain the record yet
-   not be able to obtain the corresponding DNSKEY.  In the case of an
-   insecure parent, i.e. the initial creation of a new security apex, it
-   is not possible to guarantee this.  It is up to the operator of the
-   validating resolver to wait for the new KSK to appear at all servers
-   for the zone before configuring the trust anchor.
-
-
-4.  Standby Keys
-
-   Although keys will usually be rolled according to some regular
-   schedule, there may be occasions when an emergency rollover is
-   required, e.g. if the active key is suspected of being compromised.
-   The aim of the emergency rollover is to allow the zone to be re-
-   signed with a new key as soon as possible.  As a key must be in the
-   ready state to sign the zone, having at least one additional key (a
-   standby key) in this state at all times will minimise delay.
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 24]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   In the case of a ZSK, a standby key only really makes sense with the
-   Pre-Publication method.  A permanent standby DNSKEY RR should be
-   included in zone or successor keys could be introduced as soon as
-   possible after a key becomes active.  Either way results in one or
-   more additional ZSKs in the DNSKEY RRset that can immediately be used
-   to sign the zone if the current key is compromised.
-
-   (Although in theory the mechanism could be used with both the Double-
-   Signature and Double-RRSIG methods, it would require pre-publication
-   of the signatures.  Essentially, the standby key would be permanently
-   active, as it would have to be periodically used to renew signatures.
-   Zones would also permanently require two sets of signatures.)
-
-   It is also possible to have a standby KSK.  The Double-Signature
-   method requires that the standby KSK be included in the DNSKEY RRset;
-   rolling the key then requires just the introduction of the DS record
-   in the parent.  Note that the standby KSK should also be used to sign
-   the DNSKEY RRset.  As the RRset and its signatures travel together,
-   merely adding the KSK without using it to sign the DNSKEY RRset does
-   not provide the desired time saving: for a KSK to be used in a
-   rollover the DNSKEY RRset must be signed with it, and this would
-   introduce a delay while the old RRset (not signed with the new key)
-   expires from caches.
-
-   The idea of a standby KSK in the Double-RRset rollover method
-   effectively means having two active keys (as the standby KSK and
-   associated DS record would both be published at the same time in
-   their respective zones).
-
-   Finally, in the Double-DS method of rolling a KSK, it is not a
-   standby key that is present, it is a standby DS record in the parent
-   zone.
-
-   Whatever algorithm is used, the standby item of data can be included
-   in the zone on a permanent basis, or be a successor introduced as
-   early as possible.
-
-
-5.  Algorithm Considerations
-
-   The preceding sections have implicitly assumed that all keys and
-   signatures are created using a single algorithm.  However, [RFC4035]
-   (section 2.4) states that "There MUST be an RRSIG for each RRset
-   using at least one DNSKEY of each algorithm in the zone apex DNSKEY
-   RRset".
-
-   Except in the case of an algorithm rollover - where the algorithms
-   used to create the signatures are being changed - there is no
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 25]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   relationship between the keys of different algorithms.  This means
-   that they can be rolled independently of one another.  In other
-   words, the key rollover logic described above should be run
-   separately for each algorithm; the union of the results is included
-   in the zone, which is signed using the active key for each algorithm.
-
-
-6.  Limitation of Scope
-
-   This document represents current thinking at the time of publication.
-   However, the subject matter is evolving and it is more than likely
-   that this document will need to be revised in the future.
-
-   Some of the techniques and ideas that DNSSEC operators considering
-   differ from this those described in this document.  Of note are
-   alternatives to the strict split into KSK and ZSK key roles and the
-   consequences for rollover logic from partial signing (i.e. when the
-   new key initially only signs a fraction of the zone while leaving
-   other signatures generated by the old key in place).
-
-   Furthermore, as noted in section 5, this document covers only rolling
-   keys of the same algorithm, it does not cover transition to/from/
-   addition/deletion of different algorithms.  Algorithm rollovers will
-   require a separate document.
-
-   The reader is therefore reminded that DNSSEC is as of publication in
-   early stages of deployment, and best practices may further develop
-   over time.
-
-
-7.  Summary
-
-   For ZSKs, "Pre-Publication" is generally considered to be the
-   preferred way of rolling keys.  As shown in this document, the time
-   taken to roll is wholly dependent on parameters under the control of
-   the zone manager.
-
-   In contrast, "Double-RRset" is the most efficient method for KSK
-   rollover due to the ability to have new DS records and DNSKEY RRsets
-   propagate in parallel.  The time taken to roll KSKs may depend on
-   factors related to the parent zone if the parent is signed.  For
-   zones that intend to comply with the recommendations of [RFC5011], in
-   virtually all cases the rollover time will be determined by the
-   RFC5011 "add hold-down" and "remove hold-down" times.  It should be
-   emphasized that this delay is a policy choice and not a function of
-   timing values and that it also requires changes to the rollover
-   process due to the need to manage revocation of trust anchors.
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 26]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   Finally, the treatment of emergency key rollover is significantly
-   simplified by the introduction of standby keys as standard practice
-   during all types of rollovers.
-
-
-8.  IANA Considerations
-
-   This memo includes no request to IANA.
-
-
-9.  Security Considerations
-
-   This document does not introduce any new security issues beyond those
-   already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011].
-
-
-10.  Acknowledgements
-
-   The authors gratefully acknowledge help and contributions from Roy
-   Arends, Matthijs Mekking and Wouter Wijngaards.
-
-
-11.  Change History (To be removed on publication)
-
-   o  draft-ietf-dnsop-dnssec-key-timing-02
-      * Significant re-wording of some sections.
-      * Removal of events noting change of state of predecessor key from
-      ZSK Double-RRSIG and Double-Signature methods.
-      * Change order of bullet points (and some wording) in section 1.1.
-      * Remove discussion of advantages and disadvantages of key roll
-      methods from section 2: draft is informative and does not give
-      recommendations.
-      * Removal of discussion of upper limit to retire time relationship
-      to signature lifetime.
-      * Remove timing details of first key in the zone and move
-      discussion of first signing of a zone to later in the document).
-      (Matthijs Mekking)
-      * Removal of redundant symbols from Appendix A.
-
-   o  draft-ietf-dnsop-dnssec-key-timing-01
-      * Added section on limitation of scope.
-
-   o  draft-ietf-dnsop-dnssec-key-timing-00
-      * Change to author contact details.
-
-   o  draft-morris-dnsop-dnssec-key-timing-02
-      * General restructuring.
-      * Added descriptions of more rollovers (IETF-76 meeting).
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 27]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-      * Improved description of key states and removed diagram.
-      * Provided simpler description of standby keys.
-      * Added section concerning first key in a zone.
-      * Moved [RFC5011] to a separate section.
-      * Various nits fixed (Alfred Hoenes, Jeremy Reed, Scott Rose, Sion
-      Lloyd, Tony Finch).
-
-   o  draft-morris-dnsop-dnssec-key-timing-01
-      * Use latest boilerplate for IPR text.
-      * List different ways to roll a KSK (acknowledgements to Mark
-      Andrews).
-      * Restructure to concentrate on key timing, not management
-      procedures.
-      * Change symbol notation (Diane Davidowicz and others).
-      * Added key state transition diagram (Diane Davidowicz).
-      * Corrected spelling, formatting, grammatical and style errors
-      (Diane Davidowicz, Alfred Hoenes and Jinmei Tatuya).
-      * Added note that in the case of multiple algorithms, the
-      signatures and rollovers for each algorithm can be considered as
-      more or less independent (Alfred Hoenes).
-      * Take account of the fact that signing a zone is not atomic
-      (Chris Thompson).
-      * Add section contrasting pre-publication rollover with double
-      signature rollover (Matthijs Mekking).
-      * Retained distinction between first and subsequent keys in
-      definition of initial publication interval (Matthijs Mekking).
-
-   o  draft-morris-dnsop-dnssec-key-timing-00
-      Initial draft.
-
-
-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.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 28]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-              Extensions", RFC 4035, March 2005.
-
-   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
-              Trust Anchors", RFC 5011, September 2007.
-
-12.2.  Informative References
-
-   [RFC4641]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
-              RFC 4641, September 2006.
-
-
-Appendix A.  List of Symbols
-
-   The document defines a number of symbols, all of which are listed
-   here.  All are of the form:
-
-   All symbols used in the text are of the form:
-
-             <TYPE><id><INST>
-
-   where:
-
-   <TYPE> is an upper-case character indicating what type the symbol is.
-   Defined types are:
-
-   D         delay: interval that is a feature of the process
-
-   I         interval between two events
-
-   L         lifetime: interval set by the zone manager
-
-   T         a point in time
-
-   TTL       TTL of a record
-
-   I and T and TTL are self-explanatory.  Like I, D, and L are time
-   periods, but whereas I values are intervals between two events (even
-   if the events are defined in terms of the interval, e.g. the dead
-   time occurs "retire interval" after the retire time), D, and L are
-   fixed intervals: a "D" interval (delay) is a feature of the process,
-   probably outside control of the zone manager, whereas an "L" interval
-   (lifetime) is chosen by the zone manager and is a feature of policy.
-
-   <id> is lower-case and defines what object or event the variable is
-   related to, e.g.
-
-
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 29]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   act       activation
-
-   pub       publication
-
-   ret       retire
-
-   Finally, <INST> is a capital letter that distinguishes between the
-   same variable applying to different instances of an object and is one
-   of:
-
-   C         child
-
-   G         signature
-
-   K         key
-
-   P         parent
-
-   S         successor
-
-   The list of variables used in the text is:
-
-   Dprp      Propagation delay.  The amount of time for a change made at
-             a master nameserver to propagate to all the slave
-             nameservers.
-
-   DprpC     Propagation delay in the child zone.
-
-   DprpP     Propagation delay in the parent zone.
-
-   Dreg      Registration delay: the time taken for a DS record
-             submitted to a parent zone to appear in it.  As a parent
-             zone is often managed by a different organisation to that
-             managing the child zone, the delays associated with passing
-             data between zones is captured by this term.
-
-   Dsgn      Signing delay.  After the introduction of a new ZSK, the
-             amount of time taken for all the RRs in the zone to be
-             signed with it.
-
-   Ipub      Publication interval.  The amount of time that must elapse
-             after the publication of a key before it can be assumed
-             that any resolvers that have the DNSKEY RRset cached have a
-             copy of this key.
-
-
-
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 30]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   IpubC     Publication interval in the child zone.
-
-   IpubG     Publication interval for the signature created by a ZSK:
-             the amount of time that must elapse after the signature has
-             been created before it can be assumed that any resolves
-             that have the RRset and RRSIG cached have a copy of this
-             signature.
-
-   IpubP     Publication interval in the parent zone.
-
-   Iret      Retire interval.  The amount of time that must elapse after
-             a key enters the retire state for any signatures created
-             with it to be purged from validating resolver caches.
-
-   Irev      Revoke interval.  The amount of time that a KSK must remain
-             published with the revoke bit set to satisfy [RFC5011]
-             considerations.
-
-   Lksk      Lifetime of a key-signing key.  This is the intended amount
-             of time for which this particular KSK is regarded as the
-             active KSK.  Depending on when the key is rolled-over, the
-             actual lifetime may be longer or shorter than this.
-
-   Lzsk      Lifetime of a zone-signing key.  This is the intended
-             amount of time for which the ZSK is used to sign the zone.
-             Depending on when the key is rolled-over, the actual
-             lifetime may be longer or shorter than this.
-
-   Tact      Activation time of the key; the time at which the key is
-             regarded as the principal key for the zone.
-
-   TactS     Activation time of the successor key.
-
-   Tdea      Dead time of a key.  Applicable only to ZSKs, this is the
-             time at which any record signatures held in validating
-             resolver caches are guaranteed to be created with the
-             successor key.
-
-   Tgen      Generate time of a key.  The time that a key is created.
-
-   Tpub      Publication time of a key.  The time that a key appears in
-             a zone for the first time.
-
-   TpubS     Publication time of the successor key.
-
-
-
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 31]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   Trem      Removal time of a key.  The time at which a key is removed
-             from the zone.
-
-   Tret      Retire time of a key.  The time at which a successor key
-             starts being used to sign the zone.
-
-   Trdy      Ready time of a key.  The time at which it can be
-             guaranteed that validating resolvers that have key
-             information from this zone cached have a copy of this key
-             in their cache.  (In the case of KSKs, should the
-             validating resolvers also have DS information from the
-             parent zone cached, the cache must include information
-             about the DS record corresponding to the key.)
-
-   TrdyS     Ready time of a successor key.
-
-   Tsub      Submission time - the time at which the DS record of a KSK
-             is submitted to the parent.
-
-   TsubS     Submission time of the successor key.
-
-   TTLds     Time to live of a DS record (in the parent zone).
-
-   TTLkey    Time to live of a DNSKEY record.
-
-   TTLsig    The maximum time to live of all the RRSIG records in the
-             zone that were created with the ZSK.
-
-
-Authors' Addresses
-
-   Stephen Morris
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   Phone: +1 650 423 1300
-   Email: stephen@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 32]
-
-Internet-Draft      DNSSEC Key Timing Considerations          March 2011
-
-
-   Johan Ihren
-   Netnod
-   Franzengatan 5
-   Stockholm,   SE-112 51
-   Sweden
-
-   Phone: +46 8615 8573
-   Email: johani@autonomica.se
-
-
-   John Dickinson
-   Sinodun Internet Technologies Ltd
-   Stables 4 Suite 11, Howbery Park
-   Wallingford, Oxfordshire  OX10 8BA
-   UK
-
-   Phone: +44 1491 818120
-   Email: jad@sinodun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Morris, et al.         Expires September 11, 2011              [Page 33]
-
diff --git a/doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt b/doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt
deleted file mode 100644
index c06705b0..00000000
--- a/doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-
-Domain Name System Operations                              W. Wijngaards
-Internet-Draft                                                O. Kolkman
-Intended status: Standards Track                              NLnet Labs
-Expires: August 26, 2010                               February 22, 2010
-
-
-                  DNSSEC Trust Anchor History Service
-                draft-ietf-dnsop-dnssec-trust-history-01
-
-Abstract
-
-   When DNS validators have trusted keys, but have been offline for a
-   longer period, key rollover will fail and they are stuck with stale
-   trust anchors.  History service allows validators to query for older
-   DNSKEY RRsets and pick up the rollover trail where they left off.
-
-Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-Status of This Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 26, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 1]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-1.  Introduction
-
-   This memo defines a trust history service for DNS validators -- the
-   component in a resolver that performs DNSSEC [RFC4034] validation,
-   validator for short.
-
-   A validator that has been offline or missed an (emergency) rollover
-   can use this service to reconfigure themselves with the current
-   trust-anchor.  Using a newly defined resource record (RR) that links
-   old DNSKEYS together, the TALINK RR, a validator fetches old DNSKEY
-   RRsets and checks they form a chain to the latest key (see
-   Section 2).  The lists of old DNSKEYS, linked with the TALINK RRs, do
-   not necessarily need to be published in the zone for which the DNSKEY
-   history is being maintained but can be published in any DNS domain.
-   We will call the entity that offers the trust history the History
-   Provider.  The choice of the History Provider is made by the
-   maintainer of the validator, possibly based on a hint provided, using
-   the TALINK, by the zone owner.
-
-   The algorithm that the validator uses to construct a history and
-   reconfigure a new key is detailed in Section 3.  The algorithms for
-   how providers of trust history can fetch the DNSKEY data as published
-   by the zone they track and publish that are explained in Section 4.
-
-2.  The  TALINK Resource Record
-
-   The DNS Resource Record type TALINK (decimal 58) ties the elements of
-   a linked list of DNSKEY RRs together.
-
-   The rdata consists of two domain names.  The first name is the start,
-   or previous name, and the other name the end or next name in the
-   list.  The empty label '.' is used at the endpoints of the list.
-
-   The presentation format is the two domain names.  The wire encoding
-   is the two domain names, with no compression so the type can be
-   treated according to [RFC3597].  The list is a double linked list,
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 2]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-   because this empowers low memory hosts to perform consistency checks.
-
-3.  Trust History Lookup
-
-   This is the algorithm that a validator uses to detect and resolve the
-   situation in which a trust-anchor is out of sync with the DNSKEYs
-   published by a zone owner.  The algorithm uses the TALINK RR type
-   which is used to link various old DNSKEYs as published by the History
-   Provider, to arrive from the outdated configured Trust Anchor to one
-   that matches the current DNSKEY.  The TALINK RR type is defined in
-   Section 2.
-
-   When the algorithm below results in failure the trust history cannot
-   be build and a new trust anchor will need to be re-configured using
-   another mechanism.
-
-   Step 1:  The validator performs a DNSKEY lookup to the target zone,
-      which looks like any other initial DNSKEY lookup that the
-      validator needs to match a trust anchor to the currently used
-      DNSKEY RR set.  If the keyset verifies with the trust anchor
-      currently held, the trust-anchor is not out of sync.  Otherwise,
-      store the DNSKEY RR set as result.  The algorithm will
-      successfully build a linked list to this DNSKEY RR, or delete the
-      trust point, or fail.
-
-      All nameservers (the ones authoritative for the zone or the
-      upstream resolver caches when the validator is not full resolver)
-      SHOULD be checked to make sure the DNSKEY RR sets are the same.
-      The results can differ if a key-rollover is in progress and not
-      all nameservers are in sync yet.  This case can be detected by
-      checking that the older keyset signs the newer and take the newer
-      as result keyset.  The keysets are distinguished by the average
-      over the middle of the inception and expiration dates of the
-      signatures that are validated by the keyset itself.  Otherwise,
-      the history lookup fails.  If the check fails then the
-      inconsistency may be the result of spoofing, or compromise of
-      (DNS) infrastructure elements.
-
-   Step 2:  Fetch the trust history list end points.  Perform a query of
-      QTYPE TALINK and QNAME the domain name that is configured to be
-      the History Provider for the particular domain you are trying to
-      update the trust-anchor for.
-
-   Step 3:  Go backwards through the trust history list as provided by
-      the TALINK linked list.  Verify that the keyset validly signs the
-      next keyset.  This is [RFC4034] validation, but the RRSIG
-      expiration date is ignored.  [Editor note: Are we shure that there
-      are no server implementations that will not serve expired RRSIG,
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 3]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-      are such 'smart' servers allowed by the specs?  In other words do
-      we need clarification in the DNSSEC-updates document?]  Replace
-      the owner domain name with the target zone name for verification.
-      One of the keys that signs the next keyset MUST have the SEP bit
-      set.  The middle of inception and expiration date from the valid
-      signature MUST be older than that of the signature that validates
-      the next keys in the list.  Query type TALINK to get previous and
-      next locations.
-
-      If all SEP keys have the REVOKE flag set at this step, and the
-      keyset is signed by all SEP keys, then continue but store that the
-      end result is that the trust point is deleted, see Section 5
-      [RFC5011].
-
-      If all SEP keys are of an unknown algorithm at this step, continue
-      and at the next step, when you verify if the keyset signs validly:
-      if false, continue with result a failure, if true, continue with
-      the end result that the trust point is deleted.  Thus, the keysets
-      with unknown algorithms are stepped over with an end result of
-      failure because the validator cannot determine if unknown
-      algorithm signatures are valid, until the oldest keyset with
-      unknown algorithms is signed by a known algorithm and the result
-      is set to deletion and step 3 continues to a known key.
-
-   Step 4:  When the trust anchor currently held by the validator
-      verifies the keyset, the algorithm is done.  The validator SHOULD
-      store the result on stable storage.  Use the new trust anchor for
-      validation (if using [RFC5011], put it in state VALID).
-
-4.  Trust History Tracker
-
-   External trackers can poll the target zone DNSKEY RRset regularly.
-   Ignore date changes in the RRSIG.  Ignore changes to keys with no SEP
-   flag.  Copy the newly polled DNSKEY RRset and RRSIGs, change the
-   owner name to a new name at the history location.  Publish the new
-   RRset and TALINK records to make it the last element in the list.
-   Update the TALINK that advertises the first and last name.
-
-   Integrated into the rollover, the keys are stored in the history and
-   the TALINK is updated when a new key is used in the rollover process.
-   This gives the TALINK and new historical key time to propagate.
-
-   The signer can support trust history.  Trust history key sets need
-   only contain SEP keys.  To use older signers, move historical RRSIGs
-   to another file.  Sign the zone, including the TALINK and DNSKEY
-   records.  Append the historical RRSIGs to the result.  Signing the
-   zone like this obviates the need for changes to signer and server
-   software.
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 4]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-5.  Example
-
-   In this example example.com is the History Provider for example.net.
-   The DNSKEY rdata and RRSIG rdata is omitted for brevity, it is a copy
-   and paste of the data from example.net.
-
-   $ORIGIN example.com.
-   example.com. TALINK h0.example.com. h2.example.com.
-
-   h0 TALINK . h1.example.com.
-   h0 DNSKEY ...
-   h0 RRSIG ...
-
-   h1 TALINK h0.example.com. h2.example.com.
-   h1 DNSKEY ...
-   h1 RRSIG ...
-
-   h2 TALINK h1.example.com. .
-   h2 DNSKEY ...
-   h2 RRSIG ...
-
-   The example.net zone can advertise the example.com History Provider
-   by providing the TALINK shown here at example.com at the apex of the
-   example.net zone.  The TALINK at example.com is then not needed.
-
-6.  Deployment
-
-   The trust history is advertised with TALINK RRs at the zone apex.
-   These represent alternative history sources, that can be searched in
-   turn.  The TALINK at the zone apex contains the first and last name
-   of the list of historical keys.
-
-   The historical list of keys grows perpetually.  Since most validators
-   have recent keys, their processing time remains similar as the list
-   grows.  If validators no longer have trust in the keys then they need
-   no longer be published.  The oldest key entries can be omitted from
-   the list to shorten it.
-
-   The validator decides how long it trusts a key.  A recommendation
-   from the zone owner can be configured for keys of that zone, or
-   recommendations per algorithm and key size can be used (e.g. see
-   [NIST800-57]).  If a key is older than that, trust history lookup
-   fails with it and the trust point can be considered deleted.  This
-   assumes the validator has decided on a security policy and also can
-   take actions when the update of the trust anchor fails.  Without such
-   policy, or if the alternative is no DNSSEC, the approach below can be
-   used.
-
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 5]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-   In general, the decision can be that any key - no matter how old or
-   how small - is better than no security.  The validator then never
-   considers a key too old, and the lookup algorithm becomes an
-   unsecured update mechanism at the time where the key can be trivially
-   broken.  The history provider SHOULD provide these broken keys to
-   facilitate clients performing the unsecured update.  If a key can not
-   be trivially broken then it provides a non-trivial amount of security
-   that the history lookup algorithm uses to get the current keys.
-   Conceivably after the update the result is stored on stable storage
-   and the client is thereafter safe - it performs a leap of faith.  The
-   validator operator can opt for this set up after considering the
-   trade-off between loss of DNSSEC, loss of connectivity, and the
-   argument that perceived security is worse than no security.
-
-   The history lookup can be used on its own.  Then, the trust history
-   is used whenever the key rolls over and no polling is performed.
-   This has associated risks, in that the immediate rollover without
-   timeout that it provides could be abused, and certainly when taken
-   together with leap-of-faith such systems SHOULD inform their user
-   that the key has changed and urge them to do immediate checks.
-   Initially we put a hold down timer on such rollovers to mitigate the
-   abuse risks but these make following normal rollovers impossible.
-
-   If a validator is also using [RFC5011] for the target zone, then the
-   trust history algorithm SHOULD only be invoked if the [RFC5011]
-   algorithm failed due to the inability to perform probes.  This is the
-   case when the last [RFC5011] successful probe was more than 30 days
-   ago.  If a new key has been announced, invoke the history if no 2
-   probes succeeded during the add hold-down time and there was no
-   successful probe after the add hold-down time passed.  Therefore the
-   time of the last successful probe MUST be stored on stable storage.
-
-   For testing the potentially very infrequently used lookup, the
-   following SHOULD be implemented.  For the test the lookup is
-   triggered manually by allowing the system to be given a particular
-   keyset with a last successful lookup date in the past and a test
-   History Provider.  The test History Provider provides access to a
-   generated back-dated test history.
-
-7.  Security Considerations
-
-   The History Provider only provides copies of old data.  If that
-   historic data is altered or withheld the lookup algorithm fails
-   because of validation errors in Step 3 of the algorithm.  If the
-   History provider or a Man in the Middle Adversary (MIMA) has access
-   to the original private keys (through theft, cryptanalisis, or
-   otherwise), history can be altered without failure of the algorithm.
-   Below we only consider MIMAs and assume the History Provider is a
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 6]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-   trusted party.
-
-   Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of
-   TALINK and DNSKEY data, can present some alternate history.  However
-   the DNSKEY RR set trusted that the history should arrive at is
-   already fixed by step 1.  If an attempt is made to subvert the
-   algorithm at step 2 or 3, then the result keyset can not be replaced
-   by another keyset unnoticed.
-
-   To change the keyset trusted as the outcome, the step 1 data has to
-   be spoofed and the key held by the validator (or a newer historic
-   key) has to be compromised.  Unless such spoof is targeted to a
-   specific victim, a spoof of the step 1 result has a high visibility.
-   Since most of the validators that receive the spoof have an up-to-
-   date trust anchor most validators that would receive this spoof
-   return validation failure for data from the zone that contains the
-   DNSKEYs.  An adversary will therefore have to target the attack to
-   validators that are in the process of an update.  Since validators do
-   not announce that they use trust history lookup until step 2
-   adversaries will not be able to select the validators.
-
-   A spoof of data in steps 2 and 3, together with a compromised (old)
-   key, can result in a downgrade.  At steps 2 and 3 a faked trust point
-   deletion or algorithm rollover can be inserted in a fake history.
-   This avoids the high visibility of spoofing the current key (see
-   previous paragraph) and downgrades to insecure.
-
-   Finally there is the case that one of the keys published by the
-   History Providers has been compromised.  Since someone spoofing at
-   step 1 of the lookup algorithm and presenting some fake history to a
-   compromised key, of course does not include key revocations and does
-   extend the history to contain the compromised key, it therefore is
-   not really useful for a History Provider to remove the key from the
-   published history.  That only makes lookups fail for those validators
-   who are not under attack.  Useful action could be to update
-   validators using some other means.
-
-   Rollover with [RFC5011] revokes keys after use.  If a History
-   Provider is used, then such revoked keys SHOULD be used to perform
-   history tracking and history lookup.  The old keys that the validator
-   starts with and final current keys MUST NOT be trusted if they are
-   revoked.
-
-   Depending on choices by the validator operator, it may accept a leap-
-   of-faith, and possibly allow non-hold-down rollovers.  Although this
-   allows very fast emergency rollover if all clients are known to do
-   trust-history lookups without the RFC5011-algorithm, it also allows
-   an attacker with the private key to attempt to take over a zone
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 7]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-   quickly and get validators to roll to a trust anchor of the
-   attacker's choosing.
-
-   The SEP bit is checked to make sure that control over the KSK is
-   necessary to change the keyset for the target zone.
-
-   The algorithm can be used to get the inception and expiration times
-   of signatures on the current keyset, a clock.  A MIMA can attempt to
-   shorten history and put back that clock, but the algorithm attempts
-   to make this difficult to target and highly visible to others.
-
-   If the clock of the validator can be influenced, then setting it
-   forward is unlikely to give advantage, but setting it backward
-   enables a replay attack of old DNSSEC data and signatures.  This
-   vulnerability exists also in plain DNSSEC.
-
-8.  IANA Considerations
-
-   Resource record type TALINK has been defined using RFC5395 expert
-   review, it has RR type number 58 (decimal).
-
-9.  Acknowledgments
-
-   Thanks to the people who provided review and suggestions, Joe Abley,
-   George Barwood, Edward Lewis, Michael StJohns, Bert Hubert, Mark
-   Andrews, Ted Lemon, Steve Crocker, Bill Manning, Eric Osterweil,
-   Wolfgang Nagele, Alfred Hoenes, Olafur Gudmundsson, Roy Arends and
-   Matthijs Mekking.
-
-10.  References
-
-10.1.  Informative References
-
-   [NIST800-57]  Barker, E., Barker, W., Burr, W., Polk, W., and M.
-                 Smid, "Recommendations for Key Management", NIST
-                 SP 800-57, March 2007.
-
-   [RFC5011]     StJohns, M., "Automated Updates of DNS Security
-                 (DNSSEC) Trust Anchors", RFC 5011, September 2007.
-
-10.2.  Normative References
-
-   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
-                 Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3597]     Gustafsson, A., "Handling of Unknown DNS Resource
-                 Record (RR) Types", RFC 3597, September 2003.
-
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 8]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-   [RFC4034]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
-                 Rose, "Resource Records for the DNS Security
-                 Extensions", RFC 4034, March 2005.
-
-Authors' Addresses
-
-   Wouter Wijngaards
-   NLnet Labs
-   Science Park 140
-   Amsterdam  1098 XG
-   The Netherlands
-
-   EMail: wouter@nlnetlabs.nl
-
-
-   Olaf Kolkman
-   NLnet Labs
-   Science Park 140
-   Amsterdam  1098 XG
-   The Netherlands
-
-   EMail: olaf@nlnetlabs.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 9]
-
diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
deleted file mode 100644
index bcd0d14e..00000000
--- a/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
+++ /dev/null
@@ -1,396 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                                  D. Senie
-Category: BCP                                     Amaranth Networks Inc.
-Expires in six months                                          July 2005
-
-               Encouraging the use of DNS IN-ADDR Mapping
-		    draft-ietf-dnsop-inaddr-required-07.txt 
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-Abstract
-
-   Mapping of addresses to names has been a feature of DNS.  Many sites,
-   implement it, many others don't.  Some applications attempt to use it
-   as a part of a security strategy. The goal of this document is to
-   encourage proper deployment of address to name mappings, and provide
-   guidance for their use.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society. (2005)
-
-1. Introduction
-
-   The Domain Name Service has provision for providing mapping of IP
-   addresses to host names. It is common practice to ensure both name to
-   address, and address to name mappings are provided for networks. This
-   practice, while documented, has never been required, though it is
-   generally encouraged.  This document both encourages the presence of
-
-
-
-Senie                                                           [Page 1]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   these mappings and discourages reliance on such mappings for security
-   checks.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-2. Discussion
-
-
-   From the early days of the Domain Name Service [RFC883] a special
-   domain has been set aside for resolving mappings of IP addresses to
-   domain names.  This was refined in [RFC1035], describing the .IN-
-   ADDR.ARPA in use today.  For the in the IPv6 address space, .IP6.ARPA
-   was added [RFC3152]. This document uses IPv4 CIDR block sizes and
-   allocation strategy where there are differences and uses IPv4
-   terminology.  Aside from these differences, this document can and
-   should be applied to both address spaces.
-
-   The assignment of blocks of IP address space was delegated to three
-   regional registries. Guidelines for the registries are specified in
-   [RFC2050], which requires regional registries to maintain IN-ADDR
-   records on the large blocks of space issued to ISPs and others.
-
-   ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
-   allocations. For smaller allocations, ARIN can provide IN-ADDR for
-   /24 and shorter prefixes. [ARIN].  APNIC provides methods for ISPs to
-   update IN-ADDR, however the present version of its policy document
-   for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
-   copies of this document. As of this writing, it appears APNIC has no
-   actual policy on IN-ADDR.  RIPE appears to have the strongest policy
-   in this area [RIPE302] indicating Local Internet Registries should
-   provide IN-ADDR services, and delegate those as appropriate when
-   address blocks are delegated.
-
-   As we can see, the regional registries have their own policies for
-   recommendations and/or requirements for IN-ADDR maintenance. It
-   should be noted, however, that many address blocks were allocated
-   before the creation of the regional registries, and thus it is
-   unclear whether any of the policies of the registries are binding on
-   those who hold blocks from that era.
-
-   Registries allocate address blocks on CIDR [RFC1519] boundaries.
-   Unfortunately the IN-ADDR zones are based on classful allocations.
-   Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
-   exist, but are not always implemented.
-
-3. Examples of impact of missing IN-ADDR
-
-
-
-Senie                                                           [Page 2]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   These are some examples of problems that may be introduced by
-   reliance on IN-ADDR.
-
-   Some applications use DNS lookups for security checks. To ensure
-   validity of claimed names, some applications will look up IN-ADDR
-   records to get names, and then look up the resultant name to see if
-   it maps back to the address originally known. Failure to resolve
-   matching names is seen as a potential security concern.
-
-   Some FTP sites will flat-out reject users, even for anonymous FTP, if
-   the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
-   itself resolved, does not match. Some Telnet servers also implement
-   this check.
-
-   Web sites are in some cases using IN-ADDR checks to verify whether
-   the client is located within a certain geopolitical entity. This
-   approach has been employed for downloads of crypto software, for
-   example, where export of that software is prohibited to some locales.
-   Credit card anti-fraud systems also use these methods for geographic
-   placement purposes.
-
-   The popular TCP Wrappers program found on most Unix and Linux systems
-   has options to enforce IN-ADDR checks and to reject any client that
-   does not resolve. This program also has a way to check to see that
-   the name given by a PTR record then resolves back to the same IP
-   address. This method provdes more comfort but no appreciable
-   additional security.
-
-   Some anti-spam (anti junk email) systems use IN-ADDR to verify the
-   presence of a PTR record, or validate the PTR value points back to
-   the same address.
-
-   Many web servers look up the IN-ADDR of visitors to be used in log
-   analysis.  This adds to the server load, but in the case of IN-ADDR
-   unavailability, it can lead to delayed responses for users.
-
-   Traceroutes with descriptive IN-ADDR naming proves useful when
-   debugging problems spanning large areas. When this information is
-   missing, the traceroutes take longer, and it takes additional steps
-   to determine that network is the cause of problems.
-
-   Wider-scale implementation of IN-ADDR on dialup, wireless access and
-   other such client-oriented portions of the Internet would result in
-   lower latency for queries (due to lack of negative caching), and
-   lower name server load and DNS traffic.
-
-4. Recommendations
-
-
-
-
-Senie                                                           [Page 3]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   4.1 Delegation Recommendations
-
-
-   Regional Registries and any Local Registries to whom they delegate
-   should establish and convey a policy to those to whom they delegate
-   blocks that IN-ADDR mappings are recommended.  Policies should
-   recommend those receiving delegations to provide IN-ADDR service
-   and/or delegate to downstream customers.
-
-   Network operators should define and implement policies and procedures
-   which delegate IN-ADDR to their clients who wish to run their own IN-
-   ADDR DNS services, and provide IN-ADDR services for those who do not
-   have the resources to do it themselves.  Delegation mechanisms should
-   permit the downstream customer to implement and comply with IETF
-   recommendations application of IN-ADDR to CIDR [RFC2317].
-
-   All IP address space assigned and in use should be resolved by IN-
-   ADDR records. All PTR records must use canonical names.
-
-   All IP addresses in use within a block should have an IN-ADDR
-   mapping. Those addresses not in use, and those that are not valid for
-   use (zeros or ones broadcast addresses within a CIDR block) need not
-   have mappings.
-
-   It should be noted that due to CIDR, many addresses that appear to be
-   otherwise valid host addresses may actually be zeroes or ones
-   broadcast addresses. As such, attempting to audit a site's degree of
-   compliance may only be done with knowledge of the internal subnet
-   architecture of the site.  It can be assumed, however, any host that
-   originates an IP packet necessarily will have a valid host address,
-   and must therefore have an IN-ADDR mapping.
-
-4.2 Application Recommendations
-
-
-   Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
-   of IN-ADDR, sometimes in conjunction with a lookup of the name
-   resulting from the PTR record provides no real security, can lead to
-   erroneous results and generally just increases load on DNS servers.
-   Further, in cases where address block holders fail to properly
-   configure IN-ADDR, users of those blocks are penalized.
-
-5. Security Considerations
-
-   This document has no negative impact on security. While it could be
-   argued that lack of PTR record capabilities provides a degree of
-   anonymity, this is really not valid. Trace routes, whois lookups and
-   other sources will still provide methods for discovering identity.
-
-
-
-Senie                                                           [Page 4]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   By recommending applications avoid using IN-ADDR as a security
-   mechanism this document points out that this practice, despite its
-   use by many applications, is an ineffective form of security.
-   Applications should use better mechanisms of authentication.
-
-6. IANA Considerations
-
-   There are no IANA considerations for this document.
-
-7. References
-
-7.1 Normative References
-
-   [RFC883] P.V. Mockapetris, "Domain names: Implementation
-   specification," RFC883, November 1983.
-
-   [RFC1035] P.V. Mockapetris, "Domain Names: Implementation
-   Specification," RFC 1035, November 1987.
-
-   [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
-   an Address Assignment and Aggregation Strategy," RFC 1519, September
-   1993.
-
-   [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
-   RFC 2026, BCP 9, October 1996.
-
-   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
-   Requirement Levels", RFC 2119, BCP 14, March 1997.
-
-   [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
-   Guidelines", RFC2050, BCP 12, Novebmer 1996.
-
-   [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
-   RFC 2317, March 1998.
-
-   [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
-   2001.
-
-7.2 Informative References
-
-   [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
-   unknown, http://www.arin.net/regserv/initial-isp.html
-
-   [APNIC] "Policies For IPv4 Address Space Management in the Asia
-   Pacific Region," APNIC-086, 13 January 2003.
-
-   [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
-   Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
-
-
-
-Senie                                                           [Page 5]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   2004. http://www.ripe.net//ripe/docs/rev-del.html
-
-
-
-8. Acknowledgements
-
-   Thanks to Peter Koch and Gary Miller for their input, and to many
-   people who encouraged me to write this document.
-
-9. Author's Address
-
-   Daniel Senie
-   Amaranth Networks Inc.
-   324 Still River Road
-   Bolton, MA 01740
-
-   Phone: (978) 779-5100
-
-   EMail: dts@senie.com
-
-10.  Full Copyright Statement
-
-      Copyright (C) The Internet Society (2005).
-
-      This document is subject to the rights, licenses and restrictions
-      contained in BCP 78, and except as set forth therein, the authors
-      retain all their rights.
-
-      This document and the information contained herein are provided
-      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
-      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
-      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
-      EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
-      THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
-      ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
-      PARTICULAR PURPOSE.
-
-Intellectual Property
-
-      The IETF takes no position regarding the validity or scope of any
-      Intellectual Property Rights or other rights that might be claimed
-      to pertain to the implementation or use of the technology
-      described in this document or the extent to which any license
-      under such rights might or might not be available; nor does it
-      represent that it has made any independent effort to identify any
-      such rights.  Information on the procedures with respect to
-      rights in RFC documents can be found in BCP 78 and BCP 79.
-
-
-
-
-Senie                                                           [Page 6]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-      Copies of IPR disclosures made to the IETF Secretariat and any
-      assurances of licenses to be made available, or the result of an
-      attempt made to obtain a general license or permission for the use
-      of such proprietary rights by implementers or users of this
-      specification can be obtained from the IETF on-line IPR repository
-      at http://www.ietf.org/ipr.
-
-      The IETF invites any interested party to bring to its attention
-      any copyrights, patents or patent applications, or other
-      proprietary rights that may cover technology that may be required
-      to implement this standard.  Please address the information to the
-      IETF at ietf-ipr@ietf.org.
-
-      Internet-Drafts are working documents of the
-      Internet Engineering Task Force (IETF), its areas, and its
-      working groups. Note that other groups may also distribute
-      working documents as Internet-Drafts.
-
-      Internet-Drafts are draft documents valid for a maximum of
-      six months and may be updated, replaced, or obsoleted by
-      other documents at any time. It is inappropriate to use
-      Internet-Drafts as reference material or to cite them other
-      than as "work in progress."
-
-      The list of current Internet-Drafts can be accessed at
-      http://www.ietf.org/1id-abstracts.html
-
-      The list of Internet-Draft Shadow Directories can be
-      accessed at http://www.ietf.org/shadow.html
-
-Acknowledgement
-
-      Funding for the RFC Editor function is currently provided by the
-      Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Senie                                                           [Page 7]
-
diff --git a/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt b/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt
deleted file mode 100644
index f64e8dd5..00000000
--- a/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt
+++ /dev/null
@@ -1,952 +0,0 @@
-
-
-
-DNSOP                                                        W. Hardaker
-Internet-Draft                                              Sparta, Inc.
-Intended status: Informational                         February 12, 2009
-Expires: August 16, 2009
-
-
-        Requirements for Management of Name Servers for the DNS
-          draft-ietf-dnsop-name-server-management-reqs-02.txt
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 16, 2009.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.
-
-Abstract
-
-   Management of name servers for the Domain Name Service (DNS) has
-   traditionally been done using vendor-specific monitoring,
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 1]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   configuration and control methods.  Although some service monitoring
-   platforms can test the functionality of the DNS itself there is not a
-   interoperable way to manage (monitor, control and configure) the
-   internal aspects of a name server itself.
-
-   This document discusses the requirements of a management system for
-   DNS name servers.  A management solution that is designed to manage
-   the DNS can use this document as a shopping list of needed features.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  4
-       1.1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . .  5
-       1.1.2.  Document Layout and Requirements . . . . . . . . . . .  5
-   2.  Management Architecture Requirements . . . . . . . . . . . . .  5
-     2.1.  Expected Deployment Scenarios  . . . . . . . . . . . . . .  5
-       2.1.1.  Zone Size Constraints  . . . . . . . . . . . . . . . .  5
-       2.1.2.  Name Server Discovery  . . . . . . . . . . . . . . . .  6
-       2.1.3.  Configuration Data Volatility  . . . . . . . . . . . .  6
-       2.1.4.  Protocol Selection . . . . . . . . . . . . . . . . . .  6
-       2.1.5.  Common Data Model  . . . . . . . . . . . . . . . . . .  6
-       2.1.6.  Operational Impact . . . . . . . . . . . . . . . . . .  7
-     2.2.  Name Server Types  . . . . . . . . . . . . . . . . . . . .  7
-   3.  Management Operation Types . . . . . . . . . . . . . . . . . .  7
-     3.1.  Control Requirements . . . . . . . . . . . . . . . . . . .  8
-       3.1.1.  Needed Control Operations  . . . . . . . . . . . . . .  8
-       3.1.2.  Asynchronous Status Notifications  . . . . . . . . . .  8
-     3.2.  Configuration Requirements . . . . . . . . . . . . . . . .  9
-       3.2.1.  Served Zone Modification . . . . . . . . . . . . . . .  9
-       3.2.2.  Trust Anchor Management  . . . . . . . . . . . . . . .  9
-       3.2.3.  Security Expectations  . . . . . . . . . . . . . . . .  9
-       3.2.4.  TSIG Key Management  . . . . . . . . . . . . . . . . .  9
-       3.2.5.  DNS Protocol Authorization Management  . . . . . . . .  9
-     3.3.  Monitoring Requirements  . . . . . . . . . . . . . . . . . 10
-     3.4.  Alarm and Event Requirements . . . . . . . . . . . . . . . 10
-   4.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 11
-     4.1.  Authentication . . . . . . . . . . . . . . . . . . . . . . 11
-     4.2.  Integrity Protection . . . . . . . . . . . . . . . . . . . 11
-     4.3.  Confidentiality  . . . . . . . . . . . . . . . . . . . . . 11
-     4.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 11
-     4.5.  Solution Impacts on Security . . . . . . . . . . . . . . . 12
-   5.  Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
-     5.1.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . 12
-       5.1.1.  Vendor Extensions  . . . . . . . . . . . . . . . . . . 13
-       5.1.2.  Extension Identification . . . . . . . . . . . . . . . 13
-       5.1.3.  Name-Space Collision Protection  . . . . . . . . . . . 13
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 2]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
-   8.  Document History . . . . . . . . . . . . . . . . . . . . . . . 13
-   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
-   Appendix A.  Deployment Scenarios  . . . . . . . . . . . . . . . . 15
-     A.1.  Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
-     A.2.  Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
-     A.3.  DNSSEC Management  . . . . . . . . . . . . . . . . . . . . 16
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 3]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-1.  Introduction
-
-   Management of name servers for the Domain Name Service (DNS)
-   [RFC1034] [RFC1035] has traditionally been done using vendor-specific
-   monitoring, configuration and control methods.  Although some service
-   monitoring platforms can test the functionality of the DNS itself
-   there is not a interoperable way to manage (monitor, control and
-   configure) the internal aspects of a name server itself.
-
-   Previous standardization work within the IETF resulted in the
-   creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed
-   to achieve significant implementation and deployment.  The perceived
-   reasons behind the failure for the two MIB modules are further
-   documented in [RFC3197].
-
-   This document discusses the requirements of a management system for
-   DNS name servers.  A management solution that is designed to manage
-   the DNS can use this document as a shopping list of needed features.
-
-   Specifically out of scope for this document are requirements
-   associated with management of stub resolvers.  It is not the intent
-   of this document to document stub resolver requirements, although
-   some of the requirements listed are applicable to stub resolvers as
-   well.
-
-   Also out of scope for this document is management of the host or
-   other components of the host upon which the name server software is
-   running.  This document only discusses requirements for managing the
-   name server component of a system.
-
-   The task of creating a management system for managing DNS servers is
-   not expected to be a small one.  It is likely that components of the
-   solution will need to be designed in parts over time and these
-   requirements take this into consideration.  In particular,
-   Section 5.1 discusses the need for future extensibility of the base
-   management solution.  This document is intended to be a road-map
-   towards a desired outcome and is not intended to define an "all-or-
-   nothing" system.  Successful interoperable management of name servers
-   even in part is expected to be beneficial to network operators
-   compared to the entirely custom solutions that are used at the time
-   of this writing.
-
-1.1.  Requirements notation
-
-   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].
-
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 4]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-1.1.1.  Terminology
-
-   This document is consistent with the terminology defined in Section 2
-   of [RFC4033].  Additional terminology needed for this document is
-   described below:
-
-   Name Server:  When we are discussing servers that don't fall into a
-      more specific type of server category defined in other documents,
-      this document will refer to them generically as "name servers".
-      In particular "name servers" can be considered to be any valid
-      combination of authoritative, recursive, validating, or security-
-      aware.  The more specific name server labels will be used when
-      this document refers only to a specific type of server.  However,
-      the term "name server", in this document, will not include stub
-      resolvers.
-
-1.1.2.  Document Layout and Requirements
-
-   The document is written so that each numbered section will contain
-   only a single requirement if it contains one at all.  Each
-   requirement will contain needed wording from the terminology
-   described in Section 1.1.  Subsections, however, might exist with
-   additional related requirements.  The document is laid out in this
-   way so that a specific requirement can be uniquely referred to using
-   the section number itself and the document version from which it
-   came.
-
-
-2.  Management Architecture Requirements
-
-   This section discusses requirements that reflect the needs of the
-   expected deployment environments.
-
-2.1.  Expected Deployment Scenarios
-
-   DNS zones vary greatly in the type of content published within them.
-   Name Servers, too, are deployed with a wide variety of configurations
-   to support the diversity of the deployed content.  It is important
-   that a management solution trying to meet the criteria specified in
-   this document consider supporting the largest number of potential
-   deployment cases as possible.  Further deployment scenarios that are
-   not used as direct examples of specific requirements are listed in
-   Appendix A.
-
-2.1.1.  Zone Size Constraints
-
-   The management solution MUST support both name servers that are
-   serving a small number of potentially very large zones (e.g.  Top
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 5]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   Level Domains (TLDs)) as well as name servers that are serving a very
-   large number of small zones.  These scenarios are both commonly seen
-   deployments.
-
-2.1.2.  Name Server Discovery
-
-   Large enterprise network deployments may contain multiple name
-   servers operating within the boundaries of the enterprise network.
-   These name servers may each be serving multiple zones both in and out
-   of the parent enterprise's zone.  Finding and managing large
-   quantities of name servers would be a useful feature of the resulting
-   management solution.  The management solution MAY support the ability
-   to discover previously unknown instances of name servers operating
-   within a deployed network.
-
-2.1.3.  Configuration Data Volatility
-
-   Configuration data is defined as data that relates only to the
-   configuration of a server and the zones it serves.  It specifically
-   does not include data from the zone contents that is served through
-   DNS itself.  The solution MUST support servers that remain fairly
-   statically configured over time as well as servers that have numerous
-   zones being added and removed within an hour.  Both of these
-   scenarios are also commonly seen deployments.
-
-2.1.4.  Protocol Selection
-
-   There are many requirements in this document for many different types
-   of management operations (see Section 3 for further details).  It is
-   possible that no one protocol will ideally fill all the needs of the
-   requirements listed in this document and thus multiple protocols
-   might be needed to produce a completely functional management system.
-   Multiple protocols might be used to create the complete management
-   solution, but the number of protocols used SHOULD be reduced to a
-   reasonable minimum number.
-
-2.1.5.  Common Data Model
-
-   Defining a standardized protocol (or set of protocols) to use for
-   managing name servers would be a step forward in achieving an
-   interoperable management solution.  However, just defining a protocol
-   to use by itself would not achieve the complete end goal of a
-   complete interoperable management solution.  Devices also need to
-   represent their internal management interface using a common
-   management data model.  The solution MUST create a common data model
-   that management stations can make use of when sending or collecting
-   data from a managed device so it can successfully manage equipment
-   from vendors as if they were generic DNS servers.  This common data
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 6]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   model is needed for of the operations discussion in Section 3.  Note
-   that this does not preclude the fact that name server vendors might
-   provide additional management infrastructure beyond a base management
-   specification, as discussed further in Section 5.1.
-
-2.1.6.  Operational Impact
-
-   It is impossible to add new features to an existing server (such as
-   the inclusion of a management infrastructure) and not impact the
-   existing service and/or server in some fashion.  At a minimum, for
-   example, more memory, disk and/or CPU resources will be required to
-   implement a new management system.  However, the impact to the
-   existing DNS service MUST be minimized since the DNS service itself
-   is still the primary service to be offered by the modified name
-   server.
-
-2.2.  Name Server Types
-
-   There are multiple ways in which name servers can be deployed.  Name
-   servers can take on any of the following roles:
-
-   o  Master Servers
-
-   o  Slave Servers
-
-   o  Recursive Servers
-
-   The management solution SHOULD support all of these types of name
-   servers as they are all equally important.  Note that "Recursive
-   Servers" can be further broken down by the security sub-roles they
-   might implement, as defined in section 2 of [RFC4033].  These sub-
-   roles are also important to support within any management solution.
-
-   As stated earlier, the management of stub resolvers is considered out
-   of scope for this documents.
-
-
-3.  Management Operation Types
-
-   Management operations can traditionally be broken into four
-   categories:
-
-   o  Control
-
-   o  Configuration
-
-   o  Health and Monitoring
-
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 7]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   o  Alarms and Events
-
-   This section discusses requirements for each of these four management
-   types in detail.
-
-3.1.  Control Requirements
-
-   The management solution MUST be capable of performing basic service
-   control operations.
-
-3.1.1.  Needed Control Operations
-
-   These operations SHOULD include, at a minimum, the following
-   operations:
-
-   o  Starting the name server
-
-   o  Reloading the service configuration
-
-   o  Reloading zone data
-
-   o  Restarting the name server
-
-   o  Stopping the name server
-
-   Note that no restriction is placed on how the management system
-   implements these operations.  In particular, at least "starting the
-   name server" will require a minimal management system component to
-   exist independently of the name server itself.
-
-3.1.2.  Asynchronous Status Notifications
-
-   Some control operations might take a long time to complete.  As an
-   example, some name servers take a long time to perform reloads of
-   large zones.  Because of these timing issues, the management solution
-   SHOULD take this into consideration and offer a mechanism to ease the
-   burden associated with awaiting the status of a long-running command.
-   This could, for example, result in the use of asynchronous
-   notifications for returning the status of a long-running task or it
-   might require the management station to poll for the status of a
-   given task using monitoring commands.  These and other potential
-   solutions need to be evaluated carefully to select one that balances
-   the result delivery needs with the perceived implementation costs.
-
-   Also, see the related discussion in Section 3.4 on notification
-   messages for supporting delivery of alarm and event messages.
-
-
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 8]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-3.2.  Configuration Requirements
-
-   Many features of name servers need to be configured before the server
-   can be considered functional.  The management solution MUST be able
-   to provide name servers with configuration data.  The most important
-   data to be configured, for example, is the served zone data itself.
-
-3.2.1.  Served Zone Modification
-
-   The ability to add, modify and delete zones being served by name
-   servers is needed.  Although there are already solutions for zone
-   content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007],
-   AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that
-   might be used as part of the final management solution, the
-   management system SHOULD still be able to natively create a new zone
-   (with enough minimal data to allow the other mechanisms to function
-   as well) as well as delete a zone.  This might be, for example, a
-   management operation that at least allows for the creation of the
-   initial SOA record for a new zone as that's the minimum amount of
-   zone data needed for the other operations to function.
-
-3.2.2.  Trust Anchor Management
-
-   The solution SHOULD support the ability to add, modify and delete
-   trust anchors that are used by DNS Security (DNSSEC) [RFC4033]
-   [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155].  These trust
-   anchors might be configured using the data from the DNSKEY Resource
-   Records (RRs) themselves or by using Delegation Signer (DS)
-   fingerprints.
-
-3.2.3.  Security Expectations
-
-   DNSSEC Validating resolvers need to make policy decisions about the
-   requests being processed.  For example, they need to be configured
-   with a list of zones expected to be secured by DNSSEC.  The
-   management solution SHOULD be able to add, modify and delete
-   attributes of DNSSEC security policies.
-
-3.2.4.  TSIG Key Management
-
-   TSIG [RFC2845] allows transaction level authentication of DNS
-   traffic.  The management solution SHOULD be able to add, modify and
-   delete TSIG keys known to the name server.
-
-3.2.5.  DNS Protocol Authorization Management
-
-   The management solution SHOULD have the ability to add, modify and
-   delete authorization settings for the DNS protocols itself.  Do not
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 9]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   confuse this with the ability to manage the authorization associated
-   with the management protocol itself, which is discussed later in
-   Section 4.4.  There are a number of authorization settings that are
-   used by a name server.  Example authorization settings that the
-   solution might need to cover are:
-
-   o  Access to operations on zone data (e.g.  DDNS)
-
-   o  Access to certain zone data from certain sources (e.g. from
-      particular network subnets)
-
-   o  Access to specific DNS protocol services (e.g. recursive service)
-
-   Note: the above list is expected to be used as a collection of
-   examples and is not a complete list of needed authorization
-   protections.
-
-3.3.  Monitoring Requirements
-
-   Monitoring is the process of collecting aspects of the internal state
-   of a name server at a given moment in time.  The solution MUST be
-   able to monitor the health of a name server to determine its
-   operational status, load and other internal attributes.  Example
-   management tasks that the solution might need to cover are:
-
-   o  Number of requests sent, responses sent, average response latency
-      and other performance counters
-
-   o  Server status (e.g. "serving data", "starting up", "shutting
-      down", ...)
-
-   o  Access control violations
-
-   o  List of zones being served
-
-   o  Detailed statistics about clients interacting with the name server
-      (e.g. top 10 clients requesting data).
-
-   Note: the above list is expected to be used as a collection of
-   examples and is not a complete list of needed monitoring operations.
-   In particular, some monitoring statistics are expected to be
-   computationally or resource expensive and are considered to be "nice
-   to haves" as opposed to "necessary to have".
-
-3.4.  Alarm and Event Requirements
-
-   Events occurring at the name server that trigger alarm notifications
-   can quickly inform a management station about critical issues.  A
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 10]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   management solution SHOULD include support for delivery of alarm
-   conditions.
-
-   Example alarm conditions might include:
-
-   o  The server's status is changing. (e.g it is starting up, reloading
-      configuration, restarting or shutting down)
-
-   o  A needed resource (e.g. memory or disk space) is exhausted or
-      nearing exhaustion
-
-   o  An authorization violation was detected
-
-   o  The server has not received any data traffic (e.g.  DNS requests
-      or NOTIFYs) recently (AKA the "lonely warning").  This condition
-      might indicate a problem with its deployment.
-
-
-4.  Security Requirements
-
-   The management solution will need to be appropriately secured against
-   attacks on the management infrastructure.
-
-4.1.  Authentication
-
-   The solution MUST support mutual authentication.  The management
-   client needs to be assured that the management operations are being
-   transferred to and from the correct name server.  The managed name
-   server needs to authenticate the system that is accessing the
-   management infrastructure within itself.
-
-4.2.  Integrity Protection
-
-   Management operations MUST be protected from modification while in
-   transit from the management client to the server.
-
-4.3.  Confidentiality
-
-   The management solution MUST support message confidentiality.  The
-   potential transfer of sensitive configuration is expected (such as
-   TSIG keys or security policies).  The solution does not, however,
-   necessarily need to provide confidentiality to data that would
-   normally be carried without confidentiality by the DNS system itself.
-
-4.4.  Authorization
-
-   The solution SHOULD be capable of providing a fine-grained
-   authorization model for any management protocols it introduces to the
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 11]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   completed system.  This authorization differs from the authorization
-   previously discussed in Section 3.2.5 in that this requirement is
-   concerned solely with authorization of the management system itself.
-
-   There are a number of authorization settings that might be used by a
-   managed system to determine whether the managing entity has
-   authorization to perform the given management task.  Example
-   authorization settings that the solution might need to cover are:
-
-   o  Access to the configuration that specifies which zones are to be
-      served
-
-   o  Access to the management system infrastructure
-
-   o  Access to other control operations
-
-   o  Access to other configuration operations
-
-   o  Access to monitoring operations
-
-   Note: the above list is expected to be used as a collection of
-   examples and is not a complete list of needed authorization
-   protections.
-
-4.5.  Solution Impacts on Security
-
-   The solution MUST minimize the security risks introduced to the
-   complete name server system.  It is impossible to add new
-   infrastructure to a server and not impact the security in some
-   fashion as the introduction of a management protocol alone will
-   provide a new avenue for potential attack.  Although the added
-   management benefits will be worth the increased risks, the solution
-   still needs to minimize this impact as much as possible.
-
-
-5.  Other Requirements
-
-5.1.  Extensibility
-
-   The management solution is expected to change and expand over time as
-   lessons are learned and new DNS features are deployed.  Thus, the
-   solution MUST be flexible and be able to accommodate new future
-   management operations.  The solution might, for example, make use of
-   protocol versioning or capability description exchanges to ensure
-   that management stations and name servers that weren't written to the
-   same specification version can still interoperate to the best of
-   their combined ability.
-
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 12]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-5.1.1.  Vendor Extensions
-
-   It MUST be possible for vendors to extend the standardized management
-   model with vendor-specific extensions to support additional features
-   offered by their products.
-
-5.1.2.  Extension Identification
-
-   It MUST be possible for a management station to understand which
-   parts of returned data are specific to a given vendor or other
-   standardized extension.  The data returned needs to be appropriately
-   marked through the use of name spaces or similar mechanisms to ensure
-   that the base management model data can be logically separated from
-   extension data without needing to understand the extension data
-   itself.
-
-5.1.3.  Name-Space Collision Protection
-
-   It MUST be possible to protect against multiple extensions
-   conflicting with each other.  The use of name-space protection
-   mechanisms for communicated management variables is common practice
-   to protect against problems.  Name-space identification techniques
-   also frequently solve the "Extension Identification" requirement
-   discussed in Section 5.1.2 as well.
-
-
-6.  Security Considerations
-
-   Any management protocol that meets the criteria discussed in this
-   document needs to support the criteria discussed in Section 4 in
-   order to protect the management infrastructure itself.  The DNS is a
-   core Internet service and management traffic that protects it could
-   be the target of attacks designed to subvert that service.  Because
-   the management infrastructure will be adding additional interfaces to
-   that service, it is critical that the management infrastructure
-   support adequate protections against network attacks.
-
-
-7.  IANA Considerations
-
-   No action is required from IANA for this document.
-
-
-8.  Document History
-
-   A requirement gathering discussion was held at the December 2007 IETF
-   meeting in Vancouver, BC, Canada and a follow up meeting was held at
-   the March 2008 IETF meeting in Philadelphia.  This document is a
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 13]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   compilation of the results of those discussions as well as
-   discussions on the DCOMA mailing list.
-
-
-9.  Acknowledgments
-
-   This draft is the result of discussions within the DCOMA design team
-   chaired by Jaap Akkerhuis.  This team consisted of a large number of
-   people all of whom provided valuable insight and input into the
-   discussions surrounding name server management.  The text of this
-   document was written from notes taken during meetings as well as from
-   contributions sent to the DCOMA mailing list.  This work documents
-   the consensus of the DCOMA design team.
-
-   In particular, the following team members contributed significantly
-   to the text in the document:
-
-      Stephane Bortzmeyer
-
-      Stephen Morris
-
-      Phil Regnauld
-
-   Further editing contributions and wording suggestions were made by:
-   Alfred Hoenes.
-
-
-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.
-
-   [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.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 14]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-              Update", RFC 3007, November 2000.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
-              (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
-   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
-              Trust Anchors", RFC 5011, September 2007.
-
-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-              Security (DNSSEC) Hashed Authenticated Denial of
-              Existence", RFC 5155, March 2008.
-
-10.2.  Informative References
-
-   [RFC1611]  Austein, R. and J. Saperia, "DNS Server MIB Extensions",
-              RFC 1611, May 1994.
-
-   [RFC1612]  Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
-              RFC 1612, May 1994.
-
-   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
-              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
-              July 1997.
-
-   [RFC3197]  Austein, R., "Applicability Statement for DNS MIB
-              Extensions", RFC 3197, November 2001.
-
-
-Appendix A.  Deployment Scenarios
-
-   This appendix documents some additional deployment scenarios that
-   have been traditionally difficult to manage.  They are provided as
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 15]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   guidance to protocol developers as data points of real-world name
-   server management problems.
-
-A.1.  Non-Standard Zones
-
-   If an organization uses non-standard zones (for example a purely-
-   local TLD), synchronizing all the name servers for these zones is
-   usually a time-consuming task.  It is made worse when two
-   organizations with conflicting zones merge.  This situation is not a
-   recommended deployment scenario (and is even heavily discouraged) but
-   it is, unfortunately, seen in the wild.
-
-   It is typically implemented using "forwarding" zones.  But there is
-   no way to ensure automatically that all the resolvers have the same
-   set of zones to forward at any given time.  New zones might be added
-   to a local forwarding recursive server, for example, without
-   modifying the rest of the deployed forwarding servers.  It is hoped
-   that a management solution which could handle the configuration of
-   zone forwarding would finally allow management of servers deployed in
-   this fashion.
-
-A.2.  Redundancy Sharing
-
-   For reliability reasons it is recommended that zone operators follow
-   the guidelines documented in [RFC2182] which recommends that multiple
-   name servers be configured for each zone and that the name servers
-   are separated both physically and via connectivity routes.  A common
-   solution is to establish DNS-serving partnerships: "I'll host your
-   zones and you'll host mine".  Both entities benefit from increased
-   DNS reliability via the wider service distribution.  This frequently
-   occurs between cooperating but otherwise unrelated entities (such as
-   between two distinct companies) as well as between affiliated
-   organizations (such as between branch offices within a single
-   company).
-
-   The configuration of these relationships are currently required to be
-   manually configured and maintained.  Changes to the list of zones
-   that are cross-hosted are manually negotiated between the cooperating
-   network administrators and configured by hand.  A management protocol
-   with the ability to provide selective authorization, as discussed in
-   Section 4.4, would solve many of the management difficulties between
-   cooperating organizations.
-
-A.3.  DNSSEC Management
-
-   There are many different DNSSEC deployment strategies that may be
-   used for mission-critical zones.  The following list describes some
-   example deployment scenarios that might warrant different management
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 16]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   strategies.
-
-      All contents and DNSSEC keying information controlled and operated
-      by a single organization
-
-      Zone contents controlled and operated by one organization, all
-      DNSSEC keying information controlled and operated by a second
-      organization.
-
-      Zone contents controlled and operated by one organization, zone
-      signing keys (ZSKs) controlled and operated by a second
-      organization, and key signing keys (KSKs) controlled and operated
-      by a third organization.
-
-   Although this list is not exhaustive in the potential ways that zone
-   data can be divided up, it should be sufficient to illustrate the
-   potential ways in which zone data can be controlled by multiple
-   entities.
-
-   The end result of all of these strategies, however, will be the same:
-   a live zone containing DNSSEC related resource records.  Many of the
-   above strategies are merely different ways of preparing a zone for
-   serving.  A management solution that includes support for managing
-   DNSSEC zone data may wish to take into account these potential
-   management scenarios.
-
-
-Author's Address
-
-   Wes Hardaker
-   Sparta, Inc.
-   P.O. Box 382
-   Davis, CA  95617
-   US
-
-   Phone: +1 530 792 1913
-   Email: ietf@hardakers.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 17]
-
diff --git a/doc/draft/draft-ietf-dnsop-respsize-06.txt b/doc/draft/draft-ietf-dnsop-respsize-06.txt
deleted file mode 100644
index b041925a..00000000
--- a/doc/draft/draft-ietf-dnsop-respsize-06.txt
+++ /dev/null
@@ -1,640 +0,0 @@
-
-
-
-
-
-
-   DNSOP Working Group                                     Paul Vixie, ISC
-   INTERNET-DRAFT                                         Akira Kato, WIDE
-   <draft-ietf-dnsop-respsize-06.txt>                          August 2006
-
-                      DNS Referral Response Size Issues
-
-   Status of this Memo
-      By submitting this Internet-Draft, each author represents that any
-      applicable patent or other IPR claims of which he or she is aware
-      have been or will be disclosed, and any of which he or she becomes
-      aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-      Internet-Drafts are working documents of the Internet Engineering
-      Task Force (IETF), its areas, and its working groups.  Note that
-      other groups may also distribute working documents as Internet-
-      Drafts.
-
-      Internet-Drafts are draft documents valid for a maximum of six months
-      and may be updated, replaced, or obsoleted by other documents at any
-      time.  It is inappropriate to use Internet-Drafts as reference
-      material or to cite them other than as "work in progress."
-
-      The list of current Internet-Drafts can be accessed at
-      http://www.ietf.org/ietf/1id-abstracts.txt
-
-      The list of Internet-Draft Shadow Directories can be accessed at
-      http://www.ietf.org/shadow.html.
-
-   Copyright Notice
-
-      Copyright (C) The Internet Society (2006).  All Rights Reserved.
-
-
-
-
-                                    Abstract
-
-      With a mandated default minimum maximum message size of 512 octets,
-      the DNS protocol presents some special problems for zones wishing to
-      expose a moderate or high number of authority servers (NS RRs).  This
-      document explains the operational issues caused by, or related to
-      this response size limit, and suggests ways to optimize the use of
-      this limited space.  Guidance is offered to DNS server implementors
-      and to DNS zone operators.
-
-
-
-
-   Expires January 2007                                            [Page 1]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   1 - Introduction and Overview
-
-   1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
-   octets.  Even though this limitation was due to the required minimum IP
-   reassembly limit for IPv4, it became a hard DNS protocol limit and is
-   not implicitly relaxed by changes in transport, for example to IPv6.
-
-   1.2. The EDNS0 protocol extension (see [RFC2671 2.3, 4.5]) permits
-   larger responses by mutual agreement of the requester and responder.
-   The 512 octet message size limit will remain in practical effect until
-   there is widespread deployment of EDNS0 in DNS resolvers on the
-   Internet.
-
-   1.3. Since DNS responses include a copy of the request, the space
-   available for response data is somewhat less than the full 512 octets.
-   Negative responses are quite small, but for positive and delegation
-   responses, every octet must be carefully and sparingly allocated.  This
-   document specifically addresses delegation response sizes.
-
-   2 - Delegation Details
-
-   2.1. RELEVANT PROTOCOL ELEMENTS
-
-   2.1.1. A delegation response will include the following elements:
-
-      Header Section: fixed length (12 octets)
-      Question Section: original query (name, class, type)
-      Answer Section: empty, or a CNAME/DNAME chain
-      Authority Section: NS RRset (nameserver names)
-      Additional Section: A and AAAA RRsets (nameserver addresses)
-
-   2.1.2. If the total response size exceeds 512 octets, and if the data
-   that does not fit was "required", then the TC bit will be set
-   (indicating truncation).  This will usually cause the requester to retry
-   using TCP, depending on what information was desired and what
-   information was omitted.  For example, truncation in the authority
-   section is of no interest to a stub resolver who only plans to consume
-   the answer section.  If a retry using TCP is needed, the total cost of
-   the transaction is much higher.  See [RFC1123 6.1.3.2] for details on
-   the requirement that UDP be attempted before falling back to TCP.
-
-   2.1.3. RRsets are never sent partially unless TC bit set to indicate
-   truncation.  When TC bit is set, the final apparent RRset in the final
-   non-empty section must be considered "possibly damaged" (see [RFC1035
-   6.2], [RFC2181 9]).
-
-
-
-   Expires January 2007                                            [Page 2]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   2.1.4. With or without truncation, the glue present in the additional
-   data section should be considered "possibly incomplete", and requesters
-   should be prepared to re-query for any damaged or missing RRsets.  Note
-   that truncation of the additional data section might not be signalled
-   via the TC bit since additional data is often optional (see discussion
-   in [RFC4472 B]).
-
-   2.1.5. DNS label compression allows a domain name to be instantiated
-   only once per DNS message, and then referenced with a two-octet
-   "pointer" from other locations in that same DNS message (see [RFC1035
-   4.1.4]).  If all nameserver names in a message share a common parent
-   (for example, all ending in ".ROOT-SERVERS.NET"), then more space will
-   be available for incompressable data (such as nameserver addresses).
-
-   2.1.6. The query name can be as long as 255 octets of network data.  In
-   this worst case scenario, the question section will be 259 octets in
-   size, which would leave only 240 octets for the authority and additional
-   sections (after deducting 12 octets for the fixed length header.)
-
-   2.2. ADVICE TO ZONE OWNERS
-
-   2.2.1. Average and maximum question section sizes can be predicted by
-   the zone owner, since they will know what names actually exist, and can
-   measure which ones are queried for most often.  Note that if the zone
-   contains any wildcards, it is possible for maximum length queries to
-   require positive responses, but that it is reasonable to expect
-   truncation and TCP retry in that case.  For cost and performance
-   reasons, the majority of requests should be satisfied without truncation
-   or TCP retry.
-
-   2.2.2. Some queries to non-existing names can be large, but this is not
-   a problem because negative responses need not contain any answer,
-   authority or additional records.  See [RFC2308 2.1] for more information
-   about the format of negative responses.
-
-   2.2.3. The minimum useful number of name servers is two, for redundancy
-   (see [RFC1034 4.1]).  A zone's name servers should be reachable by all
-   IP transport protocols (e.g., IPv4 and IPv6) in common use.
-
-   2.2.4. The best case is no truncation at all.  This is because many
-   requesters will retry using TCP immediately, or will automatically re-
-   query for RRsets that are possibly truncated, without considering
-   whether the omitted data was actually necessary.
-
-
-
-
-
-   Expires January 2007                                            [Page 3]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   2.3. ADVICE TO SERVER IMPLEMENTORS
-
-   2.3.1. In case of multi-homed name servers, it is advantageous to
-   include an address record from each of several name servers before
-   including several address records for any one name server.  If address
-   records for more than one transport (for example, A and AAAA) are
-   available, then it is advantageous to include records of both types
-   early on, before the message is full.
-
-   2.3.2. Each added NS RR for a zone will add 12 fixed octets (name, type,
-   class, ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME).
-   Each A RR will require 16 octets, and each AAAA RR will require 28
-   octets.
-
-   2.3.3. While DNS distinguishes between necessary and optional resource
-   records, this distinction is according to protocol elements necessary to
-   signify facts, and takes no official notice of protocol content
-   necessary to ensure correct operation.  For example, a nameserver name
-   that is in or below the zone cut being described by a delegation is
-   "necessary content," since there is no way to reach that zone unless the
-   parent zone's delegation includes "glue records" describing that name
-   server's addresses.
-
-   2.3.4. It is also necessary to distinguish between "explicit truncation"
-   where a message could not contain enough records to convey its intended
-   meaning, and so the TC bit has been set, and "silent truncation", where
-   the message was not large enough to contain some records which were "not
-   required", and so the TC bit was not set.
-
-   2.3.5. A delegation response should prioritize glue records as follows.
-
-   first
-      All glue RRsets for one name server whose name is in or below the
-      zone being delegated, or which has multiple address RRsets (currently
-      A and AAAA), or preferably both;
-
-   second
-      Alternate between adding all glue RRsets for any name servers whose
-      names are in or below the zone being delegated, and all glue RRsets
-      for any name servers who have multiple address RRsets (currently A
-      and AAAA);
-
-   thence
-      All other glue RRsets, in any order.
-
-
-
-
-   Expires January 2007                                            [Page 4]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   Whenever there are multiple candidates for a position in this priority
-   scheme, one should be chosen on a round-robin or fully random basis.
-
-   The goal of this priority scheme is to offer "necessary" glue first,
-   avoiding silent truncation for this glue if possible.
-
-   2.3.6. If any "necessary content" is silently truncated, then it is
-   advisable that the TC bit be set in order to force a TCP retry, rather
-   than have the zone be unreachable.  Note that a parent server's proper
-   response to a query for in-child glue or below-child glue is a referral
-   rather than an answer, and that this referral MUST be able to contain
-   the in-child or below-child glue, and that in outlying cases, only EDNS
-   or TCP will be large enough to contain that data.
-
-   3 - Analysis
-
-   3.1. An instrumented protocol trace of a best case delegation response
-   follows.  Note that 13 servers are named, and 13 addresses are given.
-   This query was artificially designed to exactly reach the 512 octet
-   limit.
-
-      ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
-      ;; QUERY SECTION:
-      ;;  [23456789.123456789.123456789.\
-           123456789.123456789.123456789.com A IN]        ;; @80
-
-      ;; AUTHORITY SECTION:
-      com.                 86400 NS  E.GTLD-SERVERS.NET.  ;; @112
-      com.                 86400 NS  F.GTLD-SERVERS.NET.  ;; @128
-      com.                 86400 NS  G.GTLD-SERVERS.NET.  ;; @144
-      com.                 86400 NS  H.GTLD-SERVERS.NET.  ;; @160
-      com.                 86400 NS  I.GTLD-SERVERS.NET.  ;; @176
-      com.                 86400 NS  J.GTLD-SERVERS.NET.  ;; @192
-      com.                 86400 NS  K.GTLD-SERVERS.NET.  ;; @208
-      com.                 86400 NS  L.GTLD-SERVERS.NET.  ;; @224
-      com.                 86400 NS  M.GTLD-SERVERS.NET.  ;; @240
-      com.                 86400 NS  A.GTLD-SERVERS.NET.  ;; @256
-      com.                 86400 NS  B.GTLD-SERVERS.NET.  ;; @272
-      com.                 86400 NS  C.GTLD-SERVERS.NET.  ;; @288
-      com.                 86400 NS  D.GTLD-SERVERS.NET.  ;; @304
-
-
-
-
-
-
-
-
-   Expires January 2007                                            [Page 5]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-      ;; ADDITIONAL SECTION:
-      A.GTLD-SERVERS.NET.  86400 A   192.5.6.30           ;; @320
-      B.GTLD-SERVERS.NET.  86400 A   192.33.14.30         ;; @336
-      C.GTLD-SERVERS.NET.  86400 A   192.26.92.30         ;; @352
-      D.GTLD-SERVERS.NET.  86400 A   192.31.80.30         ;; @368
-      E.GTLD-SERVERS.NET.  86400 A   192.12.94.30         ;; @384
-      F.GTLD-SERVERS.NET.  86400 A   192.35.51.30         ;; @400
-      G.GTLD-SERVERS.NET.  86400 A   192.42.93.30         ;; @416
-      H.GTLD-SERVERS.NET.  86400 A   192.54.112.30        ;; @432
-      I.GTLD-SERVERS.NET.  86400 A   192.43.172.30        ;; @448
-      J.GTLD-SERVERS.NET.  86400 A   192.48.79.30         ;; @464
-      K.GTLD-SERVERS.NET.  86400 A   192.52.178.30        ;; @480
-      L.GTLD-SERVERS.NET.  86400 A   192.41.162.30        ;; @496
-      M.GTLD-SERVERS.NET.  86400 A   192.55.83.30         ;; @512
-
-      ;; MSG SIZE  sent: 80  rcvd: 512
-
-   3.2. For longer query names, the number of address records supplied will
-   be lower.  Furthermore, it is only by using a common parent name (which
-   is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
-   fit, due to the use of DNS compression pointers in the last 12
-   occurances of the parent domain name.  The following output from a
-   response simulator demonstrates these properties.
-
-      % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
-      a.dns.br requires 10 bytes
-      b.dns.br requires 4 bytes
-      c.dns.br requires 4 bytes
-      d.dns.br requires 4 bytes
-      # of NS: 4
-      For maximum size query (255 byte):
-          only A is considered:        # of A is 4 (green)
-          A and AAAA are considered:   # of A+AAAA is 3 (yellow)
-          preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
-      For average size query (64 byte):
-          only A is considered:        # of A is 4 (green)
-          A and AAAA are considered:   # of A+AAAA is 4 (green)
-          preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-
-
-
-
-
-
-
-
-
-   Expires January 2007                                            [Page 6]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-      % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
-      ns-ext.isc.org requires 16 bytes
-      ns.psg.com requires 12 bytes
-      ns.ripe.net requires 13 bytes
-      ns.eu.int requires 11 bytes
-      # of NS: 4
-      For maximum size query (255 byte):
-          only A is considered:        # of A is 4 (green)
-          A and AAAA are considered:   # of A+AAAA is 3 (yellow)
-          preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
-      For average size query (64 byte):
-          only A is considered:        # of A is 4 (green)
-          A and AAAA are considered:   # of A+AAAA is 4 (green)
-          preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-   (Note: The response simulator program is shown in Section 5.)
-
-   Here we use the term "green" if all address records could fit, or
-   "yellow" if two or more could fit, or "orange" if only one could fit, or
-   "red" if no address record could fit.  It's clear that without a common
-   parent for nameserver names, much space would be lost.  For these
-   examples we use an average/common name size of 15 octets, befitting our
-   assumption of GTLD-SERVERS.NET as our common parent name.
-
-   We're assuming a medium query name size of 64 since that is the typical
-   size seen in trace data at the time of this writing.  If
-   Internationalized Domain Name (IDN) or any other technology which
-   results in larger query names be deployed significantly in advance of
-   EDNS, then new measurements and new estimates will have to be made.
-
-   4 - Conclusions
-
-   4.1. The current practice of giving all nameserver names a common parent
-   (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
-   responses and allows for more nameservers to be enumerated than would
-   otherwise be possible, since the common parent domain name only appears
-   once in a DNS message and is referred to via "compression pointers"
-   thereafter.
-
-   4.2. If all nameserver names for a zone share a common parent, then it
-   is operationally advisable to make all servers for the zone thus served
-   also be authoritative for the zone of that common parent.  For example,
-   the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively
-   for the ROOT-SERVERS.NET.  This is to ensure that the zone's servers
-   always have the zone's nameservers' glue available when delegating, and
-
-
-
-   Expires January 2007                                            [Page 7]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   will be able to respond with answers rather than referrals if a
-   requester who wants that glue comes back asking for it.  In this case
-   the name server will likely be a "stealth server" -- authoritative but
-   unadvertised in the glue zone's NS RRset.  See [RFC1996 2] for more
-   information about stealth servers.
-
-   4.3. Thirteen (13) is the effective maximum number of nameserver names
-   usable traditional (non-extended) DNS, assuming a common parent domain
-   name, and given that implicit referral response truncation is
-   undesirable in the average case.
-
-   4.4. Multi-homing of name servers within a protocol family is
-   inadvisable since the necessary glue RRsets (A or AAAA) are atomically
-   indivisible, and will be larger than a single resource record.  Larger
-   RRsets are more likely to lead to or encounter truncation.
-
-   4.5. Multi-homing of name servers across protocol families is less
-   likely to lead to or encounter truncation, partly because multiprotocol
-   clients are more likely to speak EDNS which can use a larger response
-   size limit, and partly because the resource records (A and AAAA) are in
-   different RRsets and are therefore divisible from each other.
-
-   4.6. Name server names which are at or below the zone they serve are
-   more sensitive to referral response truncation, and glue records for
-   them should be considered "less optional" than other glue records, in
-   the assembly of referral responses.
-
-   4.7. If a zone is served by thirteen (13) name servers having a common
-   parent name (such as ?.ROOT-SERVERS.NET) and each such name server has a
-   single address record in some protocol family (e.g., an A RR), then all
-   thirteen name servers or any subset thereof could multi-home in a second
-   protocol family by adding a second address record (e.g., an AAAA RR)
-   without reducing the reachability of the zone thus served.
-
-   5 - Source Code
-
-   #!/usr/bin/perl
-   #
-   # SYNOPSIS
-   #    repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
-   #        if all queries are assumed to have a same zone suffix,
-   #     such as "jp" in JP TLD servers, specify it in -z option
-   #
-   use strict;
-   use Getopt::Std;
-
-
-
-   Expires January 2007                                            [Page 8]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   my ($sz_msg) = (512);
-   my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
-   my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
-   my (%namedb, $name, $nssect, %opts, $optz);
-   my $n_ns = 0;
-
-   getopt('z', %opts);
-   if (defined($opts{'z'})) {
-       server_name_len($opts{'z'}); # just register it
-   }
-
-   foreach $name (@ARGV) {
-       my $len;
-       $n_ns++;
-       $len = server_name_len($name);
-       print "$name requires $len bytes\n";
-       $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl
-               +  $sz_rdlen + $len;
-   }
-   print "# of NS: $n_ns\n";
-   arsect(255, $nssect, $n_ns, "maximum");
-   arsect(64, $nssect, $n_ns, "average");
-
-   sub server_name_len {
-       my ($name) = @_;
-       my (@labels, $len, $n, $suffix);
-
-       $name =~ tr/A-Z/a-z/;
-       @labels = split(/\./, $name);
-       $len = length(join('.', @labels)) + 2;
-       for ($n = 0; $#labels >= 0; $n++, shift @labels) {
-           $suffix = join('.', @labels);
-           return length($name) - length($suffix) + $sz_ptr
-               if (defined($namedb{$suffix}));
-           $namedb{$suffix} = 1;
-       }
-       return $len;
-   }
-
-   sub arsect {
-       my ($sz_query, $nssect, $n_ns, $cond) = @_;
-       my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
-       $ansect = $sz_query + 1 + $sz_type + $sz_class;
-       $space = $sz_msg - $sz_header - $ansect - $nssect;
-       $n_a = atmost(int($space / $sz_rr_a), $n_ns);
-
-
-
-   Expires January 2007                                            [Page 9]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-       $n_a_aaaa = atmost(int($space
-                              / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
-       $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns)
-                              / $sz_rr_aaaa), $n_ns);
-       printf "For %s size query (%d byte):\n", $cond, $sz_query;
-       printf "    only A is considered:        ";
-       printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
-       printf "    A and AAAA are considered:   ";
-       printf "# of A+AAAA is %d (%s)\n",
-              $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
-       printf "    preferred-glue A is assumed: ";
-       printf "# of A is %d, # of AAAA is %d (%s)\n",
-           $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
-   }
-
-   sub judge {
-       my ($n, $n_ns) = @_;
-       return "green" if ($n >= $n_ns);
-       return "yellow" if ($n >= 2);
-       return "orange" if ($n == 1);
-       return "red";
-   }
-
-   sub atmost {
-       my ($a, $b) = @_;
-       return 0 if ($a < 0);
-       return $b if ($a > $b);
-       return $a;
-   }
-
-   6 - Security Considerations
-
-   The recommendations contained in this document have no known security
-   implications.
-
-   7 - IANA Considerations
-
-   This document does not call for changes or additions to any IANA
-   registry.
-
-   8 - Acknowledgement
-
-   The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews
-   for their valuable comments and suggestions.
-
-
-
-
-   Expires January 2007                                           [Page 10]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   This work was supported by the US National Science Foundation (research
-   grant SCI-0427144) and DNS-OARC.
-
-   9 - References
-
-   [RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities",
-      RFC1034, November 1987.
-
-   [RFC1035] Mockapetris, P.V., "Domain names - Implementation and
-      Specification", RFC1035, November 1987.
-
-   [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
-      Application and Support", RFC1123, October 1989.
-
-   [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
-      Changes (DNS NOTIFY)", RFC1996, August 1996.
-
-   [RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification",
-      RFC2181, July 1997.
-
-   [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-      RFC2308, March 1998.
-
-   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671,
-      August 1999.
-
-   [RFC4472] Durand, A., Ihren, J., Savola, P., "Operational Consideration
-      and Issues with IPV6 DNS", April 2006.
-
-   10 - Authors' Addresses
-
-   Paul Vixie
-      Internet Systems Consortium, Inc.
-      950 Charter Street
-      Redwood City, CA 94063
-      +1 650 423 1301
-      vixie@isc.org
-
-   Akira Kato
-      University of Tokyo, Information Technology Center
-      2-11-16 Yayoi Bunkyo
-      Tokyo 113-8658, JAPAN
-      +81 3 5841 2750
-      kato@wide.ad.jp
-
-
-
-
-   Expires January 2007                                           [Page 11]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   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).
-
-
-
-
-   Expires January 2007                                           [Page 12]
-
-
diff --git a/doc/draft/draft-kato-dnsop-local-zones-00.txt b/doc/draft/draft-kato-dnsop-local-zones-00.txt
deleted file mode 100644
index d857cd95..00000000
--- a/doc/draft/draft-kato-dnsop-local-zones-00.txt
+++ /dev/null
@@ -1,295 +0,0 @@
-
-
-
-Internet Engineering Task Force                         Akira Kato, WIDE
-INTERNET-DRAFT                                           Paul Vixie, ISC
-Expires: August 24, 2003                               February 24, 2003
-
-
-          Operational Guidelines for "local" zones in the DNS
-                  draft-kato-dnsop-local-zones-00.txt
-
-Status of this Memo
-
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups.  Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time.  It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as ``work in progress.''
-
-To view the list Internet-Draft Shadow Directories, see
-http://www.ietf.org/shadow.html.
-
-Distribution of this memo is unlimited.
-
-The internet-draft will expire in 6 months.  The date of expiration will
-be August 24, 2003.
-
-
-Abstract
-
-A large number of DNS queries regarding to the "local" zones are sent
-over the Internet in every second.  This memo describes operational
-guidelines to reduce the unnecessary DNS traffic as well as the load of
-the Root DNS Servers.
-
-1.  Introduction
-
-While it has yet been described in a RFC, .local is used to provide a
-local subspace of the DNS tree.  Formal delegation process has not been
-completed for this TLD.  In spite of this informal status, .local has
-been used in many installations regardless of the awareness of the
-users.  Usually, the local DNS servers are not authoritative to the
-.local domain, they end up to send queries to the Root DNS Servers.
-
-There are several other DNS zones which describe the "local"
-information.  .localhost has been used to describe the localhost for
-more than a couple of decades and virtually all of the DNS servers are
-configured authoritative for .localhost and its reverse zone .127.in-
-
-
-KATO                    Expires: August 24, 2003                [Page 1]
-
-
-DRAFT                        DNS local zones               February 2003
-
-addr.arpa.  However, there are other "local" zones currently used in the
-Internet or Intranets connected to the Internet through NATs or similar
-devices.
-
-At a DNS server of an university in Japan, half of the DNS queries sent
-to one of the 13 Root DNS Servers were regarding to the .local.  At
-another DNS Server running in one of the Major ISPs in Japan, the 1/4
-were .local.  If those "local" queries are able to direct other DNS
-servers than Root, or they can be resolved locally, it contributes the
-reduction of the Root DNS Servers.
-
-2.  Rationale
-
-Any DNS queries regarding to "local" names should not be sent to the DNS
-servers on the Internet.
-
-3.  Operational Guidelines
-
-Those queries should be processed at the DNS servers internal to each
-site so that the severs respond with NXDOMAIN rather than sending
-queries to the DNS servers outside.
-
-The "local" names have common DNS suffixes which are listed below:
-
-3.1.  Local host related zones:
-
-Following two zones are described in [Barr, 1996] and .localhost is also
-defined in [Eastlake, 1999] .
-
-     o .localhost
-     o .127.in-addr.arpa
-
-
-Following two zones are for the loopback address in IPv6 [Hinden, 1998]
-.  While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush,
-2001] , the old TLD .int has been used for this purpose for years
-[Thomson, 1995] and many implementations still use .int.  So it is
-suggested that both zones should be provided for each IPv6 reverse
-lookup zone for a while.
-
-     o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int
-     o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
-
-
-3.2.  Locally created name space
-
-While the use of .local has been proposed in several Internet-Drafts, it
-has not been described in any Internet documents with formal status.
-However, the amount of the queries for .local is much larger than
-others, it is suggested to resolve the following zone locally:
-
-
-
-
-KATO                    Expires: August 24, 2003                [Page 2]
-
-
-DRAFT                        DNS local zones               February 2003
-
-     o .local
-
-
-
-3.3.  Private or site-local addresses
-
-The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site-
-local addresses [Hinden, 1998] should be resolved locally:
-
-     o 10.in-addr.arpa
-     o 16.172.in-addr.arpa
-     o 17.172.in-addr.arpa
-     o 18.172.in-addr.arpa
-     o 19.172.in-addr.arpa
-     o 20.172.in-addr.arpa
-     o 21.172.in-addr.arpa
-     o 22.172.in-addr.arpa
-     o 23.172.in-addr.arpa
-     o 24.172.in-addr.arpa
-     o 25.172.in-addr.arpa
-     o 26.172.in-addr.arpa
-     o 27.172.in-addr.arpa
-     o 28.172.in-addr.arpa
-     o 29.172.in-addr.arpa
-     o 30.172.in-addr.arpa
-     o 31.172.in-addr.arpa
-     o 168.192.in-addr.arpa
-     o c.e.f.ip6.int
-     o d.e.f.ip6.int
-     o e.e.f.ip6.int
-     o f.e.f.ip6.int
-     o c.e.f.ip6.arpa
-     o d.e.f.ip6.arpa
-     o e.e.f.ip6.arpa
-     o f.e.f.ip6.arpa
-
-
-3.4.  Link-local addresses
-
-The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden,
-1998] should be resolved locally:
-
-     o 254.169.in-addr.arpa
-     o 8.e.f.ip6.int
-     o 9.e.f.ip6.int
-     o a.e.f.ip6.int
-     o b.e.f.ip6.int
-     o 8.e.f.ip6.arpa
-     o 9.e.f.ip6.arpa
-     o a.e.f.ip6.arpa
-     o b.e.f.ip6.arpa
-
-
-
-KATO                    Expires: August 24, 2003                [Page 3]
-
-
-DRAFT                        DNS local zones               February 2003
-
-4.  Suggestions to developers
-
-4.1.  Suggestions to DNS software implementors
-
-In order to avoid unnecessary traffic, it is suggested that DNS software
-implementors provide configuration templates or default configurations
-so that the names described in the previous section are resolved locally
-rather than sent to other DNS servers in the Internet.
-
-4.2.  Suggestions to developers of NATs or similar devices
-
-There are many NAT or similar devices available in the market.
-Regardless of the availability of DNS Servers in those devices, it is
-suggested that those devices are able to filter the DNS traffic or
-respond to the DNS traffic related to "local" zones by configuration
-regardless of its ability of DNS service.  It is suggested that this
-functionality is activated by default.
-
-5.  IANA Consideration
-
-While .local TLD has yet defined officially, there are substantial
-queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the
-traffic sent to the Root DNS Servers are related to the .local zone.
-Therefore, while it is not formally defined, it is suggested that IANA
-delegates .local TLD to an organization.
-
-The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918
-address and the link-local address.  It has several DNS server instances
-around the world by using BGP Anycast [Hardie, 2002] .  So the AS112
-Project is one of the candidates to host the .local TLD.
-
-Authors' addresses
-
-     Akira Kato
-     The University of Tokyo, Information Technology Center
-     2-11-16 Yayoi Bunkyo
-     Tokyo 113-8658, JAPAN
-     Tel: +81 3-5841-2750
-     Email: kato@wide.ad.jp
-
-
-     Paul Vixie
-     Internet Software Consortium
-     950 Charter Street
-     Redwood City, CA 94063, USA
-     Tel: +1 650-779-7001
-     Email: vixie@isc.org
-
-
-
-
-
-
-
-KATO                    Expires: August 24, 2003                [Page 4]
-
-
-DRAFT                        DNS local zones               February 2003
-
-References
-
-To be filled
-
-References
-
-Barr, 1996.
-D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912
-(February 1996).
-
-Eastlake, 1999.
-D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999).
-
-Hinden, 1998.
-R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in
-RFC2373 (July 1998).
-
-Bush, 2001.
-R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001).
-
-Thomson, 1995.
-S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
-RFC1886 (December 1995).
-
-Rekhter, 1996.
-Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear,
-"Address Allocation for Private Internets" in RFC1918 (February 1996).
-
-IANA, 2002.
-IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002).
-
-Vixie, .
-P. Vixie, "AS112 Project" in AS112. http://www.as112.net/.
-
-Hardie, 2002.
-T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast
-Addresses" in RFC3258 (April 2002).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-KATO                    Expires: August 24, 2003                [Page 5]
-
diff --git a/doc/draft/draft-kerr-ixfr-only-01.txt b/doc/draft/draft-kerr-ixfr-only-01.txt
deleted file mode 100644
index 837b255f..00000000
--- a/doc/draft/draft-kerr-ixfr-only-01.txt
+++ /dev/null
@@ -1,336 +0,0 @@
-
-
-
-DNSext Working Group                                             O. Sury
-Internet-Draft                                                    CZ.NIC
-Updates: 1995 (if approved)                                 S. Kerr, Ed.
-Intended status: Standards Track                                     ISC
-Expires: August 30, 2010                               February 26, 2010
-
-
-               IXFR-ONLY to Prevent IXFR Fallback to AXFR
-                        draft-kerr-ixfr-only-01
-
-Abstract
-
-   This documents proposes a new QTYPE (Query pseudo RRtype) for the
-   Domain Name System (DNS).  IXFR-ONLY is a variant of IXFR (RFC 1995)
-   that allows an authoritative server to incrementally update zone
-   content from another (primary) server without falling back from IXFR
-   to AXFR.  This way, alternate peers can be contacted more quickly and
-   convergence of zone content may be achieved much faster in important,
-   resilient operational scenarios.
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 30, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-
-
-
-Sury & Kerr              Expires August 30, 2010                [Page 1]
-
-Internet-Draft                  IXFR-ONLY                  February 2010
-
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
-   2.  IXFR Server Side  . . . . . . . . . . . . . . . . . . . . . . . 4
-   3.  IXFR Client Side  . . . . . . . . . . . . . . . . . . . . . . . 4
-   4.  Applicability of IXFR-ONLY  . . . . . . . . . . . . . . . . . . 5
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
-   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sury & Kerr              Expires August 30, 2010                [Page 2]
-
-Internet-Draft                  IXFR-ONLY                  February 2010
-
-
-1.  Introduction
-
-   For large DNS zones, RFC 1995 [RFC1995] defines Incremental Zone
-   Transfer (IXFR), which allows only to transfer the changed portion(s)
-   of a zone.
-
-   In the document, an IXFR client and an IXFR server is defined as in
-   RFC 1995 [RFC1995], 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.
-
-   IXFR is an efficient way to transfer changes in zones from IXFR
-   servers to IXFR clients.  However, when an IXFR client has multiple
-   IXFR servers for a single zone, it is possible that not all IXFR
-   servers have the zone with same serial number for that zone.  In this
-   case, if an IXFR client attempts an IXFR from an IXFR server which
-   does not have zone with the serial number used by the IXFR client,
-   the IXFR server will fall back to a full zone transfer (AXFR) when it
-   has a version of the zone with serial number greater than the serial
-   requested by the IXFR client.
-
-   For example, IXFR server NS1 may have serial numbers 1, 2, and 3 for
-   a zone, and IXFR server NS2 may have serial numbers 1 and 3 for the
-   same zone.  An IXFR client that has the zone with serial number 2
-   which sends an IXFR request to IXFR server NS2 will get a full zone
-   transfer (AXFR) of the zone at serial number 3.  This is because NS2
-   does not know the zone with serial number 2, and therefore does not
-   know what the differences are between zone with serial number 2 and
-   3.
-
-   If the IXFR client in this example had known to send the query to
-   IXFR server NS1, then it could have gotten an incremental transfer
-   (IXFR).  But IXFR clients can only know what the latest version of
-   the zone is at a IXFR server (this information is available via an
-   SOA query).
-
-   The IXFR-ONLY query type provides a way for the IXFR client to ask
-   each IXFR server to return an error instead of sending the current
-   version of the zone via full zone transfer (AXFR).  By using this, a
-   IXFR client can check each IXFR server until it finds one able to
-   provide IXFR.
-
-1.1.  Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-
-
-
-Sury & Kerr              Expires August 30, 2010                [Page 3]
-
-Internet-Draft                  IXFR-ONLY                  February 2010
-
-
-2.  IXFR Server Side
-
-   A IXFR server receiving a DNS message requesting IXFR-ONLY will reply
-   as described in RFC 1995 [RFC1995] if it is able to produce an IXFR
-   for the serial number requested.
-
-   If the IXFR server is is not able to reply with an IXFR it MUST NOT
-   reply with an AXFR unless AXFR result is smaller than IXFR result.
-   Instead, it MUST reply with RCODE CannotIXFR. (!FIXME)
-
-   If the IXFR result is larger than an AXFR, then an IXFR server MAY
-   reply with an AXFR result instead.  This is an optimization, and IXFR
-   servers MAY only reply with AXFR if they are certain that the reply
-   using AXFR is smaller than an equivalent IXFR reply.
-
-
-3.  IXFR Client Side
-
-   An IXFR client who wishes to use IXFR-ONLY will send a message to one
-   of the IXFR servers.  The format is exactly the same as for IXFR,
-   except the IXFR-ONLY QTYPE code is used instead of the IXFR QTYPE
-   code.
-
-   If the IXFR server replies with IXFR, then the IXFR client is done.
-
-   If the IXFR server replies with an RCODE of CannotIXFR, then the IXFR
-   client proceeds on to a different IXFR server.  In this case the IXFR
-   server implements IXFR-ONLY, but does not have information about zone
-   with the serial number requested.
-
-   If the IXFR server replies with any RCODE other than CannotIXFR or
-   NoError, then the IXFR client proceeds on to a different IXFR server.
-   In this case the IXFR server does not implement IXFR-ONLY.
-
-   If the IXFR client attempts IXFR-ONLY to each IXFR server and none of
-   them reply with an incremental transfer (IXFR), then it should
-   attempt an IXFR as described in RFC 1995 [RFC1995] to each of the
-   IXFR servers which replied with an RCODE other than CannotIXFR or
-   NoError.
-
-   The method described above allows IXFR clients to operate normally in
-   situatians where some of the IXFR servers do support IXFR-ONLY, and
-   some who do not.  IXFR clients MAY remember which IXFR servers
-   support IXFR-ONLY and query those IXFR servers first.  However since
-   IXFR servers may change software or even run a mix of software, IXFR
-   clients MUST attempt to query each IXFR server periodically when they
-   attempt to get new versions of a zone.
-
-
-
-
-Sury & Kerr              Expires August 30, 2010                [Page 4]
-
-Internet-Draft                  IXFR-ONLY                  February 2010
-
-
-   Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
-   given IXFR server, if this is known in advance.  These IXFR servers
-   are treated as if they replied with an RCODE other than CannotIXFR or
-   NoError, although no query with IXFR-ONLY is actually sent.
-
-
-4.  Applicability of IXFR-ONLY
-
-   Implementations SHOULD allow IXFR clients to disable IXFR-ONLY
-   completely.
-
-   Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
-   specific zone.  This may be useful for small zones, where fallback to
-   AXFR is cheap, or in other cases where IXFR-ONLY is causing problems.
-
-   Usage of IXFR-ONLY may cause IXFR clients to prefer particular IXFR
-   servers, by shifting load to ones that support IXFR-ONLY.  If this a
-   problem, then administrators can disable IXFR-ONLY in implementations
-   that allow it.
-
-   If a IXFR client has a single IXFR server for a zone, it SHOULD use
-   IXFR rather than IXFR-ONLY.
-
-
-5.  IANA Considerations
-
-   IANA allocates the new IXFR-ONLY QTYPE, which means "incremental
-   transfer only".  IANA allocates the CannotIXFR RCODE, which means
-   "Server cannot provide IXFR for zone".
-
-
-6.  Security Considerations
-
-   IXFR-ONLY may be used by someone to get information about the state
-   of IXFR servers by providing a quick and efficient way to check which
-   versions of a zone each IXFR server supports.  Zones should be
-   secured via TSIG [RFC2845] to prevent unauthorized information
-   exposure.  However, even administrators of IXFR servers may not want
-   this information given to IXFR clients, in which case they will need
-   to disable IXFR-ONLY.
-
-
-7.  Normative References
-
-   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-              August 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-
-
-
-Sury & Kerr              Expires August 30, 2010                [Page 5]
-
-Internet-Draft                  IXFR-ONLY                  February 2010
-
-
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-
-Authors' Addresses
-
-   Ondrej Sury
-   CZ.NIC
-   Americka 23
-   120 00 Praha 2
-   CZ
-
-   Phone: +420 222 745 110
-   Email: ondrej.sury@nic.cz
-
-
-   Shane Kerr (editor)
-   ISC
-   Bennebrokestraat 17-I
-   1015 PE Amsterdam
-   NL
-
-   Phone: +31 64 6336297
-   Email: shane@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sury & Kerr              Expires August 30, 2010                [Page 6]
-
diff --git a/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt b/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt
deleted file mode 100644
index 0a7516bd..00000000
--- a/doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt
+++ /dev/null
@@ -1,336 +0,0 @@
-
-
-
-Domain Name System Operations                                 W. Mekking
-Internet-Draft                                                NLnet Labs
-Intended status: Standards Track                           June 29, 2010
-Expires: December 31, 2010
-
-
-    Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE
-                   draft-mekking-dnsop-auto-cpsync-00
-
-Abstract
-
-   This document proposes a way to synchronise existing trust anchors
-   automatically between a child zone and its parent.  The algorithm can
-   be used for other Resource Records that are required to delegate from
-   a parent to a child such as NS and glue records.
-
-Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-Status of This Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at http://datatracker.ietf.org/drafts/current/.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   This Internet-Draft will expire on December 31, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-
-
-
-Mekking                 Expires December 31, 2010               [Page 1]
-
-Internet-Draft        Child Parent Synchronization             June 2010
-
-
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-1.  Introduction
-
-   This memo defines a way to synchronise existing trust anchors
-   automatically between a child zone and its parent.  The algorithm can
-   be used for other Resource Records that are required to delegate from
-   a parent to a child such as NS and glue records.
-
-   To create a DNSSEC RFC 4035 [RFC4035] chain of trust, child zones
-   must submit their DNSKEYs, or hashes of their DNSKEYs, to their
-   parent zone.  The parent zone publishes the hashes of the DNSKEYs in
-   the form of a DS record.  The DNSKEY RRset at the child may change
-   over time.  In order to keep the chain of trust intact, the DS
-   records at the parent zone also needs to be updated.  The rolling of
-   the keys with the SEP bit on is one of the few tasks in DNSSEC that
-   yet has to be fully automated.
-
-   The DNS UPDATE mechanism RFC 2136 [RFC2136] can be used to push zone
-   changes to the parent.
-
-   To bootstrap the direct communication channel, information must be
-   exchanged in order to detect service location and granting update
-   privileges.  A new or existing child zone can request a direct
-   communication channel with the parent.  If the parent allows for
-   direct communication with child zones, the parent can share the
-   required data to set up the channel to the child zone.  Once the
-   child has the required credentials, it can use the direct
-   communication channel with the parent to request zone changes related
-   to its delegation.
-
-   If a third party is involved, the third party can act on behalf of
-   the parent.  In this case, the third party will give out the required
-   credentials to set up the communication channel.
-
-   It is RECOMMENDED that the direct communication channel is secured
-   with TSIG [RFC2845] or SIG0 [RFC2931].
-
-2.  Access and Update Control
-
-   The DNS UPDATE normally is used for granting update permissions to a
-   machine that is within the boundary of the same organization.  This
-   document proposes to grant child zones the same permissions.
-   However, it MUST NOT be possible that a child zone updates
-
-
-
-Mekking                 Expires December 31, 2010               [Page 2]
-
-Internet-Draft        Child Parent Synchronization             June 2010
-
-
-   information in the parent zone that falls outside the administrative
-   domain of the corresponding delegation.  For example, it MUST NOT be
-   possible for a child zone to update the data that the parent is
-   authoritative for, or update a delegation that is pointed to a
-   different child zone.  It MUST only be able to update records that
-   match one of the following:
-
-   Or:   The owner name is equal the child zone name and RRtype is
-      delegation specific.  Currently those are records with RRtype NS
-      or DS.
-
-   Or:   The owner name is a subdomain of the child zone name and RRtype
-      is glue specific.  Currently those are records with RRtype A or
-      AAAA.
-
-   This list may be expanded in the future, if there is need for more
-   delegation related zone content.
-
-   In case of adding or deleting delegation specific records, the DNSSEC
-   related RRs in the parent zone might need to be updated.
-
-   The service location may be handed out by the registrar during
-   bootstrap If this information is missing, the normal guidelines for
-   sending DNS UPDATE messages SHOULD be followed.
-
-3.  Update Mechanism
-
-3.1.  Child Duties
-
-   Updating the NS RRset or corresponding glue at the parent, an update
-   can be sent at any time.  Updating the DS RRset is part of key
-   rollover, as described in RFC 4641 [RFC4641].  When performing a key
-   rollover that involves updating the RRset at the parent, the child
-   introduces a new DNSKEY in its zone that represents the security
-   entry point for determining the chain of trust.  After a while, it
-   will revoke and/or remove the previous security entry point.  The
-   timings when to update the DS RRset at the parent are described in
-   draft-dnsop-morris-dnssec-key-timing [keytiming].  When updating the
-   DS RRset at the parent automatically, these timing specifications
-   SHOULD be followed.  To determine the propagation delays described in
-   this document, the child should poll the parent zone for a short
-   time, until the DS is visible at all parent name servers.
-
-   To discuss: A child zone might be unable to reach all parent name
-   servers.
-
-   The child notifies the parent of the requested changes by sending a
-   DNS UPDATE message.  If it receives a NOERROR reply in return, the
-
-
-
-Mekking                 Expires December 31, 2010               [Page 3]
-
-Internet-Draft        Child Parent Synchronization             June 2010
-
-
-   update is acknowledged by the parent zone.  Otherwise, the child MAY
-   retry transmitting the update.  In order to prevent duplicate
-   updates, it SHOULD follow the guidelines described in RFC 2136
-   [RFC2136].
-
-3.2.  Parent Duties
-
-   When the master DNS server of the parent receives a DNS UPDATE from
-   one of its children the following must be done:
-
-   Step 1:  Check the TSIG/SIG0 credentials.  In case of TSIG, the
-      parent should follow the TSIG processing described in section 3.2
-      of RFC 2845.  In case of SIG0, the parent should follow the SIG0
-      processing described in section 3.2 of RFC 2931.
-
-   Step 2:  Verify that the updates matches the update policy for child
-      zones.
-
-   Step 3:  If verified, send back DNS UPDATE OK.  Otherwise, send back
-      DNS UPDATE REFUSED.
-
-   Step 4:  If verified, apply changes.  How that is done is a matter of
-      policy.
-
-3.3.  Proxy considerations
-
-   Some environments don't allow for direct communication between parent
-   and child zone.  In these case, the parent duties can be performed by
-   a different party (for example, the registar).  The third party will
-   forward the update to the parent zone.  In what format depends on
-   local policy.
-
-4.  Example BIND9 Configuration
-
-   This is how a parent zone can configure a policy to enable a child
-   zone synchronize delegation specific records.  The first rule of the
-   update policy grants children to update their DS and NS records in
-   the parent zone, in this case example.com.  The second rule of the
-   update policy grants children to update the corresponding glue
-   records.
-
-   key cs.example.com. {
-   algorithm HMAC-MD5;
-   secret "secretforcs";
-   }
-
-   key math.example.com. {
-   algorithm HMAC-MD5;
-
-
-
-Mekking                 Expires December 31, 2010               [Page 4]
-
-Internet-Draft        Child Parent Synchronization             June 2010
-
-
-   secret "secretformath";
-   }
-
-   ...
-
-   zone "example.com" {
-   type master;
-   file "example.com";
-   update-policy { grant *.example.com. self *.example.com.  DS NS; };
-   update-policy { grant *.example.com. selfsub *.example.com.  A AAAA;
-   };
-   };
-
-5.  Security Considerations
-
-   Automating the synchronization of (DNSSEC) records between the parent
-   and child created a new channel.  We have recommended that this
-   channel should be secured with TSIG or SIG0.  There is an advantage
-   and a disadvantage of the new security channel.  The disadvantage is
-   that you create a new attack window for your DNSSEC credentials.  If
-   the automated synchronization is used for updating DS records at the
-   parent, you SHOULD pick a cryptographically an equally strong or
-   stronger TSIG/SIG0 key than the strength of your DNSSEC keys.
-
-   The advantage is that if somehow your DNSSEC keys are compromised,
-   you can still use this channel to perform an emergency key rollover.
-
-6.  IANA Considerations
-
-   None.
-
-7.  Acknowledgments
-
-   Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards and more.
-
-8.  References
-
-8.1.  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.
-
-   [RFC4641]    Kolkman, O. and R. Gieben, "DNSSEC Operational
-                Practices", RFC 4641, September 2006.
-
-   [keytiming]  Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key
-                Timing Considerations", March 2010.
-
-
-
-Mekking                 Expires December 31, 2010               [Page 5]
-
-Internet-Draft        Child Parent Synchronization             June 2010
-
-
-8.2.  Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2845]    Vixie, P., Gudmundsson, O., Eastlake, D., and B.
-                Wellington, "Secret Key Transaction Authentication for
-                DNS (TSIG)", RFC 2845, May 2000.
-
-   [RFC2931]    Eastlake, D., "DNS Request and Transaction Signatures (
-                SIG(0)s)", RFC 2931, September 2000.
-
-   [RFC4035]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
-                Rose, "Protocol Modifications for the DNS Security
-                Extensions", RFC 4035, March 2005.
-
-Author's Address
-
-   Matthijs Mekking
-   NLnet Labs
-   Science Park 140
-   Amsterdam  1098 XG
-   The Netherlands
-
-   EMail: matthijs@nlnetlabs.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mekking                 Expires December 31, 2010               [Page 6]
-
diff --git a/doc/draft/draft-yao-dnsext-bname-04.txt b/doc/draft/draft-yao-dnsext-bname-04.txt
deleted file mode 100644
index 8b6615aa..00000000
--- a/doc/draft/draft-yao-dnsext-bname-04.txt
+++ /dev/null
@@ -1,729 +0,0 @@
-

-

-Network Working Group                                             J. Yao

-Internet-Draft                                                    X. Lee

-Intended status: Standards Track                                   CNNIC

-Expires: February 12, 2011                                      P. Vixie

-                                            Internet Software Consortium

-                                                         August 11, 2010

-

-

-                      Bundle DNS Name Redirection

-                     draft-yao-dnsext-bname-04.txt

-

-Abstract

-

-   This document defines a new DNS Resource Record called "BNAME", which

-   provides the capability to map itself and its subtree of the DNS name

-   space to another domain.  It differs from the CNAME record which only

-   maps a single node of the DNS name space, from the DNAME which only

-   maps the subtree of the DNS name space to another domain.

-

-Status of this Memo

-

-   This Internet-Draft is submitted in full conformance with the

-   provisions of BCP 78 and BCP 79.

-

-   Internet-Drafts are working documents of the Internet Engineering

-   Task Force (IETF).  Note that other groups may also distribute

-   working documents as Internet-Drafts.  The list of current Internet-

-   Drafts is at http://datatracker.ietf.org/drafts/current/.

-

-   Internet-Drafts are draft documents valid for a maximum of six months

-   and may be updated, replaced, or obsoleted by other documents at any

-   time.  It is inappropriate to use Internet-Drafts as reference

-   material or to cite them other than as "work in progress."

-

-   This Internet-Draft will expire on February 12, 2011.

-

-Copyright Notice

-

-   Copyright (c) 2010 IETF Trust and the persons identified as the

-   document authors.  All rights reserved.

-

-   This document is subject to BCP 78 and the IETF Trust's Legal

-   Provisions Relating to IETF Documents

-   (http://trustee.ietf.org/license-info) in effect on the date of

-   publication of this document.  Please review these documents

-   carefully, as they describe your rights and restrictions with respect

-   to this document.  Code Components extracted from this document must

-   include Simplified BSD License text as described in Section 4.e of

-

-

-

-Yao, et al.             Expires February 12, 2011               [Page 1]

-

-Internet-Draft                    bname                      August 2010

-

-

-   the Trust Legal Provisions and are provided without warranty as

-   described in the Simplified BSD License.

-

-   This document may contain material from IETF Documents or IETF

-   Contributions published or made publicly available before November

-   10, 2008.  The person(s) controlling the copyright in some of this

-   material may not have granted the IETF Trust the right to allow

-   modifications of such material outside the IETF Standards Process.

-   Without obtaining an adequate license from the person(s) controlling

-   the copyright in such materials, this document may not be modified

-   outside the IETF Standards Process, and derivative works of it may

-   not be created outside the IETF Standards Process, except to format

-   it for publication as an RFC or to translate it into languages other

-   than English.

-

-

-Table of Contents

-

-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

-     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3

-   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3

-   3.  The BNAME Resource Record  . . . . . . . . . . . . . . . . . .  4

-     3.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  4

-     3.2.  The BNAME Substitution . . . . . . . . . . . . . . . . . .  4

-     3.3.  The BNAME Rules  . . . . . . . . . . . . . . . . . . . . .  4

-   4.  Query Processing . . . . . . . . . . . . . . . . . . . . . . .  4

-     4.1.  Processing by Servers  . . . . . . . . . . . . . . . . . .  5

-     4.2.  Processing by Resolvers  . . . . . . . . . . . . . . . . .  8

-   5.  BNAME in DNSSEC  . . . . . . . . . . . . . . . . . . . . . . .  9

-     5.1.  BNAME validating . . . . . . . . . . . . . . . . . . . . .  9

-     5.2.  BNAME alias algorithm identifiers  . . . . . . . . . . . . 10

-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10

-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10

-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11

-   9.  Change History . . . . . . . . . . . . . . . . . . . . . . . . 11

-     9.1.  draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 11

-     9.2.  draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 11

-     9.3.  draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 11

-     9.4.  draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 11

-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12

-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12

-     10.2. Informative References . . . . . . . . . . . . . . . . . . 13

-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13

-

-

-

-

-

-

-

-

-Yao, et al.             Expires February 12, 2011               [Page 2]

-

-Internet-Draft                    bname                      August 2010

-

-

-1.  Introduction

-

-   More and more internationalized domain name labels [RFC3490] appear

-   in the DNS trees.  Some labels [RFC3743] are equivalent in some

-   languages.  The internet users want them to be identical in the DNS

-   resolution.  For example, color.exmaple.com==colour.example.com.  The

-   BNAME represents for bundle names.  This document defines a new DNS

-   Resource Record called "BNAME", which provides the capability to map

-   an entire tree of the DNS name space to another domain.  It means

-   that the BNAME redirects both itself and its descendants to its

-   owner.  The DNAME [RFC2672] and [RFC2672bis] do not redirect itself,

-   only the descendants.  The domain name that owns a DNAME record is

-   allowed to have other resource record types at that domain name.  The

-   domain name that owns a BNAME record is not allowed to have other

-   resource record types at that domain name unless they are the DNSSEC

-   related resource record types defined in [RFC4033], [RFC4034],

-   [RFC4035] and [RFC5155].  A server MAY refuse to load a zone that has

-   data at a sub-domain of a domain name owning a BNAME RR or that has

-   other data except the DNSSEC related resource record types and BNAME

-   at that name.  BNAME is a singleton type, meaning only one BNAME is

-   allowed per name except the DNSSEC related resource record types.

-   Resolvers, servers and zone content administrators should be cautious

-   that usage of BNAME or its combination with CNAME or DNAME may lead

-   to form loops.  The loops should be avoided.

-

-1.1.  Terminology

-

-   All the basic terms used in this specification are defined in the

-   documents [RFC1034], [RFC1035] and [RFC2672].

-

-

-2.  Motivation

-

-   In some languages, some characters have the variants, which look

-   differently or very similar but are identical in the meaning.  For

-   example, Chinese character U+56FD and its variant U+570B look

-   differently, but are identical in the meaning.  If Internationalized

-   Domain Label" or "IDL" [RFC3743] are composed of variant characters,

-   we regard this kind of IDL as the IDL variant.  If these IDL variants

-   are put into the DNS for resolution, they are expected to be

-   identical in the DNS resolution.  More comprehensible example is that

-   we expect color.exmaple.com to be equivalent with the

-   colour.exmaple.com in the DNS resolution.  The BNAME Resource Record

-   and its processing rules are conceived as a solution to this

-   equivalence problem.  Without the BNAME mechanism, current mechanisms

-   such as DNAME or CNAME are not enough capable to solve all the

-   problems with the emergence of internationalized domain names.  The

-   internationalized domain names may have alias or equivalence of the

-

-

-

-Yao, et al.             Expires February 12, 2011               [Page 3]

-

-Internet-Draft                    bname                      August 2010

-

-

-   original one.  The BNAME solution provides the solution to both ASCII

-   alias names and internationalized domain alias names.

-

-

-3.  The BNAME Resource Record

-

-3.1.  Format

-

-   The BNAME RR has mnemonic BNAME and type code xx (decimal).  It is

-   not class-sensitive.  Its RDATA is comprised of a single field,

-   <target>, which contains a fully qualified domain name that must be

-   sent in uncompressed form [RFC1035], [RFC3597].  The <target> field

-   MUST be present.  The presentation format of <target> is that of a

-   domain name [RFC1035].  The wildcards in the BNAME RR SHOULD NOT be

-   used.

-

-     <owner> <ttl> <class> BNAME <target>

-

-   The effect of the BNAME RR is the substitution of the record's

-   <target> for its owner name, as a suffix of a domain name.  This

-   substitution has to be applied for every BNAME RR found in the

-   resolution process, which allows fairly lengthy valid chains of BNAME

-   RRs.

-

-3.2.  The BNAME Substitution

-

-   A BNAME substitution is performed by replacing the suffix labels of

-   the name being sought matching the owner name of the BNAME resource

-   record with the string of labels in the RDATA field.  The matching

-   labels end with the root label in all cases.  Only whole labels are

-   replaced.

-

-3.3.  The BNAME Rules

-

-   There are two rules which governs the use of BNAMEs in a zone file.

-   The first one is that there SHOULD be no descendants under the owner

-   of the BNAME.  The second one is that no resource records can co-

-   exist with the BNAME for the same name except the DNSSEC related

-   resource record types.  It means that if a BNAME RR is present at a

-   node N, there MUST be no other data except the DNSSEC related

-   resource record types at N and no data at any descendant of N. This

-   restriction applies only to records of the same class as the BNAME

-   record.

-

-

-4.  Query Processing

-

-   To exploit the BNAME mechanism the name resolution algorithms

-

-

-

-Yao, et al.             Expires February 12, 2011               [Page 4]

-

-Internet-Draft                    bname                      August 2010

-

-

-   [RFC1034] 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

-   BNAME record.  This operation will be referred to as "the BNAME

-   substitution".

-

-4.1.  Processing by Servers

-

-   For a server performing non-recursive service steps 3.a, 3.c and 4 of

-   section 4.3.2 [RFC1034] are changed to check for a BNAME record, and

-   to return certain BNAME records from zone data and the cache.

-

-   If the owner name of the bname is the suffix of the name queryed but

-   different, when preparing a response, a server performing a BNAME

-   substitution will in all cases include the relevant BNAME RR in the

-   answer section.  A CNAME RR is synthesized and included in the answer

-   section.  This will help the client to reach the correct DNS data.

-

-   If the owner name of the bname is same with the name queryed, when

-   preparing a response, a server performing a BNAME substitution will

-   not include the relevant BNAME RR in the answer section unless the

-   type queryed is BNAME.  A CNAME RR will be synthesized and included

-   in the answer section unless the type queryed is BNAME or the query

-   is the DNSSEC query.

-

-   The provided synthesized CNAME RR if there has one, MUST have

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Yao, et al.             Expires February 12, 2011               [Page 5]

-

-Internet-Draft                    bname                      August 2010

-

-

-      The same CLASS as the QCLASS of the query,

-

-      TTL equal to the corresponding BNAME RR,

-

-      An <owner> equal to the QNAME in effect at the moment the BNAME RR

-      was encountered, and

-

-      An RDATA field containing the new QNAME formed by the action of

-      the BNAME substitution.

-

-

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

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Yao, et al.             Expires February 12, 2011               [Page 6]

-

-Internet-Draft                    bname                      August 2010

-

-

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

-

-         If the data at the node is a BNAME, and QTYPE doesn't

-         match BNAME, copy the BNAME RR and also a corresponding,

-         synthesized CNAME RR into the answer section of the

-         response, change QNAME to the name carried as RDATA in

-         the BNAME 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 BNAME record.

-

-

-         If a BNAME 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 [RFC2136] and exit; otherwise

-         perform the substitution and continue.  The server SHOULD

-         synthesize a corresponding CNAME record as described above and

-         include it in the answer section.  Go back to step 1.

-

-         If there was no BNAME 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.

-

-

-

-

-

-Yao, et al.             Expires February 12, 2011               [Page 7]

-

-Internet-Draft                    bname                      August 2010

-

-

-

-         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 QNAME is not found in the cache but a BNAME record is

-      present at QNAME, copy that BNAME 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 BNAMEs, 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 BNAME 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 BNAME record is encountered.

-

-

-4.2.  Processing by Resolvers

-

-   A resolver or a server providing recursive service must be modified

-   to treat a BNAME as somewhat analogous to a CNAME.  The resolver

-   algorithm of [RFC1034] section 5.3.3 is modified to renumber step 4.d

-   as 4.e and insert a new 4.d.  The complete algorithm becomes:

-

-

-

-

-

-

-

-

-

-

-

-

-

-Yao, et al.             Expires February 12, 2011               [Page 8]

-

-Internet-Draft                    bname                      August 2010

-

-

-   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 BNAME and that is not the answer

-         itself, cache the BNAME.  If substitution of the BNAME'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 BNAME 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 BNAME record in the response.

-

-

-5.  BNAME in DNSSEC

-

-5.1.  BNAME validating

-

-   With the deployment of DNSSEC, more and more servers and resolvers

-   will support DNSSEC.  In order to make BNAME valid in DNSSEC

-   verification, the DNSSEC enabled resolvers and servers MUST support

-   BNAME.  The synthesized CNAME in the answer section for the BNAME

-   will never be signed if there has one.

-

-   If the owner name of the bname is the suffix of the name queryed but

-

-

-

-Yao, et al.             Expires February 12, 2011               [Page 9]

-

-Internet-Draft                    bname                      August 2010

-

-

-   different, DNSSEC validators MUST understand BNAME, verify the BNAME

-   and then checking that the CNAME was properly synthesized in order to

-   verify the synthesized CNAME.

-

-   If the owner name of the bname is same with the name queryed, DNSSEC

-   validators MUST understand BNAME and verify the BNAME.  The BNAME

-   enabled resolver (validator) should do somewhat analogous to a CNAME

-   for further query.

-

-   In any negative response, the NSEC or NSEC3 [RFC5155] record type bit

-   map SHOULD be checked to see that there was no BNAME that could have

-   been applied.  If the BNAME bit in the type bit map is set and the

-   query type is not BNAME, then BNAME substitution should have been

-   done.

-

-5.2.  BNAME alias algorithm identifiers

-

-   In order to prevent BNAME-unaware resolvers from attempting to

-   validate responses from BNAME-signed zones, this specification

-   allocates two new DNSKEY algorithm identifiers.  Algorithm Y, DSA-

-   BNAME-SHA1 is an alias for algorithm 3, DSA.  Algorithm Z, RSASHA1-

-   BNAME-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.  The BNAME-

-   unaware resolvers will not know these new identifiers and treat

-   responses from the BNAME signed zone as insecure, otherwise the bname

-   RR will be regarded as bogus if there is no such a mechanism.  These

-   algorithm identifiers are used with the BNAME hash algorithm SHA1.

-   Using other BNAME hash algorithms requires allocation of a new alias.

-   Validating resolvers which follow the BNAME specification MUST

-   recognize the new alias algorithm identifier.

-

-

-6.  IANA Considerations

-

-   IANA is requested to assign the number to XX.  This document updates

-   the IANA registry "DNS SECURITY ALGORITHM NUMBERS".  IANA is

-   requested to assign the number to Y and Z.

-

-   [[anchor14: Note in draft: before this document goes to WG Last call,

-   it is better that we list all DNSSEC algorithms that need to be

-   aliased to reflect compatibility with this extension.]]

-

-

-7.  Security Considerations

-

-   Both ASCII domain name labels and non-ASCII ones have some aliases.

-

-

-

-Yao, et al.             Expires February 12, 2011              [Page 10]

-

-Internet-Draft                    bname                      August 2010

-

-

-   We can bundle the domain name labels and their aliases through BNAME

-   in the DNS resolutions.  The name labels and their aliases in the

-   particular languages are only known by those who know these

-   languages.  Those labels may be regarded as different ones by those

-   who don't know those languages.  Those who do not know the aliases

-   should only use the familar ones.  The applications will not know the

-   aliases unless they are properly configured.

-

-

-8.  Acknowledgements

-

-   Because the BNAME is very similar to DNAME, the authors learn a lot

-   from [RFC2672].  Many ideas are from the discussion in the DNSOP and

-   DNSEXT mailling list.  Thanks a lot to all in the list.  Many

-   important comments and suggestions are contributed by many members of

-   the DNSEXT and DNSOP WGs.  The authors especially thanks the

-   following ones:Niall O'Reilly, Glen Zorn, Mark Andrews, George

-   Barwood,Olafur Gudmundsson, Sun Guonian and Hanfeng for improving

-   this document.

-

-

-9.  Change History

-

-   [[anchor17: RFC Editor: Please remove this section.]]

-

-9.1.  draft-yao-dnsext-bname: Version 00

-

-   o  Bundle DNS Name Redirection

-

-9.2.  draft-yao-dnsext-bname: Version 01

-

-   o  Improve the algorithm

-   o  Improve the text

-

-9.3.  draft-yao-dnsext-bname: Version 02

-

-   o  Add the DNSSEC discussion

-   o  Improve the text

-

-9.4.  draft-yao-dnsext-bname: Version 03

-

-   o  Update the DNSSEC discussion

-   o  Update the IANA consideration

-

-

-10.  References

-

-

-

-

-

-Yao, et al.             Expires February 12, 2011              [Page 11]

-

-Internet-Draft                    bname                      August 2010

-

-

-10.1.  Normative References

-

-   [ASCII]    American National Standards Institute (formerly United

-              States of America Standards Institute), "USA Code for

-              Information Interchange", ANSI X3.4-1968, 1968.

-

-   [EDNS0]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)",

-              RFC 2671, August 1999.

-

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

-

-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",

-              RFC 2671, August 1999.

-

-   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",

-              RFC 2672, August 1999.

-

-   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,

-              "Internationalizing Domain Names in Applications (IDNA)",

-              RFC 3490, March 2003.

-

-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record

-              (RR) Types", RFC 3597, September 2003.

-

-   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO

-              10646", RFC 3629, November 2003.

-

-   [RFC3743]  Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint

-              Engineering Team (JET) Guidelines for Internationalized

-              Domain Names (IDN) Registration and Administration for

-              Chinese, Japanese, and Korean", RFC 3743, April 2004.

-

-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.

-              Rose, "DNS Security Introduction and Requirements",

-              RFC 4033, March 2005.

-

-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.

-

-

-

-Yao, et al.             Expires February 12, 2011              [Page 12]

-

-Internet-Draft                    bname                      August 2010

-

-

-              Rose, "Resource Records for the DNS Security Extensions",

-              RFC 4034, March 2005.

-

-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.

-              Rose, "Protocol Modifications for the DNS Security

-              Extensions", RFC 4035, March 2005.

-

-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS

-              Security (DNSSEC) Hashed Authenticated Denial of

-              Existence", RFC 5155, March 2008.

-

-10.2.  Informative References

-

-   [RFC2672bis]

-              Rose, S. and W. Wijngaards, "Update to DNAME Redirection

-              in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname-

-              17.txt, 6 2009.

-

-

-Authors' Addresses

-

-   Jiankang YAO

-   CNNIC

-   No.4 South 4th Street, Zhongguancun

-   Beijing

-

-   Phone: +86 10 58813007

-   Email: yaojk@cnnic.cn

-

-

-   Xiaodong LEE

-   CNNIC

-   No.4 South 4th Street, Zhongguancun

-   Beijing

-

-   Phone: +86 10 58813020

-   Email: lee@cnnic.cn

-

-

-   Paul Vixie

-   Internet Software Consortium

-   950 Charter Street

-   Redwood City, CA

-

-   Phone: +1 650 779 7001

-   Email: vixie@isc.org

-

-

-

-

-

-Yao, et al.             Expires February 12, 2011              [Page 13]

-

-

-

diff --git a/doc/draft/update b/doc/draft/update
deleted file mode 100644
index 6ac20904..00000000
--- a/doc/draft/update
+++ /dev/null
@@ -1,46 +0,0 @@
-#!/bin/sh
-commit=
-for i
-do
-	z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'`
-	if test -n "$z"
-	then
-		i="$z"
-	fi
-	if test -f "$i"
-	then
-		continue
-	fi
-	pat=`echo "$i" | sed 's/...txt/??.txt/'`
-	old=`echo $pat 2> /dev/null`
-	if test "X$old" != "X$pat"
-	then
-		newer=0
-		for j in $old
-		do
-			if test $j ">" $i
-			then
-				 newer=1
-			fi
-		done
-		if test $newer = 1
-		then
-			continue;
-		fi
-	fi
-	if fetch "http://www.ietf.org/internet-drafts/$i" 
-	then
-		cvs add "$i" 
-		if test "X$old" != "X$pat"
-		then
-			rm $old
-			cvs delete $old
-			commit="$commit $old"
-		fi
-		commit="$commit $i"
-	fi
-done
-if test -n "$commit"
-then
-	cvs commit -m "new draft" $commit
-fi
diff --git a/doc/rfc/fetch b/doc/rfc/fetch
deleted file mode 100755
index 17ce40fe..00000000
--- a/doc/rfc/fetch
+++ /dev/null
@@ -1,6 +0,0 @@
-#!/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
deleted file mode 100644
index bd72fdef..00000000
--- a/doc/rfc/index
+++ /dev/null
@@ -1,143 +0,0 @@
- 952:	DOD INTERNET HOST TABLE SPECIFICATION
-1032:	DOMAIN ADMINISTRATORS GUIDE
-1033:	DOMAIN ADMINISTRATORS OPERATIONS GUIDE
-1034:	DOMAIN NAMES - CONCEPTS AND FACILITIES
-1035:	DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
-1101:	DNS Encoding of Network Names and Other Types
-1122:	Requirements for Internet Hosts -- Communication Layers
-1123:	Requirements for Internet Hosts -- Application and Support
-1183:	New DNS RR Definitions (AFSDB, RP, X25, ISDN and RT)
-1348:	DNS NSAP RRs
-1535:	A Security Problem and Proposed Correction
-	 With Widely Deployed DNS Software
-1536:	Common DNS Implementation Errors and Suggested Fixes
-1537:	Common DNS Data File Configuration Errors
-1591:	Domain Name System Structure and Delegation
-1611:	DNS Server MIB Extensions
-1612:	DNS Resolver MIB Extensions
-1706:	DNS NSAP Resource Records
-1712:	DNS Encoding of Geographical Location
-1750:	Randomness Recommendations for Security
-1876:	A Means for Expressing Location Information in the Domain Name System
-1886:	DNS Extensions to support IP version 6
-1912:	Common DNS Operational and Configuration Errors
-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)
-3755:	Legacy Resolver Compatibility for Delegation Signer (DS)
-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
-4294:	IPv6 Node Requirements
-4339:	IPv6 Host Configuration of DNS Server Information Approaches
-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
-4471:	Derivation of DNS Name Predecessor and Successor
-4472:	Operational Considerations and Issues with IPv6 DNS
-4509:	Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
-4634:	US Secure Hash Algorithms (SHA and HMAC-SHA)
-4635:	HMAC SHA TSIG Algorithm Identifiers
-4641:	DNSSEC Operational Practices
-4648:	The Base16, Base32, and Base64 Data Encodings
-4697:	Observed DNS Resolution Misbehavior
-4701:	A DNS Resource Record (RR) for Encoding
-         Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
-4892:	Requirements for a Mechanism Identifying a Name Server Instance
-4955:	DNS Security (DNSSEC) Experiments
-4956:	DNS Security (DNSSEC) Opt-In
-5001:	DNS Name Server Identifier (NSID) Option
-5011:	Automated Updates of DNS Security (DNSSEC) Trust Anchors
-5155:	DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
-5205:	Host Identity Protocol (HIP) Domain Name System (DNS) Extension
-5395:	Domain Name System (DNS) IANA Considerations
-5452:	Measures for Making DNS More Resilient against Forged Answers
-5507:	Design Choices When Expanding the DNS
-5625:	DNS Proxy Implementation Guidelines
-5702:   Use of SHA-2 Algorithms with RSA in
-         DNSKEY and RRSIG Resource Records for DNSSEC
-5933:	Use of GOST Signature Algorithms in DNSKEY
-         and RRSIG Resource Records for DNSSEC
-6303:	Locally Served DNS Zones
diff --git a/doc/rfc/rfc1032.txt b/doc/rfc/rfc1032.txt
deleted file mode 100644
index 0e82721c..00000000
--- a/doc/rfc/rfc1032.txt
+++ /dev/null
@@ -1,781 +0,0 @@
-Network Working Group                                       M. Stahl
-Request for Comments: 1032                         SRI International
-                                                       November 1987
-
-
-                      DOMAIN ADMINISTRATORS GUIDE
-
-
-STATUS OF THIS MEMO
-
-   This memo describes procedures for registering a domain with the
-   Network Information Center (NIC) of Defense Data Network (DDN), and
-   offers guidelines on the establishment and administration of a domain
-   in accordance with the requirements specified in RFC-920.  It is
-   intended for use by domain administrators.  This memo should be used
-   in conjunction with RFC-920, which is an official policy statement of
-   the Internet Activities Board (IAB) and the Defense Advanced Research
-   Projects Agency (DARPA).  Distribution of this memo is unlimited.
-
-BACKGROUND
-
-   Domains are administrative entities that provide decentralized
-   management of host naming and addressing.  The domain-naming system
-   is distributed and hierarchical.
-
-   The NIC is designated by the Defense Communications Agency (DCA) to
-   provide registry services for the domain-naming system on the DDN and
-   DARPA portions of the Internet.
-
-   As registrar of top-level and second-level domains, as well as
-   administrator of the root domain name servers on behalf of DARPA and
-   DDN, the NIC is responsible for maintaining the root server zone
-   files and their binary equivalents.  In addition, the NIC is
-   responsible for administering the top-level domains of "ARPA," "COM,"
-   "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it
-   becomes feasible for other appropriate organizations to assume those
-   responsibilities.
-
-   It is recommended that the guidelines described in this document be
-   used by domain administrators in the establishment and control of
-   second-level domains.
-
-THE DOMAIN ADMINISTRATOR
-
-   The role of the domain administrator (DA) is that of coordinator,
-   manager, and technician.  If his domain is established at the second
-   level or lower in the tree, the DA must register by interacting with
-   the management of the domain directly above his, making certain that
-
-
-
-Stahl                                                           [Page 1]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   his domain satisfies all the requirements of the administration under
-   which his domain would be situated.  To find out who has authority
-   over the name space he wishes to join, the DA can ask the NIC
-   Hostmaster.  Information on contacts for the top-level and second-
-   level domains can also be found on line in the file NETINFO:DOMAIN-
-   CONTACTS.TXT, which is available from the NIC via anonymous FTP.
-
-   The DA should be technically competent; he should understand the
-   concepts and procedures for operating a domain server, as described
-   in RFC-1034, and make sure that the service provided is reliable and
-   uninterrupted.  It is his responsibility or that of his delegate to
-   ensure that the data will be current at all times.  As a manager, the
-   DA must be able to handle complaints about service provided by his
-   domain name server.  He must be aware of the behavior of the hosts in
-   his domain, and take prompt action on reports of problems, such as
-   protocol violations or other serious misbehavior.  The administrator
-   of a domain must be a responsible person who has the authority to
-   either enforce these actions himself or delegate them to someone
-   else.
-
-   Name assignments within a domain are controlled by the DA, who should
-   verify that names are unique within his domain and that they conform
-   to standard naming conventions.  He furnishes access to names and
-   name-related information to users both inside and outside his domain.
-   He should work closely with the personnel he has designated as the
-   "technical and zone" contacts for his domain, for many administrative
-   decisions will be made on the basis of input from these people.
-
-THE DOMAIN TECHNICAL AND ZONE CONTACT
-
-   A zone consists of those contiguous parts of the domain tree for
-   which a domain server has complete information and over which it has
-   authority.  A domain server may be authoritative for more than one
-   zone.  The domain technical/zone contact is the person who tends to
-   the technical aspects of maintaining the domain's name server and
-   resolver software, and database files.  He keeps the name server
-   running, and interacts with technical people in other domains and
-   zones to solve problems that affect his zone.
-
-POLICIES
-
-   Domain or host name choices and the allocation of domain name space
-   are considered to be local matters.  In the event of conflicts, it is
-   the policy of the NIC not to get involved in local disputes or in the
-   local decision-making process.  The NIC will not act as referee in
-   disputes over such matters as who has the "right" to register a
-   particular top-level or second-level domain for an organization.  The
-   NIC considers this a private local matter that must be settled among
-
-
-
-Stahl                                                           [Page 2]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   the parties involved prior to their commencing the registration
-   process with the NIC.  Therefore, it is assumed that the responsible
-   person for a domain will have resolved any local conflicts among the
-   members of his domain before registering that domain with the NIC.
-   The NIC will give guidance, if requested, by answering specific
-   technical questions, but will not provide arbitration in disputes at
-   the local level.  This policy is also in keeping with the distributed
-   hierarchical nature of the domain-naming system in that it helps to
-   distribute the tasks of solving problems and handling questions.
-
-   Naming conventions for hosts should follow the rules specified in
-   RFC-952.  From a technical standpoint, domain names can be very long.
-   Each segment of a domain name may contain up to 64 characters, but
-   the NIC strongly advises DAs to choose names that are 12 characters
-   or fewer, because behind every domain system there is a human being
-   who must keep track of the names, addresses, contacts, and other data
-   in a database.  The longer the name, the more likely the data
-   maintainer is to make a mistake.  Users also will appreciate shorter
-   names.  Most people agree that short names are easier to remember and
-   type; most domain names registered so far are 12 characters or fewer.
-
-   Domain name assignments are made on a first-come-first-served basis.
-   The NIC has chosen not to register individual hosts directly under
-   the top-level domains it administers.  One advantage of the domain
-   naming system is that administration and data maintenance can be
-   delegated down a hierarchical tree.  Registration of hosts at the
-   same level in the tree as a second-level domain would dilute the
-   usefulness of this feature.  In addition, the administrator of a
-   domain is responsible for the actions of hosts within his domain.  We
-   would not want to find ourselves in the awkward position of policing
-   the actions of individual hosts.  Rather, the subdomains registered
-   under these top-level domains retain the responsibility for this
-   function.
-
-   Countries that wish to be registered as top-level domains are
-   required to name themselves after the two-letter country code listed
-   in the international standard ISO-3166.  In some cases, however, the
-   two-letter ISO country code is identical to a state code used by the
-   U.S. Postal Service.  Requests made by countries to use the three-
-   letter form of country code specified in the ISO-3166 standard will
-   be considered in such cases so as to prevent possible conflicts and
-   confusion.
-
-
-
-
-
-
-
-
-
-Stahl                                                           [Page 3]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-HOW TO REGISTER
-
-   Obtain a domain questionnaire from the NIC hostmaster, or FTP the
-   file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA.
-
-   Fill out the questionnaire completely.  Return it via electronic mail
-   to HOSTMASTER@SRI-NIC.ARPA.
-
-   The APPENDIX to this memo contains the application form for
-   registering a top-level or second-level domain with the NIC.  It
-   supersedes the version of the questionnaire found in RFC-920.  The
-   application should be submitted by the person administratively
-   responsible for the domain, and must be filled out completely before
-   the NIC will authorize establishment of a top-level or second-level
-   domain.  The DA is responsible for keeping his domain's data current
-   with the NIC or with the registration agent with which his domain is
-   registered.  For example, the CSNET and UUCP managements act as
-   domain filters, processing domain applications for their own
-   organizations.  They pass pertinent information along periodically to
-   the NIC for incorporation into the domain database and root server
-   files.  The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT
-   outlines this procedure.  It is highly recommended that the DA review
-   this information periodically and provide any corrections or
-   additions.  Corrections should be submitted via electronic mail.
-
-WHICH DOMAIN NAME?
-
-   The designers of the domain-naming system initiated several general
-   categories of names as top-level domain names, so that each could
-   accommodate a variety of organizations.  The current top-level
-   domains registered with the DDN Network Information Center are ARPA,
-   COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country
-   domains.  To join one of these, a DA needs to be aware of the purpose
-   for which it was intended.
-
-      "ARPA" is a temporary domain.  It is by default appended to the
-      names of hosts that have not yet joined a domain.  When the system
-      was begun in 1984, the names of all hosts in the Official DoD
-      Internet Host Table maintained by the NIC were changed by adding
-      of the label ".ARPA" in order to accelerate a transition to the
-      domain-naming system.  Another reason for the blanket name changes
-      was to force hosts to become accustomed to using the new style
-      names and to modify their network software, if necessary.  This
-      was done on a network-wide basis and was directed by DCA in DDN
-      Management Bulletin No. 22.  Hosts that fall into this domain will
-      eventually move to other branches of the domain tree.
-
-
-
-
-
-Stahl                                                           [Page 4]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-      "COM" is meant to incorporate subdomains of companies and
-      businesses.
-
-      "EDU" was initiated to accommodate subdomains set up by
-      universities and other educational institutions.
-
-      "GOV" exists to act as parent domain for subdomains set up by
-      government agencies.
-
-      "MIL" was initiated to act as parent to subdomains that are
-      developed by military organizations.
-
-      "NET" was introduced as a parent domain for various network-type
-      organizations.  Organizations that belong within this top-level
-      domain are generic or network-specific, such as network service
-      centers and consortia.  "NET" also encompasses network
-      management-related organizations, such as information centers and
-      operations centers.
-
-      "ORG" exists as a parent to subdomains that do not clearly fall
-      within the other top-level domains.  This may include technical-
-      support groups, professional societies, or similar organizations.
-
-   One of the guidelines in effect in the domain-naming system is that a
-   host should have only one name regardless of what networks it is
-   connected to.  This implies, that, in general, domain names should
-   not include routing information or addresses.  For example, a host
-   that has one network connection to the Internet and another to BITNET
-   should use the same name when talking to either network.  For a
-   description of the syntax of domain names, please refer to Section 3
-   of RFC-1034.
-
-VERIFICATION OF DATA
-
-   The verification process can be accomplished in several ways.  One of
-   these is through the NIC WHOIS server.  If he has access to WHOIS,
-   the DA can type the command "whois domain <domain name><return>".
-   The reply from WHOIS will supply the following: the name and address
-   of the organization "owning" the domain; the name of the domain; its
-   administrative, technical, and zone contacts; the host names and
-   network addresses of sites providing name service for the domain.
-
-
-
-
-
-
-
-
-
-
-Stahl                                                           [Page 5]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-         Example:
-
-         @whois domain rice.edu<Return>
-
-            Rice University (RICE-DOM)
-            Advanced Studies and Research
-            Houston, TX 77001
-
-            Domain Name: RICE.EDU
-
-               Administrative Contact:
-               Kennedy, Ken  (KK28)  Kennedy@LLL-CRG.ARPA (713) 527-4834
-               Technical Contact, Zone Contact:
-               Riffle, Vicky R.  (VRR)  rif@RICE.EDU
-               (713) 527-8101 ext 3844
-
-            Domain servers:
-
-            RICE.EDU                     128.42.5.1
-            PENDRAGON.CS.PURDUE.EDU      128.10.2.5
-
-
-   Alternatively, the DA can send an electronic mail message to
-   SERVICE@SRI-NIC.ARPA.  In the subject line of the message header, the
-   DA should type "whois domain <domain name>".  The requested
-   information will be returned via electronic mail.  This method is
-   convenient for sites that do not have access to the NIC WHOIS
-   service.
-
-   The initial application for domain authorization should be submitted
-   via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA.  The
-   questionnaire described in the appendix may be used or a separate
-   application can be FTPed from host SRI-NIC.ARPA.  The information
-   provided by the administrator will be reviewed by hostmaster
-   personnel for completeness.  There will most likely be a few
-   exchanges of correspondence via electronic mail, the preferred method
-   of communication, prior to authorization of the domain.
-
-HOW TO GET MORE INFORMATION
-
-   An informational table of the top-level domains and their root
-   servers is contained in the file NETINFO:DOMAINS.TXT online at SRI-
-   NIC.ARPA. This table can be obtained by FTPing the file.
-   Alternatively, the information can be acquired by opening a TCP or
-   UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA,
-   and invoking the command "ALL-DOM".
-
-
-
-
-
-Stahl                                                           [Page 6]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   The following online files, all available by FTP from SRI-NIC.ARPA,
-   contain pertinent domain information:
-
-      - NETINFO:DOMAINS.TXT, a table of all top-level domains and the
-        network addresses of the machines providing domain name
-        service for them.  It is updated each time a new top-level
-        domain is approved.
-
-      - NETINFO:DOMAIN-INFO.TXT contains a concise list of all
-        top-level and second-level domain names registered with the
-        NIC and is updated monthly.
-
-      - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the
-        top level and second-level domains, but includes the
-        administrative, technical and zone contacts for each as well.
-
-      - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be
-        completed before registering a top-level or second-level
-        domain.
-
-   For either general or specific information on the domain system, do
-   one or more of the following:
-
-      1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA
-
-      2. Call the toll-free NIC hotline at (800) 235-3155
-
-      3. Use FTP to get background RFCs and other files maintained
-         online at the NIC.  Some pertinent RFCs are listed below in
-         the REFERENCES section of this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stahl                                                           [Page 7]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-REFERENCES
-
-   The references listed here provide important background information
-   on the domain-naming system.  Path names of the online files
-   available via anonymous FTP from the SRI-NIC.ARPA host are noted in
-   brackets.
-
-      1. Defense Communications Agency DDN Defense Communications
-         System, DDN Management Bulletin No. 22, Domain Names
-         Transition, March 1984.
-         [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ]
-
-      2. Defense Communications Agency DDN Defense Communications
-         System, DDN Management Bulletin No. 32, Phase I of the Domain
-         Name Implementation, January 1987.
-         [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]
-
-      3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname
-         Server", RFC-953, DDN Network Information Center, SRI
-         International, October 1985.  [ RFC:RFC953.TXT ]
-
-      4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD
-         Internet Host Table Specification", RFC-952, DDN Network
-         Information Center, SRI International, October 1985.
-         [ RFC:RFC952.TXT ]
-
-      5. ISO, "Codes for the Representation of Names of Countries",
-         ISO-3166, International Standards Organization, May 1981.
-         [ Not online ]
-
-      6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031,
-         Mitre Corporation, October 1987.  [ RFC:RFC1031.TXT ]
-
-      7. Lottor, M.K., "Domain Administrators Operations Guide",
-         RFC-1033, DDN Network Information Center, SRI International,
-         July 1987.  [ RFC:RFC1033.TXT ]
-
-      8. Mockapetris, P., "Domain Names - Concepts and Facilities",
-         RFC-1034, USC Information Sciences Institute, October 1987.
-         [ RFC:RFC1034.TXT ]
-
-      9. Mockapetris, P., "Domain Names - Implementation and
-         Specification", RFC-1035, USC Information Sciences Institute,
-         October 1987.  [ RFC:RFC1035.TXT ]
-
-     10. Mockapetris, P., "The Domain Name System", Proceedings of the
-         IFIP 6.5 Working Conference on Computer Message Services,
-         Nottingham, England, May 1984.  Also as ISI/RS-84-133, June
-
-
-
-Stahl                                                           [Page 8]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-         1984.  [ Not online ]
-
-     11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server
-         Design for Distributed Systems", Proceedings of the Seventh
-         International Conference on Computer Communication, October
-         30 to November 3 1984, Sidney, Australia.  Also as
-         ISI/RS-84-132, June 1984.  [ Not online ]
-
-     12. Partridge, C., "Mail Routing and the Domain System", RFC-974,
-         CSNET-CIC, BBN Laboratories, January 1986.
-         [ RFC:RFC974.TXT ]
-
-     13. Postel, J., "The Domain Names Plan and Schedule", RFC-881,
-         USC Information Sciences Institute, November 1983.
-         [ RFC:RFC881.TXT ]
-
-     14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010
-         USC Information Sciences Institute, May 1986.
-         [ RFC:RFC1010.TXT ]
-
-     15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020,
-         SRI, November 1987.
-         [ RFC:RFC1020.TXT ]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stahl                                                           [Page 9]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-APPENDIX
-
-   The following questionnaire may be FTPed from SRI-NIC.ARPA as
-   NETINFO:DOMAIN-TEMPLATE.TXT.
-
-   ---------------------------------------------------------------------
-
-   To establish a domain, the following information must be sent to the
-   NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
-
-   NOTE: The key people must have electronic mailboxes and NIC
-   "handles," unique NIC database identifiers.  If you have access to
-   "WHOIS", please check to see if you are registered and if so, make
-   sure the information is current.  Include only your handle and any
-   changes (if any) that need to be made in your entry.  If you do not
-   have access to "WHOIS", please provide all the information indicated
-   and a NIC handle will be assigned.
-
-   (1)  The name of the top-level domain to join.
-
-         For example:  COM
-
-   (2) The NIC handle of the administrative head of the organization.
-   Alternately, the person's name, title, mailing address, phone number,
-   organization, and network mailbox.  This is the contact point for
-   administrative and policy questions about the domain.  In the case of
-   a research project, this should be the principal investigator.
-
-         For example:
-
-            Administrator
-
-               Organization  The NetWorthy Corporation
-               Name          Penelope Q. Sassafrass
-               Title         President
-               Mail Address  The NetWorthy Corporation
-                             4676 Andrews Way, Suite 100
-                             Santa Clara, CA 94302-1212
-               Phone Number  (415) 123-4567
-               Net Mailbox   Sassafrass@ECHO.TNC.COM
-               NIC Handle    PQS
-
-   (3)  The NIC handle of the technical contact for the domain.
-   Alternately, the person's name, title, mailing address, phone number,
-   organization, and network mailbox.  This is the contact point for
-   problems concerning the domain or zone, as well as for updating
-   information about the domain or zone.
-
-
-
-
-Stahl                                                          [Page 10]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-         For example:
-
-            Technical and Zone Contact
-
-               Organization  The NetWorthy Corporation
-               Name          Ansel A. Aardvark
-               Title         Executive Director
-               Mail Address  The NetWorthy Corporation
-                             4676 Andrews Way, Suite 100
-                             Santa Clara, CA. 94302-1212
-               Phone Number  (415) 123-6789
-               Net Mailbox   Aardvark@ECHO.TNC.COM
-               NIC Handle    AAA2
-
-   (4)  The name of the domain (up to 12 characters).  This is the name
-   that will be used in tables and lists associating the domain with the
-   domain server addresses.  [While, from a technical standpoint, domain
-   names can be quite long (programmers beware), shorter names are
-   easier for people to cope with.]
-
-         For example:  TNC
-
-   (5)  A description of the servers that provide the domain service for
-   translating names to addresses for hosts in this domain, and the date
-   they will be operational.
-
-         A good way to answer this question is to say "Our server is
-         supplied by person or company X and does whatever their standard
-         issue server does."
-
-            For example:  Our server is a copy of the one operated by
-            the NIC; it will be installed and made operational on
-            1 November 1987.
-
-   (6) Domains must provide at least two independent servers for the
-   domain.  Establishing the servers in physically separate locations
-   and on different PSNs is strongly recommended.  A description of the
-   server machine and its backup, including
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stahl                                                          [Page 11]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-         (a) Hardware and software (using keywords from the Assigned
-         Numbers RFC).
-
-         (b) Host domain name and network addresses (which host on which
-         network for each connected network).
-
-         (c) Any domain-style nicknames (please limit your domain-style
-         nickname request to one)
-
-         For example:
-
-            - Hardware and software
-
-               VAX-11/750  and  UNIX,    or
-               IBM-PC      and  MS-DOS,  or
-               DEC-1090    and  TOPS-20
-
-            - Host domain names and network addresses
-
-               BAR.FOO.COM 10.9.0.193 on ARPANET
-
-            - Domain-style nickname
-
-               BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET)
-
-   (7)  Planned mapping of names of any other network hosts, other than
-   the server machines, into the new domain's naming space.
-
-         For example:
-
-            BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM
-            BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM
-            BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM
-
-
-   (8)  An estimate of the number of hosts that will be in the domain.
-
-         (a) Initially
-         (b) Within one year
-         (c) Two years
-         (d) Five years.
-
-         For example:
-
-            (a) Initially  =   50
-            (b) One year   =  100
-            (c) Two years  =  200
-            (d) Five years =  500
-
-
-
-Stahl                                                          [Page 12]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   (9)  The date you expect the fully qualified domain name to become
-   the official host name in HOSTS.TXT.
-
-         Please note: If changing to a fully qualified domain name (e.g.,
-         FOO.BAR.COM) causes a change in the official host name of an
-         ARPANET or MILNET host, DCA approval must be obtained beforehand.
-         Allow 10 working days for your requested changes to be processed.
-
-         ARPANET sites should contact ARPANETMGR@DDN1.ARPA.  MILNET sites
-         should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for
-         further instructions.
-
-   (10) Please describe your organization briefly.
-
-         For example: The NetWorthy Corporation is a consulting
-         organization of people working with UNIX and the C language in an
-         electronic networking environment.  It sponsors two technical
-         conferences annually and distributes a bimonthly newsletter.
-
-   ---------------------------------------------------------------------
-
-   This example of a completed application corresponds to the examples
-   found in the companion document RFC-1033, "Domain Administrators
-   Operations Guide."
-
-   (1)  The name of the top-level domain to join.
-
-            COM
-
-   (2)  The NIC handle of the administrative contact person.
-
-            NIC Handle    JAKE
-
-   (3)  The NIC handle of the domain's technical and zone
-         contact person.
-
-            NIC Handle    DLE6
-
-   (4)  The name of the domain.
-
-            SRI
-
-   (5)  A description of the servers.
-
-            Our server is the TOPS20 server JEEVES supplied by ISI; it
-            will be installed and made operational on 1 July 1987.
-
-
-
-
-
-Stahl                                                          [Page 13]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   (6)  A description of the server machine and its backup:
-
-            (a) Hardware and software
-
-               DEC-1090T   and  TOPS20
-               DEC-2065    and  TOPS20
-
-            (b) Host domain name and network address
-
-               KL.SRI.COM  10.1.0.2 on ARPANET, 128.18.10.6 on SRINET
-               STRIPE.SRI.COM  10.4.0.2 on ARPANET, 128.18.10.4 on SRINET
-
-            (c) Domain-style nickname
-
-               None
-
-   (7)  Planned mapping of names of any other network hosts, other than
-   the server machines, into the new domain's naming space.
-
-            SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM
-            SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM
-
-   (8)  An estimate of the number of hosts that will be directly within
-   this domain.
-
-            (a) Initially  =   50
-            (b) One year   =  100
-            (c) Two years  =  200
-            (d) Five years =  500
-
-   (9)  A date when you expect the fully qualified domain name to become
-   the official host name in HOSTS.TXT.
-
-            31 September 1987
-
-   (10)  Brief description of organization.
-
-            SRI International is an independent, nonprofit, scientific
-            research organization.  It performs basic and applied research
-            for government and commercial clients, and contributes to
-            worldwide economic, scientific, industrial, and social progress
-            through research and related services.
-
-
-
-
-
-
-
-
-
-Stahl                                                          [Page 14]
-
diff --git a/doc/rfc/rfc1033.txt b/doc/rfc/rfc1033.txt
deleted file mode 100644
index 37029fd9..00000000
--- a/doc/rfc/rfc1033.txt
+++ /dev/null
@@ -1,1229 +0,0 @@
-Network Working Group                                         M. Lottor
-Request For Comments:  1033                           SRI International
-                                                          November 1987
-
-
-                 DOMAIN ADMINISTRATORS OPERATIONS GUIDE
-
-
-
-STATUS OF THIS MEMO
-
-   This RFC provides guidelines for domain administrators in operating a
-   domain server and maintaining their portion of the hierarchical
-   database.  Familiarity with the domain system is assumed.
-   Distribution of this memo is unlimited.
-
-ACKNOWLEDGMENTS
-
-   This memo is a formatted collection of notes and excerpts from the
-   references listed at the end of this document.  Of particular mention
-   are Paul Mockapetris and Kevin Dunlap.
-
-INTRODUCTION
-
-   A domain server requires a few files to get started.  It will
-   normally have some number of boot/startup files (also known as the
-   "safety belt" files).  One section will contain a list of possible
-   root servers that the server will use to find the up-to-date list of
-   root servers.  Another section will list the zone files to be loaded
-   into the server for your local domain information.  A zone file
-   typically contains all the data for a particular domain.  This guide
-   describes the data formats that can be used in zone files and
-   suggested parameters to use for certain fields.  If you are
-   attempting to do anything advanced or tricky, consult the appropriate
-   domain RFC's for more details.
-
-   Note:  Each implementation of domain software may require different
-   files.  Zone files are standardized but some servers may require
-   other startup files.  See the appropriate documentation that comes
-   with your software.  See the appendix for some specific examples.
-
-ZONES
-
-   A zone defines the contents of a contiguous section of the domain
-   space, usually bounded by administrative boundaries.  There will
-   typically be a separate data file for each zone.  The data contained
-   in a zone file is composed of entries called Resource Records (RRs).
-
-
-
-
-Lottor                                                          [Page 1]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   You may only put data in your domain server that you are
-   authoritative for.  You must not add entries for domains other than
-   your own (except for the special case of "glue records").
-
-   A domain server will probably read a file on start-up that lists the
-   zones it should load into its database.  The format of this file is
-   not standardized and is different for most domain server
-   implementations.  For each zone it will normally contain the domain
-   name of the zone and the file name that contains the data to load for
-   the zone.
-
-ROOT SERVERS
-
-   A resolver will need to find the root servers when it first starts.
-   When the resolver boots, it will typically read a list of possible
-   root servers from a file.
-
-   The resolver will cycle through the list trying to contact each one.
-   When it finds a root server, it will ask it for the current list of
-   root servers.  It will then discard the list of root servers it read
-   from the data file and replace it with the current list it received.
-
-   Root servers will not change very often.  You can get the names of
-   current root servers from the NIC.
-
-   FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to
-   NIC@SRI-NIC.ARPA.
-
-   As of this date (June 1987) they are:
-
-           SRI-NIC.ARPA       10.0.0.51    26.0.0.73
-           C.ISI.EDU          10.0.0.52
-           BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
-           A.ISI.EDU          26.3.0.103
-
-RESOURCE RECORDS
-
-   Records in the zone data files are called resource records (RRs).
-   They are specified in RFC-883 and RFC-973.  An RR has a standard
-   format as shown:
-
-           <name>   [<ttl>]   [<class>]   <type>   <data>
-
-   The record is divided into fields which are separated by white space.
-
-      <name>
-
-         The name field defines what domain name applies to the given
-
-
-
-Lottor                                                          [Page 2]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-         RR.  In some cases the name field can be left blank and it will
-         default to the name field of the previous RR.
-
-      <ttl>
-
-         TTL stands for Time To Live.  It specifies how long a domain
-         resolver should cache the RR before it throws it out and asks a
-         domain server again.  See the section on TTL's.  If you leave
-         the TTL field blank it will default to the minimum time
-         specified in the SOA record (described later).
-
-      <class>
-
-         The class field specifies the protocol group.  If left blank it
-         will default to the last class specified.
-
-      <type>
-
-         The type field specifies what type of data is in the RR.  See
-         the section on types.
-
-      <data>
-
-         The data field is defined differently for each type and class
-         of data.  Popular RR data formats are described later.
-
-   The domain system does not guarantee to preserve the order of
-   resource records.  Listing RRs (such as multiple address records) in
-   a certain order does not guarantee they will be used in that order.
-
-   Case is preserved in names and data fields when loaded into the name
-   server.  All comparisons and lookups in the name server are case
-   insensitive.
-
-   Parenthesis ("(",")") are used to group data that crosses a line
-   boundary.
-
-   A semicolon (";") starts a comment; the remainder of the line is
-   ignored.
-
-   The asterisk ("*") is used for wildcarding.
-
-   The at-sign ("@") denotes the current default domain name.
-
-
-
-
-
-
-
-
-Lottor                                                          [Page 3]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-NAMES
-
-   A domain name is a sequence of labels separated by dots.
-
-   Domain names in the zone files can be one of two types, either
-   absolute or relative.  An absolute name is the fully qualified domain
-   name and is terminated with a period.  A relative name does not
-   terminate with a period, and the current default domain is appended
-   to it.  The default domain is usually the name of the domain that was
-   specified in the boot file that loads each zone.
-
-   The domain system allows a label to contain any 8-bit character.
-   Although the domain system has no restrictions, other protocols such
-   as SMTP do have name restrictions.  Because of other protocol
-   restrictions, only the following characters are recommended for use
-   in a host name (besides the dot separator):
-
-           "A-Z", "a-z", "0-9", dash and underscore
-
-TTL's  (Time To Live)
-
-   It is important that TTLs are set to appropriate values.  The TTL is
-   the time (in seconds) that a resolver will use the data it got from
-   your server before it asks your server again.  If you set the value
-   too low, your server will get loaded down with lots of repeat
-   requests.  If you set it too high, then information you change will
-   not get distributed in a reasonable amount of time.  If you leave the
-   TTL field blank, it will default to what is specified in the SOA
-   record for the zone.
-
-   Most host information does not change much over long time periods.  A
-   good way to set up your TTLs would be to set them at a high value,
-   and then lower the value if you know a change will be coming soon.
-   You might set most TTLs to anywhere between a day (86400) and a week
-   (604800).  Then, if you know some data will be changing in the near
-   future, set the TTL for that RR down to a lower value (an hour to a
-   day) until the change takes place, and then put it back up to its
-   previous value.
-
-   Also, all RRs with the same name, class, and type should have the
-   same TTL value.
-
-CLASSES
-
-   The domain system was designed to be protocol independent.  The class
-   field is used to identify the protocol group that each RR is in.
-
-   The class of interest to people using TCP/IP software is the class
-
-
-
-Lottor                                                          [Page 4]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   "Internet".  Its standard designation is "IN".
-
-   A zone file should only contain RRs of the same class.
-
-TYPES
-
-   There are many defined RR types.  For a complete list, see the domain
-   specification RFCs.  Here is a list of current commonly used types.
-   The data for each type is described in the data section.
-
-                Designation                Description
-              ==========================================
-               SOA                 Start Of Authority
-               NS                  Name Server
-
-               A                   Internet Address
-               CNAME               Canonical Name (nickname pointer)
-               HINFO               Host Information
-               WKS                 Well Known Services
-
-               MX                  Mail Exchanger
-
-               PTR                 Pointer
-
-SOA  (Start Of Authority)
-
-           <name>  [<ttl>]  [<class>]  SOA  <origin>  <person>  (
-                           <serial>
-                           <refresh>
-                           <retry>
-                           <expire>
-                           <minimum> )
-
-   The Start Of Authority record designates the start of a zone.  The
-   zone ends at the next SOA record.
-
-   <name> is the name of the zone.
-
-   <origin> is the name of the host on which the master zone file
-   resides.
-
-   <person> is a mailbox for the person responsible for the zone.  It is
-   formatted like a mailing address but the at-sign that normally
-   separates the user from the host name is replaced with a dot.
-
-   <serial> is the version number of the zone file.  It should be
-   incremented anytime a change is made to data in the zone.
-
-
-
-
-Lottor                                                          [Page 5]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   <refresh> is how long, in seconds, a secondary name server is to
-   check with the primary name server to see if an update is needed.  A
-   good value here would be one hour (3600).
-
-   <retry> is how long, in seconds, a secondary name server is to retry
-   after a failure to check for a refresh.  A good value here would be
-   10 minutes (600).
-
-   <expire> is the upper limit, in seconds, that a secondary name server
-   is to use the data before it expires for lack of getting a refresh.
-   You want this to be rather large, and a nice value is 3600000, about
-   42 days.
-
-   <minimum> is the minimum number of seconds to be used for TTL values
-   in RRs.  A minimum of at least a day is a good value here (86400).
-
-   There should only be one SOA record per zone.  A sample SOA record
-   would look something like:
-
-           @   IN   SOA   SRI-NIC.ARPA.   HOSTMASTER.SRI-NIC.ARPA. (
-                           45         ;serial
-                           3600       ;refresh
-                           600        ;retry
-                           3600000    ;expire
-                           86400 )    ;minimum
-
-
-NS  (Name Server)
-
-           <domain>   [<ttl>] [<class>]   NS   <server>
-
-   The NS record lists the name of a machine that provides domain
-   service for a particular domain.  The name associated with the RR is
-   the domain name and the data portion is the name of a host that
-   provides the service.  If machines SRI-NIC.ARPA and C.ISI.EDU provide
-   name lookup service for the domain COM then the following entries
-   would be used:
-
-           COM.    NS      SRI-NIC.ARPA.
-                   NS      C.ISI.EDU.
-
-   Note that the machines providing name service do not have to live in
-   the named domain.  There should be one NS record for each server for
-   a domain.  Also note that the name "COM" defaults for the second NS
-   record.
-
-   NS records for a domain exist in both the zone that delegates the
-   domain, and in the domain itself.
-
-
-
-Lottor                                                          [Page 6]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-GLUE RECORDS
-
-   If the name server host for a particular domain is itself inside the
-   domain, then a 'glue' record will be needed.  A glue record is an A
-   (address) RR that specifies the address of the server.  Glue records
-   are only needed in the server delegating the domain, not in the
-   domain itself.  If for example the name server for domain SRI.COM was
-   KL.SRI.COM, then the NS record would look like this, but you will
-   also need to have the following A record.
-
-           SRI.COM.	NS	KL.SRI.COM.
-           KL.SRI.COM.  A	10.1.0.2
-
-
-A  (Address)
-
-           <host>   [<ttl>] [<class>]   A   <address>
-
-   The data for an A record is an internet address in dotted decimal
-   form.  A sample A record might look like:
-
-           SRI-NIC.ARPA.           A       10.0.0.51
-
-   There should be one A record for each address of a host.
-
-CNAME ( Canonical Name)
-
-           <nickname>   [<ttl>] [<class>]   CNAME   <host>
-
-   The CNAME record is used for nicknames.  The name associated with the
-   RR is the nickname.  The data portion is the official name.  For
-   example, a machine named SRI-NIC.ARPA may want to have the nickname
-   NIC.ARPA.  In that case, the following RR would be used:
-
-           NIC.ARPA.       CNAME   SRI-NIC.ARPA.
-
-   There must not be any other RRs associated with a nickname of the
-   same class.
-
-   Nicknames are also useful when a host changes it's name.  In that
-   case, it is usually a good idea to have a CNAME pointer so that
-   people still using the old name will get to the right place.
-
-
-
-
-
-
-
-
-
-Lottor                                                          [Page 7]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-HINFO (Host Info)
-
-           <host>   [<ttl>] [<class>]   HINFO   <hardware>   <software>
-
-   The HINFO record gives information about a particular host.  The data
-   is two strings separated by whitespace.  The first string is a
-   hardware description and the second is software.  The hardware is
-   usually a manufacturer name followed by a dash and model designation.
-   The software string is usually the name of the operating system.
-
-   Official HINFO types can be found in the latest Assigned Numbers RFC,
-   the latest of which is RFC-1010.  The Hardware type is called the
-   Machine name and the Software type is called the System name.
-
-   Some sample HINFO records:
-
-           SRI-NIC.ARPA.           HINFO   DEC-2060 TOPS20
-           UCBARPA.Berkeley.EDU.   HINFO   VAX-11/780 UNIX
-
-
-WKS (Well Known Services)
-
-           <host> [<ttl>] [<class>] WKS <address> <protocol> <services>
-
-   The WKS record is used to list Well Known Services a host provides.
-   WKS's are defined to be services on port numbers below 256.  The WKS
-   record lists what services are available at a certain address using a
-   certain protocol.  The common protocols are TCP or UDP.  A sample WKS
-   record for a host offering the same services on all address would
-   look like:
-
-   Official protocol names can be found in the latest Assigned Numbers
-   RFC, the latest of which is RFC-1010.
-
-           SRI-NIC.ARPA.   WKS  10.0.0.51  TCP  TELNET FTP SMTP
-                           WKS  10.0.0.51  UDP  TIME
-                           WKS  26.0.0.73  TCP  TELNET FTP SMTP
-                           WKS  26.0.0.73  UDP  TIME
-
-MX (Mail Exchanger)  (See RFC-974 for more details.)
-
-           <name>   [<ttl>] [<class>]   MX   <preference>   <host>
-
-   MX records specify where mail for a domain name should be delivered.
-   There may be multiple MX records for a particular name.  The
-   preference value specifies the order a mailer should try multiple MX
-   records when delivering mail.  Zero is the highest preference.
-   Multiple records for the same name may have the same preference.
-
-
-
-Lottor                                                          [Page 8]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   A host BAR.FOO.COM may want its mail to be delivered to the host
-   PO.FOO.COM and would then use the MX record:
-
-           BAR.FOO.COM.    MX      10      PO.FOO.COM.
-
-   A host BAZ.FOO.COM may want its mail to be delivered to one of three
-   different machines, in the following order:
-
-           BAZ.FOO.COM.    MX      10      PO1.FOO.COM.
-                           MX      20      PO2.FOO.COM.
-                           MX      30      PO3.FOO.COM.
-
-   An entire domain of hosts not connected to the Internet may want
-   their mail to go through a mail gateway that knows how to deliver
-   mail to them.  If they would like mail addressed to any host in the
-   domain FOO.COM to go through the mail gateway they might use:
-
-           FOO.COM.        MX       10     RELAY.CS.NET.
-           *.FOO.COM.      MX       20     RELAY.CS.NET.
-
-   Note that you can specify a wildcard in the MX record to match on
-   anything in FOO.COM, but that it won't match a plain FOO.COM.
-
-IN-ADDR.ARPA
-
-   The structure of names in the domain system is set up in a
-   hierarchical way such that the address of a name can be found by
-   tracing down the domain tree contacting a server for each label of
-   the name.  Because of this 'indexing' based on name, there is no easy
-   way to translate a host address back into its host name.
-
-   In order to do the reverse translation easily, a domain was created
-   that uses hosts' addresses as part of a name that then points to the
-   data for that host.  In this way, there is now an 'index' to hosts'
-   RRs based on their address.  This address mapping domain is called
-   IN-ADDR.ARPA.  Within that domain are subdomains for each network,
-   based on network number.  Also, for consistency and natural
-   groupings, the 4 octets of a host number are reversed.
-
-   For example, the ARPANET is net 10.  That means there is a domain
-   called 10.IN-ADDR.ARPA.  Within this domain there is a PTR RR at
-   51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA
-   (who's address is 10.0.0.51).  Since the NIC is also on the MILNET
-   (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN-
-   ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA.  The format
-   of these special pointers is defined below along with the examples
-   for the NIC.
-
-
-
-
-Lottor                                                          [Page 9]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-PTR
-
-           <special-name>   [<ttl>] [<class>]   PTR   <name>
-
-   The PTR record is used to let special names point to some other
-   location in the domain tree.  They are mainly used in the IN-
-   ADDR.ARPA records for translation of addresses to names.  PTR's
-   should use official names and not aliases.
-
-   For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73
-   would have the following records in the respective zone files for net
-   10 and net 26:
-
-           51.0.0.10.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
-           73.0.0.26.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
-
-GATEWAY PTR's
-
-   The IN-ADDR tree is also used to locate gateways on a particular
-   network.  Gateways have the same kind of PTR RRs as hosts (as above)
-   but in addition they have other PTRs used to locate them by network
-   number alone.  These records have only 1, 2, or 3 octets as part of
-   the name depending on whether they are class A, B, or C networks,
-   respectively.
-
-   Lets take the SRI-CSL gateway for example.  It connects 3 different
-   networks, one class A, one class B and one class C.  It will have the
-   standard RR's for a host in the CSL.SRI.COM zone:
-
-           GW.CSL.SRI.COM.    A    10.2.0.2
-                              A    128.18.1.1
-                              A    192.12.33.2
-
-   Also, in 3 different zones (one for each network), it will have one
-   of the following number to name translation pointers:
-
-           2.0.2.10.IN-ADDR.ARPA.      PTR   GW.CSL.SRI.COM.
-           1.1.18.128.IN-ADDR.ARPA.    PTR   GW.CSL.SRI.COM.
-           1.33.12.192.IN-ADDR.ARPA.   PTR   GW.CSL.SRI.COM.
-
-   In addition, in each of the same 3 zones will be one of the following
-   gateway location pointers:
-
-           10.IN-ADDR.ARPA.            PTR   GW.CSL.SRI.COM.
-           18.128.IN-ADDR.ARPA.        PTR   GW.CSL.SRI.COM.
-           33.12.192.IN-ADDR.ARPA.     PTR   GW.CSL.SRI.COM.
-
-
-
-
-
-Lottor                                                         [Page 10]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-INSTRUCTIONS
-
-   Adding a subdomain.
-
-      To add a new subdomain to your domain:
-
-         Setup the other domain server and/or the new zone file.
-
-         Add an NS record for each server of the new domain to the zone
-         file of the parent domain.
-
-         Add any necessary glue RRs.
-
-   Adding a host.
-
-      To add a new host to your zone files:
-
-         Edit the appropriate zone file for the domain the host is in.
-
-         Add an entry for each address of the host.
-
-         Optionally add CNAME, HINFO, WKS, and MX records.
-
-         Add the reverse IN-ADDR entry for each host address in the
-         appropriate zone files for each network the host in on.
-
-   Deleting a host.
-
-      To delete a host from the zone files:
-
-         Remove all the hosts' resource records from the zone file of
-         the domain the host is in.
-
-         Remove all the hosts' PTR records from the IN-ADDR zone files
-         for each network the host was on.
-
-   Adding gateways.
-
-         Follow instructions for adding a host.
-
-         Add the gateway location PTR records for each network the
-         gateway is on.
-
-   Deleting gateways.
-
-         Follow instructions for deleting a host.
-
-         Also delete the gateway location PTR records for each network
-
-
-
-Lottor                                                         [Page 11]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-         the gateway was on.
-
-COMPLAINTS
-
-   These are the suggested steps you should take if you are having
-   problems that you believe are caused by someone else's name server:
-
-
-   1.  Complain privately to the responsible person for the domain.  You
-   can find their mailing address in the SOA record for the domain.
-
-   2.  Complain publicly to the responsible person for the domain.
-
-   3.  Ask the NIC for the administrative person responsible for the
-   domain.  Complain.  You can also find domain contacts on the NIC in
-   the file NETINFO:DOMAIN-CONTACTS.TXT
-
-   4.  Complain to the parent domain authorities.
-
-   5.  Ask the parent authorities to excommunicate the domain.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 12]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-EXAMPLE DOMAIN SERVER DATABASE FILES
-
-   The following examples show how zone files are set up for a typical
-   organization.  SRI will be used as the example organization.  SRI has
-   decided to divided their domain SRI.COM into a few subdomains, one
-   for each group that wants one.  The subdomains are CSL and ISTC.
-
-   Note the following interesting items:
-
-      There are both hosts and domains under SRI.COM.
-
-      CSL.SRI.COM is both a domain name and a host name.
-
-      All the domains are serviced by the same pair of domain servers.
-
-      All hosts at SRI are on net 128.18 except hosts in the CSL domain
-      which are on net 192.12.33.  Note that a domain does not have to
-      correspond to a physical network.
-
-      The examples do not necessarily correspond to actual data in use
-      by the SRI domain.
-
-                       SRI Domain Organization
-
-                               +-------+
-                               |  COM  |
-                               +-------+
-                                   |
-                               +-------+
-                               |  SRI  |
-                               +-------+
-                                   |
-                        +----------++-----------+
-                        |           |           |
-                    +-------+    +------+   +-------+
-                    |  CSL  |    | ISTC |   | Hosts |
-                    +-------+    +------+   +-------+
-                        |           |
-                    +-------+    +-------+
-                    | Hosts |    | Hosts |
-                    +-------+    +-------+
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 13]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "CONFIG.CMD".  Since bootstrap files are not standardized, this
-   file is presented using a pseudo configuration file syntax.]
-
-   load root server list             from file ROOT.SERVERS
-   load zone SRI.COM.                from file SRI.ZONE
-   load zone CSL.SRI.COM.            from file CSL.ZONE
-   load zone ISTC.SRI.COM.           from file ISTC.ZONE
-   load zone 18.128.IN-ADDR.ARPA.    from file SRINET.ZONE
-   load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 14]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "ROOT.SERVERS".  Again, the format of this file is not
-   standardized.]
-
-   ;list of possible root servers
-   SRI-NIC.ARPA       10.0.0.51    26.0.0.73
-   C.ISI.EDU          10.0.0.52
-   BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
-   A.ISI.EDU          26.3.0.103
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 15]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "SRI.ZONE"]
-
-   SRI.COM.        IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
-                                   870407  ;serial
-                                   1800    ;refresh every 30 minutes
-                                   600     ;retry every 10 minutes
-                                   604800  ;expire after a week
-                                   86400   ;default of an hour
-                                   )
-
-   SRI.COM.        NS      KL.SRI.COM.
-                   NS      STRIPE.SRI.COM.
-                   MX      10      KL.SRI.COM.
-
-   ;SRI.COM hosts
-
-   KL              A       10.1.0.2
-                   A       128.18.10.6
-                   MX      10      KL.SRI.COM.
-
-   STRIPE          A       10.4.0.2
-   STRIPE          A       128.18.10.4
-                   MX      10      STRIPE.SRI.COM.
-
-   NIC             CNAME   SRI-NIC.ARPA.
-
-   Blackjack       A       128.18.2.1
-                   HINFO   VAX-11/780      UNIX
-                   WKS     128.18.2.1      TCP TELNET FTP
-
-   CSL             A       192.12.33.2
-                   HINFO   FOONLY-F4       TOPS20
-                   WKS     192.12.33.2     TCP TELNET FTP SMTP FINGER
-                   MX      10      CSL.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 16]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "CSL.ZONE"]
-
-   CSL.SRI.COM.    IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
-                                   870330  ;serial
-                                   1800    ;refresh every 30 minutes
-                                   600     ;retry every 10 minutes
-                                   604800  ;expire after a week
-                                   86400   ;default of a day
-                                   )
-
-   CSL.SRI.COM.    NS              KL.SRI.COM.
-                   NS              STRIPE.SRI.COM.
-                   A               192.12.33.2
-
-   ;CSL.SRI.COM hosts
-
-   A               CNAME   CSL.SRI.COM.
-   B               A       192.12.33.3
-                   HINFO   FOONLY-F4       TOPS20
-                   WKS     192.12.33.3     TCP TELNET FTP SMTP
-   GW              A       10.2.0.2
-                   A       192.12.33.1
-                   A       128.18.1.1
-                   HINFO   PDP-11/23       MOS
-   SMELLY          A       192.12.33.4
-                   HINFO   IMAGEN          IMAGEN
-   SQUIRREL        A       192.12.33.5
-                   HINFO   XEROX-1100      INTERLISP
-   VENUS           A       192.12.33.7
-                   HINFO   SYMBOLICS-3600  LISPM
-   HELIUM          A       192.12.33.30
-                   HINFO   SUN-3/160       UNIX
-   ARGON           A       192.12.33.31
-                   HINFO   SUN-3/75        UNIX
-   RADON           A       192.12.33.32
-                   HINFO   SUN-3/75        UNIX
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 17]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "ISTC.ZONE"]
-
-   ISTC.SRI.COM.   IN  SOA     KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (
-                               870406      ;serial
-                               1800        ;refresh every 30 minutes
-                               600         ;retry every 10 minutes
-                               604800      ;expire after a week
-                               86400       ;default of a day
-                               )
-
-   ISTC.SRI.COM.   NS              KL.SRI.COM.
-                   NS              STRIPE.SRI.COM.
-                   MX              10      SPAM.ISTC.SRI.COM.
-
-   ; ISTC hosts
-
-   joyce           A       128.18.4.2
-                   HINFO   VAX-11/750 UNIX
-   bozo            A       128.18.0.6
-                   HINFO   SUN UNIX
-   sundae          A       128.18.0.11
-                   HINFO   SUN UNIX
-   tsca            A       128.18.0.201
-                   A       10.3.0.2
-                   HINFO   VAX-11/750 UNIX
-                   MX      10  TSCA.ISTC.SRI.COM.
-   tsc             CNAME   tsca
-   prmh            A       128.18.0.203
-                   A       10.2.0.51
-                   HINFO   PDP-11/44 UNIX
-   spam            A       128.18.4.3
-                   A       10.2.0.107
-                   HINFO   VAX-11/780 UNIX
-                   MX      10  SPAM.ISTC.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 18]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "SRINET.ZONE"]
-
-   18.128.IN-ADDR.ARPA.    IN  SOA  KL.SRI.COM  DLE.STRIPE.SRI.COM. (
-                               870406  ;serial
-                               1800    ;refresh every 30 minutes
-                               600     ;retry every 10 minutes
-                               604800  ;expire after a week
-                               86400   ;default of a day
-                               )
-
-   18.128.IN-ADDR.ARPA.    NS      KL.SRI.COM.
-                           NS      STRIPE.SRI.COM.
-                           PTR     GW.CSL.SRI.COM.
-
-   ; SRINET [128.18.0.0] Address Translations
-
-   ; SRI.COM Hosts
-   1.2.18.128.IN-ADDR.ARPA.        PTR     Blackjack.SRI.COM.
-
-   ; ISTC.SRI.COM Hosts
-   2.4.18.128.IN-ADDR.ARPA.        PTR     joyce.ISTC.SRI.COM.
-   6.0.18.128.IN-ADDR.ARPA.        PTR     bozo.ISTC.SRI.COM.
-   11.0.18.128.IN-ADDR.ARPA.       PTR     sundae.ISTC.SRI.COM.
-   201.0.18.128.IN-ADDR.ARPA.      PTR     tsca.ISTC.SRI.COM.
-   203.0.18.128.IN-ADDR.ARPA.      PTR     prmh.ISTC.SRI.COM.
-   3.4.18.128.IN-ADDR.ARPA.        PTR     spam.ISTC.SRI.COM.
-
-   ; CSL.SRI.COM Hosts
-   1.1.18.128.IN-ADDR.ARPA.        PTR     GW.CSL.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 19]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "SRI-CSL-NET.ZONE"]
-
-   33.12.192.IN-ADDR.ARPA. IN  SOA KL.SRI.COM  DLE.STRIPE.SRI.COM. (
-                               870404  ;serial
-                               1800    ;refresh every 30 minutes
-                               600     ;retry every 10 minutes
-                               604800  ;expire after a week
-                               86400   ;default of a day
-                               )
-
-   33.12.192.IN-ADDR.ARPA. NS      KL.SRI.COM.
-                           NS      STRIPE.SRI.COM.
-                           PTR     GW.CSL.SRI.COM.
-
-   ; SRI-CSL-NET [192.12.33.0] Address Translations
-
-   ; SRI.COM Hosts
-   2.33.12.192.IN-ADDR.ARPA.       PTR     CSL.SRI.COM.
-
-   ; CSL.SRI.COM Hosts
-   1.33.12.192.IN-ADDR.ARPA.       PTR     GW.CSL.SRI.COM.
-   3.33.12.192.IN-ADDR.ARPA.       PTR     B.CSL.SRI.COM.
-   4.33.12.192.IN-ADDR.ARPA.       PTR     SMELLY.CSL.SRI.COM.
-   5.33.12.192.IN-ADDR.ARPA.       PTR     SQUIRREL.CSL.SRI.COM.
-   7.33.12.192.IN-ADDR.ARPA.       PTR     VENUS.CSL.SRI.COM.
-   30.33.12.192.IN-ADDR.ARPA.      PTR     HELIUM.CSL.SRI.COM.
-   31.33.12.192.IN-ADDR.ARPA.      PTR     ARGON.CSL.SRI.COM.
-   32.33.12.192.IN-ADDR.ARPA.      PTR     RADON.CSL.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 20]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-APPENDIX
-
-   BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD
-   UNIX
-
-   This section describes two BIND implementation specific files; the
-   boot file and the cache file.  BIND has other options, files, and
-   specifications that are not described here.  See the Name Server
-   Operations Guide for BIND for details.
-
-   The boot file for BIND is usually called "named.boot".  This
-   corresponds to file "CONFIG.CMD" in the example section.
-
-           --------------------------------------------------------
-           cache         .                         named.ca
-           primary       SRI.COM                   SRI.ZONE
-           primary       CSL.SRI.COM               CSL.ZONE
-           primary       ISTC.SRI.COM              ISTC.ZONE
-           primary       18.128.IN-ADDR.ARPA       SRINET.ZONE
-           primary       33.12.192.IN-ADDR.ARPA    SRI-CSL-NET.ZONE
-           --------------------------------------------------------
-
-   The cache file for BIND is usually called "named.ca".  This
-   corresponds to file "ROOT.SERVERS" in the example section.
-
-           -------------------------------------------------
-           ;list of possible root servers
-           .       1          IN   NS   SRI-NIC.ARPA.
-                                   NS   C.ISI.EDU.
-                                   NS   BRL-AOS.ARPA.
-                                   NS   C.ISI.EDU.
-           ;and their addresses
-           SRI-NIC.ARPA.           A    10.0.0.51
-                                   A    26.0.0.73
-           C.ISI.EDU.              A    10.0.0.52
-           BRL-AOS.ARPA.           A    192.5.25.82
-                                   A    192.5.22.82
-                                   A    128.20.1.2
-           A.ISI.EDU.              A    26.3.0.103
-           -------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 21]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-REFERENCES
-
-   [1]  Dunlap, K., "Name Server Operations Guide for BIND", CSRG,
-        Department of Electrical Engineering and Computer Sciences,
-        University of California, Berkeley, California.
-
-   [2]  Partridge, C., "Mail Routing and the Domain System", RFC-974,
-        CSNET CIC BBN Laboratories, January 1986.
-
-   [3]  Mockapetris, P., "Domains Names - Concepts and Facilities",
-        RFC-1034, USC/Information Sciences Institute, November 1987.
-
-   [4]  Mockapetris, P., "Domain Names - Implementations Specification",
-        RFC-1035, USC/Information Sciences Institute, November 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 22]
-
diff --git a/doc/rfc/rfc1034.txt b/doc/rfc/rfc1034.txt
deleted file mode 100644
index 55cdb21f..00000000
--- a/doc/rfc/rfc1034.txt
+++ /dev/null
@@ -1,3077 +0,0 @@
-Network Working Group                                     P. Mockapetris
-Request for Comments: 1034                                           ISI
-Obsoletes: RFCs 882, 883, 973                              November 1987
-
-
-                 DOMAIN NAMES - CONCEPTS AND FACILITIES
-
-
-
-1. STATUS OF THIS MEMO
-
-This RFC is an introduction to the Domain Name System (DNS), and omits
-many details which can be found in a companion RFC, "Domain Names -
-Implementation and Specification" [RFC-1035].  That RFC assumes that the
-reader is familiar with the concepts discussed in this memo.
-
-A subset of DNS functions and data types constitute an official
-protocol.  The official protocol includes standard queries and their
-responses and most of the Internet class data formats (e.g., host
-addresses).
-
-However, the domain system is intentionally extensible.  Researchers are
-continuously proposing, implementing and experimenting with new data
-types, query types, classes, functions, etc.  Thus while the components
-of the official protocol are expected to stay essentially unchanged and
-operate as a production service, experimental behavior should always be
-expected in extensions beyond the official protocol.  Experimental or
-obsolete features are clearly marked in these RFCs, and such information
-should be used with caution.
-
-The reader is especially cautioned not to depend on the values which
-appear in examples to be current or complete, since their purpose is
-primarily pedagogical.  Distribution of this memo is unlimited.
-
-2. INTRODUCTION
-
-This RFC introduces domain style names, their use for Internet mail and
-host address support, and the protocols and servers used to implement
-domain name facilities.
-
-2.1. The history of domain names
-
-The impetus for the development of the domain system was growth in the
-Internet:
-
-   - Host name to address mappings were maintained by the Network
-     Information Center (NIC) in a single file (HOSTS.TXT) which
-     was FTPed by all hosts [RFC-952, RFC-953].  The total network
-
-
-
-Mockapetris                                                     [Page 1]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     bandwidth consumed in distributing a new version by this
-     scheme is proportional to the square of the number of hosts in
-     the network, and even when multiple levels of FTP are used,
-     the outgoing FTP load on the NIC host is considerable.
-     Explosive growth in the number of hosts didn't bode well for
-     the future.
-
-   - The network population was also changing in character.  The
-     timeshared hosts that made up the original ARPANET were being
-     replaced with local networks of workstations.  Local
-     organizations were administering their own names and
-     addresses, but had to wait for the NIC to change HOSTS.TXT to
-     make changes visible to the Internet at large.  Organizations
-     also wanted some local structure on the name space.
-
-   - The applications on the Internet were getting more
-     sophisticated and creating a need for general purpose name
-     service.
-
-
-The result was several ideas about name spaces and their management
-[IEN-116, RFC-799, RFC-819, RFC-830].  The proposals varied, but a
-common thread was the idea of a hierarchical name space, with the
-hierarchy roughly corresponding to organizational structure, and names
-using "."  as the character to mark the boundary between hierarchy
-levels.  A design using a distributed database and generalized resources
-was described in [RFC-882, RFC-883].  Based on experience with several
-implementations, the system evolved into the scheme described in this
-memo.
-
-The terms "domain" or "domain name" are used in many contexts beyond the
-DNS described here.  Very often, the term domain name is used to refer
-to a name with structure indicated by dots, but no relation to the DNS.
-This is particularly true in mail addressing [Quarterman 86].
-
-2.2. DNS design goals
-
-The design goals of the DNS influence its structure.  They are:
-
-   - The primary goal is a consistent name space which will be used
-     for referring to resources.  In order to avoid the problems
-     caused by ad hoc encodings, names should not be required to
-     contain network identifiers, addresses, routes, or similar
-     information as part of the name.
-
-   - The sheer size of the database and frequency of updates
-     suggest that it must be maintained in a distributed manner,
-     with local caching to improve performance.  Approaches that
-
-
-
-Mockapetris                                                     [Page 2]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     attempt to collect a consistent copy of the entire database
-     will become more and more expensive and difficult, and hence
-     should be avoided.  The same principle holds for the structure
-     of the name space, and in particular mechanisms for creating
-     and deleting names; these should also be distributed.
-
-   - Where there tradeoffs between the cost of acquiring data, the
-     speed of updates, and the accuracy of caches, the source of
-     the data should control the tradeoff.
-
-   - The costs of implementing such a facility dictate that it be
-     generally useful, and not restricted to a single application.
-     We should be able to use names to retrieve host addresses,
-     mailbox data, and other as yet undetermined information.  All
-     data associated with a name is tagged with a type, and queries
-     can be limited to a single type.
-
-   - Because we want the name space to be useful in dissimilar
-     networks and applications, we provide the ability to use the
-     same name space with different protocol families or
-     management.  For example, host address formats differ between
-     protocols, though all protocols have the notion of address.
-     The DNS tags all data with a class as well as the type, so
-     that we can allow parallel use of different formats for data
-     of type address.
-
-   - We want name server transactions to be independent of the
-     communications system that carries them.  Some systems may
-     wish to use datagrams for queries and responses, and only
-     establish virtual circuits for transactions that need the
-     reliability (e.g., database updates, long transactions); other
-     systems will use virtual circuits exclusively.
-
-   - The system should be useful across a wide spectrum of host
-     capabilities.  Both personal computers and large timeshared
-     hosts should be able to use the system, though perhaps in
-     different ways.
-
-2.3. Assumptions about usage
-
-The organization of the domain system derives from some assumptions
-about the needs and usage patterns of its user community and is designed
-to avoid many of the the complicated problems found in general purpose
-database systems.
-
-The assumptions are:
-
-   - The size of the total database will initially be proportional
-
-
-
-Mockapetris                                                     [Page 3]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     to the number of hosts using the system, but will eventually
-     grow to be proportional to the number of users on those hosts
-     as mailboxes and other information are added to the domain
-     system.
-
-   - Most of the data in the system will change very slowly (e.g.,
-     mailbox bindings, host addresses), but that the system should
-     be able to deal with subsets that change more rapidly (on the
-     order of seconds or minutes).
-
-   - The administrative boundaries used to distribute
-     responsibility for the database will usually correspond to
-     organizations that have one or more hosts.  Each organization
-     that has responsibility for a particular set of domains will
-     provide redundant name servers, either on the organization's
-     own hosts or other hosts that the organization arranges to
-     use.
-
-   - Clients of the domain system should be able to identify
-     trusted name servers they prefer to use before accepting
-     referrals to name servers outside of this "trusted" set.
-
-   - Access to information is more critical than instantaneous
-     updates or guarantees of consistency.  Hence the update
-     process allows updates to percolate out through the users of
-     the domain system rather than guaranteeing that all copies are
-     simultaneously updated.  When updates are unavailable due to
-     network or host failure, the usual course is to believe old
-     information while continuing efforts to update it.  The
-     general model is that copies are distributed with timeouts for
-     refreshing.  The distributor sets the timeout value and the
-     recipient of the distribution is responsible for performing
-     the refresh.  In special situations, very short intervals can
-     be specified, or the owner can prohibit copies.
-
-   - In any system that has a distributed database, a particular
-     name server may be presented with a query that can only be
-     answered by some other server.  The two general approaches to
-     dealing with this problem are "recursive", in which the first
-     server pursues the query for the client at another server, and
-     "iterative", in which the server refers the client to another
-     server and lets the client pursue the query.  Both approaches
-     have advantages and disadvantages, but the iterative approach
-     is preferred for the datagram style of access.  The domain
-     system requires implementation of the iterative approach, but
-     allows the recursive approach as an option.
-
-
-
-
-
-Mockapetris                                                     [Page 4]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-The domain system assumes that all data originates in master files
-scattered through the hosts that use the domain system.  These master
-files are updated by local system administrators.  Master files are text
-files that are read by a local name server, and hence become available
-through the name servers to users of the domain system.  The user
-programs access name servers through standard programs called resolvers.
-
-The standard format of master files allows them to be exchanged between
-hosts (via FTP, mail, or some other mechanism); this facility is useful
-when an organization wants a domain, but doesn't want to support a name
-server.  The organization can maintain the master files locally using a
-text editor, transfer them to a foreign host which runs a name server,
-and then arrange with the system administrator of the name server to get
-the files loaded.
-
-Each host's name servers and resolvers are configured by a local system
-administrator [RFC-1033].  For a name server, this configuration data
-includes the identity of local master files and instructions on which
-non-local master files are to be loaded from foreign servers.  The name
-server uses the master files or copies to load its zones.  For
-resolvers, the configuration data identifies the name servers which
-should be the primary sources of information.
-
-The domain system defines procedures for accessing the data and for
-referrals to other name servers.  The domain system also defines
-procedures for caching retrieved data and for periodic refreshing of
-data defined by the system administrator.
-
-The system administrators provide:
-
-   - The definition of zone boundaries.
-
-   - Master files of data.
-
-   - Updates to master files.
-
-   - Statements of the refresh policies desired.
-
-The domain system provides:
-
-   - Standard formats for resource data.
-
-   - Standard methods for querying the database.
-
-   - Standard methods for name servers to refresh local data from
-     foreign name servers.
-
-
-
-
-
-Mockapetris                                                     [Page 5]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-2.4. Elements of the DNS
-
-The DNS has three major components:
-
-   - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
-     specifications for a tree structured name space and data
-     associated with the names.  Conceptually, each node and leaf
-     of the domain name space tree names a set of information, and
-     query operations are attempts to extract specific types of
-     information from a particular set.  A query names the domain
-     name of interest and describes the type of resource
-     information that is desired.  For example, the Internet
-     uses some of its domain names to identify hosts; queries for
-     address resources return Internet host addresses.
-
-   - NAME SERVERS are server programs which hold information about
-     the domain tree's structure and set information.  A name
-     server may cache structure or set information about any part
-     of the domain tree, but in general a particular name server
-     has complete information about a subset of the domain space,
-     and pointers to other name servers that can be used to lead to
-     information from any part of the domain tree.  Name servers
-     know the parts of the domain tree for which they have complete
-     information; a name server is said to be an AUTHORITY for
-     these parts of the name space.  Authoritative information is
-     organized into units called ZONEs, and these zones can be
-     automatically distributed to the name servers which provide
-     redundant service for the data in a zone.
-
-   - RESOLVERS are programs that extract information from name
-     servers in response to client requests.  Resolvers must be
-     able to access at least one name server and use that name
-     server's information to answer a query directly, or pursue the
-     query using referrals to other name servers.  A resolver will
-     typically be a system routine that is directly accessible to
-     user programs; hence no protocol is necessary between the
-     resolver and the user program.
-
-These three components roughly correspond to the three layers or views
-of the domain system:
-
-   - From the user's point of view, the domain system is accessed
-     through a simple procedure or OS call to a local resolver.
-     The domain space consists of a single tree and the user can
-     request information from any section of the tree.
-
-   - From the resolver's point of view, the domain system is
-     composed of an unknown number of name servers.  Each name
-
-
-
-Mockapetris                                                     [Page 6]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     server has one or more pieces of the whole domain tree's data,
-     but the resolver views each of these databases as essentially
-     static.
-
-   - From a name server's point of view, the domain system consists
-     of separate sets of local information called zones.  The name
-     server has local copies of some of the zones.  The name server
-     must periodically refresh its zones from master copies in
-     local files or foreign name servers.  The name server must
-     concurrently process queries that arrive from resolvers.
-
-In the interests of performance, implementations may couple these
-functions.  For example, a resolver on the same machine as a name server
-might share a database consisting of the the zones managed by the name
-server and the cache managed by the resolver.
-
-3. DOMAIN NAME SPACE and RESOURCE RECORDS
-
-3.1. Name space specifications and terminology
-
-The domain name space is a tree structure.  Each node and leaf on the
-tree corresponds to a resource set (which may be empty).  The domain
-system makes no distinctions between the uses of the interior nodes and
-leaves, and this memo uses the term "node" to refer to both.
-
-Each node has a label, which is zero to 63 octets in length.  Brother
-nodes may not have the same label, although the same label can be used
-for nodes which are not brothers.  One label is reserved, and that is
-the null (i.e., zero length) label used for the root.
-
-The domain name of a node is the list of the labels on the path from the
-node to the root of the tree.  By convention, the labels that compose a
-domain name are printed or read left to right, from the most specific
-(lowest, farthest from the root) to the least specific (highest, closest
-to the root).
-
-Internally, programs that manipulate domain names should represent them
-as sequences of labels, where each label is a length octet followed by
-an octet string.  Because all domain names end at the root, which has a
-null string for a label, these internal representations can use a length
-byte of zero to terminate a domain name.
-
-By convention, domain names can be stored with arbitrary case, but
-domain name comparisons for all present domain functions are done in a
-case-insensitive manner, assuming an ASCII character set, and a high
-order zero bit.  This means that you are free to create a node with
-label "A" or a node with label "a", but not both as brothers; you could
-refer to either using "a" or "A".  When you receive a domain name or
-
-
-
-Mockapetris                                                     [Page 7]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-label, you should preserve its case.  The rationale for this choice is
-that we may someday need to add full binary domain names for new
-services; existing services would not be changed.
-
-When a user needs to type a domain name, the length of each label is
-omitted and the labels are separated by dots (".").  Since a complete
-domain name ends with the root label, this leads to a printed form which
-ends in a dot.  We use this property to distinguish between:
-
-   - a character string which represents a complete domain name
-     (often called "absolute").  For example, "poneria.ISI.EDU."
-
-   - a character string that represents the starting labels of a
-     domain name which is incomplete, and should be completed by
-     local software using knowledge of the local domain (often
-     called "relative").  For example, "poneria" used in the
-     ISI.EDU domain.
-
-Relative names are either taken relative to a well known origin, or to a
-list of domains used as a search list.  Relative names appear mostly at
-the user interface, where their interpretation varies from
-implementation to implementation, and in master files, where they are
-relative to a single origin domain name.  The most common interpretation
-uses the root "." as either the single origin or as one of the members
-of the search list, so a multi-label relative name is often one where
-the trailing dot has been omitted to save typing.
-
-To simplify implementations, the total number of octets that represent a
-domain name (i.e., the sum of all label octets and label lengths) is
-limited to 255.
-
-A domain is identified by a domain name, and consists of that part of
-the domain name space that is at or below the domain name which
-specifies the domain.  A domain is a subdomain of another domain if it
-is contained within that domain.  This relationship can be tested by
-seeing if the subdomain's name ends with the containing domain's name.
-For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
-
-3.2. Administrative guidelines on use
-
-As a matter of policy, the DNS technical specifications do not mandate a
-particular tree structure or rules for selecting labels; its goal is to
-be as general as possible, so that it can be used to build arbitrary
-applications.  In particular, the system was designed so that the name
-space did not have to be organized along the lines of network
-boundaries, name servers, etc.  The rationale for this is not that the
-name space should have no implied semantics, but rather that the choice
-of implied semantics should be left open to be used for the problem at
-
-
-
-Mockapetris                                                     [Page 8]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-hand, and that different parts of the tree can have different implied
-semantics.  For example, the IN-ADDR.ARPA domain is organized and
-distributed by network and host address because its role is to translate
-from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-
-1002] are flat because that is appropriate for that application.
-
-However, there are some guidelines that apply to the "normal" parts of
-the name space used for hosts, mailboxes, etc., that will make the name
-space more uniform, provide for growth, and minimize problems as
-software is converted from the older host table.  The political
-decisions about the top levels of the tree originated in RFC-920.
-Current policy for the top levels is discussed in [RFC-1032].  MILNET
-conversion issues are covered in [RFC-1031].
-
-Lower domains which will eventually be broken into multiple zones should
-provide branching at the top of the domain so that the eventual
-decomposition can be done without renaming.  Node labels which use
-special characters, leading digits, etc., are likely to break older
-software which depends on more restrictive choices.
-
-3.3. Technical guidelines on use
-
-Before the DNS can be used to hold naming information for some kind of
-object, two needs must be met:
-
-   - A convention for mapping between object names and domain
-     names.  This describes how information about an object is
-     accessed.
-
-   - RR types and data formats for describing the object.
-
-These rules can be quite simple or fairly complex.  Very often, the
-designer must take into account existing formats and plan for upward
-compatibility for existing usage.  Multiple mappings or levels of
-mapping may be required.
-
-For hosts, the mapping depends on the existing syntax for host names
-which is a subset of the usual text representation for domain names,
-together with RR formats for describing host addresses, etc.  Because we
-need a reliable inverse mapping from address to host name, a special
-mapping for addresses into the IN-ADDR.ARPA domain is also defined.
-
-For mailboxes, the mapping is slightly more complex.  The usual mail
-address <local-part>@<mail-domain> is mapped into a domain name by
-converting <local-part> into a single label (regardles of dots it
-contains), converting <mail-domain> into a domain name using the usual
-text format for domain names (dots denote label breaks), and
-concatenating the two to form a single domain name.  Thus the mailbox
-
-
-
-Mockapetris                                                     [Page 9]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by
-HOSTMASTER.SRI-NIC.ARPA.  An appreciation for the reasons behind this
-design also must take into account the scheme for mail exchanges [RFC-
-974].
-
-The typical user is not concerned with defining these rules, but should
-understand that they usually are the result of numerous compromises
-between desires for upward compatibility with old usage, interactions
-between different object definitions, and the inevitable urge to add new
-features when defining the rules.  The way the DNS is used to support
-some object is often more crucial than the restrictions inherent in the
-DNS.
-
-3.4. Example name space
-
-The following figure shows a part of the current domain name space, and
-is used in many examples in this RFC.  Note that the tree is a very
-small subset of the actual name space.
-
-                                   |
-                                   |
-             +---------------------+------------------+
-             |                     |                  |
-            MIL                   EDU                ARPA
-             |                     |                  |
-             |                     |                  |
-       +-----+-----+               |     +------+-----+-----+
-       |     |     |               |     |      |           |
-      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
-                                   |
-       +--------+------------------+---------------+--------+
-       |        |                  |               |        |
-      UCI      MIT                 |              UDEL     YALE
-                |                 ISI
-                |                  |
-            +---+---+              |
-            |       |              |
-           LCS  ACHILLES  +--+-----+-----+--------+
-            |             |  |     |     |        |
-            XX            A  C   VAXA  VENERA Mockapetris
-
-In this example, the root domain has three immediate subdomains: MIL,
-EDU, and ARPA.  The LCS.MIT.EDU domain has one immediate subdomain named
-XX.LCS.MIT.EDU.  All of the leaves are also domains.
-
-3.5. Preferred name syntax
-
-The DNS specifications attempt to be as general as possible in the rules
-
-
-
-Mockapetris                                                    [Page 10]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-for constructing domain names.  The idea is that the name of any
-existing object can be expressed as a domain name with minimal changes.
-However, when assigning a domain name for an object, the prudent user
-will select a name which satisfies both the rules of the domain system
-and any existing rules for the object, whether these rules are published
-or implied by existing programs.
-
-For example, when naming a mail domain, the user should satisfy both the
-rules of this memo and those in RFC-822.  When creating a new host name,
-the old rules for HOSTS.TXT should be followed.  This avoids problems
-when old software is converted to use domain names.
-
-The following syntax will result in fewer problems with many
-applications that use domain names (e.g., mail, TELNET).
-
-<domain> ::= <subdomain> | " "
-
-<subdomain> ::= <label> | <subdomain> "." <label>
-
-<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
-
-<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
-
-<let-dig-hyp> ::= <let-dig> | "-"
-
-<let-dig> ::= <letter> | <digit>
-
-<letter> ::= any one of the 52 alphabetic characters A through Z in
-upper case and a through z in lower case
-
-<digit> ::= any one of the ten digits 0 through 9
-
-Note that while upper and lower case letters are allowed in domain
-names, no significance is attached to the case.  That is, two names with
-the same spelling but different case are to be treated as if identical.
-
-The labels must follow the rules for ARPANET host names.  They must
-start with a letter, end with a letter or digit, and have as interior
-characters only letters, digits, and hyphen.  There are also some
-restrictions on the length.  Labels must be 63 characters or less.
-
-For example, the following strings identify hosts in the Internet:
-
-A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA
-
-3.6. Resource Records
-
-A domain name identifies a node.  Each node has a set of resource
-
-
-
-Mockapetris                                                    [Page 11]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-information, which may be empty.  The set of resource information
-associated with a particular name is composed of separate resource
-records (RRs).  The order of RRs in a set is not significant, and need
-not be preserved by name servers, resolvers, or other parts of the DNS.
-
-When we talk about a specific RR, we assume it has the following:
-
-owner           which is the domain name where the RR is found.
-
-type            which is an encoded 16 bit value that specifies the type
-                of the resource in this resource record.  Types refer to
-                abstract resources.
-
-                This memo uses the following types:
-
-                A               a host address
-
-                CNAME           identifies the canonical name of an
-                                alias
-
-                HINFO           identifies the CPU and OS used by a host
-
-                MX              identifies a mail exchange for the
-                                domain.  See [RFC-974 for details.
-
-                NS
-                the authoritative name server for the domain
-
-                PTR
-                a pointer to another part of the domain name space
-
-                SOA
-                identifies the start of a zone of authority]
-
-class           which is an encoded 16 bit value which identifies a
-                protocol family or instance of a protocol.
-
-                This memo uses the following classes:
-
-                IN              the Internet system
-
-                CH              the Chaos system
-
-TTL             which is the time to live of the RR.  This field is a 32
-                bit integer in units of seconds, an is primarily used by
-                resolvers when they cache RRs.  The TTL describes how
-                long a RR can be cached before it should be discarded.
-
-
-
-
-Mockapetris                                                    [Page 12]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-RDATA           which is the type and sometimes class dependent data
-                which describes the resource:
-
-                A               For the IN class, a 32 bit IP address
-
-                                For the CH class, a domain name followed
-                                by a 16 bit octal Chaos address.
-
-                CNAME           a domain name.
-
-                MX              a 16 bit preference value (lower is
-                                better) followed by a host name willing
-                                to act as a mail exchange for the owner
-                                domain.
-
-                NS              a host name.
-
-                PTR             a domain name.
-
-                SOA             several fields.
-
-The owner name is often implicit, rather than forming an integral part
-of the RR.  For example, many name servers internally form tree or hash
-structures for the name space, and chain RRs off nodes.  The remaining
-RR parts are the fixed header (type, class, TTL) which is consistent for
-all RRs, and a variable part (RDATA) that fits the needs of the resource
-being described.
-
-The meaning of the TTL field is a time limit on how long an RR can be
-kept in a cache.  This limit does not apply to authoritative data in
-zones; it is also timed out, but by the refreshing policies for the
-zone.  The TTL is assigned by the administrator for the zone where the
-data originates.  While short TTLs can be used to minimize caching, and
-a zero TTL prohibits caching, the realities of Internet performance
-suggest that these times should be on the order of days for the typical
-host.  If a change can be anticipated, the TTL can be reduced prior to
-the change to minimize inconsistency during the change, and then
-increased back to its former value following the change.
-
-The data in the RDATA section of RRs is carried as a combination of
-binary strings and domain names.  The domain names are frequently used
-as "pointers" to other data in the DNS.
-
-3.6.1. Textual expression of RRs
-
-RRs are represented in binary form in the packets of the DNS protocol,
-and are usually represented in highly encoded form when stored in a name
-server or resolver.  In this memo, we adopt a style similar to that used
-
-
-
-Mockapetris                                                    [Page 13]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-in master files in order to show the contents of RRs.  In this format,
-most RRs are shown on a single line, although continuation lines are
-possible using parentheses.
-
-The start of the line gives the owner of the RR.  If a line begins with
-a blank, then the owner is assumed to be the same as that of the
-previous RR.  Blank lines are often included for readability.
-
-Following the owner, we list the TTL, type, and class of the RR.  Class
-and type use the mnemonics defined above, and TTL is an integer before
-the type field.  In order to avoid ambiguity in parsing, type and class
-mnemonics are disjoint, TTLs are integers, and the type mnemonic is
-always last. The IN class and TTL values are often omitted from examples
-in the interests of clarity.
-
-The resource data or RDATA section of the RR are given using knowledge
-of the typical representation for the data.
-
-For example, we might show the RRs carried in a message as:
-
-    ISI.EDU.        MX      10 VENERA.ISI.EDU.
-                    MX      10 VAXA.ISI.EDU.
-    VENERA.ISI.EDU. A       128.9.0.32
-                    A       10.1.0.52
-    VAXA.ISI.EDU.   A       10.2.0.27
-                    A       128.9.0.33
-
-The MX RRs have an RDATA section which consists of a 16 bit number
-followed by a domain name.  The address RRs use a standard IP address
-format to contain a 32 bit internet address.
-
-This example shows six RRs, with two RRs at each of three domain names.
-
-Similarly we might see:
-
-    XX.LCS.MIT.EDU. IN      A       10.0.0.44
-                    CH      A       MIT.EDU. 2420
-
-This example shows two addresses for XX.LCS.MIT.EDU, each of a different
-class.
-
-3.6.2. Aliases and canonical names
-
-In existing systems, hosts and other resources often have several names
-that identify the same resource.  For example, the names C.ISI.EDU and
-USC-ISIC.ARPA both identify the same host.  Similarly, in the case of
-mailboxes, many organizations provide many names that actually go to the
-same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU,
-
-
-
-Mockapetris                                                    [Page 14]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-and PVM@ISI.EDU all go to the same mailbox (although the mechanism
-behind this is somewhat complicated).
-
-Most of these systems have a notion that one of the equivalent set of
-names is the canonical or primary name and all others are aliases.
-
-The domain system provides such a feature using the canonical name
-(CNAME) RR.  A CNAME RR identifies its owner name as an alias, and
-specifies the corresponding canonical name in the RDATA section of the
-RR.  If a CNAME RR is present at a node, no other data should be
-present; this ensures that the data for a canonical name and its aliases
-cannot be different.  This rule also insures that a cached CNAME can be
-used without checking with an authoritative server for other RR types.
-
-CNAME RRs cause special action in DNS software.  When a name server
-fails to find a desired RR in the resource set associated with the
-domain name, it checks to see if the resource set consists of a CNAME
-record with a matching class.  If so, the name server includes the CNAME
-record in the response and restarts the query at the domain name
-specified in the data field of the CNAME record.  The one exception to
-this rule is that queries which match the CNAME type are not restarted.
-
-For example, suppose a name server was processing a query with for USC-
-ISIC.ARPA, asking for type A information, and had the following resource
-records:
-
-    USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU
-
-    C.ISI.EDU       IN      A       10.0.0.52
-
-Both of these RRs would be returned in the response to the type A query,
-while a type CNAME or * query should return just the CNAME.
-
-Domain names in RRs which point at another name should always point at
-the primary name and not the alias.  This avoids extra indirections in
-accessing information.  For example, the address to name RR for the
-above host should be:
-
-    52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU
-
-rather than pointing at USC-ISIC.ARPA.  Of course, by the robustness
-principle, domain software should not fail when presented with CNAME
-chains or loops; CNAME chains should be followed and CNAME loops
-signalled as an error.
-
-3.7. Queries
-
-Queries are messages which may be sent to a name server to provoke a
-
-
-
-Mockapetris                                                    [Page 15]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-response.  In the Internet, queries are carried in UDP datagrams or over
-TCP connections.  The response by the name server either answers the
-question posed in the query, refers the requester to another set of name
-servers, or signals some error condition.
-
-In general, the user does not generate queries directly, but instead
-makes a request to a resolver which in turn sends one or more queries to
-name servers and deals with the error conditions and referrals that may
-result.  Of course, the possible questions which can be asked in a query
-does shape the kind of service a resolver can provide.
-
-DNS queries and responses are carried in a standard message format.  The
-message format has a header containing a number of fixed fields which
-are always present, and four sections which carry query parameters and
-RRs.
-
-The most important field in the header is a four bit field called an
-opcode which separates different queries.  Of the possible 16 values,
-one (standard query) is part of the official protocol, two (inverse
-query and status query) are options, one (completion) is obsolete, and
-the rest are unassigned.
-
-The four sections are:
-
-Question        Carries the query name and other query parameters.
-
-Answer          Carries RRs which directly answer the query.
-
-Authority       Carries RRs which describe other authoritative servers.
-                May optionally carry the SOA RR for the authoritative
-                data in the answer section.
-
-Additional      Carries RRs which may be helpful in using the RRs in the
-                other sections.
-
-Note that the content, but not the format, of these sections varies with
-header opcode.
-
-3.7.1. Standard queries
-
-A standard query specifies a target domain name (QNAME), query type
-(QTYPE), and query class (QCLASS) and asks for RRs which match.  This
-type of query makes up such a vast majority of DNS queries that we use
-the term "query" to mean standard query unless otherwise specified.  The
-QTYPE and QCLASS fields are each 16 bits long, and are a superset of
-defined types and classes.
-
-
-
-
-
-Mockapetris                                                    [Page 16]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-The QTYPE field may contain:
-
-<any type>      matches just that type. (e.g., A, PTR).
-
-AXFR            special zone transfer QTYPE.
-
-MAILB           matches all mail box related RRs (e.g. MB and MG).
-
-*               matches all RR types.
-
-The QCLASS field may contain:
-
-<any class>     matches just that class (e.g., IN, CH).
-
-*               matches aLL RR classes.
-
-Using the query domain name, QTYPE, and QCLASS, the name server looks
-for matching RRs.  In addition to relevant records, the name server may
-return RRs that point toward a name server that has the desired
-information or RRs that are expected to be useful in interpreting the
-relevant RRs.  For example, a name server that doesn't have the
-requested information may know a name server that does; a name server
-that returns a domain name in a relevant RR may also return the RR that
-binds that domain name to an address.
-
-For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
-ask the resolver for mail information about ISI.EDU, resulting in a
-query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.  The response's answer
-section would be:
-
-    ISI.EDU.        MX      10 VENERA.ISI.EDU.
-                    MX      10 VAXA.ISI.EDU.
-
-while the additional section might be:
-
-    VAXA.ISI.EDU.   A       10.2.0.27
-                    A       128.9.0.33
-    VENERA.ISI.EDU. A       10.1.0.52
-                    A       128.9.0.32
-
-Because the server assumes that if the requester wants mail exchange
-information, it will probably want the addresses of the mail exchanges
-soon afterward.
-
-Note that the QCLASS=* construct requires special interpretation
-regarding authority.  Since a particular name server may not know all of
-the classes available in the domain system, it can never know if it is
-authoritative for all classes.  Hence responses to QCLASS=* queries can
-
-
-
-Mockapetris                                                    [Page 17]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-never be authoritative.
-
-3.7.2. Inverse queries (Optional)
-
-Name servers may also support inverse queries that map a particular
-resource to a domain name or domain names that have that resource.  For
-example, while a standard query might map a domain name to a SOA RR, the
-corresponding inverse query might map the SOA RR back to the domain
-name.
-
-Implementation of this service is optional in a name server, but all
-name servers must at least be able to understand an inverse query
-message and return a not-implemented error response.
-
-The domain system cannot guarantee the completeness or uniqueness of
-inverse queries because the domain system is organized by domain name
-rather than by host address or any other resource type.  Inverse queries
-are primarily useful for debugging and database maintenance activities.
-
-Inverse queries may not return the proper TTL, and do not indicate cases
-where the identified RR is one of a set (for example, one address for a
-host having multiple addresses).  Therefore, the RRs returned in inverse
-queries should never be cached.
-
-Inverse queries are NOT an acceptable method for mapping host addresses
-to host names; use the IN-ADDR.ARPA domain instead.
-
-A detailed discussion of inverse queries is contained in [RFC-1035].
-
-3.8. Status queries (Experimental)
-
-To be defined.
-
-3.9. Completion queries (Obsolete)
-
-The optional completion services described in RFCs 882 and 883 have been
-deleted.  Redesigned services may become available in the future, or the
-opcodes may be reclaimed for other use.
-
-4. NAME SERVERS
-
-4.1. Introduction
-
-Name servers are the repositories of information that make up the domain
-database.  The database is divided up into sections called zones, which
-are distributed among the name servers.  While name servers can have
-several optional functions and sources of data, the essential task of a
-name server is to answer queries using data in its zones.  By design,
-
-
-
-Mockapetris                                                    [Page 18]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-name servers can answer queries in a simple manner; the response can
-always be generated using only local data, and either contains the
-answer to the question or a referral to other name servers "closer" to
-the desired information.
-
-A given zone will be available from several name servers to insure its
-availability in spite of host or communication link failure.  By
-administrative fiat, we require every zone to be available on at least
-two servers, and many zones have more redundancy than that.
-
-A given name server will typically support one or more zones, but this
-gives it authoritative information about only a small section of the
-domain tree.  It may also have some cached non-authoritative data about
-other parts of the tree.  The name server marks its responses to queries
-so that the requester can tell whether the response comes from
-authoritative data or not.
-
-4.2. How the database is divided into zones
-
-The domain database is partitioned in two ways: by class, and by "cuts"
-made in the name space between nodes.
-
-The class partition is simple.  The database for any class is organized,
-delegated, and maintained separately from all other classes.  Since, by
-convention, the name spaces are the same for all classes, the separate
-classes can be thought of as an array of parallel namespace trees.  Note
-that the data attached to nodes will be different for these different
-parallel classes.  The most common reasons for creating a new class are
-the necessity for a new data format for existing types or a desire for a
-separately managed version of the existing name space.
-
-Within a class, "cuts" in the name space can be made between any two
-adjacent nodes.  After all cuts are made, each group of connected name
-space is a separate zone.  The zone is said to be authoritative for all
-names in the connected region.  Note that the "cuts" in the name space
-may be in different places for different classes, the name servers may
-be different, etc.
-
-These rules mean that every zone has at least one node, and hence domain
-name, for which it is authoritative, and all of the nodes in a
-particular zone are connected.  Given, the tree structure, every zone
-has a highest node which is closer to the root than any other node in
-the zone.  The name of this node is often used to identify the zone.
-
-It would be possible, though not particularly useful, to partition the
-name space so that each domain name was in a separate zone or so that
-all nodes were in a single zone.  Instead, the database is partitioned
-at points where a particular organization wants to take over control of
-
-
-
-Mockapetris                                                    [Page 19]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-a subtree.  Once an organization controls its own zone it can
-unilaterally change the data in the zone, grow new tree sections
-connected to the zone, delete existing nodes, or delegate new subzones
-under its zone.
-
-If the organization has substructure, it may want to make further
-internal partitions to achieve nested delegations of name space control.
-In some cases, such divisions are made purely to make database
-maintenance more convenient.
-
-4.2.1. Technical considerations
-
-The data that describes a zone has four major parts:
-
-   - Authoritative data for all nodes within the zone.
-
-   - Data that defines the top node of the zone (can be thought of
-     as part of the authoritative data).
-
-   - Data that describes delegated subzones, i.e., cuts around the
-     bottom of the zone.
-
-   - Data that allows access to name servers for subzones
-     (sometimes called "glue" data).
-
-All of this data is expressed in the form of RRs, so a zone can be
-completely described in terms of a set of RRs.  Whole zones can be
-transferred between name servers by transferring the RRs, either carried
-in a series of messages or by FTPing a master file which is a textual
-representation.
-
-The authoritative data for a zone is simply all of the RRs attached to
-all of the nodes from the top node of the zone down to leaf nodes or
-nodes above cuts around the bottom edge of the zone.
-
-Though logically part of the authoritative data, the RRs that describe
-the top node of the zone are especially important to the zone's
-management.  These RRs are of two types: name server RRs that list, one
-per RR, all of the servers for the zone, and a single SOA RR that
-describes zone management parameters.
-
-The RRs that describe cuts around the bottom of the zone are NS RRs that
-name the servers for the subzones.  Since the cuts are between nodes,
-these RRs are NOT part of the authoritative data of the zone, and should
-be exactly the same as the corresponding RRs in the top node of the
-subzone.  Since name servers are always associated with zone boundaries,
-NS RRs are only found at nodes which are the top node of some zone.  In
-the data that makes up a zone, NS RRs are found at the top node of the
-
-
-
-Mockapetris                                                    [Page 20]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-zone (and are authoritative) and at cuts around the bottom of the zone
-(where they are not authoritative), but never in between.
-
-One of the goals of the zone structure is that any zone have all the
-data required to set up communications with the name servers for any
-subzones.  That is, parent zones have all the information needed to
-access servers for their children zones.  The NS RRs that name the
-servers for subzones are often not enough for this task since they name
-the servers, but do not give their addresses.  In particular, if the
-name of the name server is itself in the subzone, we could be faced with
-the situation where the NS RRs tell us that in order to learn a name
-server's address, we should contact the server using the address we wish
-to learn.  To fix this problem, a zone contains "glue" RRs which are not
-part of the authoritative data, and are address RRs for the servers.
-These RRs are only necessary if the name server's name is "below" the
-cut, and are only used as part of a referral response.
-
-4.2.2. Administrative considerations
-
-When some organization wants to control its own domain, the first step
-is to identify the proper parent zone, and get the parent zone's owners
-to agree to the delegation of control.  While there are no particular
-technical constraints dealing with where in the tree this can be done,
-there are some administrative groupings discussed in [RFC-1032] which
-deal with top level organization, and middle level zones are free to
-create their own rules.  For example, one university might choose to use
-a single zone, while another might choose to organize by subzones
-dedicated to individual departments or schools.  [RFC-1033] catalogs
-available DNS software an discusses administration procedures.
-
-Once the proper name for the new subzone is selected, the new owners
-should be required to demonstrate redundant name server support.  Note
-that there is no requirement that the servers for a zone reside in a
-host which has a name in that domain.  In many cases, a zone will be
-more accessible to the internet at large if its servers are widely
-distributed rather than being within the physical facilities controlled
-by the same organization that manages the zone.  For example, in the
-current DNS, one of the name servers for the United Kingdom, or UK
-domain, is found in the US.  This allows US hosts to get UK data without
-using limited transatlantic bandwidth.
-
-As the last installation step, the delegation NS RRs and glue RRs
-necessary to make the delegation effective should be added to the parent
-zone.  The administrators of both zones should insure that the NS and
-glue RRs which mark both sides of the cut are consistent and remain so.
-
-4.3. Name server internals
-
-
-
-
-Mockapetris                                                    [Page 21]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-4.3.1. Queries and responses
-
-The principal activity of name servers is to answer standard queries.
-Both the query and its response are carried in a standard message format
-which is described in [RFC-1035].  The query contains a QTYPE, QCLASS,
-and QNAME, which describe the types and classes of desired information
-and the name of interest.
-
-The way that the name server answers the query depends upon whether it
-is operating in recursive mode or not:
-
-   - The simplest mode for the server is non-recursive, since it
-     can answer queries using only local information: the response
-     contains an error, the answer, or a referral to some other
-     server "closer" to the answer.  All name servers must
-     implement non-recursive queries.
-
-   - The simplest mode for the client is recursive, since in this
-     mode the name server acts in the role of a resolver and
-     returns either an error or the answer, but never referrals.
-     This service is optional in a name server, and the name server
-     may also choose to restrict the clients which can use
-     recursive mode.
-
-Recursive service is helpful in several situations:
-
-   - a relatively simple requester that lacks the ability to use
-     anything other than a direct answer to the question.
-
-   - a request that needs to cross protocol or other boundaries and
-     can be sent to a server which can act as intermediary.
-
-   - a network where we want to concentrate the cache rather than
-     having a separate cache for each client.
-
-Non-recursive service is appropriate if the requester is capable of
-pursuing referrals and interested in information which will aid future
-requests.
-
-The use of recursive mode is limited to cases where both the client and
-the name server agree to its use.  The agreement is negotiated through
-the use of two bits in query and response messages:
-
-   - The recursion available, or RA bit, is set or cleared by a
-     name server in all responses.  The bit is true if the name
-     server is willing to provide recursive service for the client,
-     regardless of whether the client requested recursive service.
-     That is, RA signals availability rather than use.
-
-
-
-Mockapetris                                                    [Page 22]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-   - Queries contain a bit called recursion desired or RD.  This
-     bit specifies specifies whether the requester wants recursive
-     service for this query.  Clients may request recursive service
-     from any name server, though they should depend upon receiving
-     it only from servers which have previously sent an RA, or
-     servers which have agreed to provide service through private
-     agreement or some other means outside of the DNS protocol.
-
-The recursive mode occurs when a query with RD set arrives at a server
-which is willing to provide recursive service; the client can verify
-that recursive mode was used by checking that both RA and RD are set in
-the reply.  Note that the name server should never perform recursive
-service unless asked via RD, since this interferes with trouble shooting
-of name servers and their databases.
-
-If recursive service is requested and available, the recursive response
-to a query will be one of the following:
-
-   - The answer to the query, possibly preface by one or more CNAME
-     RRs that specify aliases encountered on the way to an answer.
-
-   - A name error indicating that the name does not exist.  This
-     may include CNAME RRs that indicate that the original query
-     name was an alias for a name which does not exist.
-
-   - A temporary error indication.
-
-If recursive service is not requested or is not available, the non-
-recursive response will be one of the following:
-
-   - An authoritative name error indicating that the name does not
-     exist.
-
-   - A temporary error indication.
-
-   - Some combination of:
-
-     RRs that answer the question, together with an indication
-     whether the data comes from a zone or is cached.
-
-     A referral to name servers which have zones which are closer
-     ancestors to the name than the server sending the reply.
-
-   - RRs that the name server thinks will prove useful to the
-     requester.
-
-
-
-
-
-
-Mockapetris                                                    [Page 23]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-4.3.2. Algorithm
-
-The actual algorithm used by the name server will depend on the local OS
-and data structures used to store RRs.  The following algorithm assumes
-that the RRs are organized in several tree structures, one for each
-zone, and another for the cache:
-
-   1. Set or clear the value of recursion available in the response
-      depending on whether the name server is willing to provide
-      recursive service.  If recursive service is available and
-      requested via the RD bit in the query, go to step 5,
-      otherwise step 2.
-
-   2. Search the available zones for the zone which is the nearest
-      ancestor to QNAME.  If such a zone is found, go to step 3,
-      otherwise step 4.
-
-   3. Start matching down, label by label, in the zone.  The
-      matching process can terminate several ways:
-
-         a. If the whole of QNAME is matched, we have found the
-            node.
-
-            If the data at the node is a CNAME, and QTYPE doesn't
-            match CNAME, copy the CNAME RR into the answer section
-            of the response, change QNAME to the canonical name in
-            the CNAME RR, and go back to step 1.
-
-            Otherwise, copy all RRs which match QTYPE into the
-            answer section and go to step 6.
-
-         b. If a match would take us out of the authoritative data,
-            we have a referral.  This happens when we encounter a
-            node with NS RRs marking cuts along the bottom of a
-            zone.
-
-            Copy the NS RRs for the subzone into the authority
-            section of the reply.  Put whatever addresses are
-            available into the additional section, using glue RRs
-            if the addresses are not available from authoritative
-            data or the cache.  Go to step 4.
-
-         c. If at some label, a match is impossible (i.e., the
-            corresponding label does not exist), look to see if a
-            the "*" label exists.
-
-            If the "*" label does not exist, check whether the name
-            we are looking for is the original QNAME in the query
-
-
-
-Mockapetris                                                    [Page 24]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-            or a name we have followed due to a CNAME.  If the name
-            is original, set an authoritative name error in the
-            response and exit.  Otherwise just exit.
-
-            If the "*" label does exist, match RRs at that node
-            against QTYPE.  If any match, copy them into the answer
-            section, but set the owner of the RR to be QNAME, and
-            not the node with the "*" label.  Go to step 6.
-
-   4. Start matching down in the cache.  If QNAME is found in the
-      cache, copy all RRs attached to it that match QTYPE into the
-      answer section.  If there was no delegation from
-      authoritative data, look for the best one from the cache, and
-      put it in the authority section.  Go to step 6.
-
-   5. Using the local resolver or a copy of its algorithm (see
-      resolver section of this memo) to answer the query.  Store
-      the results, including any intermediate CNAMEs, in the answer
-      section of the response.
-
-   6. Using local data only, attempt to add other RRs which may be
-      useful to the additional section of the query.  Exit.
-
-4.3.3. Wildcards
-
-In the previous algorithm, special treatment was given to RRs with owner
-names starting with the label "*".  Such RRs are called wildcards.
-Wildcard RRs can be thought of as instructions for synthesizing RRs.
-When the appropriate conditions are met, the name server creates RRs
-with an owner name equal to the query name and contents taken from the
-wildcard RRs.
-
-This facility is most often used to create a zone which will be used to
-forward mail from the Internet to some other mail system.  The general
-idea is that any name in that zone which is presented to server in a
-query will be assumed to exist, with certain properties, unless explicit
-evidence exists to the contrary.  Note that the use of the term zone
-here, instead of domain, is intentional; such defaults do not propagate
-across zone boundaries, although a subzone may choose to achieve that
-appearance by setting up similar defaults.
-
-The contents of the wildcard RRs follows the usual rules and formats for
-RRs.  The wildcards in the zone have an owner name that controls the
-query names they will match.  The owner name of the wildcard RRs is of
-the form "*.<anydomain>", where <anydomain> is any domain name.
-<anydomain> should not contain other * labels, and should be in the
-authoritative data of the zone.  The wildcards potentially apply to
-descendants of <anydomain>, but not to <anydomain> itself.  Another way
-
-
-
-Mockapetris                                                    [Page 25]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-to look at this is that the "*" label always matches at least one whole
-label and sometimes more, but always whole labels.
-
-Wildcard RRs do not apply:
-
-   - When the query is in another zone.  That is, delegation cancels
-     the wildcard defaults.
-
-   - When the query name or a name between the wildcard domain and
-     the query name is know to exist.  For example, if a wildcard
-     RR has an owner name of "*.X", and the zone also contains RRs
-     attached to B.X, the wildcards would apply to queries for name
-     Z.X (presuming there is no explicit information for Z.X), but
-     not to B.X, A.B.X, or X.
-
-A * label appearing in a query name has no special effect, but can be
-used to test for wildcards in an authoritative zone; such a query is the
-only way to get a response containing RRs with an owner name with * in
-it.  The result of such a query should not be cached.
-
-Note that the contents of the wildcard RRs are not modified when used to
-synthesize RRs.
-
-To illustrate the use of wildcard RRs, suppose a large company with a
-large, non-IP/TCP, network wanted to create a mail gateway.  If the
-company was called X.COM, and IP/TCP capable gateway machine was called
-A.X.COM, the following RRs might be entered into the COM zone:
-
-    X.COM           MX      10      A.X.COM
-
-    *.X.COM         MX      10      A.X.COM
-
-    A.X.COM         A       1.2.3.4
-    A.X.COM         MX      10      A.X.COM
-
-    *.A.X.COM       MX      10      A.X.COM
-
-This would cause any MX query for any domain name ending in X.COM to
-return an MX RR pointing at A.X.COM.  Two wildcard RRs are required
-since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM
-subtree by the explicit data for A.X.COM.  Note also that the explicit
-MX data at X.COM and A.X.COM is required, and that none of the RRs above
-would match a query name of XX.COM.
-
-4.3.4. Negative response caching (Optional)
-
-The DNS provides an optional service which allows name servers to
-distribute, and resolvers to cache, negative results with TTLs.  For
-
-
-
-Mockapetris                                                    [Page 26]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-example, a name server can distribute a TTL along with a name error
-indication, and a resolver receiving such information is allowed to
-assume that the name does not exist during the TTL period without
-consulting authoritative data.  Similarly, a resolver can make a query
-with a QTYPE which matches multiple types, and cache the fact that some
-of the types are not present.
-
-This feature can be particularly important in a system which implements
-naming shorthands that use search lists beacuse a popular shorthand,
-which happens to require a suffix toward the end of the search list,
-will generate multiple name errors whenever it is used.
-
-The method is that a name server may add an SOA RR to the additional
-section of a response when that response is authoritative.  The SOA must
-be that of the zone which was the source of the authoritative data in
-the answer section, or name error if applicable.  The MINIMUM field of
-the SOA controls the length of time that the negative result may be
-cached.
-
-Note that in some circumstances, the answer section may contain multiple
-owner names.  In this case, the SOA mechanism should only be used for
-the data which matches QNAME, which is the only authoritative data in
-this section.
-
-Name servers and resolvers should never attempt to add SOAs to the
-additional section of a non-authoritative response, or attempt to infer
-results which are not directly stated in an authoritative response.
-There are several reasons for this, including: cached information isn't
-usually enough to match up RRs and their zone names, SOA RRs may be
-cached due to direct SOA queries, and name servers are not required to
-output the SOAs in the authority section.
-
-This feature is optional, although a refined version is expected to
-become part of the standard protocol in the future.  Name servers are
-not required to add the SOA RRs in all authoritative responses, nor are
-resolvers required to cache negative results.  Both are recommended.
-All resolvers and recursive name servers are required to at least be
-able to ignore the SOA RR when it is present in a response.
-
-Some experiments have also been proposed which will use this feature.
-The idea is that if cached data is known to come from a particular zone,
-and if an authoritative copy of the zone's SOA is obtained, and if the
-zone's SERIAL has not changed since the data was cached, then the TTL of
-the cached data can be reset to the zone MINIMUM value if it is smaller.
-This usage is mentioned for planning purposes only, and is not
-recommended as yet.
-
-
-
-
-
-Mockapetris                                                    [Page 27]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-4.3.5. Zone maintenance and transfers
-
-Part of the job of a zone administrator is to maintain the zones at all
-of the name servers which are authoritative for the zone.  When the
-inevitable changes are made, they must be distributed to all of the name
-servers.  While this distribution can be accomplished using FTP or some
-other ad hoc procedure, the preferred method is the zone transfer part
-of the DNS protocol.
-
-The general model of automatic zone transfer or refreshing is that one
-of the name servers is the master or primary for the zone.  Changes are
-coordinated at the primary, typically by editing a master file for the
-zone.  After editing, the administrator signals the master server to
-load the new zone.  The other non-master or secondary servers for the
-zone periodically check for changes (at a selectable interval) and
-obtain new zone copies when changes have been made.
-
-To detect changes, secondaries just check the SERIAL field of the SOA
-for the zone.  In addition to whatever other changes are made, the
-SERIAL field in the SOA of the zone is always advanced whenever any
-change is made to the zone.  The advancing can be a simple increment, or
-could be based on the write date and time of the master file, etc.  The
-purpose is to make it possible to determine which of two copies of a
-zone is more recent by comparing serial numbers.  Serial number advances
-and comparisons use sequence space arithmetic, so there is a theoretic
-limit on how fast a zone can be updated, basically that old copies must
-die out before the serial number covers half of its 32 bit range.  In
-practice, the only concern is that the compare operation deals properly
-with comparisons around the boundary between the most positive and most
-negative 32 bit numbers.
-
-The periodic polling of the secondary servers is controlled by
-parameters in the SOA RR for the zone, which set the minimum acceptable
-polling intervals.  The parameters are called REFRESH, RETRY, and
-EXPIRE.  Whenever a new zone is loaded in a secondary, the secondary
-waits REFRESH seconds before checking with the primary for a new serial.
-If this check cannot be completed, new checks are started every RETRY
-seconds.  The check is a simple query to the primary for the SOA RR of
-the zone.  If the serial field in the secondary's zone copy is equal to
-the serial returned by the primary, then no changes have occurred, and
-the REFRESH interval wait is restarted.  If the secondary finds it
-impossible to perform a serial check for the EXPIRE interval, it must
-assume that its copy of the zone is obsolete an discard it.
-
-When the poll shows that the zone has changed, then the secondary server
-must request a zone transfer via an AXFR request for the zone.  The AXFR
-may cause an error, such as refused, but normally is answered by a
-sequence of response messages.  The first and last messages must contain
-
-
-
-Mockapetris                                                    [Page 28]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-the data for the top authoritative node of the zone.  Intermediate
-messages carry all of the other RRs from the zone, including both
-authoritative and non-authoritative RRs.  The stream of messages allows
-the secondary to construct a copy of the zone.  Because accuracy is
-essential, TCP or some other reliable protocol must be used for AXFR
-requests.
-
-Each secondary server is required to perform the following operations
-against the master, but may also optionally perform these operations
-against other secondary servers.  This strategy can improve the transfer
-process when the primary is unavailable due to host downtime or network
-problems, or when a secondary server has better network access to an
-"intermediate" secondary than to the primary.
-
-5. RESOLVERS
-
-5.1. Introduction
-
-Resolvers are programs that interface user programs to domain name
-servers.  In the simplest case, a resolver receives a request from a
-user program (e.g., mail programs, TELNET, FTP) in the form of a
-subroutine call, system call etc., and returns the desired information
-in a form compatible with the local host's data formats.
-
-The resolver is located on the same machine as the program that requests
-the resolver's services, but it may need to consult name servers on
-other hosts.  Because a resolver may need to consult several name
-servers, or may have the requested information in a local cache, the
-amount of time that a resolver will take to complete can vary quite a
-bit, from milliseconds to several seconds.
-
-A very important goal of the resolver is to eliminate network delay and
-name server load from most requests by answering them from its cache of
-prior results.  It follows that caches which are shared by multiple
-processes, users, machines, etc., are more efficient than non-shared
-caches.
-
-5.2. Client-resolver interface
-
-5.2.1. Typical functions
-
-The client interface to the resolver is influenced by the local host's
-conventions, but the typical resolver-client interface has three
-functions:
-
-   1. Host name to host address translation.
-
-      This function is often defined to mimic a previous HOSTS.TXT
-
-
-
-Mockapetris                                                    [Page 29]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-      based function.  Given a character string, the caller wants
-      one or more 32 bit IP addresses.  Under the DNS, it
-      translates into a request for type A RRs.  Since the DNS does
-      not preserve the order of RRs, this function may choose to
-      sort the returned addresses or select the "best" address if
-      the service returns only one choice to the client.  Note that
-      a multiple address return is recommended, but a single
-      address may be the only way to emulate prior HOSTS.TXT
-      services.
-
-   2. Host address to host name translation
-
-      This function will often follow the form of previous
-      functions.  Given a 32 bit IP address, the caller wants a
-      character string.  The octets of the IP address are reversed,
-      used as name components, and suffixed with "IN-ADDR.ARPA".  A
-      type PTR query is used to get the RR with the primary name of
-      the host.  For example, a request for the host name
-      corresponding to IP address 1.2.3.4 looks for PTR RRs for
-      domain name "4.3.2.1.IN-ADDR.ARPA".
-
-   3. General lookup function
-
-      This function retrieves arbitrary information from the DNS,
-      and has no counterpart in previous systems.  The caller
-      supplies a QNAME, QTYPE, and QCLASS, and wants all of the
-      matching RRs.  This function will often use the DNS format
-      for all RR data instead of the local host's, and returns all
-      RR content (e.g., TTL) instead of a processed form with local
-      quoting conventions.
-
-When the resolver performs the indicated function, it usually has one of
-the following results to pass back to the client:
-
-   - One or more RRs giving the requested data.
-
-     In this case the resolver returns the answer in the
-     appropriate format.
-
-   - A name error (NE).
-
-     This happens when the referenced name does not exist.  For
-     example, a user may have mistyped a host name.
-
-   - A data not found error.
-
-     This happens when the referenced name exists, but data of the
-     appropriate type does not.  For example, a host address
-
-
-
-Mockapetris                                                    [Page 30]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     function applied to a mailbox name would return this error
-     since the name exists, but no address RR is present.
-
-It is important to note that the functions for translating between host
-names and addresses may combine the "name error" and "data not found"
-error conditions into a single type of error return, but the general
-function should not.  One reason for this is that applications may ask
-first for one type of information about a name followed by a second
-request to the same name for some other type of information; if the two
-errors are combined, then useless queries may slow the application.
-
-5.2.2. Aliases
-
-While attempting to resolve a particular request, the resolver may find
-that the name in question is an alias.  For example, the resolver might
-find that the name given for host name to address translation is an
-alias when it finds the CNAME RR.  If possible, the alias condition
-should be signalled back from the resolver to the client.
-
-In most cases a resolver simply restarts the query at the new name when
-it encounters a CNAME.  However, when performing the general function,
-the resolver should not pursue aliases when the CNAME RR matches the
-query type.  This allows queries which ask whether an alias is present.
-For example, if the query type is CNAME, the user is interested in the
-CNAME RR itself, and not the RRs at the name it points to.
-
-Several special conditions can occur with aliases.  Multiple levels of
-aliases should be avoided due to their lack of efficiency, but should
-not be signalled as an error.  Alias loops and aliases which point to
-non-existent names should be caught and an error condition passed back
-to the client.
-
-5.2.3. Temporary failures
-
-In a less than perfect world, all resolvers will occasionally be unable
-to resolve a particular request.  This condition can be caused by a
-resolver which becomes separated from the rest of the network due to a
-link failure or gateway problem, or less often by coincident failure or
-unavailability of all servers for a particular domain.
-
-It is essential that this sort of condition should not be signalled as a
-name or data not present error to applications.  This sort of behavior
-is annoying to humans, and can wreak havoc when mail systems use the
-DNS.
-
-While in some cases it is possible to deal with such a temporary problem
-by blocking the request indefinitely, this is usually not a good choice,
-particularly when the client is a server process that could move on to
-
-
-
-Mockapetris                                                    [Page 31]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-other tasks.  The recommended solution is to always have temporary
-failure as one of the possible results of a resolver function, even
-though this may make emulation of existing HOSTS.TXT functions more
-difficult.
-
-5.3. Resolver internals
-
-Every resolver implementation uses slightly different algorithms, and
-typically spends much more logic dealing with errors of various sorts
-than typical occurances.  This section outlines a recommended basic
-strategy for resolver operation, but leaves details to [RFC-1035].
-
-5.3.1. Stub resolvers
-
-One option for implementing a resolver is to move the resolution
-function out of the local machine and into a name server which supports
-recursive queries.  This can provide an easy method of providing domain
-service in a PC which lacks the resources to perform the resolver
-function, or can centralize the cache for a whole local network or
-organization.
-
-All that the remaining stub needs is a list of name server addresses
-that will perform the recursive requests.  This type of resolver
-presumably needs the information in a configuration file, since it
-probably lacks the sophistication to locate it in the domain database.
-The user also needs to verify that the listed servers will perform the
-recursive service; a name server is free to refuse to perform recursive
-services for any or all clients.  The user should consult the local
-system administrator to find name servers willing to perform the
-service.
-
-This type of service suffers from some drawbacks.  Since the recursive
-requests may take an arbitrary amount of time to perform, the stub may
-have difficulty optimizing retransmission intervals to deal with both
-lost UDP packets and dead servers; the name server can be easily
-overloaded by too zealous a stub if it interprets retransmissions as new
-requests.  Use of TCP may be an answer, but TCP may well place burdens
-on the host's capabilities which are similar to those of a real
-resolver.
-
-5.3.2. Resources
-
-In addition to its own resources, the resolver may also have shared
-access to zones maintained by a local name server.  This gives the
-resolver the advantage of more rapid access, but the resolver must be
-careful to never let cached information override zone data.  In this
-discussion the term "local information" is meant to mean the union of
-the cache and such shared zones, with the understanding that
-
-
-
-Mockapetris                                                    [Page 32]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-authoritative data is always used in preference to cached data when both
-are present.
-
-The following resolver algorithm assumes that all functions have been
-converted to a general lookup function, and uses the following data
-structures to represent the state of a request in progress in the
-resolver:
-
-SNAME           the domain name we are searching for.
-
-STYPE           the QTYPE of the search request.
-
-SCLASS          the QCLASS of the search request.
-
-SLIST           a structure which describes the name servers and the
-                zone which the resolver is currently trying to query.
-                This structure keeps track of the resolver's current
-                best guess about which name servers hold the desired
-                information; it is updated when arriving information
-                changes the guess.  This structure includes the
-                equivalent of a zone name, the known name servers for
-                the zone, the known addresses for the name servers, and
-                history information which can be used to suggest which
-                server is likely to be the best one to try next.  The
-                zone name equivalent is a match count of the number of
-                labels from the root down which SNAME has in common with
-                the zone being queried; this is used as a measure of how
-                "close" the resolver is to SNAME.
-
-SBELT           a "safety belt" structure of the same form as SLIST,
-                which is initialized from a configuration file, and
-                lists servers which should be used when the resolver
-                doesn't have any local information to guide name server
-                selection.  The match count will be -1 to indicate that
-                no labels are known to match.
-
-CACHE           A structure which stores the results from previous
-                responses.  Since resolvers are responsible for
-                discarding old RRs whose TTL has expired, most
-                implementations convert the interval specified in
-                arriving RRs to some sort of absolute time when the RR
-                is stored in the cache.  Instead of counting the TTLs
-                down individually, the resolver just ignores or discards
-                old RRs when it runs across them in the course of a
-                search, or discards them during periodic sweeps to
-                reclaim the memory consumed by old RRs.
-
-
-
-
-
-Mockapetris                                                    [Page 33]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-5.3.3. Algorithm
-
-The top level algorithm has four steps:
-
-   1. See if the answer is in local information, and if so return
-      it to the client.
-
-   2. Find the best servers to ask.
-
-   3. Send them queries until one returns a response.
-
-   4. Analyze the response, either:
-
-         a. if the response answers the question or contains a name
-            error, cache the data as well as returning it back to
-            the client.
-
-         b. if the response contains a better delegation to other
-            servers, cache the delegation information, and go to
-            step 2.
-
-         c. if the response shows a CNAME and that is not the
-            answer itself, cache the CNAME, change the SNAME to the
-            canonical name in the CNAME RR and go to step 1.
-
-         d. if the response shows a servers failure or other
-            bizarre contents, delete the server from the SLIST and
-            go back to step 3.
-
-Step 1 searches the cache for the desired data. If the data is in the
-cache, it is assumed to be good enough for normal use.  Some resolvers
-have an option at the user interface which will force the resolver to
-ignore the cached data and consult with an authoritative server.  This
-is not recommended as the default.  If the resolver has direct access to
-a name server's zones, it should check to see if the desired data is
-present in authoritative form, and if so, use the authoritative data in
-preference to cached data.
-
-Step 2 looks for a name server to ask for the required data.  The
-general strategy is to look for locally-available name server RRs,
-starting at SNAME, then the parent domain name of SNAME, the
-grandparent, and so on toward the root.  Thus if SNAME were
-Mockapetris.ISI.EDU, this step would look for NS RRs for
-Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
-These NS RRs list the names of hosts for a zone at or above SNAME.  Copy
-the names into SLIST.  Set up their addresses using local data.  It may
-be the case that the addresses are not available.  The resolver has many
-choices here; the best is to start parallel resolver processes looking
-
-
-
-Mockapetris                                                    [Page 34]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-for the addresses while continuing onward with the addresses which are
-available.  Obviously, the design choices and options are complicated
-and a function of the local host's capabilities.  The recommended
-priorities for the resolver designer are:
-
-   1. Bound the amount of work (packets sent, parallel processes
-      started) so that a request can't get into an infinite loop or
-      start off a chain reaction of requests or queries with other
-      implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
-      SOME DATA.
-
-   2. Get back an answer if at all possible.
-
-   3. Avoid unnecessary transmissions.
-
-   4. Get the answer as quickly as possible.
-
-If the search for NS RRs fails, then the resolver initializes SLIST from
-the safety belt SBELT.  The basic idea is that when the resolver has no
-idea what servers to ask, it should use information from a configuration
-file that lists several servers which are expected to be helpful.
-Although there are special situations, the usual choice is two of the
-root servers and two of the servers for the host's domain.  The reason
-for two of each is for redundancy.  The root servers will provide
-eventual access to all of the domain space.  The two local servers will
-allow the resolver to continue to resolve local names if the local
-network becomes isolated from the internet due to gateway or link
-failure.
-
-In addition to the names and addresses of the servers, the SLIST data
-structure can be sorted to use the best servers first, and to insure
-that all addresses of all servers are used in a round-robin manner.  The
-sorting can be a simple function of preferring addresses on the local
-network over others, or may involve statistics from past events, such as
-previous response times and batting averages.
-
-Step 3 sends out queries until a response is received.  The strategy is
-to cycle around all of the addresses for all of the servers with a
-timeout between each transmission.  In practice it is important to use
-all addresses of a multihomed host, and too aggressive a retransmission
-policy actually slows response when used by multiple resolvers
-contending for the same name server and even occasionally for a single
-resolver.  SLIST typically contains data values to control the timeouts
-and keep track of previous transmissions.
-
-Step 4 involves analyzing responses.  The resolver should be highly
-paranoid in its parsing of responses.  It should also check that the
-response matches the query it sent using the ID field in the response.
-
-
-
-Mockapetris                                                    [Page 35]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-The ideal answer is one from a server authoritative for the query which
-either gives the required data or a name error.  The data is passed back
-to the user and entered in the cache for future use if its TTL is
-greater than zero.
-
-If the response shows a delegation, the resolver should check to see
-that the delegation is "closer" to the answer than the servers in SLIST
-are.  This can be done by comparing the match count in SLIST with that
-computed from SNAME and the NS RRs in the delegation.  If not, the reply
-is bogus and should be ignored.  If the delegation is valid the NS
-delegation RRs and any address RRs for the servers should be cached.
-The name servers are entered in the SLIST, and the search is restarted.
-
-If the response contains a CNAME, the search is restarted at the CNAME
-unless the response has the data for the canonical name or if the CNAME
-is the answer itself.
-
-Details and implementation hints can be found in [RFC-1035].
-
-6. A SCENARIO
-
-In our sample domain space, suppose we wanted separate administrative
-control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones.  We might
-allocate name servers as follows:
-
-
-                                   |(C.ISI.EDU,SRI-NIC.ARPA
-                                   | A.ISI.EDU)
-             +---------------------+------------------+
-             |                     |                  |
-            MIL                   EDU                ARPA
-             |(SRI-NIC.ARPA,       |(SRI-NIC.ARPA,    |
-             | A.ISI.EDU           | C.ISI.EDU)       |
-       +-----+-----+               |     +------+-----+-----+
-       |     |     |               |     |      |           |
-      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
-                                   |
-       +--------+------------------+---------------+--------+
-       |        |                  |               |        |
-      UCI      MIT                 |              UDEL     YALE
-                |(XX.LCS.MIT.EDU, ISI
-                |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
-            +---+---+              | A.ISI.EDU)
-            |       |              |
-           LCS   ACHILLES +--+-----+-----+--------+
-            |             |  |     |     |        |
-            XX            A  C   VAXA  VENERA Mockapetris
-
-
-
-
-Mockapetris                                                    [Page 36]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-In this example, the authoritative name server is shown in parentheses
-at the point in the domain tree at which is assumes control.
-
-Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and
-A.ISI.EDU.  The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU.  The
-EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU.  Note that servers
-may have zones which are contiguous or disjoint.  In this scenario,
-C.ISI.EDU has contiguous zones at the root and EDU domains.  A.ISI.EDU
-has contiguous zones at the root and MIL domains, but also has a non-
-contiguous zone at ISI.EDU.
-
-6.1. C.ISI.EDU name server
-
-C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN
-class, and would have zones for these domains.  The zone data for the
-root domain might be:
-
-    .       IN      SOA     SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
-                            870611          ;serial
-                            1800            ;refresh every 30 min
-                            300             ;retry every 5 min
-                            604800          ;expire after a week
-                            86400)          ;minimum of a day
-                    NS      A.ISI.EDU.
-                    NS      C.ISI.EDU.
-                    NS      SRI-NIC.ARPA.
-
-    MIL.    86400   NS      SRI-NIC.ARPA.
-            86400   NS      A.ISI.EDU.
-
-    EDU.    86400   NS      SRI-NIC.ARPA.
-            86400   NS      C.ISI.EDU.
-
-    SRI-NIC.ARPA.   A       26.0.0.73
-                    A       10.0.0.51
-                    MX      0 SRI-NIC.ARPA.
-                    HINFO   DEC-2060 TOPS20
-
-    ACC.ARPA.       A       26.6.0.65
-                    HINFO   PDP-11/70 UNIX
-                    MX      10 ACC.ARPA.
-
-    USC-ISIC.ARPA.  CNAME   C.ISI.EDU.
-
-    73.0.0.26.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
-    65.0.6.26.IN-ADDR.ARPA.  PTR    ACC.ARPA.
-    51.0.0.10.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
-    52.0.0.10.IN-ADDR.ARPA.  PTR    C.ISI.EDU.
-
-
-
-Mockapetris                                                    [Page 37]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-    103.0.3.26.IN-ADDR.ARPA. PTR    A.ISI.EDU.
-
-    A.ISI.EDU. 86400 A      26.3.0.103
-    C.ISI.EDU. 86400 A      10.0.0.52
-
-This data is represented as it would be in a master file.  Most RRs are
-single line entries; the sole exception here is the SOA RR, which uses
-"(" to start a multi-line RR and ")" to show the end of a multi-line RR.
-Since the class of all RRs in a zone must be the same, only the first RR
-in a zone need specify the class.  When a name server loads a zone, it
-forces the TTL of all authoritative RRs to be at least the MINIMUM field
-of the SOA, here 86400 seconds, or one day.  The NS RRs marking
-delegation of the MIL and EDU domains, together with the glue RRs for
-the servers host addresses, are not part of the authoritative data in
-the zone, and hence have explicit TTLs.
-
-Four RRs are attached to the root node: the SOA which describes the root
-zone and the 3 NS RRs which list the name servers for the root.  The
-data in the SOA RR describes the management of the zone.  The zone data
-is maintained on host SRI-NIC.ARPA, and the responsible party for the
-zone is HOSTMASTER@SRI-NIC.ARPA.  A key item in the SOA is the 86400
-second minimum TTL, which means that all authoritative data in the zone
-has at least that TTL, although higher values may be explicitly
-specified.
-
-The NS RRs for the MIL and EDU domains mark the boundary between the
-root zone and the MIL and EDU zones.  Note that in this example, the
-lower zones happen to be supported by name servers which also support
-the root zone.
-
-The master file for the EDU zone might be stated relative to the origin
-EDU.  The zone data for the EDU domain might be:
-
-    EDU.  IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
-                            870729 ;serial
-                            1800 ;refresh every 30 minutes
-                            300 ;retry every 5 minutes
-                            604800 ;expire after a week
-                            86400 ;minimum of a day
-                            )
-                    NS SRI-NIC.ARPA.
-                    NS C.ISI.EDU.
-
-    UCI 172800 NS ICS.UCI
-                    172800 NS ROME.UCI
-    ICS.UCI 172800 A 192.5.19.1
-    ROME.UCI 172800 A 192.5.19.31
-
-
-
-
-Mockapetris                                                    [Page 38]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-    ISI 172800 NS VAXA.ISI
-                    172800 NS A.ISI
-                    172800 NS VENERA.ISI.EDU.
-    VAXA.ISI 172800 A 10.2.0.27
-                    172800 A 128.9.0.33
-    VENERA.ISI.EDU. 172800 A 10.1.0.52
-                    172800 A 128.9.0.32
-    A.ISI 172800 A 26.3.0.103
-
-    UDEL.EDU.  172800 NS LOUIE.UDEL.EDU.
-                    172800 NS UMN-REI-UC.ARPA.
-    LOUIE.UDEL.EDU. 172800 A 10.0.0.96
-                    172800 A 192.5.39.3
-
-    YALE.EDU.  172800 NS YALE.ARPA.
-    YALE.EDU.  172800 NS YALE-BULLDOG.ARPA.
-
-    MIT.EDU.  43200 NS XX.LCS.MIT.EDU.
-                      43200 NS ACHILLES.MIT.EDU.
-    XX.LCS.MIT.EDU.  43200 A 10.0.0.44
-    ACHILLES.MIT.EDU. 43200 A 18.72.0.8
-
-Note the use of relative names here.  The owner name for the ISI.EDU. is
-stated using a relative name, as are two of the name server RR contents.
-Relative and absolute domain names may be freely intermixed in a master
-
-6.2. Example standard queries
-
-The following queries and responses illustrate name server behavior.
-Unless otherwise noted, the queries do not have recursion desired (RD)
-in the header.  Note that the answers to non-recursive queries do depend
-on the server being asked, but do not depend on the identity of the
-requester.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 39]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
-
-The query would look like:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY                                     |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-The response from C.ISI.EDU would be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 86400 IN A 26.0.0.73                |
-               |               86400 IN A 10.0.0.51                |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-The header of the response looks like the header of the query, except
-that the RESPONSE bit is set, indicating that this message is a
-response, not a query, and the Authoritative Answer (AA) bit is set
-indicating that the address RRs in the answer section are from
-authoritative data.  The question section of the response matches the
-question section of the query.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 40]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-If the same query was sent to some other server which was not
-authoritative for SRI-NIC.ARPA, the response might be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY,RESPONSE                            |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 1777 IN A 10.0.0.51                 |
-               |               1777 IN A 26.0.0.73                 |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-This response is different from the previous one in two ways: the header
-does not have AA set, and the TTLs are different.  The inference is that
-the data did not come from a zone, but from a cache.  The difference
-between the authoritative TTL and the TTL here is due to aging of the
-data in a cache.  The difference in ordering of the RRs in the answer
-section is not significant.
-
-6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
-
-A query similar to the previous one, but using a QTYPE of *, would
-receive the following response from C.ISI.EDU:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 86400 IN  A     26.0.0.73           |
-               |                         A     10.0.0.51           |
-               |                         MX    0 SRI-NIC.ARPA.     |
-               |                         HINFO DEC-2060 TOPS20     |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 41]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-If a similar query was directed to two name servers which are not
-authoritative for SRI-NIC.ARPA, the responses might be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE                           |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 12345 IN     A       26.0.0.73      |
-               |                            A       10.0.0.51      |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-and
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE                           |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 1290 IN HINFO  DEC-2060 TOPS20      |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-Neither of these answers have AA set, so neither response comes from
-authoritative data.  The different contents and different TTLs suggest
-that the two servers cached data at different times, and that the first
-server cached the response to a QTYPE=A query and the second cached the
-response to a HINFO query.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 42]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
-
-This type of query might be result from a mailer trying to look up
-routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA.
-The response from C.ISI.EDU would be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX          |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 86400 IN     MX      0 SRI-NIC.ARPA.|
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | SRI-NIC.ARPA. 86400 IN     A       26.0.0.73      |
-               |                            A       10.0.0.51      |
-               +---------------------------------------------------+
-
-This response contains the MX RR in the answer section of the response.
-The additional section contains the address RRs because the name server
-at C.ISI.EDU guesses that the requester will need the addresses in order
-to properly use the information carried by the MX.
-
-6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
-
-C.ISI.EDU would reply to this query with:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS          |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-The only difference between the response and the query is the AA and
-RESPONSE bits in the header.  The interpretation of this response is
-that the server is authoritative for the name, and the name exists, but
-no RRs of type NS are present there.
-
-6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
-
-If a user mistyped a host name, we might see this type of query.
-
-
-
-Mockapetris                                                    [Page 43]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-C.ISI.EDU would answer it with:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE             |
-               +---------------------------------------------------+
-    Question   | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A           |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA.      |
-               |       870611 1800 300 604800 86400                |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-This response states that the name does not exist.  This condition is
-signalled in the response code (RCODE) section of the header.
-
-The SOA RR in the authority section is the optional negative caching
-information which allows the resolver using this response to assume that
-the name will not exist for the SOA MINIMUM (86400) seconds.
-
-6.2.6. QNAME=BRL.MIL, QTYPE=A
-
-If this query is sent to C.ISI.EDU, the reply would be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE                           |
-               +---------------------------------------------------+
-    Question   | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A                 |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | MIL.             86400 IN NS       SRI-NIC.ARPA.  |
-               |                  86400    NS       A.ISI.EDU.     |
-               +---------------------------------------------------+
-    Additional | A.ISI.EDU.                A        26.3.0.103     |
-               | SRI-NIC.ARPA.             A        26.0.0.73      |
-               |                           A        10.0.0.51      |
-               +---------------------------------------------------+
-
-This response has an empty answer section, but is not authoritative, so
-it is a referral.  The name server on C.ISI.EDU, realizing that it is
-not authoritative for the MIL domain, has referred the requester to
-servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative
-for the MIL domain.
-
-
-
-
-
-Mockapetris                                                    [Page 44]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
-
-The response to this query from A.ISI.EDU would be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
-               +---------------------------------------------------+
-    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
-               | C.ISI.EDU.     86400 IN A          10.0.0.52      |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-Note that the AA bit in the header guarantees that the data matching
-QNAME is authoritative, but does not say anything about whether the data
-for C.ISI.EDU is authoritative.  This complete reply is possible because
-A.ISI.EDU happens to be authoritative for both the ARPA domain where
-USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is
-found.
-
-If the same query was sent to C.ISI.EDU, its response might be the same
-as shown above if it had its own address in its cache, but might also
-be:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 45]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
-               +---------------------------------------------------+
-    Answer     | USC-ISIC.ARPA.   86400 IN CNAME   C.ISI.EDU.      |
-               +---------------------------------------------------+
-    Authority  | ISI.EDU.        172800 IN NS      VAXA.ISI.EDU.   |
-               |                           NS      A.ISI.EDU.      |
-               |                           NS      VENERA.ISI.EDU. |
-               +---------------------------------------------------+
-    Additional | VAXA.ISI.EDU.   172800    A       10.2.0.27       |
-               |                 172800    A       128.9.0.33      |
-               | VENERA.ISI.EDU. 172800    A       10.1.0.52       |
-               |                 172800    A       128.9.0.32      |
-               | A.ISI.EDU.      172800    A       26.3.0.103      |
-               +---------------------------------------------------+
-
-This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
-plus a referral to the name servers for ISI.EDU.  This sort of reply
-isn't very likely given that the query is for the host name of the name
-server being asked, but would be common for other aliases.
-
-6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
-
-If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would
-be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
-               +---------------------------------------------------+
-    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
-server doesn't attempt to look up anything for C.ISI.EDU.  (Except
-possibly for the additional section.)
-
-6.3. Example resolution
-
-The following examples illustrate the operations a resolver must perform
-for its client.  We assume that the resolver is starting without a
-
-
-
-Mockapetris                                                    [Page 46]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-cache, as might be the case after system boot.  We further assume that
-the system is not one of the hosts in the data and that the host is
-located somewhere on net 26, and that its safety belt (SBELT) data
-structure has the following information:
-
-    Match count = -1
-    SRI-NIC.ARPA.   26.0.0.73       10.0.0.51
-    A.ISI.EDU.      26.3.0.103
-
-This information specifies servers to try, their addresses, and a match
-count of -1, which says that the servers aren't very close to the
-target.  Note that the -1 isn't supposed to be an accurate closeness
-measure, just a value so that later stages of the algorithm will work.
-
-The following examples illustrate the use of a cache, so each example
-assumes that previous requests have completed.
-
-6.3.1. Resolve MX for ISI.EDU.
-
-Suppose the first request to the resolver comes from the local mailer,
-which has mail for PVM@ISI.EDU.  The mailer might then ask for type MX
-RRs for the domain name ISI.EDU.
-
-The resolver would look in its cache for MX RRs at ISI.EDU, but the
-empty cache wouldn't be helpful.  The resolver would recognize that it
-needed to query foreign servers and try to determine the best servers to
-query.  This search would look for NS RRs for the domains ISI.EDU, EDU,
-and the root.  These searches of the cache would also fail.  As a last
-resort, the resolver would use the information from the SBELT, copying
-it into its SLIST structure.
-
-At this point the resolver would need to pick one of the three available
-addresses to try.  Given that the resolver is on net 26, it should
-choose either 26.0.0.73 or 26.3.0.103 as its first choice.  It would
-then send off a query of the form:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 47]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY                                     |
-               +---------------------------------------------------+
-    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-The resolver would then wait for a response to its query or a timeout.
-If the timeout occurs, it would try different servers, then different
-addresses of the same servers, lastly retrying addresses already tried.
-It might eventually receive a reply from SRI-NIC.ARPA:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE                           |
-               +---------------------------------------------------+
-    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | ISI.EDU.        172800 IN NS       VAXA.ISI.EDU.  |
-               |                           NS       A.ISI.EDU.     |
-               |                           NS       VENERA.ISI.EDU.|
-               +---------------------------------------------------+
-    Additional | VAXA.ISI.EDU.   172800    A        10.2.0.27      |
-               |                 172800    A        128.9.0.33     |
-               | VENERA.ISI.EDU. 172800    A        10.1.0.52      |
-               |                 172800    A        128.9.0.32     |
-               | A.ISI.EDU.      172800    A        26.3.0.103     |
-               +---------------------------------------------------+
-
-The resolver would notice that the information in the response gave a
-closer delegation to ISI.EDU than its existing SLIST (since it matches
-three labels).  The resolver would then cache the information in this
-response and use it to set up a new SLIST:
-
-    Match count = 3
-    A.ISI.EDU.      26.3.0.103
-    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
-    VENERA.ISI.EDU. 10.1.0.52       128.9.0.32
-
-A.ISI.EDU appears on this list as well as the previous one, but that is
-purely coincidental.  The resolver would again start transmitting and
-waiting for responses.  Eventually it would get an answer:
-
-
-
-Mockapetris                                                    [Page 48]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
-               +---------------------------------------------------+
-    Answer     | ISI.EDU.                MX 10 VENERA.ISI.EDU.     |
-               |                         MX 20 VAXA.ISI.EDU.       |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | VAXA.ISI.EDU.   172800  A  10.2.0.27              |
-               |                 172800  A  128.9.0.33             |
-               | VENERA.ISI.EDU. 172800  A  10.1.0.52              |
-               |                 172800  A  128.9.0.32             |
-               +---------------------------------------------------+
-
-The resolver would add this information to its cache, and return the MX
-RRs to its client.
-
-6.3.2. Get the host name for address 26.6.0.65
-
-The resolver would translate this into a request for PTR RRs for
-65.0.6.26.IN-ADDR.ARPA.  This information is not in the cache, so the
-resolver would look for foreign servers to ask.  No servers would match,
-so it would use SBELT again.  (Note that the servers for the ISI.EDU
-domain are in the cache, but ISI.EDU is not an ancestor of
-65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.)
-
-Since this request is within the authoritative data of both servers in
-SBELT, eventually one would return:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 49]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
-               +---------------------------------------------------+
-    Answer     | 65.0.6.26.IN-ADDR.ARPA.    PTR     ACC.ARPA.      |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-6.3.3. Get the host address of poneria.ISI.EDU
-
-This request would translate into a type A request for poneria.ISI.EDU.
-The resolver would not find any cached data for this name, but would
-find the NS RRs in the cache for ISI.EDU when it looks for foreign
-servers to ask.  Using this data, it would construct a SLIST of the
-form:
-
-    Match count = 3
-
-    A.ISI.EDU.      26.3.0.103
-    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
-    VENERA.ISI.EDU. 10.1.0.52
-
-A.ISI.EDU is listed first on the assumption that the resolver orders its
-choices by preference, and A.ISI.EDU is on the same network.
-
-One of these servers would answer the query.
-
-7. REFERENCES and BIBLIOGRAPHY
-
-[Dyer 87]       Dyer, S., and F. Hsu, "Hesiod", Project Athena
-                Technical Plan - Name Service, April 1987, version 1.9.
-
-                Describes the fundamentals of the Hesiod name service.
-
-[IEN-116]       J. Postel, "Internet Name Server", IEN-116,
-                USC/Information Sciences Institute, August 1979.
-
-                A name service obsoleted by the Domain Name System, but
-                still in use.
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 50]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-[Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer
-                Networks",Communications of the ACM, October 1986,
-                volume 29, number 10.
-
-[RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
-                Information Center, SRI International, December 1977.
-
-[RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
-                USC/Information Sciences Institute, August 1980.
-
-[RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
-                USC/Information Sciences Institute, September 1981.
-
-[RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
-                September 1981.
-
-                Suggests introduction of a hierarchy in place of a flat
-                name space for the Internet.
-
-[RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
-                USC/Information Sciences Institute, February 1982.
-
-[RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
-                Internet Host Table Specification", RFC-810, Network
-                Information Center, SRI International, March 1982.
-
-                Obsolete.  See RFC-952.
-
-[RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
-                Server", RFC-811, Network Information Center, SRI
-                International, March 1982.
-
-                Obsolete.  See RFC-953.
-
-[RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
-                Network Information Center, SRI International, March
-                1982.
-
-[RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
-                Internet User Applications", RFC-819, Network
-                Information Center, SRI International, August 1982.
-
-                Early thoughts on the design of the domain system.
-                Current implementation is completely different.
-
-[RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
-                USC/Information Sciences Institute, August 1980.
-
-
-
-
-Mockapetris                                                    [Page 51]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-[RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
-                RFC-830, Network Information Center, SRI International,
-                October 1982.
-
-                Early thoughts on the design of the domain system.
-                Current implementation is completely different.
-
-[RFC-882]       P. Mockapetris, "Domain names - Concepts and
-                Facilities," RFC-882, USC/Information Sciences
-                Institute, November 1983.
-
-                Superceeded by this memo.
-
-[RFC-883]       P. Mockapetris, "Domain names - Implementation and
-                Specification," RFC-883, USC/Information Sciences
-                Institute, November 1983.
-
-                Superceeded by this memo.
-
-[RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
-                RFC-920, USC/Information Sciences Institute
-                October 1984.
-
-                Explains the naming scheme for top level domains.
-
-[RFC-952]       K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
-                Table Specification", RFC-952, SRI, October 1985.
-
-                Specifies the format of HOSTS.TXT, the host/address
-                table replaced by the DNS.
-
-[RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
-                RFC-953, SRI, October 1985.
-
-                This RFC contains the official specification of the
-                hostname server protocol, which is obsoleted by the DNS.
-                This TCP based protocol accesses information stored in
-                the RFC-952 format, and is used to obtain copies of the
-                host table.
-
-[RFC-973]       P. Mockapetris, "Domain System Changes and
-                Observations", RFC-973, USC/Information Sciences
-                Institute, January 1986.
-
-                Describes changes to RFC-882 and RFC-883 and reasons for
-                them.  Now obsolete.
-
-
-
-
-
-Mockapetris                                                    [Page 52]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-[RFC-974]       C. Partridge, "Mail routing and the domain system",
-                RFC-974, CSNET CIC BBN Labs, January 1986.
-
-                Describes the transition from HOSTS.TXT based mail
-                addressing to the more powerful MX system used with the
-                domain system.
-
-[RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
-                service on a TCP/UDP transport: Concepts and Methods",
-                RFC-1001, March 1987.
-
-                This RFC and RFC-1002 are a preliminary design for
-                NETBIOS on top of TCP/IP which proposes to base NetBIOS
-                name service on top of the DNS.
-
-[RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
-                service on a TCP/UDP transport: Detailed
-                Specifications", RFC-1002, March 1987.
-
-[RFC-1010]      J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010,
-                USC/Information Sciences Institute, May 1987
-
-                Contains socket numbers and mnemonics for host names,
-                operating systems, etc.
-
-[RFC-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
-                November 1987.
-
-                Describes a plan for converting the MILNET to the DNS.
-
-[RFC-1032]      M. K. Stahl, "Establishing a Domain - Guidelines for
-                Administrators", RFC-1032, November 1987.
-
-                Describes the registration policies used by the NIC to
-                administer the top level domains and delegate subzones.
-
-[RFC-1033]      M. K. Lottor, "Domain Administrators Operations Guide",
-                RFC-1033, November 1987.
-
-                A cookbook for domain administrators.
-
-[Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
-                Name Server", Computer Networks, vol 6, nr 3, July 1982.
-
-                Describes a name service for CSNET which is independent
-                from the DNS and DNS use in the CSNET.
-
-
-
-
-
-Mockapetris                                                    [Page 53]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-Index
-
-          A   12
-          Absolute names   8
-          Aliases   14, 31
-          Authority   6
-          AXFR   17
-
-          Case of characters   7
-          CH   12
-          CNAME   12, 13, 31
-          Completion queries   18
-
-          Domain name   6, 7
-
-          Glue RRs   20
-
-          HINFO   12
-
-          IN   12
-          Inverse queries   16
-          Iterative   4
-
-          Label   7
-
-          Mailbox names   9
-          MX   12
-
-          Name error   27, 36
-          Name servers   5, 17
-          NE   30
-          Negative caching   44
-          NS   12
-
-          Opcode   16
-
-          PTR   12
-
-          QCLASS   16
-          QTYPE   16
-
-          RDATA   13
-          Recursive   4
-          Recursive service   22
-          Relative names   7
-          Resolvers   6
-          RR   12
-
-
-
-
-Mockapetris                                                    [Page 54]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-          Safety belt   33
-          Sections   16
-          SOA   12
-          Standard queries   22
-
-          Status queries   18
-          Stub resolvers   32
-
-          TTL   12, 13
-
-          Wildcards   25
-
-          Zone transfers   28
-          Zones   19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 55]
-
diff --git a/doc/rfc/rfc1035.txt b/doc/rfc/rfc1035.txt
deleted file mode 100644
index b1a9bf5a..00000000
--- a/doc/rfc/rfc1035.txt
+++ /dev/null
@@ -1,3077 +0,0 @@
-Network Working Group                                     P. Mockapetris
-Request for Comments: 1035                                           ISI
-                                                           November 1987
-Obsoletes: RFCs 882, 883, 973
-
-            DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
-
-
-1. STATUS OF THIS MEMO
-
-This RFC describes the details of the domain system and protocol, and
-assumes that the reader is familiar with the concepts discussed in a
-companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
-
-The domain system is a mixture of functions and data types which are an
-official protocol and functions and data types which are still
-experimental.  Since the domain system is intentionally extensible, new
-data types and experimental behavior should always be expected in parts
-of the system beyond the official protocol.  The official protocol parts
-include standard queries, responses and the Internet class RR data
-formats (e.g., host addresses).  Since the previous RFC set, several
-definitions have changed, so some previous definitions are obsolete.
-
-Experimental or obsolete features are clearly marked in these RFCs, and
-such information should be used with caution.
-
-The reader is especially cautioned not to depend on the values which
-appear in examples to be current or complete, since their purpose is
-primarily pedagogical.  Distribution of this memo is unlimited.
-
-                           Table of Contents
-
-  1. STATUS OF THIS MEMO                                              1
-  2. INTRODUCTION                                                     3
-      2.1. Overview                                                   3
-      2.2. Common configurations                                      4
-      2.3. Conventions                                                7
-          2.3.1. Preferred name syntax                                7
-          2.3.2. Data Transmission Order                              8
-          2.3.3. Character Case                                       9
-          2.3.4. Size limits                                         10
-  3. DOMAIN NAME SPACE AND RR DEFINITIONS                            10
-      3.1. Name space definitions                                    10
-      3.2. RR definitions                                            11
-          3.2.1. Format                                              11
-          3.2.2. TYPE values                                         12
-          3.2.3. QTYPE values                                        12
-          3.2.4. CLASS values                                        13
-
-
-
-Mockapetris                                                     [Page 1]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-          3.2.5. QCLASS values                                       13
-      3.3. Standard RRs                                              13
-          3.3.1. CNAME RDATA format                                  14
-          3.3.2. HINFO RDATA format                                  14
-          3.3.3. MB RDATA format (EXPERIMENTAL)                      14
-          3.3.4. MD RDATA format (Obsolete)                          15
-          3.3.5. MF RDATA format (Obsolete)                          15
-          3.3.6. MG RDATA format (EXPERIMENTAL)                      16
-          3.3.7. MINFO RDATA format (EXPERIMENTAL)                   16
-          3.3.8. MR RDATA format (EXPERIMENTAL)                      17
-          3.3.9. MX RDATA format                                     17
-          3.3.10. NULL RDATA format (EXPERIMENTAL)                   17
-          3.3.11. NS RDATA format                                    18
-          3.3.12. PTR RDATA format                                   18
-          3.3.13. SOA RDATA format                                   19
-          3.3.14. TXT RDATA format                                   20
-      3.4. ARPA Internet specific RRs                                20
-          3.4.1. A RDATA format                                      20
-          3.4.2. WKS RDATA format                                    21
-      3.5. IN-ADDR.ARPA domain                                       22
-      3.6. Defining new types, classes, and special namespaces       24
-  4. MESSAGES                                                        25
-      4.1. Format                                                    25
-          4.1.1. Header section format                               26
-          4.1.2. Question section format                             28
-          4.1.3. Resource record format                              29
-          4.1.4. Message compression                                 30
-      4.2. Transport                                                 32
-          4.2.1. UDP usage                                           32
-          4.2.2. TCP usage                                           32
-  5. MASTER FILES                                                    33
-      5.1. Format                                                    33
-      5.2. Use of master files to define zones                       35
-      5.3. Master file example                                       36
-  6. NAME SERVER IMPLEMENTATION                                      37
-      6.1. Architecture                                              37
-          6.1.1. Control                                             37
-          6.1.2. Database                                            37
-          6.1.3. Time                                                39
-      6.2. Standard query processing                                 39
-      6.3. Zone refresh and reload processing                        39
-      6.4. Inverse queries (Optional)                                40
-          6.4.1. The contents of inverse queries and responses       40
-          6.4.2. Inverse query and response example                  41
-          6.4.3. Inverse query processing                            42
-
-
-
-
-
-
-Mockapetris                                                     [Page 2]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-      6.5. Completion queries and responses                          42
-  7. RESOLVER IMPLEMENTATION                                         43
-      7.1. Transforming a user request into a query                  43
-      7.2. Sending the queries                                       44
-      7.3. Processing responses                                      46
-      7.4. Using the cache                                           47
-  8. MAIL SUPPORT                                                    47
-      8.1. Mail exchange binding                                     48
-      8.2. Mailbox binding (Experimental)                            48
-  9. REFERENCES and BIBLIOGRAPHY                                     50
-  Index                                                              54
-
-2. INTRODUCTION
-
-2.1. Overview
-
-The goal of domain names is to provide a mechanism for naming resources
-in such a way that the names are usable in different hosts, networks,
-protocol families, internets, and administrative organizations.
-
-From the user's point of view, domain names are useful as arguments to a
-local agent, called a resolver, which retrieves information associated
-with the domain name.  Thus a user might ask for the host address or
-mail information associated with a particular domain name.  To enable
-the user to request a particular type of information, an appropriate
-query type is passed to the resolver with the domain name.  To the user,
-the domain tree is a single information space; the resolver is
-responsible for hiding the distribution of data among name servers from
-the user.
-
-From the resolver's point of view, the database that makes up the domain
-space is distributed among various name servers.  Different parts of the
-domain space are stored in different name servers, although a particular
-data item will be stored redundantly in two or more name servers.  The
-resolver starts with knowledge of at least one name server.  When the
-resolver processes a user query it asks a known name server for the
-information; in return, the resolver either receives the desired
-information or a referral to another name server.  Using these
-referrals, resolvers learn the identities and contents of other name
-servers.  Resolvers are responsible for dealing with the distribution of
-the domain space and dealing with the effects of name server failure by
-consulting redundant databases in other servers.
-
-Name servers manage two kinds of data.  The first kind of data held in
-sets called zones; each zone is the complete database for a particular
-"pruned" subtree of the domain space.  This data is called
-authoritative.  A name server periodically checks to make sure that its
-zones are up to date, and if not, obtains a new copy of updated zones
-
-
-
-Mockapetris                                                     [Page 3]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-from master files stored locally or in another name server.  The second
-kind of data is cached data which was acquired by a local resolver.
-This data may be incomplete, but improves the performance of the
-retrieval process when non-local data is repeatedly accessed.  Cached
-data is eventually discarded by a timeout mechanism.
-
-This functional structure isolates the problems of user interface,
-failure recovery, and distribution in the resolvers and isolates the
-database update and refresh problems in the name servers.
-
-2.2. Common configurations
-
-A host can participate in the domain name system in a number of ways,
-depending on whether the host runs programs that retrieve information
-from the domain system, name servers that answer queries from other
-hosts, or various combinations of both functions.  The simplest, and
-perhaps most typical, configuration is shown below:
-
-                 Local Host                        |  Foreign
-                                                   |
-    +---------+               +----------+         |  +--------+
-    |         | user queries  |          |queries  |  |        |
-    |  User   |-------------->|          |---------|->|Foreign |
-    | Program |               | Resolver |         |  |  Name  |
-    |         |<--------------|          |<--------|--| Server |
-    |         | user responses|          |responses|  |        |
-    +---------+               +----------+         |  +--------+
-                                |     A            |
-                cache additions |     | references |
-                                V     |            |
-                              +----------+         |
-                              |  cache   |         |
-                              +----------+         |
-
-User programs interact with the domain name space through resolvers; the
-format of user queries and user responses is specific to the host and
-its operating system.  User queries will typically be operating system
-calls, and the resolver and its cache will be part of the host operating
-system.  Less capable hosts may choose to implement the resolver as a
-subroutine to be linked in with every program that needs its services.
-Resolvers answer user queries with information they acquire via queries
-to foreign name servers and the local cache.
-
-Note that the resolver may have to make several queries to several
-different foreign name servers to answer a particular user query, and
-hence the resolution of a user query may involve several network
-accesses and an arbitrary amount of time.  The queries to foreign name
-servers and the corresponding responses have a standard format described
-
-
-
-Mockapetris                                                     [Page 4]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-in this memo, and may be datagrams.
-
-Depending on its capabilities, a name server could be a stand alone
-program on a dedicated machine or a process or processes on a large
-timeshared host.  A simple configuration might be:
-
-                 Local Host                        |  Foreign
-                                                   |
-      +---------+                                  |
-     /         /|                                  |
-    +---------+ |             +----------+         |  +--------+
-    |         | |             |          |responses|  |        |
-    |         | |             |   Name   |---------|->|Foreign |
-    |  Master |-------------->|  Server  |         |  |Resolver|
-    |  files  | |             |          |<--------|--|        |
-    |         |/              |          | queries |  +--------+
-    +---------+               +----------+         |
-
-Here a primary name server acquires information about one or more zones
-by reading master files from its local file system, and answers queries
-about those zones that arrive from foreign resolvers.
-
-The DNS requires that all zones be redundantly supported by more than
-one name server.  Designated secondary servers can acquire zones and
-check for updates from the primary server using the zone transfer
-protocol of the DNS.  This configuration is shown below:
-
-                 Local Host                        |  Foreign
-                                                   |
-      +---------+                                  |
-     /         /|                                  |
-    +---------+ |             +----------+         |  +--------+
-    |         | |             |          |responses|  |        |
-    |         | |             |   Name   |---------|->|Foreign |
-    |  Master |-------------->|  Server  |         |  |Resolver|
-    |  files  | |             |          |<--------|--|        |
-    |         |/              |          | queries |  +--------+
-    +---------+               +----------+         |
-                                A     |maintenance |  +--------+
-                                |     +------------|->|        |
-                                |      queries     |  |Foreign |
-                                |                  |  |  Name  |
-                                +------------------|--| Server |
-                             maintenance responses |  +--------+
-
-In this configuration, the name server periodically establishes a
-virtual circuit to a foreign name server to acquire a copy of a zone or
-to check that an existing copy has not changed.  The messages sent for
-
-
-
-Mockapetris                                                     [Page 5]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-these maintenance activities follow the same form as queries and
-responses, but the message sequences are somewhat different.
-
-The information flow in a host that supports all aspects of the domain
-name system is shown below:
-
-                 Local Host                        |  Foreign
-                                                   |
-    +---------+               +----------+         |  +--------+
-    |         | user queries  |          |queries  |  |        |
-    |  User   |-------------->|          |---------|->|Foreign |
-    | Program |               | Resolver |         |  |  Name  |
-    |         |<--------------|          |<--------|--| Server |
-    |         | user responses|          |responses|  |        |
-    +---------+               +----------+         |  +--------+
-                                |     A            |
-                cache additions |     | references |
-                                V     |            |
-                              +----------+         |
-                              |  Shared  |         |
-                              | database |         |
-                              +----------+         |
-                                A     |            |
-      +---------+     refreshes |     | references |
-     /         /|               |     V            |
-    +---------+ |             +----------+         |  +--------+
-    |         | |             |          |responses|  |        |
-    |         | |             |   Name   |---------|->|Foreign |
-    |  Master |-------------->|  Server  |         |  |Resolver|
-    |  files  | |             |          |<--------|--|        |
-    |         |/              |          | queries |  +--------+
-    +---------+               +----------+         |
-                                A     |maintenance |  +--------+
-                                |     +------------|->|        |
-                                |      queries     |  |Foreign |
-                                |                  |  |  Name  |
-                                +------------------|--| Server |
-                             maintenance responses |  +--------+
-
-The shared database holds domain space data for the local name server
-and resolver.  The contents of the shared database will typically be a
-mixture of authoritative data maintained by the periodic refresh
-operations of the name server and cached data from previous resolver
-requests.  The structure of the domain data and the necessity for
-synchronization between name servers and resolvers imply the general
-characteristics of this database, but the actual format is up to the
-local implementor.
-
-
-
-
-Mockapetris                                                     [Page 6]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-Information flow can also be tailored so that a group of hosts act
-together to optimize activities.  Sometimes this is done to offload less
-capable hosts so that they do not have to implement a full resolver.
-This can be appropriate for PCs or hosts which want to minimize the
-amount of new network code which is required.  This scheme can also
-allow a group of hosts can share a small number of caches rather than
-maintaining a large number of separate caches, on the premise that the
-centralized caches will have a higher hit ratio.  In either case,
-resolvers are replaced with stub resolvers which act as front ends to
-resolvers located in a recursive server in one or more name servers
-known to perform that service:
-
-                   Local Hosts                     |  Foreign
-                                                   |
-    +---------+                                    |
-    |         | responses                          |
-    | Stub    |<--------------------+              |
-    | Resolver|                     |              |
-    |         |----------------+    |              |
-    +---------+ recursive      |    |              |
-                queries        |    |              |
-                               V    |              |
-    +---------+ recursive     +----------+         |  +--------+
-    |         | queries       |          |queries  |  |        |
-    | Stub    |-------------->| Recursive|---------|->|Foreign |
-    | Resolver|               | Server   |         |  |  Name  |
-    |         |<--------------|          |<--------|--| Server |
-    +---------+ responses     |          |responses|  |        |
-                              +----------+         |  +--------+
-                              |  Central |         |
-                              |   cache  |         |
-                              +----------+         |
-
-In any case, note that domain components are always replicated for
-reliability whenever possible.
-
-2.3. Conventions
-
-The domain system has several conventions dealing with low-level, but
-fundamental, issues.  While the implementor is free to violate these
-conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
-ALL behavior observed from other hosts.
-
-2.3.1. Preferred name syntax
-
-The DNS specifications attempt to be as general as possible in the rules
-for constructing domain names.  The idea is that the name of any
-existing object can be expressed as a domain name with minimal changes.
-
-
-
-Mockapetris                                                     [Page 7]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-However, when assigning a domain name for an object, the prudent user
-will select a name which satisfies both the rules of the domain system
-and any existing rules for the object, whether these rules are published
-or implied by existing programs.
-
-For example, when naming a mail domain, the user should satisfy both the
-rules of this memo and those in RFC-822.  When creating a new host name,
-the old rules for HOSTS.TXT should be followed.  This avoids problems
-when old software is converted to use domain names.
-
-The following syntax will result in fewer problems with many
-
-applications that use domain names (e.g., mail, TELNET).
-
-<domain> ::= <subdomain> | " "
-
-<subdomain> ::= <label> | <subdomain> "." <label>
-
-<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
-
-<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
-
-<let-dig-hyp> ::= <let-dig> | "-"
-
-<let-dig> ::= <letter> | <digit>
-
-<letter> ::= any one of the 52 alphabetic characters A through Z in
-upper case and a through z in lower case
-
-<digit> ::= any one of the ten digits 0 through 9
-
-Note that while upper and lower case letters are allowed in domain
-names, no significance is attached to the case.  That is, two names with
-the same spelling but different case are to be treated as if identical.
-
-The labels must follow the rules for ARPANET host names.  They must
-start with a letter, end with a letter or digit, and have as interior
-characters only letters, digits, and hyphen.  There are also some
-restrictions on the length.  Labels must be 63 characters or less.
-
-For example, the following strings identify hosts in the Internet:
-
-A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
-
-2.3.2. Data Transmission Order
-
-The order of transmission of the header and data described in this
-document is resolved to the octet level.  Whenever a diagram shows a
-
-
-
-Mockapetris                                                     [Page 8]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-group of octets, the order of transmission of those octets is the normal
-order in which they are read in English.  For example, in the following
-diagram, the octets are transmitted in the order they are numbered.
-
-     0                   1
-     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |       1       |       2       |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |       3       |       4       |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |       5       |       6       |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-Whenever an octet represents a numeric quantity, the left most bit in
-the diagram is the high order or most significant bit.  That is, the bit
-labeled 0 is the most significant bit.  For example, the following
-diagram represents the value 170 (decimal).
-
-     0 1 2 3 4 5 6 7
-    +-+-+-+-+-+-+-+-+
-    |1 0 1 0 1 0 1 0|
-    +-+-+-+-+-+-+-+-+
-
-Similarly, whenever a multi-octet field represents a numeric quantity
-the left most bit of the whole field is the most significant bit.  When
-a multi-octet quantity is transmitted the most significant octet is
-transmitted first.
-
-2.3.3. Character Case
-
-For all parts of the DNS that are part of the official protocol, all
-comparisons between character strings (e.g., labels, domain names, etc.)
-are done in a case-insensitive manner.  At present, this rule is in
-force throughout the domain system without exception.  However, future
-additions beyond current usage may need to use the full binary octet
-capabilities in names, so attempts to store domain names in 7-bit ASCII
-or use of special bytes to terminate labels, etc., should be avoided.
-
-When data enters the domain system, its original case should be
-preserved whenever possible.  In certain circumstances this cannot be
-done.  For example, if two RRs are stored in a database, one at x.y and
-one at X.Y, they are actually stored at the same place in the database,
-and hence only one casing would be preserved.  The basic rule is that
-case can be discarded only when data is used to define structure in a
-database, and two names are identical when compared in a case
-insensitive manner.
-
-
-
-
-Mockapetris                                                     [Page 9]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-Loss of case sensitive data must be minimized.  Thus while data for x.y
-and X.Y may both be stored under a single location x.y or X.Y, data for
-a.x and B.X would never be stored under A.x, A.X, b.x, or b.X.  In
-general, this preserves the case of the first label of a domain name,
-but forces standardization of interior node labels.
-
-Systems administrators who enter data into the domain database should
-take care to represent the data they supply to the domain system in a
-case-consistent manner if their system is case-sensitive.  The data
-distribution system in the domain system will ensure that consistent
-representations are preserved.
-
-2.3.4. Size limits
-
-Various objects and parameters in the DNS have size limits.  They are
-listed below.  Some could be easily changed, others are more
-fundamental.
-
-labels          63 octets or less
-
-names           255 octets or less
-
-TTL             positive values of a signed 32 bit number.
-
-UDP messages    512 octets or less
-
-3. DOMAIN NAME SPACE AND RR DEFINITIONS
-
-3.1. Name space definitions
-
-Domain names in messages are expressed in terms of a sequence of labels.
-Each label is represented as a one octet length field followed by that
-number of octets.  Since every domain name ends with the null label of
-the root, a domain name is terminated by a length byte of zero.  The
-high order two bits of every length octet must be zero, and the
-remaining six bits of the length field limit the label to 63 octets or
-less.
-
-To simplify implementations, the total length of a domain name (i.e.,
-label octets and label length octets) is restricted to 255 octets or
-less.
-
-Although labels can contain any 8 bit values in octets that make up a
-label, it is strongly recommended that labels follow the preferred
-syntax described elsewhere in this memo, which is compatible with
-existing host naming conventions.  Name servers and resolvers must
-compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
-with zero parity.  Non-alphabetic codes must match exactly.
-
-
-
-Mockapetris                                                    [Page 10]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.2. RR definitions
-
-3.2.1. Format
-
-All RRs have the same top level format shown below:
-
-                                    1  1  1  1  1  1
-      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                                               |
-    /                                               /
-    /                      NAME                     /
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      TYPE                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     CLASS                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      TTL                      |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                   RDLENGTH                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
-    /                     RDATA                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-where:
-
-NAME            an owner name, i.e., the name of the node to which this
-                resource record pertains.
-
-TYPE            two octets containing one of the RR TYPE codes.
-
-CLASS           two octets containing one of the RR CLASS codes.
-
-TTL             a 32 bit signed integer that specifies the time interval
-                that the resource record may be cached before the source
-                of the information should again be consulted.  Zero
-                values are interpreted to mean that the RR can only be
-                used for the transaction in progress, and should not be
-                cached.  For example, SOA records are always distributed
-                with a zero TTL to prohibit caching.  Zero values can
-                also be used for extremely volatile data.
-
-RDLENGTH        an unsigned 16 bit integer that specifies the length in
-                octets of the RDATA field.
-
-
-
-Mockapetris                                                    [Page 11]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-RDATA           a variable length string of octets that describes the
-                resource.  The format of this information varies
-                according to the TYPE and CLASS of the resource record.
-
-3.2.2. TYPE values
-
-TYPE fields are used in resource records.  Note that these types are a
-subset of QTYPEs.
-
-TYPE            value and meaning
-
-A               1 a host address
-
-NS              2 an authoritative name server
-
-MD              3 a mail destination (Obsolete - use MX)
-
-MF              4 a mail forwarder (Obsolete - use MX)
-
-CNAME           5 the canonical name for an alias
-
-SOA             6 marks the start of a zone of authority
-
-MB              7 a mailbox domain name (EXPERIMENTAL)
-
-MG              8 a mail group member (EXPERIMENTAL)
-
-MR              9 a mail rename domain name (EXPERIMENTAL)
-
-NULL            10 a null RR (EXPERIMENTAL)
-
-WKS             11 a well known service description
-
-PTR             12 a domain name pointer
-
-HINFO           13 host information
-
-MINFO           14 mailbox or mail list information
-
-MX              15 mail exchange
-
-TXT             16 text strings
-
-3.2.3. QTYPE values
-
-QTYPE fields appear in the question part of a query.  QTYPES are a
-superset of TYPEs, hence all TYPEs are valid QTYPEs.  In addition, the
-following QTYPEs are defined:
-
-
-
-Mockapetris                                                    [Page 12]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-AXFR            252 A request for a transfer of an entire zone
-
-MAILB           253 A request for mailbox-related records (MB, MG or MR)
-
-MAILA           254 A request for mail agent RRs (Obsolete - see MX)
-
-*               255 A request for all records
-
-3.2.4. CLASS values
-
-CLASS fields appear in resource records.  The following CLASS mnemonics
-and values are defined:
-
-IN              1 the Internet
-
-CS              2 the CSNET class (Obsolete - used only for examples in
-                some obsolete RFCs)
-
-CH              3 the CHAOS class
-
-HS              4 Hesiod [Dyer 87]
-
-3.2.5. QCLASS values
-
-QCLASS fields appear in the question section of a query.  QCLASS values
-are a superset of CLASS values; every CLASS is a valid QCLASS.  In
-addition to CLASS values, the following QCLASSes are defined:
-
-*               255 any class
-
-3.3. Standard RRs
-
-The following RR definitions are expected to occur, at least
-potentially, in all classes.  In particular, NS, SOA, CNAME, and PTR
-will be used in all classes, and have the same format in all classes.
-Because their RDATA format is known, all domain names in the RDATA
-section of these RRs may be compressed.
-
-<domain-name> is a domain name represented as a series of labels, and
-terminated by a label with zero length.  <character-string> is a single
-length octet followed by that number of characters.  <character-string>
-is treated as binary information, and can be up to 256 characters in
-length (including the length octet).
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 13]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.3.1. CNAME RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                     CNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CNAME           A <domain-name> which specifies the canonical or primary
-                name for the owner.  The owner name is an alias.
-
-CNAME RRs cause no additional section processing, but name servers may
-choose to restart the query at the canonical name in certain cases.  See
-the description of name server logic in [RFC-1034] for details.
-
-3.3.2. HINFO RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                      CPU                      /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                       OS                      /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CPU             A <character-string> which specifies the CPU type.
-
-OS              A <character-string> which specifies the operating
-                system type.
-
-Standard values for CPU and OS can be found in [RFC-1010].
-
-HINFO records are used to acquire general information about a host.  The
-main use is for protocols such as FTP that can use special procedures
-when talking between machines or operating systems of the same type.
-
-3.3.3. MB RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   MADNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME         A <domain-name> which specifies a host which has the
-                specified mailbox.
-
-
-
-Mockapetris                                                    [Page 14]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-MB records cause additional section processing which looks up an A type
-RRs corresponding to MADNAME.
-
-3.3.4. MD RDATA format (Obsolete)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   MADNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME         A <domain-name> which specifies a host which has a mail
-                agent for the domain which should be able to deliver
-                mail for the domain.
-
-MD records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MD is obsolete.  See the definition of MX and [RFC-974] for details of
-the new scheme.  The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 0.
-
-3.3.5. MF RDATA format (Obsolete)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   MADNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME         A <domain-name> which specifies a host which has a mail
-                agent for the domain which will accept mail for
-                forwarding to the domain.
-
-MF records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MF is obsolete.  See the definition of MX and [RFC-974] for details ofw
-the new scheme.  The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 10.
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 15]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.3.6. MG RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   MGMNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MGMNAME         A <domain-name> which specifies a mailbox which is a
-                member of the mail group specified by the domain name.
-
-MG records cause no additional section processing.
-
-3.3.7. MINFO RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                    RMAILBX                    /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                    EMAILBX                    /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-RMAILBX         A <domain-name> which specifies a mailbox which is
-                responsible for the mailing list or mailbox.  If this
-                domain name names the root, the owner of the MINFO RR is
-                responsible for itself.  Note that many existing mailing
-                lists use a mailbox X-request for the RMAILBX field of
-                mailing list X, e.g., Msgroup-request for Msgroup.  This
-                field provides a more general mechanism.
-
-
-EMAILBX         A <domain-name> which specifies a mailbox which is to
-                receive error messages related to the mailing list or
-                mailbox specified by the owner of the MINFO RR (similar
-                to the ERRORS-TO: field which has been proposed).  If
-                this domain name names the root, errors should be
-                returned to the sender of the message.
-
-MINFO records cause no additional section processing.  Although these
-records can be associated with a simple mailbox, they are usually used
-with a mailing list.
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 16]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.3.8. MR RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   NEWNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NEWNAME         A <domain-name> which specifies a mailbox which is the
-                proper rename of the specified mailbox.
-
-MR records cause no additional section processing.  The main use for MR
-is as a forwarding entry for a user who has moved to a different
-mailbox.
-
-3.3.9. MX RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                  PREFERENCE                   |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   EXCHANGE                    /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PREFERENCE      A 16 bit integer which specifies the preference given to
-                this RR among others at the same owner.  Lower values
-                are preferred.
-
-EXCHANGE        A <domain-name> which specifies a host willing to act as
-                a mail exchange for the owner name.
-
-MX records cause type A additional section processing for the host
-specified by EXCHANGE.  The use of MX RRs is explained in detail in
-[RFC-974].
-
-3.3.10. NULL RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                  <anything>                   /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Anything at all may be in the RDATA field so long as it is 65535 octets
-or less.
-
-
-
-
-Mockapetris                                                    [Page 17]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-NULL records cause no additional section processing.  NULL RRs are not
-allowed in master files.  NULLs are used as placeholders in some
-experimental extensions of the DNS.
-
-3.3.11. NS RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   NSDNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NSDNAME         A <domain-name> which specifies a host which should be
-                authoritative for the specified class and domain.
-
-NS records cause both the usual additional section processing to locate
-a type A record, and, when used in a referral, a special search of the
-zone in which they reside for glue information.
-
-The NS RR states that the named host should be expected to have a zone
-starting at owner name of the specified class.  Note that the class may
-not indicate the protocol family which should be used to communicate
-with the host, although it is typically a strong hint.  For example,
-hosts which are name servers for either Internet (IN) or Hesiod (HS)
-class information are normally queried using IN class protocols.
-
-3.3.12. PTR RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   PTRDNAME                    /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PTRDNAME        A <domain-name> which points to some location in the
-                domain name space.
-
-PTR records cause no additional section processing.  These RRs are used
-in special domains to point to some other location in the domain space.
-These records are simple data, and don't imply any special processing
-similar to that performed by CNAME, which identifies aliases.  See the
-description of the IN-ADDR.ARPA domain for an example.
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 18]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.3.13. SOA RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                     MNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                     RNAME                     /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    SERIAL                     |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    REFRESH                    |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     RETRY                     |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    EXPIRE                     |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    MINIMUM                    |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MNAME           The <domain-name> of the name server that was the
-                original or primary source of data for this zone.
-
-RNAME           A <domain-name> which specifies the mailbox of the
-                person responsible for this zone.
-
-SERIAL          The unsigned 32 bit version number of the original copy
-                of the zone.  Zone transfers preserve this value.  This
-                value wraps and should be compared using sequence space
-                arithmetic.
-
-REFRESH         A 32 bit time interval before the zone should be
-                refreshed.
-
-RETRY           A 32 bit time interval that should elapse before a
-                failed refresh should be retried.
-
-EXPIRE          A 32 bit time value that specifies the upper limit on
-                the time interval that can elapse before the zone is no
-                longer authoritative.
-
-
-
-
-
-Mockapetris                                                    [Page 19]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-MINIMUM         The unsigned 32 bit minimum TTL field that should be
-                exported with any RR from this zone.
-
-SOA records cause no additional section processing.
-
-All times are in units of seconds.
-
-Most of these fields are pertinent only for name server maintenance
-operations.  However, MINIMUM is used in all query operations that
-retrieve RRs from a zone.  Whenever a RR is sent in a response to a
-query, the TTL field is set to the maximum of the TTL field from the RR
-and the MINIMUM field in the appropriate SOA.  Thus MINIMUM is a lower
-bound on the TTL field for all RRs in a zone.  Note that this use of
-MINIMUM should occur when the RRs are copied into the response and not
-when the zone is loaded from a master file or via a zone transfer.  The
-reason for this provison is to allow future dynamic update facilities to
-change the SOA RR with known semantics.
-
-
-3.3.14. TXT RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   TXT-DATA                    /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-TXT-DATA        One or more <character-string>s.
-
-TXT RRs are used to hold descriptive text.  The semantics of the text
-depends on the domain where it is found.
-
-3.4. Internet specific RRs
-
-3.4.1. A RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    ADDRESS                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS         A 32 bit Internet address.
-
-Hosts that have multiple Internet addresses will have multiple A
-records.
-
-
-
-
-
-Mockapetris                                                    [Page 20]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-A records cause no additional section processing.  The RDATA section of
-an A line in a master file is an Internet address expressed as four
-decimal numbers separated by dots without any imbedded spaces (e.g.,
-"10.2.0.52" or "192.0.5.6").
-
-3.4.2. WKS RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    ADDRESS                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |       PROTOCOL        |                       |
-    +--+--+--+--+--+--+--+--+                       |
-    |                                               |
-    /                   <BIT MAP>                   /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS         An 32 bit Internet address
-
-PROTOCOL        An 8 bit IP protocol number
-
-<BIT MAP>       A variable length bit map.  The bit map must be a
-                multiple of 8 bits long.
-
-The WKS record is used to describe the well known services supported by
-a particular protocol on a particular internet address.  The PROTOCOL
-field specifies an IP protocol number, and the bit map has one bit per
-port of the specified protocol.  The first bit corresponds to port 0,
-the second to port 1, etc.  If the bit map does not include a bit for a
-protocol of interest, that bit is assumed zero.  The appropriate values
-and mnemonics for ports and protocols are specified in [RFC-1010].
-
-For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
-25 (SMTP).  If this bit is set, a SMTP server should be listening on TCP
-port 25; if zero, SMTP service is not supported on the specified
-address.
-
-The purpose of WKS RRs is to provide availability information for
-servers for TCP and UDP.  If a server supports both TCP and UDP, or has
-multiple Internet addresses, then multiple WKS RRs are used.
-
-WKS RRs cause no additional section processing.
-
-In master files, both ports and protocols are expressed using mnemonics
-or decimal numbers.
-
-
-
-
-Mockapetris                                                    [Page 21]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.5. IN-ADDR.ARPA domain
-
-The Internet uses a special domain to support gateway location and
-Internet address to host mapping.  Other classes may employ a similar
-strategy in other domains.  The intent of this domain is to provide a
-guaranteed method to perform host address to host name mapping, and to
-facilitate queries to locate all gateways on a particular network in the
-Internet.
-
-Note that both of these services are similar to functions that could be
-performed by inverse queries; the difference is that this part of the
-domain name space is structured according to address, and hence can
-guarantee that the appropriate data can be located without an exhaustive
-search of the domain space.
-
-The domain begins at IN-ADDR.ARPA and has a substructure which follows
-the Internet addressing structure.
-
-Domain names in the IN-ADDR.ARPA domain are defined to have up to four
-labels in addition to the IN-ADDR.ARPA suffix.  Each label represents
-one octet of an Internet address, and is expressed as a character string
-for a decimal value in the range 0-255 (with leading zeros omitted
-except in the case of a zero octet which is represented by a single
-zero).
-
-Host addresses are represented by domain names that have all four labels
-specified.  Thus data for Internet address 10.2.0.52 is located at
-domain name 52.0.2.10.IN-ADDR.ARPA.  The reversal, though awkward to
-read, allows zones to be delegated which are exactly one network of
-address space.  For example, 10.IN-ADDR.ARPA can be a zone containing
-data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
-MILNET.  Address nodes are used to hold pointers to primary host names
-in the normal domain space.
-
-Network numbers correspond to some non-terminal nodes at various depths
-in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
-2, or 3 octets.  Network nodes are used to hold pointers to the primary
-host names of gateways attached to that network.  Since a gateway is, by
-definition, on more than one network, it will typically have two or more
-network nodes which point at it.  Gateways will also have host level
-pointers at their fully qualified addresses.
-
-Both the gateway pointers at network nodes and the normal host pointers
-at full address nodes use the PTR RR to point back to the primary domain
-names of the corresponding hosts.
-
-For example, the IN-ADDR.ARPA domain will contain information about the
-ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
-
-
-
-Mockapetris                                                    [Page 22]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU.  Assuming that ISI
-gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
-GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
-and a name GW.LCS.MIT.EDU, the domain database would contain:
-
-    10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
-    10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
-    18.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
-    26.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
-    22.0.2.10.IN-ADDR.ARPA.    PTR MILNET-GW.ISI.EDU.
-    103.0.0.26.IN-ADDR.ARPA.   PTR MILNET-GW.ISI.EDU.
-    77.0.0.10.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
-    4.0.10.18.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
-    103.0.3.26.IN-ADDR.ARPA.   PTR A.ISI.EDU.
-    6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
-
-Thus a program which wanted to locate gateways on net 10 would originate
-a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA.  It
-would receive two RRs in response:
-
-    10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
-    10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
-
-The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
-GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
-these gateways.
-
-A resolver which wanted to find the host name corresponding to Internet
-host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
-QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
-
-    6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
-
-Several cautions apply to the use of these services:
-   - Since the IN-ADDR.ARPA special domain and the normal domain
-     for a particular host or gateway will be in different zones,
-     the possibility exists that that the data may be inconsistent.
-
-   - Gateways will often have two names in separate domains, only
-     one of which can be primary.
-
-   - Systems that use the domain database to initialize their
-     routing tables must start with enough gateway information to
-     guarantee that they can access the appropriate name server.
-
-   - The gateway data only reflects the existence of a gateway in a
-     manner equivalent to the current HOSTS.TXT file.  It doesn't
-     replace the dynamic availability information from GGP or EGP.
-
-
-
-Mockapetris                                                    [Page 23]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.6. Defining new types, classes, and special namespaces
-
-The previously defined types and classes are the ones in use as of the
-date of this memo.  New definitions should be expected.  This section
-makes some recommendations to designers considering additions to the
-existing facilities.  The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
-forum where general discussion of design issues takes place.
-
-In general, a new type is appropriate when new information is to be
-added to the database about an existing object, or we need new data
-formats for some totally new object.  Designers should attempt to define
-types and their RDATA formats that are generally applicable to all
-classes, and which avoid duplication of information.  New classes are
-appropriate when the DNS is to be used for a new protocol, etc which
-requires new class-specific data formats, or when a copy of the existing
-name space is desired, but a separate management domain is necessary.
-
-New types and classes need mnemonics for master files; the format of the
-master files requires that the mnemonics for type and class be disjoint.
-
-TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
-respectively.
-
-The present system uses multiple RRs to represent multiple values of a
-type rather than storing multiple values in the RDATA section of a
-single RR.  This is less efficient for most applications, but does keep
-RRs shorter.  The multiple RRs assumption is incorporated in some
-experimental work on dynamic update methods.
-
-The present system attempts to minimize the duplication of data in the
-database in order to insure consistency.  Thus, in order to find the
-address of the host for a mail exchange, you map the mail domain name to
-a host name, then the host name to addresses, rather than a direct
-mapping to host address.  This approach is preferred because it avoids
-the opportunity for inconsistency.
-
-In defining a new type of data, multiple RR types should not be used to
-create an ordering between entries or express different formats for
-equivalent bindings, instead this information should be carried in the
-body of the RR and a single type used.  This policy avoids problems with
-caching multiple types and defining QTYPEs to match multiple types.
-
-For example, the original form of mail exchange binding used two RR
-types one to represent a "closer" exchange (MD) and one to represent a
-"less close" exchange (MF).  The difficulty is that the presence of one
-RR type in a cache doesn't convey any information about the other
-because the query which acquired the cached information might have used
-a QTYPE of MF, MD, or MAILA (which matched both).  The redesigned
-
-
-
-Mockapetris                                                    [Page 24]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-service used a single type (MX) with a "preference" value in the RDATA
-section which can order different RRs.  However, if any MX RRs are found
-in the cache, then all should be there.
-
-4. MESSAGES
-
-4.1. Format
-
-All communications inside of the domain protocol are carried in a single
-format called a message.  The top level format of message is divided
-into 5 sections (some of which are empty in certain cases) shown below:
-
-    +---------------------+
-    |        Header       |
-    +---------------------+
-    |       Question      | the question for the name server
-    +---------------------+
-    |        Answer       | RRs answering the question
-    +---------------------+
-    |      Authority      | RRs pointing toward an authority
-    +---------------------+
-    |      Additional     | RRs holding additional information
-    +---------------------+
-
-The header section is always present.  The header includes fields that
-specify which of the remaining sections are present, and also specify
-whether the message is a query or a response, a standard query or some
-other opcode, etc.
-
-The names of the sections after the header are derived from their use in
-standard queries.  The question section contains fields that describe a
-question to a name server.  These fields are a query type (QTYPE), a
-query class (QCLASS), and a query domain name (QNAME).  The last three
-sections have the same format: a possibly empty list of concatenated
-resource records (RRs).  The answer section contains RRs that answer the
-question; the authority section contains RRs that point toward an
-authoritative name server; the additional records section contains RRs
-which relate to the query, but are not strictly answers for the
-question.
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 25]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-4.1.1. Header section format
-
-The header contains the following fields:
-
-                                    1  1  1  1  1  1
-      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      ID                       |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    QDCOUNT                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    ANCOUNT                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    NSCOUNT                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    ARCOUNT                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ID              A 16 bit identifier assigned by the program that
-                generates any kind of query.  This identifier is copied
-                the corresponding reply and can be used by the requester
-                to match up replies to outstanding queries.
-
-QR              A one bit field that specifies whether this message is a
-                query (0), or a response (1).
-
-OPCODE          A four bit field that specifies kind of query in this
-                message.  This value is set by the originator of a query
-                and copied into the response.  The values are:
-
-                0               a standard query (QUERY)
-
-                1               an inverse query (IQUERY)
-
-                2               a server status request (STATUS)
-
-                3-15            reserved for future use
-
-AA              Authoritative Answer - this bit is valid in responses,
-                and specifies that the responding name server is an
-                authority for the domain name in question section.
-
-                Note that the contents of the answer section may have
-                multiple owner names because of aliases.  The AA bit
-
-
-
-Mockapetris                                                    [Page 26]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                corresponds to the name which matches the query name, or
-                the first owner name in the answer section.
-
-TC              TrunCation - specifies that this message was truncated
-                due to length greater than that permitted on the
-                transmission channel.
-
-RD              Recursion Desired - this bit may be set in a query and
-                is copied into the response.  If RD is set, it directs
-                the name server to pursue the query recursively.
-                Recursive query support is optional.
-
-RA              Recursion Available - this be is set or cleared in a
-                response, and denotes whether recursive query support is
-                available in the name server.
-
-Z               Reserved for future use.  Must be zero in all queries
-                and responses.
-
-RCODE           Response code - this 4 bit field is set as part of
-                responses.  The values have the following
-                interpretation:
-
-                0               No error condition
-
-                1               Format error - The name server was
-                                unable to interpret the query.
-
-                2               Server failure - The name server was
-                                unable to process this query due to a
-                                problem with the name server.
-
-                3               Name Error - Meaningful only for
-                                responses from an authoritative name
-                                server, this code signifies that the
-                                domain name referenced in the query does
-                                not exist.
-
-                4               Not Implemented - The name server does
-                                not support the requested kind of query.
-
-                5               Refused - The name server refuses to
-                                perform the specified operation for
-                                policy reasons.  For example, a name
-                                server may not wish to provide the
-                                information to the particular requester,
-                                or a name server may not wish to perform
-                                a particular operation (e.g., zone
-
-
-
-Mockapetris                                                    [Page 27]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                                transfer) for particular data.
-
-                6-15            Reserved for future use.
-
-QDCOUNT         an unsigned 16 bit integer specifying the number of
-                entries in the question section.
-
-ANCOUNT         an unsigned 16 bit integer specifying the number of
-                resource records in the answer section.
-
-NSCOUNT         an unsigned 16 bit integer specifying the number of name
-                server resource records in the authority records
-                section.
-
-ARCOUNT         an unsigned 16 bit integer specifying the number of
-                resource records in the additional records section.
-
-4.1.2. Question section format
-
-The question section is used to carry the "question" in most queries,
-i.e., the parameters that define what is being asked.  The section
-contains QDCOUNT (usually 1) entries, each of the following format:
-
-                                    1  1  1  1  1  1
-      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                                               |
-    /                     QNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     QTYPE                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     QCLASS                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-QNAME           a domain name represented as a sequence of labels, where
-                each label consists of a length octet followed by that
-                number of octets.  The domain name terminates with the
-                zero length octet for the null label of the root.  Note
-                that this field may be an odd number of octets; no
-                padding is used.
-
-QTYPE           a two octet code which specifies the type of the query.
-                The values for this field include all codes valid for a
-                TYPE field, together with some more general codes which
-                can match more than one type of RR.
-
-
-
-Mockapetris                                                    [Page 28]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-QCLASS          a two octet code that specifies the class of the query.
-                For example, the QCLASS field is IN for the Internet.
-
-4.1.3. Resource record format
-
-The answer, authority, and additional sections all share the same
-format: a variable number of resource records, where the number of
-records is specified in the corresponding count field in the header.
-Each resource record has the following format:
-                                    1  1  1  1  1  1
-      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                                               |
-    /                                               /
-    /                      NAME                     /
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      TYPE                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     CLASS                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      TTL                      |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                   RDLENGTH                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
-    /                     RDATA                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NAME            a domain name to which this resource record pertains.
-
-TYPE            two octets containing one of the RR type codes.  This
-                field specifies the meaning of the data in the RDATA
-                field.
-
-CLASS           two octets which specify the class of the data in the
-                RDATA field.
-
-TTL             a 32 bit unsigned integer that specifies the time
-                interval (in seconds) that the resource record may be
-                cached before it should be discarded.  Zero values are
-                interpreted to mean that the RR can only be used for the
-                transaction in progress, and should not be cached.
-
-
-
-
-
-Mockapetris                                                    [Page 29]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-RDLENGTH        an unsigned 16 bit integer that specifies the length in
-                octets of the RDATA field.
-
-RDATA           a variable length string of octets that describes the
-                resource.  The format of this information varies
-                according to the TYPE and CLASS of the resource record.
-                For example, the if the TYPE is A and the CLASS is IN,
-                the RDATA field is a 4 octet ARPA Internet address.
-
-4.1.4. Message compression
-
-In order to reduce the size of messages, the domain system utilizes a
-compression scheme which eliminates the repetition of domain names in a
-message.  In this scheme, an entire domain name or a list of labels at
-the end of a domain name is replaced with a pointer to a prior occurance
-of the same name.
-
-The pointer takes the form of a two octet sequence:
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    | 1  1|                OFFSET                   |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The first two bits are ones.  This allows a pointer to be distinguished
-from a label, since the label must begin with two zero bits because
-labels are restricted to 63 octets or less.  (The 10 and 01 combinations
-are reserved for future use.)  The OFFSET field specifies an offset from
-the start of the message (i.e., the first octet of the ID field in the
-domain header).  A zero offset specifies the first byte of the ID field,
-etc.
-
-The compression scheme allows a domain name in a message to be
-represented as either:
-
-   - a sequence of labels ending in a zero octet
-
-   - a pointer
-
-   - a sequence of labels ending with a pointer
-
-Pointers can only be used for occurances of a domain name where the
-format is not class specific.  If this were not the case, a name server
-or resolver would be required to know the format of all RRs it handled.
-As yet, there are no such cases, but they may occur in future RDATA
-formats.
-
-If a domain name is contained in a part of the message subject to a
-length field (such as the RDATA section of an RR), and compression is
-
-
-
-Mockapetris                                                    [Page 30]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-used, the length of the compressed name is used in the length
-calculation, rather than the length of the expanded name.
-
-Programs are free to avoid using pointers in messages they generate,
-although this will reduce datagram capacity, and may cause truncation.
-However all programs are required to understand arriving messages that
-contain pointers.
-
-For example, a datagram might need to use the domain names F.ISI.ARPA,
-FOO.F.ISI.ARPA, ARPA, and the root.  Ignoring the other fields of the
-message, these domain names might be represented as:
-
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    20 |           1           |           F           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    22 |           3           |           I           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    24 |           S           |           I           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    26 |           4           |           A           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    28 |           R           |           P           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    30 |           A           |           0           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    40 |           3           |           F           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    42 |           O           |           O           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    44 | 1  1|                20                       |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    64 | 1  1|                26                       |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    92 |           0           |                       |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The domain name for F.ISI.ARPA is shown at offset 20.  The domain name
-FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
-concatenate a label for FOO to the previously defined F.ISI.ARPA.  The
-domain name ARPA is defined at offset 64 using a pointer to the ARPA
-component of the name F.ISI.ARPA at 20; note that this pointer relies on
-ARPA being the last label in the string at 20.  The root domain name is
-
-
-
-Mockapetris                                                    [Page 31]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-defined by a single octet of zeros at 92; the root domain name has no
-labels.
-
-4.2. Transport
-
-The DNS assumes that messages will be transmitted as datagrams or in a
-byte stream carried by a virtual circuit.  While virtual circuits can be
-used for any DNS activity, datagrams are preferred for queries due to
-their lower overhead and better performance.  Zone refresh activities
-must use virtual circuits because of the need for reliable transfer.
-
-The Internet supports name server access using TCP [RFC-793] on server
-port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
-port 53 (decimal).
-
-4.2.1. UDP usage
-
-Messages sent using UDP user server port 53 (decimal).
-
-Messages carried by UDP are restricted to 512 bytes (not counting the IP
-or UDP headers).  Longer messages are truncated and the TC bit is set in
-the header.
-
-UDP is not acceptable for zone transfers, but is the recommended method
-for standard queries in the Internet.  Queries sent using UDP may be
-lost, and hence a retransmission strategy is required.  Queries or their
-responses may be reordered by the network, or by processing in name
-servers, so resolvers should not depend on them being returned in order.
-
-The optimal UDP retransmission policy will vary with performance of the
-Internet and the needs of the client, but the following are recommended:
-
-   - The client should try other servers and server addresses
-     before repeating a query to a specific address of a server.
-
-   - The retransmission interval should be based on prior
-     statistics if possible.  Too aggressive retransmission can
-     easily slow responses for the community at large.  Depending
-     on how well connected the client is to its expected servers,
-     the minimum retransmission interval should be 2-5 seconds.
-
-More suggestions on server selection and retransmission policy can be
-found in the resolver section of this memo.
-
-4.2.2. TCP usage
-
-Messages sent over TCP connections use server port 53 (decimal).  The
-message is prefixed with a two byte length field which gives the message
-
-
-
-Mockapetris                                                    [Page 32]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-length, excluding the two byte length field.  This length field allows
-the low-level processing to assemble a complete message before beginning
-to parse it.
-
-Several connection management policies are recommended:
-
-   - The server should not block other activities waiting for TCP
-     data.
-
-   - The server should support multiple connections.
-
-   - The server should assume that the client will initiate
-     connection closing, and should delay closing its end of the
-     connection until all outstanding client requests have been
-     satisfied.
-
-   - If the server needs to close a dormant connection to reclaim
-     resources, it should wait until the connection has been idle
-     for a period on the order of two minutes.  In particular, the
-     server should allow the SOA and AXFR request sequence (which
-     begins a refresh operation) to be made on a single connection.
-     Since the server would be unable to answer queries anyway, a
-     unilateral close or reset may be used instead of a graceful
-     close.
-
-5. MASTER FILES
-
-Master files are text files that contain RRs in text form.  Since the
-contents of a zone can be expressed in the form of a list of RRs a
-master file is most often used to define a zone, though it can be used
-to list a cache's contents.  Hence, this section first discusses the
-format of RRs in a master file, and then the special considerations when
-a master file is used to create a zone in some name server.
-
-5.1. Format
-
-The format of these files is a sequence of entries.  Entries are
-predominantly line-oriented, though parentheses can be used to continue
-a list of items across a line boundary, and text literals can contain
-CRLF within the text.  Any combination of tabs and spaces act as a
-delimiter between the separate items that make up an entry.  The end of
-any line in the master file can end with a comment.  The comment starts
-with a ";" (semicolon).
-
-The following entries are defined:
-
-    <blank>[<comment>]
-
-
-
-
-Mockapetris                                                    [Page 33]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-    $ORIGIN <domain-name> [<comment>]
-
-    $INCLUDE <file-name> [<domain-name>] [<comment>]
-
-    <domain-name><rr> [<comment>]
-
-    <blank><rr> [<comment>]
-
-Blank lines, with or without comments, are allowed anywhere in the file.
-
-Two control entries are defined: $ORIGIN and $INCLUDE.  $ORIGIN is
-followed by a domain name, and resets the current origin for relative
-domain names to the stated name.  $INCLUDE inserts the named file into
-the current file, and may optionally specify a domain name that sets the
-relative domain name origin for the included file.  $INCLUDE may also
-have a comment.  Note that a $INCLUDE entry never changes the relative
-origin of the parent file, regardless of changes to the relative origin
-made within the included file.
-
-The last two forms represent RRs.  If an entry for an RR begins with a
-blank, then the RR is assumed to be owned by the last stated owner.  If
-an RR entry begins with a <domain-name>, then the owner name is reset.
-
-<rr> contents take one of the following forms:
-
-    [<TTL>] [<class>] <type> <RDATA>
-
-    [<class>] [<TTL>] <type> <RDATA>
-
-The RR begins with optional TTL and class fields, followed by a type and
-RDATA field appropriate to the type and class.  Class and type use the
-standard mnemonics, TTL is a decimal integer.  Omitted class and TTL
-values are default to the last explicitly stated values.  Since type and
-class mnemonics are disjoint, the parse is unique.  (Note that this
-order is different from the order used in examples and the order used in
-the actual RRs; the given order allows easier parsing and defaulting.)
-
-<domain-name>s make up a large share of the data in the master file.
-The labels in the domain name are expressed as character strings and
-separated by dots.  Quoting conventions allow arbitrary characters to be
-stored in domain names.  Domain names that end in a dot are called
-absolute, and are taken as complete.  Domain names which do not end in a
-dot are called relative; the actual domain name is the concatenation of
-the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
-an argument to the master file loading routine.  A relative name is an
-error when no origin is available.
-
-
-
-
-
-Mockapetris                                                    [Page 34]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-<character-string> is expressed in one or two ways: as a contiguous set
-of characters without interior spaces, or as a string beginning with a "
-and ending with a ".  Inside a " delimited string any character can
-occur, except for a " itself, which must be quoted using \ (back slash).
-
-Because these files are text files several special encodings are
-necessary to allow arbitrary data to be loaded.  In particular:
-
-                of the root.
-
-@               A free standing @ is used to denote the current origin.
-
-\X              where X is any character other than a digit (0-9), is
-                used to quote that character so that its special meaning
-                does not apply.  For example, "\." can be used to place
-                a dot character in a label.
-
-\DDD            where each D is a digit is the octet corresponding to
-                the decimal number described by DDD.  The resulting
-                octet is assumed to be text and is not checked for
-                special meaning.
-
-( )             Parentheses are used to group data that crosses a line
-                boundary.  In effect, line terminations are not
-                recognized within parentheses.
-
-;               Semicolon is used to start a comment; the remainder of
-                the line is ignored.
-
-5.2. Use of master files to define zones
-
-When a master file is used to load a zone, the operation should be
-suppressed if any errors are encountered in the master file.  The
-rationale for this is that a single error can have widespread
-consequences.  For example, suppose that the RRs defining a delegation
-have syntax errors; then the server will return authoritative name
-errors for all names in the subzone (except in the case where the
-subzone is also present on the server).
-
-Several other validity checks that should be performed in addition to
-insuring that the file is syntactically correct:
-
-   1. All RRs in the file should have the same class.
-
-   2. Exactly one SOA RR should be present at the top of the zone.
-
-   3. If delegations are present and glue information is required,
-      it should be present.
-
-
-
-Mockapetris                                                    [Page 35]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-   4. Information present outside of the authoritative nodes in the
-      zone should be glue information, rather than the result of an
-      origin or similar error.
-
-5.3. Master file example
-
-The following is an example file which might be used to define the
-ISI.EDU zone.and is loaded with an origin of ISI.EDU:
-
-@   IN  SOA     VENERA      Action\.domains (
-                                 20     ; SERIAL
-                                 7200   ; REFRESH
-                                 600    ; RETRY
-                                 3600000; EXPIRE
-                                 60)    ; MINIMUM
-
-        NS      A.ISI.EDU.
-        NS      VENERA
-        NS      VAXA
-        MX      10      VENERA
-        MX      20      VAXA
-
-A       A       26.3.0.103
-
-VENERA  A       10.1.0.52
-        A       128.9.0.32
-
-VAXA    A       10.2.0.27
-        A       128.9.0.33
-
-
-$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
-
-Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
-
-    MOE     MB      A.ISI.EDU.
-    LARRY   MB      A.ISI.EDU.
-    CURLEY  MB      A.ISI.EDU.
-    STOOGES MG      MOE
-            MG      LARRY
-            MG      CURLEY
-
-Note the use of the \ character in the SOA RR to specify the responsible
-person mailbox "Action.domains@E.ISI.EDU".
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 36]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-6. NAME SERVER IMPLEMENTATION
-
-6.1. Architecture
-
-The optimal structure for the name server will depend on the host
-operating system and whether the name server is integrated with resolver
-operations, either by supporting recursive service, or by sharing its
-database with a resolver.  This section discusses implementation
-considerations for a name server which shares a database with a
-resolver, but most of these concerns are present in any name server.
-
-6.1.1. Control
-
-A name server must employ multiple concurrent activities, whether they
-are implemented as separate tasks in the host's OS or multiplexing
-inside a single name server program.  It is simply not acceptable for a
-name server to block the service of UDP requests while it waits for TCP
-data for refreshing or query activities.  Similarly, a name server
-should not attempt to provide recursive service without processing such
-requests in parallel, though it may choose to serialize requests from a
-single client, or to regard identical requests from the same client as
-duplicates.  A name server should not substantially delay requests while
-it reloads a zone from master files or while it incorporates a newly
-refreshed zone into its database.
-
-6.1.2. Database
-
-While name server implementations are free to use any internal data
-structures they choose, the suggested structure consists of three major
-parts:
-
-   - A "catalog" data structure which lists the zones available to
-     this server, and a "pointer" to the zone data structure.  The
-     main purpose of this structure is to find the nearest ancestor
-     zone, if any, for arriving standard queries.
-
-   - Separate data structures for each of the zones held by the
-     name server.
-
-   - A data structure for cached data. (or perhaps separate caches
-     for different classes)
-
-All of these data structures can be implemented an identical tree
-structure format, with different data chained off the nodes in different
-parts: in the catalog the data is pointers to zones, while in the zone
-and cache data structures, the data will be RRs.  In designing the tree
-framework the designer should recognize that query processing will need
-to traverse the tree using case-insensitive label comparisons; and that
-
-
-
-Mockapetris                                                    [Page 37]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-in real data, a few nodes have a very high branching factor (100-1000 or
-more), but the vast majority have a very low branching factor (0-1).
-
-One way to solve the case problem is to store the labels for each node
-in two pieces: a standardized-case representation of the label where all
-ASCII characters are in a single case, together with a bit mask that
-denotes which characters are actually of a different case.  The
-branching factor diversity can be handled using a simple linked list for
-a node until the branching factor exceeds some threshold, and
-transitioning to a hash structure after the threshold is exceeded.  In
-any case, hash structures used to store tree sections must insure that
-hash functions and procedures preserve the casing conventions of the
-DNS.
-
-The use of separate structures for the different parts of the database
-is motivated by several factors:
-
-   - The catalog structure can be an almost static structure that
-     need change only when the system administrator changes the
-     zones supported by the server.  This structure can also be
-     used to store parameters used to control refreshing
-     activities.
-
-   - The individual data structures for zones allow a zone to be
-     replaced simply by changing a pointer in the catalog.  Zone
-     refresh operations can build a new structure and, when
-     complete, splice it into the database via a simple pointer
-     replacement.  It is very important that when a zone is
-     refreshed, queries should not use old and new data
-     simultaneously.
-
-   - With the proper search procedures, authoritative data in zones
-     will always "hide", and hence take precedence over, cached
-     data.
-
-   - Errors in zone definitions that cause overlapping zones, etc.,
-     may cause erroneous responses to queries, but problem
-     determination is simplified, and the contents of one "bad"
-     zone can't corrupt another.
-
-   - Since the cache is most frequently updated, it is most
-     vulnerable to corruption during system restarts.  It can also
-     become full of expired RR data.  In either case, it can easily
-     be discarded without disturbing zone data.
-
-A major aspect of database design is selecting a structure which allows
-the name server to deal with crashes of the name server's host.  State
-information which a name server should save across system crashes
-
-
-
-Mockapetris                                                    [Page 38]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-includes the catalog structure (including the state of refreshing for
-each zone) and the zone data itself.
-
-6.1.3. Time
-
-Both the TTL data for RRs and the timing data for refreshing activities
-depends on 32 bit timers in units of seconds.  Inside the database,
-refresh timers and TTLs for cached data conceptually "count down", while
-data in the zone stays with constant TTLs.
-
-A recommended implementation strategy is to store time in two ways:  as
-a relative increment and as an absolute time.  One way to do this is to
-use positive 32 bit numbers for one type and negative numbers for the
-other.  The RRs in zones use relative times; the refresh timers and
-cache data use absolute times.  Absolute numbers are taken with respect
-to some known origin and converted to relative values when placed in the
-response to a query.  When an absolute TTL is negative after conversion
-to relative, then the data is expired and should be ignored.
-
-6.2. Standard query processing
-
-The major algorithm for standard query processing is presented in
-[RFC-1034].
-
-When processing queries with QCLASS=*, or some other QCLASS which
-matches multiple classes, the response should never be authoritative
-unless the server can guarantee that the response covers all classes.
-
-When composing a response, RRs which are to be inserted in the
-additional section, but duplicate RRs in the answer or authority
-sections, may be omitted from the additional section.
-
-When a response is so long that truncation is required, the truncation
-should start at the end of the response and work forward in the
-datagram.  Thus if there is any data for the authority section, the
-answer section is guaranteed to be unique.
-
-The MINIMUM value in the SOA should be used to set a floor on the TTL of
-data distributed from a zone.  This floor function should be done when
-the data is copied into a response.  This will allow future dynamic
-update protocols to change the SOA MINIMUM field without ambiguous
-semantics.
-
-6.3. Zone refresh and reload processing
-
-In spite of a server's best efforts, it may be unable to load zone data
-from a master file due to syntax errors, etc., or be unable to refresh a
-zone within the its expiration parameter.  In this case, the name server
-
-
-
-Mockapetris                                                    [Page 39]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-should answer queries as if it were not supposed to possess the zone.
-
-If a master is sending a zone out via AXFR, and a new version is created
-during the transfer, the master should continue to send the old version
-if possible.  In any case, it should never send part of one version and
-part of another.  If completion is not possible, the master should reset
-the connection on which the zone transfer is taking place.
-
-6.4. Inverse queries (Optional)
-
-Inverse queries are an optional part of the DNS.  Name servers are not
-required to support any form of inverse queries.  If a name server
-receives an inverse query that it does not support, it returns an error
-response with the "Not Implemented" error set in the header.  While
-inverse query support is optional, all name servers must be at least
-able to return the error response.
-
-6.4.1. The contents of inverse queries and responses          Inverse
-queries reverse the mappings performed by standard query operations;
-while a standard query maps a domain name to a resource, an inverse
-query maps a resource to a domain name.  For example, a standard query
-might bind a domain name to a host address; the corresponding inverse
-query binds the host address to a domain name.
-
-Inverse queries take the form of a single RR in the answer section of
-the message, with an empty question section.  The owner name of the
-query RR and its TTL are not significant.  The response carries
-questions in the question section which identify all names possessing
-the query RR WHICH THE NAME SERVER KNOWS.  Since no name server knows
-about all of the domain name space, the response can never be assumed to
-be complete.  Thus inverse queries are primarily useful for database
-management and debugging activities.  Inverse queries are NOT an
-acceptable method of mapping host addresses to host names; use the IN-
-ADDR.ARPA domain instead.
-
-Where possible, name servers should provide case-insensitive comparisons
-for inverse queries.  Thus an inverse query asking for an MX RR of
-"Venera.isi.edu" should get the same response as a query for
-"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
-produce the same result as an inverse query for "IBM-pc unix".  However,
-this cannot be guaranteed because name servers may possess RRs that
-contain character strings but the name server does not know that the
-data is character.
-
-When a name server processes an inverse query, it either returns:
-
-   1. zero, one, or multiple domain names for the specified
-      resource as QNAMEs in the question section
-
-
-
-Mockapetris                                                    [Page 40]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-   2. an error code indicating that the name server doesn't support
-      inverse mapping of the specified resource type.
-
-When the response to an inverse query contains one or more QNAMEs, the
-owner name and TTL of the RR in the answer section which defines the
-inverse query is modified to exactly match an RR found at the first
-QNAME.
-
-RRs returned in the inverse queries cannot be cached using the same
-mechanism as is used for the replies to standard queries.  One reason
-for this is that a name might have multiple RRs of the same type, and
-only one would appear.  For example, an inverse query for a single
-address of a multiply homed host might create the impression that only
-one address existed.
-
-6.4.2. Inverse query and response example          The overall structure
-of an inverse query for retrieving the domain name that corresponds to
-Internet address 10.1.0.52 is shown below:
-
-                         +-----------------------------------------+
-           Header        |          OPCODE=IQUERY, ID=997          |
-                         +-----------------------------------------+
-          Question       |                 <empty>                 |
-                         +-----------------------------------------+
-           Answer        |        <anyname> A IN 10.1.0.52         |
-                         +-----------------------------------------+
-          Authority      |                 <empty>                 |
-                         +-----------------------------------------+
-         Additional      |                 <empty>                 |
-                         +-----------------------------------------+
-
-This query asks for a question whose answer is the Internet style
-address 10.1.0.52.  Since the owner name is not known, any domain name
-can be used as a placeholder (and is ignored).  A single octet of zero,
-signifying the root, is usually used because it minimizes the length of
-the message.  The TTL of the RR is not significant.  The response to
-this query might be:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 41]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                         +-----------------------------------------+
-           Header        |         OPCODE=RESPONSE, ID=997         |
-                         +-----------------------------------------+
-          Question       |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
-                         +-----------------------------------------+
-           Answer        |  VENERA.ISI.EDU  A IN 10.1.0.52         |
-                         +-----------------------------------------+
-          Authority      |                 <empty>                 |
-                         +-----------------------------------------+
-         Additional      |                 <empty>                 |
-                         +-----------------------------------------+
-
-Note that the QTYPE in a response to an inverse query is the same as the
-TYPE field in the answer section of the inverse query.  Responses to
-inverse queries may contain multiple questions when the inverse is not
-unique.  If the question section in the response is not empty, then the
-RR in the answer section is modified to correspond to be an exact copy
-of an RR at the first QNAME.
-
-6.4.3. Inverse query processing
-
-Name servers that support inverse queries can support these operations
-through exhaustive searches of their databases, but this becomes
-impractical as the size of the database increases.  An alternative
-approach is to invert the database according to the search key.
-
-For name servers that support multiple zones and a large amount of data,
-the recommended approach is separate inversions for each zone.  When a
-particular zone is changed during a refresh, only its inversions need to
-be redone.
-
-Support for transfer of this type of inversion may be included in future
-versions of the domain system, but is not supported in this version.
-
-6.5. Completion queries and responses
-
-The optional completion services described in RFC-882 and RFC-883 have
-been deleted.  Redesigned services may become available in the future.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 42]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-7. RESOLVER IMPLEMENTATION
-
-The top levels of the recommended resolver algorithm are discussed in
-[RFC-1034].  This section discusses implementation details assuming the
-database structure suggested in the name server implementation section
-of this memo.
-
-7.1. Transforming a user request into a query
-
-The first step a resolver takes is to transform the client's request,
-stated in a format suitable to the local OS, into a search specification
-for RRs at a specific name which match a specific QTYPE and QCLASS.
-Where possible, the QTYPE and QCLASS should correspond to a single type
-and a single class, because this makes the use of cached data much
-simpler.  The reason for this is that the presence of data of one type
-in a cache doesn't confirm the existence or non-existence of data of
-other types, hence the only way to be sure is to consult an
-authoritative source.  If QCLASS=* is used, then authoritative answers
-won't be available.
-
-Since a resolver must be able to multiplex multiple requests if it is to
-perform its function efficiently, each pending request is usually
-represented in some block of state information.  This state block will
-typically contain:
-
-   - A timestamp indicating the time the request began.
-     The timestamp is used to decide whether RRs in the database
-     can be used or are out of date.  This timestamp uses the
-     absolute time format previously discussed for RR storage in
-     zones and caches.  Note that when an RRs TTL indicates a
-     relative time, the RR must be timely, since it is part of a
-     zone.  When the RR has an absolute time, it is part of a
-     cache, and the TTL of the RR is compared against the timestamp
-     for the start of the request.
-
-     Note that using the timestamp is superior to using a current
-     time, since it allows RRs with TTLs of zero to be entered in
-     the cache in the usual manner, but still used by the current
-     request, even after intervals of many seconds due to system
-     load, query retransmission timeouts, etc.
-
-   - Some sort of parameters to limit the amount of work which will
-     be performed for this request.
-
-     The amount of work which a resolver will do in response to a
-     client request must be limited to guard against errors in the
-     database, such as circular CNAME references, and operational
-     problems, such as network partition which prevents the
-
-
-
-Mockapetris                                                    [Page 43]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-     resolver from accessing the name servers it needs.  While
-     local limits on the number of times a resolver will retransmit
-     a particular query to a particular name server address are
-     essential, the resolver should have a global per-request
-     counter to limit work on a single request.  The counter should
-     be set to some initial value and decremented whenever the
-     resolver performs any action (retransmission timeout,
-     retransmission, etc.)  If the counter passes zero, the request
-     is terminated with a temporary error.
-
-     Note that if the resolver structure allows one request to
-     start others in parallel, such as when the need to access a
-     name server for one request causes a parallel resolve for the
-     name server's addresses, the spawned request should be started
-     with a lower counter.  This prevents circular references in
-     the database from starting a chain reaction of resolver
-     activity.
-
-   - The SLIST data structure discussed in [RFC-1034].
-
-     This structure keeps track of the state of a request if it
-     must wait for answers from foreign name servers.
-
-7.2. Sending the queries
-
-As described in [RFC-1034], the basic task of the resolver is to
-formulate a query which will answer the client's request and direct that
-query to name servers which can provide the information.  The resolver
-will usually only have very strong hints about which servers to ask, in
-the form of NS RRs, and may have to revise the query, in response to
-CNAMEs, or revise the set of name servers the resolver is asking, in
-response to delegation responses which point the resolver to name
-servers closer to the desired information.  In addition to the
-information requested by the client, the resolver may have to call upon
-its own services to determine the address of name servers it wishes to
-contact.
-
-In any case, the model used in this memo assumes that the resolver is
-multiplexing attention between multiple requests, some from the client,
-and some internally generated.  Each request is represented by some
-state information, and the desired behavior is that the resolver
-transmit queries to name servers in a way that maximizes the probability
-that the request is answered, minimizes the time that the request takes,
-and avoids excessive transmissions.  The key algorithm uses the state
-information of the request to select the next name server address to
-query, and also computes a timeout which will cause the next action
-should a response not arrive.  The next action will usually be a
-transmission to some other server, but may be a temporary error to the
-
-
-
-Mockapetris                                                    [Page 44]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-client.
-
-The resolver always starts with a list of server names to query (SLIST).
-This list will be all NS RRs which correspond to the nearest ancestor
-zone that the resolver knows about.  To avoid startup problems, the
-resolver should have a set of default servers which it will ask should
-it have no current NS RRs which are appropriate.  The resolver then adds
-to SLIST all of the known addresses for the name servers, and may start
-parallel requests to acquire the addresses of the servers when the
-resolver has the name, but no addresses, for the name servers.
-
-To complete initialization of SLIST, the resolver attaches whatever
-history information it has to the each address in SLIST.  This will
-usually consist of some sort of weighted averages for the response time
-of the address, and the batting average of the address (i.e., how often
-the address responded at all to the request).  Note that this
-information should be kept on a per address basis, rather than on a per
-name server basis, because the response time and batting average of a
-particular server may vary considerably from address to address.  Note
-also that this information is actually specific to a resolver address /
-server address pair, so a resolver with multiple addresses may wish to
-keep separate histories for each of its addresses.  Part of this step
-must deal with addresses which have no such history; in this case an
-expected round trip time of 5-10 seconds should be the worst case, with
-lower estimates for the same local network, etc.
-
-Note that whenever a delegation is followed, the resolver algorithm
-reinitializes SLIST.
-
-The information establishes a partial ranking of the available name
-server addresses.  Each time an address is chosen and the state should
-be altered to prevent its selection again until all other addresses have
-been tried.  The timeout for each transmission should be 50-100% greater
-than the average predicted value to allow for variance in response.
-
-Some fine points:
-
-   - The resolver may encounter a situation where no addresses are
-     available for any of the name servers named in SLIST, and
-     where the servers in the list are precisely those which would
-     normally be used to look up their own addresses.  This
-     situation typically occurs when the glue address RRs have a
-     smaller TTL than the NS RRs marking delegation, or when the
-     resolver caches the result of a NS search.  The resolver
-     should detect this condition and restart the search at the
-     next ancestor zone, or alternatively at the root.
-
-
-
-
-
-Mockapetris                                                    [Page 45]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-   - If a resolver gets a server error or other bizarre response
-     from a name server, it should remove it from SLIST, and may
-     wish to schedule an immediate transmission to the next
-     candidate server address.
-
-7.3. Processing responses
-
-The first step in processing arriving response datagrams is to parse the
-response.  This procedure should include:
-
-   - Check the header for reasonableness.  Discard datagrams which
-     are queries when responses are expected.
-
-   - Parse the sections of the message, and insure that all RRs are
-     correctly formatted.
-
-   - As an optional step, check the TTLs of arriving data looking
-     for RRs with excessively long TTLs.  If a RR has an
-     excessively long TTL, say greater than 1 week, either discard
-     the whole response, or limit all TTLs in the response to 1
-     week.
-
-The next step is to match the response to a current resolver request.
-The recommended strategy is to do a preliminary matching using the ID
-field in the domain header, and then to verify that the question section
-corresponds to the information currently desired.  This requires that
-the transmission algorithm devote several bits of the domain ID field to
-a request identifier of some sort.  This step has several fine points:
-
-   - Some name servers send their responses from different
-     addresses than the one used to receive the query.  That is, a
-     resolver cannot rely that a response will come from the same
-     address which it sent the corresponding query to.  This name
-     server bug is typically encountered in UNIX systems.
-
-   - If the resolver retransmits a particular request to a name
-     server it should be able to use a response from any of the
-     transmissions.  However, if it is using the response to sample
-     the round trip time to access the name server, it must be able
-     to determine which transmission matches the response (and keep
-     transmission times for each outgoing message), or only
-     calculate round trip times based on initial transmissions.
-
-   - A name server will occasionally not have a current copy of a
-     zone which it should have according to some NS RRs.  The
-     resolver should simply remove the name server from the current
-     SLIST, and continue.
-
-
-
-
-Mockapetris                                                    [Page 46]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-7.4. Using the cache
-
-In general, we expect a resolver to cache all data which it receives in
-responses since it may be useful in answering future client requests.
-However, there are several types of data which should not be cached:
-
-   - When several RRs of the same type are available for a
-     particular owner name, the resolver should either cache them
-     all or none at all.  When a response is truncated, and a
-     resolver doesn't know whether it has a complete set, it should
-     not cache a possibly partial set of RRs.
-
-   - Cached data should never be used in preference to
-     authoritative data, so if caching would cause this to happen
-     the data should not be cached.
-
-   - The results of an inverse query should not be cached.
-
-   - The results of standard queries where the QNAME contains "*"
-     labels if the data might be used to construct wildcards.  The
-     reason is that the cache does not necessarily contain existing
-     RRs or zone boundary information which is necessary to
-     restrict the application of the wildcard RRs.
-
-   - RR data in responses of dubious reliability.  When a resolver
-     receives unsolicited responses or RR data other than that
-     requested, it should discard it without caching it.  The basic
-     implication is that all sanity checks on a packet should be
-     performed before any of it is cached.
-
-In a similar vein, when a resolver has a set of RRs for some name in a
-response, and wants to cache the RRs, it should check its cache for
-already existing RRs.  Depending on the circumstances, either the data
-in the response or the cache is preferred, but the two should never be
-combined.  If the data in the response is from authoritative data in the
-answer section, it is always preferred.
-
-8. MAIL SUPPORT
-
-The domain system defines a standard for mapping mailboxes into domain
-names, and two methods for using the mailbox information to derive mail
-routing information.  The first method is called mail exchange binding
-and the other method is mailbox binding.  The mailbox encoding standard
-and mail exchange binding are part of the DNS official protocol, and are
-the recommended method for mail routing in the Internet.  Mailbox
-binding is an experimental feature which is still under development and
-subject to change.
-
-
-
-
-Mockapetris                                                    [Page 47]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-The mailbox encoding standard assumes a mailbox name of the form
-"<local-part>@<mail-domain>".  While the syntax allowed in each of these
-sections varies substantially between the various mail internets, the
-preferred syntax for the ARPA Internet is given in [RFC-822].
-
-The DNS encodes the <local-part> as a single label, and encodes the
-<mail-domain> as a domain name.  The single label from the <local-part>
-is prefaced to the domain name from <mail-domain> to form the domain
-name corresponding to the mailbox.  Thus the mailbox HOSTMASTER@SRI-
-NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA.  If the
-<local-part> contains dots or other special characters, its
-representation in a master file will require the use of backslash
-quoting to ensure that the domain name is properly encoded.  For
-example, the mailbox Action.domains@ISI.EDU would be represented as
-Action\.domains.ISI.EDU.
-
-8.1. Mail exchange binding
-
-Mail exchange binding uses the <mail-domain> part of a mailbox
-specification to determine where mail should be sent.  The <local-part>
-is not even consulted.  [RFC-974] specifies this method in detail, and
-should be consulted before attempting to use mail exchange support.
-
-One of the advantages of this method is that it decouples mail
-destination naming from the hosts used to support mail service, at the
-cost of another layer of indirection in the lookup function.  However,
-the addition layer should eliminate the need for complicated "%", "!",
-etc encodings in <local-part>.
-
-The essence of the method is that the <mail-domain> is used as a domain
-name to locate type MX RRs which list hosts willing to accept mail for
-<mail-domain>, together with preference values which rank the hosts
-according to an order specified by the administrators for <mail-domain>.
-
-In this memo, the <mail-domain> ISI.EDU is used in examples, together
-with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
-ISI.EDU.  If a mailer had a message for Mockapetris@ISI.EDU, it would
-route it by looking up MX RRs for ISI.EDU.  The MX RRs at ISI.EDU name
-VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
-addresses.
-
-8.2. Mailbox binding (Experimental)
-
-In mailbox binding, the mailer uses the entire mail destination
-specification to construct a domain name.  The encoded domain name for
-the mailbox is used as the QNAME field in a QTYPE=MAILB query.
-
-Several outcomes are possible for this query:
-
-
-
-Mockapetris                                                    [Page 48]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-   1. The query can return a name error indicating that the mailbox
-      does not exist as a domain name.
-
-      In the long term, this would indicate that the specified
-      mailbox doesn't exist.  However, until the use of mailbox
-      binding is universal, this error condition should be
-      interpreted to mean that the organization identified by the
-      global part does not support mailbox binding.  The
-      appropriate procedure is to revert to exchange binding at
-      this point.
-
-   2. The query can return a Mail Rename (MR) RR.
-
-      The MR RR carries new mailbox specification in its RDATA
-      field.  The mailer should replace the old mailbox with the
-      new one and retry the operation.
-
-   3. The query can return a MB RR.
-
-      The MB RR carries a domain name for a host in its RDATA
-      field.  The mailer should deliver the message to that host
-      via whatever protocol is applicable, e.g., b,SMTP.
-
-   4. The query can return one or more Mail Group (MG) RRs.
-
-      This condition means that the mailbox was actually a mailing
-      list or mail group, rather than a single mailbox.  Each MG RR
-      has a RDATA field that identifies a mailbox that is a member
-      of the group.  The mailer should deliver a copy of the
-      message to each member.
-
-   5. The query can return a MB RR as well as one or more MG RRs.
-
-      This condition means the the mailbox was actually a mailing
-      list.  The mailer can either deliver the message to the host
-      specified by the MB RR, which will in turn do the delivery to
-      all members, or the mailer can use the MG RRs to do the
-      expansion itself.
-
-In any of these cases, the response may include a Mail Information
-(MINFO) RR.  This RR is usually associated with a mail group, but is
-legal with a MB.  The MINFO RR identifies two mailboxes.  One of these
-identifies a responsible person for the original mailbox name.  This
-mailbox should be used for requests to be added to a mail group, etc.
-The second mailbox name in the MINFO RR identifies a mailbox that should
-receive error messages for mail failures.  This is particularly
-appropriate for mailing lists when errors in member names should be
-reported to a person other than the one who sends a message to the list.
-
-
-
-Mockapetris                                                    [Page 49]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-New fields may be added to this RR in the future.
-
-
-9. REFERENCES and BIBLIOGRAPHY
-
-[Dyer 87]       S. Dyer, F. Hsu, "Hesiod", Project Athena
-                Technical Plan - Name Service, April 1987, version 1.9.
-
-                Describes the fundamentals of the Hesiod name service.
-
-[IEN-116]       J. Postel, "Internet Name Server", IEN-116,
-                USC/Information Sciences Institute, August 1979.
-
-                A name service obsoleted by the Domain Name System, but
-                still in use.
-
-[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
-                Communications of the ACM, October 1986, volume 29, number
-                10.
-
-[RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
-                Information Center, SRI International, December 1977.
-
-[RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
-                USC/Information Sciences Institute, August 1980.
-
-[RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
-                USC/Information Sciences Institute, September 1981.
-
-[RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
-                September 1981.
-
-                Suggests introduction of a hierarchy in place of a flat
-                name space for the Internet.
-
-[RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
-                USC/Information Sciences Institute, February 1982.
-
-[RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
-                Internet Host Table Specification", RFC-810, Network
-                Information Center, SRI International, March 1982.
-
-                Obsolete.  See RFC-952.
-
-[RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
-                Server", RFC-811, Network Information Center, SRI
-                International, March 1982.
-
-
-
-
-Mockapetris                                                    [Page 50]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                Obsolete.  See RFC-953.
-
-[RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
-                Network Information Center, SRI International, March
-                1982.
-
-[RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
-                Internet User Applications", RFC-819, Network
-                Information Center, SRI International, August 1982.
-
-                Early thoughts on the design of the domain system.
-                Current implementation is completely different.
-
-[RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
-                USC/Information Sciences Institute, August 1980.
-
-[RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
-                RFC-830, Network Information Center, SRI International,
-                October 1982.
-
-                Early thoughts on the design of the domain system.
-                Current implementation is completely different.
-
-[RFC-882]       P. Mockapetris, "Domain names - Concepts and
-                Facilities," RFC-882, USC/Information Sciences
-                Institute, November 1983.
-
-                Superceeded by this memo.
-
-[RFC-883]       P. Mockapetris, "Domain names - Implementation and
-                Specification," RFC-883, USC/Information Sciences
-                Institute, November 1983.
-
-                Superceeded by this memo.
-
-[RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
-                RFC-920, USC/Information Sciences Institute,
-                October 1984.
-
-                Explains the naming scheme for top level domains.
-
-[RFC-952]       K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
-                Table Specification", RFC-952, SRI, October 1985.
-
-                Specifies the format of HOSTS.TXT, the host/address
-                table replaced by the DNS.
-
-
-
-
-
-Mockapetris                                                    [Page 51]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-[RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
-                RFC-953, SRI, October 1985.
-
-                This RFC contains the official specification of the
-                hostname server protocol, which is obsoleted by the DNS.
-                This TCP based protocol accesses information stored in
-                the RFC-952 format, and is used to obtain copies of the
-                host table.
-
-[RFC-973]       P. Mockapetris, "Domain System Changes and
-                Observations", RFC-973, USC/Information Sciences
-                Institute, January 1986.
-
-                Describes changes to RFC-882 and RFC-883 and reasons for
-                them.
-
-[RFC-974]       C. Partridge, "Mail routing and the domain system",
-                RFC-974, CSNET CIC BBN Labs, January 1986.
-
-                Describes the transition from HOSTS.TXT based mail
-                addressing to the more powerful MX system used with the
-                domain system.
-
-[RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
-                service on a TCP/UDP transport: Concepts and Methods",
-                RFC-1001, March 1987.
-
-                This RFC and RFC-1002 are a preliminary design for
-                NETBIOS on top of TCP/IP which proposes to base NetBIOS
-                name service on top of the DNS.
-
-[RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
-                service on a TCP/UDP transport: Detailed
-                Specifications", RFC-1002, March 1987.
-
-[RFC-1010]      J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
-                USC/Information Sciences Institute, May 1987.
-
-                Contains socket numbers and mnemonics for host names,
-                operating systems, etc.
-
-[RFC-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
-                November 1987.
-
-                Describes a plan for converting the MILNET to the DNS.
-
-[RFC-1032]      M. Stahl, "Establishing a Domain - Guidelines for
-                Administrators", RFC-1032, November 1987.
-
-
-
-Mockapetris                                                    [Page 52]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                Describes the registration policies used by the NIC to
-                administer the top level domains and delegate subzones.
-
-[RFC-1033]      M. Lottor, "Domain Administrators Operations Guide",
-                RFC-1033, November 1987.
-
-                A cookbook for domain administrators.
-
-[Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
-                Name Server", Computer Networks, vol 6, nr 3, July 1982.
-
-                Describes a name service for CSNET which is independent
-                from the DNS and DNS use in the CSNET.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 53]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-Index
-
-          *   13
-
-          ;   33, 35
-
-          <character-string>   35
-          <domain-name>   34
-
-          @   35
-
-          \   35
-
-          A   12
-
-          Byte order   8
-
-          CH   13
-          Character case   9
-          CLASS   11
-          CNAME   12
-          Completion   42
-          CS   13
-
-          Hesiod   13
-          HINFO   12
-          HS   13
-
-          IN   13
-          IN-ADDR.ARPA domain   22
-          Inverse queries   40
-
-          Mailbox names   47
-          MB   12
-          MD   12
-          MF   12
-          MG   12
-          MINFO   12
-          MINIMUM   20
-          MR   12
-          MX   12
-
-          NS   12
-          NULL   12
-
-          Port numbers   32
-          Primary server   5
-          PTR   12, 18
-
-
-
-Mockapetris                                                    [Page 54]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-          QCLASS   13
-          QTYPE   12
-
-          RDATA   12
-          RDLENGTH  11
-
-          Secondary server   5
-          SOA   12
-          Stub resolvers   7
-
-          TCP   32
-          TXT   12
-          TYPE   11
-
-          UDP   32
-
-          WKS   12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 55]
-
diff --git a/doc/rfc/rfc1101.txt b/doc/rfc/rfc1101.txt
deleted file mode 100644
index 66c9d8b8..00000000
--- a/doc/rfc/rfc1101.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     P. Mockapetris
-Request for Comments: 1101                                           ISI
-Updates: RFCs 1034, 1035                                      April 1989
-
-
-             DNS Encoding of Network Names and Other Types
-
-
-1. STATUS OF THIS MEMO
-
-   This RFC proposes two extensions to the Domain Name System:
-
-      - A specific method for entering and retrieving RRs which map
-        between network names and numbers.
-
-      - Ideas for a general method for describing mappings between
-        arbitrary identifiers and numbers.
-
-   The method for mapping between network names and addresses is a
-   proposed standard, the ideas for a general method are experimental.
-
-   This RFC assumes that the reader is familiar with the DNS [RFC 1034,
-   RFC 1035] and its use.  The data shown is for pedagogical use and
-   does not necessarily reflect the real Internet.
-
-   Distribution of this memo is unlimited.
-
-2. INTRODUCTION
-
-   The DNS is extensible and can be used for a virtually unlimited
-   number of data types, name spaces, etc.  New type definitions are
-   occasionally necessary as are revisions or deletions of old types
-   (e.g., MX replacement of MD and MF [RFC 974]), and changes described
-   in [RFC 973].  This RFC describes changes due to the general need to
-   map between identifiers and values, and a specific need for network
-   name support.
-
-   Users wish to be able to use the DNS to map between network names and
-   numbers.  This need is the only capability found in HOSTS.TXT which
-   is not available from the DNS.  In designing a method to do this,
-   there were two major areas of concern:
-
-      - Several tradeoffs involving control of network names, the
-        syntax of network names, backward compatibility, etc.
-
-      - A desire to create a method which would be sufficiently
-        general to set a good precedent for future mappings,
-        for example, between TCP-port names and numbers,
-
-
-
-Mockapetris                                                     [Page 1]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-        autonomous system names and numbers, X.500 Relative
-        Distinguished Names (RDNs) and their servers, or whatever.
-
-   It was impossible to reconcile these two areas of concern for network
-   names because of the desire to unify network number support within
-   existing IP address to host name support.  The existing support is
-   the IN-ADDR.ARPA section of the DNS name space.  As a result this RFC
-   describes one structure for network names which builds on the
-   existing support for host names, and another family of structures for
-   future yellow pages (YP) functions such as conversions between TCP-
-   port numbers and mnemonics.
-
-   Both structures are described in following sections.  Each structure
-   has a discussion of design issues and specific structure
-   recommendations.
-
-   We wish to avoid defining structures and methods which can work but
-   do not because of indifference or errors on the part of system
-   administrators when maintaining the database.  The WKS RR is an
-   example.  Thus, while we favor distribution as a general method, we
-   also recognize that centrally maintained tables (such as HOSTS.TXT)
-   are usually more consistent though less maintainable and timely.
-   Hence we recommend both specific methods for mapping network names,
-   addresses, and subnets, as well as an instance of the general method
-   for mapping between allocated network numbers and network names.
-   (Allocation is centrally performed by the SRI Network Information
-   Center, aka the NIC).
-
-3. NETWORK NAME ISSUES AND DISCUSSION
-
-   The issues involved in the design were the definition of network name
-   syntax, the mappings to be provided, and possible support for similar
-   functions at the subnet level.
-
-3.1. Network name syntax
-
-   The current syntax for network names, as defined by [RFC 952] is an
-   alphanumeric string of up to 24 characters, which begins with an
-   alpha, and may include "." and "-" except as first and last
-   characters.  This is the format which was also used for host names
-   before the DNS.  Upward compatibility with existing names might be a
-   goal of any new scheme.
-
-   However, the present syntax has been used to define a flat name
-   space, and hence would prohibit the same distributed name allocation
-   method used for host names.  There is some sentiment for allowing the
-   NIC to continue to allocate and regulate network names, much as it
-   allocates numbers, but the majority opinion favors local control of
-
-
-
-Mockapetris                                                     [Page 2]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   network names.  Although it would be possible to provide a flat space
-   or a name space in which, for example, the last label of a domain
-   name captured the old-style network name, any such approach would add
-   complexity to the method and create different rules for network names
-   and host names.
-
-   For these reasons, we assume that the syntax of network names will be
-   the same as the expanded syntax for host names permitted in [HR].
-   The new syntax expands the set of names to allow leading digits, so
-   long as the resulting representations do not conflict with IP
-   addresses in decimal octet form.  For example, 3Com.COM and 3M.COM
-   are now legal, although 26.0.0.73.COM is not.  See [HR] for details.
-
-   The price is that network names will get as complicated as host
-   names.  An administrator will be able to create network names in any
-   domain under his control, and also create network number to name
-   entries in IN-ADDR.ARPA domains under his control.  Thus, the name
-   for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa-
-   network.MIL., depending on the preferences of the owner.
-
-3.2. Mappings
-
-   The desired mappings, ranked by priority with most important first,
-   are:
-
-      - Mapping a IP address or network number to a network name.
-
-        This mapping is for use in debugging tools and status displays
-        of various sorts.  The conversion from IP address to network
-        number is well known for class A, B, and C IP addresses, and
-        involves a simple mask operation.  The needs of other classes
-        are not yet defined and are ignored for the rest of this RFC.
-
-      - Mapping a network name to a network address.
-
-        This facility is of less obvious application, but a
-        symmetrical mapping seems desirable.
-
-      - Mapping an organization to its network names and numbers.
-
-        This facility is useful because it may not always be possible
-        to guess the local choice for network names, but the
-        organization name is often well known.
-
-      - Similar mappings for subnets, even when nested.
-
-        The primary application is to be able to identify all of the
-        subnets involved in a particular IP address.  A secondary
-
-
-
-Mockapetris                                                     [Page 3]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-        requirement is to retrieve address mask information.
-
-3.3. Network address section of the name space
-
-   The network name syntax discussed above can provide domain names
-   which will contain mappings from network names to various quantities,
-   but we also need a section of the name space, organized by network
-   and subnet number to hold the inverse mappings.
-
-   The choices include:
-
-      - The same network number slots already assigned and delegated
-        in the IN-ADDR.ARPA section of the name space.
-
-        For example, 10.IN-ADDR.ARPA for class A net 10,
-        2.128.IN-ADDR.ARPA for class B net 128.2, etc.
-
-      - Host-zero addresses in the IN-ADDR.ARPA tree.  (A host field
-        of all zero in an IP address is prohibited because of
-        confusion related to broadcast addresses, et al.)
-
-        For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10,
-        0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc.  Like the
-        first scheme, it uses in-place name space delegations to
-        distribute control.
-
-        The main advantage of this scheme over the first is that it
-        allows convenient names for subnets as well as networks.  A
-        secondary advantage is that it uses names which are not in use
-        already, and hence it is possible to test whether an
-        organization has entered this information in its domain
-        database.
-
-      - Some new section of the name space.
-
-        While this option provides the most opportunities, it creates
-        a need to delegate a whole new name space.  Since the IP
-        address space is so closely related to the network number
-        space, most believe that the overhead of creating such a new
-        space is overwhelming and would lead to the WKS syndrome.  (As
-        of February, 1989, approximately 400 sections of the
-        IN-ADDR.ARPA tree are already delegated, usually at network
-        boundaries.)
-
-
-
-
-
-
-
-
-Mockapetris                                                     [Page 4]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-4. SPECIFICS FOR NETWORK NAME MAPPINGS
-
-   The proposed solution uses information stored at:
-
-      - Names in the IN-ADDR.ARPA tree that correspond to host-zero IP
-        addresses.  The same method is used for subnets in a nested
-        fashion.  For example, 0.0.0.10.IN-ADDR.ARPA. for net 10.
-
-        Two types of information are stored here: PTR RRs which point
-        to the network name in their data sections, and A RRs, which
-        are present if the network (or subnet) is subnetted further.
-        If a type A RR is present, then it has the address mask as its
-        data.  The general form is:
-
-        <reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>
-        <reversed-host-zero-number>.IN-ADDR.ARPA. A   <subnet-mask>
-
-        For example:
-
-        0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
-
-        or
-
-        0.0.2.128.IN-ADDR.ARPA. PTR     cmu-net.cmu.edu.
-                                A       255.255.255.0
-
-        In general, this information will be added to an existing
-        master file for some IN-ADDR.ARPA domain for each network
-        involved.  Similar RRs can be used at host-zero subnet
-        entries.
-
-      - Names which are network names.
-
-        The data stored here is PTR RRs pointing at the host-zero
-        entries.  The general form is:
-
-        <network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA
-
-        For example:
-
-        ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.
-
-        or
-
-        isi-net.isi.edu.        PTR     0.0.9.128.IN-ADDR.ARPA.
-
-        In general, this information will be inserted in the master
-        file for the domain name of the organization; this is a
-
-
-
-Mockapetris                                                     [Page 5]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-        different file from that which holds the information below
-        IN-ADDR.ARPA.  Similar PTR RRs can be used at subnet names.
-
-      - Names corresponding to organizations.
-
-        The data here is one or more PTR RRs pointing at the
-        IN-ADDR.ARPA names corresponding to host-zero entries for
-        networks.
-
-        For example:
-
-        ISI.EDU.        PTR     0.0.9.128.IN-ADDR.ARPA.
-
-        MCC.COM.        PTR     0.167.5.192.IN-ADDR.ARPA.
-                        PTR     0.168.5.192.IN-ADDR.ARPA.
-                        PTR     0.169.5.192.IN-ADDR.ARPA.
-                        PTR     0.0.62.128.IN-ADDR.ARPA.
-
-4.1. A simple example
-
-   The ARPANET is a Class A network without subnets.  The RRs which
-   would be added, assuming the ARPANET.ARPA was selected as a network
-   name, would be:
-
-   ARPA.                   PTR     0.0.0.10.IN-ADDR.ARPA.
-
-   ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.
-
-   0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
-
-   The first RR states that the organization named ARPA owns net 10 (It
-   might also own more network numbers, and these would be represented
-   with an additional RR per net.)  The second states that the network
-   name ARPANET.ARPA. maps to net 10.  The last states that net 10 is
-   named ARPANET.ARPA.
-
-   Note that all of the usual host and corresponding IN-ADDR.ARPA
-   entries would still be required.
-
-4.2. A complicated, subnetted example
-
-   The ISI network is 128.9, a class B number.  Suppose the ISI network
-   was organized into two levels of subnet, with the first level using
-   an additional 8 bits of address, and the second level using 4 bits,
-   for address masks of x'FFFFFF00' and X'FFFFFFF0'.
-
-   Then the following RRs would be entered in ISI's master file for the
-   ISI.EDU zone:
-
-
-
-Mockapetris                                                     [Page 6]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   ; Define network entry
-   isi-net.isi.edu.                PTR  0.0.9.128.IN-ADDR.ARPA.
-
-   ; Define first level subnets
-   div1-subnet.isi.edu.            PTR  0.1.9.128.IN-ADDR.ARPA.
-   div2-subnet.isi.edu.            PTR  0.2.9.128.IN-ADDR.ARPA.
-
-   ; Define second level subnets
-   inc-subsubnet.isi.edu.          PTR  16.2.9.128.IN-ADDR.ARPA.
-
-   in the 9.128.IN-ADDR.ARPA zone:
-
-   ; Define network number and address mask
-   0.0.9.128.IN-ADDR.ARPA.         PTR  isi-net.isi.edu.
-                                   A    255.255.255.0  ;aka X'FFFFFF00'
-
-   ; Define one of the first level subnet numbers and masks
-   0.1.9.128.IN-ADDR.ARPA.         PTR  div1-subnet.isi.edu.
-                                   A    255.255.255.240 ;aka X'FFFFFFF0'
-
-   ; Define another first level subnet number and mask
-   0.2.9.128.IN-ADDR.ARPA.         PTR  div2-subnet.isi.edu.
-                                   A    255.255.255.240 ;aka X'FFFFFFF0'
-
-   ; Define second level subnet number
-   16.2.9.128.IN-ADDR.ARPA.        PTR  inc-subsubnet.isi.edu.
-
-   This assumes that the ISI network is named isi-net.isi.edu., first
-   level subnets are named div1-subnet.isi.edu. and div2-
-   subnet.isi.edu., and a second level subnet is called inc-
-   subsubnet.isi.edu.  (In a real system as complicated as this there
-   would be more first and second level subnets defined, but we have
-   shown enough to illustrate the ideas.)
-
-4.3. Procedure for using an IP address to get network name
-
-   Depending on whether the IP address is class A, B, or C, mask off the
-   high one, two, or three bytes, respectively.  Reverse the octets,
-   suffix IN-ADDR.ARPA, and do a PTR query.
-
-   For example, suppose the IP address is 10.0.0.51.
-
-      1. Since this is a class A address, use a mask x'FF000000' and
-         get 10.0.0.0.
-
-      2. Construct the name 0.0.0.10.IN-ADDR.ARPA.
-
-      3. Do a PTR query.  Get back
-
-
-
-Mockapetris                                                     [Page 7]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-         0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
-
-      4. Conclude that the network name is "ARPANET.ARPA."
-
-   Suppose that the IP address is 128.9.2.17.
-
-      1. Since this is a class B address, use a mask of x'FFFF0000'
-         and get 128.9.0.0.
-
-      2. Construct the name 0.0.9.128.IN-ADDR.ARPA.
-
-      3. Do a PTR query.  Get back
-
-         0.0.9.128.IN-ADDR.ARPA.       PTR     isi-net.isi.edu
-
-      4. Conclude that the network name is "isi-net.isi.edu."
-
-4.4. Procedure for finding all subnets involved with an IP address
-
-   This is a simple extension of the IP address to network name method.
-   When the network entry is located, do a lookup for a possible A RR.
-   If the A RR is found, look up the next level of subnet using the
-   original IP address and the mask in the A RR.  Repeat this procedure
-   until no A RR is found.
-
-   For example, repeating the use of 128.9.2.17.
-
-      1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA.
-         Retrieve:
-
-         0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
-                                  A      255.255.255.0
-
-      2. Since an A RR was found, repeat using mask from RR
-         (255.255.255.0), constructing a query for
-         0.2.9.128.IN-ADDR.ARPA.  Retrieve:
-
-         0.2.9.128.IN-ADDR.ARPA.  PTR    div2-subnet.isi.edu.
-                                  A      255.255.255.240
-
-      3. Since another A RR was found, repeat using mask
-         255.255.255.240 (x'FFFFFFF0').  constructing a query for
-         16.2.9.128.IN-ADDR.ARPA.  Retrieve:
-
-         16.2.9.128.IN-ADDR.ARPA. PTR    inc-subsubnet.isi.edu.
-
-      4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there
-         are no more subnet levels.
-
-
-
-Mockapetris                                                     [Page 8]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-5. YP ISSUES AND DISCUSSION
-
-   The term "Yellow Pages" is used in almost as many ways as the term
-   "domain", so it is useful to define what is meant herein by YP.  The
-   general problem to be solved is to create a method for creating
-   mappings from one kind of identifier to another, often with an
-   inverse capability.  The traditional methods are to search or use a
-   precomputed index of some kind.
-
-   Searching is impractical when the search is too large, and
-   precomputed indexes are possible only when it is possible to specify
-   search criteria in advance, and pay for the resources necessary to
-   build the index.  For example, it is impractical to search the entire
-   domain tree to find a particular address RR, so we build the IN-
-   ADDR.ARPA YP.  Similarly, we could never build an Internet-wide index
-   of "hosts with a load average of less than 2" in less time than it
-   would take for the data to change, so indexes are a useless approach
-   for that problem.
-
-   Such a precomputed index is what we mean by YP, and we regard the
-   IN-ADDR.ARPA domain as the first instance of a YP in the DNS.
-   Although a single, centrally-managed YP for well-known values such as
-   TCP-port is desirable, we regard organization-specific YPs for, say,
-   locally defined TCP ports as a natural extension, as are combinations
-   of YPs using search lists to merge the two.
-
-   In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC
-   1010], it is clear that there are several mappings which might be of
-   value.  For example:
-
-   <assigned-network-name> <==> <IP-address>
-   <autonomous-system-id>  <==> <number>
-   <protocol-id>           <==> <number>
-   <port-id>               <==> <number>
-   <ethernet-type>         <==> <number>
-   <public-data-net>       <==> <IP-address>
-
-   Following the IN-ADDR example, the YP takes the form of a domain tree
-   organized to optimize retrieval by search key and distribution via
-   normal DNS rules.  The name used as a key must include:
-
-      1. A well known origin.  For example, IN-ADDR.ARPA is the
-         current IP-address to host name YP.
-
-      2. A "from" data type.  This identifies the input type of the
-         mapping.  This is necessary because we may be mapping
-         something as anonymous as a number to any number of
-         mnemonics, etc.
-
-
-
-Mockapetris                                                     [Page 9]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-      3. A "to" data type.  Since we assume several symmetrical
-         mnemonic <==> number mappings, this is also necessary.
-
-   This ordering reflects the natural scoping of control, and hence the
-   order of the components in a domain name.  Thus domain names would be
-   of the form:
-
-   <from-value>.<to-data-type>.<from-data-type>.<YP-origin>
-
-   To make this work, we need to define well-know strings for each of
-   these metavariables, as well as encoding rules for converting a
-   <from-value> into a domain name.  We might define:
-
-   <YP-origin>     :=YP
-   <from-data-type>:=TCP-port | IN-ADDR | Number |
-                     Assigned-network-number | Name
-   <to-data-type>  :=<from-data-type>
-
-   Note that "YP" is NOT a valid country code under [ISO 3166] (although
-   we may want to worry about the future), and the existence of a
-   syntactically valid <to-data-type>.<from-data-type> pair does not
-   imply that a meaningful mapping exists, or is even possible.
-
-   The encoding rules might be:
-
-   TCP-port        Six character alphanumeric
-
-   IN-ADDR         Reversed 4-octet decimal string
-
-   Number          decimal integer
-
-   Assigned-network-number
-                   Reversed 4-octet decimal string
-
-   Name            Domain name
-
-6. SPECIFICS FOR YP MAPPINGS
-
-6.1. TCP-PORT
-
-   $origin Number.TCP-port.YP.
-
-   23              PTR     TELNET.TCP-port.Number.YP.
-   25              PTR     SMTP.TCP-port.Number.YP.
-
-   $origin TCP-port.Number.YP.
-
-   TELNET          PTR     23.Number.TCP-port.YP.
-
-
-
-Mockapetris                                                    [Page 10]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   SMTP            PTR     25.Number.TCP-port.YP.
-
-   Thus the mapping between 23 and TELNET is represented by a pair of
-   PTR RRs, one for each direction of the mapping.
-
-6.2. Assigned networks
-
-   Network numbers are assigned by the NIC and reported in "Internet
-   Numbers" RFCs.  To create a YP, the NIC would set up two domains:
-
-   Name.Assigned-network-number.YP and Assigned-network-number.YP
-
-   The first would contain entries of the form:
-
-   $origin Name.Assigned-network-number.YP.
-
-   0.0.0.4         PTR     SATNET.Assigned-network-number.Name.YP.
-   0.0.0.10        PTR     ARPANET.Assigned-network-number.Name.YP.
-
-   The second would contain entries of the form:
-
-   $origin Assigned-network-number.Name.YP.
-
-   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
-   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.
-
-   These YPs are not in conflict with the network name support described
-   in the first half of this RFC since they map between ASSIGNED network
-   names and numbers, not those allocated by the organizations
-   themselves.  That is, they document the NIC's decisions about
-   allocating network numbers but do not automatically track any
-   renaming performed by the new owners.
-
-   As a practical matter, we might want to create both of these domains
-   to enable users on the Internet to experiment with centrally
-   maintained support as well as the distributed version, or might want
-   to implement only the allocated number to name mapping and request
-   organizations to convert their allocated network names to the network
-   names described in the distributed model.
-
-6.3. Operational improvements
-
-   We could imagine that all conversion routines using these YPs might
-   be instructed to use "YP.<local-domain>" followed by "YP."  as a
-   search list.  Thus, if the organization ISI.EDU wished to define
-   locally meaningful TCP-PORT, it would define the domains:
-
-   <TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>.
-
-
-
-Mockapetris                                                    [Page 11]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   We could add another level of indirection in the YP lookup, defining
-   the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the
-   YP tree, rather than being the YP tree directly.  This would enable
-   entries of the form:
-
-   IN-ADDR.Netname.YP.   PTR     IN-ADDR.ARPA.
-
-   to splice in YPs from other origins or existing spaces.
-
-   Another possibility would be to shorten the RDATA section of the RRs
-   which map back and forth by deleting the origin.  This could be done
-   either by allowing the domain name in the RDATA portion to not
-   identify a real domain name, or by defining a new RR which used a
-   simple text string rather than a domain name.
-
-   Thus, we might replace
-
-   $origin Assigned-network-number.Name.YP.
-
-   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
-   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.
-
-   with
-
-   $origin Assigned-network-number.Name.YP.
-
-   SATNET.         PTR     0.0.0.4.
-   ARPANET.        PTR     0.0.0.10.
-
-   or
-
-   $origin Assigned-network-number.Name.YP.
-
-   SATNET.         PTT     "0.0.0.4"
-   ARPANET.        PTT     "0.0.0.10"
-
-   where PTT is a new type whose RDATA section is a text string.
-
-7. ACKNOWLEDGMENTS
-
-   Drew Perkins, Mark Lottor, and Rob Austein contributed several of the
-   ideas in this RFC.  Numerous contributions, criticisms, and
-   compromises were produced in the IETF Domain working group and the
-   NAMEDROPPERS mailing list.
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 12]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-8. REFERENCES
-
-   [HR]        Braden, B., editor, "Requirements for Internet Hosts",
-               RFC in preparation.
-
-   [ISO 3166]  ISO, "Codes for the Representation of Names of
-               Countries", 1981.
-
-   [RFC 882]   Mockapetris, P., "Domain names - Concepts and
-               Facilities", RFC 882, USC/Information Sciences Institute,
-               November 1983.
-
-               Superseded by RFC 1034.
-
-   [RFC 883]   Mockapetris, P.,"Domain names - Implementation and
-               Specification", RFC 883, USC/Information Sciences
-               Institute, November 1983.
-
-               Superceeded by RFC 1035.
-
-   [RFC 920]   Postel, J. and J. Reynolds, "Domain Requirements", RFC
-               920, October 1984.
-
-               Explains the naming scheme for top level domains.
-
-   [RFC 952]   Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet
-               Host Table Specification", RFC 952, SRI, October 1985.
-
-               Specifies the format of HOSTS.TXT, the host/address table
-               replaced by the DNS
-
-   [RFC 973]   Mockapetris, P., "Domain System Changes and
-               Observations", RFC 973, USC/Information Sciences
-               Institute, January 1986.
-
-               Describes changes to RFCs 882 and 883 and reasons for
-               them.
-
-   [RFC 974]   Partridge, C., "Mail routing and the domain system", RFC
-               974, CSNET CIC BBN Labs, January 1986.
-
-               Describes the transition from HOSTS.TXT based mail
-               addressing to the more powerful MX system used with the
-               domain system.
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 13]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   [RFC 997]   Reynolds, J., and J. Postel, "Internet Numbers", RFC 997,
-               USC/Information Sciences Institute, March 1987
-
-               Contains network numbers, autonomous system numbers, etc.
-
-   [RFC 1010]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC
-               1010, USC/Information Sciences Institute, May 1987
-
-               Contains socket numbers and mnemonics for host names,
-               operating systems, etc.
-
-
-   [RFC 1034]  Mockapetris, P., "Domain names - Concepts and
-               Facilities", RFC 1034, USC/Information Sciences
-               Institute, November 1987.
-
-               Introduction/overview of the DNS.
-
-   [RFC 1035]  Mockapetris, P., "Domain names - Implementation and
-               Specification", RFC 1035, USC/Information Sciences
-               Institute, November 1987.
-
-               DNS implementation instructions.
-
-Author's Address:
-
-   Paul Mockapetris
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA 90292
-
-   Phone: (213) 822-1511
-
-   Email: PVM@ISI.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 14]
-
\ No newline at end of file
diff --git a/doc/rfc/rfc1122.txt b/doc/rfc/rfc1122.txt
deleted file mode 100644
index c14f2e50..00000000
--- a/doc/rfc/rfc1122.txt
+++ /dev/null
@@ -1,6844 +0,0 @@
-
-
-
-
-
-
-Network Working Group                    Internet Engineering Task Force
-Request for Comments: 1122                             R. Braden, Editor
-                                                            October 1989
-
-
-        Requirements for Internet Hosts -- Communication Layers
-
-
-Status of This Memo
-
-   This RFC is an official specification for the Internet community.  It
-   incorporates by reference, amends, corrects, and supplements the
-   primary protocol standards documents relating to hosts.  Distribution
-   of this document is unlimited.
-
-Summary
-
-   This is one RFC of a pair that defines and discusses the requirements
-   for Internet host software.  This RFC covers the communications
-   protocol layers: link layer, IP layer, and transport layer; its
-   companion RFC-1123 covers the application and support protocols.
-
-
-
-                           Table of Contents
-
-
-
-
-   1.  INTRODUCTION ...............................................    5
-      1.1  The Internet Architecture ..............................    6
-         1.1.1  Internet Hosts ....................................    6
-         1.1.2  Architectural Assumptions .........................    7
-         1.1.3  Internet Protocol Suite ...........................    8
-         1.1.4  Embedded Gateway Code .............................   10
-      1.2  General Considerations .................................   12
-         1.2.1  Continuing Internet Evolution .....................   12
-         1.2.2  Robustness Principle ..............................   12
-         1.2.3  Error Logging .....................................   13
-         1.2.4  Configuration .....................................   14
-      1.3  Reading this Document ..................................   15
-         1.3.1  Organization ......................................   15
-         1.3.2  Requirements ......................................   16
-         1.3.3  Terminology .......................................   17
-      1.4  Acknowledgments ........................................   20
-
-   2. LINK LAYER ..................................................   21
-      2.1  INTRODUCTION ...........................................   21
-
-
-
-Internet Engineering Task Force                                 [Page 1]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-      2.2  PROTOCOL WALK-THROUGH ..................................   21
-      2.3  SPECIFIC ISSUES ........................................   21
-         2.3.1  Trailer Protocol Negotiation ......................   21
-         2.3.2  Address Resolution Protocol -- ARP ................   22
-            2.3.2.1  ARP Cache Validation .........................   22
-            2.3.2.2  ARP Packet Queue .............................   24
-         2.3.3  Ethernet and IEEE 802 Encapsulation ...............   24
-      2.4  LINK/INTERNET LAYER INTERFACE ..........................   25
-      2.5  LINK LAYER REQUIREMENTS SUMMARY ........................   26
-
-   3. INTERNET LAYER PROTOCOLS ....................................   27
-      3.1 INTRODUCTION ............................................   27
-      3.2  PROTOCOL WALK-THROUGH ..................................   29
-         3.2.1 Internet Protocol -- IP ............................   29
-            3.2.1.1  Version Number ...............................   29
-            3.2.1.2  Checksum .....................................   29
-            3.2.1.3  Addressing ...................................   29
-            3.2.1.4  Fragmentation and Reassembly .................   32
-            3.2.1.5  Identification ...............................   32
-            3.2.1.6  Type-of-Service ..............................   33
-            3.2.1.7  Time-to-Live .................................   34
-            3.2.1.8  Options ......................................   35
-         3.2.2 Internet Control Message Protocol -- ICMP ..........   38
-            3.2.2.1  Destination Unreachable ......................   39
-            3.2.2.2  Redirect .....................................   40
-            3.2.2.3  Source Quench ................................   41
-            3.2.2.4  Time Exceeded ................................   41
-            3.2.2.5  Parameter Problem ............................   42
-            3.2.2.6  Echo Request/Reply ...........................   42
-            3.2.2.7  Information Request/Reply ....................   43
-            3.2.2.8  Timestamp and Timestamp Reply ................   43
-            3.2.2.9  Address Mask Request/Reply ...................   45
-         3.2.3  Internet Group Management Protocol IGMP ...........   47
-      3.3  SPECIFIC ISSUES ........................................   47
-         3.3.1  Routing Outbound Datagrams ........................   47
-            3.3.1.1  Local/Remote Decision ........................   47
-            3.3.1.2  Gateway Selection ............................   48
-            3.3.1.3  Route Cache ..................................   49
-            3.3.1.4  Dead Gateway Detection .......................   51
-            3.3.1.5  New Gateway Selection ........................   55
-            3.3.1.6  Initialization ...............................   56
-         3.3.2  Reassembly ........................................   56
-         3.3.3  Fragmentation .....................................   58
-         3.3.4  Local Multihoming .................................   60
-            3.3.4.1  Introduction .................................   60
-            3.3.4.2  Multihoming Requirements .....................   61
-            3.3.4.3  Choosing a Source Address ....................   64
-         3.3.5  Source Route Forwarding ...........................   65
-
-
-
-Internet Engineering Task Force                                 [Page 2]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         3.3.6  Broadcasts ........................................   66
-         3.3.7  IP Multicasting ...................................   67
-         3.3.8  Error Reporting ...................................   69
-      3.4  INTERNET/TRANSPORT LAYER INTERFACE .....................   69
-      3.5  INTERNET LAYER REQUIREMENTS SUMMARY ....................   72
-
-   4. TRANSPORT PROTOCOLS .........................................   77
-      4.1  USER DATAGRAM PROTOCOL -- UDP ..........................   77
-         4.1.1  INTRODUCTION ......................................   77
-         4.1.2  PROTOCOL WALK-THROUGH .............................   77
-         4.1.3  SPECIFIC ISSUES ...................................   77
-            4.1.3.1  Ports ........................................   77
-            4.1.3.2  IP Options ...................................   77
-            4.1.3.3  ICMP Messages ................................   78
-            4.1.3.4  UDP Checksums ................................   78
-            4.1.3.5  UDP Multihoming ..............................   79
-            4.1.3.6  Invalid Addresses ............................   79
-         4.1.4  UDP/APPLICATION LAYER INTERFACE ...................   79
-         4.1.5  UDP REQUIREMENTS SUMMARY ..........................   80
-      4.2  TRANSMISSION CONTROL PROTOCOL -- TCP ...................   82
-         4.2.1  INTRODUCTION ......................................   82
-         4.2.2  PROTOCOL WALK-THROUGH .............................   82
-            4.2.2.1  Well-Known Ports .............................   82
-            4.2.2.2  Use of Push ..................................   82
-            4.2.2.3  Window Size ..................................   83
-            4.2.2.4  Urgent Pointer ...............................   84
-            4.2.2.5  TCP Options ..................................   85
-            4.2.2.6  Maximum Segment Size Option ..................   85
-            4.2.2.7  TCP Checksum .................................   86
-            4.2.2.8  TCP Connection State Diagram .................   86
-            4.2.2.9  Initial Sequence Number Selection ............   87
-            4.2.2.10  Simultaneous Open Attempts ..................   87
-            4.2.2.11  Recovery from Old Duplicate SYN .............   87
-            4.2.2.12  RST Segment .................................   87
-            4.2.2.13  Closing a Connection ........................   87
-            4.2.2.14  Data Communication ..........................   89
-            4.2.2.15  Retransmission Timeout ......................   90
-            4.2.2.16  Managing the Window .........................   91
-            4.2.2.17  Probing Zero Windows ........................   92
-            4.2.2.18  Passive OPEN Calls ..........................   92
-            4.2.2.19  Time to Live ................................   93
-            4.2.2.20  Event Processing ............................   93
-            4.2.2.21  Acknowledging Queued Segments ...............   94
-         4.2.3  SPECIFIC ISSUES ...................................   95
-            4.2.3.1  Retransmission Timeout Calculation ...........   95
-            4.2.3.2  When to Send an ACK Segment ..................   96
-            4.2.3.3  When to Send a Window Update .................   97
-            4.2.3.4  When to Send Data ............................   98
-
-
-
-Internet Engineering Task Force                                 [Page 3]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-            4.2.3.5  TCP Connection Failures ......................  100
-            4.2.3.6  TCP Keep-Alives ..............................  101
-            4.2.3.7  TCP Multihoming ..............................  103
-            4.2.3.8  IP Options ...................................  103
-            4.2.3.9  ICMP Messages ................................  103
-            4.2.3.10  Remote Address Validation ...................  104
-            4.2.3.11  TCP Traffic Patterns ........................  104
-            4.2.3.12  Efficiency ..................................  105
-         4.2.4  TCP/APPLICATION LAYER INTERFACE ...................  106
-            4.2.4.1  Asynchronous Reports .........................  106
-            4.2.4.2  Type-of-Service ..............................  107
-            4.2.4.3  Flush Call ...................................  107
-            4.2.4.4  Multihoming ..................................  108
-         4.2.5  TCP REQUIREMENT SUMMARY ...........................  108
-
-   5.  REFERENCES .................................................  112
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                 [Page 4]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-1.  INTRODUCTION
-
-   This document is one of a pair that defines and discusses the
-   requirements for host system implementations of the Internet protocol
-   suite.  This RFC covers the communication protocol layers:  link
-   layer, IP layer, and transport layer.  Its companion RFC,
-   "Requirements for Internet Hosts -- Application and Support"
-   [INTRO:1], covers the application layer protocols.  This document
-   should also be read in conjunction with "Requirements for Internet
-   Gateways" [INTRO:2].
-
-   These documents are intended to provide guidance for vendors,
-   implementors, and users of Internet communication software.  They
-   represent the consensus of a large body of technical experience and
-   wisdom, contributed by the members of the Internet research and
-   vendor communities.
-
-   This RFC enumerates standard protocols that a host connected to the
-   Internet must use, and it incorporates by reference the RFCs and
-   other documents describing the current specifications for these
-   protocols.  It corrects errors in the referenced documents and adds
-   additional discussion and guidance for an implementor.
-
-   For each protocol, this document also contains an explicit set of
-   requirements, recommendations, and options.  The reader must
-   understand that the list of requirements in this document is
-   incomplete by itself; the complete set of requirements for an
-   Internet host is primarily defined in the standard protocol
-   specification documents, with the corrections, amendments, and
-   supplements contained in this RFC.
-
-   A good-faith implementation of the protocols that was produced after
-   careful reading of the RFC's and with some interaction with the
-   Internet technical community, and that followed good communications
-   software engineering practices, should differ from the requirements
-   of this document in only minor ways.  Thus, in many cases, the
-   "requirements" in this RFC are already stated or implied in the
-   standard protocol documents, so that their inclusion here is, in a
-   sense, redundant.  However, they were included because some past
-   implementation has made the wrong choice, causing problems of
-   interoperability, performance, and/or robustness.
-
-   This document includes discussion and explanation of many of the
-   requirements and recommendations.  A simple list of requirements
-   would be dangerous, because:
-
-   o    Some required features are more important than others, and some
-        features are optional.
-
-
-
-Internet Engineering Task Force                                 [Page 5]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-   o    There may be valid reasons why particular vendor products that
-        are designed for restricted contexts might choose to use
-        different specifications.
-
-   However, the specifications of this document must be followed to meet
-   the general goal of arbitrary host interoperation across the
-   diversity and complexity of the Internet system.  Although most
-   current implementations fail to meet these requirements in various
-   ways, some minor and some major, this specification is the ideal
-   towards which we need to move.
-
-   These requirements are based on the current level of Internet
-   architecture.  This document will be updated as required to provide
-   additional clarifications or to include additional information in
-   those areas in which specifications are still evolving.
-
-   This introductory section begins with a brief overview of the
-   Internet architecture as it relates to hosts, and then gives some
-   general advice to host software vendors.  Finally, there is some
-   guidance on reading the rest of the document and some terminology.
-
-   1.1  The Internet Architecture
-
-      General background and discussion on the Internet architecture and
-      supporting protocol suite can be found in the DDN Protocol
-      Handbook [INTRO:3]; for background see for example [INTRO:9],
-      [INTRO:10], and [INTRO:11].  Reference [INTRO:5] describes the
-      procedure for obtaining Internet protocol documents, while
-      [INTRO:6] contains a list of the numbers assigned within Internet
-      protocols.
-
-      1.1.1  Internet Hosts
-
-         A host computer, or simply "host," is the ultimate consumer of
-         communication services.  A host generally executes application
-         programs on behalf of user(s), employing network and/or
-         Internet communication services in support of this function.
-         An Internet host corresponds to the concept of an "End-System"
-         used in the OSI protocol suite [INTRO:13].
-
-         An Internet communication system consists of interconnected
-         packet networks supporting communication among host computers
-         using the Internet protocols.  The networks are interconnected
-         using packet-switching computers called "gateways" or "IP
-         routers" by the Internet community, and "Intermediate Systems"
-         by the OSI world [INTRO:13].  The RFC "Requirements for
-         Internet Gateways" [INTRO:2] contains the official
-         specifications for Internet gateways.  That RFC together with
-
-
-
-Internet Engineering Task Force                                 [Page 6]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         the present document and its companion [INTRO:1] define the
-         rules for the current realization of the Internet architecture.
-
-         Internet hosts span a wide range of size, speed, and function.
-         They range in size from small microprocessors through
-         workstations to mainframes and supercomputers.  In function,
-         they range from single-purpose hosts (such as terminal servers)
-         to full-service hosts that support a variety of online network
-         services, typically including remote login, file transfer, and
-         electronic mail.
-
-         A host is generally said to be multihomed if it has more than
-         one interface to the same or to different networks.  See
-         Section 1.1.3 on "Terminology".
-
-      1.1.2  Architectural Assumptions
-
-         The current Internet architecture is based on a set of
-         assumptions about the communication system.  The assumptions
-         most relevant to hosts are as follows:
-
-         (a)  The Internet is a network of networks.
-
-              Each host is directly connected to some particular
-              network(s); its connection to the Internet is only
-              conceptual.  Two hosts on the same network communicate
-              with each other using the same set of protocols that they
-              would use to communicate with hosts on distant networks.
-
-         (b)  Gateways don't keep connection state information.
-
-              To improve robustness of the communication system,
-              gateways are designed to be stateless, forwarding each IP
-              datagram independently of other datagrams.  As a result,
-              redundant paths can be exploited to provide robust service
-              in spite of failures of intervening gateways and networks.
-
-              All state information required for end-to-end flow control
-              and reliability is implemented in the hosts, in the
-              transport layer or in application programs.  All
-              connection control information is thus co-located with the
-              end points of the communication, so it will be lost only
-              if an end point fails.
-
-         (c)  Routing complexity should be in the gateways.
-
-              Routing is a complex and difficult problem, and ought to
-              be performed by the gateways, not the hosts.  An important
-
-
-
-Internet Engineering Task Force                                 [Page 7]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-              objective is to insulate host software from changes caused
-              by the inevitable evolution of the Internet routing
-              architecture.
-
-         (d)  The System must tolerate wide network variation.
-
-              A basic objective of the Internet design is to tolerate a
-              wide range of network characteristics -- e.g., bandwidth,
-              delay, packet loss, packet reordering, and maximum packet
-              size.  Another objective is robustness against failure of
-              individual networks, gateways, and hosts, using whatever
-              bandwidth is still available.  Finally, the goal is full
-              "open system interconnection": an Internet host must be
-              able to interoperate robustly and effectively with any
-              other Internet host, across diverse Internet paths.
-
-              Sometimes host implementors have designed for less
-              ambitious goals.  For example, the LAN environment is
-              typically much more benign than the Internet as a whole;
-              LANs have low packet loss and delay and do not reorder
-              packets.  Some vendors have fielded host implementations
-              that are adequate for a simple LAN environment, but work
-              badly for general interoperation.  The vendor justifies
-              such a product as being economical within the restricted
-              LAN market.  However, isolated LANs seldom stay isolated
-              for long; they are soon gatewayed to each other, to
-              organization-wide internets, and eventually to the global
-              Internet system.  In the end, neither the customer nor the
-              vendor is served by incomplete or substandard Internet
-              host software.
-
-              The requirements spelled out in this document are designed
-              for a full-function Internet host, capable of full
-              interoperation over an arbitrary Internet path.
-
-
-      1.1.3  Internet Protocol Suite
-
-         To communicate using the Internet system, a host must implement
-         the layered set of protocols comprising the Internet protocol
-         suite.  A host typically must implement at least one protocol
-         from each layer.
-
-         The protocol layers used in the Internet architecture are as
-         follows [INTRO:4]:
-
-
-         o  Application Layer
-
-
-
-Internet Engineering Task Force                                 [Page 8]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-              The application layer is the top layer of the Internet
-              protocol suite.  The Internet suite does not further
-              subdivide the application layer, although some of the
-              Internet application layer protocols do contain some
-              internal sub-layering.  The application layer of the
-              Internet suite essentially combines the functions of the
-              top two layers -- Presentation and Application -- of the
-              OSI reference model.
-
-              We distinguish two categories of application layer
-              protocols:  user protocols that provide service directly
-              to users, and support protocols that provide common system
-              functions.  Requirements for user and support protocols
-              will be found in the companion RFC [INTRO:1].
-
-              The most common Internet user protocols are:
-
-                o  Telnet (remote login)
-                o  FTP    (file transfer)
-                o  SMTP   (electronic mail delivery)
-
-              There are a number of other standardized user protocols
-              [INTRO:4] and many private user protocols.
-
-              Support protocols, used for host name mapping, booting,
-              and management, include SNMP, BOOTP, RARP, and the Domain
-              Name System (DNS) protocols.
-
-
-         o  Transport Layer
-
-              The transport layer provides end-to-end communication
-              services for applications.  There are two primary
-              transport layer protocols at present:
-
-                o Transmission Control Protocol (TCP)
-                o User Datagram Protocol (UDP)
-
-              TCP is a reliable connection-oriented transport service
-              that provides end-to-end reliability, resequencing, and
-              flow control.  UDP is a connectionless ("datagram")
-              transport service.
-
-              Other transport protocols have been developed by the
-              research community, and the set of official Internet
-              transport protocols may be expanded in the future.
-
-              Transport layer protocols are discussed in Chapter 4.
-
-
-
-Internet Engineering Task Force                                 [Page 9]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         o  Internet Layer
-
-              All Internet transport protocols use the Internet Protocol
-              (IP) to carry data from source host to destination host.
-              IP is a connectionless or datagram internetwork service,
-              providing no end-to-end delivery guarantees. Thus, IP
-              datagrams may arrive at the destination host damaged,
-              duplicated, out of order, or not at all.  The layers above
-              IP are responsible for reliable delivery service when it
-              is required.  The IP protocol includes provision for
-              addressing, type-of-service specification, fragmentation
-              and reassembly, and security information.
-
-              The datagram or connectionless nature of the IP protocol
-              is a fundamental and characteristic feature of the
-              Internet architecture.  Internet IP was the model for the
-              OSI Connectionless Network Protocol [INTRO:12].
-
-              ICMP is a control protocol that is considered to be an
-              integral part of IP, although it is architecturally
-              layered upon IP, i.e., it uses IP to carry its data end-
-              to-end just as a transport protocol like TCP or UDP does.
-              ICMP provides error reporting, congestion reporting, and
-              first-hop gateway redirection.
-
-              IGMP is an Internet layer protocol used for establishing
-              dynamic host groups for IP multicasting.
-
-              The Internet layer protocols IP, ICMP, and IGMP are
-              discussed in Chapter 3.
-
-
-         o  Link Layer
-
-              To communicate on its directly-connected network, a host
-              must implement the communication protocol used to
-              interface to that network.  We call this a link layer or
-              media-access layer protocol.
-
-              There is a wide variety of link layer protocols,
-              corresponding to the many different types of networks.
-              See Chapter 2.
-
-
-      1.1.4  Embedded Gateway Code
-
-         Some Internet host software includes embedded gateway
-         functionality, so that these hosts can forward packets as a
-
-
-
-Internet Engineering Task Force                                [Page 10]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         gateway would, while still performing the application layer
-         functions of a host.
-
-         Such dual-purpose systems must follow the Gateway Requirements
-         RFC [INTRO:2]  with respect to their gateway functions, and
-         must follow the present document with respect to their host
-         functions.  In all overlapping cases, the two specifications
-         should be in agreement.
-
-         There are varying opinions in the Internet community about
-         embedded gateway functionality.  The main arguments are as
-         follows:
-
-         o    Pro: in a local network environment where networking is
-              informal, or in isolated internets, it may be convenient
-              and economical to use existing host systems as gateways.
-
-              There is also an architectural argument for embedded
-              gateway functionality: multihoming is much more common
-              than originally foreseen, and multihoming forces a host to
-              make routing decisions as if it were a gateway.  If the
-              multihomed  host contains an embedded gateway, it will
-              have full routing knowledge and as a result will be able
-              to make more optimal routing decisions.
-
-         o    Con: Gateway algorithms and protocols are still changing,
-              and they will continue to change as the Internet system
-              grows larger.  Attempting to include a general gateway
-              function within the host IP layer will force host system
-              maintainers to track these (more frequent) changes.  Also,
-              a larger pool of gateway implementations will make
-              coordinating the changes more difficult.  Finally, the
-              complexity of a gateway IP layer is somewhat greater than
-              that of a host, making the implementation and operation
-              tasks more complex.
-
-              In addition, the style of operation of some hosts is not
-              appropriate for providing stable and robust gateway
-              service.
-
-         There is considerable merit in both of these viewpoints.  One
-         conclusion can be drawn: an host administrator must have
-         conscious control over whether or not a given host acts as a
-         gateway.  See Section 3.1 for the detailed requirements.
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 11]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-   1.2  General Considerations
-
-      There are two important lessons that vendors of Internet host
-      software have learned and which a new vendor should consider
-      seriously.
-
-      1.2.1  Continuing Internet Evolution
-
-         The enormous growth of the Internet has revealed problems of
-         management and scaling in a large datagram-based packet
-         communication system.  These problems are being addressed, and
-         as a result there will be continuing evolution of the
-         specifications described in this document.  These changes will
-         be carefully planned and controlled, since there is extensive
-         participation in this planning by the vendors and by the
-         organizations responsible for operations of the networks.
-
-         Development, evolution, and revision are characteristic of
-         computer network protocols today, and this situation will
-         persist for some years.  A vendor who develops computer
-         communication software for the Internet protocol suite (or any
-         other protocol suite!) and then fails to maintain and update
-         that software for changing specifications is going to leave a
-         trail of unhappy customers.  The Internet is a large
-         communication network, and the users are in constant contact
-         through it.  Experience has shown that knowledge of
-         deficiencies in vendor software propagates quickly through the
-         Internet technical community.
-
-      1.2.2  Robustness Principle
-
-         At every layer of the protocols, there is a general rule whose
-         application can lead to enormous benefits in robustness and
-         interoperability [IP:1]:
-
-                "Be liberal in what you accept, and
-                 conservative in what you send"
-
-         Software should be written to deal with every conceivable
-         error, no matter how unlikely; sooner or later a packet will
-         come in with that particular combination of errors and
-         attributes, and unless the software is prepared, chaos can
-         ensue.  In general, it is best to assume that the network is
-         filled with malevolent entities that will send in packets
-         designed to have the worst possible effect.  This assumption
-         will lead to suitable protective design, although the most
-         serious problems in the Internet have been caused by
-         unenvisaged mechanisms triggered by low-probability events;
-
-
-
-Internet Engineering Task Force                                [Page 12]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         mere human malice would never have taken so devious a course!
-
-         Adaptability to change must be designed into all levels of
-         Internet host software.  As a simple example, consider a
-         protocol specification that contains an enumeration of values
-         for a particular header field -- e.g., a type field, a port
-         number, or an error code; this enumeration must be assumed to
-         be incomplete.  Thus, if a protocol specification defines four
-         possible error codes, the software must not break when a fifth
-         code shows up.  An undefined code might be logged (see below),
-         but it must not cause a failure.
-
-         The second part of the principle is almost as important:
-         software on other hosts may contain deficiencies that make it
-         unwise to exploit legal but obscure protocol features.  It is
-         unwise to stray far from the obvious and simple, lest untoward
-         effects result elsewhere.  A corollary of this is "watch out
-         for misbehaving hosts"; host software should be prepared, not
-         just to survive other misbehaving hosts, but also to cooperate
-         to limit the amount of disruption such hosts can cause to the
-         shared communication facility.
-
-      1.2.3  Error Logging
-
-         The Internet includes a great variety of host and gateway
-         systems, each implementing many protocols and protocol layers,
-         and some of these contain bugs and mis-features in their
-         Internet protocol software.  As a result of complexity,
-         diversity, and distribution of function, the diagnosis of
-         Internet problems is often very difficult.
-
-         Problem diagnosis will be aided if host implementations include
-         a carefully designed facility for logging erroneous or
-         "strange" protocol events.  It is important to include as much
-         diagnostic information as possible when an error is logged.  In
-         particular, it is often useful to record the header(s) of a
-         packet that caused an error.  However, care must be taken to
-         ensure that error logging does not consume prohibitive amounts
-         of resources or otherwise interfere with the operation of the
-         host.
-
-         There is a tendency for abnormal but harmless protocol events
-         to overflow error logging files; this can be avoided by using a
-         "circular" log, or by enabling logging only while diagnosing a
-         known failure.  It may be useful to filter and count duplicate
-         successive messages.  One strategy that seems to work well is:
-         (1) always count abnormalities and make such counts accessible
-         through the management protocol (see [INTRO:1]); and (2) allow
-
-
-
-Internet Engineering Task Force                                [Page 13]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         the logging of a great variety of events to be selectively
-         enabled.  For example, it might useful to be able to "log
-         everything" or to "log everything for host X".
-
-         Note that different managements may have differing policies
-         about the amount of error logging that they want normally
-         enabled in a host.  Some will say, "if it doesn't hurt me, I
-         don't want to know about it", while others will want to take a
-         more watchful and aggressive attitude about detecting and
-         removing protocol abnormalities.
-
-      1.2.4  Configuration
-
-         It would be ideal if a host implementation of the Internet
-         protocol suite could be entirely self-configuring.  This would
-         allow the whole suite to be implemented in ROM or cast into
-         silicon, it would simplify diskless workstations, and it would
-         be an immense boon to harried LAN administrators as well as
-         system vendors.  We have not reached this ideal; in fact, we
-         are not even close.
-
-         At many points in this document, you will find a requirement
-         that a parameter be a configurable option.  There are several
-         different reasons behind such requirements.  In a few cases,
-         there is current uncertainty or disagreement about the best
-         value, and it may be necessary to update the recommended value
-         in the future.  In other cases, the value really depends on
-         external factors -- e.g., the size of the host and the
-         distribution of its communication load, or the speeds and
-         topology of nearby networks -- and self-tuning algorithms are
-         unavailable and may be insufficient.  In some cases,
-         configurability is needed because of administrative
-         requirements.
-
-         Finally, some configuration options are required to communicate
-         with obsolete or incorrect implementations of the protocols,
-         distributed without sources, that unfortunately persist in many
-         parts of the Internet.  To make correct systems coexist with
-         these faulty systems, administrators often have to "mis-
-         configure" the correct systems.  This problem will correct
-         itself gradually as the faulty systems are retired, but it
-         cannot be ignored by vendors.
-
-         When we say that a parameter must be configurable, we do not
-         intend to require that its value be explicitly read from a
-         configuration file at every boot time.  We recommend that
-         implementors set up a default for each parameter, so a
-         configuration file is only necessary to override those defaults
-
-
-
-Internet Engineering Task Force                                [Page 14]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         that are inappropriate in a particular installation.  Thus, the
-         configurability requirement is an assurance that it will be
-         POSSIBLE to override the default when necessary, even in a
-         binary-only or ROM-based product.
-
-         This document requires a particular value for such defaults in
-         some cases.  The choice of default is a sensitive issue when
-         the configuration item controls the accommodation to existing
-         faulty systems.  If the Internet is to converge successfully to
-         complete interoperability, the default values built into
-         implementations must implement the official protocol, not
-         "mis-configurations" to accommodate faulty implementations.
-         Although marketing considerations have led some vendors to
-         choose mis-configuration defaults, we urge vendors to choose
-         defaults that will conform to the standard.
-
-         Finally, we note that a vendor needs to provide adequate
-         documentation on all configuration parameters, their limits and
-         effects.
-
-
-   1.3  Reading this Document
-
-      1.3.1  Organization
-
-         Protocol layering, which is generally used as an organizing
-         principle in implementing network software, has also been used
-         to organize this document.  In describing the rules, we assume
-         that an implementation does strictly mirror the layering of the
-         protocols.  Thus, the following three major sections specify
-         the requirements for the link layer, the internet layer, and
-         the transport layer, respectively.  A companion RFC [INTRO:1]
-         covers application level software.  This layerist organization
-         was chosen for simplicity and clarity.
-
-         However, strict layering is an imperfect model, both for the
-         protocol suite and for recommended implementation approaches.
-         Protocols in different layers interact in complex and sometimes
-         subtle ways, and particular functions often involve multiple
-         layers.  There are many design choices in an implementation,
-         many of which involve creative "breaking" of strict layering.
-         Every implementor is urged to read references [INTRO:7] and
-         [INTRO:8].
-
-         This document describes the conceptual service interface
-         between layers using a functional ("procedure call") notation,
-         like that used in the TCP specification [TCP:1].  A host
-         implementation must support the logical information flow
-
-
-
-Internet Engineering Task Force                                [Page 15]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         implied by these calls, but need not literally implement the
-         calls themselves.  For example, many implementations reflect
-         the coupling between the transport layer and the IP layer by
-         giving them shared access to common data structures.  These
-         data structures, rather than explicit procedure calls, are then
-         the agency for passing much of the information that is
-         required.
-
-         In general, each major section of this document is organized
-         into the following subsections:
-
-         (1)  Introduction
-
-         (2)  Protocol Walk-Through -- considers the protocol
-              specification documents section-by-section, correcting
-              errors, stating requirements that may be ambiguous or
-              ill-defined, and providing further clarification or
-              explanation.
-
-         (3)  Specific Issues -- discusses protocol design and
-              implementation issues that were not included in the walk-
-              through.
-
-         (4)  Interfaces -- discusses the service interface to the next
-              higher layer.
-
-         (5)  Summary -- contains a summary of the requirements of the
-              section.
-
-
-         Under many of the individual topics in this document, there is
-         parenthetical material labeled "DISCUSSION" or
-         "IMPLEMENTATION". This material is intended to give
-         clarification and explanation of the preceding requirements
-         text.  It also includes some suggestions on possible future
-         directions or developments.  The implementation material
-         contains suggested approaches that an implementor may want to
-         consider.
-
-         The summary sections are intended to be guides and indexes to
-         the text, but are necessarily cryptic and incomplete.  The
-         summaries should never be used or referenced separately from
-         the complete RFC.
-
-      1.3.2  Requirements
-
-         In this document, the words that are used to define the
-         significance of each particular requirement are capitalized.
-
-
-
-Internet Engineering Task Force                                [Page 16]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         These words are:
-
-         *    "MUST"
-
-              This word or the adjective "REQUIRED" means that the item
-              is an absolute requirement of the specification.
-
-         *    "SHOULD"
-
-              This word or the adjective "RECOMMENDED" means that there
-              may exist valid reasons in particular circumstances to
-              ignore this item, but the full implications should be
-              understood and the case carefully weighed before choosing
-              a different course.
-
-         *    "MAY"
-
-              This word or the adjective "OPTIONAL" means that this item
-              is truly optional.  One vendor may choose to include the
-              item because a particular marketplace requires it or
-              because it enhances the product, for example; another
-              vendor may omit the same item.
-
-
-         An implementation is not compliant if it fails to satisfy one
-         or more of the MUST requirements for the protocols it
-         implements.  An implementation that satisfies all the MUST and
-         all the SHOULD requirements for its protocols is said to be
-         "unconditionally compliant"; one that satisfies all the MUST
-         requirements but not all the SHOULD requirements for its
-         protocols is said to be "conditionally compliant".
-
-      1.3.3  Terminology
-
-         This document uses the following technical terms:
-
-         Segment
-              A segment is the unit of end-to-end transmission in the
-              TCP protocol.  A segment consists of a TCP header followed
-              by application data.  A segment is transmitted by
-              encapsulation inside an IP datagram.
-
-         Message
-              In this description of the lower-layer protocols, a
-              message is the unit of transmission in a transport layer
-              protocol.  In particular, a TCP segment is a message.  A
-              message consists of a transport protocol header followed
-              by application protocol data.  To be transmitted end-to-
-
-
-
-Internet Engineering Task Force                                [Page 17]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-              end through the Internet, a message must be encapsulated
-              inside a datagram.
-
-         IP Datagram
-              An IP datagram is the unit of end-to-end transmission in
-              the IP protocol.  An IP datagram consists of an IP header
-              followed by transport layer data, i.e., of an IP header
-              followed by a message.
-
-              In the description of the internet layer (Section 3), the
-              unqualified term "datagram" should be understood to refer
-              to an IP datagram.
-
-         Packet
-              A packet is the unit of data passed across the interface
-              between the internet layer and the link layer.  It
-              includes an IP header and data.  A packet may be a
-              complete IP datagram or a fragment of an IP datagram.
-
-         Frame
-              A frame is the unit of transmission in a link layer
-              protocol, and consists of a link-layer header followed by
-              a packet.
-
-         Connected Network
-              A network to which a host is interfaced is often known as
-              the "local network" or the "subnetwork" relative to that
-              host.  However, these terms can cause confusion, and
-              therefore we use the term "connected network" in this
-              document.
-
-         Multihomed
-              A host is said to be multihomed if it has multiple IP
-              addresses.  For a discussion of multihoming, see Section
-              3.3.4 below.
-
-         Physical network interface
-              This is a physical interface to a connected network and
-              has a (possibly unique) link-layer address.  Multiple
-              physical network interfaces on a single host may share the
-              same link-layer address, but the address must be unique
-              for different hosts on the same physical network.
-
-         Logical [network] interface
-              We define a logical [network] interface to be a logical
-              path, distinguished by a unique IP address, to a connected
-              network.  See Section 3.3.4.
-
-
-
-
-Internet Engineering Task Force                                [Page 18]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         Specific-destination address
-              This is the effective destination address of a datagram,
-              even if it is broadcast or multicast; see Section 3.2.1.3.
-
-         Path
-              At a given moment, all the IP datagrams from a particular
-              source host to a particular destination host will
-              typically traverse the same sequence of gateways.  We use
-              the term "path" for this sequence.  Note that a path is
-              uni-directional; it is not unusual to have different paths
-              in the two directions between a given host pair.
-
-         MTU
-              The maximum transmission unit, i.e., the size of the
-              largest packet that can be transmitted.
-
-
-         The terms frame, packet, datagram, message, and segment are
-         illustrated by the following schematic diagrams:
-
-         A. Transmission on connected network:
-           _______________________________________________
-          | LL hdr | IP hdr |         (data)              |
-          |________|________|_____________________________|
-
-           <---------- Frame ----------------------------->
-                    <----------Packet -------------------->
-
-
-         B. Before IP fragmentation or after IP reassembly:
-                    ______________________________________
-                   | IP hdr | transport| Application Data |
-                   |________|____hdr___|__________________|
-
-                    <--------  Datagram ------------------>
-                             <-------- Message ----------->
-           or, for TCP:
-                    ______________________________________
-                   | IP hdr |  TCP hdr | Application Data |
-                   |________|__________|__________________|
-
-                    <--------  Datagram ------------------>
-                             <-------- Segment ----------->
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 19]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-   1.4  Acknowledgments
-
-      This document incorporates contributions and comments from a large
-      group of Internet protocol experts, including representatives of
-      university and research labs, vendors, and government agencies.
-      It was assembled primarily by the Host Requirements Working Group
-      of the Internet Engineering Task Force (IETF).
-
-      The Editor would especially like to acknowledge the tireless
-      dedication of the following people, who attended many long
-      meetings and generated 3 million bytes of electronic mail over the
-      past 18 months in pursuit of this document: Philip Almquist, Dave
-      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
-      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
-      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
-      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
-      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
-
-      In addition, the following people made major contributions to the
-      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
-      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
-      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
-      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
-      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
-      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
-      Technology), and Mike StJohns (DCA).  The following also made
-      significant contributions to particular areas: Eric Allman
-      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
-      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
-      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
-      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
-      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
-      (Toronto).
-
-      We are grateful to all, including any contributors who may have
-      been inadvertently omitted from this list.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 20]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-2. LINK LAYER
-
-   2.1  INTRODUCTION
-
-      All Internet systems, both hosts and gateways, have the same
-      requirements for link layer protocols.  These requirements are
-      given in Chapter 3 of "Requirements for Internet Gateways"
-      [INTRO:2], augmented with the material in this section.
-
-   2.2  PROTOCOL WALK-THROUGH
-
-      None.
-
-   2.3  SPECIFIC ISSUES
-
-      2.3.1  Trailer Protocol Negotiation
-
-         The trailer protocol [LINK:1] for link-layer encapsulation MAY
-         be used, but only when it has been verified that both systems
-         (host or gateway) involved in the link-layer communication
-         implement trailers.  If the system does not dynamically
-         negotiate use of the trailer protocol on a per-destination
-         basis, the default configuration MUST disable the protocol.
-
-         DISCUSSION:
-              The trailer protocol is a link-layer encapsulation
-              technique that rearranges the data contents of packets
-              sent on the physical network.  In some cases, trailers
-              improve the throughput of higher layer protocols by
-              reducing the amount of data copying within the operating
-              system.  Higher layer protocols are unaware of trailer
-              use, but both the sending and receiving host MUST
-              understand the protocol if it is used.
-
-              Improper use of trailers can result in very confusing
-              symptoms.  Only packets with specific size attributes are
-              encapsulated using trailers, and typically only a small
-              fraction of the packets being exchanged have these
-              attributes.  Thus, if a system using trailers exchanges
-              packets with a system that does not, some packets
-              disappear into a black hole while others are delivered
-              successfully.
-
-         IMPLEMENTATION:
-              On an Ethernet, packets encapsulated with trailers use a
-              distinct Ethernet type [LINK:1], and trailer negotiation
-              is performed at the time that ARP is used to discover the
-              link-layer address of a destination system.
-
-
-
-Internet Engineering Task Force                                [Page 21]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-              Specifically, the ARP exchange is completed in the usual
-              manner using the normal IP protocol type, but a host that
-              wants to speak trailers will send an additional "trailer
-              ARP reply" packet, i.e., an ARP reply that specifies the
-              trailer encapsulation protocol type but otherwise has the
-              format of a normal ARP reply.  If a host configured to use
-              trailers receives a trailer ARP reply message from a
-              remote machine, it can add that machine to the list of
-              machines that understand trailers, e.g., by marking the
-              corresponding entry in the ARP cache.
-
-              Hosts wishing to receive trailer encapsulations send
-              trailer ARP replies whenever they complete exchanges of
-              normal ARP messages for IP.  Thus, a host that received an
-              ARP request for its IP protocol address would send a
-              trailer ARP reply in addition to the normal IP ARP reply;
-              a host that sent the IP ARP request would send a trailer
-              ARP reply when it received the corresponding IP ARP reply.
-              In this way, either the requesting or responding host in
-              an IP ARP exchange may request that it receive trailer
-              encapsulations.
-
-              This scheme, using extra trailer ARP reply packets rather
-              than sending an ARP request for the trailer protocol type,
-              was designed to avoid a continuous exchange of ARP packets
-              with a misbehaving host that, contrary to any
-              specification or common sense, responded to an ARP reply
-              for trailers with another ARP reply for IP.  This problem
-              is avoided by sending a trailer ARP reply in response to
-              an IP ARP reply only when the IP ARP reply answers an
-              outstanding request; this is true when the hardware
-              address for the host is still unknown when the IP ARP
-              reply is received.  A trailer ARP reply may always be sent
-              along with an IP ARP reply responding to an IP ARP
-              request.
-
-      2.3.2  Address Resolution Protocol -- ARP
-
-         2.3.2.1  ARP Cache Validation
-
-            An implementation of the Address Resolution Protocol (ARP)
-            [LINK:2] MUST provide a mechanism to flush out-of-date cache
-            entries.  If this mechanism involves a timeout, it SHOULD be
-            possible to configure the timeout value.
-
-            A mechanism to prevent ARP flooding (repeatedly sending an
-            ARP Request for the same IP address, at a high rate) MUST be
-            included.  The recommended maximum rate is 1 per second per
-
-
-
-Internet Engineering Task Force                                [Page 22]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-            destination.
-
-            DISCUSSION:
-                 The ARP specification [LINK:2] suggests but does not
-                 require a timeout mechanism to invalidate cache entries
-                 when hosts change their Ethernet addresses.  The
-                 prevalence of proxy ARP (see Section 2.4 of [INTRO:2])
-                 has significantly increased the likelihood that cache
-                 entries in hosts will become invalid, and therefore
-                 some ARP-cache invalidation mechanism is now required
-                 for hosts.  Even in the absence of proxy ARP, a long-
-                 period cache timeout is useful in order to
-                 automatically correct any bad ARP data that might have
-                 been cached.
-
-            IMPLEMENTATION:
-                 Four mechanisms have been used, sometimes in
-                 combination, to flush out-of-date cache entries.
-
-                 (1)  Timeout -- Periodically time out cache entries,
-                      even if they are in use.  Note that this timeout
-                      should be restarted when the cache entry is
-                      "refreshed" (by observing the source fields,
-                      regardless of target address, of an ARP broadcast
-                      from the system in question).  For proxy ARP
-                      situations, the timeout needs to be on the order
-                      of a minute.
-
-                 (2)  Unicast Poll -- Actively poll the remote host by
-                      periodically sending a point-to-point ARP Request
-                      to it, and delete the entry if no ARP Reply is
-                      received from N successive polls.  Again, the
-                      timeout should be on the order of a minute, and
-                      typically N is 2.
-
-                 (3)  Link-Layer Advice -- If the link-layer driver
-                      detects a delivery problem, flush the
-                      corresponding ARP cache entry.
-
-                 (4)  Higher-layer Advice -- Provide a call from the
-                      Internet layer to the link layer to indicate a
-                      delivery problem.  The effect of this call would
-                      be to invalidate the corresponding cache entry.
-                      This call would be analogous to the
-                      "ADVISE_DELIVPROB()" call from the transport layer
-                      to the Internet layer (see Section 3.4), and in
-                      fact the ADVISE_DELIVPROB routine might in turn
-                      call the link-layer advice routine to invalidate
-
-
-
-Internet Engineering Task Force                                [Page 23]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-                      the ARP cache entry.
-
-                 Approaches (1) and (2) involve ARP cache timeouts on
-                 the order of a minute or less.  In the absence of proxy
-                 ARP, a timeout this short could create noticeable
-                 overhead traffic on a very large Ethernet.  Therefore,
-                 it may be necessary to configure a host to lengthen the
-                 ARP cache timeout.
-
-         2.3.2.2  ARP Packet Queue
-
-            The link layer SHOULD save (rather than discard) at least
-            one (the latest) packet of each set of packets destined to
-            the same unresolved IP address, and transmit the saved
-            packet when the address has been resolved.
-
-            DISCUSSION:
-                 Failure to follow this recommendation causes the first
-                 packet of every exchange to be lost.  Although higher-
-                 layer protocols can generally cope with packet loss by
-                 retransmission, packet loss does impact performance.
-                 For example, loss of a TCP open request causes the
-                 initial round-trip time estimate to be inflated.  UDP-
-                 based applications such as the Domain Name System are
-                 more seriously affected.
-
-      2.3.3  Ethernet and IEEE 802 Encapsulation
-
-         The IP encapsulation for Ethernets is described in RFC-894
-         [LINK:3], while RFC-1042 [LINK:4] describes the IP
-         encapsulation for IEEE 802 networks.  RFC-1042 elaborates and
-         replaces the discussion in Section 3.4 of [INTRO:2].
-
-         Every Internet host connected to a 10Mbps Ethernet cable:
-
-         o    MUST be able to send and receive packets using RFC-894
-              encapsulation;
-
-         o    SHOULD be able to receive RFC-1042 packets, intermixed
-              with RFC-894 packets; and
-
-         o    MAY be able to send packets using RFC-1042 encapsulation.
-
-
-         An Internet host that implements sending both the RFC-894 and
-         the RFC-1042 encapsulations MUST provide a configuration switch
-         to select which is sent, and this switch MUST default to RFC-
-         894.
-
-
-
-Internet Engineering Task Force                                [Page 24]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-         Note that the standard IP encapsulation in RFC-1042 does not
-         use the protocol id value (K1=6) that IEEE reserved for IP;
-         instead, it uses a value (K1=170) that implies an extension
-         (the "SNAP") which can be used to hold the Ether-Type field.
-         An Internet system MUST NOT send 802 packets using K1=6.
-
-         Address translation from Internet addresses to link-layer
-         addresses on Ethernet and IEEE 802 networks MUST be managed by
-         the Address Resolution Protocol (ARP).
-
-         The MTU for an Ethernet is 1500 and for 802.3 is 1492.
-
-         DISCUSSION:
-              The IEEE 802.3 specification provides for operation over a
-              10Mbps Ethernet cable, in which case Ethernet and IEEE
-              802.3 frames can be physically intermixed.  A receiver can
-              distinguish Ethernet and 802.3 frames by the value of the
-              802.3 Length field; this two-octet field coincides in the
-              header with the Ether-Type field of an Ethernet frame.  In
-              particular, the 802.3 Length field must be less than or
-              equal to 1500, while all valid Ether-Type values are
-              greater than 1500.
-
-              Another compatibility problem arises with link-layer
-              broadcasts.  A broadcast sent with one framing will not be
-              seen by hosts that can receive only the other framing.
-
-              The provisions of this section were designed to provide
-              direct interoperation between 894-capable and 1042-capable
-              systems on the same cable, to the maximum extent possible.
-              It is intended to support the present situation where
-              894-only systems predominate, while providing an easy
-              transition to a possible future in which 1042-capable
-              systems become common.
-
-              Note that 894-only systems cannot interoperate directly
-              with 1042-only systems.  If the two system types are set
-              up as two different logical networks on the same cable,
-              they can communicate only through an IP gateway.
-              Furthermore, it is not useful or even possible for a
-              dual-format host to discover automatically which format to
-              send, because of the problem of link-layer broadcasts.
-
-   2.4  LINK/INTERNET LAYER INTERFACE
-
-      The packet receive interface between the IP layer and the link
-      layer MUST include a flag to indicate whether the incoming packet
-      was addressed to a link-layer broadcast address.
-
-
-
-Internet Engineering Task Force                                [Page 25]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-      DISCUSSION
-           Although the IP layer does not generally know link layer
-           addresses (since every different network medium typically has
-           a different address format), the broadcast address on a
-           broadcast-capable medium is an important special case.  See
-           Section 3.2.2, especially the DISCUSSION concerning broadcast
-           storms.
-
-      The packet send interface between the IP and link layers MUST
-      include the 5-bit TOS field (see Section 3.2.1.6).
-
-      The link layer MUST NOT report a Destination Unreachable error to
-      IP solely because there is no ARP cache entry for a destination.
-
-   2.5  LINK LAYER REQUIREMENTS SUMMARY
-
-                                                  |       | | | |S| |
-                                                  |       | | | |H| |F
-                                                  |       | | | |O|M|o
-                                                  |       | |S| |U|U|o
-                                                  |       | |H| |L|S|t
-                                                  |       |M|O| |D|T|n
-                                                  |       |U|U|M| | |o
-                                                  |       |S|L|A|N|N|t
-                                                  |       |T|D|Y|O|O|t
-FEATURE                                           |SECTION| | | |T|T|e
---------------------------------------------------|-------|-|-|-|-|-|--
-                                                  |       | | | | | |
-Trailer encapsulation                             |2.3.1  | | |x| | |
-Send Trailers by default without negotiation      |2.3.1  | | | | |x|
-ARP                                               |2.3.2  | | | | | |
-  Flush out-of-date ARP cache entries             |2.3.2.1|x| | | | |
-  Prevent ARP floods                              |2.3.2.1|x| | | | |
-  Cache timeout configurable                      |2.3.2.1| |x| | | |
-  Save at least one (latest) unresolved pkt       |2.3.2.2| |x| | | |
-Ethernet and IEEE 802 Encapsulation               |2.3.3  | | | | | |
-  Host able to:                                   |2.3.3  | | | | | |
-    Send & receive RFC-894 encapsulation          |2.3.3  |x| | | | |
-    Receive RFC-1042 encapsulation                |2.3.3  | |x| | | |
-    Send RFC-1042 encapsulation                   |2.3.3  | | |x| | |
-      Then config. sw. to select, RFC-894 dflt    |2.3.3  |x| | | | |
-  Send K1=6 encapsulation                         |2.3.3  | | | | |x|
-  Use ARP on Ethernet and IEEE 802 nets           |2.3.3  |x| | | | |
-Link layer report b'casts to IP layer             |2.4    |x| | | | |
-IP layer pass TOS to link layer                   |2.4    |x| | | | |
-No ARP cache entry treated as Dest. Unreach.      |2.4    | | | | |x|
-
-
-
-
-
-Internet Engineering Task Force                                [Page 26]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-3. INTERNET LAYER PROTOCOLS
-
-   3.1 INTRODUCTION
-
-      The Robustness Principle: "Be liberal in what you accept, and
-      conservative in what you send" is particularly important in the
-      Internet layer, where one misbehaving host can deny Internet
-      service to many other hosts.
-
-      The protocol standards used in the Internet layer are:
-
-      o    RFC-791 [IP:1] defines the IP protocol and gives an
-           introduction to the architecture of the Internet.
-
-      o    RFC-792 [IP:2] defines ICMP, which provides routing,
-           diagnostic and error functionality for IP.  Although ICMP
-           messages are encapsulated within IP datagrams, ICMP
-           processing is considered to be (and is typically implemented
-           as) part of the IP layer.  See Section 3.2.2.
-
-      o    RFC-950 [IP:3] defines the mandatory subnet extension to the
-           addressing architecture.
-
-      o    RFC-1112 [IP:4] defines the Internet Group Management
-           Protocol IGMP, as part of a recommended extension to hosts
-           and to the host-gateway interface to support Internet-wide
-           multicasting at the IP level.  See Section 3.2.3.
-
-           The target of an IP multicast may be an arbitrary group of
-           Internet hosts.  IP multicasting is designed as a natural
-           extension of the link-layer multicasting facilities of some
-           networks, and it provides a standard means for local access
-           to such link-layer multicasting facilities.
-
-      Other important references are listed in Section 5 of this
-      document.
-
-      The Internet layer of host software MUST implement both IP and
-      ICMP.  See Section 3.3.7 for the requirements on support of IGMP.
-
-      The host IP layer has two basic functions:  (1) choose the "next
-      hop" gateway or host for outgoing IP datagrams and (2) reassemble
-      incoming IP datagrams.  The IP layer may also (3) implement
-      intentional fragmentation of outgoing datagrams.  Finally, the IP
-      layer must (4) provide diagnostic and error functionality.  We
-      expect that IP layer functions may increase somewhat in the
-      future, as further Internet control and management facilities are
-      developed.
-
-
-
-Internet Engineering Task Force                                [Page 27]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-      For normal datagrams, the processing is straightforward.  For
-      incoming datagrams, the IP layer:
-
-      (1)  verifies that the datagram is correctly formatted;
-
-      (2)  verifies that it is destined to the local host;
-
-      (3)  processes options;
-
-      (4)  reassembles the datagram if necessary; and
-
-      (5)  passes the encapsulated message to the appropriate
-           transport-layer protocol module.
-
-      For outgoing datagrams, the IP layer:
-
-      (1)  sets any fields not set by the transport layer;
-
-      (2)  selects the correct first hop on the connected network (a
-           process called "routing");
-
-      (3)  fragments the datagram if necessary and if intentional
-           fragmentation is implemented (see Section 3.3.3); and
-
-      (4)  passes the packet(s) to the appropriate link-layer driver.
-
-
-      A host is said to be multihomed if it has multiple IP addresses.
-      Multihoming introduces considerable confusion and complexity into
-      the protocol suite, and it is an area in which the Internet
-      architecture falls seriously short of solving all problems.  There
-      are two distinct problem areas in multihoming:
-
-      (1)  Local multihoming --  the host itself is multihomed; or
-
-      (2)  Remote multihoming -- the local host needs to communicate
-           with a remote multihomed host.
-
-      At present, remote multihoming MUST be handled at the application
-      layer, as discussed in the companion RFC [INTRO:1].  A host MAY
-      support local multihoming, which is discussed in this document,
-      and in particular in Section 3.3.4.
-
-      Any host that forwards datagrams generated by another host is
-      acting as a gateway and MUST also meet the specifications laid out
-      in the gateway requirements RFC [INTRO:2].  An Internet host that
-      includes embedded gateway code MUST have a configuration switch to
-      disable the gateway function, and this switch MUST default to the
-
-
-
-Internet Engineering Task Force                                [Page 28]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-      non-gateway mode.  In this mode, a datagram arriving through one
-      interface will not be forwarded to another host or gateway (unless
-      it is source-routed), regardless of whether the host is single-
-      homed or multihomed.  The host software MUST NOT automatically
-      move into gateway mode if the host has more than one interface, as
-      the operator of the machine may neither want to provide that
-      service nor be competent to do so.
-
-      In the following, the action specified in certain cases is to
-      "silently discard" a received datagram.  This means that the
-      datagram will be discarded without further processing and that the
-      host will not send any ICMP error message (see Section 3.2.2) as a
-      result.  However, for diagnosis of problems a host SHOULD provide
-      the capability of logging the error (see Section 1.2.3), including
-      the contents of the silently-discarded datagram, and SHOULD record
-      the event in a statistics counter.
-
-      DISCUSSION:
-           Silent discard of erroneous datagrams is generally intended
-           to prevent "broadcast storms".
-
-   3.2  PROTOCOL WALK-THROUGH
-
-      3.2.1 Internet Protocol -- IP
-
-         3.2.1.1  Version Number: RFC-791 Section 3.1
-
-            A datagram whose version number is not 4 MUST be silently
-            discarded.
-
-         3.2.1.2  Checksum: RFC-791 Section 3.1
-
-            A host MUST verify the IP header checksum on every received
-            datagram and silently discard every datagram that has a bad
-            checksum.
-
-         3.2.1.3  Addressing: RFC-791 Section 3.2
-
-            There are now five classes of IP addresses: Class A through
-            Class E.  Class D addresses are used for IP multicasting
-            [IP:4], while Class E addresses are reserved for
-            experimental use.
-
-            A multicast (Class D) address is a 28-bit logical address
-            that stands for a group of hosts, and may be either
-            permanent or transient.  Permanent multicast addresses are
-            allocated by the Internet Assigned Number Authority
-            [INTRO:6], while transient addresses may be allocated
-
-
-
-Internet Engineering Task Force                                [Page 29]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            dynamically to transient groups.  Group membership is
-            determined dynamically using IGMP [IP:4].
-
-            We now summarize the important special cases for Class A, B,
-            and C IP addresses, using the following notation for an IP
-            address:
-
-                { <Network-number>, <Host-number> }
-
-            or
-                { <Network-number>, <Subnet-number>, <Host-number> }
-
-            and the notation "-1" for a field that contains all 1 bits.
-            This notation is not intended to imply that the 1-bits in an
-            address mask need be contiguous.
-
-            (a)  { 0, 0 }
-
-                 This host on this network.  MUST NOT be sent, except as
-                 a source address as part of an initialization procedure
-                 by which the host learns its own IP address.
-
-                 See also Section 3.3.6 for a non-standard use of {0,0}.
-
-            (b)  { 0, <Host-number> }
-
-                 Specified host on this network.  It MUST NOT be sent,
-                 except as a source address as part of an initialization
-                 procedure by which the host learns its full IP address.
-
-            (c)  { -1, -1 }
-
-                 Limited broadcast.  It MUST NOT be used as a source
-                 address.
-
-                 A datagram with this destination address will be
-                 received by every host on the connected physical
-                 network but will not be forwarded outside that network.
-
-            (d)  { <Network-number>, -1 }
-
-                 Directed broadcast to the specified network.  It MUST
-                 NOT be used as a source address.
-
-            (e)  { <Network-number>, <Subnet-number>, -1 }
-
-                 Directed broadcast to the specified subnet.  It MUST
-                 NOT be used as a source address.
-
-
-
-Internet Engineering Task Force                                [Page 30]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            (f)  { <Network-number>, -1, -1 }
-
-                 Directed broadcast to all subnets of the specified
-                 subnetted network.  It MUST NOT be used as a source
-                 address.
-
-            (g)  { 127, <any> }
-
-                 Internal host loopback address.  Addresses of this form
-                 MUST NOT appear outside a host.
-
-            The <Network-number> is administratively assigned so that
-            its value will be unique in the entire world.
-
-            IP addresses are not permitted to have the value 0 or -1 for
-            any of the <Host-number>, <Network-number>, or <Subnet-
-            number> fields (except in the special cases listed above).
-            This implies that each of these fields will be at least two
-            bits long.
-
-            For further discussion of broadcast addresses, see Section
-            3.3.6.
-
-            A host MUST support the subnet extensions to IP [IP:3].  As
-            a result, there will be an address mask of the form:
-            {-1, -1, 0} associated with each of the host's local IP
-            addresses; see Sections 3.2.2.9 and 3.3.1.1.
-
-            When a host sends any datagram, the IP source address MUST
-            be one of its own IP addresses (but not a broadcast or
-            multicast address).
-
-            A host MUST silently discard an incoming datagram that is
-            not destined for the host.  An incoming datagram is destined
-            for the host if the datagram's destination address field is:
-
-            (1)  (one of) the host's IP address(es); or
-
-            (2)  an IP broadcast address valid for the connected
-                 network; or
-
-            (3)  the address for a multicast group of which the host is
-                 a member on the incoming physical interface.
-
-            For most purposes, a datagram addressed to a broadcast or
-            multicast destination is processed as if it had been
-            addressed to one of the host's IP addresses; we use the term
-            "specific-destination address" for the equivalent local IP
-
-
-
-Internet Engineering Task Force                                [Page 31]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            address of the host.  The specific-destination address is
-            defined to be the destination address in the IP header
-            unless the header contains a broadcast or multicast address,
-            in which case the specific-destination is an IP address
-            assigned to the physical interface on which the datagram
-            arrived.
-
-            A host MUST silently discard an incoming datagram containing
-            an IP source address that is invalid by the rules of this
-            section.  This validation could be done in either the IP
-            layer or by each protocol in the transport layer.
-
-            DISCUSSION:
-                 A mis-addressed datagram might be caused by a link-
-                 layer broadcast of a unicast datagram or by a gateway
-                 or host that is confused or mis-configured.
-
-                 An architectural goal for Internet hosts was to allow
-                 IP addresses to be featureless 32-bit numbers, avoiding
-                 algorithms that required a knowledge of the IP address
-                 format.  Otherwise, any future change in the format or
-                 interpretation of IP addresses will require host
-                 software changes.  However, validation of broadcast and
-                 multicast addresses violates this goal; a few other
-                 violations are described elsewhere in this document.
-
-                 Implementers should be aware that applications
-                 depending upon the all-subnets directed broadcast
-                 address (f) may be unusable on some networks.  All-
-                 subnets broadcast is not widely implemented in vendor
-                 gateways at present, and even when it is implemented, a
-                 particular network administration may disable it in the
-                 gateway configuration.
-
-         3.2.1.4  Fragmentation and Reassembly: RFC-791 Section 3.2
-
-            The Internet model requires that every host support
-            reassembly.  See Sections 3.3.2 and 3.3.3 for the
-            requirements on fragmentation and reassembly.
-
-         3.2.1.5  Identification: RFC-791 Section 3.2
-
-            When sending an identical copy of an earlier datagram, a
-            host MAY optionally retain the same Identification field in
-            the copy.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 32]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            DISCUSSION:
-                 Some Internet protocol experts have maintained that
-                 when a host sends an identical copy of an earlier
-                 datagram, the new copy should contain the same
-                 Identification value as the original.  There are two
-                 suggested advantages:  (1) if the datagrams are
-                 fragmented and some of the fragments are lost, the
-                 receiver may be able to reconstruct a complete datagram
-                 from fragments of the original and the copies; (2) a
-                 congested gateway might use the IP Identification field
-                 (and Fragment Offset) to discard duplicate datagrams
-                 from the queue.
-
-                 However, the observed patterns of datagram loss in the
-                 Internet do not favor the probability of retransmitted
-                 fragments filling reassembly gaps, while other
-                 mechanisms (e.g., TCP repacketizing upon
-                 retransmission) tend to prevent retransmission of an
-                 identical datagram [IP:9].  Therefore, we believe that
-                 retransmitting the same Identification field is not
-                 useful.  Also, a connectionless transport protocol like
-                 UDP would require the cooperation of the application
-                 programs to retain the same Identification value in
-                 identical datagrams.
-
-         3.2.1.6  Type-of-Service: RFC-791 Section 3.2
-
-            The "Type-of-Service" byte in the IP header is divided into
-            two sections:  the Precedence field (high-order 3 bits), and
-            a field that is customarily called "Type-of-Service" or
-            "TOS" (low-order 5 bits).  In this document, all references
-            to "TOS" or the "TOS field" refer to the low-order 5 bits
-            only.
-
-            The Precedence field is intended for Department of Defense
-            applications of the Internet protocols.  The use of non-zero
-            values in this field is outside the scope of this document
-            and the IP standard specification.  Vendors should consult
-            the Defense Communication Agency (DCA) for guidance on the
-            IP Precedence field and its implications for other protocol
-            layers.  However, vendors should note that the use of
-            precedence will most likely require that its value be passed
-            between protocol layers in just the same way as the TOS
-            field is passed.
-
-            The IP layer MUST provide a means for the transport layer to
-            set the TOS field of every datagram that is sent; the
-            default is all zero bits.  The IP layer SHOULD pass received
-
-
-
-Internet Engineering Task Force                                [Page 33]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            TOS values up to the transport layer.
-
-            The particular link-layer mappings of TOS contained in RFC-
-            795 SHOULD NOT be implemented.
-
-            DISCUSSION:
-                 While the TOS field has been little used in the past,
-                 it is expected to play an increasing role in the near
-                 future.  The TOS field is expected to be used to
-                 control two aspects of gateway operations: routing and
-                 queueing algorithms.  See Section 2 of [INTRO:1] for
-                 the requirements on application programs to specify TOS
-                 values.
-
-                 The TOS field may also be mapped into link-layer
-                 service selectors.  This has been applied to provide
-                 effective sharing of serial lines by different classes
-                 of TCP traffic, for example.  However, the mappings
-                 suggested in RFC-795 for networks that were included in
-                 the Internet as of 1981 are now obsolete.
-
-         3.2.1.7  Time-to-Live: RFC-791 Section 3.2
-
-            A host MUST NOT send a datagram with a Time-to-Live (TTL)
-            value of zero.
-
-            A host MUST NOT discard a datagram just because it was
-            received with TTL less than 2.
-
-            The IP layer MUST provide a means for the transport layer to
-            set the TTL field of every datagram that is sent.  When a
-            fixed TTL value is used, it MUST be configurable.  The
-            current suggested value will be published in the "Assigned
-            Numbers" RFC.
-
-            DISCUSSION:
-                 The TTL field has two functions: limit the lifetime of
-                 TCP segments (see RFC-793 [TCP:1], p. 28), and
-                 terminate Internet routing loops.  Although TTL is a
-                 time in seconds, it also has some attributes of a hop-
-                 count, since each gateway is required to reduce the TTL
-                 field by at least one.
-
-                 The intent is that TTL expiration will cause a datagram
-                 to be discarded by a gateway but not by the destination
-                 host; however, hosts that act as gateways by forwarding
-                 datagrams must follow the gateway rules for TTL.
-
-
-
-
-Internet Engineering Task Force                                [Page 34]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 A higher-layer protocol may want to set the TTL in
-                 order to implement an "expanding scope" search for some
-                 Internet resource.  This is used by some diagnostic
-                 tools, and is expected to be useful for locating the
-                 "nearest" server of a given class using IP
-                 multicasting, for example.  A particular transport
-                 protocol may also want to specify its own TTL bound on
-                 maximum datagram lifetime.
-
-                 A fixed value must be at least big enough for the
-                 Internet "diameter," i.e., the longest possible path.
-                 A reasonable value is about twice the diameter, to
-                 allow for continued Internet growth.
-
-         3.2.1.8  Options: RFC-791 Section 3.2
-
-            There MUST be a means for the transport layer to specify IP
-            options to be included in transmitted IP datagrams (see
-            Section 3.4).
-
-            All IP options (except NOP or END-OF-LIST) received in
-            datagrams MUST be passed to the transport layer (or to ICMP
-            processing when the datagram is an ICMP message).  The IP
-            and transport layer MUST each interpret those IP options
-            that they understand and silently ignore the others.
-
-            Later sections of this document discuss specific IP option
-            support required by each of ICMP, TCP, and UDP.
-
-            DISCUSSION:
-                 Passing all received IP options to the transport layer
-                 is a deliberate "violation of strict layering" that is
-                 designed to ease the introduction of new transport-
-                 relevant IP options in the future.  Each layer must
-                 pick out any options that are relevant to its own
-                 processing and ignore the rest.  For this purpose,
-                 every IP option except NOP and END-OF-LIST will include
-                 a specification of its own length.
-
-                 This document does not define the order in which a
-                 receiver must process multiple options in the same IP
-                 header.  Hosts sending multiple options must be aware
-                 that this introduces an ambiguity in the meaning of
-                 certain options when combined with a source-route
-                 option.
-
-            IMPLEMENTATION:
-                 The IP layer must not crash as the result of an option
-
-
-
-Internet Engineering Task Force                                [Page 35]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 length that is outside the possible range.  For
-                 example, erroneous option lengths have been observed to
-                 put some IP implementations into infinite loops.
-
-            Here are the requirements for specific IP options:
-
-
-            (a)  Security Option
-
-                 Some environments require the Security option in every
-                 datagram; such a requirement is outside the scope of
-                 this document and the IP standard specification.  Note,
-                 however, that the security options described in RFC-791
-                 and RFC-1038 are obsolete.  For DoD applications,
-                 vendors should consult [IP:8] for guidance.
-
-
-            (b)  Stream Identifier Option
-
-                 This option is obsolete; it SHOULD NOT be sent, and it
-                 MUST be silently ignored if received.
-
-
-            (c)  Source Route Options
-
-                 A host MUST support originating a source route and MUST
-                 be able to act as the final destination of a source
-                 route.
-
-                 If host receives a datagram containing a completed
-                 source route (i.e., the pointer points beyond the last
-                 field), the datagram has reached its final destination;
-                 the option as received (the recorded route) MUST be
-                 passed up to the transport layer (or to ICMP message
-                 processing).  This recorded route will be reversed and
-                 used to form a return source route for reply datagrams
-                 (see discussion of IP Options in Section 4).  When a
-                 return source route is built, it MUST be correctly
-                 formed even if the recorded route included the source
-                 host (see case (B) in the discussion below).
-
-                 An IP header containing more than one Source Route
-                 option MUST NOT be sent; the effect on routing of
-                 multiple Source Route options is implementation-
-                 specific.
-
-                 Section 3.3.5 presents the rules for a host acting as
-                 an intermediate hop in a source route, i.e., forwarding
-
-
-
-Internet Engineering Task Force                                [Page 36]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 a source-routed datagram.
-
-                 DISCUSSION:
-                      If a source-routed datagram is fragmented, each
-                      fragment will contain a copy of the source route.
-                      Since the processing of IP options (including a
-                      source route) must precede reassembly, the
-                      original datagram will not be reassembled until
-                      the final destination is reached.
-
-                      Suppose a source routed datagram is to be routed
-                      from host S to host D via gateways G1, G2, ... Gn.
-                      There was an ambiguity in the specification over
-                      whether the source route option in a datagram sent
-                      out by S should be (A) or (B):
-
-                          (A):  {>>G2, G3, ... Gn, D}     <--- CORRECT
-
-                          (B):  {S, >>G2, G3, ... Gn, D}  <---- WRONG
-
-                      (where >> represents the pointer).  If (A) is
-                      sent, the datagram received at D will contain the
-                      option: {G1, G2, ... Gn >>}, with S and D as the
-                      IP source and destination addresses.  If (B) were
-                      sent, the datagram received at D would again
-                      contain S and D as the same IP source and
-                      destination addresses, but the option would be:
-                      {S, G1, ...Gn >>}; i.e., the originating host
-                      would be the first hop in the route.
-
-
-            (d)  Record Route Option
-
-                 Implementation of originating and processing the Record
-                 Route option is OPTIONAL.
-
-
-            (e)  Timestamp Option
-
-                 Implementation of originating and processing the
-                 Timestamp option is OPTIONAL.  If it is implemented,
-                 the following rules apply:
-
-                 o    The originating host MUST record a timestamp in a
-                      Timestamp option whose Internet address fields are
-                      not pre-specified or whose first pre-specified
-                      address is the host's interface address.
-
-
-
-
-Internet Engineering Task Force                                [Page 37]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 o    The destination host MUST (if possible) add the
-                      current timestamp to a Timestamp option before
-                      passing the option to the transport layer or to
-                      ICMP for processing.
-
-                 o    A timestamp value MUST follow the rules given in
-                      Section 3.2.2.8 for the ICMP Timestamp message.
-
-
-      3.2.2 Internet Control Message Protocol -- ICMP
-
-         ICMP messages are grouped into two classes.
-
-         *
-              ICMP error messages:
-
-               Destination Unreachable   (see Section 3.2.2.1)
-               Redirect                  (see Section 3.2.2.2)
-               Source Quench             (see Section 3.2.2.3)
-               Time Exceeded             (see Section 3.2.2.4)
-               Parameter Problem         (see Section 3.2.2.5)
-
-
-         *
-              ICMP query messages:
-
-                Echo                     (see Section 3.2.2.6)
-                Information              (see Section 3.2.2.7)
-                Timestamp                (see Section 3.2.2.8)
-                Address Mask             (see Section 3.2.2.9)
-
-
-         If an ICMP message of unknown type is received, it MUST be
-         silently discarded.
-
-         Every ICMP error message includes the Internet header and at
-         least the first 8 data octets of the datagram that triggered
-         the error; more than 8 octets MAY be sent; this header and data
-         MUST be unchanged from the received datagram.
-
-         In those cases where the Internet layer is required to pass an
-         ICMP error message to the transport layer, the IP protocol
-         number MUST be extracted from the original header and used to
-         select the appropriate transport protocol entity to handle the
-         error.
-
-         An ICMP error message SHOULD be sent with normal (i.e., zero)
-         TOS bits.
-
-
-
-Internet Engineering Task Force                                [Page 38]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         An ICMP error message MUST NOT be sent as the result of
-         receiving:
-
-         *    an ICMP error message, or
-
-         *    a datagram destined to an IP broadcast or IP multicast
-              address, or
-
-         *    a datagram sent as a link-layer broadcast, or
-
-         *    a non-initial fragment, or
-
-         *    a datagram whose source address does not define a single
-              host -- e.g., a zero address, a loopback address, a
-              broadcast address, a multicast address, or a Class E
-              address.
-
-         NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT
-         ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.
-
-         DISCUSSION:
-              These rules will prevent the "broadcast storms" that have
-              resulted from hosts returning ICMP error messages in
-              response to broadcast datagrams.  For example, a broadcast
-              UDP segment to a non-existent port could trigger a flood
-              of ICMP Destination Unreachable datagrams from all
-              machines that do not have a client for that destination
-              port.  On a large Ethernet, the resulting collisions can
-              render the network useless for a second or more.
-
-              Every datagram that is broadcast on the connected network
-              should have a valid IP broadcast address as its IP
-              destination (see Section 3.3.6).  However, some hosts
-              violate this rule.  To be certain to detect broadcast
-              datagrams, therefore, hosts are required to check for a
-              link-layer broadcast as well as an IP-layer broadcast
-              address.
-
-         IMPLEMENTATION:
-              This requires that the link layer inform the IP layer when
-              a link-layer broadcast datagram has been received; see
-              Section 2.4.
-
-         3.2.2.1  Destination Unreachable: RFC-792
-
-            The following additional codes are hereby defined:
-
-                    6 = destination network unknown
-
-
-
-Internet Engineering Task Force                                [Page 39]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                    7 = destination host unknown
-
-                    8 = source host isolated
-
-                    9 = communication with destination network
-                            administratively prohibited
-
-                   10 = communication with destination host
-                            administratively prohibited
-
-                   11 = network unreachable for type of service
-
-                   12 = host unreachable for type of service
-
-            A host SHOULD generate Destination Unreachable messages with
-            code:
-
-            2    (Protocol Unreachable), when the designated transport
-                 protocol is not supported; or
-
-            3    (Port Unreachable), when the designated transport
-                 protocol (e.g., UDP) is unable to demultiplex the
-                 datagram but has no protocol mechanism to inform the
-                 sender.
-
-            A Destination Unreachable message that is received MUST be
-            reported to the transport layer.  The transport layer SHOULD
-            use the information appropriately; for example, see Sections
-            4.1.3.3, 4.2.3.9, and 4.2.4 below.  A transport protocol
-            that has its own mechanism for notifying the sender that a
-            port is unreachable (e.g., TCP, which sends RST segments)
-            MUST nevertheless accept an ICMP Port Unreachable for the
-            same purpose.
-
-            A Destination Unreachable message that is received with code
-            0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a
-            routing transient and MUST therefore be interpreted as only
-            a hint, not proof, that the specified destination is
-            unreachable [IP:11].  For example, it MUST NOT be used as
-            proof of a dead gateway (see Section 3.3.1).
-
-         3.2.2.2  Redirect: RFC-792
-
-            A host SHOULD NOT send an ICMP Redirect message; Redirects
-            are to be sent only by gateways.
-
-            A host receiving a Redirect message MUST update its routing
-            information accordingly.  Every host MUST be prepared to
-
-
-
-Internet Engineering Task Force                                [Page 40]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            accept both Host and Network Redirects and to process them
-            as described in Section 3.3.1.2 below.
-
-            A Redirect message SHOULD be silently discarded if the new
-            gateway address it specifies is not on the same connected
-            (sub-) net through which the Redirect arrived [INTRO:2,
-            Appendix A], or if the source of the Redirect is not the
-            current first-hop gateway for the specified destination (see
-            Section 3.3.1).
-
-         3.2.2.3  Source Quench: RFC-792
-
-            A host MAY send a Source Quench message if it is
-            approaching, or has reached, the point at which it is forced
-            to discard incoming datagrams due to a shortage of
-            reassembly buffers or other resources.  See Section 2.2.3 of
-            [INTRO:2] for suggestions on when to send Source Quench.
-
-            If a Source Quench message is received, the IP layer MUST
-            report it to the transport layer (or ICMP processing). In
-            general, the transport or application layer SHOULD implement
-            a mechanism to respond to Source Quench for any protocol
-            that can send a sequence of datagrams to the same
-            destination and which can reasonably be expected to maintain
-            enough state information to make this feasible.  See Section
-            4 for the handling of Source Quench by TCP and UDP.
-
-            DISCUSSION:
-                 A Source Quench may be generated by the target host or
-                 by some gateway in the path of a datagram.  The host
-                 receiving a Source Quench should throttle itself back
-                 for a period of time, then gradually increase the
-                 transmission rate again.  The mechanism to respond to
-                 Source Quench may be in the transport layer (for
-                 connection-oriented protocols like TCP) or in the
-                 application layer (for protocols that are built on top
-                 of UDP).
-
-                 A mechanism has been proposed [IP:14] to make the IP
-                 layer respond directly to Source Quench by controlling
-                 the rate at which datagrams are sent, however, this
-                 proposal is currently experimental and not currently
-                 recommended.
-
-         3.2.2.4  Time Exceeded: RFC-792
-
-            An incoming Time Exceeded message MUST be passed to the
-            transport layer.
-
-
-
-Internet Engineering Task Force                                [Page 41]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            DISCUSSION:
-                 A gateway will send a Time Exceeded Code 0 (In Transit)
-                 message when it discards a datagram due to an expired
-                 TTL field.  This indicates either a gateway routing
-                 loop or too small an initial TTL value.
-
-                 A host may receive a Time Exceeded Code 1 (Reassembly
-                 Timeout) message from a destination host that has timed
-                 out and discarded an incomplete datagram; see Section
-                 3.3.2 below.  In the future, receipt of this message
-                 might be part of some "MTU discovery" procedure, to
-                 discover the maximum datagram size that can be sent on
-                 the path without fragmentation.
-
-         3.2.2.5  Parameter Problem: RFC-792
-
-            A host SHOULD generate Parameter Problem messages.  An
-            incoming Parameter Problem message MUST be passed to the
-            transport layer, and it MAY be reported to the user.
-
-            DISCUSSION:
-                 The ICMP Parameter Problem message is sent to the
-                 source host for any problem not specifically covered by
-                 another ICMP message.  Receipt of a Parameter Problem
-                 message generally indicates some local or remote
-                 implementation error.
-
-            A new variant on the Parameter Problem message is hereby
-            defined:
-              Code 1 = required option is missing.
-
-            DISCUSSION:
-                 This variant is currently in use in the military
-                 community for a missing security option.
-
-         3.2.2.6  Echo Request/Reply: RFC-792
-
-            Every host MUST implement an ICMP Echo server function that
-            receives Echo Requests and sends corresponding Echo Replies.
-            A host SHOULD also implement an application-layer interface
-            for sending an Echo Request and receiving an Echo Reply, for
-            diagnostic purposes.
-
-            An ICMP Echo Request destined to an IP broadcast or IP
-            multicast address MAY be silently discarded.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 42]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            DISCUSSION:
-                 This neutral provision results from a passionate debate
-                 between those who feel that ICMP Echo to a broadcast
-                 address provides a valuable diagnostic capability and
-                 those who feel that misuse of this feature can too
-                 easily create packet storms.
-
-            The IP source address in an ICMP Echo Reply MUST be the same
-            as the specific-destination address (defined in Section
-            3.2.1.3) of the corresponding ICMP Echo Request message.
-
-            Data received in an ICMP Echo Request MUST be entirely
-            included in the resulting Echo Reply.  However, if sending
-            the Echo Reply requires intentional fragmentation that is
-            not implemented, the datagram MUST be truncated to maximum
-            transmission size (see Section 3.3.3) and sent.
-
-            Echo Reply messages MUST be passed to the ICMP user
-            interface, unless the corresponding Echo Request originated
-            in the IP layer.
-
-            If a Record Route and/or Time Stamp option is received in an
-            ICMP Echo Request, this option (these options) SHOULD be
-            updated to include the current host and included in the IP
-            header of the Echo Reply message, without "truncation".
-            Thus, the recorded route will be for the entire round trip.
-
-            If a Source Route option is received in an ICMP Echo
-            Request, the return route MUST be reversed and used as a
-            Source Route option for the Echo Reply message.
-
-         3.2.2.7  Information Request/Reply: RFC-792
-
-            A host SHOULD NOT implement these messages.
-
-            DISCUSSION:
-                 The Information Request/Reply pair was intended to
-                 support self-configuring systems such as diskless
-                 workstations, to allow them to discover their IP
-                 network numbers at boot time.  However, the RARP and
-                 BOOTP protocols provide better mechanisms for a host to
-                 discover its own IP address.
-
-         3.2.2.8  Timestamp and Timestamp Reply: RFC-792
-
-            A host MAY implement Timestamp and Timestamp Reply.  If they
-            are implemented, the following rules MUST be followed.
-
-
-
-
-Internet Engineering Task Force                                [Page 43]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            o    The ICMP Timestamp server function returns a Timestamp
-                 Reply to every Timestamp message that is received.  If
-                 this function is implemented, it SHOULD be designed for
-                 minimum variability in delay (e.g., implemented in the
-                 kernel to avoid delay in scheduling a user process).
-
-            The following cases for Timestamp are to be handled
-            according to the corresponding rules for ICMP Echo:
-
-            o    An ICMP Timestamp Request message to an IP broadcast or
-                 IP multicast address MAY be silently discarded.
-
-            o    The IP source address in an ICMP Timestamp Reply MUST
-                 be the same as the specific-destination address of the
-                 corresponding Timestamp Request message.
-
-            o    If a Source-route option is received in an ICMP Echo
-                 Request, the return route MUST be reversed and used as
-                 a Source Route option for the Timestamp Reply message.
-
-            o    If a Record Route and/or Timestamp option is received
-                 in a Timestamp Request, this (these) option(s) SHOULD
-                 be updated to include the current host and included in
-                 the IP header of the Timestamp Reply message.
-
-            o    Incoming Timestamp Reply messages MUST be passed up to
-                 the ICMP user interface.
-
-            The preferred form for a timestamp value (the "standard
-            value") is in units of milliseconds since midnight Universal
-            Time.  However, it may be difficult to provide this value
-            with millisecond resolution.  For example, many systems use
-            clocks that update only at line frequency, 50 or 60 times
-            per second.  Therefore, some latitude is allowed in a
-            "standard value":
-
-            (a)  A "standard value" MUST be updated at least 15 times
-                 per second (i.e., at most the six low-order bits of the
-                 value may be undefined).
-
-            (b)  The accuracy of a "standard value" MUST approximate
-                 that of operator-set CPU clocks, i.e., correct within a
-                 few minutes.
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 44]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         3.2.2.9  Address Mask Request/Reply: RFC-950
-
-            A host MUST support the first, and MAY implement all three,
-            of the following methods for determining the address mask(s)
-            corresponding to its IP address(es):
-
-            (1)  static configuration information;
-
-            (2)  obtaining the address mask(s) dynamically as a side-
-                 effect of the system initialization process (see
-                 [INTRO:1]); and
-
-            (3)  sending ICMP Address Mask Request(s) and receiving ICMP
-                 Address Mask Reply(s).
-
-            The choice of method to be used in a particular host MUST be
-            configurable.
-
-            When method (3), the use of Address Mask messages, is
-            enabled, then:
-
-            (a)  When it initializes, the host MUST broadcast an Address
-                 Mask Request message on the connected network
-                 corresponding to the IP address.  It MUST retransmit
-                 this message a small number of times if it does not
-                 receive an immediate Address Mask Reply.
-
-            (b)  Until it has received an Address Mask Reply, the host
-                 SHOULD assume a mask appropriate for the address class
-                 of the IP address, i.e., assume that the connected
-                 network is not subnetted.
-
-            (c)  The first Address Mask Reply message received MUST be
-                 used to set the address mask corresponding to the
-                 particular local IP address.  This is true even if the
-                 first Address Mask Reply message is "unsolicited", in
-                 which case it will have been broadcast and may arrive
-                 after the host has ceased to retransmit Address Mask
-                 Requests.  Once the mask has been set by an Address
-                 Mask Reply, later Address Mask Reply messages MUST be
-                 (silently) ignored.
-
-            Conversely, if Address Mask messages are disabled, then no
-            ICMP Address Mask Requests will be sent, and any ICMP
-            Address Mask Replies received for that local IP address MUST
-            be (silently) ignored.
-
-            A host SHOULD make some reasonableness check on any address
-
-
-
-Internet Engineering Task Force                                [Page 45]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            mask it installs; see IMPLEMENTATION section below.
-
-            A system MUST NOT send an Address Mask Reply unless it is an
-            authoritative agent for address masks.  An authoritative
-            agent may be a host or a gateway, but it MUST be explicitly
-            configured as a address mask agent.  Receiving an address
-            mask via an Address Mask Reply does not give the receiver
-            authority and MUST NOT be used as the basis for issuing
-            Address Mask Replies.
-
-            With a statically configured address mask, there SHOULD be
-            an additional configuration flag that determines whether the
-            host is to act as an authoritative agent for this mask,
-            i.e., whether it will answer Address Mask Request messages
-            using this mask.
-
-            If it is configured as an agent, the host MUST broadcast an
-            Address Mask Reply for the mask on the appropriate interface
-            when it initializes.
-
-            See "System Initialization" in [INTRO:1] for more
-            information about the use of Address Mask Request/Reply
-            messages.
-
-            DISCUSSION
-                 Hosts that casually send Address Mask Replies with
-                 invalid address masks have often been a serious
-                 nuisance.  To prevent this, Address Mask Replies ought
-                 to be sent only by authoritative agents that have been
-                 selected by explicit administrative action.
-
-                 When an authoritative agent receives an Address Mask
-                 Request message, it will send a unicast Address Mask
-                 Reply to the source IP address.  If the network part of
-                 this address is zero (see (a) and (b) in 3.2.1.3), the
-                 Reply will be broadcast.
-
-                 Getting no reply to its Address Mask Request messages,
-                 a host will assume there is no agent and use an
-                 unsubnetted mask, but the agent may be only temporarily
-                 unreachable.  An agent will broadcast an unsolicited
-                 Address Mask Reply whenever it initializes, in order to
-                 update the masks of all hosts that have initialized in
-                 the meantime.
-
-            IMPLEMENTATION:
-                 The following reasonableness check on an address mask
-                 is suggested: the mask is not all 1 bits, and it is
-
-
-
-Internet Engineering Task Force                                [Page 46]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 either zero or else the 8 highest-order bits are on.
-
-      3.2.3  Internet Group Management Protocol IGMP
-
-         IGMP [IP:4] is a protocol used between hosts and gateways on a
-         single network to establish hosts' membership in particular
-         multicast groups.  The gateways use this information, in
-         conjunction with a multicast routing protocol, to support IP
-         multicasting across the Internet.
-
-         At this time, implementation of IGMP is OPTIONAL; see Section
-         3.3.7 for more information.  Without IGMP, a host can still
-         participate in multicasting local to its connected networks.
-
-   3.3  SPECIFIC ISSUES
-
-      3.3.1  Routing Outbound Datagrams
-
-         The IP layer chooses the correct next hop for each datagram it
-         sends.  If the destination is on a connected network, the
-         datagram is sent directly to the destination host; otherwise,
-         it has to be routed to a gateway on a connected network.
-
-         3.3.1.1  Local/Remote Decision
-
-            To decide if the destination is on a connected network, the
-            following algorithm MUST be used [see IP:3]:
-
-            (a)  The address mask (particular to a local IP address for
-                 a multihomed host) is a 32-bit mask that selects the
-                 network number and subnet number fields of the
-                 corresponding IP address.
-
-            (b)  If the IP destination address bits extracted by the
-                 address mask match the IP source address bits extracted
-                 by the same mask, then the destination is on the
-                 corresponding connected network, and the datagram is to
-                 be transmitted directly to the destination host.
-
-            (c)  If not, then the destination is accessible only through
-                 a gateway.  Selection of a gateway is described below
-                 (3.3.1.2).
-
-            A special-case destination address is handled as follows:
-
-            *    For a limited broadcast or a multicast address, simply
-                 pass the datagram to the link layer for the appropriate
-                 interface.
-
-
-
-Internet Engineering Task Force                                [Page 47]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            *    For a (network or subnet) directed broadcast, the
-                 datagram can use the standard routing algorithms.
-
-            The host IP layer MUST operate correctly in a minimal
-            network environment, and in particular, when there are no
-            gateways.  For example, if the IP layer of a host insists on
-            finding at least one gateway to initialize, the host will be
-            unable to operate on a single isolated broadcast net.
-
-         3.3.1.2  Gateway Selection
-
-            To efficiently route a series of datagrams to the same
-            destination, the source host MUST keep a "route cache" of
-            mappings to next-hop gateways.  A host uses the following
-            basic algorithm on this cache to route a datagram; this
-            algorithm is designed to put the primary routing burden on
-            the gateways [IP:11].
-
-            (a)  If the route cache contains no information for a
-                 particular destination, the host chooses a "default"
-                 gateway and sends the datagram to it.  It also builds a
-                 corresponding Route Cache entry.
-
-            (b)  If that gateway is not the best next hop to the
-                 destination, the gateway will forward the datagram to
-                 the best next-hop gateway and return an ICMP Redirect
-                 message to the source host.
-
-            (c)  When it receives a Redirect, the host updates the
-                 next-hop gateway in the appropriate route cache entry,
-                 so later datagrams to the same destination will go
-                 directly to the best gateway.
-
-            Since the subnet mask appropriate to the destination address
-            is generally not known, a Network Redirect message SHOULD be
-            treated identically to a Host Redirect message; i.e., the
-            cache entry for the destination host (only) would be updated
-            (or created, if an entry for that host did not exist) for
-            the new gateway.
-
-            DISCUSSION:
-                 This recommendation is to protect against gateways that
-                 erroneously send Network Redirects for a subnetted
-                 network, in violation of the gateway requirements
-                 [INTRO:2].
-
-            When there is no route cache entry for the destination host
-            address (and the destination is not on the connected
-
-
-
-Internet Engineering Task Force                                [Page 48]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            network), the IP layer MUST pick a gateway from its list of
-            "default" gateways.  The IP layer MUST support multiple
-            default gateways.
-
-            As an extra feature, a host IP layer MAY implement a table
-            of "static routes".  Each such static route MAY include a
-            flag specifying whether it may be overridden by ICMP
-            Redirects.
-
-            DISCUSSION:
-                 A host generally needs to know at least one default
-                 gateway to get started.  This information can be
-                 obtained from a configuration file or else from the
-                 host startup sequence, e.g., the BOOTP protocol (see
-                 [INTRO:1]).
-
-                 It has been suggested that a host can augment its list
-                 of default gateways by recording any new gateways it
-                 learns about.  For example, it can record every gateway
-                 to which it is ever redirected.  Such a feature, while
-                 possibly useful in some circumstances, may cause
-                 problems in other cases (e.g., gateways are not all
-                 equal), and it is not recommended.
-
-                 A static route is typically a particular preset mapping
-                 from destination host or network into a particular
-                 next-hop gateway; it might also depend on the Type-of-
-                 Service (see next section).  Static routes would be set
-                 up by system administrators to override the normal
-                 automatic routing mechanism, to handle exceptional
-                 situations.  However, any static routing information is
-                 a potential source of failure as configurations change
-                 or equipment fails.
-
-         3.3.1.3  Route Cache
-
-            Each route cache entry needs to include the following
-            fields:
-
-            (1)  Local IP address (for a multihomed host)
-
-            (2)  Destination IP address
-
-            (3)  Type(s)-of-Service
-
-            (4)  Next-hop gateway IP address
-
-            Field (2) MAY be the full IP address of the destination
-
-
-
-Internet Engineering Task Force                                [Page 49]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            host, or only the destination network number.  Field (3),
-            the TOS, SHOULD be included.
-
-            See Section 3.3.4.2 for a discussion of the implications of
-            multihoming for the lookup procedure in this cache.
-
-            DISCUSSION:
-                 Including the Type-of-Service field in the route cache
-                 and considering it in the host route algorithm will
-                 provide the necessary mechanism for the future when
-                 Type-of-Service routing is commonly used in the
-                 Internet.  See Section 3.2.1.6.
-
-                 Each route cache entry defines the endpoints of an
-                 Internet path.  Although the connecting path may change
-                 dynamically in an arbitrary way, the transmission
-                 characteristics of the path tend to remain
-                 approximately constant over a time period longer than a
-                 single typical host-host transport connection.
-                 Therefore, a route cache entry is a natural place to
-                 cache data on the properties of the path.  Examples of
-                 such properties might be the maximum unfragmented
-                 datagram size (see Section 3.3.3), or the average
-                 round-trip delay measured by a transport protocol.
-                 This data will generally be both gathered and used by a
-                 higher layer protocol, e.g., by TCP, or by an
-                 application using UDP.  Experiments are currently in
-                 progress on caching path properties in this manner.
-
-                 There is no consensus on whether the route cache should
-                 be keyed on destination host addresses alone, or allow
-                 both host and network addresses.  Those who favor the
-                 use of only host addresses argue that:
-
-                 (1)  As required in Section 3.3.1.2, Redirect messages
-                      will generally result in entries keyed on
-                      destination host addresses; the simplest and most
-                      general scheme would be to use host addresses
-                      always.
-
-                 (2)  The IP layer may not always know the address mask
-                      for a network address in a complex subnetted
-                      environment.
-
-                 (3)  The use of only host addresses allows the
-                      destination address to be used as a pure 32-bit
-                      number, which may allow the Internet architecture
-                      to be more easily extended in the future without
-
-
-
-Internet Engineering Task Force                                [Page 50]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                      any change to the hosts.
-
-                 The opposing view is that allowing a mixture of
-                 destination hosts and networks in the route cache:
-
-                 (1)  Saves memory space.
-
-                 (2)  Leads to a simpler data structure, easily
-                      combining the cache with the tables of default and
-                      static routes (see below).
-
-                 (3)  Provides a more useful place to cache path
-                      properties, as discussed earlier.
-
-
-            IMPLEMENTATION:
-                 The cache needs to be large enough to include entries
-                 for the maximum number of destination hosts that may be
-                 in use at one time.
-
-                 A route cache entry may also include control
-                 information used to choose an entry for replacement.
-                 This might take the form of a "recently used" bit, a
-                 use count, or a last-used timestamp, for example.  It
-                 is recommended that it include the time of last
-                 modification of the entry, for diagnostic purposes.
-
-                 An implementation may wish to reduce the overhead of
-                 scanning the route cache for every datagram to be
-                 transmitted.  This may be accomplished with a hash
-                 table to speed the lookup, or by giving a connection-
-                 oriented transport protocol a "hint" or temporary
-                 handle on the appropriate cache entry, to be passed to
-                 the IP layer with each subsequent datagram.
-
-                 Although we have described the route cache, the lists
-                 of default gateways, and a table of static routes as
-                 conceptually distinct, in practice they may be combined
-                 into a single "routing table" data structure.
-
-         3.3.1.4  Dead Gateway Detection
-
-            The IP layer MUST be able to detect the failure of a "next-
-            hop" gateway that is listed in its route cache and to choose
-            an alternate gateway (see Section 3.3.1.5).
-
-            Dead gateway detection is covered in some detail in RFC-816
-            [IP:11]. Experience to date has not produced a complete
-
-
-
-Internet Engineering Task Force                                [Page 51]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            algorithm which is totally satisfactory, though it has
-            identified several forbidden paths and promising techniques.
-
-            *    A particular gateway SHOULD NOT be used indefinitely in
-                 the absence of positive indications that it is
-                 functioning.
-
-            *    Active probes such as "pinging" (i.e., using an ICMP
-                 Echo Request/Reply exchange) are expensive and scale
-                 poorly.  In particular, hosts MUST NOT actively check
-                 the status of a first-hop gateway by simply pinging the
-                 gateway continuously.
-
-            *    Even when it is the only effective way to verify a
-                 gateway's status, pinging MUST be used only when
-                 traffic is being sent to the gateway and when there is
-                 no other positive indication to suggest that the
-                 gateway is functioning.
-
-            *    To avoid pinging, the layers above and/or below the
-                 Internet layer SHOULD be able to give "advice" on the
-                 status of route cache entries when either positive
-                 (gateway OK) or negative (gateway dead) information is
-                 available.
-
-
-            DISCUSSION:
-                 If an implementation does not include an adequate
-                 mechanism for detecting a dead gateway and re-routing,
-                 a gateway failure may cause datagrams to apparently
-                 vanish into a "black hole".  This failure can be
-                 extremely confusing for users and difficult for network
-                 personnel to debug.
-
-                 The dead-gateway detection mechanism must not cause
-                 unacceptable load on the host, on connected networks,
-                 or on first-hop gateway(s).  The exact constraints on
-                 the timeliness of dead gateway detection and on
-                 acceptable load may vary somewhat depending on the
-                 nature of the host's mission, but a host generally
-                 needs to detect a failed first-hop gateway quickly
-                 enough that transport-layer connections will not break
-                 before an alternate gateway can be selected.
-
-                 Passing advice from other layers of the protocol stack
-                 complicates the interfaces between the layers, but it
-                 is the preferred approach to dead gateway detection.
-                 Advice can come from almost any part of the IP/TCP
-
-
-
-Internet Engineering Task Force                                [Page 52]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 architecture, but it is expected to come primarily from
-                 the transport and link layers.  Here are some possible
-                 sources for gateway advice:
-
-                 o    TCP or any connection-oriented transport protocol
-                      should be able to give negative advice, e.g.,
-                      triggered by excessive retransmissions.
-
-                 o    TCP may give positive advice when (new) data is
-                      acknowledged.  Even though the route may be
-                      asymmetric, an ACK for new data proves that the
-                      acknowleged data must have been transmitted
-                      successfully.
-
-                 o    An ICMP Redirect message from a particular gateway
-                      should be used as positive advice about that
-                      gateway.
-
-                 o    Link-layer information that reliably detects and
-                      reports host failures (e.g., ARPANET Destination
-                      Dead messages) should be used as negative advice.
-
-                 o    Failure to ARP or to re-validate ARP mappings may
-                      be used as negative advice for the corresponding
-                      IP address.
-
-                 o    Packets arriving from a particular link-layer
-                      address are evidence that the system at this
-                      address is alive.  However, turning this
-                      information into advice about gateways requires
-                      mapping the link-layer address into an IP address,
-                      and then checking that IP address against the
-                      gateways pointed to by the route cache.  This is
-                      probably prohibitively inefficient.
-
-                 Note that positive advice that is given for every
-                 datagram received may cause unacceptable overhead in
-                 the implementation.
-
-                 While advice might be passed using required arguments
-                 in all interfaces to the IP layer, some transport and
-                 application layer protocols cannot deduce the correct
-                 advice.  These interfaces must therefore allow a
-                 neutral value for advice, since either always-positive
-                 or always-negative advice leads to incorrect behavior.
-
-                 There is another technique for dead gateway detection
-                 that has been commonly used but is not recommended.
-
-
-
-Internet Engineering Task Force                                [Page 53]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 This technique depends upon the host passively
-                 receiving ("wiretapping") the Interior Gateway Protocol
-                 (IGP) datagrams that the gateways are broadcasting to
-                 each other.  This approach has the drawback that a host
-                 needs to recognize all the interior gateway protocols
-                 that gateways may use (see [INTRO:2]).  In addition, it
-                 only works on a broadcast network.
-
-                 At present, pinging (i.e., using ICMP Echo messages) is
-                 the mechanism for gateway probing when absolutely
-                 required.  A successful ping guarantees that the
-                 addressed interface and its associated machine are up,
-                 but it does not guarantee that the machine is a gateway
-                 as opposed to a host.  The normal inference is that if
-                 a Redirect or other evidence indicates that a machine
-                 was a gateway, successful pings will indicate that the
-                 machine is still up and hence still a gateway.
-                 However, since a host silently discards packets that a
-                 gateway would forward or redirect, this assumption
-                 could sometimes fail.  To avoid this problem, a new
-                 ICMP message under development will ask "are you a
-                 gateway?"
-
-            IMPLEMENTATION:
-                 The following specific algorithm has been suggested:
-
-                 o    Associate a "reroute timer" with each gateway
-                      pointed to by the route cache.  Initialize the
-                      timer to a value Tr, which must be small enough to
-                      allow detection of a dead gateway before transport
-                      connections time out.
-
-                 o    Positive advice would reset the reroute timer to
-                      Tr.  Negative advice would reduce or zero the
-                      reroute timer.
-
-                 o    Whenever the IP layer used a particular gateway to
-                      route a datagram, it would check the corresponding
-                      reroute timer.  If the timer had expired (reached
-                      zero), the IP layer would send a ping to the
-                      gateway, followed immediately by the datagram.
-
-                 o    The ping (ICMP Echo) would be sent again if
-                      necessary, up to N times.  If no ping reply was
-                      received in N tries, the gateway would be assumed
-                      to have failed, and a new first-hop gateway would
-                      be chosen for all cache entries pointing to the
-                      failed gateway.
-
-
-
-Internet Engineering Task Force                                [Page 54]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 Note that the size of Tr is inversely related to the
-                 amount of advice available.  Tr should be large enough
-                 to insure that:
-
-                 *    Any pinging will be at a low level (e.g., <10%) of
-                      all packets sent to a gateway from the host, AND
-
-                 *    pinging is infrequent (e.g., every 3 minutes)
-
-                 Since the recommended algorithm is concerned with the
-                 gateways pointed to by route cache entries, rather than
-                 the cache entries themselves, a two level data
-                 structure (perhaps coordinated with ARP or similar
-                 caches) may be desirable for implementing a route
-                 cache.
-
-         3.3.1.5  New Gateway Selection
-
-            If the failed gateway is not the current default, the IP
-            layer can immediately switch to a default gateway.  If it is
-            the current default that failed, the IP layer MUST select a
-            different default gateway (assuming more than one default is
-            known) for the failed route and for establishing new routes.
-
-            DISCUSSION:
-                 When a gateway does fail, the other gateways on the
-                 connected network will learn of the failure through
-                 some inter-gateway routing protocol.  However, this
-                 will not happen instantaneously, since gateway routing
-                 protocols typically have a settling time of 30-60
-                 seconds.  If the host switches to an alternative
-                 gateway before the gateways have agreed on the failure,
-                 the new target gateway will probably forward the
-                 datagram to the failed gateway and send a Redirect back
-                 to the host pointing to the failed gateway (!).  The
-                 result is likely to be a rapid oscillation in the
-                 contents of the host's route cache during the gateway
-                 settling period.  It has been proposed that the dead-
-                 gateway logic should include some hysteresis mechanism
-                 to prevent such oscillations.  However, experience has
-                 not shown any harm from such oscillations, since
-                 service cannot be restored to the host until the
-                 gateways' routing information does settle down.
-
-            IMPLEMENTATION:
-                 One implementation technique for choosing a new default
-                 gateway is to simply round-robin among the default
-                 gateways in the host's list.  Another is to rank the
-
-
-
-Internet Engineering Task Force                                [Page 55]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 gateways in priority order, and when the current
-                 default gateway is not the highest priority one, to
-                 "ping" the higher-priority gateways slowly to detect
-                 when they return to service.  This pinging can be at a
-                 very low rate, e.g., 0.005 per second.
-
-         3.3.1.6  Initialization
-
-            The following information MUST be configurable:
-
-            (1)  IP address(es).
-
-            (2)  Address mask(s).
-
-            (3)  A list of default gateways, with a preference level.
-
-            A manual method of entering this configuration data MUST be
-            provided.  In addition, a variety of methods can be used to
-            determine this information dynamically; see the section on
-            "Host Initialization" in [INTRO:1].
-
-            DISCUSSION:
-                 Some host implementations use "wiretapping" of gateway
-                 protocols on a broadcast network to learn what gateways
-                 exist.  A standard method for default gateway discovery
-                 is under development.
-
-      3.3.2  Reassembly
-
-         The IP layer MUST implement reassembly of IP datagrams.
-
-         We designate the largest datagram size that can be reassembled
-         by EMTU_R ("Effective MTU to receive"); this is sometimes
-         called the "reassembly buffer size".  EMTU_R MUST be greater
-         than or equal to 576, SHOULD be either configurable or
-         indefinite, and SHOULD be greater than or equal to the MTU of
-         the connected network(s).
-
-         DISCUSSION:
-              A fixed EMTU_R limit should not be built into the code
-              because some application layer protocols require EMTU_R
-              values larger than 576.
-
-         IMPLEMENTATION:
-              An implementation may use a contiguous reassembly buffer
-              for each datagram, or it may use a more complex data
-              structure that places no definite limit on the reassembled
-              datagram size; in the latter case, EMTU_R is said to be
-
-
-
-Internet Engineering Task Force                                [Page 56]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-              "indefinite".
-
-              Logically, reassembly is performed by simply copying each
-              fragment into the packet buffer at the proper offset.
-              Note that fragments may overlap if successive
-              retransmissions use different packetizing but the same
-              reassembly Id.
-
-              The tricky part of reassembly is the bookkeeping to
-              determine when all bytes of the datagram have been
-              reassembled.  We recommend Clark's algorithm [IP:10] that
-              requires no additional data space for the bookkeeping.
-              However, note that, contrary to [IP:10], the first
-              fragment header needs to be saved for inclusion in a
-              possible ICMP Time Exceeded (Reassembly Timeout) message.
-
-         There MUST be a mechanism by which the transport layer can
-         learn MMS_R, the maximum message size that can be received and
-         reassembled in an IP datagram (see GET_MAXSIZES calls in
-         Section 3.4).  If EMTU_R is not indefinite, then the value of
-         MMS_R is given by:
-
-            MMS_R = EMTU_R - 20
-
-         since 20 is the minimum size of an IP header.
-
-         There MUST be a reassembly timeout.  The reassembly timeout
-         value SHOULD be a fixed value, not set from the remaining TTL.
-         It is recommended that the value lie between 60 seconds and 120
-         seconds.  If this timeout expires, the partially-reassembled
-         datagram MUST be discarded and an ICMP Time Exceeded message
-         sent to the source host (if fragment zero has been received).
-
-         DISCUSSION:
-              The IP specification says that the reassembly timeout
-              should be the remaining TTL from the IP header, but this
-              does not work well because gateways generally treat TTL as
-              a simple hop count rather than an elapsed time.  If the
-              reassembly timeout is too small, datagrams will be
-              discarded unnecessarily, and communication may fail.  The
-              timeout needs to be at least as large as the typical
-              maximum delay across the Internet.  A realistic minimum
-              reassembly timeout would be 60 seconds.
-
-              It has been suggested that a cache might be kept of
-              round-trip times measured by transport protocols for
-              various destinations, and that these values might be used
-              to dynamically determine a reasonable reassembly timeout
-
-
-
-Internet Engineering Task Force                                [Page 57]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-              value.  Further investigation of this approach is
-              required.
-
-              If the reassembly timeout is set too high, buffer
-              resources in the receiving host will be tied up too long,
-              and the MSL (Maximum Segment Lifetime) [TCP:1] will be
-              larger than necessary.  The MSL controls the maximum rate
-              at which fragmented datagrams can be sent using distinct
-              values of the 16-bit Ident field; a larger MSL lowers the
-              maximum rate.  The TCP specification [TCP:1] arbitrarily
-              assumes a value of 2 minutes for MSL.  This sets an upper
-              limit on a reasonable reassembly timeout value.
-
-      3.3.3  Fragmentation
-
-         Optionally, the IP layer MAY implement a mechanism to fragment
-         outgoing datagrams intentionally.
-
-         We designate by EMTU_S ("Effective MTU for sending") the
-         maximum IP datagram size that may be sent, for a particular
-         combination of IP source and destination addresses and perhaps
-         TOS.
-
-         A host MUST implement a mechanism to allow the transport layer
-         to learn MMS_S, the maximum transport-layer message size that
-         may be sent for a given {source, destination, TOS} triplet (see
-         GET_MAXSIZES call in Section 3.4).  If no local fragmentation
-         is performed, the value of MMS_S will be:
-
-            MMS_S = EMTU_S - <IP header size>
-
-         and EMTU_S must be less than or equal to the MTU of the network
-         interface corresponding to the source address of the datagram.
-         Note that <IP header size> in this equation will be 20, unless
-         the IP reserves space to insert IP options for its own purposes
-         in addition to any options inserted by the transport layer.
-
-         A host that does not implement local fragmentation MUST ensure
-         that the transport layer (for TCP) or the application layer
-         (for UDP) obtains MMS_S from the IP layer and does not send a
-         datagram exceeding MMS_S in size.
-
-         It is generally desirable to avoid local fragmentation and to
-         choose EMTU_S low enough to avoid fragmentation in any gateway
-         along the path.  In the absence of actual knowledge of the
-         minimum MTU along the path, the IP layer SHOULD use
-         EMTU_S <= 576 whenever the destination address is not on a
-         connected network, and otherwise use the connected network's
-
-
-
-Internet Engineering Task Force                                [Page 58]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         MTU.
-
-         The MTU of each physical interface MUST be configurable.
-
-         A host IP layer implementation MAY have a configuration flag
-         "All-Subnets-MTU", indicating that the MTU of the connected
-         network is to be used for destinations on different subnets
-         within the same network, but not for other networks.  Thus,
-         this flag causes the network class mask, rather than the subnet
-         address mask, to be used to choose an EMTU_S.  For a multihomed
-         host, an "All-Subnets-MTU" flag is needed for each network
-         interface.
-
-         DISCUSSION:
-              Picking the correct datagram size to use when sending data
-              is a complex topic [IP:9].
-
-              (a)  In general, no host is required to accept an IP
-                   datagram larger than 576 bytes (including header and
-                   data), so a host must not send a larger datagram
-                   without explicit knowledge or prior arrangement with
-                   the destination host.  Thus, MMS_S is only an upper
-                   bound on the datagram size that a transport protocol
-                   may send; even when MMS_S exceeds 556, the transport
-                   layer must limit its messages to 556 bytes in the
-                   absence of other knowledge about the destination
-                   host.
-
-              (b)  Some transport protocols (e.g., TCP) provide a way to
-                   explicitly inform the sender about the largest
-                   datagram the other end can receive and reassemble
-                   [IP:7].  There is no corresponding mechanism in the
-                   IP layer.
-
-                   A transport protocol that assumes an EMTU_R larger
-                   than 576 (see Section 3.3.2), can send a datagram of
-                   this larger size to another host that implements the
-                   same protocol.
-
-              (c)  Hosts should ideally limit their EMTU_S for a given
-                   destination to the minimum MTU of all the networks
-                   along the path, to avoid any fragmentation.  IP
-                   fragmentation, while formally correct, can create a
-                   serious transport protocol performance problem,
-                   because loss of a single fragment means all the
-                   fragments in the segment must be retransmitted
-                   [IP:9].
-
-
-
-
-Internet Engineering Task Force                                [Page 59]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-              Since nearly all networks in the Internet currently
-              support an MTU of 576 or greater, we strongly recommend
-              the use of 576 for datagrams sent to non-local networks.
-
-              It has been suggested that a host could determine the MTU
-              over a given path by sending a zero-offset datagram
-              fragment and waiting for the receiver to time out the
-              reassembly (which cannot complete!) and return an ICMP
-              Time Exceeded message.  This message would include the
-              largest remaining fragment header in its body.  More
-              direct mechanisms are being experimented with, but have
-              not yet been adopted (see e.g., RFC-1063).
-
-      3.3.4  Local Multihoming
-
-         3.3.4.1  Introduction
-
-            A multihomed host has multiple IP addresses, which we may
-            think of as "logical interfaces".  These logical interfaces
-            may be associated with one or more physical interfaces, and
-            these physical interfaces may be connected to the same or
-            different networks.
-
-            Here are some important cases of multihoming:
-
-            (a)  Multiple Logical Networks
-
-                 The Internet architects envisioned that each physical
-                 network would have a single unique IP network (or
-                 subnet) number.  However, LAN administrators have
-                 sometimes found it useful to violate this assumption,
-                 operating a LAN with multiple logical networks per
-                 physical connected network.
-
-                 If a host connected to such a physical network is
-                 configured to handle traffic for each of N different
-                 logical networks, then the host will have N logical
-                 interfaces.  These could share a single physical
-                 interface, or might use N physical interfaces to the
-                 same network.
-
-            (b)  Multiple Logical Hosts
-
-                 When a host has multiple IP addresses that all have the
-                 same <Network-number> part (and the same <Subnet-
-                 number> part, if any), the logical interfaces are known
-                 as "logical hosts".  These logical interfaces might
-                 share a single physical interface or might use separate
-
-
-
-Internet Engineering Task Force                                [Page 60]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 physical interfaces to the same physical network.
-
-            (c)  Simple Multihoming
-
-                 In this case, each logical interface is mapped into a
-                 separate physical interface and each physical interface
-                 is connected to a different physical network.  The term
-                 "multihoming" was originally applied only to this case,
-                 but it is now applied more generally.
-
-                 A host with embedded gateway functionality will
-                 typically fall into the simple multihoming case.  Note,
-                 however, that a host may be simply multihomed without
-                 containing an embedded gateway, i.e., without
-                 forwarding datagrams from one connected network to
-                 another.
-
-                 This case presents the most difficult routing problems.
-                 The choice of interface (i.e., the choice of first-hop
-                 network) may significantly affect performance or even
-                 reachability of remote parts of the Internet.
-
-
-            Finally, we note another possibility that is NOT
-            multihoming:  one logical interface may be bound to multiple
-            physical interfaces, in order to increase the reliability or
-            throughput between directly connected machines by providing
-            alternative physical paths between them.  For instance, two
-            systems might be connected by multiple point-to-point links.
-            We call this "link-layer multiplexing".  With link-layer
-            multiplexing, the protocols above the link layer are unaware
-            that multiple physical interfaces are present; the link-
-            layer device driver is responsible for multiplexing and
-            routing packets across the physical interfaces.
-
-            In the Internet protocol architecture, a transport protocol
-            instance ("entity") has no address of its own, but instead
-            uses a single Internet Protocol (IP) address.  This has
-            implications for the IP, transport, and application layers,
-            and for the interfaces between them.  In particular, the
-            application software may have to be aware of the multiple IP
-            addresses of a multihomed host; in other cases, the choice
-            can be made within the network software.
-
-         3.3.4.2  Multihoming Requirements
-
-            The following general rules apply to the selection of an IP
-            source address for sending a datagram from a multihomed
-
-
-
-Internet Engineering Task Force                                [Page 61]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            host.
-
-            (1)  If the datagram is sent in response to a received
-                 datagram, the source address for the response SHOULD be
-                 the specific-destination address of the request.  See
-                 Sections 4.1.3.5 and 4.2.3.7 and the "General Issues"
-                 section of [INTRO:1] for more specific requirements on
-                 higher layers.
-
-                 Otherwise, a source address must be selected.
-
-            (2)  An application MUST be able to explicitly specify the
-                 source address for initiating a connection or a
-                 request.
-
-            (3)  In the absence of such a specification, the networking
-                 software MUST choose a source address.  Rules for this
-                 choice are described below.
-
-
-            There are two key requirement issues related to multihoming:
-
-            (A)  A host MAY silently discard an incoming datagram whose
-                 destination address does not correspond to the physical
-                 interface through which it is received.
-
-            (B)  A host MAY restrict itself to sending (non-source-
-                 routed) IP datagrams only through the physical
-                 interface that corresponds to the IP source address of
-                 the datagrams.
-
-
-            DISCUSSION:
-                 Internet host implementors have used two different
-                 conceptual models for multihoming, briefly summarized
-                 in the following discussion.  This document takes no
-                 stand on which model is preferred; each seems to have a
-                 place.  This ambivalence is reflected in the issues (A)
-                 and (B) being optional.
-
-                 o    Strong ES Model
-
-                      The Strong ES (End System, i.e., host) model
-                      emphasizes the host/gateway (ES/IS) distinction,
-                      and would therefore substitute MUST for MAY in
-                      issues (A) and (B) above.  It tends to model a
-                      multihomed host as a set of logical hosts within
-                      the same physical host.
-
-
-
-Internet Engineering Task Force                                [Page 62]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                      With respect to (A), proponents of the Strong ES
-                      model note that automatic Internet routing
-                      mechanisms could not route a datagram to a
-                      physical interface that did not correspond to the
-                      destination address.
-
-                      Under the Strong ES model, the route computation
-                      for an outgoing datagram is the mapping:
-
-                         route(src IP addr, dest IP addr, TOS)
-                                                        -> gateway
-
-                      Here the source address is included as a parameter
-                      in order to select a gateway that is directly
-                      reachable on the corresponding physical interface.
-                      Note that this model logically requires that in
-                      general there be at least one default gateway, and
-                      preferably multiple defaults, for each IP source
-                      address.
-
-                 o    Weak ES Model
-
-                      This view de-emphasizes the ES/IS distinction, and
-                      would therefore substitute MUST NOT for MAY in
-                      issues (A) and (B).  This model may be the more
-                      natural one for hosts that wiretap gateway routing
-                      protocols, and is necessary for hosts that have
-                      embedded gateway functionality.
-
-                      The Weak ES Model may cause the Redirect mechanism
-                      to fail.  If a datagram is sent out a physical
-                      interface that does not correspond to the
-                      destination address, the first-hop gateway will
-                      not realize when it needs to send a Redirect.  On
-                      the other hand, if the host has embedded gateway
-                      functionality, then it has routing information
-                      without listening to Redirects.
-
-                      In the Weak ES model, the route computation for an
-                      outgoing datagram is the mapping:
-
-                         route(dest IP addr, TOS) -> gateway, interface
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 63]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         3.3.4.3  Choosing a Source Address
-
-            DISCUSSION:
-                 When it sends an initial connection request (e.g., a
-                 TCP "SYN" segment) or a datagram service request (e.g.,
-                 a UDP-based query), the transport layer on a multihomed
-                 host needs to know which source address to use.  If the
-                 application does not specify it, the transport layer
-                 must ask the IP layer to perform the conceptual
-                 mapping:
-
-                     GET_SRCADDR(remote IP addr, TOS)
-                                               -> local IP address
-
-                 Here TOS is the Type-of-Service value (see Section
-                 3.2.1.6), and the result is the desired source address.
-                 The following rules are suggested for implementing this
-                 mapping:
-
-                 (a)  If the remote Internet address lies on one of the
-                      (sub-) nets to which the host is directly
-                      connected, a corresponding source address may be
-                      chosen, unless the corresponding interface is
-                      known to be down.
-
-                 (b)  The route cache may be consulted, to see if there
-                      is an active route to the specified destination
-                      network through any network interface; if so, a
-                      local IP address corresponding to that interface
-                      may be chosen.
-
-                 (c)  The table of static routes, if any (see Section
-                      3.3.1.2) may be similarly consulted.
-
-                 (d)  The default gateways may be consulted.  If these
-                      gateways are assigned to different interfaces, the
-                      interface corresponding to the gateway with the
-                      highest preference may be chosen.
-
-                 In the future, there may be a defined way for a
-                 multihomed host to ask the gateways on all connected
-                 networks for advice about the best network to use for a
-                 given destination.
-
-            IMPLEMENTATION:
-                 It will be noted that this process is essentially the
-                 same as datagram routing (see Section 3.3.1), and
-                 therefore hosts may be able to combine the
-
-
-
-Internet Engineering Task Force                                [Page 64]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 implementation of the two functions.
-
-      3.3.5  Source Route Forwarding
-
-         Subject to restrictions given below, a host MAY be able to act
-         as an intermediate hop in a source route, forwarding a source-
-         routed datagram to the next specified hop.
-
-         However, in performing this gateway-like function, the host
-         MUST obey all the relevant rules for a gateway forwarding
-         source-routed datagrams [INTRO:2].  This includes the following
-         specific provisions, which override the corresponding host
-         provisions given earlier in this document:
-
-         (A)  TTL (ref. Section 3.2.1.7)
-
-              The TTL field MUST be decremented and the datagram perhaps
-              discarded as specified for a gateway in [INTRO:2].
-
-         (B)  ICMP Destination Unreachable (ref. Section 3.2.2.1)
-
-              A host MUST be able to generate Destination Unreachable
-              messages with the following codes:
-
-              4    (Fragmentation Required but DF Set) when a source-
-                   routed datagram cannot be fragmented to fit into the
-                   target network;
-
-              5    (Source Route Failed) when a source-routed datagram
-                   cannot be forwarded, e.g., because of a routing
-                   problem or because the next hop of a strict source
-                   route is not on a connected network.
-
-         (C)  IP Source Address (ref. Section 3.2.1.3)
-
-              A source-routed datagram being forwarded MAY (and normally
-              will) have a source address that is not one of the IP
-              addresses of the forwarding host.
-
-         (D)  Record Route Option (ref. Section 3.2.1.8d)
-
-              A host that is forwarding a source-routed datagram
-              containing a Record Route option MUST update that option,
-              if it has room.
-
-         (E)  Timestamp Option (ref. Section 3.2.1.8e)
-
-              A host that is forwarding a source-routed datagram
-
-
-
-Internet Engineering Task Force                                [Page 65]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-              containing a Timestamp Option MUST add the current
-              timestamp to that option, according to the rules for this
-              option.
-
-         To define the rules restricting host forwarding of source-
-         routed datagrams, we use the term "local source-routing" if the
-         next hop will be through the same physical interface through
-         which the datagram arrived; otherwise, it is "non-local
-         source-routing".
-
-         o    A host is permitted to perform local source-routing
-              without restriction.
-
-         o    A host that supports non-local source-routing MUST have a
-              configurable switch to disable forwarding, and this switch
-              MUST default to disabled.
-
-         o    The host MUST satisfy all gateway requirements for
-              configurable policy filters [INTRO:2] restricting non-
-              local forwarding.
-
-         If a host receives a datagram with an incomplete source route
-         but does not forward it for some reason, the host SHOULD return
-         an ICMP Destination Unreachable (code 5, Source Route Failed)
-         message, unless the datagram was itself an ICMP error message.
-
-      3.3.6  Broadcasts
-
-         Section 3.2.1.3 defined the four standard IP broadcast address
-         forms:
-
-           Limited Broadcast:  {-1, -1}
-
-           Directed Broadcast:  {<Network-number>,-1}
-
-           Subnet Directed Broadcast:
-                              {<Network-number>,<Subnet-number>,-1}
-
-           All-Subnets Directed Broadcast: {<Network-number>,-1,-1}
-
-         A host MUST recognize any of these forms in the destination
-         address of an incoming datagram.
-
-         There is a class of hosts* that use non-standard broadcast
-         address forms, substituting 0 for -1.  All hosts SHOULD
-_________________________
-*4.2BSD Unix and its derivatives, but not 4.3BSD.
-
-
-
-
-Internet Engineering Task Force                                [Page 66]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         recognize and accept any of these non-standard broadcast
-         addresses as the destination address of an incoming datagram.
-         A host MAY optionally have a configuration option to choose the
-         0 or the -1 form of broadcast address, for each physical
-         interface, but this option SHOULD default to the standard (-1)
-         form.
-
-         When a host sends a datagram to a link-layer broadcast address,
-         the IP destination address MUST be a legal IP broadcast or IP
-         multicast address.
-
-         A host SHOULD silently discard a datagram that is received via
-         a link-layer broadcast (see Section 2.4) but does not specify
-         an IP multicast or broadcast destination address.
-
-         Hosts SHOULD use the Limited Broadcast address to broadcast to
-         a connected network.
-
-
-         DISCUSSION:
-              Using the Limited Broadcast address instead of a Directed
-              Broadcast address may improve system robustness.  Problems
-              are often caused by machines that do not understand the
-              plethora of broadcast addresses (see Section 3.2.1.3), or
-              that may have different ideas about which broadcast
-              addresses are in use.  The prime example of the latter is
-              machines that do not understand subnetting but are
-              attached to a subnetted net.  Sending a Subnet Broadcast
-              for the connected network will confuse those machines,
-              which will see it as a message to some other host.
-
-              There has been discussion on whether a datagram addressed
-              to the Limited Broadcast address ought to be sent from all
-              the interfaces of a multihomed host.  This specification
-              takes no stand on the issue.
-
-      3.3.7  IP Multicasting
-
-         A host SHOULD support local IP multicasting on all connected
-         networks for which a mapping from Class D IP addresses to
-         link-layer addresses has been specified (see below).  Support
-         for local IP multicasting includes sending multicast datagrams,
-         joining multicast groups and receiving multicast datagrams, and
-         leaving multicast groups.  This implies support for all of
-         [IP:4] except the IGMP protocol itself, which is OPTIONAL.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 67]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         DISCUSSION:
-              IGMP provides gateways that are capable of multicast
-              routing with the information required to support IP
-              multicasting across multiple networks.  At this time,
-              multicast-routing gateways are in the experimental stage
-              and are not widely available.  For hosts that are not
-              connected to networks with multicast-routing gateways or
-              that do not need to receive multicast datagrams
-              originating on other networks, IGMP serves no purpose and
-              is therefore optional for now.  However, the rest of
-              [IP:4] is currently recommended for the purpose of
-              providing IP-layer access to local network multicast
-              addressing, as a preferable alternative to local broadcast
-              addressing.  It is expected that IGMP will become
-              recommended at some future date, when multicast-routing
-              gateways have become more widely available.
-
-         If IGMP is not implemented, a host SHOULD still join the "all-
-         hosts" group (224.0.0.1) when the IP layer is initialized and
-         remain a member for as long as the IP layer is active.
-
-         DISCUSSION:
-              Joining the "all-hosts" group will support strictly local
-              uses of multicasting, e.g., a gateway discovery protocol,
-              even if IGMP is not implemented.
-
-         The mapping of IP Class D addresses to local addresses is
-         currently specified for the following types of networks:
-
-         o    Ethernet/IEEE 802.3, as defined in [IP:4].
-
-         o    Any network that supports broadcast but not multicast,
-              addressing: all IP Class D addresses map to the local
-              broadcast address.
-
-         o    Any type of point-to-point link (e.g., SLIP or HDLC
-              links): no mapping required.  All IP multicast datagrams
-              are sent as-is, inside the local framing.
-
-         Mappings for other types of networks will be specified in the
-         future.
-
-         A host SHOULD provide a way for higher-layer protocols or
-         applications to determine which of the host's connected
-         network(s) support IP multicast addressing.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 68]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-      3.3.8  Error Reporting
-
-         Wherever practical, hosts MUST return ICMP error datagrams on
-         detection of an error, except in those cases where returning an
-         ICMP error message is specifically prohibited.
-
-         DISCUSSION:
-              A common phenomenon in datagram networks is the "black
-              hole disease": datagrams are sent out, but nothing comes
-              back.  Without any error datagrams, it is difficult for
-              the user to figure out what the problem is.
-
-   3.4  INTERNET/TRANSPORT LAYER INTERFACE
-
-      The interface between the IP layer and the transport layer MUST
-      provide full access to all the mechanisms of the IP layer,
-      including options, Type-of-Service, and Time-to-Live.  The
-      transport layer MUST either have mechanisms to set these interface
-      parameters, or provide a path to pass them through from an
-      application, or both.
-
-      DISCUSSION:
-           Applications are urged to make use of these mechanisms where
-           applicable, even when the mechanisms are not currently
-           effective in the Internet (e.g., TOS).  This will allow these
-           mechanisms to be immediately useful when they do become
-           effective, without a large amount of retrofitting of host
-           software.
-
-      We now describe a conceptual interface between the transport layer
-      and the IP layer, as a set of procedure calls.  This is an
-      extension of the information in Section 3.3 of RFC-791 [IP:1].
-
-
-      *    Send Datagram
-
-                SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt
-                     => result )
-
-           where the parameters are defined in RFC-791.  Passing an Id
-           parameter is optional; see Section 3.2.1.5.
-
-
-      *    Receive Datagram
-
-                RECV(BufPTR, prot
-                     => result, src, dst, SpecDest, TOS, len, opt)
-
-
-
-
-Internet Engineering Task Force                                [Page 69]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-           All the parameters are defined in RFC-791, except for:
-
-                SpecDest = specific-destination address of datagram
-                            (defined in Section 3.2.1.3)
-
-           The result parameter dst contains the datagram's destination
-           address.  Since this may be a broadcast or multicast address,
-           the SpecDest parameter (not shown in RFC-791) MUST be passed.
-           The parameter opt contains all the IP options received in the
-           datagram; these MUST also be passed to the transport layer.
-
-
-      *    Select Source Address
-
-                GET_SRCADDR(remote, TOS)  -> local
-
-                remote = remote IP address
-                TOS = Type-of-Service
-                local = local IP address
-
-           See Section 3.3.4.3.
-
-
-      *    Find Maximum Datagram Sizes
-
-                GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
-
-                MMS_R = maximum receive transport-message size.
-                MMS_S = maximum send transport-message size.
-               (local, remote, TOS defined above)
-
-           See Sections 3.3.2 and 3.3.3.
-
-
-      *    Advice on Delivery Success
-
-                ADVISE_DELIVPROB(sense, local, remote, TOS)
-
-           Here the parameter sense is a 1-bit flag indicating whether
-           positive or negative advice is being given; see the
-           discussion in Section 3.3.1.4. The other parameters were
-           defined earlier.
-
-
-      *    Send ICMP Message
-
-                SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt)
-                     -> result
-
-
-
-Internet Engineering Task Force                                [Page 70]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                (Parameters defined in RFC-791).
-
-           Passing an Id parameter is optional; see Section 3.2.1.5.
-           The transport layer MUST be able to send certain ICMP
-           messages:  Port Unreachable or any of the query-type
-           messages.  This function could be considered to be a special
-           case of the SEND() call, of course; we describe it separately
-           for clarity.
-
-
-      *    Receive ICMP Message
-
-                RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
-
-                (Parameters defined in RFC-791).
-
-           The IP layer MUST pass certain ICMP messages up to the
-           appropriate transport-layer routine.  This function could be
-           considered to be a special case of the RECV() call, of
-           course; we describe it separately for clarity.
-
-           For an ICMP error message, the data that is passed up MUST
-           include the original Internet header plus all the octets of
-           the original message that are included in the ICMP message.
-           This data will be used by the transport layer to locate the
-           connection state information, if any.
-
-           In particular, the following ICMP messages are to be passed
-           up:
-
-           o    Destination Unreachable
-
-           o    Source Quench
-
-           o    Echo Reply (to ICMP user interface, unless the Echo
-                Request originated in the IP layer)
-
-           o    Timestamp Reply (to ICMP user interface)
-
-           o    Time Exceeded
-
-
-      DISCUSSION:
-           In the future, there may be additions to this interface to
-           pass path data (see Section 3.3.1.3) between the IP and
-           transport layers.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 71]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-   3.5  INTERNET LAYER REQUIREMENTS SUMMARY
-
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-Implement IP and ICMP                            |3.1     |x| | | | |
-Handle remote multihoming in application layer   |3.1     |x| | | | |
-Support local multihoming                        |3.1     | | |x| | |
-Meet gateway specs if forward datagrams          |3.1     |x| | | | |
-Configuration switch for embedded gateway        |3.1     |x| | | | |1
-   Config switch default to non-gateway          |3.1     |x| | | | |1
-   Auto-config based on number of interfaces     |3.1     | | | | |x|1
-Able to log discarded datagrams                  |3.1     | |x| | | |
-   Record in counter                             |3.1     | |x| | | |
-                                                 |        | | | | | |
-Silently discard Version != 4                    |3.2.1.1 |x| | | | |
-Verify IP checksum, silently discard bad dgram   |3.2.1.2 |x| | | | |
-Addressing:                                      |        | | | | | |
-  Subnet addressing (RFC-950)                    |3.2.1.3 |x| | | | |
-  Src address must be host's own IP address      |3.2.1.3 |x| | | | |
-  Silently discard datagram with bad dest addr   |3.2.1.3 |x| | | | |
-  Silently discard datagram with bad src addr    |3.2.1.3 |x| | | | |
-Support reassembly                               |3.2.1.4 |x| | | | |
-Retain same Id field in identical datagram       |3.2.1.5 | | |x| | |
-                                                 |        | | | | | |
-TOS:                                             |        | | | | | |
-  Allow transport layer to set TOS               |3.2.1.6 |x| | | | |
-  Pass received TOS up to transport layer        |3.2.1.6 | |x| | | |
-  Use RFC-795 link-layer mappings for TOS        |3.2.1.6 | | | |x| |
-TTL:                                             |        | | | | | |
-  Send packet with TTL of 0                      |3.2.1.7 | | | | |x|
-  Discard received packets with TTL < 2          |3.2.1.7 | | | | |x|
-  Allow transport layer to set TTL               |3.2.1.7 |x| | | | |
-  Fixed TTL is configurable                      |3.2.1.7 |x| | | | |
-                                                 |        | | | | | |
-IP Options:                                      |        | | | | | |
-  Allow transport layer to send IP options       |3.2.1.8 |x| | | | |
-  Pass all IP options rcvd to higher layer       |3.2.1.8 |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 72]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-  IP layer silently ignore unknown options       |3.2.1.8 |x| | | | |
-  Security option                                |3.2.1.8a| | |x| | |
-  Send Stream Identifier option                  |3.2.1.8b| | | |x| |
-  Silently ignore Stream Identifer option        |3.2.1.8b|x| | | | |
-  Record Route option                            |3.2.1.8d| | |x| | |
-  Timestamp option                               |3.2.1.8e| | |x| | |
-Source Route Option:                             |        | | | | | |
-  Originate & terminate Source Route options     |3.2.1.8c|x| | | | |
-  Datagram with completed SR passed up to TL     |3.2.1.8c|x| | | | |
-  Build correct (non-redundant) return route     |3.2.1.8c|x| | | | |
-  Send multiple SR options in one header         |3.2.1.8c| | | | |x|
-                                                 |        | | | | | |
-ICMP:                                            |        | | | | | |
-  Silently discard ICMP msg with unknown type    |3.2.2   |x| | | | |
-  Include more than 8 octets of orig datagram    |3.2.2   | | |x| | |
-      Included octets same as received           |3.2.2   |x| | | | |
-  Demux ICMP Error to transport protocol         |3.2.2   |x| | | | |
-  Send ICMP error message with TOS=0             |3.2.2   | |x| | | |
-  Send ICMP error message for:                   |        | | | | | |
-   - ICMP error msg                              |3.2.2   | | | | |x|
-   - IP b'cast or IP m'cast                      |3.2.2   | | | | |x|
-   - Link-layer b'cast                           |3.2.2   | | | | |x|
-   - Non-initial fragment                        |3.2.2   | | | | |x|
-   - Datagram with non-unique src address        |3.2.2   | | | | |x|
-  Return ICMP error msgs (when not prohibited)   |3.3.8   |x| | | | |
-                                                 |        | | | | | |
-  Dest Unreachable:                              |        | | | | | |
-    Generate Dest Unreachable (code 2/3)         |3.2.2.1 | |x| | | |
-    Pass ICMP Dest Unreachable to higher layer   |3.2.2.1 |x| | | | |
-    Higher layer act on Dest Unreach             |3.2.2.1 | |x| | | |
-      Interpret Dest Unreach as only hint        |3.2.2.1 |x| | | | |
-  Redirect:                                      |        | | | | | |
-    Host send Redirect                           |3.2.2.2 | | | |x| |
-    Update route cache when recv Redirect        |3.2.2.2 |x| | | | |
-    Handle both Host and Net Redirects           |3.2.2.2 |x| | | | |
-    Discard illegal Redirect                     |3.2.2.2 | |x| | | |
-  Source Quench:                                 |        | | | | | |
-    Send Source Quench if buffering exceeded     |3.2.2.3 | | |x| | |
-    Pass Source Quench to higher layer           |3.2.2.3 |x| | | | |
-    Higher layer act on Source Quench            |3.2.2.3 | |x| | | |
-  Time Exceeded: pass to higher layer            |3.2.2.4 |x| | | | |
-  Parameter Problem:                             |        | | | | | |
-    Send Parameter Problem messages              |3.2.2.5 | |x| | | |
-    Pass Parameter Problem to higher layer       |3.2.2.5 |x| | | | |
-    Report Parameter Problem to user             |3.2.2.5 | | |x| | |
-                                                 |        | | | | | |
-  ICMP Echo Request or Reply:                    |        | | | | | |
-    Echo server and Echo client                  |3.2.2.6 |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 73]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-    Echo client                                  |3.2.2.6 | |x| | | |
-    Discard Echo Request to broadcast address    |3.2.2.6 | | |x| | |
-    Discard Echo Request to multicast address    |3.2.2.6 | | |x| | |
-    Use specific-dest addr as Echo Reply src     |3.2.2.6 |x| | | | |
-    Send same data in Echo Reply                 |3.2.2.6 |x| | | | |
-    Pass Echo Reply to higher layer              |3.2.2.6 |x| | | | |
-    Reflect Record Route, Time Stamp options     |3.2.2.6 | |x| | | |
-    Reverse and reflect Source Route option      |3.2.2.6 |x| | | | |
-                                                 |        | | | | | |
-  ICMP Information Request or Reply:             |3.2.2.7 | | | |x| |
-  ICMP Timestamp and Timestamp Reply:            |3.2.2.8 | | |x| | |
-    Minimize delay variability                   |3.2.2.8 | |x| | | |1
-    Silently discard b'cast Timestamp            |3.2.2.8 | | |x| | |1
-    Silently discard m'cast Timestamp            |3.2.2.8 | | |x| | |1
-    Use specific-dest addr as TS Reply src       |3.2.2.8 |x| | | | |1
-    Reflect Record Route, Time Stamp options     |3.2.2.6 | |x| | | |1
-    Reverse and reflect Source Route option      |3.2.2.8 |x| | | | |1
-    Pass Timestamp Reply to higher layer         |3.2.2.8 |x| | | | |1
-    Obey rules for "standard value"              |3.2.2.8 |x| | | | |1
-                                                 |        | | | | | |
-  ICMP Address Mask Request and Reply:           |        | | | | | |
-    Addr Mask source configurable                |3.2.2.9 |x| | | | |
-    Support static configuration of addr mask    |3.2.2.9 |x| | | | |
-    Get addr mask dynamically during booting     |3.2.2.9 | | |x| | |
-    Get addr via ICMP Addr Mask Request/Reply    |3.2.2.9 | | |x| | |
-      Retransmit Addr Mask Req if no Reply       |3.2.2.9 |x| | | | |3
-      Assume default mask if no Reply            |3.2.2.9 | |x| | | |3
-      Update address mask from first Reply only  |3.2.2.9 |x| | | | |3
-    Reasonableness check on Addr Mask            |3.2.2.9 | |x| | | |
-    Send unauthorized Addr Mask Reply msgs       |3.2.2.9 | | | | |x|
-      Explicitly configured to be agent          |3.2.2.9 |x| | | | |
-    Static config=> Addr-Mask-Authoritative flag |3.2.2.9 | |x| | | |
-      Broadcast Addr Mask Reply when init.       |3.2.2.9 |x| | | | |3
-                                                 |        | | | | | |
-ROUTING OUTBOUND DATAGRAMS:                      |        | | | | | |
-  Use address mask in local/remote decision      |3.3.1.1 |x| | | | |
-  Operate with no gateways on conn network       |3.3.1.1 |x| | | | |
-  Maintain "route cache" of next-hop gateways    |3.3.1.2 |x| | | | |
-  Treat Host and Net Redirect the same           |3.3.1.2 | |x| | | |
-  If no cache entry, use default gateway         |3.3.1.2 |x| | | | |
-    Support multiple default gateways            |3.3.1.2 |x| | | | |
-  Provide table of static routes                 |3.3.1.2 | | |x| | |
-    Flag: route overridable by Redirects         |3.3.1.2 | | |x| | |
-  Key route cache on host, not net address       |3.3.1.3 | | |x| | |
-  Include TOS in route cache                     |3.3.1.3 | |x| | | |
-                                                 |        | | | | | |
-  Able to detect failure of next-hop gateway     |3.3.1.4 |x| | | | |
-  Assume route is good forever                   |3.3.1.4 | | | |x| |
-
-
-
-Internet Engineering Task Force                                [Page 74]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-  Ping gateways continuously                     |3.3.1.4 | | | | |x|
-  Ping only when traffic being sent              |3.3.1.4 |x| | | | |
-  Ping only when no positive indication          |3.3.1.4 |x| | | | |
-  Higher and lower layers give advice            |3.3.1.4 | |x| | | |
-  Switch from failed default g'way to another    |3.3.1.5 |x| | | | |
-  Manual method of entering config info          |3.3.1.6 |x| | | | |
-                                                 |        | | | | | |
-REASSEMBLY and FRAGMENTATION:                    |        | | | | | |
-  Able to reassemble incoming datagrams          |3.3.2   |x| | | | |
-    At least 576 byte datagrams                  |3.3.2   |x| | | | |
-    EMTU_R configurable or indefinite            |3.3.2   | |x| | | |
-  Transport layer able to learn MMS_R            |3.3.2   |x| | | | |
-  Send ICMP Time Exceeded on reassembly timeout  |3.3.2   |x| | | | |
-    Fixed reassembly timeout value               |3.3.2   | |x| | | |
-                                                 |        | | | | | |
-  Pass MMS_S to higher layers                    |3.3.3   |x| | | | |
-  Local fragmentation of outgoing packets        |3.3.3   | | |x| | |
-     Else don't send bigger than MMS_S           |3.3.3   |x| | | | |
-  Send max 576 to off-net destination            |3.3.3   | |x| | | |
-  All-Subnets-MTU configuration flag             |3.3.3   | | |x| | |
-                                                 |        | | | | | |
-MULTIHOMING:                                     |        | | | | | |
-  Reply with same addr as spec-dest addr         |3.3.4.2 | |x| | | |
-  Allow application to choose local IP addr      |3.3.4.2 |x| | | | |
-  Silently discard d'gram in "wrong" interface   |3.3.4.2 | | |x| | |
-  Only send d'gram through "right" interface     |3.3.4.2 | | |x| | |4
-                                                 |        | | | | | |
-SOURCE-ROUTE FORWARDING:                         |        | | | | | |
-  Forward datagram with Source Route option      |3.3.5   | | |x| | |1
-    Obey corresponding gateway rules             |3.3.5   |x| | | | |1
-      Update TTL by gateway rules                |3.3.5   |x| | | | |1
-      Able to generate ICMP err code 4, 5        |3.3.5   |x| | | | |1
-      IP src addr not local host                 |3.3.5   | | |x| | |1
-      Update Timestamp, Record Route options     |3.3.5   |x| | | | |1
-    Configurable switch for non-local SRing      |3.3.5   |x| | | | |1
-      Defaults to OFF                            |3.3.5   |x| | | | |1
-    Satisfy gwy access rules for non-local SRing |3.3.5   |x| | | | |1
-    If not forward, send Dest Unreach (cd 5)     |3.3.5   | |x| | | |2
-                                                 |        | | | | | |
-BROADCAST:                                       |        | | | | | |
-  Broadcast addr as IP source addr               |3.2.1.3 | | | | |x|
-  Receive 0 or -1 broadcast formats OK           |3.3.6   | |x| | | |
-  Config'ble option to send 0 or -1 b'cast       |3.3.6   | | |x| | |
-    Default to -1 broadcast                      |3.3.6   | |x| | | |
-  Recognize all broadcast address formats        |3.3.6   |x| | | | |
-  Use IP b'cast/m'cast addr in link-layer b'cast |3.3.6   |x| | | | |
-  Silently discard link-layer-only b'cast dg's   |3.3.6   | |x| | | |
-  Use Limited Broadcast addr for connected net   |3.3.6   | |x| | | |
-
-
-
-Internet Engineering Task Force                                [Page 75]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                                                 |        | | | | | |
-MULTICAST:                                       |        | | | | | |
-  Support local IP multicasting (RFC-1112)       |3.3.7   | |x| | | |
-  Support IGMP (RFC-1112)                        |3.3.7   | | |x| | |
-  Join all-hosts group at startup                |3.3.7   | |x| | | |
-  Higher layers learn i'face m'cast capability   |3.3.7   | |x| | | |
-                                                 |        | | | | | |
-INTERFACE:                                       |        | | | | | |
-  Allow transport layer to use all IP mechanisms |3.4     |x| | | | |
-  Pass interface ident up to transport layer     |3.4     |x| | | | |
-  Pass all IP options up to transport layer      |3.4     |x| | | | |
-  Transport layer can send certain ICMP messages |3.4     |x| | | | |
-  Pass spec'd ICMP messages up to transp. layer  |3.4     |x| | | | |
-     Include IP hdr+8 octets or more from orig.  |3.4     |x| | | | |
-  Able to leap tall buildings at a single bound  |3.5     | |x| | | |
-
-Footnotes:
-
-(1)  Only if feature is implemented.
-
-(2)  This requirement is overruled if datagram is an ICMP error message.
-
-(3)  Only if feature is implemented and is configured "on".
-
-(4)  Unless has embedded gateway functionality or is source routed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 76]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
-4. TRANSPORT PROTOCOLS
-
-   4.1  USER DATAGRAM PROTOCOL -- UDP
-
-      4.1.1  INTRODUCTION
-
-         The User Datagram Protocol UDP [UDP:1] offers only a minimal
-         transport service -- non-guaranteed datagram delivery -- and
-         gives applications direct access to the datagram service of the
-         IP layer.  UDP is used by applications that do not require the
-         level of service of TCP or that wish to use communications
-         services (e.g., multicast or broadcast delivery) not available
-         from TCP.
-
-         UDP is almost a null protocol; the only services it provides
-         over IP are checksumming of data and multiplexing by port
-         number.  Therefore, an application program running over UDP
-         must deal directly with end-to-end communication problems that
-         a connection-oriented protocol would have handled -- e.g.,
-         retransmission for reliable delivery, packetization and
-         reassembly, flow control, congestion avoidance, etc., when
-         these are required.  The fairly complex coupling between IP and
-         TCP will be mirrored in the coupling between UDP and many
-         applications using UDP.
-
-      4.1.2  PROTOCOL WALK-THROUGH
-
-         There are no known errors in the specification of UDP.
-
-      4.1.3  SPECIFIC ISSUES
-
-         4.1.3.1  Ports
-
-            UDP well-known ports follow the same rules as TCP well-known
-            ports; see Section 4.2.2.1 below.
-
-            If a datagram arrives addressed to a UDP port for which
-            there is no pending LISTEN call, UDP SHOULD send an ICMP
-            Port Unreachable message.
-
-         4.1.3.2  IP Options
-
-            UDP MUST pass any IP option that it receives from the IP
-            layer transparently to the application layer.
-
-            An application MUST be able to specify IP options to be sent
-            in its UDP datagrams, and UDP MUST pass these options to the
-            IP layer.
-
-
-
-Internet Engineering Task Force                                [Page 77]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
-            DISCUSSION:
-                 At present, the only options that need be passed
-                 through UDP are Source Route, Record Route, and Time
-                 Stamp.  However, new options may be defined in the
-                 future, and UDP need not and should not make any
-                 assumptions about the format or content of options it
-                 passes to or from the application; an exception to this
-                 might be an IP-layer security option.
-
-                 An application based on UDP will need to obtain a
-                 source route from a request datagram and supply a
-                 reversed route for sending the corresponding reply.
-
-         4.1.3.3  ICMP Messages
-
-            UDP MUST pass to the application layer all ICMP error
-            messages that it receives from the IP layer.  Conceptually
-            at least, this may be accomplished with an upcall to the
-            ERROR_REPORT routine (see Section 4.2.4.1).
-
-            DISCUSSION:
-                 Note that ICMP error messages resulting from sending a
-                 UDP datagram are received asynchronously.  A UDP-based
-                 application that wants to receive ICMP error messages
-                 is responsible for maintaining the state necessary to
-                 demultiplex these messages when they arrive; for
-                 example, the application may keep a pending receive
-                 operation for this purpose.  The application is also
-                 responsible to avoid confusion from a delayed ICMP
-                 error message resulting from an earlier use of the same
-                 port(s).
-
-         4.1.3.4  UDP Checksums
-
-            A host MUST implement the facility to generate and validate
-            UDP checksums.  An application MAY optionally be able to
-            control whether a UDP checksum will be generated, but it
-            MUST default to checksumming on.
-
-            If a UDP datagram is received with a checksum that is non-
-            zero and invalid, UDP MUST silently discard the datagram.
-            An application MAY optionally be able to control whether UDP
-            datagrams without checksums should be discarded or passed to
-            the application.
-
-            DISCUSSION:
-                 Some applications that normally run only across local
-                 area networks have chosen to turn off UDP checksums for
-
-
-
-Internet Engineering Task Force                                [Page 78]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
-                 efficiency.  As a result, numerous cases of undetected
-                 errors have been reported.  The advisability of ever
-                 turning off UDP checksumming is very controversial.
-
-            IMPLEMENTATION:
-                 There is a common implementation error in UDP
-                 checksums.  Unlike the TCP checksum, the UDP checksum
-                 is optional; the value zero is transmitted in the
-                 checksum field of a UDP header to indicate the absence
-                 of a checksum.  If the transmitter really calculates a
-                 UDP checksum of zero, it must transmit the checksum as
-                 all 1's (65535).  No special action is required at the
-                 receiver, since zero and 65535 are equivalent in 1's
-                 complement arithmetic.
-
-         4.1.3.5  UDP Multihoming
-
-            When a UDP datagram is received, its specific-destination
-            address MUST be passed up to the application layer.
-
-            An application program MUST be able to specify the IP source
-            address to be used for sending a UDP datagram or to leave it
-            unspecified (in which case the networking software will
-            choose an appropriate source address).  There SHOULD be a
-            way to communicate the chosen source address up to the
-            application layer (e.g, so that the application can later
-            receive a reply datagram only from the corresponding
-            interface).
-
-            DISCUSSION:
-                 A request/response application that uses UDP should use
-                 a source address for the response that is the same as
-                 the specific destination address of the request.  See
-                 the "General Issues" section of [INTRO:1].
-
-         4.1.3.6  Invalid Addresses
-
-            A UDP datagram received with an invalid IP source address
-            (e.g., a broadcast or multicast address) must be discarded
-            by UDP or by the IP layer (see Section 3.2.1.3).
-
-            When a host sends a UDP datagram, the source address MUST be
-            (one of) the IP address(es) of the host.
-
-      4.1.4  UDP/APPLICATION LAYER INTERFACE
-
-         The application interface to UDP MUST provide the full services
-         of the IP/transport interface described in Section 3.4 of this
-
-
-
-Internet Engineering Task Force                                [Page 79]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
-         document.  Thus, an application using UDP needs the functions
-         of the GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB(), and
-         RECV_ICMP() calls described in Section 3.4.  For example,
-         GET_MAXSIZES() can be used to learn the effective maximum UDP
-         maximum datagram size for a particular {interface,remote
-         host,TOS} triplet.
-
-         An application-layer program MUST be able to set the TTL and
-         TOS values as well as IP options for sending a UDP datagram,
-         and these values must be passed transparently to the IP layer.
-         UDP MAY pass the received TOS up to the application layer.
-
-      4.1.5  UDP REQUIREMENTS SUMMARY
-
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-    UDP                                          |        | | | | | |
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-UDP send Port Unreachable                        |4.1.3.1 | |x| | | |
-                                                 |        | | | | | |
-IP Options in UDP                                |        | | | | | |
- - Pass rcv'd IP options to applic layer         |4.1.3.2 |x| | | | |
- - Applic layer can specify IP options in Send   |4.1.3.2 |x| | | | |
- - UDP passes IP options down to IP layer        |4.1.3.2 |x| | | | |
-                                                 |        | | | | | |
-Pass ICMP msgs up to applic layer                |4.1.3.3 |x| | | | |
-                                                 |        | | | | | |
-UDP checksums:                                   |        | | | | | |
- - Able to generate/check checksum               |4.1.3.4 |x| | | | |
- - Silently discard bad checksum                 |4.1.3.4 |x| | | | |
- - Sender Option to not generate checksum        |4.1.3.4 | | |x| | |
-   - Default is to checksum                      |4.1.3.4 |x| | | | |
- - Receiver Option to require checksum           |4.1.3.4 | | |x| | |
-                                                 |        | | | | | |
-UDP Multihoming                                  |        | | | | | |
- - Pass spec-dest addr to application            |4.1.3.5 |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 80]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
- - Applic layer can specify Local IP addr        |4.1.3.5 |x| | | | |
- - Applic layer specify wild Local IP addr       |4.1.3.5 |x| | | | |
- - Applic layer notified of Local IP addr used   |4.1.3.5 | |x| | | |
-                                                 |        | | | | | |
-Bad IP src addr silently discarded by UDP/IP     |4.1.3.6 |x| | | | |
-Only send valid IP source address                |4.1.3.6 |x| | | | |
-UDP Application Interface Services               |        | | | | | |
-Full IP interface of 3.4 for application         |4.1.4   |x| | | | |
- - Able to spec TTL, TOS, IP opts when send dg   |4.1.4   |x| | | | |
- - Pass received TOS up to applic layer          |4.1.4   | | |x| | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 81]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-   4.2  TRANSMISSION CONTROL PROTOCOL -- TCP
-
-      4.2.1  INTRODUCTION
-
-         The Transmission Control Protocol TCP [TCP:1] is the primary
-         virtual-circuit transport protocol for the Internet suite.  TCP
-         provides reliable, in-sequence delivery of a full-duplex stream
-         of octets (8-bit bytes).  TCP is used by those applications
-         needing reliable, connection-oriented transport service, e.g.,
-         mail (SMTP), file transfer (FTP), and virtual terminal service
-         (Telnet); requirements for these application-layer protocols
-         are described in [INTRO:1].
-
-      4.2.2  PROTOCOL WALK-THROUGH
-
-         4.2.2.1  Well-Known Ports: RFC-793 Section 2.7
-
-            DISCUSSION:
-                 TCP reserves port numbers in the range 0-255 for
-                 "well-known" ports, used to access services that are
-                 standardized across the Internet.  The remainder of the
-                 port space can be freely allocated to application
-                 processes.  Current well-known port definitions are
-                 listed in the RFC entitled "Assigned Numbers"
-                 [INTRO:6].  A prerequisite for defining a new well-
-                 known port is an RFC documenting the proposed service
-                 in enough detail to allow new implementations.
-
-                 Some systems extend this notion by adding a third
-                 subdivision of the TCP port space: reserved ports,
-                 which are generally used for operating-system-specific
-                 services.  For example, reserved ports might fall
-                 between 256 and some system-dependent upper limit.
-                 Some systems further choose to protect well-known and
-                 reserved ports by permitting only privileged users to
-                 open TCP connections with those port values.  This is
-                 perfectly reasonable as long as the host does not
-                 assume that all hosts protect their low-numbered ports
-                 in this manner.
-
-         4.2.2.2  Use of Push: RFC-793 Section 2.8
-
-            When an application issues a series of SEND calls without
-            setting the PUSH flag, the TCP MAY aggregate the data
-            internally without sending it.  Similarly, when a series of
-            segments is received without the PSH bit, a TCP MAY queue
-            the data internally without passing it to the receiving
-            application.
-
-
-
-Internet Engineering Task Force                                [Page 82]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            The PSH bit is not a record marker and is independent of
-            segment boundaries.  The transmitter SHOULD collapse
-            successive PSH bits when it packetizes data, to send the
-            largest possible segment.
-
-            A TCP MAY implement PUSH flags on SEND calls.  If PUSH flags
-            are not implemented, then the sending TCP: (1) must not
-            buffer data indefinitely, and (2) MUST set the PSH bit in
-            the last buffered segment (i.e., when there is no more
-            queued data to be sent).
-
-            The discussion in RFC-793 on pages 48, 50, and 74
-            erroneously implies that a received PSH flag must be passed
-            to the application layer.  Passing a received PSH flag to
-            the application layer is now OPTIONAL.
-
-            An application program is logically required to set the PUSH
-            flag in a SEND call whenever it needs to force delivery of
-            the data to avoid a communication deadlock.  However, a TCP
-            SHOULD send a maximum-sized segment whenever possible, to
-            improve performance (see Section 4.2.3.4).
-
-            DISCUSSION:
-                 When the PUSH flag is not implemented on SEND calls,
-                 i.e., when the application/TCP interface uses a pure
-                 streaming model, responsibility for aggregating any
-                 tiny data fragments to form reasonable sized segments
-                 is partially borne by the application layer.
-
-                 Generally, an interactive application protocol must set
-                 the PUSH flag at least in the last SEND call in each
-                 command or response sequence.  A bulk transfer protocol
-                 like FTP should set the PUSH flag on the last segment
-                 of a file or when necessary to prevent buffer deadlock.
-
-                 At the receiver, the PSH bit forces buffered data to be
-                 delivered to the application (even if less than a full
-                 buffer has been received). Conversely, the lack of a
-                 PSH bit can be used to avoid unnecessary wakeup calls
-                 to the application process; this can be an important
-                 performance optimization for large timesharing hosts.
-                 Passing the PSH bit to the receiving application allows
-                 an analogous optimization within the application.
-
-         4.2.2.3  Window Size: RFC-793 Section 3.1
-
-            The window size MUST be treated as an unsigned number, or
-            else large window sizes will appear like negative windows
-
-
-
-Internet Engineering Task Force                                [Page 83]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            and TCP will not work.  It is RECOMMENDED that
-            implementations reserve 32-bit fields for the send and
-            receive window sizes in the connection record and do all
-            window computations with 32 bits.
-
-            DISCUSSION:
-                 It is known that the window field in the TCP header is
-                 too small for high-speed, long-delay paths.
-                 Experimental TCP options have been defined to extend
-                 the window size; see for example [TCP:11].  In
-                 anticipation of the adoption of such an extension, TCP
-                 implementors should treat windows as 32 bits.
-
-         4.2.2.4  Urgent Pointer: RFC-793 Section 3.1
-
-            The second sentence is in error: the urgent pointer points
-            to the sequence number of the LAST octet (not LAST+1) in a
-            sequence of urgent data.  The description on page 56 (last
-            sentence) is correct.
-
-            A TCP MUST support a sequence of urgent data of any length.
-
-            A TCP MUST inform the application layer asynchronously
-            whenever it receives an Urgent pointer and there was
-            previously no pending urgent data, or whenever the Urgent
-            pointer advances in the data stream.  There MUST be a way
-            for the application to learn how much urgent data remains to
-            be read from the connection, or at least to determine
-            whether or not more urgent data remains to be read.
-
-            DISCUSSION:
-                 Although the Urgent mechanism may be used for any
-                 application, it is normally used to send "interrupt"-
-                 type commands to a Telnet program (see "Using Telnet
-                 Synch Sequence" section in [INTRO:1]).
-
-                 The asynchronous or "out-of-band" notification will
-                 allow the application to go into "urgent mode", reading
-                 data from the TCP connection.  This allows control
-                 commands to be sent to an application whose normal
-                 input buffers are full of unprocessed data.
-
-            IMPLEMENTATION:
-                 The generic ERROR-REPORT() upcall described in Section
-                 4.2.4.1 is a possible mechanism for informing the
-                 application of the arrival of urgent data.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 84]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-         4.2.2.5  TCP Options: RFC-793 Section 3.1
-
-            A TCP MUST be able to receive a TCP option in any segment.
-            A TCP MUST ignore without error any TCP option it does not
-            implement, assuming that the option has a length field (all
-            TCP options defined in the future will have length fields).
-            TCP MUST be prepared to handle an illegal option length
-            (e.g., zero) without crashing; a suggested procedure is to
-            reset the connection and log the reason.
-
-         4.2.2.6  Maximum Segment Size Option: RFC-793 Section 3.1
-
-            TCP MUST implement both sending and receiving the Maximum
-            Segment Size option [TCP:4].
-
-            TCP SHOULD send an MSS (Maximum Segment Size) option in
-            every SYN segment when its receive MSS differs from the
-            default 536, and MAY send it always.
-
-            If an MSS option is not received at connection setup, TCP
-            MUST assume a default send MSS of 536 (576-40) [TCP:4].
-
-            The maximum size of a segment that TCP really sends, the
-            "effective send MSS," MUST be the smaller of the send MSS
-            (which reflects the available reassembly buffer size at the
-            remote host) and the largest size permitted by the IP layer:
-
-               Eff.snd.MSS =
-
-                  min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize
-
-            where:
-
-            *    SendMSS is the MSS value received from the remote host,
-                 or the default 536 if no MSS option is received.
-
-            *    MMS_S is the maximum size for a transport-layer message
-                 that TCP may send.
-
-            *    TCPhdrsize is the size of the TCP header; this is
-                 normally 20, but may be larger if TCP options are to be
-                 sent.
-
-            *    IPoptionsize is the size of any IP options that TCP
-                 will pass to the IP layer with the current message.
-
-
-            The MSS value to be sent in an MSS option must be less than
-
-
-
-Internet Engineering Task Force                                [Page 85]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            or equal to:
-
-               MMS_R - 20
-
-            where MMS_R is the maximum size for a transport-layer
-            message that can be received (and reassembled).  TCP obtains
-            MMS_R and MMS_S from the IP layer; see the generic call
-            GET_MAXSIZES in Section 3.4.
-
-            DISCUSSION:
-                 The choice of TCP segment size has a strong effect on
-                 performance.  Larger segments increase throughput by
-                 amortizing header size and per-datagram processing
-                 overhead over more data bytes; however, if the packet
-                 is so large that it causes IP fragmentation, efficiency
-                 drops sharply if any fragments are lost [IP:9].
-
-                 Some TCP implementations send an MSS option only if the
-                 destination host is on a non-connected network.
-                 However, in general the TCP layer may not have the
-                 appropriate information to make this decision, so it is
-                 preferable to leave to the IP layer the task of
-                 determining a suitable MTU for the Internet path.  We
-                 therefore recommend that TCP always send the option (if
-                 not 536) and that the IP layer determine MMS_R as
-                 specified in 3.3.3 and 3.4.  A proposed IP-layer
-                 mechanism to measure the MTU would then modify the IP
-                 layer without changing TCP.
-
-         4.2.2.7  TCP Checksum: RFC-793 Section 3.1
-
-            Unlike the UDP checksum (see Section 4.1.3.4), the TCP
-            checksum is never optional.  The sender MUST generate it and
-            the receiver MUST check it.
-
-         4.2.2.8  TCP Connection State Diagram: RFC-793 Section 3.2,
-            page 23
-
-            There are several problems with this diagram:
-
-            (a)  The arrow from SYN-SENT to SYN-RCVD should be labeled
-                 with "snd SYN,ACK", to agree with the text on page 68
-                 and with Figure 8.
-
-            (b)  There could be an arrow from SYN-RCVD state to LISTEN
-                 state, conditioned on receiving a RST after a passive
-                 open (see text page 70).
-
-
-
-
-Internet Engineering Task Force                                [Page 86]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            (c)  It is possible to go directly from FIN-WAIT-1 to the
-                 TIME-WAIT state (see page 75 of the spec).
-
-
-         4.2.2.9  Initial Sequence Number Selection: RFC-793 Section
-            3.3, page 27
-
-            A TCP MUST use the specified clock-driven selection of
-            initial sequence numbers.
-
-         4.2.2.10  Simultaneous Open Attempts: RFC-793 Section 3.4, page
-            32
-
-            There is an error in Figure 8: the packet on line 7 should
-            be identical to the packet on line 5.
-
-            A TCP MUST support simultaneous open attempts.
-
-            DISCUSSION:
-                 It sometimes surprises implementors that if two
-                 applications attempt to simultaneously connect to each
-                 other, only one connection is generated instead of two.
-                 This was an intentional design decision; don't try to
-                 "fix" it.
-
-         4.2.2.11  Recovery from Old Duplicate SYN: RFC-793 Section 3.4,
-            page 33
-
-            Note that a TCP implementation MUST keep track of whether a
-            connection has reached SYN_RCVD state as the result of a
-            passive OPEN or an active OPEN.
-
-         4.2.2.12  RST Segment: RFC-793 Section 3.4
-
-            A TCP SHOULD allow a received RST segment to include data.
-
-            DISCUSSION
-                 It has been suggested that a RST segment could contain
-                 ASCII text that encoded and explained the cause of the
-                 RST.  No standard has yet been established for such
-                 data.
-
-         4.2.2.13  Closing a Connection: RFC-793 Section 3.5
-
-            A TCP connection may terminate in two ways: (1) the normal
-            TCP close sequence using a FIN handshake, and (2) an "abort"
-            in which one or more RST segments are sent and the
-            connection state is immediately discarded.  If a TCP
-
-
-
-Internet Engineering Task Force                                [Page 87]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            connection is closed by the remote site, the local
-            application MUST be informed whether it closed normally or
-            was aborted.
-
-            The normal TCP close sequence delivers buffered data
-            reliably in both directions.  Since the two directions of a
-            TCP connection are closed independently, it is possible for
-            a connection to be "half closed," i.e., closed in only one
-            direction, and a host is permitted to continue sending data
-            in the open direction on a half-closed connection.
-
-            A host MAY implement a "half-duplex" TCP close sequence, so
-            that an application that has called CLOSE cannot continue to
-            read data from the connection.  If such a host issues a
-            CLOSE call while received data is still pending in TCP, or
-            if new data is received after CLOSE is called, its TCP
-            SHOULD send a RST to show that data was lost.
-
-            When a connection is closed actively, it MUST linger in
-            TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
-            However, it MAY accept a new SYN from the remote TCP to
-            reopen the connection directly from TIME-WAIT state, if it:
-
-            (1)  assigns its initial sequence number for the new
-                 connection to be larger than the largest sequence
-                 number it used on the previous connection incarnation,
-                 and
-
-            (2)  returns to TIME-WAIT state if the SYN turns out to be
-                 an old duplicate.
-
-
-            DISCUSSION:
-                 TCP's full-duplex data-preserving close is a feature
-                 that is not included in the analogous ISO transport
-                 protocol TP4.
-
-                 Some systems have not implemented half-closed
-                 connections, presumably because they do not fit into
-                 the I/O model of their particular operating system.  On
-                 these systems, once an application has called CLOSE, it
-                 can no longer read input data from the connection; this
-                 is referred to as a "half-duplex" TCP close sequence.
-
-                 The graceful close algorithm of TCP requires that the
-                 connection state remain defined on (at least)  one end
-                 of the connection, for a timeout period of 2xMSL, i.e.,
-                 4 minutes.  During this period, the (remote socket,
-
-
-
-Internet Engineering Task Force                                [Page 88]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 local socket) pair that defines the connection is busy
-                 and cannot be reused.  To shorten the time that a given
-                 port pair is tied up, some TCPs allow a new SYN to be
-                 accepted in TIME-WAIT state.
-
-         4.2.2.14  Data Communication: RFC-793 Section 3.7, page 40
-
-            Since RFC-793 was written, there has been extensive work on
-            TCP algorithms to achieve efficient data communication.
-            Later sections of the present document describe required and
-            recommended TCP algorithms to determine when to send data
-            (Section 4.2.3.4), when to send an acknowledgment (Section
-            4.2.3.2), and when to update the window (Section 4.2.3.3).
-
-            DISCUSSION:
-                 One important performance issue is "Silly Window
-                 Syndrome" or "SWS" [TCP:5], a stable pattern of small
-                 incremental window movements resulting in extremely
-                 poor TCP performance.  Algorithms to avoid SWS are
-                 described below for both the sending side (Section
-                 4.2.3.4) and the receiving side (Section 4.2.3.3).
-
-                 In brief, SWS is caused by the receiver advancing the
-                 right window edge whenever it has any new buffer space
-                 available to receive data and by the sender using any
-                 incremental window, no matter how small, to send more
-                 data [TCP:5].  The result can be a stable pattern of
-                 sending tiny data segments, even though both sender and
-                 receiver have a large total buffer space for the
-                 connection.  SWS can only occur during the transmission
-                 of a large amount of data; if the connection goes
-                 quiescent, the problem will disappear.  It is caused by
-                 typical straightforward implementation of window
-                 management, but the sender and receiver algorithms
-                 given below will avoid it.
-
-                 Another important TCP performance issue is that some
-                 applications, especially remote login to character-at-
-                 a-time hosts, tend to send streams of one-octet data
-                 segments.  To avoid deadlocks, every TCP SEND call from
-                 such applications must be "pushed", either explicitly
-                 by the application or else implicitly by TCP.  The
-                 result may be a stream of TCP segments that contain one
-                 data octet each, which makes very inefficient use of
-                 the Internet and contributes to Internet congestion.
-                 The Nagle Algorithm described in Section 4.2.3.4
-                 provides a simple and effective solution to this
-                 problem.  It does have the effect of clumping
-
-
-
-Internet Engineering Task Force                                [Page 89]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 characters over Telnet connections; this may initially
-                 surprise users accustomed to single-character echo, but
-                 user acceptance has not been a problem.
-
-                 Note that the Nagle algorithm and the send SWS
-                 avoidance algorithm play complementary roles in
-                 improving performance.  The Nagle algorithm discourages
-                 sending tiny segments when the data to be sent
-                 increases in small increments, while the SWS avoidance
-                 algorithm discourages small segments resulting from the
-                 right window edge advancing in small increments.
-
-                 A careless implementation can send two or more
-                 acknowledgment segments per data segment received.  For
-                 example, suppose the receiver acknowledges every data
-                 segment immediately.  When the application program
-                 subsequently consumes the data and increases the
-                 available receive buffer space again, the receiver may
-                 send a second acknowledgment segment to update the
-                 window at the sender.  The extreme case occurs with
-                 single-character segments on TCP connections using the
-                 Telnet protocol for remote login service.  Some
-                 implementations have been observed in which each
-                 incoming 1-character segment generates three return
-                 segments: (1) the acknowledgment, (2) a one byte
-                 increase in the window, and (3) the echoed character,
-                 respectively.
-
-         4.2.2.15  Retransmission Timeout: RFC-793 Section 3.7, page 41
-
-            The algorithm suggested in RFC-793 for calculating the
-            retransmission timeout is now known to be inadequate; see
-            Section 4.2.3.1 below.
-
-            Recent work by Jacobson [TCP:7] on Internet congestion and
-            TCP retransmission stability has produced a transmission
-            algorithm combining "slow start" with "congestion
-            avoidance".  A TCP MUST implement this algorithm.
-
-            If a retransmitted packet is identical to the original
-            packet (which implies not only that the data boundaries have
-            not changed, but also that the window and acknowledgment
-            fields of the header have not changed), then the same IP
-            Identification field MAY be used (see Section 3.2.1.5).
-
-            IMPLEMENTATION:
-                 Some TCP implementors have chosen to "packetize" the
-                 data stream, i.e., to pick segment boundaries when
-
-
-
-Internet Engineering Task Force                                [Page 90]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 segments are originally sent and to queue these
-                 segments in a "retransmission queue" until they are
-                 acknowledged.  Another design (which may be simpler) is
-                 to defer packetizing until each time data is
-                 transmitted or retransmitted, so there will be no
-                 segment retransmission queue.
-
-                 In an implementation with a segment retransmission
-                 queue, TCP performance may be enhanced by repacketizing
-                 the segments awaiting acknowledgment when the first
-                 retransmission timeout occurs.  That is, the
-                 outstanding segments that fitted would be combined into
-                 one maximum-sized segment, with a new IP Identification
-                 value.  The TCP would then retain this combined segment
-                 in the retransmit queue until it was acknowledged.
-                 However, if the first two segments in the
-                 retransmission queue totalled more than one maximum-
-                 sized segment, the TCP would retransmit only the first
-                 segment using the original IP Identification field.
-
-         4.2.2.16  Managing the Window: RFC-793 Section 3.7, page 41
-
-            A TCP receiver SHOULD NOT shrink the window, i.e., move the
-            right window edge to the left.  However, a sending TCP MUST
-            be robust against window shrinking, which may cause the
-            "useable window" (see Section 4.2.3.4) to become negative.
-
-            If this happens, the sender SHOULD NOT send new data, but
-            SHOULD retransmit normally the old unacknowledged data
-            between SND.UNA and SND.UNA+SND.WND.  The sender MAY also
-            retransmit old data beyond SND.UNA+SND.WND, but SHOULD NOT
-            time out the connection if data beyond the right window edge
-            is not acknowledged.  If the window shrinks to zero, the TCP
-            MUST probe it in the standard way (see next Section).
-
-            DISCUSSION:
-                 Many TCP implementations become confused if the window
-                 shrinks from the right after data has been sent into a
-                 larger window.  Note that TCP has a heuristic to select
-                 the latest window update despite possible datagram
-                 reordering; as a result, it may ignore a window update
-                 with a smaller window than previously offered if
-                 neither the sequence number nor the acknowledgment
-                 number is increased.
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 91]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-         4.2.2.17  Probing Zero Windows: RFC-793 Section 3.7, page 42
-
-            Probing of zero (offered) windows MUST be supported.
-
-            A TCP MAY keep its offered receive window closed
-            indefinitely.  As long as the receiving TCP continues to
-            send acknowledgments in response to the probe segments, the
-            sending TCP MUST allow the connection to stay open.
-
-            DISCUSSION:
-                 It is extremely important to remember that ACK
-                 (acknowledgment) segments that contain no data are not
-                 reliably transmitted by TCP.  If zero window probing is
-                 not supported, a connection may hang forever when an
-                 ACK segment that re-opens the window is lost.
-
-                 The delay in opening a zero window generally occurs
-                 when the receiving application stops taking data from
-                 its TCP.  For example, consider a printer daemon
-                 application, stopped because the printer ran out of
-                 paper.
-
-            The transmitting host SHOULD send the first zero-window
-            probe when a zero window has existed for the retransmission
-            timeout period (see Section 4.2.2.15), and SHOULD increase
-            exponentially the interval between successive probes.
-
-            DISCUSSION:
-                 This procedure minimizes delay if the zero-window
-                 condition is due to a lost ACK segment containing a
-                 window-opening update.  Exponential backoff is
-                 recommended, possibly with some maximum interval not
-                 specified here.  This procedure is similar to that of
-                 the retransmission algorithm, and it may be possible to
-                 combine the two procedures in the implementation.
-
-         4.2.2.18  Passive OPEN Calls:  RFC-793 Section 3.8
-
-            Every passive OPEN call either creates a new connection
-            record in LISTEN state, or it returns an error; it MUST NOT
-            affect any previously created connection record.
-
-            A TCP that supports multiple concurrent users MUST provide
-            an OPEN call that will functionally allow an application to
-            LISTEN on a port while a connection block with the same
-            local port is in SYN-SENT or SYN-RECEIVED state.
-
-            DISCUSSION:
-
-
-
-Internet Engineering Task Force                                [Page 92]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 Some applications (e.g., SMTP servers) may need to
-                 handle multiple connection attempts at about the same
-                 time.  The probability of a connection attempt failing
-                 is reduced by giving the application some means of
-                 listening for a new connection at the same time that an
-                 earlier connection attempt is going through the three-
-                 way handshake.
-
-            IMPLEMENTATION:
-                 Acceptable implementations of concurrent opens may
-                 permit multiple passive OPEN calls, or they may allow
-                 "cloning" of LISTEN-state connections from a single
-                 passive OPEN call.
-
-         4.2.2.19  Time to Live: RFC-793 Section 3.9, page 52
-
-            RFC-793 specified that TCP was to request the IP layer to
-            send TCP segments with TTL = 60.  This is obsolete; the TTL
-            value used to send TCP segments MUST be configurable.  See
-            Section 3.2.1.7 for discussion.
-
-         4.2.2.20  Event Processing: RFC-793 Section 3.9
-
-            While it is not strictly required, a TCP SHOULD be capable
-            of queueing out-of-order TCP segments.  Change the "may" in
-            the last sentence of the first paragraph on page 70 to
-            "should".
-
-            DISCUSSION:
-                 Some small-host implementations have omitted segment
-                 queueing because of limited buffer space.  This
-                 omission may be expected to adversely affect TCP
-                 throughput, since loss of a single segment causes all
-                 later segments to appear to be "out of sequence".
-
-            In general, the processing of received segments MUST be
-            implemented to aggregate ACK segments whenever possible.
-            For example, if the TCP is processing a series of queued
-            segments, it MUST process them all before sending any ACK
-            segments.
-
-            Here are some detailed error corrections and notes on the
-            Event Processing section of RFC-793.
-
-            (a)  CLOSE Call, CLOSE-WAIT state, p. 61: enter LAST-ACK
-                 state, not CLOSING.
-
-            (b)  LISTEN state, check for SYN (pp. 65, 66): With a SYN
-
-
-
-Internet Engineering Task Force                                [Page 93]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 bit, if the security/compartment or the precedence is
-                 wrong for the segment, a reset is sent.  The wrong form
-                 of reset is shown in the text; it should be:
-
-                   <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
-
-
-            (c)  SYN-SENT state, Check for SYN, p. 68: When the
-                 connection enters ESTABLISHED state, the following
-                 variables must be set:
-                    SND.WND <- SEG.WND
-                    SND.WL1 <- SEG.SEQ
-                    SND.WL2 <- SEG.ACK
-
-
-            (d)  Check security and precedence, p. 71: The first heading
-                 "ESTABLISHED STATE" should really be a list of all
-                 states other than SYN-RECEIVED: ESTABLISHED, FIN-WAIT-
-                 1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, and
-                 TIME-WAIT.
-
-            (e)  Check SYN bit, p. 71:  "In SYN-RECEIVED state and if
-                 the connection was initiated with a passive OPEN, then
-                 return this connection to the LISTEN state and return.
-                 Otherwise...".
-
-            (f)  Check ACK field, SYN-RECEIVED state, p. 72: When the
-                 connection enters ESTABLISHED state, the variables
-                 listed in (c) must be set.
-
-            (g)  Check ACK field, ESTABLISHED state, p. 72: The ACK is a
-                 duplicate if SEG.ACK =< SND.UNA (the = was omitted).
-                 Similarly, the window should be updated if: SND.UNA =<
-                 SEG.ACK =< SND.NXT.
-
-            (h)  USER TIMEOUT, p. 77:
-
-                 It would be better to notify the application of the
-                 timeout rather than letting TCP force the connection
-                 closed.  However, see also Section 4.2.3.5.
-
-
-         4.2.2.21  Acknowledging Queued Segments: RFC-793 Section 3.9
-
-            A TCP MAY send an ACK segment acknowledging RCV.NXT when a
-            valid segment arrives that is in the window but not at the
-            left window edge.
-
-
-
-
-Internet Engineering Task Force                                [Page 94]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            DISCUSSION:
-                 RFC-793 (see page 74) was ambiguous about whether or
-                 not an ACK segment should be sent when an out-of-order
-                 segment was received, i.e., when SEG.SEQ was unequal to
-                 RCV.NXT.
-
-                 One reason for ACKing out-of-order segments might be to
-                 support an experimental algorithm known as "fast
-                 retransmit".   With this algorithm, the sender uses the
-                 "redundant" ACK's to deduce that a segment has been
-                 lost before the retransmission timer has expired.  It
-                 counts the number of times an ACK has been received
-                 with the same value of SEG.ACK and with the same right
-                 window edge.  If more than a threshold number of such
-                 ACK's is received, then the segment containing the
-                 octets starting at SEG.ACK is assumed to have been lost
-                 and is retransmitted, without awaiting a timeout.  The
-                 threshold is chosen to compensate for the maximum
-                 likely segment reordering in the Internet.  There is
-                 not yet enough experience with the fast retransmit
-                 algorithm to determine how useful it is.
-
-      4.2.3  SPECIFIC ISSUES
-
-         4.2.3.1  Retransmission Timeout Calculation
-
-            A host TCP MUST implement Karn's algorithm and Jacobson's
-            algorithm for computing the retransmission timeout ("RTO").
-
-            o    Jacobson's algorithm for computing the smoothed round-
-                 trip ("RTT") time incorporates a simple measure of the
-                 variance [TCP:7].
-
-            o    Karn's algorithm for selecting RTT measurements ensures
-                 that ambiguous round-trip times will not corrupt the
-                 calculation of the smoothed round-trip time [TCP:6].
-
-            This implementation also MUST include "exponential backoff"
-            for successive RTO values for the same segment.
-            Retransmission of SYN segments SHOULD use the same algorithm
-            as data segments.
-
-            DISCUSSION:
-                 There were two known problems with the RTO calculations
-                 specified in RFC-793.  First, the accurate measurement
-                 of RTTs is difficult when there are retransmissions.
-                 Second, the algorithm to compute the smoothed round-
-                 trip time is inadequate [TCP:7], because it incorrectly
-
-
-
-Internet Engineering Task Force                                [Page 95]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 assumed that the variance in RTT values would be small
-                 and constant.  These problems were solved by Karn's and
-                 Jacobson's algorithm, respectively.
-
-                 The performance increase resulting from the use of
-                 these improvements varies from noticeable to dramatic.
-                 Jacobson's algorithm for incorporating the measured RTT
-                 variance is especially important on a low-speed link,
-                 where the natural variation of packet sizes causes a
-                 large variation in RTT.  One vendor found link
-                 utilization on a 9.6kb line went from 10% to 90% as a
-                 result of implementing Jacobson's variance algorithm in
-                 TCP.
-
-            The following values SHOULD be used to initialize the
-            estimation parameters for a new connection:
-
-            (a)  RTT = 0 seconds.
-
-            (b)  RTO = 3 seconds.  (The smoothed variance is to be
-                 initialized to the value that will result in this RTO).
-
-            The recommended upper and lower bounds on the RTO are known
-            to be inadequate on large internets.  The lower bound SHOULD
-            be measured in fractions of a second (to accommodate high
-            speed LANs) and the upper bound should be 2*MSL, i.e., 240
-            seconds.
-
-            DISCUSSION:
-                 Experience has shown that these initialization values
-                 are reasonable, and that in any case the Karn and
-                 Jacobson algorithms make TCP behavior reasonably
-                 insensitive to the initial parameter choices.
-
-         4.2.3.2  When to Send an ACK Segment
-
-            A host that is receiving a stream of TCP data segments can
-            increase efficiency in both the Internet and the hosts by
-            sending fewer than one ACK (acknowledgment) segment per data
-            segment received; this is known as a "delayed ACK" [TCP:5].
-
-            A TCP SHOULD implement a delayed ACK, but an ACK should not
-            be excessively delayed; in particular, the delay MUST be
-            less than 0.5 seconds, and in a stream of full-sized
-            segments there SHOULD be an ACK for at least every second
-            segment.
-
-            DISCUSSION:
-
-
-
-Internet Engineering Task Force                                [Page 96]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 A delayed ACK gives the application an opportunity to
-                 update the window and perhaps to send an immediate
-                 response.  In particular, in the case of character-mode
-                 remote login, a delayed ACK can reduce the number of
-                 segments sent by the server by a factor of 3 (ACK,
-                 window update, and echo character all combined in one
-                 segment).
-
-                 In addition, on some large multi-user hosts, a delayed
-                 ACK can substantially reduce protocol processing
-                 overhead by reducing the total number of packets to be
-                 processed [TCP:5].  However, excessive delays on ACK's
-                 can disturb the round-trip timing and packet "clocking"
-                 algorithms [TCP:7].
-
-         4.2.3.3  When to Send a Window Update
-
-            A TCP MUST include a SWS avoidance algorithm in the receiver
-            [TCP:5].
-
-            IMPLEMENTATION:
-                 The receiver's SWS avoidance algorithm determines when
-                 the right window edge may be advanced; this is
-                 customarily known as "updating the window".  This
-                 algorithm combines with the delayed ACK algorithm (see
-                 Section 4.2.3.2) to determine when an ACK segment
-                 containing the current window will really be sent to
-                 the receiver.  We use the notation of RFC-793; see
-                 Figures 4 and 5 in that document.
-
-                 The solution to receiver SWS is to avoid advancing the
-                 right window edge RCV.NXT+RCV.WND in small increments,
-                 even if data is received from the network in small
-                 segments.
-
-                 Suppose the total receive buffer space is RCV.BUFF.  At
-                 any given moment, RCV.USER octets of this total may be
-                 tied up with data that has been received and
-                 acknowledged but which the user process has not yet
-                 consumed.  When the connection is quiescent, RCV.WND =
-                 RCV.BUFF and RCV.USER = 0.
-
-                 Keeping the right window edge fixed as data arrives and
-                 is acknowledged requires that the receiver offer less
-                 than its full buffer space, i.e., the receiver must
-                 specify a RCV.WND that keeps RCV.NXT+RCV.WND constant
-                 as RCV.NXT increases.  Thus, the total buffer space
-                 RCV.BUFF is generally divided into three parts:
-
-
-
-Internet Engineering Task Force                                [Page 97]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-
-                 |<------- RCV.BUFF ---------------->|
-                      1             2            3
-             ----|---------|------------------|------|----
-                        RCV.NXT               ^
-                                           (Fixed)
-
-             1 - RCV.USER =  data received but not yet consumed;
-             2 - RCV.WND =   space advertised to sender;
-             3 - Reduction = space available but not yet
-                             advertised.
-
-
-                 The suggested SWS avoidance algorithm for the receiver
-                 is to keep RCV.NXT+RCV.WND fixed until the reduction
-                 satisfies:
-
-                      RCV.BUFF - RCV.USER - RCV.WND  >=
-
-                             min( Fr * RCV.BUFF, Eff.snd.MSS )
-
-                 where Fr is a fraction whose recommended value is 1/2,
-                 and Eff.snd.MSS is the effective send MSS for the
-                 connection (see Section 4.2.2.6).  When the inequality
-                 is satisfied, RCV.WND is set to RCV.BUFF-RCV.USER.
-
-                 Note that the general effect of this algorithm is to
-                 advance RCV.WND in increments of Eff.snd.MSS (for
-                 realistic receive buffers:  Eff.snd.MSS < RCV.BUFF/2).
-                 Note also that the receiver must use its own
-                 Eff.snd.MSS, assuming it is the same as the sender's.
-
-         4.2.3.4  When to Send Data
-
-            A TCP MUST include a SWS avoidance algorithm in the sender.
-
-            A TCP SHOULD implement the Nagle Algorithm [TCP:9] to
-            coalesce short segments.  However, there MUST be a way for
-            an application to disable the Nagle algorithm on an
-            individual connection.  In all cases, sending data is also
-            subject to the limitation imposed by the Slow Start
-            algorithm (Section 4.2.2.15).
-
-            DISCUSSION:
-                 The Nagle algorithm is generally as follows:
-
-                      If there is unacknowledged data (i.e., SND.NXT >
-                      SND.UNA), then the sending TCP buffers all user
-
-
-
-Internet Engineering Task Force                                [Page 98]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                      data (regardless of the PSH bit), until the
-                      outstanding data has been acknowledged or until
-                      the TCP can send a full-sized segment (Eff.snd.MSS
-                      bytes; see Section 4.2.2.6).
-
-                 Some applications (e.g., real-time display window
-                 updates) require that the Nagle algorithm be turned
-                 off, so small data segments can be streamed out at the
-                 maximum rate.
-
-            IMPLEMENTATION:
-                 The sender's SWS avoidance algorithm is more difficult
-                 than the receivers's, because the sender does not know
-                 (directly) the receiver's total buffer space RCV.BUFF.
-                 An approach which has been found to work well is for
-                 the sender to calculate Max(SND.WND), the maximum send
-                 window it has seen so far on the connection, and to use
-                 this value as an estimate of RCV.BUFF.  Unfortunately,
-                 this can only be an estimate; the receiver may at any
-                 time reduce the size of RCV.BUFF.  To avoid a resulting
-                 deadlock, it is necessary to have a timeout to force
-                 transmission of data, overriding the SWS avoidance
-                 algorithm.  In practice, this timeout should seldom
-                 occur.
-
-                 The "useable window" [TCP:5] is:
-
-                      U = SND.UNA + SND.WND - SND.NXT
-
-                 i.e., the offered window less the amount of data sent
-                 but not acknowledged.  If D is the amount of data
-                 queued in the sending TCP but not yet sent, then the
-                 following set of rules is recommended.
-
-                 Send data:
-
-                 (1)  if a maximum-sized segment can be sent, i.e, if:
-
-                           min(D,U) >= Eff.snd.MSS;
-
-
-                 (2)  or if the data is pushed and all queued data can
-                      be sent now, i.e., if:
-
-                          [SND.NXT = SND.UNA and] PUSHED and D <= U
-
-                      (the bracketed condition is imposed by the Nagle
-                      algorithm);
-
-
-
-Internet Engineering Task Force                                [Page 99]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 (3)  or if at least a fraction Fs of the maximum window
-                      can be sent, i.e., if:
-
-                          [SND.NXT = SND.UNA and]
-
-                                  min(D.U) >= Fs * Max(SND.WND);
-
-
-                 (4)  or if data is PUSHed and the override timeout
-                      occurs.
-
-                 Here Fs is a fraction whose recommended value is 1/2.
-                 The override timeout should be in the range 0.1 - 1.0
-                 seconds.  It may be convenient to combine this timer
-                 with the timer used to probe zero windows (Section
-                 4.2.2.17).
-
-                 Finally, note that the SWS avoidance algorithm just
-                 specified is to be used instead of the sender-side
-                 algorithm contained in [TCP:5].
-
-         4.2.3.5  TCP Connection Failures
-
-            Excessive retransmission of the same segment by TCP
-            indicates some failure of the remote host or the Internet
-            path.  This failure may be of short or long duration.  The
-            following procedure MUST be used to handle excessive
-            retransmissions of data segments [IP:11]:
-
-            (a)  There are two thresholds R1 and R2 measuring the amount
-                 of retransmission that has occurred for the same
-                 segment.  R1 and R2 might be measured in time units or
-                 as a count of retransmissions.
-
-            (b)  When the number of transmissions of the same segment
-                 reaches or exceeds threshold R1, pass negative advice
-                 (see Section 3.3.1.4) to the IP layer, to trigger
-                 dead-gateway diagnosis.
-
-            (c)  When the number of transmissions of the same segment
-                 reaches a threshold R2 greater than R1, close the
-                 connection.
-
-            (d)  An application MUST be able to set the value for R2 for
-                 a particular connection.  For example, an interactive
-                 application might set R2 to "infinity," giving the user
-                 control over when to disconnect.
-
-
-
-
-Internet Engineering Task Force                               [Page 100]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            (d)  TCP SHOULD inform the application of the delivery
-                 problem (unless such information has been disabled by
-                 the application; see Section 4.2.4.1), when R1 is
-                 reached and before R2.  This will allow a remote login
-                 (User Telnet) application program to inform the user,
-                 for example.
-
-            The value of R1 SHOULD correspond to at least 3
-            retransmissions, at the current RTO.  The value of R2 SHOULD
-            correspond to at least 100 seconds.
-
-            An attempt to open a TCP connection could fail with
-            excessive retransmissions of the SYN segment or by receipt
-            of a RST segment or an ICMP Port Unreachable.  SYN
-            retransmissions MUST be handled in the general way just
-            described for data retransmissions, including notification
-            of the application layer.
-
-            However, the values of R1 and R2 may be different for SYN
-            and data segments.  In particular, R2 for a SYN segment MUST
-            be set large enough to provide retransmission of the segment
-            for at least 3 minutes.  The application can close the
-            connection (i.e., give up on the open attempt) sooner, of
-            course.
-
-            DISCUSSION:
-                 Some Internet paths have significant setup times, and
-                 the number of such paths is likely to increase in the
-                 future.
-
-         4.2.3.6  TCP Keep-Alives
-
-            Implementors MAY include "keep-alives" in their TCP
-            implementations, although this practice is not universally
-            accepted.  If keep-alives are included, the application MUST
-            be able to turn them on or off for each TCP connection, and
-            they MUST default to off.
-
-            Keep-alive packets MUST only be sent when no data or
-            acknowledgement packets have been received for the
-            connection within an interval.  This interval MUST be
-            configurable and MUST default to no less than two hours.
-
-            It is extremely important to remember that ACK segments that
-            contain no data are not reliably transmitted by TCP.
-            Consequently, if a keep-alive mechanism is implemented it
-            MUST NOT interpret failure to respond to any specific probe
-            as a dead connection.
-
-
-
-Internet Engineering Task Force                               [Page 101]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            An implementation SHOULD send a keep-alive segment with no
-            data; however, it MAY be configurable to send a keep-alive
-            segment containing one garbage octet, for compatibility with
-            erroneous TCP implementations.
-
-            DISCUSSION:
-                 A "keep-alive" mechanism periodically probes the other
-                 end of a connection when the connection is otherwise
-                 idle, even when there is no data to be sent.  The TCP
-                 specification does not include a keep-alive mechanism
-                 because it could:  (1) cause perfectly good connections
-                 to break during transient Internet failures; (2)
-                 consume unnecessary bandwidth ("if no one is using the
-                 connection, who cares if it is still good?"); and (3)
-                 cost money for an Internet path that charges for
-                 packets.
-
-                 Some TCP implementations, however, have included a
-                 keep-alive mechanism.  To confirm that an idle
-                 connection is still active, these implementations send
-                 a probe segment designed to elicit a response from the
-                 peer TCP.  Such a segment generally contains SEG.SEQ =
-                 SND.NXT-1 and may or may not contain one garbage octet
-                 of data.  Note that on a quiet connection SND.NXT =
-                 RCV.NXT, so that this SEG.SEQ will be outside the
-                 window.  Therefore, the probe causes the receiver to
-                 return an acknowledgment segment, confirming that the
-                 connection is still live.  If the peer has dropped the
-                 connection due to a network partition or a crash, it
-                 will respond with a RST instead of an acknowledgment
-                 segment.
-
-                 Unfortunately, some misbehaved TCP implementations fail
-                 to respond to a segment with SEG.SEQ = SND.NXT-1 unless
-                 the segment contains data.  Alternatively, an
-                 implementation could determine whether a peer responded
-                 correctly to keep-alive packets with no garbage data
-                 octet.
-
-                 A TCP keep-alive mechanism should only be invoked in
-                 server applications that might otherwise hang
-                 indefinitely and consume resources unnecessarily if a
-                 client crashes or aborts a connection during a network
-                 failure.
-
-
-
-
-
-
-
-Internet Engineering Task Force                               [Page 102]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-         4.2.3.7  TCP Multihoming
-
-            If an application on a multihomed host does not specify the
-            local IP address when actively opening a TCP connection,
-            then the TCP MUST ask the IP layer to select a local IP
-            address before sending the (first) SYN.  See the function
-            GET_SRCADDR() in Section 3.4.
-
-            At all other times, a previous segment has either been sent
-            or received on this connection, and TCP MUST use the same
-            local address is used that was used in those previous
-            segments.
-
-         4.2.3.8  IP Options
-
-            When received options are passed up to TCP from the IP
-            layer, TCP MUST ignore options that it does not understand.
-
-            A TCP MAY support the Time Stamp and Record Route options.
-
-            An application MUST be able to specify a source route when
-            it actively opens a TCP connection, and this MUST take
-            precedence over a source route received in a datagram.
-
-            When a TCP connection is OPENed passively and a packet
-            arrives with a completed IP Source Route option (containing
-            a return route), TCP MUST save the return route and use it
-            for all segments sent on this connection.  If a different
-            source route arrives in a later segment, the later
-            definition SHOULD override the earlier one.
-
-         4.2.3.9  ICMP Messages
-
-            TCP MUST act on an ICMP error message passed up from the IP
-            layer, directing it to the connection that created the
-            error.  The necessary demultiplexing information can be
-            found in the IP header contained within the ICMP message.
-
-            o    Source Quench
-
-                 TCP MUST react to a Source Quench by slowing
-                 transmission on the connection.  The RECOMMENDED
-                 procedure is for a Source Quench to trigger a "slow
-                 start," as if a retransmission timeout had occurred.
-
-            o    Destination Unreachable -- codes 0, 1, 5
-
-                 Since these Unreachable messages indicate soft error
-
-
-
-Internet Engineering Task Force                               [Page 103]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 conditions, TCP MUST NOT abort the connection, and it
-                 SHOULD make the information available to the
-                 application.
-
-                 DISCUSSION:
-                      TCP could report the soft error condition directly
-                      to the application layer with an upcall to the
-                      ERROR_REPORT routine, or it could merely note the
-                      message and report it to the application only when
-                      and if the TCP connection times out.
-
-            o    Destination Unreachable -- codes 2-4
-
-                 These are hard error conditions, so TCP SHOULD abort
-                 the connection.
-
-            o    Time Exceeded -- codes 0, 1
-
-                 This should be handled the same way as Destination
-                 Unreachable codes 0, 1, 5 (see above).
-
-            o    Parameter Problem
-
-                 This should be handled the same way as Destination
-                 Unreachable codes 0, 1, 5 (see above).
-
-
-         4.2.3.10  Remote Address Validation
-
-            A TCP implementation MUST reject as an error a local OPEN
-            call for an invalid remote IP address (e.g., a broadcast or
-            multicast address).
-
-            An incoming SYN with an invalid source address must be
-            ignored either by TCP or by the IP layer (see Section
-            3.2.1.3).
-
-            A TCP implementation MUST silently discard an incoming SYN
-            segment that is addressed to a broadcast or multicast
-            address.
-
-         4.2.3.11  TCP Traffic Patterns
-
-            IMPLEMENTATION:
-                 The TCP protocol specification [TCP:1] gives the
-                 implementor much freedom in designing the algorithms
-                 that control the message flow over the connection --
-                 packetizing, managing the window, sending
-
-
-
-Internet Engineering Task Force                               [Page 104]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 acknowledgments, etc.  These design decisions are
-                 difficult because a TCP must adapt to a wide range of
-                 traffic patterns.  Experience has shown that a TCP
-                 implementor needs to verify the design on two extreme
-                 traffic patterns:
-
-                 o    Single-character Segments
-
-                      Even if the sender is using the Nagle Algorithm,
-                      when a TCP connection carries remote login traffic
-                      across a low-delay LAN the receiver will generally
-                      get a stream of single-character segments.  If
-                      remote terminal echo mode is in effect, the
-                      receiver's system will generally echo each
-                      character as it is received.
-
-                 o    Bulk Transfer
-
-                      When TCP is used for bulk transfer, the data
-                      stream should be made up (almost) entirely of
-                      segments of the size of the effective MSS.
-                      Although TCP uses a sequence number space with
-                      byte (octet) granularity, in bulk-transfer mode
-                      its operation should be as if TCP used a sequence
-                      space that counted only segments.
-
-                 Experience has furthermore shown that a single TCP can
-                 effectively and efficiently handle these two extremes.
-
-                 The most important tool for verifying a new TCP
-                 implementation is a packet trace program.  There is a
-                 large volume of experience showing the importance of
-                 tracing a variety of traffic patterns with other TCP
-                 implementations and studying the results carefully.
-
-
-         4.2.3.12  Efficiency
-
-            IMPLEMENTATION:
-                 Extensive experience has led to the following
-                 suggestions for efficient implementation of TCP:
-
-                 (a)  Don't Copy Data
-
-                      In bulk data transfer, the primary CPU-intensive
-                      tasks are copying data from one place to another
-                      and checksumming the data.  It is vital to
-                      minimize the number of copies of TCP data.  Since
-
-
-
-Internet Engineering Task Force                               [Page 105]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                      the ultimate speed limitation may be fetching data
-                      across the memory bus, it may be useful to combine
-                      the copy with checksumming, doing both with a
-                      single memory fetch.
-
-                 (b)  Hand-Craft the Checksum Routine
-
-                      A good TCP checksumming routine is typically two
-                      to five times faster than a simple and direct
-                      implementation of the definition.  Great care and
-                      clever coding are often required and advisable to
-                      make the checksumming code "blazing fast".  See
-                      [TCP:10].
-
-                 (c)  Code for the Common Case
-
-                      TCP protocol processing can be complicated, but
-                      for most segments there are only a few simple
-                      decisions to be made.  Per-segment processing will
-                      be greatly speeded up by coding the main line to
-                      minimize the number of decisions in the most
-                      common case.
-
-
-      4.2.4  TCP/APPLICATION LAYER INTERFACE
-
-         4.2.4.1  Asynchronous Reports
-
-            There MUST be a mechanism for reporting soft TCP error
-            conditions to the application.  Generically, we assume this
-            takes the form of an application-supplied ERROR_REPORT
-            routine that may be upcalled [INTRO:7] asynchronously from
-            the transport layer:
-
-               ERROR_REPORT(local connection name, reason, subreason)
-
-            The precise encoding of the reason and subreason parameters
-            is not specified here.  However, the conditions that are
-            reported asynchronously to the application MUST include:
-
-            *    ICMP error message arrived (see 4.2.3.9)
-
-            *    Excessive retransmissions (see 4.2.3.5)
-
-            *    Urgent pointer advance (see 4.2.2.4).
-
-            However, an application program that does not want to
-            receive such ERROR_REPORT calls SHOULD be able to
-
-
-
-Internet Engineering Task Force                               [Page 106]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            effectively disable these calls.
-
-            DISCUSSION:
-                 These error reports generally reflect soft errors that
-                 can be ignored without harm by many applications.  It
-                 has been suggested that these error report calls should
-                 default to "disabled," but this is not required.
-
-         4.2.4.2  Type-of-Service
-
-            The application layer MUST be able to specify the Type-of-
-            Service (TOS) for segments that are sent on a connection.
-            It not required, but the application SHOULD be able to
-            change the TOS during the connection lifetime.  TCP SHOULD
-            pass the current TOS value without change to the IP layer,
-            when it sends segments on the connection.
-
-            The TOS will be specified independently in each direction on
-            the connection, so that the receiver application will
-            specify the TOS used for ACK segments.
-
-            TCP MAY pass the most recently received TOS up to the
-            application.
-
-            DISCUSSION
-                 Some applications (e.g., SMTP) change the nature of
-                 their communication during the lifetime of a
-                 connection, and therefore would like to change the TOS
-                 specification.
-
-                 Note also that the OPEN call specified in RFC-793
-                 includes a parameter ("options") in which the caller
-                 can specify IP options such as source route, record
-                 route, or timestamp.
-
-         4.2.4.3  Flush Call
-
-            Some TCP implementations have included a FLUSH call, which
-            will empty the TCP send queue of any data for which the user
-            has issued SEND calls but which is still to the right of the
-            current send window.  That is, it flushes as much queued
-            send data as possible without losing sequence number
-            synchronization.  This is useful for implementing the "abort
-            output" function of Telnet.
-
-
-
-
-
-
-
-Internet Engineering Task Force                               [Page 107]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-         4.2.4.4  Multihoming
-
-            The user interface outlined in sections 2.7 and 3.8 of RFC-
-            793 needs to be extended for multihoming.  The OPEN call
-            MUST have an optional parameter:
-
-                OPEN( ... [local IP address,] ... )
-
-            to allow the specification of the local IP address.
-
-            DISCUSSION:
-                 Some TCP-based applications need to specify the local
-                 IP address to be used to open a particular connection;
-                 FTP is an example.
-
-            IMPLEMENTATION:
-                 A passive OPEN call with a specified "local IP address"
-                 parameter will await an incoming connection request to
-                 that address.  If the parameter is unspecified, a
-                 passive OPEN will await an incoming connection request
-                 to any local IP address, and then bind the local IP
-                 address of the connection to the particular address
-                 that is used.
-
-                 For an active OPEN call, a specified "local IP address"
-                 parameter will be used for opening the connection.  If
-                 the parameter is unspecified, the networking software
-                 will choose an appropriate local IP address (see
-                 Section 3.3.4.2) for the connection
-
-      4.2.5  TCP REQUIREMENT SUMMARY
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-Push flag                                        |        | | | | | |
-  Aggregate or queue un-pushed data              |4.2.2.2 | | |x| | |
-  Sender collapse successive PSH flags           |4.2.2.2 | |x| | | |
-  SEND call can specify PUSH                     |4.2.2.2 | | |x| | |
-
-
-
-Internet Engineering Task Force                               [Page 108]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-    If cannot: sender buffer indefinitely        |4.2.2.2 | | | | |x|
-    If cannot: PSH last segment                  |4.2.2.2 |x| | | | |
-  Notify receiving ALP of PSH                    |4.2.2.2 | | |x| | |1
-  Send max size segment when possible            |4.2.2.2 | |x| | | |
-                                                 |        | | | | | |
-Window                                           |        | | | | | |
-  Treat as unsigned number                       |4.2.2.3 |x| | | | |
-  Handle as 32-bit number                        |4.2.2.3 | |x| | | |
-  Shrink window from right                       |4.2.2.16| | | |x| |
-  Robust against shrinking window                |4.2.2.16|x| | | | |
-  Receiver's window closed indefinitely          |4.2.2.17| | |x| | |
-  Sender probe zero window                       |4.2.2.17|x| | | | |
-    First probe after RTO                        |4.2.2.17| |x| | | |
-    Exponential backoff                          |4.2.2.17| |x| | | |
-  Allow window stay zero indefinitely            |4.2.2.17|x| | | | |
-  Sender timeout OK conn with zero wind          |4.2.2.17| | | | |x|
-                                                 |        | | | | | |
-Urgent Data                                      |        | | | | | |
-  Pointer points to last octet                   |4.2.2.4 |x| | | | |
-  Arbitrary length urgent data sequence          |4.2.2.4 |x| | | | |
-  Inform ALP asynchronously of urgent data       |4.2.2.4 |x| | | | |1
-  ALP can learn if/how much urgent data Q'd      |4.2.2.4 |x| | | | |1
-                                                 |        | | | | | |
-TCP Options                                      |        | | | | | |
-  Receive TCP option in any segment              |4.2.2.5 |x| | | | |
-  Ignore unsupported options                     |4.2.2.5 |x| | | | |
-  Cope with illegal option length                |4.2.2.5 |x| | | | |
-  Implement sending & receiving MSS option       |4.2.2.6 |x| | | | |
-  Send MSS option unless 536                     |4.2.2.6 | |x| | | |
-  Send MSS option always                         |4.2.2.6 | | |x| | |
-  Send-MSS default is 536                        |4.2.2.6 |x| | | | |
-  Calculate effective send seg size              |4.2.2.6 |x| | | | |
-                                                 |        | | | | | |
-TCP Checksums                                    |        | | | | | |
-  Sender compute checksum                        |4.2.2.7 |x| | | | |
-  Receiver check checksum                        |4.2.2.7 |x| | | | |
-                                                 |        | | | | | |
-Use clock-driven ISN selection                   |4.2.2.9 |x| | | | |
-                                                 |        | | | | | |
-Opening Connections                              |        | | | | | |
-  Support simultaneous open attempts             |4.2.2.10|x| | | | |
-  SYN-RCVD remembers last state                  |4.2.2.11|x| | | | |
-  Passive Open call interfere with others        |4.2.2.18| | | | |x|
-  Function: simultan. LISTENs for same port      |4.2.2.18|x| | | | |
-  Ask IP for src address for SYN if necc.        |4.2.3.7 |x| | | | |
-    Otherwise, use local addr of conn.           |4.2.3.7 |x| | | | |
-  OPEN to broadcast/multicast IP Address         |4.2.3.14| | | | |x|
-  Silently discard seg to bcast/mcast addr       |4.2.3.14|x| | | | |
-
-
-
-Internet Engineering Task Force                               [Page 109]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                                                 |        | | | | | |
-Closing Connections                              |        | | | | | |
-  RST can contain data                           |4.2.2.12| |x| | | |
-  Inform application of aborted conn             |4.2.2.13|x| | | | |
-  Half-duplex close connections                  |4.2.2.13| | |x| | |
-    Send RST to indicate data lost               |4.2.2.13| |x| | | |
-  In TIME-WAIT state for 2xMSL seconds           |4.2.2.13|x| | | | |
-    Accept SYN from TIME-WAIT state              |4.2.2.13| | |x| | |
-                                                 |        | | | | | |
-Retransmissions                                  |        | | | | | |
-  Jacobson Slow Start algorithm                  |4.2.2.15|x| | | | |
-  Jacobson Congestion-Avoidance algorithm        |4.2.2.15|x| | | | |
-  Retransmit with same IP ident                  |4.2.2.15| | |x| | |
-  Karn's algorithm                               |4.2.3.1 |x| | | | |
-  Jacobson's RTO estimation alg.                 |4.2.3.1 |x| | | | |
-  Exponential backoff                            |4.2.3.1 |x| | | | |
-  SYN RTO calc same as data                      |4.2.3.1 | |x| | | |
-  Recommended initial values and bounds          |4.2.3.1 | |x| | | |
-                                                 |        | | | | | |
-Generating ACK's:                                |        | | | | | |
-  Queue out-of-order segments                    |4.2.2.20| |x| | | |
-  Process all Q'd before send ACK                |4.2.2.20|x| | | | |
-  Send ACK for out-of-order segment              |4.2.2.21| | |x| | |
-  Delayed ACK's                                  |4.2.3.2 | |x| | | |
-    Delay < 0.5 seconds                          |4.2.3.2 |x| | | | |
-    Every 2nd full-sized segment ACK'd           |4.2.3.2 |x| | | | |
-  Receiver SWS-Avoidance Algorithm               |4.2.3.3 |x| | | | |
-                                                 |        | | | | | |
-Sending data                                     |        | | | | | |
-  Configurable TTL                               |4.2.2.19|x| | | | |
-  Sender SWS-Avoidance Algorithm                 |4.2.3.4 |x| | | | |
-  Nagle algorithm                                |4.2.3.4 | |x| | | |
-    Application can disable Nagle algorithm      |4.2.3.4 |x| | | | |
-                                                 |        | | | | | |
-Connection Failures:                             |        | | | | | |
-  Negative advice to IP on R1 retxs              |4.2.3.5 |x| | | | |
-  Close connection on R2 retxs                   |4.2.3.5 |x| | | | |
-  ALP can set R2                                 |4.2.3.5 |x| | | | |1
-  Inform ALP of  R1<=retxs<R2                    |4.2.3.5 | |x| | | |1
-  Recommended values for R1, R2                  |4.2.3.5 | |x| | | |
-  Same mechanism for SYNs                        |4.2.3.5 |x| | | | |
-    R2 at least 3 minutes for SYN                |4.2.3.5 |x| | | | |
-                                                 |        | | | | | |
-Send Keep-alive Packets:                         |4.2.3.6 | | |x| | |
-  - Application can request                      |4.2.3.6 |x| | | | |
-  - Default is "off"                             |4.2.3.6 |x| | | | |
-  - Only send if idle for interval               |4.2.3.6 |x| | | | |
-  - Interval configurable                        |4.2.3.6 |x| | | | |
-
-
-
-Internet Engineering Task Force                               [Page 110]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-  - Default at least 2 hrs.                      |4.2.3.6 |x| | | | |
-  - Tolerant of lost ACK's                       |4.2.3.6 |x| | | | |
-                                                 |        | | | | | |
-IP Options                                       |        | | | | | |
-  Ignore options TCP doesn't understand          |4.2.3.8 |x| | | | |
-  Time Stamp support                             |4.2.3.8 | | |x| | |
-  Record Route support                           |4.2.3.8 | | |x| | |
-  Source Route:                                  |        | | | | | |
-    ALP can specify                              |4.2.3.8 |x| | | | |1
-      Overrides src rt in datagram               |4.2.3.8 |x| | | | |
-    Build return route from src rt               |4.2.3.8 |x| | | | |
-    Later src route overrides                    |4.2.3.8 | |x| | | |
-                                                 |        | | | | | |
-Receiving ICMP Messages from IP                  |4.2.3.9 |x| | | | |
-  Dest. Unreach (0,1,5) => inform ALP            |4.2.3.9 | |x| | | |
-  Dest. Unreach (0,1,5) => abort conn            |4.2.3.9 | | | | |x|
-  Dest. Unreach (2-4) => abort conn              |4.2.3.9 | |x| | | |
-  Source Quench => slow start                    |4.2.3.9 | |x| | | |
-  Time Exceeded => tell ALP, don't abort         |4.2.3.9 | |x| | | |
-  Param Problem => tell ALP, don't abort         |4.2.3.9 | |x| | | |
-                                                 |        | | | | | |
-Address Validation                               |        | | | | | |
-  Reject OPEN call to invalid IP address         |4.2.3.10|x| | | | |
-  Reject SYN from invalid IP address             |4.2.3.10|x| | | | |
-  Silently discard SYN to bcast/mcast addr       |4.2.3.10|x| | | | |
-                                                 |        | | | | | |
-TCP/ALP Interface Services                       |        | | | | | |
-  Error Report mechanism                         |4.2.4.1 |x| | | | |
-  ALP can disable Error Report Routine           |4.2.4.1 | |x| | | |
-  ALP can specify TOS for sending                |4.2.4.2 |x| | | | |
-    Passed unchanged to IP                       |4.2.4.2 | |x| | | |
-  ALP can change TOS during connection           |4.2.4.2 | |x| | | |
-  Pass received TOS up to ALP                    |4.2.4.2 | | |x| | |
-  FLUSH call                                     |4.2.4.3 | | |x| | |
-  Optional local IP addr parm. in OPEN           |4.2.4.4 |x| | | | |
--------------------------------------------------|--------|-|-|-|-|-|--
--------------------------------------------------|--------|-|-|-|-|-|--
-
-FOOTNOTES:
-
-(1)  "ALP" means Application-Layer program.
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                               [Page 111]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-5.  REFERENCES
-
-INTRODUCTORY REFERENCES
-
-
-[INTRO:1] "Requirements for Internet Hosts -- Application and Support,"
-     IETF Host Requirements Working Group, R. Braden, Ed., RFC-1123,
-     October 1989.
-
-[INTRO:2]  "Requirements for Internet Gateways,"  R. Braden and J.
-     Postel, RFC-1009, June 1987.
-
-[INTRO:3]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
-     (three volumes), SRI International, December 1985.
-
-[INTRO:4]  "Official Internet Protocols," J. Reynolds and J. Postel,
-     RFC-1011, May 1987.
-
-     This document is republished periodically with new RFC numbers; the
-     latest version must be used.
-
-[INTRO:5]  "Protocol Document Order Information," O. Jacobsen and J.
-     Postel, RFC-980, March 1986.
-
-[INTRO:6]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May
-     1987.
-
-     This document is republished periodically with new RFC numbers; the
-     latest version must be used.
-
-[INTRO:7] "Modularity and Efficiency in Protocol Implementations," D.
-     Clark, RFC-817, July 1982.
-
-[INTRO:8] "The Structuring of Systems Using Upcalls," D. Clark, 10th ACM
-     SOSP, Orcas Island, Washington, December 1985.
-
-
-Secondary References:
-
-
-[INTRO:9]  "A Protocol for Packet Network Intercommunication," V. Cerf
-     and R. Kahn, IEEE Transactions on Communication, May 1974.
-
-[INTRO:10]  "The ARPA Internet Protocol," J. Postel, C. Sunshine, and D.
-     Cohen, Computer Networks, Vol. 5, No. 4, July 1981.
-
-[INTRO:11]  "The DARPA Internet Protocol Suite," B. Leiner, J. Postel,
-     R. Cole and D. Mills, Proceedings INFOCOM 85, IEEE, Washington DC,
-
-
-
-Internet Engineering Task Force                               [Page 112]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-     March 1985.  Also in: IEEE Communications Magazine, March 1985.
-     Also available as ISI-RS-85-153.
-
-[INTRO:12] "Final Text of DIS8473, Protocol for Providing the
-     Connectionless Mode Network Service," ANSI, published as RFC-994,
-     March 1986.
-
-[INTRO:13] "End System to Intermediate System Routing Exchange
-     Protocol," ANSI X3S3.3, published as RFC-995, April 1986.
-
-
-LINK LAYER REFERENCES
-
-
-[LINK:1] "Trailer Encapsulations," S. Leffler and M. Karels, RFC-893,
-     April 1984.
-
-[LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826,
-     November 1982.
-
-[LINK:3] "A Standard for the Transmission of IP Datagrams over Ethernet
-     Networks," C. Hornig, RFC-894, April 1984.
-
-[LINK:4] "A Standard for the Transmission of IP Datagrams over IEEE 802
-     "Networks," J. Postel and J. Reynolds, RFC-1042, February 1988.
-
-     This RFC contains a great deal of information of importance to
-     Internet implementers planning to use IEEE 802 networks.
-
-
-IP LAYER REFERENCES
-
-
-[IP:1] "Internet Protocol (IP)," J. Postel, RFC-791, September 1981.
-
-[IP:2] "Internet Control Message Protocol (ICMP)," J. Postel, RFC-792,
-     September 1981.
-
-[IP:3] "Internet Standard Subnetting Procedure," J. Mogul and J. Postel,
-     RFC-950, August 1985.
-
-[IP:4]  "Host Extensions for IP Multicasting," S. Deering, RFC-1112,
-     August 1989.
-
-[IP:5] "Military Standard Internet Protocol," MIL-STD-1777, Department
-     of Defense, August 1983.
-
-     This specification, as amended by RFC-963, is intended to describe
-
-
-
-Internet Engineering Task Force                               [Page 113]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-     the Internet Protocol but has some serious omissions (e.g., the
-     mandatory subnet extension [IP:3] and the optional multicasting
-     extension [IP:4]).  It is also out of date.  If there is a
-     conflict, RFC-791, RFC-792, and RFC-950 must be taken as
-     authoritative, while the present document is authoritative over
-     all.
-
-[IP:6] "Some Problems with the Specification of the Military Standard
-     Internet Protocol," D. Sidhu, RFC-963, November 1985.
-
-[IP:7] "The TCP Maximum Segment Size and Related Topics," J. Postel,
-     RFC-879, November 1983.
-
-     Discusses and clarifies the relationship between the TCP Maximum
-     Segment Size option and the IP datagram size.
-
-[IP:8] "Internet Protocol Security Options,"  B. Schofield, RFC-1108,
-     October 1989.
-
-[IP:9] "Fragmentation Considered Harmful," C. Kent and J. Mogul, ACM
-     SIGCOMM-87, August 1987.  Published as ACM Comp Comm Review, Vol.
-     17, no. 5.
-
-     This useful paper discusses the problems created by Internet
-     fragmentation and presents alternative solutions.
-
-[IP:10] "IP Datagram Reassembly Algorithms," D. Clark, RFC-815, July
-     1982.
-
-     This and the following paper should be read by every implementor.
-
-[IP:11] "Fault Isolation and Recovery," D. Clark, RFC-816, July 1982.
-
-SECONDARY IP REFERENCES:
-
-
-[IP:12] "Broadcasting Internet Datagrams in the Presence of Subnets," J.
-     Mogul, RFC-922, October 1984.
-
-[IP:13] "Name, Addresses, Ports, and Routes," D. Clark, RFC-814, July
-     1982.
-
-[IP:14] "Something a Host Could Do with Source Quench: The Source Quench
-     Introduced Delay (SQUID)," W. Prue and J. Postel, RFC-1016, July
-     1987.
-
-     This RFC first described directed broadcast addresses.  However,
-     the bulk of the RFC is concerned with gateways, not hosts.
-
-
-
-Internet Engineering Task Force                               [Page 114]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-UDP REFERENCES:
-
-
-[UDP:1] "User Datagram Protocol," J. Postel, RFC-768, August 1980.
-
-
-TCP REFERENCES:
-
-
-[TCP:1] "Transmission Control Protocol," J. Postel, RFC-793, September
-     1981.
-
-
-[TCP:2] "Transmission Control Protocol," MIL-STD-1778, US Department of
-     Defense, August 1984.
-
-     This specification as amended by RFC-964 is intended to describe
-     the same protocol as RFC-793 [TCP:1].  If there is a conflict,
-     RFC-793 takes precedence, and the present document is authoritative
-     over both.
-
-
-[TCP:3] "Some Problems with the Specification of the Military Standard
-     Transmission Control Protocol," D. Sidhu and T. Blumer, RFC-964,
-     November 1985.
-
-
-[TCP:4] "The TCP Maximum Segment Size and Related Topics," J. Postel,
-     RFC-879, November 1983.
-
-
-[TCP:5] "Window and Acknowledgment Strategy in TCP," D. Clark, RFC-813,
-     July 1982.
-
-
-[TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM
-     SIGCOMM-87, August 1987.
-
-
-[TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88,
-     August 1988.
-
-
-SECONDARY TCP REFERENCES:
-
-
-[TCP:8] "Modularity and Efficiency in Protocol Implementation," D.
-     Clark, RFC-817, July 1982.
-
-
-
-Internet Engineering Task Force                               [Page 115]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-[TCP:9] "Congestion Control in IP/TCP," J. Nagle, RFC-896, January 1984.
-
-
-[TCP:10] "Computing the Internet Checksum," R. Braden, D. Borman, and C.
-     Partridge, RFC-1071, September 1988.
-
-
-[TCP:11] "TCP Extensions for Long-Delay Paths," V. Jacobson & R. Braden,
-     RFC-1072, October 1988.
-
-
-Security Considerations
-
-   There are many security issues in the communication layers of host
-   software, but a full discussion is beyond the scope of this RFC.
-
-   The Internet architecture generally provides little protection
-   against spoofing of IP source addresses, so any security mechanism
-   that is based upon verifying the IP source address of a datagram
-   should be treated with suspicion.  However, in restricted
-   environments some source-address checking may be possible.  For
-   example, there might be a secure LAN whose gateway to the rest of the
-   Internet discarded any incoming datagram with a source address that
-   spoofed the LAN address.  In this case, a host on the LAN could use
-   the source address to test for local vs. remote source.  This problem
-   is complicated by source routing, and some have suggested that
-   source-routed datagram forwarding by hosts (see Section 3.3.5) should
-   be outlawed for security reasons.
-
-   Security-related issues are mentioned in sections concerning the IP
-   Security option (Section 3.2.1.8), the ICMP Parameter Problem message
-   (Section 3.2.2.5), IP options in UDP datagrams (Section 4.1.3.2), and
-   reserved TCP ports (Section 4.2.2.1).
-
-Author's Address
-
-   Robert Braden
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA 90292-6695
-
-   Phone: (213) 822 1511
-
-   EMail: Braden@ISI.EDU
-
-
-
-
-
-
-
-Internet Engineering Task Force                               [Page 116]
-
diff --git a/doc/rfc/rfc1123.txt b/doc/rfc/rfc1123.txt
deleted file mode 100644
index 51cdf83c..00000000
--- a/doc/rfc/rfc1123.txt
+++ /dev/null
@@ -1,5782 +0,0 @@
-
-
-
-
-
-
-Network Working Group                    Internet Engineering Task Force
-Request for Comments: 1123                             R. Braden, Editor
-                                                            October 1989
-
-
-       Requirements for Internet Hosts -- Application and Support
-
-Status of This Memo
-
-   This RFC is an official specification for the Internet community.  It
-   incorporates by reference, amends, corrects, and supplements the
-   primary protocol standards documents relating to hosts.  Distribution
-   of this document is unlimited.
-
-Summary
-
-   This RFC is one of a pair that defines and discusses the requirements
-   for Internet host software.  This RFC covers the application and
-   support protocols; its companion RFC-1122 covers the communication
-   protocol layers: link layer, IP layer, and transport layer.
-
-
-
-                           Table of Contents
-
-
-
-
-   1.  INTRODUCTION ...............................................    5
-      1.1  The Internet Architecture ..............................    6
-      1.2  General Considerations .................................    6
-         1.2.1  Continuing Internet Evolution .....................    6
-         1.2.2  Robustness Principle ..............................    7
-         1.2.3  Error Logging .....................................    8
-         1.2.4  Configuration .....................................    8
-      1.3  Reading this Document ..................................   10
-         1.3.1  Organization ......................................   10
-         1.3.2  Requirements ......................................   10
-         1.3.3  Terminology .......................................   11
-      1.4  Acknowledgments ........................................   12
-
-   2.  GENERAL ISSUES .............................................   13
-      2.1  Host Names and Numbers .................................   13
-      2.2  Using Domain Name Service ..............................   13
-      2.3  Applications on Multihomed hosts .......................   14
-      2.4  Type-of-Service ........................................   14
-      2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY ...............   15
-
-
-
-
-Internet Engineering Task Force                                 [Page 1]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-   3.  REMOTE LOGIN -- TELNET PROTOCOL ............................   16
-      3.1  INTRODUCTION ...........................................   16
-      3.2  PROTOCOL WALK-THROUGH ..................................   16
-         3.2.1  Option Negotiation ................................   16
-         3.2.2  Telnet Go-Ahead Function ..........................   16
-         3.2.3  Control Functions .................................   17
-         3.2.4  Telnet "Synch" Signal .............................   18
-         3.2.5  NVT Printer and Keyboard ..........................   19
-         3.2.6  Telnet Command Structure ..........................   20
-         3.2.7  Telnet Binary Option ..............................   20
-         3.2.8  Telnet Terminal-Type Option .......................   20
-      3.3  SPECIFIC ISSUES ........................................   21
-         3.3.1  Telnet End-of-Line Convention .....................   21
-         3.3.2  Data Entry Terminals ..............................   23
-         3.3.3  Option Requirements ...............................   24
-         3.3.4  Option Initiation .................................   24
-         3.3.5  Telnet Linemode Option ............................   25
-      3.4  TELNET/USER INTERFACE ..................................   25
-         3.4.1  Character Set Transparency ........................   25
-         3.4.2  Telnet Commands ...................................   26
-         3.4.3  TCP Connection Errors .............................   26
-         3.4.4  Non-Default Telnet Contact Port ...................   26
-         3.4.5  Flushing Output ...................................   26
-      3.5.  TELNET REQUIREMENTS SUMMARY ...........................   27
-
-   4.  FILE TRANSFER ..............................................   29
-      4.1  FILE TRANSFER PROTOCOL -- FTP ..........................   29
-         4.1.1  INTRODUCTION ......................................   29
-         4.1.2.  PROTOCOL WALK-THROUGH ............................   29
-            4.1.2.1  LOCAL Type ...................................   29
-            4.1.2.2  Telnet Format Control ........................   30
-            4.1.2.3  Page Structure ...............................   30
-            4.1.2.4  Data Structure Transformations ...............   30
-            4.1.2.5  Data Connection Management ...................   31
-            4.1.2.6  PASV Command .................................   31
-            4.1.2.7  LIST and NLST Commands .......................   31
-            4.1.2.8  SITE Command .................................   32
-            4.1.2.9  STOU Command .................................   32
-            4.1.2.10  Telnet End-of-line Code .....................   32
-            4.1.2.11  FTP Replies .................................   33
-            4.1.2.12  Connections .................................   34
-            4.1.2.13  Minimum Implementation; RFC-959 Section .....   34
-         4.1.3  SPECIFIC ISSUES ...................................   35
-            4.1.3.1  Non-standard Command Verbs ...................   35
-            4.1.3.2  Idle Timeout .................................   36
-            4.1.3.3  Concurrency of Data and Control ..............   36
-            4.1.3.4  FTP Restart Mechanism ........................   36
-         4.1.4  FTP/USER INTERFACE ................................   39
-
-
-
-Internet Engineering Task Force                                 [Page 2]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-            4.1.4.1  Pathname Specification .......................   39
-            4.1.4.2  "QUOTE" Command ..............................   40
-            4.1.4.3  Displaying Replies to User ...................   40
-            4.1.4.4  Maintaining Synchronization ..................   40
-         4.1.5   FTP REQUIREMENTS SUMMARY .........................   41
-      4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP .................   44
-         4.2.1  INTRODUCTION ......................................   44
-         4.2.2  PROTOCOL WALK-THROUGH .............................   44
-            4.2.2.1  Transfer Modes ...............................   44
-            4.2.2.2  UDP Header ...................................   44
-         4.2.3  SPECIFIC ISSUES ...................................   44
-            4.2.3.1  Sorcerer's Apprentice Syndrome ...............   44
-            4.2.3.2  Timeout Algorithms ...........................   46
-            4.2.3.3  Extensions ...................................   46
-            4.2.3.4  Access Control ...............................   46
-            4.2.3.5  Broadcast Request ............................   46
-         4.2.4  TFTP REQUIREMENTS SUMMARY .........................   47
-
-   5.  ELECTRONIC MAIL -- SMTP and RFC-822 ........................   48
-      5.1  INTRODUCTION ...........................................   48
-      5.2  PROTOCOL WALK-THROUGH ..................................   48
-         5.2.1  The SMTP Model ....................................   48
-         5.2.2  Canonicalization ..................................   49
-         5.2.3  VRFY and EXPN Commands ............................   50
-         5.2.4  SEND, SOML, and SAML Commands .....................   50
-         5.2.5  HELO Command ......................................   50
-         5.2.6  Mail Relay ........................................   51
-         5.2.7  RCPT Command ......................................   52
-         5.2.8  DATA Command ......................................   53
-         5.2.9  Command Syntax ....................................   54
-         5.2.10  SMTP Replies .....................................   54
-         5.2.11  Transparency .....................................   55
-         5.2.12  WKS Use in MX Processing .........................   55
-         5.2.13  RFC-822 Message Specification ....................   55
-         5.2.14  RFC-822 Date and Time Specification ..............   55
-         5.2.15  RFC-822 Syntax Change ............................   56
-         5.2.16  RFC-822  Local-part ..............................   56
-         5.2.17  Domain Literals ..................................   57
-         5.2.18  Common Address Formatting Errors .................   58
-         5.2.19  Explicit Source Routes ...........................   58
-      5.3  SPECIFIC ISSUES ........................................   59
-         5.3.1  SMTP Queueing Strategies ..........................   59
-            5.3.1.1 Sending Strategy ..............................   59
-            5.3.1.2  Receiving strategy ...........................   61
-         5.3.2  Timeouts in SMTP ..................................   61
-         5.3.3  Reliable Mail Receipt .............................   63
-         5.3.4  Reliable Mail Transmission ........................   63
-         5.3.5  Domain Name Support ...............................   65
-
-
-
-Internet Engineering Task Force                                 [Page 3]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         5.3.6  Mailing Lists and Aliases .........................   65
-         5.3.7  Mail Gatewaying ...................................   66
-         5.3.8  Maximum Message Size ..............................   68
-      5.4  SMTP REQUIREMENTS SUMMARY ..............................   69
-
-   6. SUPPORT SERVICES ............................................   72
-      6.1 DOMAIN NAME TRANSLATION .................................   72
-         6.1.1 INTRODUCTION .......................................   72
-         6.1.2  PROTOCOL WALK-THROUGH .............................   72
-            6.1.2.1  Resource Records with Zero TTL ...............   73
-            6.1.2.2  QCLASS Values ................................   73
-            6.1.2.3  Unused Fields ................................   73
-            6.1.2.4  Compression ..................................   73
-            6.1.2.5  Misusing Configuration Info ..................   73
-         6.1.3  SPECIFIC ISSUES ...................................   74
-            6.1.3.1  Resolver Implementation ......................   74
-            6.1.3.2  Transport Protocols ..........................   75
-            6.1.3.3  Efficient Resource Usage .....................   77
-            6.1.3.4  Multihomed Hosts .............................   78
-            6.1.3.5  Extensibility ................................   79
-            6.1.3.6  Status of RR Types ...........................   79
-            6.1.3.7  Robustness ...................................   80
-            6.1.3.8  Local Host Table .............................   80
-         6.1.4  DNS USER INTERFACE ................................   81
-            6.1.4.1  DNS Administration ...........................   81
-            6.1.4.2  DNS User Interface ...........................   81
-            6.1.4.3 Interface Abbreviation Facilities .............   82
-         6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ...........   84
-      6.2  HOST INITIALIZATION ....................................   87
-         6.2.1  INTRODUCTION ......................................   87
-         6.2.2  REQUIREMENTS ......................................   87
-            6.2.2.1  Dynamic Configuration ........................   87
-            6.2.2.2  Loading Phase ................................   89
-      6.3  REMOTE MANAGEMENT ......................................   90
-         6.3.1  INTRODUCTION ......................................   90
-         6.3.2  PROTOCOL WALK-THROUGH .............................   90
-         6.3.3  MANAGEMENT REQUIREMENTS SUMMARY ...................   92
-
-   7.  REFERENCES .................................................   93
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                 [Page 4]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-1.  INTRODUCTION
-
-   This document is one of a pair that defines and discusses the
-   requirements for host system implementations of the Internet protocol
-   suite.  This RFC covers the applications layer and support protocols.
-   Its companion RFC, "Requirements for Internet Hosts -- Communications
-   Layers" [INTRO:1] covers the lower layer protocols: transport layer,
-   IP layer, and link layer.
-
-   These documents are intended to provide guidance for vendors,
-   implementors, and users of Internet communication software.  They
-   represent the consensus of a large body of technical experience and
-   wisdom, contributed by members of the Internet research and vendor
-   communities.
-
-   This RFC enumerates standard protocols that a host connected to the
-   Internet must use, and it incorporates by reference the RFCs and
-   other documents describing the current specifications for these
-   protocols.  It corrects errors in the referenced documents and adds
-   additional discussion and guidance for an implementor.
-
-   For each protocol, this document also contains an explicit set of
-   requirements, recommendations, and options.  The reader must
-   understand that the list of requirements in this document is
-   incomplete by itself; the complete set of requirements for an
-   Internet host is primarily defined in the standard protocol
-   specification documents, with the corrections, amendments, and
-   supplements contained in this RFC.
-
-   A good-faith implementation of the protocols that was produced after
-   careful reading of the RFC's and with some interaction with the
-   Internet technical community, and that followed good communications
-   software engineering practices, should differ from the requirements
-   of this document in only minor ways.  Thus, in many cases, the
-   "requirements" in this RFC are already stated or implied in the
-   standard protocol documents, so that their inclusion here is, in a
-   sense, redundant.  However, they were included because some past
-   implementation has made the wrong choice, causing problems of
-   interoperability, performance, and/or robustness.
-
-   This document includes discussion and explanation of many of the
-   requirements and recommendations.  A simple list of requirements
-   would be dangerous, because:
-
-   o    Some required features are more important than others, and some
-        features are optional.
-
-   o    There may be valid reasons why particular vendor products that
-
-
-
-Internet Engineering Task Force                                 [Page 5]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-        are designed for restricted contexts might choose to use
-        different specifications.
-
-   However, the specifications of this document must be followed to meet
-   the general goal of arbitrary host interoperation across the
-   diversity and complexity of the Internet system.  Although most
-   current implementations fail to meet these requirements in various
-   ways, some minor and some major, this specification is the ideal
-   towards which we need to move.
-
-   These requirements are based on the current level of Internet
-   architecture.  This document will be updated as required to provide
-   additional clarifications or to include additional information in
-   those areas in which specifications are still evolving.
-
-   This introductory section begins with general advice to host software
-   vendors, and then gives some guidance on reading the rest of the
-   document.  Section 2 contains general requirements that may be
-   applicable to all application and support protocols.  Sections 3, 4,
-   and 5 contain the requirements on protocols for the three major
-   applications: Telnet, file transfer, and electronic mail,
-   respectively. Section 6 covers the support applications: the domain
-   name system, system initialization, and management.  Finally, all
-   references will be found in Section 7.
-
-   1.1  The Internet Architecture
-
-      For a brief introduction to the Internet architecture from a host
-      viewpoint, see Section 1.1 of [INTRO:1].  That section also
-      contains recommended references for general background on the
-      Internet architecture.
-
-   1.2  General Considerations
-
-      There are two important lessons that vendors of Internet host
-      software have learned and which a new vendor should consider
-      seriously.
-
-      1.2.1  Continuing Internet Evolution
-
-         The enormous growth of the Internet has revealed problems of
-         management and scaling in a large datagram-based packet
-         communication system.  These problems are being addressed, and
-         as a result there will be continuing evolution of the
-         specifications described in this document.  These changes will
-         be carefully planned and controlled, since there is extensive
-         participation in this planning by the vendors and by the
-         organizations responsible for operations of the networks.
-
-
-
-Internet Engineering Task Force                                 [Page 6]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         Development, evolution, and revision are characteristic of
-         computer network protocols today, and this situation will
-         persist for some years.  A vendor who develops computer
-         communication software for the Internet protocol suite (or any
-         other protocol suite!) and then fails to maintain and update
-         that software for changing specifications is going to leave a
-         trail of unhappy customers.  The Internet is a large
-         communication network, and the users are in constant contact
-         through it.  Experience has shown that knowledge of
-         deficiencies in vendor software propagates quickly through the
-         Internet technical community.
-
-      1.2.2  Robustness Principle
-
-         At every layer of the protocols, there is a general rule whose
-         application can lead to enormous benefits in robustness and
-         interoperability:
-
-                "Be liberal in what you accept, and
-                 conservative in what you send"
-
-         Software should be written to deal with every conceivable
-         error, no matter how unlikely; sooner or later a packet will
-         come in with that particular combination of errors and
-         attributes, and unless the software is prepared, chaos can
-         ensue.  In general, it is best to assume that the network is
-         filled with malevolent entities that will send in packets
-         designed to have the worst possible effect.  This assumption
-         will lead to suitable protective design, although the most
-         serious problems in the Internet have been caused by
-         unenvisaged mechanisms triggered by low-probability events;
-         mere human malice would never have taken so devious a course!
-
-         Adaptability to change must be designed into all levels of
-         Internet host software.  As a simple example, consider a
-         protocol specification that contains an enumeration of values
-         for a particular header field -- e.g., a type field, a port
-         number, or an error code; this enumeration must be assumed to
-         be incomplete.  Thus, if a protocol specification defines four
-         possible error codes, the software must not break when a fifth
-         code shows up.  An undefined code might be logged (see below),
-         but it must not cause a failure.
-
-         The second part of the principle is almost as important:
-         software on other hosts may contain deficiencies that make it
-         unwise to exploit legal but obscure protocol features.  It is
-         unwise to stray far from the obvious and simple, lest untoward
-         effects result elsewhere.  A corollary of this is "watch out
-
-
-
-Internet Engineering Task Force                                 [Page 7]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         for misbehaving hosts"; host software should be prepared, not
-         just to survive other misbehaving hosts, but also to cooperate
-         to limit the amount of disruption such hosts can cause to the
-         shared communication facility.
-
-      1.2.3  Error Logging
-
-         The Internet includes a great variety of host and gateway
-         systems, each implementing many protocols and protocol layers,
-         and some of these contain bugs and mis-features in their
-         Internet protocol software.  As a result of complexity,
-         diversity, and distribution of function, the diagnosis of user
-         problems is often very difficult.
-
-         Problem diagnosis will be aided if host implementations include
-         a carefully designed facility for logging erroneous or
-         "strange" protocol events.  It is important to include as much
-         diagnostic information as possible when an error is logged.  In
-         particular, it is often useful to record the header(s) of a
-         packet that caused an error.  However, care must be taken to
-         ensure that error logging does not consume prohibitive amounts
-         of resources or otherwise interfere with the operation of the
-         host.
-
-         There is a tendency for abnormal but harmless protocol events
-         to overflow error logging files; this can be avoided by using a
-         "circular" log, or by enabling logging only while diagnosing a
-         known failure.  It may be useful to filter and count duplicate
-         successive messages.  One strategy that seems to work well is:
-         (1) always count abnormalities and make such counts accessible
-         through the management protocol (see Section 6.3); and (2)
-         allow the logging of a great variety of events to be
-         selectively enabled.  For example, it might useful to be able
-         to "log everything" or to "log everything for host X".
-
-         Note that different managements may have differing policies
-         about the amount of error logging that they want normally
-         enabled in a host.  Some will say, "if it doesn't hurt me, I
-         don't want to know about it", while others will want to take a
-         more watchful and aggressive attitude about detecting and
-         removing protocol abnormalities.
-
-      1.2.4  Configuration
-
-         It would be ideal if a host implementation of the Internet
-         protocol suite could be entirely self-configuring.  This would
-         allow the whole suite to be implemented in ROM or cast into
-         silicon, it would simplify diskless workstations, and it would
-
-
-
-Internet Engineering Task Force                                 [Page 8]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         be an immense boon to harried LAN administrators as well as
-         system vendors.  We have not reached this ideal; in fact, we
-         are not even close.
-
-         At many points in this document, you will find a requirement
-         that a parameter be a configurable option.  There are several
-         different reasons behind such requirements.  In a few cases,
-         there is current uncertainty or disagreement about the best
-         value, and it may be necessary to update the recommended value
-         in the future.  In other cases, the value really depends on
-         external factors -- e.g., the size of the host and the
-         distribution of its communication load, or the speeds and
-         topology of nearby networks -- and self-tuning algorithms are
-         unavailable and may be insufficient.  In some cases,
-         configurability is needed because of administrative
-         requirements.
-
-         Finally, some configuration options are required to communicate
-         with obsolete or incorrect implementations of the protocols,
-         distributed without sources, that unfortunately persist in many
-         parts of the Internet.  To make correct systems coexist with
-         these faulty systems, administrators often have to "mis-
-         configure" the correct systems.  This problem will correct
-         itself gradually as the faulty systems are retired, but it
-         cannot be ignored by vendors.
-
-         When we say that a parameter must be configurable, we do not
-         intend to require that its value be explicitly read from a
-         configuration file at every boot time.  We recommend that
-         implementors set up a default for each parameter, so a
-         configuration file is only necessary to override those defaults
-         that are inappropriate in a particular installation.  Thus, the
-         configurability requirement is an assurance that it will be
-         POSSIBLE to override the default when necessary, even in a
-         binary-only or ROM-based product.
-
-         This document requires a particular value for such defaults in
-         some cases.  The choice of default is a sensitive issue when
-         the configuration item controls the accommodation to existing
-         faulty systems.  If the Internet is to converge successfully to
-         complete interoperability, the default values built into
-         implementations must implement the official protocol, not
-         "mis-configurations" to accommodate faulty implementations.
-         Although marketing considerations have led some vendors to
-         choose mis-configuration defaults, we urge vendors to choose
-         defaults that will conform to the standard.
-
-         Finally, we note that a vendor needs to provide adequate
-
-
-
-Internet Engineering Task Force                                 [Page 9]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         documentation on all configuration parameters, their limits and
-         effects.
-
-
-   1.3  Reading this Document
-
-      1.3.1  Organization
-
-         In general, each major section is organized into the following
-         subsections:
-
-         (1)  Introduction
-
-         (2)  Protocol Walk-Through -- considers the protocol
-              specification documents section-by-section, correcting
-              errors, stating requirements that may be ambiguous or
-              ill-defined, and providing further clarification or
-              explanation.
-
-         (3)  Specific Issues -- discusses protocol design and
-              implementation issues that were not included in the walk-
-              through.
-
-         (4)  Interfaces -- discusses the service interface to the next
-              higher layer.
-
-         (5)  Summary -- contains a summary of the requirements of the
-              section.
-
-         Under many of the individual topics in this document, there is
-         parenthetical material labeled "DISCUSSION" or
-         "IMPLEMENTATION".  This material is intended to give
-         clarification and explanation of the preceding requirements
-         text.  It also includes some suggestions on possible future
-         directions or developments.  The implementation material
-         contains suggested approaches that an implementor may want to
-         consider.
-
-         The summary sections are intended to be guides and indexes to
-         the text, but are necessarily cryptic and incomplete.  The
-         summaries should never be used or referenced separately from
-         the complete RFC.
-
-      1.3.2  Requirements
-
-         In this document, the words that are used to define the
-         significance of each particular requirement are capitalized.
-         These words are:
-
-
-
-Internet Engineering Task Force                                [Page 10]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         *    "MUST"
-
-              This word or the adjective "REQUIRED" means that the item
-              is an absolute requirement of the specification.
-
-         *    "SHOULD"
-
-              This word or the adjective "RECOMMENDED" means that there
-              may exist valid reasons in particular circumstances to
-              ignore this item, but the full implications should be
-              understood and the case carefully weighed before choosing
-              a different course.
-
-         *    "MAY"
-
-              This word or the adjective "OPTIONAL" means that this item
-              is truly optional.  One vendor may choose to include the
-              item because a particular marketplace requires it or
-              because it enhances the product, for example; another
-              vendor may omit the same item.
-
-
-         An implementation is not compliant if it fails to satisfy one
-         or more of the MUST requirements for the protocols it
-         implements.  An implementation that satisfies all the MUST and
-         all the SHOULD requirements for its protocols is said to be
-         "unconditionally compliant"; one that satisfies all the MUST
-         requirements but not all the SHOULD requirements for its
-         protocols is said to be "conditionally compliant".
-
-      1.3.3  Terminology
-
-         This document uses the following technical terms:
-
-         Segment
-              A segment is the unit of end-to-end transmission in the
-              TCP protocol.  A segment consists of a TCP header followed
-              by application data.  A segment is transmitted by
-              encapsulation in an IP datagram.
-
-         Message
-              This term is used by some application layer protocols
-              (particularly SMTP) for an application data unit.
-
-         Datagram
-              A [UDP] datagram is the unit of end-to-end transmission in
-              the UDP protocol.
-
-
-
-
-Internet Engineering Task Force                                [Page 11]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         Multihomed
-              A host is said to be multihomed if it has multiple IP
-              addresses to connected networks.
-
-
-
-   1.4  Acknowledgments
-
-      This document incorporates contributions and comments from a large
-      group of Internet protocol experts, including representatives of
-      university and research labs, vendors, and government agencies.
-      It was assembled primarily by the Host Requirements Working Group
-      of the Internet Engineering Task Force (IETF).
-
-      The Editor would especially like to acknowledge the tireless
-      dedication of the following people, who attended many long
-      meetings and generated 3 million bytes of electronic mail over the
-      past 18 months in pursuit of this document: Philip Almquist, Dave
-      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
-      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
-      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
-      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
-      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
-
-      In addition, the following people made major contributions to the
-      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
-      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
-      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
-      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
-      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
-      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
-      Technology), and Mike StJohns (DCA).  The following also made
-      significant contributions to particular areas: Eric Allman
-      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
-      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
-      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
-      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
-      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
-      (Toronto).
-
-      We are grateful to all, including any contributors who may have
-      been inadvertently omitted from this list.
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 12]
-
-
-
-
-RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
-
-
-2.  GENERAL ISSUES
-
-   This section contains general requirements that may be applicable to
-   all application-layer protocols.
-
-   2.1  Host Names and Numbers
-
-      The syntax of a legal Internet host name was specified in RFC-952
-      [DNS:4].  One aspect of host name syntax is hereby changed: the
-      restriction on the first character is relaxed to allow either a
-      letter or a digit.  Host software MUST support this more liberal
-      syntax.
-
-      Host software MUST handle host names of up to 63 characters and
-      SHOULD handle host names of up to 255 characters.
-
-      Whenever a user inputs the identity of an Internet host, it SHOULD
-      be possible to enter either (1) a host domain name or (2) an IP
-      address in dotted-decimal ("#.#.#.#") form.  The host SHOULD check
-      the string syntactically for a dotted-decimal number before
-      looking it up in the Domain Name System.
-
-      DISCUSSION:
-           This last requirement is not intended to specify the complete
-           syntactic form for entering a dotted-decimal host number;
-           that is considered to be a user-interface issue.  For
-           example, a dotted-decimal number must be enclosed within
-           "[ ]" brackets for SMTP mail (see Section 5.2.17).  This
-           notation could be made universal within a host system,
-           simplifying the syntactic checking for a dotted-decimal
-           number.
-
-           If a dotted-decimal number can be entered without such
-           identifying delimiters, then a full syntactic check must be
-           made, because a segment of a host domain name is now allowed
-           to begin with a digit and could legally be entirely numeric
-           (see Section 6.1.2.4).  However, a valid host name can never
-           have the dotted-decimal form #.#.#.#, since at least the
-           highest-level component label will be alphabetic.
-
-   2.2  Using Domain Name Service
-
-      Host domain names MUST be translated to IP addresses as described
-      in Section 6.1.
-
-      Applications using domain name services MUST be able to cope with
-      soft error conditions.  Applications MUST wait a reasonable
-      interval between successive retries due to a soft error, and MUST
-
-
-
-Internet Engineering Task Force                                [Page 13]
-
-
-
-
-RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
-
-
-      allow for the possibility that network problems may deny service
-      for hours or even days.
-
-      An application SHOULD NOT rely on the ability to locate a WKS
-      record containing an accurate listing of all services at a
-      particular host address, since the WKS RR type is not often used
-      by Internet sites.  To confirm that a service is present, simply
-      attempt to use it.
-
-   2.3  Applications on Multihomed hosts
-
-      When the remote host is multihomed, the name-to-address
-      translation will return a list of alternative IP addresses.  As
-      specified in Section 6.1.3.4, this list should be in order of
-      decreasing preference.  Application protocol implementations
-      SHOULD be prepared to try multiple addresses from the list until
-      success is obtained.  More specific requirements for SMTP are
-      given in Section 5.3.4.
-
-      When the local host is multihomed, a UDP-based request/response
-      application SHOULD send the response with an IP source address
-      that is the same as the specific destination address of the UDP
-      request datagram.  The "specific destination address" is defined
-      in the "IP Addressing" section of the companion RFC [INTRO:1].
-
-      Similarly, a server application that opens multiple TCP
-      connections to the same client SHOULD use the same local IP
-      address for all.
-
-   2.4  Type-of-Service
-
-      Applications MUST select appropriate TOS values when they invoke
-      transport layer services, and these values MUST be configurable.
-      Note that a TOS value contains 5 bits, of which only the most-
-      significant 3 bits are currently defined; the other two bits MUST
-      be zero.
-
-      DISCUSSION:
-           As gateway algorithms are developed to implement Type-of-
-           Service, the recommended values for various application
-           protocols may change.  In addition, it is likely that
-           particular combinations of users and Internet paths will want
-           non-standard TOS values.  For these reasons, the TOS values
-           must be configurable.
-
-           See the latest version of the "Assigned Numbers" RFC
-           [INTRO:5] for the recommended TOS values for the major
-           application protocols.
-
-
-
-Internet Engineering Task Force                                [Page 14]
-
-
-
-
-RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
-
-
-   2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY
-
-                                               |          | | | |S| |
-                                               |          | | | |H| |F
-                                               |          | | | |O|M|o
-                                               |          | |S| |U|U|o
-                                               |          | |H| |L|S|t
-                                               |          |M|O| |D|T|n
-                                               |          |U|U|M| | |o
-                                               |          |S|L|A|N|N|t
-                                               |          |T|D|Y|O|O|t
-FEATURE                                        |SECTION   | | | |T|T|e
------------------------------------------------|----------|-|-|-|-|-|--
-                                               |          | | | | | |
-User interfaces:                               |          | | | | | |
-  Allow host name to begin with digit          |2.1       |x| | | | |
-  Host names of up to 635 characters           |2.1       |x| | | | |
-  Host names of up to 255 characters           |2.1       | |x| | | |
-  Support dotted-decimal host numbers          |2.1       | |x| | | |
-  Check syntactically for dotted-dec first     |2.1       | |x| | | |
-                                               |          | | | | | |
-Map domain names per Section 6.1               |2.2       |x| | | | |
-Cope with soft DNS errors                      |2.2       |x| | | | |
-   Reasonable interval between retries         |2.2       |x| | | | |
-   Allow for long outages                      |2.2       |x| | | | |
-Expect WKS records to be available             |2.2       | | | |x| |
-                                               |          | | | | | |
-Try multiple addr's for remote multihomed host |2.3       | |x| | | |
-UDP reply src addr is specific dest of request |2.3       | |x| | | |
-Use same IP addr for related TCP connections   |2.3       | |x| | | |
-Specify appropriate TOS values                 |2.4       |x| | | | |
-  TOS values configurable                      |2.4       |x| | | | |
-  Unused TOS bits zero                         |2.4       |x| | | | |
-                                               |          | | | | | |
-                                               |          | | | | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 15]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-3.  REMOTE LOGIN -- TELNET PROTOCOL
-
-   3.1  INTRODUCTION
-
-      Telnet is the standard Internet application protocol for remote
-      login.  It provides the encoding rules to link a user's
-      keyboard/display on a client ("user") system with a command
-      interpreter on a remote server system.  A subset of the Telnet
-      protocol is also incorporated within other application protocols,
-      e.g., FTP and SMTP.
-
-      Telnet uses a single TCP connection, and its normal data stream
-      ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with
-      escape sequences to embed control functions.  Telnet also allows
-      the negotiation of many optional modes and functions.
-
-      The primary Telnet specification is to be found in RFC-854
-      [TELNET:1], while the options are defined in many other RFCs; see
-      Section 7 for references.
-
-   3.2  PROTOCOL WALK-THROUGH
-
-      3.2.1  Option Negotiation: RFC-854, pp. 2-3
-
-         Every Telnet implementation MUST include option negotiation and
-         subnegotiation machinery [TELNET:2].
-
-         A host MUST carefully follow the rules of RFC-854 to avoid
-         option-negotiation loops.  A host MUST refuse (i.e, reply
-         WONT/DONT to a DO/WILL) an unsupported option.  Option
-         negotiation SHOULD continue to function (even if all requests
-         are refused) throughout the lifetime of a Telnet connection.
-
-         If all option negotiations fail, a Telnet implementation MUST
-         default to, and support, an NVT.
-
-         DISCUSSION:
-              Even though more sophisticated "terminals" and supporting
-              option negotiations are becoming the norm, all
-              implementations must be prepared to support an NVT for any
-              user-server communication.
-
-      3.2.2  Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
-
-         On a host that never sends the Telnet command Go Ahead (GA),
-         the Telnet Server MUST attempt to negotiate the Suppress Go
-         Ahead option (i.e., send "WILL Suppress Go Ahead").  A User or
-         Server Telnet MUST always accept negotiation of the Suppress Go
-
-
-
-Internet Engineering Task Force                                [Page 16]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-         Ahead option.
-
-         When it is driving a full-duplex terminal for which GA has no
-         meaning, a User Telnet implementation MAY ignore GA commands.
-
-         DISCUSSION:
-              Half-duplex ("locked-keyboard") line-at-a-time terminals
-              for which the Go-Ahead mechanism was designed have largely
-              disappeared from the scene.  It turned out to be difficult
-              to implement sending the Go-Ahead signal in many operating
-              systems, even some systems that support native half-duplex
-              terminals.  The difficulty is typically that the Telnet
-              server code does not have access to information about
-              whether the user process is blocked awaiting input from
-              the Telnet connection, i.e., it cannot reliably determine
-              when to send a GA command.  Therefore, most Telnet Server
-              hosts do not send GA commands.
-
-              The effect of the rules in this section is to allow either
-              end of a Telnet connection to veto the use of GA commands.
-
-              There is a class of half-duplex terminals that is still
-              commercially important: "data entry terminals," which
-              interact in a full-screen manner.  However, supporting
-              data entry terminals using the Telnet protocol does not
-              require the Go Ahead signal; see Section 3.3.2.
-
-      3.2.3  Control Functions: RFC-854, pp. 7-8
-
-         The list of Telnet commands has been extended to include EOR
-         (End-of-Record), with code 239 [TELNET:9].
-
-         Both User and Server Telnets MAY support the control functions
-         EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP,
-         SB, and SE.
-
-         A host MUST be able to receive and ignore any Telnet control
-         functions that it does not support.
-
-         DISCUSSION:
-              Note that a Server Telnet is required to support the
-              Telnet IP (Interrupt Process) function, even if the server
-              host has an equivalent in-stream function (e.g., Control-C
-              in many systems).  The Telnet IP function may be stronger
-              than an in-stream interrupt command, because of the out-
-              of-band effect of TCP urgent data.
-
-              The EOR control function may be used to delimit the
-
-
-
-Internet Engineering Task Force                                [Page 17]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              stream.  An important application is data entry terminal
-              support (see Section 3.3.2).  There was concern that since
-              EOR had not been defined in RFC-854, a host that was not
-              prepared to correctly ignore unknown Telnet commands might
-              crash if it received an EOR.  To protect such hosts, the
-              End-of-Record option [TELNET:9] was introduced; however, a
-              properly implemented Telnet program will not require this
-              protection.
-
-      3.2.4  Telnet "Synch" Signal: RFC-854, pp. 8-10
-
-         When it receives "urgent" TCP data, a User or Server Telnet
-         MUST discard all data except Telnet commands until the DM (and
-         end of urgent) is reached.
-
-         When it sends Telnet IP (Interrupt Process), a User Telnet
-         SHOULD follow it by the Telnet "Synch" sequence, i.e., send as
-         TCP urgent data the sequence "IAC IP IAC DM".  The TCP urgent
-         pointer points to the DM octet.
-
-         When it receives a Telnet IP command, a Server Telnet MAY send
-         a Telnet "Synch" sequence back to the user, to flush the output
-         stream.  The choice ought to be consistent with the way the
-         server operating system behaves when a local user interrupts a
-         process.
-
-         When it receives a Telnet AO command, a Server Telnet MUST send
-         a Telnet "Synch" sequence back to the user, to flush the output
-         stream.
-
-         A User Telnet SHOULD have the capability of flushing output
-         when it sends a Telnet IP; see also Section 3.4.5.
-
-         DISCUSSION:
-              There are three possible ways for a User Telnet to flush
-              the stream of server output data:
-
-              (1)  Send AO after IP.
-
-                   This will cause the server host to send a "flush-
-                   buffered-output" signal to its operating system.
-                   However, the AO may not take effect locally, i.e.,
-                   stop terminal output at the User Telnet end, until
-                   the Server Telnet has received and processed the AO
-                   and has sent back a "Synch".
-
-              (2)  Send DO TIMING-MARK [TELNET:7] after IP, and discard
-                   all output locally until a WILL/WONT TIMING-MARK is
-
-
-
-Internet Engineering Task Force                                [Page 18]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-                   received from the Server Telnet.
-
-                   Since the DO TIMING-MARK will be processed after the
-                   IP at the server, the reply to it should be in the
-                   right place in the output data stream.  However, the
-                   TIMING-MARK will not send a "flush buffered output"
-                   signal to the server operating system.  Whether or
-                   not this is needed is dependent upon the server
-                   system.
-
-              (3)  Do both.
-
-              The best method is not entirely clear, since it must
-              accommodate a number of existing server hosts that do not
-              follow the Telnet standards in various ways.  The safest
-              approach is probably to provide a user-controllable option
-              to select (1), (2), or (3).
-
-      3.2.5  NVT Printer and Keyboard: RFC-854, p. 11
-
-         In NVT mode, a Telnet SHOULD NOT send characters with the
-         high-order bit 1, and MUST NOT send it as a parity bit.
-         Implementations that pass the high-order bit to applications
-         SHOULD negotiate binary mode (see Section 3.2.6).
-
-
-         DISCUSSION:
-              Implementors should be aware that a strict reading of
-              RFC-854 allows a client or server expecting NVT ASCII to
-              ignore characters with the high-order bit set.  In
-              general, binary mode is expected to be used for
-              transmission of an extended (beyond 7-bit) character set
-              with Telnet.
-
-              However, there exist applications that really need an 8-
-              bit NVT mode, which is currently not defined, and these
-              existing applications do set the high-order bit during
-              part or all of the life of a Telnet connection.  Note that
-              binary mode is not the same as 8-bit NVT mode, since
-              binary mode turns off end-of-line processing.  For this
-              reason, the requirements on the high-order bit are stated
-              as SHOULD, not MUST.
-
-              RFC-854 defines a minimal set of properties of a "network
-              virtual terminal" or NVT; this is not meant to preclude
-              additional features in a real terminal.  A Telnet
-              connection is fully transparent to all 7-bit ASCII
-              characters, including arbitrary ASCII control characters.
-
-
-
-Internet Engineering Task Force                                [Page 19]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              For example, a terminal might support full-screen commands
-              coded as ASCII escape sequences; a Telnet implementation
-              would pass these sequences as uninterpreted data.  Thus,
-              an NVT should not be conceived as a terminal type of a
-              highly-restricted device.
-
-      3.2.6  Telnet Command Structure: RFC-854, p. 13
-
-         Since options may appear at any point in the data stream, a
-         Telnet escape character (known as IAC, with the value 255) to
-         be sent as data MUST be doubled.
-
-      3.2.7  Telnet Binary Option: RFC-856
-
-         When the Binary option has been successfully negotiated,
-         arbitrary 8-bit characters are allowed.  However, the data
-         stream MUST still be scanned for IAC characters, any embedded
-         Telnet commands MUST be obeyed, and data bytes equal to IAC
-         MUST be doubled.  Other character processing (e.g., replacing
-         CR by CR NUL or by CR LF) MUST NOT be done.  In particular,
-         there is no end-of-line convention (see Section 3.3.1) in
-         binary mode.
-
-         DISCUSSION:
-              The Binary option is normally negotiated in both
-              directions, to change the Telnet connection from NVT mode
-              to "binary mode".
-
-              The sequence IAC EOR can be used to delimit blocks of data
-              within a binary-mode Telnet stream.
-
-      3.2.8  Telnet Terminal-Type Option: RFC-1091
-
-         The Terminal-Type option MUST use the terminal type names
-         officially defined in the Assigned Numbers RFC [INTRO:5], when
-         they are available for the particular terminal.  However, the
-         receiver of a Terminal-Type option MUST accept any name.
-
-         DISCUSSION:
-              RFC-1091 [TELNET:10] updates an earlier version of the
-              Terminal-Type option defined in RFC-930.  The earlier
-              version allowed a server host capable of supporting
-              multiple terminal types to learn the type of a particular
-              client's terminal, assuming that each physical terminal
-              had an intrinsic type.  However, today a "terminal" is
-              often really a terminal emulator program running in a PC,
-              perhaps capable of emulating a range of terminal types.
-              Therefore, RFC-1091 extends the specification to allow a
-
-
-
-Internet Engineering Task Force                                [Page 20]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              more general terminal-type negotiation between User and
-              Server Telnets.
-
-   3.3  SPECIFIC ISSUES
-
-      3.3.1  Telnet End-of-Line Convention
-
-         The Telnet protocol defines the sequence CR LF to mean "end-
-         of-line".  For terminal input, this corresponds to a command-
-         completion or "end-of-line" key being pressed on a user
-         terminal; on an ASCII terminal, this is the CR key, but it may
-         also be labelled "Return" or "Enter".
-
-         When a Server Telnet receives the Telnet end-of-line sequence
-         CR LF as input from a remote terminal, the effect MUST be the
-         same as if the user had pressed the "end-of-line" key on a
-         local terminal.  On server hosts that use ASCII, in particular,
-         receipt of the Telnet sequence CR LF must cause the same effect
-         as a local user pressing the CR key on a local terminal.  Thus,
-         CR LF and CR NUL MUST have the same effect on an ASCII server
-         host when received as input over a Telnet connection.
-
-         A User Telnet MUST be able to send any of the forms: CR LF, CR
-         NUL, and LF.  A User Telnet on an ASCII host SHOULD have a
-         user-controllable mode to send either CR LF or CR NUL when the
-         user presses the "end-of-line" key, and CR LF SHOULD be the
-         default.
-
-         The Telnet end-of-line sequence CR LF MUST be used to send
-         Telnet data that is not terminal-to-computer (e.g., for Server
-         Telnet sending output, or the Telnet protocol incorporated
-         another application protocol).
-
-         DISCUSSION:
-              To allow interoperability between arbitrary Telnet clients
-              and servers, the Telnet protocol defined a standard
-              representation for a line terminator.  Since the ASCII
-              character set includes no explicit end-of-line character,
-              systems have chosen various representations, e.g., CR, LF,
-              and the sequence CR LF.  The Telnet protocol chose the CR
-              LF sequence as the standard for network transmission.
-
-              Unfortunately, the Telnet protocol specification in RFC-
-              854 [TELNET:1] has turned out to be somewhat ambiguous on
-              what character(s) should be sent from client to server for
-              the "end-of-line" key.  The result has been a massive and
-              continuing interoperability headache, made worse by
-              various faulty implementations of both User and Server
-
-
-
-Internet Engineering Task Force                                [Page 21]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              Telnets.
-
-              Although the Telnet protocol is based on a perfectly
-              symmetric model, in a remote login session the role of the
-              user at a terminal differs from the role of the server
-              host.  For example, RFC-854 defines the meaning of CR, LF,
-              and CR LF as output from the server, but does not specify
-              what the User Telnet should send when the user presses the
-              "end-of-line" key on the terminal; this turns out to be
-              the point at issue.
-
-              When a user presses the "end-of-line" key, some User
-              Telnet implementations send CR LF, while others send CR
-              NUL (based on a different interpretation of the same
-              sentence in RFC-854).  These will be equivalent for a
-              correctly-implemented ASCII server host, as discussed
-              above.  For other servers, a mode in the User Telnet is
-              needed.
-
-              The existence of User Telnets that send only CR NUL when
-              CR is pressed creates a dilemma for non-ASCII hosts: they
-              can either treat CR NUL as equivalent to CR LF in input,
-              thus precluding the possibility of entering a "bare" CR,
-              or else lose complete interworking.
-
-              Suppose a user on host A uses Telnet to log into a server
-              host B, and then execute B's User Telnet program to log
-              into server host C.  It is desirable for the Server/User
-              Telnet combination on B to be as transparent as possible,
-              i.e., to appear as if A were connected directly to C.  In
-              particular, correct implementation will make B transparent
-              to Telnet end-of-line sequences, except that CR LF may be
-              translated to CR NUL or vice versa.
-
-         IMPLEMENTATION:
-              To understand Telnet end-of-line issues, one must have at
-              least a general model of the relationship of Telnet to the
-              local operating system.  The Server Telnet process is
-              typically coupled into the terminal driver software of the
-              operating system as a pseudo-terminal.  A Telnet end-of-
-              line sequence received by the Server Telnet must have the
-              same effect as pressing the end-of-line key on a real
-              locally-connected terminal.
-
-              Operating systems that support interactive character-at-
-              a-time applications (e.g., editors) typically have two
-              internal modes for their terminal I/O: a formatted mode,
-              in which local conventions for end-of-line and other
-
-
-
-Internet Engineering Task Force                                [Page 22]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              formatting rules have been applied to the data stream, and
-              a "raw" mode, in which the application has direct access
-              to every character as it was entered.  A Server Telnet
-              must be implemented in such a way that these modes have
-              the same effect for remote as for local terminals.  For
-              example, suppose a CR LF or CR NUL is received by the
-              Server Telnet on an ASCII host.  In raw mode, a CR
-              character is passed to the application; in formatted mode,
-              the local system's end-of-line convention is used.
-
-      3.3.2  Data Entry Terminals
-
-         DISCUSSION:
-              In addition to the line-oriented and character-oriented
-              ASCII terminals for which Telnet was designed, there are
-              several families of video display terminals that are
-              sometimes known as "data entry terminals" or DETs.  The
-              IBM 3270 family is a well-known example.
-
-              Two Internet protocols have been designed to support
-              generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET
-              option [TELNET:18, TELNET:19].  The DET option drives a
-              data entry terminal over a Telnet connection using (sub-)
-              negotiation.  SUPDUP is a completely separate terminal
-              protocol, which can be entered from Telnet by negotiation.
-              Although both SUPDUP and the DET option have been used
-              successfully in particular environments, neither has
-              gained general acceptance or wide implementation.
-
-              A different approach to DET interaction has been developed
-              for supporting the IBM 3270 family through Telnet,
-              although the same approach would be applicable to any DET.
-              The idea is to enter a "native DET" mode, in which the
-              native DET input/output stream is sent as binary data.
-              The Telnet EOR command is used to delimit logical records
-              (e.g., "screens") within this binary stream.
-
-         IMPLEMENTATION:
-              The rules for entering and leaving native DET mode are as
-              follows:
-
-              o    The Server uses the Terminal-Type option [TELNET:10]
-                   to learn that the client is a DET.
-
-              o    It is conventional, but not required, that both ends
-                   negotiate the EOR option [TELNET:9].
-
-              o    Both ends negotiate the Binary option [TELNET:3] to
-
-
-
-Internet Engineering Task Force                                [Page 23]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-                   enter native DET mode.
-
-              o    When either end negotiates out of binary mode, the
-                   other end does too, and the mode then reverts to
-                   normal NVT.
-
-
-      3.3.3  Option Requirements
-
-         Every Telnet implementation MUST support the Binary option
-         [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and
-         SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-
-         Record [TELNET:9], and Extended Options List [TELNET:8]
-         options.
-
-         A User or Server Telnet SHOULD support the Window Size Option
-         [TELNET:12] if the local operating system provides the
-         corresponding capability.
-
-         DISCUSSION:
-              Note that the End-of-Record option only signifies that a
-              Telnet can receive a Telnet EOR without crashing;
-              therefore, every Telnet ought to be willing to accept
-              negotiation of the End-of-Record option.  See also the
-              discussion in Section 3.2.3.
-
-      3.3.4  Option Initiation
-
-         When the Telnet protocol is used in a client/server situation,
-         the server SHOULD initiate negotiation of the terminal
-         interaction mode it expects.
-
-         DISCUSSION:
-              The Telnet protocol was defined to be perfectly
-              symmetrical, but its application is generally asymmetric.
-              Remote login has been known to fail because NEITHER side
-              initiated negotiation of the required non-default terminal
-              modes.  It is generally the server that determines the
-              preferred mode, so the server needs to initiate the
-              negotiation; since the negotiation is symmetric, the user
-              can also initiate it.
-
-         A client (User Telnet) SHOULD provide a means for users to
-         enable and disable the initiation of option negotiation.
-
-         DISCUSSION:
-              A user sometimes needs to connect to an application
-              service (e.g., FTP or SMTP) that uses Telnet for its
-
-
-
-Internet Engineering Task Force                                [Page 24]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              control stream but does not support Telnet options.  User
-              Telnet may be used for this purpose if initiation of
-              option negotiation is  disabled.
-
-      3.3.5  Telnet Linemode Option
-
-         DISCUSSION:
-              An important new Telnet option, LINEMODE [TELNET:12], has
-              been proposed.  The LINEMODE option provides a standard
-              way for a User Telnet and a Server Telnet to agree that
-              the client rather than the server will perform terminal
-              character processing.  When the client has prepared a
-              complete line of text, it will send it to the server in
-              (usually) one TCP packet.  This option will greatly
-              decrease the packet cost of Telnet sessions and will also
-              give much better user response over congested or long-
-              delay networks.
-
-              The LINEMODE option allows dynamic switching between local
-              and remote character processing.  For example, the Telnet
-              connection will automatically negotiate into single-
-              character mode while a full screen editor is running, and
-              then return to linemode when the editor is finished.
-
-              We expect that when this RFC is released, hosts should
-              implement the client side of this option, and may
-              implement the server side of this option.  To properly
-              implement the server side, the server needs to be able to
-              tell the local system not to do any input character
-              processing, but to remember its current terminal state and
-              notify the Server Telnet process whenever the state
-              changes.  This will allow password echoing and full screen
-              editors to be handled properly, for example.
-
-   3.4  TELNET/USER INTERFACE
-
-      3.4.1  Character Set Transparency
-
-         User Telnet implementations SHOULD be able to send or receive
-         any 7-bit ASCII character.  Where possible, any special
-         character interpretations by the user host's operating system
-         SHOULD be bypassed so that these characters can conveniently be
-         sent and received on the connection.
-
-         Some character value MUST be reserved as "escape to command
-         mode"; conventionally, doubling this character allows it to be
-         entered as data.  The specific character used SHOULD be user
-         selectable.
-
-
-
-Internet Engineering Task Force                                [Page 25]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-         On binary-mode connections, a User Telnet program MAY provide
-         an escape mechanism for entering arbitrary 8-bit values, if the
-         host operating system doesn't allow them to be entered directly
-         from the keyboard.
-
-         IMPLEMENTATION:
-              The transparency issues are less pressing on servers, but
-              implementors should take care in dealing with issues like:
-              masking off parity bits (sent by an older, non-conforming
-              client) before they reach programs that expect only NVT
-              ASCII, and properly handling programs that request 8-bit
-              data streams.
-
-      3.4.2  Telnet Commands
-
-         A User Telnet program MUST provide a user the capability of
-         entering any of the Telnet control functions IP, AO, or AYT,
-         and SHOULD provide the capability of entering EC, EL, and
-         Break.
-
-      3.4.3  TCP Connection Errors
-
-         A User Telnet program SHOULD report to the user any TCP errors
-         that are reported by the transport layer (see "TCP/Application
-         Layer Interface" section in [INTRO:1]).
-
-      3.4.4  Non-Default Telnet Contact Port
-
-         A User Telnet program SHOULD allow the user to optionally
-         specify a non-standard contact port number at the Server Telnet
-         host.
-
-      3.4.5  Flushing Output
-
-         A User Telnet program SHOULD provide the user the ability to
-         specify whether or not output should be flushed when an IP is
-         sent; see Section 3.2.4.
-
-         For any output flushing scheme that causes the User Telnet to
-         flush output locally until a Telnet signal is received from the
-         Server, there SHOULD be a way for the user to manually restore
-         normal output, in case the Server fails to send the expected
-         signal.
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 26]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-   3.5.  TELNET REQUIREMENTS SUMMARY
-
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-Option Negotiation                               |3.2.1   |x| | | | |
-  Avoid negotiation loops                        |3.2.1   |x| | | | |
-  Refuse unsupported options                     |3.2.1   |x| | | | |
-  Negotiation OK anytime on connection           |3.2.1   | |x| | | |
-  Default to NVT                                 |3.2.1   |x| | | | |
-  Send official name in Term-Type option         |3.2.8   |x| | | | |
-  Accept any name in Term-Type option            |3.2.8   |x| | | | |
-  Implement Binary, Suppress-GA options          |3.3.3   |x| | | | |
-  Echo, Status, EOL, Ext-Opt-List options        |3.3.3   | |x| | | |
-  Implement Window-Size option if appropriate    |3.3.3   | |x| | | |
-  Server initiate mode negotiations              |3.3.4   | |x| | | |
-  User can enable/disable init negotiations      |3.3.4   | |x| | | |
-                                                 |        | | | | | |
-Go-Aheads                                        |        | | | | | |
-  Non-GA server negotiate SUPPRESS-GA option     |3.2.2   |x| | | | |
-  User or Server accept SUPPRESS-GA option       |3.2.2   |x| | | | |
-  User Telnet ignore GA's                        |3.2.2   | | |x| | |
-                                                 |        | | | | | |
-Control Functions                                |        | | | | | |
-  Support SE NOP DM IP AO AYT SB                 |3.2.3   |x| | | | |
-  Support EOR EC EL Break                        |3.2.3   | | |x| | |
-  Ignore unsupported control functions           |3.2.3   |x| | | | |
-  User, Server discard urgent data up to DM      |3.2.4   |x| | | | |
-  User Telnet send "Synch" after IP, AO, AYT     |3.2.4   | |x| | | |
-  Server Telnet reply Synch to IP                |3.2.4   | | |x| | |
-  Server Telnet reply Synch to AO                |3.2.4   |x| | | | |
-  User Telnet can flush output when send IP      |3.2.4   | |x| | | |
-                                                 |        | | | | | |
-Encoding                                         |        | | | | | |
-  Send high-order bit in NVT mode                |3.2.5   | | | |x| |
-  Send high-order bit as parity bit              |3.2.5   | | | | |x|
-  Negot. BINARY if pass high-ord. bit to applic  |3.2.5   | |x| | | |
-  Always double IAC data byte                    |3.2.6   |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 27]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-  Double IAC data byte in binary mode            |3.2.7   |x| | | | |
-  Obey Telnet cmds in binary mode                |3.2.7   |x| | | | |
-  End-of-line, CR NUL in binary mode             |3.2.7   | | | | |x|
-                                                 |        | | | | | |
-End-of-Line                                      |        | | | | | |
-  EOL at Server same as local end-of-line        |3.3.1   |x| | | | |
-  ASCII Server accept CR LF or CR NUL for EOL    |3.3.1   |x| | | | |
-  User Telnet able to send CR LF, CR NUL, or LF  |3.3.1   |x| | | | |
-    ASCII user able to select CR LF/CR NUL       |3.3.1   | |x| | | |
-    User Telnet default mode is CR LF            |3.3.1   | |x| | | |
-  Non-interactive uses CR LF for EOL             |3.3.1   |x| | | | |
-                                                 |        | | | | | |
-User Telnet interface                            |        | | | | | |
-  Input & output all 7-bit characters            |3.4.1   | |x| | | |
-  Bypass local op sys interpretation             |3.4.1   | |x| | | |
-  Escape character                               |3.4.1   |x| | | | |
-     User-settable escape character              |3.4.1   | |x| | | |
-  Escape to enter 8-bit values                   |3.4.1   | | |x| | |
-  Can input IP, AO, AYT                          |3.4.2   |x| | | | |
-  Can input EC, EL, Break                        |3.4.2   | |x| | | |
-  Report TCP connection errors to user           |3.4.3   | |x| | | |
-  Optional non-default contact port              |3.4.4   | |x| | | |
-  Can spec: output flushed when IP sent          |3.4.5   | |x| | | |
-  Can manually restore output mode               |3.4.5   | |x| | | |
-                                                 |        | | | | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 28]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-4.  FILE TRANSFER
-
-   4.1  FILE TRANSFER PROTOCOL -- FTP
-
-      4.1.1  INTRODUCTION
-
-         The File Transfer Protocol FTP is the primary Internet standard
-         for file transfer.  The current specification is contained in
-         RFC-959 [FTP:1].
-
-         FTP uses separate simultaneous TCP connections for control and
-         for data transfer.  The FTP protocol includes many features,
-         some of which are not commonly implemented.  However, for every
-         feature in FTP, there exists at least one implementation.  The
-         minimum implementation defined in RFC-959 was too small, so a
-         somewhat larger minimum implementation is defined here.
-
-         Internet users have been unnecessarily burdened for years by
-         deficient FTP implementations.  Protocol implementors have
-         suffered from the erroneous opinion that implementing FTP ought
-         to be a small and trivial task.  This is wrong, because FTP has
-         a user interface, because it has to deal (correctly) with the
-         whole variety of communication and operating system errors that
-         may occur, and because it has to handle the great diversity of
-         real file systems in the world.
-
-      4.1.2.  PROTOCOL WALK-THROUGH
-
-         4.1.2.1  LOCAL Type: RFC-959 Section 3.1.1.4
-
-            An FTP program MUST support TYPE I ("IMAGE" or binary type)
-            as well as TYPE L 8 ("LOCAL" type with logical byte size 8).
-            A machine whose memory is organized into m-bit words, where
-            m is not a multiple of 8, MAY also support TYPE L m.
-
-            DISCUSSION:
-                 The command "TYPE L 8" is often required to transfer
-                 binary data between a machine whose memory is organized
-                 into (e.g.) 36-bit words and a machine with an 8-bit
-                 byte organization.  For an 8-bit byte machine, TYPE L 8
-                 is equivalent to IMAGE.
-
-                 "TYPE L m" is sometimes specified to the FTP programs
-                 on two m-bit word machines to ensure the correct
-                 transfer of a native-mode binary file from one machine
-                 to the other.  However, this command should have the
-                 same effect on these machines as "TYPE I".
-
-
-
-
-Internet Engineering Task Force                                [Page 29]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-         4.1.2.2  Telnet Format Control: RFC-959 Section 3.1.1.5.2
-
-            A host that makes no distinction between TYPE N and TYPE T
-            SHOULD implement TYPE T to be identical to TYPE N.
-
-            DISCUSSION:
-                 This provision should ease interoperation with hosts
-                 that do make this distinction.
-
-                 Many hosts represent text files internally as strings
-                 of ASCII characters, using the embedded ASCII format
-                 effector characters (LF, BS, FF, ...) to control the
-                 format when a file is printed.  For such hosts, there
-                 is no distinction between "print" files and other
-                 files.  However, systems that use record structured
-                 files typically need a special format for printable
-                 files (e.g., ASA carriage control).   For the latter
-                 hosts, FTP allows a choice of TYPE N or TYPE T.
-
-         4.1.2.3  Page Structure: RFC-959 Section 3.1.2.3 and Appendix I
-
-            Implementation of page structure is NOT RECOMMENDED in
-            general. However, if a host system does need to implement
-            FTP for "random access" or "holey" files, it MUST use the
-            defined page structure format rather than define a new
-            private FTP format.
-
-         4.1.2.4  Data Structure Transformations: RFC-959 Section 3.1.2
-
-            An FTP transformation between record-structure and file-
-            structure SHOULD be invertible, to the extent possible while
-            making the result useful on the target host.
-
-            DISCUSSION:
-                 RFC-959 required strict invertibility between record-
-                 structure and file-structure, but in practice,
-                 efficiency and convenience often preclude it.
-                 Therefore, the requirement is being relaxed.  There are
-                 two different objectives for transferring a file:
-                 processing it on the target host, or just storage.  For
-                 storage, strict invertibility is important.  For
-                 processing, the file created on the target host needs
-                 to be in the format expected by application programs on
-                 that host.
-
-                 As an example of the conflict, imagine a record-
-                 oriented operating system that requires some data files
-                 to have exactly 80 bytes in each record.  While STORing
-
-
-
-Internet Engineering Task Force                                [Page 30]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 a file on such a host, an FTP Server must be able to
-                 pad each line or record to 80 bytes; a later retrieval
-                 of such a file cannot be strictly invertible.
-
-         4.1.2.5  Data Connection Management: RFC-959 Section 3.3
-
-            A User-FTP that uses STREAM mode SHOULD send a PORT command
-            to assign a non-default data port before each transfer
-            command is issued.
-
-            DISCUSSION:
-                 This is required because of the long delay after a TCP
-                 connection is closed until its socket pair can be
-                 reused, to allow multiple transfers during a single FTP
-                 session.  Sending a port command can avoided if a
-                 transfer mode other than stream is used, by leaving the
-                 data transfer connection open between transfers.
-
-         4.1.2.6  PASV Command: RFC-959 Section 4.1.2
-
-            A server-FTP MUST implement the PASV command.
-
-            If multiple third-party transfers are to be executed during
-            the same session, a new PASV command MUST be issued before
-            each transfer command, to obtain a unique port pair.
-
-            IMPLEMENTATION:
-                 The format of the 227 reply to a PASV command is not
-                 well standardized.  In particular, an FTP client cannot
-                 assume that the parentheses shown on page 40 of RFC-959
-                 will be present (and in fact, Figure 3 on page 43 omits
-                 them).  Therefore, a User-FTP program that interprets
-                 the PASV reply must scan the reply for the first digit
-                 of the host and port numbers.
-
-                 Note that the host number h1,h2,h3,h4 is the IP address
-                 of the server host that is sending the reply, and that
-                 p1,p2 is a non-default data transfer port that PASV has
-                 assigned.
-
-         4.1.2.7  LIST and NLST Commands: RFC-959 Section 4.1.3
-
-            The data returned by an NLST command MUST contain only a
-            simple list of legal pathnames, such that the server can use
-            them directly as the arguments of subsequent data transfer
-            commands for the individual files.
-
-            The data returned by a LIST or NLST command SHOULD use an
-
-
-
-Internet Engineering Task Force                                [Page 31]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-            implied TYPE AN, unless the current type is EBCDIC, in which
-            case an implied TYPE EN SHOULD be used.
-
-            DISCUSSION:
-                 Many FTP clients support macro-commands that will get
-                 or put files matching a wildcard specification, using
-                 NLST to obtain a list of pathnames.  The expansion of
-                 "multiple-put" is local to the client, but "multiple-
-                 get" requires cooperation by the server.
-
-                 The implied type for LIST and NLST is designed to
-                 provide compatibility with existing User-FTPs, and in
-                 particular with multiple-get commands.
-
-         4.1.2.8  SITE Command: RFC-959 Section 4.1.3
-
-            A Server-FTP SHOULD use the SITE command for non-standard
-            features, rather than invent new private commands or
-            unstandardized extensions to existing commands.
-
-         4.1.2.9  STOU Command: RFC-959 Section 4.1.3
-
-            The STOU command stores into a uniquely named file.  When it
-            receives an STOU command, a Server-FTP MUST return the
-            actual file name in the "125 Transfer Starting" or the "150
-            Opening Data Connection" message that precedes the transfer
-            (the 250 reply code mentioned in RFC-959 is incorrect).  The
-            exact format of these messages is hereby defined to be as
-            follows:
-
-                125 FILE: pppp
-                150 FILE: pppp
-
-            where pppp represents the unique pathname of the file that
-            will be written.
-
-         4.1.2.10  Telnet End-of-line Code: RFC-959, Page 34
-
-            Implementors MUST NOT assume any correspondence between READ
-            boundaries on the control connection and the Telnet EOL
-            sequences (CR LF).
-
-            DISCUSSION:
-                 Thus, a server-FTP (or User-FTP) must continue reading
-                 characters from the control connection until a complete
-                 Telnet EOL sequence is encountered, before processing
-                 the command (or response, respectively).  Conversely, a
-                 single READ from the control connection may include
-
-
-
-Internet Engineering Task Force                                [Page 32]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 more than one FTP command.
-
-         4.1.2.11  FTP Replies: RFC-959 Section 4.2, Page 35
-
-            A Server-FTP MUST send only correctly formatted replies on
-            the control connection.  Note that RFC-959 (unlike earlier
-            versions of the FTP spec) contains no provision for a
-            "spontaneous" reply message.
-
-            A Server-FTP SHOULD use the reply codes defined in RFC-959
-            whenever they apply.  However, a server-FTP MAY use a
-            different reply code when needed, as long as the general
-            rules of Section 4.2 are followed. When the implementor has
-            a choice between a 4xx and 5xx reply code, a Server-FTP
-            SHOULD send a 4xx (temporary failure) code when there is any
-            reasonable possibility that a failed FTP will succeed a few
-            hours later.
-
-            A User-FTP SHOULD generally use only the highest-order digit
-            of a 3-digit reply code for making a procedural decision, to
-            prevent difficulties when a Server-FTP uses non-standard
-            reply codes.
-
-            A User-FTP MUST be able to handle multi-line replies.  If
-            the implementation imposes a limit on the number of lines
-            and if this limit is exceeded, the User-FTP MUST recover,
-            e.g., by ignoring the excess lines until the end of the
-            multi-line reply is reached.
-
-            A User-FTP SHOULD NOT interpret a 421 reply code ("Service
-            not available, closing control connection") specially, but
-            SHOULD detect closing of the control connection by the
-            server.
-
-            DISCUSSION:
-                 Server implementations that fail to strictly follow the
-                 reply rules often cause FTP user programs to hang.
-                 Note that RFC-959 resolved ambiguities in the reply
-                 rules found in earlier FTP specifications and must be
-                 followed.
-
-                 It is important to choose FTP reply codes that properly
-                 distinguish between temporary and permanent failures,
-                 to allow the successful use of file transfer client
-                 daemons.  These programs depend on the reply codes to
-                 decide whether or not to retry a failed transfer; using
-                 a permanent failure code (5xx) for a temporary error
-                 will cause these programs to give up unnecessarily.
-
-
-
-Internet Engineering Task Force                                [Page 33]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 When the meaning of a reply matches exactly the text
-                 shown in RFC-959, uniformity will be enhanced by using
-                 the RFC-959 text verbatim.  However, a Server-FTP
-                 implementor is encouraged to choose reply text that
-                 conveys specific system-dependent information, when
-                 appropriate.
-
-         4.1.2.12  Connections: RFC-959 Section 5.2
-
-            The words "and the port used" in the second paragraph of
-            this section of RFC-959 are erroneous (historical), and they
-            should be ignored.
-
-            On a multihomed server host, the default data transfer port
-            (L-1) MUST be associated with the same local IP address as
-            the corresponding control connection to port L.
-
-            A user-FTP MUST NOT send any Telnet controls other than
-            SYNCH and IP on an FTP control connection. In particular, it
-            MUST NOT attempt to negotiate Telnet options on the control
-            connection.  However, a server-FTP MUST be capable of
-            accepting and refusing Telnet negotiations (i.e., sending
-            DONT/WONT).
-
-            DISCUSSION:
-                 Although the RFC says: "Server- and User- processes
-                 should follow the conventions for the Telnet
-                 protocol...[on the control connection]", it is not the
-                 intent that Telnet option negotiation is to be
-                 employed.
-
-         4.1.2.13  Minimum Implementation; RFC-959 Section 5.1
-
-            The following commands and options MUST be supported by
-            every server-FTP and user-FTP, except in cases where the
-            underlying file system or operating system does not allow or
-            support a particular command.
-
-                 Type: ASCII Non-print, IMAGE, LOCAL 8
-                 Mode: Stream
-                 Structure: File, Record*
-                 Commands:
-                    USER, PASS, ACCT,
-                    PORT, PASV,
-                    TYPE, MODE, STRU,
-                    RETR, STOR, APPE,
-                    RNFR, RNTO, DELE,
-                    CWD,  CDUP, RMD,  MKD,  PWD,
-
-
-
-Internet Engineering Task Force                                [Page 34]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                    LIST, NLST,
-                    SYST, STAT,
-                    HELP, NOOP, QUIT.
-
-            *Record structure is REQUIRED only for hosts whose file
-            systems support record structure.
-
-            DISCUSSION:
-                 Vendors are encouraged to implement a larger subset of
-                 the protocol.  For example, there are important
-                 robustness features in the protocol (e.g., Restart,
-                 ABOR, block mode) that would be an aid to some Internet
-                 users but are not widely implemented.
-
-                 A host that does not have record structures in its file
-                 system may still accept files with STRU R, recording
-                 the byte stream literally.
-
-      4.1.3  SPECIFIC ISSUES
-
-         4.1.3.1  Non-standard Command Verbs
-
-            FTP allows "experimental" commands, whose names begin with
-            "X".  If these commands are subsequently adopted as
-            standards, there may still be existing implementations using
-            the "X" form.  At present, this is true for the directory
-            commands:
-
-                RFC-959   "Experimental"
-
-                  MKD        XMKD
-                  RMD        XRMD
-                  PWD        XPWD
-                  CDUP       XCUP
-                  CWD        XCWD
-
-            All FTP implementations SHOULD recognize both forms of these
-            commands, by simply equating them with extra entries in the
-            command lookup table.
-
-            IMPLEMENTATION:
-                 A User-FTP can access a server that supports only the
-                 "X" forms by implementing a mode switch, or
-                 automatically using the following procedure: if the
-                 RFC-959 form of one of the above commands is rejected
-                 with a 500 or 502 response code, then try the
-                 experimental form; any other response would be passed
-                 to the user.
-
-
-
-Internet Engineering Task Force                                [Page 35]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-         4.1.3.2  Idle Timeout
-
-            A Server-FTP process SHOULD have an idle timeout, which will
-            terminate the process and close the control connection if
-            the server is inactive (i.e., no command or data transfer in
-            progress) for a long period of time.  The idle timeout time
-            SHOULD be configurable, and the default should be at least 5
-            minutes.
-
-            A client FTP process ("User-PI" in RFC-959) will need
-            timeouts on responses only if it is invoked from a program.
-
-            DISCUSSION:
-                 Without a timeout, a Server-FTP process may be left
-                 pending indefinitely if the corresponding client
-                 crashes without closing the control connection.
-
-         4.1.3.3  Concurrency of Data and Control
-
-            DISCUSSION:
-                 The intent of the designers of FTP was that a user
-                 should be able to send a STAT command at any time while
-                 data transfer was in progress and that the server-FTP
-                 would reply immediately with status -- e.g., the number
-                 of bytes transferred so far.  Similarly, an ABOR
-                 command should be possible at any time during a data
-                 transfer.
-
-                 Unfortunately, some small-machine operating systems
-                 make such concurrent programming difficult, and some
-                 other implementers seek minimal solutions, so some FTP
-                 implementations do not allow concurrent use of the data
-                 and control connections.  Even such a minimal server
-                 must be prepared to accept and defer a STAT or ABOR
-                 command that arrives during data transfer.
-
-         4.1.3.4  FTP Restart Mechanism
-
-            The description of the 110 reply on pp. 40-41 of RFC-959 is
-            incorrect; the correct description is as follows.  A restart
-            reply message, sent over the control connection from the
-            receiving FTP to the User-FTP, has the format:
-
-                110 MARK ssss = rrrr
-
-            Here:
-
-            *    ssss is a text string that appeared in a Restart Marker
-
-
-
-Internet Engineering Task Force                                [Page 36]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 in the data stream and encodes a position in the
-                 sender's file system;
-
-            *    rrrr encodes the corresponding position in the
-                 receiver's file system.
-
-            The encoding, which is specific to a particular file system
-            and network implementation, is always generated and
-            interpreted by the same system, either sender or receiver.
-
-            When an FTP that implements restart receives a Restart
-            Marker in the data stream, it SHOULD force the data to that
-            point to be written to stable storage before encoding the
-            corresponding position rrrr.  An FTP sending Restart Markers
-            MUST NOT assume that 110 replies will be returned
-            synchronously with the data, i.e., it must not await a 110
-            reply before sending more data.
-
-            Two new reply codes are hereby defined for errors
-            encountered in restarting a transfer:
-
-              554 Requested action not taken: invalid REST parameter.
-
-                 A 554 reply may result from a FTP service command that
-                 follows a REST command.  The reply indicates that the
-                 existing file at the Server-FTP cannot be repositioned
-                 as specified in the REST.
-
-              555 Requested action not taken: type or stru mismatch.
-
-                 A 555 reply may result from an APPE command or from any
-                 FTP service command following a REST command.  The
-                 reply indicates that there is some mismatch between the
-                 current transfer parameters (type and stru) and the
-                 attributes of the existing file.
-
-            DISCUSSION:
-                 Note that the FTP Restart mechanism requires that Block
-                 or Compressed mode be used for data transfer, to allow
-                 the Restart Markers to be included within the data
-                 stream.  The frequency of Restart Markers can be low.
-
-                 Restart Markers mark a place in the data stream, but
-                 the receiver may be performing some transformation on
-                 the data as it is stored into stable storage.  In
-                 general, the receiver's encoding must include any state
-                 information necessary to restart this transformation at
-                 any point of the FTP data stream.  For example, in TYPE
-
-
-
-Internet Engineering Task Force                                [Page 37]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 A transfers, some receiver hosts transform CR LF
-                 sequences into a single LF character on disk.   If a
-                 Restart Marker happens to fall between CR and LF, the
-                 receiver must encode in rrrr that the transfer must be
-                 restarted in a "CR has been seen and discarded" state.
-
-                 Note that the Restart Marker is required to be encoded
-                 as a string of printable ASCII characters, regardless
-                 of the type of the data.
-
-                 RFC-959 says that restart information is to be returned
-                 "to the user".  This should not be taken literally.  In
-                 general, the User-FTP should save the restart
-                 information (ssss,rrrr) in stable storage, e.g., append
-                 it to a restart control file.  An empty restart control
-                 file should be created when the transfer first starts
-                 and deleted automatically when the transfer completes
-                 successfully.  It is suggested that this file have a
-                 name derived in an easily-identifiable manner from the
-                 name of the file being transferred and the remote host
-                 name; this is analogous to the means used by many text
-                 editors for naming "backup" files.
-
-                 There are three cases for FTP restart.
-
-                 (1)  User-to-Server Transfer
-
-                      The User-FTP puts Restart Markers <ssss> at
-                      convenient places in the data stream.  When the
-                      Server-FTP receives a Marker, it writes all prior
-                      data to disk, encodes its file system position and
-                      transformation state as rrrr, and returns a "110
-                      MARK ssss = rrrr" reply over the control
-                      connection.  The User-FTP appends the pair
-                      (ssss,rrrr) to its restart control file.
-
-                      To restart the transfer, the User-FTP fetches the
-                      last (ssss,rrrr) pair from the restart control
-                      file, repositions its local file system and
-                      transformation state using ssss, and sends the
-                      command "REST rrrr" to the Server-FTP.
-
-                 (2)  Server-to-User Transfer
-
-                      The Server-FTP puts Restart Markers <ssss> at
-                      convenient places in the data stream.  When the
-                      User-FTP receives a Marker, it writes all prior
-                      data to disk, encodes its file system position and
-
-
-
-Internet Engineering Task Force                                [Page 38]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                      transformation state as rrrr, and appends the pair
-                      (rrrr,ssss) to its restart control file.
-
-                      To restart the transfer, the User-FTP fetches the
-                      last (rrrr,ssss) pair from the restart control
-                      file, repositions its local file system and
-                      transformation state using rrrr, and sends the
-                      command "REST ssss" to the Server-FTP.
-
-                 (3)  Server-to-Server ("Third-Party") Transfer
-
-                      The sending Server-FTP puts Restart Markers <ssss>
-                      at convenient places in the data stream.  When it
-                      receives a Marker, the receiving Server-FTP writes
-                      all prior data to disk, encodes its file system
-                      position and transformation state as rrrr, and
-                      sends a "110 MARK ssss = rrrr" reply over the
-                      control connection to the User.  The User-FTP
-                      appends the pair (ssss,rrrr) to its restart
-                      control file.
-
-                      To restart the transfer, the User-FTP fetches the
-                      last (ssss,rrrr) pair from the restart control
-                      file, sends "REST ssss" to the sending Server-FTP,
-                      and sends "REST rrrr" to the receiving Server-FTP.
-
-
-      4.1.4  FTP/USER INTERFACE
-
-         This section discusses the user interface for a User-FTP
-         program.
-
-         4.1.4.1  Pathname Specification
-
-            Since FTP is intended for use in a heterogeneous
-            environment, User-FTP implementations MUST support remote
-            pathnames as arbitrary character strings, so that their form
-            and content are not limited by the conventions of the local
-            operating system.
-
-            DISCUSSION:
-                 In particular, remote pathnames can be of arbitrary
-                 length, and all the printing ASCII characters as well
-                 as space (0x20) must be allowed.  RFC-959 allows a
-                 pathname to contain any 7-bit ASCII character except CR
-                 or LF.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 39]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-         4.1.4.2  "QUOTE" Command
-
-            A User-FTP program MUST implement a "QUOTE" command that
-            will pass an arbitrary character string to the server and
-            display all resulting response messages to the user.
-
-            To make the "QUOTE" command useful, a User-FTP SHOULD send
-            transfer control commands to the server as the user enters
-            them, rather than saving all the commands and sending them
-            to the server only when a data transfer is started.
-
-            DISCUSSION:
-                 The "QUOTE" command is essential to allow the user to
-                 access servers that require system-specific commands
-                 (e.g., SITE or ALLO), or to invoke new or optional
-                 features that are not implemented by the User-FTP.  For
-                 example, "QUOTE" may be used to specify "TYPE A T" to
-                 send a print file to hosts that require the
-                 distinction, even if the User-FTP does not recognize
-                 that TYPE.
-
-         4.1.4.3  Displaying Replies to User
-
-            A User-FTP SHOULD display to the user the full text of all
-            error reply messages it receives.  It SHOULD have a
-            "verbose" mode in which all commands it sends and the full
-            text and reply codes it receives are displayed, for
-            diagnosis of problems.
-
-         4.1.4.4  Maintaining Synchronization
-
-            The state machine in a User-FTP SHOULD be forgiving of
-            missing and unexpected reply messages, in order to maintain
-            command synchronization with the server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 40]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-      4.1.5   FTP REQUIREMENTS SUMMARY
-
-                                           |               | | | |S| |
-                                           |               | | | |H| |F
-                                           |               | | | |O|M|o
-                                           |               | |S| |U|U|o
-                                           |               | |H| |L|S|t
-                                           |               |M|O| |D|T|n
-                                           |               |U|U|M| | |o
-                                           |               |S|L|A|N|N|t
-                                           |               |T|D|Y|O|O|t
-FEATURE                                    |SECTION        | | | |T|T|e
--------------------------------------------|---------------|-|-|-|-|-|--
-Implement TYPE T if same as TYPE N         |4.1.2.2        | |x| | | |
-File/Record transform invertible if poss.  |4.1.2.4        | |x| | | |
-User-FTP send PORT cmd for stream mode     |4.1.2.5        | |x| | | |
-Server-FTP implement PASV                  |4.1.2.6        |x| | | | |
-  PASV is per-transfer                     |4.1.2.6        |x| | | | |
-NLST reply usable in RETR cmds             |4.1.2.7        |x| | | | |
-Implied type for LIST and NLST             |4.1.2.7        | |x| | | |
-SITE cmd for non-standard features         |4.1.2.8        | |x| | | |
-STOU cmd return pathname as specified      |4.1.2.9        |x| | | | |
-Use TCP READ boundaries on control conn.   |4.1.2.10       | | | | |x|
-                                           |               | | | | | |
-Server-FTP send only correct reply format  |4.1.2.11       |x| | | | |
-Server-FTP use defined reply code if poss. |4.1.2.11       | |x| | | |
-  New reply code following Section 4.2     |4.1.2.11       | | |x| | |
-User-FTP use only high digit of reply      |4.1.2.11       | |x| | | |
-User-FTP handle multi-line reply lines     |4.1.2.11       |x| | | | |
-User-FTP handle 421 reply specially        |4.1.2.11       | | | |x| |
-                                           |               | | | | | |
-Default data port same IP addr as ctl conn |4.1.2.12       |x| | | | |
-User-FTP send Telnet cmds exc. SYNCH, IP   |4.1.2.12       | | | | |x|
-User-FTP negotiate Telnet options          |4.1.2.12       | | | | |x|
-Server-FTP handle Telnet options           |4.1.2.12       |x| | | | |
-Handle "Experimental" directory cmds       |4.1.3.1        | |x| | | |
-Idle timeout in server-FTP                 |4.1.3.2        | |x| | | |
-    Configurable idle timeout              |4.1.3.2        | |x| | | |
-Receiver checkpoint data at Restart Marker |4.1.3.4        | |x| | | |
-Sender assume 110 replies are synchronous  |4.1.3.4        | | | | |x|
-                                           |               | | | | | |
-Support TYPE:                              |               | | | | | |
-  ASCII - Non-Print (AN)                   |4.1.2.13       |x| | | | |
-  ASCII - Telnet (AT) -- if same as AN     |4.1.2.2        | |x| | | |
-  ASCII - Carriage Control (AC)            |959 3.1.1.5.2  | | |x| | |
-  EBCDIC - (any form)                      |959 3.1.1.2    | | |x| | |
-  IMAGE                                    |4.1.2.1        |x| | | | |
-  LOCAL 8                                  |4.1.2.1        |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 41]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-  LOCAL m                                  |4.1.2.1        | | |x| | |2
-                                           |               | | | | | |
-Support MODE:                              |               | | | | | |
-  Stream                                   |4.1.2.13       |x| | | | |
-  Block                                    |959 3.4.2      | | |x| | |
-                                           |               | | | | | |
-Support STRUCTURE:                         |               | | | | | |
-  File                                     |4.1.2.13       |x| | | | |
-  Record                                   |4.1.2.13       |x| | | | |3
-  Page                                     |4.1.2.3        | | | |x| |
-                                           |               | | | | | |
-Support commands:                          |               | | | | | |
-  USER                                     |4.1.2.13       |x| | | | |
-  PASS                                     |4.1.2.13       |x| | | | |
-  ACCT                                     |4.1.2.13       |x| | | | |
-  CWD                                      |4.1.2.13       |x| | | | |
-  CDUP                                     |4.1.2.13       |x| | | | |
-  SMNT                                     |959 5.3.1      | | |x| | |
-  REIN                                     |959 5.3.1      | | |x| | |
-  QUIT                                     |4.1.2.13       |x| | | | |
-                                           |               | | | | | |
-  PORT                                     |4.1.2.13       |x| | | | |
-  PASV                                     |4.1.2.6        |x| | | | |
-  TYPE                                     |4.1.2.13       |x| | | | |1
-  STRU                                     |4.1.2.13       |x| | | | |1
-  MODE                                     |4.1.2.13       |x| | | | |1
-                                           |               | | | | | |
-  RETR                                     |4.1.2.13       |x| | | | |
-  STOR                                     |4.1.2.13       |x| | | | |
-  STOU                                     |959 5.3.1      | | |x| | |
-  APPE                                     |4.1.2.13       |x| | | | |
-  ALLO                                     |959 5.3.1      | | |x| | |
-  REST                                     |959 5.3.1      | | |x| | |
-  RNFR                                     |4.1.2.13       |x| | | | |
-  RNTO                                     |4.1.2.13       |x| | | | |
-  ABOR                                     |959 5.3.1      | | |x| | |
-  DELE                                     |4.1.2.13       |x| | | | |
-  RMD                                      |4.1.2.13       |x| | | | |
-  MKD                                      |4.1.2.13       |x| | | | |
-  PWD                                      |4.1.2.13       |x| | | | |
-  LIST                                     |4.1.2.13       |x| | | | |
-  NLST                                     |4.1.2.13       |x| | | | |
-  SITE                                     |4.1.2.8        | | |x| | |
-  STAT                                     |4.1.2.13       |x| | | | |
-  SYST                                     |4.1.2.13       |x| | | | |
-  HELP                                     |4.1.2.13       |x| | | | |
-  NOOP                                     |4.1.2.13       |x| | | | |
-                                           |               | | | | | |
-
-
-
-Internet Engineering Task Force                                [Page 42]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-User Interface:                            |               | | | | | |
-  Arbitrary pathnames                      |4.1.4.1        |x| | | | |
-  Implement "QUOTE" command                |4.1.4.2        |x| | | | |
-  Transfer control commands immediately    |4.1.4.2        | |x| | | |
-  Display error messages to user           |4.1.4.3        | |x| | | |
-    Verbose mode                           |4.1.4.3        | |x| | | |
-  Maintain synchronization with server     |4.1.4.4        | |x| | | |
-
-Footnotes:
-
-(1)  For the values shown earlier.
-
-(2)  Here m is number of bits in a memory word.
-
-(3)  Required for host with record-structured file system, optional
-     otherwise.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 43]
-
-
-
-
-RFC1123                  FILE TRANSFER -- TFTP              October 1989
-
-
-   4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP
-
-      4.2.1  INTRODUCTION
-
-         The Trivial File Transfer Protocol TFTP is defined in RFC-783
-         [TFTP:1].
-
-         TFTP provides its own reliable delivery with UDP as its
-         transport protocol, using a simple stop-and-wait acknowledgment
-         system.  Since TFTP has an effective window of only one 512
-         octet segment, it can provide good performance only over paths
-         that have a small delay*bandwidth product.  The TFTP file
-         interface is very simple, providing no access control or
-         security.
-
-         TFTP's most important application is bootstrapping a host over
-         a local network, since it is simple and small enough to be
-         easily implemented in EPROM [BOOT:1, BOOT:2].  Vendors are
-         urged to support TFTP for booting.
-
-      4.2.2  PROTOCOL WALK-THROUGH
-
-         The TFTP specification [TFTP:1] is written in an open style,
-         and does not fully specify many parts of the protocol.
-
-         4.2.2.1  Transfer Modes: RFC-783, Page 3
-
-            The transfer mode "mail" SHOULD NOT be supported.
-
-         4.2.2.2  UDP Header: RFC-783, Page 17
-
-            The Length field of a UDP header is incorrectly defined; it
-            includes the UDP header length (8).
-
-      4.2.3  SPECIFIC ISSUES
-
-         4.2.3.1  Sorcerer's Apprentice Syndrome
-
-            There is a serious bug, known as the "Sorcerer's Apprentice
-            Syndrome," in the protocol specification.  While it does not
-            cause incorrect operation of the transfer (the file will
-            always be transferred correctly if the transfer completes),
-            this bug may cause excessive retransmission, which may cause
-            the transfer to time out.
-
-            Implementations MUST contain the fix for this problem: the
-            sender (i.e., the side originating the DATA packets) must
-            never resend the current DATA packet on receipt of a
-
-
-
-Internet Engineering Task Force                                [Page 44]
-
-
-
-
-RFC1123                  FILE TRANSFER -- TFTP              October 1989
-
-
-            duplicate ACK.
-
-            DISCUSSION:
-                 The bug is caused by the protocol rule that either
-                 side, on receiving an old duplicate datagram, may
-                 resend the current datagram.  If a packet is delayed in
-                 the network but later successfully delivered after
-                 either side has timed out and retransmitted a packet, a
-                 duplicate copy of the response may be generated.  If
-                 the other side responds to this duplicate with a
-                 duplicate of its own, then every datagram will be sent
-                 in duplicate for the remainder of the transfer (unless
-                 a datagram is lost, breaking the repetition).  Worse
-                 yet, since the delay is often caused by congestion,
-                 this duplicate transmission will usually causes more
-                 congestion, leading to more delayed packets, etc.
-
-                 The following example may help to clarify this problem.
-
-                     TFTP A                  TFTP B
-
-                 (1)  Receive ACK X-1
-                      Send DATA X
-                 (2)                          Receive DATA X
-                                              Send ACK X
-                        (ACK X is delayed in network,
-                         and  A times out):
-                 (3)  Retransmit DATA X
-
-                 (4)                          Receive DATA X again
-                                              Send ACK X again
-                 (5)  Receive (delayed) ACK X
-                      Send DATA X+1
-                 (6)                          Receive DATA X+1
-                                              Send ACK X+1
-                 (7)  Receive ACK X again
-                      Send DATA X+1 again
-                 (8)                          Receive DATA X+1 again
-                                              Send ACK X+1 again
-                 (9)  Receive ACK X+1
-                      Send DATA X+2
-                 (10)                         Receive DATA X+2
-                                              Send ACK X+3
-                 (11) Receive ACK X+1 again
-                      Send DATA X+2 again
-                 (12)                         Receive DATA X+2 again
-                                              Send ACK X+3 again
-
-
-
-
-Internet Engineering Task Force                                [Page 45]
-
-
-
-
-RFC1123                  FILE TRANSFER -- TFTP              October 1989
-
-
-                 Notice that once the delayed ACK arrives, the protocol
-                 settles down to duplicate all further packets
-                 (sequences 5-8 and 9-12).  The problem is caused not by
-                 either side timing out, but by both sides
-                 retransmitting the current packet when they receive a
-                 duplicate.
-
-                 The fix is to break the retransmission loop, as
-                 indicated above.  This is analogous to the behavior of
-                 TCP.  It is then possible to remove the retransmission
-                 timer on the receiver, since the resent ACK will never
-                 cause any action; this is a useful simplification where
-                 TFTP is used in a bootstrap program.  It is OK to allow
-                 the timer to remain, and it may be helpful if the
-                 retransmitted ACK replaces one that was genuinely lost
-                 in the network.  The sender still requires a retransmit
-                 timer, of course.
-
-         4.2.3.2  Timeout Algorithms
-
-            A TFTP implementation MUST use an adaptive timeout.
-
-            IMPLEMENTATION:
-                 TCP retransmission algorithms provide a useful base to
-                 work from.  At least an exponential backoff of
-                 retransmission timeout is necessary.
-
-         4.2.3.3  Extensions
-
-            A variety of non-standard extensions have been made to TFTP,
-            including additional transfer modes and a secure operation
-            mode (with passwords).  None of these have been
-            standardized.
-
-         4.2.3.4  Access Control
-
-            A server TFTP implementation SHOULD include some
-            configurable access control over what pathnames are allowed
-            in TFTP operations.
-
-         4.2.3.5  Broadcast Request
-
-            A TFTP request directed to a broadcast address SHOULD be
-            silently ignored.
-
-            DISCUSSION:
-                 Due to the weak access control capability of TFTP,
-                 directed broadcasts of TFTP requests to random networks
-
-
-
-Internet Engineering Task Force                                [Page 46]
-
-
-
-
-RFC1123                  FILE TRANSFER -- TFTP              October 1989
-
-
-                 could create a significant security hole.
-
-      4.2.4  TFTP REQUIREMENTS SUMMARY
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-Fix Sorcerer's Apprentice Syndrome               |4.2.3.1 |x| | | | |
-Transfer modes:                                  |        | | | | | |
-  netascii                                       |RFC-783 |x| | | | |
-  octet                                          |RFC-783 |x| | | | |
-  mail                                           |4.2.2.1 | | | |x| |
-  extensions                                     |4.2.3.3 | | |x| | |
-Use adaptive timeout                             |4.2.3.2 |x| | | | |
-Configurable access control                      |4.2.3.4 | |x| | | |
-Silently ignore broadcast request                |4.2.3.5 | |x| | | |
--------------------------------------------------|--------|-|-|-|-|-|--
--------------------------------------------------|--------|-|-|-|-|-|--
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 47]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-5.  ELECTRONIC MAIL -- SMTP and RFC-822
-
-   5.1  INTRODUCTION
-
-      In the TCP/IP protocol suite, electronic mail in a format
-      specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail
-      Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1].
-
-      While SMTP has remained unchanged over the years, the Internet
-      community has made several changes in the way SMTP is used.  In
-      particular, the conversion to the Domain Name System (DNS) has
-      caused changes in address formats and in mail routing.  In this
-      section, we assume familiarity with the concepts and terminology
-      of the DNS, whose requirements are given in Section 6.1.
-
-      RFC-822 specifies the Internet standard format for electronic mail
-      messages.  RFC-822 supercedes an older standard, RFC-733, that may
-      still be in use in a few places, although it is obsolete.  The two
-      formats are sometimes referred to simply by number ("822" and
-      "733").
-
-      RFC-822 is used in some non-Internet mail environments with
-      different mail transfer protocols than SMTP, and SMTP has also
-      been adapted for use in some non-Internet environments.  Note that
-      this document presents the rules for the use of SMTP and RFC-822
-      for the Internet environment only; other mail environments that
-      use these protocols may be expected to have their own rules.
-
-   5.2  PROTOCOL WALK-THROUGH
-
-      This section covers both RFC-821 and RFC-822.
-
-      The SMTP specification in RFC-821 is clear and contains numerous
-      examples, so implementors should not find it difficult to
-      understand.  This section simply updates or annotates portions of
-      RFC-821 to conform with current usage.
-
-      RFC-822 is a long and dense document, defining a rich syntax.
-      Unfortunately, incomplete or defective implementations of RFC-822
-      are common.  In fact, nearly all of the many formats of RFC-822
-      are actually used, so an implementation generally needs to
-      recognize and correctly interpret all of the RFC-822 syntax.
-
-      5.2.1  The SMTP Model: RFC-821 Section 2
-
-         DISCUSSION:
-              Mail is sent by a series of request/response transactions
-              between a client, the "sender-SMTP," and a server, the
-
-
-
-Internet Engineering Task Force                                [Page 48]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              "receiver-SMTP".  These transactions pass (1) the message
-              proper, which is composed of header and body, and (2) SMTP
-              source and destination addresses, referred to as the
-              "envelope".
-
-              The SMTP programs are analogous to Message Transfer Agents
-              (MTAs) of X.400.  There will be another level of protocol
-              software, closer to the end user, that is responsible for
-              composing and analyzing RFC-822 message headers; this
-              component is known as the "User Agent" in X.400, and we
-              use that term in this document.  There is a clear logical
-              distinction between the User Agent and the SMTP
-              implementation, since they operate on different levels of
-              protocol.  Note, however, that this distinction is may not
-              be exactly reflected the structure of typical
-              implementations of Internet mail.  Often there is a
-              program known as the "mailer" that implements SMTP and
-              also some of the User Agent functions; the rest of the
-              User Agent functions are included in a user interface used
-              for entering and reading mail.
-
-              The SMTP envelope is constructed at the originating site,
-              typically by the User Agent when the message is first
-              queued for the Sender-SMTP program.  The envelope
-              addresses may be derived from information in the message
-              header, supplied by the user interface (e.g., to implement
-              a bcc: request), or derived from local configuration
-              information (e.g., expansion of a mailing list).  The SMTP
-              envelope cannot in general be re-derived from the header
-              at a later stage in message delivery, so the envelope is
-              transmitted separately from the message itself using the
-              MAIL and RCPT commands of SMTP.
-
-              The text of RFC-821 suggests that mail is to be delivered
-              to an individual user at a host.  With the advent of the
-              domain system and of mail routing using mail-exchange (MX)
-              resource records, implementors should now think of
-              delivering mail to a user at a domain, which may or may
-              not be a particular host.  This DOES NOT change the fact
-              that SMTP is a host-to-host mail exchange protocol.
-
-      5.2.2  Canonicalization: RFC-821 Section 3.1
-
-         The domain names that a Sender-SMTP sends in MAIL and RCPT
-         commands MUST have been  "canonicalized," i.e., they must be
-         fully-qualified principal names or domain literals, not
-         nicknames or domain abbreviations.  A canonicalized name either
-         identifies a host directly or is an MX name; it cannot be a
-
-
-
-Internet Engineering Task Force                                [Page 49]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         CNAME.
-
-      5.2.3  VRFY and EXPN Commands: RFC-821 Section 3.3
-
-         A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN
-         (this requirement overrides RFC-821).  However, there MAY be
-         configuration information to disable VRFY and EXPN in a
-         particular installation; this might even allow EXPN to be
-         disabled for selected lists.
-
-         A new reply code is defined for the VRFY command:
-
-              252 Cannot VRFY user (e.g., info is not local), but will
-                  take message for this user and attempt delivery.
-
-         DISCUSSION:
-              SMTP users and administrators make regular use of these
-              commands for diagnosing mail delivery problems.  With the
-              increasing use of multi-level mailing list expansion
-              (sometimes more than two levels), EXPN has been
-              increasingly important for diagnosing inadvertent mail
-              loops.  On the other hand,  some feel that EXPN represents
-              a significant privacy, and perhaps even a security,
-              exposure.
-
-      5.2.4  SEND, SOML, and SAML Commands: RFC-821 Section 3.4
-
-         An SMTP MAY implement the commands to send a message to a
-         user's terminal: SEND, SOML, and SAML.
-
-         DISCUSSION:
-              It has been suggested that the use of mail relaying
-              through an MX record is inconsistent with the intent of
-              SEND to deliver a message immediately and directly to a
-              user's terminal.  However, an SMTP receiver that is unable
-              to write directly to the user terminal can return a "251
-              User Not Local" reply to the RCPT following a SEND, to
-              inform the originator of possibly deferred delivery.
-
-      5.2.5  HELO Command: RFC-821 Section 3.5
-
-         The sender-SMTP MUST ensure that the <domain> parameter in a
-         HELO command is a valid principal host domain name for the
-         client host.  As a result, the receiver-SMTP will not have to
-         perform MX resolution on this name in order to validate the
-         HELO parameter.
-
-         The HELO receiver MAY verify that the HELO parameter really
-
-
-
-Internet Engineering Task Force                                [Page 50]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         corresponds to the IP address of the sender.  However, the
-         receiver MUST NOT refuse to accept a message, even if the
-         sender's HELO command fails verification.
-
-         DISCUSSION:
-              Verifying the HELO parameter requires a domain name lookup
-              and may therefore take considerable time.  An alternative
-              tool for tracking bogus mail sources is suggested below
-              (see "DATA Command").
-
-              Note also that the HELO argument is still required to have
-              valid <domain> syntax, since it will appear in a Received:
-              line; otherwise, a 501 error is to be sent.
-
-         IMPLEMENTATION:
-              When HELO parameter validation fails, a suggested
-              procedure is to insert a note about the unknown
-              authenticity of the sender into the message header (e.g.,
-              in the "Received:"  line).
-
-      5.2.6  Mail Relay: RFC-821 Section 3.6
-
-         We distinguish three types of mail (store-and-) forwarding:
-
-         (1)  A simple forwarder or "mail exchanger" forwards a message
-              using private knowledge about the recipient; see section
-              3.2 of RFC-821.
-
-         (2)  An SMTP mail "relay" forwards a message within an SMTP
-              mail environment as the result of an explicit source route
-              (as defined in section 3.6 of RFC-821).  The SMTP relay
-              function uses the "@...:" form of source route from RFC-
-              822 (see Section 5.2.19 below).
-
-         (3)  A mail "gateway" passes a message between different
-              environments.  The rules for mail gateways are discussed
-              below in Section 5.3.7.
-
-         An Internet host that is forwarding a message but is not a
-         gateway to a different mail environment (i.e., it falls under
-         (1) or (2)) SHOULD NOT alter any existing header fields,
-         although the host will add an appropriate Received: line as
-         required in Section 5.2.8.
-
-         A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
-         explicit source route using the "@...:" address form.  Thus,
-         the relay function defined in section  3.6 of RFC-821 should
-         not be used.
-
-
-
-Internet Engineering Task Force                                [Page 51]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         DISCUSSION:
-              The intent is to discourage all source routing and to
-              abolish explicit source routing for mail delivery within
-              the Internet environment.  Source-routing is unnecessary;
-              the simple target address "user@domain" should always
-              suffice.  This is the result of an explicit architectural
-              decision to use universal naming rather than source
-              routing for mail.  Thus, SMTP provides end-to-end
-              connectivity, and the DNS provides globally-unique,
-              location-independent names.  MX records handle the major
-              case where source routing might otherwise be needed.
-
-         A receiver-SMTP MUST accept the explicit source route syntax in
-         the envelope, but it MAY implement the relay function as
-         defined in section 3.6 of RFC-821.  If it does not implement
-         the relay function, it SHOULD attempt to deliver the message
-         directly to the host to the right of the right-most "@" sign.
-
-         DISCUSSION:
-              For example, suppose a host that does not implement the
-              relay function receives a message with the SMTP command:
-              "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and
-              GAMMA represent domain names.  Rather than immediately
-              refusing the message with a 550 error reply as suggested
-              on page 20 of RFC-821, the host should try to forward the
-              message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>".
-              Since this host does not support relaying, it is not
-              required to update the reverse path.
-
-              Some have suggested that source routing may be needed
-              occasionally for manually routing mail around failures;
-              however, the reality and importance of this need is
-              controversial.  The use of explicit SMTP mail relaying for
-              this purpose is discouraged, and in fact it may not be
-              successful, as many host systems do not support it.  Some
-              have used the "%-hack" (see Section 5.2.16) for this
-              purpose.
-
-      5.2.7  RCPT Command: RFC-821 Section 4.1.1
-
-         A host that supports a receiver-SMTP MUST support the reserved
-         mailbox "Postmaster".
-
-         The receiver-SMTP MAY verify RCPT parameters as they arrive;
-         however, RCPT responses MUST NOT be delayed beyond a reasonable
-         time (see Section 5.3.2).
-
-         Therefore, a "250 OK" response to a RCPT does not necessarily
-
-
-
-Internet Engineering Task Force                                [Page 52]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         imply that the delivery address(es) are valid.  Errors found
-         after message acceptance will be reported by mailing a
-         notification message to an appropriate address (see Section
-         5.3.3).
-
-         DISCUSSION:
-              The set of conditions under which a RCPT parameter can be
-              validated immediately is an engineering design choice.
-              Reporting destination mailbox errors to the Sender-SMTP
-              before mail is transferred is generally desirable to save
-              time and network bandwidth, but this advantage is lost if
-              RCPT verification is lengthy.
-
-              For example, the receiver can verify immediately any
-              simple local reference, such as a single locally-
-              registered mailbox.  On the other hand, the "reasonable
-              time" limitation generally implies deferring verification
-              of a mailing list until after the message has been
-              transferred and accepted, since verifying a large mailing
-              list can take a very long time.  An implementation might
-              or might not choose to defer validation of addresses that
-              are non-local and therefore require a DNS lookup.  If a
-              DNS lookup is performed but a soft domain system error
-              (e.g., timeout) occurs, validity must be assumed.
-
-      5.2.8  DATA Command: RFC-821 Section 4.1.1
-
-         Every receiver-SMTP (not just one that "accepts a message for
-         relaying or for final delivery" [SMTP:1]) MUST insert a
-         "Received:" line at the beginning of a message.  In this line,
-         called a "time stamp line" in RFC-821:
-
-         *    The FROM field SHOULD contain both (1) the name of the
-              source host as presented in the HELO command and (2) a
-              domain literal containing the IP address of the source,
-              determined from the TCP connection.
-
-         *    The ID field MAY contain an "@" as suggested in RFC-822,
-              but this is not required.
-
-         *    The FOR field MAY contain a list of <path> entries when
-              multiple RCPT commands have been given.
-
-
-         An Internet mail program MUST NOT change a Received: line that
-         was previously added to the message header.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 53]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         DISCUSSION:
-              Including both the source host and the IP source address
-              in the Received: line may provide enough information for
-              tracking illicit mail sources and eliminate a need to
-              explicitly verify the HELO parameter.
-
-              Received: lines are primarily intended for humans tracing
-              mail routes, primarily of diagnosis of faults.  See also
-              the discussion under 5.3.7.
-
-         When the receiver-SMTP makes "final delivery" of a message,
-         then it MUST pass the MAIL FROM: address from the SMTP envelope
-         with the message, for use if an error notification message must
-         be sent later (see Section 5.3.3).  There is an analogous
-         requirement when gatewaying from the Internet into a different
-         mail environment; see Section 5.3.7.
-
-         DISCUSSION:
-              Note that the final reply to the DATA command depends only
-              upon the successful transfer and storage of the message.
-              Any problem with the destination address(es) must either
-              (1) have been reported in an SMTP error reply to the RCPT
-              command(s), or (2) be reported in a later error message
-              mailed to the originator.
-
-         IMPLEMENTATION:
-              The MAIL FROM: information may be passed as a parameter or
-              in a Return-Path: line inserted at the beginning of the
-              message.
-
-      5.2.9  Command Syntax: RFC-821 Section 4.1.2
-
-         The syntax shown in RFC-821 for the MAIL FROM: command omits
-         the case of an empty path:  "MAIL FROM: <>" (see RFC-821 Page
-         15).  An empty reverse path MUST be supported.
-
-      5.2.10  SMTP Replies:  RFC-821 Section 4.2
-
-         A receiver-SMTP SHOULD send only the reply codes listed in
-         section 4.2.2 of RFC-821 or in this document.  A receiver-SMTP
-         SHOULD use the text shown in examples in RFC-821 whenever
-         appropriate.
-
-         A sender-SMTP MUST determine its actions only by the reply
-         code, not by the text (except for 251 and 551 replies); any
-         text, including no text at all, must be acceptable.  The space
-         (blank) following the reply code is considered part of the
-         text.  Whenever possible, a sender-SMTP SHOULD test only the
-
-
-
-Internet Engineering Task Force                                [Page 54]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         first digit of the reply code, as specified in Appendix E of
-         RFC-821.
-
-         DISCUSSION:
-              Interoperability problems have arisen with SMTP systems
-              using reply codes that are not listed explicitly in RFC-
-              821 Section 4.3 but are legal according to the theory of
-              reply codes explained in Appendix E.
-
-      5.2.11  Transparency: RFC-821 Section 4.5.2
-
-         Implementors MUST be sure that their mail systems always add
-         and delete periods to ensure message transparency.
-
-      5.2.12  WKS Use in MX Processing: RFC-974, p. 5
-
-         RFC-974 [SMTP:3] recommended that the domain system be queried
-         for WKS ("Well-Known Service") records, to verify that each
-         proposed mail target does support SMTP.  Later experience has
-         shown that WKS is not widely supported, so the WKS step in MX
-         processing SHOULD NOT be used.
-
-      The following are notes on RFC-822, organized by section of that
-      document.
-
-      5.2.13  RFC-822 Message Specification: RFC-822 Section 4
-
-         The syntax shown for the Return-path line omits the possibility
-         of a null return path, which is used to prevent looping of
-         error notifications (see Section 5.3.3).  The complete syntax
-         is:
-
-             return = "Return-path"  ":" route-addr
-                    / "Return-path"  ":" "<" ">"
-
-         The set of optional header fields is hereby expanded to include
-         the Content-Type field defined in RFC-1049 [SMTP:7].  This
-         field "allows mail reading systems to automatically identify
-         the type of a structured message body and to process it for
-         display accordingly".  [SMTP:7]  A User Agent MAY support this
-         field.
-
-      5.2.14  RFC-822 Date and Time Specification: RFC-822 Section 5
-
-         The syntax for the date is hereby changed to:
-
-            date = 1*2DIGIT month 2*4DIGIT
-
-
-
-
-Internet Engineering Task Force                                [Page 55]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         All mail software SHOULD use 4-digit years in dates, to ease
-         the transition to the next century.
-
-         There is a strong trend towards the use of numeric timezone
-         indicators, and implementations SHOULD use numeric timezones
-         instead of timezone names.  However, all implementations MUST
-         accept either notation.  If timezone names are used, they MUST
-         be exactly as defined in RFC-822.
-
-         The military time zones are specified incorrectly in RFC-822:
-         they count the wrong way from UT (the signs are reversed).  As
-         a result, military time zones in RFC-822 headers carry no
-         information.
-
-         Finally, note that there is a typo in the definition of "zone"
-         in the syntax summary of appendix D; the correct definition
-         occurs in Section 3 of RFC-822.
-
-      5.2.15  RFC-822 Syntax Change: RFC-822 Section 6.1
-
-         The syntactic definition of "mailbox" in RFC-822 is hereby
-         changed to:
-
-            mailbox =  addr-spec            ; simple address
-                    / [phrase] route-addr   ; name & addr-spec
-
-         That is, the phrase preceding a route address is now OPTIONAL.
-         This change makes the following header field legal, for
-         example:
-
-             From: <craig@nnsc.nsf.net>
-
-      5.2.16  RFC-822  Local-part: RFC-822 Section 6.2
-
-         The basic mailbox address specification has the form: "local-
-         part@domain".  Here "local-part", sometimes called the "left-
-         hand side" of the address, is domain-dependent.
-
-         A host that is forwarding the message but is not the
-         destination host implied by the right-hand side "domain" MUST
-         NOT interpret or modify the "local-part" of the address.
-
-         When mail is to be gatewayed from the Internet mail environment
-         into a foreign mail environment (see Section 5.3.7), routing
-         information for that foreign environment MAY be embedded within
-         the "local-part" of the address.  The gateway will then
-         interpret this local part appropriately for the foreign mail
-         environment.
-
-
-
-Internet Engineering Task Force                                [Page 56]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         DISCUSSION:
-              Although source routes are discouraged within the Internet
-              (see Section 5.2.6), there are non-Internet mail
-              environments whose delivery mechanisms do depend upon
-              source routes.  Source routes for extra-Internet
-              environments can generally be buried in the "local-part"
-              of the address (see Section 5.2.16) while mail traverses
-              the Internet.  When the mail reaches the appropriate
-              Internet mail gateway, the gateway will interpret the
-              local-part and build the necessary address or route for
-              the target mail environment.
-
-              For example, an Internet host might send mail to:
-              "a!b!c!user@gateway-domain".  The complex local part
-              "a!b!c!user" would be uninterpreted within the Internet
-              domain, but could be parsed and understood by the
-              specified mail gateway.
-
-              An embedded source route is sometimes encoded in the
-              "local-part" using "%" as a right-binding routing
-              operator.  For example, in:
-
-                 user%domain%relay3%relay2@relay1
-
-              the "%" convention implies that the mail is to be routed
-              from "relay1" through "relay2", "relay3", and finally to
-              "user" at "domain".  This is commonly known as the "%-
-              hack".  It is suggested that "%" have lower precedence
-              than any other routing operator (e.g., "!") hidden in the
-              local-part; for example, "a!b%c" would be interpreted as
-              "(a!b)%c".
-
-              Only the target host (in this case, "relay1") is permitted
-              to analyze the local-part "user%domain%relay3%relay2".
-
-      5.2.17  Domain Literals: RFC-822 Section 6.2.3
-
-         A mailer MUST be able to accept and parse an Internet domain
-         literal whose content ("dtext"; see RFC-822) is a dotted-
-         decimal host address.  This satisfies the requirement of
-         Section 2.1 for the case of mail.
-
-         An SMTP MUST accept and recognize a domain literal for any of
-         its own IP addresses.
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 57]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-      5.2.18  Common Address Formatting Errors: RFC-822 Section 6.1
-
-         Errors in formatting or parsing 822 addresses are unfortunately
-         common.  This section mentions only the most common errors.  A
-         User Agent MUST accept all valid RFC-822 address formats, and
-         MUST NOT generate illegal address syntax.
-
-         o    A common error is to leave out the semicolon after a group
-              identifier.
-
-         o    Some systems fail to fully-qualify domain names in
-              messages they generate.  The right-hand side of an "@"
-              sign in a header address field MUST be a fully-qualified
-              domain name.
-
-              For example, some systems fail to fully-qualify the From:
-              address; this prevents a "reply" command in the user
-              interface from automatically constructing a return
-              address.
-
-              DISCUSSION:
-                   Although RFC-822 allows the local use of abbreviated
-                   domain names within a domain, the application of
-                   RFC-822 in Internet mail does not allow this.  The
-                   intent is that an Internet host must not send an SMTP
-                   message header containing an abbreviated domain name
-                   in an address field.  This allows the address fields
-                   of the header to be passed without alteration across
-                   the Internet, as required in Section 5.2.6.
-
-         o    Some systems mis-parse multiple-hop explicit source routes
-              such as:
-
-                  @relay1,@relay2,@relay3:user@domain.
-
-
-         o    Some systems over-qualify domain names by adding a
-              trailing dot to some or all domain names in addresses or
-              message-ids.  This violates RFC-822 syntax.
-
-
-      5.2.19  Explicit Source Routes: RFC-822 Section 6.2.7
-
-         Internet host software SHOULD NOT create an RFC-822 header
-         containing an address with an explicit source route, but MUST
-         accept such headers for compatibility with earlier systems.
-
-         DISCUSSION:
-
-
-
-Internet Engineering Task Force                                [Page 58]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              In an understatement, RFC-822 says "The use of explicit
-              source routing is discouraged".  Many hosts implemented
-              RFC-822 source routes incorrectly, so the syntax cannot be
-              used unambiguously in practice.  Many users feel the
-              syntax is ugly.  Explicit source routes are not needed in
-              the mail envelope for delivery; see Section 5.2.6.  For
-              all these reasons, explicit source routes using the RFC-
-              822 notations are not to be used in Internet mail headers.
-
-              As stated in Section 5.2.16, it is necessary to allow an
-              explicit source route to be buried in the local-part of an
-              address, e.g., using the "%-hack", in order to allow mail
-              to be gatewayed into another environment in which explicit
-              source routing is necessary.  The vigilant will observe
-              that there is no way for a User Agent to detect and
-              prevent the use of such implicit source routing when the
-              destination is within the Internet.  We can only
-              discourage source routing of any kind within the Internet,
-              as unnecessary and undesirable.
-
-   5.3  SPECIFIC ISSUES
-
-      5.3.1  SMTP Queueing Strategies
-
-         The common structure of a host SMTP implementation includes
-         user mailboxes, one or more areas for queueing messages in
-         transit, and one or more daemon processes for sending and
-         receiving mail.  The exact structure will vary depending on the
-         needs of the users on the host and the number and size of
-         mailing lists supported by the host.  We describe several
-         optimizations that have proved helpful, particularly for
-         mailers supporting high traffic levels.
-
-         Any queueing strategy MUST include:
-
-         o    Timeouts on all activities.  See Section 5.3.2.
-
-         o    Never sending error messages in response to error
-              messages.
-
-
-         5.3.1.1 Sending Strategy
-
-            The general model of a sender-SMTP is one or more processes
-            that periodically attempt to transmit outgoing mail.  In a
-            typical system, the program that composes a message has some
-            method for requesting immediate attention for a new piece of
-            outgoing mail, while mail that cannot be transmitted
-
-
-
-Internet Engineering Task Force                                [Page 59]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-            immediately MUST be queued and periodically retried by the
-            sender.  A mail queue entry will include not only the
-            message itself but also the envelope information.
-
-            The sender MUST delay retrying a particular destination
-            after one attempt has failed.  In general, the retry
-            interval SHOULD be at least 30 minutes; however, more
-            sophisticated and variable strategies will be beneficial
-            when the sender-SMTP can determine the reason for non-
-            delivery.
-
-            Retries continue until the message is transmitted or the
-            sender gives up; the give-up time generally needs to be at
-            least 4-5 days.  The parameters to the retry algorithm MUST
-            be configurable.
-
-            A sender SHOULD keep a list of hosts it cannot reach and
-            corresponding timeouts, rather than just retrying queued
-            mail items.
-
-            DISCUSSION:
-                 Experience suggests that failures are typically
-                 transient (the target system has crashed), favoring a
-                 policy of two connection attempts in the first hour the
-                 message is in the queue, and then backing off to once
-                 every two or three hours.
-
-                 The sender-SMTP can shorten the queueing delay by
-                 cooperation with the receiver-SMTP.  In particular, if
-                 mail is received from a particular address, it is good
-                 evidence that any mail queued for that host can now be
-                 sent.
-
-                 The strategy may be further modified as a result of
-                 multiple addresses per host (see Section 5.3.4), to
-                 optimize delivery time vs. resource usage.
-
-                 A sender-SMTP may have a large queue of messages for
-                 each unavailable destination host, and if it retried
-                 all these messages in every retry cycle, there would be
-                 excessive Internet overhead and the daemon would be
-                 blocked for a long period.  Note that an SMTP can
-                 generally determine that a delivery attempt has failed
-                 only after a timeout of a minute or more; a one minute
-                 timeout per connection will result in a very large
-                 delay if it is repeated for dozens or even hundreds of
-                 queued messages.
-
-
-
-
-Internet Engineering Task Force                                [Page 60]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-            When the same message is to be delivered to several users on
-            the same host, only one copy of the message SHOULD be
-            transmitted.  That is, the sender-SMTP should use the
-            command sequence: RCPT, RCPT,... RCPT, DATA instead of the
-            sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA.
-            Implementation of this efficiency feature is strongly urged.
-
-            Similarly, the sender-SMTP MAY support multiple concurrent
-            outgoing mail transactions to achieve timely delivery.
-            However, some limit SHOULD be imposed to protect the host
-            from devoting all its resources to mail.
-
-            The use of the different addresses of a multihomed host is
-            discussed below.
-
-         5.3.1.2  Receiving strategy
-
-            The receiver-SMTP SHOULD attempt to keep a pending listen on
-            the SMTP port at all times.  This will require the support
-            of multiple incoming TCP connections for SMTP.  Some limit
-            MAY be imposed.
-
-            IMPLEMENTATION:
-                 When the receiver-SMTP receives mail from a particular
-                 host address, it could notify the sender-SMTP to retry
-                 any mail pending for that host address.
-
-      5.3.2  Timeouts in SMTP
-
-         There are two approaches to timeouts in the sender-SMTP:  (a)
-         limit the time for each SMTP command separately, or (b) limit
-         the time for the entire SMTP dialogue for a single mail
-         message.  A sender-SMTP SHOULD use option (a), per-command
-         timeouts.  Timeouts SHOULD be easily reconfigurable, preferably
-         without recompiling the SMTP code.
-
-         DISCUSSION:
-              Timeouts are an essential feature of an SMTP
-              implementation.  If the timeouts are too long (or worse,
-              there are no timeouts), Internet communication failures or
-              software bugs in receiver-SMTP programs can tie up SMTP
-              processes indefinitely.  If the timeouts are too short,
-              resources will be wasted with attempts that time out part
-              way through message delivery.
-
-              If option (b) is used, the timeout has to be very large,
-              e.g., an hour, to allow time to expand very large mailing
-              lists.  The timeout may also need to increase linearly
-
-
-
-Internet Engineering Task Force                                [Page 61]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              with the size of the message, to account for the time to
-              transmit a very large message.  A large fixed timeout
-              leads to two problems:  a failure can still tie up the
-              sender for a very long time, and very large messages may
-              still spuriously time out (which is a wasteful failure!).
-
-              Using the recommended option (a), a timer is set for each
-              SMTP command and for each buffer of the data transfer.
-              The latter means that the overall timeout is inherently
-              proportional to the size of the message.
-
-         Based on extensive experience with busy mail-relay hosts, the
-         minimum per-command timeout values SHOULD be as follows:
-
-         o    Initial 220 Message: 5 minutes
-
-              A Sender-SMTP process needs to distinguish between a
-              failed TCP connection and a delay in receiving the initial
-              220 greeting message.  Many receiver-SMTPs will accept a
-              TCP connection but delay delivery of the 220 message until
-              their system load will permit more mail to be processed.
-
-         o    MAIL Command: 5 minutes
-
-
-         o    RCPT Command: 5 minutes
-
-              A longer timeout would be required if processing of
-              mailing lists and aliases were not deferred until after
-              the message was accepted.
-
-         o    DATA Initiation: 2 minutes
-
-              This is while awaiting the "354 Start Input" reply to a
-              DATA command.
-
-         o    Data Block: 3 minutes
-
-              This is while awaiting the completion of each TCP SEND
-              call transmitting a chunk of data.
-
-         o    DATA Termination: 10 minutes.
-
-              This is while awaiting the "250 OK" reply. When the
-              receiver gets the final period terminating the message
-              data, it typically performs processing to deliver the
-              message to a user mailbox.  A spurious timeout at this
-              point would be very wasteful, since the message has been
-
-
-
-Internet Engineering Task Force                                [Page 62]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              successfully sent.
-
-         A receiver-SMTP SHOULD have a timeout of at least 5 minutes
-         while it is awaiting the next command from the sender.
-
-      5.3.3  Reliable Mail Receipt
-
-         When the receiver-SMTP accepts a piece of mail (by sending a
-         "250 OK" message in response to DATA), it is accepting
-         responsibility for delivering or relaying the message.  It must
-         take this responsibility seriously, i.e., it MUST NOT lose the
-         message for frivolous reasons, e.g., because the host later
-         crashes or because of a predictable resource shortage.
-
-         If there is a delivery failure after acceptance of a message,
-         the receiver-SMTP MUST formulate and mail a notification
-         message.  This notification MUST be sent using a null ("<>")
-         reverse path in the envelope; see Section 3.6 of RFC-821.  The
-         recipient of this notification SHOULD be the address from the
-         envelope return path (or the Return-Path: line).  However, if
-         this address is null ("<>"),  the receiver-SMTP MUST NOT send a
-         notification.  If the address is an explicit source route, it
-         SHOULD be stripped down to its final hop.
-
-         DISCUSSION:
-              For example, suppose that an error notification must be
-              sent for a message that arrived with:
-              "MAIL FROM:<@a,@b:user@d>".  The notification message
-              should be sent to: "RCPT TO:<user@d>".
-
-              Some delivery failures after the message is accepted by
-              SMTP will be unavoidable.  For example, it may be
-              impossible for the receiver-SMTP to validate all the
-              delivery addresses in RCPT command(s) due to a "soft"
-              domain system error or because the target is a mailing
-              list (see earlier discussion of RCPT).
-
-         To avoid receiving duplicate messages as the result of
-         timeouts, a receiver-SMTP MUST seek to minimize the time
-         required to respond to the final "." that ends a message
-         transfer.  See RFC-1047 [SMTP:4] for a discussion of this
-         problem.
-
-      5.3.4  Reliable Mail Transmission
-
-         To transmit a message, a sender-SMTP determines the IP address
-         of the target host from the destination address in the
-         envelope.  Specifically, it maps the string to the right of the
-
-
-
-Internet Engineering Task Force                                [Page 63]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         "@" sign into an IP address.  This mapping or the transfer
-         itself may fail with a soft error, in which case the sender-
-         SMTP will requeue the outgoing mail for a later retry, as
-         required in Section 5.3.1.1.
-
-         When it succeeds, the mapping can result in a list of
-         alternative delivery addresses rather than a single address,
-         because of (a) multiple MX records, (b) multihoming, or both.
-         To provide reliable mail transmission, the sender-SMTP MUST be
-         able to try (and retry) each of the addresses in this list in
-         order, until a delivery attempt succeeds.  However, there MAY
-         also be a configurable limit on the number of alternate
-         addresses that can be tried.  In any case, a host SHOULD try at
-         least two addresses.
-
-         The following information is to be used to rank the host
-         addresses:
-
-         (1)  Multiple MX Records -- these contain a preference
-              indication that should be used in sorting.  If there are
-              multiple destinations with the same preference and there
-              is no clear reason to favor one (e.g., by address
-              preference), then the sender-SMTP SHOULD pick one at
-              random to spread the load across multiple mail exchanges
-              for a specific organization; note that this is a
-              refinement of the procedure in [DNS:3].
-
-         (2)  Multihomed host -- The destination host (perhaps taken
-              from the preferred MX record) may be multihomed, in which
-              case the domain name resolver will return a list of
-              alternative IP addresses.  It is the responsibility of the
-              domain name resolver interface (see Section 6.1.3.4 below)
-              to have ordered this list by decreasing preference, and
-              SMTP MUST try them in the order presented.
-
-         DISCUSSION:
-              Although the capability to try multiple alternative
-              addresses is required, there may be circumstances where
-              specific installations want to limit or disable the use of
-              alternative addresses.  The question of whether a sender
-              should attempt retries using the different addresses of a
-              multihomed host has been controversial.  The main argument
-              for using the multiple addresses is that it maximizes the
-              probability of timely delivery, and indeed sometimes the
-              probability of any delivery; the counter argument is that
-              it may result in unnecessary resource use.
-
-              Note that resource use is also strongly determined by the
-
-
-
-Internet Engineering Task Force                                [Page 64]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              sending strategy discussed in Section 5.3.1.
-
-      5.3.5  Domain Name Support
-
-         SMTP implementations MUST use the mechanism defined in Section
-         6.1 for mapping between domain names and IP addresses.  This
-         means that every Internet SMTP MUST include support for the
-         Internet DNS.
-
-         In particular, a sender-SMTP MUST support the MX record scheme
-         [SMTP:3].  See also Section 7.4 of [DNS:2] for information on
-         domain name support for SMTP.
-
-      5.3.6  Mailing Lists and Aliases
-
-         An SMTP-capable host SHOULD support both the alias and the list
-         form of address expansion for multiple delivery.  When a
-         message is delivered or forwarded to each address of an
-         expanded list form, the return address in the envelope
-         ("MAIL FROM:") MUST be changed to be the address of a person
-         who administers the list, but the message header MUST be left
-         unchanged; in particular, the "From" field of the message is
-         unaffected.
-
-         DISCUSSION:
-              An important mail facility is a mechanism for multi-
-              destination delivery of a single message, by transforming
-              or "expanding" a pseudo-mailbox address into a list of
-              destination mailbox addresses.  When a message is sent to
-              such a pseudo-mailbox (sometimes called an "exploder"),
-              copies are forwarded or redistributed to each mailbox in
-              the expanded list.  We classify such a pseudo-mailbox as
-              an "alias" or a "list", depending upon the expansion
-              rules:
-
-              (a)  Alias
-
-                   To expand an alias, the recipient mailer simply
-                   replaces the pseudo-mailbox address in the envelope
-                   with each of the expanded addresses in turn; the rest
-                   of the envelope and the message body are left
-                   unchanged.  The message is then delivered or
-                   forwarded to each expanded address.
-
-              (b)  List
-
-                   A mailing list may be said to operate by
-                   "redistribution" rather than by "forwarding".  To
-
-
-
-Internet Engineering Task Force                                [Page 65]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-                   expand a list, the recipient mailer replaces the
-                   pseudo-mailbox address in the envelope with each of
-                   the expanded addresses in turn. The return address in
-                   the envelope is changed so that all error messages
-                   generated by the final deliveries will be returned to
-                   a list administrator, not to the message originator,
-                   who generally has no control over the contents of the
-                   list and will typically find error messages annoying.
-
-
-      5.3.7  Mail Gatewaying
-
-         Gatewaying mail between different mail environments, i.e.,
-         different mail formats and protocols, is complex and does not
-         easily yield to standardization.  See for example [SMTP:5a],
-         [SMTP:5b].  However, some general requirements may be given for
-         a gateway between the Internet and another mail environment.
-
-         (A)  Header fields MAY be rewritten when necessary as messages
-              are gatewayed across mail environment boundaries.
-
-              DISCUSSION:
-                   This may involve interpreting the local-part of the
-                   destination address, as suggested in Section 5.2.16.
-
-                   The other mail systems gatewayed to the Internet
-                   generally use a subset of RFC-822 headers, but some
-                   of them do not have an equivalent to the SMTP
-                   envelope.  Therefore, when a message leaves the
-                   Internet environment, it may be necessary to fold the
-                   SMTP envelope information into the message header.  A
-                   possible solution would be to create new header
-                   fields to carry the envelope information (e.g., "X-
-                   SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would
-                   require changes in mail programs in the foreign
-                   environment.
-
-         (B)  When forwarding a message into or out of the Internet
-              environment, a gateway MUST prepend a Received: line, but
-              it MUST NOT alter in any way a Received: line that is
-              already in the header.
-
-              DISCUSSION:
-                   This requirement is a subset of the general
-                   "Received:" line requirement of Section 5.2.8; it is
-                   restated here for emphasis.
-
-                   Received: fields of messages originating from other
-
-
-
-Internet Engineering Task Force                                [Page 66]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-                   environments may not conform exactly to RFC822.
-                   However, the most important use of Received: lines is
-                   for debugging mail faults, and this debugging can be
-                   severely hampered by well-meaning gateways that try
-                   to "fix" a Received: line.
-
-                   The gateway is strongly encouraged to indicate the
-                   environment and protocol in the "via" clauses of
-                   Received field(s) that it supplies.
-
-         (C)  From the Internet side, the gateway SHOULD accept all
-              valid address formats in SMTP commands and in RFC-822
-              headers, and all valid RFC-822 messages.  Although a
-              gateway must accept an RFC-822 explicit source route
-              ("@...:" format) in either the RFC-822 header or in the
-              envelope, it MAY or may not act on the source route; see
-              Sections 5.2.6 and 5.2.19.
-
-              DISCUSSION:
-                   It is often tempting to restrict the range of
-                   addresses accepted at the mail gateway to simplify
-                   the translation into addresses for the remote
-                   environment.  This practice is based on the
-                   assumption that mail users have control over the
-                   addresses their mailers send to the mail gateway.  In
-                   practice, however, users have little control over the
-                   addresses that are finally sent; their mailers are
-                   free to change addresses into any legal RFC-822
-                   format.
-
-         (D)  The gateway MUST ensure that all header fields of a
-              message that it forwards into the Internet meet the
-              requirements for Internet mail.  In particular, all
-              addresses in "From:", "To:", "Cc:", etc., fields must be
-              transformed (if necessary) to satisfy RFC-822 syntax, and
-              they must be effective and useful for sending replies.
-
-
-         (E)  The translation algorithm used to convert mail from the
-              Internet protocols to another environment's protocol
-              SHOULD try to ensure that error messages from the foreign
-              mail environment are delivered to the return path from the
-              SMTP envelope, not to the sender listed in the "From:"
-              field of the RFC-822 message.
-
-              DISCUSSION:
-                   Internet mail lists usually place the address of the
-                   mail list maintainer in the envelope but leave the
-
-
-
-Internet Engineering Task Force                                [Page 67]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-                   original message header intact (with the "From:"
-                   field containing the original sender).  This yields
-                   the behavior the average recipient expects: a reply
-                   to the header gets sent to the original sender, not
-                   to a mail list maintainer; however, errors get sent
-                   to the maintainer (who can fix the problem) and not
-                   the sender (who probably cannot).
-
-         (F)  Similarly, when forwarding a message from another
-              environment into the Internet, the gateway SHOULD set the
-              envelope return path in accordance with an error message
-              return address, if any, supplied by the foreign
-              environment.
-
-
-      5.3.8  Maximum Message Size
-
-         Mailer software MUST be able to send and receive messages of at
-         least 64K bytes in length (including header), and a much larger
-         maximum size is highly desirable.
-
-         DISCUSSION:
-              Although SMTP does not define the maximum size of a
-              message, many systems impose implementation limits.
-
-              The current de facto minimum limit in the Internet is 64K
-              bytes.  However, electronic mail is used for a variety of
-              purposes that create much larger messages.  For example,
-              mail is often used instead of FTP for transmitting ASCII
-              files, and in particular to transmit entire documents.  As
-              a result, messages can be 1 megabyte or even larger.  We
-              note that the present document together with its lower-
-              layer companion contains 0.5 megabytes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 68]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-   5.4  SMTP REQUIREMENTS SUMMARY
-
-                                               |          | | | |S| |
-                                               |          | | | |H| |F
-                                               |          | | | |O|M|o
-                                               |          | |S| |U|U|o
-                                               |          | |H| |L|S|t
-                                               |          |M|O| |D|T|n
-                                               |          |U|U|M| | |o
-                                               |          |S|L|A|N|N|t
-                                               |          |T|D|Y|O|O|t
-FEATURE                                        |SECTION   | | | |T|T|e
------------------------------------------------|----------|-|-|-|-|-|--
-                                               |          | | | | | |
-RECEIVER-SMTP:                                 |          | | | | | |
-  Implement VRFY                               |5.2.3     |x| | | | |
-  Implement EXPN                               |5.2.3     | |x| | | |
-    EXPN, VRFY configurable                    |5.2.3     | | |x| | |
-  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
-  Verify HELO parameter                        |5.2.5     | | |x| | |
-    Refuse message with bad HELO               |5.2.5     | | | | |x|
-  Accept explicit src-route syntax in env.     |5.2.6     |x| | | | |
-  Support "postmaster"                         |5.2.7     |x| | | | |
-  Process RCPT when received (except lists)    |5.2.7     | | |x| | |
-      Long delay of RCPT responses             |5.2.7     | | | | |x|
-                                               |          | | | | | |
-  Add Received: line                           |5.2.8     |x| | | | |
-      Received: line include domain literal    |5.2.8     | |x| | | |
-  Change previous Received: line               |5.2.8     | | | | |x|
-  Pass Return-Path info (final deliv/gwy)      |5.2.8     |x| | | | |
-  Support empty reverse path                   |5.2.9     |x| | | | |
-  Send only official reply codes               |5.2.10    | |x| | | |
-  Send text from RFC-821 when appropriate      |5.2.10    | |x| | | |
-  Delete "." for transparency                  |5.2.11    |x| | | | |
-  Accept and recognize self domain literal(s)  |5.2.17    |x| | | | |
-                                               |          | | | | | |
-  Error message about error message            |5.3.1     | | | | |x|
-  Keep pending listen on SMTP port             |5.3.1.2   | |x| | | |
-  Provide limit on recv concurrency            |5.3.1.2   | | |x| | |
-  Wait at least 5 mins for next sender cmd     |5.3.2     | |x| | | |
-  Avoidable delivery failure after "250 OK"    |5.3.3     | | | | |x|
-  Send error notification msg after accept     |5.3.3     |x| | | | |
-    Send using null return path                |5.3.3     |x| | | | |
-    Send to envelope return path               |5.3.3     | |x| | | |
-    Send to null address                       |5.3.3     | | | | |x|
-    Strip off explicit src route               |5.3.3     | |x| | | |
-  Minimize acceptance delay (RFC-1047)         |5.3.3     |x| | | | |
------------------------------------------------|----------|-|-|-|-|-|--
-
-
-
-Internet Engineering Task Force                                [Page 69]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-                                               |          | | | | | |
-SENDER-SMTP:                                   |          | | | | | |
-  Canonicalized domain names in MAIL, RCPT     |5.2.2     |x| | | | |
-  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
-  Send valid principal host name in HELO       |5.2.5     |x| | | | |
-  Send explicit source route in RCPT TO:       |5.2.6     | | | |x| |
-  Use only reply code to determine action      |5.2.10    |x| | | | |
-  Use only high digit of reply code when poss. |5.2.10    | |x| | | |
-  Add "." for transparency                     |5.2.11    |x| | | | |
-                                               |          | | | | | |
-  Retry messages after soft failure            |5.3.1.1   |x| | | | |
-    Delay before retry                         |5.3.1.1   |x| | | | |
-    Configurable retry parameters              |5.3.1.1   |x| | | | |
-    Retry once per each queued dest host       |5.3.1.1   | |x| | | |
-  Multiple RCPT's for same DATA                |5.3.1.1   | |x| | | |
-  Support multiple concurrent transactions     |5.3.1.1   | | |x| | |
-    Provide limit on concurrency               |5.3.1.1   | |x| | | |
-                                               |          | | | | | |
-  Timeouts on all activities                   |5.3.1     |x| | | | |
-    Per-command timeouts                       |5.3.2     | |x| | | |
-    Timeouts easily reconfigurable             |5.3.2     | |x| | | |
-    Recommended times                          |5.3.2     | |x| | | |
-  Try alternate addr's in order                |5.3.4     |x| | | | |
-    Configurable limit on alternate tries      |5.3.4     | | |x| | |
-    Try at least two alternates                |5.3.4     | |x| | | |
-  Load-split across equal MX alternates        |5.3.4     | |x| | | |
-  Use the Domain Name System                   |5.3.5     |x| | | | |
-    Support MX records                         |5.3.5     |x| | | | |
-    Use WKS records in MX processing           |5.2.12    | | | |x| |
------------------------------------------------|----------|-|-|-|-|-|--
-                                               |          | | | | | |
-MAIL FORWARDING:                               |          | | | | | |
-  Alter existing header field(s)               |5.2.6     | | | |x| |
-  Implement relay function: 821/section 3.6    |5.2.6     | | |x| | |
-    If not, deliver to RHS domain              |5.2.6     | |x| | | |
-  Interpret 'local-part' of addr               |5.2.16    | | | | |x|
-                                               |          | | | | | |
-MAILING LISTS AND ALIASES                      |          | | | | | |
-  Support both                                 |5.3.6     | |x| | | |
-  Report mail list error to local admin.       |5.3.6     |x| | | | |
-                                               |          | | | | | |
-MAIL GATEWAYS:                                 |          | | | | | |
-  Embed foreign mail route in local-part       |5.2.16    | | |x| | |
-  Rewrite header fields when necessary         |5.3.7     | | |x| | |
-  Prepend Received: line                       |5.3.7     |x| | | | |
-  Change existing Received: line               |5.3.7     | | | | |x|
-  Accept full RFC-822 on Internet side         |5.3.7     | |x| | | |
-  Act on RFC-822 explicit source route         |5.3.7     | | |x| | |
-
-
-
-Internet Engineering Task Force                                [Page 70]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-  Send only valid RFC-822 on Internet side     |5.3.7     |x| | | | |
-  Deliver error msgs to envelope addr          |5.3.7     | |x| | | |
-  Set env return path from err return addr     |5.3.7     | |x| | | |
-                                               |          | | | | | |
-USER AGENT -- RFC-822                          |          | | | | | |
-  Allow user to enter <route> address          |5.2.6     | | | |x| |
-  Support RFC-1049 Content Type field          |5.2.13    | | |x| | |
-  Use 4-digit years                            |5.2.14    | |x| | | |
-  Generate numeric timezones                   |5.2.14    | |x| | | |
-  Accept all timezones                         |5.2.14    |x| | | | |
-  Use non-num timezones from RFC-822           |5.2.14    |x| | | | |
-  Omit phrase before route-addr                |5.2.15    | | |x| | |
-  Accept and parse dot.dec. domain literals    |5.2.17    |x| | | | |
-  Accept all RFC-822 address formats           |5.2.18    |x| | | | |
-  Generate invalid RFC-822 address format      |5.2.18    | | | | |x|
-  Fully-qualified domain names in header       |5.2.18    |x| | | | |
-  Create explicit src route in header          |5.2.19    | | | |x| |
-  Accept explicit src route in header          |5.2.19    |x| | | | |
-                                               |          | | | | | |
-Send/recv at least 64KB messages               |5.3.8     |x| | | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 71]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-6. SUPPORT SERVICES
-
-   6.1 DOMAIN NAME TRANSLATION
-
-      6.1.1 INTRODUCTION
-
-         Every host MUST implement a resolver for the Domain Name System
-         (DNS), and it MUST implement a mechanism using this DNS
-         resolver to convert host names to IP addresses and vice-versa
-         [DNS:1, DNS:2].
-
-         In addition to the DNS, a host MAY also implement a host name
-         translation mechanism that searches a local Internet host
-         table.  See Section 6.1.3.8 for more information on this
-         option.
-
-         DISCUSSION:
-              Internet host name translation was originally performed by
-              searching local copies of a table of all hosts.  This
-              table became too large to update and distribute in a
-              timely manner and too large to fit into many hosts, so the
-              DNS was invented.
-
-              The DNS creates a distributed database used primarily for
-              the translation between host names and host addresses.
-              Implementation of DNS software is required.  The DNS
-              consists of two logically distinct parts: name servers and
-              resolvers (although implementations often combine these
-              two logical parts in the interest of efficiency) [DNS:2].
-
-              Domain name servers store authoritative data about certain
-              sections of the database and answer queries about the
-              data.  Domain resolvers query domain name servers for data
-              on behalf of user processes.  Every host therefore needs a
-              DNS resolver; some host machines will also need to run
-              domain name servers.  Since no name server has complete
-              information, in general it is necessary to obtain
-              information from more than one name server to resolve a
-              query.
-
-      6.1.2  PROTOCOL WALK-THROUGH
-
-         An implementor must study references [DNS:1] and [DNS:2]
-         carefully.  They provide a thorough description of the theory,
-         protocol, and implementation of the domain name system, and
-         reflect several years of experience.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 72]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-         6.1.2.1  Resource Records with Zero TTL: RFC-1035 Section 3.2.1
-
-            All DNS name servers and resolvers MUST properly handle RRs
-            with a zero TTL: return the RR to the client but do not
-            cache it.
-
-            DISCUSSION:
-                 Zero TTL values are interpreted to mean that the RR can
-                 only be used for the transaction in progress, and
-                 should not be cached; they are useful for extremely
-                 volatile data.
-
-         6.1.2.2  QCLASS Values: RFC-1035 Section 3.2.5
-
-            A query with "QCLASS=*" SHOULD NOT be used unless the
-            requestor is seeking data from more than one class.  In
-            particular, if the requestor is only interested in Internet
-            data types, QCLASS=IN MUST be used.
-
-         6.1.2.3  Unused Fields: RFC-1035 Section 4.1.1
-
-            Unused fields in a query or response message MUST be zero.
-
-         6.1.2.4  Compression: RFC-1035 Section 4.1.4
-
-            Name servers MUST use compression in responses.
-
-            DISCUSSION:
-                 Compression is essential to avoid overflowing UDP
-                 datagrams; see Section 6.1.3.2.
-
-         6.1.2.5  Misusing Configuration Info: RFC-1035 Section 6.1.2
-
-            Recursive name servers and full-service resolvers generally
-            have some configuration information containing hints about
-            the location of root or local name servers.  An
-            implementation MUST NOT include any of these hints in a
-            response.
-
-            DISCUSSION:
-                 Many implementors have found it convenient to store
-                 these hints as if they were cached data, but some
-                 neglected to ensure that this "cached data" was not
-                 included in responses.  This has caused serious
-                 problems in the Internet when the hints were obsolete
-                 or incorrect.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 73]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-      6.1.3  SPECIFIC ISSUES
-
-         6.1.3.1  Resolver Implementation
-
-            A name resolver SHOULD be able to multiplex concurrent
-            requests if the host supports concurrent processes.
-
-            In implementing a DNS resolver, one of two different models
-            MAY optionally be chosen: a full-service resolver, or a stub
-            resolver.
-
-
-            (A)  Full-Service Resolver
-
-                 A full-service resolver is a complete implementation of
-                 the resolver service, and is capable of dealing with
-                 communication failures, failure of individual name
-                 servers, location of the proper name server for a given
-                 name, etc.  It must satisfy the following requirements:
-
-                 o    The resolver MUST implement a local caching
-                      function to avoid repeated remote access for
-                      identical requests, and MUST time out information
-                      in the cache.
-
-                 o    The resolver SHOULD be configurable with start-up
-                      information pointing to multiple root name servers
-                      and multiple name servers for the local domain.
-                      This insures that the resolver will be able to
-                      access the whole name space in normal cases, and
-                      will be able to access local domain information
-                      should the local network become disconnected from
-                      the rest of the Internet.
-
-
-            (B)  Stub Resolver
-
-                 A "stub resolver" relies on the services of a recursive
-                 name server on the connected network or a "nearby"
-                 network.  This scheme allows the host to pass on the
-                 burden of the resolver function to a name server on
-                 another host.  This model is often essential for less
-                 capable hosts, such as PCs, and is also recommended
-                 when the host is one of several workstations on a local
-                 network, because it allows all of the workstations to
-                 share the cache of the recursive name server and hence
-                 reduce the number of domain requests exported by the
-                 local network.
-
-
-
-Internet Engineering Task Force                                [Page 74]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 At a minimum, the stub resolver MUST be capable of
-                 directing its requests to redundant recursive name
-                 servers.  Note that recursive name servers are allowed
-                 to restrict the sources of requests that they will
-                 honor, so the host administrator must verify that the
-                 service will be provided.  Stub resolvers MAY implement
-                 caching if they choose, but if so, MUST timeout cached
-                 information.
-
-
-         6.1.3.2  Transport Protocols
-
-            DNS resolvers and recursive servers MUST support UDP, and
-            SHOULD support TCP, for sending (non-zone-transfer) queries.
-            Specifically, a DNS resolver or server that is sending a
-            non-zone-transfer query MUST send a UDP query first.  If the
-            Answer section of the response is truncated and if the
-            requester supports TCP, it SHOULD try the query again using
-            TCP.
-
-            DNS servers MUST be able to service UDP queries and SHOULD
-            be able to service TCP queries.  A name server MAY limit the
-            resources it devotes to TCP queries, but it SHOULD NOT
-            refuse to service a TCP query just because it would have
-            succeeded with UDP.
-
-            Truncated responses MUST NOT be saved (cached) and later
-            used in such a way that the fact that they are truncated is
-            lost.
-
-            DISCUSSION:
-                 UDP is preferred over TCP for queries because UDP
-                 queries have much lower overhead, both in packet count
-                 and in connection state.  The use of UDP is essential
-                 for heavily-loaded servers, especially the root
-                 servers.  UDP also offers additional robustness, since
-                 a resolver can attempt several UDP queries to different
-                 servers for the cost of a single TCP query.
-
-                 It is possible for a DNS response to be truncated,
-                 although this is a very rare occurrence in the present
-                 Internet DNS.  Practically speaking, truncation cannot
-                 be predicted, since it is data-dependent.  The
-                 dependencies include the number of RRs in the answer,
-                 the size of each RR, and the savings in space realized
-                 by the name compression algorithm.  As a rule of thumb,
-                 truncation in NS and MX lists should not occur for
-                 answers containing 15 or fewer RRs.
-
-
-
-Internet Engineering Task Force                                [Page 75]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 Whether it is possible to use a truncated answer
-                 depends on the application.  A mailer must not use a
-                 truncated MX response, since this could lead to mail
-                 loops.
-
-                 Responsible practices can make UDP suffice in the vast
-                 majority of cases.  Name servers must use compression
-                 in responses.  Resolvers must differentiate truncation
-                 of the Additional section of a response (which only
-                 loses extra information) from truncation of the Answer
-                 section (which for MX records renders the response
-                 unusable by mailers).  Database administrators should
-                 list only a reasonable number of primary names in lists
-                 of name servers, MX alternatives, etc.
-
-                 However, it is also clear that some new DNS record
-                 types defined in the future will contain information
-                 exceeding the 512 byte limit that applies to UDP, and
-                 hence will require TCP.  Thus, resolvers and name
-                 servers should implement TCP services as a backup to
-                 UDP today, with the knowledge that they will require
-                 the TCP service in the future.
-
-            By private agreement, name servers and resolvers MAY arrange
-            to use TCP for all traffic between themselves.  TCP MUST be
-            used for zone transfers.
-
-            A DNS server MUST have sufficient internal concurrency that
-            it can continue to process UDP queries while awaiting a
-            response or performing a zone transfer on an open TCP
-            connection [DNS:2].
-
-            A server MAY support a UDP query that is delivered using an
-            IP broadcast or multicast address.  However, the Recursion
-            Desired bit MUST NOT be set in a query that is multicast,
-            and MUST be ignored by name servers receiving queries via a
-            broadcast or multicast address.  A host that sends broadcast
-            or multicast DNS queries SHOULD send them only as occasional
-            probes, caching the IP address(es) it obtains from the
-            response(s) so it can normally send unicast queries.
-
-            DISCUSSION:
-                 Broadcast or (especially) IP multicast can provide a
-                 way to locate nearby name servers without knowing their
-                 IP addresses in advance.  However, general broadcasting
-                 of recursive queries can result in excessive and
-                 unnecessary load on both network and servers.
-
-
-
-
-Internet Engineering Task Force                                [Page 76]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-         6.1.3.3  Efficient Resource Usage
-
-            The following requirements on servers and resolvers are very
-            important to the health of the Internet as a whole,
-            particularly when DNS services are invoked repeatedly by
-            higher level automatic servers, such as mailers.
-
-            (1)  The resolver MUST implement retransmission controls to
-                 insure that it does not waste communication bandwidth,
-                 and MUST impose finite bounds on the resources consumed
-                 to respond to a single request.  See [DNS:2] pages 43-
-                 44 for specific recommendations.
-
-            (2)  After a query has been retransmitted several times
-                 without a response, an implementation MUST give up and
-                 return a soft error to the application.
-
-            (3)  All DNS name servers and resolvers SHOULD cache
-                 temporary failures, with a timeout period of the order
-                 of minutes.
-
-                 DISCUSSION:
-                      This will prevent applications that immediately
-                      retry soft failures (in violation of Section 2.2
-                      of this document) from generating excessive DNS
-                      traffic.
-
-            (4)  All DNS name servers and resolvers SHOULD cache
-                 negative responses that indicate the specified name, or
-                 data of the specified type, does not exist, as
-                 described in [DNS:2].
-
-            (5)  When a DNS server or resolver retries a UDP query, the
-                 retry interval SHOULD be constrained by an exponential
-                 backoff algorithm, and SHOULD also have upper and lower
-                 bounds.
-
-                 IMPLEMENTATION:
-                      A measured RTT and variance (if available) should
-                      be used to calculate an initial retransmission
-                      interval.  If this information is not available, a
-                      default of no less than 5 seconds should be used.
-                      Implementations may limit the retransmission
-                      interval, but this limit must exceed twice the
-                      Internet maximum segment lifetime plus service
-                      delay at the name server.
-
-            (6)  When a resolver or server receives a Source Quench for
-
-
-
-Internet Engineering Task Force                                [Page 77]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 a query it has issued, it SHOULD take steps to reduce
-                 the rate of querying that server in the near future.  A
-                 server MAY ignore a Source Quench that it receives as
-                 the result of sending a response datagram.
-
-                 IMPLEMENTATION:
-                      One recommended action to reduce the rate is to
-                      send the next query attempt to an alternate
-                      server, if there is one available.  Another is to
-                      backoff the retry interval for the same server.
-
-
-         6.1.3.4  Multihomed Hosts
-
-            When the host name-to-address function encounters a host
-            with multiple addresses, it SHOULD rank or sort the
-            addresses using knowledge of the immediately connected
-            network number(s) and any other applicable performance or
-            history information.
-
-            DISCUSSION:
-                 The different addresses of a multihomed host generally
-                 imply different Internet paths, and some paths may be
-                 preferable to others in performance, reliability, or
-                 administrative restrictions.  There is no general way
-                 for the domain system to determine the best path.  A
-                 recommended approach is to base this decision on local
-                 configuration information set by the system
-                 administrator.
-
-            IMPLEMENTATION:
-                 The following scheme has been used successfully:
-
-                 (a)  Incorporate into the host configuration data a
-                      Network-Preference List, that is simply a list of
-                      networks in preferred order.  This list may be
-                      empty if there is no preference.
-
-                 (b)  When a host name is mapped into a list of IP
-                      addresses, these addresses should be sorted by
-                      network number, into the same order as the
-                      corresponding networks in the Network-Preference
-                      List.  IP addresses whose networks do not appear
-                      in the Network-Preference List should be placed at
-                      the end of the list.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 78]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-         6.1.3.5  Extensibility
-
-            DNS software MUST support all well-known, class-independent
-            formats [DNS:2], and SHOULD be written to minimize the
-            trauma associated with the introduction of new well-known
-            types and local experimentation with non-standard types.
-
-            DISCUSSION:
-                 The data types and classes used by the DNS are
-                 extensible, and thus new types will be added and old
-                 types deleted or redefined.  Introduction of new data
-                 types ought to be dependent only upon the rules for
-                 compression of domain names inside DNS messages, and
-                 the translation between printable (i.e., master file)
-                 and internal formats for Resource Records (RRs).
-
-                 Compression relies on knowledge of the format of data
-                 inside a particular RR.  Hence compression must only be
-                 used for the contents of well-known, class-independent
-                 RRs, and must never be used for class-specific RRs or
-                 RR types that are not well-known.  The owner name of an
-                 RR is always eligible for compression.
-
-                 A name server may acquire, via zone transfer, RRs that
-                 the server doesn't know how to convert to printable
-                 format.  A resolver can receive similar information as
-                 the result of queries.  For proper operation, this data
-                 must be preserved, and hence the implication is that
-                 DNS software cannot use textual formats for internal
-                 storage.
-
-                 The DNS defines domain name syntax very generally -- a
-                 string of labels each containing up to 63 8-bit octets,
-                 separated by dots, and with a maximum total of 255
-                 octets.  Particular applications of the DNS are
-                 permitted to further constrain the syntax of the domain
-                 names they use, although the DNS deployment has led to
-                 some applications allowing more general names.  In
-                 particular, Section 2.1 of this document liberalizes
-                 slightly the syntax of a legal Internet host name that
-                 was defined in RFC-952 [DNS:4].
-
-         6.1.3.6  Status of RR Types
-
-            Name servers MUST be able to load all RR types except MD and
-            MF from configuration files.  The MD and MF types are
-            obsolete and MUST NOT be implemented; in particular, name
-            servers MUST NOT load these types from configuration files.
-
-
-
-Internet Engineering Task Force                                [Page 79]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-            DISCUSSION:
-                 The RR types MB, MG, MR, NULL, MINFO and RP are
-                 considered experimental, and applications that use the
-                 DNS cannot expect these RR types to be supported by
-                 most domains.  Furthermore these types are subject to
-                 redefinition.
-
-                 The TXT and WKS RR types have not been widely used by
-                 Internet sites; as a result, an application cannot rely
-                 on the the existence of a TXT or WKS RR in most
-                 domains.
-
-         6.1.3.7  Robustness
-
-            DNS software may need to operate in environments where the
-            root servers or other servers are unavailable due to network
-            connectivity or other problems.  In this situation, DNS name
-            servers and resolvers MUST continue to provide service for
-            the reachable part of the name space, while giving temporary
-            failures for the rest.
-
-            DISCUSSION:
-                 Although the DNS is meant to be used primarily in the
-                 connected Internet, it should be possible to use the
-                 system in networks which are unconnected to the
-                 Internet.  Hence implementations must not depend on
-                 access to root servers before providing service for
-                 local names.
-
-         6.1.3.8  Local Host Table
-
-            DISCUSSION:
-                 A host may use a local host table as a backup or
-                 supplement to the DNS.  This raises the question of
-                 which takes precedence, the DNS or the host table; the
-                 most flexible approach would make this a configuration
-                 option.
-
-                 Typically, the contents of such a supplementary host
-                 table will be determined locally by the site.  However,
-                 a publically-available table of Internet hosts is
-                 maintained by the DDN Network Information Center (DDN
-                 NIC), with a format documented in [DNS:4].  This table
-                 can be retrieved from the DDN NIC using a protocol
-                 described in [DNS:5].  It must be noted that this table
-                 contains only a small fraction of all Internet hosts.
-                 Hosts using this protocol to retrieve the DDN NIC host
-                 table should use the VERSION command to check if the
-
-
-
-Internet Engineering Task Force                                [Page 80]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 table has changed before requesting the entire table
-                 with the ALL command.  The VERSION identifier should be
-                 treated as an arbitrary string and tested only for
-                 equality; no numerical sequence may be assumed.
-
-                 The DDN NIC host table includes administrative
-                 information that is not needed for host operation and
-                 is therefore not currently included in the DNS
-                 database; examples include network and gateway entries.
-                 However, much of this additional information will be
-                 added to the DNS in the future.  Conversely, the DNS
-                 provides essential services (in particular, MX records)
-                 that are not available from the DDN NIC host table.
-
-      6.1.4  DNS USER INTERFACE
-
-         6.1.4.1  DNS Administration
-
-            This document is concerned with design and implementation
-            issues in host software, not with administrative or
-            operational issues.  However, administrative issues are of
-            particular importance in the DNS, since errors in particular
-            segments of this large distributed database can cause poor
-            or erroneous performance for many sites.  These issues are
-            discussed in [DNS:6] and [DNS:7].
-
-         6.1.4.2  DNS User Interface
-
-            Hosts MUST provide an interface to the DNS for all
-            application programs running on the host.  This interface
-            will typically direct requests to a system process to
-            perform the resolver function [DNS:1, 6.1:2].
-
-            At a minimum, the basic interface MUST support a request for
-            all information of a specific type and class associated with
-            a specific name, and it MUST return either all of the
-            requested information, a hard error code, or a soft error
-            indication.  When there is no error, the basic interface
-            returns the complete response information without
-            modification, deletion, or ordering, so that the basic
-            interface will not need to be changed to accommodate new
-            data types.
-
-            DISCUSSION:
-                 The soft error indication is an essential part of the
-                 interface, since it may not always be possible to
-                 access particular information from the DNS; see Section
-                 6.1.3.3.
-
-
-
-Internet Engineering Task Force                                [Page 81]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-            A host MAY provide other DNS interfaces tailored to
-            particular functions, transforming the raw domain data into
-            formats more suited to these functions.  In particular, a
-            host MUST provide a DNS interface to facilitate translation
-            between host addresses and host names.
-
-         6.1.4.3 Interface Abbreviation Facilities
-
-            User interfaces MAY provide a method for users to enter
-            abbreviations for commonly-used names.  Although the
-            definition of such methods is outside of the scope of the
-            DNS specification, certain rules are necessary to insure
-            that these methods allow access to the entire DNS name space
-            and to prevent excessive use of Internet resources.
-
-            If an abbreviation method is provided, then:
-
-            (a)  There MUST be some convention for denoting that a name
-                 is already complete, so that the abbreviation method(s)
-                 are suppressed.  A trailing dot is the usual method.
-
-            (b)  Abbreviation expansion MUST be done exactly once, and
-                 MUST be done in the context in which the name was
-                 entered.
-
-
-            DISCUSSION:
-                 For example, if an abbreviation is used in a mail
-                 program for a destination, the abbreviation should be
-                 expanded into a full domain name and stored in the
-                 queued message with an indication that it is already
-                 complete.  Otherwise, the abbreviation might be
-                 expanded with a mail system search list, not the
-                 user's, or a name could grow due to repeated
-                 canonicalizations attempts interacting with wildcards.
-
-            The two most common abbreviation methods are:
-
-            (1)  Interface-level aliases
-
-                 Interface-level aliases are conceptually implemented as
-                 a list of alias/domain name pairs. The list can be
-                 per-user or per-host, and separate lists can be
-                 associated with different functions, e.g. one list for
-                 host name-to-address translation, and a different list
-                 for mail domains.  When the user enters a name, the
-                 interface attempts to match the name to the alias
-                 component of a list entry, and if a matching entry can
-
-
-
-Internet Engineering Task Force                                [Page 82]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 be found, the name is replaced by the domain name found
-                 in the pair.
-
-                 Note that interface-level aliases and CNAMEs are
-                 completely separate mechanisms; interface-level aliases
-                 are a local matter while CNAMEs are an Internet-wide
-                 aliasing mechanism which is a required part of any DNS
-                 implementation.
-
-            (2)  Search Lists
-
-                 A search list is conceptually implemented as an ordered
-                 list of domain names.  When the user enters a name, the
-                 domain names in the search list are used as suffixes to
-                 the user-supplied name, one by one, until a domain name
-                 with the desired associated data is found, or the
-                 search list is exhausted.  Search lists often contain
-                 the name of the local host's parent domain or other
-                 ancestor domains.  Search lists are often per-user or
-                 per-process.
-
-                 It SHOULD be possible for an administrator to disable a
-                 DNS search-list facility.  Administrative denial may be
-                 warranted in some cases, to prevent abuse of the DNS.
-
-                 There is danger that a search-list mechanism will
-                 generate excessive queries to the root servers while
-                 testing whether user input is a complete domain name,
-                 lacking a final period to mark it as complete.  A
-                 search-list mechanism MUST have one of, and SHOULD have
-                 both of, the following two provisions to prevent this:
-
-                 (a)  The local resolver/name server can implement
-                      caching  of negative responses (see Section
-                      6.1.3.3).
-
-                 (b)  The search list expander can require two or more
-                      interior dots in a generated domain name before it
-                      tries using the name in a query to non-local
-                      domain servers, such as the root.
-
-                 DISCUSSION:
-                      The intent of this requirement is to avoid
-                      excessive delay for the user as the search list is
-                      tested, and more importantly to prevent excessive
-                      traffic to the root and other high-level servers.
-                      For example, if the user supplied a name "X" and
-                      the search list contained the root as a component,
-
-
-
-Internet Engineering Task Force                                [Page 83]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                      a query would have to consult a root server before
-                      the next search list alternative could be tried.
-                      The resulting load seen by the root servers and
-                      gateways near the root would be multiplied by the
-                      number of hosts in the Internet.
-
-                      The negative caching alternative limits the effect
-                      to the first time a name is used.  The interior
-                      dot rule is simpler to implement but can prevent
-                      easy use of some top-level names.
-
-
-      6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY
-
-                                               |           | | | |S| |
-                                               |           | | | |H| |F
-                                               |           | | | |O|M|o
-                                               |           | |S| |U|U|o
-                                               |           | |H| |L|S|t
-                                               |           |M|O| |D|T|n
-                                               |           |U|U|M| | |o
-                                               |           |S|L|A|N|N|t
-                                               |           |T|D|Y|O|O|t
-FEATURE                                        |SECTION    | | | |T|T|e
------------------------------------------------|-----------|-|-|-|-|-|--
-GENERAL ISSUES                                 |           | | | | | |
-                                               |           | | | | | |
-Implement DNS name-to-address conversion       |6.1.1      |x| | | | |
-Implement DNS address-to-name conversion       |6.1.1      |x| | | | |
-Support conversions using host table           |6.1.1      | | |x| | |
-Properly handle RR with zero TTL               |6.1.2.1    |x| | | | |
-Use QCLASS=* unnecessarily                     |6.1.2.2    | |x| | | |
-  Use QCLASS=IN for Internet class             |6.1.2.2    |x| | | | |
-Unused fields zero                             |6.1.2.3    |x| | | | |
-Use compression in responses                   |6.1.2.4    |x| | | | |
-                                               |           | | | | | |
-Include config info in responses               |6.1.2.5    | | | | |x|
-Support all well-known, class-indep. types     |6.1.3.5    |x| | | | |
-Easily expand type list                        |6.1.3.5    | |x| | | |
-Load all RR types (except MD and MF)           |6.1.3.6    |x| | | | |
-Load MD or MF type                             |6.1.3.6    | | | | |x|
-Operate when root servers, etc. unavailable    |6.1.3.7    |x| | | | |
------------------------------------------------|-----------|-|-|-|-|-|--
-RESOLVER ISSUES:                               |           | | | | | |
-                                               |           | | | | | |
-Resolver support multiple concurrent requests  |6.1.3.1    | |x| | | |
-Full-service resolver:                         |6.1.3.1    | | |x| | |
-  Local caching                                |6.1.3.1    |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 84]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-  Information in local cache times out         |6.1.3.1    |x| | | | |
-  Configurable with starting info              |6.1.3.1    | |x| | | |
-Stub resolver:                                 |6.1.3.1    | | |x| | |
-  Use redundant recursive name servers         |6.1.3.1    |x| | | | |
-  Local caching                                |6.1.3.1    | | |x| | |
-  Information in local cache times out         |6.1.3.1    |x| | | | |
-Support for remote multi-homed hosts:          |           | | | | | |
-  Sort multiple addresses by preference list   |6.1.3.4    | |x| | | |
-                                               |           | | | | | |
------------------------------------------------|-----------|-|-|-|-|-|--
-TRANSPORT PROTOCOLS:                           |           | | | | | |
-                                               |           | | | | | |
-Support UDP queries                            |6.1.3.2    |x| | | | |
-Support TCP queries                            |6.1.3.2    | |x| | | |
-  Send query using UDP first                   |6.1.3.2    |x| | | | |1
-  Try TCP if UDP answers are truncated         |6.1.3.2    | |x| | | |
-Name server limit TCP query resources          |6.1.3.2    | | |x| | |
-  Punish unnecessary TCP query                 |6.1.3.2    | | | |x| |
-Use truncated data as if it were not           |6.1.3.2    | | | | |x|
-Private agreement to use only TCP              |6.1.3.2    | | |x| | |
-Use TCP for zone transfers                     |6.1.3.2    |x| | | | |
-TCP usage not block UDP queries                |6.1.3.2    |x| | | | |
-Support broadcast or multicast queries         |6.1.3.2    | | |x| | |
-  RD bit set in query                          |6.1.3.2    | | | | |x|
-  RD bit ignored by server is b'cast/m'cast    |6.1.3.2    |x| | | | |
-  Send only as occasional probe for addr's     |6.1.3.2    | |x| | | |
------------------------------------------------|-----------|-|-|-|-|-|--
-RESOURCE USAGE:                                |           | | | | | |
-                                               |           | | | | | |
-Transmission controls, per [DNS:2]             |6.1.3.3    |x| | | | |
-  Finite bounds per request                    |6.1.3.3    |x| | | | |
-Failure after retries => soft error            |6.1.3.3    |x| | | | |
-Cache temporary failures                       |6.1.3.3    | |x| | | |
-Cache negative responses                       |6.1.3.3    | |x| | | |
-Retries use exponential backoff                |6.1.3.3    | |x| | | |
-  Upper, lower bounds                          |6.1.3.3    | |x| | | |
-Client handle Source Quench                    |6.1.3.3    | |x| | | |
-Server ignore Source Quench                    |6.1.3.3    | | |x| | |
------------------------------------------------|-----------|-|-|-|-|-|--
-USER INTERFACE:                                |           | | | | | |
-                                               |           | | | | | |
-All programs have access to DNS interface      |6.1.4.2    |x| | | | |
-Able to request all info for given name        |6.1.4.2    |x| | | | |
-Returns complete info or error                 |6.1.4.2    |x| | | | |
-Special interfaces                             |6.1.4.2    | | |x| | |
-  Name<->Address translation                   |6.1.4.2    |x| | | | |
-                                               |           | | | | | |
-Abbreviation Facilities:                       |6.1.4.3    | | |x| | |
-
-
-
-Internet Engineering Task Force                                [Page 85]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-  Convention for complete names                |6.1.4.3    |x| | | | |
-  Conversion exactly once                      |6.1.4.3    |x| | | | |
-  Conversion in proper context                 |6.1.4.3    |x| | | | |
-  Search list:                                 |6.1.4.3    | | |x| | |
-    Administrator can disable                  |6.1.4.3    | |x| | | |
-    Prevention of excessive root queries       |6.1.4.3    |x| | | | |
-      Both methods                             |6.1.4.3    | |x| | | |
------------------------------------------------|-----------|-|-|-|-|-|--
------------------------------------------------|-----------|-|-|-|-|-|--
-
-1.   Unless there is private agreement between particular resolver and
-     particular server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 86]
-
-
-
-
-RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
-
-
-   6.2  HOST INITIALIZATION
-
-      6.2.1  INTRODUCTION
-
-         This section discusses the initialization of host software
-         across a connected network, or more generally across an
-         Internet path.  This is necessary for a diskless host, and may
-         optionally be used for a host with disk drives.  For a diskless
-         host, the initialization process is called "network booting"
-         and is controlled by a bootstrap program located in a boot ROM.
-
-         To initialize a diskless host across the network, there are two
-         distinct phases:
-
-         (1)  Configure the IP layer.
-
-              Diskless machines often have no permanent storage in which
-              to store network configuration information, so that
-              sufficient configuration information must be obtained
-              dynamically to support the loading phase that follows.
-              This information must include at least the IP addresses of
-              the host and of the boot server.  To support booting
-              across a gateway, the address mask and a list of default
-              gateways are also required.
-
-         (2)  Load the host system code.
-
-              During the loading phase, an appropriate file transfer
-              protocol is used to copy the system code across the
-              network from the boot server.
-
-         A host with a disk may perform the first step, dynamic
-         configuration.  This is important for microcomputers, whose
-         floppy disks allow network configuration information to be
-         mistakenly duplicated on more than one host.  Also,
-         installation of new hosts is much simpler if they automatically
-         obtain their configuration information from a central server,
-         saving administrator time and decreasing the probability of
-         mistakes.
-
-      6.2.2  REQUIREMENTS
-
-         6.2.2.1  Dynamic Configuration
-
-            A number of protocol provisions have been made for dynamic
-            configuration.
-
-            o    ICMP Information Request/Reply messages
-
-
-
-Internet Engineering Task Force                                [Page 87]
-
-
-
-
-RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
-
-
-                 This obsolete message pair was designed to allow a host
-                 to find the number of the network it is on.
-                 Unfortunately, it was useful only if the host already
-                 knew the host number part of its IP address,
-                 information that hosts requiring dynamic configuration
-                 seldom had.
-
-            o    Reverse Address Resolution Protocol (RARP) [BOOT:4]
-
-                 RARP is a link-layer protocol for a broadcast medium
-                 that allows a host to find its IP address given its
-                 link layer address.  Unfortunately, RARP does not work
-                 across IP gateways and therefore requires a RARP server
-                 on every network.  In addition, RARP does not provide
-                 any other configuration information.
-
-            o    ICMP Address Mask Request/Reply messages
-
-                 These ICMP messages allow a host to learn the address
-                 mask for a particular network interface.
-
-            o    BOOTP Protocol [BOOT:2]
-
-                 This protocol allows a host to determine the IP
-                 addresses of the local host and the boot server, the
-                 name of an appropriate boot file, and optionally the
-                 address mask and list of default gateways.  To locate a
-                 BOOTP server, the host broadcasts a BOOTP request using
-                 UDP.  Ad hoc gateway extensions have been used to
-                 transmit the BOOTP broadcast through gateways, and in
-                 the future the IP Multicasting facility will provide a
-                 standard mechanism for this purpose.
-
-
-            The suggested approach to dynamic configuration is to use
-            the BOOTP protocol with the extensions defined in "BOOTP
-            Vendor Information Extensions" RFC-1084 [BOOT:3].  RFC-1084
-            defines some important general (not vendor-specific)
-            extensions.  In particular, these extensions allow the
-            address mask to be supplied in BOOTP; we RECOMMEND that the
-            address mask be supplied in this manner.
-
-            DISCUSSION:
-                 Historically, subnetting was defined long after IP, and
-                 so a separate mechanism (ICMP Address Mask messages)
-                 was designed to supply the address mask to a host.
-                 However, the IP address mask and the corresponding IP
-                 address conceptually form a pair, and for operational
-
-
-
-Internet Engineering Task Force                                [Page 88]
-
-
-
-
-RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
-
-
-                 simplicity they ought to be defined at the same time
-                 and by the same mechanism, whether a configuration file
-                 or a dynamic mechanism like BOOTP.
-
-                 Note that BOOTP is not sufficiently general to specify
-                 the configurations of all interfaces of a multihomed
-                 host.  A multihomed host must either use BOOTP
-                 separately for each interface, or configure one
-                 interface using BOOTP to perform the loading, and
-                 perform the complete initialization from a file later.
-
-                 Application layer configuration information is expected
-                 to be obtained from files after loading of the system
-                 code.
-
-         6.2.2.2  Loading Phase
-
-            A suggested approach for the loading phase is to use TFTP
-            [BOOT:1] between the IP addresses established by BOOTP.
-
-            TFTP to a broadcast address SHOULD NOT be used, for reasons
-            explained in Section 4.2.3.4.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 89]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-   6.3  REMOTE MANAGEMENT
-
-      6.3.1  INTRODUCTION
-
-         The Internet community has recently put considerable effort
-         into the development of network management protocols.  The
-         result has been a two-pronged approach [MGT:1, MGT:6]:  the
-         Simple Network Management Protocol (SNMP) [MGT:4] and the
-         Common Management Information Protocol over TCP (CMOT) [MGT:5].
-
-         In order to be managed using SNMP or CMOT, a host will need to
-         implement an appropriate management agent.  An Internet host
-         SHOULD include an agent for either SNMP or CMOT.
-
-         Both SNMP and CMOT operate on a Management Information Base
-         (MIB) that defines a collection of management values.  By
-         reading and setting these values, a remote application may
-         query and change the state of the managed system.
-
-         A standard MIB [MGT:3] has been defined for use by both
-         management protocols, using data types defined by the Structure
-         of Management Information (SMI) defined in [MGT:2].  Additional
-         MIB variables can be introduced under the "enterprises" and
-         "experimental" subtrees of the MIB naming space [MGT:2].
-
-         Every protocol module in the host SHOULD implement the relevant
-         MIB variables.  A host SHOULD implement the MIB variables as
-         defined in the most recent standard MIB, and MAY implement
-         other MIB variables when appropriate and useful.
-
-      6.3.2  PROTOCOL WALK-THROUGH
-
-         The MIB is intended to cover both hosts and gateways, although
-         there may be detailed differences in MIB application to the two
-         cases.  This section contains the appropriate interpretation of
-         the MIB for hosts.  It is likely that later versions of the MIB
-         will include more entries for host management.
-
-         A managed host must implement the following groups of MIB
-         object definitions: System, Interfaces, Address Translation,
-         IP, ICMP, TCP, and UDP.
-
-         The following specific interpretations apply to hosts:
-
-         o    ipInHdrErrors
-
-              Note that the error "time-to-live exceeded" can occur in a
-              host only when it is forwarding a source-routed datagram.
-
-
-
-Internet Engineering Task Force                                [Page 90]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-         o    ipOutNoRoutes
-
-              This object counts datagrams discarded because no route
-              can be found.  This may happen in a host if all the
-              default gateways in the host's configuration are down.
-
-         o    ipFragOKs, ipFragFails, ipFragCreates
-
-              A host that does not implement intentional fragmentation
-              (see "Fragmentation" section of [INTRO:1]) MUST return the
-              value zero for these three objects.
-
-         o    icmpOutRedirects
-
-              For a host, this object MUST always be zero, since hosts
-              do not send Redirects.
-
-         o    icmpOutAddrMaskReps
-
-              For a host, this object MUST always be zero, unless the
-              host is an authoritative source of address mask
-              information.
-
-         o    ipAddrTable
-
-              For a host, the "IP Address Table" object is effectively a
-              table of logical interfaces.
-
-         o    ipRoutingTable
-
-              For a host, the "IP Routing Table" object is effectively a
-              combination of the host's Routing Cache and the static
-              route table described in "Routing Outbound Datagrams"
-              section of [INTRO:1].
-
-              Within each ipRouteEntry, ipRouteMetric1...4 normally will
-              have no meaning for a host and SHOULD always be -1, while
-              ipRouteType will normally have the value "remote".
-
-              If destinations on the connected network do not appear in
-              the Route Cache (see "Routing Outbound Datagrams section
-              of [INTRO:1]), there will be no entries with ipRouteType
-              of "direct".
-
-
-         DISCUSSION:
-              The current MIB does not include Type-of-Service in an
-              ipRouteEntry, but a future revision is expected to make
-
-
-
-Internet Engineering Task Force                                [Page 91]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-              this addition.
-
-              We also expect the MIB to be expanded to allow the remote
-              management of applications (e.g., the ability to partially
-              reconfigure mail systems).  Network service applications
-              such as mail systems should therefore be written with the
-              "hooks" for remote management.
-
-      6.3.3  MANAGEMENT REQUIREMENTS SUMMARY
-
-                                               |           | | | |S| |
-                                               |           | | | |H| |F
-                                               |           | | | |O|M|o
-                                               |           | |S| |U|U|o
-                                               |           | |H| |L|S|t
-                                               |           |M|O| |D|T|n
-                                               |           |U|U|M| | |o
-                                               |           |S|L|A|N|N|t
-                                               |           |T|D|Y|O|O|t
-FEATURE                                        |SECTION    | | | |T|T|e
------------------------------------------------|-----------|-|-|-|-|-|--
-Support SNMP or CMOT agent                     |6.3.1      | |x| | | |
-Implement specified objects in standard MIB    |6.3.1      | |x| | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 92]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-7.  REFERENCES
-
-   This section lists the primary references with which every
-   implementer must be thoroughly familiar.  It also lists some
-   secondary references that are suggested additional reading.
-
-   INTRODUCTORY REFERENCES:
-
-
-   [INTRO:1] "Requirements for Internet Hosts -- Communication Layers,"
-        IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122,
-        October 1989.
-
-   [INTRO:2]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
-        (three volumes), SRI International, December 1985.
-
-   [INTRO:3]  "Official Internet Protocols," J. Reynolds and J. Postel,
-        RFC-1011, May 1987.
-
-        This document is republished periodically with new RFC numbers;
-        the latest version must be used.
-
-   [INTRO:4]  "Protocol Document Order Information," O. Jacobsen and J.
-        Postel, RFC-980, March 1986.
-
-   [INTRO:5]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010,
-        May 1987.
-
-        This document is republished periodically with new RFC numbers;
-        the latest version must be used.
-
-
-   TELNET REFERENCES:
-
-
-   [TELNET:1]  "Telnet Protocol Specification," J. Postel and J.
-        Reynolds, RFC-854, May 1983.
-
-   [TELNET:2]  "Telnet Option Specification," J. Postel and J. Reynolds,
-        RFC-855, May 1983.
-
-   [TELNET:3]  "Telnet Binary Transmission," J. Postel and J. Reynolds,
-        RFC-856, May 1983.
-
-   [TELNET:4]  "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857,
-        May 1983.
-
-   [TELNET:5]  "Telnet Suppress Go Ahead Option," J. Postel and J.
-
-
-
-Internet Engineering Task Force                                [Page 93]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-        Reynolds, RFC-858, May 1983.
-
-   [TELNET:6]  "Telnet Status Option," J. Postel and J. Reynolds, RFC-
-        859, May 1983.
-
-   [TELNET:7]  "Telnet Timing Mark Option," J. Postel and J. Reynolds,
-        RFC-860, May 1983.
-
-   [TELNET:8]  "Telnet Extended Options List," J. Postel and J.
-        Reynolds, RFC-861, May 1983.
-
-   [TELNET:9]  "Telnet End-Of-Record Option," J. Postel, RFC-855,
-        December 1983.
-
-   [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
-        February 1989.
-
-        This document supercedes RFC-930.
-
-   [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
-        October 1988.
-
-   [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
-        1989.
-
-   [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
-        December 1988.
-
-   [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
-        1080, November 1988.
-
-
-   SECONDARY TELNET REFERENCES:
-
-
-   [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
-        Defense, May 1984.
-
-        This document is intended to describe the same protocol as RFC-
-        854.  In case of conflict, RFC-854 takes precedence, and the
-        present document takes precedence over both.
-
-   [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
-
-   [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
-        1977.
-
-   [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
-
-
-
-Internet Engineering Task Force                                [Page 94]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-   [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
-        Implementation," A. Yasuda and T. Thompson, RFC-1043, February
-        1988.
-
-
-   FTP REFERENCES:
-
-
-   [FTP:1]  "File Transfer Protocol," J. Postel and J. Reynolds, RFC-
-        959, October 1985.
-
-   [FTP:2]  "Document File Format Standards," J. Postel, RFC-678,
-        December 1974.
-
-   [FTP:3]  "File Transfer Protocol," MIL-STD-1780, U.S. Department of
-        Defense, May 1984.
-
-        This document is based on an earlier version of the FTP
-        specification (RFC-765) and is obsolete.
-
-
-   TFTP REFERENCES:
-
-
-   [TFTP:1]  "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June
-        1981.
-
-
-   MAIL REFERENCES:
-
-
-   [SMTP:1]  "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
-        1982.
-
-   [SMTP:2]  "Standard For The Format of ARPA Internet Text Messages,"
-        D. Crocker, RFC-822, August 1982.
-
-        This document obsoleted an earlier specification, RFC-733.
-
-   [SMTP:3]  "Mail Routing and the Domain System," C. Partridge, RFC-
-        974, January 1986.
-
-        This RFC describes the use of MX records, a mandatory extension
-        to the mail delivery process.
-
-   [SMTP:4]  "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
-        February 1988.
-
-
-
-
-Internet Engineering Task Force                                [Page 95]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-   [SMTP:5a]  "Mapping between X.400 and RFC 822," S. Kille, RFC-987,
-        June 1986.
-
-   [SMTP:5b]  "Addendum to RFC-987," S. Kille, RFC-???, September 1987.
-
-        The two preceding RFC's define a proposed standard for
-        gatewaying mail between the Internet and the X.400 environments.
-
-   [SMTP:6]  "Simple Mail Transfer Protocol,"  MIL-STD-1781, U.S.
-        Department of Defense, May 1984.
-
-        This specification is intended to describe the same protocol as
-        does RFC-821.  However, MIL-STD-1781 is incomplete; in
-        particular, it does not include MX records [SMTP:3].
-
-   [SMTP:7]  "A Content-Type Field for Internet Messages," M. Sirbu,
-        RFC-1049, March 1988.
-
-
-   DOMAIN NAME SYSTEM REFERENCES:
-
-
-   [DNS:1]  "Domain Names - Concepts and Facilities," P. Mockapetris,
-        RFC-1034, November 1987.
-
-        This document and the following one obsolete RFC-882, RFC-883,
-        and RFC-973.
-
-   [DNS:2]  "Domain Names - Implementation and Specification," RFC-1035,
-        P. Mockapetris, November 1987.
-
-
-   [DNS:3]  "Mail Routing and the Domain System," C. Partridge, RFC-974,
-        January 1986.
-
-
-   [DNS:4]  "DoD Internet Host Table Specification," K. Harrenstein,
-        RFC-952, M. Stahl, E. Feinler, October 1985.
-
-        SECONDARY DNS REFERENCES:
-
-
-   [DNS:5]  "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
-        RFC-953, October 1985.
-
-   [DNS:6]  "Domain Administrators Guide," M. Stahl, RFC-1032, November
-        1987.
-
-
-
-
-Internet Engineering Task Force                                [Page 96]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-   [DNS:7]  "Domain Administrators Operations Guide," M. Lottor, RFC-
-        1033, November 1987.
-
-   [DNS:8]  "The Domain Name System Handbook," Vol. 4 of Internet
-        Protocol Handbook, NIC 50007, SRI Network Information Center,
-        August 1989.
-
-
-   SYSTEM INITIALIZATION REFERENCES:
-
-
-   [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June
-        1984.
-
-   [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-
-        951, September 1985.
-
-   [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-
-        1084, December 1988.
-
-        Note: this RFC revised and obsoleted RFC-1048.
-
-   [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T.
-        Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.
-
-
-   MANAGEMENT REFERENCES:
-
-
-   [MGT:1]  "IAB Recommendations for the Development of Internet Network
-        Management Standards," V. Cerf, RFC-1052, April 1988.
-
-   [MGT:2]  "Structure and Identification of Management Information for
-        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065,
-        August 1988.
-
-   [MGT:3]  "Management Information Base for Network Management of
-        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066,
-        August 1988.
-
-   [MGT:4]  "A Simple Network Management Protocol," J. Case, M. Fedor,
-        M. Schoffstall, and C. Davin, RFC-1098, April 1989.
-
-   [MGT:5]  "The Common Management Information Services and Protocol
-        over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.
-
-   [MGT:6]  "Report of the Second Ad Hoc Network Management Review
-        Group," V. Cerf, RFC-1109, August 1989.
-
-
-
-Internet Engineering Task Force                                [Page 97]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-Security Considerations
-
-   There are many security issues in the application and support
-   programs of host software, but a full discussion is beyond the scope
-   of this RFC.  Security-related issues are mentioned in sections
-   concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and
-   EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the
-   SMTP DATA command (Section 5.2.8).
-
-Author's Address
-
-   Robert Braden
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA 90292-6695
-
-   Phone: (213) 822 1511
-
-   EMail: Braden@ISI.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 98]
-
diff --git a/doc/rfc/rfc1183.txt b/doc/rfc/rfc1183.txt
deleted file mode 100644
index 6f080448..00000000
--- a/doc/rfc/rfc1183.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        C. Everhart
-Request for Comments: 1183                                      Transarc
-Updates: RFCs 1034, 1035                                      L. Mamakos
-                                                  University of Maryland
-                                                              R. Ullmann
-                                                          Prime Computer
-                                                  P. Mockapetris, Editor
-                                                                     ISI
-                                                            October 1990
-
-
-                         New DNS RR Definitions
-
-Status of this Memo
-
-   This memo defines five new DNS types for experimental purposes.  This
-   RFC describes an Experimental Protocol for the Internet community,
-   and requests discussion and suggestions for improvements.
-   Distribution of this memo is unlimited.
-
-Table of Contents
-
-   Introduction....................................................    1
-   1. AFS Data Base location.......................................    2
-   2. Responsible Person...........................................    3
-   2.1. Identification of the guilty party.........................    3
-   2.2. The Responsible Person RR..................................    4
-   3. X.25 and ISDN addresses, Route Binding.......................    6
-   3.1. The X25 RR.................................................    6
-   3.2. The ISDN RR................................................    7
-   3.3. The Route Through RR.......................................    8
-   REFERENCES and BIBLIOGRAPHY.....................................    9
-   Security Considerations.........................................   10
-   Authors' Addresses..............................................   11
-
-Introduction
-
-   This RFC defines the format of new Resource Records (RRs) for the
-   Domain Name System (DNS), and reserves corresponding DNS type
-   mnemonics and numerical codes.  The definitions are in three
-   independent sections: (1) location of AFS database servers, (2)
-   location of responsible persons, and (3) representation of X.25 and
-   ISDN addresses and route binding.  All are experimental.
-
-   This RFC assumes that the reader is familiar with the DNS [3,4].  The
-   data shown is for pedagogical use and does not necessarily reflect
-   the real Internet.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 1]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-1. AFS Data Base location
-
-   This section defines an extension of the DNS to locate servers both
-   for AFS (AFS is a registered trademark of Transarc Corporation) and
-   for the Open Software Foundation's (OSF) Distributed Computing
-   Environment (DCE) authenticated naming system using HP/Apollo's NCA,
-   both to be components of the OSF DCE.  The discussion assumes that
-   the reader is familiar with AFS [5] and NCA [6].
-
-   The AFS (originally the Andrew File System) system uses the DNS to
-   map from a domain name to the name of an AFS cell database server.
-   The DCE Naming service uses the DNS for a similar function: mapping
-   from the domain name of a cell to authenticated name servers for that
-   cell.  The method uses a new RR type with mnemonic AFSDB and type
-   code of 18 (decimal).
-
-   AFSDB has the following format:
-
-   <owner> <ttl> <class> AFSDB <subtype> <hostname>
-
-   Both RDATA fields are required in all AFSDB RRs.  The <subtype> field
-   is a 16 bit integer.  The <hostname> field is a domain name of a host
-   that has a server for the cell named by the owner name of the RR.
-
-   The format of the AFSDB RR is class insensitive.  AFSDB records cause
-   type A additional section processing for <hostname>.  This, in fact,
-   is the rationale for using a new type code, rather than trying to
-   build the same functionality with TXT RRs.
-
-   Note that the format of AFSDB in a master file is identical to MX.
-   For purposes of the DNS itself, the subtype is merely an integer.
-   The present subtype semantics are discussed below, but changes are
-   possible and will be announced in subsequent RFCs.
-
-   In the case of subtype 1, the host has an AFS version 3.0 Volume
-   Location Server for the named AFS cell.  In the case of subtype 2,
-   the host has an authenticated name server holding the cell-root
-   directory node for the named DCE/NCA cell.
-
-   The use of subtypes is motivated by two considerations.  First, the
-   space of DNS RR types is limited.  Second, the services provided are
-   sufficiently distinct that it would continue to be confusing for a
-   client to attempt to connect to a cell's servers using the protocol
-   for one service, if the cell offered only the other service.
-
-   As an example of the use of this RR, suppose that the Toaster
-   Corporation has deployed AFS 3.0 but not (yet) the OSF's DCE.  Their
-   cell, named toaster.com, has three "AFS 3.0 cell database server"
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 2]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   machines: bigbird.toaster.com, ernie.toaster.com, and
-   henson.toaster.com.  These three machines would be listed in three
-   AFSDB RRs.  These might appear in a master file as:
-
-   toaster.com.   AFSDB   1 bigbird.toaster.com.
-   toaster.com.   AFSDB   1 ernie.toaster.com.
-   toaster.com.   AFSDB   1 henson.toaster.com.
-
-   As another example use of this RR, suppose that Femto College (domain
-   name femto.edu) has deployed DCE, and that their DCE cell root
-   directory is served by processes running on green.femto.edu and
-   turquoise.femto.edu.  Furthermore, their DCE file servers also run
-   AFS 3.0-compatible volume location servers, on the hosts
-   turquoise.femto.edu and orange.femto.edu.  These machines would be
-   listed in four AFSDB RRs, which might appear in a master file as:
-
-   femto.edu.   AFSDB   2 green.femto.edu.
-   femto.edu.   AFSDB   2 turquoise.femto.edu.
-   femto.edu.   AFSDB   1 turquoise.femto.edu.
-   femto.edu.   AFSDB   1 orange.femto.edu.
-
-2. Responsible Person
-
-   The purpose of this section is to provide a standard method for
-   associating responsible person identification to any name in the DNS.
-
-   The domain name system functions as a distributed database which
-   contains many different form of information.  For a particular name
-   or host, you can discover it's Internet address, mail forwarding
-   information, hardware type and operating system among others.
-
-   A key aspect of the DNS is that the tree-structured namespace can be
-   divided into pieces, called zones, for purposes of distributing
-   control and responsibility.  The responsible person for zone database
-   purposes is named in the SOA RR for that zone.  This section
-   describes an extension which allows different responsible persons to
-   be specified for different names in a zone.
-
-2.1. Identification of the guilty party
-
-   Often it is desirable to be able to identify the responsible entity
-   for a particular host.  When that host is down or malfunctioning, it
-   is difficult to contact those parties which might resolve or repair
-   the host.  Mail sent to POSTMASTER may not reach the person in a
-   timely fashion.  If the host is one of a multitude of workstations,
-   there may be no responsible person which can be contacted on that
-   host.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 3]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   The POSTMASTER mailbox on that host continues to be a good contact
-   point for mail problems, and the zone contact in the SOA record for
-   database problem, but the RP record allows us to associate a mailbox
-   to entities that don't receive mail or are not directly connected
-   (namespace-wise) to the problem (e.g., GATEWAY.ISI.EDU might want to
-   point at HOTLINE@BBN.COM, and GATEWAY doesn't get mail, nor does the
-   ISI zone administrator have a clue about fixing gateways).
-
-2.2. The Responsible Person RR
-
-   The method uses a new RR type with mnemonic RP and type code of 17
-   (decimal).
-
-   RP has the following format:
-
-   <owner> <ttl> <class> RP <mbox-dname> <txt-dname>
-
-   Both RDATA fields are required in all RP RRs.
-
-   The first field, <mbox-dname>, is a domain name that specifies the
-   mailbox for the responsible person.  Its format in master files uses
-   the DNS convention for mailbox encoding, identical to that used for
-   the RNAME mailbox field in the SOA RR.  The root domain name (just
-   ".") may be specified for <mbox-dname> to indicate that no mailbox is
-   available.
-
-   The second field, <txt-dname>, is a domain name for which TXT RR's
-   exist.  A subsequent query can be performed to retrieve the
-   associated TXT resource records at <txt-dname>.  This provides a
-   level of indirection so that the entity can be referred to from
-   multiple places in the DNS.  The root domain name (just ".") may be
-   specified for <txt-dname> to indicate that the TXT_DNAME is absent,
-   and no associated TXT RR exists.
-
-   The format of the RP RR is class insensitive.  RP records cause no
-   additional section processing.  (TXT additional section processing
-   for <txt-dname> is allowed as an option, but only if it is disabled
-   for the root, i.e., ".").
-
-   The Responsible Person RR can be associated with any node in the
-   Domain Name System hierarchy, not just at the leaves of the tree.
-
-   The TXT RR associated with the TXT_DNAME contain free format text
-   suitable for humans.  Refer to [4] for more details on the TXT RR.
-
-   Multiple RP records at a single name may be present in the database.
-   They should have identical TTLs.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 4]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   EXAMPLES
-
-   Some examples of how the RP record might be used.
-
-   sayshell.umd.edu. A     128.8.1.14
-                     MX    10 sayshell.umd.edu.
-                     HINFO NeXT UNIX
-                     WKS   128.8.1.14 tcp ftp telnet smtp
-                     RP    louie.trantor.umd.edu.  LAM1.people.umd.edu.
-
-   LAM1.people.umd.edu. TXT (
-         "Louis A. Mamakos, (301) 454-2946, don't call me at home!" )
-
-   In this example, the responsible person's mailbox for the host
-   SAYSHELL.UMD.EDU is louie@trantor.umd.edu.  The TXT RR at
-   LAM1.people.umd.edu provides additional information and advice.
-
-   TERP.UMD.EDU.    A     128.8.10.90
-                    MX    10 128.8.10.90
-                    HINFO MICROVAX-II UNIX
-                    WKS   128.8.10.90 udp domain
-                    WKS   128.8.10.90 tcp ftp telnet smtp domain
-                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
-                    RP    root.terp.umd.edu. ops.CS.UMD.EDU.
-
-   TRANTOR.UMD.EDU. A     128.8.10.14
-                    MX    10 trantor.umd.edu.
-                    HINFO MICROVAX-II UNIX
-                    WKS   128.8.10.14 udp domain
-                    WKS   128.8.10.14 tcp ftp telnet smtp domain
-                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
-                    RP    petry.netwolf.umd.edu. petry.people.UMD.EDU.
-                    RP    root.trantor.umd.edu. ops.CS.UMD.EDU.
-                    RP    gregh.sunset.umd.edu.  .
-
-   LAM1.people.umd.edu.  TXT   "Louis A. Mamakos (301) 454-2946"
-   petry.people.umd.edu. TXT   "Michael G. Petry (301) 454-2946"
-   ops.CS.UMD.EDU.       TXT   "CS Operations Staff (301) 454-2943"
-
-   This set of resource records has two hosts, TRANTOR.UMD.EDU and
-   TERP.UMD.EDU, as well as a number of TXT RRs.  Note that TERP.UMD.EDU
-   and TRANTOR.UMD.EDU both reference the same pair of TXT resource
-   records, although the mail box names (root.terp.umd.edu and
-   root.trantor.umd.edu) differ.
-
-   Here, we obviously care much more if the machine flakes out, as we've
-   specified four persons which might want to be notified of problems or
-   other events involving TRANTOR.UMD.EDU.  In this example, the last RP
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 5]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   RR for TRANTOR.UMD.EDU specifies a mailbox (gregh.sunset.umd.edu),
-   but no associated TXT RR.
-
-3. X.25 and ISDN addresses, Route Binding
-
-   This section describes an experimental representation of X.25 and
-   ISDN addresses in the DNS, as well as a route binding method,
-   analogous to the MX for mail routing, for very large scale networks.
-
-   There are several possible uses, all experimental at this time.
-   First, the RRs provide simple documentation of the correct addresses
-   to use in static configurations of IP/X.25 [11] and SMTP/X.25 [12].
-
-   The RRs could also be used automatically by an internet network-layer
-   router, typically IP.  The procedure would be to map IP address to
-   domain name, then name to canonical name if needed, then following RT
-   records, and finally attempting an IP/X.25 call to the address found.
-   Alternately, configured domain names could be resolved to identify IP
-   to X.25/ISDN bindings for a static but periodically refreshed routing
-   table.
-
-   This provides a function similar to ARP for wide area non-broadcast
-   networks that will scale well to a network with hundreds of millions
-   of hosts.
-
-   Also, a standard address binding reference will facilitate other
-   experiments in the use of X.25 and ISDN, especially in serious
-   inter-operability testing.  The majority of work in such a test is
-   establishing the n-squared entries in static tables.
-
-   Finally, the RRs are intended for use in a proposal [13] by one of
-   the authors for a possible next-generation internet.
-
-3.1. The X25 RR
-
-   The X25 RR is defined with mnemonic X25 and type code 19 (decimal).
-
-   X25 has the following format:
-
-   <owner> <ttl> <class> X25 <PSDN-address>
-
-   <PSDN-address> is required in all X25 RRs.
-
-   <PSDN-address> identifies the PSDN (Public Switched Data Network)
-   address in the X.121 [10] numbering plan associated with <owner>.
-   Its format in master files is a <character-string> syntactically
-   identical to that used in TXT and HINFO.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 6]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   The format of X25 is class insensitive.  X25 RRs cause no additional
-   section processing.
-
-   The <PSDN-address> is a string of decimal digits, beginning with the
-   4 digit DNIC (Data Network Identification Code), as specified in
-   X.121. National prefixes (such as a 0) MUST NOT be used.
-
-   For example:
-
-   Relay.Prime.COM.  X25       311061700956
-
-3.2. The ISDN RR
-
-   The ISDN RR is defined with mnemonic ISDN and type code 20 (decimal).
-
-   An ISDN (Integrated Service Digital Network) number is simply a
-   telephone number.  The intent of the members of the CCITT is to
-   upgrade all telephone and data network service to a common service.
-
-   The numbering plan (E.163/E.164) is the same as the familiar
-   international plan for POTS (an un-official acronym, meaning Plain
-   Old Telephone Service).  In E.166, CCITT says "An E.163/E.164
-   telephony subscriber may become an ISDN subscriber without a number
-   change."
-
-   ISDN has the following format:
-
-   <owner> <ttl> <class> ISDN <ISDN-address> <sa>
-
-   The <ISDN-address> field is required; <sa> is optional.
-
-   <ISDN-address> identifies the ISDN number of <owner> and DDI (Direct
-   Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and
-   PSTN (Public Switched Telephone Network) numbering plan.  E.163
-   defines the country codes, and E.164 the form of the addresses.  Its
-   format in master files is a <character-string> syntactically
-   identical to that used in TXT and HINFO.
-
-   <sa> specifies the subaddress (SA).  The format of <sa> in master
-   files is a <character-string> syntactically identical to that used in
-   TXT and HINFO.
-
-   The format of ISDN is class insensitive.  ISDN RRs cause no
-   additional section processing.
-
-   The <ISDN-address> is a string of characters, normally decimal
-   digits, beginning with the E.163 country code and ending with the DDI
-   if any.  Note that ISDN, in Q.931, permits any IA5 character in the
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 7]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   general case.
-
-   The <sa> is a string of hexadecimal digits.  For digits 0-9, the
-   concrete encoding in the Q.931 call setup information element is
-   identical to BCD.
-
-   For example:
-
-   Relay.Prime.COM.   IN   ISDN      150862028003217
-   sh.Prime.COM.      IN   ISDN      150862028003217 004
-
-   (Note: "1" is the country code for the North American Integrated
-   Numbering Area, i.e., the system of "area codes" familiar to people
-   in those countries.)
-
-   The RR data is the ASCII representation of the digits.  It is encoded
-   as one or two <character-string>s, i.e., count followed by
-   characters.
-
-   CCITT recommendation E.166 [9] defines prefix escape codes for the
-   representation of ISDN (E.163/E.164) addresses in X.121, and PSDN
-   (X.121) addresses in E.164.  It specifies that the exact codes are a
-   "national matter", i.e., different on different networks.  A host
-   connected to the ISDN may be able to use both the X25 and ISDN
-   addresses, with the local prefix added.
-
-3.3. The Route Through RR
-
-   The Route Through RR is defined with mnemonic RT and type code 21
-   (decimal).
-
-   The RT resource record provides a route-through binding for hosts
-   that do not have their own direct wide area network addresses.  It is
-   used in much the same way as the MX RR.
-
-   RT has the following format:
-
-   <owner> <ttl> <class> RT <preference> <intermediate-host>
-
-   Both RDATA fields are required in all RT RRs.
-
-   The first field, <preference>, is a 16 bit integer, representing the
-   preference of the route.  Smaller numbers indicate more preferred
-   routes.
-
-   <intermediate-host> is the domain name of a host which will serve as
-   an intermediate in reaching the host specified by <owner>.  The DNS
-   RRs associated with <intermediate-host> are expected to include at
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 8]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   least one A, X25, or ISDN record.
-
-   The format of the RT RR is class insensitive.  RT records cause type
-   X25, ISDN, and A additional section processing for <intermediate-
-   host>.
-
-   For example,
-
-   sh.prime.com.      IN   RT   2    Relay.Prime.COM.
-                      IN   RT   10   NET.Prime.COM.
-   *.prime.com.       IN   RT   90   Relay.Prime.COM.
-
-   When a host is looking up DNS records to attempt to route a datagram,
-   it first looks for RT records for the destination host, which point
-   to hosts with address records (A, X25, ISDN) compatible with the wide
-   area networks available to the host.  If it is itself in the set of
-   RT records, it discards any RTs with preferences higher or equal to
-   its own.  If there are no (remaining) RTs, it can then use address
-   records of the destination itself.
-
-   Wild-card RTs are used exactly as are wild-card MXs.  RT's do not
-   "chain"; that is, it is not valid to use the RT RRs found for a host
-   referred to by an RT.
-
-   The concrete encoding is identical to the MX RR.
-
-REFERENCES and BIBLIOGRAPHY
-
-   [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
-       Information Center, SRI International, November 1987.
-
-   [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
-       Network Information Center, SRI International, November, 1987.
-
-   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
-       1034, USC/Information Sciences Institute, November 1987.
-
-   [4] Mockapetris, P., "Domain Names - Implementation and
-       Specification", RFC 1035, USC/Information Sciences Institute,
-       November 1987.
-
-   [5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review,
-       7(3), pp. 61-69, March 1989.
-
-   [6] Zahn, et al., "Network Computing Architecture", Prentice-Hall,
-       1989.
-
-   [7] International Telegraph and Telephone Consultative Committee,
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 9]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-       "Numbering Plan for the International Telephone Service", CCITT
-       Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988,
-       Fascicle II.2 ("Blue Book").
-
-   [8] International Telegraph and Telephone Consultative Committee,
-       "Numbering Plan for the ISDN Era", CCITT Recommendations E.164.,
-       IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue
-       Book").
-
-   [9] International Telegraph and Telephone Consultative Committee.
-       "Numbering Plan Interworking in the ISDN Era", CCITT
-       Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988,
-       Fascicle II.2 ("Blue Book").
-
-  [10] International Telegraph and Telephone Consultative Committee,
-       "International Numbering Plan for the Public Data Networks",
-       CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne,
-       1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978;
-       amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne,
-       1988.
-
-  [11] Korb, J., "Standard for the Transmission of IP datagrams Over
-       Public Data Networks", RFC 877, Purdue University, September
-       1983.
-
-  [12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February
-       1989.
-
-  [13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer
-       (unpublished), July 1990.
-
-  [14] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
-       RFC 1101, USC/Information Sciences Institute, April 1989.
-
-Security Considerations
-
-   Security issues are not addressed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                       [Page 10]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-Authors' Addresses
-
-   Craig F. Everhart
-   Transarc Corporation
-   The Gulf Tower
-   707 Grant Street
-   Pittsburgh, PA  15219
-
-   Phone: +1 412 338 4467
-
-   EMail: Craig_Everhart@transarc.com
-
-
-   Louis A. Mamakos
-   Network Infrastructure Group
-   Computer Science Center
-   University of Maryland
-   College Park, MD 20742-2411
-
-   Phone: +1-301-405-7836
-
-   Email: louie@Sayshell.UMD.EDU
-
-
-   Robert Ullmann 10-30
-   Prime Computer, Inc.
-   500 Old Connecticut Path
-   Framingham, MA 01701
-
-   Phone: +1 508 620 2800 ext 1736
-
-   Email: Ariel@Relay.Prime.COM
-
-
-   Paul Mockapetris
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA 90292
-
-   Phone: 213-822-1511
-
-   EMail: pvm@isi.edu
-
-
-
-
-
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                       [Page 11]
-
\ No newline at end of file
diff --git a/doc/rfc/rfc1348.txt b/doc/rfc/rfc1348.txt
deleted file mode 100644
index d9e5dea0..00000000
--- a/doc/rfc/rfc1348.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         B. Manning
-Request for Comments: 1348                               Rice University
-Updates: RFCs 1034, 1035                                       July 1992
-
-
-                              DNS NSAP RRs
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  Discussion and suggestions for improvement are requested.
-   Please refer to the current edition of the "IAB Official Protocol
-   Standards" for the standardization state and status of this protocol.
-   Distribution of this memo is unlimited.
-
-Table of Contents
-
-   Introduction .....................................................  1
-   Background .......................................................  1
-   NSAP RR ..........................................................  2
-   NSAP-PTR RR ......................................................  2
-   REFERENCES and BIBLIOGRAPHY ......................................  3
-   Security Considerations ..........................................  4
-   Author's Address .................................................  4
-
-Introduction
-
-   This RFC defines the format of two new Resource Records (RRs) for the
-   Domain Name System (DNS), and reserves corresponding DNS type
-   mnemonic and numerical codes.  This format may be used with the any
-   proposal that has variable length addresses, but is targeted for CLNP
-   use.
-
-   This memo assumes that the reader is familiar with the DNS [3,4].
-
-Background
-
-   This section describes an experimental representation of NSAP
-   addresses in the DNS. There are several reasons to take this approch.
-   First, it provides simple documentation of the correct addresses to
-   use in static configurations of CLNP compliant hosts and routers.
-
-   NSAP support requires that a new DNS resource record entry type
-   ("NSAP") be defined, to store longer Internet (i.e., NSAP) addresses.
-   This resource record allows mapping from DNS names to NSAP addresses,
-   and will contain entries for systems which are able to run Internet
-   applications, over TCP or UDP, over CLNP.
-
-
-
-
-Manning                                                         [Page 1]
-
-RFC 1348                      DNS NSAP RRs                     July 1992
-
-
-   The backward translation (from NSAP address to DNS name) is
-   facilitated by definition of an associated resource record. This
-   resource record is known as "NSAP-PTR", and is used in a manner
-   analogous to the existing "in-addr.arpa".
-
-   These RRs are intended for use in a proposal [6] by one of the
-   members of the NOOP WG to address the next-generation internet.
-
-The NSAP RR
-
-   The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal).
-
-   An NSAP (Network Service Access Protocol) number is a unique string
-   to OSI transport service.
-
-   The numbering plan follows RFC 1237 and associated OSI definitions
-   for NSAP format.
-
-   NSAP has the following format:
-
-   <owner> <ttl> <class> NSAP <length> <NSAP-address>
-
-   All fields are required.
-
-   <length> identifies the number of octets in the <NSAP-address> as
-   defined by the various national and international authorities.
-
-   <NSAP-address> enumerates the actual octet values assigned by the
-   assigning authority.  Its format in master files is a <character-
-   string> syntactically identical to that used in TXT and HINFO.
-
-   The format of NSAP is class insensitive.  NSAP RR causes no
-   additional section processing.
-
-   For example:
-
-foo.bar.com.    IN  NSAP   21 47000580ffff000000321099991111222233334444
-host.school.de  IN  NSAP   17 39276f3100111100002222333344449876
-
-   The RR data is the ASCII representation of the digits.  It is encoded
-   as two <character-strings>, i.e., count followed by characters.
-
-The NSAP-PTR RR
-
-   The NSAP-PTR RR is defined with mnemonic NSAP-PTR and a type code 23
-   (decimal).
-
-   Its function is analogous to the PTR record used for IP addresses
-
-
-
-Manning                                                         [Page 2]
-
-RFC 1348                      DNS NSAP RRs                     July 1992
-
-
-   [4,7].
-
-   NSAP-PTR has the following format:
-
-   <NSAP-suffix> <ttl> <class> NSAP-PTR <owner>
-
-   All fields are required.
-
-   <NSAP-suffix> enumerates the actual octet values assigned by the
-   assigning authority for the LOCAL network.  Its format in master
-   files is a <character-string> syntactically identical to that used in
-   TXT and HINFO.
-
-   The format of NSAP-PTR is class insensitive.  NSAP-PTR RR causes no
-   additional section processing.
-
-   For example:
-
-   In net ff08000574.nsap-in-addr.arpa:
-
-   444433332222111199990123000000ff    NSAP-PTR   foo.bar.com.
-
-   Or in net 11110031f67293.nsap-in-addr.arpa:
-
-   67894444333322220000  NSAP-PTR        host.school.de.
-
-   The RR data is the ASCII representation of the digits.  It is encoded
-   as a <character-string>.
-
-REFERENCES and BIBLIOGRAPHY
-
-   [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
-       Information Center, SRI International, November 1987.
-
-   [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
-       Network Information Center, SRI International, November, 1987.
-
-   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
-       1034, USC/Information Sciences Institute, November 1987.
-
-   [4] Mockapetris, P., "Domain Names - Implementation and
-       Specification", RFC 1035, USC/Information Sciences Institute,
-       November 1987.
-
-   [5] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI
-       NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC,
-       July 1991.
-
-
-
-
-Manning                                                         [Page 3]
-
-RFC 1348                      DNS NSAP RRs                     July 1992
-
-
-   [6] Callon, R., "TCP and UDP with Bigger Addresses (TUBA),
-       A Simple Proposal for Internet Addressing and Routing",
-       Digital Equipment Corporation, RFC 1347, June 1992.
-
-   [7] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
-       RFC 1101, USC/Information Sciences Institute, April 1989.
-
-   [8] ISO/IEC.  Information Processing Systems -- Data Communications
-       -- Network Service Definition Addendum 2: Network Layer Address-
-       ing. International Standard 8348/Addendum 2, ISO/IEC JTC 1,
-       Switzerland, 1988.
-
-   [9] Bryant, P., "NSAPs", PB660, IPTAG/92/23, SCIENCE AND ENGINEERING
-       RESEARCH COUNCIL, RUTHERFORD APPLETON LABORATORY May 1992.
-
-Security Considerations
-
-   Security issues are not addressed in this memo.
-
-Author's Address
-
-   Bill Manning
-   Rice University - ONCS
-   PO Box 1892
-   6100 South Main
-   Houston, Texas  77251-1892
-
-   Phone: +1.713.285.5415
-   EMail: bmanning@rice.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manning                                                         [Page 4]
-
\ No newline at end of file
diff --git a/doc/rfc/rfc1535.txt b/doc/rfc/rfc1535.txt
deleted file mode 100644
index 03bddeeb..00000000
--- a/doc/rfc/rfc1535.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          E. Gavron
-Request for Comments: 1535                            ACES Research Inc.
-Category: Informational                                     October 1993
-
-
-              A Security Problem and Proposed Correction
-                   With Widely Deployed DNS Software
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard.  Distribution of this memo is
-   unlimited.
-
-Abstract
-
-   This document discusses a flaw in some of the currently distributed
-   name resolver clients.  The flaw exposes a security weakness related
-   to the search heuristic invoked by these same resolvers when users
-   provide a partial domain name, and which is easy to exploit (although
-   not by the masses).  This document points out the flaw, a case in
-   point, and a solution.
-
-Background
-
-   Current Domain Name Server clients are designed to ease the burden of
-   remembering IP dotted quad addresses.  As such they translate human-
-   readable names into addresses and other resource records.  Part of
-   the translation process includes understanding and dealing with
-   hostnames that are not fully qualified domain names (FQDNs).
-
-   An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
-   domain name is of the format {name}
-
-   A domain name may have many parts and typically these include the
-   host, domain, and type.  Example:  foobar.company.com or
-   fooschool.university.edu.
-
-Flaw
-
-   The problem with most widely distributed resolvers based on the BSD
-   BIND resolver is that they attempt to resolve a partial name by
-   processing a search list of partial domains to be added to portions
-   of the specified host name until a DNS record is found.  This
-   "feature" is disabled by default in the official BIND 4.9.2 release.
-
-   Example: A TELNET attempt by    User@Machine.Tech.ACES.COM
-                             to    UnivHost.University.EDU
-
-
-
-Gavron                                                          [Page 1]
-
-RFC 1535               DNS Software Enhancements            October 1993
-
-
-   The resolver client will realize that since "UnivHost.University.EDU"
-   does not end with a ".", it is not an absolute "rooted" FQDN.  It
-   will then try the following combinations until a resource record is
-   found:
-
-                UnivHost.University.EDU.Tech.ACES.COM.
-                UnivHost.University.EDU.ACES.COM.
-                UnivHost.University.EDU.COM.
-                UnivHost.University.EDU.
-
-Security Issue
-
-   After registering the EDU.COM domain, it was discovered that an
-   unliberal application of one wildcard CNAME record would cause *all*
-   connects from any .COM site to any .EDU site to terminate at one
-   target machine in the private edu.com sub-domain.
-
-   Further, discussion reveals that specific hostnames registered in
-   this private subdomain, or any similarly named subdomain may be used
-   to spoof a host.
-
-        Example:        harvard.edu.com.        CNAME   targethost
-
-   Thus all connects to Harvard.edu from all .com sites would end up at
-   targthost, a machine which could provide a Harvard.edu login banner.
-
-   This is clearly unacceptable.  Further, it could only be made worse
-   with domains like COM.EDU, MIL.GOV, GOV.COM, etc.
-
-Public vs. Local Name Space Administration
-
-   The specification of the Domain Name System and the software that
-   implements it provides an undifferentiated hierarchy which permits
-   delegation of administration for subordinate portions of the name
-   space.  Actual administration of the name space is divided between
-   "public" and "local" portions.  Public administration pertains to all
-   top-level domains, such as .COM and .EDU.  For some domains, it also
-   pertains to some number of sub-domain levels.  The multi-level nature
-   of the public administration is most evident for top-level domains
-   for countries.  For example in the Fully Qualified Domain Name,
-   dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels
-   of public administration.  Only the left-most portion is subject to
-   local administration.
-
-
-
-
-
-
-
-
-Gavron                                                          [Page 2]
-
-RFC 1535               DNS Software Enhancements            October 1993
-
-
-   The danger of the heuristic search common in current practise is that
-   it it is possible to "intercept" the search by matching against an
-   unintended value while walking up the search list.  While this is
-   potentially dangerous at any level, it is entirely unacceptable when
-   the error impacts users outside of a local administration.
-
-   When attempting to resolve a partial domain name, DNS resolvers use
-   the Domain Name of the searching host for deriving the search list.
-   Existing DNS resolvers do not distinguish the portion of that name
-   which is in the locally administered scope from the part that is
-   publically administered.
-
-Solution(s)
-
-   At a minimum, DNS resolvers must honor the BOUNDARY between local and
-   public administration, by limiting any search lists to locally-
-   administered portions of the Domain Name space.  This requires a
-   parameter which shows the scope of the name space controlled by the
-   local administrator.
-
-   This would permit progressive searches from the most qualified to
-   less qualified up through the locally controlled domain, but not
-   beyond.
-
-   For example, if the local user were trying to reach:
-
-        User@chief.admin.DESERTU.EDU from
-        starburst,astro.DESERTU.EDU,
-
-   it is reasonable to permit the user to enter just chief.admin, and
-   for the search to cover:
-
-        chief.admin.astro.DESERTU.EDU
-        chief.admin.DESERTU.EDU
-
-   but not
-
-        chief.admin.EDU
-
-   In this case, the value of "search" should be set to "DESERTU.EDU"
-   because that's the scope of the name space controlled by the local
-   DNS administrator.
-
-   This is more than a mere optimization hack.  The local administrator
-   has control over the assignment of names within the locally
-   administered domain, so the administrator can make sure that
-   abbreviations result in the right thing.  Outside of the local
-   control, users are necessarily at risk.
-
-
-
-Gavron                                                          [Page 3]
-
-RFC 1535               DNS Software Enhancements            October 1993
-
-
-   A more stringent mechanism is implemented in BIND 4.9.2, to respond
-   to this problem:
-
-   The DNS Name resolver clients narrows its IMPLICIT search list IF ANY
-   to only try the first and the last of the examples shown.
-
-   Any additional search alternatives must be configured into the
-   resolver EXPLICITLY.
-
-   DNS Name resolver software SHOULD NOT use implicit search lists in
-   attempts to resolve partial names into absolute FQDNs other than the
-   hosts's immediate parent domain.
-
-   Resolvers which continue to use implicit search lists MUST limit
-   their scope to locally administered sub-domains.
-
-   DNS Name resolver software SHOULD NOT come pre-configured with
-   explicit search lists that perpetuate this problem.
-
-   Further, in any event where a "." exists in a specified name it
-   should be assumed to be a fully qualified domain name (FQDN) and
-   SHOULD be tried as a rooted name first.
-
-   Example:  Given  user@a.b.c.d connecting to e.f.g.h  only two tries
-             should be attempted as a result of using an implicit
-             search list:
-
-                e.f.g.h.  and e.f.g.h.b.c.d.
-
-             Given user@a.b.c.d. connecting to host those same two
-             tries would appear as:
-
-                x.b.c.d.  and x.
-
-   Some organizations make regular use of multi-part, partially
-   qualified Domain Names.  For example, host foo.loc1.org.city.state.us
-   might be used to making references to bar.loc2, or mumble.loc3, all
-   of which refer to whatever.locN.org.city.state.us
-
-   The stringent implicit search rules for BIND 4.9.2 will now cause
-   these searches to fail.  To return the ability for them to succeed,
-   configuration of the client resolvers must be changed to include an
-   explicit search rule for org.city.state.us.  That is, it must contain
-   an explicit rule for any -- and each -- portion of the locally-
-   administered sub-domain that it wishes to have as part of the search
-   list.
-
-
-
-
-
-Gavron                                                          [Page 4]
-
-RFC 1535               DNS Software Enhancements            October 1993
-
-
-References
-
-   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
-       RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names Implementation and Specification",
-       STD 13, RFC 1035, USC/Information Sciences Institute, November
-       1987.
-
-   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
-       974, CSNET CIC BBN, January 1986.
-
-   [4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
-       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
-       USC/Information Sciences Institute, USC, October 1993.
-
-   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
-       1537, CWI, October 1993.
-
-Security Considerations
-
-   This memo indicates vulnerabilities with all too-forgiving DNS
-   clients.  It points out a correction that would eliminate the future
-   potential of the problem.
-
-Author's Address
-
-   Ehud Gavron
-   ACES Research Inc.
-   PO Box 14546
-   Tucson, AZ 85711
-
-   Phone: (602) 743-9841
-   EMail: gavron@aces.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gavron                                                          [Page 5]
-
diff --git a/doc/rfc/rfc1536.txt b/doc/rfc/rfc1536.txt
deleted file mode 100644
index 5ff2b25d..00000000
--- a/doc/rfc/rfc1536.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           A. Kumar
-Request for Comments: 1536                                     J. Postel
-Category: Informational                                        C. Neuman
-                                                                     ISI
-                                                               P. Danzig
-                                                               S. Miller
-                                                                     USC
-                                                            October 1993
-
-
-          Common DNS Implementation Errors and Suggested Fixes
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard.  Distribution of this memo is
-   unlimited.
-
-Abstract
-
-   This memo describes common errors seen in DNS implementations and
-   suggests some fixes. Where applicable, violations of recommendations
-   from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo
-   also describes, where relevant, the algorithms followed in BIND
-   (versions 4.8.3 and 4.9 which the authors referred to) to serve as an
-   example.
-
-Introduction
-
-   The last few years have seen, virtually, an explosion of DNS traffic
-   on the NSFnet backbone. Various DNS implementations and various
-   versions of these implementations interact with each other, producing
-   huge amounts of unnecessary traffic. Attempts are being made by
-   researchers all over the internet, to document the nature of these
-   interactions, the symptomatic traffic patterns and to devise remedies
-   for the sick pieces of software.
-
-   This draft is an attempt to document fixes for known DNS problems so
-   people know what problems to watch out for and how to repair broken
-   software.
-
-1. Fast Retransmissions
-
-   DNS implements the classic request-response scheme of client-server
-   interaction. UDP is, therefore, the chosen protocol for communication
-   though TCP is used for zone transfers. The onus of requerying in case
-   no response is seen in a "reasonable" period of time, lies with the
-   client. Although RFC 1034 and 1035 do not recommend any
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 1]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   retransmission policy, RFC 1035 does recommend that the resolvers
-   should cycle through a list of servers. Both name servers and stub
-   resolvers should, therefore, implement some kind of a retransmission
-   policy based on round trip time estimates of the name servers. The
-   client should back-off exponentially, probably to a maximum timeout
-   value.
-
-   However, clients might not implement either of the two. They might
-   not wait a sufficient amount of time before retransmitting or they
-   might not back-off their inter-query times sufficiently.
-
-   Thus, what the server would see will be a series of queries from the
-   same querying entity, spaced very close together. Of course, a
-   correctly implemented server discards all duplicate queries but the
-   queries contribute to wide-area traffic, nevertheless.
-
-   We classify a retransmission of a query as a pure Fast retry timeout
-   problem when a series of query packets meet the following conditions.
-
-      a. Query packets are seen within a time less than a "reasonable
-         waiting period" of each other.
-
-      b. No response to the original query was seen i.e., we see two or
-         more queries, back to back.
-
-      c. The query packets share the same query identifier.
-
-      d. The server eventually responds to the query.
-
-A GOOD IMPLEMENTATION:
-
-   BIND (we looked at versions 4.8.3 and 4.9) implements a good
-   retransmission algorithm which solves or limits all of these
-   problems.  The Berkeley stub-resolver queries servers at an interval
-   that starts at the greater of 4 seconds and 5 seconds divided by the
-   number of servers the resolver queries. The resolver cycles through
-   servers and at the end of a cycle, backs off the time out
-   exponentially.
-
-   The Berkeley full-service resolver (built in with the program
-   "named") starts with a time-out equal to the greater of 4 seconds and
-   two times the round-trip time estimate of the server.  The time-out
-   is backed off with each cycle, exponentially, to a ceiling value of
-   45 seconds.
-
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 2]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-FIXES:
-
-      a. Estimate round-trip times or set a reasonably high initial
-         time-out.
-
-      b. Back-off timeout periods exponentially.
-
-      c. Yet another fundamental though difficult fix is to send the
-         client an acknowledgement of a query, with a round-trip time
-         estimate.
-
-   Since UDP is used, no response is expected by the client until the
-   query is complete.  Thus, it is less likely to have information about
-   previous packets on which to estimate its back-off time.  Unless, you
-   maintain state across queries, so subsequent queries to the same
-   server use information from previous queries.  Unfortunately, such
-   estimates are likely to be inaccurate for chained requests since the
-   variance is likely to be high.
-
-   The fix chosen in the ARDP library used by Prospero is that the
-   server will send an initial acknowledgement to the client in those
-   cases where the server expects the query to take a long time (as
-   might be the case for chained queries).  This initial acknowledgement
-   can include an expected time to wait before retrying.
-
-   This fix is more difficult since it requires that the client software
-   also be trained to expect the acknowledgement packet. This, in an
-   internet of millions of hosts is at best a hard problem.
-
-2. Recursion Bugs
-
-   When a server receives a client request, it first looks up its zone
-   data and the cache to check if the query can be answered. If the
-   answer is unavailable in either place, the server seeks names of
-   servers that are more likely to have the information, in its cache or
-   zone data. It then does one of two things. If the client desires the
-   server to recurse and the server architecture allows recursion, the
-   server chains this request to these known servers closest to the
-   queried name. If the client doesn't seek recursion or if the server
-   cannot handle recursion, it returns the list of name servers to the
-   client assuming the client knows what to do with these records.
-
-   The client queries this new list of name servers to get either the
-   answer, or names of another set of name servers to query. This
-   process repeats until the client is satisfied. Servers might also go
-   through this chaining process if the server returns a CNAME record
-   for the queried name. Some servers reprocess this name to try and get
-   the desired record type.
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 3]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   However, in certain cases, this chain of events may not be good. For
-   example, a broken or malicious name server might list itself as one
-   of the name servers to query again. The unsuspecting client resends
-   the same query to the same server.
-
-   In another situation, more difficult to detect, a set of servers
-   might form a loop wherein A refers to B and B refers to A. This loop
-   might involve more than two servers.
-
-   Yet another error is where the client does not know how to process
-   the list of name servers returned, and requeries the same server
-   since that is one (of the few) servers it knows.
-
-   We, therefore, classify recursion bugs into three distinct
-   categories:
-
-      a. Ignored referral: Client did not know how to handle NS records
-         in the AUTHORITY section.
-
-      b. Too many referrals: Client called on a server too many times,
-         beyond a "reasonable" number, with same query. This is
-         different from a Fast retransmission problem and a Server
-         Failure detection problem in that a response is seen for every
-         query.  Also, the identifiers are always different. It implies
-         client is in a loop and should have detected that and broken
-         it.  (RFC 1035 mentions that client should not recurse beyond
-         a certain depth.)
-
-      c. Malicious Server: a server refers to itself in the authority
-         section. If a server does not have an answer now, it is very
-         unlikely it will be any better the next time you query it,
-         specially when it claims to be authoritative over a domain.
-
-      RFC 1034 warns against such situations, on page 35.
-
-      "Bound the amount of work (packets sent, parallel processes
-       started) so that a request can't get into an infinite loop or
-       start off a chain reaction of requests or queries with other
-       implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
-       SOME DATA."
-
-A GOOD IMPLEMENTATION:
-
-   BIND fixes at least one of these problems. It places an upper limit
-   on the number of recursive queries it will make, to answer a
-   question.  It chases a maximum of 20 referral links and 8 canonical
-   name translations.
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 4]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-FIXES:
-
-      a. Set an upper limit on the number of referral links and CNAME
-         links you are willing to chase.
-
-         Note that this is not guaranteed to break only recursion loops.
-         It could, in a rare case, prune off a very long search path,
-         prematurely.  We know, however, with high probability, that if
-         the number of links cross a certain metric (two times the depth
-         of the DNS tree), it is a recursion problem.
-
-      b. Watch out for self-referring servers. Avoid them whenever
-         possible.
-
-      c. Make sure you never pass off an authority NS record with your
-         own name on it!
-
-      d. Fix clients to accept iterative answers from servers not built
-         to provide recursion. Such clients should either be happy with
-         the non-authoritative answer or be willing to chase the
-         referral links themselves.
-
-3. Zero Answer Bugs:
-
-   Name servers sometimes return an authoritative NOERROR with no
-   ANSWER, AUTHORITY or ADDITIONAL records. This happens when the
-   queried name is valid but it does not have a record of the desired
-   type. Of course, the server has authority over the domain.
-
-   However, once again, some implementations of resolvers do not
-   interpret this kind of a response reasonably. They always expect an
-   answer record when they see an authoritative NOERROR. These entities
-   continue to resend their queries, possibly endlessly.
-
-A GOOD IMPLEMENTATION
-
-   BIND resolver code does not query a server more than 3 times. If it
-   is unable to get an answer from 4 servers, querying them three times
-   each, it returns error.
-
-   Of course, it treats a zero-answer response the way it should be
-   treated; with respect!
-
-FIXES:
-
-      a. Set an upper limit on the number of retransmissions for a given
-         query, at the very least.
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 5]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-      b. Fix resolvers to interpret such a response as an authoritative
-         statement of non-existence of the record type for the given
-         name.
-
-4. Inability to detect server failure:
-
-   Servers in the internet are not very reliable (they go down every
-   once in a while) and resolvers are expected to adapt to the changed
-   scenario by not querying the server for a while. Thus, when a server
-   does not respond to a query, resolvers should try another server.
-   Also, non-stub resolvers should update their round trip time estimate
-   for the server to a large value so that server is not tried again
-   before other, faster servers.
-
-   Stub resolvers, however, cycle through a fixed set of servers and if,
-   unfortunately, a server is down while others do not respond for other
-   reasons (high load, recursive resolution of query is taking more time
-   than the resolver's time-out, ....), the resolver queries the dead
-   server again! In fact, some resolvers might not set an upper limit on
-   the number of query retransmissions they will send and continue to
-   query dead servers indefinitely.
-
-   Name servers running system or chained queries might also suffer from
-   the same problem. They store names of servers they should query for a
-   given domain. They cycle through these names and in case none of them
-   answers, hit each one more than one. It is, once again, important
-   that there be an upper limit on the number of retransmissions, to
-   prevent network overload.
-
-   This behavior is clearly in violation of the dictum in RFC 1035 (page
-   46)
-
-      "If a resolver gets a server error or other bizarre response
-       from a name server, it should remove it from SLIST, and may
-       wish to schedule an immediate transmission to the next
-       candidate server address."
-
-   Removal from SLIST implies that the server is not queried again for
-   some time.
-
-   Correctly implemented full-service resolvers should, as pointed out
-   before, update round trip time values for servers that do not respond
-   and query them only after other, good servers. Full-service resolvers
-   might, however, not follow any of these common sense directives. They
-   query dead servers, and they query them endlessly.
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 6]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-A GOOD IMPLEMENTATION:
-
-   BIND places an upper limit on the number of times it queries a
-   server.  Both the stub-resolver and the full-service resolver code do
-   this.  Also, since the full-service resolver estimates round-trip
-   times and sorts name server addresses by these estimates, it does not
-   query a dead server again, until and unless all the other servers in
-   the list are dead too!  Further, BIND implements exponential back-off
-   too.
-
-FIXES:
-
-      a. Set an upper limit on number of retransmissions.
-
-      b. Measure round-trip time from servers (some estimate is better
-         than none). Treat no response as a "very large" round-trip
-         time.
-
-      c. Maintain a weighted rtt estimate and decay the "large" value
-         slowly, with time, so that the server is eventually tested
-         again, but not after an indefinitely long period.
-
-      d. Follow an exponential back-off scheme so that even if you do
-         not restrict the number of queries, you do not overload the
-         net excessively.
-
-5. Cache Leaks:
-
-   Every resource record returned by a server is cached for TTL seconds,
-   where the TTL value is returned with the RR. Full-service (or stub)
-   resolvers cache the RR and answer any queries based on this cached
-   information, in the future, until the TTL expires. After that, one
-   more query to the wide-area network gets the RR in cache again.
-
-   Full-service resolvers might not implement this caching mechanism
-   well. They might impose a limit on the cache size or might not
-   interpret the TTL value correctly. In either case, queries repeated
-   within a TTL period of a RR constitute a cache leak.
-
-A GOOD/BAD IMPLEMENTATION:
-
-   BIND has no restriction on the cache size and the size is governed by
-   the limits on the virtual address space of the machine it is running
-   on. BIND caches RRs for the duration of the TTL returned with each
-   record.
-
-   It does, however, not follow the RFCs with respect to interpretation
-   of a 0 TTL value. If a record has a TTL value of 0 seconds, BIND uses
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 7]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   the minimum TTL value, for that zone, from the SOA record and caches
-   it for that duration. This, though it saves some traffic on the
-   wide-area network, is not correct behavior.
-
-FIXES:
-
-      a. Look over your caching mechanism to ensure TTLs are interpreted
-         correctly.
-
-      b. Do not restrict cache sizes (come on, memory is cheap!).
-         Expired entries are reclaimed periodically, anyway. Of course,
-         the cache size is bound to have some physical limit. But, when
-         possible, this limit should be large (run your name server on
-         a machine with a large amount of physical memory).
-
-      c. Possibly, a mechanism is needed to flush the cache, when it is
-         known or even suspected that the information has changed.
-
-6. Name Error Bugs:
-
-   This bug is very similar to the Zero Answer bug. A server returns an
-   authoritative NXDOMAIN when the queried name is known to be bad, by
-   the server authoritative for the domain, in the absence of negative
-   caching. This authoritative NXDOMAIN response is usually accompanied
-   by the SOA record for the domain, in the authority section.
-
-   Resolvers should recognize that the name they queried for was a bad
-   name and should stop querying further.
-
-   Some resolvers might, however, not interpret this correctly and
-   continue to query servers, expecting an answer record.
-
-   Some applications, in fact, prompt NXDOMAIN answers! When given a
-   perfectly good name to resolve, they append the local domain to it
-   e.g., an application in the domain "foo.bar.com", when trying to
-   resolve the name "usc.edu" first tries "usc.edu.foo.bar.com", then
-   "usc.edu.bar.com" and finally the good name "usc.edu". This causes at
-   least two queries that return NXDOMAIN, for every good query. The
-   problem is aggravated since the negative answers from the previous
-   queries are not cached.  When the same name is sought again, the
-   process repeats.
-
-   Some DNS resolver implementations suffer from this problem, too. They
-   append successive sub-parts of the local domain using an implicit
-   searchlist mechanism, when certain conditions are satisfied and try
-   the original name, only when this first set of iterations fails. This
-   behavior recently caused pandemonium in the Internet when the domain
-   "edu.com" was registered and a wildcard "CNAME" record placed at the
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 8]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   top level. All machines from "com" domains trying to connect to hosts
-   in the "edu" domain ended up with connections to the local machine in
-   the "edu.com" domain!
-
-GOOD/BAD IMPLEMENTATIONS:
-
-   Some local versions of BIND already implement negative caching. They
-   typically cache negative answers with a very small TTL, sufficient to
-   answer a burst of queries spaced close together, as is typically
-   seen.
-
-   The next official public release of BIND (4.9.2) will have negative
-   caching as an ifdef'd feature.
-
-   The BIND resolver appends local domain to the given name, when one of
-   two conditions is met:
-
-      i.  The name has no periods and the flag RES_DEFNAME is set.
-      ii. There is no trailing period and the flag RES_DNSRCH is set.
-
-   The flags RES_DEFNAME and RES_DNSRCH are default resolver options, in
-   BIND, but can be changed at compile time.
-
-   Only if the name, so generated, returns an NXDOMAIN is the original
-   name tried as a Fully Qualified Domain Name. And only if it contains
-   at least one period.
-
-FIXES:
-
-      a. Fix the resolver code.
-
-      b. Negative Caching. Negative caching servers will restrict the
-         traffic seen on the wide-area network, even if not curb it
-         altogether.
-
-      c. Applications and resolvers should not append the local domain to
-         names they seek to resolve, as far as possible. Names
-         interspersed with periods should be treated as Fully Qualified
-         Domain Names.
-
-         In other words, Use searchlists only when explicitly specified.
-         No implicit searchlists should be used. A name that contains
-         any dots should first be tried as a FQDN and if that fails, with
-         the local domain name (or searchlist if specified) appended. A
-         name containing no dots can be appended with the searchlist right
-         away, but once again, no implicit searchlists should be used.
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 9]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   Associated with the name error bug is another problem where a server
-   might return an authoritative NXDOMAIN, although the name is valid. A
-   secondary server, on start-up, reads the zone information from the
-   primary, through a zone transfer. While it is in the process of
-   loading the zones, it does not have information about them, although
-   it is authoritative for them.  Thus, any query for a name in that
-   domain is answered with an NXDOMAIN response code. This problem might
-   not be disastrous were it not for negative caching servers that cache
-   this answer and so propagate incorrect information over the internet.
-
-BAD IMPLEMENTATION:
-
-   BIND apparently suffers from this problem.
-
-   Also, a new name added to the primary database will take a while to
-   propagate to the secondaries. Until that time, they will return
-   NXDOMAIN answers for a good name. Negative caching servers store this
-   answer, too and aggravate this problem further. This is probably a
-   more general DNS problem but is apparently more harmful in this
-   situation.
-
-FIX:
-
-      a. Servers should start answering only after loading all the zone
-         data. A failed server is better than a server handing out
-         incorrect information.
-
-      b. Negative cache records for a very small time, sufficient only
-         to ward off a burst of requests for the same bad name. This
-         could be related to the round-trip time of the server from
-         which the negative answer was received. Alternatively, a
-         statistical measure of the amount of time for which queries
-         for such names are received could be used. Minimum TTL value
-         from the SOA record is not advisable since they tend to be
-         pretty large.
-
-      c. A "PUSH" (or, at least, a "NOTIFY") mechanism should be allowed
-         and implemented, to allow the primary server to inform
-         secondaries that the database has been modified since it last
-         transferred zone data.  To alleviate the problem of "too many
-         zone transfers" that this might cause, Incremental Zone
-         Transfers should also be part of DNS.  Also, the primary should
-         not NOTIFY/PUSH with every update but bunch a good number
-         together.
-
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                         [Page 10]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-7. Format Errors:
-
-   Some resolvers issue query packets that do not necessarily conform to
-   standards as laid out in the relevant RFCs. This unnecessarily
-   increases net traffic and wastes server time.
-
-FIXES:
-
-      a. Fix resolvers.
-
-      b. Each resolver verify format of packets before sending them out,
-         using a mechanism outside of the resolver. This is, obviously,
-         needed only if step 1 cannot be followed.
-
-References
-
-   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
-       RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names Implementation and Specification",
-       STD 13, RFC 1035, USC/Information Sciences Institute, November
-       1987.
-
-   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
-       974, CSNET CIC BBN, January 1986.
-
-   [4] Gavron, E., "A Security Problem and Proposed Correction With
-       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
-       October 1993.
-
-   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
-       1537, CWI, October 1993.
-
-Security Considerations
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                         [Page 11]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-Authors' Addresses
-
-   Anant Kumar
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina Del Rey CA 90292-6695
-
-   Phone:(310) 822-1511
-   FAX:  (310) 823-6741
-   EMail: anant@isi.edu
-
-
-   Jon Postel
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina Del Rey CA 90292-6695
-
-   Phone:(310) 822-1511
-   FAX:  (310) 823-6714
-   EMail: postel@isi.edu
-
-
-   Cliff Neuman
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina Del Rey CA 90292-6695
-
-   Phone:(310) 822-1511
-   FAX:  (310) 823-6714
-   EMail: bcn@isi.edu
-
-
-   Peter Danzig
-   Computer Science Department
-   University of Southern California
-   University Park
-
-   EMail: danzig@caldera.usc.edu
-
-
-   Steve Miller
-   Computer Science Department
-   University of Southern California
-   University Park
-   Los Angeles CA 90089
-
-   EMail: smiller@caldera.usc.edu
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                         [Page 12]
-
diff --git a/doc/rfc/rfc1537.txt b/doc/rfc/rfc1537.txt
deleted file mode 100644
index 81b97683..00000000
--- a/doc/rfc/rfc1537.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        P. Beertema
-Request for Comments: 1537                                           CWI
-Category: Informational                                     October 1993
-
-
-               Common DNS Data File Configuration Errors
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard.  Distribution of this memo is
-   unlimited.
-
-Abstract
-
-   This memo describes errors often found in DNS data files. It points
-   out common mistakes system administrators tend to make and why they
-   often go unnoticed for long periods of time.
-
-Introduction
-
-   Due to the lack of extensive documentation and automated tools, DNS
-   zone files have mostly been configured by system administrators, by
-   hand. Some of the rules for writing the data files are rather subtle
-   and a few common mistakes are seen in domains worldwide.
-
-   This document is an attempt to list "surprises" that administrators
-   might find hidden in their zone files. It describes the symptoms of
-   the malady and prescribes medicine to cure that. It also gives some
-   general recommendations and advice on specific nameserver and zone
-   file issues and on the (proper) use of the Domain Name System.
-
-1. SOA records
-
-   A problem I've found in quite some nameservers is that the various
-   timers have been set (far) too low. Especially for top level domain
-   nameservers this causes unnecessary traffic over international and
-   intercontinental links.
-
-   Unfortunately the examples given in the BIND manual, in RFC's and in
-   some expert documents give those very short timer values, and that's
-   most likely what people have modeled their SOA records after.
-
-   First of all a short explanation of the timers used in the SOA
-   record:
-
-
-
-
-
-
-Beertema                                                        [Page 1]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-        - Refresh: The SOA record of the primary server is checked
-                   every "refresh" time by the secondary servers;
-                   if it has changed, a zone transfer is done.
-
-        - Retry: If a secondary server cannot reach the primary
-                 server, it tries it again every "retry" time.
-
-        - Expire: If for "expire" time the primary server cannot
-                  be reached, all information about the zone is
-                  invalidated on the secondary servers (i.e., they
-                  are no longer authoritative for that zone).
-
-        - Minimum TTL: The default TTL value for all records in the
-                       zone file; a different TTL value may be given
-                       explicitly in a record when necessary.
-                       (This timer is named "Minimum", and that's
-                       what it's function should be according to
-                       STD 13, RFC 1035, but most (all?)
-                       implementations take it as the default value
-                       exported with records without an explicit TTL
-                       value).
-
-   For top level domain servers I would recommend the following values:
-
-          86400 ; Refresh     24 hours
-           7200 ; Retry        2 hours
-        2592000 ; Expire      30 days
-         345600 ; Minimum TTL  4 days
-
-   For other servers I would suggest:
-
-          28800 ; Refresh     8 hours
-           7200 ; Retry       2 hours
-         604800 ; Expire      7 days
-          86400 ; Minimum TTL 1 day
-
-   but here the frequency of changes, the required speed of propagation,
-   the reachability of the primary server etc. play a role in optimizing
-   the timer values.
-
-2. Glue records
-
-   Quite often, people put unnecessary glue (A) records in their zone
-   files. Even worse is that I've even seen *wrong* glue records for an
-   external host in a primary zone file! Glue records need only be in a
-   zone file if the server host is within the zone and there is no A
-   record for that host elsewhere in the zone file.
-
-
-
-
-Beertema                                                        [Page 2]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   Old BIND versions ("native" 4.8.3 and older versions) showed the
-   problem that wrong glue records could enter secondary servers in a
-   zone transfer.
-
-3. "Secondary server surprise"
-
-   I've seen it happen on various occasions that hosts got bombarded by
-   nameserver requests without knowing why. On investigation it turned
-   out then that such a host was supposed to (i.e., the information was
-   in the root servers) run secondary for some domain (or reverse (in-
-   addr.arpa)) domain, without that host's nameserver manager having
-   been asked or even been told so!
-
-   Newer BIND versions (4.9 and later) solved this problem.  At the same
-   time though the fix has the disadvantage that it's far less easy to
-   spot this problem.
-
-   Practice has shown that most domain registrars accept registrations
-   of nameservers without checking if primary (!) and secondary servers
-   have been set up, informed, or even asked.  It should also be noted
-   that a combination of long-lasting unreachability of primary
-   nameservers, (therefore) expiration of zone information, plus static
-   IP routing, can lead to massive network traffic that can fill up
-   lines completely.
-
-4. "MX records surprise"
-
-   In a sense similar to point 3. Sometimes nameserver managers enter MX
-   records in their zone files that point to external hosts, without
-   first asking or even informing the systems managers of those external
-   hosts.  This has to be fought out between the nameserver manager and
-   the systems managers involved. Only as a last resort, if really
-   nothing helps to get the offending records removed, can the systems
-   manager turn to the naming authority of the domain above the
-   offending domain to get the problem sorted out.
-
-5. "Name extension surprise"
-
-   Sometimes one encounters weird names, which appear to be an external
-   name extended with a local domain. This is caused by forgetting to
-   terminate a name with a dot: names in zone files that don't end with
-   a dot are always expanded with the name of the current zone (the
-   domain that the zone file stands for or the last $ORIGIN).
-
-   Example: zone file for foo.xx:
-
-   pqr          MX 100  relay.yy.
-   xyz          MX 100  relay.yy           (no trailing dot!)
-
-
-
-Beertema                                                        [Page 3]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   When fully written out this stands for:
-
-      pqr.foo.xx.  MX 100  relay.yy.
-      xyz.foo.xx.  MX 100  relay.yy.foo.xx.   (name extension!)
-
-6. Missing secondary servers
-
-   It is required that there be a least 2 nameservers for a domain. For
-   obvious reasons the nameservers for top level domains need to be very
-   well reachable from all over the Internet. This implies that there
-   must be more than just 2 of them; besides, most of the (secondary)
-   servers should be placed at "strategic" locations, e.g., close to a
-   point where international and/or intercontinental lines come
-   together.  To keep things manageable, there shouldn't be too many
-   servers for a domain either.
-
-   Important aspects in selecting the location of primary and secondary
-   servers are reliability (network, host) and expedient contacts: in
-   case of problems, changes/fixes must be carried out quickly.  It
-   should be considered logical that primary servers for European top
-   level domains should run on a host in Europe, preferably (if
-   possible) in the country itself. For each top level domain there
-   should be 2 secondary servers in Europe and 2 in the USA, but there
-   may of course be more on either side.  An excessive number of
-   nameservers is not a good idea though; a recommended maximum is 7
-   nameservers.  In Europe, EUnet has offered to run secondary server
-   for each European top level domain.
-
-7. Wildcard MX records
-
-   Wildcard MX records should be avoided where possible. They often
-   cause confusion and errors: especially beginning nameserver managers
-   tend to overlook the fact that a host/domain listed with ANY type of
-   record in a zone file is NOT covered by an overall wildcard MX record
-   in that zone; this goes not only for simple domain/host names, but
-   also for names that cover one or more domains. Take the following
-   example in zone foo.bar:
-
-         *            MX 100  mailhost
-         pqr          MX 100  mailhost
-         abc.def      MX 100  mailhost
-
-   This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid
-   domains, but the wildcard MX record covers NONE of them, nor anything
-   below them.  To cover everything by MX records, the required entries
-   are:
-
-
-
-
-
-Beertema                                                        [Page 4]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-         *            MX 100  mailhost
-         pqr          MX 100  mailhost
-         *.pqr        MX 100  mailhost
-         abc.def      MX 100  mailhost
-         *.def        MX 100  mailhost
-         *.abc.def    MX 100  mailhost
-
-   An overall wildcard MX record is almost never useful.
-
-   In particular the zone file of a top level domain should NEVER
-   contain only an overall wildcard MX record (*.XX). The effect of such
-   a wildcard MX record can be that mail is unnecessarily sent across
-   possibly expensive links, only to fail at the destination or gateway
-   that the record points to. Top level domain zone files should
-   explicitly list at least all the officially registered primary
-   subdomains.
-
-   Whereas overall wildcard MX records should be avoided, wildcard MX
-   records are acceptable as an explicit part of subdomain entries,
-   provided they are allowed under a given subdomain (to be determined
-   by the naming authority for that domain).
-
-   Example:
-
-         foo.xx.      MX 100  gateway.xx.
-                      MX 200  fallback.yy.
-         *.foo.xx.    MX 100  gateway.xx.
-                      MX 200  fallback.yy.
-8. Hostnames
-
-   People appear to sometimes look only at STD 11, RFC 822 to determine
-   whether a particular hostname is correct or not. Hostnames should
-   strictly conform to the syntax given in STD 13, RFC 1034 (page 11),
-   with *addresses* in addition conforming to RFC 822. As an example
-   take "c&w.blues" which is perfectly legal according to RFC 822, but
-   which can have quite surprising effects on particular systems, e.g.,
-   "telnet c&w.blues" on a Unix system.
-
-9. HINFO records
-
-   There appears to be a common misunderstanding that one of the data
-   fields (usually the second field) in HINFO records is optional. A
-   recent scan of all reachable nameservers in only one country revealed
-   some 300 incomplete HINFO records. Specifying two data fields in a
-   HINFO record is mandatory (RFC 1033), but note that this does *not*
-   mean that HINFO records themselves are mandatory.
-
-
-
-
-
-Beertema                                                        [Page 5]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-10. Safety measures and specialties
-
-   Nameservers and resolvers aren't flawless. Bogus queries should be
-   kept from being forwarded to the root servers, since they'll only
-   lead to unnecessary intercontinental traffic. Known bogus queries
-   that can easily be dealt with locally are queries for 0 and broadcast
-   addresses.  To catch such queries, every nameserver should run
-   primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone
-   files need only contain a SOA and an NS record.
-
-   Also each nameserver should run primary for 0.0.127.in-addr.arpa;
-   that zone file should contain a SOA and NS record and an entry:
-
-         1    PTR     localhost.
-
-   There has been extensive discussion about whether or not to append
-   the local domain to it. The conclusion was that "localhost." would be
-   the best solution; reasons given were:
-
-   - "localhost" itself is used and expected to work on some systems.
-
-   - translating 127.0.0.1 into "localhost.my_domain" can cause some
-     software to connect to itself using the loopback interface when
-     it didn't want to.
-
-   Note that all domains that contain hosts should have a "localhost" A
-   record in them.
-
-   People maintaining zone files with the Serial number given in dotted
-   decimal notation (e.g., when SCCS is used to maintain the files)
-   should beware of a bug in all BIND versions: if the serial number is
-   in Release.Version (dotted decimal) notation, then it is virtually
-   impossible to change to a higher release: because of the wrong way
-   that notation is turned into an integer, it results in a serial
-   number that is LOWER than that of the former release.
-
-   For this reason and because the Serial is an (unsigned) integer
-   according to STD 13, RFC 1035, it is recommended not to use the
-   dotted decimal notation. A recommended notation is to use the date
-   (yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is
-   or can be more than one change per day in a zone file.
-
-   Very old versions of DNS resolver code have a bug that causes queries
-   for A records with domain names like "192.16.184.3" to go out. This
-   happens when users type in IP addresses and the resolver code does
-   not catch this case before sending out a DNS query. This problem has
-   been fixed in all resolver implementations known to us but if it
-   still pops up it is very serious because all those queries will go to
-
-
-
-Beertema                                                        [Page 6]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   the root servers looking for top level domains like "3" etc. It is
-   strongly recommended to install the latest (publicly) available BIND
-   version plus all available patches to get rid of these and other
-   problems.
-
-   Running secondary nameserver off another secondary nameserver is
-   possible, but not recommended unless really necessary: there are
-   known cases where it has led to problems like bogus TTL values. This
-   can be caused by older or flawed implementations, but secondary
-   nameservers in principle should always transfer their zones from the
-   official primary nameserver.
-
-11. Some general points
-
-   The Domain Name System and nameserver are purely technical tools, not
-   meant in any way to exert control or impose politics. The function of
-   a naming authority is that of a clearing house. Anyone registering a
-   subdomain under a particular (top level) domain becomes naming
-   authority and therewith the sole responsible for that subdomain.
-   Requests to enter MX or NS records concerning such a subdomain
-   therefore always MUST be honored by the registrar of the next higher
-   domain.
-
-   Examples of practices that are not allowed are:
-
-      - imposing specific mail routing (MX records) when registering
-        a subdomain.
-
-      - making registration of a subdomain dependent on to the use of
-        certain networks or services.
-
-      - using TXT records as a means of (free) commercial advertising.
-
-   In the latter case a network service provider could decide to cut off
-   a particular site until the offending TXT records have been removed
-   from the site's zone file.
-
-   Of course there are obvious cases where a naming authority can refuse
-   to register a particular subdomain and can require a proposed name to
-   be changed in order to get it registered (think of DEC trying to
-   register a domain IBM.XX).
-
-   There are also cases were one has to probe the authority of the
-   person: sending in the application - not every systems manager should
-   be able to register a domain name for a whole university.  The naming
-   authority can impose certain extra rules as long as they don't
-   violate or conflict with the rights and interest of the registrars of
-   subdomains; a top level domain registrar may e.g., require that there
-
-
-
-Beertema                                                        [Page 7]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   be primary subdomain "ac" and "co" only and that subdomains be
-   registered under those primary subdomains.
-
-   The naming authority can also interfere in exceptional cases like the
-   one mentioned in point 4, e.g., by temporarily removing a domain's
-   entry from the nameserver zone files; this of course should be done
-   only with extreme care and only as a last resort.
-
-   When adding NS records for subdomains, top level domain nameserver
-   managers should realize that the people setting up the nameserver for
-   a subdomain often are rather inexperienced and can make mistakes that
-   can easily lead to the subdomain becoming completely unreachable or
-   that can cause unnecessary DNS traffic (see point 1). It is therefore
-   highly recommended that, prior to entering such an NS record, the
-   (top level) nameserver manager does a couple of sanity checks on the
-   new nameserver (SOA record and timers OK?, MX records present where
-   needed? No obvious errors made? Listed secondary servers
-   operational?). Things that cannot be caught though by such checks
-   are:
-
-      - resolvers set up to use external hosts as nameservers
-
-      - nameservers set up to use external hosts as forwarders
-        without permission from those hosts.
-
-   Care should also be taken when registering 2-letter subdomains.
-   Although this is allowed, an implication is that abbreviated
-   addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in
-   and under that subdomain.  When requested to register such a domain,
-   one should always notify the people of this consequence. As an
-   example take the name "cs", which is commonly used for Computer
-   Science departments: it is also the name of the top level domain for
-   Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is
-   ambiguous in that in can denote both a user on the host
-   host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia.
-   (This example does not take into account the recent political changes
-   in the mentioned country).
-
-References
-
-   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
-       RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names Implementation and Specification",
-       STD 13, RFC 1035, USC/Information Sciences Institute, November
-       1987.
-
-
-
-
-
-Beertema                                                        [Page 8]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
-       974, CSNET CIC BBN, January 1986.
-
-   [4] Gavron, E., "A Security Problem and Proposed Correction With
-       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
-       October 1993.
-
-   [5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
-       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
-       USC/Information Sciences Institute, USC, October 1993.
-
-Security Considerations
-
-   Security issues are not discussed in this memo.
-
-Author's Address
-
-   Piet Beertema
-   CWI
-   Kruislaan 413
-   NL-1098 SJ Amsterdam
-   The Netherlands
-
-   Phone: +31 20 592 4112
-   FAX:   +31 20 592 4199
-   EMail: Piet.Beertema@cwi.nl
-
-
-Editor's Address
-
-   Anant Kumar
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina Del Rey CA 90292-6695
-
-   Phone:(310) 822-1511
-   FAX:  (310) 823-6741
-   EMail: anant@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-Beertema                                                        [Page 9]
-
\ No newline at end of file
diff --git a/doc/rfc/rfc1591.txt b/doc/rfc/rfc1591.txt
deleted file mode 100644
index 89e0a254..00000000
--- a/doc/rfc/rfc1591.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          J. Postel
-Request for Comments: 1591                                           ISI
-Category: Informational                                       March 1994
-
-
-              Domain Name System Structure and Delegation
-
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-1. Introduction
-
-   This memo provides some information on the structure of the names in
-   the Domain Name System (DNS), specifically the top-level domain
-   names; and on the administration of domains.  The Internet Assigned
-   Numbers Authority (IANA) is the overall authority for the IP
-   Addresses, the Domain Names, and many other parameters, used in the
-   Internet.  The day-to-day responsibility for the assignment of IP
-   Addresses, Autonomous System Numbers, and most top and second level
-   Domain Names are handled by the Internet Registry (IR) and regional
-   registries.
-
-2.  The Top Level Structure of the Domain Names
-
-   In the Domain Name System (DNS) naming of computers there is a
-   hierarchy of names.  The root of system is unnamed.  There are a set
-   of what are called "top-level domain names" (TLDs).  These are the
-   generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
-   letter country codes from ISO-3166.  It is extremely unlikely that
-   any other TLDs will be created.
-
-   Under each TLD may be created a hierarchy of names.  Generally, under
-   the generic TLDs the structure is very flat.  That is, many
-   organizations are registered directly under the TLD, and any further
-   structure is up to the individual organizations.
-
-   In the country TLDs, there is a wide variation in the structure, in
-   some countries the structure is very flat, in others there is
-   substantial structural organization.  In some country domains the
-   second levels are generic categories (such as, AC, CO, GO, and RE),
-   in others they are based on political geography, and in still others,
-   organization names are listed directly under the country code.  The
-   organization for the US country domain is described in RFC 1480 [1].
-
-
-
-
-Postel                                                          [Page 1]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-   Each of the generic TLDs was created for a general category of
-   organizations.  The country code domains (for example, FR, NL, KR,
-   US) are each organized by an administrator for that country.  These
-   administrators may further delegate the management of portions of the
-   naming tree.  These administrators are performing a public service on
-   behalf of the Internet community.  Descriptions of the generic
-   domains and the US country domain follow.
-
-   Of these generic domains, five are international in nature, and two
-   are restricted to use by entities in the United States.
-
-   World Wide Generic Domains:
-
-   COM - This domain is intended for commercial entities, that is
-         companies.  This domain has grown very large and there is
-         concern about the administrative load and system performance if
-         the current growth pattern is continued.  Consideration is
-         being taken to subdivide the COM domain and only allow future
-         commercial registrations in the subdomains.
-
-   EDU - This domain was originally intended for all educational
-         institutions.  Many Universities, colleges, schools,
-         educational service organizations, and educational consortia
-         have registered here.  More recently a decision has been taken
-         to limit further registrations to 4 year colleges and
-         universities.  Schools and 2-year colleges will be registered
-         in the country domains (see US Domain, especially K12 and CC,
-         below).
-
-   NET - This domain is intended to hold only the computers of network
-         providers, that is the NIC and NOC computers, the
-         administrative computers, and the network node computers.  The
-         customers of the network provider would have domain names of
-         their own (not in the NET TLD).
-
-   ORG - This domain is intended as the miscellaneous TLD for
-         organizations that didn't fit anywhere else.  Some non-
-         government organizations may fit here.
-
-   INT - This domain is for organizations established by international
-         treaties, or international databases.
-
-   United States Only Generic Domains:
-
-   GOV - This domain was originally intended for any kind of government
-         office or agency.  More recently a decision was taken to
-         register only agencies of the US Federal government in this
-         domain.  State and local agencies are registered in the country
-
-
-
-Postel                                                          [Page 2]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-         domains (see US Domain, below).
-
-   MIL - This domain is used by the US military.
-
-   Example country code Domain:
-
-   US - As an example of a country domain, the US domain provides for
-        the registration of all kinds of entities in the United States
-        on the basis of political geography, that is, a hierarchy of
-        <entity-name>.<locality>.<state-code>.US.  For example,
-        "IBM.Armonk.NY.US".  In addition, branches of the US domain are
-        provided within each state for schools (K12), community colleges
-        (CC), technical schools (TEC), state government agencies
-        (STATE), councils of governments (COG),libraries (LIB), museums
-        (MUS), and several other generic types of entities (see RFC 1480
-        for details [1]).
-
-   To find a contact for a TLD use the "whois" program to access the
-   database on the host rs.internic.net.  Append "-dom" to the name of
-   TLD you are interested in.  For example:
-
-                       whois -h rs.internic.net us-dom
-      or
-                       whois -h rs.internic.net edu-dom
-
-3.  The Administration of Delegated Domains
-
-   The Internet Assigned Numbers Authority (IANA) is responsible for the
-   overall coordination and management of the Domain Name System (DNS),
-   and especially the delegation of portions of the name space called
-   top-level domains.  Most of these top-level domains are two-letter
-   country codes taken from the ISO standard 3166.
-
-   A central Internet Registry (IR) has been selected and designated to
-   handled the bulk of the day-to-day administration of the Domain Name
-   System.  Applications for new top-level domains (for example, country
-   code domains) are handled by the IR with consultation with the IANA.
-   The central IR is INTERNIC.NET.  Second level domains in COM, EDU,
-   ORG, NET, and GOV are registered by the Internet Registry at the
-   InterNIC.  The second level domains in the MIL are registered by the
-   DDN registry at NIC.DDN.MIL.  Second level names in INT are
-   registered by the PVM at ISI.EDU.
-
-   While all requests for new top-level domains must be sent to the
-   Internic (at hostmaster@internic.net), the regional registries are
-   often enlisted to assist in the administration of the DNS, especially
-   in solving problems with a country administration.  Currently, the
-   RIPE NCC is the regional registry for Europe and the APNIC is the
-
-
-
-Postel                                                          [Page 3]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-   regional registry for the Asia-Pacific region, while the INTERNIC
-   administers the North America region, and all the as yet undelegated
-   regions.
-
-      The contact mailboxes for these regional registries are:
-
-         INTERNIC        hostmaster@internic.net
-         APNIC           hostmaster@apnic.net
-         RIPE NCC        ncc@ripe.net
-
-   The policy concerns involved when a new top-level domain is
-   established are described in the following.  Also mentioned are
-   concerns raised when it is necessary to change the delegation of an
-   established domain from one party to another.
-
-   A new top-level domain is usually created and its management
-   delegated to a "designated manager" all at once.
-
-   Most of these same concerns are relevant when a sub-domain is
-   delegated and in general the principles described here apply
-   recursively to all delegations of the Internet DNS name space.
-
-   The major concern in selecting a designated manager for a domain is
-   that it be able to carry out the necessary responsibilities, and have
-   the ability to do a equitable, just, honest, and competent job.
-
-   1) The key requirement is that for each domain there be a designated
-      manager for supervising that domain's name space.  In the case of
-      top-level domains that are country codes this means that there is
-      a manager that supervises the domain names and operates the domain
-      name system in that country.
-
-      The manager must, of course, be on the Internet.  There must be
-      Internet Protocol (IP) connectivity to the nameservers and email
-      connectivity to the management and staff of the manager.
-
-      There must be an administrative contact and a technical contact
-      for each domain.  For top-level domains that are country codes at
-      least the administrative contact must reside in the country
-      involved.
-
-   2) These designated authorities are trustees for the delegated
-      domain, and have a duty to serve the community.
-
-      The designated manager is the trustee of the top-level domain for
-      both the nation, in the case of a country code, and the global
-      Internet community.
-
-
-
-
-Postel                                                          [Page 4]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-      Concerns about "rights" and "ownership" of domains are
-      inappropriate.  It is appropriate to be concerned about
-      "responsibilities" and "service" to the community.
-
-   3) The designated manager must be equitable to all groups in the
-      domain that request domain names.
-
-      This means that the same rules are applied to all requests, all
-      requests must be processed in a non-discriminatory fashion, and
-      academic and commercial (and other) users are treated on an equal
-      basis.  No bias shall be shown regarding requests that may come
-      from customers of some other business related to the manager --
-      e.g., no preferential service for customers of a particular data
-      network provider.  There can be no requirement that a particular
-      mail system (or other application), protocol, or product be used.
-
-      There are no requirements on subdomains of top-level domains
-      beyond the requirements on higher-level domains themselves.  That
-      is, the requirements in this memo are applied recursively.  In
-      particular, all subdomains shall be allowed to operate their own
-      domain name servers, providing in them whatever information the
-      subdomain manager sees fit (as long as it is true and correct).
-
-   4) Significantly interested parties in the domain should agree that
-      the designated manager is the appropriate party.
-
-      The IANA tries to have any contending parties reach agreement
-      among themselves, and generally takes no action to change things
-      unless all the contending parties agree; only in cases where the
-      designated manager has substantially mis-behaved would the IANA
-      step in.
-
-      However, it is also appropriate for interested parties to have
-      some voice in selecting the designated manager.
-
-      There are two cases where the IANA and the central IR may
-      establish a new top-level domain and delegate only a portion of
-      it: (1) there are contending parties that cannot agree, or (2) the
-      applying party may not be able to represent or serve the whole
-      country.  The later case sometimes arises when a party outside a
-      country is trying to be helpful in getting networking started in a
-      country -- this is sometimes called a "proxy" DNS service.
-
-      The Internet DNS Names Review Board (IDNB), a committee
-      established by the IANA, will act as a review panel for cases in
-      which the parties can not reach agreement among themselves.  The
-      IDNB's decisions will be binding.
-
-
-
-
-Postel                                                          [Page 5]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-   5) The designated manager must do a satisfactory job of operating the
-      DNS service for the domain.
-
-      That is, the actual management of the assigning of domain names,
-      delegating subdomains and operating nameservers must be done with
-      technical competence.  This includes keeping the central IR (in
-      the case of top-level domains) or other higher-level domain
-      manager advised of the status of the domain, responding to
-      requests in a timely manner, and operating the database with
-      accuracy, robustness, and resilience.
-
-      There must be a primary and a secondary nameserver that have IP
-      connectivity to the Internet and can be easily checked for
-      operational status and database accuracy by the IR and the IANA.
-
-      In cases when there are persistent problems with the proper
-      operation of a domain, the delegation may be revoked, and possibly
-      delegated to another designated manager.
-
-   6) For any transfer of the designated manager trusteeship from one
-      organization to another, the higher-level domain manager (the IANA
-      in the case of top-level domains) must receive communications from
-      both the old organization and the new organization that assure the
-      IANA that the transfer in mutually agreed, and that the new
-      organization understands its responsibilities.
-
-      It is also very helpful for the IANA to receive communications
-      from other parties that may be concerned or affected by the
-      transfer.
-
-4. Rights to Names
-
-   1) Names and Trademarks
-
-      In case of a dispute between domain name registrants as to the
-      rights to a particular name, the registration authority shall have
-      no role or responsibility other than to provide the contact
-      information to both parties.
-
-      The registration of a domain name does not have any Trademark
-      status.  It is up to the requestor to be sure he is not violating
-      anyone else's Trademark.
-
-   2) Country Codes
-
-      The IANA is not in the business of deciding what is and what is
-      not a country.
-
-
-
-
-Postel                                                          [Page 6]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-      The selection of the ISO 3166 list as a basis for country code
-      top-level domain names was made with the knowledge that ISO has a
-      procedure for determining which entities should be and should not
-      be on that list.
-
-5. Security Considerations
-
-   Security issues are not discussed in this memo.
-
-6. Acknowledgements
-
-   Many people have made comments on draft version of these descriptions
-   and procedures.  Steve Goldstein and John Klensin have been
-   particularly helpful.
-
-7. Author's Address
-
-   Jon Postel
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA  90292
-
-   Phone: 310-822-1511
-   Fax:   310-823-6714
-   EMail: Postel@ISI.EDU
-
-7. References
-
-   [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480,
-       USC/Information Sciences Institute, June 1993.
-
-   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
-       USC/Information Sciences Institute, July 1992.
-
-   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
-       13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [4] Mockapetris, P., "Domain Names - Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-   [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
-       974, CSNET CIC BBN, January 1986.
-
-   [7] Braden, R., Editor, "Requirements for Internet Hosts --
-       Application and Support", STD 3, RFC 1123, Internet Engineering
-       Task Force, October 1989.
-
-
-
-
-Postel                                                          [Page 7]
-
diff --git a/doc/rfc/rfc1611.txt b/doc/rfc/rfc1611.txt
deleted file mode 100644
index ed5b93a8..00000000
--- a/doc/rfc/rfc1611.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 1611               Epilogue Technology Corporation
-Category: Standards Track                                     J. Saperia
-                                           Digital Equipment Corporation
-                                                                May 1994
-
-                       DNS Server MIB Extensions
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Table of Contents
-
-   1. Introduction ..............................................    1
-   2. The SNMPv2 Network Management Framework ...................    2
-   2.1 Object Definitions .......................................    2
-   3. Overview ..................................................    2
-   3.1 Resolvers ................................................    3
-   3.2 Name Servers .............................................    3
-   3.3 Selected Objects .........................................    4
-   3.4 Textual Conventions ......................................    4
-   4. Definitions ...............................................    5
-   5. Acknowledgements ..........................................   28
-   6. References ................................................   28
-   7. Security Considerations ...................................   29
-   8. Authors' Addresses ........................................   30
-
-1.  Introduction
-
-   This memo defines a portion of the Management Information Base (MIB)
-   for use with network management protocols in the Internet community.
-   In particular, it describes a set of extensions which instrument DNS
-   name server functions.  This memo was produced by the DNS working
-   group.
-
-   With the adoption of the Internet-standard Network Management
-   Framework [4,5,6,7], and with a large number of vendor
-   implementations of these standards in commercially available
-   products, it became possible to provide a higher level of effective
-   network management in TCP/IP-based internets than was previously
-   available.  With the growth in the use of these standards, it has
-   become possible to consider the management of other elements of the
-   infrastructure beyond the basic TCP/IP protocols.  A key element of
-
-
-
-Austein & Saperia                                               [Page 1]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   the TCP/IP infrastructure is the DNS.
-
-   Up to this point there has been no mechanism to integrate the
-   management of the DNS with SNMP-based managers.  This memo provides
-   the mechanisms by which IP-based management stations can effectively
-   manage DNS name server software in an integrated fashion.
-
-   We have defined DNS MIB objects to be used in conjunction with the
-   Internet MIB to allow access to and control of DNS name server
-   software via SNMP by the Internet community.
-
-2.  The SNMPv2 Network Management Framework
-
-   The SNMPv2 Network Management Framework consists of four major
-   components.  They are:
-
-      o  RFC 1442 which defines the SMI, the mechanisms used for
-         describing and naming objects for the purpose of management.
-
-      o  STD 17, RFC 1213 defines MIB-II, the core set of managed objects
-         for the Internet suite of protocols.
-
-      o  RFC 1445 which defines the administrative and other architectural
-         aspects of the framework.
-
-      o  RFC 1448 which defines the protocol used for network access to
-         managed objects.
-
-      The Framework permits new objects to be defined for the purpose of
-      experimentation and evaluation.
-
-2.1.  Object Definitions
-
-   Managed objects are accessed via a virtual information store, termed
-   the Management Information Base or MIB.  Objects in the MIB are
-   defined using the subset of Abstract Syntax Notation One (ASN.1)
-   defined in the SMI.  In particular, each object object type is named
-   by an OBJECT IDENTIFIER, an administratively assigned name.  The
-   object type together with an object instance serves to uniquely
-   identify a specific instantiation of the object.  For human
-   convenience, we often use a textual string, termed the descriptor, to
-   refer to the object type.
-
-3.  Overview
-
-   In theory, the DNS world is pretty simple.  There are two kinds of
-   entities: resolvers and name servers.  Resolvers ask questions.  Name
-   servers answer them.  The real world, however, is not so simple.
-
-
-
-Austein & Saperia                                               [Page 2]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   Implementors have made widely differing choices about how to divide
-   DNS functions between resolvers and servers.  They have also
-   constructed various sorts of exotic hybrids.  The most difficult task
-   in defining this MIB was to accommodate this wide range of entities
-   without having to come up with a separate MIB for each.
-
-   We divided up the various DNS functions into two, non-overlapping
-   classes, called "resolver functions" and "name server functions."  A
-   DNS entity that performs what we define as resolver functions
-   contains a resolver, and therefore must implement the MIB groups
-   required of all resolvers which are defined in a separate MIB Module.
-   A DNS entity which implements name server functions is considered to
-   be a name server, and must implement the MIB groups required for name
-   servers in this module.  If the same piece of software performs both
-   resolver and server functions, we imagine that it contains both a
-   resolver and a server and would thus implement both the DNS Server
-   and DNS Resolver MIBs.
-
-3.1.  Resolvers
-
-   In our model, a resolver is a program (or piece thereof) which
-   obtains resource records from servers.  Normally it does so at the
-   behest of an application, but may also do so as part of its own
-   operation.  A resolver sends DNS protocol queries and receives DNS
-   protocol replies.  A resolver neither receives queries nor sends
-   replies.  A full service resolver is one that knows how to resolve
-   queries: it obtains the needed resource records by contacting a
-   server authoritative for the records desired.  A stub resolver does
-   not know how to resolve queries: it sends all queries to a local name
-   server, setting the "recursion desired" flag to indicate that it
-   hopes that the name server will be willing to resolve the query.  A
-   resolver may (optionally) have a cache for remembering previously
-   acquired resource records.  It may also have a negative cache for
-   remembering names or data that have been determined not to exist.
-
-3.2.  Name Servers
-
-   A name server is a program (or piece thereof) that provides resource
-   records to resolvers.  All references in this document to "a name
-   server" imply "the name server's role"; in some cases the name
-   server's role and the resolver's role might be combined into a single
-   program.  A name server receives DNS protocol queries and sends DNS
-   protocol replies.  A name server neither sends queries nor receives
-   replies.  As a consequence, name servers do not have caches.
-   Normally, a name server would expect to receive only those queries to
-   which it could respond with authoritative information.  However, if a
-   name server receives a query that it cannot respond to with purely
-   authoritative information, it may choose to try to obtain the
-
-
-
-Austein & Saperia                                               [Page 3]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   necessary additional information from a resolver which may or may not
-   be a separate process.
-
-3.3.  Selected Objects
-
-   Many of the objects included in this memo have been created from
-   information contained in the DNS specifications [1,2], as amended and
-   clarified by subsequent host requirements documents [3].  Other
-   objects have been created based on experience with existing DNS
-   management tools, expected operational needs, the statistics
-   generated by existing DNS implementations, and the configuration
-   files used by existing DNS implementations.  These objects have been
-   ordered into groups as follows:
-
-      o  Server Configuration Group
-
-      o  Server Counter Group
-
-      o  Server Optional Counter Group
-
-      o  Server Zone Group
-
-   This information has been converted into a standard form using the
-   SNMPv2 SMI defined in [9].  For the most part, the descriptions are
-   influenced by the DNS related RFCs noted above.  For example, the
-   descriptions for counters used for the various types of queries of
-   DNS records are influenced by the definitions used for the various
-   record types found in [2].
-
-3.4.  Textual Conventions
-
-   Several conceptual data types have been introduced as a textual
-   conventions in this DNS MIB document.  These additions will
-   facilitate the common understanding of information used by the DNS.
-   No changes to the SMI or the SNMP are necessary to support these
-   conventions.
-
-   Readers familiar with MIBs designed to manage entities in the lower
-   layers of the Internet protocol suite may be surprised at the number
-   of non-enumerated integers used in this MIB to represent values such
-   as DNS RR class and type numbers.  The reason for this choice is
-   simple: the DNS itself is designed as an extensible protocol,
-   allowing new classes and types of resource records to be added to the
-   protocol without recoding the core DNS software.  Using non-
-   enumerated integers to represent these data types in this MIB allows
-   the MIB to accommodate these changes as well.
-
-
-
-
-
-Austein & Saperia                                               [Page 4]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-4.  Definitions
-
-   DNS-SERVER-MIB DEFINITIONS ::= BEGIN
-
-   IMPORTS
-       mib-2
-           FROM RFC-1213
-       MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
-       IpAddress, Counter32, Gauge32
-           FROM SNMPv2-SMI
-       TEXTUAL-CONVENTION, RowStatus, DisplayString, TruthValue
-           FROM SNMPv2-TC
-       MODULE-COMPLIANCE, OBJECT-GROUP
-           FROM SNMPv2-CONF;
-
-   dns OBJECT-IDENTITY
-       STATUS  current
-       DESCRIPTION
-               "The OID assigned to DNS MIB work by the IANA."
-       ::= { mib-2 32 }
-
-   dnsServMIB MODULE-IDENTITY
-       LAST-UPDATED "9401282251Z"
-       ORGANIZATION "IETF DNS Working Group"
-       CONTACT-INFO
-               "       Rob Austein
-               Postal: Epilogue Technology Corporation
-                       268 Main Street, Suite 283
-                       North Reading, MA 10864
-                       US
-                  Tel: +1 617 245 0804
-                  Fax: +1 617 245 8122
-               E-Mail: sra@epilogue.com
-
-                       Jon Saperia
-               Postal: Digital Equipment Corporation
-                       110 Spit Brook Road
-                       ZKO1-3/H18
-                       Nashua, NH 03062-2698
-                       US
-                  Tel: +1 603 881 0480
-                  Fax: +1 603 881 0120
-                Email: saperia@zko.dec.com"
-       DESCRIPTION
-               "The MIB module for entities implementing the server side
-               of the Domain Name System (DNS) protocol."
-       ::= { dns 1 }
-
-
-
-
-Austein & Saperia                                               [Page 5]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServMIBObjects       OBJECT IDENTIFIER ::= { dnsServMIB 1 }
-
-   -- (Old-style) groups in the DNS server MIB.
-
-   dnsServConfig           OBJECT IDENTIFIER ::= { dnsServMIBObjects 1 }
-   dnsServCounter          OBJECT IDENTIFIER ::= { dnsServMIBObjects 2 }
-   dnsServOptCounter       OBJECT IDENTIFIER ::= { dnsServMIBObjects 3 }
-   dnsServZone             OBJECT IDENTIFIER ::= { dnsServMIBObjects 4 }
-
-
-   -- Textual conventions
-
-   DnsName ::= TEXTUAL-CONVENTION
-       -- A DISPLAY-HINT would be nice, but difficult to express.
-       STATUS  current
-       DESCRIPTION
-               "A DNS name is a sequence of labels.  When DNS names are
-               displayed, the boundaries between labels are typically
-               indicated by dots (e.g. `Acme' and `COM' are labels in
-               the name `Acme.COM').  In the DNS protocol, however, no
-               such separators are needed because each label is encoded
-               as a length octet followed by the indicated number of
-               octets of label.  For example, `Acme.COM' is encoded as
-               the octet sequence { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O',
-               'M', 0 } (the final 0 is the length of the name of the
-               root domain, which appears implicitly at the end of any
-               DNS name).  This MIB uses the same encoding as the DNS
-               protocol.
-
-               A DnsName must always be a fully qualified name.  It is
-               an error to encode a relative domain name as a DnsName
-               without first making it a fully qualified name."
-       REFERENCE
-               "RFC-1034 section 3.1."
-       SYNTAX  OCTET STRING (SIZE (0..255))
-
-   DnsNameAsIndex ::= TEXTUAL-CONVENTION
-       STATUS  current
-       DESCRIPTION
-               "This textual convention is like a DnsName, but is used
-               as an index componant in tables.  Alphabetic characters
-               in names of this type are restricted to uppercase: the
-               characters 'a' through 'z' are mapped to the characters
-               'A' through 'Z'.  This restriction is intended to make
-               the lexical ordering imposed by SNMP useful when applied
-               to DNS names.
-
-               Note that it is theoretically possible for a valid DNS
-
-
-
-Austein & Saperia                                               [Page 6]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-               name to exceed the allowed length of an SNMP object
-               identifer, and thus be impossible to represent in tables
-               in this MIB that are indexed by DNS name.  Sampling of
-               DNS names in current use on the Internet suggests that
-               this limit does not pose a serious problem in practice."
-       REFERENCE
-               "RFC-1034 section 3.1, RFC-1448 section 4.1."
-       SYNTAX  DnsName
-
-   DnsClass ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "2d"
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the class values
-               which appear in Resource Records in the DNS.  A 16-bit
-               unsigned integer is used to allow room for new classes
-               of records to be defined.  Existing standard classes are
-               listed in the DNS specifications."
-       REFERENCE
-               "RFC-1035 section 3.2.4."
-       SYNTAX  INTEGER (0..65535)
-
-   DnsType ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "2d"
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the type values
-               which appear in Resource Records in the DNS.  A 16-bit
-               unsigned integer is used to allow room for new record
-               types to be defined.  Existing standard types are listed
-               in the DNS specifications."
-       REFERENCE
-               "RFC-1035 section 3.2.2."
-       SYNTAX  INTEGER (0..65535)
-
-   DnsQClass ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "2d"
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the QClass values
-               which appear in Resource Records in the DNS.  A 16-bit
-               unsigned integer is used to allow room for new QClass
-               records to be defined.  Existing standard QClasses are
-               listed in the DNS specification."
-       REFERENCE
-               "RFC-1035 section 3.2.5."
-       SYNTAX  INTEGER (0..65535)
-
-
-
-
-Austein & Saperia                                               [Page 7]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   DnsQType ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "2d"
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the QType values
-               which appear in Resource Records in the DNS.  A 16-bit
-               unsigned integer is used to allow room for new QType
-               records to be defined.  Existing standard QTypes are
-               listed in the DNS specification."
-       REFERENCE
-               "RFC-1035 section 3.2.3."
-       SYNTAX  INTEGER (0..65535)
-
-   DnsTime ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "4d"
-       STATUS  current
-       DESCRIPTION
-               "DnsTime values are 32-bit unsigned integers which
-               measure time in seconds."
-       REFERENCE
-               "RFC-1035."
-       SYNTAX  Gauge32
-
-
-   DnsOpCode ::= TEXTUAL-CONVENTION
-       STATUS  current
-       DESCRIPTION
-               "This textual convention is used to represent the DNS
-               OPCODE values used in the header section of DNS
-               messages.  Existing standard OPCODE values are listed in
-               the DNS specifications."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       SYNTAX  INTEGER (0..15)
-
-   DnsRespCode ::= TEXTUAL-CONVENTION
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the DNS RCODE value
-               in DNS response messages.  Existing standard RCODE
-               values are listed in the DNS specifications."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       SYNTAX  INTEGER (0..15)
-
-
-
-
-
-
-
-Austein & Saperia                                               [Page 8]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   -- Server Configuration Group
-
-   dnsServConfigImplementIdent OBJECT-TYPE
-       SYNTAX      DisplayString
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "The implementation identification string for the DNS
-               server software in use on the system, for example;
-               `FNS-2.1'"
-       ::= { dnsServConfig 1 }
-
-   dnsServConfigRecurs  OBJECT-TYPE
-       SYNTAX      INTEGER { available(1),
-                             restricted(2),
-                             unavailable(3) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "This represents the recursion services offered by this
-               name server.  The values that can be read or written
-               are:
-
-               available(1) - performs recursion on requests from
-               clients.
-
-               restricted(2) - recursion is performed on requests only
-               from certain clients, for example; clients on an access
-               control list.
-
-               unavailable(3) - recursion is not available."
-        ::= { dnsServConfig 2 }
-
-   dnsServConfigUpTime OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "If the server has a persistent state (e.g., a process),
-               this value will be the time elapsed since it started.
-               For software without persistant state, this value will
-               be zero."
-       ::= { dnsServConfig 3 }
-
-   dnsServConfigResetTime OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-
-
-
-Austein & Saperia                                               [Page 9]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       DESCRIPTION
-               "If the server has a persistent state (e.g., a process)
-               and supports a `reset' operation (e.g., can be told to
-               re-read configuration files), this value will be the
-               time elapsed since the last time the name server was
-               `reset.'  For software that does not have persistence or
-               does not support a `reset' operation, this value will be
-               zero."
-       ::= { dnsServConfig 4 }
-
-   dnsServConfigReset OBJECT-TYPE
-       SYNTAX      INTEGER { other(1),
-                             reset(2),
-                             initializing(3),
-                             running(4) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status/action object to reinitialize any persistant name
-               server state.  When set to reset(2), any persistant
-               name server state (such as a process) is reinitialized as
-               if the name server had just been started.  This value
-               will never be returned by a read operation.  When read,
-               one of the following values will be returned:
-                   other(1) - server in some unknown state;
-                   initializing(3) - server (re)initializing;
-                   running(4) - server currently running."
-       ::= { dnsServConfig 5 }
-
-
-   -- Server Counter Group
-
-   dnsServCounterAuthAns OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries which were authoritatively answered."
-       ::= { dnsServCounter 2 }
-
-   dnsServCounterAuthNoNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries for which `authoritative no such name'
-               responses were made."
-       ::= { dnsServCounter 3 }
-
-
-
-Austein & Saperia                                              [Page 10]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServCounterAuthNoDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries for which `authoritative no such data'
-               (empty answer) responses were made."
-       ::= { dnsServCounter 4 }
-
-   dnsServCounterNonAuthDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries which were non-authoritatively
-               answered (cached data)."
-       ::= { dnsServCounter 5 }
-
-   dnsServCounterNonAuthNoDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries which were non-authoritatively
-               answered with no data (empty answer)."
-       ::= { dnsServCounter 6 }
-
-   dnsServCounterReferrals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests that were referred to other servers."
-       ::= { dnsServCounter 7 }
-
-   dnsServCounterErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed that were
-               answered with errors (RCODE values other than 0 and 3)."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsServCounter 8 }
-
-   dnsServCounterRelNames OBJECT-TYPE
-       SYNTAX      Counter32
-
-
-
-Austein & Saperia                                              [Page 11]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received by the server for names that
-               are only 1 label long (text form - no internal dots)."
-       ::= { dnsServCounter 9 }
-
-   dnsServCounterReqRefusals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of DNS requests refused by the server."
-       ::= { dnsServCounter 10 }
-
-   dnsServCounterReqUnparses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received which were unparseable."
-       ::= { dnsServCounter 11 }
-
-   dnsServCounterOtherErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests which were aborted for other (local)
-               server errors."
-       ::= { dnsServCounter 12 }
-
-   -- DNS Server Counter Table
-
-   dnsServCounterTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsServCounterEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Counter information broken down by DNS class and type."
-       ::= { dnsServCounter 13 }
-
-   dnsServCounterEntry OBJECT-TYPE
-       SYNTAX      DnsServCounterEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "This table contains count information for each DNS class
-
-
-
-Austein & Saperia                                              [Page 12]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-               and type value known to the server.  The index allows
-               management software to to create indices to the table to
-               get the specific information desired, e.g., number of
-               queries over UDP for records with type value `A' which
-               came to this server.  In order to prevent an
-               uncontrolled expansion of rows in the table; if
-               dnsServCounterRequests is 0 and dnsServCounterResponses
-               is 0, then the row does not exist and `no such' is
-               returned when the agent is queried for such instances."
-       INDEX     { dnsServCounterOpCode,
-                   dnsServCounterQClass,
-                   dnsServCounterQType,
-                   dnsServCounterTransport }
-       ::= { dnsServCounterTable 1 }
-
-   DnsServCounterEntry ::=
-       SEQUENCE {
-           dnsServCounterOpCode
-               DnsOpCode,
-           dnsServCounterQClass
-               DnsClass,
-           dnsServCounterQType
-               DnsType,
-           dnsServCounterTransport
-               INTEGER,
-           dnsServCounterRequests
-               Counter32,
-           dnsServCounterResponses
-               Counter32
-           }
-
-   dnsServCounterOpCode OBJECT-TYPE
-       SYNTAX      DnsOpCode
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The DNS OPCODE being counted in this row of the table."
-       ::= { dnsServCounterEntry 1 }
-
-   dnsServCounterQClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The class of record being counted in this row of the
-               table."
-       ::= { dnsServCounterEntry 2 }
-
-
-
-
-Austein & Saperia                                              [Page 13]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServCounterQType OBJECT-TYPE
-       SYNTAX      DnsType
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The type of record which is being counted in this row in
-               the table."
-       ::= { dnsServCounterEntry 3 }
-
-   dnsServCounterTransport OBJECT-TYPE
-       SYNTAX      INTEGER { udp(1), tcp(2), other(3) }
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "A value of udp(1) indicates that the queries reported on
-               this row were sent using UDP.
-
-               A value of tcp(2) indicates that the queries reported on
-               this row were sent using TCP.
-
-               A value of other(3) indicates that the queries reported
-               on this row were sent using a transport that was neither
-               TCP nor UDP."
-       ::= { dnsServCounterEntry 4 }
-
-   dnsServCounterRequests OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests (queries) that have been recorded in
-               this row of the table."
-       ::= { dnsServCounterEntry 5 }
-
-   dnsServCounterResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses made by the server since
-               initialization for the kind of query identified on this
-               row of the table."
-       ::= { dnsServCounterEntry 6 }
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 14]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   -- Server Optional Counter Group
-
-   -- The Server Optional Counter Group is intended for those systems
-   -- which make distinctions between the different sources of the DNS
-   -- queries as defined below.
-   --
-   -- Objects in this group are implemented on servers which distinguish
-   -- between queries which originate from the same host as the server,
-   -- queries from one of an arbitrary group of hosts that are on an
-   -- access list defined by the server, and queries from hosts that do
-   -- not fit either of these descriptions.
-   --
-   -- The objects found in the Server Counter group are totals.  Thus if
-   -- one wanted to identify, for example, the number of queries from
-   -- `remote' hosts which have been given authoritative answers, one
-   -- would subtract the current values of ServOptCounterFriendsAuthAns
-   -- and ServOptCounterSelfAuthAns from servCounterAuthAns.
-   --
-   -- The purpose of these distinctions is to allow for implementations
-   -- to group queries and responses on this basis.  One way in which
-   -- servers may make these distinctions is by looking at the source IP
-   -- address of the DNS query.  If the source of the query is `your
-   -- own' then the query should be counted as `yourself' (local host).
-   -- If the source of the query matches an `access list,' the query
-   -- came from a friend.  What constitutes an `access list' is
-   -- implementation dependent and could be as simple as a rule that all
-   -- hosts on the same IP network as the DNS server are classed
-   -- `friends.'
-   --
-   -- In order to avoid double counting, the following rules apply:
-   --
-   -- 1. No host is in more than one of the three groups defined above.
-   --
-   -- 2. All queries from the local host are always counted in the
-   --    `yourself' group regardless of what the access list, if any,
-   --    says.
-   --
-   -- 3. The access list should not define `your friends' in such a way
-   --    that it includes all hosts.   That is, not everybody is your
-   --    `friend.'
-
-   dnsServOptCounterSelfAuthAns OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which
-
-
-
-Austein & Saperia                                              [Page 15]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-               there has been an authoritative answer."
-       ::= { dnsServOptCounter 1 }
-
-   dnsServOptCounterSelfAuthNoNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which
-               there has been an authoritative no such name answer
-               given."
-       ::= { dnsServOptCounter 2 }
-
-   dnsServOptCounterSelfAuthNoDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which
-               there has been an authoritative no such data answer
-               (empty answer) made."
-       ::= { dnsServOptCounter 3 }
-
-   dnsServOptCounterSelfNonAuthDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which a
-               non-authoritative answer (cached data) was made."
-       ::= { dnsServOptCounter 4 }
-
-   dnsServOptCounterSelfNonAuthNoDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which a
-               `non-authoritative, no such data' response was made
-               (empty answer)."
-       ::= { dnsServOptCounter 5 }
-
-   dnsServOptCounterSelfReferrals OBJECT-TYPE
-       SYNTAX      Counter32
-
-
-
-Austein & Saperia                                              [Page 16]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries the server has processed which
-               originated from a resolver on the same host and were
-               referred to other servers."
-       ::= { dnsServOptCounter 6 }
-
-   dnsServOptCounterSelfErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host which have
-               been answered with errors (RCODEs other than 0 and 3)."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsServOptCounter 7 }
-
-   dnsServOptCounterSelfRelNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received for names that are only 1
-               label long (text form - no internal dots) the server has
-               processed which originated from a resolver on the same
-               host."
-       ::= { dnsServOptCounter 8 }
-
-   dnsServOptCounterSelfReqRefusals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of DNS requests refused by the server which
-               originated from a resolver on the same host."
-       ::= { dnsServOptCounter 9 }
-
-   dnsServOptCounterSelfReqUnparses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received which were unparseable and
-               which originated from a resolver on the same host."
-       ::= { dnsServOptCounter 10 }
-
-
-
-Austein & Saperia                                              [Page 17]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServOptCounterSelfOtherErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests which were aborted for other (local)
-               server errors and which originated on the same host."
-       ::= { dnsServOptCounter 11 }
-
-   dnsServOptCounterFriendsAuthAns OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends which were
-               authoritatively answered.  The definition of friends is
-               a locally defined matter."
-       ::= { dnsServOptCounter 12 }
-
-   dnsServOptCounterFriendsAuthNoNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends, for which
-               authoritative `no such name' responses were made.  The
-               definition of friends is a locally defined matter."
-       ::= { dnsServOptCounter 13 }
-
-   dnsServOptCounterFriendsAuthNoDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends for which
-               authoritative no such data (empty answer) responses were
-               made.  The definition of friends is a locally defined
-               matter."
-       ::= { dnsServOptCounter 14 }
-
-   dnsServOptCounterFriendsNonAuthDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends which were
-               non-authoritatively answered (cached data). The
-               definition of friends is a locally defined matter."
-
-
-
-Austein & Saperia                                              [Page 18]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       ::= { dnsServOptCounter 15 }
-
-   dnsServOptCounterFriendsNonAuthNoDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends which were
-               non-authoritatively answered with no such data (empty
-               answer)."
-       ::= { dnsServOptCounter 16 }
-
-   dnsServOptCounterFriendsReferrals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests which originated from friends that
-               were referred to other servers.  The definition of
-               friends is a locally defined matter."
-       ::= { dnsServOptCounter 17 }
-
-   dnsServOptCounterFriendsErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from friends and were answered with errors
-               (RCODE values other than 0 and 3).  The definition of
-               friends is a locally defined matter."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsServOptCounter 18 }
-
-   dnsServOptCounterFriendsRelNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received for names from friends that
-               are only 1 label long (text form - no internal dots) the
-               server has processed."
-       ::= { dnsServOptCounter 19 }
-
-   dnsServOptCounterFriendsReqRefusals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-
-
-
-Austein & Saperia                                              [Page 19]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "Number of DNS requests refused by the server which were
-               received from `friends'."
-       ::= { dnsServOptCounter 20 }
-
-   dnsServOptCounterFriendsReqUnparses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received which were unparseable and
-               which originated from `friends'."
-       ::= { dnsServOptCounter 21 }
-
-   dnsServOptCounterFriendsOtherErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests which were aborted for other (local)
-               server errors and which originated from `friends'."
-       ::= { dnsServOptCounter 22 }
-
-
-   -- Server Zone Group
-
-   -- DNS Management Zone Configuration Table
-
-   -- This table contains zone configuration information.
-
-   dnsServZoneTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsServZoneEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of zones for which this name server provides
-               information.  Each of the zones may be loaded from stable
-               storage via an implementation-specific mechanism or may
-               be obtained from another name server via a zone transfer.
-
-               If name server doesn't load any zones, this table is
-               empty."
-       ::= { dnsServZone 1 }
-
-   dnsServZoneEntry OBJECT-TYPE
-       SYNTAX      DnsServZoneEntry
-       MAX-ACCESS  not-accessible
-
-
-
-Austein & Saperia                                              [Page 20]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "An entry in the name server zone table.  New rows may be
-               added either via SNMP or by the name server itself."
-       INDEX     { dnsServZoneName,
-                   dnsServZoneClass }
-       ::= { dnsServZoneTable 1 }
-
-   DnsServZoneEntry ::=
-       SEQUENCE {
-           dnsServZoneName
-               DnsNameAsIndex,
-           dnsServZoneClass
-               DnsClass,
-           dnsServZoneLastReloadSuccess
-               DnsTime,
-           dnsServZoneLastReloadAttempt
-               DnsTime,
-           dnsServZoneLastSourceAttempt
-               IpAddress,
-           dnsServZoneStatus
-               RowStatus,
-           dnsServZoneSerial
-               Counter32,
-           dnsServZoneCurrent
-               TruthValue,
-           dnsServZoneLastSourceSuccess
-               IpAddress
-       }
-
-   dnsServZoneName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS name of the zone described by this row of the table.
-               This is the owner name of the SOA RR that defines the
-               top of the zone. This is name is in uppercase:
-               characters 'a' through 'z' are mapped to 'A' through 'Z'
-               in order to make the lexical ordering useful."
-       ::= { dnsServZoneEntry 1 }
-
-   dnsServZoneClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS class of the RRs in this zone."
-
-
-
-Austein & Saperia                                              [Page 21]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       ::= { dnsServZoneEntry 2 }
-
-   dnsServZoneLastReloadSuccess OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Elapsed time in seconds since last successful reload of
-               this zone."
-       ::= { dnsServZoneEntry 3 }
-
-   dnsServZoneLastReloadAttempt OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Elapsed time in seconds since last attempted reload of
-               this zone."
-       ::= { dnsServZoneEntry 4 }
-
-   dnsServZoneLastSourceAttempt OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "IP address of host from which most recent zone transfer
-               of this zone was attempted.  This value should match the
-               value of dnsServZoneSourceSuccess if the attempt was
-               succcessful.  If zone transfer has not been attempted
-               within the memory of this name server, this value should
-               be 0.0.0.0."
-       ::= { dnsServZoneEntry 5 }
-
-   dnsServZoneStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "The status of the information represented in this row of
-               the table."
-       ::= { dnsServZoneEntry 6 }
-
-   dnsServZoneSerial OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Zone serial number (from the SOA RR) of the zone
-
-
-
-Austein & Saperia                                              [Page 22]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-               represented by this row of the table.  If the zone has
-               not been successfully loaded within the memory of this
-               name server, the value of this variable is zero."
-       ::= { dnsServZoneEntry 7 }
-
-   dnsServZoneCurrent OBJECT-TYPE
-       SYNTAX      TruthValue
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Whether the server's copy of the zone represented by
-               this row of the table is currently valid.  If the zone
-               has never been successfully loaded or has expired since
-               it was last succesfully loaded, this variable will have
-               the value false(2), otherwise this variable will have
-               the value true(1)."
-       ::= { dnsServZoneEntry 8 }
-
-   dnsServZoneLastSourceSuccess OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "IP address of host which was the source of the most
-               recent successful zone transfer for this zone.  If
-               unknown (e.g., zone has never been successfully
-               transfered) or irrelevant (e.g., zone was loaded from
-               stable storage), this value should be 0.0.0.0."
-       ::= { dnsServZoneEntry 9 }
-
-   -- DNS Zone Source Table
-
-   dnsServZoneSrcTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsServZoneSrcEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "This table is a list of IP addresses from which the
-               server will attempt to load zone information using DNS
-               zone transfer operations.  A reload may occur due to SNMP
-               operations that create a row in dnsServZoneTable or a
-               SET to object dnsServZoneReload.  This table is only
-               used when the zone is loaded via zone transfer."
-       ::= { dnsServZone 2 }
-
-   dnsServZoneSrcEntry OBJECT-TYPE
-       SYNTAX      DnsServZoneSrcEntry
-       MAX-ACCESS  not-accessible
-
-
-
-Austein & Saperia                                              [Page 23]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "An entry in the name server zone source table."
-       INDEX     { dnsServZoneSrcName,
-                   dnsServZoneSrcClass,
-                   dnsServZoneSrcAddr }
-       ::= { dnsServZoneSrcTable 1 }
-
-   DnsServZoneSrcEntry ::=
-       SEQUENCE {
-           dnsServZoneSrcName
-               DnsNameAsIndex,
-           dnsServZoneSrcClass
-               DnsClass,
-           dnsServZoneSrcAddr
-               IpAddress,
-           dnsServZoneSrcStatus
-               RowStatus
-       }
-
-   dnsServZoneSrcName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS name of the zone to which this entry applies."
-       ::= { dnsServZoneSrcEntry 1 }
-
-   dnsServZoneSrcClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS class of zone to which this entry applies."
-       ::= { dnsServZoneSrcEntry 2 }
-
-   dnsServZoneSrcAddr OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "IP address of name server host from which this zone
-               might be obtainable."
-       ::= { dnsServZoneSrcEntry 3 }
-
-   dnsServZoneSrcStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-create
-
-
-
-Austein & Saperia                                              [Page 24]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "The status of the information represented in this row of
-               the table."
-       ::= { dnsServZoneSrcEntry 4 }
-
-
-   -- SNMPv2 groups.
-
-   dnsServMIBGroups        OBJECT IDENTIFIER ::= { dnsServMIB 2 }
-
-   dnsServConfigGroup OBJECT-GROUP
-       OBJECTS   { dnsServConfigImplementIdent,
-                   dnsServConfigRecurs,
-                   dnsServConfigUpTime,
-                   dnsServConfigResetTime,
-                   dnsServConfigReset }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing basic configuration
-               control of a DNS name server."
-       ::= { dnsServMIBGroups 1 }
-
-   dnsServCounterGroup OBJECT-GROUP
-       OBJECTS   { dnsServCounterAuthAns,
-                   dnsServCounterAuthNoNames,
-                   dnsServCounterAuthNoDataResps,
-                   dnsServCounterNonAuthDatas,
-                   dnsServCounterNonAuthNoDatas,
-                   dnsServCounterReferrals,
-                   dnsServCounterErrors,
-                   dnsServCounterRelNames,
-                   dnsServCounterReqRefusals,
-                   dnsServCounterReqUnparses,
-                   dnsServCounterOtherErrors,
-                   dnsServCounterOpCode,
-                   dnsServCounterQClass,
-                   dnsServCounterQType,
-                   dnsServCounterTransport,
-                   dnsServCounterRequests,
-                   dnsServCounterResponses }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing basic instrumentation
-               of a DNS name server."
-       ::= { dnsServMIBGroups 2 }
-
-
-
-
-
-Austein & Saperia                                              [Page 25]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServOptCounterGroup OBJECT-GROUP
-       OBJECTS   { dnsServOptCounterSelfAuthAns,
-                   dnsServOptCounterSelfAuthNoNames,
-                   dnsServOptCounterSelfAuthNoDataResps,
-                   dnsServOptCounterSelfNonAuthDatas,
-                   dnsServOptCounterSelfNonAuthNoDatas,
-                   dnsServOptCounterSelfReferrals,
-                   dnsServOptCounterSelfErrors,
-                   dnsServOptCounterSelfRelNames,
-                   dnsServOptCounterSelfReqRefusals,
-                   dnsServOptCounterSelfReqUnparses,
-                   dnsServOptCounterSelfOtherErrors,
-                   dnsServOptCounterFriendsAuthAns,
-                   dnsServOptCounterFriendsAuthNoNames,
-                   dnsServOptCounterFriendsAuthNoDataResps,
-                   dnsServOptCounterFriendsNonAuthDatas,
-                   dnsServOptCounterFriendsNonAuthNoDatas,
-                   dnsServOptCounterFriendsReferrals,
-                   dnsServOptCounterFriendsErrors,
-                   dnsServOptCounterFriendsRelNames,
-                   dnsServOptCounterFriendsReqRefusals,
-                   dnsServOptCounterFriendsReqUnparses,
-                   dnsServOptCounterFriendsOtherErrors }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing extended
-               instrumentation of a DNS name server."
-       ::= { dnsServMIBGroups 3 }
-
-   dnsServZoneGroup OBJECT-GROUP
-       OBJECTS   { dnsServZoneName,
-                   dnsServZoneClass,
-                   dnsServZoneLastReloadSuccess,
-                   dnsServZoneLastReloadAttempt,
-                   dnsServZoneLastSourceAttempt,
-                   dnsServZoneLastSourceSuccess,
-                   dnsServZoneStatus,
-                   dnsServZoneSerial,
-                   dnsServZoneCurrent,
-                   dnsServZoneSrcName,
-                   dnsServZoneSrcClass,
-                   dnsServZoneSrcAddr,
-                   dnsServZoneSrcStatus }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing configuration control
-               of a DNS name server which loads authoritative zones."
-       ::= { dnsServMIBGroups 4 }
-
-
-
-Austein & Saperia                                              [Page 26]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   -- Compliances.
-
-   dnsServMIBCompliances OBJECT IDENTIFIER ::= { dnsServMIB 3 }
-
-   dnsServMIBCompliance MODULE-COMPLIANCE
-       STATUS      current
-       DESCRIPTION
-               "The compliance statement for agents implementing the DNS
-               name server MIB extensions."
-       MODULE -- This MIB module
-           MANDATORY-GROUPS { dnsServConfigGroup, dnsServCounterGroup }
-           GROUP   dnsServOptCounterGroup
-           DESCRIPTION
-               "The server optional counter group is unconditionally
-               optional."
-           GROUP   dnsServZoneGroup
-           DESCRIPTION
-               "The server zone group is mandatory for any name server
-               that acts as an authoritative server for any DNS zone."
-           OBJECT  dnsServConfigRecurs
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsServConfigReset
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-       ::= { dnsServMIBCompliances 1 }
-
-   END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 27]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-5.  Acknowledgements
-
-   This document is the result of work undertaken the by DNS working
-   group.  The authors would particularly like to thank the following
-   people for their contributions to this document: Philip Almquist,
-   Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins
-   (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM).
-
-6.  References
-
-   [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
-       13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names -- Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-   [3] Braden, R., Editor, "Requirements for Internet Hosts --
-       Application and Support, STD 3, RFC 1123, USC/Information
-       Sciences Institute, October 1989.
-
-   [4] Rose, M., and K. McCloghrie, "Structure and Identification of
-       Management Information for TCP/IP-based internets", STD 16, RFC
-       1155, Performance Systems International, Hughes LAN Systems, May
-       1990.
-
-   [5] McCloghrie, K., and M. Rose, "Management Information Base for
-       Network Management of TCP/IP-based internets", RFC 1156, Hughes
-       LAN Systems, Performance Systems International, May 1990.
-
-   [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
-       Network Management Protocol", STD 15, RFC 1157, SNMP Research,
-       Performance Systems International, Performance Systems
-       International, MIT Laboratory for Computer Science, May 1990.
-
-   [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
-       STD 16, RFC 1212, Performance Systems International, Hughes LAN
-       Systems, March 1991.
-
-   [8] McCloghrie, K., and M. Rose, Editors, "Management Information
-       Base for Network Management of TCP/IP-based internets: MIB-II",
-       STD 17, RFC 1213, Hughes LAN Systems, Performance Systems
-       International, March 1991.
-
-   [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
-       of Management Information for version 2 of the Simple Network
-       Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
-       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-
-
-
-Austein & Saperia                                              [Page 28]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       University, April 1993.
-
-  [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
-       Conventions for version 2 of the the Simple Network Management
-       Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
-       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
-       "Conformance Statements for version 2 of the the Simple Network
-       Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc.,
-       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [12] Galvin, J., and K. McCloghrie, "Administrative Model for version
-       2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
-       Trusted Information Systems, Hughes LAN Systems, April 1993.
-
-  [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
-       Operations for version 2 of the Simple Network Management
-       Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
-       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [14] "Information processing systems - Open Systems Interconnection -
-       Specification of Abstract Syntax Notation One (ASN.1)",
-       International Organization for Standardization, International
-       Standard 8824, December 1987.
-
-7.  Security Considerations
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 29]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-8.  Authors' Addresses
-
-   Rob Austein
-   Epilogue Technology Corporation
-   268 Main Street, Suite 283
-   North Reading, MA 01864
-   USA
-
-   Phone: +1-617-245-0804
-   Fax:   +1-617-245-8122
-   EMail: sra@epilogue.com
-
-
-   Jon Saperia
-   Digital Equipment Corporation
-   110 Spit Brook Road
-   ZKO1-3/H18
-   Nashua, NH 03062-2698
-   USA
-
-   Phone: +1-603-881-0480
-   Fax:   +1-603-881-0120
-   EMail: saperia@zko.dec.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 30]
-
diff --git a/doc/rfc/rfc1612.txt b/doc/rfc/rfc1612.txt
deleted file mode 100644
index 4ef23b0c..00000000
--- a/doc/rfc/rfc1612.txt
+++ /dev/null
@@ -1,1795 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 1612               Epilogue Technology Corporation
-Category: Standards Track                                     J. Saperia
-                                           Digital Equipment Corporation
-                                                                May 1994
-
-
-                      DNS Resolver MIB Extensions
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Table of Contents
-
-   1. Introduction ..............................................    1
-   2. The SNMPv2 Network Management Framework ...................    2
-   2.1 Object Definitions .......................................    2
-   3. Overview ..................................................    2
-   3.1 Resolvers ................................................    3
-   3.2 Name Servers .............................................    3
-   3.3 Selected Objects .........................................    4
-   3.4 Textual Conventions ......................................    4
-   4. Definitions ...............................................    5
-   5. Acknowledgements ..........................................   30
-   6. References ................................................   30
-   7. Security Considerations ...................................   32
-   8. Authors' Addresses ........................................   32
-
-1.  Introduction
-
-   This memo defines a portion of the Management Information Base (MIB)
-   for use with network management protocols in the Internet community.
-   In particular, it describes a set of extensions which instrument DNS
-   resolver functions.  This memo was produced by the DNS working group.
-
-   With the adoption of the Internet-standard Network Management
-   Framework [4,5,6,7], and with a large number of vendor
-   implementations of these standards in commercially available
-   products, it became possible to provide a higher level of effective
-   network management in TCP/IP-based internets than was previously
-   available.  With the growth in the use of these standards, it has
-   become possible to consider the management of other elements of the
-   infrastructure beyond the basic TCP/IP protocols.  A key element of
-
-
-
-Austein & Saperia                                               [Page 1]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   the TCP/IP infrastructure is the DNS.
-
-   Up to this point there has been no mechanism to integrate the
-   management of the DNS with SNMP-based managers.  This memo provides
-   the mechanisms by which IP-based management stations can effectively
-   manage DNS resolver software in an integrated fashion.
-
-   We have defined DNS MIB objects to be used in conjunction with the
-   Internet MIB to allow access to and control of DNS resolver software
-   via SNMP by the Internet community.
-
-2.  The SNMPv2 Network Management Framework
-
-   The SNMPv2 Network Management Framework consists of four major
-   components.  They are:
-
-      o  RFC 1442 which defines the SMI, the mechanisms used for
-         describing and naming objects for the purpose of management.
-
-      o  STD 17, RFC 1213 defines MIB-II, the core set of managed
-         objects for the Internet suite of protocols.
-
-      o  RFC 1445 which defines the administrative and other
-         architectural aspects of the framework.
-
-      o  RFC 1448 which defines the protocol used for network access to
-         managed objects.
-
-   The Framework permits new objects to be defined for the purpose of
-   experimentation and evaluation.
-
-2.1.  Object Definitions
-
-   Managed objects are accessed via a virtual information store, termed
-   the Management Information Base or MIB.  Objects in the MIB are
-   defined using the subset of Abstract Syntax Notation One (ASN.1)
-   defined in the SMI.  In particular, each object object type is named
-   by an OBJECT IDENTIFIER, an administratively assigned name.  The
-   object type together with an object instance serves to uniquely
-   identify a specific instantiation of the object.  For human
-   convenience, we often use a textual string, termed the descriptor, to
-   refer to the object type.
-
-3.  Overview
-
-   In theory, the DNS world is pretty simple.  There are two kinds of
-   entities: resolvers and name servers.  Resolvers ask questions.  Name
-   servers answer them.  The real world, however, is not so simple.
-
-
-
-Austein & Saperia                                               [Page 2]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   Implementors have made widely differing choices about how to divide
-   DNS functions between resolvers and servers.  They have also
-   constructed various sorts of exotic hybrids.  The most difficult task
-   in defining this MIB was to accommodate this wide range of entities
-   without having to come up with a separate MIB for each.
-
-   We divided up the various DNS functions into two, non-overlapping
-   classes, called "resolver functions" and "name server functions."  A
-   DNS entity that performs what we define as resolver functions
-   contains a resolver, and therefore must implement the MIB groups
-   required of all resolvers which are defined in this module.  Some
-   resolvers also implement "optional" functions such as a cache, in
-   which case they must also implement the cache group contained in this
-   MIB.  A DNS entity which implements name server functions is
-   considered to be a name server, and must implement the MIB groups
-   required for name servers which are defined in a separate module.  If
-   the same piece of software performs both resolver and server
-   functions, we imagine that it contains both a resolver and a server
-   and would thus implement both the DNS Server and DNS Resolver MIBs.
-
-3.1.  Resolvers
-
-   In our model, a resolver is a program (or piece thereof) which
-   obtains resource records from servers.  Normally it does so at the
-   behest of an application, but may also do so as part of its own
-   operation.  A resolver sends DNS protocol queries and receives DNS
-   protocol replies.  A resolver neither receives queries nor sends
-   replies.  A full service resolver is one that knows how to resolve
-   queries: it obtains the needed resource records by contacting a
-   server authoritative for the records desired.  A stub resolver does
-   not know how to resolve queries: it sends all queries to a local name
-   server, setting the "recursion desired" flag to indicate that it
-   hopes that the name server will be willing to resolve the query.  A
-   resolver may (optionally) have a cache for remembering previously
-   acquired resource records.  It may also have a negative cache for
-   remembering names or data that have been determined not to exist.
-
-3.2.  Name Servers
-
-   A name server is a program (or piece thereof) that provides resource
-   records to resolvers.  All references in this document to "a name
-   server" imply "the name server's role"; in some cases the name
-   server's role and the resolver's role might be combined into a single
-   program.  A name server receives DNS protocol queries and sends DNS
-   protocol replies.  A name server neither sends queries nor receives
-   replies.  As a consequence, name servers do not have caches.
-   Normally, a name server would expect to receive only those queries to
-   which it could respond with authoritative information.  However, if a
-
-
-
-Austein & Saperia                                               [Page 3]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   name server receives a query that it cannot respond to with purely
-   authoritative information, it may choose to try to obtain the
-   necessary additional information from a resolver which may or may not
-   be a separate process.
-
-3.3.  Selected Objects
-
-   Many of the objects included in this memo have been created from
-   information contained in the DNS specifications [1,2], as amended and
-   clarified by subsequent host requirements documents [3].  Other
-   objects have been created based on experience with existing DNS
-   management tools, expected operational needs, the statistics
-   generated by existing DNS implementations, and the configuration
-   files used by existing DNS implementations.  These objects have been
-   ordered into groups as follows:
-
-         o  Resolver Configuration Group
-
-         o  Resolver Counter Group
-
-         o  Resolver Lame Delegation Group
-
-         o  Resolver Cache Group
-
-         o  Resolver Negative Cache Group
-
-         o  Resolver Optional Counter Group
-
-   This information has been converted into a standard form using the
-   SNMPv2 SMI defined in [9].  For the most part, the descriptions are
-   influenced by the DNS related RFCs noted above.  For example, the
-   descriptions for counters used for the various types of queries of
-   DNS records are influenced by the definitions used for the various
-   record types found in [2].
-
-3.4.  Textual Conventions
-
-   Several conceptual data types have been introduced as a textual
-   conventions in the DNS Server MIB document and have been imported
-   into this MIB module.  These additions will facilitate the common
-   understanding of information used by the DNS.  No changes to the SMI
-   or the SNMP are necessary to support these conventions.
-
-   Readers familiar with MIBs designed to manage entities in the lower
-   layers of the Internet protocol suite may be surprised at the number
-   of non-enumerated integers used in this MIB to represent values such
-   as DNS RR class and type numbers.  The reason for this choice is
-   simple: the DNS itself is designed as an extensible protocol,
-
-
-
-Austein & Saperia                                               [Page 4]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   allowing new classes and types of resource records to be added to the
-   protocol without recoding the core DNS software.  Using non-
-   enumerated integers to represent these data types in this MIB allows
-   the MIB to accommodate these changes as well.
-
-4.  Definitions
-
-   DNS-RESOLVER-MIB DEFINITIONS ::= BEGIN
-
-   IMPORTS
-       MODULE-IDENTITY, OBJECT-TYPE, IpAddress, Counter32, Integer32
-           FROM SNMPv2-SMI
-       TEXTUAL-CONVENTION, RowStatus, DisplayString
-           FROM SNMPv2-TC
-       MODULE-COMPLIANCE, OBJECT-GROUP
-           FROM SNMPv2-CONF
-       dns, DnsName, DnsNameAsIndex, DnsClass, DnsType, DnsQClass,
-       DnsQType, DnsTime, DnsOpCode, DnsRespCode
-           FROM DNS-SERVER-MIB;
-
-   -- DNS Resolver MIB
-
-   dnsResMIB MODULE-IDENTITY
-       LAST-UPDATED "9401282250Z"
-       ORGANIZATION "IETF DNS Working Group"
-       CONTACT-INFO
-               "       Rob Austein
-               Postal: Epilogue Technology Corporation
-                       268 Main Street, Suite 283
-                       North Reading, MA 10864
-                       US
-                  Tel: +1 617 245 0804
-                  Fax: +1 617 245 8122
-               E-Mail: sra@epilogue.com
-
-                       Jon Saperia
-               Postal: Digital Equipment Corporation
-                       110 Spit Brook Road
-                       ZKO1-3/H18
-                       Nashua, NH 03062-2698
-                       US
-                  Tel: +1 603 881 0480
-                  Fax: +1 603 881 0120
-               E-mail: saperia@zko.dec.com"
-       DESCRIPTION
-               "The MIB module for entities implementing the client
-               (resolver) side of the Domain Name System (DNS)
-               protocol."
-
-
-
-Austein & Saperia                                               [Page 5]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       ::= { dns 2 }
-
-   dnsResMIBObjects        OBJECT IDENTIFIER ::= { dnsResMIB 1 }
-
-   -- (Old-style) groups in the DNS resolver MIB.
-
-   dnsResConfig            OBJECT IDENTIFIER ::= { dnsResMIBObjects 1 }
-   dnsResCounter           OBJECT IDENTIFIER ::= { dnsResMIBObjects 2 }
-   dnsResLameDelegation    OBJECT IDENTIFIER ::= { dnsResMIBObjects 3 }
-   dnsResCache             OBJECT IDENTIFIER ::= { dnsResMIBObjects 4 }
-   dnsResNCache            OBJECT IDENTIFIER ::= { dnsResMIBObjects 5 }
-   dnsResOptCounter        OBJECT IDENTIFIER ::= { dnsResMIBObjects 6 }
-
-
-   -- Resolver Configuration Group
-
-   dnsResConfigImplementIdent OBJECT-TYPE
-       SYNTAX      DisplayString
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "The implementation identification string for the
-               resolver software in use on the system, for example;
-               `RES-2.1'"
-       ::= { dnsResConfig 1 }
-
-   dnsResConfigService OBJECT-TYPE
-       SYNTAX      INTEGER { recursiveOnly(1),
-                             iterativeOnly(2),
-                             recursiveAndIterative(3) }
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Kind of DNS resolution service provided:
-
-               recursiveOnly(1) indicates a stub resolver.
-
-               iterativeOnly(2) indicates a normal full service
-               resolver.
-
-               recursiveAndIterative(3) indicates a full-service
-               resolver which performs a mix of recursive and iterative
-               queries."
-        ::= { dnsResConfig 2 }
-
-   dnsResConfigMaxCnames OBJECT-TYPE
-       SYNTAX      INTEGER (0..2147483647)
-       MAX-ACCESS  read-write
-
-
-
-Austein & Saperia                                               [Page 6]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "Limit on how many CNAMEs the resolver should allow
-               before deciding that there's a CNAME loop.  Zero means
-               that resolver has no explicit CNAME limit."
-       REFERENCE
-               "RFC-1035 section 7.1."
-       ::= { dnsResConfig 3 }
-
-   -- DNS Resolver Safety Belt Table
-
-   dnsResConfigSbeltTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResConfigSbeltEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of safety belt information used by the resolver
-               when it hasn't got any better idea of where to send a
-               query, such as when the resolver is booting or is a stub
-               resolver."
-       ::= { dnsResConfig 4 }
-
-   dnsResConfigSbeltEntry OBJECT-TYPE
-       SYNTAX      DnsResConfigSbeltEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "An entry in the resolver's Sbelt table.
-               Rows may be created or deleted at any time by the DNS
-               resolver and by SNMP SET requests.  Whether the values
-               changed via SNMP are saved in stable storage across
-               `reset' operations is implementation-specific."
-       INDEX     { dnsResConfigSbeltAddr,
-                   dnsResConfigSbeltSubTree,
-                   dnsResConfigSbeltClass }
-       ::= { dnsResConfigSbeltTable 1 }
-
-   DnsResConfigSbeltEntry ::=
-       SEQUENCE {
-           dnsResConfigSbeltAddr
-               IpAddress,
-           dnsResConfigSbeltName
-               DnsName,
-           dnsResConfigSbeltRecursion
-               INTEGER,
-           dnsResConfigSbeltPref
-               INTEGER,
-           dnsResConfigSbeltSubTree
-
-
-
-Austein & Saperia                                               [Page 7]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               DnsNameAsIndex,
-           dnsResConfigSbeltClass
-               DnsClass,
-           dnsResConfigSbeltStatus
-               RowStatus
-       }
-
-   dnsResConfigSbeltAddr OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The IP address of the Sbelt name server identified by
-               this row of the table."
-       ::= { dnsResConfigSbeltEntry 1 }
-
-   dnsResConfigSbeltName OBJECT-TYPE
-       SYNTAX      DnsName
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "The DNS name of a Sbelt nameserver identified by this
-               row of the table.  A zero-length string indicates that
-               the name is not known by the resolver."
-       ::= { dnsResConfigSbeltEntry 2 }
-
-   dnsResConfigSbeltRecursion OBJECT-TYPE
-       SYNTAX      INTEGER { iterative(1),
-                             recursive(2),
-                             recursiveAndIterative(3) }
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "Kind of queries resolver will be sending to the name
-               server identified in this row of the table:
-
-               iterative(1) indicates that resolver will be directing
-               iterative queries to this name server (RD bit turned
-               off).
-
-               recursive(2) indicates that resolver will be directing
-               recursive queries to this name server (RD bit turned
-               on).
-
-               recursiveAndIterative(3) indicates that the resolver
-               will be directing both recursive and iterative queries
-               to the server identified in this row of the table."
-        ::= { dnsResConfigSbeltEntry 3 }
-
-
-
-Austein & Saperia                                               [Page 8]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResConfigSbeltPref OBJECT-TYPE
-       SYNTAX      INTEGER (0..2147483647)
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "This value identifies the preference for the name server
-               identified in this row of the table.  The lower the
-               value, the more desirable the resolver considers this
-               server."
-        ::= { dnsResConfigSbeltEntry 4 }
-
-   dnsResConfigSbeltSubTree OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Queries sent to the name server identified by this row
-               of the table are limited to those for names in the name
-               subtree identified by this variable.  If no such
-               limitation applies, the value of this variable is the
-               name of the root domain (a DNS name consisting of a
-               single zero octet)."
-       ::= { dnsResConfigSbeltEntry 5 }
-
-   dnsResConfigSbeltClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The class of DNS queries that will be sent to the server
-               identified by this row of the table."
-       ::= { dnsResConfigSbeltEntry 6 }
-
-   dnsResConfigSbeltStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "Row status column for this row of the Sbelt table."
-       ::= { dnsResConfigSbeltEntry 7 }
-
-   dnsResConfigUpTime OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "If the resolver has a persistent state (e.g., a
-               process), this value will be the time elapsed since it
-
-
-
-Austein & Saperia                                               [Page 9]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               started.  For software without persistant state, this
-               value will be 0."
-       ::= { dnsResConfig 5 }
-
-   dnsResConfigResetTime OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "If the resolver has a persistent state (e.g., a process)
-               and supports a `reset' operation (e.g., can be told to
-               re-read configuration files), this value will be the
-               time elapsed since the last time the resolver was
-               `reset.'  For software that does not have persistence or
-               does not support a `reset' operation, this value will be
-               zero."
-       ::= { dnsResConfig 6 }
-
-   dnsResConfigReset OBJECT-TYPE
-       SYNTAX      INTEGER { other(1),
-                             reset(2),
-                             initializing(3),
-                             running(4) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status/action object to reinitialize any persistant
-               resolver state.  When set to reset(2), any persistant
-               resolver state (such as a process) is reinitialized as if
-               the resolver had just been started.  This value will
-               never be returned by a read operation.  When read, one of
-               the following values will be returned:
-                   other(1) - resolver in some unknown state;
-                   initializing(3) - resolver (re)initializing;
-                   running(4) - resolver currently running."
-       ::= { dnsResConfig 7 }
-
-
-   -- Resolver Counters Group
-
-   -- Resolver Counter Table
-
-   dnsResCounterByOpcodeTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResCounterByOpcodeEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of the current count of resolver queries and
-
-
-
-Austein & Saperia                                              [Page 10]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               answers."
-       ::= { dnsResCounter 3 }
-
-   dnsResCounterByOpcodeEntry OBJECT-TYPE
-       SYNTAX      DnsResCounterByOpcodeEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Entry in the resolver counter table.  Entries are
-               indexed by DNS OpCode."
-       INDEX     { dnsResCounterByOpcodeCode }
-       ::= { dnsResCounterByOpcodeTable 1 }
-
-   DnsResCounterByOpcodeEntry ::=
-       SEQUENCE {
-           dnsResCounterByOpcodeCode
-               DnsOpCode,
-           dnsResCounterByOpcodeQueries
-               Counter32,
-           dnsResCounterByOpcodeResponses
-               Counter32
-       }
-
-   dnsResCounterByOpcodeCode OBJECT-TYPE
-       SYNTAX      DnsOpCode
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The index to this table.  The OpCodes that have already
-               been defined are found in RFC-1035."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsResCounterByOpcodeEntry 1 }
-
-   dnsResCounterByOpcodeQueries OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Total number of queries that have sent out by the
-               resolver since initialization for the OpCode which is
-               the index to this row of the table."
-       ::= { dnsResCounterByOpcodeEntry 2 }
-
-   dnsResCounterByOpcodeResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-
-
-
-Austein & Saperia                                              [Page 11]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       DESCRIPTION
-               "Total number of responses that have been received by the
-               resolver since initialization for the OpCode which is
-               the index to this row of the table."
-       ::= { dnsResCounterByOpcodeEntry 3 }
-
-   -- Resolver Response Code Counter Table
-
-   dnsResCounterByRcodeTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResCounterByRcodeEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of the current count of responses to resolver
-               queries."
-       ::= { dnsResCounter 4 }
-
-   dnsResCounterByRcodeEntry OBJECT-TYPE
-       SYNTAX      DnsResCounterByRcodeEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Entry in the resolver response table.  Entries are
-               indexed by DNS response code."
-       INDEX     { dnsResCounterByRcodeCode }
-       ::= { dnsResCounterByRcodeTable 1 }
-
-   DnsResCounterByRcodeEntry ::=
-       SEQUENCE {
-           dnsResCounterByRcodeCode
-               DnsRespCode,
-           dnsResCounterByRcodeResponses
-               Counter32
-       }
-
-   dnsResCounterByRcodeCode OBJECT-TYPE
-       SYNTAX      DnsRespCode
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The index to this table.  The Response Codes that have
-               already been defined are found in RFC-1035."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsResCounterByRcodeEntry 1 }
-
-
-
-
-
-
-Austein & Saperia                                              [Page 12]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResCounterByRcodeResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses the resolver has received for the
-               response code value which identifies this row of the
-               table."
-       ::= { dnsResCounterByRcodeEntry 2 }
-
-   -- Additional DNS Resolver Counter Objects
-
-   dnsResCounterNonAuthDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests made by the resolver for which a
-               non-authoritative answer (cached data) was received."
-       ::= { dnsResCounter 5 }
-
-   dnsResCounterNonAuthNoDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests made by the resolver for which a
-               non-authoritative answer - no such data response (empty
-               answer) was received."
-       ::= { dnsResCounter 6 }
-
-   dnsResCounterMartians OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses received which were received from
-               servers that the resolver does not think it asked."
-       ::= { dnsResCounter 7 }
-
-   dnsResCounterRecdResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses received to all queries."
-       ::= { dnsResCounter 8 }
-
-
-
-
-Austein & Saperia                                              [Page 13]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResCounterUnparseResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses received which were unparseable."
-       ::= { dnsResCounter 9 }
-
-   dnsResCounterFallbacks OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of times the resolver had to fall back to its
-               seat belt information."
-       ::= { dnsResCounter 10 }
-
-
-   -- Lame Delegation Group
-
-   dnsResLameDelegationOverflows OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of times the resolver attempted to add an entry
-               to the Lame Delegation table but was unable to for some
-               reason such as space constraints."
-       ::= { dnsResLameDelegation 1 }
-
-   -- Lame Delegation Table
-
-   dnsResLameDelegationTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResLameDelegationEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of name servers returning lame delegations.
-
-               A lame delegation has occured when a parent zone
-               delegates authority for a child zone to a server that
-               appears not to think that it is authoritative for the
-               child zone in question."
-       ::= { dnsResLameDelegation 2 }
-
-   dnsResLameDelegationEntry OBJECT-TYPE
-       SYNTAX      DnsResLameDelegationEntry
-       MAX-ACCESS  not-accessible
-
-
-
-Austein & Saperia                                              [Page 14]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "Entry in lame delegation table.  Only the resolver may
-               create rows in this table.  SNMP SET requests may be used
-               to delete rows."
-       INDEX     { dnsResLameDelegationSource,
-                   dnsResLameDelegationName,
-                   dnsResLameDelegationClass }
-       ::= { dnsResLameDelegationTable 1 }
-
-   DnsResLameDelegationEntry ::=
-       SEQUENCE {
-           dnsResLameDelegationSource
-               IpAddress,
-           dnsResLameDelegationName
-               DnsNameAsIndex,
-           dnsResLameDelegationClass
-               DnsClass,
-           dnsResLameDelegationCounts
-               Counter32,
-           dnsResLameDelegationStatus
-               RowStatus
-       }
-
-   dnsResLameDelegationSource OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Source of lame delegation."
-       ::= { dnsResLameDelegationEntry 1 }
-
-   dnsResLameDelegationName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS name for which lame delegation was received."
-       ::= { dnsResLameDelegationEntry 2 }
-
-   dnsResLameDelegationClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS class of received lame delegation."
-       ::= { dnsResLameDelegationEntry 3 }
-
-
-
-
-Austein & Saperia                                              [Page 15]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResLameDelegationCounts OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "How many times this lame delegation has been received."
-       ::= { dnsResLameDelegationEntry 4 }
-
-   dnsResLameDelegationStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status column for the lame delegation table.  Since only
-               the agent (DNS resolver) creates rows in this table, the
-               only values that a manager may write to this variable
-               are active(1) and destroy(6)."
-       ::= { dnsResLameDelegationEntry 5 }
-
-
-   -- Resolver Cache Group
-
-   dnsResCacheStatus OBJECT-TYPE
-       SYNTAX      INTEGER { enabled(1), disabled(2), clear(3) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status/action for the resolver's cache.
-
-               enabled(1) means that the use of the cache is allowed.
-               Query operations can return this state.
-
-               disabled(2) means that the cache is not being used.
-               Query operations can return this state.
-
-               Setting this variable to clear(3) deletes the entire
-               contents of the resolver's cache, but does not otherwise
-               change the resolver's state.  The status will retain its
-               previous value from before the clear operation (i.e.,
-               enabled(1) or disabled(2)).  The value of clear(3) can
-               NOT be returned by a query operation."
-       ::= { dnsResCache 1 }
-
-   dnsResCacheMaxTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-
-
-
-Austein & Saperia                                              [Page 16]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               "Maximum Time-To-Live for RRs in this cache.  If the
-               resolver does not implement a TTL ceiling, the value of
-               this field should be zero."
-       ::= { dnsResCache 2 }
-
-   dnsResCacheGoodCaches OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of RRs the resolver has cached successfully."
-       ::= { dnsResCache 3 }
-
-   dnsResCacheBadCaches OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of RRs the resolver has refused to cache because
-               they appear to be dangerous or irrelevant.  E.g., RRs
-               with suspiciously high TTLs, unsolicited root
-               information, or that just don't appear to be relevant to
-               the question the resolver asked."
-       ::= { dnsResCache 4 }
-
-   -- Resolver Cache Table
-
-   dnsResCacheRRTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResCacheRREntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "This table contains information about all the resource
-               records currently in the resolver's cache."
-       ::= { dnsResCache 5 }
-
-   dnsResCacheRREntry OBJECT-TYPE
-       SYNTAX      DnsResCacheRREntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "An entry in the resolvers's cache.  Rows may be created
-               only by the resolver.  SNMP SET requests may be used to
-               delete rows."
-       INDEX     { dnsResCacheRRName,
-                   dnsResCacheRRClass,
-                   dnsResCacheRRType,
-                   dnsResCacheRRIndex }
-
-
-
-Austein & Saperia                                              [Page 17]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       ::= { dnsResCacheRRTable 1 }
-
-   DnsResCacheRREntry ::=
-       SEQUENCE {
-           dnsResCacheRRName
-               DnsNameAsIndex,
-           dnsResCacheRRClass
-               DnsClass,
-           dnsResCacheRRType
-               DnsType,
-           dnsResCacheRRTTL
-               DnsTime,
-           dnsResCacheRRElapsedTTL
-               DnsTime,
-           dnsResCacheRRSource
-               IpAddress,
-           dnsResCacheRRData
-               OCTET STRING,
-           dnsResCacheRRStatus
-               RowStatus,
-           dnsResCacheRRIndex
-               Integer32,
-           dnsResCacheRRPrettyName
-               DnsName
-       }
-
-   dnsResCacheRRName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Owner name of the Resource Record in the cache which is
-               identified in this row of the table.  As described in
-               RFC-1034, the owner of the record is the domain name
-               were the RR is found."
-       REFERENCE
-               "RFC-1034 section 3.6."
-       ::= { dnsResCacheRREntry 1 }
-
-   dnsResCacheRRClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS class of the Resource Record in the cache which is
-               identified in this row of the table."
-       ::= { dnsResCacheRREntry 2 }
-
-
-
-
-Austein & Saperia                                              [Page 18]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResCacheRRType OBJECT-TYPE
-       SYNTAX      DnsType
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS type of the Resource Record in the cache which is
-               identified in this row of the table."
-       ::= { dnsResCacheRREntry 3 }
-
-   dnsResCacheRRTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Time-To-Live of RR in DNS cache.  This is the initial
-               TTL value which was received with the RR when it was
-               originally received."
-       ::= { dnsResCacheRREntry 4 }
-
-   dnsResCacheRRElapsedTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Elapsed seconds since RR was received."
-       ::= { dnsResCacheRREntry 5 }
-
-   dnsResCacheRRSource OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Host from which RR was received, 0.0.0.0 if unknown."
-       ::= { dnsResCacheRREntry 6 }
-
-   dnsResCacheRRData OBJECT-TYPE
-       SYNTAX      OCTET STRING
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "RDATA portion of a cached RR.  The value is in the
-               format defined for the particular DNS class and type of
-               the resource record."
-       REFERENCE
-               "RFC-1035 section 3.2.1."
-       ::= { dnsResCacheRREntry 7 }
-
-
-
-
-
-Austein & Saperia                                              [Page 19]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResCacheRRStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status column for the resolver cache table.  Since only
-               the agent (DNS resolver) creates rows in this table, the
-               only values that a manager may write to this variable
-               are active(1) and destroy(6)."
-       ::= { dnsResCacheRREntry 8 }
-
-   dnsResCacheRRIndex OBJECT-TYPE
-       SYNTAX      Integer32
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "A value which makes entries in the table unique when the
-               other index values (dnsResCacheRRName,
-               dnsResCacheRRClass, and dnsResCacheRRType) do not
-               provide a unique index."
-       ::= { dnsResCacheRREntry 9 }
-
-   dnsResCacheRRPrettyName OBJECT-TYPE
-       SYNTAX      DnsName
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Name of the RR at this row in the table.  This is
-               identical to the dnsResCacheRRName variable, except that
-               character case is preserved in this variable, per DNS
-               conventions."
-       REFERENCE
-               "RFC-1035 section 2.3.3."
-       ::= { dnsResCacheRREntry 10 }
-
-   -- Resolver Negative Cache Group
-
-   dnsResNCacheStatus OBJECT-TYPE
-       SYNTAX      INTEGER { enabled(1), disabled(2), clear(3) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status/action for the resolver's negative response
-               cache.
-
-               enabled(1) means that the use of the negative response
-               cache is allowed.  Query operations can return this
-               state.
-
-
-
-Austein & Saperia                                              [Page 20]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               disabled(2) means that the negative response cache is
-               not being used.  Query operations can return this state.
-
-               Setting this variable to clear(3) deletes the entire
-               contents of the resolver's negative response cache.  The
-               status will retain its previous value from before the
-               clear operation (i.e., enabled(1) or disabled(2)).  The
-               value of clear(3) can NOT be returned by a query
-               operation."
-       ::= { dnsResNCache 1 }
-
-   dnsResNCacheMaxTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Maximum Time-To-Live for cached authoritative errors.
-               If the resolver does not implement a TTL ceiling, the
-               value of this field should be zero."
-       ::= { dnsResNCache 2 }
-
-   dnsResNCacheGoodNCaches OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of authoritative errors the resolver has cached
-               successfully."
-       ::= { dnsResNCache 3 }
-
-   dnsResNCacheBadNCaches OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of authoritative errors the resolver would have
-               liked to cache but was unable to because the appropriate
-               SOA RR was not supplied or looked suspicious."
-       REFERENCE
-               "RFC-1034 section 4.3.4."
-       ::= { dnsResNCache 4 }
-
-   -- Resolver Negative Cache Table
-
-   dnsResNCacheErrTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResNCacheErrEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-
-
-
-Austein & Saperia                                              [Page 21]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       DESCRIPTION
-               "The resolver's negative response cache.  This table
-               contains information about authoritative errors that
-               have been cached by the resolver."
-       ::= { dnsResNCache 5 }
-
-   dnsResNCacheErrEntry OBJECT-TYPE
-       SYNTAX      DnsResNCacheErrEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "An entry in the resolver's negative response cache
-               table.  Only the resolver can create rows.  SNMP SET
-               requests may be used to delete rows."
-       INDEX     { dnsResNCacheErrQName,
-                   dnsResNCacheErrQClass,
-                   dnsResNCacheErrQType,
-                   dnsResNCacheErrIndex }
-       ::= { dnsResNCacheErrTable 1 }
-
-   DnsResNCacheErrEntry ::=
-       SEQUENCE {
-           dnsResNCacheErrQName
-               DnsNameAsIndex,
-           dnsResNCacheErrQClass
-               DnsQClass,
-           dnsResNCacheErrQType
-               DnsQType,
-           dnsResNCacheErrTTL
-               DnsTime,
-           dnsResNCacheErrElapsedTTL
-               DnsTime,
-           dnsResNCacheErrSource
-               IpAddress,
-           dnsResNCacheErrCode
-               INTEGER,
-           dnsResNCacheErrStatus
-               RowStatus,
-           dnsResNCacheErrIndex
-               Integer32,
-           dnsResNCacheErrPrettyName
-               DnsName
-       }
-
-   dnsResNCacheErrQName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-
-
-
-Austein & Saperia                                              [Page 22]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       DESCRIPTION
-               "QNAME associated with a cached authoritative error."
-       REFERENCE
-               "RFC-1034 section 3.7.1."
-       ::= { dnsResNCacheErrEntry 1 }
-
-   dnsResNCacheErrQClass OBJECT-TYPE
-       SYNTAX      DnsQClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS QCLASS associated with a cached authoritative
-               error."
-       ::= { dnsResNCacheErrEntry 2 }
-
-   dnsResNCacheErrQType OBJECT-TYPE
-       SYNTAX      DnsQType
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS QTYPE associated with a cached authoritative error."
-       ::= { dnsResNCacheErrEntry 3 }
-
-   dnsResNCacheErrTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Time-To-Live of a cached authoritative error at the time
-               of the error, it should not be decremented by the number
-               of seconds since it was received.  This should be the
-               TTL as copied from the MINIMUM field of the SOA that
-               accompanied the authoritative error, or a smaller value
-               if the resolver implements a ceiling on negative
-               response cache TTLs."
-       REFERENCE
-               "RFC-1034 section 4.3.4."
-       ::= { dnsResNCacheErrEntry 4 }
-
-   dnsResNCacheErrElapsedTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Elapsed seconds since authoritative error was received."
-       ::= { dnsResNCacheErrEntry 5 }
-
-
-
-
-
-Austein & Saperia                                              [Page 23]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResNCacheErrSource OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Host which sent the authoritative error, 0.0.0.0 if
-               unknown."
-       ::= { dnsResNCacheErrEntry 6 }
-
-   dnsResNCacheErrCode OBJECT-TYPE
-       SYNTAX      INTEGER { nonexistantName(1), noData(2), other(3) }
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "The authoritative error that has been cached:
-
-               nonexistantName(1) indicates an authoritative name error
-               (RCODE = 3).
-
-               noData(2) indicates an authoritative response with no
-               error (RCODE = 0) and no relevant data.
-
-               other(3) indicates some other cached authoritative
-               error.  At present, no such errors are known to exist."
-       ::= { dnsResNCacheErrEntry 7 }
-
-   dnsResNCacheErrStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status column for the resolver negative response cache
-               table.  Since only the agent (DNS resolver) creates rows
-               in this table, the only values that a manager may write
-               to this variable are active(1) and destroy(6)."
-       ::= { dnsResNCacheErrEntry 8 }
-
-   dnsResNCacheErrIndex OBJECT-TYPE
-       SYNTAX      Integer32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "A value which makes entries in the table unique when the
-               other index values (dnsResNCacheErrQName,
-               dnsResNCacheErrQClass, and dnsResNCacheErrQType) do not
-               provide a unique index."
-       ::= { dnsResNCacheErrEntry 9 }
-
-
-
-
-Austein & Saperia                                              [Page 24]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResNCacheErrPrettyName OBJECT-TYPE
-       SYNTAX      DnsName
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "QNAME associated with this row in the table.  This is
-               identical to the dnsResNCacheErrQName variable, except
-               that character case is preserved in this variable, per
-               DNS conventions."
-       REFERENCE
-               "RFC-1035 section 2.3.3."
-       ::= { dnsResNCacheErrEntry 10 }
-
-
-   -- Resolver Optional Counters Group
-
-   dnsResOptCounterReferals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses which were received from servers
-               redirecting query to another server."
-       ::= { dnsResOptCounter 1 }
-
-   dnsResOptCounterRetrans OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number requests retransmitted for all reasons."
-       ::= { dnsResOptCounter 2 }
-
-   dnsResOptCounterNoResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries that were retransmitted because of no
-               response."
-       ::= { dnsResOptCounter 3 }
-
-   dnsResOptCounterRootRetrans OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries that were retransmitted that were to
-
-
-
-Austein & Saperia                                              [Page 25]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               root servers."
-       ::= { dnsResOptCounter 4 }
-
-   dnsResOptCounterInternals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests internally generated by the
-               resolver."
-       ::= { dnsResOptCounter 5 }
-
-   dnsResOptCounterInternalTimeOuts OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests internally generated which timed
-               out."
-       ::= { dnsResOptCounter 6 }
-
-
-   -- SNMPv2 groups.
-
-   dnsResMIBGroups         OBJECT IDENTIFIER ::= { dnsResMIB 2 }
-
-   dnsResConfigGroup OBJECT-GROUP
-       OBJECTS   { dnsResConfigImplementIdent,
-                   dnsResConfigService,
-                   dnsResConfigMaxCnames,
-                   dnsResConfigSbeltAddr,
-                   dnsResConfigSbeltName,
-                   dnsResConfigSbeltRecursion,
-                   dnsResConfigSbeltPref,
-                   dnsResConfigSbeltSubTree,
-                   dnsResConfigSbeltClass,
-                   dnsResConfigSbeltStatus,
-                   dnsResConfigUpTime,
-                   dnsResConfigResetTime }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing basic configuration
-               information for a DNS resolver implementation."
-       ::= { dnsResMIBGroups 1 }
-
-   dnsResCounterGroup OBJECT-GROUP
-       OBJECTS   { dnsResCounterByOpcodeCode,
-                   dnsResCounterByOpcodeQueries,
-
-
-
-Austein & Saperia                                              [Page 26]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-                   dnsResCounterByOpcodeResponses,
-                   dnsResCounterByRcodeCode,
-                   dnsResCounterByRcodeResponses,
-                   dnsResCounterNonAuthDataResps,
-                   dnsResCounterNonAuthNoDataResps,
-                   dnsResCounterMartians,
-                   dnsResCounterRecdResponses,
-                   dnsResCounterUnparseResps,
-                   dnsResCounterFallbacks }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing basic instrumentation
-               of a DNS resolver implementation."
-       ::= { dnsResMIBGroups 2 }
-
-   dnsResLameDelegationGroup OBJECT-GROUP
-       OBJECTS   { dnsResLameDelegationOverflows,
-                   dnsResLameDelegationSource,
-                   dnsResLameDelegationName,
-                   dnsResLameDelegationClass,
-                   dnsResLameDelegationCounts,
-                   dnsResLameDelegationStatus }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing instrumentation of
-               `lame delegation' failures."
-       ::= { dnsResMIBGroups 3 }
-
-
-   dnsResCacheGroup OBJECT-GROUP
-       OBJECTS   { dnsResCacheStatus,
-                   dnsResCacheMaxTTL,
-                   dnsResCacheGoodCaches,
-                   dnsResCacheBadCaches,
-                   dnsResCacheRRName,
-                   dnsResCacheRRClass,
-                   dnsResCacheRRType,
-                   dnsResCacheRRTTL,
-                   dnsResCacheRRElapsedTTL,
-                   dnsResCacheRRSource,
-                   dnsResCacheRRData,
-                   dnsResCacheRRStatus,
-                   dnsResCacheRRIndex,
-                   dnsResCacheRRPrettyName }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing access to and control
-               of a DNS resolver's cache."
-
-
-
-Austein & Saperia                                              [Page 27]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       ::= { dnsResMIBGroups 4 }
-
-   dnsResNCacheGroup OBJECT-GROUP
-       OBJECTS   { dnsResNCacheStatus,
-                   dnsResNCacheMaxTTL,
-                   dnsResNCacheGoodNCaches,
-                   dnsResNCacheBadNCaches,
-                   dnsResNCacheErrQName,
-                   dnsResNCacheErrQClass,
-                   dnsResNCacheErrQType,
-                   dnsResNCacheErrTTL,
-                   dnsResNCacheErrElapsedTTL,
-                   dnsResNCacheErrSource,
-                   dnsResNCacheErrCode,
-                   dnsResNCacheErrStatus,
-                   dnsResNCacheErrIndex,
-                   dnsResNCacheErrPrettyName }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing access to and control
-               of a DNS resolver's negative response cache."
-       ::= { dnsResMIBGroups 5 }
-
-   dnsResOptCounterGroup OBJECT-GROUP
-       OBJECTS   { dnsResOptCounterReferals,
-                   dnsResOptCounterRetrans,
-                   dnsResOptCounterNoResponses,
-                   dnsResOptCounterRootRetrans,
-                   dnsResOptCounterInternals,
-                   dnsResOptCounterInternalTimeOuts }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing further
-               instrumentation applicable to many but not all DNS
-               resolvers."
-       ::= { dnsResMIBGroups 6 }
-
-
-   -- Compliances.
-
-   dnsResMIBCompliances OBJECT IDENTIFIER ::= { dnsResMIB 3 }
-
-   dnsResMIBCompliance MODULE-COMPLIANCE
-       STATUS      current
-       DESCRIPTION
-               "The compliance statement for agents implementing the DNS
-               resolver MIB extensions."
-       MODULE -- This MIB module
-
-
-
-Austein & Saperia                                              [Page 28]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-           MANDATORY-GROUPS { dnsResConfigGroup, dnsResCounterGroup }
-           GROUP   dnsResCacheGroup
-           DESCRIPTION
-               "The resolver cache group is mandatory for resolvers that
-               implement a cache."
-           GROUP   dnsResNCacheGroup
-           DESCRIPTION
-               "The resolver negative cache group is mandatory for
-               resolvers that implement a negative response cache."
-           GROUP   dnsResLameDelegationGroup
-           DESCRIPTION
-               "The lame delegation group is unconditionally optional."
-           GROUP   dnsResOptCounterGroup
-           DESCRIPTION
-               "The optional counters group is unconditionally
-               optional."
-           OBJECT  dnsResConfigMaxCnames
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResConfigSbeltName
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResConfigSbeltRecursion
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResConfigSbeltPref
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResConfigReset
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResCacheStatus
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResCacheMaxTTL
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResNCacheStatus
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-
-
-
-Austein & Saperia                                              [Page 29]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-           OBJECT  dnsResNCacheMaxTTL
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-       ::= { dnsResMIBCompliances 1 }
-
-   END
-
-5.  Acknowledgements
-
-   This document is the result of work undertaken the by DNS working
-   group.  The authors would particularly like to thank the following
-   people for their contributions to this document: Philip Almquist,
-   Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins
-   (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM).
-
-6.  References
-
-   [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
-       13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names -- Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-   [3] Braden, R., Editor, "Requirements for Internet Hosts --
-       Application and Support, STD 3, RFC 1123, USC/Information
-       Sciences Institute, October 1989.
-
-   [4] Rose, M., and K. McCloghrie, "Structure and Identification of
-       Management Information for TCP/IP-based internets", STD 16, RFC
-       1155, Performance Systems International, Hughes LAN Systems, May
-       1990.
-
-   [5] McCloghrie, K., and M. Rose, "Management Information Base for
-       Network Management of TCP/IP-based internets", RFC 1156, Hughes
-       LAN Systems, Performance Systems International, May 1990.
-
-   [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
-       Network Management Protocol", STD 15, RFC 1157, SNMP Research,
-       Performance Systems International, Performance Systems
-       International, MIT Laboratory for Computer Science, May 1990.
-
-   [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
-       STD 16, RFC 1212, Performance Systems International, Hughes LAN
-       Systems, March 1991.
-
-
-
-
-
-Austein & Saperia                                              [Page 30]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   [8] McCloghrie, K., and M. Rose, "Management Information Base for
-       Network Management of TCP/IP-based internets: MIB-II", STD 17,
-       RFC 1213, Hughes LAN Systems, Performance Systems International,
-       March 1991.
-
-   [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
-       of Management Information for version 2 of the Simple Network
-       Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
-       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
-       Conventions for version 2 of the the Simple Network Management
-       Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
-       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
-       "Conformance Statements for version 2 of the the Simple Network
-       Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc.,
-       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [12] Galvin, J., and K. McCloghrie, "Administrative Model for version
-       2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
-       Trusted Information Systems, Hughes LAN Systems, April 1993.
-
-  [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
-       Operations for version 2 of the Simple Network Management
-       Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
-       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [14] "Information processing systems - Open Systems Interconnection -
-       Specification of Abstract Syntax Notation One (ASN.1)",
-       International Organization for Standardization, International
-       Standard 8824, December 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 31]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-7.  Security Considerations
-
-   Security issues are not discussed in this memo.
-
-8.  Authors' Addresses
-
-   Rob Austein
-   Epilogue Technology Corporation
-   268 Main Street, Suite 283
-   North Reading, MA 01864
-   USA
-
-   Phone: +1-617-245-0804
-   Fax:   +1-617-245-8122
-   EMail: sra@epilogue.com
-
-
-   Jon Saperia
-   Digital Equipment Corporation
-   110 Spit Brook Road
-   ZKO1-3/H18
-   Nashua, NH 03062-2698
-   USA
-
-   Phone: +1-603-881-0480
-   Fax:   +1-603-881-0120
-   EMail: saperia@zko.dec.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 32]
-
diff --git a/doc/rfc/rfc1706.txt b/doc/rfc/rfc1706.txt
deleted file mode 100644
index 5b5d8219..00000000
--- a/doc/rfc/rfc1706.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         B. Manning
-Request for Comments: 1706                                           ISI
-Obsoletes: 1637, 1348                                         R. Colella
-Category: Informational                                             NIST
-                                                            October 1994
-
-
-                       DNS NSAP Resource Records
-
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   OSI lower layer protocols, comprising the connectionless network
-   protocol (CLNP) and supporting routing protocols, are deployed in
-   some parts of the global Internet.  Maintenance and debugging of CLNP
-   connectivity is greatly aided by support in the Domain Name System
-   (DNS) for mapping between names and NSAP addresses.
-
-   This document defines the format of one new Resource Record (RR) for
-   the DNS for domain name-to-NSAP mapping. The RR may be used with any
-   NSAP address format.
-
-   NSAP-to-name translation is accomplished through use of the PTR RR
-   (see STD 13, RFC 1035 for a description of the PTR RR). This paper
-   describes how PTR RRs are used to support this translation.
-
-   This document obsoletes RFC 1348 and RFC 1637.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manning & Colella                                               [Page 1]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-1.  Introduction
-
-   OSI lower layer protocols, comprising the connectionless network
-   protocol (CLNP) [5] and supporting routing protocols, are deployed in
-   some parts of the global Internet.  Maintenance and debugging of CLNP
-   connectivity is greatly aided by support in the Domain Name System
-   (DNS) [7] [8] for mapping between names and NSAP (network service
-   access point) addresses [6] [Note: NSAP and NSAP address are used
-   interchangeably throughout this memo].
-
-   This document defines the format of one new Resource Record (RR) for
-   the DNS for domain name-to-NSAP mapping. The RR may be used with any
-   NSAP address format.
-
-   NSAP-to-name translation is accomplished through use of the PTR RR
-   (see RFC 1035 for a description of the PTR RR). This paper describes
-   how PTR RRs are used to support this translation.
-
-   This memo assumes that the reader is familiar with the DNS. Some
-   familiarity with NSAPs is useful; see [1] or Annex A of [6] for
-   additional information.
-
-2.  Background
-
-   The reason for defining DNS mappings for NSAPs is to support the
-   existing CLNP deployment in the Internet.  Debugging with CLNP ping
-   and traceroute has become more difficult with only numeric NSAPs as
-   the scale of deployment has increased. Current debugging is supported
-   by maintaining and exchanging a configuration file with name/NSAP
-   mappings similar in function to hosts.txt. This suffers from the lack
-   of a central coordinator for this file and also from the perspective
-   of scaling.  The former describes the most serious short-term
-   problem. Scaling of a hosts.txt-like solution has well-known long-
-   term scaling difficiencies.
-
-3.  Scope
-
-   The methods defined in this paper are applicable to all NSAP formats.
-
-   As a point of reference, there is a distinction between registration
-   and publication of addresses. For IP addresses, the IANA is the root
-   registration authority and the DNS a publication method. For NSAPs,
-   Annex A of the network service definition, ISO8348 [6], describes the
-   root registration authority and this memo defines how the DNS is used
-   as a publication method.
-
-
-
-
-
-
-Manning & Colella                                               [Page 2]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-4.  Structure of NSAPs
-
-   NSAPs are hierarchically structured to allow distributed
-   administration and efficient routing. Distributed administration
-   permits subdelegated addressing authorities to, as allowed by the
-   delegator, further structure the portion of the NSAP space under
-   their delegated control.  Accomodating this distributed authority
-   requires that there be little or no a priori knowledge of the
-   structure of NSAPs built into DNS resolvers and servers.
-
-   For the purposes of this memo, NSAPs can be thought of as a tree of
-   identifiers. The root of the tree is ISO8348 [6], and has as its
-   immediately registered subordinates the one-octet Authority and
-   Format Identifiers (AFIs) defined there. The size of subsequently-
-   defined fields depends on which branch of the tree is taken. The
-   depth of the tree varies according to the authority responsible for
-   defining subsequent fields.
-
-   An example is the authority under which U.S. GOSIP defines NSAPs [2].
-   Under the AFI of 47, NIST (National Institute of Standards and
-   Technology) obtained a value of 0005 (the AFI of 47 defines the next
-   field as being two octets consisting of four BCD digits from the
-   International Code Designator space [3]). NIST defined the subsequent
-   fields in [2], as shown in Figure 1. The field immediately following
-   0005 is a format identifier for the rest of the U.S. GOSIP NSAP
-   structure, with a hex value of 80. Following this is the three-octet
-   field, values for which are allocated to network operators; the
-   registration authority for this field is delegated to GSA (General
-   Services Administration).
-
-   The last octet of the NSAP is the NSelector (NSel). In practice, the
-   NSAP minus the NSel identifies the CLNP protocol machine on a given
-   system, and the NSel identifies the CLNP user. Since there can be
-   more than one CLNP user (meaning multiple NSel values for a given
-   "base" NSAP), the representation of the NSAP should be CLNP-user
-   independent. To achieve this, an NSel value of zero shall be used
-   with all NSAP values stored in the DNS. An NSAP with NSel=0
-   identifies the network layer itself. It is left to the application
-   retrieving the NSAP to determine the appropriate value to use in that
-   instance of communication.
-
-   When CLNP is used to support TCP and UDP services, the NSel value
-   used is the appropriate IP PROTO value as registered with the IANA.
-   For "standard" OSI, the selection of NSel values is left as a matter
-   of local administration. Administrators of systems that support the
-   OSI transport protocol [4] in addition to TCP/UDP must select NSels
-   for use by OSI Transport that do not conflict with the IP PROTO
-   values.
-
-
-
-Manning & Colella                                               [Page 3]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-              |--------------|
-              | <-- IDP -->  |
-              |--------------|-------------------------------------|
-              | AFI |  IDI   |            <-- DSP -->              |
-              |-----|--------|-------------------------------------|
-              | 47  |  0005  | DFI | AA |Rsvd | RD |Area | ID |Sel |
-              |-----|--------|-----|----|-----|----|-----|----|----|
-       octets |  1  |   2    |  1  | 3  |  2  | 2  |  2  | 6  | 1  |
-              |-----|--------|-----|----|-----|----|-----|----|----|
-
-                    IDP    Initial Domain Part
-                    AFI    Authority and Format Identifier
-                    IDI    Initial Domain Identifier
-                    DSP    Domain Specific Part
-                    DFI    DSP Format Identifier
-                    AA     Administrative Authority
-                    Rsvd   Reserved
-                    RD     Routing Domain Identifier
-                    Area   Area Identifier
-                    ID     System Identifier
-                    SEL    NSAP Selector
-
-                  Figure 1: GOSIP Version 2 NSAP structure.
-
-
-   In the NSAP RRs in Master Files and in the printed text in this memo,
-   NSAPs are often represented as a string of "."-separated hex values.
-   The values correspond to convenient divisions of the NSAP to make it
-   more readable. For example, the "."-separated fields might correspond
-   to the NSAP fields as defined by the appropriate authority (RARE,
-   U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for
-   readability. The "."s do not appear in DNS packets and DNS servers
-   can ignore them when reading Master Files. For example, a printable
-   representation of the first four fields of a U.S. GOSIP NSAP might
-   look like
-
-                             47.0005.80.005a00
-
-   and a full U.S. GOSIP NSAP might appear as
-
-             47.0005.80.005a00.0000.1000.0020.00800a123456.00.
-
-   Other NSAP formats have different lengths and different
-   administratively defined field widths to accomodate different
-   requirements. For more information on NSAP formats in use see RFC
-   1629 [1].
-
-
-
-
-
-Manning & Colella                                               [Page 4]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-5.  The NSAP RR
-
-   The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
-   (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
-   mapping in the DNS using the NSAP RR operates analogously to IP
-   address lookup. A query is generated by the resolver requesting an
-   NSAP RR for a provided domain name.
-
-   NSAP RRs conform to the top level RR format and semantics as defined
-   in Section 3.2.1 of RFC 1035.
-
-                                            1  1  1  1  1  1
-              0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                                               |
-           /                                               /
-           /                        NAME                   /
-           |                                               |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                    TYPE = NSAP                |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                    CLASS = IN                 |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                        TTL                    |
-           |                                               |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                      RDLENGTH                 |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           /                       RDATA                   /
-           /                                               /
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-   *  NAME: an owner name, i.e., the name of the node to which this
-      resource record pertains.
-
-   *  TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
-
-   *  CLASS: two octets containing the RR IN CLASS code of 1.
-
-   *  TTL: a 32 bit signed integer that specifies the time interval in
-      seconds that the resource record may be cached before the source
-      of the information should again be consulted. Zero values are
-      interpreted to mean that the RR can only be used for the
-      transaction in progress, and should not be cached. For example,
-      SOA records are always distributed with a zero TTL to prohibit
-      caching. Zero values can also be used for extremely volatile data.
-
-
-
-Manning & Colella                                               [Page 5]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-   *  RDLENGTH: an unsigned 16 bit integer that specifies the length in
-      octets of the RDATA field.
-
-   *  RDATA: a variable length string of octets containing the NSAP.
-      The value is the binary encoding of the NSAP as it would appear in
-      the CLNP source or destination address field. A typical example of
-      such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
-      20 (decimal); "."s have been omitted to emphasize that they don't
-      appear in the DNS packets.
-
-                 39840f80005a0000000001e13708002010726e00
-
-   NSAP RRs cause no additional section processing.
-
-6.  NSAP-to-name Mapping Using the PTR RR
-
-   The PTR RR is defined in RFC 1035. This RR is typically used under
-   the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
-
-   Similarly, the PTR RR is used to map from NSAPs to domain names under
-   the "NSAP.INT" domain. A domain name is generated from the NSAP
-   according to the rules described below. A query is sent by the
-   resolver requesting a PTR RR for the provided domain name.
-
-   A domain name is generated from an NSAP by reversing the hex nibbles
-   of the NSAP, treating each nibble as a separate subdomain, and
-   appending the top-level subdomain name "NSAP.INT" to it. For example,
-   the domain name used in the reverse lookup for the NSAP
-
-             47.0005.80.005a00.0000.0001.e133.ffffff000162.00
-
-   would appear as
-
-     0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
-                         0.8.5.0.0.0.7.4.NSAP.INT.
-
-   [Implementation note: For sanity's sake user interfaces should be
-   designed to allow users to enter NSAPs using their natural order,
-   i.e., as they are typically written on paper. Also, arbitrary "."s
-   should be allowed (and ignored) on input.]
-
-7.  Master File Format
-
-   The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
-   conforms to Section 5, "Master Files," of RFC 1035. Below are
-   examples of the use of these RRs in Master Files to support name-to-
-   NSAP and NSAP-to-name mapping.
-
-
-
-
-Manning & Colella                                               [Page 6]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-   The NSAP RR introduces a new hex string format for the RDATA field.
-   The format is "0x" (i.e., a zero followed by an 'x' character)
-   followed by a variable length string of hex characters (0 to 9, a to
-   f). The hex string is case-insensitive. "."s (i.e., periods) may be
-   inserted in the hex string anywhere after the "0x" for readability.
-   The "."s have no significance other than for readability and are not
-   propagated in the protocol (e.g., queries or zone transfers).
-
-
-   ;;;;;;
-   ;;;;;; Master File for domain nsap.nist.gov.
-   ;;;;;;
-
-
-   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
-                                     1994041800   ; Serial  - date
-                                     1800         ; Refresh - 30 minutes
-                                     300          ; Retry   - 5 minutes
-                                     604800       ; Expire  - 7 days
-                                     3600 )       ; Minimum - 1 hour
-          IN     NS     emu.ncsl.nist.gov.
-          IN     NS     tuba.nsap.lanl.gov.
-   ;
-   ;
-   $ORIGIN nsap.nist.gov.
-   ;
-   ;     hosts
-   ;
-   bsdi1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
-            IN  A     129.6.224.161
-            IN  HINFO PC_486    BSDi1.1
-   ;
-   bsdi2    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
-            IN  A     129.6.224.162
-            IN  HINFO PC_486    BSDi1.1
-   ;
-   cursive  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
-            IN  A     129.6.224.171
-            IN  HINFO PC_386    DOS_5.0/NCSA_Telnet(TUBA)
-   ;
-   infidel  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
-            IN  A     129.6.55.164
-            IN  HINFO PC/486    BSDi1.0(TUBA)
-   ;
-   ;     routers
-   ;
-   cisco1   IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
-            IN  A     129.6.224.151
-
-
-
-Manning & Colella                                               [Page 7]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-            IN  A     129.6.225.151
-            IN  A     129.6.229.151
-   ;
-   3com1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
-            IN  A     129.6.224.111
-            IN  A     129.6.225.111
-            IN  A     129.6.228.111
-
-
-
-
-   ;;;;;;
-   ;;;;;; Master File for reverse mapping of NSAPs under the
-   ;;;;;;     NSAP prefix:
-   ;;;;;;
-   ;;;;;;          47.0005.80.005a00.0000.0001.e133
-   ;;;;;;
-
-
-   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
-                                     1994041800   ; Serial  - date
-                                     1800         ; Refresh - 30 minutes
-                                     300          ; Retry   - 5 minutes
-                                     604800       ; Expire  - 7 days
-                                     3600 )       ; Minimum - 1 hour
-          IN     NS     emu.ncsl.nist.gov.
-          IN     NS     tuba.nsap.lanl.gov.
-   ;
-   ;
-   $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
-   ;
-   0.0.1.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi1.nsap.nist.gov.
-   ;
-   0.0.2.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi2.nsap.nist.gov.
-   ;
-   0.0.1.7.1.0.0.0.f.f.f.f.f.f  IN    PTR  cursive.nsap.nist.gov.
-   ;
-   0.0.4.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  infidel.nsap.nist.gov.
-   ;
-   0.0.1.5.1.0.0.0.a.a.a.a.a.a  IN    PTR  cisco1.nsap.nist.gov.
-   ;
-   0.0.1.1.1.0.0.0.a.a.a.a.a.a  IN    PTR  3com1.nsap.nist.gov.
-
-8.  Security Considerations
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-Manning & Colella                                               [Page 8]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-9.  Authors' Addresses
-
-   Bill Manning
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA. 90292
-   USA
-
-   Phone: +1.310.822.1511
-   EMail: bmanning@isi.edu
-
-
-   Richard Colella
-   National Institute of Standards and Technology
-   Technology/B217
-   Gaithersburg, MD 20899
-   USA
-
-   Phone: +1 301-975-3627
-   Fax: +1 301 590-0932
-   EMail: colella@nist.gov
-
-10.  References
-
-   [1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
-       for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
-       Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
-       1994.
-
-   [2] GOSIP Advanced Requirements Group.  Government Open Systems
-       Interconnection Profile (GOSIP) Version 2. Federal Information
-       Processing Standard 146-1, U.S. Department of Commerce, National
-       Institute of Standards and Technology, Gaithersburg, MD, April
-       1991.
-
-   [3] ISO/IEC.  Data interchange - structures for the identification of
-       organization.  International Standard 6523, ISO/IEC JTC 1,
-       Switzerland, 1984.
-
-   [4] ISO/IEC. Connection oriented transport protocol specification.
-       International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
-
-   [5] ISO/IEC.  Protocol for Providing the Connectionless-mode Network
-       Service.  International Standard 8473, ISO/IEC JTC 1,
-       Switzerland, 1986.
-
-
-
-
-
-
-Manning & Colella                                               [Page 9]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-   [6] ISO/IEC. Information Processing Systems -- Data Communications --
-       Network Service Definition.  International Standard 8348, ISO/IEC
-       JTC 1, Switzerland, 1993.
-
-   [7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
-       13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [8] Mockapetris, P., "Domain Names -- Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manning & Colella                                              [Page 10]
-
diff --git a/doc/rfc/rfc1712.txt b/doc/rfc/rfc1712.txt
deleted file mode 100644
index 40d88578..00000000
--- a/doc/rfc/rfc1712.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         C. Farrell
-Request for Comments: 1712                                    M. Schulze
-Category: Experimental                                       S. Pleitner
-                                                              D. Baldoni
-                                         Curtin University of Technology
-                                                           November 1994
-
-
-                 DNS Encoding of Geographical Location
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  This memo does not specify an Internet standard of any
-   kind.  Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Abstract
-
-   This document defines the format of a new Resource Record (RR) for
-   the Domain Naming System (DNS), and reserves a corresponding DNS type
-   mnemonic and numerical code.  This definition deals with associating
-   geographical host location mappings to host names within a domain.
-   The data shown in this document is fictitious and does not
-   necessarily reflect the real Internet.
-
-1. Introduction
-
-   It has been a long standing problem to relate IP numbers to
-   geographical locations. The availability of Geographical location
-   information has immediate applications in network management.  Such
-   information can be used to supplement the data already provided by
-   utilities such as whois [Har85], traceroute [VJ89], and nslookup
-   [UCB89].  The usefulness and functionality of these already widely
-   used tools would be greatly enhanced by the provision of reliable
-   geographical location information.
-
-   The ideal way to manage and maintain a database of information, such
-   as geographical location of internet hosts, is to delegate
-   responsibility to local domain administrators. A large distributed
-   database could be implemented with a simple mechanism for updating
-   the local information.  A query mechanism also has to be available
-   for checking local entries, as well as inquiring about data from
-   non-local domains.
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 1]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-2. Background
-
-   The Internet continues to grow at an ever increasing rate with IP
-   numbers allocated on a first-come-first-serve basis.  Deciding when
-   and how to setup a database of geographical information about
-   internet hosts presented a number of options.  The uumap project
-   [UU85] was the first serious attempt to collect geographical location
-   data from sites and store it centrally.  This project met with
-   limited success because of the difficulty in maintaining and updating
-   a large central database.  Another problem was the lack of tools for
-   the checking the data supplied, this problem resulted in some
-   erroneous data entering the database.
-
-2.1 SNMP:
-
-   Using an SNMP get request on the sysLocation MIB (Management
-   Information Base) variable was also an option, however this would
-   require the host to be running an appropriate agent with public read
-   access.  It was also felt that MIB data should reflect local
-   management data (e.g., "this" host is on level 5 room 74) rather than
-   a hosts geographical position.  This view is supported in the
-   examples given in literature in this area [ROSE91].
-
-2.2 X500:
-
-   The X.500 Directory service [X.500.88] defined as part of the ISO
-   standards also appears as a potential provider of geographical
-   location data. However due to the limited implementations of this
-   service it was decided to defer this until this service gains wider
-   use and acceptance within the Internet community.
-
-2.3 BIND:
-
-   The DNS [Mock87a][Mock87b] represents an existing system ideally
-   suited to the provision of host specific information. The DNS is a
-   widely used and well-understood mechanism for providing a distributed
-   database of such information and its extensible nature allows it to
-   be used to disseminate virtually any information.  The most commonly
-   used DNS implementation is the Berkeley Internet Name Domain server
-   BIND [UCB89].  The information we wished to make available needed to
-   be updated locally but available globally; a perfect match with the
-   services provided by the DNS. Current DNS servers provide a variety
-   of useful information about hosts in their domain but lack the
-   ability to report a host's geographical location.
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 2]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-3. RDATA Format
-
-        MSB                                        LSB
-        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-        /                 LONGITUDE                  /
-        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-        /                  LATITUDE                  /
-        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-        /                  ALTITUDE                  /
-        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-   LONGITUDE The real number describing the longitude encoded as a
-             printable string. The precision is limited by 256 charcters
-             within the range -90..90 degrees. Positive numbers
-             indicate locations north of the equator.
-
-   LATITUDE The real number describing the latitude encoded as a
-            printable string. The precision is limited by 256 charcters
-            within the range -180..180 degrees. Positive numbers
-            indicate locations east of the prime meridian.
-
-   ALTITUDE The real number describing the altitude (in meters) from
-            mean sea-level encoded as a printable string. The precision
-            is limited by 256 charcters. Positive numbers indicate
-            locations above mean sea-level.
-
-   Latitude/Longitude/Altitude values are encoded as strings as to avoid
-   the precision limitations imposed by encoding as unsigned integers.
-   Although this might not be considered optimal, it allows for a very
-   high degree of precision with an acceptable average encoded record
-   length.
-
-4. The GPOS RR
-
-   The geographical location is defined with the mnemonic GPOS and type
-   code 27.
-
-   GPOS has the following format:
-           <owner> <ttl> <class> GPOS <longitude> <latitude> <altitude>
-
-   A floating point format was chosen to specify geographical locations
-   for reasons of simplicity.  This also guarantees a concise
-   unambiguous description of a location by enforcing three compulsory
-   numerical values to be specified.
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 3]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-   The owner, ttl, and class fields are optional and default to the last
-   defined value if omitted. The longitude is a floating point number
-   ranging from -90 to 90 with positive values indicating locations
-   north of the equator.  For example Perth, Western Australia is
-   located at 32^ 7` 19" south of the equator which would be specified
-   as -32.68820.  The latitude is a number ranging from -180.0 to 180.0.
-   For example Perth, Western Australia is located at 116^ 2' 25" east
-   of the prime meridian which would be specified as 116.86520.  Curtin
-   University, Perth is also 10 meters above sea-level.
-
-   The valid GPOS record for a host at Curtin University in  Perth
-   Western Australia would therefore be:
-
-                GPOS -32.6882 116.8652 10.0
-
-   There is no limit imposed on the number of decimal places, although
-   the length of the encoded string is limited to 256 characters for
-   each field. It is also suggested that administrators limit their
-   entries to the minimum number of necessary characters in each field.
-
-5. Master File Format
-
-   Each host requires its own GPOS field in the corresponding  DNS RR to
-   explicitly specify its geographical location and altitude.  If the
-   GPOS field is omitted, a DNS enquiry will return no position
-   information for that host.
-
-   Consider the following example:
-
-; Authoritative data for cs.curtin.edu.au.
-;
-@     IN    SOA     marsh.cs.curtin.edu.au. postmaster.cs.curtin.edu.au.
-                (
-                        94070503        ; Serial (yymmddnn)
-                        10800           ; Refresh (3 hours)
-                        3600            ; Retry (1 hour)
-                        3600000         ; Expire (1000 hours)
-                        86400           ; Minimum (24 hours)
-                )
-
-                IN      NS      marsh.cs.curtin.edu.au.
-
-marsh           IN      A       134.7.1.1
-                IN      MX      0       marsh
-                IN      HINFO   SGI-Indigo IRIX-4.0.5F
-                IN      GPOS    -32.6882 116.8652 10.0
-ftp             IN      CNAME   marsh
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 4]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-lillee          IN      A       134.7.1.2
-                IN      MX      0       marsh
-                IN      HINFO   SGI-Indigo IRIX-4.0.5F
-                IN      GPOS    -32.6882 116.8652 10.0
-
-hinault         IN      A       134.7.1.23
-                IN      MX      0       marsh
-                IN      HINFO   SUN-IPC SunOS-4.1.3
-                IN      GPOS    -22.6882 116.8652 250.0
-
-merckx          IN      A       134.7.1.24
-                IN      MX      0       marsh
-                IN      HINFO   SUN-IPC SunOS-4.1.1
-
-ambrose         IN      A       134.7.1.99
-                IN      MX      0       marsh
-                IN      HINFO   SGI-CHALLENGE_L IRIX-5.2
-                IN      GPOS    -32.6882 116.8652 10.0
-
-   The hosts marsh, lillee, and ambrose are all at the same geographical
-   location, Perth Western Australia (-32.68820 116.86520). The host
-   hinault is at a different geographical location, 10 degrees north of
-   Perth in the mountains (-22.6882 116.8652 250.0). For security
-   reasons we do not wish to give the location of the host merckx.
-
-   Although the GPOS clause is not a standard entry within BIND
-   configuration files, most vendor implementations seem to ignore
-   whatever is not understood upon startup of the DNS.  Usually this
-   will result in a number of warnings appearing in system log files,
-   but in no way alters naming information or impedes the DNS from
-   performing its normal duties.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 5]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-7. References
-
-   [ROSE91]        Rose M., "The Simple Book: An Introduction to
-                   Management of TCP/IP-based Internets", Prentice-Hall,
-                   Englewood Cliffs, New Jersey, 1991.
-
-   [X.500.88]      CCITT: The Directory - Overview of Concepts, Models
-                   and Services", Recommendations X.500 - X.521.
-
-   [Har82]         Harrenstein K, Stahl M., and E. Feinler,
-                   "NICNAME/WHOIS" RFC 812, SRI NIC, March 1982.
-
-   [Mock87a]       Mockapetris P., "Domain Names - Concepts and
-                   Facilities", STD 13, RFC 1034, USC/Information
-                   Sciences Institute, November 1987.
-
-   [Mock87b]       Mockapetris P., "Domain Names - Implementation and
-                   Specification", STD 13, RFC 1035, USC/Information
-                   Sciences Institute, November 1987.
-
-   [FRB93]         Ford P., Rekhter Y., and H-W. Braun, "Improving the
-                   Routing and Addressing of IP", IEEE Network
-                   Vol.7, No. 3, pp. 11-15, May 1993.
-
-   [VJ89]          Jacobsen V., "The Traceroute(8) Manual Page",
-                   Lawrence Berkeley Laboratory, Berkeley,
-                   CA, February 1989.
-
-   [UCB89]         University of California, "BIND: Berkeley Internet
-                   Name Domain Server", 1989.
-   [UU85]          UUCP Mapping Project, Software available via
-                   anonymous FTP from ftp.uu.net., 1985.
-
-8. Security Considerations
-
-   Once information has been entered into the DNS, it is considered
-   public.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 6]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-9. Authors' Addresses
-
-   Craig Farrell
-   Department of Computer Science
-   Curtin University of technology
-   GPO Box U1987 Perth,
-   Western Australia
-
-   EMail: craig@cs.curtin.edu.au
-
-
-   Mike Schulze
-   Department of Computer Science
-   Curtin University of technology
-   GPO Box U1987 Perth,
-   Western Australia
-
-   EMail: mike@cs.curtin.edu.au
-
-
-   Scott Pleitner
-   Department of Computer Science
-   Curtin University of technology
-   GPO Box U1987 Perth,
-   Western Australia
-
-   EMail: pleitner@cs.curtin.edu.au
-
-
-   Daniel Baldoni
-   Department of Computer Science
-   Curtin University of technology
-   GPO Box U1987 Perth,
-   Western Australia
-
-   EMail: flint@cs.curtin.edu.au
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 7]
-
diff --git a/doc/rfc/rfc1750.txt b/doc/rfc/rfc1750.txt
deleted file mode 100644
index 56d478c7..00000000
--- a/doc/rfc/rfc1750.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   D. Eastlake, 3rd
-Request for Comments: 1750                                           DEC
-Category: Informational                                       S. Crocker
-                                                               Cybercash
-                                                             J. Schiller
-                                                                     MIT
-                                                           December 1994
-
-
-                Randomness Recommendations for Security
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   Security systems today are built on increasingly strong cryptographic
-   algorithms that foil pattern analysis attempts. However, the security
-   of these systems is dependent on generating secret quantities for
-   passwords, cryptographic keys, and similar quantities.  The use of
-   pseudo-random processes to generate secret quantities can result in
-   pseudo-security.  The sophisticated attacker of these security
-   systems may find it easier to reproduce the environment that produced
-   the secret quantities, searching the resulting small set of
-   possibilities, than to locate the quantities in the whole of the
-   number space.
-
-   Choosing random quantities to foil a resourceful and motivated
-   adversary is surprisingly difficult.  This paper points out many
-   pitfalls in using traditional pseudo-random number generation
-   techniques for choosing such quantities.  It recommends the use of
-   truly random hardware techniques and shows that the existing hardware
-   on many systems can be used for this purpose.  It provides
-   suggestions to ameliorate the problem when a hardware solution is not
-   available.  And it gives examples of how large such quantities need
-   to be for some particular applications.
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 1]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-Acknowledgements
-
-   Comments on this document that have been incorporated were received
-   from (in alphabetic order) the following:
-
-        David M. Balenson (TIS)
-        Don Coppersmith (IBM)
-        Don T. Davis (consultant)
-        Carl Ellison (Stratus)
-        Marc Horowitz (MIT)
-        Christian Huitema (INRIA)
-        Charlie Kaufman (IRIS)
-        Steve Kent (BBN)
-        Hal Murray (DEC)
-        Neil Haller (Bellcore)
-        Richard Pitkin (DEC)
-        Tim Redmond (TIS)
-        Doug Tygar (CMU)
-
-Table of Contents
-
-   1. Introduction........................................... 3
-   2. Requirements........................................... 4
-   3. Traditional Pseudo-Random Sequences.................... 5
-   4. Unpredictability....................................... 7
-   4.1 Problems with Clocks and Serial Numbers............... 7
-   4.2 Timing and Content of External Events................  8
-   4.3 The Fallacy of Complex Manipulation..................  8
-   4.4 The Fallacy of Selection from a Large Database.......  9
-   5. Hardware for Randomness............................... 10
-   5.1 Volume Required...................................... 10
-   5.2 Sensitivity to Skew.................................. 10
-   5.2.1 Using Stream Parity to De-Skew..................... 11
-   5.2.2 Using Transition Mappings to De-Skew............... 12
-   5.2.3 Using FFT to De-Skew............................... 13
-   5.2.4 Using Compression to De-Skew....................... 13
-   5.3 Existing Hardware Can Be Used For Randomness......... 14
-   5.3.1 Using Existing Sound/Video Input................... 14
-   5.3.2 Using Existing Disk Drives......................... 14
-   6. Recommended Non-Hardware Strategy..................... 14
-   6.1 Mixing Functions..................................... 15
-   6.1.1 A Trivial Mixing Function.......................... 15
-   6.1.2 Stronger Mixing Functions.......................... 16
-   6.1.3 Diff-Hellman as a Mixing Function.................. 17
-   6.1.4 Using a Mixing Function to Stretch Random Bits..... 17
-   6.1.5 Other Factors in Choosing a Mixing Function........ 18
-   6.2 Non-Hardware Sources of Randomness................... 19
-   6.3 Cryptographically Strong Sequences................... 19
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 2]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   6.3.1 Traditional Strong Sequences....................... 20
-   6.3.2 The Blum Blum Shub Sequence Generator.............. 21
-   7. Key Generation Standards.............................. 22
-   7.1 US DoD Recommendations for Password Generation....... 23
-   7.2 X9.17 Key Generation................................. 23
-   8. Examples of Randomness Required....................... 24
-   8.1  Password Generation................................. 24
-   8.2 A Very High Security Cryptographic Key............... 25
-   8.2.1 Effort per Key Trial............................... 25
-   8.2.2 Meet in the Middle Attacks......................... 26
-   8.2.3 Other Considerations............................... 26
-   9. Conclusion............................................ 27
-   10. Security Considerations.............................. 27
-   References............................................... 28
-   Authors' Addresses....................................... 30
-
-1. Introduction
-
-   Software cryptography is coming into wider use.  Systems like
-   Kerberos, PEM, PGP, etc. are maturing and becoming a part of the
-   network landscape [PEM].  These systems provide substantial
-   protection against snooping and spoofing.  However, there is a
-   potential flaw.  At the heart of all cryptographic systems is the
-   generation of secret, unguessable (i.e., random) numbers.
-
-   For the present, the lack of generally available facilities for
-   generating such unpredictable numbers is an open wound in the design
-   of cryptographic software.  For the software developer who wants to
-   build a key or password generation procedure that runs on a wide
-   range of hardware, the only safe strategy so far has been to force
-   the local installation to supply a suitable routine to generate
-   random numbers.  To say the least, this is an awkward, error-prone
-   and unpalatable solution.
-
-   It is important to keep in mind that the requirement is for data that
-   an adversary has a very low probability of guessing or determining.
-   This will fail if pseudo-random data is used which only meets
-   traditional statistical tests for randomness or which is based on
-   limited range sources, such as clocks.  Frequently such random
-   quantities are determinable by an adversary searching through an
-   embarrassingly small space of possibilities.
-
-   This informational document suggests techniques for producing random
-   quantities that will be resistant to such attack.  It recommends that
-   future systems include hardware random number generation or provide
-   access to existing hardware that can be used for this purpose.  It
-   suggests methods for use if such hardware is not available.  And it
-   gives some estimates of the number of random bits required for sample
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 3]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   applications.
-
-2. Requirements
-
-   Probably the most commonly encountered randomness requirement today
-   is the user password. This is usually a simple character string.
-   Obviously, if a password can be guessed, it does not provide
-   security.  (For re-usable passwords, it is desirable that users be
-   able to remember the password.  This may make it advisable to use
-   pronounceable character strings or phrases composed on ordinary
-   words.  But this only affects the format of the password information,
-   not the requirement that the password be very hard to guess.)
-
-   Many other requirements come from the cryptographic arena.
-   Cryptographic techniques can be used to provide a variety of services
-   including confidentiality and authentication.  Such services are
-   based on quantities, traditionally called "keys", that are unknown to
-   and unguessable by an adversary.
-
-   In some cases, such as the use of symmetric encryption with the one
-   time pads [CRYPTO*] or the US Data Encryption Standard [DES], the
-   parties who wish to communicate confidentially and/or with
-   authentication must all know the same secret key.  In other cases,
-   using what are called asymmetric or "public key" cryptographic
-   techniques, keys come in pairs.  One key of the pair is private and
-   must be kept secret by one party, the other is public and can be
-   published to the world.  It is computationally infeasible to
-   determine the private key from the public key [ASYMMETRIC, CRYPTO*].
-
-   The frequency and volume of the requirement for random quantities
-   differs greatly for different cryptographic systems.  Using pure RSA
-   [CRYPTO*], random quantities are required when the key pair is
-   generated, but thereafter any number of messages can be signed
-   without any further need for randomness.  The public key Digital
-   Signature Algorithm that has been proposed by the US National
-   Institute of Standards and Technology (NIST) requires good random
-   numbers for each signature.  And encrypting with a one time pad, in
-   principle the strongest possible encryption technique, requires a
-   volume of randomness equal to all the messages to be processed.
-
-   In most of these cases, an adversary can try to determine the
-   "secret" key by trial and error.  (This is possible as long as the
-   key is enough smaller than the message that the correct key can be
-   uniquely identified.)  The probability of an adversary succeeding at
-   this must be made acceptably low, depending on the particular
-   application.  The size of the space the adversary must search is
-   related to the amount of key "information" present in the information
-   theoretic sense [SHANNON].  This depends on the number of different
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 4]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   secret values possible and the probability of each value as follows:
-
-                      -----
-                       \
-        Bits-of-info =  \  - p   * log  ( p  )
-                        /     i       2    i
-                       /
-                      -----
-
-   where i varies from 1 to the number of possible secret values and p
-   sub i is the probability of the value numbered i.  (Since p sub i is
-   less than one, the log will be negative so each term in the sum will
-   be non-negative.)
-
-   If there are 2^n different values of equal probability, then n bits
-   of information are present and an adversary would, on the average,
-   have to try half of the values, or 2^(n-1) , before guessing the
-   secret quantity.  If the probability of different values is unequal,
-   then there is less information present and fewer guesses will, on
-   average, be required by an adversary.  In particular, any values that
-   the adversary can know are impossible, or are of low probability, can
-   be initially ignored by an adversary, who will search through the
-   more probable values first.
-
-   For example, consider a cryptographic system that uses 56 bit keys.
-   If these 56 bit keys are derived by using a fixed pseudo-random
-   number generator that is seeded with an 8 bit seed, then an adversary
-   needs to search through only 256 keys (by running the pseudo-random
-   number generator with every possible seed), not the 2^56 keys that
-   may at first appear to be the case. Only 8 bits of "information" are
-   in these 56 bit keys.
-
-3. Traditional Pseudo-Random Sequences
-
-   Most traditional sources of random numbers use deterministic sources
-   of "pseudo-random" numbers.  These typically start with a "seed"
-   quantity and use numeric or logical operations to produce a sequence
-   of values.
-
-   [KNUTH] has a classic exposition on pseudo-random numbers.
-   Applications he mentions are simulation of natural phenomena,
-   sampling, numerical analysis, testing computer programs, decision
-   making, and games.  None of these have the same characteristics as
-   the sort of security uses we are talking about.  Only in the last two
-   could there be an adversary trying to find the random quantity.
-   However, in these cases, the adversary normally has only a single
-   chance to use a guessed value.  In guessing passwords or attempting
-   to break an encryption scheme, the adversary normally has many,
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 5]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   perhaps unlimited, chances at guessing the correct value and should
-   be assumed to be aided by a computer.
-
-   For testing the "randomness" of numbers, Knuth suggests a variety of
-   measures including statistical and spectral.  These tests check
-   things like autocorrelation between different parts of a "random"
-   sequence or distribution of its values.  They could be met by a
-   constant stored random sequence, such as the "random" sequence
-   printed in the CRC Standard Mathematical Tables [CRC].
-
-   A typical pseudo-random number generation technique, known as a
-   linear congruence pseudo-random number generator, is modular
-   arithmetic where the N+1th value is calculated from the Nth value by
-
-        V    = ( V  * a + b )(Mod c)
-         N+1      N
-
-   The above technique has a strong relationship to linear shift
-   register pseudo-random number generators, which are well understood
-   cryptographically [SHIFT*].  In such generators bits are introduced
-   at one end of a shift register as the Exclusive Or (binary sum
-   without carry) of bits from selected fixed taps into the register.
-
-   For example:
-
-      +----+     +----+     +----+                      +----+
-      | B  | <-- | B  | <-- | B  | <--  . . . . . . <-- | B  | <-+
-      |  0 |     |  1 |     |  2 |                      |  n |   |
-      +----+     +----+     +----+                      +----+   |
-        |                     |            |                     |
-        |                     |            V                  +-----+
-        |                     V            +----------------> |     |
-        V                     +-----------------------------> | XOR |
-        +---------------------------------------------------> |     |
-                                                              +-----+
-
-
-       V    = ( ( V  * 2 ) + B .xor. B ... )(Mod 2^n)
-        N+1         N         0       2
-
-   The goodness of traditional pseudo-random number generator algorithms
-   is measured by statistical tests on such sequences.  Carefully chosen
-   values of the initial V and a, b, and c or the placement of shift
-   register tap in the above simple processes can produce excellent
-   statistics.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 6]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   These sequences may be adequate in simulations (Monte Carlo
-   experiments) as long as the sequence is orthogonal to the structure
-   of the space being explored.  Even there, subtle patterns may cause
-   problems.  However, such sequences are clearly bad for use in
-   security applications.  They are fully predictable if the initial
-   state is known.  Depending on the form of the pseudo-random number
-   generator, the sequence may be determinable from observation of a
-   short portion of the sequence [CRYPTO*, STERN].  For example, with
-   the generators above, one can determine V(n+1) given knowledge of
-   V(n).  In fact, it has been shown that with these techniques, even if
-   only one bit of the pseudo-random values is released, the seed can be
-   determined from short sequences.
-
-   Not only have linear congruent generators been broken, but techniques
-   are now known for breaking all polynomial congruent generators
-   [KRAWCZYK].
-
-4. Unpredictability
-
-   Randomness in the traditional sense described in section 3 is NOT the
-   same as the unpredictability required for security use.
-
-   For example, use of a widely available constant sequence, such as
-   that from the CRC tables, is very weak against an adversary. Once
-   they learn of or guess it, they can easily break all security, future
-   and past, based on the sequence [CRC].  Yet the statistical
-   properties of these tables are good.
-
-   The following sections describe the limitations of some randomness
-   generation techniques and sources.
-
-4.1 Problems with Clocks and Serial Numbers
-
-   Computer clocks, or similar operating system or hardware values,
-   provide significantly fewer real bits of unpredictability than might
-   appear from their specifications.
-
-   Tests have been done on clocks on numerous systems and it was found
-   that their behavior can vary widely and in unexpected ways.  One
-   version of an operating system running on one set of hardware may
-   actually provide, say, microsecond resolution in a clock while a
-   different configuration of the "same" system may always provide the
-   same lower bits and only count in the upper bits at much lower
-   resolution.  This means that successive reads on the clock may
-   produce identical values even if enough time has passed that the
-   value "should" change based on the nominal clock resolution. There
-   are also cases where frequently reading a clock can produce
-   artificial sequential values because of extra code that checks for
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 7]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   the clock being unchanged between two reads and increases it by one!
-   Designing portable application code to generate unpredictable numbers
-   based on such system clocks is particularly challenging because the
-   system designer does not always know the properties of the system
-   clocks that the code will execute on.
-
-   Use of a hardware serial number such as an Ethernet address may also
-   provide fewer bits of uniqueness than one would guess.  Such
-   quantities are usually heavily structured and subfields may have only
-   a limited range of possible values or values easily guessable based
-   on approximate date of manufacture or other data.  For example, it is
-   likely that most of the Ethernet cards installed on Digital Equipment
-   Corporation (DEC) hardware within DEC were manufactured by DEC
-   itself, which significantly limits the range of built in addresses.
-
-   Problems such as those described above related to clocks and serial
-   numbers make code to produce unpredictable quantities difficult if
-   the code is to be ported across a variety of computer platforms and
-   systems.
-
-4.2 Timing and Content of External Events
-
-   It is possible to measure the timing and content of mouse movement,
-   key strokes, and similar user events.  This is a reasonable source of
-   unguessable data with some qualifications.  On some machines, inputs
-   such as key strokes are buffered.  Even though the user's inter-
-   keystroke timing may have sufficient variation and unpredictability,
-   there might not be an easy way to access that variation.  Another
-   problem is that no standard method exists to sample timing details.
-   This makes it hard to build standard software intended for
-   distribution to a large range of machines based on this technique.
-
-   The amount of mouse movement or the keys actually hit are usually
-   easier to access than timings but may yield less unpredictability as
-   the user may provide highly repetitive input.
-
-   Other external events, such as network packet arrival times, can also
-   be used with care.  In particular, the possibility of manipulation of
-   such times by an adversary must be considered.
-
-4.3 The Fallacy of Complex Manipulation
-
-   One strategy which may give a misleading appearance of
-   unpredictability is to take a very complex algorithm (or an excellent
-   traditional pseudo-random number generator with good statistical
-   properties) and calculate a cryptographic key by starting with the
-   current value of a computer system clock as the seed.  An adversary
-   who knew roughly when the generator was started would have a
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 8]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   relatively small number of seed values to test as they would know
-   likely values of the system clock.  Large numbers of pseudo-random
-   bits could be generated but the search space an adversary would need
-   to check could be quite small.
-
-   Thus very strong and/or complex manipulation of data will not help if
-   the adversary can learn what the manipulation is and there is not
-   enough unpredictability in the starting seed value.  Even if they can
-   not learn what the manipulation is, they may be able to use the
-   limited number of results stemming from a limited number of seed
-   values to defeat security.
-
-   Another serious strategy error is to assume that a very complex
-   pseudo-random number generation algorithm will produce strong random
-   numbers when there has been no theory behind or analysis of the
-   algorithm.  There is a excellent example of this fallacy right near
-   the beginning of chapter 3 in [KNUTH] where the author describes a
-   complex algorithm.  It was intended that the machine language program
-   corresponding to the algorithm would be so complicated that a person
-   trying to read the code without comments wouldn't know what the
-   program was doing.  Unfortunately, actual use of this algorithm
-   showed that it almost immediately converged to a single repeated
-   value in one case and a small cycle of values in another case.
-
-   Not only does complex manipulation not help you if you have a limited
-   range of seeds but blindly chosen complex manipulation can destroy
-   the randomness in a good seed!
-
-4.4 The Fallacy of Selection from a Large Database
-
-   Another strategy that can give a misleading appearance of
-   unpredictability is selection of a quantity randomly from a database
-   and assume that its strength is related to the total number of bits
-   in the database.  For example, typical USENET servers as of this date
-   process over 35 megabytes of information per day.  Assume a random
-   quantity was selected by fetching 32 bytes of data from a random
-   starting point in this data.  This does not yield 32*8 = 256 bits
-   worth of unguessability.  Even after allowing that much of the data
-   is human language and probably has more like 2 or 3 bits of
-   information per byte, it doesn't yield 32*2.5 = 80 bits of
-   unguessability.  For an adversary with access to the same 35
-   megabytes the unguessability rests only on the starting point of the
-   selection.  That is, at best, about 25 bits of unguessability in this
-   case.
-
-   The same argument applies to selecting sequences from the data on a
-   CD ROM or Audio CD recording or any other large public database.  If
-   the adversary has access to the same database, this "selection from a
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 9]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   large volume of data" step buys very little.  However, if a selection
-   can be made from data to which the adversary has no access, such as
-   system buffers on an active multi-user system, it may be of some
-   help.
-
-5. Hardware for Randomness
-
-   Is there any hope for strong portable randomness in the future?
-   There might be.  All that's needed is a physical source of
-   unpredictable numbers.
-
-   A thermal noise or radioactive decay source and a fast, free-running
-   oscillator would do the trick directly [GIFFORD].  This is a trivial
-   amount of hardware, and could easily be included as a standard part
-   of a computer system's architecture.  Furthermore, any system with a
-   spinning disk or the like has an adequate source of randomness
-   [DAVIS].  All that's needed is the common perception among computer
-   vendors that this small additional hardware and the software to
-   access it is necessary and useful.
-
-5.1 Volume Required
-
-   How much unpredictability is needed?  Is it possible to quantify the
-   requirement in, say, number of random bits per second?
-
-   The answer is not very much is needed.  For DES, the key is 56 bits
-   and, as we show in an example in Section 8, even the highest security
-   system is unlikely to require a keying material of over 200 bits.  If
-   a series of keys are needed, it can be generated from a strong random
-   seed using a cryptographically strong sequence as explained in
-   Section 6.3.  A few hundred random bits generated once a day would be
-   enough using such techniques.  Even if the random bits are generated
-   as slowly as one per second and it is not possible to overlap the
-   generation process, it should be tolerable in high security
-   applications to wait 200 seconds occasionally.
-
-   These numbers are trivial to achieve.  It could be done by a person
-   repeatedly tossing a coin.  Almost any hardware process is likely to
-   be much faster.
-
-5.2 Sensitivity to Skew
-
-   Is there any specific requirement on the shape of the distribution of
-   the random numbers?  The good news is the distribution need not be
-   uniform.  All that is needed is a conservative estimate of how non-
-   uniform it is to bound performance.  Two simple techniques to de-skew
-   the bit stream are given below and stronger techniques are mentioned
-   in Section 6.1.2 below.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 10]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-5.2.1 Using Stream Parity to De-Skew
-
-   Consider taking a sufficiently long string of bits and map the string
-   to "zero" or "one".  The mapping will not yield a perfectly uniform
-   distribution, but it can be as close as desired.  One mapping that
-   serves the purpose is to take the parity of the string.  This has the
-   advantages that it is robust across all degrees of skew up to the
-   estimated maximum skew and is absolutely trivial to implement in
-   hardware.
-
-   The following analysis gives the number of bits that must be sampled:
-
-   Suppose the ratio of ones to zeros is 0.5 + e : 0.5 - e, where e is
-   between 0 and 0.5 and is a measure of the "eccentricity" of the
-   distribution.  Consider the distribution of the parity function of N
-   bit samples.  The probabilities that the parity will be one or zero
-   will be the sum of the odd or even terms in the binomial expansion of
-   (p + q)^N, where p = 0.5 + e, the probability of a one, and q = 0.5 -
-   e, the probability of a zero.
-
-   These sums can be computed easily as
-
-                         N            N
-        1/2 * ( ( p + q )  + ( p - q )  )
-   and
-                         N            N
-        1/2 * ( ( p + q )  - ( p - q )  ).
-
-   (Which one corresponds to the probability the parity will be 1
-   depends on whether N is odd or even.)
-
-   Since p + q = 1 and p - q = 2e, these expressions reduce to
-
-                       N
-        1/2 * [1 + (2e) ]
-   and
-                       N
-        1/2 * [1 - (2e) ].
-
-   Neither of these will ever be exactly 0.5 unless e is zero, but we
-   can bring them arbitrarily close to 0.5.  If we want the
-   probabilities to be within some delta d of 0.5, i.e. then
-
-                            N
-        ( 0.5 + ( 0.5 * (2e)  ) )  <  0.5 + d.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 11]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Solving for N yields N > log(2d)/log(2e).  (Note that 2e is less than
-   1, so its log is negative.  Division by a negative number reverses
-   the sense of an inequality.)
-
-   The following table gives the length of the string which must be
-   sampled for various degrees of skew in order to come within 0.001 of
-   a 50/50 distribution.
-
-                       +---------+--------+-------+
-                       | Prob(1) |    e   |    N  |
-                       +---------+--------+-------+
-                       |   0.5   |  0.00  |    1  |
-                       |   0.6   |  0.10  |    4  |
-                       |   0.7   |  0.20  |    7  |
-                       |   0.8   |  0.30  |   13  |
-                       |   0.9   |  0.40  |   28  |
-                       |   0.95  |  0.45  |   59  |
-                       |   0.99  |  0.49  |  308  |
-                       +---------+--------+-------+
-
-   The last entry shows that even if the distribution is skewed 99% in
-   favor of ones, the parity of a string of 308 samples will be within
-   0.001 of a 50/50 distribution.
-
-5.2.2 Using Transition Mappings to De-Skew
-
-   Another technique, originally due to von Neumann [VON NEUMANN], is to
-   examine a bit stream as a sequence of non-overlapping pairs. You
-   could then discard any 00 or 11 pairs found, interpret 01 as a 0 and
-   10 as a 1.  Assume the probability of a 1 is 0.5+e and the
-   probability of a 0 is 0.5-e where e is the eccentricity of the source
-   and described in the previous section.  Then the probability of each
-   pair is as follows:
-
-            +------+-----------------------------------------+
-            | pair |            probability                  |
-            +------+-----------------------------------------+
-            |  00  | (0.5 - e)^2          =  0.25 - e + e^2  |
-            |  01  | (0.5 - e)*(0.5 + e)  =  0.25     - e^2  |
-            |  10  | (0.5 + e)*(0.5 - e)  =  0.25     - e^2  |
-            |  11  | (0.5 + e)^2          =  0.25 + e + e^2  |
-            +------+-----------------------------------------+
-
-   This technique will completely eliminate any bias but at the expense
-   of taking an indeterminate number of input bits for any particular
-   desired number of output bits.  The probability of any particular
-   pair being discarded is 0.5 + 2e^2 so the expected number of input
-   bits to produce X output bits is X/(0.25 - e^2).
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 12]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   This technique assumes that the bits are from a stream where each bit
-   has the same probability of being a 0 or 1 as any other bit in the
-   stream and that bits are not correlated, i.e., that the bits are
-   identical independent distributions.  If alternate bits were from two
-   correlated sources, for example, the above analysis breaks down.
-
-   The above technique also provides another illustration of how a
-   simple statistical analysis can mislead if one is not always on the
-   lookout for patterns that could be exploited by an adversary.  If the
-   algorithm were mis-read slightly so that overlapping successive bits
-   pairs were used instead of non-overlapping pairs, the statistical
-   analysis given is the same; however, instead of provided an unbiased
-   uncorrelated series of random 1's and 0's, it instead produces a
-   totally predictable sequence of exactly alternating 1's and 0's.
-
-5.2.3 Using FFT to De-Skew
-
-   When real world data consists of strongly biased or correlated bits,
-   it may still contain useful amounts of randomness.  This randomness
-   can be extracted through use of the discrete Fourier transform or its
-   optimized variant, the FFT.
-
-   Using the Fourier transform of the data, strong correlations can be
-   discarded.  If adequate data is processed and remaining correlations
-   decay, spectral lines approaching statistical independence and
-   normally distributed randomness can be produced [BRILLINGER].
-
-5.2.4 Using Compression to De-Skew
-
-   Reversible compression techniques also provide a crude method of de-
-   skewing a skewed bit stream.  This follows directly from the
-   definition of reversible compression and the formula in Section 2
-   above for the amount of information in a sequence.  Since the
-   compression is reversible, the same amount of information must be
-   present in the shorter output than was present in the longer input.
-   By the Shannon information equation, this is only possible if, on
-   average, the probabilities of the different shorter sequences are
-   more uniformly distributed than were the probabilities of the longer
-   sequences.  Thus the shorter sequences are de-skewed relative to the
-   input.
-
-   However, many compression techniques add a somewhat predicatable
-   preface to their output stream and may insert such a sequence again
-   periodically in their output or otherwise introduce subtle patterns
-   of their own.  They should be considered only a rough technique
-   compared with those described above or in Section 6.1.2.  At a
-   minimum, the beginning of the compressed sequence should be skipped
-   and only later bits used for applications requiring random bits.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 13]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-5.3 Existing Hardware Can Be Used For Randomness
-
-   As described below, many computers come with hardware that can, with
-   care, be used to generate truly random quantities.
-
-5.3.1 Using Existing Sound/Video Input
-
-   Increasingly computers are being built with inputs that digitize some
-   real world analog source, such as sound from a microphone or video
-   input from a camera.  Under appropriate circumstances, such input can
-   provide reasonably high quality random bits.  The "input" from a
-   sound digitizer with no source plugged in or a camera with the lens
-   cap on, if the system has enough gain to detect anything, is
-   essentially thermal noise.
-
-   For example, on a SPARCstation, one can read from the /dev/audio
-   device with nothing plugged into the microphone jack.  Such data is
-   essentially random noise although it should not be trusted without
-   some checking in case of hardware failure.  It will, in any case,
-   need to be de-skewed as described elsewhere.
-
-   Combining this with compression to de-skew one can, in UNIXese,
-   generate a huge amount of medium quality random data by doing
-
-        cat /dev/audio | compress - >random-bits-file
-
-5.3.2 Using Existing Disk Drives
-
-   Disk drives have small random fluctuations in their rotational speed
-   due to chaotic air turbulence [DAVIS].  By adding low level disk seek
-   time instrumentation to a system, a series of measurements can be
-   obtained that include this randomness. Such data is usually highly
-   correlated so that significant processing is needed, including FFT
-   (see section 5.2.3).  Nevertheless experimentation has shown that,
-   with such processing, disk drives easily produce 100 bits a minute or
-   more of excellent random data.
-
-   Partly offsetting this need for processing is the fact that disk
-   drive failure will normally be rapidly noticed.  Thus, problems with
-   this method of random number generation due to hardware failure are
-   very unlikely.
-
-6. Recommended Non-Hardware Strategy
-
-   What is the best overall strategy for meeting the requirement for
-   unguessable random numbers in the absence of a reliable hardware
-   source?  It is to obtain random input from a large number of
-   uncorrelated sources and to mix them with a strong mixing function.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 14]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Such a function will preserve the randomness present in any of the
-   sources even if other quantities being combined are fixed or easily
-   guessable.  This may be advisable even with a good hardware source as
-   hardware can also fail, though this should be weighed against any
-   increase in the chance of overall failure due to added software
-   complexity.
-
-6.1 Mixing Functions
-
-   A strong mixing function is one which combines two or more inputs and
-   produces an output where each output bit is a different complex non-
-   linear function of all the input bits.  On average, changing any
-   input bit will change about half the output bits.  But because the
-   relationship is complex and non-linear, no particular output bit is
-   guaranteed to change when any particular input bit is changed.
-
-   Consider the problem of converting a stream of bits that is skewed
-   towards 0 or 1 to a shorter stream which is more random, as discussed
-   in Section 5.2 above.  This is simply another case where a strong
-   mixing function is desired, mixing the input bits to produce a
-   smaller number of output bits.  The technique given in Section 5.2.1
-   of using the parity of a number of bits is simply the result of
-   successively Exclusive Or'ing them which is examined as a trivial
-   mixing function immediately below.  Use of stronger mixing functions
-   to extract more of the randomness in a stream of skewed bits is
-   examined in Section 6.1.2.
-
-6.1.1 A Trivial Mixing Function
-
-   A trivial example for single bit inputs is the Exclusive Or function,
-   which is equivalent to addition without carry, as show in the table
-   below.  This is a degenerate case in which the one output bit always
-   changes for a change in either input bit.  But, despite its
-   simplicity, it will still provide a useful illustration.
-
-                   +-----------+-----------+----------+
-                   |  input 1  |  input 2  |  output  |
-                   +-----------+-----------+----------+
-                   |     0     |     0     |     0    |
-                   |     0     |     1     |     1    |
-                   |     1     |     0     |     1    |
-                   |     1     |     1     |     0    |
-                   +-----------+-----------+----------+
-
-   If inputs 1 and 2 are uncorrelated and combined in this fashion then
-   the output will be an even better (less skewed) random bit than the
-   inputs.  If we assume an "eccentricity" e as defined in Section 5.2
-   above, then the output eccentricity relates to the input eccentricity
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 15]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   as follows:
-
-        e       = 2 * e        * e
-         output        input 1    input 2
-
-   Since e is never greater than 1/2, the eccentricity is always
-   improved except in the case where at least one input is a totally
-   skewed constant.  This is illustrated in the following table where
-   the top and left side values are the two input eccentricities and the
-   entries are the output eccentricity:
-
-     +--------+--------+--------+--------+--------+--------+--------+
-     |    e   |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
-     +--------+--------+--------+--------+--------+--------+--------+
-     |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |
-     |  0.10  |  0.00  |  0.02  |  0.04  |  0.06  |  0.08  |  0.10  |
-     |  0.20  |  0.00  |  0.04  |  0.08  |  0.12  |  0.16  |  0.20  |
-     |  0.30  |  0.00  |  0.06  |  0.12  |  0.18  |  0.24  |  0.30  |
-     |  0.40  |  0.00  |  0.08  |  0.16  |  0.24  |  0.32  |  0.40  |
-     |  0.50  |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
-     +--------+--------+--------+--------+--------+--------+--------+
-
-   However, keep in mind that the above calculations assume that the
-   inputs are not correlated.  If the inputs were, say, the parity of
-   the number of minutes from midnight on two clocks accurate to a few
-   seconds, then each might appear random if sampled at random intervals
-   much longer than a minute.  Yet if they were both sampled and
-   combined with xor, the result would be zero most of the time.
-
-6.1.2 Stronger Mixing Functions
-
-   The US Government Data Encryption Standard [DES] is an example of a
-   strong mixing function for multiple bit quantities.  It takes up to
-   120 bits of input (64 bits of "data" and 56 bits of "key") and
-   produces 64 bits of output each of which is dependent on a complex
-   non-linear function of all input bits.  Other strong encryption
-   functions with this characteristic can also be used by considering
-   them to mix all of their key and data input bits.
-
-   Another good family of mixing functions are the "message digest" or
-   hashing functions such as The US Government Secure Hash Standard
-   [SHS] and the MD2, MD4, MD5 [MD2, MD4, MD5] series.  These functions
-   all take an arbitrary amount of input and produce an output mixing
-   all the input bits. The MD* series produce 128 bits of output and SHS
-   produces 160 bits.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 16]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Although the message digest functions are designed for variable
-   amounts of input, DES and other encryption functions can also be used
-   to combine any number of inputs.  If 64 bits of output is adequate,
-   the inputs can be packed into a 64 bit data quantity and successive
-   56 bit keys, padding with zeros if needed, which are then used to
-   successively encrypt using DES in Electronic Codebook Mode [DES
-   MODES].  If more than 64 bits of output are needed, use more complex
-   mixing.  For example, if inputs are packed into three quantities, A,
-   B, and C, use DES to encrypt A with B as a key and then with C as a
-   key to produce the 1st part of the output, then encrypt B with C and
-   then A for more output and, if necessary, encrypt C with A and then B
-   for yet more output.  Still more output can be produced by reversing
-   the order of the keys given above to stretch things. The same can be
-   done with the hash functions by hashing various subsets of the input
-   data to produce multiple outputs.  But keep in mind that it is
-   impossible to get more bits of "randomness" out than are put in.
-
-   An example of using a strong mixing function would be to reconsider
-   the case of a string of 308 bits each of which is biased 99% towards
-   zero.  The parity technique given in Section 5.2.1 above reduced this
-   to one bit with only a 1/1000 deviance from being equally likely a
-   zero or one.  But, applying the equation for information given in
-   Section 2, this 308 bit sequence has 5 bits of information in it.
-   Thus hashing it with SHS or MD5 and taking the bottom 5 bits of the
-   result would yield 5 unbiased random bits as opposed to the single
-   bit given by calculating the parity of the string.
-
-6.1.3 Diffie-Hellman as a Mixing Function
-
-   Diffie-Hellman exponential key exchange is a technique that yields a
-   shared secret between two parties that can be made computationally
-   infeasible for a third party to determine even if they can observe
-   all the messages between the two communicating parties.  This shared
-   secret is a mixture of initial quantities generated by each of them
-   [D-H].  If these initial quantities are random, then the shared
-   secret contains the combined randomness of them both, assuming they
-   are uncorrelated.
-
-6.1.4 Using a Mixing Function to Stretch Random Bits
-
-   While it is not necessary for a mixing function to produce the same
-   or fewer bits than its inputs, mixing bits cannot "stretch" the
-   amount of random unpredictability present in the inputs.  Thus four
-   inputs of 32 bits each where there is 12 bits worth of
-   unpredicatability (such as 4,096 equally probable values) in each
-   input cannot produce more than 48 bits worth of unpredictable output.
-   The output can be expanded to hundreds or thousands of bits by, for
-   example, mixing with successive integers, but the clever adversary's
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 17]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   search space is still 2^48 possibilities.  Furthermore, mixing to
-   fewer bits than are input will tend to strengthen the randomness of
-   the output the way using Exclusive Or to produce one bit from two did
-   above.
-
-   The last table in Section 6.1.1 shows that mixing a random bit with a
-   constant bit with Exclusive Or will produce a random bit.  While this
-   is true, it does not provide a way to "stretch" one random bit into
-   more than one.  If, for example, a random bit is mixed with a 0 and
-   then with a 1, this produces a two bit sequence but it will always be
-   either 01 or 10.  Since there are only two possible values, there is
-   still only the one bit of original randomness.
-
-6.1.5 Other Factors in Choosing a Mixing Function
-
-   For local use, DES has the advantages that it has been widely tested
-   for flaws, is widely documented, and is widely implemented with
-   hardware and software implementations available all over the world
-   including source code available by anonymous FTP.  The SHS and MD*
-   family are younger algorithms which have been less tested but there
-   is no particular reason to believe they are flawed.  Both MD5 and SHS
-   were derived from the earlier MD4 algorithm.  They all have source
-   code available by anonymous FTP [SHS, MD2, MD4, MD5].
-
-   DES and SHS have been vouched for the the US National Security Agency
-   (NSA) on the basis of criteria that primarily remain secret.  While
-   this is the cause of much speculation and doubt, investigation of DES
-   over the years has indicated that NSA involvement in modifications to
-   its design, which originated with IBM, was primarily to strengthen
-   it.  No concealed or special weakness has been found in DES.  It is
-   almost certain that the NSA modification to MD4 to produce the SHS
-   similarly strengthened the algorithm, possibly against threats not
-   yet known in the public cryptographic community.
-
-   DES, SHS, MD4, and MD5 are royalty free for all purposes.  MD2 has
-   been freely licensed only for non-profit use in connection with
-   Privacy Enhanced Mail [PEM].  Between the MD* algorithms, some people
-   believe that, as with "Goldilocks and the Three Bears", MD2 is strong
-   but too slow, MD4 is fast but too weak, and MD5 is just right.
-
-   Another advantage of the MD* or similar hashing algorithms over
-   encryption algorithms is that they are not subject to the same
-   regulations imposed by the US Government prohibiting the unlicensed
-   export or import of encryption/decryption software and hardware.  The
-   same should be true of DES rigged to produce an irreversible hash
-   code but most DES packages are oriented to reversible encryption.
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 18]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-6.2 Non-Hardware Sources of Randomness
-
-   The best source of input for mixing would be a hardware randomness
-   such as disk drive timing affected by air turbulence, audio input
-   with thermal noise, or radioactive decay.  However, if that is not
-   available there are other possibilities.  These include system
-   clocks, system or input/output buffers, user/system/hardware/network
-   serial numbers and/or addresses and timing, and user input.
-   Unfortunately, any of these sources can produce limited or
-   predicatable values under some circumstances.
-
-   Some of the sources listed above would be quite strong on multi-user
-   systems where, in essence, each user of the system is a source of
-   randomness.  However, on a small single user system, such as a
-   typical IBM PC or Apple Macintosh, it might be possible for an
-   adversary to assemble a similar configuration.  This could give the
-   adversary inputs to the mixing process that were sufficiently
-   correlated to those used originally as to make exhaustive search
-   practical.
-
-   The use of multiple random inputs with a strong mixing function is
-   recommended and can overcome weakness in any particular input.  For
-   example, the timing and content of requested "random" user keystrokes
-   can yield hundreds of random bits but conservative assumptions need
-   to be made.  For example, assuming a few bits of randomness if the
-   inter-keystroke interval is unique in the sequence up to that point
-   and a similar assumption if the key hit is unique but assuming that
-   no bits of randomness are present in the initial key value or if the
-   timing or key value duplicate previous values.  The results of mixing
-   these timings and characters typed could be further combined with
-   clock values and other inputs.
-
-   This strategy may make practical portable code to produce good random
-   numbers for security even if some of the inputs are very weak on some
-   of the target systems.  However, it may still fail against a high
-   grade attack on small single user systems, especially if the
-   adversary has ever been able to observe the generation process in the
-   past.  A hardware based random source is still preferable.
-
-6.3 Cryptographically Strong Sequences
-
-   In cases where a series of random quantities must be generated, an
-   adversary may learn some values in the sequence.  In general, they
-   should not be able to predict other values from the ones that they
-   know.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 19]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   The correct technique is to start with a strong random seed, take
-   cryptographically strong steps from that seed [CRYPTO2, CRYPTO3], and
-   do not reveal the complete state of the generator in the sequence
-   elements.  If each value in the sequence can be calculated in a fixed
-   way from the previous value, then when any value is compromised, all
-   future values can be determined.  This would be the case, for
-   example, if each value were a constant function of the previously
-   used values, even if the function were a very strong, non-invertible
-   message digest function.
-
-   It should be noted that if your technique for generating a sequence
-   of key values is fast enough, it can trivially be used as the basis
-   for a confidentiality system.  If two parties use the same sequence
-   generating technique and start with the same seed material, they will
-   generate identical sequences.  These could, for example, be xor'ed at
-   one end with data being send, encrypting it, and xor'ed with this
-   data as received, decrypting it due to the reversible properties of
-   the xor operation.
-
-6.3.1 Traditional Strong Sequences
-
-   A traditional way to achieve a strong sequence has been to have the
-   values be produced by hashing the quantities produced by
-   concatenating the seed with successive integers or the like and then
-   mask the values obtained so as to limit the amount of generator state
-   available to the adversary.
-
-   It may also be possible to use an "encryption" algorithm with a
-   random key and seed value to encrypt and feedback some or all of the
-   output encrypted value into the value to be encrypted for the next
-   iteration.  Appropriate feedback techniques will usually be
-   recommended with the encryption algorithm.  An example is shown below
-   where shifting and masking are used to combine the cypher output
-   feedback.  This type of feedback is recommended by the US Government
-   in connection with DES [DES MODES].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 20]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-      +---------------+
-      |       V       |
-      |  |     n      |
-      +--+------------+
-            |      |           +---------+
-            |      +---------> |         |      +-----+
-         +--+                  | Encrypt | <--- | Key |
-         |           +-------- |         |      +-----+
-         |           |         +---------+
-         V           V
-      +------------+--+
-      |      V     |  |
-      |       n+1     |
-      +---------------+
-
-   Note that if a shift of one is used, this is the same as the shift
-   register technique described in Section 3 above but with the all
-   important difference that the feedback is determined by a complex
-   non-linear function of all bits rather than a simple linear or
-   polynomial combination of output from a few bit position taps.
-
-   It has been shown by Donald W. Davies that this sort of shifted
-   partial output feedback significantly weakens an algorithm compared
-   will feeding all of the output bits back as input.  In particular,
-   for DES, repeated encrypting a full 64 bit quantity will give an
-   expected repeat in about 2^63 iterations.  Feeding back anything less
-   than 64 (and more than 0) bits will give an expected repeat in
-   between 2**31 and 2**32 iterations!
-
-   To predict values of a sequence from others when the sequence was
-   generated by these techniques is equivalent to breaking the
-   cryptosystem or inverting the "non-invertible" hashing involved with
-   only partial information available.  The less information revealed
-   each iteration, the harder it will be for an adversary to predict the
-   sequence.  Thus it is best to use only one bit from each value.  It
-   has been shown that in some cases this makes it impossible to break a
-   system even when the cryptographic system is invertible and can be
-   broken if all of each generated value was revealed.
-
-6.3.2 The Blum Blum Shub Sequence Generator
-
-   Currently the generator which has the strongest public proof of
-   strength is called the Blum Blum Shub generator after its inventors
-   [BBS].  It is also very simple and is based on quadratic residues.
-   It's only disadvantage is that is is computationally intensive
-   compared with the traditional techniques give in 6.3.1 above.  This
-   is not a serious draw back if it is used for moderately infrequent
-   purposes, such as generating session keys.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 21]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Simply choose two large prime numbers, say p and q, which both have
-   the property that you get a remainder of 3 if you divide them by 4.
-   Let n = p * q.  Then you choose a random number x relatively prime to
-   n.  The initial seed for the generator and the method for calculating
-   subsequent values are then
-
-                   2
-        s    =  ( x  )(Mod n)
-         0
-
-                   2
-        s    = ( s   )(Mod n)
-         i+1      i
-
-   You must be careful to use only a few bits from the bottom of each s.
-   It is always safe to use only the lowest order bit.  If you use no
-   more than the
-
-                  log  ( log  ( s  ) )
-                     2      2    i
-
-   low order bits, then predicting any additional bits from a sequence
-   generated in this manner is provable as hard as factoring n.  As long
-   as the initial x is secret, you can even make n public if you want.
-
-   An intersting characteristic of this generator is that you can
-   directly calculate any of the s values.  In particular
-
-                     i
-               ( ( 2  )(Mod (( p - 1 ) * ( q - 1 )) ) )
-      s  = ( s                                          )(Mod n)
-       i      0
-
-   This means that in applications where many keys are generated in this
-   fashion, it is not necessary to save them all.  Each key can be
-   effectively indexed and recovered from that small index and the
-   initial s and n.
-
-7. Key Generation Standards
-
-   Several public standards are now in place for the generation of keys.
-   Two of these are described below.  Both use DES but any equally
-   strong or stronger mixing function could be substituted.
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 22]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-7.1 US DoD Recommendations for Password Generation
-
-   The United States Department of Defense has specific recommendations
-   for password generation [DoD].  They suggest using the US Data
-   Encryption Standard [DES] in Output Feedback Mode [DES MODES] as
-   follows:
-
-        use an initialization vector determined from
-             the system clock,
-             system ID,
-             user ID, and
-             date and time;
-        use a key determined from
-             system interrupt registers,
-             system status registers, and
-             system counters; and,
-        as plain text, use an external randomly generated 64 bit
-        quantity such as 8 characters typed in by a system
-        administrator.
-
-   The password can then be calculated from the 64 bit "cipher text"
-   generated in 64-bit Output Feedback Mode.  As many bits as are needed
-   can be taken from these 64 bits and expanded into a pronounceable
-   word, phrase, or other format if a human being needs to remember the
-   password.
-
-7.2 X9.17 Key Generation
-
-   The American National Standards Institute has specified a method for
-   generating a sequence of keys as follows:
-
-        s  is the initial 64 bit seed
-         0
-
-        g  is the sequence of generated 64 bit key quantities
-         n
-
-        k is a random key reserved for generating this key sequence
-
-        t is the time at which a key is generated to as fine a resolution
-            as is available (up to 64 bits).
-
-        DES ( K, Q ) is the DES encryption of quantity Q with key K
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 23]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-        g    = DES ( k, DES ( k, t ) .xor. s  )
-         n                                  n
-
-        s    = DES ( k, DES ( k, t ) .xor. g  )
-         n+1                                n
-
-   If g sub n is to be used as a DES key, then every eighth bit should
-   be adjusted for parity for that use but the entire 64 bit unmodified
-   g should be used in calculating the next s.
-
-8. Examples of Randomness Required
-
-   Below are two examples showing rough calculations of needed
-   randomness for security.  The first is for moderate security
-   passwords while the second assumes a need for a very high security
-   cryptographic key.
-
-8.1  Password Generation
-
-   Assume that user passwords change once a year and it is desired that
-   the probability that an adversary could guess the password for a
-   particular account be less than one in a thousand.  Further assume
-   that sending a password to the system is the only way to try a
-   password.  Then the crucial question is how often an adversary can
-   try possibilities.  Assume that delays have been introduced into a
-   system so that, at most, an adversary can make one password try every
-   six seconds.  That's 600 per hour or about 15,000 per day or about
-   5,000,000 tries in a year.  Assuming any sort of monitoring, it is
-   unlikely someone could actually try continuously for a year.  In
-   fact, even if log files are only checked monthly, 500,000 tries is
-   more plausible before the attack is noticed and steps taken to change
-   passwords and make it harder to try more passwords.
-
-   To have a one in a thousand chance of guessing the password in
-   500,000 tries implies a universe of at least 500,000,000 passwords or
-   about 2^29.  Thus 29 bits of randomness are needed. This can probably
-   be achieved using the US DoD recommended inputs for password
-   generation as it has 8 inputs which probably average over 5 bits of
-   randomness each (see section 7.1).  Using a list of 1000 words, the
-   password could be expressed as a three word phrase (1,000,000,000
-   possibilities) or, using case insensitive letters and digits, six
-   would suffice ((26+10)^6 = 2,176,782,336 possibilities).
-
-   For a higher security password, the number of bits required goes up.
-   To decrease the probability by 1,000 requires increasing the universe
-   of passwords by the same factor which adds about 10 bits.  Thus to
-   have only a one in a million chance of a password being guessed under
-   the above scenario would require 39 bits of randomness and a password
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 24]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   that was a four word phrase from a 1000 word list or eight
-   letters/digits.  To go to a one in 10^9 chance, 49 bits of randomness
-   are needed implying a five word phrase or ten letter/digit password.
-
-   In a real system, of course, there are also other factors.  For
-   example, the larger and harder to remember passwords are, the more
-   likely users are to write them down resulting in an additional risk
-   of compromise.
-
-8.2 A Very High Security Cryptographic Key
-
-   Assume that a very high security key is needed for symmetric
-   encryption / decryption between two parties.  Assume an adversary can
-   observe communications and knows the algorithm being used.  Within
-   the field of random possibilities, the adversary can try key values
-   in hopes of finding the one in use.  Assume further that brute force
-   trial of keys is the best the adversary can do.
-
-8.2.1 Effort per Key Trial
-
-   How much effort will it take to try each key?  For very high security
-   applications it is best to assume a low value of effort.  Even if it
-   would clearly take tens of thousands of computer cycles or more to
-   try a single key, there may be some pattern that enables huge blocks
-   of key values to be tested with much less effort per key.  Thus it is
-   probably best to assume no more than a couple hundred cycles per key.
-   (There is no clear lower bound on this as computers operate in
-   parallel on a number of bits and a poor encryption algorithm could
-   allow many keys or even groups of keys to be tested in parallel.
-   However, we need to assume some value and can hope that a reasonably
-   strong algorithm has been chosen for our hypothetical high security
-   task.)
-
-   If the adversary can command a highly parallel processor or a large
-   network of work stations, 2*10^10 cycles per second is probably a
-   minimum assumption for availability today.  Looking forward just a
-   couple years, there should be at least an order of magnitude
-   improvement.  Thus assuming 10^9 keys could be checked per second or
-   3.6*10^11 per hour or 6*10^13 per week or 2.4*10^14 per month is
-   reasonable.  This implies a need for a minimum of 51 bits of
-   randomness in keys to be sure they cannot be found in a month.  Even
-   then it is possible that, a few years from now, a highly determined
-   and resourceful adversary could break the key in 2 weeks (on average
-   they need try only half the keys).
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 25]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-8.2.2 Meet in the Middle Attacks
-
-   If chosen or known plain text and the resulting encrypted text are
-   available, a "meet in the middle" attack is possible if the structure
-   of the encryption algorithm allows it.  (In a known plain text
-   attack, the adversary knows all or part of the messages being
-   encrypted, possibly some standard header or trailer fields.  In a
-   chosen plain text attack, the adversary can force some chosen plain
-   text to be encrypted, possibly by "leaking" an exciting text that
-   would then be sent by the adversary over an encrypted channel.)
-
-   An oversimplified explanation of the meet in the middle attack is as
-   follows: the adversary can half-encrypt the known or chosen plain
-   text with all possible first half-keys, sort the output, then half-
-   decrypt the encoded text with all the second half-keys.  If a match
-   is found, the full key can be assembled from the halves and used to
-   decrypt other parts of the message or other messages.  At its best,
-   this type of attack can halve the exponent of the work required by
-   the adversary while adding a large but roughly constant factor of
-   effort.  To be assured of safety against this, a doubling of the
-   amount of randomness in the key to a minimum of 102 bits is required.
-
-   The meet in the middle attack assumes that the cryptographic
-   algorithm can be decomposed in this way but we can not rule that out
-   without a deep knowledge of the algorithm.  Even if a basic algorithm
-   is not subject to a meet in the middle attack, an attempt to produce
-   a stronger algorithm by applying the basic algorithm twice (or two
-   different algorithms sequentially) with different keys may gain less
-   added security than would be expected.  Such a composite algorithm
-   would be subject to a meet in the middle attack.
-
-   Enormous resources may be required to mount a meet in the middle
-   attack but they are probably within the range of the national
-   security services of a major nation.  Essentially all nations spy on
-   other nations government traffic and several nations are believed to
-   spy on commercial traffic for economic advantage.
-
-8.2.3 Other Considerations
-
-   Since we have not even considered the possibilities of special
-   purpose code breaking hardware or just how much of a safety margin we
-   want beyond our assumptions above, probably a good minimum for a very
-   high security cryptographic key is 128 bits of randomness which
-   implies a minimum key length of 128 bits.  If the two parties agree
-   on a key by Diffie-Hellman exchange [D-H], then in principle only
-   half of this randomness would have to be supplied by each party.
-   However, there is probably some correlation between their random
-   inputs so it is probably best to assume that each party needs to
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 26]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   provide at least 96 bits worth of randomness for very high security
-   if Diffie-Hellman is used.
-
-   This amount of randomness is beyond the limit of that in the inputs
-   recommended by the US DoD for password generation and could require
-   user typing timing, hardware random number generation, or other
-   sources.
-
-   It should be noted that key length calculations such at those above
-   are controversial and depend on various assumptions about the
-   cryptographic algorithms in use.  In some cases, a professional with
-   a deep knowledge of code breaking techniques and of the strength of
-   the algorithm in use could be satisfied with less than half of the
-   key size derived above.
-
-9. Conclusion
-
-   Generation of unguessable "random" secret quantities for security use
-   is an essential but difficult task.
-
-   We have shown that hardware techniques to produce such randomness
-   would be relatively simple.  In particular, the volume and quality
-   would not need to be high and existing computer hardware, such as
-   disk drives, can be used.  Computational techniques are available to
-   process low quality random quantities from multiple sources or a
-   larger quantity of such low quality input from one source and produce
-   a smaller quantity of higher quality, less predictable key material.
-   In the absence of hardware sources of randomness, a variety of user
-   and software sources can frequently be used instead with care;
-   however, most modern systems already have hardware, such as disk
-   drives or audio input, that could be used to produce high quality
-   randomness.
-
-   Once a sufficient quantity of high quality seed key material (a few
-   hundred bits) is available, strong computational techniques are
-   available to produce cryptographically strong sequences of
-   unpredicatable quantities from this seed material.
-
-10. Security Considerations
-
-   The entirety of this document concerns techniques and recommendations
-   for generating unguessable "random" quantities for use as passwords,
-   cryptographic keys, and similar security uses.
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 27]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-References
-
-   [ASYMMETRIC] - Secure Communications and Asymmetric Cryptosystems,
-   edited by Gustavus J. Simmons, AAAS Selected Symposium 69, Westview
-   Press, Inc.
-
-   [BBS] - A Simple Unpredictable Pseudo-Random Number Generator, SIAM
-   Journal on Computing, v. 15, n. 2, 1986, L. Blum, M. Blum, & M. Shub.
-
-   [BRILLINGER] - Time Series: Data Analysis and Theory, Holden-Day,
-   1981, David Brillinger.
-
-   [CRC] - C.R.C. Standard Mathematical Tables, Chemical Rubber
-   Publishing Company.
-
-   [CRYPTO1] - Cryptography: A Primer, A Wiley-Interscience Publication,
-   John Wiley & Sons, 1981, Alan G. Konheim.
-
-   [CRYPTO2] - Cryptography:  A New Dimension in Computer Data Security,
-   A Wiley-Interscience Publication, John Wiley & Sons, 1982, Carl H.
-   Meyer & Stephen M. Matyas.
-
-   [CRYPTO3] - Applied Cryptography: Protocols, Algorithms, and Source
-   Code in C, John Wiley & Sons, 1994, Bruce Schneier.
-
-   [DAVIS] - Cryptographic Randomness from Air Turbulence in Disk
-   Drives, Advances in Cryptology - Crypto '94, Springer-Verlag Lecture
-   Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and
-   Philip Fenstermacher.
-
-   [DES] -  Data Encryption Standard, United States of America,
-   Department of Commerce, National Institute of Standards and
-   Technology, Federal Information Processing Standard (FIPS) 46-1.
-   - Data Encryption Algorithm, American National Standards Institute,
-   ANSI X3.92-1981.
-   (See also FIPS 112, Password Usage, which includes FORTRAN code for
-   performing DES.)
-
-   [DES MODES] - DES Modes of Operation, United States of America,
-   Department of Commerce, National Institute of Standards and
-   Technology, Federal Information Processing Standard (FIPS) 81.
-   - Data Encryption Algorithm - Modes of Operation, American National
-   Standards Institute, ANSI X3.106-1983.
-
-   [D-H] - New Directions in Cryptography, IEEE Transactions on
-   Information Technology, November, 1976, Whitfield Diffie and Martin
-   E. Hellman.
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 28]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   [DoD] - Password Management Guideline, United States of America,
-   Department of Defense, Computer Security Center, CSC-STD-002-85.
-   (See also FIPS 112, Password Usage, which incorporates CSC-STD-002-85
-   as one of its appendices.)
-
-   [GIFFORD] - Natural Random Number, MIT/LCS/TM-371, September 1988,
-   David K. Gifford
-
-   [KNUTH] - The Art of Computer Programming, Volume 2: Seminumerical
-   Algorithms, Chapter 3: Random Numbers. Addison Wesley Publishing
-   Company, Second Edition 1982, Donald E. Knuth.
-
-   [KRAWCZYK] - How to Predict Congruential Generators, Journal of
-   Algorithms, V. 13, N. 4, December 1992, H. Krawczyk
-
-   [MD2] - The MD2 Message-Digest Algorithm, RFC1319, April 1992, B.
-   Kaliski
-   [MD4] - The MD4 Message-Digest Algorithm, RFC1320, April 1992, R.
-   Rivest
-   [MD5] - The MD5 Message-Digest Algorithm, RFC1321, April 1992, R.
-   Rivest
-
-   [PEM] - RFCs 1421 through 1424:
-   - RFC 1424, Privacy Enhancement for Internet Electronic Mail: Part
-   IV: Key Certification and Related Services, 02/10/1993, B. Kaliski
-   - RFC 1423, Privacy Enhancement for Internet Electronic Mail: Part
-   III: Algorithms, Modes, and Identifiers, 02/10/1993, D. Balenson
-   - RFC 1422, Privacy Enhancement for Internet Electronic Mail: Part
-   II: Certificate-Based Key Management, 02/10/1993, S. Kent
-   - RFC 1421, Privacy Enhancement for Internet Electronic Mail: Part I:
-   Message Encryption and Authentication Procedures, 02/10/1993, J. Linn
-
-   [SHANNON] - The Mathematical Theory of Communication, University of
-   Illinois Press, 1963, Claude E. Shannon.  (originally from:  Bell
-   System Technical Journal, July and October 1948)
-
-   [SHIFT1] - Shift Register Sequences, Aegean Park Press, Revised
-   Edition 1982, Solomon W. Golomb.
-
-   [SHIFT2] - Cryptanalysis of Shift-Register Generated Stream Cypher
-   Systems, Aegean Park Press, 1984, Wayne G. Barker.
-
-   [SHS] - Secure Hash Standard, United States of American, National
-   Institute of Science and Technology, Federal Information Processing
-   Standard (FIPS) 180, April 1993.
-
-   [STERN] - Secret Linear Congruential Generators are not
-   Cryptograhically Secure, Proceedings of IEEE STOC, 1987, J. Stern.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 29]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   [VON NEUMANN] - Various techniques used in connection with random
-   digits, von Neumann's Collected Works, Vol. 5, Pergamon Press, 1963,
-   J. von Neumann.
-
-Authors' Addresses
-
-   Donald E. Eastlake 3rd
-   Digital Equipment Corporation
-   550 King Street, LKG2-1/BB3
-   Littleton, MA 01460
-
-   Phone:   +1 508 486 6577(w)  +1 508 287 4877(h)
-   EMail:   dee@lkg.dec.com
-
-
-   Stephen D. Crocker
-   CyberCash Inc.
-   2086 Hunters Crest Way
-   Vienna, VA 22181
-
-   Phone:   +1 703-620-1222(w)  +1 703-391-2651 (fax)
-   EMail:   crocker@cybercash.com
-
-
-   Jeffrey I. Schiller
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-
-   Phone:   +1 617 253 0161(w)
-   EMail:   jis@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 30]
-
diff --git a/doc/rfc/rfc1876.txt b/doc/rfc/rfc1876.txt
deleted file mode 100644
index a289cffe..00000000
--- a/doc/rfc/rfc1876.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           C. Davis
-Request for Comments: 1876                             Kapor Enterprises
-Updates: 1034, 1035                                             P. Vixie
-Category: Experimental                                 Vixie Enterprises
-                                                              T. Goodwin
-                                                            FORE Systems
-                                                            I. Dickinson
-                                                   University of Warwick
-                                                            January 1996
-
-
- A Means for Expressing Location Information in the Domain Name System
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  This memo does not specify an Internet standard of any
-   kind.  Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-1. Abstract
-
-   This memo defines a new DNS RR type for experimental purposes.  This
-   RFC describes a mechanism to allow the DNS to carry location
-   information about hosts, networks, and subnets.  Such information for
-   a small subset of hosts is currently contained in the flat-file UUCP
-   maps.  However, just as the DNS replaced the use of HOSTS.TXT to
-   carry host and network address information, it is possible to replace
-   the UUCP maps as carriers of location information.
-
-   This RFC defines the format of a new Resource Record (RR) for the
-   Domain Name System (DNS), and reserves a corresponding DNS type
-   mnemonic (LOC) and numerical code (29).
-
-   This RFC assumes that the reader is familiar with the DNS [RFC 1034,
-   RFC 1035].  The data shown in our examples is for pedagogical use and
-   does not necessarily reflect the real Internet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 1]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-2. RDATA Format
-
-       MSB                                           LSB
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      0|        VERSION        |         SIZE          |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      2|       HORIZ PRE       |       VERT PRE        |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      4|                   LATITUDE                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      6|                   LATITUDE                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      8|                   LONGITUDE                   |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-     10|                   LONGITUDE                   |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-     12|                   ALTITUDE                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-     14|                   ALTITUDE                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   (octet)
-
-where:
-
-VERSION      Version number of the representation.  This must be zero.
-             Implementations are required to check this field and make
-             no assumptions about the format of unrecognized versions.
-
-SIZE         The diameter of a sphere enclosing the described entity, in
-             centimeters, expressed as a pair of four-bit unsigned
-             integers, each ranging from zero to nine, with the most
-             significant four bits representing the base and the second
-             number representing the power of ten by which to multiply
-             the base.  This allows sizes from 0e0 (<1cm) to 9e9
-             (90,000km) to be expressed.  This representation was chosen
-             such that the hexadecimal representation can be read by
-             eye; 0x15 = 1e5.  Four-bit values greater than 9 are
-             undefined, as are values with a base of zero and a non-zero
-             exponent.
-
-             Since 20000000m (represented by the value 0x29) is greater
-             than the equatorial diameter of the WGS 84 ellipsoid
-             (12756274m), it is therefore suitable for use as a
-             "worldwide" size.
-
-HORIZ PRE    The horizontal precision of the data, in centimeters,
-             expressed using the same representation as SIZE.  This is
-             the diameter of the horizontal "circle of error", rather
-
-
-
-Davis, et al                  Experimental                      [Page 2]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-             than a "plus or minus" value.  (This was chosen to match
-             the interpretation of SIZE; to get a "plus or minus" value,
-             divide by 2.)
-
-VERT PRE     The vertical precision of the data, in centimeters,
-             expressed using the sane representation as for SIZE.  This
-             is the total potential vertical error, rather than a "plus
-             or minus" value.  (This was chosen to match the
-             interpretation of SIZE; to get a "plus or minus" value,
-             divide by 2.)  Note that if altitude above or below sea
-             level is used as an approximation for altitude relative to
-             the [WGS 84] ellipsoid, the precision value should be
-             adjusted.
-
-LATITUDE     The latitude of the center of the sphere described by the
-             SIZE field, expressed as a 32-bit integer, most significant
-             octet first (network standard byte order), in thousandths
-             of a second of arc.  2^31 represents the equator; numbers
-             above that are north latitude.
-
-LONGITUDE    The longitude of the center of the sphere described by the
-             SIZE field, expressed as a 32-bit integer, most significant
-             octet first (network standard byte order), in thousandths
-             of a second of arc, rounded away from the prime meridian.
-             2^31 represents the prime meridian; numbers above that are
-             east longitude.
-
-ALTITUDE     The altitude of the center of the sphere described by the
-             SIZE field, expressed as a 32-bit integer, most significant
-             octet first (network standard byte order), in centimeters,
-             from a base of 100,000m below the [WGS 84] reference
-             spheroid used by GPS (semimajor axis a=6378137.0,
-             reciprocal flattening rf=298.257223563).  Altitude above
-             (or below) sea level may be used as an approximation of
-             altitude relative to the the [WGS 84] spheroid, though due
-             to the Earth's surface not being a perfect spheroid, there
-             will be differences.  (For example, the geoid (which sea
-             level approximates) for the continental US ranges from 10
-             meters to 50 meters below the [WGS 84] spheroid.
-             Adjustments to ALTITUDE and/or VERT PRE will be necessary
-             in most cases.  The Defense Mapping Agency publishes geoid
-             height values relative to the [WGS 84] ellipsoid.
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 3]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-3. Master File Format
-
-   The LOC record is expressed in a master file in the following format:
-
-   <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
-                               {"E"|"W"} alt["m"] [siz["m"] [hp["m"]
-                               [vp["m"]]]] )
-
-   (The parentheses are used for multi-line data as specified in [RFC
-   1035] section 5.1.)
-
-   where:
-
-       d1:     [0 .. 90]            (degrees latitude)
-       d2:     [0 .. 180]           (degrees longitude)
-       m1, m2: [0 .. 59]            (minutes latitude/longitude)
-       s1, s2: [0 .. 59.999]        (seconds latitude/longitude)
-       alt:    [-100000.00 .. 42849672.95] BY .01 (altitude in meters)
-       siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)
-
-   If omitted, minutes and seconds default to zero, size defaults to 1m,
-   horizontal precision defaults to 10000m, and vertical precision
-   defaults to 10m.  These defaults are chosen to represent typical
-   ZIP/postal code area sizes, since it is often easy to find
-   approximate geographical location by ZIP/postal code.
-
-4. Example Data
-
-;;;
-;;; note that these data would not all appear in one zone file
-;;;
-
-;; network LOC RR derived from ZIP data.  note use of precision defaults
-cambridge-net.kei.com.        LOC   42 21 54 N 71 06 18 W -24m 30m
-
-;; higher-precision host LOC RR.  note use of vertical precision default
-loiosh.kei.com.               LOC   42 21 43.952 N 71 5 6.344 W
-                                    -24m 1m 200m
-
-pipex.net.                    LOC   52 14 05 N 00 08 50 E 10m
-
-curtin.edu.au.                LOC   32 7 19 S 116 2 25 E 10m
-
-rwy04L.logan-airport.boston.  LOC   42 21 28.764 N 71 00 51.617 W
-                                    -44m 2000m
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 4]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-5. Application use of the LOC RR
-
-5.1 Suggested Uses
-
-   Some uses for the LOC RR have already been suggested, including the
-   USENET backbone flow maps, a "visual traceroute" application showing
-   the geographical path of an IP packet, and network management
-   applications that could use LOC RRs to generate a map of hosts and
-   routers being managed.
-
-5.2 Search Algorithms
-
-   This section specifies how to use the DNS to translate domain names
-   and/or IP addresses into location information.
-
-   If an application wishes to have a "fallback" behavior, displaying a
-   less precise or larger area when a host does not have an associated
-   LOC RR, it MAY support use of the algorithm in section 5.2.3, as
-   noted in sections 5.2.1 and 5.2.2.  If fallback is desired, this
-   behaviour is the RECOMMENDED default, but in some cases it may need
-   to be modified based on the specific requirements of the application
-   involved.
-
-   This search algorithm is designed to allow network administrators to
-   specify the location of a network or subnet without requiring LOC RR
-   data for each individual host.  For example, a computer lab with 24
-   workstations, all of which are on the same subnet and in basically
-   the same location, would only need a LOC RR for the subnet.
-   (However, if the file server's location has been more precisely
-   measured, a separate LOC RR for it can be placed in the DNS.)
-
-5.2.1 Searching by Name
-
-   If the application is beginning with a name, rather than an IP
-   address (as the USENET backbone flow maps do), it MUST check for a
-   LOC RR associated with that name.  (CNAME records should be followed
-   as for any other RR type.)
-
-   If there is no LOC RR for that name, all A records (if any)
-   associated with the name MAY be checked for network (or subnet) LOC
-   RRs using the "Searching by Network or Subnet" algorithm (5.2.3).  If
-   multiple A records exist and have associated network or subnet LOC
-   RRs, the application may choose to use any, some, or all of the LOC
-   RRs found, possibly in combination.  It is suggested that multi-homed
-   hosts have LOC RRs for their name in the DNS to avoid any ambiguity
-   in these cases.
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 5]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-   Note that domain names that do not have associated A records must
-   have a LOC RR associated with their name in order for location
-   information to be accessible.
-
-5.2.2 Searching by Address
-
-   If the application is beginning with an IP address (as a "visual
-   traceroute" application might be) it MUST first map the address to a
-   name using the IN-ADDR.ARPA namespace (see [RFC 1034], section
-   5.2.1), then check for a LOC RR associated with that name.
-
-   If there is no LOC RR for the name, the address MAY be checked for
-   network (or subnet) LOC RRs using the "Searching by Network or
-   Subnet" algorithm (5.2.3).
-
-5.2.3 Searching by Network or Subnet
-
-   Even if a host's name does not have any associated LOC RRs, the
-   network(s) or subnet(s) it is on may.  If the application wishes to
-   search for such less specific data, the following algorithm SHOULD be
-   followed to find a network or subnet LOC RR associated with the IP
-   address.  This algorithm is adapted slightly from that specified in
-   [RFC 1101], sections 4.3 and 4.4.
-
-   Since subnet LOC RRs are (if present) more specific than network LOC
-   RRs, it is best to use them if available.  In order to do so, we
-   build a stack of network and subnet names found while performing the
-   [RFC 1101] search, then work our way down the stack until a LOC RR is
-   found.
-
-   1. create a host-zero address using the network portion of the IP
-      address (one, two, or three bytes for class A, B, or C networks,
-      respectively).  For example, for the host 128.9.2.17, on the class
-      B network 128.9, this would result in the address "128.9.0.0".
-
-   2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A
-      records.  Retrieve:
-
-               0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
-                                        A      255.255.255.0
-
-      Push the name "isi-net.isi.edu" onto the stack of names to be
-      searched for LOC RRs later.
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 6]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-   3. Since an A RR was found, repeat using mask from RR
-      (255.255.255.0), constructing a query for 0.2.9.128.IN-ADDR.ARPA.
-      Retrieve:
-
-               0.2.9.128.IN-ADDR.ARPA.  PTR    div2-subnet.isi.edu.
-                                        A      255.255.255.240
-
-      Push the name "div2-subnet.isi.edu" onto the stack of names to be
-      searched for LOC RRs later.
-
-   4. Since another A RR was found, repeat using mask 255.255.255.240
-      (x'FFFFFFF0'), constructing a query for 16.2.9.128.IN-ADDR.ARPA.
-      Retrieve:
-
-               16.2.9.128.IN-ADDR.ARPA. PTR    inc-subsubnet.isi.edu.
-
-      Push the name "inc-subsubnet.isi.edu" onto the stack of names to
-      be searched for LOC RRs later.
-
-   5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no
-      more subnet levels to search.  We now pop the top name from the
-      stack and check for an associated LOC RR.  Repeat until a LOC RR
-      is found.
-
-      In this case, assume that inc-subsubnet.isi.edu does not have an
-      associated LOC RR, but that div2-subnet.isi.edu does.  We will
-      then use div2-subnet.isi.edu's LOC RR as an approximation of this
-      host's location.  (Note that even if isi-net.isi.edu has a LOC RR,
-      it will not be used if a subnet also has a LOC RR.)
-
-5.3 Applicability to non-IN Classes and non-IP Addresses
-
-   The LOC record is defined for all RR classes, and may be used with
-   non-IN classes such as HS and CH.  The semantics of such use are not
-   defined by this memo.
-
-   The search algorithm in section 5.2.3 may be adapted to other
-   addressing schemes by extending [RFC 1101]'s encoding of network
-   names to cover those schemes.  Such extensions are not defined by
-   this memo.
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 7]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-6. References
-
-   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, USC/Information Sciences Institute,
-              November 1987.
-
-   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, USC/Information Sciences
-              Institute, November 1987.
-
-   [RFC 1101] Mockapetris, P., "DNS Encoding of Network Names and Other
-              Types", RFC 1101, USC/Information Sciences Institute,
-              April 1989.
-
-   [WGS 84] United States Department of Defense; DoD WGS-1984 - Its
-            Definition and Relationships with Local Geodetic Systems;
-            Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R-
-            138-R; CV, KV;
-
-7. Security Considerations
-
-   High-precision LOC RR information could be used to plan a penetration
-   of physical security, leading to potential denial-of-machine attacks.
-   To avoid any appearance of suggesting this method to potential
-   attackers, we declined the opportunity to name this RR "ICBM".
-
-8. Authors' Addresses
-
-   The authors as a group can be reached as <loc@pipex.net>.
-
-   Christopher Davis
-   Kapor Enterprises, Inc.
-   238 Main Street, Suite 400
-   Cambridge, MA 02142
-
-   Phone: +1 617 576 4532
-   EMail: ckd@kei.com
-
-
-   Paul Vixie
-   Vixie Enterprises
-   Star Route Box 159A
-   Woodside, CA 94062
-
-   Phone: +1 415 747 0204
-   EMail: paul@vix.com
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 8]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-   Tim Goodwin
-   Public IP Exchange Ltd (PIPEX)
-   216 The Science Park
-   Cambridge CB4 4WA
-   UK
-
-   Phone: +44 1223 250250
-   EMail: tim@pipex.net
-
-
-   Ian Dickinson
-   FORE Systems
-   2475 The Crescent
-   Solihull Parkway
-   Birmingham Business Park
-   B37 7YE
-   UK
-
-   Phone: +44 121 717 4444
-   EMail: idickins@fore.co.uk
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 9]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-Appendix A: Sample Conversion Routines
-
-/*
- * routines to convert between on-the-wire RR format and zone file
- * format.  Does not contain conversion to/from decimal degrees;
- * divide or multiply by 60*60*1000 for that.
- */
-
-static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000,
-                                 1000000,10000000,100000000,1000000000};
-
-/* takes an XeY precision/size value, returns a string representation.*/
-static const char *
-precsize_ntoa(prec)
-        u_int8_t prec;
-{
-        static char retbuf[sizeof("90000000.00")];
-        unsigned long val;
-        int mantissa, exponent;
-
-        mantissa = (int)((prec >> 4) & 0x0f) % 10;
-        exponent = (int)((prec >> 0) & 0x0f) % 10;
-
-        val = mantissa * poweroften[exponent];
-
-        (void) sprintf(retbuf,"%d.%.2d", val/100, val%100);
-        return (retbuf);
-}
-
-/* converts ascii size/precision X * 10**Y(cm) to 0xXY. moves pointer.*/
-static u_int8_t
-precsize_aton(strptr)
-        char **strptr;
-{
-        unsigned int mval = 0, cmval = 0;
-        u_int8_t retval = 0;
-        register char *cp;
-        register int exponent;
-        register int mantissa;
-
-        cp = *strptr;
-
-        while (isdigit(*cp))
-                mval = mval * 10 + (*cp++ - '0');
-
-        if (*cp == '.') {               /* centimeters */
-                cp++;
-                if (isdigit(*cp)) {
-
-
-
-Davis, et al                  Experimental                     [Page 10]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-                        cmval = (*cp++ - '0') * 10;
-                        if (isdigit(*cp)) {
-                                cmval += (*cp++ - '0');
-                        }
-                }
-        }
-        cmval = (mval * 100) + cmval;
-
-        for (exponent = 0; exponent < 9; exponent++)
-                if (cmval < poweroften[exponent+1])
-                        break;
-
-        mantissa = cmval / poweroften[exponent];
-        if (mantissa > 9)
-                mantissa = 9;
-
-        retval = (mantissa << 4) | exponent;
-
-        *strptr = cp;
-
-        return (retval);
-}
-
-/* converts ascii lat/lon to unsigned encoded 32-bit number.
- *  moves pointer. */
-static u_int32_t
-latlon2ul(latlonstrptr,which)
-        char **latlonstrptr;
-        int *which;
-{
-        register char *cp;
-        u_int32_t retval;
-        int deg = 0, min = 0, secs = 0, secsfrac = 0;
-
-        cp = *latlonstrptr;
-
-        while (isdigit(*cp))
-                deg = deg * 10 + (*cp++ - '0');
-
-        while (isspace(*cp))
-                cp++;
-
-        if (!(isdigit(*cp)))
-                goto fndhemi;
-
-        while (isdigit(*cp))
-                min = min * 10 + (*cp++ - '0');
-
-
-
-
-Davis, et al                  Experimental                     [Page 11]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        while (isspace(*cp))
-                cp++;
-
-        if (!(isdigit(*cp)))
-                goto fndhemi;
-
-        while (isdigit(*cp))
-                secs = secs * 10 + (*cp++ - '0');
-
-        if (*cp == '.') {               /* decimal seconds */
-                cp++;
-                if (isdigit(*cp)) {
-                        secsfrac = (*cp++ - '0') * 100;
-                        if (isdigit(*cp)) {
-                                secsfrac += (*cp++ - '0') * 10;
-                                if (isdigit(*cp)) {
-                                        secsfrac += (*cp++ - '0');
-                                }
-                        }
-                }
-        }
-
-        while (!isspace(*cp))   /* if any trailing garbage */
-                cp++;
-
-        while (isspace(*cp))
-                cp++;
-
- fndhemi:
-        switch (*cp) {
-        case 'N': case 'n':
-        case 'E': case 'e':
-                retval = ((unsigned)1<<31)
-                        + (((((deg * 60) + min) * 60) + secs) * 1000)
-                        + secsfrac;
-                break;
-        case 'S': case 's':
-        case 'W': case 'w':
-                retval = ((unsigned)1<<31)
-                        - (((((deg * 60) + min) * 60) + secs) * 1000)
-                        - secsfrac;
-                break;
-        default:
-                retval = 0;     /* invalid value -- indicates error */
-                break;
-        }
-
-        switch (*cp) {
-
-
-
-Davis, et al                  Experimental                     [Page 12]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        case 'N': case 'n':
-        case 'S': case 's':
-                *which = 1;     /* latitude */
-                break;
-        case 'E': case 'e':
-        case 'W': case 'w':
-                *which = 2;     /* longitude */
-                break;
-        default:
-                *which = 0;     /* error */
-                break;
-        }
-
-        cp++;                   /* skip the hemisphere */
-
-        while (!isspace(*cp))   /* if any trailing garbage */
-                cp++;
-
-        while (isspace(*cp))    /* move to next field */
-                cp++;
-
-        *latlonstrptr = cp;
-
-        return (retval);
-}
-
-/* converts a zone file representation in a string to an RDATA
- * on-the-wire representation. */
-u_int32_t
-loc_aton(ascii, binary)
-        const char *ascii;
-        u_char *binary;
-{
-        const char *cp, *maxcp;
-        u_char *bcp;
-
-        u_int32_t latit = 0, longit = 0, alt = 0;
-        u_int32_t lltemp1 = 0, lltemp2 = 0;
-        int altmeters = 0, altfrac = 0, altsign = 1;
-        u_int8_t hp = 0x16;    /* default = 1e6 cm = 10000.00m = 10km */
-        u_int8_t vp = 0x13;    /* default = 1e3 cm = 10.00m */
-        u_int8_t siz = 0x12;   /* default = 1e2 cm = 1.00m */
-        int which1 = 0, which2 = 0;
-
-        cp = ascii;
-        maxcp = cp + strlen(ascii);
-
-        lltemp1 = latlon2ul(&cp, &which1);
-
-
-
-Davis, et al                  Experimental                     [Page 13]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        lltemp2 = latlon2ul(&cp, &which2);
-
-        switch (which1 + which2) {
-        case 3:                 /* 1 + 2, the only valid combination */
-                if ((which1 == 1) && (which2 == 2)) { /* normal case */
-                        latit = lltemp1;
-                        longit = lltemp2;
-                } else if ((which1 == 2) && (which2 == 1)) {/*reversed*/
-                        longit = lltemp1;
-                        latit = lltemp2;
-                } else {        /* some kind of brokenness */
-                        return 0;
-                }
-                break;
-        default:                /* we didn't get one of each */
-                return 0;
-        }
-
-        /* altitude */
-        if (*cp == '-') {
-                altsign = -1;
-                cp++;
-        }
-
-        if (*cp == '+')
-                cp++;
-
-        while (isdigit(*cp))
-                altmeters = altmeters * 10 + (*cp++ - '0');
-
-        if (*cp == '.') {               /* decimal meters */
-                cp++;
-                if (isdigit(*cp)) {
-                        altfrac = (*cp++ - '0') * 10;
-                        if (isdigit(*cp)) {
-                                altfrac += (*cp++ - '0');
-                        }
-                }
-        }
-
-        alt = (10000000 + (altsign * (altmeters * 100 + altfrac)));
-
-        while (!isspace(*cp) && (cp < maxcp))
-                                           /* if trailing garbage or m */
-                cp++;
-
-        while (isspace(*cp) && (cp < maxcp))
-                cp++;
-
-
-
-Davis, et al                  Experimental                     [Page 14]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        if (cp >= maxcp)
-                goto defaults;
-
-        siz = precsize_aton(&cp);
-
-        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
-                cp++;
-
-        while (isspace(*cp) && (cp < maxcp))
-                cp++;
-
-        if (cp >= maxcp)
-                goto defaults;
-
-        hp = precsize_aton(&cp);
-
-        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
-                cp++;
-
-        while (isspace(*cp) && (cp < maxcp))
-                cp++;
-
-        if (cp >= maxcp)
-                goto defaults;
-
-        vp = precsize_aton(&cp);
-
- defaults:
-
-        bcp = binary;
-        *bcp++ = (u_int8_t) 0;  /* version byte */
-        *bcp++ = siz;
-        *bcp++ = hp;
-        *bcp++ = vp;
-        PUTLONG(latit,bcp);
-        PUTLONG(longit,bcp);
-        PUTLONG(alt,bcp);
-
-        return (16);            /* size of RR in octets */
-}
-
-/* takes an on-the-wire LOC RR and prints it in zone file
- * (human readable) format. */
-char *
-loc_ntoa(binary,ascii)
-        const u_char *binary;
-        char *ascii;
-{
-
-
-
-Davis, et al                  Experimental                     [Page 15]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        static char tmpbuf[255*3];
-
-        register char *cp;
-        register const u_char *rcp;
-
-        int latdeg, latmin, latsec, latsecfrac;
-        int longdeg, longmin, longsec, longsecfrac;
-        char northsouth, eastwest;
-        int altmeters, altfrac, altsign;
-
-        const int referencealt = 100000 * 100;
-
-        int32_t latval, longval, altval;
-        u_int32_t templ;
-        u_int8_t sizeval, hpval, vpval, versionval;
-
-        char *sizestr, *hpstr, *vpstr;
-
-        rcp = binary;
-        if (ascii)
-                cp = ascii;
-        else {
-                cp = tmpbuf;
-        }
-
-        versionval = *rcp++;
-
-        if (versionval) {
-                sprintf(cp,"; error: unknown LOC RR version");
-                return (cp);
-        }
-
-        sizeval = *rcp++;
-
-        hpval = *rcp++;
-        vpval = *rcp++;
-
-        GETLONG(templ,rcp);
-        latval = (templ - ((unsigned)1<<31));
-
-        GETLONG(templ,rcp);
-        longval = (templ - ((unsigned)1<<31));
-
-        GETLONG(templ,rcp);
-        if (templ < referencealt) { /* below WGS 84 spheroid */
-                altval = referencealt - templ;
-                altsign = -1;
-        } else {
-
-
-
-Davis, et al                  Experimental                     [Page 16]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-                altval = templ - referencealt;
-                altsign = 1;
-        }
-
-        if (latval < 0) {
-                northsouth = 'S';
-                latval = -latval;
-        }
-        else
-                northsouth = 'N';
-
-        latsecfrac = latval % 1000;
-        latval = latval / 1000;
-        latsec = latval % 60;
-        latval = latval / 60;
-        latmin = latval % 60;
-        latval = latval / 60;
-        latdeg = latval;
-
-        if (longval < 0) {
-                eastwest = 'W';
-                longval = -longval;
-        }
-        else
-                eastwest = 'E';
-
-        longsecfrac = longval % 1000;
-        longval = longval / 1000;
-        longsec = longval % 60;
-        longval = longval / 60;
-        longmin = longval % 60;
-        longval = longval / 60;
-        longdeg = longval;
-
-        altfrac = altval % 100;
-        altmeters = (altval / 100) * altsign;
-
-        sizestr = savestr(precsize_ntoa(sizeval));
-        hpstr = savestr(precsize_ntoa(hpval));
-        vpstr = savestr(precsize_ntoa(vpval));
-
-        sprintf(cp,
-                "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %d.%.2dm
-                %sm %sm %sm",
-                latdeg, latmin, latsec, latsecfrac, northsouth,
-                longdeg, longmin, longsec, longsecfrac, eastwest,
-                altmeters, altfrac, sizestr, hpstr, vpstr);
-
-
-
-
-Davis, et al                  Experimental                     [Page 17]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        free(sizestr);
-        free(hpstr);
-        free(vpstr);
-
-        return (cp);
-}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                     [Page 18]
-
diff --git a/doc/rfc/rfc1886.txt b/doc/rfc/rfc1886.txt
deleted file mode 100644
index 9874fddb..00000000
--- a/doc/rfc/rfc1886.txt
+++ /dev/null
@@ -1,268 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         S. Thomson
-Request for Comments: 1886                                      Bellcore
-Category: Standards Track                                     C. Huitema
-                                                                   INRIA
-                                                           December 1995
-
-
-                DNS Extensions to support IP version 6
-
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-
-Abstract
-
-   This document defines the changes that need to be made to the Domain
-   Name System to support hosts running IP version 6 (IPv6).  The
-   changes include a new resource record type to store an IPv6 address,
-   a new domain to support lookups based on an IPv6 address, and updated
-   definitions of existing query types that return Internet addresses as
-   part of additional section processing.  The extensions are designed
-   to be compatible with existing applications and, in particular, DNS
-   implementations themselves.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thompson & Huitema          Standards Track                    [Page 1]
-
-RFC 1886                  IPv6 DNS Extensions              December 1995
-
-
-1. INTRODUCTION
-
-   Current support for the storage of Internet addresses in the Domain
-   Name System (DNS)[1,2] cannot easily be extended to support IPv6
-   addresses[3] since applications assume that address queries return
-   32-bit IPv4 addresses only.
-
-   To support the storage of IPv6 addresses we define the following
-   extensions:
-
-      o A new resource record type is defined to map a domain name to an
-        IPv6 address.
-
-      o A new domain is defined to support lookups based on address.
-
-      o Existing queries that perform additional section processing to
-        locate IPv4 addresses are redefined to perform additional
-        section processing on both IPv4 and IPv6 addresses.
-
-   The changes are designed to be compatible with existing software. The
-   existing support for IPv4 addresses is retained. Transition issues
-   related to the co-existence of both IPv4 and IPv6 addresses in DNS
-   are discussed in [4].
-
-
-2. NEW RESOURCE RECORD DEFINITION AND DOMAIN
-
-   A new record type is defined to store a host's IPv6 address. A host
-   that has more than one IPv6 address must have more than one such
-   record.
-
-
-2.1 AAAA record type
-
-   The AAAA resource record type is a new record specific to the
-   Internet class that stores a single IPv6 address.
-
-   The value of the type is 28 (decimal).
-
-
-2.2 AAAA data format
-
-   A 128 bit IPv6 address is encoded in the data portion of an AAAA
-   resource record in network byte order (high-order byte first).
-
-
-
-
-Thompson & Huitema          Standards Track                    [Page 2]
-
-RFC 1886                  IPv6 DNS Extensions              December 1995
-
-
-2.3 AAAA query
-
-   An AAAA query for a specified domain name in the Internet class
-   returns all associated AAAA resource records in the answer section of
-   a response.
-
-   A type AAAA query does not perform additional section processing.
-
-
-2.4 Textual format of AAAA records
-
-   The textual representation of the data portion of the AAAA resource
-   record used in a master database file is the textual representation
-   of a IPv6 address as defined in [3].
-
-
-2.5 IP6.INT Domain
-
-   A special domain is defined to look up a record given an address. The
-   intent of this domain is to provide a way of mapping an IPv6 address
-   to a host name, although it may be used for other purposes as well.
-   The domain is rooted at IP6.INT.
-
-   An IPv6 address is represented as a name in the IP6.INT domain by a
-   sequence of nibbles separated by dots with the suffix ".IP6.INT". The
-   sequence of nibbles is encoded in reverse order, i.e. the low-order
-   nibble is encoded first, followed by the next low-order nibble and so
-   on. Each nibble is represented by a hexadecimal digit. For example,
-   the inverse lookup domain name corresponding to the address
-
-       4321:0:1:2:3:4:567:89ab
-
-   would be
-
-b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
-
-
-
-3. MODIFICATIONS TO EXISTING QUERY TYPES
-
-   All existing query types that perform type A additional section
-   processing, i.e. name server (NS), mail exchange (MX) and mailbox
-   (MB) query types, must be redefined to perform both type A and type
-   AAAA additional section processing. These new definitions mean that a
-   name server must add any relevant IPv4 addresses and any relevant
-
-
-
-Thompson & Huitema          Standards Track                    [Page 3]
-
-RFC 1886                  IPv6 DNS Extensions              December 1995
-
-
-   IPv6 addresses available locally to the additional section of a
-   response when processing any one of the above queries.
-
-
-4. SECURITY CONSIDERATIONS
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thompson & Huitema          Standards Track                    [Page 4]
-
-RFC 1886                  IPv6 DNS Extensions              December 1995
-
-
-5. REFERENCES
-
-
-   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
-        13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2]  Mockapetris, P., "Domain Names - Implementation and Specifica-
-        tion", STD 13, RFC 1035, USC/Information Sciences Institute,
-        November 1987.
-
-   [3]  Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing
-        Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December
-        1995.
-
-
-   [4]  Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
-        Hosts and Routers", Work in Progress.
-
-
-Authors' Addresses
-
-   Susan Thomson
-   Bellcore
-   MRE 2P343
-   445 South Street
-   Morristown, NJ 07960
-   U.S.A.
-
-   Phone: +1 201-829-4514
-   EMail: set@thumper.bellcore.com
-
-
-   Christian Huitema
-   INRIA, Sophia-Antipolis
-   2004 Route des Lucioles
-   BP 109
-   F-06561 Valbonne Cedex
-   France
-
-   Phone: +33 93 65 77 15
-   EMail: Christian.Huitema@MIRSA.INRIA.FR
-
-
-
-
-
-
-
-Thompson & Huitema          Standards Track                    [Page 5]
-
diff --git a/doc/rfc/rfc1912.txt b/doc/rfc/rfc1912.txt
deleted file mode 100644
index 8ace7d26..00000000
--- a/doc/rfc/rfc1912.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            D. Barr
-Request for Comments: 1912             The Pennsylvania State University
-Obsoletes: 1537                                            February 1996
-Category: Informational
-
-
-            Common DNS Operational and Configuration Errors
-
-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 memo describes errors often found in both the operation of
-   Domain Name System (DNS) servers, and in the data that these DNS
-   servers contain.  This memo tries to summarize current Internet
-   requirements as well as common practice in the operation and
-   configuration of the DNS.  This memo also tries to summarize or
-   expand upon issues raised in [RFC 1537].
-
-1. Introduction
-
-   Running a nameserver is not a trivial task.  There are many things
-   that can go wrong, and many decisions have to be made about what data
-   to put in the DNS and how to set up servers.  This memo attempts to
-   address many of the common mistakes and pitfalls that are made in DNS
-   data as well as in the operation of nameservers.  Discussions are
-   also made regarding some other relevant issues such as server or
-   resolver bugs, and a few political issues with respect to the
-   operation of DNS on the Internet.
-
-2. DNS Data
-
-   This section discusses problems people typically have with the DNS
-   data in their nameserver, as found in the zone data files that the
-   nameserver loads into memory.
-
-2.1 Inconsistent, Missing, or Bad Data
-
-   Every Internet-reachable host should have a name.  The consequences
-   of this are becoming more and more obvious.  Many services available
-   on the Internet will not talk to you if you aren't correctly
-   registered in the DNS.
-
-
-
-
-
-Barr                         Informational                      [Page 1]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   Make sure your PTR and A records match.  For every IP address, there
-   should be a matching PTR record in the in-addr.arpa domain.  If a
-   host is multi-homed, (more than one IP address) make sure that all IP
-   addresses have a corresponding PTR record (not just the first one).
-   Failure to have matching PTR and A records can cause loss of Internet
-   services similar to not being registered in the DNS at all.  Also,
-   PTR records must point back to a valid A record, not a alias defined
-   by a CNAME.  It is highly recommended that you use some software
-   which automates this checking, or generate your DNS data from a
-   database which automatically creates consistent data.
-
-   DNS domain names consist of "labels" separated by single dots.  The
-   DNS is very liberal in its rules for the allowable characters in a
-   domain name.  However, if a domain name is used to name a host, it
-   should follow rules restricting host names.  Further if a name is
-   used for mail, it must follow the naming rules for names in mail
-   addresses.
-
-   Allowable characters in a label for a host name are only ASCII
-   letters, digits, and the `-' character.  Labels may not be all
-   numbers, but may have a leading digit  (e.g., 3com.com).  Labels must
-   end and begin only with a letter or digit.  See [RFC 1035] and [RFC
-   1123].  (Labels were initially restricted in [RFC 1035] to start with
-   a letter, and some older hosts still reportedly have problems with
-   the relaxation in [RFC 1123].)  Note there are some Internet
-   hostnames which violate this rule (411.org, 1776.com).  The presence
-   of underscores in a label is allowed in [RFC 1033], except [RFC 1033]
-   is informational only and was not defining a standard.  There is at
-   least one popular TCP/IP implementation which currently refuses to
-   talk to hosts named with underscores in them.  It must be noted that
-   the language in [1035] is such that these rules are voluntary -- they
-   are there for those who wish to minimize problems.  Note that the
-   rules for Internet host names also apply to hosts and addresses used
-   in SMTP (See RFC 821).
-
-   If a domain name is to be used for mail (not involving SMTP), it must
-   follow the rules for mail in [RFC 822], which is actually more
-   liberal than the above rules.  Labels for mail can be any ASCII
-   character except "specials", control characters, and whitespace
-   characters.  "Specials" are specific symbols used in the parsing of
-   addresses.  They are the characters "()<>@,;:\".[]".  (The "!"
-   character wasn't in [RFC 822], however it also shouldn't be used due
-   to the conflict with UUCP mail as defined in RFC 976)  However, since
-   today almost all names which are used for mail on the Internet are
-   also names used for hostnames, one rarely sees addresses using these
-   relaxed standard, but mail software should be made liberal and robust
-   enough to accept them.
-
-
-
-
-Barr                         Informational                      [Page 2]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   You should also be careful to not have addresses which are valid
-   alternate syntaxes to the inet_ntoa() library call.  For example 0xe
-   is a valid name, but if you were to type "telnet 0xe", it would try
-   to connect to IP address 0.0.0.14.  It is also rumored that there
-   exists some broken inet_ntoa() routines that treat an address like
-   x400 as an IP address.
-
-   Certain operating systems have limitations on the length of their own
-   hostname.  While not strictly of issue to the DNS, you should be
-   aware of your operating system's length limits before choosing the
-   name of a host.
-
-   Remember that many resource records (abbreviated RR) take on more
-   than one argument.  HINFO requires two arguments, as does RP.  If you
-   don't supply enough arguments, servers sometime return garbage for
-   the missing fields.  If you need to include whitespace within any
-   data, you must put the string in quotes.
-
-2.2 SOA records
-
-   In the SOA record of every zone, remember to fill in the e-mail
-   address that will get to the person who maintains the DNS at your
-   site (commonly referred to as "hostmaster").  The `@' in the e-mail
-   must be replaced by a `.' first.  Do not try to put an `@' sign in
-   this address.  If the local part of the address already contains a
-   `.' (e.g., John.Smith@widget.xx), then you need to quote the `.' by
-   preceding it with `\' character.  (e.g., to become
-   John\.Smith.widget.xx) Alternately (and preferred), you can just use
-   the generic name `hostmaster', and use a mail alias to redirect it to
-   the appropriate persons.  There exists software which uses this field
-   to automatically generate the e-mail address for the zone contact.
-   This software will break if this field is improperly formatted.  It
-   is imperative that this address get to one or more real persons,
-   because it is often used for everything from reporting bad DNS data
-   to reporting security incidents.
-
-   Even though some BIND versions allow you to use a decimal in a serial
-   number, don't.  A decimal serial number is converted to an unsigned
-   32-bit integer internally anyway.  The formula for a n.m serial
-   number is n*10^(3+int(0.9+log10(m))) + m which translates to
-   something rather unexpected.  For example it's routinely possible
-   with a decimal serial number (perhaps automatically generated by
-   SCCS) to be incremented such that it is numerically larger, but after
-   the above conversion yield a serial number which is LOWER than
-   before.  Decimal serial numbers have been officially deprecated in
-   recent BIND versions.  The recommended syntax is YYYYMMDDnn
-   (YYYY=year, MM=month, DD=day, nn=revision number.  This won't
-   overflow until the year 4294.
-
-
-
-Barr                         Informational                      [Page 3]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   Choose logical values for the timer values in the SOA record (note
-   values below must be expressed as seconds in the zone data):
-
-      Refresh: How often a secondary will poll the primary server to see
-          if the serial number for the zone has increased (so it knows
-          to request a new copy of the data for the zone).  Set this to
-          how long your secondaries can comfortably contain out-of-date
-          data.  You can keep it short (20 mins to 2 hours) if you
-          aren't worried about a small increase in bandwidth used, or
-          longer (2-12 hours) if your Internet connection is slow or is
-          started on demand.  Recent BIND versions (4.9.3) have optional
-          code to automatically notify secondaries that data has
-          changed, allowing you to set this TTL to a long value (one
-          day, or more).
-
-      Retry: If a secondary was unable to contact the primary at the
-          last refresh, wait the retry value before trying again.  This
-          value isn't as important as others, unless the secondary is on
-          a distant network from the primary or the primary is more
-          prone to outages.  It's typically some fraction of the refresh
-          interval.
-
-
-      Expire: How long a secondary will still treat its copy of the zone
-          data as valid if it can't contact the primary.  This value
-          should be greater than how long a major outage would typically
-          last, and must be greater than the minimum and retry
-          intervals, to avoid having a secondary expire the data before
-          it gets a chance to get a new copy.  After a zone is expired a
-          secondary will still continue to try to contact the primary,
-          but it will no longer provide nameservice for the zone.  2-4
-          weeks are suggested values.
-
-      Minimum: The default TTL (time-to-live) for resource records --
-          how long data will remain in other nameservers' cache.  ([RFC
-          1035] defines this to be the minimum value, but servers seem
-          to always implement this as the default value)  This is by far
-          the most important timer.  Set this as large as is comfortable
-          given how often you update your nameserver.  If you plan to
-          make major changes, it's a good idea to turn this value down
-          temporarily beforehand.  Then wait the previous minimum value,
-          make your changes, verify their correctness, and turn this
-          value back up.  1-5 days are typical values.  Remember this
-          value can be overridden on individual resource records.
-
-
-
-
-
-
-
-Barr                         Informational                      [Page 4]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   As you can see, the typical values above for the timers vary widely.
-   Popular documentation like [RFC 1033] recommended a day for the
-   minimum TTL, which is now considered too low except for zones with
-   data that vary regularly.  Once a DNS stabilizes, values on the order
-   of 3 or more days are recommended.  It is also recommended that you
-   individually override the TTL on certain RRs which are often
-   referenced and don't often change to have very large values (1-2
-   weeks).  Good examples of this are the MX, A, and PTR records of your
-   mail host(s), the NS records of your zone, and the A records of your
-   nameservers.
-
-2.3 Glue A Records
-
-   Glue records are A records that are associated with NS records to
-   provide "bootstrapping" information to the nameserver.  For example:
-
-           podunk.xx.      in      ns      ns1.podunk.xx.
-                           in      ns      ns2.podunk.xx.
-           ns1.podunk.xx.  in      a       1.2.3.4
-           ns2.podunk.xx.  in      a       1.2.3.5
-
-   Here, the A records are referred to as "Glue records".
-
-   Glue records are required only in forward zone files for nameservers
-   that are located in the subdomain of the current zone that is being
-   delegated.  You shouldn't have any A records in an in-addr.arpa zone
-   file (unless you're using RFC 1101-style encoding of subnet masks).
-
-   If your nameserver is multi-homed (has more than one IP address), you
-   must list all of its addresses in the glue to avoid cache
-   inconsistency due to differing TTL values, causing some lookups to
-   not find all addresses for your nameserver.
-
-   Some people get in the bad habit of putting in a glue record whenever
-   they add an NS record "just to make sure".  Having duplicate glue
-   records in your zone files just makes it harder when a nameserver
-   moves to a new IP address, or is removed. You'll spend hours trying
-   to figure out why random people still see the old IP address for some
-   host, because someone forgot to change or remove a glue record in
-   some other file.  Newer BIND versions will ignore these extra glue
-   records in local zone files.
-
-   Older BIND versions (4.8.3 and previous) have a problem where it
-   inserts these extra glue records in the zone transfer data to
-   secondaries.  If one of these glues is wrong, the error can be
-   propagated to other nameservers.  If two nameservers are secondaries
-   for other zones of each other, it's possible for one to continually
-   pass old glue records back to the other.  The only way to get rid of
-
-
-
-Barr                         Informational                      [Page 5]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   the old data is to kill both of them, remove the saved backup files,
-   and restart them.  Combined with that those same versions also tend
-   to become infected more easily with bogus data found in other non-
-   secondary nameservers (like the root zone data).
-
-2.4 CNAME records
-
-   A CNAME record is not allowed to coexist with any other data.  In
-   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
-   can't also have an MX record for suzy.podunk.edu, or an A record, or
-   even a TXT record.  Especially do not try to combine CNAMEs and NS
-   records like this!:
-
-
-           podunk.xx.      IN      NS      ns1
-                           IN      NS      ns2
-                           IN      CNAME   mary
-           mary            IN      A       1.2.3.4
-
-
-   This is often attempted by inexperienced administrators as an obvious
-   way to allow your domain name to also be a host.  However, DNS
-   servers like BIND will see the CNAME and refuse to add any other
-   resources for that name.  Since no other records are allowed to
-   coexist with a CNAME, the NS entries are ignored.  Therefore all the
-   hosts in the podunk.xx domain are ignored as well!
-
-   If you want to have your domain also be a host, do the following:
-
-           podunk.xx.      IN      NS      ns1
-                           IN      NS      ns2
-                           IN      A       1.2.3.4
-           mary            IN      A       1.2.3.4
-
-   Don't go overboard with CNAMEs.  Use them when renaming hosts, but
-   plan to get rid of them (and inform your users).  However CNAMEs are
-   useful (and encouraged) for generalized names for servers -- `ftp'
-   for your ftp server, `www' for your Web server, `gopher' for your
-   Gopher server, `news' for your Usenet news server, etc.
-
-   Don't forget to delete the CNAMEs associated with a host if you
-   delete the host it is an alias for.  Such "stale CNAMEs" are a waste
-   of resources.
-
-
-
-
-
-
-
-
-Barr                         Informational                      [Page 6]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   Don't use CNAMEs in combination with RRs which point to other names
-   like MX, CNAME, PTR and NS.  (PTR is an exception if you want to
-   implement classless in-addr delegation.)  For example, this is
-   strongly discouraged:
-
-           podunk.xx.      IN      MX      mailhost
-           mailhost        IN      CNAME   mary
-           mary            IN      A       1.2.3.4
-
-
-   [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
-   974] explicitly states that MX records shall not point to an alias
-   defined by a CNAME.  This results in unnecessary indirection in
-   accessing the data, and DNS resolvers and servers need to work more
-   to get the answer.  If you really want to do this, you can accomplish
-   the same thing by using a preprocessor such as m4 on your host files.
-
-   Also, having chained records such as CNAMEs pointing to CNAMEs may
-   make administration issues easier, but is known to tickle bugs in
-   some resolvers that fail to check loops correctly.  As a result some
-   hosts may not be able to resolve such names.
-
-   Having NS records pointing to a CNAME is bad and may conflict badly
-   with current BIND servers.  In fact, current BIND implementations
-   will ignore such records, possibly leading to a lame delegation.
-   There is a certain amount of security checking done in BIND to
-   prevent spoofing DNS NS records.  Also, older BIND servers reportedly
-   will get caught in an infinite query loop trying to figure out the
-   address for the aliased nameserver, causing a continuous stream of
-   DNS requests to be sent.
-
-2.5 MX records
-
-   It is a good idea to give every host an MX record, even if it points
-   to itself!  Some mailers will cache MX records, but will always need
-   to check for an MX before sending mail.  If a site does not have an
-   MX, then every piece of mail may result in one more resolver query,
-   since the answer to the MX query often also contains the IP addresses
-   of the MX hosts.  Internet SMTP mailers are required by [RFC 1123] to
-   support the MX mechanism.
-
-   Put MX records even on hosts that aren't intended to send or receive
-   e-mail.  If there is a security problem involving one of these hosts,
-   some people will mistakenly send mail to postmaster or root at the
-   site without checking first to see if it is a "real" host or just a
-   terminal or personal computer that's not set up to accept e-mail.  If
-   you give it an MX record, then the e-mail can be redirected to a real
-   person.  Otherwise mail can just sit in a queue for hours or days
-
-
-
-Barr                         Informational                      [Page 7]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   until the mailer gives up trying to send it.
-
-   Don't forget that whenever you add an MX record, you need to inform
-   the target mailer if it is to treat the first host as "local".  (The
-   "Cw" flag in sendmail, for example)
-
-   If you add an MX record which points to an external host (e.g., for
-   the purposes of backup mail routing) be sure to ask permission from
-   that site first.  Otherwise that site could get rather upset and take
-   action (like throw your mail away, or appeal to higher authorities
-   like your parent DNS administrator or network provider.)
-
-2.6 Other Resource Records
-
-2.6.1 WKS
-
-   WKS records are deprecated in [RFC 1123].  They serve no known useful
-   function, except internally among LISP machines.  Don't use them.
-
-2.6.2 HINFO
-
-   On the issue HINFO records, some will argue that these is a security
-   problem (by broadcasting what vendor hardware and operating system
-   you so people can run systematic attacks on known vendor security
-   holes).  If you do use them, you should keep up to date with known
-   vendor security problems.  However, they serve a useful purpose.
-   Don't forget that HINFO requires two arguments, the hardware type,
-   and the operating system.
-
-   HINFO is sometimes abused to provide other information.  The record
-   is meant to provide specific information about the machine itself.
-   If you need to express other information about the host in the DNS,
-   use TXT.
-
-2.6.3 TXT
-
-   TXT records have no specific definition.  You can put most anything
-   in them.  Some use it for a generic description of the host, some put
-   specific information like its location, primary user, or maybe even a
-   phone number.
-
-2.6.4 RP
-
-   RP records are relatively new.  They are used to specify an e-mail
-   address (see first paragraph of section 2.2)  of the "Responsible
-   Person" of the host, and the name of a TXT record where you can get
-   more information.  See [RFC 1183].
-
-
-
-
-Barr                         Informational                      [Page 8]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-2.7 Wildcard records
-
-   Wildcard MXs are useful mostly for non IP-connected sites.  A common
-   mistake is thinking that a wildcard MX for a zone will apply to all
-   hosts in the zone.  A wildcard MX will apply only to names in the
-   zone which aren't listed in the DNS at all.  e.g.,
-
-           podunk.xx.      IN      NS      ns1
-                           IN      NS      ns2
-           mary            IN      A       1.2.3.4
-           *.podunk.xx.    IN      MX      5 sue
-
-   Mail for mary.podunk.xx will be sent to itself for delivery.  Only
-   mail for jane.podunk.xx or any hosts you don't see above will be sent
-   to the MX.  For most Internet sites, wildcard MX records are not
-   useful.  You need to put explicit MX records on every host.
-
-   Wildcard MXs can be bad, because they make some operations succeed
-   when they should fail instead.  Consider the case where someone in
-   the domain "widget.com" tries to send mail to "joe@larry".  If the
-   host "larry" doesn't actually exist, the mail should in fact bounce
-   immediately.  But because of domain searching the address gets
-   resolved to "larry.widget.com", and because of the wildcard MX this
-   is a valid address according to DNS.  Or perhaps someone simply made
-   a typo in the hostname portion of the address.  The mail message then
-   gets routed to the mail host, which then rejects the mail with
-   strange error messages like "I refuse to talk to myself" or "Local
-   configuration error".
-
-   Wildcard MX records are good for when you have a large number of
-   hosts which are not directly Internet-connected (for example, behind
-   a firewall) and for administrative or political reasons it is too
-   difficult to have individual MX records for every host, or to force
-   all e-mail addresses to be "hidden" behind one or more domain names.
-   In that case, you must divide your DNS into two parts, an internal
-   DNS, and an external DNS.  The external DNS will have only a few
-   hosts and explicit MX records, and one or more wildcard MXs for each
-   internal domain.  Internally the DNS will be complete, with all
-   explicit MX records and no wildcards.
-
-   Wildcard As and CNAMEs are possible too, and are really confusing to
-   users, and a potential nightmare if used without thinking first.  It
-   could result (due again to domain searching) in any telnet/ftp
-   attempts from within the domain to unknown hosts to be directed to
-   one address.  One such wildcard CNAME (in *.edu.com) caused
-   Internet-wide loss of services and potential security nightmares due
-   to unexpected interactions with domain searching.  It resulted in
-   swift fixes, and even an RFC ([RFC 1535]) documenting the problem.
-
-
-
-Barr                         Informational                      [Page 9]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-2.8 Authority and Delegation Errors (NS records)
-
-   You are required to have at least two nameservers for every domain,
-   though more is preferred.  Have secondaries outside your network.  If
-   the secondary isn't under your control, periodically check up on them
-   and make sure they're getting current zone data from you.  Queries to
-   their nameserver about your hosts should always result in an
-   "authoritative" response.  If not, this is called a "lame
-   delegation".  A lame delegations exists when a nameserver is
-   delegated responsibility for providing nameservice for a zone (via NS
-   records) but is not performing nameservice for that zone (usually
-   because it is not set up as a primary or secondary for the zone).
-
-   The "classic" lame delegation can be illustrated in this example:
-
-           podunk.xx.      IN      NS      ns1.podunk.xx.
-                           IN      NS      ns0.widget.com.
-
-   "podunk.xx" is a new domain which has recently been created, and
-   "ns1.podunk.xx" has been set up to perform nameservice for the zone.
-   They haven't quite finished everything yet and haven't made sure that
-   the hostmaster at "ns0.widget.com" has set up to be a proper
-   secondary, and thus has no information about the podunk.xx domain,
-   even though the DNS says it is supposed to.  Various things can
-   happen depending on which nameserver is used.  At best, extra DNS
-   traffic will result from a lame delegation.  At worst, you can get
-   unresolved hosts and bounced e-mail.
-
-   Also, sometimes a nameserver is moved to another host or removed from
-   the list of secondaries.  Unfortunately due to caching of NS records,
-   many sites will still think that a host is a secondary after that
-   host has stopped providing nameservice.  In order to prevent lame
-   delegations while the cache is being aged, continue to provide
-   nameservice on the old nameserver for the length of the maximum of
-   the minimum plus refresh times for the zone and the parent zone.
-   (See section 2.2)
-
-   Whenever a primary or secondary is removed or changed, it takes a
-   fair amount of human coordination among the parties involved.  (The
-   site itself, it's parent, and the site hosting the secondary)  When a
-   primary moves, make sure all secondaries have their named.boot files
-   updated and their servers reloaded.  When a secondary moves, make
-   sure the address records at both the primary and parent level are
-   changed.
-
-   It's also been reported that some distant sites like to pick popular
-   nameservers like "ns.uu.net" and just add it to their list of NS
-   records in hopes that they will magically perform additional
-
-
-
-Barr                         Informational                     [Page 10]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   nameservice for them.  This is an even worse form of lame delegation,
-   since this adds traffic to an already busy nameserver.  Please
-   contact the hostmasters of sites which have lame delegations.
-   Various tools can be used to detect or actively find lame
-   delegations.  See the list of contributed software in the BIND
-   distribution.
-
-   Make sure your parent domain has the same NS records for your zone as
-   you do.  (Don't forget your in-addr.arpa zones too!).  Do not list
-   too many (7 is the recommended maximum), as this just makes things
-   harder to manage and is only really necessary for very popular top-
-   level or root zones.  You also run the risk of overflowing the 512-
-   byte limit of a UDP packet in the response to an NS query.  If this
-   happens, resolvers will "fall back" to using TCP requests, resulting
-   in increased load on your nameserver.
-
-   It's important when picking geographic locations for secondary
-   nameservers to minimize latency as well as increase reliability.
-   Keep in mind network topologies.  For example if your site is on the
-   other end of a slow local or international link, consider a secondary
-   on the other side of the link to decrease average latency.  Contact
-   your Internet service provider or parent domain contact for more
-   information about secondaries which may be available to you.
-
-3. BIND operation
-
-   This section discusses common problems people have in the actual
-   operation of the nameserver (specifically, BIND).  Not only must the
-   data be correct as explained above, but the nameserver must be
-   operated correctly for the data to be made available.
-
-3.1 Serial numbers
-
-   Each zone has a serial number associated with it.  Its use is for
-   keeping track of who has the most current data.  If and only if the
-   primary's serial number of the zone is greater will the secondary ask
-   the primary for a copy of the new zone data (see special case below).
-
-   Don't forget to change the serial number when you change data!  If
-   you don't, your secondaries will not transfer the new zone
-   information.  Automating the incrementing of the serial number with
-   software is also a good idea.
-
-   If you make a mistake and increment the serial number too high, and
-   you want to reset the serial number to a lower value, use the
-   following procedure:
-
-
-
-
-
-Barr                         Informational                     [Page 11]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-      Take the `incorrect' serial number and add 2147483647 to it.  If
-      the number exceeds 4294967296, subtract 4294967296.  Load the
-      resulting number.  Then wait 2 refresh periods to allow the zone
-      to propagate to all servers.
-
-      Repeat above until the resulting serial number is less than the
-      target serial number.
-
-      Up the serial number to the target serial number.
-
-   This procedure won't work if one of your secondaries is running an
-   old version of BIND (4.8.3 or earlier).  In this case you'll have to
-   contact the hostmaster for that secondary and have them kill the
-   secondary servers, remove the saved backup file, and restart the
-   server.  Be careful when editing the serial number -- DNS admins
-   don't like to kill and restart nameservers because you lose all that
-   cached data.
-
-3.2 Zone file style guide
-
-   Here are some useful tips in structuring your zone files.  Following
-   these will help you spot mistakes, and avoid making more.
-
-   Be consistent with the style of entries in your DNS files. If your
-   $ORIGIN is podunk.xx., try not to write entries like:
-
-           mary            IN      A       1.2.3.1
-           sue.podunk.xx.  IN      A       1.2.3.2
-
-   or:
-
-           bobbi           IN      A       1.2.3.2
-                           IN      MX      mary.podunk.xx.
-
-
-   Either use all FQDNs (Fully Qualified Domain Names) everywhere or
-   used unqualified names everywhere.  Or have FQDNs all on the right-
-   hand side but unqualified names on the left.  Above all, be
-   consistent.
-
-   Use tabs between fields, and try to keep columns lined up.  It makes
-   it easier to spot missing fields (note some fields such as "IN" are
-   inherited from the previous record and may be left out in certain
-   circumstances.)
-
-
-
-
-
-
-
-Barr                         Informational                     [Page 12]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   Remember you don't need to repeat the name of the host when you are
-   defining multiple records for one host.  Be sure also to keep all
-   records associated with a host together in the file.  It will make
-   things more straightforward when it comes time to remove or rename a
-   host.
-
-   Always remember your $ORIGIN.  If you don't put a `.' at the end of
-   an FQDN, it's not recognized as an FQDN.  If it is not an FQDN, then
-   the nameserver will append $ORIGIN to the name.  Double check, triple
-   check, those trailing dots, especially in in-addr.arpa zone files,
-   where they are needed the most.
-
-   Be careful with the syntax of the SOA and WKS records (the records
-   which use parentheses).  BIND is not very flexible in how it parses
-   these records.  See the documentation for BIND.
-
-3.3 Verifying data
-
-   Verify the data you just entered or changed by querying the resolver
-   with dig (or your favorite DNS tool, many are included in the BIND
-   distribution) after a change.  A few seconds spent double checking
-   can save hours of trouble, lost mail, and general headaches.  Also be
-   sure to check syslog output when you reload the nameserver.  If you
-   have grievous errors in your DNS data or boot file, named will report
-   it via syslog.
-
-   It is also highly recommended that you automate this checking, either
-   with software which runs sanity checks on the data files before they
-   are loaded into the nameserver, or with software which checks the
-   data already loaded in the nameserver.  Some contributed software to
-   do this is included in the BIND distribution.
-
-4. Miscellaneous Topics
-
-4.1 Boot file setup
-
-   Certain zones should always be present in nameserver configurations:
-
-           primary         localhost               localhost
-           primary         0.0.127.in-addr.arpa    127.0
-           primary         255.in-addr.arpa        255
-           primary         0.in-addr.arpa          0
-
-   These are set up to either provide nameservice for "special"
-   addresses, or to help eliminate accidental queries for broadcast or
-   local address to be sent off to the root nameservers.  All of these
-   files will contain NS and SOA records just like the other zone files
-   you maintain, the exception being that you can probably make the SOA
-
-
-
-Barr                         Informational                     [Page 13]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   timers very long, since this data will never change.
-
-   The "localhost" address is a "special" address which always refers to
-   the local host.  It should contain the following line:
-
-           localhost.      IN      A       127.0.0.1
-
-   The "127.0" file should contain the line:
-
-           1    PTR     localhost.
-
-   There has been some extensive discussion about whether or not to
-   append the local domain to it.  The conclusion is that "localhost."
-   would be the best solution.  The reasons given include:
-
-      "localhost" by itself is used and expected to work in some
-      systems.
-
-      Translating 127.0.0.1 into "localhost.dom.ain" can cause some
-      software to connect back to the loopback interface when it didn't
-      want to because "localhost" is not equal to "localhost.dom.ain".
-
-   The "255" and "0" files should not contain any additional data beyond
-   the NS and SOA records.
-
-   Note that future BIND versions may include all or some of this data
-   automatically without additional configuration.
-
-4.2 Other Resolver and Server bugs
-
-   Very old versions of the DNS resolver have a bug that cause queries
-   for names that look like IP addresses to go out, because the user
-   supplied an IP address and the software didn't realize that it didn't
-   need to be resolved.  This has been fixed but occasionally it still
-   pops up.  It's important because this bug means that these queries
-   will be sent directly to the root nameservers, adding to an already
-   heavy DNS load.
-
-   While running a secondary nameserver off another secondary nameserver
-   is possible, it is not recommended unless necessary due to network
-   topologies.  There are known cases where it has led to problems like
-   bogus TTL values.  While this may be caused by older or flawed DNS
-   implementations, you should not chain secondaries off of one another
-   since this builds up additional reliability dependencies as well as
-   adds additional delays in updates of new zone data.
-
-
-
-
-
-
-Barr                         Informational                     [Page 14]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-4.3 Server issues
-
-   DNS operates primarily via UDP (User Datagram Protocol) messages.
-   Some UNIX operating systems, in an effort to save CPU cycles, run
-   with UDP checksums turned off.  The relative merits of this have long
-   been debated.  However, with the increase in CPU speeds, the
-   performance considerations become less and less important.  It is
-   strongly encouraged that you turn on UDP checksumming to avoid
-   corrupted data not only with DNS but with other services that use UDP
-   (like NFS).  Check with your operating system documentation to verify
-   that UDP checksumming is enabled.
-
-References
-
-   [RFC 974] Partridge, C., "Mail routing and the domain system", STD
-              14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
-
-   [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC
-              1033, USC/Information Sciences Institute, November 1987.
-
-   [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 1123] Braden, R., "Requirements for Internet Hosts --
-              Application and Support", STD 3, RFC 1123, IETF, October
-              1989.
-
-   [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC
-              1178, Integrated Systems Group/NIST, August 1990.
-
-   [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart,
-              "New DNS RR Definitions", RFC 1183, October 1990.
-
-   [RFC 1535] Gavron, E., "A Security Problem and Proposed Correction
-              With Widely Deployed DNS Software", RFC 1535, ACES
-              Research Inc., October 1993.
-
-   [RFC 1536] 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.
-
-
-
-
-
-Barr                         Informational                     [Page 15]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors",
-              RFC 1537, CWI, October 1993.
-
-   [RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN,
-              November 1994.
-
-   [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND",
-              Vixie Enterprises, July 1994.
-
-5. Security Considerations
-
-   Security issues are not discussed in this memo.
-
-6. Author's Address
-
-   David Barr
-   The Pennsylvania State University
-   Department of Mathematics
-   334 Whitmore Building
-   University Park, PA 16802
-
-   Voice: +1 814 863 7374
-   Fax: +1 814 863-8311
-   EMail: barr@math.psu.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barr                         Informational                     [Page 16]
-
diff --git a/doc/rfc/rfc1982.txt b/doc/rfc/rfc1982.txt
deleted file mode 100644
index 5a34bc42..00000000
--- a/doc/rfc/rfc1982.txt
+++ /dev/null
@@ -1,394 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             R. Elz
-Request for Comments: 1982                       University of Melbourne
-Updates: 1034, 1035                                              R. Bush
-Category: Standards Track                                    RGnet, Inc.
-                                                             August 1996
-
-
-                        Serial Number Arithmetic
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This memo defines serial number arithmetic, as used in the Domain
-   Name System.  The DNS has long relied upon serial number arithmetic,
-   a concept which has never really been defined, certainly not in an
-   IETF document, though which has been widely understood.  This memo
-   supplies the missing definition.  It is intended to update RFC1034
-   and RFC1035.
-
-1. Introduction
-
-   The serial number field of the SOA resource record is defined in
-   RFC1035 as
-
-   SERIAL   The unsigned 32 bit version number of the original copy of
-            the zone.  Zone transfers preserve this value.  This value
-            wraps and should be compared using sequence space
-            arithmetic.
-
-   RFC1034 uses the same terminology when defining secondary server zone
-   consistency procedures.
-
-   Unfortunately the term "sequence space arithmetic" is not defined in
-   either RFC1034 or RFC1035, nor do any of their references provide
-   further information.
-
-   This phrase seems to have been intending to specify arithmetic as
-   used in TCP sequence numbers [RFC793], and defined in [IEN-74].
-
-   Unfortunately, the arithmetic defined in [IEN-74] is not adequate for
-   the purposes of the DNS, as no general comparison operator is
-
-
-
-Elz & Bush                  Standards Track                     [Page 1]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-   defined.
-
-   To avoid further problems with this simple field, this document
-   defines the field and the operations available upon it.  This
-   definition is intended merely to clarify the intent of RFC1034 and
-   RFC1035, and is believed to generally agree with current
-   implementations.  However, older, superseded, implementations are
-   known to have treated the serial number as a simple unsigned integer,
-   with no attempt to implement any kind of "sequence space arithmetic",
-   however that may have been interpreted, and further, ignoring the
-   requirement that the value wraps.  Nothing can be done with these
-   implementations, beyond extermination.
-
-2. Serial Number Arithmetic
-
-   Serial numbers are formed from non-negative integers from a finite
-   subset of the range of all integer values.  The lowest integer in
-   every subset used for this purpose is zero, the maximum is always one
-   less than a power of two.
-
-   When considered as serial numbers however no value has any particular
-   significance, there is no minimum or maximum serial number, every
-   value has a successor and predecessor.
-
-   To define a serial number to be used in this way, the size of the
-   serial number space must be given.  This value, called "SERIAL_BITS",
-   gives the power of two which results in one larger than the largest
-   integer corresponding to a serial number value.  This also specifies
-   the number of bits required to hold every possible value of a serial
-   number of the defined type.  The operations permitted upon serial
-   numbers are defined in the following section.
-
-3. Operations upon the serial number
-
-   Only two operations are defined upon serial numbers, addition of a
-   positive integer of limited range, and comparison with another serial
-   number.
-
-3.1. Addition
-
-   Serial numbers may be incremented by the addition of a positive
-   integer n, where n is taken from the range of integers
-   [0 .. (2^(SERIAL_BITS - 1) - 1)].  For a sequence number s, the
-   result of such an addition, s', is defined as
-
-                   s' = (s + n) modulo (2 ^ SERIAL_BITS)
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 2]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-   where the addition and modulus operations here act upon values that
-   are non-negative values of unbounded size in the usual ways of
-   integer arithmetic.
-
-   Addition of a value outside the range
-   [0 .. (2^(SERIAL_BITS - 1) - 1)] is undefined.
-
-3.2. Comparison
-
-   Any two serial numbers, s1 and s2, may be compared.  The definition
-   of the result of this comparison is as follows.
-
-   For the purposes of this definition, consider two integers, i1 and
-   i2, from the unbounded set of non-negative integers, such that i1 and
-   s1 have the same numeric value, as do i2 and s2.  Arithmetic and
-   comparisons applied to i1 and i2 use ordinary unbounded integer
-   arithmetic.
-
-   Then, s1 is said to be equal to s2 if and only if i1 is equal to i2,
-   in all other cases, s1 is not equal to s2.
-
-   s1 is said to be less than s2 if, and only if, s1 is not equal to s2,
-   and
-
-        (i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) or
-        (i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1))
-
-   s1 is said to be greater than s2 if, and only if, s1 is not equal to
-   s2, and
-
-        (i1 < i2 and i2 - i1 > 2^(SERIAL_BITS - 1)) or
-        (i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1))
-
-   Note that there are some pairs of values s1 and s2 for which s1 is
-   not equal to s2, but for which s1 is neither greater than, nor less
-   than, s2.  An attempt to use these ordering operators on such pairs
-   of values produces an undefined result.
-
-   The reason for this is that those pairs of values are such that any
-   simple definition that were to define s1 to be less than s2 where
-   (s1, s2) is such a pair, would also usually cause s2 to be less than
-   s1, when the pair is (s2, s1).  This would mean that the particular
-   order selected for a test could cause the result to differ, leading
-   to unpredictable implementations.
-
-   While it would be possible to define the test in such a way that the
-   inequality would not have this surprising property, while being
-   defined for all pairs of values, such a definition would be
-
-
-
-Elz & Bush                  Standards Track                     [Page 3]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-   unnecessarily burdensome to implement, and difficult to understand,
-   and would still allow cases where
-
-        s1 < s2 and (s1 + 1) > (s2 + 1)
-
-   which is just as non-intuitive.
-
-   Thus the problem case is left undefined, implementations are free to
-   return either result, or to flag an error, and users must take care
-   not to depend on any particular outcome.  Usually this will mean
-   avoiding allowing those particular pairs of numbers to co-exist.
-
-   The relationships greater than or equal to, and less than or equal
-   to, follow in the natural way from the above definitions.
-
-4. Corollaries
-
-   These definitions give rise to some results of note.
-
-4.1. Corollary 1
-
-   For any sequence number s and any integer n such that addition of n
-   to s is well defined, (s + n) >= s.  Further (s + n) == s only when
-   n == 0, in all other defined cases, (s + n) > s.
-
-4.2. Corollary 2
-
-   If s' is the result of adding the non-zero integer n to the sequence
-   number s, and m is another integer from the range defined as able to
-   be added to a sequence number, and s" is the result of adding m to
-   s', then it is undefined whether s" is greater than, or less than s,
-   though it is known that s" is not equal to s.
-
-4.3. Corollary 3
-
-   If s" from the previous corollary is further incremented, then there
-   is no longer any known relationship between the result and s.
-
-4.4. Corollary 4
-
-   If in corollary 2 the value (n + m) is such that addition of the sum
-   to sequence number s would produce a defined result, then corollary 1
-   applies, and s" is known to be greater than s.
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 4]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-5. Examples
-
-5.1. A trivial example
-
-   The simplest meaningful serial number space has SERIAL_BITS == 2.  In
-   this space, the integers that make up the serial number space are 0,
-   1, 2, and 3.  That is, 3 == 2^SERIAL_BITS - 1.
-
-   In this space, the largest integer that it is meaningful to add to a
-   sequence number is 2^(SERIAL_BITS - 1) - 1, or 1.
-
-   Then, as defined 0+1 == 1, 1+1 == 2, 2+1 == 3, and 3+1 == 0.
-   Further, 1 > 0, 2 > 1, 3 > 2, and 0 > 3.  It is undefined whether
-   2 > 0 or 0 > 2, and whether 1 > 3 or 3 > 1.
-
-5.2. A slightly larger example
-
-   Consider the case where SERIAL_BITS == 8.  In this space the integers
-   that make up the serial number space are 0, 1, 2, ... 254, 255.
-   255 == 2^SERIAL_BITS - 1.
-
-   In this space, the largest integer that it is meaningful to add to a
-   sequence number is 2^(SERIAL_BITS - 1) - 1, or 127.
-
-   Addition is as expected in this space, for example: 255+1 == 0,
-   100+100 == 200, and 200+100 == 44.
-
-   Comparison is more interesting, 1 > 0, 44 > 0, 100 > 0, 100 > 44,
-   200 > 100, 255 > 200, 0 > 255, 100 > 255, 0 > 200, and 44 > 200.
-
-   Note that 100+100 > 100, but that (100+100)+100 < 100.  Incrementing
-   a serial number can cause it to become "smaller".  Of course,
-   incrementing by a smaller number will allow many more increments to
-   be made before this occurs.  However this is always something to be
-   aware of, it can cause surprising errors, or be useful as it is the
-   only defined way to actually cause a serial number to decrease.
-
-   The pairs of values 0 and 128, 1 and 129, 2 and 130, etc, to 127 and
-   255 are not equal, but in each pair, neither number is defined as
-   being greater than, or less than, the other.
-
-   It could be defined (arbitrarily) that 128 > 0, 129 > 1,
-   130 > 2, ..., 255 > 127, by changing the comparison operator
-   definitions, as mentioned above.  However note that that would cause
-   255 > 127, while (255 + 1) < (127 + 1), as 0 < 128.  Such a
-   definition, apart from being arbitrary, would also be more costly to
-   implement.
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 5]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-6. Citation
-
-   As this defined arithmetic may be useful for purposes other than for
-   the DNS serial number, it may be referenced as Serial Number
-   Arithmetic from RFC1982.  Any such reference shall be taken as
-   implying that the rules of sections 2 to 5 of this document apply to
-   the stated values.
-
-7. The DNS SOA serial number
-
-   The serial number in the DNS SOA Resource Record is a Serial Number
-   as defined above, with SERIAL_BITS being 32.  That is, the serial
-   number is a non negative integer with values taken from the range
-   [0 .. 4294967295].  That is, a 32 bit unsigned integer.
-
-   The maximum defined increment is 2147483647 (2^31 - 1).
-
-   Care should be taken that the serial number not be incremented, in
-   one or more steps, by more than this maximum within the period given
-   by the value of SOA.expire.  Doing so may leave some secondary
-   servers with out of date copies of the zone, but with a serial number
-   "greater" than that of the primary server.  Of course, special
-   circumstances may require this rule be set aside, for example, when
-   the serial number needs to be set lower for some reason.  If this
-   must be done, then take special care to verify that ALL servers have
-   correctly succeeded in following the primary server's serial number
-   changes, at each step.
-
-   Note that each, and every, increment to the serial number must be
-   treated as the start of a new sequence of increments for this
-   purpose, as well as being the continuation of all previous sequences
-   started within the period specified by SOA.expire.
-
-   Caution should also be exercised before causing the serial number to
-   be set to the value zero.  While this value is not in any way special
-   in serial number arithmetic, or to the DNS SOA serial number, many
-   DNS implementations have incorrectly treated zero as a special case,
-   with special properties, and unusual behaviour may be expected if
-   zero is used as a DNS SOA serial number.
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 6]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-8. Document Updates
-
-   RFC1034 and RFC1035 are to be treated as if the references to
-   "sequence space arithmetic" therein are replaced by references to
-   serial number arithmetic, as defined in this document.
-
-9. Security Considerations
-
-   This document does not consider security.
-
-   It is not believed that anything in this document adds to any
-   security issues that may exist with the DNS, nor does it do anything
-   to lessen them.
-
-References
-
-   [RFC1034]   Domain Names - Concepts and Facilities,
-               P. Mockapetris, STD 13, ISI, November 1987.
-
-   [RFC1035]   Domain Names - Implementation and Specification
-               P. Mockapetris, STD 13, ISI, November 1987
-
-   [RFC793]    Transmission Control protocol
-               Information Sciences Institute, STD 7, USC, September 1981
-
-   [IEN-74]    Sequence Number Arithmetic
-               William W. Plummer, BB&N Inc, September 1978
-
-Acknowledgements
-
-   Thanks to Rob Austein for suggesting clarification of the undefined
-   comparison operators, and to Michael Patton for attempting to locate
-   another reference for this procedure.  Thanks also to members of the
-   IETF DNSIND working group of 1995-6, in particular, Paul Mockapetris.
-
-Authors' Addresses
-
-   Robert Elz                     Randy Bush
-   Computer Science               RGnet, Inc.
-   University of Melbourne        10361 NE Sasquatch Lane
-   Parkville, Vic,  3052          Bainbridge Island, Washington,  98110
-   Australia.                     United States.
-
-   EMail: kre@munnari.OZ.AU       EMail: randy@psg.com
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 7]
diff --git a/doc/rfc/rfc1995.txt b/doc/rfc/rfc1995.txt
deleted file mode 100644
index b50bdc60..00000000
--- a/doc/rfc/rfc1995.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            M. Ohta
-Request for Comments: 1995                 Tokyo Institute of Technology
-Updates: 1035                                                August 1996
-Category: Standards Track
-
-
-                    Incremental Zone Transfer in DNS
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This document proposes extensions to the DNS protocols to provide an
-   incremental zone transfer (IXFR) mechanism.
-
-1. Introduction
-
-   For rapid propagation of changes to a DNS database [STD13], it is
-   necessary to reduce latency by actively notifying servers of the
-   change.  This is accomplished by the NOTIFY extension of the DNS
-   [NOTIFY].
-
-   The current full zone transfer mechanism (AXFR) is not an efficient
-   means to propagate changes to a small part of a zone, as it transfers
-   the entire zone file.
-
-   Incremental transfer (IXFR) as proposed is a more efficient
-   mechanism, as it transfers only the changed portion(s) of a zone.
-
-   In this document, a secondary name server which requests IXFR is
-   called an IXFR client and a primary or secondary name server which
-   responds to the request is called an IXFR server.
-
-2. Brief Description of the Protocol
-
-   If an IXFR client, which likely has an older version of a zone,
-   thinks it needs new information about the zone (typically through SOA
-   refresh timeout or the NOTIFY mechanism), it sends an IXFR message
-   containing the SOA serial number of its, presumably outdated, copy of
-   the zone.
-
-
-
-
-
-Ohta                        Standards Track                     [Page 1]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   An IXFR server should keep record of the newest version of the zone
-   and the differences between that copy and several older versions.
-   When an IXFR request with an older version number is received, the
-   IXFR server needs to send only the differences required to make that
-   version current.  Alternatively, the server may choose to transfer
-   the entire zone just as in a normal full zone transfer.
-
-   When a zone has been updated, it should be saved in stable storage
-   before the new version is used to respond to IXFR (or AXFR) queries.
-   Otherwise, if the server crashes, data which is no longer available
-   may have been distributed to secondary servers, which can cause
-   persistent database inconsistencies.
-
-   If an IXFR query with the same or newer version number than that of
-   the server is received, it is replied to with a single SOA record of
-   the server's current version, just as in AXFR.
-
-   Transport of a query may be by either UDP or TCP.  If an IXFR query
-   is via UDP, the IXFR server may attempt to reply using UDP if the
-   entire response can be contained in a single DNS packet.  If the UDP
-   reply does not fit, the query is responded to with a single SOA
-   record of the server's current version to inform the client that a
-   TCP query should be initiated.
-
-   Thus, a client should first make an IXFR query using UDP.  If the
-   query type is not recognized by the server, an AXFR (preceded by a
-   UDP SOA query) should be tried, ensuring backward compatibility.  If
-   the query response is a single packet with the entire new zone, or if
-   the server does not have a newer version than the client, everything
-   is done.  Otherwise, a TCP IXFR query should be tried.
-
-   To ensure integrity, servers should use UDP checksums for all UDP
-   responses.  A cautious client which receives a UDP packet with a
-   checksum value of zero should ignore the result and try a TCP IXFR
-   instead.
-
-   The query type value of IXFR assigned by IANA is 251.
-
-3. Query Format
-
-   The IXFR query packet format is the same as that of a normal DNS
-   query, but with the query type being IXFR and the authority section
-   containing the SOA record of client's version of the zone.
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 2]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-4. Response Format
-
-   If incremental zone transfer is not available, the entire zone is
-   returned.  The first and the last RR of the response is the SOA
-   record of the zone.  I.e. the behavior is the same as an AXFR
-   response except the query type is IXFR.
-
-   If incremental zone transfer is available, one or more difference
-   sequences is returned.  The list of difference sequences is preceded
-   and followed by a copy of the server's current version of the SOA.
-
-   Each difference sequence represents one update to the zone (one SOA
-   serial change) consisting of deleted RRs and added RRs.  The first RR
-   of the deleted RRs is the older SOA RR and the first RR of the added
-   RRs is the newer SOA RR.
-
-   Modification of an RR is performed first by removing the original RR
-   and then adding the modified one.
-
-   The sequences of differential information are ordered oldest first
-   newest last.  Thus, the differential sequences are the history of
-   changes made since the version known by the IXFR client up to the
-   server's current version.
-
-   RRs in the incremental transfer messages may be partial.  That is, if
-   a single RR of multiple RRs of the same RR type changes, only the
-   changed RR is transferred.
-
-   An IXFR client, should only replace an older version with a newer
-   version after all the differences have been successfully processed.
-
-   An incremental response is different from that of a non-incremental
-   response in that it begins with two SOA RRs, the server's current SOA
-   followed by the SOA of the client's version which is about to be
-   replaced.
-
-   5. Purging Strategy
-
-   An IXFR server can not be required to hold all previous versions
-   forever and may delete them anytime. In general, there is a trade-off
-   between the size of storage space and the possibility of using IXFR.
-
-   Information about older versions should be purged if the total length
-   of an IXFR response would be longer than that of an AXFR response.
-   Given that the purpose of IXFR is to reduce AXFR overhead, this
-   strategy is quite reasonable.  The strategy assures that the amount
-   of storage required is at most twice that of the current zone
-   information.
-
-
-
-Ohta                        Standards Track                     [Page 3]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   Information older than the SOA expire period may also be purged.
-
-6. Optional Condensation of Multiple Versions
-
-   An IXFR server may optionally condense multiple difference sequences
-   into a single difference sequence, thus, dropping information on
-   intermediate versions.
-
-   This may be beneficial if a lot of versions, not all of which are
-   useful, are generated. For example, if multiple ftp servers share a
-   single DNS name and the IP address associated with the name is
-   changed once a minute to balance load between the ftp servers, it is
-   not so important to keep track of all the history of changes.
-
-   But, this feature may not be so useful if an IXFR client has access
-   to two IXFR servers: A and B, with inconsistent condensation results.
-   The current version of the IXFR client, received from server A, may
-   be unknown to server B. In such a case, server B can not provide
-   incremental data from the unknown version and a full zone transfer is
-   necessary.
-
-   Condensation is completely optional. Clients can't detect from the
-   response whether the server has condensed the reply or not.
-
-   For interoperability, IXFR servers, including those without the
-   condensation feature, should not flag an error even if it receives a
-   client's IXFR request with a unknown version number and should,
-   instead, attempt to perform a full zone transfer.
-
-7. Example
-
-   Given the following three generations of data with the current serial
-   number of 3,
-
-      JAIN.AD.JP.         IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
-                                        1 600 600 3600000 604800)
-                          IN NS  NS.JAIN.AD.JP.
-      NS.JAIN.AD.JP.      IN A   133.69.136.1
-      NEZU.JAIN.AD.JP.    IN A   133.69.136.5
-
-   NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added.
-
-      jain.ad.jp.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
-                                        2 600 600 3600000 604800)
-                          IN NS  NS.JAIN.AD.JP.
-      NS.JAIN.AD.JP.      IN A   133.69.136.1
-      JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4
-                          IN A   192.41.197.2
-
-
-
-Ohta                        Standards Track                     [Page 4]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed.
-
-      JAIN.AD.JP.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
-                                        3 600 600 3600000 604800)
-                          IN NS  NS.JAIN.AD.JP.
-      NS.JAIN.AD.JP.      IN A   133.69.136.1
-      JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3
-                          IN A   192.41.197.2
-
-   The following IXFR query
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY                                     |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | <empty>                                           |
-                 +---------------------------------------------------+
-      Authority  | JAIN.AD.JP.         IN SOA serial=1               |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-   could be replied to with the following full zone transfer message:
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY, RESPONSE                           |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN.AD.JP.         IN NS  NS.JAIN.AD.JP.         |
-                 | NS.JAIN.AD.JP.      IN A   133.69.136.1           |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
-                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 +---------------------------------------------------+
-      Authority  | <empty>                                           |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 5]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   or with the following incremental message:
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY, RESPONSE                           |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN.AD.JP.         IN SOA serial=1               |
-                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
-                 | JAIN.AD.JP.         IN SOA serial=2               |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
-                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
-                 | JAIN.AD.JP.         IN SOA serial=2               |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 +---------------------------------------------------+
-      Authority  | <empty>                                           |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-   or with the following condensed incremental message:
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY, RESPONSE                           |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN.AD.JP.         IN SOA serial=1               |
-                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
-                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 +---------------------------------------------------+
-      Authority  | <empty>                                           |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 6]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   or, if UDP packet overflow occurs, with the following message:
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY, RESPONSE                           |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
-                 +---------------------------------------------------+
-      Authority  | <empty>                                           |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-8. Acknowledgements
-
-   The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
-   and Jon Postel.
-
-   For the refinement of the protocol and documentation, many people
-   have contributed including, but not limited to, Anant Kumar, Robert
-   Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the
-   members of the IETF DNSIND working group.
-
-9. References
-
-   [NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for Prompt
-   Notification of Zone Changes", RFC 1996, August 1996.
-
-   [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and
-   RFC 1035), November 1987.
-
-10. Security Considerations
-
-   Though DNS is related to several security problems, no attempt is
-   made to fix them in this document.
-
-   This document is believed to introduce no additional security
-   problems to the current DNS protocol.
-
-
-
-
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 7]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-11. Author's Address
-
-   Masataka Ohta
-   Computer Center
-   Tokyo Institute of Technology
-   2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN
-
-   Phone: +81-3-5734-3299
-   Fax: +81-3-5734-3415
-   EMail: mohta@necom830.hpcl.titech.ac.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 8]
-
diff --git a/doc/rfc/rfc1996.txt b/doc/rfc/rfc1996.txt
deleted file mode 100644
index b08f2007..00000000
--- a/doc/rfc/rfc1996.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           P. Vixie
-Request for Comments: 1996                                           ISC
-Updates: 1035                                                August 1996
-Category: Standards Track
-
-
-    A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This memo describes the NOTIFY opcode for DNS, by which a master
-   server advises a set of slave servers that the master's data has been
-   changed and that a query should be initiated to discover the new
-   data.
-
-1. Rationale and Scope
-
-   1.1. Slow propagation of new and changed data in a DNS zone can be
-   due to a zone's relatively long refresh times.  Longer refresh times
-   are beneficial in that they reduce load on the master servers, but
-   that benefit comes at the cost of long intervals of incoherence among
-   authority servers whenever the zone is updated.
-
-   1.2. The DNS NOTIFY transaction allows master servers to inform slave
-   servers when the zone has changed -- an interrupt as opposed to poll
-   model -- which it is hoped will reduce propagation delay while not
-   unduly increasing the masters' load.  This specification only allows
-   slaves to be notified of SOA RR changes, but the architechture of
-   NOTIFY is intended to be extensible to other RR types.
-
-   1.3. This document intentionally gives more definition to the roles
-   of "Master," "Slave" and "Stealth" servers, their enumeration in NS
-   RRs, and the SOA MNAME field.  In that sense, this document can be
-   considered an addendum to [RFC1035].
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 1]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-2. Definitions and Invariants
-
-   2.1. The following definitions are used in this document:
-
-   Slave           an authoritative server which uses zone transfer to
-                   retrieve the zone.  All slave servers are named in
-                   the NS RRs for the zone.
-
-   Master          any authoritative server configured to be the source
-                   of zone transfer for one or more slave servers.
-
-   Primary Master  master server at the root of the zone transfer
-                   dependency graph.  The primary master is named in the
-                   zone's SOA MNAME field and optionally by an NS RR.
-                   There is by definition only one primary master server
-                   per zone.
-
-   Stealth         like a slave server except not listed in an NS RR for
-                   the zone.  A stealth server, unless explicitly
-                   configured to do otherwise, will set the AA bit in
-                   responses and be capable of acting as a master.  A
-                   stealth server will only be known by other servers if
-                   they are given static configuration data indicating
-                   its existence.
-
-   Notify Set      set of servers to be notified of changes to some
-                   zone.  Default is all servers named in the NS RRset,
-                   except for any server also named in the SOA MNAME.
-                   Some implementations will permit the name server
-                   administrator to override this set or add elements to
-                   it (such as, for example, stealth servers).
-
-   2.2. The zone's servers must be organized into a dependency graph
-   such that there is a primary master, and all other servers must use
-   AXFR or IXFR either from the primary master or from some slave which
-   is also a master.  No loops are permitted in the AXFR dependency
-   graph.
-
-3. NOTIFY Message
-
-   3.1. When a master has updated one or more RRs in which slave servers
-   may be interested, the master may send the changed RR's name, class,
-   type, and optionally, new RDATA(s), to each known slave server using
-   a best efforts protocol based on the NOTIFY opcode.
-
-   3.2. NOTIFY uses the DNS Message Format, although it uses only a
-   subset of the available fields.  Fields not otherwise described
-   herein are to be filled with binary zero (0), and implementations
-
-
-
-Vixie                       Standards Track                     [Page 2]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-   must ignore all messages for which this is not the case.
-
-   3.3. NOTIFY is similar to QUERY in that it has a request message with
-   the header QR flag "clear" and a response message with QR "set".  The
-   response message contains no useful information, but its reception by
-   the master is an indication that the slave has received the NOTIFY
-   and that the master can remove the slave from any retry queue for
-   this NOTIFY event.
-
-   3.4. The transport protocol used for a NOTIFY transaction will be UDP
-   unless the master has reason to believe that TCP is necessary; for
-   example, if a firewall has been installed between master and slave,
-   and only TCP has been allowed; or, if the changed RR is too large to
-   fit in a UDP/DNS datagram.
-
-   3.5. If TCP is used, both master and slave must continue to offer
-   name service during the transaction, even when the TCP transaction is
-   not making progress.  The NOTIFY request is sent once, and a
-   "timeout" is said to have occurred if no NOTIFY response is received
-   within a reasonable interval.
-
-   3.6. If UDP is used, a master periodically sends a NOTIFY request to
-   a slave until either too many copies have been sent (a "timeout"), an
-   ICMP message indicating that the port is unreachable, or until a
-   NOTIFY response is received from the slave with a matching query ID,
-   QNAME, IP source address, and UDP source port number.
-
-   Note:
-      The interval between transmissions, and the total number of
-      retransmissions, should be operational parameters specifiable by
-      the name server administrator, perhaps on a per-zone basis.
-      Reasonable defaults are a 60 second interval (or timeout if
-      using TCP), and a maximum of 5 retransmissions (for UDP).  It is
-      considered reasonable to use additive or exponential backoff for
-      the retry interval.
-
-   3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
-   ADCOUNT>=0.  If ANCOUNT>0, then the answer section represents an
-   unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>.  A
-   slave receiving such a hint is free to treat equivilence of this
-   answer section with its local data as a "no further work needs to be
-   done" indication.  If ANCOUNT=0, or ANCOUNT>0 and the answer section
-   differs from the slave's local data, then the slave should query its
-   known masters to retrieve the new data.
-
-   3.8. In no case shall the answer section of a NOTIFY request be used
-   to update a slave's local data, or to indicate that a zone transfer
-   needs to be undertaken, or to change the slave's zone refresh timers.
-
-
-
-Vixie                       Standards Track                     [Page 3]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-   Only a "data present; data same" condition can lead a slave to act
-   differently if ANCOUNT>0 than it would if ANCOUNT=0.
-
-   3.9. This version of the NOTIFY specification makes no use of the
-   authority or additional data sections, and so conforming
-   implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting
-   requests.  Since a future revision of this specification may define a
-   backwards compatible use for either or both of these sections,
-   current implementations must ignore these sections, but not the
-   entire message, if AUCOUNT>0 and/or ADCOUNT>0.
-
-   3.10. If a slave receives a NOTIFY request from a host that is not a
-   known master for the zone containing the QNAME, it should ignore the
-   request and produce an error message in its operations log.
-
-   Note:
-      This implies that slaves of a multihomed master must either know
-      their master by the "closest" of the master's interface
-      addresses, or must know all of the master's interface addresses.
-      Otherwise, a valid NOTIFY request might come from an address
-      that is not on the slave's state list of masters for the zone,
-      which would be an error.
-
-   3.11. The only defined NOTIFY event at this time is that the SOA RR
-   has changed.  Upon completion of a NOTIFY transaction for QTYPE=SOA,
-   the slave should behave as though the zone given in the QNAME had
-   reached its REFRESH interval (see [RFC1035]), i.e., it should query
-   its masters for the SOA of the zone given in the NOTIFY QNAME, and
-   check the answer to see if the SOA SERIAL has been incremented since
-   the last time the zone was fetched.  If so, a zone transfer (either
-   AXFR or IXFR) should be initiated.
-
-   Note:
-      Because a deep server dependency graph may have multiple paths
-      from the primary master to any given slave, it is possible that
-      a slave will receive a NOTIFY from one of its known masters even
-      though the rest of its known masters have not yet updated their
-      copies of the zone.  Therefore, when issuing a QUERY for the
-      zone's SOA, the query should be directed at the known master who
-      was the source of the NOTIFY event, and not at any of the other
-      known masters.  This represents a departure from [RFC1035],
-      which specifies that upon expiry of the SOA REFRESH interval,
-      all known masters should be queried in turn.
-
-   3.12. If a NOTIFY request is received by a slave who does not
-   implement the NOTIFY opcode, it will respond with a NOTIMP
-   (unimplemented feature error) message.  A master server who receives
-   such a NOTIMP should consider the NOTIFY transaction complete for
-
-
-
-Vixie                       Standards Track                     [Page 4]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-   that slave.
-
-4. Details and Examples
-
-   4.1. Retaining query state information across host reboots is
-   optional, but it is reasonable to simply execute an SOA NOTIFY
-   transaction on each authority zone when a server first starts.
-
-   4.2. Each slave is likely to receive several copies of the same
-   NOTIFY request:  One from the primary master, and one from each other
-   slave as that slave transfers the new zone and notifies its potential
-   peers.  The NOTIFY protocol supports this multiplicity by requiring
-   that NOTIFY be sent by a slave/master only AFTER it has updated the
-   SOA RR or has determined that no update is necessary, which in
-   practice means after a successful zone transfer.  Thus, barring
-   delivery reordering, the last NOTIFY any slave receives will be the
-   one indicating the latest change.  Since a slave always requests SOAs
-   and AXFR/IXFRs only from its known masters, it will have an
-   opportunity to retry its QUERY for the SOA after each of its masters
-   have completed each zone update.
-
-   4.3. If a master server seeks to avoid causing a large number of
-   simultaneous outbound zone transfers, it may delay for an arbitrary
-   length of time before sending a NOTIFY message to any given slave.
-   It is expected that the time will be chosen at random, so that each
-   slave will begin its transfer at a unique time.  The delay shall not
-   in any case be longer than the SOA REFRESH time.
-
-   Note:
-      This delay should be a parameter that each primary master name
-      server can specify, perhaps on a per-zone basis.  Random delays
-      of between 30 and 60 seconds would seem adequate if the servers
-      share a LAN and the zones are of moderate size.
-
-   4.4. A slave which receives a valid NOTIFY should defer action on any
-   subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
-   completed the transaction begun by the first NOTIFY.  This duplicate
-   rejection is necessary to avoid having multiple notifications lead to
-   pummeling the master server.
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 5]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-   4.5 Zone has Updated on Primary Master
-
-   Primary master sends a NOTIFY request to all servers named in Notify
-   Set.  The NOTIFY request has the following characteristics:
-
-      query ID:   (new)
-      op:         NOTIFY (4)
-      resp:       NOERROR
-      flags:      AA
-      qcount:     1
-      qname:      (zone name)
-      qclass:     (zone class)
-      qtype:      T_SOA
-
-   4.6 Zone has Updated on a Slave that is also a Master
-
-   As above in 4.5, except that this server's Notify Set may be
-   different from the Primary Master's due to optional static
-   specification of local stealth servers.
-
-   4.7 Slave Receives a NOTIFY Request from a Master
-
-   When a slave server receives a NOTIFY request from one of its locally
-   designated masters for the zone enclosing the given QNAME, with
-   QTYPE=SOA and QR=0, it should enter the state it would if the zone's
-   refresh timer had expired.  It will also send a NOTIFY response back
-   to the NOTIFY request's source, with the following characteristics:
-
-      query ID:   (same)
-      op:         NOTIFY (4)
-      resp:       NOERROR
-      flags:      QR AA
-      qcount:     1
-      qname:      (zone name)
-      qclass:     (zone class)
-      qtype:      T_SOA
-
-   This is intended to be identical to the NOTIFY request, except that
-   the QR bit is also set.  The query ID of the response must be the
-   same as was received in the request.
-
-   4.8 Master Receives a NOTIFY Response from Slave
-
-   When a master server receives a NOTIFY response, it deletes this
-   query from the retry queue, thus completing the "notification
-   process" of "this" RRset change to "that" server.
-
-
-
-
-
-Vixie                       Standards Track                     [Page 6]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-5. Security Considerations
-
-   We believe that the NOTIFY operation's only security considerations
-   are:
-
-   1. That a NOTIFY request with a forged IP/UDP source address can
-      cause a slave to send spurious SOA queries to its masters,
-      leading to a benign denial of service attack if the forged
-      requests are sent very often.
-
-   2. That TCP spoofing could be used against a slave server given
-      NOTIFY as a means of synchronizing an SOA query and UDP/DNS
-      spoofing as a means of forcing a zone transfer.
-
-6. References
-
-   [RFC1035]
-      Mockapetris, P., "Domain Names - Implementation and
-      Specification", STD 13, RFC 1035, November 1987.
-
-   [IXFR]
-      Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
-
-7. Author's Address
-
-   Paul Vixie
-   Internet Software Consortium
-   Star Route Box 159A
-   Woodside, CA 94062
-
-   Phone: +1 415 747 0204
-   EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 7]
-
diff --git a/doc/rfc/rfc2052.txt b/doc/rfc/rfc2052.txt
deleted file mode 100644
index 46ba3629..00000000
--- a/doc/rfc/rfc2052.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     A. Gulbrandsen
-Request for Comments: 2052                            Troll Technologies
-Updates: 1035, 1183                                             P. Vixie
-Category: Experimental                                 Vixie Enterprises
-                                                            October 1996
-
-
-       A DNS RR for specifying the location of services (DNS SRV)
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  This memo does not specify an Internet standard of any
-   kind.  Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Abstract
-
-   This document describes a DNS RR which specifies the location of the
-   server(s) for a specific protocol and domain (like a more general
-   form of MX).
-
-Overview and rationale
-
-   Currently, one must either know the exact address of a server to
-   contact it, or broadcast a question.  This has led to, for example,
-   ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC-
-   level broadcasts to locate servers.
-
-   The SRV RR allows administrators to use several servers for a single
-   domain, to move services from host to host with little fuss, and to
-   designate some hosts as primary servers for a service and others as
-   backups.
-
-   Clients ask for a specific service/protocol for a specific domain
-   (the word domain is used here in the strict RFC 1034 sense), and get
-   back the names of any available servers.
-
-Introductory example
-
-   When a SRV-cognizant web-browser wants to retrieve
-
-      http://www.asdf.com/
-
-   it does a lookup of
-
-      http.tcp.www.asdf.com
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 1]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-   and retrieves the document from one of the servers in the reply.  The
-   example zone file near the end of the memo contains answering RRs for
-   this query.
-
-The format of the SRV RR
-
-   Here is the format of the SRV RR, whose DNS type code is 33:
-
-        Service.Proto.Name TTL Class SRV Priority Weight Port Target
-
-        (There is an example near the end of this document.)
-
-   Service
-        The symbolic name of the desired service, as defined in Assigned
-        Numbers or locally.
-
-        Some widely used services, notably POP, don't have a single
-        universal name.  If Assigned Numbers names the service
-        indicated, that name is the only name which is legal for SRV
-        lookups.  Only locally defined services may be named locally.
-        The Service is case insensitive.
-
-   Proto
-        TCP and UDP are at present the most useful values
-        for this field, though any name defined by Assigned Numbers or
-        locally may be used (as for Service).  The Proto is case
-        insensitive.
-
-   Name
-        The domain this RR refers to.  The SRV RR is unique in that the
-        name one searches for is not this name; the example near the end
-        shows this clearly.
-
-   TTL
-        Standard DNS meaning.
-
-   Class
-        Standard DNS meaning.
-
-   Priority
-        As for MX, the priority of this target host.  A client MUST
-        attempt to contact the target host with the lowest-numbered
-        priority it can reach; target hosts with the same priority
-        SHOULD be tried in pseudorandom order.  The range is 0-65535.
-
-
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 2]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-   Weight
-        Load balancing mechanism.  When selecting a target host among
-        the those that have the same priority, the chance of trying this
-        one first SHOULD be proportional to its weight.  The range of
-        this number is 1-65535.  Domain administrators are urged to use
-        Weight 0 when there isn't any load balancing to do, to make the
-        RR easier to read for humans (less noisy).
-
-   Port
-        The port on this target host of this service.  The range is
-        0-65535.  This is often as specified in Assigned Numbers but
-        need not be.
-
-   Target
-        As for MX, the domain name of the target host.  There MUST be
-        one or more A records for this name. Implementors are urged, but
-        not required, to return the A record(s) in the Additional Data
-        section.  Name compression is to be used for this field.
-
-        A Target of "." means that the service is decidedly not
-        available at this domain.
-
-Domain administrator advice
-
-   Asking everyone to update their telnet (for example) clients when the
-   first internet site adds a SRV RR for Telnet/TCP is futile (even if
-   desirable).  Therefore SRV will have to coexist with A record lookups
-   for a long time, and DNS administrators should try to provide A
-   records to support old clients:
-
-      - Where the services for a single domain are spread over several
-        hosts, it seems advisable to have a list of A RRs at the same
-        DNS node as the SRV RR, listing reasonable (if perhaps
-        suboptimal) fallback hosts for Telnet, NNTP and other protocols
-        likely to be used with this name.  Note that some programs only
-        try the first address they get back from e.g. gethostbyname(),
-        and we don't know how widespread this behaviour is.
-
-      - Where one service is provided by several hosts, one can either
-        provide A records for all the hosts (in which case the round-
-        robin mechanism, where available, will share the load equally)
-        or just for one (presumably the fastest).
-
-      - If a host is intended to provide a service only when the main
-        server(s) is/are down, it probably shouldn't be listed in A
-        records.
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 3]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-      - Hosts that are referenced by backup A records must use the port
-        number specified in Assigned Numbers for the service.
-
-   Currently there's a practical limit of 512 bytes for DNS replies.
-   Until all resolvers can handle larger responses, domain
-   administrators are strongly advised to keep their SRV replies below
-   512 bytes.
-
-   All round numbers, wrote Dr. Johnson, are false, and these numbers
-   are very round: A reply packet has a 30-byte overhead plus the name
-   of the service ("telnet.tcp.asdf.com" for instance); each SRV RR adds
-   20 bytes plus the name of the target host; each NS RR in the NS
-   section is 15 bytes plus the name of the name server host; and
-   finally each A RR in the additional data section is 20 bytes or so,
-   and there are A's for each SRV and NS RR mentioned in the answer.
-   This size estimate is extremely crude, but shouldn't underestimate
-   the actual answer size by much.  If an answer may be close to the
-   limit, using e.g. "dig" to look at the actual answer is a good idea.
-
-The "Weight" field
-
-   Weight, the load balancing field, is not quite satisfactory, but the
-   actual load on typical servers changes much too quickly to be kept
-   around in DNS caches.  It seems to the authors that offering
-   administrators a way to say "this machine is three times as fast as
-   that one" is the best that can practically be done.
-
-   The only way the authors can see of getting a "better" load figure is
-   asking a separate server when the client selects a server and
-   contacts it.  For short-lived services like SMTP an extra step in the
-   connection establishment seems too expensive, and for long-lived
-   services like telnet, the load figure may well be thrown off a minute
-   after the connection is established when someone else starts or
-   finishes a heavy job.
-
-The Port number
-
-   Currently, the translation from service name to port number happens
-   at the client, often using a file such as /etc/services.
-
-   Moving this information to the DNS makes it less necessary to update
-   these files on every single computer of the net every time a new
-   service is added, and makes it possible to move standard services out
-   of the "root-only" port range on unix
-
-
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 4]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-Usage rules
-
-   A SRV-cognizant client SHOULD use this procedure to locate a list of
-   servers and connect to the preferred one:
-
-        Do a lookup for QNAME=service.protocol.target, QCLASS=IN,
-        QTYPE=SRV.
-
-        If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV
-        RR which specifies the requested Service and Protocol in the
-        reply:
-
-             If there is precisely one SRV RR, and its Target is "."
-             (the root domain), abort.
-
-             Else, for all such RR's, build a list of (Priority, Weight,
-             Target) tuples
-
-             Sort the list by priority (lowest number first)
-
-             Create a new empty list
-
-             For each distinct priority level
-                  While there are still elements left at this priority
-                  level
-                       Select an element randomly, with probability
-                       Weight, and move it to the tail of the new list
-
-             For each element in the new list
-
-                  query the DNS for A RR's for the Target or use any
-                  RR's found in the Additional Data secion of the
-                  earlier SRV query.
-
-                  for each A RR found, try to connect to the (protocol,
-                  address, service).
-
-        else if the service desired is SMTP
-
-             skip to RFC 974 (MX).
-
-        else
-
-             Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
-
-             for each A RR found, try to connect to the (protocol,
-             address, service)
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 5]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-   Notes:
-
-      - Port numbers SHOULD NOT be used in place of the symbolic service
-        or protocol names (for the same reason why variant names cannot
-        be allowed: Applications would have to do two or more lookups).
-
-      - If a truncated response comes back from an SRV query, and the
-        Additional Data section has at least one complete RR in it, the
-        answer MUST be considered complete and the client resolver
-        SHOULD NOT retry the query using TCP, but use normal UDP queries
-        for A RR's missing from the Additional Data section.
-
-      - A client MAY use means other than Weight to choose among target
-        hosts with equal Priority.
-
-      - A client MUST parse all of the RR's in the reply.
-
-      - If the Additional Data section doesn't contain A RR's for all
-        the SRV RR's and the client may want to connect to the target
-        host(s) involved, the client MUST look up the A RR(s).  (This
-        happens quite often when the A RR has shorter TTL than the SRV
-        or NS RR's.)
-
-      - A future standard could specify that a SRV RR whose Protocol was
-        TCP and whose Service was SMTP would override RFC 974's rules
-        with regard to the use of an MX RR.  This would allow firewalled
-        organizations with several SMTP relays to control the load
-        distribution using the Weight field.
-
-      - Future protocols could be designed to use SRV RR lookups as the
-        means by which clients locate their servers.
-
-Fictional example
-
-   This is (part of) the zone file for asdf.com, a still-unused domain:
-
-        $ORIGIN asdf.com.
-        @               SOA server.asdf.com. root.asdf.com. (
-                            1995032001 3600 3600 604800 86400 )
-                        NS  server.asdf.com.
-                        NS  ns1.ip-provider.net.
-                        NS  ns2.ip-provider.net.
-        ftp.tcp         SRV 0 0 21 server.asdf.com.
-        finger.tcp      SRV 0 0 79 server.asdf.com.
-        ; telnet - use old-slow-box or new-fast-box if either is
-        ; available, make three quarters of the logins go to
-        ; new-fast-box.
-        telnet.tcp      SRV 0 1 23 old-slow-box.asdf.com.
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 6]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-                        SRV 0 3 23 new-fast-box.asdf.com.
-        ; if neither old-slow-box or new-fast-box is up, switch to
-        ; using the sysdmin's box and the server
-                        SRV 1 0 23 sysadmins-box.asdf.com.
-                        SRV 1 0 23 server.asdf.com.
-        ; HTTP - server is the main server, new-fast-box is the backup
-        ; (On new-fast-box, the HTTP daemon runs on port 8000)
-        http.tcp        SRV 0 0 80 server.asdf.com.
-                        SRV 10 0 8000 new-fast-box.asdf.com.
-        ; since we want to support both http://asdf.com/ and
-        ; http://www.asdf.com/ we need the next two RRs as well
-        http.tcp.www    SRV 0 0 80 server.asdf.com.
-                        SRV 10 0 8000 new-fast-box.asdf.com.
-        ; SMTP - mail goes to the server, and to the IP provider if
-        ; the net is down
-        smtp.tcp        SRV 0 0 25 server.asdf.com.
-                        SRV 1 0 25 mailhost.ip-provider.net.
-        @               MX  0 server.asdf.com.
-                        MX  1 mailhost.ip-provider.net.
-        ; NNTP - use the IP providers's NNTP server
-        nntp.tcp        SRV 0 0 119 nntphost.ip-provider.net.
-        ; IDB is an locally defined protocol
-        idb.tcp         SRV  0 0 2025 new-fast-box.asdf.com.
-        ; addresses
-        server          A   172.30.79.10
-        old-slow-box    A   172.30.79.11
-        sysadmins-box   A   172.30.79.12
-        new-fast-box    A   172.30.79.13
-        ; backup A records - new-fast-box and old-slow-box are
-        ; included, naturally, and server is too, but might go
-        ; if the load got too bad
-        @               A   172.30.79.10
-                        A   172.30.79.11
-                        A   172.30.79.13
-        ; backup A RR for www.asdf.com
-        www             A       172.30.79.10
-        ; NO other services are supported
-        *.tcp           SRV  0 0 0 .
-        *.udp           SRV  0 0 0 .
-
-   In this example, a telnet connection to "asdf.com." needs an SRV
-   lookup of "telnet.tcp.asdf.com." and possibly A lookups of "new-
-   fast-box.asdf.com." and/or the other hosts named.  The size of the
-   SRV reply is approximately 365 bytes:
-
-      30 bytes general overhead
-      20 bytes for the query string, "telnet.tcp.asdf.com."
-      130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 7]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-        fast-box", "old-slow-box", "server" and "sysadmins-box" -
-        "asdf.com" in the query section is quoted here and doesn't
-        need to be counted again.
-      75 bytes for 3 NS RRs, 15 bytes each plus the lengths of
-        "server", "ns1.ip-provider.net." and "ns2" - again, "ip-
-        provider.net." is quoted and only needs to be counted once.
-      120 bytes for the 6 A RR's mentioned by the SRV and NS RR's.
-
-Refererences
-
-   RFC 1918: Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
-        and E.  Lear, "Address Allocation for Private Internets",
-        RFC 1918, February 1996.
-
-   RFC 1916 Berkowitz, H., Ferguson, P, Leland, W. and P. Nesser,
-        "Enterprise Renumbering: Experience and Information
-        Solicitation", RFC 1916, February 1996.
-
-   RFC 1912 Barr, D., "Common DNS Operational and Configuration
-        Errors", RFC 1912, February 1996.
-
-   RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
-        RFC 1900, February 1996.
-
-   RFC 1920: Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS",
-        STD 1, RFC 1920, March 1996.
-
-   RFC 1814: Gerich, E., "Unique Addresses are Good", RFC 1814, June
-             1995.
-
-   RFC 1794: Brisco, T., "DNS Support for Load Balancing", April 1995.
-
-   RFC 1713: Romao, A., "Tools for DNS debugging", November 1994.
-
-   RFC 1712: Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni,
-        "DNS Encoding of Geographical Location", RFC 1712, November
-        1994.
-
-   RFC 1706: Manning, B. and R. Colella, "DNS NSAP Resource Records",
-        RFC 1706, October 1994.
-
-   RFC 1700: Reynolds, J., and J. Postel, "ASSIGNED NUMBERS",
-        STD 2, RFC 1700, October 1994.
-
-   RFC 1183: Ullmann, R., Mockapetris, P., Mamakos, L., and
-        C. Everhart, "New DNS RR Definitions", RFC 1183, November
-        1990.
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 8]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-   RFC 1101: Mockapetris, P., "DNS encoding of network names and other
-        types", RFC 1101, April 1989.
-
-   RFC 1035: Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   RFC 1034: Mockapetris, P., "Domain names - concepts and
-        facilities", STD 13, RFC 1034, November 1987.
-
-   RFC 1033: Lottor, M., "Domain administrators operations guide",
-        RFC 1033, November 1987.
-
-   RFC 1032: Stahl, M., "Domain administrators guide", RFC 1032,
-        November 1987.
-
-   RFC 974: Partridge, C., "Mail routing and the domain system",
-        STD 14, RFC 974, January 1986.
-
-Security Considerations
-
-   The authors believes this RR to not cause any new security problems.
-   Some problems become more visible, though.
-
-      - The ability to specify ports on a fine-grained basis obviously
-        changes how a router can filter packets.  It becomes impossible
-        to block internal clients from accessing specific external
-        services, slightly harder to block internal users from running
-        unautorised services, and more important for the router
-        operations and DNS operations personnel to cooperate.
-
-      - There is no way a site can keep its hosts from being referenced
-        as servers (as, indeed, some sites become unwilling secondary
-        MXes today).  This could lead to denial of service.
-
-      - With SRV, DNS spoofers can supply false port numbers, as well as
-        host names and addresses.  The authors do not see any practical
-        effect of this.
-
-   We assume that as the DNS-security people invent new features, DNS
-   servers will return the relevant RRs in the Additional Data section
-   when answering an SRV query.
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 9]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-Authors' Addresses
-
-   Arnt Gulbrandsen
-   Troll Tech
-   Postboks 6133 Etterstad
-   N-0602 Oslo
-   Norway
-
-   Phone: +47 22646966
-   EMail: agulbra@troll.no
-
-
-   Paul Vixie
-   Vixie Enterprises
-   Star Route 159A
-   Woodside, CA  94062
-
-   Phone: (415) 747-0204
-   EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                     [Page 10]
-
diff --git a/doc/rfc/rfc2104.txt b/doc/rfc/rfc2104.txt
deleted file mode 100644
index a205103a..00000000
--- a/doc/rfc/rfc2104.txt
+++ /dev/null
@@ -1,620 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       H. Krawczyk
-Request for Comments: 2104                                          IBM
-Category: Informational                                      M. Bellare
-                                                                   UCSD
-                                                             R. Canetti
-                                                                    IBM
-                                                          February 1997
-
-
-             HMAC: Keyed-Hashing for Message Authentication
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   This document describes HMAC, a mechanism for message authentication
-   using cryptographic hash functions. HMAC can be used with any
-   iterative cryptographic hash function, e.g., MD5, SHA-1, in
-   combination with a secret shared key.  The cryptographic strength of
-   HMAC depends on the properties of the underlying hash function.
-
-1. Introduction
-
-   Providing a way to check the integrity of information transmitted
-   over or stored in an unreliable medium is a prime necessity in the
-   world of open computing and communications. Mechanisms that provide
-   such integrity check based on a secret key are usually called
-   "message authentication codes" (MAC). Typically, message
-   authentication codes are used between two parties that share a secret
-   key in order to validate information transmitted between these
-   parties. In this document we present such a MAC mechanism based on
-   cryptographic hash functions. This mechanism, called HMAC, is based
-   on work by the authors [BCK1] where the construction is presented and
-   cryptographically analyzed. We refer to that work for the details on
-   the rationale and security analysis of HMAC, and its comparison to
-   other keyed-hash methods.
-
-
-
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 1]
-
-RFC 2104                          HMAC                     February 1997
-
-
-   HMAC can be used in combination with any iterated cryptographic hash
-   function. MD5 and SHA-1 are examples of such hash functions. HMAC
-   also uses a secret key for calculation and verification of the
-   message authentication values. The main goals behind this
-   construction are
-
-   * To use, without modifications, available hash functions.
-     In particular, hash functions that perform well in software,
-     and for which code is freely and widely available.
-
-   * To preserve the original performance of the hash function without
-     incurring a significant degradation.
-
-   * To use and handle keys in a simple way.
-
-   * To have a well understood cryptographic analysis of the strength of
-     the authentication mechanism based on reasonable assumptions on the
-     underlying hash function.
-
-   * To allow for easy replaceability of the underlying hash function in
-     case that faster or more secure hash functions are found or
-     required.
-
-   This document specifies HMAC using a generic cryptographic hash
-   function (denoted by H). Specific instantiations of HMAC need to
-   define a particular hash function. Current candidates for such hash
-   functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD].
-   These different realizations of HMAC will be denoted by HMAC-SHA1,
-   HMAC-MD5, HMAC-RIPEMD, etc.
-
-   Note: To the date of writing of this document MD5 and SHA-1 are the
-   most widely used cryptographic hash functions. MD5 has been recently
-   shown to be vulnerable to collision search attacks [Dobb].  This
-   attack and other currently known weaknesses of MD5 do not compromise
-   the use of MD5 within HMAC as specified in this document (see
-   [Dobb]); however, SHA-1 appears to be a cryptographically stronger
-   function. To this date, MD5 can be considered for use in HMAC for
-   applications where the superior performance of MD5 is critical.   In
-   any case, implementers and users need to be aware of possible
-   cryptanalytic developments regarding any of these cryptographic hash
-   functions, and the eventual need to replace the underlying hash
-   function. (See section 6 for more information on the security of
-   HMAC.)
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 2]
-
-RFC 2104                          HMAC                     February 1997
-
-
-2. Definition of HMAC
-
-   The definition of HMAC requires a cryptographic hash function, which
-   we denote by H, and a secret key K. We assume H to be a cryptographic
-   hash function where data is hashed by iterating a basic compression
-   function on blocks of data.   We denote by B the byte-length of such
-   blocks (B=64 for all the above mentioned examples of hash functions),
-   and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
-   SHA-1).  The authentication key K can be of any length up to B, the
-   block length of the hash function.  Applications that use keys longer
-   than B bytes will first hash the key using H and then use the
-   resultant L byte string as the actual key to HMAC. In any case the
-   minimal recommended length for K is L bytes (as the hash output
-   length). See section 3 for more information on keys.
-
-   We define two fixed and different strings ipad and opad as follows
-   (the 'i' and 'o' are mnemonics for inner and outer):
-
-                   ipad = the byte 0x36 repeated B times
-                  opad = the byte 0x5C repeated B times.
-
-   To compute HMAC over the data `text' we perform
-
-                    H(K XOR opad, H(K XOR ipad, text))
-
-   Namely,
-
-    (1) append zeros to the end of K to create a B byte string
-        (e.g., if K is of length 20 bytes and B=64, then K will be
-         appended with 44 zero bytes 0x00)
-    (2) XOR (bitwise exclusive-OR) the B byte string computed in step
-        (1) with ipad
-    (3) append the stream of data 'text' to the B byte string resulting
-        from step (2)
-    (4) apply H to the stream generated in step (3)
-    (5) XOR (bitwise exclusive-OR) the B byte string computed in
-        step (1) with opad
-    (6) append the H result from step (4) to the B byte string
-        resulting from step (5)
-    (7) apply H to the stream generated in step (6) and output
-        the result
-
-   For illustration purposes, sample code based on MD5 is provided as an
-   appendix.
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 3]
-
-RFC 2104                          HMAC                     February 1997
-
-
-3. Keys
-
-   The key for HMAC can be of any length (keys longer than B bytes are
-   first hashed using H).  However, less than L bytes is strongly
-   discouraged as it would decrease the security strength of the
-   function.  Keys longer than L bytes are acceptable but the extra
-   length would not significantly increase the function strength. (A
-   longer key may be advisable if the randomness of the key is
-   considered weak.)
-
-   Keys need to be chosen at random (or using a cryptographically strong
-   pseudo-random generator seeded with a random seed), and periodically
-   refreshed.  (Current attacks do not indicate a specific recommended
-   frequency for key changes as these attacks are practically
-   infeasible.  However, periodic key refreshment is a fundamental
-   security practice that helps against potential weaknesses of the
-   function and keys, and limits the damage of an exposed key.)
-
-4. Implementation Note
-
-   HMAC is defined in such a way that the underlying hash function H can
-   be used with no modification to its code. In particular, it uses the
-   function H with the pre-defined initial value IV (a fixed value
-   specified by each iterative hash function to initialize its
-   compression function).  However, if desired, a performance
-   improvement can be achieved at the cost of (possibly) modifying the
-   code of H to support variable IVs.
-
-   The idea is that the intermediate results of the compression function
-   on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed
-   only once at the time of generation of the key K, or before its first
-   use. These intermediate results are stored and then used to
-   initialize the IV of H each time that a message needs to be
-   authenticated.  This method saves, for each authenticated message,
-   the application of the compression function of H on two B-byte blocks
-   (i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be
-   significant when authenticating short streams of data.  We stress
-   that the stored intermediate values need to be treated and protected
-   the same as secret keys.
-
-   Choosing to implement HMAC in the above way is a decision of the
-   local implementation and has no effect on inter-operability.
-
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 4]
-
-RFC 2104                          HMAC                     February 1997
-
-
-5. Truncated output
-
-   A well-known practice with message authentication codes is to
-   truncate the output of the MAC and output only part of the bits
-   (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
-   analytical advantages of truncating the output of hash-based MAC
-   functions. The results in this area are not absolute as for the
-   overall security advantages of truncation. It has advantages (less
-   information on the hash result available to an attacker) and
-   disadvantages (less bits to predict for the attacker).  Applications
-   of HMAC can choose to truncate the output of HMAC by outputting the t
-   leftmost bits of the HMAC computation for some parameter t (namely,
-   the computation is carried in the normal way as defined in section 2
-   above but the end result is truncated to t bits). We recommend that
-   the output length t be not less than half the length of the hash
-   output (to match the birthday attack bound) and not less than 80 bits
-   (a suitable lower bound on the number of bits that need to be
-   predicted by an attacker).  We propose denoting a realization of HMAC
-   that uses a hash function H with t bits of output as HMAC-H-t. For
-   example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
-   and with the output truncated to 80 bits.  (If the parameter t is not
-   specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
-   hash are output.)
-
-6. Security
-
-   The security of the message authentication mechanism presented here
-   depends on cryptographic properties of the hash function H: the
-   resistance to collision finding (limited to the case where the
-   initial value is secret and random, and where the output of the
-   function is not explicitly available to the attacker), and the
-   message authentication property of the compression function of H when
-   applied to single blocks (in HMAC these blocks are partially unknown
-   to an attacker as they contain the result of the inner H computation
-   and, in particular, cannot be fully chosen by the attacker).
-
-   These properties, and actually stronger ones, are commonly assumed
-   for hash functions of the kind used with HMAC. In particular, a hash
-   function for which the above properties do not hold would become
-   unsuitable for most (probably, all) cryptographic applications,
-   including alternative message authentication schemes based on such
-   functions.  (For a complete analysis and rationale of the HMAC
-   function the reader is referred to [BCK1].)
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 5]
-
-RFC 2104                          HMAC                     February 1997
-
-
-   Given the limited confidence gained so far as for the cryptographic
-   strength of candidate hash functions, it is important to observe the
-   following two properties of the HMAC construction and its secure use
-   for message authentication:
-
-   1. The construction is independent of the details of the particular
-   hash function H in use and then the latter can be replaced by any
-   other secure (iterative) cryptographic hash function.
-
-   2. Message authentication, as opposed to encryption, has a
-   "transient" effect. A published breaking of a message authentication
-   scheme would lead to the replacement of that scheme, but would have
-   no adversarial effect on information authenticated in the past.  This
-   is in sharp contrast with encryption, where information encrypted
-   today may suffer from exposure in the future if, and when, the
-   encryption algorithm is broken.
-
-   The strongest attack known against HMAC is based on the frequency of
-   collisions for the hash function H ("birthday attack") [PV,BCK2], and
-   is totally impractical for minimally reasonable hash functions.
-
-   As an example, if we consider a hash function like MD5 where the
-   output length equals L=16 bytes (128 bits) the attacker needs to
-   acquire the correct message authentication tags computed (with the
-   _same_ secret key K!) on about 2**64 known plaintexts.  This would
-   require the processing of at least 2**64 blocks under H, an
-   impossible task in any realistic scenario (for a block length of 64
-   bytes this would take 250,000 years in a continuous 1Gbps link, and
-   without changing the secret key K during all this time).  This attack
-   could become realistic only if serious flaws in the collision
-   behavior of the function H are discovered (e.g.  collisions found
-   after 2**30 messages). Such a discovery would determine the immediate
-   replacement of the function H (the effects of such failure would be
-   far more severe for the traditional uses of H in the context of
-   digital signatures, public key certificates, etc.).
-
-   Note: this attack needs to be strongly contrasted with regular
-   collision attacks on cryptographic hash functions where no secret key
-   is involved and where 2**64 off-line parallelizable (!) operations
-   suffice to find collisions.  The latter attack is approaching
-   feasibility [VW] while the birthday attack on HMAC is totally
-   impractical.  (In the above examples, if one uses a hash function
-   with, say, 160 bit of output then 2**64 should be replaced by 2**80.)
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 6]
-
-RFC 2104                          HMAC                     February 1997
-
-
-   A correct implementation of the above construction, the choice of
-   random (or cryptographically pseudorandom) keys, a secure key
-   exchange mechanism, frequent key refreshments, and good secrecy
-   protection of keys are all essential ingredients for the security of
-   the integrity verification mechanism provided by HMAC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 7]
-
-RFC 2104                          HMAC                     February 1997
-
-
-Appendix -- Sample Code
-
-   For the sake of illustration we provide the following sample code for
-   the implementation of HMAC-MD5 as well as some corresponding test
-   vectors (the code is based on MD5 code as described in [MD5]).
-
-/*
-** Function: hmac_md5
-*/
-
-void
-hmac_md5(text, text_len, key, key_len, digest)
-unsigned char*  text;                /* pointer to data stream */
-int             text_len;            /* length of data stream */
-unsigned char*  key;                 /* pointer to authentication key */
-int             key_len;             /* length of authentication key */
-caddr_t         digest;              /* caller digest to be filled in */
-
-{
-        MD5_CTX context;
-        unsigned char k_ipad[65];    /* inner padding -
-                                      * key XORd with ipad
-                                      */
-        unsigned char k_opad[65];    /* outer padding -
-                                      * key XORd with opad
-                                      */
-        unsigned char tk[16];
-        int i;
-        /* if key is longer than 64 bytes reset it to key=MD5(key) */
-        if (key_len > 64) {
-
-                MD5_CTX      tctx;
-
-                MD5Init(&tctx);
-                MD5Update(&tctx, key, key_len);
-                MD5Final(tk, &tctx);
-
-                key = tk;
-                key_len = 16;
-        }
-
-        /*
-         * the HMAC_MD5 transform looks like:
-         *
-         * MD5(K XOR opad, MD5(K XOR ipad, text))
-         *
-         * where K is an n byte key
-         * ipad is the byte 0x36 repeated 64 times
-
-
-
-Krawczyk, et. al.            Informational                      [Page 8]
-
-RFC 2104                          HMAC                     February 1997
-
-
-         * opad is the byte 0x5c repeated 64 times
-         * and text is the data being protected
-         */
-
-        /* start out by storing key in pads */
-        bzero( k_ipad, sizeof k_ipad);
-        bzero( k_opad, sizeof k_opad);
-        bcopy( key, k_ipad, key_len);
-        bcopy( key, k_opad, key_len);
-
-        /* XOR key with ipad and opad values */
-        for (i=0; i<64; i++) {
-                k_ipad[i] ^= 0x36;
-                k_opad[i] ^= 0x5c;
-        }
-        /*
-         * perform inner MD5
-         */
-        MD5Init(&context);                   /* init context for 1st
-                                              * pass */
-        MD5Update(&context, k_ipad, 64)      /* start with inner pad */
-        MD5Update(&context, text, text_len); /* then text of datagram */
-        MD5Final(digest, &context);          /* finish up 1st pass */
-        /*
-         * perform outer MD5
-         */
-        MD5Init(&context);                   /* init context for 2nd
-                                              * pass */
-        MD5Update(&context, k_opad, 64);     /* start with outer pad */
-        MD5Update(&context, digest, 16);     /* then results of 1st
-                                              * hash */
-        MD5Final(digest, &context);          /* finish up 2nd pass */
-}
-
-Test Vectors (Trailing '\0' of a character string not included in test):
-
-  key =         0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
-  key_len =     16 bytes
-  data =        "Hi There"
-  data_len =    8  bytes
-  digest =      0x9294727a3638bb1c13f48ef8158bfc9d
-
-  key =         "Jefe"
-  data =        "what do ya want for nothing?"
-  data_len =    28 bytes
-  digest =      0x750c783e6ab0b503eaa86e310a5db738
-
-  key =         0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
-
-
-
-Krawczyk, et. al.            Informational                      [Page 9]
-
-RFC 2104                          HMAC                     February 1997
-
-
-  key_len       16 bytes
-  data =        0xDDDDDDDDDDDDDDDDDDDD...
-                ..DDDDDDDDDDDDDDDDDDDD...
-                ..DDDDDDDDDDDDDDDDDDDD...
-                ..DDDDDDDDDDDDDDDDDDDD...
-                ..DDDDDDDDDDDDDDDDDDDD
-  data_len =    50 bytes
-  digest =      0x56be34521d144c88dbb8c733f0e8b3f6
-
-Acknowledgments
-
-   Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided
-   useful comments on early drafts, and ran the first interoperability
-   tests of this specification. Jeff and Pau-Chen kindly provided the
-   sample code and test vectors that appear in the appendix.  Burt
-   Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van
-   Oorschot have provided useful comments and suggestions during the
-   investigation of the HMAC construction.
-
-References
-
-   [ANSI]  ANSI X9.9, "American National Standard for Financial
-           Institution Message Authentication (Wholesale)," American
-           Bankers Association, 1981.   Revised 1986.
-
-   [Atk]   Atkinson, R., "IP Authentication Header", RFC 1826, August
-           1995.
-
-   [BCK1]  M. Bellare, R. Canetti, and H. Krawczyk,
-           "Keyed Hash Functions and Message Authentication",
-           Proceedings of Crypto'96, LNCS 1109, pp. 1-15.
-           (http://www.research.ibm.com/security/keyed-md5.html)
-
-   [BCK2]  M. Bellare, R. Canetti, and H. Krawczyk,
-           "Pseudorandom Functions Revisited: The Cascade Construction",
-           Proceedings of FOCS'96.
-
-   [Dobb]  H. Dobbertin, "The Status of MD5  After a Recent Attack",
-           RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
-           http://www.rsa.com/rsalabs/pubs/cryptobytes.html
-
-   [PV]    B. Preneel and P. van Oorschot, "Building fast MACs from hash
-           functions", Advances in Cryptology -- CRYPTO'95 Proceedings,
-           Lecture Notes in Computer Science, Springer-Verlag Vol.963,
-           1995, pp. 1-14.
-
-   [MD5]   Rivest, R., "The MD5 Message-Digest Algorithm",
-           RFC 1321, April 1992.
-
-
-
-Krawczyk, et. al.            Informational                     [Page 10]
-
-RFC 2104                          HMAC                     February 1997
-
-
-   [MM]    Meyer, S. and Matyas, S.M., Cryptography, New York Wiley,
-           1982.
-
-   [RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A
-            strengthened version of RIPEMD", Fast Software Encryption,
-            LNCS Vol 1039, pp. 71-82.
-            ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.
-
-   [SHA]   NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
-
-   [Tsu]   G. Tsudik, "Message authentication with one-way hash
-           functions", In Proceedings of Infocom'92, May 1992.
-           (Also in "Access Control and Policy Enforcement in
-            Internetworks", Ph.D. Dissertation, Computer Science
-            Department, University of Southern California, April 1991.)
-
-   [VW]    P. van Oorschot and M. Wiener, "Parallel Collision
-           Search with Applications to Hash Functions and Discrete
-           Logarithms", Proceedings of the 2nd ACM Conf. Computer and
-           Communications Security, Fairfax, VA, November 1994.
-
-Authors' Addresses
-
-   Hugo Krawczyk
-   IBM T.J. Watson Research Center
-   P.O.Box 704
-   Yorktown Heights, NY 10598
-
-   EMail: hugo@watson.ibm.com
-
-   Mihir Bellare
-   Dept of Computer Science and Engineering
-   Mail Code 0114
-   University of California at San Diego
-   9500 Gilman Drive
-   La Jolla, CA 92093
-
-   EMail: mihir@cs.ucsd.edu
-
-   Ran Canetti
-   IBM T.J. Watson Research Center
-   P.O.Box 704
-   Yorktown Heights, NY 10598
-
-   EMail: canetti@watson.ibm.com
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                     [Page 11]
-
-
diff --git a/doc/rfc/rfc2119.txt b/doc/rfc/rfc2119.txt
deleted file mode 100644
index e31fae47..00000000
--- a/doc/rfc/rfc2119.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         S. Bradner
-Request for Comments: 2119                            Harvard University
-BCP: 14                                                       March 1997
-Category: Best Current Practice
-
-
-        Key words for use in RFCs to Indicate Requirement Levels
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Abstract
-
-   In many standards track documents several words are used to signify
-   the requirements in the specification.  These words are often
-   capitalized.  This document defines these words as they should be
-   interpreted in IETF documents.  Authors who follow these guidelines
-   should incorporate this phrase near the beginning of their document:
-
-      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
-      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
-      "OPTIONAL" in this document are to be interpreted as described in
-      RFC 2119.
-
-   Note that the force of these words is modified by the requirement
-   level of the document in which they are used.
-
-1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
-   definition is an absolute requirement of the specification.
-
-2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
-   definition is an absolute prohibition of the specification.
-
-3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
-   may exist valid reasons in particular circumstances to ignore a
-   particular item, but the full implications must be understood and
-   carefully weighed before choosing a different course.
-
-4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
-   there may exist valid reasons in particular circumstances when the
-   particular behavior is acceptable or even useful, but the full
-   implications should be understood and the case carefully weighed
-   before implementing any behavior described with this label.
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 1]
-
-RFC 2119                     RFC Key Words                    March 1997
-
-
-5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
-   truly optional.  One vendor may choose to include the item because a
-   particular marketplace requires it or because the vendor feels that
-   it enhances the product while another vendor may omit the same item.
-   An implementation which does not include a particular option MUST be
-   prepared to interoperate with another implementation which does
-   include the option, though perhaps with reduced functionality. In the
-   same vein an implementation which does include a particular option
-   MUST be prepared to interoperate with another implementation which
-   does not include the option (except, of course, for the feature the
-   option provides.)
-
-6. Guidance in the use of these Imperatives
-
-   Imperatives of the type defined in this memo must be used with care
-   and sparingly.  In particular, they MUST only be used where it is
-   actually required for interoperation or to limit behavior which has
-   potential for causing harm (e.g., limiting retransmisssions)  For
-   example, they must not be used to try to impose a particular method
-   on implementors where the method is not required for
-   interoperability.
-
-7. Security Considerations
-
-   These terms are frequently used to specify behavior with security
-   implications.  The effects on security of not implementing a MUST or
-   SHOULD, or doing something the specification says MUST NOT or SHOULD
-   NOT be done may be very subtle. Document authors should take the time
-   to elaborate the security implications of not following
-   recommendations or requirements as most implementors will not have
-   had the benefit of the experience and discussion that produced the
-   specification.
-
-8. Acknowledgments
-
-   The definitions of these terms are an amalgam of definitions taken
-   from a number of RFCs.  In addition, suggestions have been
-   incorporated from a number of people including Robert Ullmann, Thomas
-   Narten, Neal McBurnett, and Robert Elz.
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 2]
-
-RFC 2119                     RFC Key Words                    March 1997
-
-
-9. Author's Address
-
-      Scott Bradner
-      Harvard University
-      1350 Mass. Ave.
-      Cambridge, MA 02138
-
-      phone - +1 617 495 3864
-
-      email - sob@harvard.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 3]
-
diff --git a/doc/rfc/rfc2133.txt b/doc/rfc/rfc2133.txt
deleted file mode 100644
index ea66cf01..00000000
--- a/doc/rfc/rfc2133.txt
+++ /dev/null
@@ -1,1795 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Gilligan
-Request for Comments: 2133                                      Freegate
-Category: Informational                                       S. Thomson
-                                                                Bellcore
-                                                                J. Bound
-                                                                 Digital
-                                                              W. Stevens
-                                                              Consultant
-                                                              April 1997
-
-               Basic Socket Interface Extensions for IPv6
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   The de facto standard application program interface (API) for TCP/IP
-   applications is the "sockets" interface.  Although this API was
-   developed for Unix in the early 1980s it has also been implemented on
-   a wide variety of non-Unix systems.  TCP/IP applications written
-   using the sockets API have in the past enjoyed a high degree of
-   portability and we would like the same portability with IPv6
-   applications.  But changes are required to the sockets API to support
-   IPv6 and this memo describes these changes.  These include a new
-   socket address structure to carry IPv6 addresses, new address
-   conversion functions, and some new socket options.  These extensions
-   are designed to provide access to the basic IPv6 features required by
-   TCP and UDP applications, including multicasting, while introducing a
-   minimum of change into the system and providing complete
-   compatibility for existing IPv4 applications.  Additional extensions
-   for advanced IPv6 features (raw sockets and access to the IPv6
-   extension headers) are defined in another document [5].
-
-Table of Contents
-
-   1.  Introduction ................................................  2
-   2.  Design Considerations .......................................  3
-   2.1.  What Needs to be Changed ..................................  3
-   2.2.  Data Types ................................................  5
-   2.3.  Headers ...................................................  5
-   2.4.  Structures ................................................  5
-   3.  Socket Interface ............................................  5
-   3.1.  IPv6 Address Family and Protocol Family ...................  5
-   3.2.  IPv6 Address Structure ....................................  6
-
-
-
-Gilligan, et. al.            Informational                      [Page 1]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   3.3.  Socket Address Structure for 4.3BSD-Based Systems .........  6
-   3.4.  Socket Address Structure for 4.4BSD-Based Systems .........  7
-   3.5.  The Socket Functions ......................................  8
-   3.6.  Compatibility with IPv4 Applications ......................  9
-   3.7.  Compatibility with IPv4 Nodes .............................  9
-   3.8.  IPv6 Wildcard Address ..................................... 10
-   3.9.  IPv6 Loopback Address ..................................... 11
-   4.  Interface Identification .................................... 12
-   4.1.  Name-to-Index ............................................. 13
-   4.2.  Index-to-Name ............................................. 13
-   4.3.  Return All Interface Names and Indexes .................... 14
-   4.4.  Free Memory ............................................... 14
-   5.  Socket Options .............................................. 14
-   5.1.  Changing Socket Type ...................................... 15
-   5.2.  Unicast Hop Limit ......................................... 16
-   5.3.  Sending and Receiving Multicast Packets ................... 17
-   6.  Library Functions ........................................... 19
-   6.1.  Hostname-to-Address Translation ........................... 19
-   6.2.  Address To Hostname Translation ........................... 22
-   6.3.  Protocol-Independent Hostname and Service Name Translation  22
-   6.4.  Socket Address Structure to Hostname and Service Name ..... 25
-   6.5.  Address Conversion Functions .............................. 27
-   6.6.  Address Testing Macros .................................... 28
-   7.  Summary of New Definitions .................................. 29
-   8.  Security Considerations ..................................... 31
-   9.  Acknowledgments ............................................. 31
-   10.  References ................................................. 31
-   11.  Authors' Addresses ......................................... 32
-
-1.  Introduction
-
-   While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
-   by 128-bit addresses.  The socket interface make the size of an IP
-   address quite visible to an application; virtually all TCP/IP
-   applications for BSD-based systems have knowledge of the size of an
-   IP address.  Those parts of the API that expose the addresses must be
-   changed to accommodate the larger IPv6 address size.  IPv6 also
-   introduces new features (e.g., flow label and priority), some of
-   which must be made visible to applications via the API.  This memo
-   defines a set of extensions to the socket interface to support the
-   larger address size and new features of IPv6.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 2]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-2.  Design Considerations
-
-   There are a number of important considerations in designing changes
-   to this well-worn API:
-
-   -  The API changes should provide both source and binary
-       compatibility for programs written to the original API.  That is,
-       existing program binaries should continue to operate when run on
-       a system supporting the new API.  In addition, existing
-       applications that are re-compiled and run on a system supporting
-       the new API should continue to operate.  Simply put, the API
-       changes for IPv6 should not break existing programs.
-
-   -  The changes to the API should be as small as possible in order to
-       simplify the task of converting existing IPv4 applications to
-       IPv6.
-
-   -  Where possible, applications should be able to use this API to
-       interoperate with both IPv6 and IPv4 hosts.  Applications should
-       not need to know which type of host they are communicating with.
-
-   -  IPv6 addresses carried in data structures should be 64-bit
-       aligned.  This is necessary in order to obtain optimum
-       performance on 64-bit machine architectures.
-
-   Because of the importance of providing IPv4 compatibility in the API,
-   these extensions are explicitly designed to operate on machines that
-   provide complete support for both IPv4 and IPv6.  A subset of this
-   API could probably be designed for operation on systems that support
-   only IPv6.  However, this is not addressed in this memo.
-
-2.1.  What Needs to be Changed
-
-   The socket interface API consists of a few distinct components:
-
-    -  Core socket functions.
-
-    -  Address data structures.
-
-    -  Name-to-address translation functions.
-
-    -  Address conversion functions.
-
-    The core socket functions -- those functions that deal with such
-    things as setting up and tearing down TCP connections, and sending
-    and receiving UDP packets -- were designed to be transport
-    independent.  Where protocol addresses are passed as function
-    arguments, they are carried via opaque pointers.  A protocol-specific
-
-
-
-Gilligan, et. al.            Informational                      [Page 3]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-    address data structure is defined for each protocol that the socket
-    functions support.  Applications must cast pointers to these
-    protocol-specific address structures into pointers to the generic
-    "sockaddr" address structure when using the socket functions.  These
-    functions need not change for IPv6, but a new IPv6-specific address
-    data structure is needed.
-
-    The "sockaddr_in" structure is the protocol-specific data structure
-    for IPv4.  This data structure actually includes 8-octets of unused
-    space, and it is tempting to try to use this space to adapt the
-    sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
-    structure is not large enough to hold the 16-octet IPv6 address as
-    well as the other information (address family and port number) that
-    is needed.  So a new address data structure must be defined for IPv6.
-
-    The name-to-address translation functions in the socket interface are
-    gethostbyname() and gethostbyaddr().  These must be modified to
-    support IPv6 and the semantics defined must provide 100% backward
-    compatibility for all existing IPv4 applications, along with IPv6
-    support for new applications.  Additionally, the POSIX 1003.g work in
-    progress [4] specifies a new hostname-to-address translation function
-    which is protocol independent.  This function can also be used with
-    IPv6.
-
-    The address conversion functions -- inet_ntoa() and inet_addr() --
-    convert IPv4 addresses between binary and printable form.  These
-    functions are quite specific to 32-bit IPv4 addresses.  We have
-    designed two analogous functions that convert both IPv4 and IPv6
-    addresses, and carry an address type parameter so that they can be
-    extended to other protocol families as well.
-
-    Finally, a few miscellaneous features are needed to support IPv6.
-    New interfaces are needed to support the IPv6 flow label, priority,
-    and hop limit header fields.  New socket options are needed to
-    control the sending and receiving of IPv6 multicast packets.
-
-    The socket interface will be enhanced in the future to provide access
-    to other IPv6 features.  These extensions are described in [5].
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 4]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-2.2.  Data Types
-
-   The data types of the structure elements given in this memo are
-   intended to be examples, not absolute requirements.  Whenever
-   possible, POSIX 1003.1g data types are used:  u_intN_t means an
-   unsigned integer of exactly N bits (e.g., u_int16_t) and u_intNm_t
-   means an unsigned integer of at least N bits (e.g., u_int32m_t).  We
-   also assume the argument data types from 1003.1g when possible (e.g.,
-    the final argument to setsockopt() is a size_t value).  Whenever
-   buffer sizes are specified, the POSIX 1003.1 size_t data type is used
-   (e.g., the two length arguments to getnameinfo()).
-
-2.3.  Headers
-
-   When function prototypes and structures are shown we show the headers
-   that must be #included to cause that item to be defined.
-
-2.4.  Structures
-
-   When structures are described the members shown are the ones that
-   must appear in an implementation.  Additional, nonstandard members
-   may also be defined by an implementation.
-
-   The ordering shown for the members of a structure is the recommended
-   ordering, given alignment considerations of multibyte members, but an
-   implementation may order the members differently.
-
-3.  Socket Interface
-
-   This section specifies the socket interface changes for IPv6.
-
-3.1.  IPv6 Address Family and Protocol Family
-
-   A new address family name, AF_INET6, is defined in <sys/socket.h>.
-   The AF_INET6 definition distinguishes between the original
-   sockaddr_in address data structure, and the new sockaddr_in6 data
-   structure.
-
-   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
-   Like most of the other protocol family names, this will usually be
-   defined to have the same value as the corresponding address family
-   name:
-
-       #define PF_INET6        AF_INET6
-
-   The PF_INET6 is used in the first argument to the socket() function
-   to indicate that an IPv6 socket is being created.
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 5]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-3.2.  IPv6 Address Structure
-
-   A new data structure to hold a single IPv6 address is defined as
-    follows:
-
-       #include <netinet/in.h>
-
-       struct in6_addr {
-           u_int8_t  s6_addr[16];      /* IPv6 address */
-       }
-
-   This data structure contains an array of sixteen 8-bit elements,
-   which make up one 128-bit IPv6 address.  The IPv6 address is stored
-   in network byte order.
-
-3.3.  Socket Address Structure for 4.3BSD-Based Systems
-
-   In the socket interface, a different protocol-specific data structure
-   is defined to carry the addresses for each protocol suite.  Each
-   protocol-specific data structure is designed so it can be cast into a
-   protocol-independent data structure -- the "sockaddr" structure.
-   Each has a "family" field that overlays the "sa_family" of the
-   sockaddr data structure.  This field identifies the type of the data
-   structure.
-
-   The sockaddr_in structure is the protocol-specific address data
-   structure for IPv4.  It is used to pass addresses between
-   applications and the system in the socket functions.  The following
-   structure is defined to carry IPv6 addresses:
-
-       #include <netinet/in.h>
-
-       struct sockaddr_in6 {
-           u_int16m_t      sin6_family;    /* AF_INET6 */
-           u_int16m_t      sin6_port;      /* transport layer port # */
-           u_int32m_t      sin6_flowinfo;  /* IPv6 flow information */
-           struct in6_addr sin6_addr;      /* IPv6 address */
-       };
-
-   This structure is designed to be compatible with the sockaddr data
-   structure used in the 4.3BSD release.
-
-   The sin6_family field identifies this as a sockaddr_in6 structure.
-   This field overlays the sa_family field when the buffer is cast to a
-   sockaddr data structure.  The value of this field must be AF_INET6.
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 6]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The sin6_port field contains the 16-bit UDP or TCP port number.  This
-   field is used in the same way as the sin_port field of the
-   sockaddr_in structure.  The port number is stored in network byte
-   order.
-
-   The sin6_flowinfo field is a 32-bit field that contains two pieces of
-   information: the 24-bit IPv6 flow label and the 4-bit priority field.
-   The contents and interpretation of this member is unspecified at this
-   time.
-
-   The sin6_addr field is a single in6_addr structure (defined in the
-   previous section).  This field holds one 128-bit IPv6 address.  The
-   address is stored in network byte order.
-
-   The ordering of elements in this structure is specifically designed
-   so that the sin6_addr field will be aligned on a 64-bit boundary.
-   This is done for optimum performance on 64-bit architectures.
-
-   Notice that the sockaddr_in6 structure will normally be larger than
-   the generic sockaddr structure.  On many existing implementations the
-   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
-   being 16 bytes.  Any existing code that makes this assumption needs
-   to be examined carefully when converting to IPv6.
-
-3.4.  Socket Address Structure for 4.4BSD-Based Systems
-
-   The 4.4BSD release includes a small, but incompatible change to the
-   socket interface.  The "sa_family" field of the sockaddr data
-   structure was changed from a 16-bit value to an 8-bit value, and the
-   space saved used to hold a length field, named "sa_len".  The
-   sockaddr_in6 data structure given in the previous section cannot be
-   correctly cast into the newer sockaddr data structure.  For this
-   reason, the following alternative IPv6 address data structure is
-   provided to be used on systems based on 4.4BSD:
-
-       #include <netinet/in.h>
-
-       #define SIN6_LEN
-
-       struct sockaddr_in6 {
-           u_char          sin6_len;       /* length of this struct */
-           u_char          sin6_family;    /* AF_INET6 */
-           u_int16m_t      sin6_port;      /* transport layer port # */
-           u_int32m_t      sin6_flowinfo;  /* IPv6 flow information */
-           struct in6_addr sin6_addr;      /* IPv6 address */
-       };
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 7]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The only differences between this data structure and the 4.3BSD
-   variant are the inclusion of the length field, and the change of the
-   family field to a 8-bit data type.  The definitions of all the other
-   fields are identical to the structure defined in the previous
-   section.
-
-   Systems that provide this version of the sockaddr_in6 data structure
-   must also declare SIN6_LEN as a result of including the
-   <netinet/in.h> header.  This macro allows applications to determine
-   whether they are being built on a system that supports the 4.3BSD or
-   4.4BSD variants of the data structure.
-
-3.5.  The Socket Functions
-
-   Applications call the socket() function to create a socket descriptor
-   that represents a communication endpoint.  The arguments to the
-   socket() function tell the system which protocol to use, and what
-   format address structure will be used in subsequent functions.  For
-   example, to create an IPv4/TCP socket, applications make the call:
-
-       s = socket(PF_INET, SOCK_STREAM, 0);
-
-   To create an IPv4/UDP socket, applications make the call:
-
-       s = socket(PF_INET, SOCK_DGRAM, 0);
-
-   Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
-   the constant PF_INET6 instead of PF_INET in the first argument.  For
-   example, to create an IPv6/TCP socket, applications make the call:
-
-       s = socket(PF_INET6, SOCK_STREAM, 0);
-
-   To create an IPv6/UDP socket, applications make the call:
-
-       s = socket(PF_INET6, SOCK_DGRAM, 0);
-
-   Once the application has created a PF_INET6 socket, it must use the
-   sockaddr_in6 address structure when passing addresses in to the
-   system.  The functions that the application uses to pass addresses
-   into the system are:
-
-       bind()
-       connect()
-       sendmsg()
-       sendto()
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 8]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The system will use the sockaddr_in6 address structure to return
-   addresses to applications that are using PF_INET6 sockets.  The
-   functions that return an address from the system to an application
-   are:
-
-          accept()
-          recvfrom()
-          recvmsg()
-          getpeername()
-          getsockname()
-
-   No changes to the syntax of the socket functions are needed to
-   support IPv6, since all of the "address carrying" functions use an
-   opaque address pointer, and carry an address length as a function
-   argument.
-
-3.6.  Compatibility with IPv4 Applications
-
-   In order to support the large base of applications using the original
-   API, system implementations must provide complete source and binary
-   compatibility with the original API.  This means that systems must
-   continue to support PF_INET sockets and the sockaddr_in address
-   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
-   sockets using the PF_INET constant in the socket() function, as
-   described in the previous section.  Applications should be able to
-   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
-   sockets simultaneously within the same process.
-
-   Applications using the original API should continue to operate as
-   they did on systems supporting only IPv4.  That is, they should
-   continue to interoperate with IPv4 nodes.
-
-3.7.  Compatibility with IPv4 Nodes
-
-   The API also provides a different type of compatibility: the ability
-   for IPv6 applications to interoperate with IPv4 applications.  This
-   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
-   addressing architecture specification [2].  This address format
-   allows the IPv4 address of an IPv4 node to be represented as an IPv6
-   address.  The IPv4 address is encoded into the low-order 32 bits of
-   the IPv6 address, and the high-order 96 bits hold the fixed prefix
-   0:0:0:0:0:FFFF.  IPv4-mapped addresses are written as follows:
-
-       ::FFFF:<IPv4-address>
-
-   These addresses are often generated automatically by the
-   gethostbyname() function when the specified host has only IPv4
-   addresses (as described in Section 6.1).
-
-
-
-Gilligan, et. al.            Informational                      [Page 9]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   Applications may use PF_INET6 sockets to open TCP connections to IPv4
-   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
-   destination's IPv4 address as an IPv4-mapped IPv6 address, and
-   passing that address, within a sockaddr_in6 structure, in the
-   connect() or sendto() call.  When applications use PF_INET6 sockets
-   to accept TCP connections from IPv4 nodes, or receive UDP packets
-   from IPv4 nodes, the system returns the peer's address to the
-   application in the accept(), recvfrom(), or getpeername() call using
-   a sockaddr_in6 structure encoded this way.
-
-   Few applications will likely need to know which type of node they are
-   interoperating with.  However, for those applications that do need to
-   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.6, is
-   provided.
-
-3.8.  IPv6 Wildcard Address
-
-   While the bind() function allows applications to select the source IP
-   address of UDP packets and TCP connections, applications often want
-   the system to select the source address for them.  With IPv4, one
-   specifies the address as the symbolic constant INADDR_ANY (called the
-   "wildcard" address) in the bind() call, or simply omits the bind()
-   entirely.
-
-   Since the IPv6 address type is a structure (struct in6_addr), a
-   symbolic constant can be used to initialize an IPv6 address variable,
-   but cannot be used in an assignment.  Therefore systems provide the
-   IPv6 wildcard address in two forms.
-
-   The first version is a global variable named "in6addr_any" that is an
-   in6_addr structure.  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-       extern const struct in6_addr in6addr_any;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 10]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   Applications use in6addr_any similarly to the way they use INADDR_ANY
-   in IPv4.  For example, to bind a socket to port number 23, but let
-   the system select the source address, an application could use the
-   following code:
-
-       struct sockaddr_in6 sin6;
-        . . .
-       sin6.sin6_family = AF_INET6;
-       sin6.sin6_flowinfo = 0;
-       sin6.sin6_port = htons(23);
-       sin6.sin6_addr = in6addr_any;  /* structure assignment */
-        . . .
-       if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-               . . .
-
-   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
-   is defined in <netinet/in.h>.  This constant can be used to
-   initialize an in6_addr structure:
-
-       struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
-   Note that this constant can be used ONLY at declaration time.  It can
-   not be used to assign a previously declared in6_addr structure.  For
-   example, the following code will not work:
-
-       /* This is the WRONG way to assign an unspecified address */
-       struct sockaddr_in6 sin6;
-        . . .
-       sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
-   Be aware that the IPv4 INADDR_xxx constants are all defined in host
-   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
-   in6addr_xxx externals are defined in network byte order.
-
-3.9.  IPv6 Loopback Address
-
-   Applications may need to send UDP packets to, or originate TCP
-   connections to, services residing on the local node.  In IPv4, they
-   can do this by using the constant IPv4 address INADDR_LOOPBACK in
-   their connect(), sendto(), or sendmsg() call.
-
-   IPv6 also provides a loopback address to contact local TCP and UDP
-   services.  Like the unspecified address, the IPv6 loopback address is
-   provided in two forms -- a global variable and a symbolic constant.
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 11]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The global variable is an in6_addr structure named
-   "in6addr_loopback."  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-       extern const struct in6_addr in6addr_loopback;
-
-   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
-   in IPv4 applications (but beware of the byte ordering difference
-   mentioned at the end of the previous section).  For example, to open
-   a TCP connection to the local telnet server, an application could use
-   the following code:
-
-       struct sockaddr_in6 sin6;
-        . . .
-       sin6.sin6_family = AF_INET6;
-       sin6.sin6_flowinfo = 0;
-       sin6.sin6_port = htons(23);
-       sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
-        . . .
-       if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-               . . .
-
-   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
-   in <netinet/in.h>.  It can be used at declaration time ONLY; for
-   example:
-
-       struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
-   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
-   to a previously declared IPv6 address variable.
-
-4.  Interface Identification
-
-   This API uses an interface index (a small positive integer) to
-   identify the local interface on which a multicast group is joined
-   (Section 5.3).  Additionally, the advanced API [5] uses these same
-   interface indexes to identify the interface on which a datagram is
-   received, or to specify the interface on which a datagram is to be
-   sent.
-
-   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
-   and the like.  On Berkeley-derived implementations, when an interface
-   is made known to the system, the kernel assigns a unique positive
-   integer value (called the interface index) to that interface.  These
-   are small positive integers that start at 1.  (Note that 0 is never
-   used for an interface index.)  There may be gaps so that there is no
-   current interface for a particular positive interface index.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 12]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   This API defines two functions that map between an interface name and
-   index, a third function that returns all the interface names and
-   indexes, and a fourth function to return the dynamic memory allocated
-   by the previous function.  How these functions are implemented is
-   left up to the implementation.  4.4BSD implementations can implement
-   these functions using the existing sysctl() function with the
-   NET_RT_LIST command.  Other implementations may wish to use ioctl()
-   for this purpose.
-
-4.1.  Name-to-Index
-
-   The first function maps an interface name into its corresponding
-   index.
-
-       #include <net/if.h>
-
-       unsigned int  if_nametoindex(const char *ifname);
-
-   If the specified interface does not exist, the return value is 0.
-
-4.2.  Index-to-Name
-
-   The second function maps an interface index into its corresponding
-   name.
-
-       #include <net/if.h>
-
-       char  *if_indextoname(unsigned int ifindex, char *ifname);
-
-   The ifname argument must point to a buffer of at least IFNAMSIZ bytes
-   into which the interface name corresponding to the specified index is
-   returned.  (IFNAMSIZ is also defined in <net/if.h> and its value
-   includes a terminating null byte at the end of the interface name.)
-   This pointer is also the return value of the function.  If there is
-   no interface corresponding to the specified index, NULL is returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 13]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-4.3.  Return All Interface Names and Indexes
-
-   The final function returns an array of if_nameindex structures, one
-   structure per interface.
-
-       #include <net/if.h>
-
-       struct if_nameindex {
-         unsigned int   if_index;  /* 1, 2, ... */
-         char          *if_name;   /* null terminated name: "le0", ... */
-       };
-
-       struct if_nameindex  *if_nameindex(void);
-
-   The end of the array of structures is indicated by a structure with
-   an if_index of 0 and an if_name of NULL.  The function returns a NULL
-   pointer upon an error.
-
-   The memory used for this array of structures along with the interface
-   names pointed to by the if_name members is obtained dynamically.
-   This memory is freed by the next function.
-
-4.4.  Free Memory
-
-   The following function frees the dynamic memory that was allocated by
-   if_nameindex().
-
-       #include <net/if.h>
-
-       void  if_freenameindex(struct if_nameindex *ptr);
-
-   The argument to this function must be a pointer that was returned by
-   if_nameindex().
-
-5.  Socket Options
-
-   A number of new socket options are defined for IPv6.  All of these
-   new options are at the IPPROTO_IPV6 level.  That is, the "level"
-   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
-   when using these options.  The constant name prefix IPV6_ is used in
-   all of the new socket options.  This serves to clearly identify these
-   options as applying to IPv6.
-
-   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
-   related constants defined in this section are obtained by including
-   the header <netinet/in.h>.
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 14]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-5.1.  Changing Socket Type
-
-   Unix allows open sockets to be passed between processes via the
-   exec() call and other means.  It is a relatively common application
-   practice to pass open sockets across exec() calls.  Thus it is
-   possible for an application using the original API to pass an open
-   PF_INET socket to an application that is expecting to receive a
-   PF_INET6 socket.  Similarly, it is possible for an application using
-   the extended API to pass an open PF_INET6 socket to an application
-   using the original API, which would be equipped only to deal with
-   PF_INET sockets.  Either of these cases could cause problems, because
-   the application that is passed the open socket might not know how to
-   decode the address structures returned in subsequent socket
-   functions.
-
-   To remedy this problem, a new setsockopt() option is defined that
-   allows an application to "convert" a PF_INET6 socket into a PF_INET
-   socket and vice versa.
-
-   An IPv6 application that is passed an open socket from an unknown
-   process may use the IPV6_ADDRFORM setsockopt() option to "convert"
-   the socket to PF_INET6.  Once that has been done, the system will
-   return sockaddr_in6 address structures in subsequent socket
-   functions.
-
-   An IPv6 application that is about to pass an open PF_INET6 socket to
-   a program that is not be IPv6 capable can "downgrade" the socket to
-   PF_INET before calling exec().  After that, the system will return
-   sockaddr_in address structures to the application that was exec()'ed.
-   Be aware that you cannot downgrade an IPv6 socket to an IPv4 socket
-   unless all nonwildcard addresses already associated with the IPv6
-   socket are IPv4-mapped IPv6 addresses.
-
-   The IPV6_ADDRFORM option is valid at both the IPPROTO_IP and
-   IPPROTO_IPV6 levels.  The only valid option values are PF_INET6 and
-   PF_INET.  For example, to convert a PF_INET6 socket to PF_INET, a
-   program would call:
-
-       int  addrform = PF_INET;
-
-       if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
-                      (char *) &addrform, sizeof(addrform)) == -1)
-           perror("setsockopt IPV6_ADDRFORM");
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 15]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   An application may use IPV6_ADDRFORM with getsockopt() to learn
-   whether an open socket is a PF_INET of PF_INET6 socket.  For example:
-
-       int  addrform;
-       size_t  len = sizeof(addrform);
-
-       if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
-                      (char *) &addrform, &len) == -1)
-           perror("getsockopt IPV6_ADDRFORM");
-       else if (addrform == PF_INET)
-           printf("This is an IPv4 socket.\n");
-       else if (addrform == PF_INET6)
-           printf("This is an IPv6 socket.\n");
-       else
-           printf("This system is broken.\n");
-
-5.2.  Unicast Hop Limit
-
-   A new setsockopt() option controls the hop limit used in outgoing
-   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
-   and it is used at the IPPROTO_IPV6 layer.  The following example
-   illustrates how it is used:
-
-       int  hoplimit = 10;
-
-       if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                      (char *) &hoplimit, sizeof(hoplimit)) == -1)
-           perror("setsockopt IPV6_UNICAST_HOPS");
-
-   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
-   option value given is used as the hop limit for all subsequent
-   unicast packets sent via that socket.  If the option is not set, the
-   system selects a default value.  The integer hop limit value (called
-   x) is interpreted as follows:
-
-       x < -1:        return an error of EINVAL
-       x == -1:       use kernel default
-       0 <= x <= 255: use x
-       x >= 256:      return an error of EINVAL
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 16]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
-   determine the hop limit value that the system will use for subsequent
-   unicast packets sent via that socket.  For example:
-
-       int  hoplimit;
-       size_t  len = sizeof(hoplimit);
-
-       if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                      (char *) &hoplimit, &len) == -1)
-           perror("getsockopt IPV6_UNICAST_HOPS");
-       else
-           printf("Using %d for hop limit.\n", hoplimit);
-
-5.3.  Sending and Receiving Multicast Packets
-
-   IPv6 applications may send UDP multicast packets by simply specifying
-   an IPv6 multicast address in the address argument of the sendto()
-   function.
-
-   Three socket options at the IPPROTO_IPV6 layer control some of the
-   parameters for sending multicast packets.  Setting these options is
-   not required:  applications may send multicast packets without using
-   these options.  The setsockopt() options for controlling the sending
-   of multicast packets are summarized below:
-
-       IPV6_MULTICAST_IF
-
-           Set the interface to use for outgoing multicast packets.  The
-           argument is the index of the interface to use.
-
-           Argument type: unsigned int
-
-       IPV6_MULTICAST_HOPS
-
-           Set the hop limit to use for outgoing multicast packets.
-           (Note a separate option - IPV6_UNICAST_HOPS - is provided to
-           set the hop limit to use for outgoing unicast packets.)  The
-           interpretation of the argument is the same as for the
-           IPV6_UNICAST_HOPS option:
-
-               x < -1:        return an error of EINVAL
-               x == -1:       use kernel default
-               0 <= x <= 255: use x
-               x >= 256:      return an error of EINVAL
-
-           Argument type: int
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 17]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-       IPV6_MULTICAST_LOOP
-
-           Controls whether outgoing multicast packets  sent  should  be
-           delivered  back  to the local application.  A toggle.  If the
-           option is set to 1, multicast packets are looped back.  If it
-           is set to 0, they are not.
-
-           Argument type: unsigned int
-
-   The reception of multicast packets is controlled by the two
-   setsockopt() options summarized below:
-
-       IPV6_ADD_MEMBERSHIP
-
-           Join a multicast group on a specified local interface.  If
-           the interface index is specified as 0, the kernel chooses the
-           local interface.  For example, some kernels look up the
-           multicast group in the normal IPv6 routing table and using
-           the resulting interface.
-
-           Argument type: struct ipv6_mreq
-
-       IPV6_DROP_MEMBERSHIP
-
-           Leave a multicast group on a specified interface.
-
-           Argument type: struct ipv6_mreq
-
-   The argument type of both of these options is the ipv6_mreq
-   structure, defined as:
-
-       #include <netinet/in.h>
-
-       struct ipv6_mreq {
-           struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
-           unsigned int    ipv6mr_interface; /* interface index */
-       };
-
-   Note that to receive multicast datagrams a process must join the
-   multicast group and bind the UDP port to which datagrams will be
-   sent.  Some processes also bind the multicast group address to the
-   socket, in addition to the port, to prevent other datagrams destined
-   to that same port from being delivered to the socket.
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 18]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-6.  Library Functions
-
-   New library functions are needed to perform a variety of operations
-   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
-   in the Domain Name System (DNS).  Both forward lookup (hostname-to-
-   address translation) and reverse lookup (address-to-hostname
-   translation) need to be supported.  Functions are also needed to
-   convert IPv6 addresses between their binary and textual form.
-
-6.1.  Hostname-to-Address Translation
-
-   The commonly used function gethostbyname() remains unchanged as does
-   the hostent structure to which it returns a pointer.  Existing
-   applications that call this function continue to receive only IPv4
-   addresses that are the result of a query in the DNS for A records.
-   (We assume the DNS is being used; some environments may be using a
-   hosts file or some other name resolution system, either of which may
-   impede renumbering.  We also assume that the RES_USE_INET6 resolver
-   option is not set, which we describe in more detail shortly.)
-
-   Two new changes are made to support IPv6 addresses.  First, the
-   following function is new:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       struct hostent *gethostbyname2(const char *name, int af);
-
-   The af argument specifies the address family.  The default operation
-   of this function is simple:
-
-    -  If the af argument is AF_INET, then a query is made for A
-       records.  If successful, IPv4 addresses are returned and the
-       h_length member of the hostent structure will be 4, else the
-       function returns a NULL pointer.
-
-    -  If the af argument is AF_INET6, then a query is made for AAAA
-       records.  If successful, IPv6 addresses are returned and the
-       h_length member of the hostent structure will be 16, else the
-       function returns a NULL pointer.
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 19]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The second change, that provides additional functionality, is a new
-   resolver option RES_USE_INET6, which is defined as a result of
-   including the <resolv.h> header.  (This option is provided starting
-   with the BIND 4.9.4 release.)  There are three ways to set this
-   option.
-
-    -  The first way is
-
-           res_init();
-           _res.options |= RES_USE_INET6;
-
-       and then call either gethostbyname() or gethostbyname2().  This
-       option then affects only the process that is calling the
-       resolver.
-
-    -  The second way to set this option is to set the environment
-       variable RES_OPTIONS, as in RES_OPTIONS=inet6.  (This example is
-       for the Bourne and Korn shells.)  This method affects any
-       processes that see this environment variable.
-
-    -  The third way is to set this option in the resolver configuration
-       file (normally /etc/resolv.conf) and the option then affects all
-       applications on the host.  This final method should not be done
-       until all applications on the host are capable of dealing with
-       IPv6 addresses.
-
-   There is no priority among these three methods.  When the
-   RES_USE_INET6 option is set, two changes occur:
-
-    -  gethostbyname(host) first calls gethostbyname2(host, AF_INET6)
-       looking for AAAA records, and if this fails it then calls
-       gethostbyname2(host, AF_INET) looking for A records.
-
-    -  gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6
-       addresses with the h_length member of the hostent structure set
-       to 16.
-
-   An application must not enable the RES_USE_INET6 option until it is
-   prepared to deal with 16-byte addresses in the returned hostent
-   structure.
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 20]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The following table summarizes the operation of the existing
-   gethostbyname() function, the new function gethostbyname2(), along
-   with the new resolver option RES_USE_INET6.
-
-+------------------+---------------------------------------------------+
-|                  |              RES_USE_INET6 option                 |
-|                  +-------------------------+-------------------------+
-|                  |          off            |           on            |
-+------------------+-------------------------+-------------------------+
-|                  |Search for A records.    |Search for AAAA records. |
-| gethostbyname    | If found, return IPv4   | If found, return IPv6   |
-| (host)           | addresses (h_length=4). | addresses (h_length=16).|
-|                  | Else error.             | Else search for A       |
-|                  |                         | records.  If found,     |
-|                  |Provides backward        | return IPv4-mapped IPv6 |
-|                  | compatibility with all  | addresses (h_length=16).|
-|                  | existing IPv4 appls.    | Else error.             |
-+------------------+-------------------------+-------------------------+
-|                  |Search for A records.    |Search for A records.    |
-| gethostbyname2   | If found, return IPv4   | If found, return        |
-| (host, AF_INET)  | addresses (h_length=4). | IPv4-mapped IPv6        |
-|                  | Else error.             | addresses (h_length=16).|
-|                  |                         | Else error.             |
-+------------------+-------------------------+-------------------------+
-|                  |Search for AAAA records. |Search for AAAA records. |
-| gethostbyname2   | If found, return IPv6   | If found, return IPv6   |
-| (host, AF_INET6) | addresses (h_length=16).| addresses (h_length=16).|
-|                  | Else error.             | Else error.             |
-+------------------+-------------------------+-------------------------+
-
-   It is expected that when a typical naive application that calls
-   gethostbyname() today is modified to use IPv6, it simply changes the
-   program to use IPv6 sockets and then enables the RES_USE_INET6
-   resolver option before calling gethostbyname().  This application
-   will then work with either IPv4 or IPv6 peers.
-
-   Note that gethostbyname() and gethostbyname2() are not thread-safe,
-   since both return a pointer to a static hostent structure.  But
-   several vendors have defined a thread-safe gethostbyname_r() function
-   that requires four additional arguments.  We expect these vendors to
-   also define a gethostbyname2_r() function.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 21]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-6.2.  Address To Hostname Translation
-
-   The existing gethostbyaddr() function already requires an address
-   family argument and can therefore work with IPv6 addresses:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       struct hostent *gethostbyaddr(const char *src, int len, int af);
-
-   One possible source of confusion is the handling of IPv4-mapped IPv6
-   addresses and IPv4-compatible IPv6 addresses.  This is addressed in
-   [6] and involves the following logic:
-
-    1.  If af is AF_INET6, and if len equals 16, and if the IPv6 address
-        is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6
-        address, then skip over the first 12 bytes of the IPv6 address,
-        set af to AF_INET, and set len to 4.
-
-    2.  If af is AF_INET, then query for a PTR record in the in-
-        addr.arpa domain.
-
-    3.  If af is AF_INET6, then query for a PTR record in the ip6.int
-        domain.
-
-    4.  If the function is returning success, and if af equals AF_INET,
-        and if the RES_USE_INET6 option was set, then the single address
-        that is returned in the hostent structure (a copy of the first
-        argument to the function) is returned as an IPv4-mapped IPv6
-        address and the h_length member is set to 16.
-
-   All four steps listed are performed, in order.  The same caveats
-   regarding a thread-safe version of gethostbyname() that were made at
-   the end of the previous section apply here as well.
-
-6.3.  Protocol-Independent Hostname and Service Name Translation
-
-   Hostname-to-address translation is done in a protocol-independent
-   fashion using the getaddrinfo() function that is taken from the
-   Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
-   (Protocol Independent Interfaces) work in progress specification [4].
-
-   The official specification for this function will be the final POSIX
-   standard.  We are providing this independent description of the
-   function because POSIX standards are not freely available (as are
-   IETF documents).  Should there be any discrepancies between this
-   description and the POSIX description, the POSIX description takes
-   precedence.
-
-
-
-Gilligan, et. al.            Informational                     [Page 22]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       int getaddrinfo(const char *hostname, const char *servname,
-                       const struct addrinfo *hints,
-                       struct addrinfo **res);
-
-   The addrinfo structure is defined as:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       struct addrinfo {
-         int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME */
-         int     ai_family;    /* PF_xxx */
-         int     ai_socktype;  /* SOCK_xxx */
-         int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
-         size_t  ai_addrlen;   /* length of ai_addr */
-         char   *ai_canonname; /* canonical name for hostname */
-         struct sockaddr  *ai_addr; /* binary address */
-         struct addrinfo  *ai_next; /* next structure in linked list */
-       };
-
-   The return value from the function is 0 upon success or a nonzero
-   error code.  The following names are the nonzero error codes from
-   getaddrinfo(), and are defined in <netdb.h>:
-
-       EAI_ADDRFAMILY  address family for hostname not supported
-       EAI_AGAIN       temporary failure in name resolution
-       EAI_BADFLAGS    invalid value for ai_flags
-       EAI_FAIL        non-recoverable failure in name resolution
-       EAI_FAMILY      ai_family not supported
-       EAI_MEMORY      memory allocation failure
-       EAI_NODATA      no address associated with hostname
-       EAI_NONAME      hostname nor servname provided, or not known
-       EAI_SERVICE     servname not supported for ai_socktype
-       EAI_SOCKTYPE    ai_socktype not supported
-       EAI_SYSTEM      system error returned in errno
-
-   The hostname and servname arguments are pointers to null-terminated
-   strings or NULL.  One or both of these two arguments must be a non-
-   NULL pointer.  In the normal client scenario, both the hostname and
-   servname are specified.  In the normal server scenario, only the
-   servname is specified.  A non-NULL hostname string can be either a
-   host name or a numeric host address string (i.e., a dotted-decimal
-   IPv4 address or an IPv6 hex address).  A non-NULL servname string can
-   be either a service name or a decimal port number.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 23]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The caller can optionally pass an addrinfo structure, pointed to by
-   the third argument, to provide hints concerning the type of socket
-   that the caller supports.  In this hints structure all members other
-   than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
-   or a NULL pointer.  A value of PF_UNSPEC for ai_family means the
-   caller will accept any protocol family.  A value of 0 for ai_socktype
-   means the caller will accept any socket type.  A value of 0 for
-   ai_protocol means the caller will accept any protocol.  For example,
-   if the caller handles only TCP and not UDP, then the ai_socktype
-   member of the hints structure should be set to SOCK_STREAM when
-   getaddrinfo() is called.  If the caller handles only IPv4 and not
-   IPv6, then the ai_family member of the hints structure should be set
-   to PF_INET when getaddrinfo() is called.  If the third argument to
-   getaddrinfo() is a NULL pointer, this is the same as if the caller
-   had filled in an addrinfo structure initialized to zero with
-   ai_family set to PF_UNSPEC.
-
-   Upon successful return a pointer to a linked list of one or more
-   addrinfo structures is returned through the final argument.  The
-   caller can process each addrinfo structure in this list by following
-   the ai_next pointer, until a NULL pointer is encountered.  In each
-   returned addrinfo structure the three members ai_family, ai_socktype,
-   and ai_protocol are the corresponding arguments for a call to the
-   socket() function.  In each addrinfo structure the ai_addr member
-   points to a filled-in socket address structure whose length is
-   specified by the ai_addrlen member.
-
-   If the AI_PASSIVE bit is set in the ai_flags member of the hints
-   structure, then the caller plans to use the returned socket address
-   structure in a call to bind().  In this case, if the hostname
-   argument is a NULL pointer, then the IP address portion of the socket
-   address structure will be set to INADDR_ANY for an IPv4 address or
-   IN6ADDR_ANY_INIT for an IPv6 address.
-
-   If the AI_PASSIVE bit is not set in the ai_flags member of the hints
-   structure, then the returned socket address structure will be ready
-   for a call to connect() (for a connection-oriented protocol) or
-   either connect(), sendto(), or sendmsg() (for a connectionless
-   protocol).  In this case, if the hostname argument is a NULL pointer,
-   then the IP address portion of the socket address structure will be
-   set to the loopback address.
-
-   If the AI_CANONNAME bit is set in the ai_flags member of the hints
-   structure, then upon successful return the ai_canonname member of the
-   first addrinfo structure in the linked list will point to a null-
-   terminated string containing the canonical name of the specified
-   hostname.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 24]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   All of the information returned by getaddrinfo() is dynamically
-   allocated: the addrinfo structures, and the socket address structures
-   and canonical host name strings pointed to by the addrinfo
-   structures.  To return this information to the system the function
-   freeaddrinfo() is called:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       void freeaddrinfo(struct addrinfo *ai);
-
-   The addrinfo structure pointed to by the ai argument is freed, along
-   with any dynamic storage pointed to by the structure.  This operation
-   is repeated until a NULL ai_next pointer is encountered.
-
-   To aid applications in printing error messages based on the EAI_xxx
-   codes returned by getaddrinfo(), the following function is defined.
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       char *gai_strerror(int ecode);
-
-   The argument is one of the EAI_xxx values defined earlier and the
-   eturn value points to a string describing the error.  If the argument
-   is not one of the EAI_xxx values, the function still returns a
-   pointer to a string whose contents indicate an unknown error.
-
-6.4.  Socket Address Structure to Hostname and Service Name
-
-   The POSIX 1003.1g specification includes no function to perform the
-   reverse conversion from getaddrinfo():  to look up a hostname and
-   service name, given the binary address and port.  Therefore, we
-   define the following function:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       int getnameinfo(const struct sockaddr *sa, size_t salen,
-                       char *host, size_t hostlen,
-                       char *serv, size_t servlen,
-                       int flags);
-
-   This function looks up an IP address and port number provided by the
-   caller in the DNS and system-specific database, and returns text
-   strings for both in buffers provided by the caller.  The function
-   indicates successful completion by a zero return value; a non-zero
-   return value indicates failure.
-
-
-
-Gilligan, et. al.            Informational                     [Page 25]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The first argument, sa, points to either a sockaddr_in structure (for
-   IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
-   address and port number.  The salen argument gives the length of the
-   sockaddr_in or sockaddr_in6 structure.
-
-   The function returns the hostname associated with the IP address in
-   the buffer pointed to by the host argument.  The caller provides the
-   size of this buffer via the hostlen argument.  The service name
-   associated with the port number is returned in the buffer pointed to
-   by serv, and the servlen argument gives the length of this buffer.
-   The caller specifies not to return either string by providing a zero
-   value for the hostlen or servlen arguments.  Otherwise, the caller
-   must provide buffers large enough to hold the hostname and the
-   service name, including the terminating null characters.
-
-   Unfortunately most systems do not provide constants that specify the
-   maximum size of either a fully-qualified domain name or a service
-   name.  Therefore to aid the application in allocating buffers for
-   these two returned strings the following constants are defined in
-   <netdb.h>:
-
-       #define NI_MAXHOST  1025
-       #define NI_MAXSERV    32
-
-   The first value is actually defined as the constant MAXDNAME in
-   recent versions of BIND's <arpa/nameser.h> header (older versions of
-   BIND define this constant to be 256) and the second is a guess based
-   on the services listed in the current Assigned Numbers RFC.
-
-   The final argument is a flag that changes the default actions of this
-   function.  By default the fully-qualified domain name (FQDN) for the
-   host is looked up in the DNS and returned.  If the flag bit NI_NOFQDN
-   is set, only the hostname portion of the FQDN is returned for local
-   hosts.
-
-   If the flag bit NI_NUMERICHOST is set, or if the host's name cannot
-   be located in the DNS, the numeric form of the host's address is
-   returned instead of its name (e.g., by calling inet_ntop() instead of
-   gethostbyaddr()).  If the flag bit NI_NAMEREQD is set, an error is
-   returned if the host's name cannot be located in the DNS.
-
-   If the flag bit NI_NUMERICSERV is set, the numeric form of the
-   service address is returned (e.g., its port number) instead of its
-   name.  The two NI_NUMERICxxx flags are required to support the "-n"
-   flag that many commands provide.
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 26]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   A fifth flag bit, NI_DGRAM, specifies that the service is a datagram
-   service, and causes getservbyport() to be called with a second
-   argument of "udp" instead of its default of "tcp".  This is required
-   for the few ports (512-514) that have different services for UDP and
-   TCP.
-
-   These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
-   flags already defined for getaddrinfo().
-
-6.5.  Address Conversion Functions
-
-   The two functions inet_addr() and inet_ntoa() convert an IPv4 address
-   between binary and text form.  IPv6 applications need similar
-   functions.  The following two functions convert both IPv6 and IPv4
-   addresses:
-
-       #include <sys/socket.h>
-       #include <arpa/inet.h>
-
-       int inet_pton(int af, const char *src, void *dst);
-
-       const char *inet_ntop(int af, const void *src,
-                             char *dst, size_t size);
-
-   The inet_pton() function converts an address in its standard text
-   presentation form into its numeric binary form.  The af argument
-   specifies the family of the address.  Currently the AF_INET and
-   AF_INET6 address families are supported.  The src argument points to
-   the string being passed in.  The dst argument points to a buffer into
-   which the function stores the numeric address.  The address is
-   returned in network byte order.  Inet_pton() returns 1 if the
-   conversion succeeds, 0 if the input is not a valid IPv4 dotted-
-   decimal string or a valid IPv6 address string, or -1 with errno set
-   to EAFNOSUPPORT if the af argument is unknown.  The calling
-   application must ensure that the buffer referred to by dst is large
-   enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
-   bytes for AF_INET6).
-
-   If the af argument is AF_INET, the function accepts a string in the
-   standard IPv4 dotted-decimal form:
-
-       ddd.ddd.ddd.ddd
-
-   where ddd is a one to three digit decimal number between 0 and 255.
-   Note that many implementations of the existing inet_addr() and
-   inet_aton() functions accept nonstandard input:  octal numbers,
-   hexadecimal numbers, and fewer than four numbers.  inet_pton() does
-   not accept these formats.
-
-
-
-Gilligan, et. al.            Informational                     [Page 27]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   If the af argument is AF_INET6, then the function accepts a string in
-   one of the standard IPv6 text forms defined in Section 2.2 of the
-   addressing architecture specification [2].
-
-   The inet_ntop() function converts a numeric address into a text
-   string suitable for presentation.  The af argument specifies the
-   family of the address.  This can be AF_INET or AF_INET6.  The src
-   argument points to a buffer holding an IPv4 address if the af
-   argument is AF_INET, or an IPv6 address if the af argument is
-   AF_INET6.  The dst argument points to a buffer where the function
-   will store the resulting text string.  The size argument specifies
-   the size of this buffer.  The application must specify a non-NULL dst
-   argument.  For IPv6 addresses, the buffer must be at least 46-octets.
-   For IPv4 addresses, the buffer must be at least 16-octets.  In order
-   to allow applications to easily declare buffers of the proper size to
-   store IPv4 and IPv6 addresses in string form, the following two
-   constants are defined in <netinet/in.h>:
-
-       #define INET_ADDRSTRLEN    16
-       #define INET6_ADDRSTRLEN   46
-
-   The inet_ntop() function returns a pointer to the buffer containing
-   the text string if the conversion succeeds, and NULL otherwise.  Upon
-   failure, errno is set to EAFNOSUPPORT if the af argument is invalid
-   or ENOSPC if the size of the result buffer is inadequate.
-
-6.6.  Address Testing Macros
-
-   The following macros can be used to test for special IPv6 addresses.
-
-       #include <netinet/in.h>
-
-       int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
-       int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
-       int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
-       int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
-       int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
-       int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
-       int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
-
-       int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-       int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-       int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-       int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
-       int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 28]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The first seven macros return true if the address is of the specified
-   type, or false otherwise.  The last five test the scope of a
-   multicast address and return true if the address is a multicast
-   address of the specified scope or false if the address is either not
-   a multicast address or not of the specified scope.
-
-7.  Summary of New Definitions
-
-   The following list summarizes the constants, structure, and extern
-   definitions discussed in this memo, sorted by header.
-
-     <net/if.h>      IFNAMSIZ
-     <net/if.h>      struct if_nameindex{};
-
-     <netdb.h>       AI_CANONNAME
-     <netdb.h>       AI_PASSIVE
-     <netdb.h>       EAI_ADDRFAMILY
-     <netdb.h>       EAI_AGAIN
-     <netdb.h>       EAI_BADFLAGS
-     <netdb.h>       EAI_FAIL
-     <netdb.h>       EAI_FAMILY
-     <netdb.h>       EAI_MEMORY
-     <netdb.h>       EAI_NODATA
-     <netdb.h>       EAI_NONAME
-     <netdb.h>       EAI_SERVICE
-     <netdb.h>       EAI_SOCKTYPE
-     <netdb.h>       EAI_SYSTEM
-     <netdb.h>       NI_DGRAM
-     <netdb.h>       NI_MAXHOST
-     <netdb.h>       NI_MAXSERV
-     <netdb.h>       NI_NAMEREQD
-     <netdb.h>       NI_NOFQDN
-     <netdb.h>       NI_NUMERICHOST
-     <netdb.h>       NI_NUMERICSERV
-     <netdb.h>       struct addrinfo{};
-
-     <netinet/in.h>  IN6ADDR_ANY_INIT
-     <netinet/in.h>  IN6ADDR_LOOPBACK_INIT
-     <netinet/in.h>  INET6_ADDRSTRLEN
-     <netinet/in.h>  INET_ADDRSTRLEN
-     <netinet/in.h>  IPPROTO_IPV6
-     <netinet/in.h>  IPV6_ADDRFORM
-     <netinet/in.h>  IPV6_ADD_MEMBERSHIP
-     <netinet/in.h>  IPV6_DROP_MEMBERSHIP
-     <netinet/in.h>  IPV6_MULTICAST_HOPS
-     <netinet/in.h>  IPV6_MULTICAST_IF
-     <netinet/in.h>  IPV6_MULTICAST_LOOP
-     <netinet/in.h>  IPV6_UNICAST_HOPS
-
-
-
-Gilligan, et. al.            Informational                     [Page 29]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-     <netinet/in.h>  SIN6_LEN
-     <netinet/in.h>  extern const struct in6_addr in6addr_any;
-     <netinet/in.h>  extern const struct in6_addr in6addr_loopback;
-     <netinet/in.h>  struct in6_addr{};
-     <netinet/in.h>  struct ipv6_mreq{};
-     <netinet/in.h>  struct sockaddr_in6{};
-
-     <resolv.h>      RES_USE_INET6
-
-     <sys/socket.h>  AF_INET6
-     <sys/socket.h>  PF_INET6
-
-
-   The following list summarizes the function and macro prototypes
-   discussed in this memo, sorted by header.
-
-<arpa/inet.h>   int inet_pton(int, const char *, void *);
-<arpa/inet.h>   const char *inet_ntop(int, const void *,
-                                      char *, size_t);
-
-<net/if.h>      char *if_indextoname(unsigned int, char *);
-<net/if.h>      unsigned int if_nametoindex(const char *);
-<net/if.h>      void if_freenameindex(struct if_nameindex *);
-<net/if.h>      struct if_nameindex *if_nameindex(void);
-
-<netdb.h>       int getaddrinfo(const char *, const char *,
-                                const struct addrinfo *,
-                                struct addrinfo **);
-<netdb.h>       int getnameinfo(const struct sockaddr *, size_t,
-                                char *, size_t, char *, size_t, int);
-<netdb.h>       void freeaddrinfo(struct addrinfo *);
-<netdb.h>       char *gai_strerror(int);
-<netdb.h>       struct hostent *gethostbyname(const char *);
-<netdb.h>       struct hostent *gethostbyaddr(const char *, int, int);
-<netdb.h>       struct hostent *gethostbyname2(const char *, int);
-
-<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-
-
-Gilligan, et. al.            Informational                     [Page 30]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-8.  Security Considerations
-
-   IPv6 provides a number of new security mechanisms, many of which need
-   to be accessible to applications.  A companion memo detailing the
-   extensions to the socket interfaces to support IPv6 security is being
-   written [3].
-
-9.  Acknowledgments
-
-   Thanks to the many people who made suggestions and provided feedback
-   to to the numerous revisions of this document, including: Werner
-   Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew Cherenson,
-   Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis Dupont,
-   Robert Elz, Marc Hasson, Tim Hartrick, Tom Herbert, Bob Hinden, Wan-
-   Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan
-   Lloyd, Charles Lynn, Jack McCann, Dan McDonald, Dave Mitton, Thomas
-   Narten, Erik Nordmark, Josh Osborne, Craig Partridge, Jean-Luc
-   Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
-   Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
-   Waitzman, Carl Williams, and Kazuhiko Yamamoto,
-
-   The getaddrinfo() and getnameinfo() functions are taken from an
-   earlier Work in Progress by Keith Sklower.  As noted in that
-   document, William Durst, Steven Wise, Michael Karels, and Eric Allman
-   provided many useful discussions on the subject of protocol-
-   independent name-to-address translation, and reviewed early versions
-   of Keith Sklower's original proposal.  Eric Allman implemented the
-   first prototype of getaddrinfo().  The observation that specifying
-   the pair of name and service would suffice for connecting to a
-   service independent of protocol details was made by Marshall Rose in
-   a proposal to X/Open for a "Uniform Network Interface".
-
-   Craig Metz made many contributions to this document.  Ramesh Govindan
-   made a number of contributions and co-authored an earlier version of
-   this memo.
-
-10.  References
-
-   [1] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6)
-       Specification", RFC 1883, December 1995.
-
-   [2] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture",
-       RFC 1884, December 1995.
-
-   [3] McDonald, D., "A Simple IP Security API Extension to BSD Sockets",
-       Work in Progress.
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 31]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   [4] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
-       6.3, November 1995.
-
-   [5] Stevens, W., and M. Thomas, "Advanced Sockets API for IPv6",
-       Work in Progress.
-
-   [6] Vixie, P., "Reverse Name Lookups of Encapsulated IPv4 Addresses in
-       IPv6", Work in Progress.
-
-11.  Authors' Addresses
-
-    Robert E. Gilligan
-    Freegate Corporation
-    710 Lakeway Dr.  STE 230
-    Sunnyvale, CA 94086
-
-    Phone: +1 408 524 4804
-    EMail: gilligan@freegate.net
-
-
-    Susan Thomson
-    Bell Communications Research
-    MRE 2P-343, 445 South Street
-    Morristown, NJ 07960
-
-    Phone: +1 201 829 4514
-    EMail: set@thumper.bellcore.com
-
-
-    Jim Bound
-    Digital Equipment Corporation
-    110 Spitbrook Road ZK3-3/U14
-    Nashua, NH 03062-2698
-
-    Phone: +1 603 881 0400
-    Email: bound@zk3.dec.com
-
-
-    W. Richard Stevens
-    1202 E. Paseo del Zorro
-    Tucson, AZ 85718-2826
-
-    Phone: +1 520 297 9416
-    EMail: rstevens@kohala.com
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 32]
-
diff --git a/doc/rfc/rfc2136.txt b/doc/rfc/rfc2136.txt
deleted file mode 100644
index 4d62702e..00000000
--- a/doc/rfc/rfc2136.txt
+++ /dev/null
@@ -1,1460 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                  P. Vixie, Editor
-Request for Comments: 2136                                          ISC
-Updates: 1035                                                S. Thomson
-Category: Standards Track                                      Bellcore
-                                                             Y. Rekhter
-                                                                  Cisco
-                                                               J. Bound
-                                                                    DEC
-                                                             April 1997
-
-         Dynamic Updates in the Domain Name System (DNS UPDATE)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   The Domain Name System was originally designed to support queries of
-   a statically configured database.  While the data was expected to
-   change, the frequency of those changes was expected to be fairly low,
-   and all updates were made as external edits to a zone's Master File.
-
-   Using this specification of the UPDATE opcode, it is possible to add
-   or delete RRs or RRsets from a specified zone.  Prerequisites are
-   specified separately from update operations, and can specify a
-   dependency upon either the previous existence or nonexistence of an
-   RRset, or the existence of a single RR.
-
-   UPDATE is atomic, i.e., all prerequisites must be satisfied or else
-   no update operations will take place.  There are no data dependent
-   error conditions defined after the prerequisites have been met.
-
-1 - Definitions
-
-   This document intentionally gives more definition to the roles of
-   "Master," "Slave," and "Primary Master" servers, and their
-   enumeration in NS RRs, and the SOA MNAME field.  In that sense, the
-   following server type definitions can be considered an addendum to
-   [RFC1035], and are intended to be consistent with [RFC1996]:
-
-      Slave           an authoritative server that uses AXFR or IXFR to
-                      retrieve the zone and is named in the zone's NS
-                      RRset.
-
-
-
-Vixie, et. al.              Standards Track                     [Page 1]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-      Master          an authoritative server configured to be the
-                      source of AXFR or IXFR data for one or more slave
-                      servers.
-
-      Primary Master  master server at the root of the AXFR/IXFR
-                      dependency graph.  The primary master is named in
-                      the zone's SOA MNAME field and optionally by an NS
-                      RR.  There is by definition only one primary master
-                      server per zone.
-
-   A domain name identifies a node within the domain name space tree
-   structure.  Each node has a set (possibly empty) of Resource Records
-   (RRs).  All RRs having the same NAME, CLASS and TYPE are called a
-   Resource Record Set (RRset).
-
-   The pseudocode used in this document is for example purposes only.
-   If it is found to disagree with the text, the text shall be
-   considered authoritative.  If the text is found to be ambiguous, the
-   pseudocode can be used to help resolve the ambiguity.
-
-   1.1 - Comparison Rules
-
-   1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
-   RDLENGTH and RDATA fields are equal.  Note that the time-to-live
-   (TTL) field is explicitly excluded from the comparison.
-
-   1.1.2. The rules for comparison of character strings in names are
-   specified in [RFC1035 2.3.3].
-
-   1.1.3. Wildcarding is disabled.  That is, a wildcard ("*") in an
-   update only matches a wildcard ("*") in the zone, and vice versa.
-
-   1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in
-   the update, and will not otherwise be followed.  All UPDATE
-   operations are done on the basis of canonical names.
-
-   1.1.5. The following RR types cannot be appended to an RRset.  If the
-   following comparison rules are met, then an attempt to add the new RR
-   will result in the replacement of the previous RR:
-
-      SOA    compare only NAME, CLASS and TYPE -- it is not possible to
-             have more than one SOA per zone, even if any of the data
-             fields differ.
-
-      WKS    compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
-             -- only one WKS RR is possible for this tuple, even if the
-             services masks differ.
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 2]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-      CNAME  compare only NAME, CLASS, and TYPE -- it is not possible
-             to have more than one CNAME RR, even if their data fields
-             differ.
-
-   1.2 - Glue RRs
-
-   For the purpose of determining whether a domain name used in the
-   UPDATE protocol is contained within a specified zone, a domain name
-   is "in" a zone if it is owned by that zone's domain name.  See
-   section 7.18 for details.
-
-   1.3 - New Assigned Numbers
-
-      CLASS = NONE (254)
-      RCODE = YXDOMAIN (6)
-      RCODE = YXRRSET (7)
-      RCODE = NXRRSET (8)
-      RCODE = NOTAUTH (9)
-      RCODE = NOTZONE (10)
-      Opcode = UPDATE (5)
-
-2 - Update Message Format
-
-   The DNS Message Format is defined by [RFC1035 4.1].  Some extensions
-   are necessary (for example, more error codes are possible under
-   UPDATE than under QUERY) and some fields must be overloaded (see
-   description of CLASS fields below).
-
-   The overall format of an UPDATE message is, following [ibid]:
-
-      +---------------------+
-      |        Header       |
-      +---------------------+
-      |         Zone        | specifies the zone to be updated
-      +---------------------+
-      |     Prerequisite    | RRs or RRsets which must (not) preexist
-      +---------------------+
-      |        Update       | RRs or RRsets to be added or deleted
-      +---------------------+
-      |   Additional Data   | additional data
-      +---------------------+
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 3]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   The Header Section specifies that this message is an UPDATE, and
-   describes the size of the other sections.  The Zone Section names the
-   zone that is to be updated by this message.  The Prerequisite Section
-   specifies the starting invariants (in terms of zone content) required
-   for this update.  The Update Section contains the edits to be made,
-   and the Additional Data Section contains data which may be necessary
-   to complete, but is not part of, this update.
-
-   2.1 - Transport Issues
-
-   An update transaction may be carried in a UDP datagram, if the
-   request fits, or in a TCP connection (at the discretion of the
-   requestor).  When TCP is used, the message is in the format described
-   in [RFC1035 4.2.2].
-
-   2.2 - Message Header
-
-   The header of the DNS Message Format is defined by [RFC 1035 4.1].
-   Not all opcodes define the same set of flag bits, though as a
-   practical matter most of the bits defined for QUERY (in [ibid]) are
-   identically defined by the other opcodes.  UPDATE uses only one flag
-   bit (QR).
-
-   The DNS Message Format specifies record counts for its four sections
-   (Question, Answer, Authority, and Additional).  UPDATE uses the same
-   fields, and the same section formats, but the naming and use of these
-   sections differs as shown in the following modified header, after
-   [RFC1035 4.1.1]:
-
-                                      1  1  1  1  1  1
-        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                      ID                       |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |QR|   Opcode  |          Z         |   RCODE   |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                    ZOCOUNT                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                    PRCOUNT                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                    UPCOUNT                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                    ADCOUNT                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 4]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   These fields are used as follows:
-
-   ID      A 16-bit identifier assigned by the entity that generates any
-           kind of request.  This identifier is copied in the
-           corresponding reply and can be used by the requestor to match
-           replies to outstanding requests, or by the server to detect
-           duplicated requests from some requestor.
-
-   QR      A one bit field that specifies whether this message is a
-           request (0), or a response (1).
-
-   Opcode  A four bit field that specifies the kind of request in this
-           message.  This value is set by the originator of a request
-           and copied into the response.  The Opcode value that
-           identifies an UPDATE message is five (5).
-
-   Z       Reserved for future use.  Should be zero (0) in all requests
-           and responses.  A non-zero Z field should be ignored by
-           implementations of this specification.
-
-   RCODE   Response code - this four bit field is undefined in requests
-           and set in responses.  The values and meanings of this field
-           within responses are as follows:
-
-              Mneumonic   Value   Description
-              ------------------------------------------------------------
-              NOERROR     0       No error condition.
-              FORMERR     1       The name server was unable to interpret
-                                  the request due to a format error.
-              SERVFAIL    2       The name server encountered an internal
-                                  failure while processing this request,
-                                  for example an operating system error
-                                  or a forwarding timeout.
-              NXDOMAIN    3       Some name that ought to exist,
-                                  does not exist.
-              NOTIMP      4       The name server does not support
-                                  the specified Opcode.
-              REFUSED     5       The name server refuses to perform the
-                                  specified operation for policy or
-                                  security reasons.
-              YXDOMAIN    6       Some name that ought not to exist,
-                                  does exist.
-              YXRRSET     7       Some RRset that ought not to exist,
-                                  does exist.
-              NXRRSET     8       Some RRset that ought to exist,
-                                  does not exist.
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 5]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-              NOTAUTH     9       The server is not authoritative for
-                                  the zone named in the Zone Section.
-              NOTZONE     10      A name used in the Prerequisite or
-                                  Update Section is not within the
-                                  zone denoted by the Zone Section.
-
-   ZOCOUNT The number of RRs in the Zone Section.
-
-   PRCOUNT The number of RRs in the Prerequisite Section.
-
-   UPCOUNT The number of RRs in the Update Section.
-
-   ADCOUNT The number of RRs in the Additional Data Section.
-
-   2.3 - Zone Section
-
-   The Zone Section has the same format as that specified in [RFC1035
-   4.1.2], with the fields redefined as follows:
-
-                                      1  1  1  1  1  1
-        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                                               |
-      /                     ZNAME                     /
-      /                                               /
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                     ZTYPE                     |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                     ZCLASS                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   UPDATE uses this section to denote the zone of the records being
-   updated.  All records to be updated must be in the same zone, and
-   therefore the Zone Section is allowed to contain exactly one record.
-   The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is
-   the zone's class.
-
-   2.4 - Prerequisite Section
-
-   This section contains a set of RRset prerequisites which must be
-   satisfied at the time the UPDATE packet is received by the primary
-   master server.  The format of this section is as specified by
-   [RFC1035 4.1.3].  There are five possible sets of semantics that can
-   be expressed here, summarized as follows and then explained below.
-
-      (1)  RRset exists (value independent).  At least one RR with a
-           specified NAME and TYPE (in the zone and class specified by
-           the Zone Section) must exist.
-
-
-
-Vixie, et. al.              Standards Track                     [Page 6]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-      (2)  RRset exists (value dependent).  A set of RRs with a
-           specified NAME and TYPE exists and has the same members
-           with the same RDATAs as the RRset specified here in this
-           Section.
-
-      (3)  RRset does not exist.  No RRs with a specified NAME and TYPE
-          (in the zone and class denoted by the Zone Section) can exist.
-
-      (4)  Name is in use.  At least one RR with a specified NAME (in
-           the zone and class specified by the Zone Section) must exist.
-           Note that this prerequisite is NOT satisfied by empty
-           nonterminals.
-
-      (5)  Name is not in use.  No RR of any type is owned by a
-           specified NAME.  Note that this prerequisite IS satisfied by
-           empty nonterminals.
-
-   The syntax of these is as follows:
-
-   2.4.1 - RRset Exists (Value Independent)
-
-   At least one RR with a specified NAME and TYPE (in the zone and class
-   specified in the Zone Section) must exist.
-
-   For this prerequisite, a requestor adds to the section a single RR
-   whose NAME and TYPE are equal to that of the zone RRset whose
-   existence is required.  RDLENGTH is zero and RDATA is therefore
-   empty.  CLASS must be specified as ANY to differentiate this
-   condition from that of an actual RR whose RDLENGTH is naturally zero
-   (0) (e.g., NULL).  TTL is specified as zero (0).
-
-   2.4.2 - RRset Exists (Value Dependent)
-
-   A set of RRs with a specified NAME and TYPE exists and has the same
-   members with the same RDATAs as the RRset specified here in this
-   section.  While RRset ordering is undefined and therefore not
-   significant to this comparison, the sets be identical in their
-   extent.
-
-   For this prerequisite, a requestor adds to the section an entire
-   RRset whose preexistence is required.  NAME and TYPE are that of the
-   RRset being denoted.  CLASS is that of the zone.  TTL must be
-   specified as zero (0) and is ignored when comparing RRsets for
-   identity.
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 7]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   2.4.3 - RRset Does Not Exist
-
-   No RRs with a specified NAME and TYPE (in the zone and class denoted
-   by the Zone Section) can exist.
-
-   For this prerequisite, a requestor adds to the section a single RR
-   whose NAME and TYPE are equal to that of the RRset whose nonexistence
-   is required.  The RDLENGTH of this record is zero (0), and RDATA
-   field is therefore empty.  CLASS must be specified as NONE in order
-   to distinguish this condition from a valid RR whose RDLENGTH is
-   naturally zero (0) (for example, the NULL RR).  TTL must be specified
-   as zero (0).
-
-   2.4.4 - Name Is In Use
-
-   Name is in use.  At least one RR with a specified NAME (in the zone
-   and class specified by the Zone Section) must exist.  Note that this
-   prerequisite is NOT satisfied by empty nonterminals.
-
-   For this prerequisite, a requestor adds to the section a single RR
-   whose NAME is equal to that of the name whose ownership of an RR is
-   required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS must
-   be specified as ANY to differentiate this condition from that of an
-   actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL).  TYPE
-   must be specified as ANY to differentiate this case from that of an
-   RRset existence test.  TTL is specified as zero (0).
-
-   2.4.5 - Name Is Not In Use
-
-   Name is not in use.  No RR of any type is owned by a specified NAME.
-   Note that this prerequisite IS satisfied by empty nonterminals.
-
-   For this prerequisite, a requestor adds to the section a single RR
-   whose NAME is equal to that of the name whose nonownership of any RRs
-   is required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS
-   must be specified as NONE.  TYPE must be specified as ANY.  TTL must
-   be specified as zero (0).
-
-   2.5 - Update Section
-
-   This section contains RRs to be added to or deleted from the zone.
-   The format of this section is as specified by [RFC1035 4.1.3].  There
-   are four possible sets of semantics, summarized below and with
-   details to follow.
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 8]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-      (1) Add RRs to an RRset.
-      (2) Delete an RRset.
-      (3) Delete all RRsets from a name.
-      (4) Delete an RR from an RRset.
-
-   The syntax of these is as follows:
-
-   2.5.1 - Add To An RRset
-
-   RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
-   and RDATA are those being added, and CLASS is the same as the zone
-   class.  Any duplicate RRs will be silently ignored by the primary
-   master.
-
-   2.5.2 - Delete An RRset
-
-   One RR is added to the Update Section whose NAME and TYPE are those
-   of the RRset to be deleted.  TTL must be specified as zero (0) and is
-   otherwise not used by the primary master.  CLASS must be specified as
-   ANY.  RDLENGTH must be zero (0) and RDATA must therefore be empty.
-   If no such RRset exists, then this Update RR will be silently ignored
-   by the primary master.
-
-   2.5.3 - Delete All RRsets From A Name
-
-   One RR is added to the Update Section whose NAME is that of the name
-   to be cleansed of RRsets.  TYPE must be specified as ANY.  TTL must
-   be specified as zero (0) and is otherwise not used by the primary
-   master.  CLASS must be specified as ANY.  RDLENGTH must be zero (0)
-   and RDATA must therefore be empty.  If no such RRsets exist, then
-   this Update RR will be silently ignored by the primary master.
-
-   2.5.4 - Delete An RR From An RRset
-
-   RRs to be deleted are added to the Update Section.  The NAME, TYPE,
-   RDLENGTH and RDATA must match the RR being deleted.  TTL must be
-   specified as zero (0) and will otherwise be ignored by the primary
-   master.  CLASS must be specified as NONE to distinguish this from an
-   RR addition.  If no such RRs exist, then this Update RR will be
-   silently ignored by the primary master.
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 9]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   2.6 - Additional Data Section
-
-   This section contains RRs which are related to the update itself, or
-   to new RRs being added by the update.  For example, out of zone glue
-   (A RRs referred to by new NS RRs) should be presented here.  The
-   server can use or ignore out of zone glue, at the discretion of the
-   server implementor.  The format of this section is as specified by
-   [RFC1035 4.1.3].
-
-3 - Server Behavior
-
-   A server, upon receiving an UPDATE request, will signal NOTIMP to the
-   requestor if the UPDATE opcode is not recognized or if it is
-   recognized but has not been implemented.  Otherwise, processing
-   continues as follows.
-
-   3.1 - Process Zone Section
-
-   3.1.1. The Zone Section is checked to see that there is exactly one
-   RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
-   requestor.  Next, the ZNAME and ZCLASS are checked to see if the zone
-   so named is one of this server's authority zones, else signal NOTAUTH
-   to the requestor.  If the server is a zone slave, the request will be
-   forwarded toward the primary master.
-
-   3.1.2 - Pseudocode For Zone Section Processing
-
-      if (zcount != 1 || ztype != SOA)
-           return (FORMERR)
-      if (zone_type(zname, zclass) == SLAVE)
-           return forward()
-      if (zone_type(zname, zclass) == MASTER)
-           return update()
-      return (NOTAUTH)
-
-   Sections 3.2 through 3.8 describe the primary master's behaviour,
-   whereas Section 6 describes a forwarder's behaviour.
-
-   3.2 - Process Prerequisite Section
-
-   Next, the Prerequisite Section is checked to see that all
-   prerequisites are satisfied by the current state of the zone.  Using
-   the definitions expressed in Section 1.2, if any RR's NAME is not
-   within the zone specified in the Zone Section, signal NOTZONE to the
-   requestor.
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 10]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.2.1. For RRs in this section whose CLASS is ANY, test to see that
-   TTL and RDLENGTH are both zero (0), else signal FORMERR to the
-   requestor.  If TYPE is ANY, test to see that there is at least one RR
-   in the zone whose NAME is the same as that of the Prerequisite RR,
-   else signal NXDOMAIN to the requestor.  If TYPE is not ANY, test to
-   see that there is at least one RR in the zone whose NAME and TYPE are
-   the same as that of the Prerequisite RR, else signal NXRRSET to the
-   requestor.
-
-   3.2.2. For RRs in this section whose CLASS is NONE, test to see that
-   the TTL and RDLENGTH are both zero (0), else signal FORMERR to the
-   requestor.  If the TYPE is ANY, test to see that there are no RRs in
-   the zone whose NAME is the same as that of the Prerequisite RR, else
-   signal YXDOMAIN to the requestor.  If the TYPE is not ANY, test to
-   see that there are no RRs in the zone whose NAME and TYPE are the
-   same as that of the Prerequisite RR, else signal YXRRSET to the
-   requestor.
-
-   3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
-   test to see that the TTL is zero (0), else signal FORMERR to the
-   requestor.  Then, build an RRset for each unique <NAME,TYPE> and
-   compare each resulting RRset for set equality (same members, no more,
-   no less) with RRsets in the zone.  If any Prerequisite RRset is not
-   entirely and exactly matched by a zone RRset, signal NXRRSET to the
-   requestor.  If any RR in this section has a CLASS other than ZCLASS
-   or NONE or ANY, signal FORMERR to the requestor.
-
-   3.2.4 - Table Of Metavalues Used In Prerequisite Section
-
-   CLASS    TYPE     RDATA    Meaning
-   ------------------------------------------------------------
-   ANY      ANY      empty    Name is in use
-   ANY      rrset    empty    RRset exists (value independent)
-   NONE     ANY      empty    Name is not in use
-   NONE     rrset    empty    RRset does not exist
-   zone     rrset    rr       RRset exists (value dependent)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 11]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.2.5 - Pseudocode for Prerequisite Section Processing
-
-      for rr in prerequisites
-           if (rr.ttl != 0)
-                return (FORMERR)
-           if (zone_of(rr.name) != ZNAME)
-                return (NOTZONE);
-           if (rr.class == ANY)
-                if (rr.rdlength != 0)
-                     return (FORMERR)
-                if (rr.type == ANY)
-                     if (!zone_name<rr.name>)
-                          return (NXDOMAIN)
-                else
-                     if (!zone_rrset<rr.name, rr.type>)
-                          return (NXRRSET)
-           if (rr.class == NONE)
-                if (rr.rdlength != 0)
-                     return (FORMERR)
-                if (rr.type == ANY)
-                     if (zone_name<rr.name>)
-                          return (YXDOMAIN)
-                else
-                     if (zone_rrset<rr.name, rr.type>)
-                          return (YXRRSET)
-           if (rr.class == zclass)
-                temp<rr.name, rr.type> += rr
-           else
-                return (FORMERR)
-
-      for rrset in temp
-           if (zone_rrset<rrset.name, rrset.type> != rrset)
-                return (NXRRSET)
-
-   3.3 - Check Requestor's Permissions
-
-   3.3.1. Next, the requestor's permission to update the RRs named in
-   the Update Section may be tested in an implementation dependent
-   fashion or using mechanisms specified in a subsequent Secure DNS
-   Update protocol.  If the requestor does not have permission to
-   perform these updates, the server may write a warning message in its
-   operations log, and may either signal REFUSED to the requestor, or
-   ignore the permission problem and proceed with the update.
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 12]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.3.2. While the exact processing is implementation defined, if these
-   verification activities are to be performed, this is the point in the
-   server's processing where such performance should take place, since
-   if a REFUSED condition is encountered after an update has been
-   partially applied, it will be necessary to undo the partial update
-   and restore the zone to its original state before answering the
-   requestor.
-
-   3.3.3 - Pseudocode for Permission Checking
-
-      if (security policy exists)
-           if (this update is not permitted)
-                if (local option)
-                     log a message about permission problem
-                if (local option)
-                     return (REFUSED)
-
-   3.4 - Process Update Section
-
-   Next, the Update Section is processed as follows.
-
-   3.4.1 - Prescan
-
-   The Update Section is parsed into RRs and each RR's CLASS is checked
-   to see if it is ANY, NONE, or the same as the Zone Class, else signal
-   a FORMERR to the requestor.  Using the definitions in Section 1.2,
-   each RR's NAME must be in the zone specified by the Zone Section,
-   else signal NOTZONE to the requestor.
-
-   3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
-   ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
-   unrecognized type, then signal FORMERR to the requestor.  For RRs
-   whose CLASS is ANY or NONE, check the TTL to see that it is zero (0),
-   else signal a FORMERR to the requestor.  For any RR whose CLASS is
-   ANY, check the RDLENGTH to make sure that it is zero (0) (that is,
-   the RDATA field is empty), and that the TYPE is not AXFR, MAILA,
-   MAILB, or any other QUERY metatype besides ANY, or any unrecognized
-   type, else signal FORMERR to the requestor.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 13]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.4.1.3 - Pseudocode For Update Section Prescan
-
-      [rr] for rr in updates
-           if (zone_of(rr.name) != ZNAME)
-                return (NOTZONE);
-           if (rr.class == zclass)
-                if (rr.type & ANY|AXFR|MAILA|MAILB)
-                     return (FORMERR)
-           elsif (rr.class == ANY)
-                if (rr.ttl != 0 || rr.rdlength != 0
-                    || rr.type & AXFR|MAILA|MAILB)
-                     return (FORMERR)
-           elsif (rr.class == NONE)
-                if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
-                     return (FORMERR)
-           else
-                return (FORMERR)
-
-   3.4.2 - Update
-
-   The Update Section is parsed into RRs and these RRs are processed in
-   order.
-
-   3.4.2.1. If any system failure (such as an out of memory condition,
-   or a hardware error in persistent storage) occurs during the
-   processing of this section, signal SERVFAIL to the requestor and undo
-   all updates applied to the zone during this transaction.
-
-   3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
-   the zone.  In case of duplicate RDATAs (which for SOA RRs is always
-   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
-   fields both match), the Zone RR is replaced by Update RR.  If the
-   TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
-   lower (according to [RFC1982]) than or equal to the current Zone SOA
-   RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
-   Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
-   Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
-   RR.
-
-   3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY,
-   all Zone RRs with the same NAME are deleted, unless the NAME is the
-   same as ZNAME in which case only those RRs whose TYPE is other than
-   SOA or NS are deleted.  For any Update RR whose CLASS is ANY and
-   whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
-   deleted, unless the NAME is the same as ZNAME in which case neither
-   SOA or NS RRs will be deleted.
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 14]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
-   NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
-   unless the NAME is the same as ZNAME and either the TYPE is SOA or
-   the TYPE is NS and the matching Zone RR is the only NS remaining in
-   the RRset, in which case this Update RR is ignored.
-
-   3.4.2.5. Signal NOERROR to the requestor.
-
-   3.4.2.6 - Table Of Metavalues Used In Update Section
-
-   CLASS    TYPE     RDATA    Meaning
-   ---------------------------------------------------------
-   ANY      ANY      empty    Delete all RRsets from a name
-   ANY      rrset    empty    Delete an RRset
-   NONE     rrset    rr       Delete an RR from an RRset
-   zone     rrset    rr       Add to an RRset
-
-   3.4.2.7 - Pseudocode For Update Section Processing
-
-      [rr] for rr in updates
-           if (rr.class == zclass)
-                if (rr.type == CNAME)
-                     if (zone_rrset<rr.name, ~CNAME>)
-                          next [rr]
-                elsif (zone_rrset<rr.name, CNAME>)
-                     next [rr]
-                if (rr.type == SOA)
-                     if (!zone_rrset<rr.name, SOA> ||
-                         zone_rr<rr.name, SOA>.serial > rr.soa.serial)
-                          next [rr]
-                for zrr in zone_rrset<rr.name, rr.type>
-                     if (rr.type == CNAME || rr.type == SOA ||
-                         (rr.type == WKS && rr.proto == zrr.proto &&
-                          rr.address == zrr.address) ||
-                         rr.rdata == zrr.rdata)
-                          zrr = rr
-                          next [rr]
-                zone_rrset<rr.name, rr.type> += rr
-           elsif (rr.class == ANY)
-                if (rr.type == ANY)
-                     if (rr.name == zname)
-                          zone_rrset<rr.name, ~(SOA|NS)> = Nil
-                     else
-                          zone_rrset<rr.name, *> = Nil
-                elsif (rr.name == zname &&
-                       (rr.type == SOA || rr.type == NS))
-                     next [rr]
-                else
-
-
-
-Vixie, et. al.              Standards Track                    [Page 15]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-                     zone_rrset<rr.name, rr.type> = Nil
-           elsif (rr.class == NONE)
-                if (rr.type == SOA)
-                     next [rr]
-                if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
-                     next [rr]
-                zone_rr<rr.name, rr.type, rr.data> = Nil
-      return (NOERROR)
-
-   3.5 - Stability
-
-   When a zone is modified by an UPDATE operation, the server must
-   commit the change to nonvolatile storage before sending a response to
-   the requestor or answering any queries or transfers for the modified
-   zone.  It is reasonable for a server to store only the update records
-   as long as a system reboot or power failure will cause these update
-   records to be incorporated into the zone the next time the server is
-   started.  It is also reasonable for the server to copy the entire
-   modified zone to nonvolatile storage after each update operation,
-   though this would have suboptimal performance for large zones.
-
-   3.6 - Zone Identity
-
-   If the zone's SOA SERIAL is changed by an update operation, that
-   change must be in a positive direction (using modulo 2**32 arithmetic
-   as specified by [RFC1982]).  Attempts to replace an SOA with one
-   whose SERIAL is less than the current one will be silently ignored by
-   the primary master server.
-
-   If the zone's SOA's SERIAL is not changed as a result of an update
-   operation, then the server shall increment it automatically before
-   the SOA or any changed name or RR or RRset is included in any
-   response or transfer.  The primary master server's implementor might
-   choose to autoincrement the SOA SERIAL if any of the following events
-   occurs:
-
-   (1)  Each update operation.
-
-   (2)  A name, RR or RRset in the zone has changed and has subsequently
-        been visible to a DNS client since the unincremented SOA was
-        visible to a DNS client, and the SOA is about to become visible
-        to a DNS client.
-
-   (3)  A configurable period of time has elapsed since the last update
-        operation.  This period shall be less than or equal to one third
-        of the zone refresh time, and the default shall be the lesser of
-        that maximum and 300 seconds.
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 16]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   (4)  A configurable number of updates has been applied since the last
-        SOA change.  The default value for this configuration parameter
-        shall be one hundred (100).
-
-   It is imperative that the zone's contents and the SOA's SERIAL be
-   tightly synchronized.  If the zone appears to change, the SOA must
-   appear to change as well.
-
-   3.7 - Atomicity
-
-   During the processing of an UPDATE transaction, the server must
-   ensure atomicity with respect to other (concurrent) UPDATE or QUERY
-   transactions.  No two transactions can be processed concurrently if
-   either depends on the final results of the other; in particular, a
-   QUERY should not be able to retrieve RRsets which have been partially
-   modified by a concurrent UPDATE, and an UPDATE should not be able to
-   start from prerequisites that might not still hold at the completion
-   of some other concurrent UPDATE.  Finally, if two UPDATE transactions
-   would modify the same names, RRs or RRsets, then such UPDATE
-   transactions must be serialized.
-
-   3.8 - Response
-
-   At the end of UPDATE processing, a response code will be known.  A
-   response message is generated by copying the ID and Opcode fields
-   from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
-   and ADCOUNT fields and associated sections, or placing zeros (0) in
-   the these "count" fields and not including any part of the original
-   update.  The QR bit is set to one (1), and the response is sent back
-   to the requestor.  If the requestor used UDP, then the response will
-   be sent to the requestor's source UDP port.  If the requestor used
-   TCP, then the response will be sent back on the requestor's open TCP
-   connection.
-
-4 - Requestor Behaviour
-
-   4.1. From a requestor's point of view, any authoritative server for
-   the zone can appear to be able to process update requests, even
-   though only the primary master server is actually able to modify the
-   zone's master file.  Requestors are expected to know the name of the
-   zone they intend to update and to know or be able to determine the
-   name servers for that zone.
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 17]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   4.2. If update ordering is desired, the requestor will need to know
-   the value of the existing SOA RR.  Requestors who update the SOA RR
-   must update the SOA SERIAL field in a positive direction (as defined
-   by [RFC1982]) and also preserve the other SOA fields unless the
-   requestor's explicit intent is to change them.  The SOA SERIAL field
-   must never be set to zero (0).
-
-   4.3. If the requestor has reasonable cause to believe that all of a
-   zone's servers will be equally reachable, then it should arrange to
-   try the primary master server (as given by the SOA MNAME field if
-   matched by some NS NSDNAME) first to avoid unnecessary forwarding
-   inside the slave servers.  (Note that the primary master will in some
-   cases not be reachable by all requestors, due to firewalls or network
-   partitioning.)
-
-   4.4. Once the zone's name servers been found and possibly sorted so
-   that the ones more likely to be reachable and/or support the UPDATE
-   opcode are listed first, the requestor composes an UPDATE message of
-   the following form and sends it to the first name server on its list:
-
-      ID:                        (new)
-      Opcode:                    UPDATE
-      Zone zcount:               1
-      Zone zname:                (zone name)
-      Zone zclass:               (zone class)
-      Zone ztype:                T_SOA
-      Prerequisite Section:      (see previous text)
-      Update Section:            (see previous text)
-      Additional Data Section:   (empty)
-
-   4.5. If the requestor receives a response, and the response has an
-   RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
-   appropriate response to its caller.
-
-   4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
-   if no response is received within an implementation dependent timeout
-   period, or if an ICMP error is received indicating that the server's
-   port is unreachable, then the requestor will delete the unusable
-   server from its internal name server list and try the next one,
-   repeating until the name server list is empty.  If the requestor runs
-   out of servers to try, an appropriate error will be returned to the
-   requestor's caller.
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 18]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-5 - Duplicate Detection, Ordering and Mutual Exclusion
-
-   5.1. For correct operation, mechanisms may be needed to ensure
-   idempotence, order UPDATE requests and provide mutual exclusion.  An
-   UPDATE message or response might be delivered zero times, one time,
-   or multiple times.  Datagram duplication is of particular interest
-   since it covers the case of the so-called "replay attack" where a
-   correct request is duplicated maliciously by an intruder.
-
-   5.2. Multiple UPDATE requests or responses in transit might be
-   delivered in any order, due to network topology changes or load
-   balancing, or to multipath forwarding graphs wherein several slave
-   servers all forward to the primary master.  In some cases, it might
-   be required that the earlier update not be applied after the later
-   update, where "earlier" and "later" are defined by an external time
-   base visible to some set of requestors, rather than by the order of
-   request receipt at the primary master.
-
-   5.3. A requestor can ensure transaction idempotence by explicitly
-   deleting some "marker RR" (rather than deleting the RRset of which it
-   is a part) and then adding a new "marker RR" with a different RDATA
-   field.  The Prerequisite Section should specify that the original
-   "marker RR" must be present in order for this UPDATE message to be
-   accepted by the server.
-
-   5.4. If the request is duplicated by a network error, all duplicate
-   requests will fail since only the first will find the original
-   "marker RR" present and having its known previous value.  The
-   decisions of whether to use such a "marker RR" and what RR to use are
-   left up to the application programmer, though one obvious choice is
-   the zone's SOA RR as described below.
-
-   5.5. Requestors can ensure update ordering by externally
-   synchronizing their use of successive values of the "marker RR."
-   Mutual exclusion can be addressed as a degenerate case, in that a
-   single succession of the "marker RR" is all that is needed.
-
-   5.6. A special case where update ordering and datagram duplication
-   intersect is when an RR validly changes to some new value and then
-   back to its previous value.  Without a "marker RR" as described
-   above, this sequence of updates can leave the zone in an undefined
-   state if datagrams are duplicated.
-
-   5.7. To achieve an atomic multitransaction "read-modify-write" cycle,
-   a requestor could first retrieve the SOA RR, and build an UPDATE
-   message one of whose prerequisites was the old SOA RR.  It would then
-   specify updates that would delete this SOA RR and add a new one with
-   an incremented SOA SERIAL, along with whatever actual prerequisites
-
-
-
-Vixie, et. al.              Standards Track                    [Page 19]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   and updates were the object of the transaction.  If the transaction
-   succeeds, the requestor knows that the RRs being changed were not
-   otherwise altered by any other requestor.
-
-6 - Forwarding
-
-   When a zone slave forwards an UPDATE message upward toward the zone's
-   primary master server, it must allocate a new ID and prepare to enter
-   the role of "forwarding server," which is a requestor with respect to
-   the forward server.
-
-   6.1. The set of forward servers will be same as the set of servers
-   this zone slave would use as the source of AXFR or IXFR data.  So,
-   while the original requestor might have used the zone's NS RRset to
-   locate its update server, a forwarder always forwards toward its
-   designated zone master servers.
-
-   6.2. If the original requestor used TCP, then the TCP connection from
-   the requestor is still open and the forwarder must use TCP to forward
-   the message.  If the original requestor used UDP, the forwarder may
-   use either UDP or TCP to forward the message, at the whim of the
-   implementor.
-
-   6.3. It is reasonable for forward servers to be forwarders
-   themselves, if the AXFR dependency graph being followed is a deep one
-   involving firewalls and multiple connectivity realms.  In most cases
-   the AXFR dependency graph will be shallow and the forward server will
-   be the primary master server.
-
-   6.4. The forwarder will not respond to its requestor until it
-   receives a response from its forward server.  UPDATE transactions
-   involving forwarders are therefore time synchronized with respect to
-   the original requestor and the primary master server.
-
-   6.5. When there are multiple possible sources of AXFR data and
-   therefore multiple possible forward servers, a forwarder will use the
-   same fallback strategy with respect to connectivity or timeout errors
-   that it would use when performing an AXFR.  This is implementation
-   dependent.
-
-   6.6. When a forwarder receives a response from a forward server, it
-   copies this response into a new response message, assigns its
-   requestor's ID to that message, and sends the response back to the
-   requestor.
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 20]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-7 - Design, Implementation, Operation, and Protocol Notes
-
-   Some of the principles which guided the design of this UPDATE
-   specification are as follows.  Note that these are not part of the
-   formal specification and any disagreement between this section and
-   any other section of this document should be resolved in favour of
-   the other section.
-
-   7.1. Using metavalues for CLASS is possible only because all RRs in
-   the packet are assumed to be in the same zone, and CLASS is an
-   attribute of a zone rather than of an RRset.  (It is for this reason
-   that the Zone Section is not optional.)
-
-   7.2. Since there are no data-present or data-absent errors possible
-   from processing the Update Section, any necessary data-present and
-   data- absent dependencies should be specified in the Prerequisite
-   Section.
-
-   7.3. The Additional Data Section can be used to supply a server with
-   out of zone glue that will be needed in referrals.  For example, if
-   adding a new NS RR to HOME.VIX.COM specifying a nameserver called
-   NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional
-   Data Section.  Servers can use this information or ignore it, at the
-   discretion of the implementor.  We discourage caching this
-   information for use in subsequent DNS responses.
-
-   7.4. The Additional Data Section might be used if some of the RRs
-   later needed for Secure DNS Update are not actually zone updates, but
-   rather ancillary keys or signatures not intended to be stored in the
-   zone (as an update would be), yet necessary for validating the update
-   operation.
-
-   7.5. It is expected that in the absence of Secure DNS Update, a
-   server will only accept updates if they come from a source address
-   that has been statically configured in the server's description of a
-   primary master zone.  DHCP servers would be likely candidates for
-   inclusion in this statically configured list.
-
-   7.6. It is not possible to create a zone using this protocol, since
-   there is no provision for a slave server to be told who its master
-   servers are.  It is expected that this protocol will be extended in
-   the future to cover this case.  Therefore, at this time, the addition
-   of SOA RRs is unsupported.  For similar reasons, deletion of SOA RRs
-   is also unsupported.
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 21]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   7.7. The prerequisite for specifying that a name own at least one RR
-   differs semantically from QUERY, in that QUERY would return
-   <NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at
-   this name, while UPDATE's prerequisite condition [Section 2.4.4]
-   would NOT be satisfied.
-
-   7.8. It is possible for a UDP response to be lost in transit and for
-   a request to be retried due to a timeout condition.  In this case an
-   UPDATE that was successful the first time it was received by the
-   primary master might ultimately appear to have failed when the
-   response to a duplicate request is finally received by the requestor.
-   (This is because the original prerequisites may no longer be
-   satisfied after the update has been applied.)  For this reason,
-   requestors who require an accurate response code must use TCP.
-
-   7.9. Because a requestor who requires an accurate response code will
-   initiate their UPDATE transaction using TCP, a forwarder who receives
-   a request via TCP must forward it using TCP.
-
-   7.10. Deferral of SOA SERIAL autoincrements is made possible so that
-   serial numbers can be conserved and wraparound at 2**32 can be made
-   an infrequent occurance.  Visible (to DNS clients) SOA SERIALs need
-   to differ if the zone differs.  Note that the Authority Section SOA
-   in a QUERY response is a form of visibility, for the purposes of this
-   prerequisite.
-
-   7.11. A zone's SOA SERIAL should never be set to zero (0) due to
-   interoperability problems with some older but widely installed
-   implementations of DNS.  When incrementing an SOA SERIAL, if the
-   result of the increment is zero (0) (as will be true when wrapping
-   around 2**32), it is necessary to increment it again or set it to one
-   (1).  See [RFC1982] for more detail on this subject.
-
-   7.12. Due to the TTL minimalization necessary when caching an RRset,
-   it is recommended that all TTLs in an RRset be set to the same value.
-   While the DNS Message Format permits variant TTLs to exist in the
-   same RRset, and this variance can exist inside a zone, such variance
-   will have counterintuitive results and its use is discouraged.
-
-   7.13. Zone cut management presents some obscure corner cases to the
-   add and delete operations in the Update Section.  It is possible to
-   delete an NS RR as long as it is not the last NS RR at the root of a
-   zone.  If deleting all RRs from a name, SOA and NS RRs at the root of
-   a zone are unaffected.  If deleting RRsets, it is not possible to
-   delete either SOA or NS RRsets at the top of a zone.  An attempt to
-   add an SOA will be treated as a replace operation if an SOA already
-   exists, or as a no-op if the SOA would be new.
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 22]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   7.14. No semantic checking is required in the primary master server
-   when adding new RRs.  Therefore a requestor can cause CNAME or NS or
-   any other kind of RR to be added even if their target name does not
-   exist or does not have the proper RRsets to make the original RR
-   useful.  Primary master servers that DO implement this kind of
-   checking should take great care to avoid out-of-zone dependencies
-   (whose veracity cannot be authoritatively checked) and should
-   implement all such checking during the prescan phase.
-
-   7.15. Nonterminal or wildcard CNAMEs are not well specified by
-   [RFC1035] and their use will probably lead to unpredictable results.
-   Their use is discouraged.
-
-   7.16. Empty nonterminals (nodes with children but no RRs of their
-   own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response
-   to a query of any type for that name.  There is no provision for
-   empty terminal nodes -- so if all RRs of a terminal node are deleted,
-   the name is no longer in use, and queries of any type for that name
-   will result in an NXDOMAIN response.
-
-   7.17. In a deep AXFR dependency graph, it has not historically been
-   an error for slaves to depend mutually upon each other.  This
-   configuration has been used to enable a zone to flow from the primary
-   master to all slaves even though not all slaves have continuous
-   connectivity to the primary master.  UPDATE's use of the AXFR
-   dependency graph for forwarding prohibits this kind of dependency
-   loop, since UPDATE forwarding has no loop detection analagous to the
-   SOA SERIAL pretest used by AXFR.
-
-   7.18. Previously existing names which are occluded by a new zone cut
-   are still considered part of the parent zone, for the purposes of
-   zone transfers, even though queries for such names will be referred
-   to the new subzone's servers.  If a zone cut is removed, all parent
-   zone names that were occluded by it will again become visible to
-   queries.  (This is a clarification of [RFC1034].)
-
-   7.19. If a server is authoritative for both a zone and its child,
-   then queries for names at the zone cut between them will be answered
-   authoritatively using only data from the child zone.  (This is a
-   clarification of [RFC1034].)
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 23]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   7.20. Update ordering using the SOA RR is problematic since there is
-   no way to know which of a zone's NS RRs represents the primary
-   master, and the zone slaves can be out of date if their SOA.REFRESH
-   timers have not elapsed since the last time the zone was changed on
-   the primary master.  We recommend that a zone needing ordered updates
-   use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see
-   [RFC1995]), and that a client receiving a prerequisite error while
-   attempting an ordered update simply retry after a random delay period
-   to allow the zone to settle.
-
-8 - Security Considerations
-
-   8.1. In the absence of [RFC2137] or equivilent technology, the
-   protocol described by this document makes it possible for anyone who
-   can reach an authoritative name server to alter the contents of any
-   zones on that server.  This is a serious increase in vulnerability
-   from the current technology.  Therefore it is very strongly
-   recommended that the protocols described in this document not be used
-   without [RFC2137] or other equivalently strong security measures,
-   e.g. IPsec.
-
-   8.2. A denial of service attack can be launched by flooding an update
-   forwarder with TCP sessions containing updates that the primary
-   master server will ultimately refuse due to permission problems.
-   This arises due to the requirement that an update forwarder receiving
-   a request via TCP use a synchronous TCP session for its forwarding
-   operation.  The connection management mechanisms of [RFC1035 4.2.2]
-   are sufficient to prevent large scale damage from such an attack, but
-   not to prevent some queries from going unanswered during the attack.
-
-Acknowledgements
-
-   We would like to thank the IETF DNSIND working group for their input
-   and assistance, in particular, Rob Austein, Randy Bush, Donald
-   Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz.  Special
-   thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing this
-   document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 24]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-References
-
-   [RFC1035]
-      Mockapetris, P., "Domain Names - Implementation and
-      Specification", STD 13, RFC 1035, USC/Information Sciences
-      Institute, November 1987.
-
-   [RFC1982]
-      Elz, R., "Serial Number Arithmetic", RFC 1982, University of
-      Melbourne, August 1996.
-
-   [RFC1995]
-      Ohta, M., "Incremental Zone Transfer", RFC 1995, Tokyo Institute
-      of Technology, August 1996.
-
-   [RFC1996]
-      Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
-      RFC 1996, Internet Software Consortium, August 1996.
-
-   [RFC2065]
-      Eastlake, D., and C. Kaufman, "Domain Name System Protocol
-      Security Extensions", RFC 2065, January 1997.
-
-   [RFC2137]
-      Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
-      2137, April 1997.
-
-Authors' Addresses
-
-   Yakov Rekhter
-   Cisco Systems
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-
-   Phone: +1 914 528 0090
-   EMail: yakov@cisco.com
-
-
-   Susan Thomson
-   Bellcore
-   445 South Street
-   Morristown, NJ 07960
-
-   Phone: +1 201 829 4514
-   EMail: set@thumper.bellcore.com
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 25]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   Jim Bound
-   Digital Equipment Corp.
-   110 Spitbrook Rd ZK3-3/U14
-   Nashua, NH 03062-2698
-
-   Phone: +1 603 881 0400
-   EMail: bound@zk3.dec.com
-
-
-   Paul Vixie
-   Internet Software Consortium
-   Star Route Box 159A
-   Woodside, CA 94062
-
-   Phone: +1 415 747 0204
-   EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 26]
-
-
diff --git a/doc/rfc/rfc2137.txt b/doc/rfc/rfc2137.txt
deleted file mode 100644
index ceb3613d..00000000
--- a/doc/rfc/rfc2137.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 2137                               CyberCash, Inc.
-Updates: 1035                                                 April 1997
-Category: Standards Track
-
-
-                Secure Domain Name System Dynamic Update
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   Domain Name System (DNS) protocol extensions have been defined to
-   authenticate the data in DNS and provide key distribution services
-   [RFC2065].  DNS Dynamic Update operations have also been defined
-   [RFC2136], but without a detailed description of security for the
-   update operation.  This memo describes how to use DNSSEC digital
-   signatures covering requests and data to secure updates and restrict
-   updates to those authorized to perform them as indicated by the
-   updater's possession of cryptographic keys.
-
-Acknowledgements
-
-   The contributions of the following persons (who are listed in
-   alphabetic order) to this memo are gratefully acknowledged:
-
-         Olafur Gudmundsson (ogud@tis.com>
-         Charlie Kaufman <Charlie_Kaufman@iris.com>
-         Stuart Kwan <skwan@microsoft.com>
-         Edward Lewis <lewis@tis.com>
-
-Table of Contents
-
-      1. Introduction............................................2
-      1.1 Overview of DNS Dynamic Update.........................2
-      1.2 Overview of DNS Security...............................2
-      2. Two Basic Modes.........................................3
-      3. Keys....................................................5
-      3.1 Update Keys............................................6
-      3.1.1 Update Key Name Scope................................6
-      3.1.2 Update Key Class Scope...............................6
-      3.1.3 Update Key Signatory Field...........................6
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-      3.2 Zone Keys and Update Modes.............................8
-      3.3 Wildcard Key Punch Through.............................9
-      4. Update Signatures.......................................9
-      4.1 Update Request Signatures..............................9
-      4.2 Update Data Signatures................................10
-      5. Security Considerations................................10
-      References................................................10
-      Author's Address..........................................11
-
-1. Introduction
-
-   Dynamic update operations have been defined for the Domain Name
-   System (DNS) in RFC 2136, but without a detailed description of
-   security for those updates.  Means of securing the DNS and using it
-   for key distribution have been defined in RFC 2065.
-
-   This memo proposes techniques based on the defined DNS security
-   mechanisms to authenticate DNS updates.
-
-   Familiarity with the DNS system [RFC 1034, 1035] is assumed.
-   Familiarity with the DNS security and dynamic update proposals will
-   be helpful.
-
-1.1 Overview of DNS Dynamic Update
-
-   DNS dynamic update defines a new DNS opcode, new DNS request and
-   response structure if that opcode is used, and new error codes.  An
-   update can specify complex combinations of deletion and insertion
-   (with or without pre-existence testing) of resource records (RRs)
-   with one or more owner names; however, all testing and changes for
-   any particular DNS update request are restricted to a single zone.
-   Updates occur at the primary server for a zone.
-
-   The primary server for a secure dynamic zone must increment the zone
-   SOA serial number when an update occurs or the next time the SOA is
-   retrieved if one or more updates have occurred since the previous SOA
-   retrieval and the updates themselves did not update the SOA.
-
-1.2 Overview of DNS Security
-
-   DNS security authenticates data in the DNS by also storing digital
-   signatures in the DNS as SIG resource records (RRs).  A SIG RR
-   provides a digital signature on the set of all RRs with the same
-   owner name and class as the SIG and whose type is the type covered by
-   the SIG.  The SIG RR cryptographically binds the covered RR set to
-   the signer, time signed, signature expiration date, etc.  There are
-   one or more keys associated with every secure zone and all data in
-   the secure zone is signed either by a zone key or by a dynamic update
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-   key tracing its authority to a zone key.
-
-   DNS security also defines transaction SIGs and request SIGs.
-   Transaction SIGs appear at the end of a response.  Transaction SIGs
-   authenticate the response and bind it to the corresponding request
-   with the key of the host where the responding DNS server is.  Request
-   SIGs appear at the end of a request and authenticate the request with
-   the key of the submitting entity.
-
-   Request SIGs are the primary means of authenticating update requests.
-
-   DNS security also permits the storage of public keys in the DNS via
-   KEY RRs.  These KEY RRs are also, of course, authenticated by SIG
-   RRs.  KEY RRs for zones are stored in their superzone and subzone
-   servers, if any, so that the secure DNS tree of zones can be
-   traversed by a security aware resolver.
-
-2. Two Basic Modes
-
-   A dynamic secure zone is any secure DNS zone containing one or more
-   KEY RRs that can authorize dynamic updates, i.e., entity or user KEY
-   RRs with the signatory field non-zero, and whose zone KEY RR
-   signatory field indicates that updates are implemented. There are two
-   basic modes of dynamic secure zone which relate to the update
-   strategy, mode A and mode B.  A summary comparison table is given
-   below and then each mode is described.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-                   SUMMARY OF DYNAMIC SECURE ZONE MODES
-
-   CRITERIA:                |   MODE A           |   MODE B
-   =========================+====================+===================
-   Definition:              | Zone Key Off line  | Zone Key On line
-   =========================+====================+===================
-   Server Workload          |   Low              |   High
-   -------------------------+--------------------+-------------------
-   Static Data Security     |   Very High        |   Medium-High
-   -------------------------+--------------------+-------------------
-   Dynamic Data Security    |   Medium           |   Medium-High
-   -------------------------+--------------------+-------------------
-   Key Restrictions         |   Fine grain       |   Coarse grain
-   -------------------------+--------------------+-------------------
-   Dynamic Data Temporality |   Transient        |   Permanent
-   -------------------------+--------------------+-------------------
-   Dynamic Key Rollover     |   No               |   Yes
-   -------------------------+--------------------+-------------------
-
-   For mode A, the zone owner key and static zone master file are always
-   kept off-line for maximum security of the static zone contents.
-
-   As a consequence, any dynamicly added or changed RRs are signed in
-   the secure zone by their authorizing dynamic update key and they are
-   backed up, along with this SIG RR, in a separate online dynamic
-   master file.  In this type of zone, server computation is minimized
-   since the server need only check signatures on the update data and
-   request, which have already been signed by the updater, generally a
-   much faster operation than signing data.  However, the AXFR SIG and
-   NXT RRs which covers the zone under the zone key will not cover
-   dynamically added data.  Thus, for type A dynamic secure zones, zone
-   transfer security is not automatically provided for dynamically added
-   RRs, where they could be omitted, and authentication is not provided
-   for the server denial of the existence of a dynamically added type.
-   Because the dynamicly added RRs retain their update KEY signed SIG,
-   finer grained control of updates can be implemented via bits in the
-   KEY RR signatory field.  Because dynamic data is only stored in the
-   online dynamic master file and only authenticated by dynamic keys
-   which expire, updates are transient in nature.  Key rollover for an
-   entity that can authorize dynamic updates is more cumbersome since
-   the authority of their key must be traceable to a zone key and so, in
-   general, they must securely communicate a new key to the zone
-   authority for manual transfer to the off line static master file.
-   NOTE: for this mode the zone SOA must be signed by a dynamic update
-   key and that private key must be kept on line so that the SOA can be
-   changed for updates.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-   For mode B, the zone owner key and master file are kept on-line at
-   the zone primary server. When authenticated updates succeed, SIGs
-   under the zone key for the resulting data (including the possible NXT
-   type bit map changes) are calculated and these SIG (and possible NXT)
-   changes are entered into the zone and the unified on-line master
-   file.  (The zone transfer AXFR SIG may be recalculated for each
-   update or on demand when a zone transfer is requested and it is out
-   of date.)
-
-   As a consequence, this mode requires considerably more computational
-   effort on the part of the server as the public/private keys are
-   generally arranged so that signing (calculating a SIG) is more effort
-   than verifying a signature.  The security of static data in the zone
-   is decreased because the ultimate state of the static data being
-   served and the ultimate zone authority private key are all on-line on
-   the net.  This means that if the primary server is subverted, false
-   data could be authenticated to secondaries and other
-   servers/resolvers.  On the other hand, this mode of operation means
-   that data added dynamically is more secure than in mode A.  Dynamic
-   data will be covered by the AXFR SIG and thus always protected during
-   zone transfers and will be included in NXT RRs so that it can be
-   falsely denied by a server only to the same extent that static data
-   can (i.e., if it is within a wild card scope). Because the zone key
-   is used to sign all the zone data, the information as to who
-   originated the current state of dynamic RR sets is lost, making
-   unavailable the effects of some of the update control bits in the KEY
-   RR signatory field.  In addition, the incorporation of the updates
-   into the primary master file and their authentication by the zone key
-   makes then permanent in nature.  Maintaining the zone key on-line
-   also means that dynamic update keys which are signed by the zone key
-   can be dynamically updated since the zone key is available to
-   dynamically sign new values.
-
-   NOTE:  The Mode A / Mode B distinction only effects the validation
-   and performance of update requests.  It has no effect on retrievals.
-   One reasonable operational scheme may be to keep a mostly static main
-   zone operating in Mode A and have one or more dynamic subzones
-   operating in Mode B.
-
-3. Keys
-
-   Dynamic update requests depend on update keys as described in section
-   3.1 below.  In addition, the zone secure dynamic update mode and
-   availability of some options is indicated in the zone key.  Finally,
-   a special rule is used in searching for KEYs to validate updates as
-   described in section 3.3.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-3.1 Update Keys
-
-   All update requests to a secure zone must include signatures by one
-   or more key(s) that together can authorize that update.  In order for
-   the Domain Name System (DNS) server receiving the request to confirm
-   this, the key or keys must be available to and authenticated by that
-   server as a specially flagged KEY Resource Record.
-
-   The scope of authority of such keys is indicated by their KEY RR
-   owner name, class, and signatory field flags as described below. In
-   addition, such KEY RRs must be entity or user keys and not have the
-   authentication use prohibited bit on.  All parts of the actual update
-   must be within the scope of at least one of the keys used for a
-   request SIG on the update request as described in section 4.
-
-3.1.1 Update Key Name Scope
-
-   The owner name of any update authorizing KEY RR must (1) be the same
-   as the owner name of any RRs being added or deleted or (2) a wildcard
-   name including within its extended scope (see section 3.3) the name
-   of any RRs being added or deleted and those RRs must be in the same
-   zone.
-
-3.1.2 Update Key Class Scope
-
-   The class of any update authorizing KEY RR must be the same as the
-   class of any RR's being added or deleted.
-
-3.1.3 Update Key Signatory Field
-
-   The four bit "signatory field" (see RFC 2065) of any update
-   authorizing KEY RR must be non-zero.  The bits have the meanings
-   described below for non-zone keys (see section 3.2 for zone type
-   keys).
-
-                    UPDATE KEY RR SIGNATORY FIELD BITS
-
-         0           1           2           3
-   +-----------+-----------+-----------+-----------+
-   |   zone    |  strong   |  unique   |  general  |
-   +-----------+-----------+-----------+-----------+
-
-   Bit 0, zone control - If nonzero, this key is authorized to attach,
-        detach, and move zones by creating and deleting NS, glue A, and
-        zone KEY RR(s).  If zero, the key can not authorize any update
-        that would effect such RRs.  This bit is meaningful for both
-        type A and type B dynamic secure zones.
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-        NOTE:  do not confuse the "zone" signatory field bit with the
-        "zone" key type bit.
-
-   Bit 1, strong update - If nonzero, this key is authorized to add and
-        delete RRs even if there are other RRs with the same owner name
-        and class that are authenticated by a SIG signed with a
-        different dynamic update KEY. If zero, the key can only
-        authorize updates where any existing RRs of the same owner and
-        class are authenticated by a SIG using the same key.  This bit
-        is meaningful only for type A dynamic zones and is ignored in
-        type B dynamic zones.
-
-        Keeping this bit zero on multiple KEY RRs with the same or
-        nested wild card owner names permits multiple entities to exist
-        that can create and delete names but can not effect RRs with
-        different owner names from any they created.  In effect, this
-        creates two levels of dynamic update key, strong and weak, where
-        weak keys are limited in interfering with each other but a
-        strong key can interfere with any weak keys or other strong
-        keys.
-
-   Bit 2, unique name update - If nonzero, this key is authorized to add
-        and update RRs for only a single owner name.  If there already
-        exist RRs with one or more names signed by this key, they may be
-        updated but no new name created until the number of existing
-        names is reduced to zero.  This bit is meaningful only for mode
-        A dynamic zones and is ignored in mode B dynamic zones. This bit
-        is meaningful only if the owner name is a wildcard.  (Any
-        dynamic update KEY with a non-wildcard name is, in effect, a
-        unique name update key.)
-
-        This bit can be used to restrict a KEY from flooding a zone with
-        new names.  In conjunction with a local administratively imposed
-        limit on the number of dynamic RRs with a particular name, it
-        can completely restrict a KEY from flooding a zone with RRs.
-
-   Bit 3, general update - The general update signatory field bit has no
-        special meaning.  If the other three bits are all zero, it must
-        be one so that the field is non-zero to designate that the key
-        is an update key.  The meaning of all values of the signatory
-        field with the general bit and one or more other signatory field
-        bits on is reserved.
-
-   All the signatory bit update authorizations described above only
-   apply if the update is within the name and class scope as per
-   sections 3.1.1 and 3.1.2.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-3.2 Zone Keys and Update Modes
-
-   Zone type keys are automatically authorized to sign anything in their
-   zone, of course, regardless of the value of their signatory field.
-   For zone keys, the signatory field bits have different means than
-   they they do for update keys, as shown below.  The signatory field
-   MUST be zero if dynamic update is not supported for a zone and MUST
-   be non-zero if it is.
-
-                     ZONE KEY RR SIGNATORY FIELD BITS
-
-                  0           1           2           3
-            +-----------+-----------+-----------+-----------+
-            |   mode    |  strong   |  unique   |  general  |
-            +-----------+-----------+-----------+-----------+
-
-   Bit 0, mode - This bit indicates the update mode for this zone.  Zero
-        indicates mode A while a one indicates mode B.
-
-   Bit 1, strong update - If nonzero, this indicates that the "strong"
-        key feature described in section 3.1.3 above is implemented and
-        enabled for this secure zone.  If zero, the feature is not
-        available.  Has no effect if the zone is a mode B secure update
-        zone.
-
-   Bit 2, unique name update - If nonzero, this indicates that the
-        "unique name" feature described in section 3.1.3 above is
-        implemented and enabled for this secure zone.  If zero, this
-        feature is not available.  Has no effect if the zone is a mode B
-        secure update zone.
-
-   Bit 3, general - This bit has no special meeting.  If dynamic update
-        for a zone is supported and the other bits in the zone key
-        signatory field are zero, it must be a one.  The meaning of zone
-        keys where the signatory field has the general bit and one or
-        more other bits on is reserved.
-
-   If there are multiple dynamic update KEY RRs for a zone and zone
-   policy is in transition, they might have different non-zero signatory
-   fields.  In that case, strong and unique name restrictions must be
-   enforced as long as there is a non-expired zone key being advertised
-   that indicates mode A with the strong or unique name bit on
-   respectively.  Mode B updates MUST be supported as long as there is a
-   non-expired zone key that indicates mode B.  Mode A updates may be
-   treated as mode B updates at server option if non-expired zone keys
-   indicate that both are supported.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 8]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-   A server that will be executing update operations on a zone, that is,
-   the primary master server, MUST not advertize a zone key that will
-   attract requests for a mode or features that it can not support.
-
-3.3 Wildcard Key Punch Through
-
-   Just as a zone key is valid throughout the entire zone, update keys
-   with wildcard names are valid throughout their extended scope, within
-   the zone. That is, they remain valid for any name that would match
-   them, even existing specific names within their apparent scope.
-
-   If this were not so, then whenever a name within a wildcard scope was
-   created by dynamic update, it would be necessary to first create a
-   copy of the KEY RR with this name, because otherwise the existence of
-   the more specific name would hide the authorizing KEY RR and would
-   make later updates impossible.  An updater could create such a KEY RR
-   but could not zone sign it with their authorizing signer.  They would
-   have to sign it with the same key using the wildcard name as signer.
-   Thus in creating, for example, one hundred type A RRs authorized by a
-   *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100
-   KEYs, and 200 SIGs would have to be created as opposed to merely 100
-   As and 100 SIGs with key punch through.
-
-4. Update Signatures
-
-   Two kinds of signatures can appear in updates.  Request signatures,
-   which are always required, cover the entire request and authenticate
-   the DNS header, including opcode, counts, etc., as well as the data.
-   Data signatures, on the other hand, appear only among the RRs to be
-   added and are only required for mode A operation.  These two types of
-   signatures are described further below.
-
-4.1 Update Request Signatures
-
-   An update can effect multiple owner names in a zone.  It may be that
-   these different names are covered by different dynamic update keys.
-   For every owner name effected, the updater must know a private key
-   valid for that name (and the zone's class) and must prove this by
-   appending request SIG RRs under each such key.
-
-   As specified in RFC 2065, a request signature is a SIG RR occurring
-   at the end of a request with a type covered field of zero.  For an
-   update, request signatures occur in the Additional information
-   section.  Each request SIG signs the entire request, including DNS
-   header, but excluding any other request SIG(s) and with the ARCOUNT
-   in the DNS header set to what it wold be without the request SIGs.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 9]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-4.2 Update Data Signatures
-
-   Mode A dynamic secure zones require that the update requester provide
-   SIG RRs that will authenticate the after update state of all RR sets
-   that are changed by the update and are non-empty after the update.
-   These SIG RRs appear in the request as RRs to be added and the
-   request must delete any previous data SIG RRs that are invalidated by
-   the request.
-
-   In Mode B dynamic secure zones, all zone data is authenticated by
-   zone key SIG RRs.  In this case, data signatures need not be included
-   with the update.  A resolver can determine which mode an updatable
-   secure zone is using by examining the signatory field bits of the
-   zone KEY RR (see section 3.2).
-
-5. Security Considerations
-
-   Any zone permitting dynamic updates is inherently less secure than a
-   static secure zone maintained off line as recommended in RFC 2065. If
-   nothing else, secure dynamic update requires on line change to and
-   re-signing of the zone SOA resource record (RR) to increase the SOA
-   serial number.  This means that compromise of the primary server host
-   could lead to arbitrary serial number changes.
-
-   Isolation of dynamic RRs to separate zones from those holding most
-   static RRs can limit the damage that could occur from breach of a
-   dynamic zone's security.
-
-References
-
-   [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security
-   Extensions", RFC 2065, CyberCash, Iris, January 1997.
-
-   [RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound,
-   "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-   April 1997.
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-   Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-   STD 13, RFC 1034, November 1987.
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 10]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-Author's Address
-
-   Donald E. Eastlake, 3rd
-   CyberCash, Inc.
-   318 Acton Street
-   Carlisle, MA 01741 USA
-
-   Phone:   +1 508-287-4877
-            +1 508-371-7148 (fax)
-            +1 703-620-4200 (main office, Reston, Virginia, USA)
-   EMail:   dee@cybercash.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 11]
-
diff --git a/doc/rfc/rfc2163.txt b/doc/rfc/rfc2163.txt
deleted file mode 100644
index 00fcee7c..00000000
--- a/doc/rfc/rfc2163.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       C. Allocchio
-Request for Comments: 2163                                    GARR-Italy
-Obsoletes: 1664                                             January 1998
-Category: Standards Track
-
-
-                  Using the Internet DNS to Distribute
-            MIXER Conformant Global Address Mapping (MCGAM)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   This memo is the complete technical specification to store in the
-   Internet Domain Name System (DNS) the mapping information (MCGAM)
-   needed by MIXER conformant e-mail gateways and other tools to map
-   RFC822 domain names into X.400 O/R names and vice versa.  Mapping
-   information can be managed in a distributed rather than a centralised
-   way. Organizations can publish their MIXER mapping or preferred
-   gateway routing information using just local resources (their local
-   DNS server), avoiding the need for a strong coordination with any
-   centralised organization. MIXER conformant gateways and tools located
-   on Internet hosts can retrieve the mapping information querying the
-   DNS instead of having fixed tables which need to be centrally updated
-   and distributed.
-
-   This memo obsoletes RFC1664. It includes the changes introduced by
-   MIXER specification with respect to RFC1327: the new 'gate1' (O/R
-   addresses to domain) table is fully supported. Full backward
-   compatibility with RFC1664 specification is mantained, too.
-
-   RFC1664 was a joint effort of IETF X400 operation working group
-   (x400ops) and TERENA (formely named "RARE") Mail and Messaging
-   working group (WG-MSG). This update was performed by the IETF MIXER
-   working group.
-
-
-
-
-
-
-Allocchio                   Standards Track                     [Page 1]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-1. Introduction
-
-   The connectivity between the Internet SMTP mail and other mail
-   services, including the Internet X.400 mail and the commercial X.400
-   service providers, is assured by the Mail eXchanger (MX) record
-   information distributed via the Internet Domain Name System (DNS). A
-   number of documents then specify in details how to convert or encode
-   addresses from/to RFC822 style to the other mail system syntax.
-   However, only conversion methods provide, via some algorithm or a set
-   of mapping rules, a smooth translation, resulting in addresses
-   indistinguishable from the native ones in both RFC822 and foreign
-   world.
-
-   MIXER describes a set of mappings (MIXER Conformant Global Address
-   Mapping - MCGAM) which will enable interworking between systems
-   operating the CCITT X.400 (1984/88/92) Recommendations and systems
-   using using the RFC822 mail protocol, or protocols derived from
-   RFC822. That document addresses conversion of services, addresses,
-   message envelopes, and message bodies between the two mail systems.
-   This document is concerned with one aspect of MIXER: the mechanism
-   for mapping between X.400 O/R addresses and RFC822 domain names. As
-   described in Appendix F of MIXER, implementation of the mappings
-   requires a database which maps between X.400 O/R addresses and domain
-   names; in RFC1327 this database was statically defined.
-
-   The original approach in RFC1327 required many efforts to maintain
-   the correct mapping: all the gateways needed to get coherent tables
-   to apply the same mappings, the conversion tables had to be
-   distributed among all the operational gateways, and also every update
-   needed to be distributed.
-
-   The concept of mapping rules distribution and use has been revised in
-   the new MIXER specification, introducing the concept of MIXER
-   Conformant Global Address Mapping (MCGAM). A MCGAM does not need to
-   be globally installed by any MIXER conformant gateway in the world
-   any more. However MIXER requires now efficient methods to publish its
-   MCGAM.
-
-   Static tables are one of the possible methods to publish MCGAM.
-   However this static mechanism requires quite a long time to be spent
-   modifying and distributing the information, putting heavy constraints
-   on the time schedule of every update.  In fact it does not appear
-   efficient compared to the Internet Domain Name Service (DNS).  More
-   over it does not look feasible to distribute the database to a large
-   number of other useful applications, like local address converters,
-   e-mail User Agents or any other tool requiring the mapping rules to
-   produce correct results.
-
-
-
-
-Allocchio                   Standards Track                     [Page 2]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   Two much more efficient methods are proposed by MIXER for publication
-   of MCGAM: the Internet DNS and X.500. This memo is the complete
-   technical specification for publishing MCGAM via Internet DNS.
-
-   A first proposal to use the Internet DNS to store, retrieve and
-   maintain those mappings was introduced by two of the authors of
-   RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource record
-   (RR)  types: TO-X400 and TO-822. This proposal now adopts a more
-   complete strategy, and requires one new RR only. The distribution of
-   MCGAMs via DNS is in fact an important service for the whole Internet
-   community: it completes the information given by MX resource record
-   and it allows to produce clean addresses when messages are exchanged
-   among the Internet RFC822 world and the X.400 one (both Internet and
-   Public X.400 service providers).
-
-   A first experiment in using the DNS without expanding the current set
-   of RR and using available ones was deployed by some of the authors of
-   RFC1664 at the time of its development. The existing PTR resource
-   records were used to store the mapping rules, and a new DNS tree was
-   created under the ".it" top level domain. The result of the
-   experiment was positive, and a few test applications ran under this
-   provisional set up. This test was also very useful in order to define
-   a possible migration strategy during the deployment of the new DNS
-   containing the new RR. The Internet DNS nameservers wishing to
-   provide this mapping information need in fact to be modified to
-   support the new RR type, and in the real Internet, due to the large
-   number of different implementations, this takes some time.
-
-   The basic idea is to adopt a new DNS RR to store the mapping
-   information. The RFC822 to X.400 mapping rules (including the so
-   called 'gate2' rules) will be stored in the ordinary DNS tree, while
-   the definition of a new branch of the name space defined under each
-   national top level domain is envisaged in order to contain the X.400
-   to RFC822 mappings ('table1' and 'gate1'). A "two-way" mapping
-   resolution schema is thus fully implemented.
-
-   The creation of the new domain name space representing the X.400 O/R
-   names structure also provides the chance to use the DNS to distribute
-   dynamically other X.400 related information, thus solving other
-   efficiency problems currently affecting the X.400 MHS service.
-
-   In this paper we will adopt the MCGAM syntax, showing how it can be
-   stored into the Internet DNS.
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                     [Page 3]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-1.1 Definitions syntax
-
-   The definitions in this document is given in BNF-like syntax, using
-   the following conventions:
-
-      |   means choice
-      \   is used for continuation of a definition over several lines
-      []  means optional
-      {}  means repeated one or more times
-
-   The definitions, however, are detailed only until a certain level,
-   and below it self-explaining character text strings will be used.
-
-2. Motivation
-
-   Implementations of MIXER gateways require that a database store
-   address mapping information for X.400 and RFC822. This information
-   must be made available (published) to all MIXER gateways. In the
-   Internet community, the DNS has proven to be a practical mean for
-   providing a distributed name service. Advantages of using a DNS based
-   system over a table based approach for mapping between O/R addresses
-   and domain names are:
-
-     - It avoids fetching and storing of entire mapping tables by every
-       host that wishes to implement MIXER gateways and/or tools
-
-     - Modifications to the DNS based mapping information can be made
-       available in a more timely manner than with a table driven
-       approach.
-
-     - It allows full authority delegation, in agreement with the
-       Internet regionalization process.
-
-     - Table management is not necessarily required for DNS-based
-       MIXER gateways.
-
-     - One can determine the mappings in use by a remote gateway by
-       querying the DNS (remote debugging).
-
-   Also many other tools, like address converters and User Agents can
-   take advantage of the real-time availability of MIXER tables,
-   allowing a much easier maintenance of the information.
-
-3. The domain space for X.400 O/R name addresses
-
-   Usual domain names (the ones normally used as the global part of an
-   RFC822 e-mail address) and their associated information, i.e., host
-   IP addresses, mail exchanger names, etc., are stored in the DNS as a
-
-
-
-Allocchio                   Standards Track                     [Page 4]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   distributed database under a number of top-level domains. Some top-
-   level domains are used for traditional categories or international
-   organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand
-   any country has its own two letter ISO country code as top-level
-   domain (FR, DE, GB, IT, RU, ...), including "US" for USA.  The
-   special top-level/second-level couple IN-ADDR.ARPA is used to store
-   the IP address to domain name relationship. This memo defines in the
-   above structure the appropriate way to locate the X.400 O/R name
-   space, thus enabling to store in DNS the MIXER mappings (MCGAMs).
-
-   The MIXER mapping information is composed by four tables:
-
-    - 'table1' and 'gate1' gives the translation from X.400 to RFC822;
-    - 'table2' and 'gate2' tables map RFC822 into X.400.
-
-   Each mapping table is composed by mapping rules, and a single mapping
-   rule is composed by a keyword (the argument of the mapping function
-   derived from the address to be translated) and a translator (the
-   mapping function parameter):
-
-                            keyword#translator#
-
-   the '#' sign is a delimiter enclosing the translator. An example:
-
-                 foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us#
-
-   Local mappings are not intended for use outside their restricted
-   environment, thus they should not be included in DNS. If local
-   mappings are used, they should be stored using static local tables,
-   exactly as local static host tables can be used with DNS.
-
-   The keyword of a 'table2' and 'gate2' table entry is a valid RFC822
-   domain; thus the usual domain name space can be used without problems
-   to store these entries.
-   On the other hand, the keyword of a 'table1' and 'gate1' entry
-   belongs to the X.400 O/R name space. The X.400 O/R name space does
-   not usually fit into the usual domain name space, although there are
-   a number of similarities; a new name structure is thus needed to
-   represent it. This new name structure contains the X.400 mail
-   domains.
-
-   To ensure the correct functioning of the DNS system, the new X.400
-   name structure must be hooked to the existing domain name space in a
-   way which respects the existing name hierarchy.
-
-   A possible solution was to create another special branch, starting
-   from the root of the DNS tree, somehow similar to the in-addr.arpa
-   tree. This idea would have required to establish a central authority
-
-
-
-Allocchio                   Standards Track                     [Page 5]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   to coordinate at international level the management of each national
-   X.400 name tree, including the X.400 public service providers. This
-   coordination problem is a heavy burden if approached globally. More
-   over the X.400 name structure is very 'country oriented': thus while
-   it requires a coordination at national level, it does not have
-   concepts like the international root. In fact the X.400 international
-   service is based  on a large number of bilateral agreements, and only
-   within some communities an international coordination service exists.
-
-   The X.400 two letter ISO country codes, however, are the same used
-   for the RFC822 country top-level domains and this gives us an
-   appropriate hook to insert the new branches. The proposal is, in
-   fact, to create under each national top level ISO country code a new
-   branch in the name space. This branch represents exactly the X.400
-   O/R name structure as defined in each single country, following the
-   ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed
-   under each country top-level domain, and hence the national X.400
-   name space derives its own structure:
-
-                                    . (root)
-                                    |
-      +-----------------+-----------+--------+-----------------+...
-      |                 |                    |                 |
-     edu                it                   us                fr
-      |                 |                    |                 |
-  +---+---+...    +-----+-----+...     +-----+-----+...     +--+---+...
-  |       |       |     |     |        |     |     |        |      |
- ...     ...     cnr   X42D  infn      va    ca   X42D     X42D  inria
-                        |                    |     |        |
-           +------------+------------+...   ...   ...  +----+-------+...
-           |            |            |                 |            |
-    ADMD-PtPostel  ADMD-garr  ADMD-Master400        ADMD-atlas  ADMD-red
-                        |            |                 |            |
-             +----------+----+...   ...        +-------+------+... ...
-             |               |                 |              |
-         PRMD-infn       PRMD-STET        PRMD-Telecom   PRMD-Renault
-             |               |                 |              |
-            ...             ...               ...            ...
-
-
-   The creation of the X.400 new name tree at national level solves the
-   problem of the international coordination. Actually the coordination
-   problem is just moved at national level, but it thus becomes easier
-   to solve. The coordination at national level between the X.400
-   communities and the Internet world is already a requirement for the
-   creation of the national static MIXER mapping tables; the use of the
-   Internet DNS gives further motivations for this coordination.
-
-
-
-
-Allocchio                   Standards Track                     [Page 6]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   The coordination at national level also fits in the new concept of
-   MCGAM pubblication. The DNS in fact allows a step by step authority
-   distribution, up to a final complete delegation: thus organizations
-   whishing to publish their MCGAM just need to receive delegation also
-   for their branch of the new X.400 name space. A further advantage of
-   the national based solution is to allow each country to set up its
-   own X.400 name structure in DNS and to deploy its own authority
-   delegation according to its local time scale and requirements, with
-   no loss of global service in the mean time. And last, placing the new
-   X.400 name tree and coordination process at national level fits into
-   the Internet regionalization and internationalisation process, as it
-   requires local bodies to take care of local coordination problems.
-
-   The DNS name space thus contains completely the information required
-   by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a
-   simple query to the nearest nameserver provides it. Moreover there is
-   no more any need to store, maintain and distribute manually any
-   mapping table. The new X.400 name space can also contain further
-   information about the X.400 community, as DNS allows for it a
-   complete set of resource records, and thus it allows further
-   developments. This set of RRs in the new X.400 name space must be
-   considered 'reserved' and thus not used until further specifications.
-
-   The construction of the new domain space trees will follow the same
-   procedures used when organising at first the already existing DNS
-   space: at first the information will be stored in a quite centralised
-   way, and distribution of authority will be gradually achieved. A
-   separate document will describe the implementation phase and the
-   methods to assure a smooth introduction of the new service.
-
-4. The new DNS resource record for MIXER mapping rules: PX
-
-   The specification of the Internet DNS (RFC1035) provides a number of
-   specific resource records (RRs) to contain specific pieces of
-   information. In particular they contain the Mail eXchanger (MX) RR
-   and the host Address (A) records which are used by the Internet SMTP
-   mailers. As we will store the RFC822 to X.400 mapping information in
-   the already existing DNS name tree, we need to define a new DNS RR in
-   order to avoid any possible clash or misuse of already existing data
-   structures. The same new RR will also be used to store the mappings
-   from X.400 to RFC822. More over the mapping information, i.e., the
-   MCGAMs, has a specific format and syntax which require an appropriate
-   data structure and processing. A further advantage of defining a new
-   RR is the ability to include flexibility for some eventual future
-   development.
-
-
-
-
-
-
-Allocchio                   Standards Track                     [Page 7]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   The definition of the new 'PX' DNS resource record is:
-
-      class:        IN   (Internet)
-
-      name:         PX   (pointer to X.400/RFC822 mapping information)
-
-      value:        26
-
-   The PX RDATA format is:
-
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          |                  PREFERENCE                   |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                    MAP822                     /
-          /                                               /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                    MAPX400                    /
-          /                                               /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-   PREFERENCE   A 16 bit integer which specifies the preference given to
-                this RR among others at the same owner.  Lower values
-                are preferred;
-
-   MAP822       A <domain-name> element containing <rfc822-domain>, the
-                RFC822 part of the MCGAM;
-
-   MAPX400      A <domain-name> element containing the value of
-                <x400-in-domain-syntax> derived from the X.400 part of
-                the MCGAM (see sect. 4.2);
-
-   PX records cause no additional section processing. The PX RR format
-   is the usual one:
-
-             <name> [<class>] [<TTL>] <type> <RDATA>
-
-   When we store in DNS a 'table1' or a 'gate1' entry, then <name> will
-   be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we
-   store a 'table2' or a 'gate2' table entry, <name> will be an RFC822
-   mail domain name, including both fully qualified DNS domains and mail
-   only domains (MX-only domains). All normal DNS conventions, like
-   default values, wildcards, abbreviations and message compression,
-   apply also for all the components of the PX RR. In particular <name>,
-   MAP822 and MAPX400, as <domain-name> elements, must have the final
-   "." (root) when they are fully qualified.
-
-
-
-
-Allocchio                   Standards Track                     [Page 8]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-4.1 Additional features of the PX resource record
-
-   The definition of the RDATA for the PX resource record, and the fact
-   that DNS allows a distinction between an exact value and a wildcard
-   match for the <name> parameter, represent an extension of the MIXER
-   specification for mapping rules. In fact, any MCGAM entry is an
-   implicit wildcard entry, i.e., the rule
-
-      net2.it#PRMD$net2.ADMD$p400.C$it#
-
-   covers any RFC822 domain ending with 'net2.it', unless more detailed
-   rules for some subdomain in 'net2.it' are present. Thus there is no
-   possibility to specify explicitly a MCGAM as an exact match only
-   rule. In DNS an entry like
-
-      *.net2.it.   IN  PX  10   net2.it.  PRMD-net2.ADMD-p400.C-it.
-
-   specify the usual wildcard match as for MIXER tables. However an
-   entry like
-
-      ab.net2.it.  IN  PX  10   ab.net2.it.  O-ab.PRMD-net2.ADMDb.C-it.
-
-   is valid only for an exact match of 'ab.net2.it' RFC822 domain.
-
-   Note also that in DNS syntax there is no '#' delimiter around MAP822
-   and MAPX400 fields: the syntax defined in sect. 4.2 in fact does not
-   allow the <blank> (ASCII decimal 32) character within these fields,
-   making unneeded the use of an explicit delimiter as required in the
-   MIXER original syntax.
-
-   Another extension to the MIXER specifications is the PREFERENCE value
-   defined as part of the PX RDATA section. This numeric value has
-   exactly the same meaning than the similar one used for the MX RR. It
-   is thus possible to specify more than one single mapping for a domain
-   (both from RFC822 to X.400 and vice versa), giving as the preference
-   order. In MIXER static tables, however, you cannot specify more than
-   one mapping per each RFC822 domain, and the same restriction apply
-   for any X.400 domain mapping to an RFC822 one.
-
-   More over, in the X.400 recommendations a note suggests than an
-   ADMD=<blank> should be reserved for some special cases. Various
-   national functional profile specifications for an X.400 MHS states
-   that if an X.400 PRMD is reachable via any of its national ADMDs,
-   independently of its actual single or multiple connectivity with
-   them, it should use ADMD=<blank> to advertise this fact. Again, if a
-   PRMD has no connections to any ADMD it should use ADMD=0 to notify
-   its status, etc. However, in most of the current real situations, the
-   ADMD service providers do not accept messages coming from their
-
-
-
-Allocchio                   Standards Track                     [Page 9]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   subscribers if they have a blank ADMD, forcing them to have their own
-   ADMD value. In such a situation there are problems in indicating
-   properly the actually working mappings for domains with multiple
-   connectivity. The PX RDATA 'PREFERENCE' extension was introduced to
-   take in consideration these problems.
-
-   However, as these extensions are not available with MIXER static
-   tables, it is strongly discouraged to use them when interworking with
-   any table based gateway or application. The extensions were in fact
-   introduced just to add more flexibility, like the PREFERENCE value,
-    or they were already implicit in the DNS mechanism, like the
-   wildcard specification. They should be used very carefully or just
-   considered 'reserved for future use'. In particular, for current use,
-   the PREFERENCE value in the PX record specification should be fixed
-   to a value of 50, and only wildcard specifications should be used
-   when specifying <name> values.
-
-4.2 The DNS syntax for an X.400 'domain'
-
-   The syntax definition of the MCGAM rules is defined in appendix F of
-   that document. However that syntax is not very human oriented and
-   contains a number of characters which have a special meaning in other
-   fields of the Internet DNS. Thus in order to avoid any possible
-   problem, especially due to some old DNS implementations still being
-   used in the Internet, we define a syntax for the X.400 part of any
-   MCGAM rules (and hence for any X.400 O/R name) which makes it
-   compatible with a <domain-name> element, i.e.,
-
-   <domain-name>    ::= <subdomain> | " "
-   <subdomain>      ::= <label> | <label> "." <subdomain>
-   <label>          ::= <alphanum>|
-                        <alphanum> {<alphanumhyphen>} <alphanum>
-   <alphanum>       ::= "0".."9" | "A".."Z" | "a".."z"
-   <alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"
-
-   (see RFC1035, section 2.3.1, page 8).  The legal character set for
-   <label> does not correspond to the IA5 Printablestring one used in
-   MIXER to define MCGAM rules. However a very simple "escape mechanism"
-   can be applied in order to bypass the problem. We can in fact simply
-   describe the X.400 part of a MCGAM rule format as:
-
-     <map-rule>   ::= <map-elem> | <map-elem> { "." <map-elem> }
-     <map-elem>   ::= <attr-label> "$" <attr-value>
-     <attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
-     <attr-value> ::= " " | "@" | IA5-Printablestring
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 10]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   As you can notice <domain-name> and <map-rule> look similar, and also
-   <label> and <map-elem> look the same. If we define the correct method
-   to transform a <map-elem> into a <label> and vice versa the problem
-   to write a MCGAM rule in <domain-name> syntax is solved.
-
-   The RFC822 domain part of any MCGAM rule is of course already in
-   <domain-name> syntax, and thus remains unchanged.
-
-   In particular, in a 'table1' or 'gate1' mapping rule the 'keyword'
-   value must be converted into <x400-in-domain-syntax> (X.400 mail DNS
-   mail domain), while the 'translator' value is already a valid RFC822
-   domain.  Vice versa in a 'table2' or 'gate2' mapping rule, the
-   'translator' must be converted into <x400-in-domain-syntax>, while
-   the 'keyword' is already a valid RFC822 domain.
-
-4.2.1 IA5-Printablestring to <alphanumhyphen> mappings
-
-   The problem of unmatching IA5-Printablestring and <label> character
-   set definition is solved by a simple character mapping rule: whenever
-   an IA5 character does not belong to <alphanumhyphen>, then it is
-   mapped using its 3 digit decimal ASCII code, enclosed in hyphens. A
-   small set of special rules is also defined for the most frequent
-   cases. Moreover some frequent characters combinations used in MIXER
-   rules are also mapped as special cases.
-
-   Let's then define the following simple rules:
-
-    MCGAM rule            DNS store translation    conditions
-    -----------------------------------------------------------------
-    <attr-label>$@        <attr-label>             missing attribute
-    <attr-label>$<blank>  <attr-label>"b"          blank attribute
-    <attr-label>$xxx      <attr-label>-xxx         elsewhere
-
-   Non <alphanumhyphen> characters in <attr-value>:
-
-    MCGAM rule            DNS store translation    conditions
-    -----------------------------------------------------------------
-    -                     -h-                      hyphen
-    \.                    -d-                      quoted dot
-    <blank>               -b-                      blank
-    <non A/N character>   -<3digit-decimal>-       elsewhere
-
-   If the DNS store translation of <attr-value> happens to end with an
-   hyphen, then this last hyphen is omitted.
-
-   Let's now have some examples:
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 11]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-    MCGAM rule            DNS store translation    conditions
-    -----------------------------------------------------------------
-    PRMD$@                PRMD                     missing attribute
-    ADMD$<blank>          ADMDb                    blank attribute
-    ADMD$400-net          ADMD-400-h-net           hyphen mapping
-    PRMD$UK\.BD           PRMD-UK-d-BD             quoted dot mapping
-    O$ACME Inc\.          O-ACME-b-Inc-d           blank & final hyphen
-    PRMD$main-400-a       PRMD-main-h-400-h-a      hyphen mapping
-    O$-123-b              O--h-123-h-b             hyphen mapping
-    OU$123-x              OU-123-h-x               hyphen mapping
-    PRMD$Adis+co          PRMD-Adis-043-co         3digit mapping
-
-   Thus, an X.400 part from a MCGAM like
-
-     OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$cc
-
-   translates to
-
-     OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-cc
-
-   Another example:
-
-     OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GB
-
-   translates to
-
-     OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB
-
-4.2.2 Flow chart
-
-   In order to achieve the proper DNS store translations of the X.400
-   part of a MCGAM or any other X.400 O/R name, some software tools will
-   be used. It is in fact evident that the above rules for converting
-   mapping table from MIXER to DNS format (and vice versa) are not user
-   friendly enough to think of a human made conversion.
-
-   To help in designing such tools, we describe hereunder a small flow
-   chart. The fundamental rule to be applied during translation is,
-   however, the following:
-
-      "A string must be parsed from left to right, moving appropriately
-      the pointer in order not to consider again the already translated
-      left section of the string in subsequent analysis."
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 12]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   Flow chart 1 - Translation from MIXER to DNS format:
-
-                 parse  single attribute
-              (enclosed in "." separators)
-                           |
-            (yes)  ---  <label>$@ ?  ---  (no)
-              |                             |
-        map to <label>        (no)  <label>$<blank> ?  (yes)
-              |                 |                        |
-              |           map to <label>-        map to <label>"b"
-              |                 |                        |
-              |           map "\." to -d-                |
-              |                 |                        |
-              |           map "-" to -h-                 |
-              |                 |                        |
-              |    map non A/N char to -<3digit>-        |
-  restart     |                 |                        |
-     ^        |      remove (if any) last "-"            |
-     |        |                 |                        |
-     |        \------->     add a  "."    <--------------/
-     |                          |
-     \----------  take  next  attribute  (if  any)
-
-
-   Flow chart 2 - Translation from DNS to MIXER format:
-
-
-                parse single attribute
-            (enclosed in "." separators)
-                          |
-            (yes) ---- <label> ? ---- (no)
-              |                          |
-      map to <label>$@        (no) <label>"b" ? (yes)
-              |                 |                 |
-              |           map to <label>$    map to <label>$<blank>
-              |                 |                 |
-              |           map -d- to "\."         |
-              |                 |                 |
-              |           map -h- to "-"          |
-              |                 |                 |
-              |           map -b- to " "          |
-  restart     |                 |                 |
-     ^        |   map -<3digit>- to non A/N char  |
-     |        |                 |                 |
-     |        \-------->   add a "."   <----------/
-     |                         |
-     \------------- take next attribute (if any)
-
-
-
-
-Allocchio                   Standards Track                    [Page 13]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   Note that the above flow charts deal with the translation of the
-   attributes syntax, only.
-
-4.2.3 The Country Code convention in the <name> value.
-
-   The RFC822 domain space and the X.400 O/R address space, as said in
-   section 3, have one specific common feature: the X.400 ISO country
-   codes are the same as the RFC822 ISO top level domains for countries.
-   In the previous sections we have also defined a method to write in
-   <domain-name> syntax any X.400 domain, while in section 3 we
-   described the new name space starting at each country top level
-   domain under the X42D.cc (where 'cc' is then two letter ISO country
-   code).
-
-   The <name> value for a 'table1' or 'gate1' entry in DNS should thus
-   be derived from the X.400 domain value, translated to <domain-name>
-   syntax, adding the 'X42D.cc.' post-fix to it, i.e.,
-
-     ADMD$acme.C$fr
-
-   produces in <domain-name> syntax the key:
-
-     ADMD-acme.C-fr
-
-   which is post-fixed by 'X42D.fr.' resulting in:
-
-     ADMD-acme.C-fr.X42D.fr.
-
-   However, due to the identical encoding for X.400 country codes and
-   RFC822 country top level domains, the string 'C-fr.X42D.fr.' is
-   clearly redundant.
-
-   We thus define the 'Country Code convention' for the <name> key,
-   i.e.,
-
-     "The C-cc section of an X.400 domain in <domain-name> syntax must
-     be omitted when creating a <name> key, as it is identical to the
-     top level country code used to identify the DNS zone where the
-     information is stored".
-
-   Thus we obtain the following <name> key examples:
-
-   X.400 domain                       DNS <name> key
-   --------------------------------------------------------------------
-   ADMD$acme.C$fr                     ADMD-acme.X42D.fr.
-   PRMD$ux\.av.ADMD$ .C$gb            PRMD-ux-d-av.ADMDb.X42D.gb.
-   PRMD$ppb.ADMD$Dat 400.C$de         PRMD-ppb.ADMD-Dat-b-400.X42D.de.
-
-
-
-
-Allocchio                   Standards Track                    [Page 14]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-4.3 Creating the appropriate DNS files
-
-   Using MIXER's assumption of an asymmetric mapping between X.400 and
-   RFC822 addresses, two separate relations are required to store the
-   mapping database: MIXER 'table1' and MIXER 'table2'; thus also in DNS
-   we will maintain the two different sections, even if they will both
-   use the PX resource record. More over MIXER also specify two
-   additional tables: MIXER 'gate1' and 'gate2' tables. These additional
-   tables, however, have the same syntax rules than MIXER 'table1' and
-   'table2' respectively, and thus the same translation procedure as
-   'table1' and 'table2' will be applied; some details about the MIXER
-   'gate1' and 'gate2' tables are discussed in section 4.4.
-
-   Let's now check how to create, from an MCGAM entry, the appropriate
-   DNS entry in a DNS data file. We can again define an MCGAM entry as
-   defined in appendix F of that document as:
-
-     <x400-domain>#<rfc822-domain>#  (case A: 'table1' and 'gate1'
-     entry)
-
-   and
-
-     <rfc822-domain>#<x400-domain>#  (case B: 'table2' and 'gate2'
-     entry)
-
-   The two cases must be considered separately. Let's consider case A.
-
-    - take <x400-domain> and translate it into <domain-name> syntax,
-     obtaining <x400-in-domain-syntax>;
-    - create the <name> key from <x400-in-domain-syntax> i.e., apply
-     the Country Code convention described in sect. 4.2.3;
-    - construct the DNS PX record as:
-
-      *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>
-
-   Please note that within PX RDATA the <rfc822-domain> precedes the
-   <x400-in-domain-syntax> also for a 'table1' and 'gate1' entry.
-
-   an example: from the 'table1' rule
-
-     PRMD$ab.ADMD$ac.C$fr#ab.fr#
-
-   we obtain
-
-     *.PRMD-ab.ADMD-ac.X42D.fr. IN PX 50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.
-
-   Note that <name>, <rfc822-domain> and <x400-in-domain-syntax> are
-   fully qualified <domain-name> elements, thus ending with a ".".
-
-
-
-Allocchio                   Standards Track                    [Page 15]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   Let's now consider case B.
-
-    - take <rfc822-domain> as <name> key;
-    - translate <x400-domain> into <x400-in-domain-syntax>;
-    - construct the DNS PX record as:
-
-     *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>
-
-   an example: from the 'table2' rule
-
-     ab.fr#PRMD$ab.ADMD$ac.C$fr#
-
-   we obtain
-
-     *.ab.fr.  IN  PX  50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.
-
-   Again note the fully qualified <domain-name> elements.
-
-   A file containing the MIXER mapping rules and MIXER 'gate1' and
-   'gate2' table written in DNS format will look like the following
-   fictious example:
-
-     !
-     ! MIXER table 1: X.400 --> RFC822
-     !
-     *.ADMD-acme.X42D.it.               IN  PX  50  it. ADMD-acme.C-it.
-     *.PRMD-accred.ADMD-tx400.X42D.it.  IN  PX  50   \
-                                accred.it. PRMD-accred.ADMD-tx400.C-it.
-     *.O-u-h-newcity.PRMD-x4net.ADMDb.X42D.it.  IN  PX  50   \
-                       cs.ncty.it. O-u-h-newcity.PRMD-x4net.ADMDb.C-it.
-     !
-     ! MIXER table 2: RFC822 --> X.400
-     !
-     *.nrc.it.    IN  PX  50   nrc.it. PRMD-nrc.ADMD-acme.C-it.
-     *.ninp.it.   IN  PX  50   ninp.it. O.PRMD-ninp.ADMD-acme.C-it.
-     *.bd.it.     IN  PX  50   bd.it. PRMD-uk-d-bd.ADMDb.C-it.
-     !
-     ! MIXER Gate 1 Table
-     !
-     *.ADMD-XKW-h-Mail.X42D.it.         IN  PX  50   \
-                            XKW-gateway.it. ADMD-XKW-h-Mail.C-it.G.
-     *.PRMD-Super-b-Inc.ADMDb.X42D.it.  IN  PX  50   \
-                            GlobalGw.it. PRMD-Super-b-Inc.ADMDb.C-it.G.
-     !
-     ! MIXER Gate 2 Table
-     !
-     my.it.  IN PX 50  my.it. OU-int-h-gw.O.PRMD-ninp.ADMD-acme.C-it.G.
-     co.it.  IN PX 50  co.it. O-mhs-h-relay.PRMD-x4net.ADMDb.C-it.G.
-
-
-
-Allocchio                   Standards Track                    [Page 16]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   (here the "\" indicates continuation on the same line, as wrapping is
-   done only due to typographical reasons).
-
-   Note the special suffix ".G." on the right side of the 'gate1' and
-   'gate2' Tables section whose aim is described in section 4.4. The
-   corresponding MIXER tables are:
-
-     #
-     # MIXER table 1: X.400 --> RFC822
-     #
-     ADMD$acme.C$it#it#
-     PRMD$accred.ADMD$tx400.C$it#accred.it#
-     O$u-newcity.PRMD$x4net.ADMD$ .C$it#cs.ncty.it#
-     #
-     # MIXER table 2: RFC822 --> X.400
-     #
-     nrc.it#PRMD$nrc.ADMD$acme.C$it#
-     ninp.it#O.PRMD$ninp.ADMD$acme.C$it#
-     bd.it#PRMD$uk\.bd.ADMD$ .C$it#
-     #
-     # MIXER Gate 1 Table
-     #
-     ADMD$XKW-Mail.C$it#XKW-gateway.it#
-     PRMD$Super Inc.ADMD$ .C$it#GlobalGw.it#
-     #
-     # MIXER Gate 2 Table
-     #
-     my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it#
-     co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t#
-
-4.4 Storing the MIXER 'gate1' and 'gate2' tables
-
-   Section 4.3.4 of MIXER also specify how an address should be
-   converted between RFC822 and X.400 in case a complete mapping is
-   impossible. To allow the use of DDAs for non mappable domains, the
-   MIXER 'gate2' table is thus introduced.
-
-   In a totally similar way, when an X.400 address cannot be completely
-   converted in RFC822, section 4.3.5 of MIXER specifies how to encode
-   (LHS encoding) the address itself, pointing then to the appropriate
-   MIXER conformant gateway, indicated in the MIXER 'gate1' table.
-
-   DNS must store and distribute also these 'gate1' and 'gate2' data.
-
-   One of the major features of the DNS is the ability to distribute the
-   authority: a certain site runs the "primary" nameserver for one
-   determined sub-tree and thus it is also the only place allowed to
-   update information regarding that sub-tree. This fact allows, in our
-
-
-
-Allocchio                   Standards Track                    [Page 17]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   case, a further additional feature to the table based approach. In
-   fact we can avoid one possible ambiguity about the use of the 'gate1'
-   and 'gate2' tables (and thus of LHS and DDAs encoding).
-
-   The authority maintaining a DNS entry in the usual RFC822 domain
-   space is the only one allowed to decide if its domain should be
-   mapped using Standard Attributes (SA) syntax or Domain Defined
-   Attributes (DDA) one. If the authority decides that its RFC822 domain
-   should be mapped using SA, then the PX RDATA will be a 'table2'
-   entry, otherwise it will be a 'gate2' table entry. Thus for an RFC822
-   domain we cannot have any more two possible entries, one from 'table2
-   and another one from 'gate2' table, and the action for a gateway
-   results clearly stated.
-
-   Similarly, the authority mantaining a DNS entry in the new X.400 name
-   space is the only one allowed to decide if its X.400 domain should be
-   mapped using SA syntax or Left Hand Side (LHS) encoding. If the
-   authority decides that its X.400 domain should be mapped using SA,
-   then the PX RDATA will be a 'table1' entry, otherwise it will be a
-   'gate1' table entry. Thus also for an X.400 domain we cannot have any
-   more two possible entries, one from 'table1' and another one from
-   'gate1' table, and the action for a gateway results clearly stated.
-
-   The MIXER 'gate1' table syntax is actually identical to MIXER
-   'table1', and 'gate2' table syntax is identical to MIXER 'table2'.
-   Thus the same syntax translation rules from MIXER to DNS format can
-   be applied in both cases. However a gateway or any other application
-   must know if the answer it got from DNS contains some 'table1',
-   'table2' or some 'gate1', 'gate2' table information. This is easily
-   obtained flagging with an additional ".G." post-fix the PX RDATA
-   value when it contains a 'gate1' or 'gate2' table entry. The example
-   in section 4.3 shows clearly the result. As any X.400 O/R domain must
-   end with a country code ("C-xx" in our DNS syntax) the additional
-   ".G." creates no conflicts or ambiguities at all. This postfix must
-   obviously be removed before using the MIXER 'gate1' or 'gate2' table
-   data.
-
-5. Finding MIXER mapping information from DNS
-
-   The MIXER mapping information is stored in DNS both in the normal
-   RFC822 domain name space, and in the newly defined X.400 name space.
-   The information, stored in PX resource records, does not represent a
-   full RFC822 or X.400 O/R address: it is a template which specifies
-   the fields of the domain that are used by the mapping algorithm.
-
-   When mapping information is stored in the DNS, queries to the DNS are
-   issued whenever an iterative search through the mapping table would
-   be performed (MIXER: section 4.3.4, State I; section 4.3.5, mapping
-
-
-
-Allocchio                   Standards Track                    [Page 18]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   B). Due to the DNS search mechanism, DNS by itself returns the
-   longest possible match in the stored mapping rule with a single
-   query, thus no iteration and/or multiple queries are needed. As
-   specified in MIXER, a search of the mapping table will result in
-   either success (mapping found) or failure (query failed, mapping not
-   found).
-
-   When a DNS query is issued, a third possible result is timeout. If
-   the result is timeout, the gateway operation is delayed and then
-   retried at a later time. A result of success or failure is processed
-   according to the algorithms specified in MIXER. If a DNS error code
-   is returned, an error message should be logged and the gateway
-   operation is delayed as for timeout. These pathological situations,
-   however, should be avoided with a careful duplication and chaching
-   mechanism which DNS itself provides.
-
-   Searching the nameserver which can authoritatively solve the query is
-   automatically performed by the DNS distributed name service.
-
-5.1 A DNS query example
-
-   An MIXER mail-gateway located in the Internet, when translating
-   addresses from RFC822 to X.400, can get information about the MCGAM
-   rule asking the DNS. As an example, when translating the address
-   SUN.CCE.NRC.IT, the gateway will just query DNS for the associated PX
-   resource record. The DNS should contain a PX record like this:
-
-   *.cce.nrc.it.  IN PX 50   cce.nrc.it.  O-cce.PRMD-nrc.ADMD-acme.C-it.
-
-   The first query will return immediately the appropriate mapping rule
-   in DNS store format.
-
-   There is no ".G." at the end of the obtained PX RDATA value, thus
-   applying the syntax translation specified in paragraph 4.2 the MIXER
-   Table 2 mapping rule will be obtained.
-
-   Let's now take another example where a 'gate2' table rule is
-   returned.  If we are looking for an RFC822 domain ending with top
-   level domain "MW", and the DNS contains a PX record like this,
-
-      *.mw.   IN  PX  50  mw.  O-cce.PRMD-nrc.ADMD-acme.C-it.G.
-
-   DNS will return 'mw.' and 'O-cce.PRMD-nrc.ADMD-acme.C-it.G.', i.e., a
-   'gate2' table entry in DNS store format. Dropping the final ".G." and
-   applying the syntax translation specified in paragraph 4.2 the
-   original rule will be available. More over, the ".G." flag also tells
-   the gateway to use DDA encoding for the inquired RFC822 domain.
-
-
-
-
-Allocchio                   Standards Track                    [Page 19]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   On the other hand, translating from X.400 to RFC822 the address
-
-      C=de; ADMD=pkz; PRMD=nfc; O=top;
-
-   the mail gateway should convert the syntax according to paragraph
-   4.2, apply the 'Country code convention' described in 4.2.3 to derive
-   the appropriate DNS translation of the X.400 O/R name and then query
-   DNS for the corresponding PX resource record. The obtained record for
-   which the PX record must be queried is thus:
-
-      O-top.PRMD-nfc.ADMD-pkz.X42D.de.
-
-   The DNS could contain:
-
-      *.ADMD-pkz.X42D.de.  IN  PX  50  pkz.de.  ADMD-pkz.C-de.
-
-   Assuming that there are not more specific records in DNS, the
-   wildcard mechanism will return the MIXER 'table1' rule in encoded
-   format.
-
-   Finally, an example where a 'gate1' rule is involved. If we are
-   looking for an X.400 domain ending with ADMD=PWT400; C=US; , and the
-   DNS contains a PX record like this,
-
-      *.ADMD-PWT400.X42D.us.  IN  PX  50  intGw.com. ADMD-PWT400.C-us.G.
-
-   DNS will return 'intGw.com.' and 'ADMD-PWT400.C-us.G.', i.e., a
-   'gate1' table entry in DNS store format. Dropping the final ".G." and
-   applying the syntax translation specified in paragraph 4.2 the
-   original rule will be available. More over, the ".G." flag also tells
-   the gateway to use LHS encoding for the inquired X.400 domain.
-
-6. Administration of mapping information
-
-   The DNS, using the PX RR, is able to distribute the MCGAM rules to
-   all MIXER gateways located on the Internet. However, not all MIXER
-   gateways will be able to use the Internet DNS. It is expected that
-   some gateways in a particular management domain will conform to one
-   of the following models:
-
-     (a) Table-based, (b) DNS-based, (c) X.500-based
-
-   Table-based management domains will continue to publish their MCGAM
-   rules and retrieve the mapping tables via the International Mapping
-   Table coordinator, manually or via some automated procedures. Their
-   MCGAM information can be made available also in DNS by the
-   appropriate DNS authorities, using the same mechanism already in
-   place for MX records: if a branch has not yet in place its own DNS
-
-
-
-Allocchio                   Standards Track                    [Page 20]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   server, some higher authority in the DNS tree will provide the
-   service for it. A transition procedure similar to the one used to
-   migrate from the 'hosts.txt' tables to DNS can be applied also to the
-   deployment phase of this specification. An informational document
-   describing the implementation phase and the detailed coordination
-   procedures is expected.
-
-   Another distributed directory service which can distribute the MCGAM
-   information is X.500. Coordination with table-based domains can be
-   obtained in an identical way as for the DNS case.
-
-   Coordination of MCGAM information between DNS and X.500 is more
-   complex, as it requies some kind of uploading information between the
-   two systems. The ideal solution is a dynamic alignment mechanism
-   which transparently makes the DNS mapping information available in
-   X.500 and vice versa. Some work in this specific field is already
-   being done [see Costa] which can result in a global transparent
-   directory service, where the information is stored in DNS or in
-   X.500, but is visible completely by any of the two systems.
-
-   However we must remind that MIXER concept of MCGAM rules publication
-   is different from the old RFC1327 concept of globally distributed,
-   coordinated and unique mapping rules. In fact MIXER does not requires
-   any more for any conformant gateway or tool to know the complete set
-   of MCGAM: it only requires to use some set (eventually empty) of
-   valid MCGAM rules, published either by Tables, DNS or X.500
-   mechanisms or any combination of these methods. More over MIXER
-   specifies that also incomplete sets of MCGAM can be used, and
-   supplementary local unpublished (but valid) MCGAM can also be used.
-   As a consequence, the problem of coordination between the three
-   systems proposed by MIXER for MCGAM publication is non essential, and
-   important only for efficient operational matters. It does not in fact
-   affect the correct behaviour of MIXER conformant gateways and tools.
-
-7. Conclusion
-
-   The introduction of the new PX resource record and the definition of
-   the X.400 O/R name space in the DNS structure provide a good
-   repository for MCGAM information. The mapping information is stored
-   in the DNS tree structure so that it can be easily obtained using the
-   DNS distributed name service. At the same time the definition of the
-   appropriate DNS space for X.400 O/R names provide a repository where
-   to store and distribute some other X.400 MHS information. The use of
-   the DNS has many known advantages in storing, managing and updating
-   the information. A successful number of tests were been performed
-   under the provisional top level domain "X400.IT" when RFC1664 was
-   developed, and their results confirmed the advantages of the method.
-   Operational exeprience for over 2 years with RFC1664 specification
-
-
-
-Allocchio                   Standards Track                    [Page 21]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   confirmed the feasibility of the method, and helped identifying some
-   operational procedures to deploy the insertion of MCGAM into DNS.
-
-   Software to query the DNS and then to convert between the textual
-   representation of DNS resource records and the address format defined
-   in MIXER was developed with RFC1664. This software also allows a
-   smooth implementation and deployment period, eventually taking care
-   of the transition phase. This software can be easily used (with
-   little or null modification) also for this updated specification,
-   supporting the new 'gate1' MIXER table. DNS software implementations
-   supporting RFC1664 also supports with no modification this memo new
-   specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 22]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   A further informational document describing operational and
-   implementation of the service is expected.
-
-8. Acknowledgements
-
-   We wish to thanks all those who contributed to the discussion and
-   revision of this document: many of their ideas and suggestions
-   constitute essential parts of this work. In particular thanks to Jon
-   Postel, Paul Mockapetris, Rob Austin and the whole IETF x400ops,
-   TERENA wg-msg and IETF namedroppers groups. A special mention to
-   Christian Huitema for his fundamental contribution to this work.
-
-   This document is a revision of RFC1664, edited by one of its authors
-   on behalf of the IETF MIXER working group. The current editor wishes
-   to thank here also the authors of RFC1664:
-
-     Antonio Blasco Bonito     RFC822: bonito@cnuce.cnr.it
-     CNUCE - CNR               X.400:  C=it;A=garr;P=cnr;
-     Reparto infr. reti                O=cnuce;S=bonito;
-     Viale S. Maria 36
-     I 56126 Pisa
-     Italy
-
-
-     Bruce Cole                RFC822: bcole@cisco.com
-     Cisco Systems Inc.        X.400:  C=us;A= ;P=Internet;
-     P.O. Box 3075                     DD.rfc-822=bcole(a)cisco.com;
-     1525 O'Brien Drive
-     Menlo Park, CA 94026
-     U.S.A.
-
-
-     Silvia Giordano           RFC822: giordano@cscs.ch
-     Centro Svizzero di        X.400:  C=ch;A=arcom;P=switch;O=cscs;
-     Calcolo Scientifico               S=giordano;
-     Via Cantonale
-     CH 6928 Manno
-     Switzerland
-
-
-     Robert Hagens                   RFC822: hagens@ans.net
-     Advanced Network and Services   X.400:  C=us;A= ;P=Internet;
-     1875 Campus Commons Drive               DD.rfc-822=hagens(a)ans.net;
-     Reston, VA 22091
-     U.S.A.
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 23]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-9. References
-
-   [CCITT] CCITT SG 5/VII, "Recommendation X.400, Message Handling
-       Systems: System Model - Service Elements", October 1988.
-
-   [RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC
-       822", RFC 1327, March 1992.
-
-   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-       STD 13, RFC 1034, USC/Information Sciences Institute, November
-       1987.
-
-   [RFC 1035] Mockapetris, P., "Domain names - Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-   [RFC 1033] Lottor, M., "Domain Administrators Operation Guide", RFC
-       1033, SRI International, November 1987.
-
-   [RFC 2156] Kille, S. E., " MIXER (Mime Internet X.400 Enhanced
-       Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156,
-       January 1998.
-
-   [Costa] Costa, A., Macedo, J., and V. Freitas, "Accessing and
-       Managing DNS Information in the X.500 Directory", Proceeding of
-       the 4th Joint European Networking Conference, Trondheim, NO, May
-       1993.
-
-10. Security Considerations
-
-   This document specifies a means by which DNS "PX" records can direct
-   the translation between X.400 and Internet mail addresses.
-
-   This can indirectly affect the routing of mail across an gateway
-   between X.400 and Internet Mail.  A succesful attack on this service
-   could cause incorrect translation of an originator address (thus
-   "forging" the originator address), or incorrect translation of a
-   recipient address (thus directing the mail to an unauthorized
-   recipient, or making it appear to an authorized recipient, that the
-   message was intended for recipients other than those chosen by the
-   originator) or could force the mail path via some particular gateway
-   or message transfer agent where mail security can be affected by
-   compromised software.
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 24]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   There are several means by which an attacker might be able to deliver
-   incorrect PX records to a client.  These include: (a) compromise of a
-   DNS server,  (b) generating a counterfeit response to a client's DNS
-   query, (c) returning incorrect "additional information" in response
-   to an unrelated query.
-
-   Clients using PX records SHOULD ensure that routing and address
-   translations are based only on authoritative answers.  Once DNS
-   Security mechanisms [RFC 2065] become more widely deployed, clients
-   SHOULD employ those mechanisms to verify the authenticity and
-   integrity of PX records.
-
-11. Author's Address
-
-   Claudio Allocchio
-   Sincrotrone Trieste
-   SS 14 Km 163.5 Basovizza
-   I 34012 Trieste
-   Italy
-
-   RFC822: Claudio.Allocchio@elettra.trieste.it
-   X.400:  C=it;A=garr;P=Trieste;O=Elettra;
-   S=Allocchio;G=Claudio;
-   Phone:  +39 40 3758523
-   Fax:    +39 40 3758565
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 25]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-12.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 26]
-
diff --git a/doc/rfc/rfc2168.txt b/doc/rfc/rfc2168.txt
deleted file mode 100644
index 3eed1bdb..00000000
--- a/doc/rfc/rfc2168.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       R. Daniel
-Request for Comments: 2168             Los Alamos National Laboratory
-Category: Experimental                                    M. Mealling
-                                              Network Solutions, Inc.
-                                                            June 1997
-
-
-               Resolution of Uniform Resource Identifiers
-                      using the Domain Name System
-
-Status of this Memo
-===================
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  This memo does not specify an Internet standard of any
-   kind.  Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Abstract:
-=========
-
-   Uniform Resource Locators (URLs) are the foundation of the World Wide
-   Web, and are a vital Internet technology. However, they have proven
-   to be brittle in practice. The basic problem is that URLs typically
-   identify a particular path to a file on a particular host. There is
-   no graceful way of changing the path or host once the URL has been
-   assigned. Neither is there a graceful way of replicating the resource
-   located by the URL to achieve better network utilization and/or fault
-   tolerance. Uniform Resource Names (URNs) have been hypothesized as a
-   adjunct to URLs that would overcome such problems. URNs and URLs are
-   both instances of a broader class of identifiers known as Uniform
-   Resource Identifiers (URIs).
-
-   The requirements document for URN resolution systems[15] defines the
-   concept of a "resolver discovery service". This document describes
-   the first, experimental, RDS. It is implemented by a new DNS Resource
-   Record, NAPTR (Naming Authority PoinTeR), that provides rules for
-   mapping parts of URIs to domain names.  By changing the mapping
-   rules, we can change the host that is contacted to resolve a URI.
-   This will allow a more graceful handling of URLs over long time
-   periods, and forms the foundation for a new proposal for Uniform
-   Resource Names.
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 1]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   In addition to locating resolvers, the NAPTR provides for other
-   naming systems to be grandfathered into the URN world, provides
-   independence between the name assignment system and the resolution
-   protocol system, and allows multiple services (Name to Location, Name
-   to Description, Name to Resource, ...) to be offered.  In conjunction
-   with the SRV RR, the NAPTR record allows those services to be
-   replicated for the purposes of fault tolerance and load balancing.
-
-Introduction:
-=============
-
-   Uniform Resource Locators have been a significant advance in
-   retrieving Internet-accessible resources. However, their  brittle
-   nature over time has been recognized for several years. The Uniform
-   Resource Identifier working group proposed the development of Uniform
-   Resource Names to serve as persistent, location-independent
-   identifiers for Internet resources in order to overcome most of the
-   problems with URLs. RFC-1737 [1] sets forth requirements on URNs.
-
-   During the lifetime of the URI-WG, a number of URN proposals were
-   generated. The developers of several of those proposals met in a
-   series of meetings, resulting in a compromise known as the Knoxville
-   framework.  The major principle behind the Knoxville framework is
-   that the resolution system must be separate from the way names are
-   assigned. This is in marked contrast to most URLs, which identify the
-   host to contact and the protocol to use. Readers are referred to [2]
-   for background on the Knoxville framework and for additional
-   information on the context and purpose of this proposal.
-
-   Separating the way names are resolved from the way they are
-   constructed provides several benefits. It allows multiple naming
-   approaches and resolution approaches to compete, as it allows
-   different protocols and resolvers to be used. There is just one
-   problem with such a separation - how do we resolve a name when it
-   can't give us directions to its resolver?
-
-   For the short term, DNS is the obvious candidate for the resolution
-   framework, since it is widely deployed and understood. However, it is
-   not appropriate to use DNS to maintain information on a per-resource
-   basis. First of all, DNS was never intended to handle that many
-   records. Second, the limited record size is inappropriate for catalog
-   information. Third, domain names are not appropriate as URNs.
-
-   Therefore our approach is to use DNS to locate "resolvers" that can
-   provide information on individual resources, potentially including
-   the resource itself. To accomplish this, we "rewrite" the URI into a
-   domain name following the rules provided in NAPTR records. Rewrite
-   rules provide considerable power, which is important when trying to
-
-
-
-Daniel & Mealling             Experimental                      [Page 2]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   meet the goals listed above. However, collections of rules can become
-   difficult to understand. To lessen this problem, the NAPTR rules are
-   *always* applied to the original URI, *never* to the output of
-   previous rules.
-
-   Locating a resolver through the rewrite procedure may take multiple
-   steps, but the beginning is always the same. The start of the URI is
-   scanned to extract its colon-delimited prefix. (For URNs, the prefix
-   is always "urn:" and we extract the following colon-delimited
-   namespace identifier [3]). NAPTR resolution begins by taking the
-   extracted string, appending the well-known suffix ".urn.net", and
-   querying the DNS for NAPTR records at that domain name.  Based on the
-   results of this query, zero or more additional DNS queries may be
-   needed to locate resolvers for the URI. The details of the
-   conversation between the client and the resolver thus located are
-   outside the bounds of this draft. Three brief examples of this
-   procedure are given in the next section.
-
-   The NAPTR RR provides the level of indirection needed to keep the
-   naming system independent of the resolution system, its protocols,
-   and services.  Coupled with the new SRV resource record proposal[4]
-   there is also the potential for replicating the resolver on multiple
-   hosts, overcoming some of the most significant problems of URLs. This
-   is an important and subtle point. Not only do the NAPTR and SRV
-   records allow us to replicate the resource, we can replicate the
-   resolvers that know about the replicated resource. Preventing a
-   single point of failure at the resolver level is a significant
-   benefit. Separating the resolution procedure from the way names are
-   constructed has additional benefits.  Different resolution procedures
-   can be used over time, and resolution procedures that are determined
-   to be useful can be extended to deal with additional namespaces.
-
-Caveats
-=======
-
-   The NAPTR proposal is the first resolution procedure to be considered
-   by the URN-WG. There are several concerns about the proposal which
-   have motivated the group to recommend it for publication as an
-   Experimental rather than a standards-track RFC.
-
-   First, URN resolution is new to the IETF and we wish to gain
-   operational experience before recommending any procedure for the
-   standards track. Second, the NAPTR proposal is based on DNS and
-   consequently inherits concerns about security and administration. The
-   recent advancement of the DNSSEC and secure update drafts to Proposed
-   Standard reduce these concerns, but we wish to experiment with those
-   new capabilities in the context of URN administration.  A third area
-   of concern is the potential for a noticeable impact on the DNS.  We
-
-
-
-Daniel & Mealling             Experimental                      [Page 3]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   believe that the proposal makes appropriate use of caching and
-   additional information, but it is best to go slow where the potential
-   for impact on a core system like the DNS is concerned. Fourth, the
-   rewrite rules in the NAPTR proposal are based on regular expressions.
-   Since regular expressions are difficult for humans to construct
-   correctly, concerns exist about the usability and maintainability of
-   the rules. This is especially true where international character sets
-   are concerned. Finally, the URN-WG is developing a requirements
-   document for URN Resolution Services[15], but that document is not
-   complete. That document needs to precede any resolution service
-   proposals on the standards track.
-
-Terminology
-===========
-
-   "Must" or "Shall" - Software that does not behave in the manner that
-              this document says it must is not conformant to this
-              document.
-   "Should" - Software that does not follow the behavior that this
-              document says it should may still be conformant, but is
-              probably broken in some fundamental way.
-   "May" -    Implementations may or may not provide the described
-              behavior, while still remaining conformant to this
-              document.
-
-Brief overview and examples of the NAPTR RR:
-============================================
-
-   A detailed description of the NAPTR RR will be given later, but to
-   give a flavor for the proposal we first give a simple description of
-   the record and three examples of its use.
-
-   The key fields in the NAPTR RR are order, preference, service, flags,
-   regexp, and replacement:
-
-   * The order field specifies the order in which records MUST be
-     processed when multiple NAPTR records are returned in response to a
-     single query.  A naming authority may have delegated a portion of
-     its namespace to another agency. Evaluating the NAPTR records in
-     the correct order is necessary for delegation to work properly.
-
-   * The preference field specifies the order in which records SHOULD be
-     processed when multiple NAPTR records have the same value of
-     "order".  This field lets a service provider specify the order in
-     which resolvers are contacted, so that more capable machines are
-     contacted in preference to less capable ones.
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 4]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   * The service field specifies the resolution protocol and resolution
-     service(s) that will be available if the rewrite specified by the
-     regexp or replacement fields is applied. Resolution protocols are
-     the protocols used to talk with a resolver. They will be specified
-     in other documents, such as [5]. Resolution services are operations
-     such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC),
-     etc.  These will be discussed in the URN Resolution Services
-     document[6], and their behavior in a particular resolution protocol
-     will be given in the specification for that protocol (see [5] for a
-     concrete example).
-
-   * The flags field contains modifiers that affect what happens in the
-     next DNS lookup, typically for optimizing the process. Flags may
-     also affect the interpretation of the other fields in the record,
-     therefore, clients MUST skip NAPTR records which contain an unknown
-     flag value.
-
-   * The regexp field is one of two fields used for the rewrite rules,
-     and is the core concept of the NAPTR record. The regexp field is a
-     String containing a sed-like substitution expression. (The actual
-     grammar for the substitution expressions is given later in this
-     draft). The substitution expression is applied to the original URN
-     to determine the next domain name to be queried. The regexp field
-     should be used when the domain name to be generated is conditional
-     on information in the URI. If the next domain name is always known,
-     which is anticipated to be a common occurrence, the replacement
-     field should be used instead.
-
-   * The replacement field is the other field that may be used for the
-     rewrite rule. It is an optimization of the rewrite process for the
-     case where the next domain name is fixed instead of being
-     conditional on the content of the URI. The replacement field is a
-     domain name (subject to compression if a DNS sender knows that a
-     given recipient is able to decompress names in this RR type's RDATA
-     field). If the rewrite is more complex than a simple substitution
-     of a domain name, the replacement field should be set to . and the
-     regexp field used.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 5]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   Note that the client applies all the substitutions and performs all
-   lookups, they are not performed in the DNS servers. Note also that it
-   is the belief of the developers of this document that regexps should
-   rarely be used. The replacement field seems adequate for the vast
-   majority of situations. Regexps are only necessary when portions of a
-   namespace are to be delegated to different resolvers. Finally, note
-   that the regexp and replacement fields are, at present, mutually
-   exclusive. However, developers of client software should be aware
-   that a new flag might be defined which requires values in both
-   fields.
-
-Example 1
----------
-
-   Consider a URN that uses the hypothetical DUNS namespace. DUNS
-   numbers are identifiers for approximately 30 million registered
-   businesses around the world, assigned and maintained by Dunn and
-   Bradstreet. The URN might look like:
-
-                   urn:duns:002372413:annual-report-1997
-
-   The first step in the resolution process is to find out about the
-   DUNS namespace. The namespace identifier, "duns", is extracted from
-   the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked
-   up. It might return records of the form:
-
-duns.urn.net
-;;      order pref flags service          regexp        replacement
- IN NAPTR 100  10  "s" "dunslink+N2L+N2C" ""  dunslink.udp.isi.dandb.com
- IN NAPTR 100  20  "s" "rcds+N2C"         ""  rcds.udp.isi.dandb.com
- IN NAPTR 100  30  "s" "http+N2L+N2C+N2R" ""  http.tcp.isi.dandb.com
-
-   The order field contains equal values, indicating that no name
-   delegation order has to be followed. The preference field indicates
-   that the provider would like clients to use the special dunslink
-   protocol, followed by the RCDS protocol, and that HTTP is offered as
-   a last resort. All the records specify the "s" flag, which will be
-   explained momentarily.  The service fields say that if we speak
-   dunslink, we will be able to issue either the N2L or N2C requests to
-   obtain a URL or a URC (description) of the resource. The Resource
-   Cataloging and Distribution Service (RCDS)[7] could be used to get a
-   URC for the resource, while HTTP could be used to get a URL, URC, or
-   the resource itself.  All the records supply the next domain name to
-   query, none of them need to be rewritten with the aid of regular
-   expressions.
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 6]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   The general case might require multiple NAPTR rewrites to locate a
-   resolver, but eventually we will come to the "terminal NAPTR". Once
-   we have the terminal NAPTR, our next probe into the DNS will be for a
-   SRV or A record instead of another NAPTR. Rather than probing for a
-   non-existent NAPTR record to terminate the loop, the flags field is
-   used to indicate a terminal lookup. If it has a value of "s", the
-   next lookup should be for SRV RRs, "a" denotes that A records should
-   sought.  A "p" flag is also provided to indicate that the next action
-   is Protocol-specific, but that looking up another NAPTR will not be
-   part of it.
-
-   Since our example RR specified the "s" flag, it was terminal.
-   Assuming our client does not know the dunslink protocol, our next
-   action is to lookup SRV RRs for rcds.udp.isi.dandb.com, which will
-   tell us hosts that can provide the necessary resolution service. That
-   lookup might return:
-
-    ;;                          Pref Weight Port Target
-    rcds.udp.isi.dandb.com IN SRV 0    0    1000 defduns.isi.dandb.com
-                           IN SRV 0    0    1000 dbmirror.com.au
-                           IN SRV 0    0    1000 ukmirror.com.uk
-
-   telling us three hosts that could actually do the resolution, and
-   giving us the port we should use to talk to their RCDS server.  (The
-   reader is referred to the SRV proposal [4] for the interpretation of
-   the fields above).
-
-   There is opportunity for significant optimization here. We can return
-   the SRV records as additional information for terminal NAPTRs (and
-   the A records as additional information for those SRVs). While this
-   recursive provision of additional information is not explicitly
-   blessed in the DNS specifications, it is not forbidden, and BIND does
-   take advantage of it [8]. This is a significant optimization. In
-   conjunction with a long TTL for *.urn.net records, the average number
-   of probes to DNS for resolving DUNS URNs would approach one.
-   Therefore, DNS server implementors SHOULD provide additional
-   information with NAPTR responses. The additional information will be
-   either SRV or A records.  If SRV records are available, their A
-   records should be provided as recursive additional information.
-
-   Note that the example NAPTR records above are intended to represent
-   the reply the client will see. They are not quite identical to what
-   the domain administrator would put into the zone files. For one
-   thing, the administrator should supply the trailing '.' character on
-   any FQDNs.
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 7]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-Example 2
----------
-
-   Consider a URN namespace based on MIME Content-Ids. The URN might
-   look like this:
-
-                 urn:cid:199606121851.1@mordred.gatech.edu
-
-   (Note that this example is chosen for pedagogical purposes, and does
-   not conform to the recently-approved CID URL scheme.)
-
-   The first step in the resolution process is to find out about the CID
-   namespace. The namespace identifier, cid, is extracted from the URN,
-   prepended to urn.net, and the NAPTR for cid.urn.net looked up. It
-   might return records of the form:
-
- cid.urn.net
-  ;;       order pref flags service        regexp           replacement
-   IN NAPTR 100   10   ""  ""  "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i"    .
-
-   We have only one NAPTR response, so ordering the responses is not a
-   problem.  The replacement field is empty, so we check the regexp
-   field and use the pattern provided there. We apply that regexp to the
-   entire URN to see if it matches, which it does.  The \2 part of the
-   substitution expression returns the string "gatech.edu". Since the
-   flags field does not contain "s" or "a", the lookup is not terminal
-   and our next probe to DNS is for more NAPTR records:
-   lookup(query=NAPTR, "gatech.edu").
-
-   Note that the rule does not extract the full domain name from the
-   CID, instead it assumes the CID comes from a host and extracts its
-   domain.  While all hosts, such as mordred, could have their very own
-   NAPTR, maintaining those records for all the machines at a site as
-   large as Georgia Tech would be an intolerable burden. Wildcards are
-   not appropriate here since they only return results when there is no
-   exactly matching names already in the system.
-
-   The record returned from the query on "gatech.edu" might look like:
-
-gatech.edu IN NAPTR
-;;       order pref flags service           regexp  replacement
-  IN NAPTR 100  50  "s"  "z3950+N2L+N2C"     ""    z3950.tcp.gatech.edu
-  IN NAPTR 100  50  "s"  "rcds+N2C"          ""    rcds.udp.gatech.edu
-  IN NAPTR 100  50  "s"  "http+N2L+N2C+N2R"  ""    http.tcp.gatech.edu
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 8]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   Continuing with our example, we note that the values of the order and
-   preference fields are equal in all records, so the client is free to
-   pick any record. The flags field tells us that these are the last
-   NAPTR patterns we should see, and after the rewrite (a simple
-   replacement in this case) we should look up SRV records to get
-   information on the hosts that can provide the necessary service.
-
-   Assuming we prefer the Z39.50 protocol, our lookup might return:
-
-   ;;                        Pref Weight   Port Target
-   z3950.tcp.gatech.edu IN SRV 0    0      1000 z3950.gatech.edu
-                        IN SRV 0    0      1000 z3950.cc.gatech.edu
-                        IN SRV 0    0      1000 z3950.uga.edu
-
-   telling us three hosts that could actually do the resolution, and
-   giving us the port we should use to talk to their Z39.50 server.
-
-   Recall that the regular expression used \2 to extract a domain name
-   from the CID, and \. for matching the literal '.' characters
-   seperating the domain name components. Since '\' is the escape
-   character, literal occurances of a backslash must be escaped by
-   another backslash. For the case of the cid.urn.net record above, the
-   regular expression entered into the zone file should be
-   "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i".  When the client code actually
-   receives the record, the pattern will have been converted to
-   "/urn:cid:.+@([^.]+\.)(.*)$/\2/i".
-
-Example 3
----------
-
-   Even if URN systems were in place now, there would still be a
-   tremendous number of URLs.  It should be possible to develop a URN
-   resolution system that can also provide location independence for
-   those URLs.  This is related to the requirement in [1] to be able to
-   grandfather in names from other naming systems, such as ISO Formal
-   Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
-   etc.
-
-   The NAPTR RR could also be used for URLs that have already been
-   assigned.  Assume we have the URL for a very popular piece of
-   software that the publisher wishes to mirror at multiple sites around
-   the world:
-
-        http://www.foo.com/software/latest-beta.exe
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 9]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   We extract the prefix, "http", and lookup NAPTR records for
-   http.urn.net. This might return a record of the form
-
-   http.urn.net IN NAPTR
-   ;;  order   pref flags service      regexp             replacement
-        100     90   ""      ""   "!http://([^/:]+)!\1!i"       .
-
-   This expression returns everything after the first double slash and
-   before the next slash or colon. (We use the '!' character to delimit
-   the parts of the substitution expression. Otherwise we would have to
-   use backslashes to escape the forward slashes, and would have a
-   regexp in the zone file that looked like
-   "/http:\\/\\/([^\\/:]+)/\\1/i".).
-
-   Applying this pattern to the URL extracts "www.foo.com". Looking up
-   NAPTR records for that might return:
-
-   www.foo.com
-   ;;       order pref flags   service  regexp     replacement
-    IN NAPTR 100  100  "s"   "http+L2R"   ""    http.tcp.foo.com
-    IN NAPTR 100  100  "s"   "ftp+L2R"    ""    ftp.tcp.foo.com
-
-   Looking up SRV records for http.tcp.foo.com would return information
-   on the hosts that foo.com has designated to be its mirror sites. The
-   client can then pick one for the user.
-
-NAPTR RR Format
-===============
-
-   The format of the NAPTR RR is given below. The DNS type code for
-   NAPTR is 35.
-
-       Domain TTL Class Order Preference Flags Service Regexp
-       Replacement
-
-   where:
-
-   Domain
-          The domain name this resource record refers to.
-   TTL
-          Standard DNS Time To Live field
-   Class
-          Standard DNS meaning
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 10]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   Order
-          A 16-bit integer specifying the order in which the NAPTR
-          records MUST be processed to ensure correct delegation of
-          portions of the namespace over time. Low numbers are processed
-          before high numbers, and once a NAPTR is found that "matches"
-          a URN, the client MUST NOT consider any NAPTRs with a higher
-          value for order.
-
-   Preference
-          A 16-bit integer which specifies the order in which NAPTR
-          records with equal "order" values SHOULD be processed, low
-          numbers being processed before high numbers.  This is similar
-          to the preference field in an MX record, and is used so domain
-          administrators can direct clients towards more capable hosts
-          or lighter weight protocols.
-
-   Flags
-          A String giving flags to control aspects of the rewriting and
-          interpretation of the fields in the record. Flags are single
-          characters from the set [A-Z0-9]. The case of the alphabetic
-          characters is not significant.
-
-          At this time only three flags, "S", "A", and "P", are defined.
-          "S" means that the next lookup should be for SRV records
-          instead of NAPTR records. "A" means that the next lookup
-          should be for A records. The "P" flag says that the remainder
-          of the resolution shall be carried out in a Protocol-specific
-          fashion, and we should not do any more DNS queries.
-
-          The remaining alphabetic flags are reserved. The numeric flags
-          may be used for local experimentation. The S, A, and P flags
-          are all mutually exclusive, and resolution libraries MAY
-          signal an error if more than one is given. (Experimental code
-          and code for assisting in the creation of NAPTRs would be more
-          likely to signal such an error than a client such as a
-          browser). We anticipate that multiple flags will be allowed in
-          the future, so implementers MUST NOT assume that the flags
-          field can only contain 0 or 1 characters. Finally, if a client
-          encounters a record with an unknown flag, it MUST ignore it
-          and move to the next record. This test takes precedence even
-          over the "order" field. Since flags can control the
-          interpretation placed on fields, a novel flag might change the
-          interpretation of the regexp and/or replacement fields such
-          that it is impossible to determine if a record matched a URN.
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 11]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   Service
-          Specifies the resolution service(s) available down this
-          rewrite path. It may also specify the particular protocol that
-          is used to talk with a resolver. A protocol MUST be specified
-          if the flags field states that the NAPTR is terminal. If a
-          protocol is specified, but the flags field does not state that
-          the NAPTR is terminal, the next lookup MUST be for a NAPTR.
-          The client MAY choose not to perform the next lookup if the
-          protocol is unknown, but that behavior MUST NOT be relied
-          upon.
-
-          The service field may take any of the values below (using the
-          Augmented BNF of RFC 822[9]):
-
-           service_field = [ [protocol] *("+" rs)]
-           protocol      = ALPHA *31ALPHANUM
-           rs            = ALPHA *31ALPHANUM
-        // The protocol and rs fields are limited to 32
-        // characters and must start with an alphabetic.
-        // The current set of "known" strings are:
-        // protocol      = "rcds" / "thttp" / "hdl" / "rwhois" / "z3950"
-        // rs            = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C"
-        //               / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C"
-
-          i.e. an optional protocol specification followed by 0 or more
-          resolution services. Each resolution service is indicated by
-          an initial '+' character.
-
-          Note that the empty string is also a valid service field. This
-          will typically be seen at the top levels of a namespace, when
-          it is impossible to know what services and protocols will be
-          offered by a particular publisher within that name space.
-
-          At this time the known protocols are rcds[7], hdl[10] (binary,
-          UDP-based protocols),  thttp[5] (a textual, TCP-based
-          protocol), rwhois[11] (textual, UDP or TCP based), and
-          Z39.50[12] (binary, TCP-based). More will be allowed later.
-          The names of the protocols must be formed from the characters
-          [a-Z0-9]. Case of the characters is not significant.
-
-          The service requests currently allowed will be described in
-          more detail in [6], but in brief they are:
-                N2L  - Given a URN, return a URL
-                N2Ls - Given a URN, return a set of URLs
-                N2R  - Given a URN, return an instance of the resource.
-                N2Rs - Given a URN, return multiple instances of the
-                       resource, typically encoded using
-                       multipart/alternative.
-
-
-
-Daniel & Mealling             Experimental                     [Page 12]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-                N2C  - Given a URN, return a collection of meta-
-                       information on the named resource. The format of
-                       this response is the subject of another document.
-                N2Ns - Given a URN, return all URNs that are also
-                       identifers for the resource.
-                L2R  - Given a URL, return the resource.
-                L2Ns - Given a URL, return all the URNs that are
-                       identifiers for the resource.
-                L2Ls - Given a URL, return all the URLs for instances of
-                       of the same resource.
-                L2C  - Given a URL, return a description of the
-                       resource.
-
-          The actual format of the service request and response will be
-          determined by the resolution protocol, and is the subject for
-          other documents (e.g. [5]). Protocols need not offer all
-          services. The labels for service requests shall be formed from
-          the set of characters [A-Z0-9]. The case of the alphabetic
-          characters is not significant.
-
-   Regexp
-          A STRING containing a substitution expression that is applied
-          to the original URI in order to construct the next domain name
-          to lookup. The grammar of the substitution expression is given
-          in the next section.
-
-   Replacement
-          The next NAME to query for NAPTR, SRV, or A records depending
-          on the value of the flags field. As mentioned above, this may
-          be compressed.
-
-Substitution Expression Grammar:
-================================
-
-   The content of the regexp field is a substitution expression. True
-   sed(1) substitution expressions are not appropriate for use in this
-   application for a variety of reasons, therefore the contents of the
-   regexp field MUST follow the grammar below:
-
-subst_expr   = delim-char  ere  delim-char  repl  delim-char  *flags
-delim-char   = "/" / "!" / ... (Any non-digit or non-flag character other
-               than backslash '\'. All occurances of a delim_char in a
-               subst_expr must be the same character.)
-ere          = POSIX Extended Regular Expression (see [13], section
-               2.8.4)
-repl         = dns_str /  backref / repl dns_str  / repl backref
-dns_str      = 1*DNS_CHAR
-backref      = "\" 1POS_DIGIT
-
-
-
-Daniel & Mealling             Experimental                     [Page 13]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-flags        = "i"
-DNS_CHAR     = "-" / "0" / ... / "9" / "a" / ... / "z" / "A" / ... / "Z"
-POS_DIGIT    = "1" / "2" / ... / "9"  ; 0 is not an allowed backref
-value domain name (see RFC-1123 [14]).
-
-   The result of applying the substitution expression to the original
-   URI MUST result in a string that obeys the syntax for DNS host names
-   [14]. Since it is possible for the regexp field to be improperly
-   specified, such that a non-conforming host name can be constructed,
-   client software SHOULD verify that the result is a legal host name
-   before making queries on it.
-
-   Backref expressions in the repl portion of the substitution
-   expression are replaced by the (possibly empty) string of characters
-   enclosed by '(' and ')' in the ERE portion of the substitution
-   expression. N is a single digit from 1 through 9, inclusive. It
-   specifies the N'th backref expression, the one that begins with the
-   N'th '(' and continues to the matching ')'.  For example, the ERE
-                      (A(B(C)DE)(F)G)
-   has backref expressions:
-                      \1  = ABCDEFG
-                      \2  = BCDE
-                      \3  = C
-                      \4  = F
-                 \5..\9  = error - no matching subexpression
-
-   The "i" flag indicates that the ERE matching SHALL be performed in a
-   case-insensitive fashion. Furthermore, any backref replacements MAY
-   be normalized to lower case when the "i" flag is given.
-
-   The first character in the substitution expression shall be used as
-   the character that delimits the components of the substitution
-   expression.  There must be exactly three non-escaped occurrences of
-   the delimiter character in a substitution expression. Since escaped
-   occurrences of the delimiter character will be interpreted as
-   occurrences of that character, digits MUST NOT be used as delimiters.
-   Backrefs would be confused with literal digits were this allowed.
-   Similarly, if flags are specified in the substitution expression, the
-   delimiter character must not also be a flag character.
-
-
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 14]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-Advice to domain administrators:
-================================
-
-   Beware of regular expressions. Not only are they a pain to get
-   correct on their own, but there is the previously mentioned
-   interaction with DNS. Any backslashes in a regexp must be entered
-   twice in a zone file in order to appear once in a query response.
-   More seriously, the need for double backslashes has probably not been
-   tested by all implementors of DNS servers. We anticipate that urn.net
-   will be the heaviest user of regexps. Only when delegating portions
-   of namespaces should the typical domain administrator need to use
-   regexps.
-
-   On a related note, beware of interactions with the shell when
-   manipulating regexps from the command line. Since '\' is a common
-   escape character in shells, there is a good chance that when you
-   think you are saying "\\" you are actually saying "\".  Similar
-   caveats apply to characters such as
-
-   The "a" flag allows the next lookup to be for A records rather than
-   SRV records. Since there is no place for a port specification in the
-   NAPTR record, when the "A" flag is used the specified protocol must
-   be running on its default port.
-
-   The URN Sytnax draft defines a canonical form for each URN, which
-   requires %encoding characters outside a limited repertoire. The
-   regular expressions MUST be written to operate on that canonical
-   form. Since international character sets will end up with extensive
-   use of %encoded characters, regular expressions operating on them
-   will be essentially impossible to read or write by hand.
-
-Usage
-=====
-
-   For the edification of implementers, pseudocode for a client routine
-   using NAPTRs is given below. This code is provided merely as a
-   convience, it does not have any weight as a standard way to process
-   NAPTR records. Also, as is the case with pseudocode, it has never
-   been executed and may contain logical errors. You have been warned.
-
-    //
-    // findResolver(URN)
-    // Given a URN, find a host that can resolve it.
-    //
-    findResolver(string URN) {
-      // prepend prefix to urn.net
-      sprintf(key, "%s.urn.net", extractNS(URN));
-      do {
-
-
-
-Daniel & Mealling             Experimental                     [Page 15]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-        rewrite_flag = false;
-        terminal = false;
-        if (key has been seen) {
-          quit with a loop detected error
-        }
-        add key to list of "seens"
-        records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key'
-
-        discard any records with an unknown value in the "flags" field.
-        sort NAPTR records by "order" field and "preference" field
-            (with "order" being more significant than "preference").
-        n_naptrs = number of NAPTR records in response.
-        curr_order = records[0].order;
-        max_order = records[n_naptrs-1].order;
-
-        // Process current batch of NAPTRs according to "order" field.
-        for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {
-          if (unknown_flag) // skip this record and go to next one
-             continue;
-          newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);
-          if (!newkey) // Skip to next record if the rewrite didn't
-             match continue;
-          // We did do a rewrite, shrink max_order to current value
-          // so that delegation works properly
-          max_order = naptr[j].order;
-          // Will we know what to do with the protocol and services
-          // specified in the NAPTR? If not, try next record.
-          if(!isKnownProto(naptr[j].services)) {
-            continue;
-          }
-          if(!isKnownService(naptr[j].services)) {
-            continue;
-          }
-
-          // At this point we have a successful rewrite and we will
-          // know how to speak the protocol and request a known
-          // resolution service. Before we do the next lookup, check
-          // some optimization possibilities.
-
-          if (strcasecmp(flags, "S")
-           || strcasecmp(flags, "P"))
-           || strcasecmp(flags, "A")) {
-             terminal = true;
-             services = naptr[j].services;
-             addnl = any SRV and/or A records returned as additional
-                     info for naptr[j].
-          }
-          key = newkey;
-
-
-
-Daniel & Mealling             Experimental                     [Page 16]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-          rewriteflag = true;
-          break;
-        }
-      } while (rewriteflag && !terminal);
-
-      // Did we not find our way to a resolver?
-      if (!rewrite_flag) {
-         report an error
-         return NULL;
-      }
-
-
-      // Leave rest to another protocol?
-      if (strcasecmp(flags, "P")) {
-         return key as host to talk to;
-      }
-
-      // If not, keep plugging
-      if (!addnl) { // No SRVs came in as additional info, look them up
-        srvs = lookup(type=SRV, key);
-      }
-
-      sort SRV records by preference, weight, ...
-      foreach (SRV record) { // in order of preference
-        try contacting srv[j].target using the protocol and one of the
-            resolution service requests from the "services" field of the
-            last NAPTR record.
-        if (successful)
-          return (target, protocol, service);
-          // Actually we would probably return a result, but this
-          // code was supposed to just tell us a good host to talk to.
-      }
-      die with an "unable to find a host" error;
-    }
-
-Notes:
-======
-
-     -  A client MUST process multiple NAPTR records in the order
-        specified by the "order" field, it MUST NOT simply use the first
-        record that provides a known protocol and service combination.
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 17]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-     -  If a record at a particular order matches the URI, but the
-        client doesn't know the specified protocol and service, the
-        client SHOULD continue to examine records that have the same
-        order. The client MUST NOT consider records with a higher value
-        of order. This is necessary to make delegation of portions of
-        the namespace work.  The order field is what lets site
-        administrators say "all requests for URIs matching pattern x go
-        to server 1, all others go to server 2".
-        (A match is defined as:
-          1)  The NAPTR provides a replacement domain name
-          or
-          2) The regular expression matches the URN
-           )
-
-     -  When multiple RRs have the same "order", the client should use
-        the value of the preference field to select the next NAPTR to
-        consider. However, because of preferred protocols or services,
-        estimates of network distance and bandwidth, etc. clients may
-        use different criteria to sort the records.
-     -  If the lookup after a rewrite fails, clients are strongly
-        encouraged to report a failure, rather than backing up to pursue
-        other rewrite paths.
-     -  When a namespace is to be delegated among a set of resolvers,
-        regexps must be used. Each regexp appears in a separate NAPTR
-        RR.  Administrators should do as little delegation as possible,
-        because of limitations on the size of DNS responses.
-     -  Note that SRV RRs impose additional requirements on clients.
-
-Acknowledgments:
-=================
-
-   The editors would like to thank Keith Moore for all his consultations
-   during the development of this draft. We would also like to thank
-   Paul Vixie for his assistance in debugging our implementation, and
-   his answers on our questions. Finally, we would like to acknowledge
-   our enormous intellectual debt to the participants in the Knoxville
-   series of meetings, as well as to the participants in the URI and URN
-   working groups.
-
-References:
-===========
-
-   [1]  Sollins, Karen and Larry Masinter, "Functional Requirements
-        for Uniform Resource Names", RFC-1737, Dec. 1994.
-
-   [2]  The URN Implementors, Uniform Resource Names: A Progress Report,
-        http://www.dlib.org/dlib/february96/02arms.html, D-Lib Magazine,
-        February 1996.
-
-
-
-Daniel & Mealling             Experimental                     [Page 18]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   [3]  Moats, Ryan, "URN Syntax", RFC-2141, May 1997.
-
-   [4]  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
-        the location of services (DNS SRV)", RFC-2052, October 1996.
-
-   [5]  Daniel, Jr., Ron, "A Trivial Convention for using HTTP in URN
-        Resolution", RFC-2169, June 1997.
-
-   [6]  URN-WG, "URN Resolution Services", Work in Progress.
-
-   [7]  Moore, Keith,  Shirley Browne, Jason Cox, and Jonathan Gettler,
-        Resource Cataloging and Distribution System, Technical Report
-        CS-97-346, University of Tennessee, Knoxville, December 1996
-
-   [8]  Paul Vixie, personal communication.
-
-   [9]  Crocker, Dave H. "Standard for the Format of ARPA Internet Text
-        Messages", RFC-822, August 1982.
-
-   [10] Orth, Charles and Bill Arms; Handle Resolution Protocol
-        Specification, http://www.handle.net/docs/client_spec.html
-
-   [11] Williamson, S., M. Kosters, D. Blacka, J. Singh, K. Zeilstra,
-        "Referral Whois Protocol (RWhois)", RFC-2167, June 1997.
-
-   [12] Information Retrieval (Z39.50): Application Service Definition
-        and Protocol Specification, ANSI/NISO Z39.50-1995, July 1995.
-
-   [13] IEEE Standard for Information Technology - Portable Operating
-        System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1);
-        IEEE Std 1003.2-1992; The Institute of Electrical and
-        Electronics Engineers; New York; 1993. ISBN:1-55937-255-9
-
-   [14] Braden, R., "Requirements for Internet Hosts - Application and
-        and Support", RFC-1123, Oct. 1989.
-
-   [15] Sollins, Karen, "Requirements and a Framework for URN Resolution
-        Systems", November 1996, Work in Progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 19]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-Security Considerations
-=======================
-
-   The use of "urn.net" as the registry for URN namespaces is subject to
-   denial of service attacks, as well as other DNS spoofing attacks. The
-   interactions with DNSSEC are currently being studied. It is expected
-   that NAPTR records will be signed with SIG records once the DNSSEC
-   work is deployed.
-
-   The rewrite rules make identifiers from other namespaces subject to
-   the same attacks as normal domain names. Since they have not been
-   easily resolvable before, this may or may not be considered a
-   problem.
-
-   Regular expressions should be checked for sanity, not blindly passed
-   to something like PERL.
-
-   This document has discussed a way of locating a resolver, but has not
-   discussed any detail of how the communication with the resolver takes
-   place. There are significant security considerations attached to the
-   communication with a resolver. Those considerations are outside the
-   scope of this document, and must be addressed by the specifications
-   for particular resolver communication protocols.
-
-Author Contact Information:
-===========================
-
-   Ron Daniel
-   Los Alamos National Laboratory
-   MS B287
-   Los Alamos, NM, USA, 87545
-   voice:  +1 505 665 0597
-   fax:    +1 505 665 4939
-   email:  rdaniel@lanl.gov
-
-
-   Michael Mealling
-   Network Solutions
-   505 Huntmar Park Drive
-   Herndon, VA  22070
-   voice: (703) 742-0400
-   fax: (703) 742-9552
-   email: michaelm@internic.net
-   URL: http://www.netsol.com/
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 20]
-
diff --git a/doc/rfc/rfc2181.txt b/doc/rfc/rfc2181.txt
deleted file mode 100644
index 7899e1cb..00000000
--- a/doc/rfc/rfc2181.txt
+++ /dev/null
@@ -1,842 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             R. Elz
-Request for Comments: 2181                       University of Melbourne
-Updates: 1034, 1035, 1123                                        R. Bush
-Category: Standards Track                                    RGnet, Inc.
-                                                               July 1997
-
-
-                Clarifications to the DNS Specification
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-1. Abstract
-
-   This document considers some areas that have been identified as
-   problems with the specification of the Domain Name System, and
-   proposes remedies for the defects identified.  Eight separate issues
-   are considered:
-
-     + IP packet header address usage from multi-homed servers,
-     + TTLs in sets of records with the same name, class, and type,
-     + correct handling of zone cuts,
-     + three minor issues concerning SOA records and their use,
-     + the precise definition of the Time to Live (TTL)
-     + Use of the TC (truncated) header bit
-     + the issue of what is an authoritative, or canonical, name,
-     + and the issue of what makes a valid DNS label.
-
-   The first six of these are areas where the correct behaviour has been
-   somewhat unclear, we seek to rectify that.  The other two are already
-   adequately specified, however the specifications seem to be sometimes
-   ignored.  We seek to reinforce the existing specifications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 1]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-
-
-Contents
-
-    1  Abstract  ...................................................   1
-    2  Introduction  ...............................................   2
-    3  Terminology  ................................................   3
-    4  Server Reply Source Address Selection  ......................   3
-    5  Resource Record Sets  .......................................   4
-    6  Zone Cuts  ..................................................   8
-    7  SOA RRs  ....................................................  10
-    8  Time to Live (TTL)  .........................................  10
-    9  The TC (truncated) header bit  ..............................  11
-   10  Naming issues  ..............................................  11
-   11  Name syntax  ................................................  13
-   12  Security Considerations  ....................................  14
-   13  References  .................................................  14
-   14  Acknowledgements  ...........................................  15
-   15  Authors' Addresses  .........................................  15
-
-
-
-
-2. Introduction
-
-   Several problem areas in the Domain Name System specification
-   [RFC1034, RFC1035] have been noted through the years [RFC1123].  This
-   document addresses several additional problem areas.  The issues here
-   are independent.  Those issues are the question of which source
-   address a multi-homed DNS server should use when replying to a query,
-   the issue of differing TTLs for DNS records with the same label,
-   class and type, and the issue of canonical names, what they are, how
-   CNAME records relate, what names are legal in what parts of the DNS,
-   and what is the valid syntax of a DNS name.
-
-   Clarifications to the DNS specification to avoid these problems are
-   made in this memo.  A minor ambiguity in RFC1034 concerned with SOA
-   records is also corrected, as is one in the definition of the TTL
-   (Time To Live) and some possible confusion in use of the TC bit.
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 2]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-3. Terminology
-
-   This memo does not use the oft used expressions MUST, SHOULD, MAY, or
-   their negative forms.  In some sections it may seem that a
-   specification is worded mildly, and hence some may infer that the
-   specification is optional.  That is not correct.  Anywhere that this
-   memo suggests that some action should be carried out, or must be
-   carried out, or that some behaviour is acceptable, or not, that is to
-   be considered as a fundamental aspect of this specification,
-   regardless of the specific words used.  If some behaviour or action
-   is truly optional, that will be clearly specified by the text.
-
-4. Server Reply Source Address Selection
-
-   Most, if not all, DNS clients, expect the address from which a reply
-   is received to be the same address as that to which the query
-   eliciting the reply was sent.  This is true for servers acting as
-   clients for the purposes of recursive query resolution, as well as
-   simple resolver clients.  The address, along with the identifier (ID)
-   in the reply is used for disambiguating replies, and filtering
-   spurious responses.  This may, or may not, have been intended when
-   the DNS was designed, but is now a fact of life.
-
-   Some multi-homed hosts running DNS servers generate a reply using a
-   source address that is not the same as the destination address from
-   the client's request packet.  Such replies will be discarded by the
-   client because the source address of the reply does not match that of
-   a host to which the client sent the original request.  That is, it
-   appears to be an unsolicited response.
-
-4.1. UDP Source Address Selection
-
-   To avoid these problems, servers when responding to queries using UDP
-   must cause the reply to be sent with the source address field in the
-   IP header set to the address that was in the destination address
-   field of the IP header of the packet containing the query causing the
-   response.  If this would cause the response to be sent from an IP
-   address that is not permitted for this purpose, then the response may
-   be sent from any legal IP address allocated to the server.  That
-   address should be chosen to maximise the possibility that the client
-   will be able to use it for further queries.  Servers configured in
-   such a way that not all their addresses are equally reachable from
-   all potential clients need take particular care when responding to
-   queries sent to anycast, multicast, or similar, addresses.
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 3]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-4.2. Port Number Selection
-
-   Replies to all queries must be directed to the port from which they
-   were sent.  When queries are received via TCP this is an inherent
-   part of the transport protocol.  For queries received by UDP the
-   server must take note of the source port and use that as the
-   destination port in the response.  Replies should always be sent from
-   the port to which they were directed.  Except in extraordinary
-   circumstances, this will be the well known port assigned for DNS
-   queries [RFC1700].
-
-5. Resource Record Sets
-
-   Each DNS Resource Record (RR) has a label, class, type, and data.  It
-   is meaningless for two records to ever have label, class, type and
-   data all equal - servers should suppress such duplicates if
-   encountered.  It is however possible for most record types to exist
-   with the same label, class and type, but with different data.  Such a
-   group of records is hereby defined to be a Resource Record Set
-   (RRSet).
-
-5.1. Sending RRs from an RRSet
-
-   A query for a specific (or non-specific) label, class, and type, will
-   always return all records in the associated RRSet - whether that be
-   one or more RRs.  The response must be marked as "truncated" if the
-   entire RRSet will not fit in the response.
-
-5.2. TTLs of RRs in an RRSet
-
-   Resource Records also have a time to live (TTL).  It is possible for
-   the RRs in an RRSet to have different TTLs.  No uses for this have
-   been found that cannot be better accomplished in other ways.  This
-   can, however, cause partial replies (not marked "truncated") from a
-   caching server, where the TTLs for some but not all the RRs in the
-   RRSet have expired.
-
-   Consequently the use of differing TTLs in an RRSet is hereby
-   deprecated, the TTLs of all RRs in an RRSet must be the same.
-
-   Should a client receive a response containing RRs from an RRSet with
-   differing TTLs, it should treat this as an error.  If the RRSet
-   concerned is from a non-authoritative source for this data, the
-   client should simply ignore the RRSet, and if the values were
-   required, seek to acquire them from an authoritative source.  Clients
-   that are configured to send all queries to one, or more, particular
-   servers should treat those servers as authoritative for this purpose.
-   Should an authoritative source send such a malformed RRSet, the
-
-
-
-Elz & Bush                  Standards Track                     [Page 4]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   client should treat the RRs for all purposes as if all TTLs in the
-   RRSet had been set to the value of the lowest TTL in the RRSet.  In
-   no case may a server send an RRSet with TTLs not all equal.
-
-5.3. DNSSEC Special Cases
-
-   Two of the record types added by DNS Security (DNSSEC) [RFC2065]
-   require special attention when considering the formation of Resource
-   Record Sets.  Those are the SIG and NXT records.  It should be noted
-   that DNS Security is still very new, and there is, as yet, little
-   experience with it.  Readers should be prepared for the information
-   related to DNSSEC contained in this document to become outdated as
-   the DNS Security specification matures.
-
-5.3.1. SIG records and RRSets
-
-   A SIG record provides signature (validation) data for another RRSet
-   in the DNS.  Where a zone has been signed, every RRSet in the zone
-   will have had a SIG record associated with it.  The data type of the
-   RRSet is included in the data of the SIG RR, to indicate with which
-   particular RRSet this SIG record is associated.  Were the rules above
-   applied, whenever a SIG record was included with a response to
-   validate that response, the SIG records for all other RRSets
-   associated with the appropriate node would also need to be included.
-   In some cases, this could be a very large number of records, not
-   helped by their being rather large RRs.
-
-   Thus, it is specifically permitted for the authority section to
-   contain only those SIG RRs with the "type covered" field equal to the
-   type field of an answer being returned.  However, where SIG records
-   are being returned in the answer section, in response to a query for
-   SIG records, or a query for all records associated with a name
-   (type=ANY) the entire SIG RRSet must be included, as for any other RR
-   type.
-
-   Servers that receive responses containing SIG records in the
-   authority section, or (probably incorrectly) as additional data, must
-   understand that the entire RRSet has almost certainly not been
-   included.  Thus, they must not cache that SIG record in a way that
-   would permit it to be returned should a query for SIG records be
-   received at that server.  RFC2065 actually requires that SIG queries
-   be directed only to authoritative servers to avoid the problems that
-   could be caused here, and while servers exist that do not understand
-   the special properties of SIG records, this will remain necessary.
-   However, careful design of SIG record processing in new
-   implementations should permit this restriction to be relaxed in the
-   future, so resolvers do not need to treat SIG record queries
-   specially.
-
-
-
-Elz & Bush                  Standards Track                     [Page 5]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   It has been occasionally stated that a received request for a SIG
-   record should be forwarded to an authoritative server, rather than
-   being answered from data in the cache.  This is not necessary - a
-   server that has the knowledge of SIG as a special case for processing
-   this way would be better to correctly cache SIG records, taking into
-   account their characteristics.  Then the server can determine when it
-   is safe to reply from the cache, and when the answer is not available
-   and the query must be forwarded.
-
-5.3.2. NXT RRs
-
-   Next Resource Records (NXT) are even more peculiar.  There will only
-   ever be one NXT record in a zone for a particular label, so
-   superficially, the RRSet problem is trivial.  However, at a zone cut,
-   both the parent zone, and the child zone (superzone and subzone in
-   RFC2065 terminology) will have NXT records for the same name.  Those
-   two NXT records do not form an RRSet, even where both zones are
-   housed at the same server.  NXT RRSets always contain just a single
-   RR.  Where both NXT records are visible, two RRSets exist.  However,
-   servers are not required to treat this as a special case when
-   receiving NXT records in a response.  They may elect to notice the
-   existence of two different NXT RRSets, and treat that as they would
-   two different RRSets of any other type.  That is, cache one, and
-   ignore the other.  Security aware servers will need to correctly
-   process the NXT record in the received response though.
-
-5.4. Receiving RRSets
-
-   Servers must never merge RRs from a response with RRs in their cache
-   to form an RRSet.  If a response contains data that would form an
-   RRSet with data in a server's cache the server must either ignore the
-   RRs in the response, or discard the entire RRSet currently in the
-   cache, as appropriate.  Consequently the issue of TTLs varying
-   between the cache and a response does not cause concern, one will be
-   ignored.  That is, one of the data sets is always incorrect if the
-   data from an answer differs from the data in the cache.  The
-   challenge for the server is to determine which of the data sets is
-   correct, if one is, and retain that, while ignoring the other.  Note
-   that if a server receives an answer containing an RRSet that is
-   identical to that in its cache, with the possible exception of the
-   TTL value, it may, optionally, update the TTL in its cache with the
-   TTL of the received answer.  It should do this if the received answer
-   would be considered more authoritative (as discussed in the next
-   section) than the previously cached answer.
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 6]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-5.4.1. Ranking data
-
-   When considering whether to accept an RRSet in a reply, or retain an
-   RRSet already in its cache instead, a server should consider the
-   relative likely trustworthiness of the various data.  An
-   authoritative answer from a reply should replace cached data that had
-   been obtained from additional information in an earlier reply.
-   However additional information from a reply will be ignored if the
-   cache contains data from an authoritative answer or a zone file.
-
-   The accuracy of data available is assumed from its source.
-   Trustworthiness shall be, in order from most to least:
-
-     + Data from a primary zone file, other than glue data,
-     + Data from a zone transfer, other than glue,
-     + The authoritative data included in the answer section of an
-       authoritative reply.
-     + Data from the authority section of an authoritative answer,
-     + Glue from a primary zone, or glue from a zone transfer,
-     + Data from the answer section of a non-authoritative answer, and
-       non-authoritative data from the answer section of authoritative
-       answers,
-     + Additional information from an authoritative answer,
-       Data from the authority section of a non-authoritative answer,
-       Additional information from non-authoritative answers.
-
-   Note that the answer section of an authoritative answer normally
-   contains only authoritative data.  However when the name sought is an
-   alias (see section 10.1.1) only the record describing that alias is
-   necessarily authoritative.  Clients should assume that other records
-   may have come from the server's cache.  Where authoritative answers
-   are required, the client should query again, using the canonical name
-   associated with the alias.
-
-   Unauthenticated RRs received and cached from the least trustworthy of
-   those groupings, that is data from the additional data section, and
-   data from the authority section of a non-authoritative answer, should
-   not be cached in such a way that they would ever be returned as
-   answers to a received query.  They may be returned as additional
-   information where appropriate.  Ignoring this would allow the
-   trustworthiness of relatively untrustworthy data to be increased
-   without cause or excuse.
-
-   When DNS security [RFC2065] is in use, and an authenticated reply has
-   been received and verified, the data thus authenticated shall be
-   considered more trustworthy than unauthenticated data of the same
-   type.  Note that throughout this document, "authoritative" means a
-   reply with the AA bit set.  DNSSEC uses trusted chains of SIG and KEY
-
-
-
-Elz & Bush                  Standards Track                     [Page 7]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   records to determine the authenticity of data, the AA bit is almost
-   irrelevant.  However DNSSEC aware servers must still correctly set
-   the AA bit in responses to enable correct operation with servers that
-   are not security aware (almost all currently).
-
-   Note that, glue excluded, it is impossible for data from two
-   correctly configured primary zone files, two correctly configured
-   secondary zones (data from zone transfers) or data from correctly
-   configured primary and secondary zones to ever conflict.  Where glue
-   for the same name exists in multiple zones, and differs in value, the
-   nameserver should select data from a primary zone file in preference
-   to secondary, but otherwise may choose any single set of such data.
-   Choosing that which appears to come from a source nearer the
-   authoritative data source may make sense where that can be
-   determined.  Choosing primary data over secondary allows the source
-   of incorrect glue data to be discovered more readily, when a problem
-   with such data exists.  Where a server can detect from two zone files
-   that one or more are incorrectly configured, so as to create
-   conflicts, it should refuse to load the zones determined to be
-   erroneous, and issue suitable diagnostics.
-
-   "Glue" above includes any record in a zone file that is not properly
-   part of that zone, including nameserver records of delegated sub-
-   zones (NS records), address records that accompany those NS records
-   (A, AAAA, etc), and any other stray data that might appear.
-
-5.5. Sending RRSets (reprise)
-
-   A Resource Record Set should only be included once in any DNS reply.
-   It may occur in any of the Answer, Authority, or Additional
-   Information sections, as required.  However it should not be repeated
-   in the same, or any other, section, except where explicitly required
-   by a specification.  For example, an AXFR response requires the SOA
-   record (always an RRSet containing a single RR) be both the first and
-   last record of the reply.  Where duplicates are required this way,
-   the TTL transmitted in each case must be the same.
-
-6. Zone Cuts
-
-   The DNS tree is divided into "zones", which are collections of
-   domains that are treated as a unit for certain management purposes.
-   Zones are delimited by "zone cuts".  Each zone cut separates a
-   "child" zone (below the cut) from a "parent" zone (above the cut).
-   The domain name that appears at the top of a zone (just below the cut
-   that separates the zone from its parent) is called the zone's
-   "origin".  The name of the zone is the same as the name of the domain
-   at the zone's origin.  Each zone comprises that subset of the DNS
-   tree that is at or below the zone's origin, and that is above the
-
-
-
-Elz & Bush                  Standards Track                     [Page 8]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   cuts that separate the zone from its children (if any).  The
-   existence of a zone cut is indicated in the parent zone by the
-   existence of NS records specifying the origin of the child zone.  A
-   child zone does not contain any explicit reference to its parent.
-
-6.1. Zone authority
-
-   The authoritative servers for a zone are enumerated in the NS records
-   for the origin of the zone, which, along with a Start of Authority
-   (SOA) record are the mandatory records in every zone.  Such a server
-   is authoritative for all resource records in a zone that are not in
-   another zone.  The NS records that indicate a zone cut are the
-   property of the child zone created, as are any other records for the
-   origin of that child zone, or any sub-domains of it.  A server for a
-   zone should not return authoritative answers for queries related to
-   names in another zone, which includes the NS, and perhaps A, records
-   at a zone cut, unless it also happens to be a server for the other
-   zone.
-
-   Other than the DNSSEC cases mentioned immediately below, servers
-   should ignore data other than NS records, and necessary A records to
-   locate the servers listed in the NS records, that may happen to be
-   configured in a zone at a zone cut.
-
-6.2. DNSSEC issues
-
-   The DNS security mechanisms [RFC2065] complicate this somewhat, as
-   some of the new resource record types added are very unusual when
-   compared with other DNS RRs.  In particular the NXT ("next") RR type
-   contains information about which names exist in a zone, and hence
-   which do not, and thus must necessarily relate to the zone in which
-   it exists.  The same domain name may have different NXT records in
-   the parent zone and the child zone, and both are valid, and are not
-   an RRSet.  See also section 5.3.2.
-
-   Since NXT records are intended to be automatically generated, rather
-   than configured by DNS operators, servers may, but are not required
-   to, retain all differing NXT records they receive regardless of the
-   rules in section 5.4.
-
-   For a secure parent zone to securely indicate that a subzone is
-   insecure, DNSSEC requires that a KEY RR indicating that the subzone
-   is insecure, and the parent zone's authenticating SIG RR(s) be
-   present in the parent zone, as they by definition cannot be in the
-   subzone.  Where a subzone is secure, the KEY and SIG records will be
-   present, and authoritative, in that zone, but should also always be
-   present in the parent zone (if secure).
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 9]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   Note that in none of these cases should a server for the parent zone,
-   not also being a server for the subzone, set the AA bit in any
-   response for a label at a zone cut.
-
-7. SOA RRs
-
-   Three minor issues concerning the Start of Zone of Authority (SOA)
-   Resource Record need some clarification.
-
-7.1. Placement of SOA RRs in authoritative answers
-
-   RFC1034, in section 3.7, indicates that the authority section of an
-   authoritative answer may contain the SOA record for the zone from
-   which the answer was obtained.  When discussing negative caching,
-   RFC1034 section 4.3.4 refers to this technique but mentions the
-   additional section of the response.  The former is correct, as is
-   implied by the example shown in section 6.2.5 of RFC1034.  SOA
-   records, if added, are to be placed in the authority section.
-
-7.2. TTLs on SOA RRs
-
-   It may be observed that in section 3.2.1 of RFC1035, which defines
-   the format of a Resource Record, that the definition of the TTL field
-   contains a throw away line which states that the TTL of an SOA record
-   should always be sent as zero to prevent caching.  This is mentioned
-   nowhere else, and has not generally been implemented.
-   Implementations should not assume that SOA records will have a TTL of
-   zero, nor are they required to send SOA records with a TTL of zero.
-
-7.3. The SOA.MNAME field
-
-   It is quite clear in the specifications, yet seems to have been
-   widely ignored, that the MNAME field of the SOA record should contain
-   the name of the primary (master) server for the zone identified by
-   the SOA.  It should not contain the name of the zone itself.  That
-   information would be useless, as to discover it, one needs to start
-   with the domain name of the SOA record - that is the name of the
-   zone.
-
-8. Time to Live (TTL)
-
-   The definition of values appropriate to the TTL field in STD 13 is
-   not as clear as it could be, with respect to how many significant
-   bits exist, and whether the value is signed or unsigned.  It is
-   hereby specified that a TTL value is an unsigned number, with a
-   minimum value of 0, and a maximum value of 2147483647.  That is, a
-   maximum of 2^31 - 1.  When transmitted, this value shall be encoded
-   in the less significant 31 bits of the 32 bit TTL field, with the
-
-
-
-Elz & Bush                  Standards Track                    [Page 10]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   most significant, or sign, bit set to zero.
-
-   Implementations should treat TTL values received with the most
-   significant bit set as if the entire value received was zero.
-
-   Implementations are always free to place an upper bound on any TTL
-   received, and treat any larger values as if they were that upper
-   bound.  The TTL specifies a maximum time to live, not a mandatory
-   time to live.
-
-9. The TC (truncated) header bit
-
-   The TC bit should be set in responses only when an RRSet is required
-   as a part of the response, but could not be included in its entirety.
-   The TC bit should not be set merely because some extra information
-   could have been included, but there was insufficient room.  This
-   includes the results of additional section processing.  In such cases
-   the entire RRSet that will not fit in the response should be omitted,
-   and the reply sent as is, with the TC bit clear.  If the recipient of
-   the reply needs the omitted data, it can construct a query for that
-   data and send that separately.
-
-   Where TC is set, the partial RRSet that would not completely fit may
-   be left in the response.  When a DNS client receives a reply with TC
-   set, it should ignore that response, and query again, using a
-   mechanism, such as a TCP connection, that will permit larger replies.
-
-10. Naming issues
-
-   It has sometimes been inferred from some sections of the DNS
-   specification [RFC1034, RFC1035] that a host, or perhaps an interface
-   of a host, is permitted exactly one authoritative, or official, name,
-   called the canonical name.  There is no such requirement in the DNS.
-
-10.1. CNAME resource records
-
-   The DNS CNAME ("canonical name") record exists to provide the
-   canonical name associated with an alias name.  There may be only one
-   such canonical name for any one alias.  That name should generally be
-   a name that exists elsewhere in the DNS, though there are some rare
-   applications for aliases with the accompanying canonical name
-   undefined in the DNS.  An alias name (label of a CNAME record) may,
-   if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
-   other data.  That is, for any label in the DNS (any domain name)
-   exactly one of the following is true:
-
-
-
-
-
-
-Elz & Bush                  Standards Track                    [Page 11]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-     + one CNAME record exists, optionally accompanied by SIG, NXT, and
-       KEY RRs,
-     + one or more records exist, none being CNAME records,
-     + the name exists, but has no associated RRs of any type,
-     + the name does not exist at all.
-
-10.1.1. CNAME terminology
-
-   It has been traditional to refer to the label of a CNAME record as "a
-   CNAME".  This is unfortunate, as "CNAME" is an abbreviation of
-   "canonical name", and the label of a CNAME record is most certainly
-   not a canonical name.  It is, however, an entrenched usage.  Care
-   must therefore be taken to be very clear whether the label, or the
-   value (the canonical name) of a CNAME resource record is intended.
-   In this document, the label of a CNAME resource record will always be
-   referred to as an alias.
-
-10.2. PTR records
-
-   Confusion about canonical names has lead to a belief that a PTR
-   record should have exactly one RR in its RRSet.  This is incorrect,
-   the relevant section of RFC1034 (section 3.6.2) indicates that the
-   value of a PTR record should be a canonical name.  That is, it should
-   not be an alias.  There is no implication in that section that only
-   one PTR record is permitted for a name.  No such restriction should
-   be inferred.
-
-   Note that while the value of a PTR record must not be an alias, there
-   is no requirement that the process of resolving a PTR record not
-   encounter any aliases.  The label that is being looked up for a PTR
-   value might have a CNAME record.  That is, it might be an alias.  The
-   value of that CNAME RR, if not another alias, which it should not be,
-   will give the location where the PTR record is found.  That record
-   gives the result of the PTR type lookup.  This final result, the
-   value of the PTR RR, is the label which must not be an alias.
-
-10.3. MX and NS records
-
-   The domain name used as the value of a NS resource record, or part of
-   the value of a MX resource record must not be an alias.  Not only is
-   the specification clear on this point, but using an alias in either
-   of these positions neither works as well as might be hoped, nor well
-   fulfills the ambition that may have led to this approach.  This
-   domain name must have as its value one or more address records.
-   Currently those will be A records, however in the future other record
-   types giving addressing information may be acceptable.  It can also
-   have other RRs, but never a CNAME RR.
-
-
-
-
-Elz & Bush                  Standards Track                    [Page 12]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   Searching for either NS or MX records causes "additional section
-   processing" in which address records associated with the value of the
-   record sought are appended to the answer.  This helps avoid needless
-   extra queries that are easily anticipated when the first was made.
-
-   Additional section processing does not include CNAME records, let
-   alone the address records that may be associated with the canonical
-   name derived from the alias.  Thus, if an alias is used as the value
-   of an NS or MX record, no address will be returned with the NS or MX
-   value.  This can cause extra queries, and extra network burden, on
-   every query.  It is trivial for the DNS administrator to avoid this
-   by resolving the alias and placing the canonical name directly in the
-   affected record just once when it is updated or installed.  In some
-   particular hard cases the lack of the additional section address
-   records in the results of a NS lookup can cause the request to fail.
-
-11. Name syntax
-
-   Occasionally it is assumed that the Domain Name System serves only
-   the purpose of mapping Internet host names to data, and mapping
-   Internet addresses to host names.  This is not correct, the DNS is a
-   general (if somewhat limited) hierarchical database, and can store
-   almost any kind of data, for almost any purpose.
-
-   The DNS itself places only one restriction on the particular labels
-   that can be used to identify resource records.  That one restriction
-   relates to the length of the label and the full name.  The length of
-   any one label is limited to between 1 and 63 octets.  A full domain
-   name is limited to 255 octets (including the separators).  The zero
-   length full name is defined as representing the root of the DNS tree,
-   and is typically written and displayed as ".".  Those restrictions
-   aside, any binary string whatever can be used as the label of any
-   resource record.  Similarly, any binary string can serve as the value
-   of any record that includes a domain name as some or all of its value
-   (SOA, NS, MX, PTR, CNAME, and any others that may be added).
-   Implementations of the DNS protocols must not place any restrictions
-   on the labels that can be used.  In particular, DNS servers must not
-   refuse to serve a zone because it contains labels that might not be
-   acceptable to some DNS client programs.  A DNS server may be
-   configurable to issue warnings when loading, or even to refuse to
-   load, a primary zone containing labels that might be considered
-   questionable, however this should not happen by default.
-
-   Note however, that the various applications that make use of DNS data
-   can have restrictions imposed on what particular values are
-   acceptable in their environment.  For example, that any binary label
-   can have an MX record does not imply that any binary name can be used
-   as the host part of an e-mail address.  Clients of the DNS can impose
-
-
-
-Elz & Bush                  Standards Track                    [Page 13]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   whatever restrictions are appropriate to their circumstances on the
-   values they use as keys for DNS lookup requests, and on the values
-   returned by the DNS.  If the client has such restrictions, it is
-   solely responsible for validating the data from the DNS to ensure
-   that it conforms before it makes any use of that data.
-
-   See also [RFC1123] section 6.1.3.5.
-
-12. Security Considerations
-
-   This document does not consider security.
-
-   In particular, nothing in section 4 is any way related to, or useful
-   for, any security related purposes.
-
-   Section 5.4.1 is also not related to security.  Security of DNS data
-   will be obtained by the Secure DNS [RFC2065], which is mostly
-   orthogonal to this memo.
-
-   It is not believed that anything in this document adds to any
-   security issues that may exist with the DNS, nor does it do anything
-   to that will necessarily lessen them.  Correct implementation of the
-   clarifications in this document might play some small part in
-   limiting the spread of non-malicious bad data in the DNS, but only
-   DNSSEC can help with deliberate attempts to subvert DNS data.
-
-13. References
-
-   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and Facilities",
-               STD 13, RFC 1034, November 1987.
-
-   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
-               Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1123]   Braden, R., "Requirements for Internet Hosts - application
-               and support", STD 3, RFC 1123, January 1989.
-
-   [RFC1700]   Reynolds, J., Postel, J., "Assigned Numbers",
-               STD 2, RFC 1700, October 1994.
-
-   [RFC2065]   Eastlake, D., Kaufman, C., "Domain Name System Security
-               Extensions", RFC 2065, January 1997.
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                    [Page 14]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-14. Acknowledgements
-
-   This memo arose from discussions in the DNSIND working group of the
-   IETF in 1995 and 1996, the members of that working group are largely
-   responsible for the ideas captured herein.  Particular thanks to
-   Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
-   DNSSEC issues in this document, and to John Gilmore for pointing out
-   where the clarifications were not necessarily clarifying.  Bob Halley
-   suggested clarifying the placement of SOA records in authoritative
-   answers, and provided the references.  Michael Patton, as usual, and
-   Mark Andrews, Alan Barrett and Stan Barber provided much assistance
-   with many details.  Josh Littlefield helped make sure that the
-   clarifications didn't cause problems in some irritating corner cases.
-
-15. Authors' Addresses
-
-   Robert Elz
-   Computer Science
-   University of Melbourne
-   Parkville, Victoria, 3052
-   Australia.
-
-   EMail: kre@munnari.OZ.AU
-
-
-   Randy Bush
-   RGnet, Inc.
-   5147 Crystal Springs Drive NE
-   Bainbridge Island, Washington,  98110
-   United States.
-
-   EMail: randy@psg.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                    [Page 15]
diff --git a/doc/rfc/rfc2230.txt b/doc/rfc/rfc2230.txt
deleted file mode 100644
index 03995fe2..00000000
--- a/doc/rfc/rfc2230.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Atkinson
-Request for Comments: 2230                                            NRL
-Category: Informational                                     November 1997
-
-
-               Key Exchange Delegation Record for the DNS
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1997).  All Rights Reserved.
-
-ABSTRACT
-
-   This note describes a mechanism whereby authorisation for one node to
-   act as key exchanger for a second node is delegated and made
-   available via the Secure DNS.  This mechanism is intended to be used
-   only with the Secure DNS.  It can be used with several security
-   services.  For example, a system seeking to use IP Security [RFC-
-   1825, RFC-1826, RFC-1827] to protect IP packets for a given
-   destination can use this mechanism to determine the set of authorised
-   remote key exchanger systems for that destination.
-
-1. INTRODUCTION
-
-
-   The Domain Name System (DNS) is the standard way that Internet nodes
-   locate information about addresses, mail exchangers, and other data
-   relating to remote Internet nodes. [RFC-1035, RFC-1034] More
-   recently, Eastlake and Kaufman have defined standards-track security
-   extensions to the DNS. [RFC-2065] These security extensions can be
-   used to authenticate signed DNS data records and can also be used to
-   store signed public keys in the DNS.
-
-   The KX record is useful in providing an authenticatible method of
-   delegating authorisation for one node to provide key exchange
-   services on behalf of one or more, possibly different, nodes.  This
-   note specifies the syntax and semantics of the KX record, which is
-   currently in limited deployment in certain IP-based networks.  The
-
-
-
-
-
-
-
-Atkinson                     Informational                      [Page 1]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   reader is assumed to be familiar with the basics of DNS, including
-   familiarity with [RFC-1035, RFC-1034].  This document is not on the
-   IETF standards-track and does not specify any level of standard.
-   This document merely provides information for the Internet community.
-
-1.1 Identity Terminology
-
-   This document relies upon the concept of "identity domination".  This
-   concept might be new to the reader and so is explained in this
-   section.  The subject of endpoint naming for security associations
-   has historically been somewhat contentious.  This document takes no
-   position on what forms of identity should be used.  In a network,
-   there are several forms of identity that are possible.
-
-   For example, IP Security has defined notions of identity that
-   include: IP Address, IP Address Range, Connection ID, Fully-Qualified
-   Domain Name (FQDN), and User with Fully Qualified Domain Name (USER
-   FQDN).
-
-   A USER FQDN identity dominates a FQDN identity.  A FQDN identity in
-   turn dominates an IP Address identity.  Similarly, a Connection ID
-   dominates an IP Address identity.  An IP Address Range dominates each
-   IP Address identity for each IP address within that IP address range.
-   Also, for completeness, an IP Address identity is considered to
-   dominate itself.
-
-2. APPROACH
-
-   This document specifies a new kind of DNS Resource Record (RR), known
-   as the Key Exchanger (KX) record.  A Key Exchanger Record has the
-   mnemonic "KX" and the type code of 36.  Each KX record is associated
-   with a fully-qualified domain name.  The KX record is modeled on the
-   MX record described in [Part86]. Any given domain, subdomain, or host
-   entry in the DNS might have a KX record.
-
-2.1 IPsec Examples
-
-   In these two examples, let S be the originating node and let D be the
-   destination node.  S2 is another node on the same subnet as S.  D2 is
-   another node on the same subnet as D.  R1 and R2 are IPsec-capable
-   routers.  The path from S to D goes via first R1 and later R2.  The
-   return path from D to S goes via first R2 and later R1.
-
-   IETF-standard IP Security uses unidirectional Security Associations
-   [RFC-1825].  Therefore, a typical IP session will use a pair of
-   related Security Associations, one in each direction.  The examples
-   below talk about how to setup an example Security Association, but in
-   practice a pair of matched Security Associations will normally be
-
-
-
-Atkinson                     Informational                      [Page 2]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   used.
-
-2.1.1 Subnet-to-Subnet Example
-
-   If neither S nor D implements IPsec, security can still be provided
-   between R1 and R2 by building a secure tunnel.  This can use either
-   AH or ESP.
-
-       S ---+                                          +----D
-            |                                          |
-            +- R1 -----[zero or more routers]-------R2-+
-            |                                          |
-       S2---+                                          +----D2
-
-       Figure 1:  Network Diagram for Subnet-to-Subnet Example
-
-   In this example, R1 makes the policy decision to provide the IPsec
-   service for traffic from R1 destined for R2.  Once R1 has decided
-   that the packet from S to D should be protected, it performs a secure
-   DNS lookup for the records associated with domain D.  If R1 only
-   knows the IP address for D, then a secure reverse DNS lookup will be
-   necessary to determine the domain D, before that forward secure DNS
-   lookup for records associated with domain D.  If these DNS records of
-   domain D include a KX record for the IPsec service, then R1 knows
-   which set of nodes are authorised key exchanger nodes for the
-   destination D.
-
-   In this example, let there be at least one KX record for D and let
-   the most preferred KX record for D point at R2.  R1 then selects a
-   key exchanger (in this example, R2) for D from the list obtained from
-   the secure DNS.  Then R1 initiates a key management session with that
-   key exchanger (in this example, R2) to setup an IPsec Security
-   Association between R1 and D.  In this example, R1 knows (either by
-   seeing an outbound packet arriving from S destined to D or via other
-   methods) that S will be sending traffic to D.  In this example R1's
-   policy requires that traffic from S to D should be segregated at
-   least on a host-to-host basis, so R1 desires an IPsec Security
-   Association with source identity that dominates S, proxy identity
-   that dominates R1, and destination identity that dominates R2.
-
-   In turn, R2 is able to authenticate the delegation of Key Exchanger
-   authorisation for target S to R1 by making an authenticated forward
-   DNS lookup for KX records associated with S and verifying that at
-   least one such record points to R1.  The identity S is typically
-   given to R2 as part of the key management process between R1 and R2.
-
-
-
-
-
-
-Atkinson                     Informational                      [Page 3]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   If D initially only knows the IP address of S, then it will need to
-   perform a secure reverse DNS lookup to obtain the fully-qualified
-   domain name for S prior to that secure forward DNS lookup.
-
-   If R2 does not receive an authenticated DNS response indicating that
-   R1 is an authorised key exchanger for S, then D will not accept the
-   SA negotiation from R1 on behalf of identity S.
-
-   If the proposed IPsec Security Association is acceptable to both R1
-   and R2, each of which might have separate policies, then they create
-   that IPsec Security Association via Key Management.
-
-   Note that for unicast traffic, Key Management will typically also
-   setup a separate (but related) IPsec Security Association for the
-   return traffic.  That return IPsec Security Association will have
-   equivalent identities.  In this example, that return IPsec Security
-   Association will have a source identity that dominates D, a proxy
-   identity that dominates R2, and a destination identity that dominates
-   R1.
-
-   Once the IPsec Security Association has been created, then R1 uses it
-   to protect traffic from S destined for D via a secure tunnel that
-   originates at R1 and terminates at R2.  For the case of unicast, R2
-   will use the return IPsec Security Association to protect traffic
-   from D destined for S via a secure tunnel that originates at R2 and
-   terminates at R1.
-
-2.1.2 Subnet-to-Host Example
-
-   Consider the case where D and R1 implement IPsec, but S does not
-   implement IPsec, which is an interesting variation on the previous
-   example.  This example is shown in Figure 2 below.
-
-       S ---+
-            |
-            +- R1 -----[zero or more routers]-------D
-            |
-       S2---+
-
-       Figure 2:  Network Diagram for Subnet-to-Host Example
-
-   In this example, R1 makes the policy decision that IP Security is
-   needed for the packet travelling from S to D.  Then, R1 performs the
-   secure DNS lookup for D and determines that D is its own key
-   exchanger, either from the existence of a KX record for D pointing to
-   D or from an authenticated DNS response indicating that no KX record
-   exists for D.  If R1 does not initially know the domain name of D,
-   then prior to the above forward secure DNS lookup, R1 performs a
-
-
-
-Atkinson                     Informational                      [Page 4]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   secure reverse DNS lookup on the IP address of D to determine the
-   fully-qualified domain name for that IP address.  R1 then initiates
-   key management with D to create an IPsec Security Association on
-   behalf of S.
-
-   In turn, D can verify that R1 is authorised to create an IPsec
-   Security Association on behalf of S by performing a DNS KX record
-   lookup for target S.  R1 usually provides identity S to D via key
-   management.  If D only has the IP address of S, then D will need to
-   perform a secure reverse lookup on the IP address of S to determine
-   domain name S prior to the secure forward DNS lookup on S to locate
-   the KX records for S.
-
-   If D does not receive an authenticated DNS response indicating that
-   R1 is an authorised key exchanger for S, then D will not accept the
-   SA negotiation from R1 on behalf of identity S.
-
-   If the IPsec Security Association is successfully established between
-   R1 and D, that IPsec Security Association has a source identity that
-   dominates S's IP address, a proxy identity that dominates R1's IP
-   address, and a destination identity that dominates D's IP address.
-
-   Finally, R1 begins providing the security service for packets from S
-   that transit R1 destined for D.  When D receives such packets, D
-   examines the SA information during IPsec input processing and sees
-   that R1's address is listed as valid proxy address for that SA and
-   that S is the source address for that SA.  Hence, D knows at input
-   processing time that R1 is authorised to provide security on behalf
-   of S.  Therefore packets coming from R1 with valid IP security that
-   claim to be from S are trusted by D to have really come from S.
-
-2.1.3 Host to Subnet Example
-
-   Now consider the above case from D's perspective (i.e. where D is
-   sending IP packets to S).  This variant is sometimes known as the
-   Mobile Host or "roadwarrier" case. The same basic concepts apply, but
-   the details are covered here in hope of improved clarity.
-
-       S ---+
-            |
-            +- R1 -----[zero or more routers]-------D
-            |
-       S2---+
-
-       Figure 3:  Network Diagram for Host-to-Subnet Example
-
-
-
-
-
-
-Atkinson                     Informational                      [Page 5]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   In this example, D makes the policy decision that IP Security is
-   needed for the packets from D to S.  Then D performs the secure DNS
-   lookup for S and discovers that a KX record for S exists and points
-   at R1.  If D only has the IP address of S, then it performs a secure
-   reverse DNS lookup on the IP address of S prior to the forward secure
-   DNS lookup for S.
-
-   D then initiates key management with R1, where R1 is acting on behalf
-   of S, to create an appropriate Security Association.  Because D is
-   acting as its own key exchanger, R1 does not need to perform a secure
-   DNS lookup for KX records associated with D.
-
-   D and R1 then create an appropriate IPsec Security Security
-   Association.  This IPsec Security Association is setup as a secure
-   tunnel with a source identity that dominates D's IP Address and a
-   destination identity that dominates R1's IP Address.  Because D
-   performs IPsec for itself, no proxy identity is needed in this IPsec
-   Security Association.  If the proxy identity is non-null in this
-   situation, then the proxy identity must dominate D's IP Address.
-
-   Finally, D sends secured IP packets to R1.  R1 receives those
-   packets, provides IPsec input processing (including appropriate
-   inner/outer IP address validation), and forwards valid packets along
-   to S.
-
-2.2 Other Examples
-
-   This mechanism can be extended for use with other services as well.
-   To give some insight into other possible uses, this section discusses
-   use of KX records in environments using a Key Distribution Center
-   (KDC), such as Kerberos [KN93], and a possible use of KX records in
-   conjunction with mobile nodes accessing the network via a dialup
-   service.
-
-2.2.1 KDC Examples
-
-   This example considers the situation of a destination node
-   implementing IPsec that can only obtain its Security Association
-   information from a Key Distribution Center (KDC).  Let the KDC
-   implement both the KDC protocol and also a non-KDC key management
-   protocol (e.g. ISAKMP).  In such a case, each client node of the KDC
-   might have its own KX record pointing at the KDC so that nodes not
-   implementing the KDC protocol can still create Security Associations
-   with each of the client nodes of the KDC.
-
-   In the event the session initiator were not using the KDC but the
-   session target was an IPsec node that only used the KDC, the
-   initiator would find the KX record for the target pointing at the
-
-
-
-Atkinson                     Informational                      [Page 6]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   KDC.  Then, the external key management exchange (e.g. ISAKMP) would
-   be between the initiator and the KDC.  Then the KDC would distribute
-   the IPsec SA to the KDC-only IPsec node using the KDC.  The IPsec
-   traffic itself could travel directly between the initiator and the
-   destination node.
-
-   In the event the initiator node could only use the KDC and the target
-   were not using the KDC, the initiator would send its request for a
-   key to the KDC.  The KDC would then initiate an external key
-   management exchange (e.g. ISAKMP) with a node that the target's KX
-   record(s) pointed to, on behalf of the initiator node.
-
-   The target node could verify that the KDC were allowed to proxy for
-   the initiator node by looking up the KX records for the initiator
-   node and finding a KX record for the initiator that listed the KDC.
-
-   Then the external key exchange would be performed between the KDC and
-   the target node.  Then the KDC would distribute the resulting IPsec
-   Security Association to the initiator.  Again, IPsec traffic itself
-   could travel directly between the initiator and the destination.
-
-2.2.2 Dial-Up Host Example
-
-   This example outlines a possible use of KX records with mobile hosts
-   that dial into the network via PPP and are dynamically assigned an IP
-   address and domain-name at dial-in time.
-
-   Consider the situation where each mobile node is dynamically assigned
-   both a domain name and an IP address at the time that node dials into
-   the network.  Let the policy require that each mobile node act as its
-   own Key Exchanger.  In this case, it is important that dial-in nodes
-   use addresses from one or more well known IP subnets or address pools
-   dedicated to dial-in access.  If that is true, then no KX record or
-   other action is needed to ensure that each node will act as its own
-   Key Exchanger because lack of a KX record indicates that the node is
-   its own Key Exchanger.
-
-   Consider the situation where the mobile node's domain name remains
-   constant but its IP address changes.  Let the policy require that
-   each mobile node act as its own Key Exchanger.  In this case, there
-   might be operational problems when another node attempts to perform a
-   secure reverse DNS lookup on the IP address to determine the
-   corresponding domain name.  The authenticated DNS binding (in the
-   form of a PTR record) between the mobile node's currently assigned IP
-   address and its permanent domain name will need to be securely
-   updated each time the node is assigned a new IP address.  There are
-   no mechanisms for accomplishing this that are both IETF-standard and
-   widely deployed as of the time this note was written.  Use of Dynamic
-
-
-
-Atkinson                     Informational                      [Page 7]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   DNS Update without authentication is a significant security risk and
-   hence is not recommended for this situation.
-
-3. SYNTAX OF KX RECORD
-
-   A KX record has the DNS TYPE of "KX" and a numeric value of 36.  A KX
-   record is a member of the Internet ("IN") CLASS in the DNS.  Each KX
-   record is associated with a <domain-name> entry in the DNS.  A KX
-   record has the following textual syntax:
-
-        <domain-name>  IN  KX  <preference> <domain-name>
-
-   For this description, let the <domain-name> item to the left of the
-   "KX" string be called <domain-name 1> and the <domain-name> item to
-   the right of the "KX" string be called <domain-name 2>.  <preference>
-   is a non-negative integer.
-
-   Internet nodes about to initiate a key exchange with <domain-name 1>
-   should instead contact <domain-name 2> to initiate the key exchange
-   for a security service between the initiator and <domain-name 2>.  If
-   more than one KX record exists for <domain-name 1>, then the
-   <preference> field is used to indicate preference among the systems
-   delegated to.  Lower values are preferred over higher values.  The
-   <domain-name 2> is authorised to provide key exchange services on
-   behalf of <domain-name 1>.  The <domain-name 2> MUST have a CNAME
-   record, an A record, or an AAAA record associated with it.
-
-3.1 KX RDATA format
-
-   The KX DNS record has the following RDATA format:
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                  PREFERENCE                   |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   EXCHANGER                   /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-   PREFERENCE      A 16 bit non-negative integer which specifies the
-                   preference given to this RR among other KX records
-                   at the same owner.  Lower values are preferred.
-
-   EXCHANGER       A <domain-name> which specifies a host willing to
-                   act as a mail exchange for the owner name.
-
-
-
-
-
-Atkinson                     Informational                      [Page 8]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   KX records MUST cause type A additional section processing for the
-   host specified by EXCHANGER.  In the event that the host processing
-   the DNS transaction supports IPv6, KX records MUST also cause type
-   AAAA additional section processing.
-
-   The KX RDATA field MUST NOT be compressed.
-
-4. SECURITY CONSIDERATIONS
-
-   KX records MUST always be signed using the method(s) defined by the
-   DNS Security extensions specified in [RFC-2065].  All unsigned KX
-   records MUST be ignored because of the security vulnerability caused
-   by assuming that unsigned records are valid.  All signed KX records
-   whose signatures do not correctly validate MUST be ignored because of
-   the potential security vulnerability in trusting an invalid KX
-   record.
-
-   KX records MUST be ignored by systems not implementing Secure DNS
-   because such systems have no mechanism to authenticate the KX record.
-
-   If a node does not have a permanent DNS entry and some form of
-   Dynamic DNS Update is in use, then those dynamic DNS updates MUST be
-   fully authenticated to prevent an adversary from injecting false DNS
-   records (especially the KX, A, and PTR records) into the Domain Name
-   System.  If false records were inserted into the DNS without being
-   signed by the Secure DNS mechanisms, then a denial-of-service attack
-   results.  If false records were inserted into the DNS and were
-   (erroneously) signed by the signing authority, then an active attack
-   results.
-
-   Myriad serious security vulnerabilities can arise if the restrictions
-   throuhout this document are not strictly adhered to.  Implementers
-   should carefully consider the openly published issues relating to DNS
-   security [Bell95,Vixie95] as they build their implementations.
-   Readers should also consider the security considerations discussed in
-   the DNS Security Extensions document [RFC-2065].
-
-5. REFERENCES
-
-
-   [RFC-1825]  Atkinson, R., "IP Authentication Header", RFC 1826,
-               August 1995.
-
-   [RFC-1827]  Atkinson, R., "IP Encapsulating Security Payload",
-               RFC 1827, August 1995.
-
-
-
-
-
-
-Atkinson                     Informational                      [Page 9]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   [Bell95] Bellovin, S., "Using the Domain Name System for System
-            Break-ins", Proceedings of 5th USENIX UNIX Security
-            Symposium, USENIX Association, Berkeley, CA, June 1995.
-            ftp://ftp.research.att.com/dist/smb/dnshack.ps
-
-   [RFC-2065]  Eastlake, D., and C. Kaufman, "Domain Name System
-               Security Extensions", RFC 2065, January 1997.
-
-   [RFC-1510]  Kohl J., and C. Neuman, "The Kerberos Network
-               Authentication Service", RFC 1510, September 1993.
-
-   [RFC-1035]  Mockapetris, P., "Domain names - implementation and
-               specification", STD 13, RFC 1035, November 1987.
-
-   [RFC-1034]  Mockapetris, P., "Domain names - concepts and
-               facilities", STD 13, RFC 1034, November 1987.
-
-   [Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of
-             the 5th USENIX UNIX Security Symposium, USENIX
-             Association, Berkeley, CA, June 1995.
-             ftp://ftp.vix.com/pri/vixie/bindsec.psf
-
-ACKNOWLEDGEMENTS
-
-   Development of this DNS record was primarily performed during 1993
-   through 1995.  The author's work on this was sponsored jointly by the
-   Computing Systems Technology Office (CSTO) of the Advanced Research
-   Projects Agency (ARPA) and by the Information Security Program Office
-   (PD71E), Space & Naval Warface Systems Command (SPAWAR).  In that
-   era, Dave Mihelcic and others provided detailed review and
-   constructive feedback.  More recently, Bob Moscowitz and Todd Welch
-   provided detailed review and constructive feedback of a work in
-   progress version of this document.
-
-AUTHOR'S ADDRESS
-
-   Randall Atkinson
-   Code 5544
-   Naval Research Laboratory
-   4555 Overlook Avenue, SW
-   Washington, DC 20375-5337
-
-   Phone: (DSN) 354-8590
-   EMail: atkinson@itd.nrl.navy.mil
-
-
-
-
-
-
-
-Atkinson                     Informational                     [Page 10]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1997).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implmentation may be prepared, copied, published
-   andand distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Atkinson                     Informational                     [Page 11]
-
diff --git a/doc/rfc/rfc2308.txt b/doc/rfc/rfc2308.txt
deleted file mode 100644
index 9123a952..00000000
--- a/doc/rfc/rfc2308.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          M. Andrews
-Request for Comments: 2308                                          CSIRO
-Updates: 1034, 1035                                            March 1998
-Category: Standards Track
-
-
-              Negative Caching of DNS Queries (DNS NCACHE)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   [RFC1034] provided a description of how to cache negative responses.
-   It however had a fundamental flaw in that it did not allow a name
-   server to hand out those cached responses to other resolvers, thereby
-   greatly reducing the effect of the caching.  This document addresses
-   issues raise in the light of experience and replaces [RFC1034 Section
-   4.3.4].
-
-   Negative caching was an optional part of the DNS specification and
-   deals with the caching of the non-existence of an RRset [RFC2181] or
-   domain name.
-
-   Negative caching is useful as it reduces the response time for
-   negative answers.  It also reduces the number of messages that have
-   to be sent between resolvers and name servers hence overall network
-   traffic.  A large proportion of DNS traffic on the Internet could be
-   eliminated if all resolvers implemented negative caching.  With this
-   in mind negative caching should no longer be seen as an optional part
-   of a DNS resolver.
-
-
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                     [Page 1]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-1 - Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   "Negative caching" - the storage of knowledge that something does not
-   exist.  We can store the knowledge that a record has a particular
-   value.  We can also do the reverse, that is, to store the knowledge
-   that a record does not exist.  It is the storage of knowledge that
-   something does not exist, cannot or does not give an answer that we
-   call negative caching.
-
-   "QNAME" - the name in the query section of an answer, or where this
-   resolves to a CNAME, or CNAME chain, the data field of the last
-   CNAME.  The last CNAME in this sense is that which contains a value
-   which does not resolve to another CNAME.  Implementations should note
-   that including CNAME records in responses in order, so that the first
-   has the label from the query section, and then each in sequence has
-   the label from the data section of the previous (where more than one
-   CNAME is needed) allows the sequence to be processed in one pass, and
-   considerably eases the task of the receiver.  Other relevant records
-   (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
-
-   "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
-   described in [RFC1035 Section 4.1.1] and the two terms are used
-   interchangeably in this document.
-
-   "NODATA" - a pseudo RCODE which indicates that the name is valid, for
-   the given class, but are no records of the given type.  A NODATA
-   response has to be inferred from the answer.
-
-   "FORWARDER" - a nameserver used to resolve queries instead of
-   directly using the authoritative nameserver chain.  The forwarder
-   typically either has better access to the internet, or maintains a
-   bigger cache which may be shared amongst many resolvers.  How a
-   server is identified as a FORWARDER, or knows it is a FORWARDER is
-   outside the scope of this document.  However if you are being used as
-   a forwarder the query will have the recursion desired flag set.
-
-   An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected
-   when reading this document.
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                     [Page 2]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-2 - Negative Responses
-
-   The most common negative responses indicate that a particular RRset
-   does not exist in the DNS.  The first sections of this document deal
-   with this case.  Other negative responses can indicate failures of a
-   nameserver, those are dealt with in section 7 (Other Negative
-   Responses).
-
-   A negative response is indicated by one of the following conditions:
-
-2.1 - Name Error
-
-   Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
-   in the RCODE field.  In this case the domain referred to by the QNAME
-   does not exist.  Note: the answer section may have SIG and CNAME RRs
-   and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
-
-   It is possible to distinguish between a referral and a NXDOMAIN
-   response by the presense of NXDOMAIN in the RCODE regardless of the
-   presence of NS or SOA records in the authority section.
-
-   NXDOMAIN responses can be categorised into four types by the contents
-   of the authority section.  These are shown below along with a
-   referral for comparison.  Fields not mentioned are not important in
-   terms of the examples.
-
-           NXDOMAIN RESPONSE: TYPE 1.
-
-           Header:
-               RDCODE=NXDOMAIN
-           Query:
-               AN.EXAMPLE. A
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
-               XX. NS NS1.XX.
-               XX. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-               NS2.XX. A 127.0.0.3
-
-           NXDOMAIN RESPONSE: TYPE 2.
-
-           Header:
-               RDCODE=NXDOMAIN
-           Query:
-               AN.EXAMPLE. A
-
-
-
-Andrews                     Standards Track                     [Page 3]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
-           Additional:
-               <empty>
-
-           NXDOMAIN RESPONSE: TYPE 3.
-
-           Header:
-               RDCODE=NXDOMAIN
-           Query:
-               AN.EXAMPLE. A
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               <empty>
-           Additional:
-               <empty>
-
-           NXDOMAIN RESPONSE: TYPE 4
-
-           Header:
-               RDCODE=NXDOMAIN
-           Query:
-               AN.EXAMPLE. A
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               XX. NS NS1.XX.
-               XX. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-               NS2.XX. A 127.0.0.3
-
-           REFERRAL RESPONSE.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               AN.EXAMPLE. A
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               XX. NS NS1.XX.
-               XX. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-
-
-
-Andrews                     Standards Track                     [Page 4]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-               NS2.XX. A 127.0.0.3
-
-   Note, in the four examples of NXDOMAIN responses, it is known that
-   the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
-   The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
-   exist.  On the other hand, in the referral example, it is shown that
-   "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
-   known one way or the other about the existence of "TRIPPLE.XX", other
-   than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
-   obtaining information about it.
-
-   Where no CNAME records appear, the NXDOMAIN response refers to the
-   name in the label of the RR in the question section.
-
-2.1.1 Special Handling of Name Error
-
-   This section deals with errors encountered when implementing negative
-   caching of NXDOMAIN responses.
-
-   There are a large number of resolvers currently in existence that
-   fail to correctly detect and process all forms of NXDOMAIN response.
-   Some resolvers treat a TYPE 1 NXDOMAIN response as a referral.  To
-   alleviate this problem it is recommended that servers that are
-   authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
-   responses, that is the authority section contains a SOA record and no
-   NS records.  If a non- authoritative server sends a type 1 NXDOMAIN
-   response to one of these old resolvers, the result will be an
-   unnecessary query to an authoritative server.  This is undesirable,
-   but not fatal except when the server is being used a FORWARDER.  If
-   however the resolver is using the server as a FORWARDER to such a
-   resolver it will be necessary to disable the sending of TYPE 1
-   NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.
-
-   Some resolvers incorrectly continue processing if the authoritative
-   answer flag is not set, looping until the query retry threshold is
-   exceeded and then returning SERVFAIL.  This is a problem when your
-   nameserver is listed as a FORWARDER for such resolvers.  If the
-   nameserver is used as a FORWARDER by such resolver, the authority
-   flag will have to be forced on for NXDOMAIN responses to these
-   resolvers.  In practice this causes no problems even if turned on
-   always, and has been the default behaviour in BIND from 4.9.3
-   onwards.
-
-2.2 - No Data
-
-   NODATA is indicated by an answer with the RCODE set to NOERROR and no
-   relevant answers in the answer section.  The authority section will
-   contain an SOA record, or there will be no NS records there.
-
-
-
-Andrews                     Standards Track                     [Page 5]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   NODATA responses have to be algorithmically determined from the
-   response's contents as there is no RCODE value to indicate NODATA.
-   In some cases to determine with certainty that NODATA is the correct
-   response it can be necessary to send another query.
-
-   The authority section may contain NXT and SIG RRsets in addition to
-   NS and SOA records.  CNAME and SIG records may exist in the answer
-   section.
-
-   It is possible to distinguish between a NODATA and a referral
-   response by the presence of a SOA record in the authority section or
-   the absence of NS records in the authority section.
-
-   NODATA responses can be categorised into three types by the contents
-   of the authority section.  These are shown below along with a
-   referral for comparison.  Fields not mentioned are not important in
-   terms of the examples.
-
-           NODATA RESPONSE: TYPE 1.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               ANOTHER.EXAMPLE. A
-           Answer:
-               <empty>
-           Authority:
-               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
-               EXAMPLE. NS NS1.XX.
-               EXAMPLE. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-               NS2.XX. A 127.0.0.3
-
-           NO DATA RESPONSE: TYPE 2.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               ANOTHER.EXAMPLE. A
-           Answer:
-               <empty>
-           Authority:
-               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
-           Additional:
-               <empty>
-
-
-
-
-
-Andrews                     Standards Track                     [Page 6]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-           NO DATA RESPONSE: TYPE 3.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               ANOTHER.EXAMPLE. A
-           Answer:
-               <empty>
-           Authority:
-               <empty>
-           Additional:
-               <empty>
-
-           REFERRAL RESPONSE.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               ANOTHER.EXAMPLE. A
-           Answer:
-               <empty>
-           Authority:
-               EXAMPLE. NS NS1.XX.
-               EXAMPLE. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-               NS2.XX. A 127.0.0.3
-
-
-   These examples, unlike the NXDOMAIN examples above, have no CNAME
-   records, however they could, in just the same way that the NXDOMAIN
-   examples did, in which case it would be the value of the last CNAME
-   (the QNAME) for which NODATA would be concluded.
-
-2.2.1 - Special Handling of No Data
-
-   There are a large number of resolvers currently in existence that
-   fail to correctly detect and process all forms of NODATA response.
-   Some resolvers treat a TYPE 1 NODATA response as a referral.  To
-   alleviate this problem it is recommended that servers that are
-   authoritative for the NODATA response only send TYPE 2 NODATA
-   responses, that is the authority section contains a SOA record and no
-   NS records.  Sending a TYPE 1 NODATA response from a non-
-   authoritative server to one of these resolvers will only result in an
-   unnecessary query.  If a server is listed as a FORWARDER for another
-   resolver it may also be necessary to disable the sending of TYPE 1
-   NODATA response for non-authoritative NODATA responses.
-
-
-
-
-Andrews                     Standards Track                     [Page 7]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   Some name servers fail to set the RCODE to NXDOMAIN in the presence
-   of CNAMEs in the answer section.  If a definitive NXDOMAIN / NODATA
-   answer is required in this case the resolver must query again using
-   the QNAME as the query label.
-
-3 - Negative Answers from Authoritative Servers
-
-   Name servers authoritative for a zone MUST include the SOA record of
-   the zone in the authority section of the response when reporting an
-   NXDOMAIN or indicating that no data of the requested type exists.
-   This is required so that the response may be cached.  The TTL of this
-   record is set from the minimum of the MINIMUM field of the SOA record
-   and the TTL of the SOA itself, and indicates how long a resolver may
-   cache the negative answer.  The TTL SIG record associated with the
-   SOA record should also be trimmed in line with the SOA's TTL.
-
-   If the containing zone is signed [RFC2065] the SOA and appropriate
-   NXT and SIG records MUST be added.
-
-4 - SOA Minimum Field
-
-   The SOA minimum field has been overloaded in the past to have three
-   different meanings, the minimum TTL value of all RRs in a zone, the
-   default TTL of RRs which did not contain a TTL value and the TTL of
-   negative responses.
-
-   Despite being the original defined meaning, the first of these, the
-   minimum TTL value of all RRs in a zone, has never in practice been
-   used and is hereby deprecated.
-
-   The second, the default TTL of RRs which contain no explicit TTL in
-   the master zone file, is relevant only at the primary server.  After
-   a zone transfer all RRs have explicit TTLs and it is impossible to
-   determine whether the TTL for a record was explicitly set or derived
-   from the default after a zone transfer.  Where a server does not
-   require RRs to include the TTL value explicitly, it should provide a
-   mechanism, not being the value of the MINIMUM field of the SOA
-   record, from which the missing TTL values are obtained.  How this is
-   done is implementation dependent.
-
-   The Master File format [RFC 1035 Section 5] is extended to include
-   the following directive:
-
-                           $TTL <TTL> [comment]
-
-
-
-
-
-
-
-Andrews                     Standards Track                     [Page 8]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   All resource records appearing after the directive, and which do not
-   explicitly include a TTL value, have their TTL set to the TTL given
-   in the $TTL directive.  SIG records without a explicit TTL get their
-   TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].
-
-   The remaining of the current meanings, of being the TTL to be used
-   for negative responses, is the new defined meaning of the SOA minimum
-   field.
-
-5 - Caching Negative Answers
-
-   Like normal answers negative answers have a time to live (TTL).  As
-   there is no record in the answer section to which this TTL can be
-   applied, the TTL must be carried by another method.  This is done by
-   including the SOA record from the zone in the authority section of
-   the reply.  When the authoritative server creates this record its TTL
-   is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
-   This TTL decrements in a similar manner to a normal cached answer and
-   upon reaching zero (0) indicates the cached negative answer MUST NOT
-   be used again.
-
-   A negative answer that resulted from a name error (NXDOMAIN) should
-   be cached such that it can be retrieved and returned in response to
-   another query for the same <QNAME, QCLASS> that resulted in the
-   cached negative response.
-
-   A negative answer that resulted from a no data error (NODATA) should
-   be cached such that it can be retrieved and returned in response to
-   another query for the same <QNAME, QTYPE, QCLASS> that resulted in
-   the cached negative response.
-
-   The NXT record, if it exists in the authority section of a negative
-   answer received, MUST be stored such that it can be be located and
-   returned with SOA record in the authority section, as should any SIG
-   records in the authority section.  For NXDOMAIN answers there is no
-   "necessary" obvious relationship between the NXT records and the
-   QNAME.  The NXT record MUST have the same owner name as the query
-   name for NODATA responses.
-
-   Negative responses without SOA records SHOULD NOT be cached as there
-   is no way to prevent the negative responses looping forever between a
-   pair of servers even with a short TTL.
-
-   Despite the DNS forming a tree of servers, with various mis-
-   configurations it is possible to form a loop in the query graph, e.g.
-   two servers listing each other as forwarders, various lame server
-   configurations.  Without a TTL count down a cache negative response
-
-
-
-
-Andrews                     Standards Track                     [Page 9]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   when received by the next server would have its TTL reset.  This
-   negative indication could then live forever circulating between the
-   servers involved.
-
-   As with caching positive responses it is sensible for a resolver to
-   limit for how long it will cache a negative response as the protocol
-   supports caching for up to 68 years.  Such a limit should not be
-   greater than that applied to positive answers and preferably be
-   tunable.  Values of one to three hours have been found to work well
-   and would make sensible a default.  Values exceeding one day have
-   been found to be problematic.
-
-6 - Negative answers from the cache
-
-   When a server, in answering a query, encounters a cached negative
-   response it MUST add the cached SOA record to the authority section
-   of the response with the TTL decremented by the amount of time it was
-   stored in the cache.  This allows the NXDOMAIN / NODATA response to
-   time out correctly.
-
-   If a NXT record was cached along with SOA record it MUST be added to
-   the authority section.  If a SIG record was cached along with a NXT
-   record it SHOULD be added to the authority section.
-
-   As with all answers coming from the cache, negative answers SHOULD
-   have an implicit referral built into the answer.  This enables the
-   resolver to locate an authoritative source.  An implicit referral is
-   characterised by NS records in the authority section referring the
-   resolver towards a authoritative source.  NXDOMAIN types 1 and 4
-   responses contain implicit referrals as does NODATA type 1 response.
-
-7 - Other Negative Responses
-
-   Caching of other negative responses is not covered by any existing
-   RFC.  There is no way to indicate a desired TTL in these responses.
-   Care needs to be taken to ensure that there are not forwarding loops.
-
-7.1 Server Failure (OPTIONAL)
-
-   Server failures fall into two major classes.  The first is where a
-   server can determine that it has been misconfigured for a zone.  This
-   may be where it has been listed as a server, but not configured to be
-   a server for the zone, or where it has been configured to be a server
-   for the zone, but cannot obtain the zone data for some reason.  This
-   can occur either because the zone file does not exist or contains
-   errors, or because another server from which the zone should have
-   been available either did not respond or was unable or unwilling to
-   supply the zone.
-
-
-
-Andrews                     Standards Track                    [Page 10]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   The second class is where the server needs to obtain an answer from
-   elsewhere, but is unable to do so, due to network failures, other
-   servers that don't reply, or return server failure errors, or
-   similar.
-
-   In either case a resolver MAY cache a server failure response.  If it
-   does so it MUST NOT cache it for longer than five (5) minutes, and it
-   MUST be cached against the specific query tuple <query name, type,
-   class, server IP address>.
-
-7.2 Dead / Unreachable Server (OPTIONAL)
-
-   Dead / Unreachable servers are servers that fail to respond in any
-   way to a query or where the transport layer has provided an
-   indication that the server does not exist or is unreachable.  A
-   server may be deemed to be dead or unreachable if it has not
-   responded to an outstanding query within 120 seconds.
-
-   Examples of transport layer indications are:
-
-      ICMP error messages indicating host, net or port unreachable.
-      TCP resets
-      IP stack error messages providing similar indications to those above.
-
-   A server MAY cache a dead server indication.  If it does so it MUST
-   NOT be deemed dead for longer than five (5) minutes.  The indication
-   MUST be stored against query tuple <query name, type, class, server
-   IP address> unless there was a transport layer indication that the
-   server does not exist, in which case it applies to all queries to
-   that specific IP address.
-
-8 - Changes from RFC 1034
-
-   Negative caching in resolvers is no-longer optional, if a resolver
-   caches anything it must also cache negative answers.
-
-   Non-authoritative negative answers MAY be cached.
-
-   The SOA record from the authority section MUST be cached.  Name error
-   indications must be cached against the tuple <query name, QCLASS>.
-   No data indications must be cached against <query name, QTYPE,
-   QCLASS> tuple.
-
-   A cached SOA record must be added to the response.  This was
-   explicitly not allowed because previously the distinction between a
-   normal cached SOA record, and the SOA cached as a result of a
-   negative response was not made, and simply extracting a normal cached
-   SOA and adding that to a cached negative response causes problems.
-
-
-
-Andrews                     Standards Track                    [Page 11]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   The $TTL TTL directive was added to the master file format.
-
-9 - History of Negative Caching
-
-   This section presents a potted history of negative caching in the DNS
-   and forms no part of the technical specification of negative caching.
-
-   It is interesting to note that the same concepts were re-invented in
-   both the CHIVES and BIND servers.
-
-   The history of the early CHIVES work (Section 9.1) was supplied by
-   Rob Austein <sra@epilogue.com> and is reproduced here in the form in
-   which he supplied it [MPA].
-
-   Sometime around the spring of 1985, I mentioned to Paul Mockapetris
-   that our experience with his JEEVES DNS resolver had pointed out the
-   need for some kind of negative caching scheme.  Paul suggested that
-   we simply cache authoritative errors, using the SOA MINIMUM value for
-   the zone that would have contained the target RRs.  I'm pretty sure
-   that this conversation took place before RFC-973 was written, but it
-   was never clear to me whether this idea was something that Paul came
-   up with on the spot in response to my question or something he'd
-   already been planning to put into the document that became RFC-973.
-   In any case, neither of us was entirely sure that the SOA MINIMUM
-   value was really the right metric to use, but it was available and
-   was under the control of the administrator of the target zone, both
-   of which seemed to us at the time to be important feature.
-
-   Late in 1987, I released the initial beta-test version of CHIVES, the
-   DNS resolver I'd written to replace Paul's JEEVES resolver.  CHIVES
-   included a search path mechanism that was used pretty heavily at
-   several sites (including my own), so CHIVES also included a negative
-   caching mechanism based on SOA MINIMUM values.  The basic strategy
-   was to cache authoritative error codes keyed by the exact query
-   parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the
-   SOA MINIMUM value.  CHIVES did not attempt to track down SOA RRs if
-   they weren't supplied in the authoritative response, so it never
-   managed to completely eliminate the gratuitous DNS error message
-   traffic, but it did help considerably.  Keep in mind that this was
-   happening at about the same time as the near-collapse of the ARPANET
-   due to congestion caused by exponential growth and the the "old"
-   (pre-VJ) TCP retransmission algorithm, so negative caching resulted
-   in drasticly better DNS response time for our users, mailer daemons,
-   etcetera.
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 12]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   As far as I know, CHIVES was the first resolver to implement negative
-   caching.  CHIVES was developed during the twilight years of TOPS-20,
-   so it never ran on very many machines, but the few machines that it
-   did run on were the ones that were too critical to shut down quickly
-   no matter how much it cost to keep them running.  So what few users
-   we did have tended to drive CHIVES pretty hard.  Several interesting
-   bits of DNS technology resulted from that, but the one that's
-   relevant here is the MAXTTL configuration parameter.
-
-   Experience with JEEVES had already shown that RRs often showed up
-   with ridiculously long TTLs (99999999 was particularly popular for
-   many years, due to bugs in the code and documentation of several
-   early versions of BIND), and that robust software that blindly
-   believed such TTLs could create so many strange failures that it was
-   often necessary to reboot the resolver frequently just to clear this
-   garbage out of the cache.  So CHIVES had a configuration parameter
-   "MAXTTL", which specified the maximum "reasonable" TTL in a received
-   RR.  RRs with TTLs greater than MAXTTL would either have their TTLs
-   reduced to MAXTTL or would be discarded entirely, depending on the
-   setting of another configuration parameter.
-
-   When we started getting field experience with CHIVES's negative
-   caching code, it became clear that the SOA MINIMUM value was often
-   large enough to cause the same kinds of problems for negative caching
-   as the huge TTLs in RRs had for normal caching (again, this was in
-   part due to a bug in several early versions of BIND, where a
-   secondary server would authoritatively deny all knowledge of its
-   zones if it couldn't contact the primaries on reboot).  So we started
-   running the negative cache TTLs through the MAXTTL check too, and
-   continued to experiment.
-
-   The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL
-   (last of the major Internet TOPS-20 machines to be shut down, thus
-   the last major user of CHIVES, thus the place where we had the
-   longest experimental baseline) was to set MAXTTL to about three days.
-   Most of the traffic initiated by SIMTEL20 in its last years was
-   mail-related, and the mail queue timeout was set to one week, so this
-   gave a "stuck" message several tries at complete DNS resolution,
-   without bogging down the system with a lot of useless queries.  Since
-   (for reasons that now escape me) we only had the single MAXTTL
-   parameter rather than separate ones for positive and negative
-   caching, it's not clear how much effect this setting of MAXTTL had on
-   the negative caching code.
-
-   CHIVES also included a second, somewhat controversial mechanism which
-   took the place of negative caching in some cases.  The CHIVES
-   resolver daemon could be configured to load DNS master files, giving
-   it the ability to act as what today would be called a "stealth
-
-
-
-Andrews                     Standards Track                    [Page 13]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   secondary".  That is, when configured in this way, the resolver had
-   direct access to authoritative information for heavily-used zones.
-   The search path mechanisms in CHIVES reflected this: there were
-   actually two separate search paths, one of which only searched local
-   authoritative zone data, and one which could generate normal
-   iterative queries.  This cut down on the need for negative caching in
-   cases where usage was predictably heavy (e.g., the resolver on
-   XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and
-   AI.MIT.EDU and put both of these suffixes into the "local" search
-   path, since between them the hosts in these two zones accounted for
-   the bulk of the DNS traffic).  Not all sites running CHIVES chose to
-   use this feature; C.CS.CMU.EDU, for example, chose to use the
-   "remote" search path for everything because there were too many
-   different sub-zones at CMU for zone shadowing to be practical for
-   them, so they relied pretty heavily on negative caching even for
-   local traffic.
-
-   Overall, I still think the basic design we used for negative caching
-   was pretty reasonable: the zone administrator specified how long to
-   cache negative answers, and the resolver configuration chose the
-   actual cache time from the range between zero and the period
-   specified by the zone administrator.  There are a lot of details I'd
-   do differently now (like using a new SOA field instead of overloading
-   the MINIMUM field), but after more than a decade, I'd be more worried
-   if we couldn't think of at least a few improvements.
-
-9.2 BIND
-
-   While not the first attempt to get negative caching into BIND, in
-   July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that
-   implemented, validation and negative caching (NCACHE).  This code had
-   a 10 minute TTL for negative caching and only cached the indication
-   that there was a negative response, NXDOMAIN or NOERROR_NODATA. This
-   is the origin of the NODATA pseudo response code mentioned above.
-
-   Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA
-   record such that it could be retrieved by a similar query.  UUnet
-   complained that they were getting old answers after loading a new
-   zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994.
-   In reality this indicated that the named needed to purge the space
-   the zone would occupy.  Functionality to do this was added in BIND
-   4.9.3 BETA11 patch2, December 1994.
-
-   RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 14]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-10 Example
-
-   The following example is based on a signed zone that is empty apart
-   from the nameservers.  We will query for WWW.XX.EXAMPLE showing
-   initial response and again 10 minutes later.  Note 1: during the
-   intervening 10 minutes the NS records for XX.EXAMPLE have expired.
-   Note 2: the TTL of the SIG records are not explicitly set in the zone
-   file and are hence the TTL of the RRset they are the signature for.
-
-        Zone File:
-
-        $TTL 86400
-        $ORIGIN XX.EXAMPLE.
-        @       IN      SOA     NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
-                                1997102000      ; serial
-                                1800    ; refresh (30 mins)
-                                900     ; retry (15 mins)
-                                604800  ; expire (7 days)
-                                1200 ) ; minimum (20 mins)
-                IN      SIG     SOA ...
-          1200  IN      NXT     NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
-                IN      SIG     NXT ... XX.EXAMPLE. ...
-           300  IN      NS      NS1.XX.EXAMPLE.
-           300  IN      NS      NS2.XX.EXAMPLE.
-                IN      SIG     NS ... XX.EXAMPLE. ...
-                IN      KEY     0x4100 1 1 ...
-                IN      SIG     KEY ... XX.EXAMPLE. ...
-                IN      SIG     KEY ... EXAMPLE. ...
-        NS1     IN      A       10.0.0.1
-                IN      SIG     A ... XX.EXAMPLE. ...
-          1200  IN      NXT     NS2.XX.EXAMPLE. A NXT SIG
-                IN      SIG     NXT ...
-        NS2     IN      A       10.0.0.2
-                IN      SIG     A ... XX.EXAMPLE. ...
-          1200  IN      NXT     XX.EXAMPLE. A NXT SIG
-                IN      SIG     NXT ... XX.EXAMPLE. ...
-
-        Initial Response:
-
-        Header:
-            RDCODE=NXDOMAIN, AA=1, QR=1, TC=0
-        Query:
-            WWW.XX.EXAMPLE. IN A
-        Answer:
-            <empty>
-        Authority:
-            XX.EXAMPLE.      1200 IN SOA NS1.XX.EXAMPLE. ...
-            XX.EXAMPLE.      1200 IN SIG SOA ... XX.EXAMPLE. ...
-
-
-
-Andrews                     Standards Track                    [Page 15]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-            NS2.XX.EXAMPLE.  1200 IN NXT XX.EXAMPLE. NXT A NXT SIG
-            NS2.XX.EXAMPLE.  1200 IN SIG NXT ... XX.EXAMPLE. ...
-            XX.EXAMPLE.     86400 IN NS  NS1.XX.EXAMPLE.
-            XX.EXAMPLE.     86400 IN NS  NS2.XX.EXAMPLE.
-            XX.EXAMPLE.     86400 IN SIG NS ... XX.EXAMPLE. ...
-        Additional
-            XX.EXAMPLE.     86400 IN KEY 0x4100 1 1 ...
-            XX.EXAMPLE.     86400 IN SIG KEY ... EXAMPLE. ...
-            NS1.XX.EXAMPLE. 86400 IN A   10.0.0.1
-            NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
-            NS2.XX.EXAMPLE. 86400 IN A   10.0.0.2
-            NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
-
-         After 10 Minutes:
-
-         Header:
-             RDCODE=NXDOMAIN, AA=0, QR=1, TC=0
-         Query:
-             WWW.XX.EXAMPLE. IN A
-         Answer:
-             <empty>
-         Authority:
-             XX.EXAMPLE.       600 IN SOA NS1.XX.EXAMPLE. ...
-             XX.EXAMPLE.       600 IN SIG SOA ... XX.EXAMPLE. ...
-             NS2.XX.EXAMPLE.   600 IN NXT XX.EXAMPLE. NXT A NXT SIG
-             NS2.XX.EXAMPLE.   600 IN SIG NXT ... XX.EXAMPLE. ...
-             EXAMPLE.        65799 IN NS  NS1.YY.EXAMPLE.
-             EXAMPLE.        65799 IN NS  NS2.YY.EXAMPLE.
-             EXAMPLE.        65799 IN SIG NS ... XX.EXAMPLE. ...
-         Additional
-             XX.EXAMPLE.     65800 IN KEY 0x4100 1 1 ...
-             XX.EXAMPLE.     65800 IN SIG KEY ... EXAMPLE. ...
-             NS1.YY.EXAMPLE. 65799 IN A   10.100.0.1
-             NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
-             NS2.YY.EXAMPLE. 65799 IN A   10.100.0.2
-             NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
-             EXAMPLE.        65799 IN KEY 0x4100 1 1 ...
-             EXAMPLE.        65799 IN SIG KEY ... . ...
-
-
-11 Security Considerations
-
-   It is believed that this document does not introduce any significant
-   additional security threats other that those that already exist when
-   using data from the DNS.
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 16]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   With negative caching it might be possible to propagate a denial of
-   service attack by spreading a NXDOMAIN message with a very high TTL.
-   Without negative caching that would be much harder.  A similar effect
-   could be achieved previously by spreading a bad A record, so that the
-   server could not be reached - which is almost the same.  It has the
-   same effect as far as what the end user is able to do, but with a
-   different psychological effect.  With the bad A, I feel "damn the
-   network is broken again" and try again tomorrow.  With the "NXDOMAIN"
-   I feel "Oh, they've turned off the server and it doesn't exist any
-   more" and probably never bother trying this server again.
-
-   A practical example of this is a SMTP server where this behaviour is
-   encoded.  With a NXDOMAIN attack the mail message would bounce
-   immediately, where as with a bad A attack the mail would be queued
-   and could potentially get through after the attack was suspended.
-
-   For such an attack to be successful, the NXDOMAIN indiction must be
-   injected into a parent server (or a busy caching resolver).  One way
-   this might be done by the use of a CNAME which results in the parent
-   server querying an attackers server.  Resolvers that wish to prevent
-   such attacks can query again the final QNAME ignoring any NS data in
-   the query responses it has received for this query.
-
-   Implementing TTL sanity checking will reduce the effectiveness of
-   such an attack, because a successful attack would require re-
-   injection of the bogus data at more frequent intervals.
-
-   DNS Security [RFC2065] provides a mechanism to verify whether a
-   negative response is valid or not, through the use of NXT and SIG
-   records.  This document supports the use of that mechanism by
-   promoting the transmission of the relevant security records even in a
-   non security aware server.
-
-Acknowledgments
-
-   I would like to thank Rob Austein for his history of the CHIVES
-   nameserver. The DNSIND working group, in particular Robert Elz for
-   his valuable technical and editorial contributions to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 17]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-References
-
-   [RFC1034]
-           Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES,"
-           STD 13, RFC 1034, November 1987.
-
-   [RFC1035]
-           Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
-           SPECIFICATION," STD 13, RFC 1035, November 1987.
-
-   [RFC2065]
-           Eastlake, D., and C. Kaufman, "Domain Name System Security
-           Extensions," RFC 2065, January 1997.
-
-   [RFC2119]
-           Bradner, S., "Key words for use in RFCs to Indicate
-           Requirement Levels," BCP 14, RFC 2119, March 1997.
-
-   [RFC2181]
-           Elz, R., and R. Bush, "Clarifications to the DNS
-           Specification," RFC 2181, July 1997.
-
-Author's Address
-
-   Mark Andrews
-   CSIRO - Mathematical and Information Sciences
-   Locked Bag 17
-   North Ryde NSW 2113
-   AUSTRALIA
-
-   Phone: +61 2 9325 3148
-   EMail: Mark.Andrews@cmis.csiro.au
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 18]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 19]
-
diff --git a/doc/rfc/rfc2317.txt b/doc/rfc/rfc2317.txt
deleted file mode 100644
index c17bb41f..00000000
--- a/doc/rfc/rfc2317.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         H. Eidnes
-Request for Comments: 2317                                 SINTEF RUNIT
-BCP: 20                                                     G. de Groot
-Category: Best Current Practice          Berkeley Software Design, Inc.
-                                                               P. Vixie
-                                           Internet Software Consortium
-                                                             March 1998
-
-
-                   Classless IN-ADDR.ARPA delegation
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-2. Introduction
-
-   This document describes a way to do IN-ADDR.ARPA delegation on non-
-   octet boundaries for address spaces covering fewer than 256
-   addresses.  The proposed method should thus remove one of the
-   objections to subnet on non-octet boundaries but perhaps more
-   significantly, make it possible to assign IP address space in smaller
-   chunks than 24-bit prefixes, without losing the ability to delegate
-   authority for the corresponding IN-ADDR.ARPA mappings.  The proposed
-   method is fully compatible with the original DNS lookup mechanisms
-   specified in [1], i.e. there is no need to modify the lookup
-   algorithm used, and there should be no need to modify any software
-   which does DNS lookups.
-
-   The document also discusses some operational considerations to
-   provide some guidance in implementing this method.
-
-3. Motivation
-
-   With the proliferation of classless routing technology, it has become
-   feasible to assign address space on non-octet boundaries.  In case of
-   a very small organization with only a few hosts, assigning a full
-   24-bit prefix (what was traditionally referred to as a "class C
-   network number") often leads to inefficient address space
-   utilization.
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 1]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   One of the problems encountered when assigning a longer prefix (less
-   address space) is that it seems impossible for such an organization
-   to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously.  By
-   use of the reverse delegation method described below, the most
-   important objection to assignment of longer prefixes to unrelated
-   organizations can be removed.
-
-   Let us assume we have assigned the address spaces to three different
-   parties as follows:
-
-           192.0.2.0/25   to organization A
-           192.0.2.128/26 to organization B
-           192.0.2.192/26 to organization C
-
-   In the classical approach, this would lead to a single zone like
-   this:
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   ;
-   1               PTR     host1.A.domain.
-   2               PTR     host2.A.domain.
-   3               PTR     host3.A.domain.
-   ;
-   129             PTR     host1.B.domain.
-   130             PTR     host2.B.domain.
-   131             PTR     host3.B.domain.
-   ;
-   193             PTR     host1.C.domain.
-   194             PTR     host2.C.domain.
-   195             PTR     host3.C.domain.
-
-   The administration of this zone is problematic.  Authority for this
-   zone can only be delegated once, and this usually translates into
-   "this zone can only be administered by one organization."  The other
-   organizations with address space that corresponds to entries in this
-   zone would thus have to depend on another organization for their
-   address to name translation.  With the proposed method, this
-   potential problem can be avoided.
-
-4. Classless IN-ADDR.ARPA delegation
-
-   Since a single zone can only be delegated once, we need more points
-   to do delegation on to solve the problem above.  These extra points
-   of delegation can be introduced by extending the IN-ADDR.ARPA tree
-   downwards, e.g. by using the first address or the first address and
-   the network mask length (as shown below) in the corresponding address
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 2]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   space to form the the first component in the name for the zones.  The
-   following four zone files show how the problem in the motivation
-   section could be solved using this method.
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
-   ;...
-   ;  <<0-127>> /25
-   0/25            NS      ns.A.domain.
-   0/25            NS      some.other.name.server.
-   ;
-   1               CNAME   1.0/25.2.0.192.in-addr.arpa.
-   2               CNAME   2.0/25.2.0.192.in-addr.arpa.
-   3               CNAME   3.0/25.2.0.192.in-addr.arpa.
-   ;
-   ;  <<128-191>> /26
-   128/26          NS      ns.B.domain.
-   128/26          NS      some.other.name.server.too.
-   ;
-   129             CNAME   129.128/26.2.0.192.in-addr.arpa.
-   130             CNAME   130.128/26.2.0.192.in-addr.arpa.
-   131             CNAME   131.128/26.2.0.192.in-addr.arpa.
-   ;
-   ;  <<192-255>> /26
-   192/26          NS      ns.C.domain.
-   192/26          NS      some.other.third.name.server.
-   ;
-   193             CNAME   193.192/26.2.0.192.in-addr.arpa.
-   194             CNAME   194.192/26.2.0.192.in-addr.arpa.
-   195             CNAME   195.192/26.2.0.192.in-addr.arpa.
-
-   $ORIGIN 0/25.2.0.192.in-addr.arpa.
-   @       IN      SOA     ns.A.domain. hostmaster.A.domain. (...)
-   @               NS      ns.A.domain.
-   @               NS      some.other.name.server.
-   ;
-   1               PTR     host1.A.domain.
-   2               PTR     host2.A.domain.
-   3               PTR     host3.A.domain.
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 3]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   $ORIGIN 128/26.2.0.192.in-addr.arpa.
-   @       IN      SOA     ns.B.domain. hostmaster.B.domain. (...)
-   @               NS      ns.B.domain.
-   @               NS      some.other.name.server.too.
-   ;
-   129             PTR     host1.B.domain.
-   130             PTR     host2.B.domain.
-   131             PTR     host3.B.domain.
-
-
-   $ORIGIN 192/26.2.0.192.in-addr.arpa.
-   @       IN      SOA     ns.C.domain. hostmaster.C.domain. (...)
-   @               NS      ns.C.domain.
-   @               NS      some.other.third.name.server.
-   ;
-   193             PTR     host1.C.domain.
-   194             PTR     host2.C.domain.
-   195             PTR     host3.C.domain.
-
-   For each size-256 chunk split up using this method, there is a need
-   to install close to 256 CNAME records in the parent zone.  Some
-   people might view this as ugly; we will not argue that particular
-   point.  It is however quite easy to automatically generate the CNAME
-   resource records in the parent zone once and for all, if the way the
-   address space is partitioned is known.
-
-   The advantage of this approach over the other proposed approaches for
-   dealing with this problem is that there should be no need to modify
-   any already-deployed software.  In particular, the lookup mechanism
-   in the DNS does not have to be modified to accommodate this splitting
-   of the responsibility for the IPv4 address to name translation on
-   "non-dot" boundaries.  Furthermore, this technique has been in use
-   for several years in many installations, apparently with no ill
-   effects.
-
-   As usual, a resource record like
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   129             CNAME   129.128/26.2.0.192.in-addr.arpa.
-
-   can be convienently abbreviated to
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   129             CNAME   129.128/26
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 4]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   Some DNS implementations are not kind to special characters in domain
-   names, e.g. the "/" used in the above examples.  As [3] makes clear,
-   these are legal, though some might feel unsightly.  Because these are
-   not host names the restriction of [2] does not apply.  Modern clients
-   and servers have an option to act in the liberal and correct fashion.
-
-   The examples here use "/" because it was felt to be more visible and
-   pedantic reviewers felt that the 'these are not hostnames' argument
-   needed to be repeated.  We advise you not to be so pedantic, and to
-   not precisely copy the above examples, e.g.  substitute a more
-   conservative character, such as hyphen, for "/".
-
-5. Operational considerations
-
-   This technique is intended to be used for delegating address spaces
-   covering fewer than 256 addresses.  For delegations covering larger
-   blocks of addresses the traditional methods (multiple delegations)
-   can be used instead.
-
-5.1 Recommended secondary name service
-
-   Some older versions of name server software will make no effort to
-   find and return the pointed-to name in CNAME records if the pointed-
-   to name is not already known locally as cached or as authoritative
-   data.  This can cause some confusion in resolvers, as only the CNAME
-   record will be returned in the response.  To avoid this problem it is
-   recommended that the authoritative name servers for the delegating
-   zone (the zone containing all the CNAME records) all run as slave
-   (secondary) name servers for the "child" zones delegated and pointed
-   into via the CNAME records.
-
-5.2 Alternative naming conventions
-
-   As a result of this method, the location of the zone containing the
-   actual PTR records is no longer predefined.  This gives flexibility
-   and some examples will be presented here.
-
-   An alternative to using the first address, or the first address and
-   the network mask length in the corresponding address space, to name
-   the new zones is to use some other (non-numeric) name.  Thus it is
-   also possible to point to an entirely different part of the DNS tree
-   (i.e. outside of the IN-ADDR.ARPA tree).  It would be necessary to
-   use one of these alternate methods if two organizations somehow
-   shared the same physical subnet (and corresponding IP address space)
-   with no "neat" alignment of the addresses, but still wanted to
-   administrate their own IN-ADDR.ARPA mappings.
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 5]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   The following short example shows how you can point out of the IN-
-   ADDR.ARPA tree:
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
-   ; ...
-   1               CNAME   1.A.domain.
-   2               CNAME   2.A.domain.
-   ; ...
-   129             CNAME   129.B.domain.
-   130             CNAME   130.B.domain.
-   ;
-
-
-   $ORIGIN A.domain.
-   @       IN      SOA     my-ns.A.domain. hostmaster.A.domain. (...)
-   ; ...
-   ;
-   host1           A       192.0.2.1
-   1               PTR     host1
-   ;
-   host2           A       192.0.2.2
-   2               PTR     host2
-   ;
-
-   etc.
-
-   This way you can actually end up with the name->address and the
-   (pointed-to) address->name mapping data in the same zone file - some
-   may view this as an added bonus as no separate set of secondaries for
-   the reverse zone is required.  Do however note that the traversal via
-   the IN-ADDR.ARPA tree will still be done, so the CNAME records
-   inserted there need to point in the right direction for this to work.
-
-   Sketched below is an alternative approach using the same solution:
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   @                  SOA     my-ns.my.domain. hostmaster.my.domain. (...)
-   ; ...
-   1                  CNAME   1.2.0.192.in-addr.A.domain.
-   2                  CNAME   2.2.0.192.in-addr.A.domain.
-
-   $ORIGIN A.domain.
-   @                  SOA     my-ns.A.domain. hostmaster.A.domain. (...)
-   ; ...
-   ;
-   host1              A       192.0.2.1
-   1.2.0.192.in-addr  PTR     host1
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 6]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   host2              A       192.0.2.2
-   2.2.0.192.in-addr  PTR     host2
-
-   It is clear that many possibilities exist which can be adapted to the
-   specific requirements of the situation at hand.
-
-5.3 Other operational issues
-
-   Note that one cannot provide CNAME referrals twice for the same
-   address space, i.e. you cannot allocate a /25 prefix to one
-   organisation, and run IN-ADDR.ARPA this way, and then have the
-   organisation subnet the /25 into longer prefixes, and attempt to
-   employ the same technique to give each subnet control of its own
-   number space. This would result in a CNAME record pointing to a CNAME
-   record, which may be less robust overall.
-
-   Unfortunately, some old beta releases of the popular DNS name server
-   implementation BIND 4.9.3 had a bug which caused problems if a CNAME
-   record was encountered when a reverse lookup was made.  The beta
-   releases involved have since been obsoleted, and this issue is
-   resolved in the released code.  Some software manufacturers have
-   included the defective beta code in their product. In the few cases
-   we know of, patches from the manufacturers are available or planned
-   to replace the obsolete beta code involved.
-
-6. Security Considerations
-
-   With this scheme, the "leaf sites" will need to rely on one more site
-   running their DNS name service correctly than they would be if they
-   had a /24 allocation of their own, and this may add an extra
-   component which will need to work for reliable name resolution.
-
-   Other than that, the authors are not aware of any additional security
-   issues introduced by this mechanism.
-
-7. Conclusion
-
-   The suggested scheme gives more flexibility in delegating authority
-   in the IN-ADDR.ARPA domain, thus making it possible to assign address
-   space more efficiently without losing the ability to delegate the DNS
-   authority over the corresponding address to name mappings.
-
-8. Acknowledgments
-
-   Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-
-   ip.domains some time ago.  Alan Barrett and Sam Wilson provided
-   valuable comments on the newsgroup.
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 7]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   We would like to thank Rob Austein, Randy Bush, Matt Crawford, Robert
-   Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony
-   Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer,
-   and Peter Koch for their review and constructive comments.
-
-9. References
-
-   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-        STD 13, RFC 1034, November 1987.
-
-   [2]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host
-        Table Specification", RFC 952, October 1985.
-
-   [3]  Elz, R., and R. Bush, "Clarifications to the DNS
-        Specification", RFC 2181, July 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 8]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-10. Authors' Addresses
-
-   Havard Eidnes
-   SINTEF RUNIT
-   N-7034 Trondheim
-   Norway
-
-   Phone: +47 73 59 44 68
-   Fax: +47 73 59 17 00
-   EMail: Havard.Eidnes@runit.sintef.no
-
-
-   Geert Jan de Groot
-   Berkeley Software Design, Inc. (BSDI)
-   Hendrik Staetslaan 69
-   5622 HM Eindhoven
-   The Netherlands
-
-   Phone: +31 40 2960509
-   Fax:   +31 40 2960309
-   EMail: GeertJan.deGroot@bsdi.com
-
-
-   Paul Vixie
-   Internet Software Consortium
-   Star Route Box 159A
-   Woodside, CA 94062
-   USA
-
-   Phone: +1 415 747 0204
-   EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 9]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-11.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                 [Page 10]
-
diff --git a/doc/rfc/rfc2373.txt b/doc/rfc/rfc2373.txt
deleted file mode 100644
index 59fcff80..00000000
--- a/doc/rfc/rfc2373.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Hinden
-Request for Comments: 2373                                       Nokia
-Obsoletes: 1884                                             S. Deering
-Category: Standards Track                                Cisco Systems
-							     July 1998
-
-                  IP Version 6 Addressing Architecture
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   This specification defines the addressing architecture of the IP
-   Version 6 protocol [IPV6].  The document includes the IPv6 addressing
-   model, text representations of IPv6 addresses, definition of IPv6
-   unicast addresses, anycast addresses, and multicast addresses, and an
-   IPv6 node's required addresses.
-
-Table of Contents
-
-   1. Introduction.................................................2
-   2. IPv6 Addressing..............................................2
-      2.1 Addressing Model.........................................3
-      2.2 Text Representation of Addresses.........................3
-      2.3 Text Representation of Address Prefixes..................5
-      2.4 Address Type Representation..............................6
-      2.5 Unicast Addresses........................................7
-        2.5.1 Interface Identifiers................................8
-        2.5.2 The Unspecified Address..............................9
-        2.5.3 The Loopback Address.................................9
-        2.5.4 IPv6 Addresses with Embedded IPv4 Addresses.........10
-        2.5.5 NSAP Addresses......................................10
-        2.5.6 IPX Addresses.......................................10
-        2.5.7 Aggregatable Global Unicast Addresses...............11
-        2.5.8 Local-use IPv6 Unicast Addresses....................11
-      2.6 Anycast Addresses.......................................12
-        2.6.1 Required Anycast Address............................13
-      2.7 Multicast Addresses.....................................14
-
-
-
-Hinden & Deering            Standards Track                     [Page 1]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-        2.7.1 Pre-Defined Multicast Addresses.....................15
-        2.7.2 Assignment of New IPv6 Multicast Addresses..........17
-      2.8 A Node's Required Addresses.............................17
-   3. Security Considerations.....................................18
-   APPENDIX A: Creating EUI-64 based Interface Identifiers........19
-   APPENDIX B: ABNF Description of Text Representations...........22
-   APPENDIX C: CHANGES FROM RFC-1884..............................23
-   REFERENCES.....................................................24
-   AUTHORS' ADDRESSES.............................................25
-   FULL COPYRIGHT STATEMENT.......................................26
-
-
-1.0 INTRODUCTION
-
-   This specification defines the addressing architecture of the IP
-   Version 6 protocol.  It includes a detailed description of the
-   currently defined address formats for IPv6 [IPV6].
-
-   The authors would like to acknowledge the contributions of Paul
-   Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
-   Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
-   Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
-   Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
-   and Sue Thomson.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-2.0 IPv6 ADDRESSING
-
-   IPv6 addresses are 128-bit identifiers for interfaces and sets of
-   interfaces.  There are three types of addresses:
-
-     Unicast:   An identifier for a single interface.  A packet sent to
-                a unicast address is delivered to the interface
-                identified by that address.
-
-     Anycast:   An identifier for a set of interfaces (typically
-                belonging to different nodes).  A packet sent to an
-                anycast address is delivered to one of the interfaces
-                identified by that address (the "nearest" one, according
-                to the routing protocols' measure of distance).
-
-     Multicast: An identifier for a set of interfaces (typically
-                belonging to different nodes).  A packet sent to a
-                multicast address is delivered to all interfaces
-                identified by that address.
-
-
-
-Hinden & Deering            Standards Track                     [Page 2]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   There are no broadcast addresses in IPv6, their function being
-   superseded by multicast addresses.
-
-   In this document, fields in addresses are given a specific name, for
-   example "subscriber".  When this name is used with the term "ID" for
-   identifier after the name (e.g., "subscriber ID"), it refers to the
-   contents of the named field.  When it is used with the term "prefix"
-   (e.g.  "subscriber prefix") it refers to all of the address up to and
-   including this field.
-
-   In IPv6, all zeros and all ones are legal values for any field,
-   unless specifically excluded.  Specifically, prefixes may contain
-   zero-valued fields or end in zeros.
-
-2.1 Addressing Model
-
-   IPv6 addresses of all types are assigned to interfaces, not nodes.
-   An IPv6 unicast address refers to a single interface.  Since each
-   interface belongs to a single node, any of that node's interfaces'
-   unicast addresses may be used as an identifier for the node.
-
-   All interfaces are required to have at least one link-local unicast
-   address (see section 2.8 for additional required addresses).  A
-   single interface may also be assigned multiple IPv6 addresses of any
-   type (unicast, anycast, and multicast) or scope.  Unicast addresses
-   with scope greater than link-scope are not needed for interfaces that
-   are not used as the origin or destination of any IPv6 packets to or
-   from non-neighbors.  This is sometimes convenient for point-to-point
-   interfaces.  There is one exception to this addressing model:
-
-     An unicast address or a set of unicast addresses may be assigned to
-     multiple physical interfaces if the implementation treats the
-     multiple physical interfaces as one interface when presenting it to
-     the internet layer.  This is useful for load-sharing over multiple
-     physical interfaces.
-
-   Currently IPv6 continues the IPv4 model that a subnet prefix is
-   associated with one link.  Multiple subnet prefixes may be assigned
-   to the same link.
-
-2.2 Text Representation of Addresses
-
-   There are three conventional forms for representing IPv6 addresses as
-   text strings:
-
-   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
-      hexadecimal values of the eight 16-bit pieces of the address.
-      Examples:
-
-
-
-Hinden & Deering            Standards Track                     [Page 3]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-         FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
-
-         1080:0:0:0:8:800:200C:417A
-
-      Note that it is not necessary to write the leading zeros in an
-      individual field, but there must be at least one numeral in every
-      field (except for the case described in 2.).
-
-   2. Due to some methods of allocating certain styles of IPv6
-      addresses, it will be common for addresses to contain long strings
-      of zero bits.  In order to make writing addresses containing zero
-      bits easier a special syntax is available to compress the zeros.
-      The use of "::" indicates multiple groups of 16-bits of zeros.
-      The "::" can only appear once in an address.  The "::" can also be
-      used to compress the leading and/or trailing zeros in an address.
-
-      For example the following addresses:
-
-         1080:0:0:0:8:800:200C:417A  a unicast address
-         FF01:0:0:0:0:0:0:101        a multicast address
-         0:0:0:0:0:0:0:1             the loopback address
-         0:0:0:0:0:0:0:0             the unspecified addresses
-
-      may be represented as:
-
-         1080::8:800:200C:417A       a unicast address
-         FF01::101                   a multicast address
-         ::1                         the loopback address
-         ::                          the unspecified addresses
-
-   3. An alternative form that is sometimes more convenient when dealing
-      with a mixed environment of IPv4 and IPv6 nodes is
-      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
-      the six high-order 16-bit pieces of the address, and the 'd's are
-      the decimal values of the four low-order 8-bit pieces of the
-      address (standard IPv4 representation).  Examples:
-
-         0:0:0:0:0:0:13.1.68.3
-
-         0:0:0:0:0:FFFF:129.144.52.38
-
-      or in compressed form:
-
-         ::13.1.68.3
-
-         ::FFFF:129.144.52.38
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 4]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.3 Text Representation of Address Prefixes
-
-   The text representation of IPv6 address prefixes is similar to the
-   way IPv4 addresses prefixes are written in CIDR notation.  An IPv6
-   address prefix is represented by the notation:
-
-      ipv6-address/prefix-length
-
-   where
-
-      ipv6-address    is an IPv6 address in any of the notations listed
-                      in section 2.2.
-
-      prefix-length   is a decimal value specifying how many of the
-                      leftmost contiguous bits of the address comprise
-                      the prefix.
-
-   For example, the following are legal representations of the 60-bit
-   prefix 12AB00000000CD3 (hexadecimal):
-
-      12AB:0000:0000:CD30:0000:0000:0000:0000/60
-      12AB::CD30:0:0:0:0/60
-      12AB:0:0:CD30::/60
-
-   The following are NOT legal representations of the above prefix:
-
-      12AB:0:0:CD3/60   may drop leading zeros, but not trailing zeros,
-                        within any 16-bit chunk of the address
-
-      12AB::CD30/60     address to left of "/" expands to
-                        12AB:0000:0000:0000:0000:000:0000:CD30
-
-      12AB::CD3/60      address to left of "/" expands to
-                        12AB:0000:0000:0000:0000:000:0000:0CD3
-
-   When writing both a node address and a prefix of that node address
-   (e.g., the node's subnet prefix), the two can combined as follows:
-
-      the node address      12AB:0:0:CD30:123:4567:89AB:CDEF
-      and its subnet number 12AB:0:0:CD30::/60
-
-      can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 5]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.4 Address Type Representation
-
-   The specific type of an IPv6 address is indicated by the leading bits
-   in the address.  The variable-length field comprising these leading
-   bits is called the Format Prefix (FP).  The initial allocation of
-   these prefixes is as follows:
-
-    Allocation                            Prefix         Fraction of
-                                          (binary)       Address Space
-    -----------------------------------   --------       -------------
-    Reserved                              0000 0000      1/256
-    Unassigned                            0000 0001      1/256
-
-    Reserved for NSAP Allocation          0000 001       1/128
-    Reserved for IPX Allocation           0000 010       1/128
-
-    Unassigned                            0000 011       1/128
-    Unassigned                            0000 1         1/32
-    Unassigned                            0001           1/16
-
-    Aggregatable Global Unicast Addresses 001            1/8
-    Unassigned                            010            1/8
-    Unassigned                            011            1/8
-    Unassigned                            100            1/8
-    Unassigned                            101            1/8
-    Unassigned                            110            1/8
-
-    Unassigned                            1110           1/16
-    Unassigned                            1111 0         1/32
-    Unassigned                            1111 10        1/64
-    Unassigned                            1111 110       1/128
-    Unassigned                            1111 1110 0    1/512
-
-    Link-Local Unicast Addresses          1111 1110 10   1/1024
-    Site-Local Unicast Addresses          1111 1110 11   1/1024
-
-    Multicast Addresses                   1111 1111      1/256
-
-    Notes:
-
-      (1) The "unspecified address" (see section 2.5.2), the loopback
-          address (see section 2.5.3), and the IPv6 Addresses with
-          Embedded IPv4 Addresses (see section 2.5.4), are assigned out
-          of the 0000 0000 format prefix space.
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 6]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-      (2) The format prefixes 001 through 111, except for Multicast
-          Addresses (1111 1111), are all required to have to have 64-bit
-          interface identifiers in EUI-64 format.  See section 2.5.1 for
-          definitions.
-
-   This allocation supports the direct allocation of aggregation
-   addresses, local use addresses, and multicast addresses.  Space is
-   reserved for NSAP addresses and IPX addresses.  The remainder of the
-   address space is unassigned for future use.  This can be used for
-   expansion of existing use (e.g., additional aggregatable addresses,
-   etc.) or new uses (e.g., separate locators and identifiers).  Fifteen
-   percent of the address space is initially allocated.  The remaining
-   85% is reserved for future use.
-
-   Unicast addresses are distinguished from multicast addresses by the
-   value of the high-order octet of the addresses: a value of FF
-   (11111111) identifies an address as a multicast address; any other
-   value identifies an address as a unicast address.  Anycast addresses
-   are taken from the unicast address space, and are not syntactically
-   distinguishable from unicast addresses.
-
-2.5 Unicast Addresses
-
-   IPv6 unicast addresses are aggregatable with contiguous bit-wise
-   masks similar to IPv4 addresses under Class-less Interdomain Routing
-   [CIDR].
-
-   There are several forms of unicast address assignment in IPv6,
-   including the global aggregatable global unicast address, the NSAP
-   address, the IPX hierarchical address, the site-local address, the
-   link-local address, and the IPv4-capable host address.  Additional
-   address types can be defined in the future.
-
-   IPv6 nodes may have considerable or little knowledge of the internal
-   structure of the IPv6 address, depending on the role the node plays
-   (for instance, host versus router).  At a minimum, a node may
-   consider that unicast addresses (including its own) have no internal
-   structure:
-
-   |                           128 bits                              |
-   +-----------------------------------------------------------------+
-   |                          node address                           |
-   +-----------------------------------------------------------------+
-
-   A slightly sophisticated host (but still rather simple) may
-   additionally be aware of subnet prefix(es) for the link(s) it is
-   attached to, where different addresses may have different values for
-   n:
-
-
-
-Hinden & Deering            Standards Track                     [Page 7]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   |                         n bits                 |   128-n bits   |
-   +------------------------------------------------+----------------+
-   |                   subnet prefix                | interface ID   |
-   +------------------------------------------------+----------------+
-
-   Still more sophisticated hosts may be aware of other hierarchical
-   boundaries in the unicast address.  Though a very simple router may
-   have no knowledge of the internal structure of IPv6 unicast
-   addresses, routers will more generally have knowledge of one or more
-   of the hierarchical boundaries for the operation of routing
-   protocols.  The known boundaries will differ from router to router,
-   depending on what positions the router holds in the routing
-   hierarchy.
-
-2.5.1 Interface Identifiers
-
-   Interface identifiers in IPv6 unicast addresses are used to identify
-   interfaces on a link.  They are required to be unique on that link.
-   They may also be unique over a broader scope.  In many cases an
-   interface's identifier will be the same as that interface's link-
-   layer address.  The same interface identifier may be used on multiple
-   interfaces on a single node.
-
-   Note that the use of the same interface identifier on multiple
-   interfaces of a single node does not affect the interface
-   identifier's global uniqueness or each IPv6 addresses global
-   uniqueness created using that interface identifier.
-
-   In a number of the format prefixes (see section 2.4) Interface IDs
-   are required to be 64 bits long and to be constructed in IEEE EUI-64
-   format [EUI64].  EUI-64 based Interface identifiers may have global
-   scope when a global token is available (e.g., IEEE 48bit MAC) or may
-   have local scope where a global token is not available (e.g., serial
-   links, tunnel end-points, etc.).  It is required that the "u" bit
-   (universal/local bit in IEEE EUI-64 terminology) be inverted when
-   forming the interface identifier from the EUI-64.  The "u" bit is set
-   to one (1) to indicate global scope, and it is set to zero (0) to
-   indicate local scope.  The first three octets in binary of an EUI-64
-   identifier are as follows:
-
-       0       0 0       1 1       2
-      |0       7 8       5 6       3|
-      +----+----+----+----+----+----+
-      |cccc|ccug|cccc|cccc|cccc|cccc|
-      +----+----+----+----+----+----+
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 8]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   written in Internet standard bit-order , where "u" is the
-   universal/local bit, "g" is the individual/group bit, and "c" are the
-   bits of the company_id.  Appendix A: "Creating EUI-64 based Interface
-   Identifiers" provides examples on the creation of different EUI-64
-   based interface identifiers.
-
-   The motivation for inverting the "u" bit when forming the interface
-   identifier is to make it easy for system administrators to hand
-   configure local scope identifiers when hardware tokens are not
-   available.  This is expected to be case for serial links, tunnel end-
-   points, etc.  The alternative would have been for these to be of the
-   form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler ::1,
-   ::2, etc.
-
-   The use of the universal/local bit in the IEEE EUI-64 identifier is
-   to allow development of future technology that can take advantage of
-   interface identifiers with global scope.
-
-   The details of forming interface identifiers are defined in the
-   appropriate "IPv6 over <link>" specification such as "IPv6 over
-   Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
-
-2.5.2 The Unspecified Address
-
-   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
-   must never be assigned to any node.  It indicates the absence of an
-   address.  One example of its use is in the Source Address field of
-   any IPv6 packets sent by an initializing host before it has learned
-   its own address.
-
-   The unspecified address must not be used as the destination address
-   of IPv6 packets or in IPv6 Routing Headers.
-
-2.5.3 The Loopback Address
-
-   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
-   It may be used by a node to send an IPv6 packet to itself.  It may
-   never be assigned to any physical interface.  It may be thought of as
-   being associated with a virtual interface (e.g., the loopback
-   interface).
-
-   The loopback address must not be used as the source address in IPv6
-   packets that are sent outside of a single node.  An IPv6 packet with
-   a destination address of loopback must never be sent outside of a
-   single node and must never be forwarded by an IPv6 router.
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 9]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.5.4 IPv6 Addresses with Embedded IPv4 Addresses
-
-   The IPv6 transition mechanisms [TRAN] include a technique for hosts
-   and routers to dynamically tunnel IPv6 packets over IPv4 routing
-   infrastructure.  IPv6 nodes that utilize this technique are assigned
-   special IPv6 unicast addresses that carry an IPv4 address in the low-
-   order 32-bits.  This type of address is termed an "IPv4-compatible
-   IPv6 address" and has the format:
-
-   |                80 bits               | 16 |      32 bits        |
-   +--------------------------------------+--------------------------+
-   |0000..............................0000|0000|    IPv4 address     |
-   +--------------------------------------+----+---------------------+
-
-   A second type of IPv6 address which holds an embedded IPv4 address is
-   also defined.  This address is used to represent the addresses of
-   IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses.
-   This type of address is termed an "IPv4-mapped IPv6 address" and has
-   the format:
-
-   |                80 bits               | 16 |      32 bits        |
-   +--------------------------------------+--------------------------+
-   |0000..............................0000|FFFF|    IPv4 address     |
-   +--------------------------------------+----+---------------------+
-
-2.5.5 NSAP Addresses
-
-   This mapping of NSAP address into IPv6 addresses is defined in
-   [NSAP].  This document recommends that network implementors who have
-   planned or deployed an OSI NSAP addressing plan, and who wish to
-   deploy or transition to IPv6, should redesign a native IPv6
-   addressing plan to meet their needs.  However, it also defines a set
-   of mechanisms for the support of OSI NSAP addressing in an IPv6
-   network.  These mechanisms are the ones that must be used if such
-   support is required.  This document also defines a mapping of IPv6
-   addresses within the OSI address format, should this be required.
-
-2.5.6 IPX Addresses
-
-   This mapping of IPX address into IPv6 addresses is as follows:
-
-   |   7   |                   121 bits                              |
-   +-------+---------------------------------------------------------+
-   |0000010|                 to be defined                           |
-   +-------+---------------------------------------------------------+
-
-   The draft definition, motivation, and usage are under study.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 10]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.5.7 Aggregatable Global Unicast Addresses
-
-   The global aggregatable global unicast address is defined in [AGGR].
-   This address format is designed to support both the current provider
-   based aggregation and a new type of aggregation called exchanges.
-   The combination will allow efficient routing aggregation for both
-   sites which connect directly to providers and who connect to
-   exchanges.  Sites will have the choice to connect to either type of
-   aggregation point.
-
-   The IPv6 aggregatable global unicast address format is as follows:
-
-   | 3|  13 | 8 |   24   |   16   |          64 bits               |
-   +--+-----+---+--------+--------+--------------------------------+
-   |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
-   |  | ID  |   |  ID    |  ID    |                                |
-   +--+-----+---+--------+--------+--------------------------------+
-
-   Where
-
-      001          Format Prefix (3 bit) for Aggregatable Global
-                   Unicast Addresses
-      TLA ID       Top-Level Aggregation Identifier
-      RES          Reserved for future use
-      NLA ID       Next-Level Aggregation Identifier
-      SLA ID       Site-Level Aggregation Identifier
-      INTERFACE ID Interface Identifier
-
-   The contents, field sizes, and assignment rules are defined in
-   [AGGR].
-
-2.5.8 Local-Use IPv6 Unicast Addresses
-
-   There are two types of local-use unicast addresses defined.  These
-   are Link-Local and Site-Local.  The Link-Local is for use on a single
-   link and the Site-Local is for use in a single site.  Link-Local
-   addresses have the following format:
-
-   |   10     |
-   |  bits    |        54 bits          |          64 bits           |
-   +----------+-------------------------+----------------------------+
-   |1111111010|           0             |       interface ID         |
-   +----------+-------------------------+----------------------------+
-
-   Link-Local addresses are designed to be used for addressing on a
-   single link for purposes such as auto-address configuration, neighbor
-   discovery, or when no routers are present.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 11]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   Routers must not forward any packets with link-local source or
-   destination addresses to other links.
-
-   Site-Local addresses have the following format:
-
-   |   10     |
-   |  bits    |   38 bits   |  16 bits  |         64 bits            |
-   +----------+-------------+-----------+----------------------------+
-   |1111111011|    0        | subnet ID |       interface ID         |
-   +----------+-------------+-----------+----------------------------+
-
-   Site-Local addresses are designed to be used for addressing inside of
-   a site without the need for a global prefix.
-
-   Routers must not forward any packets with site-local source or
-   destination addresses outside of the site.
-
-2.6 Anycast Addresses
-
-   An IPv6 anycast address is an address that is assigned to more than
-   one interface (typically belonging to different nodes), with the
-   property that a packet sent to an anycast address is routed to the
-   "nearest" interface having that address, according to the routing
-   protocols' measure of distance.
-
-   Anycast addresses are allocated from the unicast address space, using
-   any of the defined unicast address formats.  Thus, anycast addresses
-   are syntactically indistinguishable from unicast addresses.  When a
-   unicast address is assigned to more than one interface, thus turning
-   it into an anycast address, the nodes to which the address is
-   assigned must be explicitly configured to know that it is an anycast
-   address.
-
-   For any assigned anycast address, there is a longest address prefix P
-   that identifies the topological region in which all interfaces
-   belonging to that anycast address reside.  Within the region
-   identified by P, each member of the anycast set must be advertised as
-   a separate entry in the routing system (commonly referred to as a
-   "host route"); outside the region identified by P, the anycast
-   address may be aggregated into the routing advertisement for prefix
-   P.
-
-   Note that in, the worst case, the prefix P of an anycast set may be
-   the null prefix, i.e., the members of the set may have no topological
-   locality.  In that case, the anycast address must be advertised as a
-   separate routing entry throughout the entire internet, which presents
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 12]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   a severe scaling limit on how many such "global" anycast sets may be
-   supported.  Therefore, it is expected that support for global anycast
-   sets may be unavailable or very restricted.
-
-   One expected use of anycast addresses is to identify the set of
-   routers belonging to an organization providing internet service.
-   Such addresses could be used as intermediate addresses in an IPv6
-   Routing header, to cause a packet to be delivered via a particular
-   aggregation or sequence of aggregations.  Some other possible uses
-   are to identify the set of routers attached to a particular subnet,
-   or the set of routers providing entry into a particular routing
-   domain.
-
-   There is little experience with widespread, arbitrary use of internet
-   anycast addresses, and some known complications and hazards when
-   using them in their full generality [ANYCST].  Until more experience
-   has been gained and solutions agreed upon for those problems, the
-   following restrictions are imposed on IPv6 anycast addresses:
-
-      o An anycast address must not be used as the source address of an
-        IPv6 packet.
-
-      o An anycast address must not be assigned to an IPv6 host, that
-        is, it may be assigned to an IPv6 router only.
-
-2.6.1 Required Anycast Address
-
-   The Subnet-Router anycast address is predefined.  Its format is as
-   follows:
-
-   |                         n bits                 |   128-n bits   |
-   +------------------------------------------------+----------------+
-   |                   subnet prefix                | 00000000000000 |
-   +------------------------------------------------+----------------+
-
-   The "subnet prefix" in an anycast address is the prefix which
-   identifies a specific link.  This anycast address is syntactically
-   the same as a unicast address for an interface on the link with the
-   interface identifier set to zero.
-
-   Packets sent to the Subnet-Router anycast address will be delivered
-   to one router on the subnet.  All routers are required to support the
-   Subnet-Router anycast addresses for the subnets which they have
-   interfaces.
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 13]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   The subnet-router anycast address is intended to be used for
-   applications where a node needs to communicate with one of a set of
-   routers on a remote subnet.  For example when a mobile host needs to
-   communicate with one of the mobile agents on its "home" subnet.
-
-2.7 Multicast Addresses
-
-   An IPv6 multicast address is an identifier for a group of nodes.  A
-   node may belong to any number of multicast groups.  Multicast
-   addresses have the following format:
-
-   |   8    |  4 |  4 |                  112 bits                   |
-   +------ -+----+----+---------------------------------------------+
-   |11111111|flgs|scop|                  group ID                   |
-   +--------+----+----+---------------------------------------------+
-
-      11111111 at the start of the address identifies the address as
-      being a multicast address.
-
-                                    +-+-+-+-+
-      flgs is a set of 4 flags:     |0|0|0|T|
-                                    +-+-+-+-+
-
-         The high-order 3 flags are reserved, and must be initialized to
-         0.
-
-         T = 0 indicates a permanently-assigned ("well-known") multicast
-         address, assigned by the global internet numbering authority.
-
-         T = 1 indicates a non-permanently-assigned ("transient")
-         multicast address.
-
-      scop is a 4-bit multicast scope value used to limit the scope of
-      the multicast group.  The values are:
-
-         0  reserved
-         1  node-local scope
-         2  link-local scope
-         3  (unassigned)
-         4  (unassigned)
-         5  site-local scope
-         6  (unassigned)
-         7  (unassigned)
-         8  organization-local scope
-         9  (unassigned)
-         A  (unassigned)
-         B  (unassigned)
-         C  (unassigned)
-
-
-
-Hinden & Deering            Standards Track                    [Page 14]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-         D  (unassigned)
-         E  global scope
-         F  reserved
-
-      group ID identifies the multicast group, either permanent or
-      transient, within the given scope.
-
-   The "meaning" of a permanently-assigned multicast address is
-   independent of the scope value.  For example, if the "NTP servers
-   group" is assigned a permanent multicast address with a group ID of
-   101 (hex), then:
-
-      FF01:0:0:0:0:0:0:101 means all NTP servers on the same node as the
-      sender.
-
-      FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
-      sender.
-
-      FF05:0:0:0:0:0:0:101 means all NTP servers at the same site as the
-      sender.
-
-      FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.
-
-   Non-permanently-assigned multicast addresses are meaningful only
-   within a given scope.  For example, a group identified by the non-
-   permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
-   site bears no relationship to a group using the same address at a
-   different site, nor to a non-permanent group using the same group ID
-   with different scope, nor to a permanent group with the same group
-   ID.
-
-   Multicast addresses must not be used as source addresses in IPv6
-   packets or appear in any routing header.
-
-2.7.1 Pre-Defined Multicast Addresses
-
-   The following well-known multicast addresses are pre-defined:
-
-      Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
-                                      FF01:0:0:0:0:0:0:0
-                                      FF02:0:0:0:0:0:0:0
-                                      FF03:0:0:0:0:0:0:0
-                                      FF04:0:0:0:0:0:0:0
-                                      FF05:0:0:0:0:0:0:0
-                                      FF06:0:0:0:0:0:0:0
-                                      FF07:0:0:0:0:0:0:0
-                                      FF08:0:0:0:0:0:0:0
-                                      FF09:0:0:0:0:0:0:0
-
-
-
-Hinden & Deering            Standards Track                    [Page 15]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-                                      FF0A:0:0:0:0:0:0:0
-                                      FF0B:0:0:0:0:0:0:0
-                                      FF0C:0:0:0:0:0:0:0
-                                      FF0D:0:0:0:0:0:0:0
-                                      FF0E:0:0:0:0:0:0:0
-                                      FF0F:0:0:0:0:0:0:0
-
-   The above multicast addresses are reserved and shall never be
-   assigned to any multicast group.
-
-      All Nodes Addresses:    FF01:0:0:0:0:0:0:1
-                              FF02:0:0:0:0:0:0:1
-
-   The above multicast addresses identify the group of all IPv6 nodes,
-   within scope 1 (node-local) or 2 (link-local).
-
-      All Routers Addresses:   FF01:0:0:0:0:0:0:2
-                               FF02:0:0:0:0:0:0:2
-                               FF05:0:0:0:0:0:0:2
-
-   The above multicast addresses identify the group of all IPv6 routers,
-   within scope 1 (node-local), 2 (link-local), or 5 (site-local).
-
-      Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX
-
-   The above multicast address is computed as a function of a node's
-   unicast and anycast addresses.  The solicited-node multicast address
-   is formed by taking the low-order 24 bits of the address (unicast or
-   anycast) and appending those bits to the prefix
-   FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
-   range
-
-      FF02:0:0:0:0:1:FF00:0000
-
-   to
-
-      FF02:0:0:0:0:1:FFFF:FFFF
-
-   For example, the solicited node multicast address corresponding to
-   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
-   addresses that differ only in the high-order bits, e.g. due to
-   multiple high-order prefixes associated with different aggregations,
-   will map to the same solicited-node address thereby reducing the
-   number of multicast addresses a node must join.
-
-   A node is required to compute and join the associated Solicited-Node
-   multicast addresses for every unicast and anycast address it is
-   assigned.
-
-
-
-Hinden & Deering            Standards Track                    [Page 16]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.7.2 Assignment of New IPv6 Multicast Addresses
-
-   The current approach [ETHER] to map IPv6 multicast addresses into
-   IEEE 802 MAC addresses takes the low order 32 bits of the IPv6
-   multicast address and uses it to create a MAC address.  Note that
-   Token Ring networks are handled differently.  This is defined in
-   [TOKEN].  Group ID's less than or equal to 32 bits will generate
-   unique MAC addresses.  Due to this new IPv6 multicast addresses
-   should be assigned so that the group identifier is always in the low
-   order 32 bits as shown in the following:
-
-   |   8    |  4 |  4 |          80 bits          |     32 bits     |
-   +------ -+----+----+---------------------------+-----------------+
-   |11111111|flgs|scop|   reserved must be zero   |    group ID     |
-   +--------+----+----+---------------------------+-----------------+
-
-   While this limits the number of permanent IPv6 multicast groups to
-   2^32 this is unlikely to be a limitation in the future.  If it
-   becomes necessary to exceed this limit in the future multicast will
-   still work but the processing will be sightly slower.
-
-   Additional IPv6 multicast addresses are defined and registered by the
-   IANA [MASGN].
-
-2.8 A Node's Required Addresses
-
-   A host is required to recognize the following addresses as
-   identifying itself:
-
-      o Its Link-Local Address for each interface
-      o Assigned Unicast Addresses
-      o Loopback Address
-      o All-Nodes Multicast Addresses
-      o Solicited-Node Multicast Address for each of its assigned
-        unicast and anycast addresses
-      o Multicast Addresses of all other groups to which the host
-        belongs.
-
-   A router is required to recognize all addresses that a host is
-   required to recognize, plus the following addresses as identifying
-   itself:
-
-      o The Subnet-Router anycast addresses for the interfaces it is
-        configured to act as a router on.
-      o All other Anycast addresses with which the router has been
-        configured.
-      o All-Routers Multicast Addresses
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 17]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-      o Multicast Addresses of all other groups to which the router
-        belongs.
-
-   The only address prefixes which should be predefined in an
-   implementation are the:
-
-      o Unspecified Address
-      o Loopback Address
-      o Multicast Prefix (FF)
-      o Local-Use Prefixes (Link-Local and Site-Local)
-      o Pre-Defined Multicast Addresses
-      o IPv4-Compatible Prefixes
-
-   Implementations should assume all other addresses are unicast unless
-   specifically configured (e.g., anycast addresses).
-
-3. Security Considerations
-
-   IPv6 addressing documents do not have any direct impact on Internet
-   infrastructure security.  Authentication of IPv6 packets is defined
-   in [AUTH].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 18]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-APPENDIX A : Creating EUI-64 based Interface Identifiers
---------------------------------------------------------
-
-   Depending on the characteristics of a specific link or node there are
-   a number of approaches for creating EUI-64 based interface
-   identifiers.  This appendix describes some of these approaches.
-
-Links or Nodes with EUI-64 Identifiers
-
-   The only change needed to transform an EUI-64 identifier to an
-   interface identifier is to invert the "u" (universal/local) bit.  For
-   example, a globally unique EUI-64 identifier of the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   where "c" are the bits of the assigned company_id, "0" is the value
-   of the universal/local bit to indicate global scope, "g" is
-   individual/group bit, and "m" are the bits of the manufacturer-
-   selected extension identifier.  The IPv6 interface identifier would
-   be of the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   The only change is inverting the value of the universal/local bit.
-
-Links or Nodes with IEEE 802 48 bit MAC's
-
-   [EUI64] defines a method to create a EUI-64 identifier from an IEEE
-   48bit MAC identifier.  This is to insert two octets, with hexadecimal
-   values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the
-   company_id and vendor supplied id).  For example the 48 bit MAC with
-   global scope:
-
-   |0              1|1              3|3              4|
-   |0              5|6              1|2              7|
-   +----------------+----------------+----------------+
-   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 19]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   where "c" are the bits of the assigned company_id, "0" is the value
-   of the universal/local bit to indicate global scope, "g" is
-   individual/group bit, and "m" are the bits of the manufacturer-
-   selected extension identifier.  The interface identifier would be of
-   the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   When IEEE 802 48bit MAC addresses are available (on an interface or a
-   node), an implementation should use them to create interface
-   identifiers due to their availability and uniqueness properties.
-
-Links with Non-Global Identifiers
-
-   There are a number of types of links that, while multi-access, do not
-   have globally unique link identifiers.  Examples include LocalTalk
-   and Arcnet.  The method to create an EUI-64 formatted identifier is
-   to take the link identifier (e.g., the LocalTalk 8 bit node
-   identifier) and zero fill it to the left.  For example a LocalTalk 8
-   bit node identifier of hexadecimal value 0x4F results in the
-   following interface identifier:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
-   +----------------+----------------+----------------+----------------+
-
-   Note that this results in the universal/local bit set to "0" to
-   indicate local scope.
-
-Links without Identifiers
-
-   There are a number of links that do not have any type of built-in
-   identifier.  The most common of these are serial links and configured
-   tunnels.  Interface identifiers must be chosen that are unique for
-   the link.
-
-   When no built-in identifier is available on a link the preferred
-   approach is to use a global interface identifier from another
-   interface or one which is assigned to the node itself.  To use this
-   approach no other interface connecting the same node to the same link
-   may use the same identifier.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 20]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   If there is no global interface identifier available for use on the
-   link the implementation needs to create a local scope interface
-   identifier.  The only requirement is that it be unique on the link.
-   There are many possible approaches to select a link-unique interface
-   identifier.  They include:
-
-      Manual Configuration
-      Generated Random Number
-      Node Serial Number (or other node-specific token)
-
-   The link-unique interface identifier should be generated in a manner
-   that it does not change after a reboot of a node or if interfaces are
-   added or deleted from the node.
-
-   The selection of the appropriate algorithm is link and implementation
-   dependent.  The details on forming interface identifiers are defined
-   in the appropriate "IPv6 over <link>" specification.  It is strongly
-   recommended that a collision detection algorithm be implemented as
-   part of any automatic algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 21]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-APPENDIX B: ABNF Description of Text Representations
-----------------------------------------------------
-
-   This appendix defines the text representation of IPv6 addresses and
-   prefixes in Augmented BNF [ABNF] for reference purposes.
-
-      IPv6address = hexpart [ ":" IPv4address ]
-      IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
-
-      IPv6prefix  = hexpart "/" 1*2DIGIT
-
-      hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
-      hexseq  = hex4 *( ":" hex4)
-      hex4    = 1*4HEXDIG
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 22]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-APPENDIX C: CHANGES FROM RFC-1884
----------------------------------
-
-   The following changes were made from RFC-1884 "IP Version 6
-   Addressing Architecture":
-
-      - Added an appendix providing a ABNF description of text
-        representations.
-      - Clarification that link unique identifiers not change after
-        reboot or other interface reconfigurations.
-      - Clarification of Address Model based on comments.
-      - Changed aggregation format terminology to be consistent with
-        aggregation draft.
-      - Added text to allow interface identifier to be used on more than
-        one interface on same node.
-      - Added rules for defining new multicast addresses.
-      - Added appendix describing procedures for creating EUI-64 based
-        interface ID's.
-      - Added notation for defining IPv6 prefixes.
-      - Changed solicited node multicast definition to use a longer
-        prefix.
-      - Added site scope all routers multicast address.
-      - Defined Aggregatable Global Unicast Addresses to use "001" Format
-        Prefix.
-      - Changed "010" (Provider-Based Unicast) and "100" (Reserved for
-        Geographic) Format Prefixes to Unassigned.
-      - Added section on Interface ID definition for unicast addresses.
-        Requires use of EUI-64 in range of format prefixes and rules for
-        setting global/local scope bit in EUI-64.
-      - Updated NSAP text to reflect working in RFC1888.
-      - Removed protocol specific IPv6 multicast addresses (e.g., DHCP)
-        and referenced the IANA definitions.
-      - Removed section "Unicast Address Example".  Had become OBE.
-      - Added new and updated references.
-      - Minor text clarifications and improvements.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 23]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-REFERENCES
-
-   [ABNF]    Crocker, D., and P. Overell, "Augmented BNF for
-             Syntax Specifications: ABNF", RFC 2234, November 1997.
-
-   [AGGR]    Hinden, R., O'Dell, M., and S. Deering, "An
-             Aggregatable Global Unicast Address Format", RFC 2374, July
-             1998.
-
-   [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
-             1995.
-
-   [ANYCST]  Partridge, C., Mendez, T., and W. Milliken, "Host
-             Anycasting Service", RFC 1546, November 1993.
-
-   [CIDR]    Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
-             Inter-Domain Routing (CIDR): An Address Assignment and
-             Aggregation Strategy", RFC 1519, September 1993.
-
-   [ETHER]   Crawford, M., "Transmission of IPv6 Pacekts over Ethernet
-             Networks", Work in Progress.
-
-   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
-             Registration Authority",
-             http://standards.ieee.org/db/oui/tutorials/EUI64.html,
-             March 1997.
-
-   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
-             Networks", Work in Progress.
-
-   [IPV6]    Deering, S., and R. Hinden, Editors, "Internet Protocol,
-             Version 6 (IPv6) Specification", RFC 1883, December 1995.
-
-   [MASGN]   Hinden, R., and S. Deering, "IPv6 Multicast Address
-             Assignments", RFC 2375, July 1998.
-
-   [NSAP]    Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
-             and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TOKEN]   Thomas, S., "Transmission of IPv6 Packets over Token Ring
-             Networks", Work in Progress.
-
-   [TRAN]    Gilligan, R., and E. Nordmark, "Transition Mechanisms for
-             IPv6 Hosts and Routers", RFC 1993, April 1996.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 24]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-AUTHORS' ADDRESSES
-
-   Robert M. Hinden
-   Nokia
-   232 Java Drive
-   Sunnyvale, CA 94089
-   USA
-
-   Phone: +1 408 990-2004
-   Fax:   +1 408 743-5677
-   EMail: hinden@iprg.nokia.com
-
-
-   Stephen E. Deering
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-   USA
-
-   Phone: +1 408 527-8213
-   Fax:   +1 408 527-8254
-   EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 25]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 26]
-
diff --git a/doc/rfc/rfc2374.txt b/doc/rfc/rfc2374.txt
deleted file mode 100644
index e3c7f0de..00000000
--- a/doc/rfc/rfc2374.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Hinden
-Request for Comments: 2374                                       Nokia
-Obsoletes: 2073                                              M. O'Dell
-Category: Standards Track                                        UUNET
-                                                            S. Deering
-                                                                 Cisco
-                                                             July 1998
-
-
-           An IPv6 Aggregatable Global Unicast Address Format
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-1.0 Introduction
-
-   This document defines an IPv6 aggregatable global unicast address
-   format for use in the Internet.  The address format defined in this
-   document is consistent with the IPv6 Protocol [IPV6] and the "IPv6
-   Addressing Architecture" [ARCH].  It is designed to facilitate
-   scalable Internet routing.
-
-   This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
-   Address Format".  RFC 2073 will become historic.  The Aggregatable
-   Global Unicast Address Format is an improvement over RFC 2073 in a
-   number of areas.  The major changes include removal of the registry
-   bits because they are not needed for route aggregation, support of
-   EUI-64 based interface identifiers, support of provider and exchange
-   based aggregation, separation of public and site topology, and new
-   aggregation based terminology.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 1]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-2.0 Overview of the IPv6 Address
-
-   IPv6 addresses are 128-bit identifiers for interfaces and sets of
-   interfaces.  There are three types of addresses: Unicast, Anycast,
-   and Multicast.  This document defines a specific type of Unicast
-   address.
-
-   In this document, fields in addresses are given specific names, for
-   example "subnet".  When this name is used with the term "ID" (for
-   "identifier") after the name (e.g., "subnet ID"), it refers to the
-   contents of the named field.  When it is used with the term "prefix"
-   (e.g.  "subnet prefix") it refers to all of the addressing bits to
-   the left of and including this field.
-
-   IPv6 unicast addresses are designed assuming that the Internet
-   routing system makes forwarding decisions based on a "longest prefix
-   match" algorithm on arbitrary bit boundaries and does not have any
-   knowledge of the internal structure of IPv6 addresses.  The structure
-   in IPv6 addresses is for assignment and allocation.  The only
-   exception to this is the distinction made between unicast and
-   multicast addresses.
-
-   The specific type of an IPv6 address is indicated by the leading bits
-   in the address.  The variable-length field comprising these leading
-   bits is called the Format Prefix (FP).
-
-   This document defines an address format for the 001 (binary) Format
-   Prefix for Aggregatable Global Unicast addresses. The same address
-   format could be used for other Format Prefixes, as long as these
-   Format Prefixes also identify IPv6 unicast addresses.  Only the "001"
-   Format Prefix is defined here.
-
-3.0 IPv6 Aggregatable Global Unicast Address Format
-
-   This document defines an address format for the IPv6 aggregatable
-   global unicast address assignment.  The authors believe that this
-   address format will be widely used for IPv6 nodes connected to the
-   Internet.  This address format is designed to support both the
-   current provider-based aggregation and a new type of exchange-based
-   aggregation.  The combination will allow efficient routing
-   aggregation for sites that connect directly to providers and for
-   sites that connect to exchanges.  Sites will have the choice to
-   connect to either type of aggregation entity.
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 2]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   While this address format is designed to support exchange-based
-   aggregation (in addition to current provider-based aggregation) it is
-   not dependent on exchanges for it's overall route aggregation
-   properties.  It will provide efficient route aggregation with only
-   provider-based aggregation.
-
-   Aggregatable addresses are organized into a three level hierarchy:
-
-      - Public Topology
-      - Site Topology
-      - Interface Identifier
-
-   Public topology is the collection of providers and exchanges who
-   provide public Internet transit services.  Site topology is local to
-   a specific site or organization which does not provide public transit
-   service to nodes outside of the site.  Interface identifiers identify
-   interfaces on links.
-
-        ______________                  ______________
-    --+/              \+--------------+/              \+----------
-      (       P1       )    +----+    (       P3       )  +----+
-      +\______________/     |    |----+\______________/+--|    |--
-      |                  +--| X1 |                       +| X2 |
-      | ______________  /   |    |-+    ______________  / |    |--
-      +/              \+    +-+--+  \  /              \+  +----+
-      (       P2       )     / \     +(      P4        )
-    --+\______________/     /   \      \______________/
-           |               /     \           |      |
-           |              /       |          |      |
-           |             /        |          |      |
-          _|_          _/_       _|_        _|_    _|_
-         /   \        /   \     /   \      /   \  /   \
-        ( S.A )      ( S.B )   ( P5  )    ( P6  )( S.C )
-         \___/        \___/     \___/      \___/  \___/
-                                  |          / \
-                                 _|_       _/_  \   ___
-                                /   \     /   \  +-/   \
-                               ( S.D )   ( S.E )  ( S.F )
-                                \___/     \___/    \___/
-
-   As shown in the figure above, the aggregatable address format is
-   designed to support long-haul providers (shown as P1, P2, P3, and
-   P4), exchanges (shown as X1 and X2), multiple levels of providers
-   (shown at P5 and P6), and subscribers (shown as S.x) Exchanges
-   (unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses.
-   Organizations who connect to these exchanges will also subscribe
-   (directly, indirectly via the exchange, etc.) for long-haul service
-   from one or more long-haul providers.  Doing so, they will achieve
-
-
-
-Hinden, et. al.             Standards Track                     [Page 3]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   addressing independence from long-haul transit providers.  They will
-   be able to change long-haul providers without having to renumber
-   their organization.  They can also be multihomed via the exchange to
-   more than one long-haul provider without having to have address
-   prefixes from each long-haul provider.  Note that the mechanisms used
-   for this type of provider selection and portability are not discussed
-   in the document.
-
-3.1 Aggregatable Global Unicast Address Structure
-
-   The aggregatable global unicast address format is as follows:
-
-     | 3|  13 | 8 |   24   |   16   |          64 bits               |
-     +--+-----+---+--------+--------+--------------------------------+
-     |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
-     |  | ID  |   |  ID    |  ID    |                                |
-     +--+-----+---+--------+--------+--------------------------------+
-
-     <--Public Topology--->   Site
-                           <-------->
-                            Topology
-                                     <------Interface Identifier----->
-
-   Where
-
-      FP           Format Prefix (001)
-      TLA ID       Top-Level Aggregation Identifier
-      RES          Reserved for future use
-      NLA ID       Next-Level Aggregation Identifier
-      SLA ID       Site-Level Aggregation Identifier
-      INTERFACE ID Interface Identifier
-
-   The following sections specify each part of the IPv6 Aggregatable
-   Global Unicast address format.
-
-3.2 Top-Level Aggregation ID
-
-   Top-Level Aggregation Identifiers (TLA ID) are the top level in the
-   routing hierarchy.  Default-free routers must have a routing table
-   entry for every active TLA ID and will probably have additional
-   entries providing routing information for the TLA ID in which they
-   are located.  They may have additional entries in order to optimize
-   routing for their specific topology, but the routing topology at all
-   levels must be designed to minimize the number of additional entries
-   fed into the default free routing tables.
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 4]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   This addressing format supports 8,192 (2^13) TLA ID's.  Additional
-   TLA ID's may be added by either growing the TLA field to the right
-   into the reserved field or by using this format for additional format
-   prefixes.
-
-   The issues relating to TLA ID assignment are beyond the scope of this
-   document.  They will be described in a document under preparation.
-
-3.3 Reserved
-
-   The Reserved field is reserved for future use and must be set to
-   zero.
-
-   The Reserved field allows for future growth of the TLA and NLA fields
-   as appropriate.  See section 4.0 for a discussion.
-
-3.4 Next-Level Aggregation Identifier
-
-   Next-Level Aggregation Identifier's are used by organizations
-   assigned a TLA ID to create an addressing hierarchy and to identify
-   sites.  The organization can assign the top part of the NLA ID in a
-   manner to create an addressing hierarchy appropriate to its network.
-   It can use the remainder of the bits in the field to identify sites
-   it wishes to serve.  This is shown as follows:
-
-      |  n  |      24-n bits     |   16   |    64 bits      |
-      +-----+--------------------+--------+-----------------+
-      |NLA1 |      Site ID       | SLA ID | Interface ID    |
-      +-----+--------------------+--------+-----------------+
-
-   Each organization assigned a TLA ID receives 24 bits of NLA ID space.
-   This NLA ID space allows each organization to provide service to
-   approximately as many organizations as the current IPv4 Internet can
-   support total networks.
-
-   Organizations assigned TLA ID's may also support NLA ID's in their
-   own Site ID space.  This allows the organization assigned a TLA ID to
-   provide service to organizations providing public transit service and
-   to organizations who do not provide public transit service.  These
-   organizations receiving an NLA ID may also choose to use their Site
-   ID space to support other NLA ID's.  This is shown as follows:
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 5]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   |  n  |      24-n bits     |   16   |    64 bits      |
-   +-----+--------------------+--------+-----------------+
-   |NLA1 |      Site ID       | SLA ID | Interface ID    |
-   +-----+--------------------+--------+-----------------+
-
-         |  m  |    24-n-m    |   16   |    64 bits      |
-         +-----+--------------+--------+-----------------+
-         |NLA2 |   Site ID    | SLA ID | Interface ID    |
-         +-----+--------------+--------+-----------------+
-
-               |  o  |24-n-m-o|   16   |    64 bits      |
-               +-----+--------+--------+-----------------+
-               |NLA3 | Site ID| SLA ID | Interface ID    |
-               +-----+--------+--------+-----------------+
-
-   The design of the bit layout of the NLA ID space for a specific TLA
-   ID is left to the organization responsible for that TLA ID.  Likewise
-   the design of the bit layout of the next level NLA ID is the
-   responsibility of the previous level NLA ID.  It is recommended that
-   organizations assigning NLA address space use "slow start" allocation
-   procedures similar to [RFC2050].
-
-   The design of an NLA ID allocation plan is a tradeoff between routing
-   aggregation efficiency and flexibility.  Creating hierarchies allows
-   for greater amount of aggregation and results in smaller routing
-   tables.  Flat NLA ID assignment provides for easier allocation and
-   attachment flexibility, but results in larger routing tables.
-
-3.5 Site-Level Aggregation Identifier
-
-   The SLA ID field is used by an individual organization to create its
-   own local addressing hierarchy and to identify subnets.  This is
-   analogous to subnets in IPv4 except that each organization has a much
-   greater number of subnets.  The 16 bit SLA ID field support 65,535
-   individual subnets.
-
-   Organizations may choose to either route their SLA ID "flat" (e.g.,
-   not create any logical relationship between the SLA identifiers that
-   results in larger routing tables), or to create a two or more level
-   hierarchy (that results in smaller routing tables) in the SLA ID
-   field.  The latter is shown as follows:
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 6]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   |  n  |   16-n     |              64 bits                |
-   +-----+------------+-------------------------------------+
-   |SLA1 |   Subnet   |            Interface ID             |
-   +-----+------------+-------------------------------------+
-
-         | m  |16-n-m |              64 bits                |
-         +----+-------+-------------------------------------+
-         |SLA2|Subnet |            Interface ID             |
-         +----+-------+-------------------------------------+
-
-   The approach chosen for structuring an SLA ID field is the
-   responsibility of the individual organization.
-
-   The number of subnets supported in this address format should be
-   sufficient for all but the largest of organizations.  Organizations
-   which need additional subnets can arrange with the organization they
-   are obtaining Internet service from to obtain additional site
-   identifiers and use this to create additional subnets.
-
-3.6 Interface ID
-
-   Interface identifiers are used to identify interfaces on a link.
-   They are required to be unique on that link.  They may also be unique
-   over a broader scope.  In many cases an interfaces identifier will be
-   the same or be based on the interface's link-layer address.
-   Interface IDs used in the aggregatable global unicast address format
-   are required to be 64 bits long and to be constructed in IEEE EUI-64
-   format [EUI-64].  These identifiers may have global scope when a
-   global token (e.g., IEEE 48bit MAC) is available or may have local
-   scope where a global token is not available (e.g., serial links,
-   tunnel end-points, etc.).  The "u" bit (universal/local bit in IEEE
-   EUI-64 terminology) in the EUI-64 identifier must be set correctly,
-   as defined in [ARCH], to indicate global or local scope.
-
-   The procedures for creating EUI-64 based Interface Identifiers is
-   defined in [ARCH].  The details on forming interface identifiers is
-   defined in the appropriate "IPv6 over <link>" specification such as
-   "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
-
-4.0 Technical Motivation
-
-   The design choices for the size of the fields in the aggregatable
-   address format were based on the need to meet a number of technical
-   requirements.  These are described in the following paragraphs.
-
-   The size of the Top-Level Aggregation Identifier is 13 bits.  This
-   allows for 8,192 TLA ID's.  This size was chosen to insure that the
-   default-free routing table in top level routers in the Internet is
-
-
-
-Hinden, et. al.             Standards Track                     [Page 7]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   kept within the limits, with a reasonable margin, of the current
-   routing technology.  The margin is important because default-free
-   routers will also carry a significant number of longer (i.e., more-
-   specific) prefixes for optimizing paths internal to a TLA and between
-   TLAs.
-
-   The important issue is not only the size of the default-free routing
-   table, but the complexity of the topology that determines the number
-   of copies of the default-free routes that a router must examine while
-   computing a forwarding table.  Current practice with IPv4 it is
-   common to see a prefix announced fifteen times via different paths.
-
-   The complexity of Internet topology is very likely to increase in the
-   future.  It is important that IPv6 default-free routing support
-   additional complexity as well as a considerably larger internet.
-
-   It should be noted for comparison that at the time of this writing
-   (spring, 1998) the IPv4 default-free routing table contains
-   approximately 50,000 prefixes.  While this shows that it is possible
-   to support more routes than 8,192 it is matter of debate if the
-   number of prefixes supported today in IPv4 is already too high for
-   current routing technology.  There are serious issues of route
-   stability as well as cases of providers not supporting all top level
-   prefixes.  The technical requirement was to pick a TLA ID size that
-   was below, with a reasonable margin, what was being done with IPv4.
-
-   The choice of 13 bits for the TLA field was an engineering
-   compromise.  Fewer bits would have been too small by not supporting
-   enough top level organizations.  More bits would have exceeded what
-   can be reasonably accommodated, with a reasonable margin, with
-   current routing technology in order to deal with the issues described
-   in the previous paragraphs.
-
-   If in the future, routing technology improves to support a larger
-   number of top level routes in the default-free routing tables there
-   are two choices on how to increase the number TLA identifiers.  The
-   first is to expand the TLA ID field into the reserved field.  This
-   would increase the number of TLA ID's to approximately 2 million.
-   The second approach is to allocate another format prefix (FP) for use
-   with this address format.  Either or a combination of these
-   approaches allows the number of TLA ID's to increase significantly.
-
-   The size of the Reserved field is 8 bits.  This size was chosen to
-   allow significant growth of either the TLA ID and/or the NLA ID
-   fields.
-
-   The size of the Next-Level Aggregation Identifier field is 24 bits.
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 8]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   This allows for approximately sixteen million NLA ID's if used in a
-   flat manner.  Used hierarchically it allows for a complexity roughly
-   equivalent to the IPv4 address space (assuming an average network
-   size of 254 interfaces).  If in the future additional room for
-   complexity is needed in the NLA ID, this may be accommodated by
-   extending the NLA ID into the Reserved field.
-
-   The size of the Site-Level Aggregation Identifier field is 16 bits.
-   This supports 65,535 individual subnets per site.  The design goal
-   for the size of this field was to be sufficient for all but the
-   largest of organizations.  Organizations which need additional
-   subnets can arrange with the organization they are obtaining Internet
-   service from to obtain additional site identifiers and use this to
-   create additional subnets.
-
-   The Site-Level Aggregation Identifier field was given a fixed size in
-   order to force the length of all prefixes identifying a particular
-   site to be the same length (i.e., 48 bits).  This facilitates
-   movement of sites in the topology (e.g., changing service providers
-   and multi-homing to multiple service providers).
-
-   The Interface ID Interface Identifier field is 64 bits.  This size
-   was chosen to meet the requirement specified in [ARCH] to support
-   EUI-64 based Interface Identifiers.
-
-5.0 Acknowledgments
-
-   The authors would like to express our thanks to Thomas Narten, Bob
-   Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
-   Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
-   for their review and constructive comments.
-
-6.0 References
-
-   [ALLOC]   IAB and IESG, "IPv6 Address Allocation Management",
-             RFC 1881, December 1995.
-
-   [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
-             RFC 2373, July 1998.
-
-   [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
-             1995.
-
-   [AUTO]    Thompson, S., and T. Narten., "IPv6 Stateless Address
-             Autoconfiguration", RFC 1971, August 1996.
-
-   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
-             Networks", Work in Progress.
-
-
-
-Hinden, et. al.             Standards Track                     [Page 9]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
-             Registration Authority",
-             http://standards.ieee.org/db/oui/tutorials/EUI64.html,
-             March 1997.
-
-   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
-             Networks", Work in Progress.
-
-   [IPV6]    Deering, S., and R. Hinden, "Internet Protocol, Version 6
-             (IPv6) Specification", RFC 1883, December 1995.
-
-   [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
-             and J. Postel, "Internet Registry IP Allocation
-             Guidelines", BCP 12, RFC 1466, November 1996.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-7.0 Security Considerations
-
-   IPv6 addressing documents do not have any direct impact on Internet
-   infrastructure security.  Authentication of IPv6 packets is defined
-   in [AUTH].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                    [Page 10]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-8.0 Authors' Addresses
-
-   Robert M. Hinden
-   Nokia
-   232 Java Drive
-   Sunnyvale, CA 94089
-   USA
-
-   Phone: 1 408 990-2004
-   EMail: hinden@iprg.nokia.com
-
-
-   Mike O'Dell
-   UUNET Technologies, Inc.
-   3060 Williams Drive
-   Fairfax, VA 22030
-   USA
-
-   Phone: 1 703 206-5890
-   EMail: mo@uunet.uu.net
-
-
-   Stephen E. Deering
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-   USA
-
-   Phone: 1 408 527-8213
-   EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                    [Page 11]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-9.0  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                    [Page 12]
-
diff --git a/doc/rfc/rfc2375.txt b/doc/rfc/rfc2375.txt
deleted file mode 100644
index a1fe8b9a..00000000
--- a/doc/rfc/rfc2375.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Hinden
-Request for Comments: 2375                             Ipsilon Networks
-Category: Informational                                      S. Deering
-                                                                  Cisco
-                                                              July 1998
-
-
-                   IPv6 Multicast Address Assignments
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-1.0 Introduction
-
-   This document defines the initial assignment of IPv6 multicast
-   addresses.  It is based on the "IP Version 6 Addressing Architecture"
-   [ADDARCH] and current IPv4 multicast address assignment found in
-   <ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses>.
-   It adapts the IPv4 assignments that are relevant to IPv6 assignments.
-   IPv4 assignments that were not relevant were not converted into IPv6
-   assignments.  Comments are solicited on this conversion.
-
-   All other IPv6 multicast addresses are reserved.
-
-   Sections 2 and 3 specify reserved and preassigned IPv6 multicast
-   addresses.
-
-   [ADDRARCH] defines rules for assigning new IPv6 multicast addresses.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-2. Fixed Scope Multicast Addresses
-
-   These permanently assigned multicast addresses are valid over a
-   specified scope value.
-
-
-
-
-
-
-
-Hinden & Deering             Informational                      [Page 1]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-2.1 Node-Local Scope
-
-   FF01:0:0:0:0:0:0:1     All Nodes Address                  [ADDARCH]
-   FF01:0:0:0:0:0:0:2     All Routers Address                [ADDARCH]
-
-2.2 Link-Local Scope
-
-   FF02:0:0:0:0:0:0:1     All Nodes Address                  [ADDARCH]
-   FF02:0:0:0:0:0:0:2     All Routers Address                [ADDARCH]
-   FF02:0:0:0:0:0:0:3     Unassigned                             [JBP]
-   FF02:0:0:0:0:0:0:4     DVMRP Routers                  [RFC1075,JBP]
-   FF02:0:0:0:0:0:0:5     OSPFIGP                        [RFC2328,Moy]
-   FF02:0:0:0:0:0:0:6     OSPFIGP Designated Routers     [RFC2328,Moy]
-   FF02:0:0:0:0:0:0:7     ST Routers                    [RFC1190,KS14]
-   FF02:0:0:0:0:0:0:8     ST Hosts                      [RFC1190,KS14]
-   FF02:0:0:0:0:0:0:9     RIP Routers                        [RFC2080]
-   FF02:0:0:0:0:0:0:A     EIGRP Routers                    [Farinacci]
-   FF02:0:0:0:0:0:0:B     Mobile-Agents                 [Bill Simpson]
-
-   FF02:0:0:0:0:0:0:D     All PIM Routers                  [Farinacci]
-   FF02:0:0:0:0:0:0:E     RSVP-ENCAPSULATION                  [Braden]
-
-   FF02:0:0:0:0:0:1:1     Link Name                       [Harrington]
-   FF02:0:0:0:0:0:1:2     All-dhcp-agents              [Bound,Perkins]
-
-   FF02:0:0:0:0:1:FFXX:XXXX     Solicited-Node Address       [ADDARCH]
-
-2.3 Site-Local Scope
-
-   FF05:0:0:0:0:0:0:2       All Routers Address              [ADDARCH]
-
-   FF05:0:0:0:0:0:1:3       All-dhcp-servers           [Bound,Perkins]
-   FF05:0:0:0:0:0:1:4       All-dhcp-relays            [Bound,Perkins]
-   FF05:0:0:0:0:0:1:1000    Service Location                 [RFC2165]
-    -FF05:0:0:0:0:0:1:13FF
-
-3.0 All Scope Multicast Addresses
-
-   These permanently assigned multicast addresses are valid over all
-   scope ranges.  This is shown by an "X" in the scope field of the
-   address that means any legal scope value.
-
-   Note that, as defined in [ADDARCH], IPv6 multicast addresses which
-   are only different in scope represent different groups.  Nodes must
-   join each group individually.
-
-   The IPv6 multicast addresses with variable scope are as follows:
-
-
-
-
-Hinden & Deering             Informational                      [Page 2]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-   FF0X:0:0:0:0:0:0:0     Reserved Multicast Address         [ADDARCH]
-
-   FF0X:0:0:0:0:0:0:100   VMTP Managers Group           [RFC1045,DRC3]
-   FF0X:0:0:0:0:0:0:101   Network Time Protocol (NTP)   [RFC1119,DLM1]
-   FF0X:0:0:0:0:0:0:102   SGI-Dogfight                           [AXC]
-   FF0X:0:0:0:0:0:0:103   Rwhod                                  [SXD]
-   FF0X:0:0:0:0:0:0:104   VNP                                   [DRC3]
-   FF0X:0:0:0:0:0:0:105   Artificial Horizons - Aviator          [BXF]
-   FF0X:0:0:0:0:0:0:106   NSS - Name Service Server             [BXS2]
-   FF0X:0:0:0:0:0:0:107   AUDIONEWS - Audio News Multicast      [MXF2]
-   FF0X:0:0:0:0:0:0:108   SUN NIS+ Information Service          [CXM3]
-   FF0X:0:0:0:0:0:0:109   MTP Multicast Transport Protocol       [SXA]
-   FF0X:0:0:0:0:0:0:10A   IETF-1-LOW-AUDIO                       [SC3]
-   FF0X:0:0:0:0:0:0:10B   IETF-1-AUDIO                           [SC3]
-   FF0X:0:0:0:0:0:0:10C   IETF-1-VIDEO                           [SC3]
-   FF0X:0:0:0:0:0:0:10D   IETF-2-LOW-AUDIO                       [SC3]
-   FF0X:0:0:0:0:0:0:10E   IETF-2-AUDIO                           [SC3]
-   FF0X:0:0:0:0:0:0:10F   IETF-2-VIDEO                           [SC3]
-
-   FF0X:0:0:0:0:0:0:110   MUSIC-SERVICE             [Guido van Rossum]
-   FF0X:0:0:0:0:0:0:111   SEANET-TELEMETRY             [Andrew Maffei]
-   FF0X:0:0:0:0:0:0:112   SEANET-IMAGE                 [Andrew Maffei]
-   FF0X:0:0:0:0:0:0:113   MLOADD                              [Braden]
-   FF0X:0:0:0:0:0:0:114   any private experiment                 [JBP]
-   FF0X:0:0:0:0:0:0:115   DVMRP on MOSPF                         [Moy]
-   FF0X:0:0:0:0:0:0:116   SVRLOC                            [Veizades]
-   FF0X:0:0:0:0:0:0:117   XINGTV                      <hgxing@aol.com>
-   FF0X:0:0:0:0:0:0:118   microsoft-ds         <arnoldm@microsoft.com>
-   FF0X:0:0:0:0:0:0:119   nbc-pro           <bloomer@birch.crd.ge.com>
-   FF0X:0:0:0:0:0:0:11A   nbc-pfn           <bloomer@birch.crd.ge.com>
-   FF0X:0:0:0:0:0:0:11B   lmsc-calren-1                         [Uang]
-   FF0X:0:0:0:0:0:0:11C   lmsc-calren-2                         [Uang]
-   FF0X:0:0:0:0:0:0:11D   lmsc-calren-3                         [Uang]
-   FF0X:0:0:0:0:0:0:11E   lmsc-calren-4                         [Uang]
-   FF0X:0:0:0:0:0:0:11F   ampr-info                          [Janssen]
-
-   FF0X:0:0:0:0:0:0:120   mtrace                              [Casner]
-   FF0X:0:0:0:0:0:0:121   RSVP-encap-1                        [Braden]
-   FF0X:0:0:0:0:0:0:122   RSVP-encap-2                        [Braden]
-   FF0X:0:0:0:0:0:0:123   SVRLOC-DA                         [Veizades]
-   FF0X:0:0:0:0:0:0:124   rln-server                            [Kean]
-   FF0X:0:0:0:0:0:0:125   proshare-mc                          [Lewis]
-   FF0X:0:0:0:0:0:0:126   dantz                               [Yackle]
-   FF0X:0:0:0:0:0:0:127   cisco-rp-announce                [Farinacci]
-   FF0X:0:0:0:0:0:0:128   cisco-rp-discovery               [Farinacci]
-   FF0X:0:0:0:0:0:0:129   gatekeeper                            [Toga]
-   FF0X:0:0:0:0:0:0:12A   iberiagames                        [Marocho]
-
-
-
-
-Hinden & Deering             Informational                      [Page 3]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-   FF0X:0:0:0:0:0:0:201  "rwho" Group (BSD) (unofficial)         [JBP]
-   FF0X:0:0:0:0:0:0:202   SUN RPC PMAPPROC_CALLIT               [BXE1]
-
-   FF0X:0:0:0:0:0:2:0000
-    -FF0X:0:0:0:0:0:2:7FFD  Multimedia Conference Calls          [SC3]
-   FF0X:0:0:0:0:0:2:7FFE    SAPv1 Announcements                  [SC3]
-   FF0X:0:0:0:0:0:2:7FFF    SAPv0 Announcements (deprecated)     [SC3]
-   FF0X:0:0:0:0:0:2:8000
-    -FF0X:0:0:0:0:0:2:FFFF  SAP Dynamic Assignments              [SC3]
-
-5.0 References
-
-   [ADDARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
-             Architecture", RFC 2373, July 1998.
-
-   [AUTORFC] Thompson, S., and T. Narten, "IPv6 Stateless Address
-             Autoconfiguration", RFC 1971, August 1996.
-
-   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
-             Networks", Work in Progress.
-
-   [RFC1045] Cheriton, D., "VMTP: Versatile Message Transaction Protocol
-             Specification", RFC 1045, February 1988.
-
-   [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
-             Vector Multicast Routing Protocol", RFC 1075, November
-             1988.
-
-   [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
-             RFC 1112, Stanford University, August 1989.
-
-   [RFC1119] Mills, D., "Network Time Protocol (Version 1),
-             Specification and Implementation", STD 12, RFC 1119, July
-             1988.
-
-   [RFC1190] Topolcic, C., Editor, "Experimental Internet Stream
-             Protocol, Version 2 (ST-II)", RFC 1190, October 1990.
-
-   [RFC2080] Malkin, G., and R. Minnear, "RIPng for IPv6", RFC 2080,
-             January 1997.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan
-             "Service Location Protocol", RFC 2165 June 1997.
-
-   [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
-
-
-
-Hinden & Deering             Informational                      [Page 4]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-6. People
-
-   <arnoldm@microsoft.com>
-
-   [AXC] Andrew Cherenson <arc@SGI.COM>
-
-   [Braden] Bob Braden, <braden@isi.edu>, April 1996.
-
-   [Bob Brenner]
-
-   [Bressler] David J. Bressler, <bressler@tss.com>, April 1996.
-
-   <bloomer@birch.crd.ge.com>
-
-   [Bound] Jim Bound <bound@zk3.dec.com>
-
-   [BXE1] Brendan Eic <brendan@illyria.wpd.sgi.com>
-
-   [BXF] Bruce Factor <ahi!bigapple!bruce@uunet.UU.NET>
-
-   [BXS2] Bill Schilit <schilit@parc.xerox.com>
-
-   [Casner] Steve Casner, <casner@isi.edu>, January 1995.
-
-   [CXM3] Chuck McManis <cmcmanis@sun.com>
-
-   [Tim Clark]
-
-   [DLM1] David Mills <Mills@HUEY.UDEL.EDU>
-
-   [DRC3] Dave Cheriton <cheriton@PESCADERO.STANFORD.EDU>
-
-   [DXS3] Daniel Steinber <Daniel.Steinberg@Eng.Sun.COM>
-
-   [Farinacci] Dino Farinacci, <dino@cisco.com>
-
-   [GSM11] Gary S. Malkin <GMALKIN@XYLOGICS.COM>
-
-   [Harrington] Dan Harrington, <dan@lucent.com>, July 1996.
-
-   <hgxing@aol.com>
-
-   [IANA] IANA <iana@iana.org>
-
-   [Janssen] Rob Janssen, <rob@pe1chl.ampr.org>, January 1995.
-
-   [JBP] Jon Postel <postel@isi.edu>
-
-
-
-
-Hinden & Deering             Informational                      [Page 5]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-   [JXM1] Jim Miner <miner@star.com>
-
-   [Kean] Brian Kean, <bkean@dca.com>, August 1995.
-
-   [KS14] <mystery contact>
-
-   [Lee] Choon Lee, <cwl@nsd.3com.com>, April 1996.
-
-   [Lewis] Mark Lewis, <Mark_Lewis@ccm.jf.intel.com>, October 1995.
-
-   [Malamud] Carl Malamud, <carl@radio.com>, January 1996.
-
-   [Andrew Maffei]
-
-   [Marohco] Jose Luis Marocho, <73374.313@compuserve.com>, July 1996.
-
-   [Moy] John Moy <jmoy@casc.com>
-
-   [MXF2] Martin Forssen <maf@dtek.chalmers.se>
-
-   [Perkins] Charlie Perkins, <cperkins@corp.sun.com>
-
-   [Guido van Rossum]
-
-   [SC3] Steve Casner <casner@isi.edu>
-
-   [Simpson] Bill Simpson <bill.simpson@um.cc.umich.edu> November 1994.
-
-   [Joel Snyder]
-
-   [SXA] Susie Armstrong <Armstrong.wbst128@XEROX.COM>
-
-   [SXD] Steve Deering <deering@PARC.XEROX.COM>
-
-   [tynan] Dermot Tynan, <dtynan@claddagh.ie>, August 1995.
-
-   [Toga] Jim Toga, <jtoga@ibeam.jf.intel.com>, May 1996.
-
-   [Uang] Yea Uang <uang@force.decnet.lockheed.com> November 1994.
-
-   [Veizades] John Veizades,  <veizades@tgv.com>, May 1995.
-
-   [Yackle] Dotty Yackle, <ditty_yackle@dantz.com>, February 1996.
-
-
-
-
-
-
-
-
-Hinden & Deering             Informational                      [Page 6]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-7.0 Security Considerations
-
-   This document defines the initial assignment of IPv6 multicast
-   addresses.  As such it does not directly impact the security of the
-   Internet infrastructure or its applications.
-
-8.0 Authors' Addresses
-
-   Robert M. Hinden
-   Ipsilon Networks, Inc.
-   232 Java Drive
-   Sunnyvale, CA 94089
-   USA
-
-   Phone: +1 415 990 2004
-   EMail: hinden@ipsilon.com
-
-
-   Stephen E. Deering
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-   USA
-
-   Phone: +1 408 527-8213
-   EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering             Informational                      [Page 7]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-9.0  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering             Informational                      [Page 8]
-
diff --git a/doc/rfc/rfc2418.txt b/doc/rfc/rfc2418.txt
deleted file mode 100644
index 9bdb2c53..00000000
--- a/doc/rfc/rfc2418.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         S. Bradner
-Request for Comments: 2418                                        Editor
-Obsoletes: 1603                                       Harvard University
-BCP: 25                                                   September 1998
-Category: Best Current Practice
-
-
-                           IETF Working Group
-                       Guidelines and Procedures
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   The Internet Engineering Task Force (IETF) has responsibility for
-   developing and reviewing specifications intended as Internet
-   Standards. IETF activities are organized into working groups (WGs).
-   This document describes the guidelines and procedures for formation
-   and operation of IETF working groups. It also describes the formal
-   relationship between IETF participants WG and the Internet
-   Engineering Steering Group (IESG) and the basic duties of IETF
-   participants, including WG Chairs, WG participants, and IETF Area
-   Directors.
-
-Table of Contents
-
-   Abstract .........................................................  1
-   1. Introduction ..................................................  2
-     1.1. IETF approach to standardization ..........................  4
-     1.2. Roles within a Working Group ..............................  4
-   2. Working group formation .......................................  4
-     2.1. Criteria for formation ....................................  4
-     2.2. Charter ...................................................  6
-     2.3. Charter review & approval .................................  8
-     2.4. Birds of a feather (BOF) ..................................  9
-   3. Working Group Operation ....................................... 10
-     3.1. Session planning .......................................... 11
-     3.2. Session venue ............................................. 11
-     3.3. Session management ........................................ 13
-     3.4. Contention and appeals .................................... 15
-
-
-
-Bradner                  Best Current Practice                  [Page 1]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   4. Working Group Termination ..................................... 15
-   5. Rechartering a Working Group .................................. 15
-   6. Staff Roles ................................................... 16
-     6.1. WG Chair .................................................. 16
-     6.2. WG Secretary .............................................. 18
-     6.3. Document Editor ........................................... 18
-     6.4. WG Facilitator ............................................ 18
-     6.5. Design teams .............................................. 19
-     6.6. Working Group Consultant .................................. 19
-     6.7. Area Director ............................................. 19
-   7. Working Group Documents ....................................... 19
-     7.1. Session documents ......................................... 19
-     7.2. Internet-Drafts (I-D) ..................................... 19
-     7.3. Request For Comments (RFC) ................................ 20
-     7.4. Working Group Last-Call ................................... 20
-     7.5. Submission of documents ................................... 21
-   8. Review of documents ........................................... 21
-   9. Security Considerations ....................................... 22
-   10. Acknowledgments .............................................. 23
-   11. References ................................................... 23
-   12. Editor's Address ............................................. 23
-   Appendix:  Sample Working Group Charter .......................... 24
-   Full Copyright Statement ......................................... 26
-
-1. Introduction
-
-   The Internet, a loosely-organized international collaboration of
-   autonomous, interconnected networks, supports host-to-host
-   communication through voluntary adherence to open protocols and
-   procedures defined by Internet Standards.  There are also many
-   isolated interconnected networks, which are not connected to the
-   global Internet but use the Internet Standards. Internet Standards
-   are developed in the Internet Engineering Task Force (IETF).  This
-   document defines guidelines and procedures for IETF working groups.
-   The Internet Standards Process of the IETF is defined in [1]. The
-   organizations involved in the IETF Standards Process are described in
-   [2] as are the roles of specific individuals.
-
-   The IETF is a large, open community of network designers, operators,
-   vendors, users, and researchers concerned with the Internet and the
-   technology used on it. The primary activities of the IETF are
-   performed by committees known as working groups. There are currently
-   more than 100 working groups. (See the IETF web page for an up-to-
-   date list of IETF Working Groups - http://www.ietf.org.) Working
-   groups tend to have a narrow focus and a lifetime bounded by the
-   completion of a specific set of tasks, although there are exceptions.
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 2]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   For management purposes, the IETF working groups are collected
-   together into areas, with each area having a separate focus.  For
-   example, the security area deals with the development of security-
-   related technology.  Each IETF area is managed by one or two Area
-   Directors (ADs).  There are currently 8 areas in the IETF but the
-   number changes from time to time.  (See the IETF web page for a list
-   of the current areas, the Area Directors for each area, and a list of
-   which working groups are assigned to each area.)
-
-   In many areas, the Area Directors have formed an advisory group or
-   directorate.  These comprise experienced members of the IETF and the
-   technical community represented by the area.  The specific name and
-   the details of the role for each group differ from area to area, but
-   the primary intent is that these groups assist the Area Director(s),
-   e.g., with the review of specifications produced in the area.
-
-   The IETF area directors are selected by a nominating committee, which
-   also selects an overall chair for the IETF.  The nominations process
-   is described in [3].
-
-   The area directors sitting as a body, along with the IETF Chair,
-   comprise the Internet Engineering Steering Group (IESG). The IETF
-   Executive Director is an ex-officio participant of the IESG, as are
-   the IAB Chair and a designated Internet Architecture Board (IAB)
-   liaison.  The IESG approves IETF Standards and approves the
-   publication of other IETF documents.  (See [1].)
-
-   A small IETF Secretariat provides staff and administrative support
-   for the operation of the IETF.
-
-   There is no formal membership in the IETF.  Participation is open to
-   all.  This participation may be by on-line contribution, attendance
-   at face-to-face sessions, or both.  Anyone from the Internet
-   community who has the time and interest is urged to participate in
-   IETF meetings and any of its on-line working group discussions.
-   Participation is by individual technical contributors, rather than by
-   formal representatives of organizations.
-
-   This document defines procedures and guidelines for the formation and
-   operation of working groups in the IETF. It defines the relations of
-   working groups to other bodies within the IETF. The duties of working
-   group Chairs and Area Directors with respect to the operation of the
-   working group are also defined.  When used in this document the key
-   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
-   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
-   interpreted as described in RFC 2119 [6].  RFC 2119 defines the use
-   of these key words to help make the intent of standards track
-   documents as clear as possible.  The same key words are used in this
-
-
-
-Bradner                  Best Current Practice                  [Page 3]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   document to help smooth WG operation and reduce the chance for
-   confusion about the processes.
-
-1.1. IETF approach to standardization
-
-   Familiarity with The Internet Standards Process [1] is essential for
-   a complete understanding of the philosophy, procedures and guidelines
-   described in this document.
-
-1.2. Roles within a Working Group
-
-   The document, "Organizations Involved in the IETF Standards Process"
-   [2] describes the roles of a number of individuals within a working
-   group, including the working group chair and the document editor.
-   These descriptions are expanded later in this document.
-
-2. Working group formation
-
-   IETF working groups (WGs) are the primary mechanism for development
-   of IETF specifications and guidelines, many of which are intended to
-   be standards or recommendations. A working group may be established
-   at the initiative of an Area Director or it may be initiated by an
-   individual or group of individuals. Anyone interested in creating an
-   IETF working group MUST obtain the advice and consent of the IETF
-   Area Director(s) in whose area the working group would fall and MUST
-   proceed through the formal steps detailed in this section.
-
-   Working groups are typically created to address a specific problem or
-   to produce one or more specific deliverables (a guideline, standards
-   specification, etc.).  Working groups are generally expected to be
-   short-lived in nature.  Upon completion of its goals and achievement
-   of its objectives, the working group is terminated. A working group
-   may also be terminated for other reasons (see section 4).
-   Alternatively, with the concurrence of the IESG, Area Director, the
-   WG Chair, and the WG participants, the objectives or assignment of
-   the working group may be extended by modifying the working group's
-   charter through a rechartering process (see section 5).
-
-2.1. Criteria for formation
-
-   When determining whether it is appropriate to create a working group,
-   the Area Director(s) and the IESG will consider several issues:
-
-    - Are the issues that the working group plans to address clear and
-      relevant to the Internet community?
-
-    - Are the goals specific and reasonably achievable, and achievable
-      within a reasonable time frame?
-
-
-
-Bradner                  Best Current Practice                  [Page 4]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-    - What are the risks and urgency of the work, to determine the level
-      of effort required?
-
-    - Do the working group's activities overlap with those of another
-      working group?  If so, it may still be appropriate to create the
-      working group, but this question must be considered carefully by
-      the Area Directors as subdividing efforts often dilutes the
-      available technical expertise.
-
-    - Is there sufficient interest within the IETF in the working
-      group's topic with enough people willing to expend the effort to
-      produce the desired result (e.g., a protocol specification)?
-      Working groups require considerable effort, including management
-      of the working group process, editing of working group documents,
-      and contributing to the document text.  IETF experience suggests
-      that these roles typically cannot all be handled by one person; a
-      minimum of four or five active participants in the management
-      positions are typically required in addition to a minimum of one
-      or two dozen people that will attend the working group meetings
-      and contribute on the mailing list.  NOTE: The interest must be
-      broad enough that a working group would not be seen as merely the
-      activity of a single vendor.
-
-    - Is there enough expertise within the IETF in the working group's
-      topic, and are those people interested in contributing in the
-      working group?
-
-    - Does a base of interested consumers (end-users) appear to exist
-      for the planned work?  Consumer interest can be measured by
-      participation of end-users within the IETF process, as well as by
-      less direct means.
-
-    - Does the IETF have a reasonable role to play in the determination
-      of the technology?  There are many Internet-related technologies
-      that may be interesting to IETF members but in some cases the IETF
-      may not be in a position to effect the course of the technology in
-      the "real world".  This can happen, for example, if the technology
-      is being developed by another standards body or an industry
-      consortium.
-
-    - Are all known intellectual property rights relevant to the
-      proposed working group's efforts issues understood?
-
-    - Is the proposed work plan an open IETF effort or is it an attempt
-      to "bless" non-IETF technology where the effect of input from IETF
-      participants may be limited?
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 5]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-    - Is there a good understanding of any existing work that is
-      relevant to the topics that the proposed working group is to
-      pursue?  This includes work within the IETF and elsewhere.
-
-    - Do the working group's goals overlap with known work in another
-      standards body, and if so is adequate liaison in place?
-
-   Considering the above criteria, the Area Director(s), using his or
-   her best judgement, will decide whether to pursue the formation of
-   the group through the chartering process.
-
-2.2. Charter
-
-   The formation of a working group requires a charter which is
-   primarily negotiated between a prospective working group Chair and
-   the relevant Area Director(s), although final approval is made by the
-   IESG with advice from the Internet Architecture Board (IAB).  A
-   charter is a contract between a working group and the IETF to perform
-   a set of tasks.  A charter:
-
-   1. Lists relevant administrative information for the working group;
-   2. Specifies the direction or objectives of the working group and
-      describes the approach that will be taken to achieve the goals;
-      and
-   3. Enumerates a set of milestones together with time frames for their
-      completion.
-
-   When the prospective Chair(s), the Area Director and the IETF
-   Secretariat are satisfied with the charter form and content, it
-   becomes the basis for forming a working group. Note that an Area
-   Director MAY require holding an exploratory Birds of a Feather (BOF)
-   meeting, as described below, to gage the level of support for a
-   working group before submitting the charter to the IESG and IAB for
-   approval.
-
-   Charters may be renegotiated periodically to reflect the current
-   status, organization or goals of the working group (see section 5).
-   Hence, a charter is a contract between the IETF and the working group
-   which is committing to meet explicit milestones and delivering
-   specific "products".
-
-   Specifically, each charter consists of the following sections:
-
-   Working group name
-      A working group name should be reasonably descriptive or
-      identifiable. Additionally, the group shall define an acronym
-      (maximum 8 printable ASCII characters) to reference the group in
-      the IETF directories, mailing lists, and general documents.
-
-
-
-Bradner                  Best Current Practice                  [Page 6]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Chair(s)
-      The working group may have one or more Chairs to perform the
-      administrative functions of the group. The email address(es) of
-      the Chair(s) shall be included.  Generally, a working group is
-      limited to two chairs.
-
-   Area and Area Director(s)
-      The name of the IETF area with which the working group is
-      affiliated and the name and electronic mail address of the
-      associated Area Director(s).
-
-   Responsible Area Director
-      The Area Director who acts as the primary IESG contact for the
-      working group.
-
-   Mailing list
-      An IETF working group MUST have a general Internet mailing list.
-      Most of the work of an IETF working group will be conducted on the
-      mailing list. The working group charter MUST include:
-
-      1. The address to which a participant sends a subscription request
-         and the procedures to follow when subscribing,
-
-      2. The address to which a participant sends submissions and
-         special procedures, if any, and
-
-      3. The location of the mailing list archive. A message archive
-         MUST be maintained in a public place which can be accessed via
-         FTP or via the web.
-
-         As a service to the community, the IETF Secretariat operates a
-         mailing list archive for working group mailing lists. In order
-         to take advantage of this service, working group mailing lists
-         MUST include the address "wg_acronym-archive@lists.ietf.org"
-         (where "wg_acronym" is the working group acronym) in the
-         mailing list in order that a copy of all mailing list messages
-         be recorded in the Secretariat's archive.  Those archives are
-         located at ftp://ftp.ietf.org/ietf-mail-archive.  For
-         robustness, WGs SHOULD maintain an additional archive separate
-         from that maintained by the Secretariat.
-
-   Description of working group
-      The focus and intent of the group shall be set forth briefly. By
-      reading this section alone, an individual should be able to decide
-      whether this group is relevant to their own work. The first
-      paragraph must give a brief summary of the problem area, basis,
-      goal(s) and approach(es) planned for the working group.  This
-      paragraph can be used as an overview of the working group's
-
-
-
-Bradner                  Best Current Practice                  [Page 7]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-      effort.
-
-      To facilitate evaluation of the intended work and to provide on-
-      going guidance to the working group, the charter must describe the
-      problem being solved and should discuss objectives and expected
-      impact with respect to:
-
-         - Architecture
-         - Operations
-         - Security
-         - Network management
-         - Scaling
-         - Transition (where applicable)
-
-   Goals and milestones
-      The working group charter MUST establish a timetable for specific
-      work items.  While this may be renegotiated over time, the list of
-      milestones and dates facilitates the Area Director's tracking of
-      working group progress and status, and it is indispensable to
-      potential participants identifying the critical moments for input.
-      Milestones shall consist of deliverables that can be qualified as
-      showing specific achievement; e.g., "Internet-Draft finished" is
-      fine, but "discuss via email" is not. It is helpful to specify
-      milestones for every 3-6 months, so that progress can be gauged
-      easily.  This milestone list is expected to be updated
-      periodically (see section 5).
-
-      An example of a WG charter is included as Appendix A.
-
-2.3. Charter review & approval
-
-   Proposed working groups often comprise technically competent
-   participants who are not familiar with the history of Internet
-   architecture or IETF processes.  This can, unfortunately, lead to
-   good working group consensus about a bad design.  To facilitate
-   working group efforts, an Area Director may assign a Consultant from
-   among the ranks of senior IETF participants.  (Consultants are
-   described in section 6.)  At the discretion of the Area Director,
-   approval of a new WG may be withheld in the absence of sufficient
-   consultant resources.
-
-   Once the Area Director (and the Area Directorate, as the Area
-   Director deems appropriate) has approved the working group charter,
-   the charter is submitted for review by the IAB and approval by the
-   IESG.  After a review period of at least a week the proposed charter
-   is posted to the IETF-announce mailing list as a public notice that
-   the formation of the working group is being considered.  At the same
-   time the proposed charter is also posted to the "new-work" mailing
-
-
-
-Bradner                  Best Current Practice                  [Page 8]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   list.  This mailing list has been created to let qualified
-   representatives from other standards organizations know about pending
-   IETF working groups.  After another review period lasting at least a
-   week the IESG MAY approve the charter as-is, it MAY request that
-   changes be made in the charter, or MAY decline to approve chartering
-   of the working group
-
-   If the IESG approves the formation of the working group it remands
-   the approved charter to the IETF Secretariat who records and enters
-   the information into the IETF tracking database.  The working group
-   is announced to the IETF-announce a by the IETF Secretariat.
-
-2.4. Birds of a Feather (BOF)
-
-   Often it is not clear whether an issue merits the formation of a
-   working group.  To facilitate exploration of the issues the IETF
-   offers the possibility of a Birds of a Feather (BOF) session, as well
-   as the early formation of an email list for preliminary discussion.
-   In addition, a BOF may serve as a forum for a single presentation or
-   discussion, without any intent to form a working group.
-
-   A BOF is a session at an IETF meeting which permits "market research"
-   and technical "brainstorming".  Any individual may request permission
-   to hold a BOF on a subject. The request MUST be filed with a relevant
-   Area Director who must approve a BOF before it can be scheduled. The
-   person who requests the BOF may be asked to serve as Chair of the
-   BOF.
-
-   The Chair of the BOF is also responsible for providing a report on
-   the outcome of the BOF.  If the Area Director approves, the BOF is
-   then scheduled by submitting a request to agenda@ietf.org with copies
-   to the Area Director(s). A BOF description and agenda are required
-   before a BOF can be scheduled.
-
-   Available time for BOFs is limited, and BOFs are held at the
-   discretion of the ADs for an area.  The AD(s) may require additional
-   assurances before authorizing a BOF.  For example,
-
-    - The Area Director MAY require the establishment of an open email
-      list prior to authorizing a BOF.  This permits initial exchanges
-      and sharing of framework, vocabulary and approaches, in order to
-      make the time spent in the BOF more productive.
-
-    - The Area Director MAY require that a BOF be held, prior to
-      establishing a working group (see section 2.2).
-
-    - The Area Director MAY require that there be a draft of the WG
-      charter prior to holding a BOF.
-
-
-
-Bradner                  Best Current Practice                  [Page 9]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-    - The Area Director MAY require that a BOF not be held until an
-      Internet-Draft describing the proposed technology has been
-      published so it can be used as a basis for discussion in the BOF.
-
-   In general, a BOF on a particular topic is held only once (ONE slot
-   at one IETF Plenary meeting). Under unusual circumstances Area
-   Directors may, at their discretion, allow a BOF to meet for a second
-   time. BOFs are not permitted to meet three times.  Note that all
-   other things being equal, WGs will be given priority for meeting
-   space over BOFs.  Also, occasionally BOFs may be held for other
-   purposes than to discuss formation of a working group.
-
-   Usually the outcome of a BOF will be one of the following:
-
-    - There was enough interest and focus in the subject to warrant the
-      formation of a WG;
-
-    - While there was a reasonable level of interest expressed in the
-      BOF some other criteria for working group formation was not met
-      (see section 2.1).
-
-    - The discussion came to a fruitful conclusion, with results to be
-      written down and published, however there is no need to establish
-      a WG; or
-
-    - There was not enough interest in the subject to warrant the
-      formation of a WG.
-
-3.  Working Group Operation
-
-   The IETF has basic requirements for open and fair participation and
-   for thorough consideration of technical alternatives.  Within those
-   constraints, working groups are autonomous and each determines most
-   of the details of its own operation with respect to session
-   participation, reaching closure, etc. The core rule for operation is
-   that acceptance or agreement is achieved via working group "rough
-   consensus".  WG participants should specifically note the
-   requirements for disclosure of conflicts of interest in [2].
-
-   A number of procedural questions and issues will arise over time, and
-   it is the function of the Working Group Chair(s) to manage the group
-   process, keeping in mind that the overall purpose of the group is to
-   make progress towards reaching rough consensus in realizing the
-   working group's goals and objectives.
-
-   There are few hard and fast rules on organizing or conducting working
-   group activities, but a set of guidelines and practices has evolved
-   over time that have proven successful. These are listed here, with
-
-
-
-Bradner                  Best Current Practice                 [Page 10]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   actual choices typically determined by the working group participants
-   and the Chair(s).
-
-3.1. Session planning
-
-   For coordinated, structured WG interactions, the Chair(s) MUST
-   publish a draft agenda well in advance of the actual session. The
-   agenda should contain at least:
-
-   - The items for discussion;
-   - The estimated time necessary per item; and
-   - A clear indication of what documents the participants will need to
-     read before the session in order to be well prepared.
-
-   Publication of the working group agenda shall include sending a copy
-   of the agenda to the working group mailing list and to
-   agenda@ietf.org.
-
-   All working group actions shall be taken in a public forum, and wide
-   participation is encouraged. A working group will conduct much of its
-   business via electronic mail distribution lists but may meet
-   periodically to discuss and review task status and progress, to
-   resolve specific issues and to direct future activities.  IETF
-   Plenary meetings are the primary venue for these face-to-face working
-   group sessions, and it is common (though not required) that active
-   "interim" face-to-face meetings, telephone conferences, or video
-   conferences may also be held.  Interim meetings are subject to the
-   same rules for advance notification, reporting, open participation,
-   and process, which apply to other working group meetings.
-
-   All working group sessions (including those held outside of the IETF
-   meetings) shall be reported by making minutes available.  These
-   minutes should include the agenda for the session, an account of the
-   discussion including any decisions made, and a list of attendees. The
-   Working Group Chair is responsible for insuring that session minutes
-   are written and distributed, though the actual task may be performed
-   by someone designated by the Working Group Chair. The minutes shall
-   be submitted in printable ASCII text for publication in the IETF
-   Proceedings, and for posting in the IETF Directories and are to be
-   sent to: minutes@ietf.org
-
-3.2. Session venue
-
-   Each working group will determine the balance of email and face-to-
-   face sessions that is appropriate for achieving its milestones.
-   Electronic mail permits the widest participation; face-to-face
-   meetings often permit better focus and therefore can be more
-   efficient for reaching a consensus among a core of the working group
-
-
-
-Bradner                  Best Current Practice                 [Page 11]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   participants.  In determining the balance, the WG must ensure that
-   its process does not serve to exclude contribution by email-only
-   participants.  Decisions reached during a face-to-face meeting about
-   topics or issues which have not been discussed on the mailing list,
-   or are significantly different from previously arrived mailing list
-   consensus MUST be reviewed on the mailing list.
-
-   IETF Meetings
-   If a WG needs a session at an IETF meeting, the Chair must apply for
-   time-slots as soon as the first announcement of that IETF meeting is
-   made by the IETF Secretariat to the WG-chairs list.  Session time is
-   a scarce resource at IETF meetings, so placing requests early will
-   facilitate schedule coordination for WGs requiring the same set of
-   experts.
-
-   The application for a WG session at an IETF meeting MUST be made to
-   the IETF Secretariat at the address agenda@ietf.org.  Some Area
-   Directors may want to coordinate WG sessions in their area and
-   request that time slots be coordinated through them.  If this is the
-   case it will be noted in the IETF meeting announcement. A WG
-   scheduling request MUST contain:
-
-   - The working group name and full title;
-   - The amount of time requested;
-   - The rough outline of the WG agenda that is expected to be covered;
-   - The estimated number of people that will attend the WG session;
-   - Related WGs that should not be scheduled for the same time slot(s);
-     and
-   - Optionally a request can be added for the WG session to be
-     transmitted over the Internet in audio and video.
-
-   NOTE: While open discussion and contribution is essential to working
-   group success, the Chair is responsible for ensuring forward
-   progress.  When acceptable to the WG, the Chair may call for
-   restricted participation (but not restricted attendance!) at IETF
-   working group sessions for the purpose of achieving progress. The
-   Working Group Chair then has the authority to refuse to grant the
-   floor to any individual who is unprepared or otherwise covering
-   inappropriate material, or who, in the opinion of the Chair is
-   disrupting the WG process.  The Chair should consult with the Area
-   Director(s) if the individual persists in disruptive behavior.
-
-   On-line
-   It can be quite useful to conduct email exchanges in the same manner
-   as a face-to-face session, with published schedule and agenda, as
-   well as on-going summarization and consensus polling.
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 12]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Many working group participants hold that mailing list discussion is
-   the best place to consider and resolve issues and make decisions. The
-   choice of operational style is made by the working group itself.  It
-   is important to note, however, that Internet email discussion is
-   possible for a much wider base of interested persons than is
-   attendance at IETF meetings, due to the time and expense required to
-   attend.
-
-   As with face-to-face sessions occasionally one or more individuals
-   may engage in behavior on a mailing list which disrupts the WG's
-   progress.  In these cases the Chair should attempt to discourage the
-   behavior by communication directly with the offending individual
-   rather than on the open mailing list.  If the behavior persists then
-   the Chair must involve the Area Director in the issue.  As a last
-   resort and after explicit warnings, the Area Director, with the
-   approval of the IESG, may request that the mailing list maintainer
-   block the ability of the offending individual to post to the mailing
-   list. (If the mailing list software permits this type of operation.)
-   Even if this is done, the individual must not be prevented from
-   receiving messages posted to the list.  Other methods of mailing list
-   control may be considered but must be approved by the AD(s) and the
-   IESG.
-
-3.3. Session management
-
-   Working groups make decisions through a "rough consensus" process.
-   IETF consensus does not require that all participants agree although
-   this is, of course, preferred.  In general, the dominant view of the
-   working group shall prevail.  (However, it must be noted that
-   "dominance" is not to be determined on the basis of volume or
-   persistence, but rather a more general sense of agreement.) Consensus
-   can be determined by a show of hands, humming, or any other means on
-   which the WG agrees (by rough consensus, of course).  Note that 51%
-   of the working group does not qualify as "rough consensus" and 99% is
-   better than rough.  It is up to the Chair to determine if rough
-   consensus has been reached.
-
-   It can be particularly challenging to gauge the level of consensus on
-   a mailing list.  There are two different cases where a working group
-   may be trying to understand the level of consensus via a mailing list
-   discussion. But in both cases the volume of messages on a topic is
-   not, by itself, a good indicator of consensus since one or two
-   individuals may be generating much of the traffic.
-
-   In the case where a consensus which has been reached during a face-
-   to-face meeting is being verified on a mailing list the people who
-   were in the meeting and expressed agreement must be taken into
-   account.  If there were 100 people in a meeting and only a few people
-
-
-
-Bradner                  Best Current Practice                 [Page 13]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   on the mailing list disagree with the consensus of the meeting then
-   the consensus should be seen as being verified.  Note that enough
-   time should be given to the verification process for the mailing list
-   readers to understand and consider any objections that may be raised
-   on the list.  The normal two week last-call period should be
-   sufficient for this.
-
-   The other case is where the discussion has been held entirely over
-   the mailing list.  The determination of the level of consensus may be
-   harder to do in this case since most people subscribed to mailing
-   lists do not actively participate in discussions on the list. It is
-   left to the discretion of the working group chair how to evaluate the
-   level of consensus.  The most common method used is for the working
-   group chair to state what he or she believes to be the consensus view
-   and. at the same time, requests comments from the list about the
-   stated conclusion.
-
-   The challenge to managing working group sessions is to balance the
-   need for open and fair consideration of the issues against the need
-   to make forward progress.  The working group, as a whole, has the
-   final responsibility for striking this balance.  The Chair has the
-   responsibility for overseeing the process but may delegate direct
-   process management to a formally-designated Facilitator.
-
-   It is occasionally appropriate to revisit a topic, to re-evaluate
-   alternatives or to improve the group's understanding of a relevant
-   decision.  However, unnecessary repeated discussions on issues can be
-   avoided if the Chair makes sure that the main arguments in the
-   discussion (and the outcome) are summarized and archived after a
-   discussion has come to conclusion. It is also good practice to note
-   important decisions/consensus reached by email in the minutes of the
-   next 'live' session, and to summarize briefly the decision-making
-   history in the final documents the WG produces.
-
-   To facilitate making forward progress, a Working Group Chair may wish
-   to decide to reject or defer the input from a member, based upon the
-   following criteria:
-
-   Old
-   The input pertains to a topic that already has been resolved and is
-   redundant with information previously available;
-
-   Minor
-   The input is new and pertains to a topic that has already been
-   resolved, but it is felt to be of minor import to the existing
-   decision;
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 14]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Timing
-   The input pertains to a topic that the working group has not yet
-   opened for discussion; or
-
-   Scope
-   The input is outside of the scope of the working group charter.
-
-3.4. Contention and appeals
-
-   Disputes are possible at various stages during the IETF process. As
-   much as possible the process is designed so that compromises can be
-   made, and genuine consensus achieved; however, there are times when
-   even the most reasonable and knowledgeable people are unable to
-   agree.  To achieve the goals of openness and fairness, such conflicts
-   must be resolved by a process of open review and discussion.
-
-   Formal procedures for requesting a review of WG, Chair, Area Director
-   or IESG actions and conducting appeals are documented in The Internet
-   Standards Process [1].
-
-4. Working Group Termination
-
-   Working groups are typically chartered to accomplish a specific task
-   or tasks.  After the tasks are complete, the group will be disbanded.
-   However, if a WG produces a Proposed or Draft Standard, the WG will
-   frequently become dormant rather than disband (i.e., the WG will no
-   longer conduct formal activities, but the mailing list will remain
-   available to review the work as it moves to Draft Standard and
-   Standard status.)
-
-   If, at some point, it becomes evident that a working group is unable
-   to complete the work outlined in the charter, or if the assumptions
-   which that work was based have been modified in discussion or by
-   experience, the Area Director, in consultation with the working group
-   can either:
-
-   1. Recharter to refocus its tasks,
-   2. Choose new Chair(s), or
-   3. Disband.
-
-   If the working group disagrees with the Area Director's choice, it
-   may appeal to the IESG (see section 3.4).
-
-5. Rechartering a Working Group
-
-   Updated milestones are renegotiated with the Area Director and the
-   IESG, as needed, and then are submitted to the IESG Secretariat:
-   iesg-secretary@ietf.org.
-
-
-
-Bradner                  Best Current Practice                 [Page 15]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Rechartering (other than revising milestones) a working group follows
-   the same procedures that the initial chartering does (see section 2).
-   The revised charter must be submitted to the IESG and IAB for
-   approval.  As with the initial chartering, the IESG may approve new
-   charter as-is, it may request that changes be made in the new charter
-   (including having the Working Group continue to use the old charter),
-   or it may decline to approve the rechartered working group.  In the
-   latter case, the working group is disbanded.
-
-6. Staff Roles
-
-   Working groups require considerable care and feeding.  In addition to
-   general participation, successful working groups benefit from the
-   efforts of participants filling specific functional roles.  The Area
-   Director must agree to the specific people performing the WG Chair,
-   and Working Group Consultant roles, and they serve at the discretion
-   of the Area Director.
-
-6.1. WG Chair
-
-   The Working Group Chair is concerned with making forward progress
-   through a fair and open process, and has wide discretion in the
-   conduct of WG business.  The Chair must ensure that a number of tasks
-   are performed, either directly or by others assigned to the tasks.
-
-   The Chair has the responsibility and the authority to make decisions,
-   on behalf of the working group, regarding all matters of working
-   group process and staffing, in conformance with the rules of the
-   IETF.  The AD has the authority and the responsibility to assist in
-   making those decisions at the request of the Chair or when
-   circumstances warrant such an intervention.
-
-   The Chair's responsibility encompasses at least the following:
-
-   Ensure WG process and content management
-
-      The Chair has ultimate responsibility for ensuring that a working
-      group achieves forward progress and meets its milestones.  The
-      Chair is also responsible to ensure that the working group
-      operates in an open and fair manner.  For some working groups,
-      this can be accomplished by having the Chair perform all
-      management-related activities.  In other working groups --
-      particularly those with large or divisive participation -- it is
-      helpful to allocate process and/or secretarial functions to other
-      participants.  Process management pertains strictly to the style
-      of working group interaction and not to its content. It ensures
-      fairness and detects redundancy.  The secretarial function
-      encompasses document editing.  It is quite common for a working
-
-
-
-Bradner                  Best Current Practice                 [Page 16]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-      group to assign the task of specification Editor to one or two
-      participants.  Sometimes, they also are part of the design team,
-      described below.
-
-   Moderate the WG email list
-
-      The Chair should attempt to ensure that the discussions on this
-      list are relevant and that they converge to consensus agreements.
-      The Chair should make sure that discussions on the list are
-      summarized and that the outcome is well documented (to avoid
-      repetition).  The Chair also may choose to schedule organized on-
-      line "sessions" with agenda and deliverables.  These can be
-      structured as true meetings, conducted over the course of several
-      days (to allow participation across the Internet).
-
-      Organize, prepare and chair face-to-face and on-line formal
-      sessions.
-
-   Plan WG Sessions
-
-      The Chair must plan and announce all WG sessions well in advance
-      (see section 3.1).
-
-   Communicate results of sessions
-
-      The Chair and/or Secretary must ensure that minutes of a session
-      are taken and that an attendance list is circulated (see section
-      3.1).
-
-      Immediately after a session, the WG Chair MUST provide the Area
-      Director with a very short report (approximately one paragraph,
-      via email) on the session.
-
-   Distribute the workload
-
-      Of course, each WG will have participants who may not be able (or
-      want) to do any work at all. Most of the time the bulk of the work
-      is done by a few dedicated participants. It is the task of the
-      Chair to motivate enough experts to allow for a fair distribution
-      of the workload.
-
-   Document development
-
-      Working groups produce documents and documents need authors. The
-      Chair must make sure that authors of WG documents incorporate
-      changes as agreed to by the WG (see section 6.3).
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 17]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Document publication
-
-      The Chair and/or Document Editor will work with the RFC Editor to
-      ensure document conformance with RFC publication requirements [5]
-      and to coordinate any editorial changes suggested by the RFC
-      Editor.  A particular concern is that all participants are working
-      from the same version of a document at the same time.
-
-   Document implementations
-
-      Under the procedures described in [1], the Chair is responsible
-      for documenting the specific implementations which qualify the
-      specification for Draft or Internet Standard status along with
-      documentation about testing of the interoperation of these
-      implementations.
-
-6.2. WG Secretary
-
-   Taking minutes and editing working group documents often is performed
-   by a specifically-designated participant or set of participants.  In
-   this role, the Secretary's job is to record WG decisions, rather than
-   to perform basic specification.
-
-6.3. Document Editor
-
-   Most IETF working groups focus their efforts on a document, or set of
-   documents, that capture the results of the group's work.  A working
-   group generally designates a person or persons to serve as the Editor
-   for a particular document.  The Document Editor is responsible for
-   ensuring that the contents of the document accurately reflect the
-   decisions that have been made by the working group.
-
-   As a general practice, the Working Group Chair and Document Editor
-   positions are filled by different individuals to help ensure that the
-   resulting documents accurately reflect the consensus of the working
-   group and that all processes are followed.
-
-6.4. WG Facilitator
-
-   When meetings tend to become distracted or divisive, it often is
-   helpful to assign the task of "process management" to one
-   participant.  Their job is to oversee the nature, rather than the
-   content, of participant interactions.  That is, they attend to the
-   style of the discussion and to the schedule of the agenda, rather
-   than making direct technical contributions themselves.
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 18]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-6.5. Design teams
-
-   It is often useful, and perhaps inevitable, for a sub-group of a
-   working group to develop a proposal to solve a particular problem.
-   Such a sub-group is called a design team.  In order for a design team
-   to remain small and agile, it is acceptable to have closed membership
-   and private meetings.  Design teams may range from an informal chat
-   between people in a hallway to a formal set of expert volunteers that
-   the WG chair or AD appoints to attack a controversial problem.  The
-   output of a design team is always subject to approval, rejection or
-   modification by the WG as a whole.
-
-6.6. Working Group Consultant
-
-   At the discretion of the Area Director, a Consultant may be assigned
-   to a working group.  Consultants have specific technical background
-   appropriate to the WG and experience in Internet architecture and
-   IETF process.
-
-6.7. Area Director
-
-   Area Directors are responsible for ensuring that working groups in
-   their area produce coherent, coordinated, architecturally consistent
-   and timely output as a contribution to the overall results of the
-   IETF.
-
-7.  Working Group Documents
-
-7.1. Session documents
-
-   All relevant documents to be discussed at a session should be
-   published and available as Internet-Drafts at least two weeks before
-   a session starts.  Any document which does not meet this publication
-   deadline can only be discussed in a working group session with the
-   specific approval of the working group chair(s).  Since it is
-   important that working group members have adequate time to review all
-   documents, granting such an exception should only be done under
-   unusual conditions.  The final session agenda should be posted to the
-   working group mailing list at least two weeks before the session and
-   sent at that time to agenda@ietf.org for publication on the IETF web
-   site.
-
-7.2. Internet-Drafts (I-D)
-
-   The Internet-Drafts directory is provided to working groups as a
-   resource for posting and disseminating in-process copies of working
-   group documents. This repository is replicated at various locations
-   around the Internet. It is encouraged that draft documents be posted
-
-
-
-Bradner                  Best Current Practice                 [Page 19]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   as soon as they become reasonably stable.
-
-   It is stressed here that Internet-Drafts are working documents and
-   have no official standards status whatsoever. They may, eventually,
-   turn into a standards-track document or they may sink from sight.
-   Internet-Drafts are submitted to: internet-drafts@ietf.org
-
-   The format of an Internet-Draft must be the same as for an RFC [2].
-   Further, an I-D must contain:
-
-   - Beginning, standard, boilerplate text which is provided by the
-     Secretariat on their web site and in the ftp directory;
-   - The I-D filename; and
-   - The expiration date for the I-D.
-
-   Complete specification of requirements for an Internet-Draft are
-   found in the file "1id-guidelines.txt" in the Internet-Drafts
-   directory at an Internet Repository site.  The organization of the
-   Internet-Drafts directory is found in the file "1id-organization" in
-   the Internet-Drafts directory at an Internet Repository site.  This
-   file also contains the rules for naming Internet-Drafts.  (See [1]
-   for more information about Internet-Drafts.)
-
-7.3. Request For Comments (RFC)
-
-   The work of an IETF working group often results in publication of one
-   or more documents, as part of the Request For Comments (RFCs) [1]
-   series. This series is the archival publication record for the
-   Internet community. A document can be written by an individual in a
-   working group, by a group as a whole with a designated Editor, or by
-   others not involved with the IETF.
-
-   NOTE: The RFC series is a publication mechanism only and publication
-   does not determine the IETF status of a document.  Status is
-   determined through separate, explicit status labels assigned by the
-   IESG on behalf of the IETF.  In other words, the reader is reminded
-   that all Internet Standards are published as RFCs, but NOT all RFCs
-   specify standards [4].
-
-7.4. Working Group Last-Call
-
-   When a WG decides that a document is ready for publication it may be
-   submitted to the IESG for consideration. In most cases the
-   determination that a WG feels that a document is ready for
-   publication is done by the WG Chair issuing a working group Last-
-   Call.  The decision to issue a working group Last-Call is at the
-   discretion of the WG Chair working with the Area Director.  A working
-   group Last-Call serves the same purpose within a working group that
-
-
-
-Bradner                  Best Current Practice                 [Page 20]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   an IESG Last-Call does in the broader IETF community (see [1]).
-
-7.5. Submission of documents
-
-   Once that a WG has determined at least rough consensus exists within
-   the WG for the advancement of a document the following must be done:
-
-   - The version of the relevant document exactly as agreed to by the WG
-     MUST be in the Internet-Drafts directory.
-
-   - The relevant document MUST be formatted according to section 7.3.
-
-   - The WG Chair MUST send email to the relevant Area Director.  A copy
-     of the request MUST be also sent to the IESG Secretariat.  The mail
-     MUST contain the reference to the document's ID filename, and the
-     action requested.  The copy of the message to the IESG Secretariat
-     is to ensure that the request gets recorded by the Secretariat so
-     that they can monitor the progress of the document through the
-     process.
-
-   Unless returned by the IESG to the WG for further development,
-   progressing of the document is then the responsibility of the IESG.
-   After IESG approval, responsibility for final disposition is the
-   joint responsibility of the RFC Editor, the WG Chair and the Document
-   Editor.
-
-8. Review of documents
-
-   The IESG reviews all documents submitted for publication as RFCs.
-   Usually minimal IESG review is necessary in the case of a submission
-   from a WG intended as an Informational or Experimental RFC. More
-   extensive review is undertaken in the case of standards-track
-   documents.
-
-   Prior to the IESG beginning their deliberations on standards-track
-   documents, IETF Secretariat will issue a "Last-Call" to the IETF
-   mailing list (see [1]). This Last Call will announce the intention of
-   the IESG to consider the document, and it will solicit final comments
-   from the IETF within a period of two weeks.  It is important to note
-   that a Last-Call is intended as a brief, final check with the
-   Internet community, to make sure that no important concerns have been
-   missed or misunderstood. The Last-Call should not serve as a more
-   general, in-depth review.
-
-   The IESG review takes into account responses to the Last-Call and
-   will lead to one of these possible conclusions:
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 21]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   1. The document is accepted as is for the status requested.
-      This fact will be announced by the IETF Secretariat to the IETF
-      mailing list and to the RFC Editor.
-
-   2. The document is accepted as-is but not for the status requested.
-      This fact will be announced by the IETF Secretariat to the IETF
-      mailing list and to the RFC Editor (see [1] for more details).
-
-   3. Changes regarding content are suggested to the author(s)/WG.
-      Suggestions from the IESG must be clear and direct, so as to
-      facilitate working group and author correction of the
-      specification.  If the author(s)/WG can explain to the
-      satisfaction of the IESG why the changes are not necessary, the
-      document will be accepted for publication as under point 1, above.
-      If the changes are made the revised document may be resubmitted
-      for IESG review.
-
-   4. Changes are suggested by the IESG and a change in status is
-      recommended.
-      The process described above for 3 and 2 are followed in that
-      order.
-
-   5. The document is rejected.
-      Any document rejection will be accompanied by specific and
-      thorough arguments from the IESG. Although the IETF and working
-      group process is structured such that this alternative is not
-      likely to arise for documents coming from a working group, the
-      IESG has the right and responsibility to reject documents that the
-      IESG feels are fatally flawed in some way.
-
-      If any individual or group of individuals feels that the review
-      treatment has been unfair, there is the opportunity to make a
-      procedural complaint. The mechanism for this type of complaints is
-      described in [1].
-
-9. Security Considerations
-
-   Documents describing IETF processes, such as this one, do not have an
-   impact on the security of the network infrastructure or of Internet
-   applications.
-
-   It should be noted that all IETF working groups are required to
-   examine and understand the security implications of any technology
-   they develop.  This analysis must be included in any resulting RFCs
-   in a Security Considerations section.  Note that merely noting a
-   significant security hole is no longer sufficient.  IETF developed
-   technologies should not add insecurity to the environment in which
-   they are run.
-
-
-
-Bradner                  Best Current Practice                 [Page 22]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-10. Acknowledgments
-
-   This revision of this document relies heavily on the previous version
-   (RFC 1603) which was edited by Erik Huizer and Dave Crocker.  It has
-   been reviewed by the Poisson Working Group.
-
-11. References
-
-   [1] Bradner, S., Editor, "The Internet Standards Process -- Revision
-       3", BCP 9, RFC 2026, October 1996.
-
-   [2] Hovey, R., and S. Bradner, "The Organizations involved in the
-       IETF Standards Process", BCP 11, RFC 2028, October 1996.
-
-   [3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall
-       Process: Operation of the Nominating and Recall Committees", BCP
-       10, RFC 2282, February 1998.
-
-   [4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
-       RFC 1796, April 1995.
-
-   [5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC
-       2223, October 1997.
-
-   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
-       Level", BCP 14, RFC 2119, March 1997.
-
-
-12. Editor's Address
-
-   Scott Bradner
-   Harvard University
-   1350 Mass Ave.
-   Cambridge MA
-   02138
-   USA
-
-   Phone +1 617 495 3864
-   EMail: sob@harvard.edu
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 23]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Appendix:  Sample Working Group Charter
-
-   Working Group Name:
-        IP Telephony (iptel)
-
-   IETF Area:
-        Transport Area
-
-   Chair(s):
-        Jonathan Rosenberg <jdrosen@bell-labs.com>
-
-   Transport Area Director(s):
-        Scott Bradner <sob@harvard.edu>
-        Allyn Romanow <allyn@mci.net>
-
-   Responsible Area Director:
-        Allyn Romanow <allyn@mci.net>
-
-   Mailing Lists:
-        General Discussion:iptel@lists.research.bell-labs.com
-        To Subscribe: iptel-request@lists.research.bell-labs.com
-        Archive: http://www.bell-labs.com/mailing-lists/siptel
-
-   Description of Working Group:
-
-   Before Internet telephony can become a widely deployed service, a
-   number of protocols must be deployed. These include signaling and
-   capabilities exchange, but also include a number of "peripheral"
-   protocols for providing related services.
-
-   The primary purpose of this working group is to develop two such
-   supportive protocols and a frameword document. They are:
-
-   1. Call Processing Syntax. When a call is setup between two
-   endpoints, the signaling will generally pass through several servers
-   (such as an H.323 gatekeeper) which are responsible for forwarding,
-   redirecting, or proxying the signaling messages. For example, a user
-   may make a call to j.doe@bigcompany.com. The signaling message to
-   initiate the call will arrive at some server at bigcompany. This
-   server can inform the caller that the callee is busy, forward the
-   call initiation request to another server closer to the user, or drop
-   the call completely (among other possibilities). It is very desirable
-   to allow the callee to provide input to this process, guiding the
-   server in its decision on how to act. This can enable a wide variety
-   of advanced personal mobility and call agent services.
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 24]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Such preferences can be expressed in a call processing syntax, which
-   can be authored by the user (or generated automatically by some
-   tool), and then uploaded to the server. The group will develop this
-   syntax, and specify means of securely transporting and extending it.
-   The result will be a single standards track RFC.
-
-   2. In addition, the group will write a service model document, which
-   describes the services that are enabled by the call processing
-   syntax, and discusses how the syntax can be used. This document will
-   result in a single RFC.
-
-   3. Gateway Attribute Distribution Protocol. When making a call
-   between an IP host and a PSTN user, a telephony gateway must be used.
-   The selection of such gateways can be based on many criteria,
-   including client expressed preferences, service provider preferences,
-   and availability of gateways, in addition to destination telephone
-   number.  Since gateways outside of the hosts' administrative domain
-   might be used, a protocol is required to allow gateways in remote
-   domains to distribute their attributes (such as PSTN connectivity,
-   supported codecs, etc.) to entities in other domains which must make
-   a selection of a gateway. The protocol must allow for scalable,
-   bandwidth efficient, and very secure transmission of these
-   attributes. The group will investigate and design a protocol for this
-   purpose, generate an Internet Draft, and advance it to RFC as
-   appropriate.
-
-   Goals and Milestones:
-
-   May 98    Issue first Internet-Draft on service framework
-   Jul 98    Submit framework ID to IESG for publication as an RFC.
-   Aug 98    Issue first Internet-Draft on Call Processing Syntax
-   Oct 98    Submit Call processing syntax to IESG for consideration
-             as a Proposed Standard.
-   Dec 98    Achieve consensus on basics of gateway attribute
-             distribution protocol
-   Jan 99    Submit Gateway Attribute Distribution protocol to IESG
-             for consideration as a RFC (info, exp, stds track TB
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 25]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 26]
-
diff --git a/doc/rfc/rfc2535.txt b/doc/rfc/rfc2535.txt
deleted file mode 100644
index fe0b3d07..00000000
--- a/doc/rfc/rfc2535.txt
+++ /dev/null
@@ -1,2635 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         D. Eastlake
-Request for Comments: 2535                                            IBM
-Obsoletes: 2065                                                March 1999
-Updates: 2181, 1035, 1034
-Category: Standards Track
-
-                 Domain Name System Security Extensions
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   Extensions to the Domain Name System (DNS) are described that provide
-   data integrity and authentication to security aware resolvers and
-   applications through the use of cryptographic digital signatures.
-   These digital signatures are included in secured zones as resource
-   records.  Security can also be provided through non-security aware
-   DNS servers in some cases.
-
-   The extensions provide for the storage of authenticated public keys
-   in the DNS.  This storage of keys can support general public key
-   distribution services as well as DNS security.  The stored keys
-   enable security aware resolvers to learn the authenticating key of
-   zones in addition to those for which they are initially configured.
-   Keys associated with DNS names can be retrieved to support other
-   protocols.  Provision is made for a variety of key types and
-   algorithms.
-
-   In addition, the security extensions provide for the optional
-   authentication of DNS protocol transactions and requests.
-
-   This document incorporates feedback on RFC 2065 from early
-   implementers and potential users.
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Acknowledgments
-
-   The significant contributions and suggestions of the following
-   persons (in alphabetic order) to DNS security are gratefully
-   acknowledged:
-
-      James M. Galvin
-      John Gilmore
-      Olafur Gudmundsson
-      Charlie Kaufman
-      Edward Lewis
-      Thomas Narten
-      Radia J. Perlman
-      Jeffrey I. Schiller
-      Steven (Xunhua) Wang
-      Brian Wellington
-
-Table of Contents
-
-   Abstract...................................................1
-   Acknowledgments............................................2
-   1. Overview of Contents....................................4
-   2. Overview of the DNS Extensions..........................5
-   2.1 Services Not Provided..................................5
-   2.2 Key Distribution.......................................5
-   2.3 Data Origin Authentication and Integrity...............6
-   2.3.1 The SIG Resource Record..............................7
-   2.3.2 Authenticating Name and Type Non-existence...........7
-   2.3.3 Special Considerations With Time-to-Live.............7
-   2.3.4 Special Considerations at Delegation Points..........8
-   2.3.5 Special Considerations with CNAME....................8
-   2.3.6 Signers Other Than The Zone..........................9
-   2.4 DNS Transaction and Request Authentication.............9
-   3. The KEY Resource Record................................10
-   3.1 KEY RDATA format......................................10
-   3.1.1 Object Types, DNS Names, and Keys...................11
-   3.1.2 The KEY RR Flag Field...............................11
-   3.1.3 The Protocol Octet..................................13
-   3.2 The KEY Algorithm Number Specification................14
-   3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15
-   3.4 Determination of Zone Secure/Unsecured Status.........15
-   3.5 KEY RRs in the Construction of Responses..............17
-   4. The SIG Resource Record................................17
-   4.1 SIG RDATA Format......................................17
-   4.1.1 Type Covered Field..................................18
-   4.1.2 Algorithm Number Field..............................18
-   4.1.3 Labels Field........................................18
-   4.1.4 Original TTL Field..................................19
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   4.1.5 Signature Expiration and Inception Fields...........19
-   4.1.6 Key Tag Field.......................................20
-   4.1.7 Signer's Name Field.................................20
-   4.1.8 Signature Field.....................................20
-   4.1.8.1 Calculating Transaction and Request SIGs..........21
-   4.2 SIG RRs in the Construction of Responses..............21
-   4.3 Processing Responses and SIG RRs......................22
-   4.4 Signature Lifetime, Expiration, TTLs, and Validity....23
-   5. Non-existent Names and Types...........................24
-   5.1 The NXT Resource Record...............................24
-   5.2 NXT RDATA Format......................................25
-   5.3 Additional Complexity Due to Wildcards................26
-   5.4 Example...............................................26
-   5.5 Special Considerations at Delegation Points...........27
-   5.6 Zone Transfers........................................27
-   5.6.1 Full Zone Transfers.................................28
-   5.6.2 Incremental Zone Transfers..........................28
-   6. How to Resolve Securely and the AD and CD Bits.........29
-   6.1 The AD and CD Header Bits.............................29
-   6.2 Staticly Configured Keys..............................31
-   6.3 Chaining Through The DNS..............................31
-   6.3.1 Chaining Through KEYs...............................31
-   6.3.2 Conflicting Data....................................33
-   6.4 Secure Time...........................................33
-   7. ASCII Representation of Security RRs...................34
-   7.1 Presentation of KEY RRs...............................34
-   7.2 Presentation of SIG RRs...............................35
-   7.3 Presentation of NXT RRs...............................36
-   8. Canonical Form and Order of Resource Records...........36
-   8.1 Canonical RR Form.....................................36
-   8.2 Canonical DNS Name Order..............................37
-   8.3 Canonical RR Ordering Within An RRset.................37
-   8.4 Canonical Ordering of RR Types........................37
-   9. Conformance............................................37
-   9.1 Server Conformance....................................37
-   9.2 Resolver Conformance..................................38
-   10. Security Considerations...............................38
-   11. IANA Considerations...................................39
-   References................................................39
-   Author's Address..........................................41
-   Appendix A: Base 64 Encoding..............................42
-   Appendix B: Changes from RFC 2065.........................44
-   Appendix C: Key Tag Calculation...........................46
-   Full Copyright Statement..................................47
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-1. Overview of Contents
-
-   This document standardizes extensions of the Domain Name System (DNS)
-   protocol to support DNS security and public key distribution. It
-   assumes that the reader is familiar with the Domain Name System,
-   particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An
-   earlier version of these extensions appears in RFC 2065.  This
-   replacement for that RFC incorporates early implementation experience
-   and requests from  potential users.
-
-   Section 2 provides an overview of the extensions and the key
-   distribution, data origin authentication, and transaction and request
-   security they provide.
-
-   Section 3 discusses the KEY resource record, its structure, and use
-   in DNS responses.  These resource records represent the public keys
-   of entities named in the DNS and are used for key distribution.
-
-   Section 4 discusses the SIG digital signature resource record, its
-   structure, and use in DNS responses.  These resource records are used
-   to authenticate other resource records in the DNS and optionally to
-   authenticate DNS transactions and requests.
-
-   Section 5 discusses the NXT resource record (RR) and its use in DNS
-   responses including full and incremental zone transfers.  The NXT RR
-   permits authenticated denial of the existence of a name or of an RR
-   type for an existing name.
-
-   Section 6 discusses how a resolver can be configured with a starting
-   key or keys and proceed to securely resolve DNS requests.
-   Interactions between resolvers and servers are discussed for various
-   combinations of security aware and security non-aware.  Two
-   additional DNS header bits are defined for signaling between
-   resolvers and servers.
-
-   Section 7 describes the ASCII representation of the security resource
-   records for use in master files and elsewhere.
-
-   Section 8 defines the canonical form and order of RRs for DNS
-   security purposes.
-
-   Section 9 defines levels of conformance for resolvers and servers.
-
-   Section 10 provides a few paragraphs on overall security
-   considerations.
-
-   Section 11 specified IANA considerations for allocation of additional
-   values of paramters defined in this document.
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Appendix A gives details of base 64 encoding which is used in the
-   file representation of some RRs defined in this document.
-
-   Appendix B summarizes changes between this memo and RFC 2065.
-
-   Appendix C specified how to calculate the simple checksum used as a
-   key tag in most SIG RRs.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2. Overview of the DNS Extensions
-
-   The Domain Name System (DNS) protocol security extensions provide
-   three distinct services: key distribution as described in Section 2.2
-   below, data origin authentication as described in Section 2.3 below,
-   and transaction and request authentication, described in Section 2.4
-   below.
-
-   Special considerations related to "time to live", CNAMEs, and
-   delegation points are also discussed in Section 2.3.
-
-2.1 Services Not Provided
-
-   It is part of the design philosophy of the DNS that the data in it is
-   public and that the DNS gives the same answers to all inquirers.
-   Following this philosophy, no attempt has been made to include any
-   sort of access control lists or other means to differentiate
-   inquirers.
-
-   No effort has been made to provide for any confidentiality for
-   queries or responses.  (This service may be available via IPSEC [RFC
-   2401], TLS, or other security protocols.)
-
-   Protection is not provided against denial of service.
-
-2.2 Key Distribution
-
-   A resource record format is defined to associate keys with DNS names.
-   This permits the DNS to be used as a public key distribution
-   mechanism in support of DNS security itself and other protocols.
-
-   The syntax of a KEY resource record (RR) is described in Section 3.
-   It includes an algorithm identifier, the actual public key
-   parameter(s), and a variety of flags including those indicating the
-   type of entity the key is associated with and/or asserting that there
-   is no key associated with that entity.
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Under conditions described in Section 3.5, security aware DNS servers
-   will automatically attempt to return KEY resources as additional
-   information, along with those resource records actually requested, to
-   minimize the number of queries needed.
-
-2.3 Data Origin Authentication and Integrity
-
-   Authentication is provided by associating with resource record sets
-   (RRsets [RFC 2181]) in the DNS cryptographically generated digital
-   signatures. Commonly, there will be a single private key that
-   authenticates an entire zone but there might be multiple keys for
-   different algorithms, signers, etc. If a security aware resolver
-   reliably learns a public key of the zone, it can authenticate, for
-   signed data read from that zone, that it is properly authorized.  The
-   most secure implementation is for the zone private key(s) to be kept
-   off-line and used to re-sign all of the records in the zone
-   periodically.  However, there are cases, for example dynamic update
-   [RFCs 2136, 2137], where DNS private keys need to be on-line [RFC
-   2541].
-
-   The data origin authentication key(s) are associated with the zone
-   and not with the servers that store copies of the data.  That means
-   compromise of a secondary server or, if the key(s) are kept off line,
-   even the primary server for a zone, will not necessarily affect the
-   degree of assurance that a resolver has that it can determine whether
-   data is genuine.
-
-   A resolver could learn a public key of a zone either by reading it
-   from the DNS or by having it staticly configured.  To reliably learn
-   a public key by reading it from the DNS, the key itself must be
-   signed with a key the resolver trusts. The resolver must be
-   configured with at least a public key which authenticates one zone as
-   a starting point. From there, it can securely read public keys of
-   other zones, if the intervening zones in the DNS tree are secure and
-   their signed keys accessible.
-
-   Adding data origin authentication and integrity requires no change to
-   the "on-the-wire" DNS protocol beyond the addition of the signature
-   resource type and the key resource type needed for key distribution.
-   (Data non-existence authentication also requires the NXT RR as
-   described in 2.3.2.)  This service can be supported by existing
-   resolver and caching server implementations so long as they can
-   support the additional resource types (see Section 9). The one
-   exception is that CNAME referrals in a secure zone can not be
-   authenticated if they are from non-security aware servers (see
-   Section 2.3.5).
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   If signatures are separately retrieved and verified when retrieving
-   the information they authenticate, there will be more trips to the
-   server and performance will suffer.  Security aware servers mitigate
-   that degradation by attempting to send the signature(s) needed (see
-   Section 4.2).
-
-2.3.1 The SIG Resource Record
-
-   The syntax of a SIG resource record (signature) is described in
-   Section 4.  It cryptographicly binds the RRset being signed to the
-   signer and a validity interval.
-
-   Every name in a secured zone will have associated with it at least
-   one SIG resource record for each resource type under that name except
-   for glue address RRs and delegation point NS RRs.  A security aware
-   server will attempt to return, with RRs retrieved, the corresponding
-   SIGs.  If a server is not security aware, the resolver must retrieve
-   all the SIG records for a name and select the one or ones that sign
-   the resource record set(s) that resolver is interested in.
-
-2.3.2 Authenticating Name and Type Non-existence
-
-   The above security mechanism only provides a way to sign existing
-   RRsets in a zone.  "Data origin" authentication is not obviously
-   provided for the non-existence of a domain name in a zone or the
-   non-existence of a type for an existing name.  This gap is filled by
-   the NXT RR which authenticatably asserts a range of non-existent
-   names in a zone and the non-existence of types for the existing name
-   just before that range.
-
-   Section 5 below covers the NXT RR.
-
-2.3.3 Special Considerations With Time-to-Live
-
-   A digital signature will fail to verify if any change has occurred to
-   the data between the time it was originally signed and the time the
-   signature is verified.  This conflicts with our desire to have the
-   time-to-live (TTL) field of resource records tick down while they are
-   cached.
-
-   This could be avoided by leaving the time-to-live out of the digital
-   signature, but that would allow unscrupulous servers to set
-   arbitrarily long TTL values undetected.  Instead, we include the
-   "original" TTL in the signature and communicate that data along with
-   the current TTL. Unscrupulous servers under this scheme can
-   manipulate the TTL but a security aware resolver will bound the TTL
-   value it uses at the original signed value.  Separately, signatures
-   include a signature inception time and a signature expiration time. A
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   resolver that knows the absolute time can determine securely whether
-   a signature is in effect.  It is not possible to rely solely on the
-   signature expiration as a substitute for the TTL, however, since the
-   TTL is primarily a database consistency mechanism and non-security
-   aware servers that depend on TTL must still be supported.
-
-2.3.4 Special Considerations at Delegation Points
-
-   DNS security would like to view each zone as a unit of data
-   completely under the control of the zone owner with each entry
-   (RRset) signed by a special private key held by the zone manager.
-   But the DNS protocol views the leaf nodes in a zone, which are also
-   the apex nodes of a subzone (i.e., delegation points), as "really"
-   belonging to the subzone.  These nodes occur in two master files and
-   might have RRs signed by both the upper and lower zone's keys. A
-   retrieval could get a mixture of these RRs and SIGs, especially since
-   one server could be serving both the zone above and below a
-   delegation point. [RFC 2181]
-
-   There MUST be a zone KEY RR, signed by its superzone, for every
-   subzone if the superzone is secure. This will normally appear in the
-   subzone and may also be included in the superzone.  But, in the case
-   of an unsecured subzone which can not or will not be modified to add
-   any security RRs, a KEY declaring the subzone to be unsecured MUST
-   appear with the superzone signature in the superzone, if the
-   superzone is secure. For all but one other RR type the data from the
-   subzone is more authoritative so only the subzone KEY RR should be
-   signed in the superzone if it appears there. The NS and any glue
-   address RRs SHOULD only be signed in the subzone. The SOA and any
-   other RRs that have the zone name as owner should appear only in the
-   subzone and thus are signed only there. The NXT RR type is the
-   exceptional case that will always appear differently and
-   authoritatively in both the superzone and subzone, if both are
-   secure, as described in Section 5.
-
-2.3.5 Special Considerations with CNAME
-
-   There is a problem when security related RRs with the same owner name
-   as a CNAME RR are retrieved from a non-security-aware server. In
-   particular, an initial retrieval for the CNAME or any other type may
-   not retrieve any associated SIG, KEY, or NXT RR. For retrieved types
-   other than CNAME, it will retrieve that type at the target name of
-   the CNAME (or chain of CNAMEs) and will also return the CNAME.  In
-   particular, a specific retrieval for type SIG will not get the SIG,
-   if any, at the original CNAME domain name but rather a SIG at the
-   target name.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 8]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Security aware servers must be used to securely CNAME in DNS.
-   Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along
-   with CNAME RRs, (2) suppress CNAME processing on retrieval of these
-   types as well as on retrieval of the type CNAME, and (3)
-   automatically return SIG RRs authenticating the CNAME or CNAMEs
-   encountered in resolving a query.  This is a change from the previous
-   DNS standard [RFCs 1034/1035] which prohibited any other RR type at a
-   node where a CNAME RR was present.
-
-2.3.6 Signers Other Than The Zone
-
-   There are cases where the signer in a SIG resource record is other
-   than one of the private key(s) used to authenticate a zone.
-
-   One is for support of dynamic update [RFC 2136] (or future requests
-   which require secure authentication) where an entity is permitted to
-   authenticate/update its records [RFC 2137] and the zone is operating
-   in a mode where the zone key is not on line. The public key of the
-   entity must be present in the DNS and be signed by a zone level key
-   but the other RR(s) may be signed with the entity's key.
-
-   A second case is support of transaction and request authentication as
-   described in Section 2.4.
-
-   In additions, signatures can be included on resource records within
-   the DNS for use by applications other than DNS. DNS related
-   signatures authenticate that data originated with the authority of a
-   zone owner or that a request or transaction originated with the
-   relevant entity. Other signatures can provide other types of
-   assurances.
-
-2.4 DNS Transaction and Request Authentication
-
-   The data origin authentication service described above protects
-   retrieved resource records and the non-existence of resource records
-   but provides no protection for DNS requests or for message headers.
-
-   If header bits are falsely set by a bad server, there is little that
-   can be done.  However, it is possible to add transaction
-   authentication.  Such authentication means that a resolver can be
-   sure it is at least getting messages from the server it thinks it
-   queried and that the response is from the query it sent (i.e., that
-   these messages have not been diddled in transit).  This is
-   accomplished by optionally adding a special SIG resource record at
-   the end of the reply which digitally signs the concatenation of the
-   server's response and the resolver's query.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 9]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Requests can also be authenticated by including a special SIG RR at
-   the end of the request.  Authenticating requests serves no function
-   in older DNS servers and requests with a non-empty additional
-   information section produce error returns or may even be ignored by
-   many of them. However, this syntax for signing requests is defined as
-   a way of authenticating secure dynamic update requests [RFC 2137] or
-   future requests requiring authentication.
-
-   The private keys used in transaction security belong to the entity
-   composing the reply, not to the zone involved.  Request
-   authentication may also involve the private key of the host or other
-   entity composing the request or other private keys depending on the
-   request authority it is sought to establish. The corresponding public
-   key(s) are normally stored in and retrieved from the DNS for
-   verification.
-
-   Because requests and replies are highly variable, message
-   authentication SIGs can not be pre-calculated.  Thus it will be
-   necessary to keep the private key on-line, for example in software or
-   in a directly connected piece of hardware.
-
-3. The KEY Resource Record
-
-   The KEY resource record (RR) is used to store a public key that is
-   associated with a Domain Name System (DNS) name.  This can be the
-   public key of a zone, a user, or a host or other end entity. Security
-   aware DNS implementations MUST be designed to handle at least two
-   simultaneously valid keys of the same type associated with the same
-   name.
-
-   The type number for the KEY RR is 25.
-
-   A KEY RR is, like any other RR, authenticated by a SIG RR.  KEY RRs
-   must be signed by a zone level key.
-
-3.1 KEY RDATA format
-
-   The RDATA for a KEY RR consists of flags, a protocol octet, the
-   algorithm number octet, and the public key itself.  The format is as
-   follows:
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 10]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |             flags             |    protocol   |   algorithm   |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               /
-   /                          public key                           /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-   The KEY RR is not intended for storage of certificates and a separate
-   certificate RR has been developed for that purpose, defined in [RFC
-   2538].
-
-   The meaning of the KEY RR owner name, flags, and protocol octet are
-   described in Sections 3.1.1 through 3.1.5 below.  The flags and
-   algorithm must be examined before any data following the algorithm
-   octet as they control the existence and format of any following data.
-   The algorithm and public key fields are described in Section 3.2.
-   The format of the public key is algorithm dependent.
-
-   KEY RRs do not specify their validity period but their authenticating
-   SIG RR(s) do as described in Section 4 below.
-
-3.1.1 Object Types, DNS Names, and Keys
-
-   The public key in a KEY RR is for the object named in the owner name.
-
-   A DNS name may refer to three different categories of things.  For
-   example, foo.host.example could be (1) a zone, (2) a host or other
-   end entity , or (3) the mapping into a DNS name of the user or
-   account foo@host.example.  Thus, there are flag bits, as described
-   below, in the KEY RR to indicate with which of these roles the owner
-   name and public key are associated.  Note that an appropriate zone
-   KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs
-   occur only at delegation points.
-
-3.1.2 The KEY RR Flag Field
-
-   In the "flags" field:
-
-     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
-   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   |  A/C  | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z |      SIG      |
-   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-   Bit 0 and 1 are the key "type" bits whose values have the following
-   meanings:
-
-
-
-Eastlake                    Standards Track                    [Page 11]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-           10: Use of the key is prohibited for authentication.
-           01: Use of the key is prohibited for confidentiality.
-           00: Use of the key for authentication and/or confidentiality
-               is permitted. Note that DNS security makes use of keys
-               for authentication only. Confidentiality use flagging is
-               provided for use of keys in other protocols.
-               Implementations not intended to support key distribution
-               for confidentiality MAY require that the confidentiality
-               use prohibited bit be on for keys they serve.
-           11: If both bits are one, the "no key" value, there is no key
-               information and the RR stops after the algorithm octet.
-               By the use of this "no key" value, a signed KEY RR can
-               authenticatably assert that, for example, a zone is not
-               secured.  See section 3.4 below.
-
-   Bits 2 is reserved and must be zero.
-
-   Bits 3 is reserved as a flag extension bit.  If it is a one, a second
-          16 bit flag field is added after the algorithm octet and
-          before the key data.  This bit MUST NOT be set unless one or
-          more such additional bits have been defined and are non-zero.
-
-   Bits 4-5 are reserved and must be zero.
-
-   Bits 6 and 7 form a field that encodes the name type. Field values
-   have the following meanings:
-
-           00: indicates that this is a key associated with a "user" or
-               "account" at an end entity, usually a host.  The coding
-               of the owner name is that used for the responsible
-               individual mailbox in the SOA and RP RRs: The owner name
-               is the user name as the name of a node under the entity
-               name.  For example, "j_random_user" on
-               host.subdomain.example could have a public key associated
-               through a KEY RR with name
-               j_random_user.host.subdomain.example.  It could be used
-               in a security protocol where authentication of a user was
-               desired.  This key might be useful in IP or other
-               security for a user level service such a telnet, ftp,
-               rlogin, etc.
-           01: indicates that this is a zone key for the zone whose name
-               is the KEY RR owner name.  This is the public key used
-               for the primary DNS security feature of data origin
-               authentication.  Zone KEY RRs occur only at delegation
-               points.
-           10: indicates that this is a key associated with the non-zone
-               "entity" whose name is the RR owner name.  This will
-               commonly be a host but could, in some parts of the DNS
-
-
-
-Eastlake                    Standards Track                    [Page 12]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-               tree, be some other type of entity such as a telephone
-               number [RFC 1530] or numeric IP address.  This is the
-               public key used in connection with DNS request and
-               transaction authentication services.  It could also be
-               used in an IP-security protocol where authentication at
-               the host, rather than user, level was desired, such as
-               routing, NTP, etc.
-           11: reserved.
-
-   Bits 8-11 are reserved and must be zero.
-
-   Bits 12-15 are the "signatory" field.  If non-zero, they indicate
-              that the key can validly sign things as specified in DNS
-              dynamic update [RFC 2137].  Note that zone keys (see bits
-              6 and 7 above) always have authority to sign any RRs in
-              the zone regardless of the value of the signatory field.
-
-3.1.3 The Protocol Octet
-
-   It is anticipated that keys stored in DNS will be used in conjunction
-   with a variety of Internet protocols.  It is intended that the
-   protocol octet and possibly some of the currently unused (must be
-   zero) bits in the KEY RR flags as specified in the future will be
-   used to indicate a key's validity for different protocols.
-
-   The following values of the Protocol Octet are reserved as indicated:
-
-        VALUE   Protocol
-
-          0      -reserved
-          1     TLS
-          2     email
-          3     dnssec
-          4     IPSEC
-         5-254   - available for assignment by IANA
-        255     All
-
-   In more detail:
-        1 is reserved for use in connection with TLS.
-        2 is reserved for use in connection with email.
-        3 is used for DNS security.  The protocol field SHOULD be set to
-          this value for zone keys and other keys used in DNS security.
-          Implementations that can determine that a key is a DNS
-          security key by the fact that flags label it a zone key or the
-          signatory flag field is non-zero are NOT REQUIRED to check the
-          protocol field.
-        4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol
-          and indicates that this key is valid for use in conjunction
-
-
-
-Eastlake                    Standards Track                    [Page 13]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-          with that security standard.  This key could be used in
-          connection with secured communication on behalf of an end
-          entity or user whose name is the owner name of the KEY RR if
-          the entity or user flag bits are set.  The presence of a KEY
-          resource with this protocol value is an assertion that the
-          host speaks Oakley/IPSEC.
-        255 indicates that the key can be used in connection with any
-          protocol for which KEY RR protocol octet values have been
-          defined.  The use of this value is discouraged and the use of
-          different keys for different protocols is encouraged.
-
-3.2 The KEY Algorithm Number Specification
-
-   This octet is the key algorithm parallel to the same field for the
-   SIG resource as described in Section 4.1.  The following values are
-   assigned:
-
-   VALUE   Algorithm
-
-     0      - reserved, see Section 11
-     1     RSA/MD5 [RFC 2537] - recommended
-     2     Diffie-Hellman [RFC 2539] - optional, key only
-     3     DSA [RFC 2536] - MANDATORY
-     4     reserved for elliptic curve crypto
-   5-251    - available, see Section 11
-   252     reserved for indirect keys
-   253     private - domain name (see below)
-   254     private - OID (see below)
-   255      - reserved, see Section 11
-
-   Algorithm specific formats and procedures are given in separate
-   documents.  The mandatory to implement for interoperability algorithm
-   is number 3, DSA.  It is recommended that the RSA/MD5 algorithm,
-   number 1, also be implemented.  Algorithm 2 is used to indicate
-   Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve.
-
-   Algorithm number 252 indicates an indirect key format where the
-   actual key material is elsewhere.  This format is to be defined in a
-   separate document.
-
-   Algorithm numbers 253 and 254 are reserved for private use and will
-   never be assigned a specific algorithm.  For number 253, the public
-   key area and the signature begin with a wire encoded domain name.
-   Only local domain name compression is permitted.  The domain name
-   indicates the private algorithm to use and the remainder of the
-   public key area is whatever is required by that algorithm.  For
-   number 254, the public key area for the KEY RR and the signature
-   begin with an unsigned length byte followed by a BER encoded Object
-
-
-
-Eastlake                    Standards Track                    [Page 14]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Identifier (ISO OID) of that length.  The OID indicates the private
-   algorithm in use and the remainder of the area is whatever is
-   required by that algorithm.  Entities should only use domain names
-   and OIDs they control to designate their private algorithms.
-
-   Values 0 and 255 are reserved but the value 0 is used in the
-   algorithm field when that field is not used.  An example is in a KEY
-   RR with the top two flag bits on, the "no-key" value, where no key is
-   present.
-
-3.3 Interaction of Flags, Algorithm, and Protocol Bytes
-
-   Various combinations of the no-key type flags, algorithm byte,
-   protocol byte, and any future assigned protocol indicating flags are
-   possible.  The meaning of these combinations is indicated below:
-
-   NK = no key type (flags bits 0 and 1 on)
-   AL = algorithm byte
-   PR = protocols indicated by protocol byte or future assigned flags
-
-   x represents any valid non-zero value(s).
-
-    AL  PR   NK  Meaning
-     0   0   0   Illegal, claims key but has bad algorithm field.
-     0   0   1   Specifies total lack of security for owner zone.
-     0   x   0   Illegal, claims key but has bad algorithm field.
-     0   x   1   Specified protocols unsecured, others may be secure.
-     x   0   0   Gives key but no protocols to use it.
-     x   0   1   Denies key for specific algorithm.
-     x   x   0   Specifies key for protocols.
-     x   x   1   Algorithm not understood for protocol.
-
-3.4 Determination of Zone Secure/Unsecured Status
-
-   A zone KEY RR with the "no-key" type field value (both key type flag
-   bits 0 and 1 on) indicates that the zone named is unsecured while a
-   zone KEY RR with a key present indicates that the zone named is
-   secure.  The secured versus unsecured status of a zone may vary with
-   different cryptographic algorithms.  Even for the same algorithm,
-   conflicting zone KEY RRs may be present.
-
-   Zone KEY RRs, like all RRs, are only trusted if they are
-   authenticated by a SIG RR whose signer field is a signer for which
-   the resolver has a public key they trust and where resolver policy
-   permits that signer to sign for the KEY owner name.  Untrusted zone
-   KEY RRs MUST be ignored in determining the security status of the
-   zone.  However, there can be multiple sets of trusted zone KEY RRs
-   for a zone with different algorithms, signers, etc.
-
-
-
-Eastlake                    Standards Track                    [Page 15]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   For any particular algorithm, zones can be (1) secure, indicating
-   that any retrieved RR must be authenticated by a SIG RR or it will be
-   discarded as bogus, (2) unsecured, indicating that SIG RRs are not
-   expected or required for RRs retrieved from the zone, or (3)
-   experimentally secure, which indicates that SIG RRs might or might
-   not be present but must be checked if found.  The status of a zone is
-   determined as follows:
-
-   1. If, for a zone and algorithm, every trusted zone KEY RR for the
-      zone says there is no key for that zone, it is unsecured for that
-      algorithm.
-
-   2. If, there is at least one trusted no-key zone KEY RR and one
-      trusted key specifying zone KEY RR, then that zone is only
-      experimentally secure for the algorithm.  Both authenticated and
-      non-authenticated RRs for it should be accepted by the resolver.
-
-   3. If every trusted zone KEY RR that the zone and algorithm has is
-      key specifying, then it is secure for that algorithm and only
-      authenticated RRs from it will be accepted.
-
-   Examples:
-
-   (1)  A resolver initially trusts only signatures by the superzone of
-   zone Z within the DNS hierarchy.  Thus it will look only at the KEY
-   RRs that are signed by the superzone.  If it finds only no-key KEY
-   RRs, it will assume the zone is not secure.  If it finds only key
-   specifying KEY RRs, it will assume the zone is secure and reject any
-   unsigned responses.  If it finds both, it will assume the zone is
-   experimentally secure
-
-   (2)  A resolver trusts the superzone of zone Z (to which it got
-   securely from its local zone) and a third party, cert-auth.example.
-   When considering data from zone Z, it may be signed by the superzone
-   of Z, by cert-auth.example, by both, or by neither.  The following
-   table indicates whether zone Z will be considered secure,
-   experimentally secure, or unsecured, depending on the signed zone KEY
-   RRs for Z;
-
-                      c e r t - a u t h . e x a m p l e
-
-        KEY RRs|   None    |  NoKeys   |  Mixed   |   Keys   |
-     S       --+-----------+-----------+----------+----------+
-     u  None   | illegal   | unsecured | experim. | secure   |
-     p       --+-----------+-----------+----------+----------+
-     e  NoKeys | unsecured | unsecured | experim. | secure   |
-     r       --+-----------+-----------+----------+----------+
-     Z  Mixed  | experim.  | experim.  | experim. | secure   |
-
-
-
-Eastlake                    Standards Track                    [Page 16]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-     o       --+-----------+-----------+----------+----------+
-     n  Keys   | secure    | secure    | secure   | secure   |
-     e         +-----------+-----------+----------+----------+
-
-3.5 KEY RRs in the Construction of Responses
-
-   An explicit request for KEY RRs does not cause any special additional
-   information processing except, of course, for the corresponding SIG
-   RR from a security aware server (see Section 4.2).
-
-   Security aware DNS servers include KEY RRs as additional information
-   in responses, where a KEY is available, in the following cases:
-
-   (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same
-   name (perhaps just a zone key) SHOULD be included as additional
-   information if space is available. If not all additional information
-   will fit, type A and AAAA glue RRs have higher priority than KEY
-   RR(s).
-
-   (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same
-   name (usually just a host RR and NOT the zone key (which usually
-   would have a different name)) SHOULD be included if space is
-   available.  On inclusion of A or AAAA RRs as additional information,
-   the KEY RRset with the same name should also be included but with
-   lower priority than the A or AAAA RRs.
-
-4. The SIG Resource Record
-
-   The SIG or "signature" resource record (RR) is the fundamental way
-   that data is authenticated in the secure Domain Name System (DNS). As
-   such it is the heart of the security provided.
-
-   The SIG RR unforgably authenticates an RRset [RFC 2181] of a
-   particular type, class, and name and binds it to a time interval and
-   the signer's domain name.  This is done using cryptographic
-   techniques and the signer's private key.  The signer is frequently
-   the owner of the zone from which the RR originated.
-
-   The type number for the SIG RR type is 24.
-
-4.1 SIG RDATA Format
-
-   The RDATA portion of a SIG RR is as shown below.  The integrity of
-   the RDATA information is protected by the signature field.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 17]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |        type covered           |  algorithm    |     labels    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                         original TTL                          |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                      signature expiration                     |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                      signature inception                      |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |            key  tag           |                               |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         signer's name         +
-      |                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
-      /                                                               /
-      /                            signature                          /
-      /                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-4.1.1 Type Covered Field
-
-   The "type covered" is the type of the other RRs covered by this SIG.
-
-4.1.2 Algorithm Number Field
-
-   This octet is as described in section 3.2.
-
-4.1.3 Labels Field
-
-   The "labels" octet is an unsigned count of how many labels there are
-   in the original SIG RR owner name not counting the null label for
-   root and not counting any initial "*" for a wildcard.  If a secured
-   retrieval is the result of wild card substitution, it is necessary
-   for the resolver to use the original form of the name in verifying
-   the digital signature.  This field makes it easy to determine the
-   original form.
-
-   If, on retrieval, the RR appears to have a longer name than indicated
-   by "labels", the resolver can tell it is the result of wildcard
-   substitution.  If the RR owner name appears to be shorter than the
-   labels count, the SIG RR must be considered corrupt and ignored.  The
-   maximum number of labels allowed in the current DNS is 127 but the
-   entire octet is reserved and would be required should DNS names ever
-   be expanded to 255 labels.  The following table gives some examples.
-   The value of "labels" is at the top, the retrieved owner name on the
-   left, and the table entry is the name to use in signature
-   verification except that "bad" means the RR is corrupt.
-
-
-
-Eastlake                    Standards Track                    [Page 18]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   labels= |  0  |   1  |    2   |      3   |      4   |
-   --------+-----+------+--------+----------+----------+
-          .|   . | bad  |  bad   |    bad   |    bad   |
-         d.|  *. |   d. |  bad   |    bad   |    bad   |
-       c.d.|  *. | *.d. |   c.d. |    bad   |    bad   |
-     b.c.d.|  *. | *.d. | *.c.d. |   b.c.d. |    bad   |
-   a.b.c.d.|  *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |
-
-4.1.4 Original TTL Field
-
-   The "original TTL" field is included in the RDATA portion to avoid
-   (1) authentication problems that caching servers would otherwise
-   cause by decrementing the real TTL field and (2) security problems
-   that unscrupulous servers could otherwise cause by manipulating the
-   real TTL field.  This original TTL is protected by the signature
-   while the current TTL field is not.
-
-   NOTE:  The "original TTL" must be restored into the covered RRs when
-   the signature is verified (see Section 8).  This generaly implies
-   that all RRs for a particular type, name, and class, that is, all the
-   RRs in any particular RRset, must have the same TTL to start with.
-
-4.1.5 Signature Expiration and Inception Fields
-
-   The SIG is valid from the "signature inception" time until the
-   "signature expiration" time.  Both are unsigned numbers of seconds
-   since the start of 1 January 1970, GMT, ignoring leap seconds.  (See
-   also Section 4.4.)  Ring arithmetic is used as for DNS SOA serial
-   numbers [RFC 1982] which means that these times can never be more
-   than about 68 years in the past or the future.  This means that these
-   times are ambiguous modulo ~136.09 years.  However there is no
-   security flaw because keys are required to be changed to new random
-   keys by [RFC 2541] at least every five years.  This means that the
-   probability that the same key is in use N*136.09 years later should
-   be the same as the probability that a random guess will work.
-
-   A SIG RR may have an expiration time numerically less than the
-   inception time if the expiration time is near the 32 bit wrap around
-   point and/or the signature is long lived.
-
-   (To prevent misordering of network requests to update a zone
-   dynamically, monotonically increasing "signature inception" times may
-   be necessary.)
-
-   A secure zone must be considered changed for SOA serial number
-   purposes not only when its data is updated but also when new SIG RRs
-   are inserted (ie, the zone or any part of it is re-signed).
-
-
-
-
-Eastlake                    Standards Track                    [Page 19]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-4.1.6 Key Tag Field
-
-   The "key Tag" is a two octet quantity that is used to efficiently
-   select between multiple keys which may be applicable and thus check
-   that a public key about to be used for the computationally expensive
-   effort to check the signature is possibly valid.  For algorithm 1
-   (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two
-   octets of the public key modulus needed to decode the signature
-   field.  That is to say, the most significant 16 of the least
-   significant 24 bits of the modulus in network (big endian) order. For
-   all other algorithms, including private algorithms, it is calculated
-   as a simple checksum of the KEY RR as described in Appendix C.
-
-4.1.7 Signer's Name Field
-
-   The "signer's name" field is the domain name of the signer generating
-   the SIG RR.  This is the owner name of the public KEY RR that can be
-   used to verify the signature.  It is frequently the zone which
-   contained the RRset being authenticated.  Which signers should be
-   authorized to sign what is a significant resolver policy question as
-   discussed in Section 6. The signer's name may be compressed with
-   standard DNS name compression when being transmitted over the
-   network.
-
-4.1.8 Signature Field
-
-   The actual signature portion of the SIG RR binds the other RDATA
-   fields to the RRset of the "type covered" RRs with that owner name
-   and class.  This covered RRset is thereby authenticated.  To
-   accomplish this, a data sequence is constructed as follows:
-
-         data = RDATA | RR(s)...
-
-   where "|" is concatenation,
-
-   RDATA is the wire format of all the RDATA fields in the SIG RR itself
-   (including the canonical form of the signer's name) before but not
-   including the signature, and
-
-   RR(s) is the RRset of the RR(s) of the type covered with the same
-   owner name and class as the SIG RR in canonical form and order as
-   defined in Section 8.
-
-   How this data sequence is processed into the signature is algorithm
-   dependent.  These algorithm dependent formats and procedures are
-   described in separate documents (Section 3.2).
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 20]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   SIGs SHOULD NOT be included in a zone for any "meta-type" such as
-   ANY, AXFR, etc. (but see section 5.6.2 with regard to IXFR).
-
-4.1.8.1 Calculating Transaction and Request SIGs
-
-   A response message from a security aware server may optionally
-   contain a special SIG at the end of the additional information
-   section to authenticate the transaction.
-
-   This SIG has a "type covered" field of zero, which is not a valid RR
-   type.  It is calculated by using a "data" (see Section 4.1.8) of the
-   entire preceding DNS reply message, including DNS header but not the
-   IP header and before the reply RR counts have been adjusted for the
-   inclusion of any transaction SIG, concatenated with the entire DNS
-   query message that produced this response, including the query's DNS
-   header and any request SIGs but not its IP header.  That is
-
-      data = full response (less transaction SIG) | full query
-
-   Verification of the transaction SIG (which is signed by the server
-   host key, not the zone key) by the requesting resolver shows that the
-   query and response were not tampered with in transit, that the
-   response corresponds to the intended query, and that the response
-   comes from the queried server.
-
-   A DNS request may be optionally signed by including one or more SIGs
-   at the end of the query. Such SIGs are identified by having a "type
-   covered" field of zero. They sign the preceding DNS request message
-   including DNS header but not including the IP header or any request
-   SIGs at the end and before the request RR counts have been adjusted
-   for the inclusions of any request SIG(s).
-
-   WARNING: Request SIGs are unnecessary for any currently defined
-   request other than update [RFC 2136, 2137] and will cause some old
-   DNS servers to give an error return or ignore a query.  However, such
-   SIGs may in the future be needed for other requests.
-
-   Except where needed to authenticate an update or similar privileged
-   request, servers are not required to check request SIGs.
-
-4.2 SIG RRs in the Construction of Responses
-
-   Security aware DNS servers SHOULD, for every authenticated RRset the
-   query will return, attempt to send the available SIG RRs which
-   authenticate the requested RRset.  The following rules apply to the
-   inclusion of SIG RRs in responses:
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 21]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-     1. when an RRset is placed in a response, its SIG RR has a higher
-        priority for inclusion than additional RRs that may need to be
-        included.  If space does not permit its inclusion, the response
-        MUST be considered truncated except as provided in 2 below.
-
-     2. When a SIG RR is present in the zone for an additional
-        information section RR, the response MUST NOT be considered
-        truncated merely because space does not permit the inclusion of
-        the SIG RR with the additional information.
-
-     3. SIGs to authenticate glue records and NS RRs for subzones at a
-        delegation point are unnecessary and MUST NOT be sent.
-
-     4. If a SIG covers any RR that would be in the answer section of
-        the response, its automatic inclusion MUST be in the answer
-        section.  If it covers an RR that would appear in the authority
-        section, its automatic inclusion MUST be in the authority
-        section.  If it covers an RR that would appear in the additional
-        information section it MUST appear in the additional information
-        section.  This is a change in the existing standard [RFCs 1034,
-        1035] which contemplates only NS and SOA RRs in the authority
-        section.
-
-     5. Optionally, DNS transactions may be authenticated by a SIG RR at
-        the end of the response in the additional information section
-        (Section 4.1.8.1).  Such SIG RRs are signed by the DNS server
-        originating the response.  Although the signer field MUST be a
-        name of the originating server host, the owner name, class, TTL,
-        and original TTL, are meaningless.  The class and TTL fields
-        SHOULD be zero.  To conserve space, the owner name SHOULD be
-        root (a single zero octet).  If transaction authentication is
-        desired, that SIG RR must be considered the highest priority for
-        inclusion.
-
-4.3 Processing Responses and SIG RRs
-
-   The following rules apply to the processing of SIG RRs included in a
-   response:
-
-     1. A security aware resolver that receives a response from a
-        security aware server via a secure communication with the AD bit
-        (see Section 6.1) set, MAY choose to accept the RRs as received
-        without verifying the zone SIG RRs.
-
-     2. In other cases, a security aware resolver SHOULD verify the SIG
-        RRs for the RRs of interest.  This may involve initiating
-        additional queries for SIG or KEY RRs, especially in the case of
-
-
-
-
-Eastlake                    Standards Track                    [Page 22]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-        getting a response from a server that does not implement
-        security.  (As explained in 2.3.5 above, it will not be possible
-        to secure CNAMEs being served up by non-secure resolvers.)
-
-        NOTE: Implementers might expect the above SHOULD to be a MUST.
-        However, local policy or the calling application may not require
-        the security services.
-
-     3. If SIG RRs are received in response to a user query explicitly
-        specifying the SIG type, no special processing is required.
-
-   If the message does not pass integrity checks or the SIG does not
-   check against the signed RRs, the SIG RR is invalid and should be
-   ignored.  If all of the SIG RR(s) purporting to authenticate an RRset
-   are invalid, then the RRset is not authenticated.
-
-   If the SIG RR is the last RR in a response in the additional
-   information section and has a type covered of zero, it is a
-   transaction signature of the response and the query that produced the
-   response.  It MAY be optionally checked and the message rejected if
-   the checks fail.  But even if the checks succeed, such a transaction
-   authentication SIG does NOT directly authenticate any RRs in the
-   message.  Only a proper SIG RR signed by the zone or a key tracing
-   its authority to the zone or to static resolver configuration can
-   directly authenticate RRs, depending on resolver policy (see Section
-   6).  If a resolver does not implement transaction and/or request
-   SIGs, it MUST ignore them without error.
-
-   If all checks indicate that the SIG RR is valid then RRs verified by
-   it should be considered authenticated.
-
-4.4 Signature Lifetime, Expiration, TTLs, and Validity
-
-   Security aware servers MUST NOT consider SIG RRs to authenticate
-   anything before their signature inception or after its expiration
-   time (see also Section 6).  Security aware servers MUST NOT consider
-   any RR to be authenticated after all its signatures have expired.
-   When a secure server caches authenticated data, if the TTL would
-   expire at a time further in the future than the authentication
-   expiration time, the server SHOULD trim the TTL in the cache entry
-   not to extent beyond the authentication expiration time.  Within
-   these constraints, servers should continue to follow DNS TTL aging.
-   Thus authoritative servers should continue to follow the zone refresh
-   and expire parameters and a non-authoritative server should count
-   down the TTL and discard RRs when the TTL is zero (even for a SIG
-   that has not yet reached its authentication expiration time).  In
-   addition, when RRs are transmitted in a query response, the TTL
-
-
-
-
-Eastlake                    Standards Track                    [Page 23]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   should be trimmed so that current time plus the TTL does not extend
-   beyond the authentication expiration time.  Thus, in general, the TTL
-   on a transmitted RR would be
-
-      min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))
-
-   When signatures are generated, signature expiration times should be
-   set far enough in the future that it is quite certain that new
-   signatures can be generated before the old ones expire.  However,
-   setting expiration too far into the future could mean a long time to
-   flush any bad data or signatures that may have been generated.
-
-   It is recommended that signature lifetime be a small multiple of the
-   TTL (ie, 4 to 16 times the TTL) but not less than a reasonable
-   maximum re-signing interval and not less than the zone expiry time.
-
-5. Non-existent Names and Types
-
-   The SIG RR mechanism described in Section 4 above provides strong
-   authentication of RRs that exist in a zone.  But it is not clear
-   above how to verifiably deny the existence of a name in a zone or a
-   type for an existent name.
-
-   The nonexistence of a name in a zone is indicated by the NXT ("next")
-   RR for a name interval containing the nonexistent name. An NXT RR or
-   RRs and its or their SIG(s) are returned in the authority section,
-   along with the error, if the server is security aware.  The same is
-   true for a non-existent type under an existing name except that there
-   is no error indication other than an empty answer section
-   accompanying the NXT(s). This is a change in the existing standard
-   [RFCs 1034/1035] which contemplates only NS and SOA RRs in the
-   authority section. NXT RRs will also be returned if an explicit query
-   is made for the NXT type.
-
-   The existence of a complete set of NXT records in a zone means that
-   any query for any name and any type to a security aware server
-   serving the zone will result in an reply containing at least one
-   signed RR unless it is a query for delegation point NS or glue A or
-   AAAA RRs.
-
-5.1 The NXT Resource Record
-
-   The NXT resource record is used to securely indicate that RRs with an
-   owner name in a certain name interval do not exist in a zone and to
-   indicate what RR types are present for an existing name.
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 24]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   The owner name of the NXT RR is an existing name in the zone.  It's
-   RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone
-   create a chain of all of the literal owner names in that zone,
-   including unexpanded wildcards but omitting the owner name of glue
-   address records unless they would otherwise be included. This implies
-   a canonical ordering of all domain names in a zone as described in
-   Section 8. The presence of the NXT RR means that no name between its
-   owner name and the name in its RDATA area exists and that no other
-   types exist under its owner name.
-
-   There is a potential problem with the last NXT in a zone as it wants
-   to have an owner name which is the last existing name in canonical
-   order, which is easy, but it is not obvious what name to put in its
-   RDATA to indicate the entire remainder of the name space.  This is
-   handled by treating the name space as circular and putting the zone
-   name in the RDATA of the last NXT in a zone.
-
-   The NXT RRs for a zone SHOULD be automatically calculated and added
-   to the zone when SIGs are added.  The NXT RR's TTL SHOULD NOT exceed
-   the zone minimum TTL.
-
-   The type number for the NXT RR is 30.
-
-   NXT RRs are only signed by zone level keys.
-
-5.2 NXT RDATA Format
-
-   The RDATA for an NXT RR consists simply of a domain name followed by
-   a bit map, as shown below.
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                  next domain name                             /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                    type bit map                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   The NXT RR type bit map format currently defined is one bit per RR
-   type present for the owner name.  A one bit indicates that at least
-   one RR of that type is present for the owner name.  A zero indicates
-   that no such RR is present.  All bits not specified because they are
-   beyond the end of the bit map are assumed to be zero.  Note that bit
-   30, for NXT, will always be on so the minimum bit map length is
-   actually four octets. Trailing zero octets are prohibited in this
-   format.  The first bit represents RR type zero (an illegal type which
-   can not be present) and so will be zero in this format.  This format
-   is not used if there exists an RR with a type number greater than
-
-
-
-Eastlake                    Standards Track                    [Page 25]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   127.  If the zero bit of the type bit map is a one, it indicates that
-   a different format is being used which will always be the case if a
-   type number greater than 127 is present.
-
-   The domain name may be compressed with standard DNS name compression
-   when being transmitted over the network.  The size of the bit map can
-   be inferred from the RDLENGTH and the length of the next domain name.
-
-5.3 Additional Complexity Due to Wildcards
-
-   Proving that a non-existent name response is correct or that a
-   wildcard expansion response is correct makes things a little more
-   complex.
-
-   In particular, when a non-existent name response is returned, an NXT
-   must be returned showing that the exact name queried did not exist
-   and, in general, one or more additional NXT's need to be returned to
-   also prove that there wasn't a wildcard whose expansion should have
-   been returned. (There is no need to return multiple copies of the
-   same NXT.) These NXTs, if any, are returned in the authority section
-   of the response.
-
-   Furthermore, if a wildcard expansion is returned in a response, in
-   general one or more NXTs needs to also be returned in the authority
-   section to prove that no more specific name (including possibly more
-   specific wildcards in the zone) existed on which the response should
-   have been based.
-
-5.4 Example
-
-   Assume zone foo.nil has entries for
-
-          big.foo.nil,
-          medium.foo.nil.
-          small.foo.nil.
-          tiny.foo.nil.
-
-   Then a query to a security aware server for huge.foo.nil would
-   produce an error reply with an RCODE of NXDOMAIN and the authority
-   section data including something like the following:
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 26]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   foo.nil.    NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil
-   foo.nil.    SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2
-                    19970102030405 ;signature expiration
-                    19961211100908 ;signature inception
-                    2143           ;key identifier
-                    foo.nil.       ;signer
-   AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm
-   fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits)
-                          )
-   big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil
-   big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3
-                    19970102030405 ;signature expiration
-                    19961211100908 ;signature inception
-                    2143           ;key identifier
-                    foo.nil.       ;signer
-    MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU
-    1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits)
-                             )
-   Note that this response implies that big.foo.nil is an existing name
-   in the zone and thus has other RR types associated with it than NXT.
-   However, only the NXT (and its SIG) RR appear in the response to this
-   query for huge.foo.nil, which is a non-existent name.
-
-5.5 Special Considerations at Delegation Points
-
-   A name (other than root) which is the head of a zone also appears as
-   the leaf in a superzone.  If both are secure, there will always be
-   two different NXT RRs with the same name.  They can be easily
-   distinguished by their signers, the next domain name fields, the
-   presence of the SOA type bit, etc.  Security aware servers should
-   return the correct NXT automatically when required to authenticate
-   the non-existence of a name and both NXTs, if available, on explicit
-   query for type NXT.
-
-   Non-security aware servers will never automatically return an NXT and
-   some old implementations may only return the NXT from the subzone on
-   explicit queries.
-
-5.6 Zone Transfers
-
-   The subsections below describe how full and incremental zone
-   transfers are secured.
-
-   SIG RRs secure all authoritative RRs transferred for both full and
-   incremental [RFC 1995] zone transfers.  NXT RRs are an essential
-   element in secure zone transfers and assure that every authoritative
-   name and type will be present; however, if there are multiple SIGs
-   with the same name and type covered, a subset of the SIGs could be
-
-
-
-Eastlake                    Standards Track                    [Page 27]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   sent as long as at least one is present and, in the case of unsigned
-   delegation point NS or glue A or AAAA RRs a subset of these RRs or
-   simply a modified set could be sent as long as at least one of each
-   type is included.
-
-   When an incremental or full zone transfer request is received with
-   the same or newer version number than that of the server's copy of
-   the zone, it is replied to with just the SOA RR of the server's
-   current version and the SIG RRset verifying that SOA RR.
-
-   The complete NXT chains specified in this document enable a resolver
-   to obtain, by successive queries chaining through NXTs, all of the
-   names in a zone even if zone transfers are prohibited.  Different
-   format NXTs may be specified in the future to avoid this.
-
-5.6.1 Full Zone Transfers
-
-   To provide server authentication that a complete transfer has
-   occurred, transaction authentication SHOULD be used on full zone
-   transfers.  This provides strong server based protection for the
-   entire zone in transit.
-
-5.6.2 Incremental Zone Transfers
-
-   Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be
-   verified in the same way as for a full zone transfer and the
-   integrity of the NXT name chain and correctness of the NXT type bits
-   for the zone after the incremental RR deletes and adds can check each
-   disjoint area of the zone updated.  But the completeness of an
-   incremental transfer can not be confirmed because usually neither the
-   deleted RR section nor the added RR section has a compete zone NXT
-   chain.  As a result, a server which securely supports IXFR must
-   handle IXFR SIG RRs for each incremental transfer set that it
-   maintains.
-
-   The IXFR SIG is calculated over the incremental zone update
-   collection of RRs in the order in which it is transmitted: old SOA,
-   then deleted RRs, then new SOA and added RRs.  Within each section,
-   RRs must be ordered as specified in Section 8.  If condensation of
-   adjacent incremental update sets is done by the zone owner, the
-   original IXFR SIG for each set included in the condensation must be
-   discarded and a new on IXFR SIG calculated to cover the resulting
-   condensed set.
-
-   The IXFR SIG really belongs to the zone as a whole, not to the zone
-   name.  Although it SHOULD be correct for the zone name, the labels
-   field of an IXFR SIG is otherwise meaningless.  The IXFR SIG is only
-   sent as part of an incremental zone transfer.  After validation of
-
-
-
-Eastlake                    Standards Track                    [Page 28]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   the IXFR SIG, the transferred RRs MAY be considered valid without
-   verification of the internal SIGs if such trust in the server
-   conforms to local policy.
-
-6. How to Resolve Securely and the AD and CD Bits
-
-   Retrieving or resolving secure data from the Domain Name System (DNS)
-   involves starting with one or more trusted public keys that have been
-   staticly configured at the resolver.  With starting trusted keys, a
-   resolver willing to perform cryptography can progress securely
-   through the secure DNS structure to the zone of interest as described
-   in Section 6.3. Such trusted public keys would normally be configured
-   in a manner similar to that described in Section 6.2.  However, as a
-   practical matter, a security aware resolver would still gain some
-   confidence in the results it returns even if it was not configured
-   with any keys but trusted what it got from a local well known server
-   as if it were staticly configured.
-
-   Data stored at a security aware server needs to be internally
-   categorized as Authenticated, Pending, or Insecure. There is also a
-   fourth transient state of Bad which indicates that all SIG checks
-   have explicitly failed on the data. Such Bad data is not retained at
-   a security aware server. Authenticated means that the data has a
-   valid SIG under a KEY traceable via a chain of zero or more SIG and
-   KEY RRs allowed by the resolvers policies to a KEY staticly
-   configured at the resolver. Pending data has no authenticated SIGs
-   and at least one additional SIG the resolver is still trying to
-   authenticate.  Insecure data is data which it is known can never be
-   either Authenticated or found Bad in the zone where it was found
-   because it is in or has been reached via a unsecured zone or because
-   it is unsigned glue address or delegation point NS data. Behavior in
-   terms of control of and flagging based on such data labels is
-   described in Section 6.1.
-
-   The proper validation of signatures requires a reasonably secure
-   shared opinion of the absolute time between resolvers and servers as
-   described in Section 6.4.
-
-6.1 The AD and CD Header Bits
-
-   Two previously unused bits are allocated out of the DNS
-   query/response format header. The AD (authentic data) bit indicates
-   in a response that all the data included in the answer and authority
-   portion of the response has been authenticated by the server
-   according to the policies of that server. The CD (checking disabled)
-   bit indicates in a query that Pending (non-authenticated) data is
-   acceptable to the resolver sending the query.
-
-
-
-
-Eastlake                    Standards Track                    [Page 29]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   These bits are allocated from the previously must-be-zero Z field as
-   follows:
-
-                                           1  1  1  1  1  1
-             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                      ID                       |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    QDCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    ANCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    NSCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    ARCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   These bits are zero in old servers and resolvers.  Thus the responses
-   of old servers are not flagged as authenticated to security aware
-   resolvers and queries from non-security aware resolvers do not assert
-   the checking disabled bit and thus will be answered by security aware
-   servers only with Authenticated or Insecure data. Security aware
-   resolvers MUST NOT trust the AD bit unless they trust the server they
-   are talking to and either have a secure path to it or use DNS
-   transaction security.
-
-   Any security aware resolver willing to do cryptography SHOULD assert
-   the CD bit on all queries to permit it to impose its own policies and
-   to reduce DNS latency time by allowing security aware servers to
-   answer with Pending data.
-
-   Security aware servers MUST NOT return Bad data.  For non-security
-   aware resolvers or security aware resolvers requesting service by
-   having the CD bit clear, security aware servers MUST return only
-   Authenticated or Insecure data in the answer and authority sections
-   with the AD bit set in the response. Security aware servers SHOULD
-   return Pending data, with the AD bit clear in the response, to
-   security aware resolvers requesting this service by asserting the CD
-   bit in their request.  The AD bit MUST NOT be set on a response
-   unless all of the RRs in the answer and authority sections of the
-   response are either Authenticated or Insecure.  The AD bit does not
-   cover the additional information section.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 30]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-6.2 Staticly Configured Keys
-
-   The public key to authenticate a zone SHOULD be defined in local
-   configuration files before that zone is loaded at the primary server
-   so the zone can be authenticated.
-
-   While it might seem logical for everyone to start with a public key
-   associated with the root zone and staticly configure this in every
-   resolver, this has problems.  The logistics of updating every DNS
-   resolver in the world should this key ever change would be severe.
-   Furthermore, many organizations will explicitly wish their "interior"
-   DNS implementations to completely trust only their own DNS servers.
-   Interior resolvers of such organizations can then go through the
-   organization's zone servers to access data outside the organization's
-   domain and need not be configured with keys above the organization's
-   DNS apex.
-
-   Host resolvers that are not part of a larger organization may be
-   configured with a key for the domain of their local ISP whose
-   recursive secure DNS caching server they use.
-
-6.3 Chaining Through The DNS
-
-   Starting with one or more trusted keys for any zone, it should be
-   possible to retrieve signed keys for that zone's subzones which have
-   a key. A secure sub-zone is indicated by a KEY RR with non-null key
-   information appearing with the NS RRs in the sub-zone and which may
-   also be present in the parent.  These make it possible to descend
-   within the tree of zones.
-
-6.3.1 Chaining Through KEYs
-
-   In general, some RRset that you wish to validate in the secure DNS
-   will be signed by one or more SIG RRs.  Each of these SIG RRs has a
-   signer under whose name is stored the public KEY to use in
-   authenticating the SIG.  Each of those KEYs will, generally, also be
-   signed with a SIG.  And those SIGs will have signer names also
-   referring to KEYs.  And so on. As a result, authentication leads to
-   chains of alternating SIG and KEY RRs with the first SIG signing the
-   original data whose authenticity is to be shown and the final KEY
-   being some trusted key staticly configured at the resolver performing
-   the authentication.
-
-   In testing such a chain, the validity periods of the SIGs encountered
-   must be intersected to determine the validity period of the
-   authentication of the data, a purely algorithmic process. In
-   addition, the validation of each SIG over the data with reference to
-   a KEY must meet the objective cryptographic test implied by the
-
-
-
-Eastlake                    Standards Track                    [Page 31]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   cryptographic algorithm used (although even here the resolver may
-   have policies as to trusted algorithms and key lengths).  Finally,
-   the judgement that a SIG with a particular signer name can
-   authenticate data (possibly a KEY RRset) with a particular owner
-   name, is primarily a policy question.  Ultimately, this is a policy
-   local to the resolver and any clients that depend on that resolver's
-   decisions.  It is, however, recommended, that the policy below be
-   adopted:
-
-        Let A < B mean that A is a shorter domain name than B formed by
-        dropping one or more whole labels from the left end of B, i.e.,
-        A is a direct or indirect superdomain of B.  Let A = B mean that
-        A and B are the same domain name (i.e., are identical after
-        letter case canonicalization).  Let A > B mean that A is a
-        longer domain name than B formed by adding one or more whole
-        labels on the left end of B, i.e., A is a direct or indirect
-        subdomain of B
-
-        Let Static be the owner names of the set of staticly configured
-        trusted keys at a resolver.
-
-        Then Signer is a valid signer name for a SIG authenticating an
-        RRset (possibly a KEY RRset) with owner name Owner at the
-        resolver if any of the following three rules apply:
-
-        (1) Owner > or = Signer (except that if Signer is root, Owner
-        must be root or a top level domain name).  That is, Owner is the
-        same as or a subdomain of Signer.
-
-        (2) ( Owner < Signer ) and ( Signer > or = some Static ).  That
-        is, Owner is a superdomain of Signer and Signer is staticly
-        configured or a subdomain of a staticly configured key.
-
-        (3) Signer = some Static.  That is, the signer is exactly some
-        staticly configured key.
-
-   Rule 1 is the rule for descending the DNS tree and includes a special
-   prohibition on the root zone key due to the restriction that the root
-   zone be only one label deep.  This is the most fundamental rule.
-
-   Rule 2 is the rule for ascending the DNS tree from one or more
-   staticly configured keys.  Rule 2 has no effect if only root zone
-   keys are staticly configured.
-
-   Rule 3 is a rule permitting direct cross certification.  Rule 3 has
-   no effect if only root zone keys are staticly configured.
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 32]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Great care should be taken that the consequences have been fully
-   considered before making any local policy adjustments to these rules
-   (other than dispensing with rules 2 and 3 if only root zone keys are
-   staticly configured).
-
-6.3.2 Conflicting Data
-
-   It is possible that there will be multiple SIG-KEY chains that appear
-   to authenticate conflicting RRset answers to the same query.  A
-   resolver should choose only the most reliable answer to return and
-   discard other data.  This choice of most reliable is a matter of
-   local policy which could take into account differing trust in
-   algorithms, key sizes, staticly configured keys, zones traversed,
-   etc.  The technique given below is recommended for taking into
-   account SIG-KEY chain length.
-
-   A resolver should keep track of the number of successive secure zones
-   traversed from a staticly configured key starting point to any secure
-   zone it can reach.  In general, the lower such a distance number is,
-   the greater the confidence in the data.  Staticly configured data
-   should be given a distance number of zero.  If a query encounters
-   different Authenticated data for the same query with different
-   distance values, that with a larger value should be ignored unless
-   some other local policy covers the case.
-
-   A security conscious resolver should completely refuse to step from a
-   secure zone into a unsecured zone unless the unsecured zone is
-   certified to be non-secure by the presence of an authenticated KEY RR
-   for the unsecured zone with the no-key type value.  Otherwise the
-   resolver is getting bogus or spoofed data.
-
-   If legitimate unsecured zones are encountered in traversing the DNS
-   tree, then no zone can be trusted as secure that can be reached only
-   via information from such non-secure zones. Since the unsecured zone
-   data could have been spoofed, the "secure" zone reached via it could
-   be counterfeit.  The "distance" to data in such zones or zones
-   reached via such zones could be set to 256 or more as this exceeds
-   the largest possible distance through secure zones in the DNS.
-
-6.4 Secure Time
-
-   Coordinated interpretation of the time fields in SIG RRs requires
-   that reasonably consistent time be available to the hosts
-   implementing the DNS security extensions.
-
-   A variety of time synchronization protocols exist including the
-   Network Time Protocol (NTP [RFC 1305, 2030]).  If such protocols are
-   used, they MUST be used securely so that time can not be spoofed.
-
-
-
-Eastlake                    Standards Track                    [Page 33]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Otherwise, for example, a host could get its clock turned back and
-   might then believe old SIG RRs, and the data they authenticate, which
-   were valid but are no longer.
-
-7. ASCII Representation of Security RRs
-
-   This section discusses the format for master file and other ASCII
-   presentation of the three DNS security resource records.
-
-   The algorithm field in KEY and SIG RRs can be represented as either
-   an unsigned integer or symbolicly.  The following initial symbols are
-   defined as indicated:
-
-        Value  Symbol
-
-        001    RSAMD5
-        002    DH
-        003    DSA
-        004    ECC
-        252    INDIRECT
-        253    PRIVATEDNS
-        254    PRIVATEOID
-
-7.1 Presentation of KEY RRs
-
-   KEY RRs may appear as single logical lines in a zone data master file
-   [RFC 1033].
-
-   The flag field is represented as an unsigned integer or a sequence of
-   mnemonics as follows separated by instances of the verticle bar ("|")
-   character:
-
-     BIT  Mnemonic  Explanation
-    0-1           key type
-        NOCONF    =1 confidentiality use prohibited
-        NOAUTH    =2 authentication use prohibited
-        NOKEY     =3 no key present
-    2   FLAG2     - reserved
-    3   EXTEND    flags extension
-    4   FLAG4     - reserved
-    5   FLAG5     - reserved
-    6-7           name type
-        USER      =0 (default, may be omitted)
-        ZONE      =1
-        HOST      =2 (host or other end entity)
-        NTYP3     - reserved
-    8   FLAG8     - reserved
-    9   FLAG9     - reserved
-
-
-
-Eastlake                    Standards Track                    [Page 34]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   10   FLAG10    - reserved
-   11   FLAG11    - reserved
-   12-15          signatory field, values 0 to 15
-            can be represented by SIG0, SIG1, ... SIG15
-
-   No flag mnemonic need be present if the bit or field it represents is
-   zero.
-
-   The protocol octet can be represented as either an unsigned integer
-   or symbolicly.  The following initial symbols are defined:
-
-        000    NONE
-        001    TLS
-        002    EMAIL
-        003    DNSSEC
-        004    IPSEC
-        255    ALL
-
-   Note that if the type flags field has the NOKEY value, nothing
-   appears after the algorithm octet.
-
-   The remaining public key portion is represented in base 64 (see
-   Appendix A) and may be divided up into any number of white space
-   separated substrings, down to single base 64 digits, which are
-   concatenated to obtain the full signature.  These substrings can span
-   lines using the standard parenthesis.
-
-   Note that the public key may have internal sub-fields but these do
-   not appear in the master file representation.  For example, with
-   algorithm 1 there is a public exponent size, then a public exponent,
-   and then a modulus.  With algorithm 254, there will be an OID size,
-   an OID, and algorithm dependent information. But in both cases only a
-   single logical base 64 string will appear in the master file.
-
-7.2 Presentation of SIG RRs
-
-   A data SIG RR may be represented as a single logical line in a zone
-   data file [RFC 1033] but there are some special considerations as
-   described below.  (It does not make sense to include a transaction or
-   request authenticating SIG RR in a file as they are a transient
-   authentication that covers data including an ephemeral transaction
-   number and so must be calculated in real time.)
-
-   There is no particular problem with the signer, covered type, and
-   times.  The time fields appears in the form YYYYMMDDHHMMSS where YYYY
-   is the year, the first MM is the month number (01-12), DD is the day
-   of the month (01-31), HH is the hour in 24 hours notation (00-23),
-   the second MM is the minute (00-59), and SS is the second (00-59).
-
-
-
-Eastlake                    Standards Track                    [Page 35]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   The original TTL field appears as an unsigned integer.
-
-   If the original TTL, which applies to the type signed, is the same as
-   the TTL of the SIG RR itself, it may be omitted.  The date field
-   which follows it is larger than the maximum possible TTL so there is
-   no ambiguity.
-
-   The "labels" field appears as an unsigned integer.
-
-   The key tag appears as an unsigned number.
-
-   However, the signature itself can be very long.  It is the last data
-   field and is represented in base 64 (see Appendix A) and may be
-   divided up into any number of white space separated substrings, down
-   to single base 64 digits, which are concatenated to obtain the full
-   signature.  These substrings can be split between lines using the
-   standard parenthesis.
-
-7.3 Presentation of NXT RRs
-
-   NXT RRs do not appear in original unsigned zone master files since
-   they should be derived from the zone as it is being signed.  If a
-   signed file with NXTs added is printed or NXTs are printed by
-   debugging code, they appear as the next domain name followed by the
-   RR type present bits as an unsigned interger or sequence of RR
-   mnemonics.
-
-8. Canonical Form and Order of Resource Records
-
-   This section specifies, for purposes of domain name system (DNS)
-   security, the canonical form of resource records (RRs), their name
-   order, and their overall order.  A canonical name order is necessary
-   to construct the NXT name chain.  A canonical form and ordering
-   within an RRset is necessary in consistently constructing and
-   verifying SIG RRs.  A canonical ordering of types within a name is
-   required in connection with incremental transfer (Section 5.6.2).
-
-8.1 Canonical RR Form
-
-   For purposes of DNS security, the canonical form for an RR is the
-   wire format of the RR with domain names (1) fully expanded (no name
-   compression via pointers), (2) all domain name letters set to lower
-   case, (3) owner name wild cards in master file form (no substitution
-   made for *), and (4) the original TTL substituted for the current
-   TTL.
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 36]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-8.2 Canonical DNS Name Order
-
-   For purposes of DNS security, the canonical ordering of owner names
-   is to sort individual labels as unsigned left justified octet strings
-   where the absence of a octet sorts before a zero value octet and
-   upper case letters are treated as lower case letters.  Names in a
-   zone are sorted by sorting on the highest level label and then,
-   within those names with the same highest level label by the next
-   lower label, etc. down to leaf node labels.  Within a zone, the zone
-   name itself always exists and all other names are the zone name with
-   some prefix of lower level labels.  Thus the zone name itself always
-   sorts first.
-
-   Example:
-          foo.example
-          a.foo.example
-          yljkjljk.a.foo.example
-          Z.a.foo.example
-          zABC.a.FOO.EXAMPLE
-          z.foo.example
-          *.z.foo.example
-          \200.z.foo.example
-
-8.3 Canonical RR Ordering Within An RRset
-
-   Within any particular owner name and type, RRs are sorted by RDATA as
-   a left justified unsigned octet sequence where the absence of an
-   octet sorts before the zero octet.
-
-8.4 Canonical Ordering of RR Types
-
-   When RRs of the same name but different types must be ordered, they
-   are ordered by type, considering the type to be an unsigned integer,
-   except that SIG RRs are placed immediately after the type they cover.
-   Thus, for example, an A record would be put before an MX record
-   because A is type 1 and MX is type 15 but if both were signed, the
-   order would be A < SIG(A) < MX < SIG(MX).
-
-9. Conformance
-
-   Levels of server and resolver conformance are defined below.
-
-9.1 Server Conformance
-
-   Two levels of server conformance for DNS security are defined as
-   follows:
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 37]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   BASIC:  Basic server compliance is the ability to store and retrieve
-   (including zone transfer) SIG, KEY, and NXT RRs.  Any secondary or
-   caching server for a secure zone MUST have at least basic compliance
-   and even then some things, such as secure CNAMEs, will not work
-   without full compliance.
-
-   FULL:  Full server compliance adds the following to basic compliance:
-   (1) ability to read SIG, KEY, and NXT RRs in zone files and (2)
-   ability, given a zone file and private key, to add appropriate SIG
-   and NXT RRs, possibly via a separate application, (3) proper
-   automatic inclusion of SIG, KEY, and NXT RRs in responses, (4)
-   suppression of CNAME following on retrieval of the security type RRs,
-   (5) recognize the CD query header bit and set the AD query header
-   bit, as appropriate, and (6) proper handling of the two NXT RRs at
-   delegation points.  Primary servers for secure zones MUST be fully
-   compliant and for complete secure operation, all secondary, caching,
-   and other servers handling the zone SHOULD be fully compliant as
-   well.
-
-9.2 Resolver Conformance
-
-   Two levels of resolver compliance (including the resolver portion of
-   a server) are defined for DNS Security:
-
-   BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs
-   when they are explicitly requested.
-
-   FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT
-   RRs including verification of SIGs at least for the mandatory
-   algorithm, (2) maintains appropriate information in its local caches
-   and database to indicate which RRs have been authenticated and to
-   what extent they have been authenticated, (3) performs additional
-   queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when
-   needed, (4) normally sets the CD query header bit on its queries.
-
-10. Security Considerations
-
-   This document specifies extensions to the Domain Name System (DNS)
-   protocol to provide data integrity and data origin authentication,
-   public key distribution, and optional transaction and request
-   security.
-
-   It should be noted that, at most, these extensions guarantee the
-   validity of resource records, including KEY resource records,
-   retrieved from the DNS.  They do not magically solve other security
-   problems.  For example, using secure DNS you can have high confidence
-   in the IP address you retrieve for a host name; however, this does
-   not stop someone for substituting an unauthorized host at that
-
-
-
-Eastlake                    Standards Track                    [Page 38]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   address or capturing packets sent to that address and falsely
-   responding with packets apparently from that address.  Any reasonably
-   complete security system will require the protection of many
-   additional facets of the Internet beyond DNS.
-
-   The implementation of NXT RRs as described herein enables a resolver
-   to determine all the names in a zone even if zone transfers are
-   prohibited (section 5.6).  This is an active area of work and may
-   change.
-
-   A number of precautions in DNS implementation have evolved over the
-   years to harden the insecure DNS against spoofing.  These precautions
-   should not be abandoned but should be considered to provide
-   additional protection in case of key compromise in secure DNS.
-
-11. IANA Considerations
-
-   KEY RR flag bits 2 and 8-11 and all flag extension field bits can be
-   assigned by IETF consensus as defined in RFC 2434.  The remaining
-   values of the NAMTYP flag field and flag bits 4 and 5 (which could
-   conceivably become an extension of the NAMTYP field) can only be
-   assigned by an IETF Standards Action [RFC 2434].
-
-   Algorithm numbers 5 through 251 are available for assignment should
-   sufficient reason arise.  However, the designation of a new algorithm
-   could have a major impact on interoperability and requires an IETF
-   Standards Action [RFC 2434].  The existence of the private algorithm
-   types 253 and 254 should satify most needs for private or proprietary
-   algorithms.
-
-   Additional values of the Protocol Octet (5-254) can be assigned by
-   IETF Consensus [RFC 2434].
-
-   The meaning of the first bit of the NXT RR "type bit map" being a one
-   can only be assigned by a standards action.
-
-References
-
-   [RFC 1033]  Lottor, M., "Domain Administrators Operations Guide", RFC
-               1033, November 1987.
-
-   [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]  Mockapetris, P., "Domain Names - Implementation and
-               Specifications", STD 13, RFC 1035, November 1987.
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 39]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   [RFC 1305]  Mills, D., "Network Time Protocol (v3)", RFC 1305, March
-               1992.
-
-   [RFC 1530]  Malamud, C. and M. Rose, "Principles of Operation for the
-               TPC.INT Subdomain: General Principles and Policy", RFC
-               1530, October 1993.
-
-   [RFC 2401]  Kent, S. and R. Atkinson, "Security Architecture for the
-               Internet Protocol", RFC 2401, November 1998.
-
-   [RFC 1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC
-               1982, September 1996.
-
-   [RFC 1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-               August 1996.
-
-   [RFC 2030]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
-               for IPv4, IPv6 and OSI", RFC 2030, October 1996.
-
-   [RFC 2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-               Extensions (MIME) Part One: Format of Internet Message
-               Bodies", RFC 2045, November 1996.
-
-   [RFC 2065]  Eastlake, D. and C. Kaufman, "Domain Name System Security
-               Extensions", RFC 2065, January 1997.
-
-   [RFC 2119]  Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
-               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-               RFC 2136, April 1997.
-
-   [RFC 2137]  Eastlake, D., "Secure Domain Name System Dynamic Update",
-               RFC 2137, April 1997.
-
-   [RFC 2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-               Specification", RFC 2181, July 1997.
-
-   [RFC 2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-               October 1998.
-
-   [RFC 2537]  Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
-               System (DNS)", RFC 2537, March 1999.
-
-   [RFC 2539]  Eastlake, D., "Storage of Diffie-Hellman Keys in the
-               Domain Name System (DNS)", RFC 2539, March 1999.
-
-
-
-Eastlake                    Standards Track                    [Page 40]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   [RFC 2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name
-               System (DNS)", RFC 2536, March 1999.
-
-   [RFC 2538]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in
-               the Domain Name System", RFC 2538, March 1999.
-
-   [RFC 2541]  Eastlake, D., "DNS Operational Security Considerations",
-               RFC 2541, March 1999.
-
-   [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road
-   RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-784-7913 (w)
-            +1-914-276-2668 (h)
-   Fax:     +1-914-784-3833 (w-fax)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 41]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Appendix A: Base 64 Encoding
-
-   The following encoding technique is taken from [RFC 2045] by N.
-   Borenstein and N. Freed.  It is reproduced here in an edited form for
-   convenience.
-
-   A 65-character subset of US-ASCII is used, enabling 6 bits to be
-   represented per printable character. (The extra 65th character, "=",
-   is used to signify a special processing function.)
-
-   The encoding process represents 24-bit groups of input bits as output
-   strings of 4 encoded characters. Proceeding from left to right, a
-   24-bit input group is formed by concatenating 3 8-bit input groups.
-   These 24 bits are then treated as 4 concatenated 6-bit groups, each
-   of which is translated into a single digit in the base 64 alphabet.
-
-   Each 6-bit group is used as an index into an array of 64 printable
-   characters. The character referenced by the index is placed in the
-   output string.
-
-                         Table 1: The Base 64 Alphabet
-
-      Value Encoding  Value Encoding  Value Encoding  Value Encoding
-          0 A            17 R            34 i            51 z
-          1 B            18 S            35 j            52 0
-          2 C            19 T            36 k            53 1
-          3 D            20 U            37 l            54 2
-          4 E            21 V            38 m            55 3
-          5 F            22 W            39 n            56 4
-          6 G            23 X            40 o            57 5
-          7 H            24 Y            41 p            58 6
-          8 I            25 Z            42 q            59 7
-          9 J            26 a            43 r            60 8
-         10 K            27 b            44 s            61 9
-         11 L            28 c            45 t            62 +
-         12 M            29 d            46 u            63 /
-         13 N            30 e            47 v
-         14 O            31 f            48 w         (pad) =
-         15 P            32 g            49 x
-         16 Q            33 h            50 y
-
-   Special processing is performed if fewer than 24 bits are available
-   at the end of the data being encoded.  A full encoding quantum is
-   always completed at the end of a quantity.  When fewer than 24 input
-   bits are available in an input group, zero bits are added (on the
-   right) to form an integral number of 6-bit groups.  Padding at the
-   end of the data is performed using the '=' character.  Since all base
-   64 input is an integral number of octets, only the following cases
-
-
-
-Eastlake                    Standards Track                    [Page 42]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   can arise: (1) the final quantum of encoding input is an integral
-   multiple of 24 bits; here, the final unit of encoded output will be
-   an integral multiple of 4 characters with no "=" padding, (2) the
-   final quantum of encoding input is exactly 8 bits; here, the final
-   unit of encoded output will be two characters followed by two "="
-   padding characters, or (3) the final quantum of encoding input is
-   exactly 16 bits; here, the final unit of encoded output will be three
-   characters followed by one "=" padding character.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 43]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Appendix B: Changes from RFC 2065
-
-   This section summarizes the most important changes that have been
-   made since RFC 2065.
-
-   1. Most of Section 7 of [RFC 2065] called "Operational
-      Considerations", has been removed and may be made into a separate
-      document [RFC 2541].
-
-   2. The KEY RR has been changed by (2a) eliminating the "experimental"
-      flag as unnecessary, (2b) reserving a flag  bit for flags
-      expansion, (2c) more compactly encoding a number of bit fields in
-      such a way as to leave unchanged bits actually used by the limited
-      code currently deployed, (2d) eliminating the IPSEC and email flag
-      bits which are replaced by values of the protocol field and adding
-      a protocol field value for DNS security itself, (2e) adding
-      material to indicate that zone KEY RRs occur only at delegation
-      points, and (2f) removing the description of the RSA/MD5 algorithm
-      to a separate document [RFC 2537].  Section 3.4 describing the
-      meaning of various combinations of "no-key" and key present KEY
-      RRs has been added and the secure / unsecure status of a zone has
-      been clarified as being per algorithm.
-
-   3. The SIG RR has been changed by (3a) renaming the "time signed"
-      field to be the "signature inception" field, (3b) clarifying that
-      signature expiration and inception use serial number ring
-      arithmetic, (3c) changing the definition of the key footprint/tag
-      for algorithms other than 1 and adding Appendix C to specify its
-      calculation.  In addition, the SIG covering type AXFR has been
-      eliminated while one covering IXFR [RFC 1995] has been added (see
-      section 5.6).
-
-   4. Algorithm 3, the DSA algorithm, is now designated as the mandatory
-      to implement algorithm.  Algorithm 1, the RSA/MD5 algorithm, is
-      now a recommended option.  Algorithm 2 and 4 are designated as the
-      Diffie-Hellman key and elliptic cryptography algorithms
-      respectively, all to be defined in separate documents. Algorithm
-      code point 252 is designated to indicate "indirect" keys, to be
-      defined in a separate document, where the actual key is elsewhere.
-      Both the KEY and SIG RR definitions have been simplified by
-      eliminating the "null" algorithm 253 as defined in [RFC 2065].
-      That algorithm had been included because at the time it was
-      thought it might be useful in DNS dynamic update [RFC 2136]. It
-      was in fact not so used and it is dropped to simplify DNS
-      security.  Howver, that algorithm number has been re-used to
-      indicate private algorithms where a domain name specifies the
-      algorithm.
-
-
-
-
-Eastlake                    Standards Track                    [Page 44]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   5. The NXT RR has been changed so that (5a) the NXT RRs in a zone
-      cover all names, including wildcards as literal names without
-      expansion, except for glue address records whose names would not
-      otherwise appear, (5b) all NXT bit map areas whose first octet has
-      bit zero set have been reserved for future definition, (5c) the
-      number of and circumstances under which an NXT must be returned in
-      connection with wildcard names has been extended, and (5d) in
-      connection with the bit map, references to the WKS RR have been
-      removed and verticle bars ("|") have been added between the RR
-      type mnemonics in the ASCII representation.
-
-   6. Information on the canonical form and ordering of RRs has been
-      moved into a separate Section 8.
-
-   7. A subsection covering incremental and full zone transfer has been
-      added in Section 5.
-
-   8. Concerning DNS chaining: Further specification and policy
-      recommendations on secure resolution have been added, primarily in
-      Section 6.3.1.  It is now clearly stated that authenticated data
-      has a validity period of the intersection of the validity periods
-      of the SIG RRs in its authentication chain.  The requirement to
-      staticly configure a superzone's key signed by a zone in all of
-      the zone's authoritative servers has been removed.  The
-      recommendation to continue DNS security checks in a secure island
-      of DNS data that is separated from other parts of the DNS tree by
-      insecure zones and does not contain a zone for which a key has
-      been staticly configured was dropped.
-
-   9. It was clarified that the presence of the AD bit in a response
-      does not apply to the additional information section or to glue
-      address or delegation point NS RRs.  The AD bit only indicates
-      that the answer and authority sections of the response are
-      authoritative.
-
-   10. It is now required that KEY RRs and NXT RRs be signed only with
-       zone-level keys.
-
-   11.  Add IANA Considerations section and references to RFC 2434.
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 45]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Appendix C: Key Tag Calculation
-
-   The key tag field in the SIG RR is just a means of more efficiently
-   selecting the correct KEY RR to use when there is more than one KEY
-   RR candidate available, for example, in verifying a signature.  It is
-   possible for more than one candidate key to have the same tag, in
-   which case each must be tried until one works or all fail.  The
-   following reference implementation of how to calculate the Key Tag,
-   for all algorithms other than algorithm 1, is in ANSI C.  It is coded
-   for clarity, not efficiency.  (See section 4.1.6 for how to determine
-   the Key Tag of an algorithm 1 key.)
-
-   /* assumes int is at least 16 bits
-      first byte of the key tag is the most significant byte of return
-      value
-      second byte of the key tag is the least significant byte of
-      return value
-      */
-
-   int keytag (
-
-           unsigned char key[],  /* the RDATA part of the KEY RR */
-           unsigned int keysize, /* the RDLENGTH */
-           )
-   {
-   long int    ac;    /* assumed to be 32 bits or larger */
-
-   for ( ac = 0, i = 0; i < keysize; ++i )
-       ac += (i&1) ? key[i] : key[i]<<8;
-   ac += (ac>>16) & 0xFFFF;
-   return ac & 0xFFFF;
-   }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 46]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 47]
-
diff --git a/doc/rfc/rfc2536.txt b/doc/rfc/rfc2536.txt
deleted file mode 100644
index 88be242b..00000000
--- a/doc/rfc/rfc2536.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. EastLake
-Request for Comments: 2536                                           IBM
-Category: Standards Track                                     March 1999
-
-
-           DSA KEYs and SIGs in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   A standard method for storing US Government Digital Signature
-   Algorithm keys and signatures in the Domain Name System is described
-   which utilizes DNS KEY and SIG resource records.
-
-Table of Contents
-
-   Abstract...................................................1
-   1. Introduction............................................1
-   2. DSA KEY Resource Records................................2
-   3. DSA SIG Resource Records................................3
-   4. Performance Considerations..............................3
-   5. Security Considerations.................................4
-   6. IANA Considerations.....................................4
-   References.................................................5
-   Author's Address...........................................5
-   Full Copyright Statement...................................6
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information. The DNS has been extended to include digital
-   signatures and cryptographic keys as described in [RFC 2535].  Thus
-   the DNS can now be secured and can be used for secure key
-   distribution.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-   This document describes how to store US Government Digital Signature
-   Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
-   US Digital Signature Algorithm is assumed [Schneier].  Implementation
-   of DSA is mandatory for DNS security.
-
-2. DSA KEY Resource Records
-
-   DSA public keys are stored in the DNS as KEY RRs using algorithm
-   number 3 [RFC 2535].  The structure of the algorithm specific portion
-   of the RDATA part of this RR is as shown below.  These fields, from Q
-   through Y are the "public key" part of the DSA KEY RR.
-
-   The period of key validity is not in the KEY RR but is indicated by
-   the SIG RR(s) which signs and authenticates the KEY RR(s) at that
-   domain name.
-
-           Field     Size
-           -----     ----
-            T         1  octet
-            Q        20  octets
-            P        64 + T*8  octets
-            G        64 + T*8  octets
-            Y        64 + T*8  octets
-
-   As described in [FIPS 186] and [Schneier]: T is a key size parameter
-   chosen such that 0 <= T <= 8.  (The meaning for algorithm 3 if the T
-   octet is greater than 8 is reserved and the remainder of the RDATA
-   portion may have a different format in that case.)  Q is a prime
-   number selected at key generation time such that 2**159 < Q < 2**160
-   so Q is always 20 octets long and, as with all other fields, is
-   stored in "big-endian" network order.  P, G, and Y are calculated as
-   directed by the FIPS 186 key generation algorithm [Schneier].  P is
-   in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T
-   octets long.  G and Y are quantities modulus P and so can be up to
-   the same length as P and are allocated fixed size fields with the
-   same number of octets as P.
-
-   During the key generation process, a random number X must be
-   generated such that 1 <= X <= Q-1.  X is the private key and is used
-   in the final step of public key generation where Y is computed as
-
-             Y = G**X mod P
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-3. DSA SIG Resource Records
-
-   The signature portion of the SIG RR RDATA area, when using the US
-   Digital Signature Algorithm, is shown below with fields in the order
-   they occur.  See [RFC 2535] for fields in the SIG RR RDATA which
-   precede the signature itself.
-
-           Field     Size
-           -----     ----
-            T         1 octet
-            R        20 octets
-            S        20 octets
-
-   The data signed is determined as specified in [RFC 2535].  Then the
-   following steps are taken, as specified in [FIPS 186], where Q, P, G,
-   and Y are as specified in the public key [Schneier]:
-
-           hash = SHA-1 ( data )
-
-           Generate a random K such that 0 < K < Q.
-
-           R = ( G**K mod P ) mod Q
-
-           S = ( K**(-1) * (hash + X*R) ) mod Q
-
-   Since Q is 160 bits long, R and S can not be larger than 20 octets,
-   which is the space allocated.
-
-   T is copied from the public key.  It is not logically necessary in
-   the SIG but is present so that values of T > 8 can more conveniently
-   be used as an escape for extended versions of DSA or other algorithms
-   as later specified.
-
-4. Performance Considerations
-
-   General signature generation speeds are roughly the same for RSA [RFC
-   2537] and DSA.  With sufficient pre-computation, signature generation
-   with DSA is faster than RSA.  Key generation is also faster for DSA.
-   However, signature verification is an order of magnitude slower than
-   RSA when the RSA public exponent is chosen to be small as is
-   recommended for KEY RRs used in domain name system (DNS) data
-   authentication.
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including overhead.  While larger
-   transfers will perform correctly and work is underway to make larger
-   transfers more efficient, it is still advisable at this time to make
-   reasonable efforts to minimize the size of KEY RR sets stored within
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-   the DNS consistent with adequate security.  Keep in mind that in a
-   secure zone, at least one authenticating SIG RR will also be
-   returned.
-
-5. Security Considerations
-
-   Many of the general security consideration in [RFC 2535] apply.  Keys
-   retrieved from the DNS should not be trusted unless (1) they have
-   been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is essential and
-   dependent on local policy.
-
-   The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
-   current DSA standard may limit the security of DSA.  For particularly
-   critical applications, implementors are encouraged to consider the
-   range of available algorithms and key sizes.
-
-   DSA assumes the ability to frequently generate high quality random
-   numbers.  See [RFC 1750] for guidance.  DSA is designed so that if
-   manipulated rather than random numbers are used, very high bandwidth
-   covert channels are possible.  See [Schneier] and more recent
-   research.  The leakage of an entire DSA private key in only two DSA
-   signatures has been demonstrated.  DSA provides security only if
-   trusted implementations, including trusted random number generation,
-   are used.
-
-6. IANA Considerations
-
-   Allocation of meaning to values of the T parameter that are not
-   defined herein requires an IETF standards actions.  It is intended
-   that values unallocated herein be used to cover future extensions of
-   the DSS standard.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-References
-
-   [FIPS 186]   U.S. Federal Information Processing Standard: Digital
-                Signature Standard.
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
-                Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC 1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-                Recommendations for Security", RFC 1750, December 1994.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RFC 2537]   Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
-                System (DNS)", RFC 2537, March 1999.
-
-   [Schneier]   Schneier, B., "Applied Cryptography Second Edition:
-                protocols, algorithms, and source code in C", 1996.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
diff --git a/doc/rfc/rfc2537.txt b/doc/rfc/rfc2537.txt
deleted file mode 100644
index cb75cf5b..00000000
--- a/doc/rfc/rfc2537.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2537                                           IBM
-Category: Standards Track                                     March 1999
-
-
-         RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   A standard method for storing RSA keys and and RSA/MD5 based
-   signatures in the Domain Name System is described which utilizes DNS
-   KEY and SIG resource records.
-
-Table of Contents
-
-   Abstract...................................................1
-   1. Introduction............................................1
-   2. RSA Public KEY Resource Records.........................2
-   3. RSA/MD5 SIG Resource Records............................2
-   4. Performance Considerations..............................3
-   5. Security Considerations.................................4
-   References.................................................4
-   Author's Address...........................................5
-   Full Copyright Statement...................................6
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information. The DNS has been extended to include digital
-   signatures and cryptographic keys as described in [RFC 2535].  Thus
-   the DNS can now be secured and used for secure key distribution.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-   This document describes how to store RSA keys and and RSA/MD5 based
-   signatures in the DNS.  Familiarity with the RSA algorithm is assumed
-   [Schneier].  Implementation of the RSA algorithm in DNS is
-   recommended.
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
-   in this document are to be interpreted as described in RFC 2119.
-
-2. RSA Public KEY Resource Records
-
-   RSA public keys are stored in the DNS as KEY RRs using algorithm
-   number 1 [RFC 2535].  The structure of the algorithm specific portion
-   of the RDATA part of such RRs is as shown below.
-
-           Field             Size
-           -----             ----
-           exponent length   1 or 3 octets (see text)
-           exponent          as specified by length field
-           modulus           remaining space
-
-   For interoperability, the exponent and modulus are each currently
-   limited to 4096 bits in length.  The public key exponent is a
-   variable length unsigned integer.  Its length in octets is
-   represented as one octet if it is in the range of 1 to 255 and by a
-   zero octet followed by a two octet unsigned length if it is longer
-   than 255 bytes.  The public key modulus field is a multiprecision
-   unsigned integer.  The length of the modulus can be determined from
-   the RDLENGTH and the preceding RDATA fields including the exponent.
-   Leading zero octets are prohibited in the exponent and modulus.
-
-3. RSA/MD5 SIG Resource Records
-
-   The signature portion of the SIG RR RDATA area, when using the
-   RSA/MD5 algorithm, is calculated as shown below.  The data signed is
-   determined as specified in [RFC 2535].  See [RFC 2535] for fields in
-   the SIG RR RDATA which precede the signature itself.
-
-
-     hash = MD5 ( data )
-
-     signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-   where MD5 is the message digest algorithm documented in [RFC 1321],
-   "|" is concatenation, "e" is the private key exponent of the signer,
-   and "n" is the modulus of the signer's public key.  01, FF, and 00
-   are fixed octets of the corresponding hexadecimal value. "prefix" is
-   the ASN.1 BER MD5 algorithm designator prefix specified in [RFC
-   2437], that is,
-
-      hex 3020300c06082a864886f70d020505000410 [NETSEC].
-
-   This prefix is included to make it easier to use RSAREF (or similar
-   packages such as EuroRef).  The FF octet MUST be repeated the maximum
-   number of times such that the value of the quantity being
-   exponentiated is the same length in octets as the value of n.
-
-   (The above specifications are identical to the corresponding part of
-   Public Key Cryptographic Standard #1 [RFC 2437].)
-
-   The size of n, including most and least significant bits (which will
-   be 1) MUST be not less than 512 bits and not more than 4096 bits.  n
-   and e SHOULD be chosen such that the public exponent is small.
-
-   Leading zero bytes are permitted in the RSA/MD5 algorithm signature.
-
-   A public exponent of 3 minimizes the effort needed to verify a
-   signature.  Use of 3 as the public exponent is weak for
-   confidentiality uses since, if the same data can be collected
-   encrypted under three different keys with an exponent of 3 then,
-   using the Chinese Remainder Theorem [NETSEC], the original plain text
-   can be easily recovered.  This weakness is not significant for DNS
-   security because we seek only authentication, not confidentiality.
-
-4. Performance Considerations
-
-   General signature generation speeds are roughly the same for RSA and
-   DSA [RFC 2536].  With sufficient pre-computation, signature
-   generation with DSA is faster than RSA.  Key generation is also
-   faster for DSA.  However, signature verification is an order of
-   magnitude slower with DSA when the RSA public exponent is chosen to
-   be small as is recommended for KEY RRs used in domain name system
-   (DNS) data authentication.
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including overhead.  While larger
-   transfers will perform correctly and work is underway to make larger
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-   transfers more efficient, it is still advisable at this time to make
-   reasonable efforts to minimize the size of KEY RR sets stored within
-   the DNS consistent with adequate security.  Keep in mind that in a
-   secure zone, at least one authenticating SIG RR will also be
-   returned.
-
-5. Security Considerations
-
-   Many of the general security consideration in [RFC 2535] apply.  Keys
-   retrieved from the DNS should not be trusted unless (1) they have
-   been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is essential and
-   dependent on local policy.
-
-   For interoperability, the RSA key size is limited to 4096 bits.  For
-   particularly critical applications, implementors are encouraged to
-   consider the range of available algorithms and key sizes.
-
-References
-
-   [NETSEC]     Kaufman, C., Perlman, R. and M. Speciner, "Network
-                Security: PRIVATE Communications in a PUBLIC World",
-                Series in Computer Networking and Distributed
-                Communications, 1995.
-
-   [RFC 2437]   Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
-                Specifications Version 2.0", RFC 2437, October 1998.
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
-                Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC 1321]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321
-                April 1992.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RFC 2536]   EastLake, D., "DSA KEYs and SIGs in the Domain Name
-                System (DNS)", RFC 2536, March 1999.
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-   [Schneier]   Bruce Schneier, "Applied Cryptography Second Edition:
-                protocols, algorithms, and source code in C", 1996, John
-                Wiley and Sons, ISBN 0-471-11709-9.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
diff --git a/doc/rfc/rfc2538.txt b/doc/rfc/rfc2538.txt
deleted file mode 100644
index c53e3efd..00000000
--- a/doc/rfc/rfc2538.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2538                                           IBM
-Category: Standards Track                                 O. Gudmundsson
-                                                                TIS Labs
-                                                              March 1999
-
-
-          Storing Certificates in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   Cryptographic public key are frequently published and their
-   authenticity demonstrated by certificates.  A CERT resource record
-   (RR) is defined so that such certificates and related certificate
-   revocation lists can be stored in the Domain Name System (DNS).
-
-Table of Contents
-
-   Abstract...................................................1
-   1. Introduction............................................2
-   2. The CERT Resource Record................................2
-   2.1 Certificate Type Values................................3
-   2.2 Text Representation of CERT RRs........................4
-   2.3 X.509 OIDs.............................................4
-   3. Appropriate Owner Names for CERT RRs....................5
-   3.1 X.509 CERT RR Names....................................5
-   3.2 PGP CERT RR Names......................................6
-   4. Performance Considerations..............................6
-   5. IANA Considerations.....................................7
-   6. Security Considerations.................................7
-   References.................................................8
-   Authors' Addresses.........................................9
-   Full Copyright Notice.....................................10
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 1]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-1. Introduction
-
-   Public keys are frequently published in the form of a certificate and
-   their authenticity is commonly demonstrated by certificates and
-   related certificate revocation lists (CRLs).  A certificate is a
-   binding, through a cryptographic digital signature, of a public key,
-   a validity interval and/or conditions, and identity, authorization,
-   or other information. A certificate revocation list is a list of
-   certificates that are revoked, and incidental information, all signed
-   by the signer (issuer) of the revoked certificates. Examples are
-   X.509 certificates/CRLs in the X.500 directory system or PGP
-   certificates/revocations used by PGP software.
-
-   Section 2 below specifies a CERT resource record (RR) for the storage
-   of certificates in the Domain Name System.
-
-   Section 3 discusses appropriate owner names for CERT RRs.
-
-   Sections 4, 5, and 6 below cover performance, IANA, and security
-   considerations, respectively.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2. The CERT Resource Record
-
-   The CERT resource record (RR) has the structure given below.  Its RR
-   type code is 37.
-
-                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |             type              |             key tag           |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |   algorithm   |                                               /
-    +---------------+            certificate or CRL                 /
-    /                                                               /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-   The type field is the certificate type as define in section 2.1
-   below.
-
-   The algorithm field has the same meaning as the algorithm field in
-   KEY and SIG RRs [RFC 2535] except that a zero algorithm field
-   indicates the algorithm is unknown to a secure DNS, which may simply
-   be the result of the algorithm not having been standardized for
-   secure DNS.
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 2]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-   The key tag field is the 16 bit value computed for the key embedded
-   in the certificate as specified in the DNSSEC Standard [RFC 2535].
-   This field is used as an efficiency measure to pick which CERT RRs
-   may be applicable to a particular key.  The key tag can be calculated
-   for the key in question and then only CERT RRs with the same key tag
-   need be examined. However, the key must always be transformed to the
-   format it would have as the public key portion of a KEY RR before the
-   key tag is computed.  This is only possible if the key is applicable
-   to an algorithm (and limits such as key size limits) defined for DNS
-   security.  If it is not, the algorithm field MUST BE zero and the tag
-   field is meaningless and SHOULD BE zero.
-
-2.1 Certificate Type Values
-
-   The following values are defined or reserved:
-
-    Value  Mnemonic  Certificate Type
-    -----  --------  ----------- ----
-        0            reserved
-        1   PKIX     X.509 as per PKIX
-        2   SPKI     SPKI cert
-        3   PGP      PGP cert
-    4-252            available for IANA assignment
-      253   URI      URI private
-      254   OID      OID private
-    255-65534        available for IANA assignment
-    65535            reserved
-
-   The PKIX type is reserved to indicate an X.509 certificate conforming
-   to the profile being defined by the IETF PKIX working group.  The
-   certificate section will start with a one byte unsigned OID length
-   and then an X.500 OID indicating the nature of the remainder of the
-   certificate section (see 2.3 below).  (NOTE: X.509 certificates do
-   not include their X.500 directory type designating OID as a prefix.)
-
-   The SPKI type is reserved to indicate a certificate formated as to be
-   specified by the IETF SPKI working group.
-
-   The PGP type indicates a Pretty Good Privacy certificate as described
-   in RFC 2440 and its extensions and successors.
-
-   The URI private type indicates a certificate format defined by an
-   absolute URI.  The certificate portion of the CERT RR MUST begin with
-   a null terminated URI [RFC 2396] and the data after the null is the
-   private format certificate itself.  The URI SHOULD be such that a
-   retrieval from it will lead to documentation on the format of the
-   certificate.  Recognition of private certificate types need not be
-   based on URI equality but can use various forms of pattern matching
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 3]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-   so that, for example, subtype or version information can also be
-   encoded into the URI.
-
-   The OID private type indicates a private format certificate specified
-   by a an ISO OID prefix.  The certificate section will start with a
-   one byte unsigned OID length and then a BER encoded OID indicating
-   the nature of the remainder of the certificate section.  This can be
-   an X.509 certificate format or some other format.  X.509 certificates
-   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
-   type, not the OID private type.  Recognition of private certificate
-   types need not be based on OID equality but can use various forms of
-   pattern matching such as OID prefix.
-
-2.2 Text Representation of CERT RRs
-
-   The RDATA portion of a CERT RR has the type field as an unsigned
-   integer or as a mnemonic symbol as listed in section 2.1 above.
-
-   The key tag field is represented as an unsigned integer.
-
-   The algorithm field is represented as an unsigned integer or a
-   mnemonic symbol as listed in [RFC 2535].
-
-   The certificate / CRL portion is represented in base 64 and may be
-   divided up into any number of white space separated substrings, down
-   to single base 64 digits, which are concatenated to obtain the full
-   signature.  These substrings can span lines using the standard
-   parenthesis.
-
-   Note that the certificate / CRL portion may have internal sub-fields
-   but these do not appear in the master file representation.  For
-   example, with type 254, there will be an OID size, an OID, and then
-   the certificate / CRL proper. But only a single logical base 64
-   string will appear in the text representation.
-
-2.3 X.509 OIDs
-
-   OIDs have been defined in connection with the X.500 directory for
-   user certificates, certification authority certificates, revocations
-   of certification authority, and revocations of user certificates.
-   The following table lists the OIDs, their BER encoding, and their
-   length prefixed hex format for use in CERT RRs:
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 4]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-    id-at-userCertificate
-        = { joint-iso-ccitt(2) ds(5) at(4) 36 }
-           == 0x 03 55 04 24
-    id-at-cACertificate
-        = { joint-iso-ccitt(2) ds(5) at(4) 37 }
-           == 0x 03 55 04 25
-    id-at-authorityRevocationList
-        = { joint-iso-ccitt(2) ds(5) at(4) 38 }
-           == 0x 03 55 04 26
-    id-at-certificateRevocationList
-        = { joint-iso-ccitt(2) ds(5) at(4) 39 }
-           == 0x 03 55 04 27
-
-3. Appropriate Owner Names for CERT RRs
-
-   It is recommended that certificate CERT RRs be stored under a domain
-   name related to their subject, i.e., the name of the entity intended
-   to control the private key corresponding to the public key being
-   certified.  It is recommended that certificate revocation list CERT
-   RRs be stored under a domain name related to their issuer.
-
-   Following some of the guidelines below may result in the use in DNS
-   names of characters that require DNS quoting which is to use a
-   backslash followed by the octal representation of the ASCII code for
-   the character such as \000 for NULL.
-
-3.1 X.509 CERT RR Names
-
-   Some X.509 versions permit multiple names to be associated with
-   subjects and issuers under "Subject Alternate Name" and "Issuer
-   Alternate Name".  For example, x.509v3 has such Alternate Names with
-   an ASN.1 specification as follows:
-
-         GeneralName ::= CHOICE {
-            otherName                  [0] INSTANCE OF OTHER-NAME,
-            rfc822Name                 [1] IA5String,
-            dNSName                    [2] IA5String,
-            x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
-            directoryName              [4] EXPLICIT Name,
-            ediPartyName               [5] EDIPartyName,
-            uniformResourceIdentifier  [6] IA5String,
-            iPAddress                  [7] OCTET STRING,
-            registeredID               [8] OBJECT IDENTIFIER
-         }
-
-   The recommended locations of CERT storage are as follows, in priority
-   order:
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 5]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-   (1) If a domain name is included in the identification in the
-       certificate or CRL, that should be used.
-   (2) If a domain name is not included but an IP address is included,
-       then the translation of that IP address into the appropriate
-       inverse domain name should be used.
-   (3) If neither of the above it used but a URI containing a domain
-       name is present, that domain name should be used.
-   (4) If none of the above is included but a character string name is
-       included, then it should be treated as described for PGP names in
-       3.2 below.
-   (5) If none of the above apply, then the distinguished name (DN)
-       should be mapped into a domain name as specified in RFC 2247.
-
-   Example 1: Assume that an X.509v3 certificate is issued to /CN=John
-   Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative
-   names of (a) string "John (the Man) Doe", (b) domain name john-
-   doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>.  Then
-   the storage locations recommended, in priority order, would be
-       (1) john-doe.com,
-       (2) www.secure.john-doe.com, and
-       (3) Doe.com.xy.
-
-   Example 2:  Assume that an X.509v3 certificate is issued to /CN=James
-   Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names
-   of (a) domain name widget.foo.example, (b) IPv4 address
-   10.251.13.201, and (c) string "James Hacker
-   <hacker@mail.widget.foo.example>".  Then the storage locations
-   recommended, in priority order, would be
-        (1) widget.foo.example,
-        (2) 201.13.251.10.in-addr.arpa, and
-        (3) hacker.mail.widget.foo.example.
-
-3.2 PGP CERT RR Names
-
-   PGP signed keys (certificates) use a general character string User ID
-   [RFC 2440]. However, it is recommended by PGP that such names include
-   the RFC 822 email address of the party, as in "Leslie Example
-   <Leslie@host.example>".  If such a format is used, the CERT should be
-   under the standard translation of the email address into a domain
-   name, which would be leslie.host.example in this case.  If no RFC 822
-   name can be extracted from the string name no specific domain name is
-   recommended.
-
-4. Performance Considerations
-
-   Current Domain Name System (DNS) implementations are optimized for
-   small transfers, typically not more than 512 bytes including
-   overhead.  While larger transfers will perform correctly and work is
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 6]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-   underway to make larger transfers more efficient, it is still
-   advisable at this time to make every reasonable effort to minimize
-   the size of certificates stored within the DNS.  Steps that can be
-   taken may include using the fewest possible optional or extensions
-   fields and using short field values for variable length fields that
-   must be included.
-
-5. IANA Considerations
-
-   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
-   only be assigned by an IETF standards action [RFC 2434] (and this
-   document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE).
-   Certificate types 0x0100 through 0xFEFF are assigned through IETF
-   Consensus [RFC 2434] based on RFC documentation of the certificate
-   type.  The availability of private types under 0x00FD and 0x00FE
-   should satisfy most requirements for proprietary or private types.
-
-6. Security Considerations
-
-   By definition, certificates contain their own authenticating
-   signature.  Thus it is reasonable to store certificates in non-secure
-   DNS zones or to retrieve certificates from DNS with DNS security
-   checking not implemented or deferred for efficiency.  The results MAY
-   be trusted if the certificate chain is verified back to a known
-   trusted key and this conforms with the user's security policy.
-
-   Alternatively, if certificates are retrieved from a secure DNS zone
-   with DNS security checking enabled and are verified by DNS security,
-   the key within the retrieved certificate MAY be trusted without
-   verifying the certificate chain if this conforms with the user's
-   security policy.
-
-   CERT RRs are not used in connection with securing the DNS security
-   additions so there are no security considerations related to CERT RRs
-   and securing the DNS itself.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 7]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-References
-
-   RFC 1034   Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   RFC 1035   Mockapetris, P., "Domain Names - Implementation and
-              Specifications", STD 13, RFC 1035, November 1987.
-
-   RFC 2119   Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   RFC 2247   Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
-              Sataluri, "Using Domains in LDAP/X.500 Distinguished
-              Names", RFC 2247, January 1998.
-
-   RFC 2396   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
-              Resource Identifiers (URI): Generic Syntax", RFC 2396,
-              August 1998.
-
-   RFC 2440   Callas, J., Donnerhacke, L., Finney, H. and R.  Thayer,
-              "OpenPGP Message Format", RFC 2240, November 1998.
-
-   RFC 2434   Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-              October 1998.
-
-   RFC 2535   Eastlake, D., "Domain Name System (DNS) Security
-              Extensions", RFC 2535, March 1999.
-
-   RFC 2459   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and CRL
-              Profile", RFC 2459, January 1999.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 8]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-Authors' Addresses
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road
-   RR#1
-   Carmel, NY 10512 USA
-
-   Phone:   +1-914-784-7913 (w)
-            +1-914-276-2668 (h)
-   Fax:     +1-914-784-3833 (w-fax)
-   EMail:   dee3@us.ibm.com
-
-
-   Olafur Gudmundsson
-   TIS Labs at Network Associates
-   3060 Washington Rd, Route 97
-   Glenwood MD 21738
-
-   Phone: +1 443-259-2389
-   EMail: ogud@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 9]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                    [Page 10]
-
diff --git a/doc/rfc/rfc2539.txt b/doc/rfc/rfc2539.txt
deleted file mode 100644
index cf32523d..00000000
--- a/doc/rfc/rfc2539.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2539                                           IBM
-Category: Standards Track                                     March 1999
-
-
-     Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   A standard method for storing Diffie-Hellman keys in the Domain Name
-   System is described which utilizes DNS KEY resource records.
-
-Acknowledgements
-
-   Part of the format for Diffie-Hellman keys and the description
-   thereof was taken from a work in progress by:
-
-      Ashar Aziz <ashar.aziz@eng.sun.com>
-      Tom Markson <markson@incog.com>
-      Hemma Prafullchandra <hemma@eng.sun.com>
-
-   In addition, the following person provided useful comments that have
-   been incorporated:
-
-      Ran Atkinson <rja@inet.org>
-      Thomas Narten <narten@raleigh.ibm.com>
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-Table of Contents
-
-   Abstract...................................................1
-   Acknowledgements...........................................1
-   1. Introduction............................................2
-   1.1 About This Document....................................2
-   1.2 About Diffie-Hellman...................................2
-   2. Diffie-Hellman KEY Resource Records.....................3
-   3. Performance Considerations..............................4
-   4. IANA Considerations.....................................4
-   5. Security Considerations.................................4
-   References.................................................5
-   Author's Address...........................................5
-   Appendix A: Well known prime/generator pairs...............6
-   A.1. Well-Known Group 1:  A 768 bit prime..................6
-   A.2. Well-Known Group 2:  A 1024 bit prime.................6
-   Full Copyright Notice......................................7
-
-1. Introduction
-
-   The Domain Name System (DNS) is the current global hierarchical
-   replicated distributed database system for Internet addressing, mail
-   proxy, and similar information. The DNS has been extended to include
-   digital signatures and cryptographic keys as described in [RFC 2535].
-   Thus the DNS can now be used for secure key distribution.
-
-1.1 About This Document
-
-   This document describes how to store Diffie-Hellman keys in the DNS.
-   Familiarity with the Diffie-Hellman key exchange algorithm is assumed
-   [Schneier].
-
-1.2 About Diffie-Hellman
-
-   Diffie-Hellman requires two parties to interact to derive keying
-   information which can then be used for authentication.  Since DNS SIG
-   RRs are primarily used as stored authenticators of zone information
-   for many different resolvers, no Diffie-Hellman algorithm SIG RR is
-   defined. For example, assume that two parties have local secrets "i"
-   and "j".  Assume they each respectively calculate X and Y as follows:
-
-                X = g**i ( mod p ) Y = g**j ( mod p )
-
-   They exchange these quantities and then each calculates a Z as
-   follows:
-
-                Zi = Y**i ( mod p ) Zj = X**j ( mod p )
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-   shared secret between the two parties that an adversary who does not
-   know i or j will not be able to learn from the exchanged messages
-   (unless the adversary can derive i or j by performing a discrete
-   logarithm mod p which is hard for strong p and g).
-
-   The private key for each party is their secret i (or j).  The public
-   key is the pair p and g, which must be the same for the parties, and
-   their individual X (or Y).
-
-2. Diffie-Hellman KEY Resource Records
-
-   Diffie-Hellman keys are stored in the DNS as KEY RRs using algorithm
-   number 2.  The structure of the RDATA portion of this RR is as shown
-   below.  The first 4 octets, including the flags, protocol, and
-   algorithm fields are common to all KEY RRs as described in [RFC
-   2535].  The remainder, from prime length through public value is the
-   "public key" part of the KEY RR. The period of key validity is not in
-   the KEY RR but is indicated by the SIG RR(s) which signs and
-   authenticates the KEY RR(s) at that domain name.
-
-                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |           KEY flags           |    protocol   |  algorithm=2  |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |     prime length (or flag)    |  prime (p) (or special)       /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /  prime (p)  (variable length) |       generator length        |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    | generator (g) (variable length)                               |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |     public value length       | public value (variable length)/
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /  public value (g^i mod p)    (variable length)                |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Prime length is length of the Diffie-Hellman prime (p) in bytes if it
-   is 16 or greater.  Prime contains the binary representation of the
-   Diffie-Hellman prime with most significant byte first (i.e., in
-   network order). If "prime length" field is 1 or 2, then the "prime"
-   field is actually an unsigned index into a table of 65,536
-   prime/generator pairs and the generator length SHOULD be zero.  See
-   Appedix A for defined table entries and Section 4 for information on
-   allocating additional table entries.  The meaning of a zero or 3
-   through 15 value for "prime length" is reserved.
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-   Generator length is the length of the generator (g) in bytes.
-   Generator is the binary representation of generator with most
-   significant byte first.  PublicValueLen is the Length of the Public
-   Value (g**i (mod p)) in bytes.  PublicValue is the binary
-   representation of the DH public value with most significant byte
-   first.
-
-   The corresponding algorithm=2 SIG resource record is not used so no
-   format for it is defined.
-
-3. Performance Considerations
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including overhead.  While larger
-   transfers will perform correctly and work is underway to make larger
-   transfers more efficient, it is still advisable to make reasonable
-   efforts to minimize the size of KEY RR sets stored within the DNS
-   consistent with adequate security.  Keep in mind that in a secure
-   zone, an authenticating SIG RR will also be returned.
-
-4. IANA Considerations
-
-   Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
-   an IETF consensus.
-
-   Well known prime/generator pairs number 0x0000 through 0x07FF can
-   only be assigned by an IETF standards action and this Proposed
-   Standard assigns 0x0001 through 0x0002. Pairs number 0s0800 through
-   0xBFFF can be assigned based on RFC documentation.  Pairs number
-   0xC000 through 0xFFFF are available for private use and are not
-   centrally coordinated. Use of such private pairs outside of a closed
-   environment may result in conflicts.
-
-5. Security Considerations
-
-   Many of the general security consideration in [RFC 2535] apply.  Keys
-   retrieved from the DNS should not be trusted unless (1) they have
-   been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is important and
-   dependent on local policy.
-
-   In addition, the usual Diffie-Hellman key strength considerations
-   apply. (p-1)/2 should also be prime, g should be primitive mod p, p
-   should be "large", etc.  [Schneier]
-
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-References
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
-                Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [Schneier]   Bruce Schneier, "Applied Cryptography: Protocols,
-                Algorithms, and Source Code in C", 1996, John Wiley and
-                Sons
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-Appendix A: Well known prime/generator pairs
-
-   These numbers are copied from the IPSEC effort where the derivation
-   of these values is more fully explained and additional information is
-   available.  Richard Schroeppel performed all the mathematical and
-   computational work for this appendix.
-
-A.1. Well-Known Group 1:  A 768 bit prime
-
-   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
-   decimal value is
-          155251809230070893513091813125848175563133404943451431320235
-          119490296623994910210725866945387659164244291000768028886422
-          915080371891804634263272761303128298374438082089019628850917
-          0691316593175367469551763119843371637221007210577919
-
-   Prime modulus: Length (32 bit words): 24, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words): 1, Data (hex): 2
-
-A.2. Well-Known Group 2:  A 1024 bit prime
-
-   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
-   Its decimal value is
-         179769313486231590770839156793787453197860296048756011706444
-         423684197180216158519368947833795864925541502180565485980503
-         646440548199239100050792877003355816639229553136239076508735
-         759914822574862575007425302077447712589550957937778424442426
-         617334727629299387668709205606050270810842907692932019128194
-         467627007
-
-   Prime modulus:  Length (32 bit words): 32, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
-            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
-            FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words):  1, Data (hex): 2
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
diff --git a/doc/rfc/rfc2540.txt b/doc/rfc/rfc2540.txt
deleted file mode 100644
index 63148061..00000000
--- a/doc/rfc/rfc2540.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2540                                           IBM
-Category: Experimental                                        March 1999
-
-
-             Detached Domain Name System (DNS) Information
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  It does not specify an Internet standard of any kind.
-   Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   A standard format is defined for representing detached DNS
-   information.  This is anticipated to be of use for storing
-   information retrieved from the Domain Name System (DNS), including
-   security information, in archival contexts or contexts not connected
-   to the Internet.
-
-Table of Contents
-
-   Abstract...................................................1
-   1. Introduction............................................1
-   2. General Format..........................................2
-   2.1 Binary Format..........................................3
-   2.2. Text Format...........................................4
-   3. Usage Example...........................................4
-   4. IANA Considerations.....................................4
-   5. Security Considerations.................................4
-   References.................................................5
-   Author's Address...........................................5
-   Full Copyright Statement...................................6
-
-1. Introduction
-
-   The Domain Name System (DNS) is a replicated hierarchical distributed
-   database system [RFC 1034, 1035] that can provide highly available
-   service.  It provides the operational basis for Internet host name to
-   address translation, automatic SMTP mail routing, and other basic
-   Internet functions.  The DNS has been extended as described in [RFC
-   2535] to permit the general storage of public cryptographic keys in
-
-
-
-Eastlake                      Experimental                      [Page 1]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-   the DNS and to enable the authentication of information retrieved
-   from the DNS though digital signatures.
-
-   The DNS was not originally designed for storage of information
-   outside of the active zones and authoritative master files that are
-   part of the connected DNS.  However there may be cases where this is
-   useful, particularly in connection with archived security
-   information.
-
-2. General Format
-
-   The formats used for detached Domain Name System (DNS) information
-   are similar to those used for connected DNS information. The primary
-   difference is that elements of the connected DNS system (unless they
-   are an authoritative server for the zone containing the information)
-   are required to count down the Time To Live (TTL) associated with
-   each DNS Resource Record (RR) and discard them (possibly fetching a
-   fresh copy) when the TTL reaches zero.  In contrast to this, detached
-   information may be stored in a off-line file, where it can not be
-   updated, and perhaps used to authenticate historic data or it might
-   be received via non-DNS protocols long after it was retrieved from
-   the DNS.  Therefore, it is not practical to count down detached DNS
-   information TTL and it may be necessary to keep the data beyond the
-   point where the TTL (which is defined as an unsigned field) would
-   underflow.  To preserve information as to the freshness of this
-   detached data, it is accompanied by its retrieval time.
-
-   Whatever retrieves the information from the DNS must associate this
-   retrieval time with it.  The retrieval time remains fixed thereafter.
-   When the current time minus the retrieval time exceeds the TTL for
-   any particular detached RR, it is no longer a valid copy within the
-   normal connected DNS scheme.  This may make it invalid in context for
-   some detached purposes as well.  If the RR is a SIG (signature) RR it
-   also has an expiration time.  Regardless of the TTL, it and any RRs
-   it signs can not be considered authenticated after the signature
-   expiration time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                      Experimental                      [Page 2]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-2.1 Binary Format
-
-   The standard binary format for detached DNS information is as
-   follows:
-
-                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                      first retrieval time                     |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |          RR count             |                               |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
-    /                                                               /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-    |                       next retrieval time                     |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |          RR count             |                               |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
-    /                                                               /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /                              ...                              /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |     hex 20    |
-    +-+-+-+-+-+-+-+-+
-
-   Retrieval time - the time that the immediately following information
-       was obtained from the connected DNS system.  It is an unsigned
-       number of seconds since the start of 1 January 1970, GMT,
-       ignoring leap seconds, in network (big-endian) order.  Note that
-       this time can not be before the initial proposal of this
-       standard.  Therefore, the initial byte of an actual retrieval
-       time, considered as a 32 bit unsigned quantity, would always be
-       larger than 20 hex.  The end of detached DNS information is
-       indicated by a "retrieval time" field initial byte equal to 0x20.
-       Use of a "retrieval time" field with a leading unsigned byte of
-       zero indicates a 64 bit (actually 8 leading zero bits plus a 56
-       bit quantity).  This 64 bit format will be required when
-       retrieval time is larger than 0xFFFFFFFF, which is some time in
-       the year 2106.  The meaning of retrieval times with an initial
-       byte between 0x01 and 0x1F is reserved (see section 5).
-       Retrieval times will not generally be 32 bit aligned with respect
-       to each other due to the variable length nature of RRs.
-
-   RR count - an unsigned integer number (with bytes in network order)
-       of following resource records retrieved at the preceding
-       retrieval time.
-
-
-
-
-
-Eastlake                      Experimental                      [Page 3]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-   Resource Records - the actual data which is in the same format as if
-       it were being transmitted in a DNS response.  In particular, name
-       compression via pointers is permitted with the origin at the
-       beginning of the particular detached information data section,
-       just after the RR count.
-
-2.2. Text Format
-
-   The standard text format for detached DNS information is as
-   prescribed for zone master files [RFC 1035] except that the $INCLUDE
-   control entry is prohibited and the new $DATE entry is required
-   (unless the information set is empty). $DATE is followed by the date
-   and time that the following information was obtained from the DNS
-   system as described for retrieval time in section 2.1 above.  It is
-   in the text format YYYYMMDDHHMMSS where YYYY is the year (which may
-   be more than four digits to cover years after 9999), the first MM is
-   the month number (01-12), DD is the day of the month (01-31), HH is
-   the hour in 24 hours notation (00-23), the second MM is the minute
-   (00-59), and SS is the second (00-59).  Thus a $DATE must appear
-   before the first RR and at every change in retrieval time through the
-   detached information.
-
-3. Usage Example
-
-   A document might be authenticated by a key retrieved from the DNS in
-   a KEY resource record (RR).  To later prove the authenticity of this
-   document, it would be desirable to preserve the KEY RR for that
-   public key, the SIG RR signing that KEY RR, the KEY RR for the key
-   used to authenticate that SIG, and so on through SIG and KEY RRs
-   until a well known trusted key is reached, perhaps the key for the
-   DNS root or some third party authentication service. (In some cases
-   these KEY RRs will actually be sets of KEY RRs with the same owner
-   and class because SIGs actually sign such record sets.)
-
-   This information could be preserved as a set of detached DNS
-   information blocks.
-
-4. IANA Considerations
-
-   Allocation of meanings to retrieval time fields with a initial byte
-   of between 0x01 and 0x1F requires an IETF consensus.
-
-5. Security Considerations
-
-   The entirety of this document concerns a means to represent detached
-   DNS information.  Such detached resource records may be security
-   relevant and/or secured information as described in [RFC 2535].  The
-   detached format provides no overall security for sets of detached
-
-
-
-Eastlake                      Experimental                      [Page 4]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-   information or for the association between retrieval time and
-   information.  This can be provided by wrapping the detached
-   information format with some other form of signature.  However, if
-   the detached information is accompanied by SIG RRs, its validity
-   period is indicated in those SIG RRs so the retrieval time might be
-   of secondary importance.
-
-References
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., " Domain Names - Implementation and
-                Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                      Experimental                      [Page 5]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                      Experimental                      [Page 6]
-
diff --git a/doc/rfc/rfc2541.txt b/doc/rfc/rfc2541.txt
deleted file mode 100644
index a62ed2b4..00000000
--- a/doc/rfc/rfc2541.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2541                                           IBM
-Category: Informational                                       March 1999
-
-
-                DNS Security Operational Considerations
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   Secure DNS is based on cryptographic techniques.  A necessary part of
-   the strength of these techniques is careful attention to the
-   operational aspects of key and signature generation, lifetime, size,
-   and storage.  In addition, special attention must be paid to the
-   security of the high level zones, particularly the root zone.  This
-   document discusses these operational aspects for keys and signatures
-   used in connection with the KEY and SIG DNS resource records.
-
-Acknowledgments
-
-   The contributions and suggestions of the following persons (in
-   alphabetic order) are gratefully acknowledged:
-
-         John Gilmore
-         Olafur Gudmundsson
-         Charlie Kaufman
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 1]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-Table of Contents
-
-   Abstract...................................................1
-   Acknowledgments............................................1
-   1. Introduction............................................2
-   2. Public/Private Key Generation...........................2
-   3. Public/Private Key Lifetimes............................2
-   4. Public/Private Key Size Considerations..................3
-   4.1 RSA Key Sizes..........................................3
-   4.2 DSS Key Sizes..........................................4
-   5. Private Key Storage.....................................4
-   6. High Level Zones, The Root Zone, and The Meta-Root Key..5
-   7. Security Considerations.................................5
-   References.................................................6
-   Author's Address...........................................6
-   Full Copyright Statement...................................7
-
-1. Introduction
-
-   This document describes operational considerations for the
-   generation, lifetime, size, and storage of DNS cryptographic keys and
-   signatures for use in the KEY and SIG resource records [RFC 2535].
-   Particular attention is paid to high level zones and the root zone.
-
-2. Public/Private Key Generation
-
-   Careful generation of all keys is a sometimes overlooked but
-   absolutely essential element in any cryptographically secure system.
-   The strongest algorithms used with the longest keys are still of no
-   use if an adversary can guess enough to lower the size of the likely
-   key space so that it can be exhaustively searched.  Technical
-   suggestions for the generation of random keys will be found in [RFC
-   1750].
-
-   Long term keys are particularly sensitive as they will represent a
-   more valuable target and be subject to attack for a longer time than
-   short period keys.  It is strongly recommended that long term key
-   generation occur off-line in a manner isolated from the network via
-   an air gap or, at a minimum, high level secure hardware.
-
-3. Public/Private Key Lifetimes
-
-   No key should be used forever.  The longer a key is in use, the
-   greater the probability that it will have been compromised through
-   carelessness, accident, espionage, or cryptanalysis.  Furthermore, if
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 2]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-   key rollover is a rare event, there is an increased risk that, when
-   the time does come to change the key, no one at the site will
-   remember how to do it or operational problems will have developed in
-   the key rollover procedures.
-
-   While public key lifetime is a matter of local policy, these
-   considerations imply that, unless there are extraordinary
-   circumstances, no long term key should have a lifetime significantly
-   over four years.  In fact, a reasonable guideline for long term keys
-   that are kept off-line and carefully guarded is a 13 month lifetime
-   with the intent that they be replaced every year.  A reasonable
-   maximum lifetime for keys that are used for transaction security or
-   the like and are kept on line is 36 days with the intent that they be
-   replaced monthly or more often.  In many cases, a key lifetime of
-   somewhat over a day may be reasonable.
-
-   On the other hand, public keys with too short a lifetime can lead to
-   excessive resource consumption in re-signing data and retrieving
-   fresh information because cached information becomes stale.  In the
-   Internet environment, almost all public keys should have lifetimes no
-   shorter than three minutes, which is a reasonable estimate of maximum
-   packet delay even in unusual circumstances.
-
-4. Public/Private Key Size Considerations
-
-   There are a number of factors that effect public key size choice for
-   use in the DNS security extension.  Unfortunately, these factors
-   usually do not all point in the same direction.  Choice of zone key
-   size should generally be made by the zone administrator depending on
-   their local conditions.
-
-   For most schemes, larger keys are more secure but slower.  In
-   addition, larger keys increase the size of the KEY and SIG RRs.  This
-   increases the chance of DNS UDP packet overflow and the possible
-   necessity for using higher overhead TCP in responses.
-
-4.1 RSA Key Sizes
-
-   Given a small public exponent, verification (the most common
-   operation) for the MD5/RSA algorithm will vary roughly with the
-   square of the modulus length, signing will vary with the cube of the
-   modulus length, and key generation (the least common operation) will
-   vary with the fourth power of the modulus length.  The current best
-   algorithms for factoring a modulus and breaking RSA security vary
-   roughly with the 1.6 power of the modulus itself.  Thus going from a
-   640 bit modulus to a 1280 bit modulus only increases the verification
-   time by a factor of 4 but may increase the work factor of breaking
-   the key by over 2^900.
-
-
-
-Eastlake                     Informational                      [Page 3]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-   The recommended minimum RSA algorithm modulus size is 704 bits which
-   is believed by the author to be secure at this time.  But high level
-   zones in the DNS tree may wish to set a higher minimum, perhaps 1000
-   bits, for security reasons.  (Since the United States National
-   Security Agency generally permits export of encryption systems using
-   an RSA modulus of up to 512 bits, use of that small a modulus, i.e.
-   n, must be considered weak.)
-
-   For an RSA key used only to secure data and not to secure other keys,
-   704 bits should be adequate at this time.
-
-4.2 DSS Key Sizes
-
-   DSS keys are probably roughly as strong as an RSA key of the same
-   length but DSS signatures are significantly smaller.
-
-5. Private Key Storage
-
-   It is recommended that, where possible, zone private keys and the
-   zone file master copy be kept and used in off-line, non-network
-   connected, physically secure machines only.  Periodically an
-   application can be run to add authentication to a zone by adding SIG
-   and NXT RRs and adding no-key type KEY RRs for subzones/algorithms
-   where a real KEY RR for the subzone with that algorithm is not
-   provided. Then the augmented file can be transferred, perhaps by
-   sneaker-net, to the networked zone primary server machine.
-
-   The idea is to have a one way information flow to the network to
-   avoid the possibility of tampering from the network.  Keeping the
-   zone master file on-line on the network and simply cycling it through
-   an off-line signer does not do this.  The on-line version could still
-   be tampered with if the host it resides on is compromised.  For
-   maximum security, the master copy of the zone file should be off net
-   and should not be updated based on an unsecured network mediated
-   communication.
-
-   This is not possible if the zone is to be dynamically updated
-   securely [RFC 2137]. At least a private key capable of updating the
-   SOA and NXT chain must be on line in that case.
-
-   Secure resolvers must be configured with some trusted on-line public
-   key information (or a secure path to such a resolver) or they will be
-   unable to authenticate.  Although on line, this public key
-   information must be protected or it could be altered so that spoofed
-   DNS data would appear authentic.
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 4]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-   Non-zone private keys, such as host or user keys, generally have to
-   be kept on line to be used for real-time purposes such as DNS
-   transaction security.
-
-6. High Level Zones, The Root Zone, and The Meta-Root Key
-
-   Higher level zones are generally more sensitive than lower level
-   zones.  Anyone controlling or breaking the security of a zone thereby
-   obtains authority over all of its subdomains (except in the case of
-   resolvers that have locally configured the public key of a
-   subdomain).  Therefore, extra care should be taken with high level
-   zones and strong keys used.
-
-   The root zone is the most critical of all zones.  Someone controlling
-   or compromising the security of the root zone would control the
-   entire DNS name space of all resolvers using that root zone (except
-   in the case of resolvers that have locally configured the public key
-   of a subdomain). Therefore, the utmost care must be taken in the
-   securing of the root zone. The strongest and most carefully handled
-   keys should be used.  The root zone private key should always be kept
-   off line.
-
-   Many resolvers will start at a root server for their access to and
-   authentication of DNS data.  Securely updating an enormous population
-   of resolvers around the world will be extremely difficult.  Yet the
-   guidelines in section 3 above would imply that the root zone private
-   key be changed annually or more often and if it were staticly
-   configured at all these resolvers, it would have to be updated when
-   changed.
-
-   To permit relatively frequent change to the root zone key yet
-   minimize exposure of the ultimate key of the DNS tree, there will be
-   a "meta-root" key used very rarely and then only to sign a sequence
-   of regular root key RRsets with overlapping time validity periods
-   that are to be rolled out. The root zone contains the meta-root and
-   current regular root KEY RR(s) signed by SIG RRs under both the
-   meta-root and other root private key(s) themselves.
-
-   The utmost security in the storage and use of the meta-root key is
-   essential.  The exact techniques are precautions to be used are
-   beyond the scope of this document.  Because of its special position,
-   it may be best to continue with the same meta-root key for an
-   extended period of time such as ten to fifteen years.
-
-7. Security Considerations
-
-   The entirety of this document is concerned with operational
-   considerations of public/private key pair DNS Security.
-
-
-
-Eastlake                     Informational                      [Page 5]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-References
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
-                Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-                Requirements for Security", RFC 1750, December 1994.
-
-   [RFC 2065]   Eastlake, D. and C. Kaufman, "Domain Name System
-                Security Extensions", RFC 2065, January 1997.
-
-   [RFC 2137]   Eastlake, D., "Secure Domain Name System Dynamic
-                Update", RFC 2137, April 1997.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RSA FAQ]    RSADSI Frequently Asked Questions periodic posting.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 6]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 7]
-
diff --git a/doc/rfc/rfc2553.txt b/doc/rfc/rfc2553.txt
deleted file mode 100644
index 6989bf30..00000000
--- a/doc/rfc/rfc2553.txt
+++ /dev/null
@@ -1,2299 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Gilligan
-Request for Comments: 2553                                      FreeGate
-Obsoletes: 2133                                               S. Thomson
-Category: Informational                                         Bellcore
-                                                                J. Bound
-                                                                  Compaq
-                                                              W. Stevens
-                                                              Consultant
-                                                              March 1999
-
-
-               Basic Socket Interface Extensions for IPv6
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   The de facto standard application program interface (API) for TCP/IP
-   applications is the "sockets" interface.  Although this API was
-   developed for Unix in the early 1980s it has also been implemented on
-   a wide variety of non-Unix systems.  TCP/IP applications written
-   using the sockets API have in the past enjoyed a high degree of
-   portability and we would like the same portability with IPv6
-   applications.  But changes are required to the sockets API to support
-   IPv6 and this memo describes these changes.  These include a new
-   socket address structure to carry IPv6 addresses, new address
-   conversion functions, and some new socket options.  These extensions
-   are designed to provide access to the basic IPv6 features required by
-   TCP and UDP applications, including multicasting, while introducing a
-   minimum of change into the system and providing complete
-   compatibility for existing IPv4 applications.  Additional extensions
-   for advanced IPv6 features (raw sockets and access to the IPv6
-   extension headers) are defined in another document [4].
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 1]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-Table of Contents
-
-   1. Introduction.................................................3
-   2. Design Considerations........................................3
-   2.1 What Needs to be Changed....................................4
-   2.2 Data Types..................................................5
-   2.3 Headers.....................................................5
-   2.4 Structures..................................................5
-   3. Socket Interface.............................................6
-   3.1 IPv6 Address Family and Protocol Family.....................6
-   3.2 IPv6 Address Structure......................................6
-   3.3 Socket Address Structure for 4.3BSD-Based Systems...........7
-   3.4 Socket Address Structure for 4.4BSD-Based Systems...........8
-   3.5 The Socket Functions........................................9
-   3.6 Compatibility with IPv4 Applications.......................10
-   3.7 Compatibility with IPv4 Nodes..............................10
-   3.8 IPv6 Wildcard Address......................................11
-   3.9 IPv6 Loopback Address......................................12
-   3.10 Portability Additions.....................................13
-   4. Interface Identification....................................16
-   4.1 Name-to-Index..............................................16
-   4.2 Index-to-Name..............................................17
-   4.3 Return All Interface Names and Indexes.....................17
-   4.4 Free Memory................................................18
-   5. Socket Options..............................................18
-   5.1 Unicast Hop Limit..........................................18
-   5.2 Sending and Receiving Multicast Packets....................19
-   6. Library Functions...........................................21
-   6.1 Nodename-to-Address Translation............................21
-   6.2 Address-To-Nodename Translation............................24
-   6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....26
-   6.4 Protocol-Independent Nodename and Service Name Translation.26
-   6.5 Socket Address Structure to Nodename and Service Name......29
-   6.6 Address Conversion Functions...............................31
-   6.7 Address Testing Macros.....................................32
-   7. Summary of New Definitions..................................33
-   8. Security Considerations.....................................35
-   9. Year 2000 Considerations....................................35
-   Changes From RFC 2133..........................................35
-   Acknowledgments................................................38
-   References.....................................................39
-   Authors' Addresses.............................................40
-   Full Copyright Statement.......................................41
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 2]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-1. Introduction
-
-   While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
-   by 128-bit addresses.  The socket interface makes the size of an IP
-   address quite visible to an application; virtually all TCP/IP
-   applications for BSD-based systems have knowledge of the size of an
-   IP address.  Those parts of the API that expose the addresses must be
-   changed to accommodate the larger IPv6 address size.  IPv6 also
-   introduces new features (e.g., traffic class and flowlabel), some of
-   which must be made visible to applications via the API.  This memo
-   defines a set of extensions to the socket interface to support the
-   larger address size and new features of IPv6.
-
-2. Design Considerations
-
-   There are a number of important considerations in designing changes
-   to this well-worn API:
-
-      - The API changes should provide both source and binary
-        compatibility for programs written to the original API.  That
-        is, existing program binaries should continue to operate when
-        run on a system supporting the new API.  In addition, existing
-        applications that are re-compiled and run on a system supporting
-        the new API should continue to operate.  Simply put, the API
-        changes for IPv6 should not break existing programs.  An
-        additonal mechanism for implementations to verify this is to
-        verify the new symbols are protected by Feature Test Macros as
-        described in IEEE Std 1003.1.  (Such Feature Test Macros are not
-        defined by this RFC.)
-
-      - The changes to the API should be as small as possible in order
-        to simplify the task of converting existing IPv4 applications to
-        IPv6.
-
-      - Where possible, applications should be able to use this API to
-        interoperate with both IPv6 and IPv4 hosts.  Applications should
-        not need to know which type of host they are communicating with.
-
-      - IPv6 addresses carried in data structures should be 64-bit
-        aligned.  This is necessary in order to obtain optimum
-        performance on 64-bit machine architectures.
-
-   Because of the importance of providing IPv4 compatibility in the API,
-   these extensions are explicitly designed to operate on machines that
-   provide complete support for both IPv4 and IPv6.  A subset of this
-   API could probably be designed for operation on systems that support
-   only IPv6.  However, this is not addressed in this memo.
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 3]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-2.1 What Needs to be Changed
-
-   The socket interface API consists of a few distinct components:
-
-      -  Core socket functions.
-
-      -  Address data structures.
-
-      -  Name-to-address translation functions.
-
-      -  Address conversion functions.
-
-   The core socket functions -- those functions that deal with such
-   things as setting up and tearing down TCP connections, and sending
-   and receiving UDP packets -- were designed to be transport
-   independent.  Where protocol addresses are passed as function
-   arguments, they are carried via opaque pointers.  A protocol-specific
-   address data structure is defined for each protocol that the socket
-   functions support.  Applications must cast pointers to these
-   protocol-specific address structures into pointers to the generic
-   "sockaddr" address structure when using the socket functions.  These
-   functions need not change for IPv6, but a new IPv6-specific address
-   data structure is needed.
-
-   The "sockaddr_in" structure is the protocol-specific data structure
-   for IPv4.  This data structure actually includes 8-octets of unused
-   space, and it is tempting to try to use this space to adapt the
-   sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
-   structure is not large enough to hold the 16-octet IPv6 address as
-   well as the other information (address family and port number) that
-   is needed.  So a new address data structure must be defined for IPv6.
-
-   IPv6 addresses are scoped [2] so they could be link-local, site,
-   organization, global, or other scopes at this time undefined.  To
-   support applications that want to be able to identify a set of
-   interfaces for a specific scope, the IPv6 sockaddr_in structure must
-   support a field that can be used by an implementation to identify a
-   set of interfaces identifying the scope for an IPv6 address.
-
-   The name-to-address translation functions in the socket interface are
-   gethostbyname() and gethostbyaddr().  These are left as is and new
-   functions are defined to support IPv4 and IPv6.  Additionally, the
-   POSIX 1003.g draft [3] specifies a new nodename-to-address
-   translation function which is protocol independent.  This function
-   can also be used with IPv4 and IPv6.
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 4]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The address conversion functions -- inet_ntoa() and inet_addr() --
-   convert IPv4 addresses between binary and printable form.  These
-   functions are quite specific to 32-bit IPv4 addresses.  We have
-   designed two analogous functions that convert both IPv4 and IPv6
-   addresses, and carry an address type parameter so that they can be
-   extended to other protocol families as well.
-
-   Finally, a few miscellaneous features are needed to support IPv6.
-   New interfaces are needed to support the IPv6 traffic class, flow
-   label, and hop limit header fields.  New socket options are needed to
-   control the sending and receiving of IPv6 multicast packets.
-
-   The socket interface will be enhanced in the future to provide access
-   to other IPv6 features.  These extensions are described in [4].
-
-2.2 Data Types
-
-   The data types of the structure elements given in this memo are
-   intended to be examples, not absolute requirements.  Whenever
-   possible, data types from Draft 6.6 (March 1997) of POSIX 1003.1g are
-   used: uintN_t means an unsigned integer of exactly N bits (e.g.,
-   uint16_t).  We also assume the argument data types from 1003.1g when
-   possible (e.g., the final argument to setsockopt() is a size_t
-   value).  Whenever buffer sizes are specified, the POSIX 1003.1 size_t
-   data type is used (e.g., the two length arguments to getnameinfo()).
-
-2.3 Headers
-
-   When function prototypes and structures are shown we show the headers
-   that must be #included to cause that item to be defined.
-
-2.4 Structures
-
-   When structures are described the members shown are the ones that
-   must appear in an implementation.  Additional, nonstandard members
-   may also be defined by an implementation.  As an additional
-   precaution nonstandard members could be verified by Feature Test
-   Macros as described in IEEE Std 1003.1.  (Such Feature Test Macros
-   are not defined by this RFC.)
-
-   The ordering shown for the members of a structure is the recommended
-   ordering, given alignment considerations of multibyte members, but an
-   implementation may order the members differently.
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 5]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-3. Socket Interface
-
-   This section specifies the socket interface changes for IPv6.
-
-3.1 IPv6 Address Family and Protocol Family
-
-   A new address family name, AF_INET6, is defined in <sys/socket.h>.
-   The AF_INET6 definition distinguishes between the original
-   sockaddr_in address data structure, and the new sockaddr_in6 data
-   structure.
-
-   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
-   Like most of the other protocol family names, this will usually be
-   defined to have the same value as the corresponding address family
-   name:
-
-      #define PF_INET6        AF_INET6
-
-   The PF_INET6 is used in the first argument to the socket() function
-   to indicate that an IPv6 socket is being created.
-
-3.2 IPv6 Address Structure
-
-   A new in6_addr structure holds a single IPv6 address and is defined
-   as a result of including <netinet/in.h>:
-
-      struct in6_addr {
-          uint8_t  s6_addr[16];      /* IPv6 address */
-      };
-
-   This data structure contains an array of sixteen 8-bit elements,
-   which make up one 128-bit IPv6 address.  The IPv6 address is stored
-   in network byte order.
-
-   The structure in6_addr above is usually implemented with an embedded
-   union with extra fields that force the desired alignment level in a
-   manner similar to BSD implementations of "struct in_addr". Those
-   additional implementation details are omitted here for simplicity.
-
-   An example is as follows:
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 6]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   struct in6_addr {
-        union {
-            uint8_t  _S6_u8[16];
-            uint32_t _S6_u32[4];
-            uint64_t _S6_u64[2];
-        } _S6_un;
-   };
-   #define s6_addr _S6_un._S6_u8
-
-3.3 Socket Address Structure for 4.3BSD-Based Systems
-
-   In the socket interface, a different protocol-specific data structure
-   is defined to carry the addresses for each protocol suite.  Each
-   protocol- specific data structure is designed so it can be cast into a
-   protocol- independent data structure -- the "sockaddr" structure.
-   Each has a "family" field that overlays the "sa_family" of the
-   sockaddr data structure.  This field identifies the type of the data
-   structure.
-
-   The sockaddr_in structure is the protocol-specific address data
-   structure for IPv4.  It is used to pass addresses between applications
-   and the system in the socket functions.  The following sockaddr_in6
-   structure holds IPv6 addresses and is defined as a result of including
-   the <netinet/in.h> header:
-
-struct sockaddr_in6 {
-    sa_family_t     sin6_family;    /* AF_INET6 */
-    in_port_t       sin6_port;      /* transport layer port # */
-    uint32_t        sin6_flowinfo;  /* IPv6 traffic class & flow info */
-    struct in6_addr sin6_addr;      /* IPv6 address */
-    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
-};
-
-   This structure is designed to be compatible with the sockaddr data
-   structure used in the 4.3BSD release.
-
-   The sin6_family field identifies this as a sockaddr_in6 structure.
-   This field overlays the sa_family field when the buffer is cast to a
-   sockaddr data structure.  The value of this field must be AF_INET6.
-
-   The sin6_port field contains the 16-bit UDP or TCP port number.  This
-   field is used in the same way as the sin_port field of the
-   sockaddr_in structure.  The port number is stored in network byte
-   order.
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 7]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The sin6_flowinfo field is a 32-bit field that contains two pieces of
-   information: the traffic class and the flow label.  The contents and
-   interpretation of this member is specified in [1].  The sin6_flowinfo
-   field SHOULD be set to zero by an implementation prior to using the
-   sockaddr_in6 structure by an application on receive operations.
-
-   The sin6_addr field is a single in6_addr structure (defined in the
-   previous section).  This field holds one 128-bit IPv6 address.  The
-   address is stored in network byte order.
-
-   The ordering of elements in this structure is specifically designed
-   so that when sin6_addr field is aligned on a 64-bit boundary, the
-   start of the structure will also be aligned on a 64-bit boundary.
-   This is done for optimum performance on 64-bit architectures.
-
-   The sin6_scope_id field is a 32-bit integer that identifies a set of
-   interfaces as appropriate for the scope of the address carried in the
-   sin6_addr field.  For a link scope sin6_addr sin6_scope_id would be
-   an interface index.  For a site scope sin6_addr, sin6_scope_id would
-   be a site identifier.  The mapping of sin6_scope_id to an interface
-   or set of interfaces is left to implementation and future
-   specifications on the subject of site identifiers.
-
-   Notice that the sockaddr_in6 structure will normally be larger than
-   the generic sockaddr structure.  On many existing implementations the
-   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
-   being 16 bytes.  Any existing code that makes this assumption needs
-   to be examined carefully when converting to IPv6.
-
-3.4 Socket Address Structure for 4.4BSD-Based Systems
-
-   The 4.4BSD release includes a small, but incompatible change to the
-   socket interface.  The "sa_family" field of the sockaddr data
-   structure was changed from a 16-bit value to an 8-bit value, and the
-   space saved used to hold a length field, named "sa_len".  The
-   sockaddr_in6 data structure given in the previous section cannot be
-   correctly cast into the newer sockaddr data structure.  For this
-   reason, the following alternative IPv6 address data structure is
-   provided to be used on systems based on 4.4BSD.  It is defined as a
-   result of including the <netinet/in.h> header.
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 8]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-struct sockaddr_in6 {
-    uint8_t         sin6_len;       /* length of this struct */
-    sa_family_t     sin6_family;    /* AF_INET6 */
-    in_port_t       sin6_port;      /* transport layer port # */
-    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
-    struct in6_addr sin6_addr;      /* IPv6 address */
-    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
-};
-
-   The only differences between this data structure and the 4.3BSD
-   variant are the inclusion of the length field, and the change of the
-   family field to a 8-bit data type.  The definitions of all the other
-   fields are identical to the structure defined in the previous
-   section.
-
-   Systems that provide this version of the sockaddr_in6 data structure
-   must also declare SIN6_LEN as a result of including the
-   <netinet/in.h> header.  This macro allows applications to determine
-   whether they are being built on a system that supports the 4.3BSD or
-   4.4BSD variants of the data structure.
-
-3.5 The Socket Functions
-
-   Applications call the socket() function to create a socket descriptor
-   that represents a communication endpoint.  The arguments to the
-   socket() function tell the system which protocol to use, and what
-   format address structure will be used in subsequent functions.  For
-   example, to create an IPv4/TCP socket, applications make the call:
-
-      s = socket(PF_INET, SOCK_STREAM, 0);
-
-   To create an IPv4/UDP socket, applications make the call:
-
-      s = socket(PF_INET, SOCK_DGRAM, 0);
-
-   Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
-   the constant PF_INET6 instead of PF_INET in the first argument.  For
-   example, to create an IPv6/TCP socket, applications make the call:
-
-      s = socket(PF_INET6, SOCK_STREAM, 0);
-
-   To create an IPv6/UDP socket, applications make the call:
-
-      s = socket(PF_INET6, SOCK_DGRAM, 0);
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 9]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   Once the application has created a PF_INET6 socket, it must use the
-   sockaddr_in6 address structure when passing addresses in to the
-   system.  The functions that the application uses to pass addresses
-   into the system are:
-
-      bind()
-      connect()
-      sendmsg()
-      sendto()
-
-   The system will use the sockaddr_in6 address structure to return
-   addresses to applications that are using PF_INET6 sockets.  The
-   functions that return an address from the system to an application
-   are:
-
-      accept()
-      recvfrom()
-      recvmsg()
-      getpeername()
-      getsockname()
-
-   No changes to the syntax of the socket functions are needed to
-   support IPv6, since all of the "address carrying" functions use an
-   opaque address pointer, and carry an address length as a function
-   argument.
-
-3.6 Compatibility with IPv4 Applications
-
-   In order to support the large base of applications using the original
-   API, system implementations must provide complete source and binary
-   compatibility with the original API.  This means that systems must
-   continue to support PF_INET sockets and the sockaddr_in address
-   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
-   sockets using the PF_INET constant in the socket() function, as
-   described in the previous section.  Applications should be able to
-   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
-   sockets simultaneously within the same process.
-
-   Applications using the original API should continue to operate as
-   they did on systems supporting only IPv4.  That is, they should
-   continue to interoperate with IPv4 nodes.
-
-3.7 Compatibility with IPv4 Nodes
-
-   The API also provides a different type of compatibility: the ability
-   for IPv6 applications to interoperate with IPv4 applications.  This
-   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
-   addressing architecture specification [2].  This address format
-
-
-
-Gilligan, et. al.            Informational                     [Page 10]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   allows the IPv4 address of an IPv4 node to be represented as an IPv6
-   address.  The IPv4 address is encoded into the low-order 32 bits of
-   the IPv6 address, and the high-order 96 bits hold the fixed prefix
-   0:0:0:0:0:FFFF.  IPv4- mapped addresses are written as follows:
-
-      ::FFFF:<IPv4-address>
-
-   These addresses can be generated automatically by the
-   getipnodebyname() function when the specified host has only IPv4
-   addresses (as described in Section 6.1).
-
-   Applications may use PF_INET6 sockets to open TCP connections to IPv4
-   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
-   destination's IPv4 address as an IPv4-mapped IPv6 address, and
-   passing that address, within a sockaddr_in6 structure, in the
-   connect() or sendto() call.  When applications use PF_INET6 sockets
-   to accept TCP connections from IPv4 nodes, or receive UDP packets
-   from IPv4 nodes, the system returns the peer's address to the
-   application in the accept(), recvfrom(), or getpeername() call using
-   a sockaddr_in6 structure encoded this way.
-
-   Few applications will likely need to know which type of node they are
-   interoperating with.  However, for those applications that do need to
-   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is
-   provided.
-
-3.8 IPv6 Wildcard Address
-
-   While the bind() function allows applications to select the source IP
-   address of UDP packets and TCP connections, applications often want
-   the system to select the source address for them.  With IPv4, one
-   specifies the address as the symbolic constant INADDR_ANY (called the
-   "wildcard" address) in the bind() call, or simply omits the bind()
-   entirely.
-
-   Since the IPv6 address type is a structure (struct in6_addr), a
-   symbolic constant can be used to initialize an IPv6 address variable,
-   but cannot be used in an assignment.  Therefore systems provide the
-   IPv6 wildcard address in two forms.
-
-   The first version is a global variable named "in6addr_any" that is an
-   in6_addr structure.  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-      extern const struct in6_addr in6addr_any;
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 11]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   Applications use in6addr_any similarly to the way they use INADDR_ANY
-   in IPv4.  For example, to bind a socket to port number 23, but let
-   the system select the source address, an application could use the
-   following code:
-
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_family = AF_INET6;
-      sin6.sin6_flowinfo = 0;
-      sin6.sin6_port = htons(23);
-      sin6.sin6_addr = in6addr_any;  /* structure assignment */
-       . . .
-      if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-              . . .
-
-   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
-   is defined in <netinet/in.h>.  This constant can be used to
-   initialize an in6_addr structure:
-
-      struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
-   Note that this constant can be used ONLY at declaration time.  It can
-   not be used to assign a previously declared in6_addr structure.  For
-   example, the following code will not work:
-
-      /* This is the WRONG way to assign an unspecified address */
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
-   Be aware that the IPv4 INADDR_xxx constants are all defined in host
-   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
-   in6addr_xxx externals are defined in network byte order.
-
-3.9 IPv6 Loopback Address
-
-   Applications may need to send UDP packets to, or originate TCP
-   connections to, services residing on the local node.  In IPv4, they
-   can do this by using the constant IPv4 address INADDR_LOOPBACK in
-   their connect(), sendto(), or sendmsg() call.
-
-   IPv6 also provides a loopback address to contact local TCP and UDP
-   services.  Like the unspecified address, the IPv6 loopback address is
-   provided in two forms -- a global variable and a symbolic constant.
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 12]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The global variable is an in6_addr structure named
-   "in6addr_loopback."  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-      extern const struct in6_addr in6addr_loopback;
-
-   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
-   in IPv4 applications (but beware of the byte ordering difference
-   mentioned at the end of the previous section).  For example, to open
-   a TCP connection to the local telnet server, an application could use
-   the following code:
-
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_family = AF_INET6;
-      sin6.sin6_flowinfo = 0;
-      sin6.sin6_port = htons(23);
-      sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
-       . . .
-      if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-              . . .
-
-   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
-   in <netinet/in.h>.  It can be used at declaration time ONLY; for
-   example:
-
-      struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
-   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
-   to a previously declared IPv6 address variable.
-
-3.10 Portability Additions
-
-   One simple addition to the sockets API that can help application
-   writers is the "struct sockaddr_storage". This data structure can
-   simplify writing code portable across multiple address families and
-   platforms.  This data structure is designed with the following goals.
-
-      - It has a large enough implementation specific maximum size to
-        store the desired set of protocol specific socket address data
-        structures. Specifically, it is at least large enough to
-        accommodate sockaddr_in and sockaddr_in6 and possibly other
-        protocol specific socket addresses too.
-      - It is aligned at an appropriate boundary so protocol specific
-        socket address data structure pointers can be cast to it and
-        access their fields without alignment problems. (e.g. pointers
-        to sockaddr_in6 and/or sockaddr_in can be cast to it and access
-        fields without alignment problems).
-
-
-
-Gilligan, et. al.            Informational                     [Page 13]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      - It has the initial field(s) isomorphic to the fields of the
-        "struct sockaddr" data structure on that implementation which
-        can be used as a discriminants for deriving the protocol in use.
-        These initial field(s) would on most implementations either be a
-        single field of type "sa_family_t" (isomorphic to sa_family
-        field, 16 bits) or two fields of type uint8_t and sa_family_t
-        respectively, (isomorphic to sa_len and sa_family_t, 8 bits
-        each).
-
-   An example implementation design of such a data structure would be as
-   follows.
-
-/*
- * Desired design of maximum size and alignment
- */
-#define _SS_MAXSIZE    128  /* Implementation specific max size */
-#define _SS_ALIGNSIZE  (sizeof (int64_t))
-                         /* Implementation specific desired alignment */
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE   (_SS_ALIGNSIZE - sizeof (sa_family_t))
-#define _SS_PAD2SIZE   (_SS_MAXSIZE - (sizeof (sa_family_t)+
-                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
-    sa_family_t  __ss_family;     /* address family */
-    /* Following fields are implementation specific */
-    char      __ss_pad1[_SS_PAD1SIZE];
-              /* 6 byte pad, this is to make implementation
-              /* specific pad up to alignment field that */
-              /* follows explicit in the data structure */
-    int64_t   __ss_align;     /* field to force desired structure */
-               /* storage alignment */
-    char      __ss_pad2[_SS_PAD2SIZE];
-              /* 112 byte pad to achieve desired size, */
-              /* _SS_MAXSIZE value minus size of ss_family */
-              /* __ss_pad1, __ss_align fields is 112 */
-};
-
-   On implementations where sockaddr data structure includes a "sa_len",
-   field this data structure would look like this:
-
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
-                            (sizeof (uint8_t) + sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+
-
-
-
-Gilligan, et. al.            Informational                     [Page 14]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
-    uint8_t      __ss_len;        /* address length */
-    sa_family_t  __ss_family;     /* address family */
-    /* Following fields are implementation specific */
-    char         __ss_pad1[_SS_PAD1SIZE];
-                  /* 6 byte pad, this is to make implementation
-                  /* specific pad up to alignment field that */
-                  /* follows explicit in the data structure */
-    int64_t      __ss_align;  /* field to force desired structure */
-                  /* storage alignment */
-    char         __ss_pad2[_SS_PAD2SIZE];
-                  /* 112 byte pad to achieve desired size, */
-                  /* _SS_MAXSIZE value minus size of ss_len, */
-                  /* __ss_family, __ss_pad1, __ss_align fields is 112 */
-};
-
-   The above example implementation illustrates a data structure which
-   will align on a 64 bit boundary. An implementation specific field
-   "__ss_align" along "__ss_pad1" is used to force a 64-bit alignment
-   which covers proper alignment good enough for needs of sockaddr_in6
-   (IPv6), sockaddr_in (IPv4) address data structures.  The size of
-   padding fields __ss_pad1 depends on the chosen alignment boundary.
-   The size of padding field __ss_pad2 depends on the value of overall
-   size chosen for the total size of the structure. This size and
-   alignment are represented in the above example by implementation
-   specific (not required) constants _SS_MAXSIZE (chosen value 128) and
-   _SS_ALIGNMENT (with chosen value 8).  Constants _SS_PAD1SIZE (derived
-   value 6) and _SS_PAD2SIZE (derived value 112) are also for
-   illustration and not required.  The implementation specific
-   definitions and structure field names above start with an underscore
-   to denote implementation private namespace.  Portable code is not
-   expected to access or reference those fields or constants.
-
-   The sockaddr_storage structure solves the problem of declaring
-   storage for automatic variables which is large enough and aligned
-   enough for storing socket address data structure of any family. For
-   example, code with a file descriptor and without the context of the
-   address family can pass a pointer to a variable of this type where a
-   pointer to a socket address structure is expected in calls such as
-   getpeername() and determine the address family by accessing the
-   received content after the call.
-
-   The sockaddr_storage structure may also be useful and applied to
-   certain other interfaces where a generic socket address large enough
-   and aligned for use with multiple address families may be needed. A
-   discussion of those interfaces is outside the scope of this document.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 15]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   Also, much existing code assumes that any socket address structure
-   can fit in a generic sockaddr structure.  While this has been true
-   for IPv4 socket address structures, it has always been false for Unix
-   domain socket address structures (but in practice this has not been a
-   problem) and it is also false for IPv6 socket address structures
-   (which can be a problem).
-
-   So now an application can do the following:
-
-      struct sockaddr_storage __ss;
-      struct sockaddr_in6 *sin6;
-      sin6 = (struct sockaddr_in6 *) &__ss;
-
-4. Interface Identification
-
-   This API uses an interface index (a small positive integer) to
-   identify the local interface on which a multicast group is joined
-   (Section 5.3).  Additionally, the advanced API [4] uses these same
-   interface indexes to identify the interface on which a datagram is
-   received, or to specify the interface on which a datagram is to be
-   sent.
-
-   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
-   and the like.  On Berkeley-derived implementations, when an interface
-   is made known to the system, the kernel assigns a unique positive
-   integer value (called the interface index) to that interface.  These
-   are small positive integers that start at 1.  (Note that 0 is never
-   used for an interface index.) There may be gaps so that there is no
-   current interface for a particular positive interface index.
-
-   This API defines two functions that map between an interface name and
-   index, a third function that returns all the interface names and
-   indexes, and a fourth function to return the dynamic memory allocated
-   by the previous function.  How these functions are implemented is
-   left up to the implementation.  4.4BSD implementations can implement
-   these functions using the existing sysctl() function with the
-   NET_RT_IFLIST command.  Other implementations may wish to use ioctl()
-   for this purpose.
-
-4.1 Name-to-Index
-
-   The first function maps an interface name into its corresponding
-   index.
-
-      #include <net/if.h>
-
-      unsigned int  if_nametoindex(const char *ifname);
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 16]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   If the specified interface name does not exist, the return value is
-   0, and errno is set to ENXIO.  If there was a system error (such as
-   running out of memory), the return value is 0 and errno is set to the
-   proper value (e.g., ENOMEM).
-
-4.2 Index-to-Name
-
-   The second function maps an interface index into its corresponding
-   name.
-
-      #include <net/if.h>
-
-      char  *if_indextoname(unsigned int ifindex, char *ifname);
-
-   The ifname argument must point to a buffer of at least IF_NAMESIZE
-   bytes into which the interface name corresponding to the specified
-   index is returned.  (IF_NAMESIZE is also defined in <net/if.h> and
-   its value includes a terminating null byte at the end of the
-   interface name.) This pointer is also the return value of the
-   function.  If there is no interface corresponding to the specified
-   index, NULL is returned, and errno is set to ENXIO, if there was a
-   system error (such as running out of memory), if_indextoname returns
-   NULL and errno would be set to the proper value (e.g., ENOMEM).
-
-4.3 Return All Interface Names and Indexes
-
-   The if_nameindex structure holds the information about a single
-   interface and is defined as a result of including the <net/if.h>
-   header.
-
-      struct if_nameindex {
-        unsigned int   if_index;  /* 1, 2, ... */
-        char          *if_name;   /* null terminated name: "le0", ... */
-      };
-
-   The final function returns an array of if_nameindex structures, one
-   structure per interface.
-
-      struct if_nameindex  *if_nameindex(void);
-
-   The end of the array of structures is indicated by a structure with
-   an if_index of 0 and an if_name of NULL.  The function returns a NULL
-   pointer upon an error, and would set errno to the appropriate value.
-
-   The memory used for this array of structures along with the interface
-   names pointed to by the if_name members is obtained dynamically.
-   This memory is freed by the next function.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 17]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-4.4 Free Memory
-
-   The following function frees the dynamic memory that was allocated by
-   if_nameindex().
-
-      #include <net/if.h>
-
-      void  if_freenameindex(struct if_nameindex *ptr);
-
-   The argument to this function must be a pointer that was returned by
-   if_nameindex().
-
-   Currently net/if.h doesn't have prototype definitions for functions
-   and it is recommended that these definitions be defined in net/if.h
-   as well and the struct if_nameindex{}.
-
-5. Socket Options
-
-   A number of new socket options are defined for IPv6.  All of these
-   new options are at the IPPROTO_IPV6 level.  That is, the "level"
-   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
-   when using these options.  The constant name prefix IPV6_ is used in
-   all of the new socket options.  This serves to clearly identify these
-   options as applying to IPv6.
-
-   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
-   related constants defined in this section are obtained by including
-   the header <netinet/in.h>.
-
-5.1 Unicast Hop Limit
-
-   A new setsockopt() option controls the hop limit used in outgoing
-   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
-   and it is used at the IPPROTO_IPV6 layer.  The following example
-   illustrates how it is used:
-
-      int  hoplimit = 10;
-
-      if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                     (char *) &hoplimit, sizeof(hoplimit)) == -1)
-          perror("setsockopt IPV6_UNICAST_HOPS");
-
-   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
-   option value given is used as the hop limit for all subsequent
-   unicast packets sent via that socket.  If the option is not set, the
-   system selects a default value.  The integer hop limit value (called
-   x) is interpreted as follows:
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 18]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      x < -1:        return an error of EINVAL
-      x == -1:       use kernel default
-      0 <= x <= 255: use x
-      x >= 256:      return an error of EINVAL
-
-   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
-   determine the hop limit value that the system will use for subsequent
-   unicast packets sent via that socket.  For example:
-
-      int  hoplimit;
-      size_t  len = sizeof(hoplimit);
-
-      if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                     (char *) &hoplimit, &len) == -1)
-          perror("getsockopt IPV6_UNICAST_HOPS");
-      else
-          printf("Using %d for hop limit.\n", hoplimit);
-
-5.2 Sending and Receiving Multicast Packets
-
-   IPv6 applications may send UDP multicast packets by simply specifying
-   an IPv6 multicast address in the address argument of the sendto()
-   function.
-
-   Three socket options at the IPPROTO_IPV6 layer control some of the
-   parameters for sending multicast packets.  Setting these options is
-   not required: applications may send multicast packets without using
-   these options.  The setsockopt() options for controlling the sending
-   of multicast packets are summarized below.  These three options can
-   also be used with getsockopt().
-
-      IPV6_MULTICAST_IF
-
-         Set the interface to use for outgoing multicast packets.  The
-         argument is the index of the interface to use.
-
-         Argument type: unsigned int
-
-      IPV6_MULTICAST_HOPS
-
-         Set the hop limit to use for outgoing multicast packets.  (Note
-         a separate option - IPV6_UNICAST_HOPS - is provided to set the
-         hop limit to use for outgoing unicast packets.)
-
-         The interpretation of the argument is the same as for the
-         IPV6_UNICAST_HOPS option:
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 19]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-           x < -1:        return an error of EINVAL
-           x == -1:       use kernel default
-           0 <= x <= 255: use x
-           x >= 256:      return an error of EINVAL
-
-           If IPV6_MULTICAST_HOPS is not set, the default is 1
-           (same as IPv4 today)
-
-         Argument type: int
-
-      IPV6_MULTICAST_LOOP
-
-         If a multicast datagram is sent to a group to which the sending
-         host itself belongs (on the outgoing interface), a copy of the
-         datagram is looped back by the IP layer for local delivery if
-         this option is set to 1.  If this option is set to 0 a copy
-         is not looped back.  Other option values return an error of
-         EINVAL.
-
-         If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
-         same as IPv4 today).
-
-         Argument type: unsigned int
-
-   The reception of multicast packets is controlled by the two
-   setsockopt() options summarized below.  An error of EOPNOTSUPP is
-   returned if these two options are used with getsockopt().
-
-      IPV6_JOIN_GROUP
-
-         Join a multicast group on a specified local interface.  If the
-         interface index is specified as 0, the kernel chooses the local
-         interface.  For example, some kernels look up the multicast
-         group in the normal IPv6 routing table and using the resulting
-         interface.
-
-         Argument type: struct ipv6_mreq
-
-      IPV6_LEAVE_GROUP
-
-         Leave a multicast group on a specified interface.
-
-         Argument type: struct ipv6_mreq
-
-   The argument type of both of these options is the ipv6_mreq structure,
-   defined as a result of including the <netinet/in.h> header;
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 20]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   struct ipv6_mreq {
-       struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
-       unsigned int    ipv6mr_interface; /* interface index */
-   };
-
-   Note that to receive multicast datagrams a process must join the
-   multicast group and bind the UDP port to which datagrams will be
-   sent.  Some processes also bind the multicast group address to the
-   socket, in addition to the port, to prevent other datagrams destined
-   to that same port from being delivered to the socket.
-
-6. Library Functions
-
-   New library functions are needed to perform a variety of operations
-   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
-   in the Domain Name System (DNS).  Both forward lookup (nodename-to-
-   address translation) and reverse lookup (address-to-nodename
-   translation) need to be supported.  Functions are also needed to
-   convert IPv6 addresses between their binary and textual form.
-
-   We note that the two existing functions, gethostbyname() and
-   gethostbyaddr(), are left as-is.  New functions are defined to handle
-   both IPv4 and IPv6 addresses.
-
-6.1 Nodename-to-Address Translation
-
-   The commonly used function gethostbyname() is inadequate for many
-   applications, first because it provides no way for the caller to
-   specify anything about the types of addresses desired (IPv4 only,
-   IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
-   implementations of this function are not thread safe.  RFC 2133
-   defined a function named gethostbyname2() but this function was also
-   inadequate, first because its use required setting a global option
-   (RES_USE_INET6) when IPv6 addresses were required, and second because
-   a flag argument is needed to provide the caller with additional
-   control over the types of addresses required.
-
-   The following function is new and must be thread safe:
-
-   #include <sys/socket.h>
-   #include <netdb.h>
-
-   struct hostent *getipnodebyname(const char *name, int af, int flags
-                                       int *error_num);
-
-   The name argument can be either a node name or a numeric address
-   string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address).
-   The af argument specifies the address family, either AF_INET or
-
-
-
-Gilligan, et. al.            Informational                     [Page 21]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   AF_INET6. The error_num value is returned to the caller, via a
-   pointer, with the appropriate error code in error_num, to support
-   thread safe error code returns.  error_num will be set to one of the
-   following values:
-
-      HOST_NOT_FOUND
-
-         No such host is known.
-
-      NO_ADDRESS
-
-         The server recognised the request and the name but no address is
-         available.  Another type of request to the name server for the
-         domain might return an answer.
-
-      NO_RECOVERY
-
-         An unexpected server failure occurred which cannot be recovered.
-
-      TRY_AGAIN
-
-         A temporary and possibly transient error occurred, such as a
-         failure of a server to respond.
-
-   The flags argument specifies the types of addresses that are searched
-   for, and the types of addresses that are returned.  We note that a
-   special flags value of AI_DEFAULT (defined below) should handle most
-   applications.
-
-   That is, porting simple applications to use IPv6 replaces the call
-
-      hptr = gethostbyname(name);
-
-   with
-
-      hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num);
-
-   and changes any subsequent error diagnosis code to use error_num
-   instead of externally declared variables, such as h_errno.
-
-   Applications desiring finer control over the types of addresses
-   searched for and returned, can specify other combinations of the
-   flags argument.
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 22]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   A flags of 0 implies a strict interpretation of the af argument:
-
-      - If flags is 0 and af is AF_INET, then the caller wants only
-        IPv4 addresses.  A query is made for A records.  If successful,
-        the IPv4 addresses are returned and the h_length member of the
-        hostent structure will be 4, else the function returns a NULL
-        pointer.
-
-      -  If flags is 0 and if af is AF_INET6, then the caller wants only
-        IPv6 addresses.  A query is made for AAAA records.  If
-        successful, the IPv6 addresses are returned and the h_length
-        member of the hostent structure will be 16, else the function
-        returns a NULL pointer.
-
-   Other constants can be logically-ORed into the flags argument, to
-   modify the behavior of the function.
-
-      - If the AI_V4MAPPED flag is specified along with an af of
-        AF_INET6, then the caller will accept IPv4-mapped IPv6
-        addresses.  That is, if no AAAA records are found then a query
-        is made for A records and any found are returned as IPv4-mapped
-        IPv6 addresses (h_length will be 16).  The AI_V4MAPPED flag is
-        ignored unless af equals AF_INET6.
-
-      - The AI_ALL flag is used in conjunction with the AI_V4MAPPED
-        flag, and is only used with the IPv6 address family.  When AI_ALL
-        is logically or'd with AI_V4MAPPED flag then the caller wants
-        all addresses: IPv6 and IPv4-mapped IPv6.  A query is first made
-        for AAAA records and if successful, the IPv6 addresses are
-        returned. Another query is then made for A records and any found
-        are returned as IPv4-mapped IPv6 addresses. h_length will be 16.
-        Only if both queries fail does the function return a NULL pointer.
-        This flag is ignored unless af equals AF_INET6.
-
-      - The AI_ADDRCONFIG flag specifies that a query for AAAA records
-        should occur only if the node has at least one IPv6 source
-        address configured and a query for A records should occur only
-        if the node has at least one IPv4 source address configured.
-
-        For example, if the node has no IPv6 source addresses
-        configured, and af equals AF_INET6, and the node name being
-        looked up has both AAAA and A records, then:
-
-            (a) if only AI_ADDRCONFIG is specified, the function
-                returns a NULL pointer;
-            (b) if AI_ADDRCONFIG | AI_V4MAPPED is specified, the A
-                records are returned as IPv4-mapped IPv6 addresses;
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 23]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The special flags value of AI_DEFAULT is defined as
-
-      #define  AI_DEFAULT  (AI_V4MAPPED | AI_ADDRCONFIG)
-
-   We noted that the getipnodebyname() function must allow the name
-   argument to be either a node name or a literal address string (i.e.,
-   a dotted-decimal IPv4 address or an IPv6 hex address).  This saves
-   applications from having to call inet_pton() to handle literal
-   address strings.
-
-   There are four scenarios based on the type of literal address string
-   and the value of the af argument.
-
-   The two simple cases are:
-
-   When name is a dotted-decimal IPv4 address and af equals AF_INET, or
-   when name is an IPv6 hex address and af equals AF_INET6.  The members
-   of the returned hostent structure are: h_name points to a copy of the
-   name argument, h_aliases is a NULL pointer, h_addrtype is a copy of
-   the af argument, h_length is either 4 (for AF_INET) or 16 (for
-   AF_INET6), h_addr_list[0] is a pointer to the 4-byte or 16-byte
-   binary address, and h_addr_list[1] is a NULL pointer.
-
-   When name is a dotted-decimal IPv4 address and af equals AF_INET6,
-   and flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is
-   returned:  h_name points to an IPv6 hex address containing the IPv4-
-   mapped IPv6 address, h_aliases is a NULL pointer, h_addrtype is
-   AF_INET6, h_length is 16, h_addr_list[0] is a pointer to the 16-byte
-   binary address, and h_addr_list[1] is a NULL pointer.  If AI_V4MAPPED
-   is set (with or without AI_ALL) return IPv4-mapped otherwise return
-   NULL.
-
-   It is an error when name is an IPv6 hex address and af equals
-   AF_INET.  The function's return value is a NULL pointer and error_num
-   equals HOST_NOT_FOUND.
-
-6.2 Address-To-Nodename Translation
-
-   The following function has the same arguments as the existing
-   gethostbyaddr() function, but adds an error number.
-
-      #include <sys/socket.h> #include <netdb.h>
-
-      struct hostent *getipnodebyaddr(const void *src, size_t len,
-                                          int af, int *error_num);
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 24]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   As with getipnodebyname(), getipnodebyaddr() must be thread safe.
-   The error_num value is returned to the caller with the appropriate
-   error code, to support thread safe error code returns.  The following
-   error conditions may be returned for error_num:
-
-      HOST_NOT_FOUND
-
-         No such host is known.
-
-      NO_ADDRESS
-
-         The server recognized the request and the name but no address
-         is available.  Another type of request to the name server for
-         the domain might return an answer.
-
-      NO_RECOVERY
-
-         An unexpected server failure occurred which cannot be
-         recovered.
-
-      TRY_AGAIN
-
-         A temporary and possibly transient error occurred, such as a
-         failure of a server to respond.
-
-   One possible source of confusion is the handling of IPv4-mapped IPv6
-   addresses and IPv4-compatible IPv6 addresses, but the following logic
-   should apply.
-
-      1.  If af is AF_INET6, and if len equals 16, and if the IPv6
-          address is an IPv4-mapped IPv6 address or an IPv4-compatible
-          IPv6 address, then skip over the first 12 bytes of the IPv6
-          address, set af to AF_INET, and set len to 4.
-
-      2.  If af is AF_INET, lookup the name for the given IPv4 address
-          (e.g., query for a PTR record in the in-addr.arpa domain).
-
-      3.  If af is AF_INET6, lookup the name for the given IPv6 address
-          (e.g., query for a PTR record in the ip6.int domain).
-
-      4.  If the function is returning success, then the single address
-          that is returned in the hostent structure is a copy of the
-          first argument to the function with the same address family
-          that was passed as an argument to this function.
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 25]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   All four steps listed are performed, in order.  Also note that the
-   IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-
-   compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST
-   be returned and a query of the address not performed.
-
-   Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return
-   false for "::" and "::1".
-
-6.3 Freeing memory for getipnodebyname and getipnodebyaddr
-
-   The hostent structure does not change from its existing definition.
-   This structure, and the information pointed to by this structure, are
-   dynamically allocated by getipnodebyname and getipnodebyaddr.  The
-   following function frees this memory:
-
-      #include <netdb.h>
-
-      void freehostent(struct hostent *ptr);
-
-6.4 Protocol-Independent Nodename and Service Name Translation
-
-   Nodename-to-address translation is done in a protocol-independent
-   fashion using the getaddrinfo() function that is taken from the
-   Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
-   (Protocol Independent Interfaces) draft specification [3].
-
-   The official specification for this function will be the final POSIX
-   standard, with the following additional requirements:
-
-      -  getaddrinfo() (along with the getnameinfo() function described
-         in the next section) must be thread safe.
-
-      -  The AI_NUMERICHOST is new with this document.
-
-      -  All fields in socket address structures returned by
-         getaddrinfo() that are not filled in through an explicit
-         argument (e.g., sin6_flowinfo and sin_zero) must be set to 0.
-         (This makes it easier to compare socket address structures.)
-
-      -  getaddrinfo() must fill in the length field of a socket address
-         structure (e.g., sin6_len) on systems that support this field.
-
-   We are providing this independent description of the function because
-   POSIX standards are not freely available (as are IETF documents).
-
-      #include <sys/socket.h>
-      #include <netdb.h>
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 26]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      int getaddrinfo(const char *nodename, const char *servname,
-                      const struct addrinfo *hints,
-                      struct addrinfo **res);
-
-   The addrinfo structure is defined as a result of including the
-   <netdb.h> header.
-
-  struct addrinfo {
-    int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */
-    int     ai_family;    /* PF_xxx */
-    int     ai_socktype;  /* SOCK_xxx */
-    int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
-    size_t  ai_addrlen;   /* length of ai_addr */
-    char   *ai_canonname; /* canonical name for nodename */
-    struct sockaddr  *ai_addr; /* binary address */
-    struct addrinfo  *ai_next; /* next structure in linked list */
-  };
-
-   The return value from the function is 0 upon success or a nonzero
-   error code.  The following names are the nonzero error codes from
-   getaddrinfo(), and are defined in <netdb.h>:
-
-      EAI_ADDRFAMILY  address family for nodename not supported
-      EAI_AGAIN       temporary failure in name resolution
-      EAI_BADFLAGS    invalid value for ai_flags
-      EAI_FAIL        non-recoverable failure in name resolution
-      EAI_FAMILY      ai_family not supported
-      EAI_MEMORY      memory allocation failure
-      EAI_NODATA      no address associated with nodename
-      EAI_NONAME      nodename nor servname provided, or not known
-      EAI_SERVICE     servname not supported for ai_socktype
-      EAI_SOCKTYPE    ai_socktype not supported
-      EAI_SYSTEM      system error returned in errno
-
-   The nodename and servname arguments are pointers to null-terminated
-   strings or NULL.  One or both of these two arguments must be a non-
-   NULL pointer.  In the normal client scenario, both the nodename and
-   servname are specified.  In the normal server scenario, only the
-   servname is specified.  A non-NULL nodename string can be either a
-   node name or a numeric host address string (i.e., a dotted-decimal
-   IPv4 address or an IPv6 hex address).  A non-NULL servname string can
-   be either a service name or a decimal port number.
-
-   The caller can optionally pass an addrinfo structure, pointed to by
-   the third argument, to provide hints concerning the type of socket
-   that the caller supports.  In this hints structure all members other
-   than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
-   or a NULL pointer.  A value of PF_UNSPEC for ai_family means the
-
-
-
-Gilligan, et. al.            Informational                     [Page 27]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   caller will accept any protocol family.  A value of 0 for ai_socktype
-   means the caller will accept any socket type.  A value of 0 for
-   ai_protocol means the caller will accept any protocol.  For example,
-   if the caller handles only TCP and not UDP, then the ai_socktype
-   member of the hints structure should be set to SOCK_STREAM when
-   getaddrinfo() is called.  If the caller handles only IPv4 and not
-   IPv6, then the ai_family member of the hints structure should be set
-   to PF_INET when getaddrinfo() is called.  If the third argument to
-   getaddrinfo() is a NULL pointer, this is the same as if the caller
-   had filled in an addrinfo structure initialized to zero with
-   ai_family set to PF_UNSPEC.
-
-   Upon successful return a pointer to a linked list of one or more
-   addrinfo structures is returned through the final argument.  The
-   caller can process each addrinfo structure in this list by following
-   the ai_next pointer, until a NULL pointer is encountered.  In each
-   returned addrinfo structure the three members ai_family, ai_socktype,
-   and ai_protocol are the corresponding arguments for a call to the
-   socket() function.  In each addrinfo structure the ai_addr member
-   points to a filled-in socket address structure whose length is
-   specified by the ai_addrlen member.
-
-   If the AI_PASSIVE bit is set in the ai_flags member of the hints
-   structure, then the caller plans to use the returned socket address
-   structure in a call to bind().  In this case, if the nodename
-   argument is a NULL pointer, then the IP address portion of the socket
-   address structure will be set to INADDR_ANY for an IPv4 address or
-   IN6ADDR_ANY_INIT for an IPv6 address.
-
-   If the AI_PASSIVE bit is not set in the ai_flags member of the hints
-   structure, then the returned socket address structure will be ready
-   for a call to connect() (for a connection-oriented protocol) or
-   either connect(), sendto(), or sendmsg() (for a connectionless
-   protocol).  In this case, if the nodename argument is a NULL pointer,
-   then the IP address portion of the socket address structure will be
-   set to the loopback address.
-
-   If the AI_CANONNAME bit is set in the ai_flags member of the hints
-   structure, then upon successful return the ai_canonname member of the
-   first addrinfo structure in the linked list will point to a null-
-   terminated string containing the canonical name of the specified
-   nodename.
-
-   If the AI_NUMERICHOST bit is set in the ai_flags member of the hints
-   structure, then a non-NULL nodename string must be a numeric host
-   address string.  Otherwise an error of EAI_NONAME is returned.  This
-   flag prevents any type of name resolution service (e.g., the DNS)
-   from being called.
-
-
-
-Gilligan, et. al.            Informational                     [Page 28]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   All of the information returned by getaddrinfo() is dynamically
-   allocated: the addrinfo structures, and the socket address structures
-   and canonical node name strings pointed to by the addrinfo
-   structures.  To return this information to the system the function
-   freeaddrinfo() is called:
-
-      #include <sys/socket.h> #include <netdb.h>
-
-      void freeaddrinfo(struct addrinfo *ai);
-
-   The addrinfo structure pointed to by the ai argument is freed, along
-   with any dynamic storage pointed to by the structure.  This operation
-   is repeated until a NULL ai_next pointer is encountered.
-
-   To aid applications in printing error messages based on the EAI_xxx
-   codes returned by getaddrinfo(), the following function is defined.
-
-      #include <sys/socket.h> #include <netdb.h>
-
-      char *gai_strerror(int ecode);
-
-   The argument is one of the EAI_xxx values defined earlier and the
-   return value points to a string describing the error.  If the
-   argument is not one of the EAI_xxx values, the function still returns
-   a pointer to a string whose contents indicate an unknown error.
-
-6.5 Socket Address Structure to Nodename and Service Name
-
-   The POSIX 1003.1g specification includes no function to perform the
-   reverse conversion from getaddrinfo(): to look up a nodename and
-   service name, given the binary address and port.  Therefore, we
-   define the following function:
-
-      #include <sys/socket.h>
-      #include <netdb.h>
-
-      int getnameinfo(const struct sockaddr *sa, socklen_t salen,
-                      char *host, size_t hostlen,
-                      char *serv, size_t servlen,
-                      int flags);
-
-   This function looks up an IP address and port number provided by the
-   caller in the DNS and system-specific database, and returns text
-   strings for both in buffers provided by the caller.  The function
-   indicates successful completion by a zero return value; a non-zero
-   return value indicates failure.
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 29]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The first argument, sa, points to either a sockaddr_in structure (for
-   IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
-   address and port number.  The salen argument gives the length of the
-   sockaddr_in or sockaddr_in6 structure.
-
-   The function returns the nodename associated with the IP address in
-   the buffer pointed to by the host argument.  The caller provides the
-   size of this buffer via the hostlen argument.  The service name
-   associated with the port number is returned in the buffer pointed to
-   by serv, and the servlen argument gives the length of this buffer.
-   The caller specifies not to return either string by providing a zero
-   value for the hostlen or servlen arguments.  Otherwise, the caller
-   must provide buffers large enough to hold the nodename and the
-   service name, including the terminating null characters.
-
-   Unfortunately most systems do not provide constants that specify the
-   maximum size of either a fully-qualified domain name or a service
-   name.  Therefore to aid the application in allocating buffers for
-   these two returned strings the following constants are defined in
-   <netdb.h>:
-
-      #define NI_MAXHOST  1025
-      #define NI_MAXSERV    32
-
-   The first value is actually defined as the constant MAXDNAME in recent
-   versions of BIND's <arpa/nameser.h> header (older versions of BIND
-   define this constant to be 256) and the second is a guess based on the
-   services listed in the current Assigned Numbers RFC.
-
-   The final argument is a flag that changes the default actions of this
-   function.  By default the fully-qualified domain name (FQDN) for the
-   host is looked up in the DNS and returned.  If the flag bit NI_NOFQDN
-   is set, only the nodename portion of the FQDN is returned for local
-   hosts.
-
-   If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be
-   located in the DNS, the numeric form of the host's address is returned
-   instead of its name (e.g., by calling inet_ntop() instead of
-   getipnodebyaddr()).  If the flag bit NI_NAMEREQD is set, an error is
-   returned if the host's name cannot be located in the DNS.
-
-   If the flag bit NI_NUMERICSERV is set, the numeric form of the service
-   address is returned (e.g., its port number) instead of its name.  The
-   two NI_NUMERICxxx flags are required to support the "-n" flag that
-   many commands provide.
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 30]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   A fifth flag bit, NI_DGRAM, specifies that the service is a datagram
-   service, and causes getservbyport() to be called with a second
-   argument of "udp" instead of its default of "tcp".  This is required
-   for the few ports (e.g. 512-514) that have different services for UDP
-   and TCP.
-
-   These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
-   flags already defined for getaddrinfo().
-
-6.6 Address Conversion Functions
-
-   The two functions inet_addr() and inet_ntoa() convert an IPv4 address
-   between binary and text form.  IPv6 applications need similar
-   functions.  The following two functions convert both IPv6 and IPv4
-   addresses:
-
-      #include <sys/socket.h>
-      #include <arpa/inet.h>
-
-      int inet_pton(int af, const char *src, void *dst);
-
-      const char *inet_ntop(int af, const void *src,
-                            char *dst, size_t size);
-
-   The inet_pton() function converts an address in its standard text
-   presentation form into its numeric binary form.  The af argument
-   specifies the family of the address.  Currently the AF_INET and
-   AF_INET6 address families are supported.  The src argument points to
-   the string being passed in.  The dst argument points to a buffer into
-   which the function stores the numeric address.  The address is
-   returned in network byte order.  Inet_pton() returns 1 if the
-   conversion succeeds, 0 if the input is not a valid IPv4 dotted-
-   decimal string or a valid IPv6 address string, or -1 with errno set
-   to EAFNOSUPPORT if the af argument is unknown.  The calling
-   application must ensure that the buffer referred to by dst is large
-   enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
-   bytes for AF_INET6).
-
-   If the af argument is AF_INET, the function accepts a string in the
-   standard IPv4 dotted-decimal form:
-
-      ddd.ddd.ddd.ddd
-
-   where ddd is a one to three digit decimal number between 0 and 255.
-   Note that many implementations of the existing inet_addr() and
-   inet_aton() functions accept nonstandard input: octal numbers,
-   hexadecimal numbers, and fewer than four numbers.  inet_pton() does
-   not accept these formats.
-
-
-
-Gilligan, et. al.            Informational                     [Page 31]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   If the af argument is AF_INET6, then the function accepts a string in
-   one of the standard IPv6 text forms defined in Section 2.2 of the
-   addressing architecture specification [2].
-
-   The inet_ntop() function converts a numeric address into a text
-   string suitable for presentation.  The af argument specifies the
-   family of the address.  This can be AF_INET or AF_INET6.  The src
-   argument points to a buffer holding an IPv4 address if the af
-   argument is AF_INET, or an IPv6 address if the af argument is
-   AF_INET6, the address must be in network byte order.  The dst
-   argument points to a buffer where the function will store the
-   resulting text string.  The size argument specifies the size of this
-   buffer.  The application must specify a non-NULL dst argument.  For
-   IPv6 addresses, the buffer must be at least 46-octets.  For IPv4
-   addresses, the buffer must be at least 16-octets.  In order to allow
-   applications to easily declare buffers of the proper size to store
-   IPv4 and IPv6 addresses in string form, the following two constants
-   are defined in <netinet/in.h>:
-
-      #define INET_ADDRSTRLEN    16
-      #define INET6_ADDRSTRLEN   46
-
-   The inet_ntop() function returns a pointer to the buffer containing
-   the text string if the conversion succeeds, and NULL otherwise.  Upon
-   failure, errno is set to EAFNOSUPPORT if the af argument is invalid or
-   ENOSPC if the size of the result buffer is inadequate.
-
-6.7 Address Testing Macros
-
-   The following macros can be used to test for special IPv6 addresses.
-
-      #include <netinet/in.h>
-
-      int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
-      int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
-      int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
-      int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
-      int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
-      int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
-      int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
-
-      int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-      int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-      int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-      int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
-      int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 32]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The first seven macros return true if the address is of the specified
-   type, or false otherwise.  The last five test the scope of a
-   multicast address and return true if the address is a multicast
-   address of the specified scope or false if the address is either not
-   a multicast address or not of the specified scope.  Note that
-   IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true only for
-   the two local-use IPv6 unicast addresses.  These two macros do not
-   return true for IPv6 multicast addresses of either link-local scope
-   or site-local scope.
-
-7. Summary of New Definitions
-
-   The following list summarizes the constants, structure, and extern
-   definitions discussed in this memo, sorted by header.
-
-      <net/if.h>      IF_NAMESIZE
-      <net/if.h>      struct if_nameindex{};
-
-      <netdb.h>       AI_ADDRCONFIG
-      <netdb.h>       AI_DEFAULT
-      <netdb.h>       AI_ALL
-      <netdb.h>       AI_CANONNAME
-      <netdb.h>       AI_NUMERICHOST
-      <netdb.h>       AI_PASSIVE
-      <netdb.h>       AI_V4MAPPED
-      <netdb.h>       EAI_ADDRFAMILY
-      <netdb.h>       EAI_AGAIN
-      <netdb.h>       EAI_BADFLAGS
-      <netdb.h>       EAI_FAIL
-      <netdb.h>       EAI_FAMILY
-      <netdb.h>       EAI_MEMORY
-      <netdb.h>       EAI_NODATA
-      <netdb.h>       EAI_NONAME
-      <netdb.h>       EAI_SERVICE
-      <netdb.h>       EAI_SOCKTYPE
-      <netdb.h>       EAI_SYSTEM
-      <netdb.h>       NI_DGRAM
-      <netdb.h>       NI_MAXHOST
-      <netdb.h>       NI_MAXSERV
-      <netdb.h>       NI_NAMEREQD
-      <netdb.h>       NI_NOFQDN
-      <netdb.h>       NI_NUMERICHOST
-      <netdb.h>       NI_NUMERICSERV
-      <netdb.h>       struct addrinfo{};
-
-      <netinet/in.h>  IN6ADDR_ANY_INIT
-      <netinet/in.h>  IN6ADDR_LOOPBACK_INIT
-      <netinet/in.h>  INET6_ADDRSTRLEN
-
-
-
-Gilligan, et. al.            Informational                     [Page 33]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      <netinet/in.h>  INET_ADDRSTRLEN
-      <netinet/in.h>  IPPROTO_IPV6
-      <netinet/in.h>  IPV6_JOIN_GROUP
-      <netinet/in.h>  IPV6_LEAVE_GROUP
-      <netinet/in.h>  IPV6_MULTICAST_HOPS
-      <netinet/in.h>  IPV6_MULTICAST_IF
-      <netinet/in.h>  IPV6_MULTICAST_LOOP
-      <netinet/in.h>  IPV6_UNICAST_HOPS
-      <netinet/in.h>  SIN6_LEN
-      <netinet/in.h>  extern const struct in6_addr in6addr_any;
-      <netinet/in.h>  extern const struct in6_addr in6addr_loopback;
-      <netinet/in.h>  struct in6_addr{};
-      <netinet/in.h>  struct ipv6_mreq{};
-      <netinet/in.h>  struct sockaddr_in6{};
-
-      <sys/socket.h>  AF_INET6
-      <sys/socket.h>  PF_INET6
-      <sys/socket.h>  struct sockaddr_storage;
-
-   The following list summarizes the function and macro prototypes
-   discussed in this memo, sorted by header.
-
-<arpa/inet.h>   int inet_pton(int, const char *, void *);
-<arpa/inet.h>   const char *inet_ntop(int, const void *,
-                                      char *, size_t);
-
-<net/if.h>      char *if_indextoname(unsigned int, char *);
-<net/if.h>      unsigned int if_nametoindex(const char *);
-<net/if.h>      void if_freenameindex(struct if_nameindex *);
-<net/if.h>      struct if_nameindex *if_nameindex(void);
-
-<netdb.h>       int getaddrinfo(const char *, const char *,
-                                const struct addrinfo *,
-                                struct addrinfo **);
-<netdb.h>       int getnameinfo(const struct sockaddr *, socklen_t,
-                                char *, size_t, char *, size_t, int);
-<netdb.h>       void freeaddrinfo(struct addrinfo *);
-<netdb.h>       char *gai_strerror(int);
-<netdb.h>       struct hostent *getipnodebyname(const char *, int, int,
-                                       int *);
-<netdb.h>       struct hostent *getipnodebyaddr(const void *, size_t,
-                                       int, int *);
-<netdb.h>       void freehostent(struct hostent *);
-
-<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-
-
-
-Gilligan, et. al.            Informational                     [Page 34]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-8. Security Considerations
-
-   IPv6 provides a number of new security mechanisms, many of which need
-   to be accessible to applications.  Companion memos detailing the
-   extensions to the socket interfaces to support IPv6 security are
-   being written.
-
-9. Year 2000 Considerations
-
-   There are no issues for this memo concerning the Year 2000 issue
-   regarding the use of dates.
-
-Changes From RFC 2133
-
-   Changes made in the March 1998 Edition (-01 draft):
-
-      Changed all "hostname" to "nodename" for consistency with other
-      IPv6 documents.
-
-      Section 3.3: changed comment for sin6_flowinfo to be "traffic
-      class & flow info" and updated corresponding text description to
-      current definition of these two fields.
-
-      Section 3.10 ("Portability Additions") is new.
-
-      Section 6: a new paragraph was added reiterating that the existing
-      gethostbyname() and gethostbyaddr() are not changed.
-
-      Section 6.1: change gethostbyname3() to getnodebyname().  Add
-      AI_DEFAULT to handle majority of applications.  Renamed
-      AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and
-      IPv4 addresses too.  Defined exactly what getnodebyname() must
-      return if the name argument is a numeric address string.
-
-      Section 6.2: change gethostbyaddr() to getnodebyaddr().  Reword
-      items 2 and 3 in the description of how to handle IPv4-mapped and
-      IPv4- compatible addresses to "lookup a name" for a given address,
-      instead of specifying what type of DNS query to issue.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 35]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      Section 6.3: added two more requirements to getaddrinfo().
-
-      Section 7: added the following constants to the list for
-      <netdb.h>:  AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED.  Add union
-      sockaddr_union and SA_LEN to the lists for <sys/socket.h>.
-
-      Updated references.
-
-   Changes made in the November 1997 Edition (-00 draft):
-
-      The data types have been changed to conform with Draft 6.6 of the
-      Posix 1003.1g standard.
-
-      Section 3.2: data type of s6_addr changed to "uint8_t".
-
-      Section 3.3: data type of sin6_family changed to "sa_family_t".
-      data type of sin6_port changed to "in_port_t", data type of
-      sin6_flowinfo changed to "uint32_t".
-
-      Section 3.4: same as Section 3.3, plus data type of sin6_len
-      changed to "uint8_t".
-
-      Section 6.2: first argument of gethostbyaddr() changed from "const
-      char *" to "const void *" and second argument changed from "int"
-      to "size_t".
-
-      Section 6.4: second argument of getnameinfo() changed from
-      "size_t" to "socklen_t".
-
-      The wording was changed when new structures were defined, to be
-      more explicit as to which header must be included to define the
-      structure:
-
-      Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section
-      3.4 (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3
-      (ipv6_mreq{}), and Section 6.3 (addrinfo{}).
-
-      Section 4: NET_RT_LIST changed to NET_RT_IFLIST.
-
-      Section 5.1: The IPV6_ADDRFORM socket option was removed.
-
-      Section 5.3: Added a note that an option value other than 0 or 1
-      for IPV6_MULTICAST_LOOP returns an error.  Added a note that
-      IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP
-      can also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and
-      IPV6_DROP_MEMBERSHIP cannot be used with getsockopt().
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 36]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      Section 6.1: Removed the description of gethostbyname2() and its
-      associated RES_USE_INET6 option, replacing it with
-      gethostbyname3().
-
-      Section 6.2: Added requirement that gethostbyaddr() be thread
-      safe.  Reworded step 4 to avoid using the RES_USE_INET6 option.
-
-      Section 6.3: Added the requirement that getaddrinfo() and
-      getnameinfo() be thread safe.  Added the AI_NUMERICHOST flag.
-
-      Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and
-      IN6_IS_ADDR_SITELOCAL macros.
-
-   Changes made to the draft -01 specification Sept 98
-
-      Changed priority to traffic class in the spec.
-
-      Added the need for scope identification in section 2.1.
-
-      Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and
-      3.4.
-
-      Changed 3.10 to use generic storage structure to support holding
-      IPv6 addresses and removed the SA_LEN macro.
-
-      Distinguished between invalid input parameters and system failures
-      for Interface Identification in Section 4.1 and 4.2.
-
-      Added defaults for multicast operations in section 5.2 and changed
-      the names from ADD to JOIN and DROP to LEAVE to be consistent with
-      IPv6 multicast terminology.
-
-      Changed getnodebyname to getipnodebyname, getnodebyaddr to
-      getipnodebyaddr, and added MT safe error code to function
-      parameters in section 6.
-
-      Moved freehostent to its own sub-section after getipnodebyaddr now
-      6.3 (so this bumps all remaining sections in section 6.
-
-      Clarified the use of AI_ALL and AI_V4MAPPED that these are
-      dependent on the AF parameter and must be used as a conjunction in
-      section 6.1.
-
-      Removed the restriction that literal addresses cannot be used with
-      a flags argument in section 6.1.
-
-      Added Year 2000 Section to the draft
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 37]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      Deleted Reference to the following because the attached is deleted
-      from the ID directory and has expired.  But the logic from the
-      aforementioned draft still applies, so that was kept in Section
-      6.2 bullets after 3rd paragraph.
-
-      [7]  P. Vixie, "Reverse Name Lookups of Encapsulated IPv4
-           Addresses in IPv6", Internet-Draft, <draft-vixie-ipng-
-           ipv4ptr-00.txt>, May 1996.
-
-      Deleted the following reference as it is no longer referenced.
-      And the draft has expired.
-
-      [3]  D. McDonald, "A Simple IP Security API Extension to BSD
-           Sockets", Internet-Draft, <draft-mcdonald-simple-ipsec-api-
-           01.txt>, March 1997.
-
-      Deleted the following reference as it is no longer referenced.
-
-      [4]  C. Metz, "Network Security API for Sockets",
-           Internet-Draft, <draft-metz-net-security-api-01.txt>, January
-           1998.
-
-      Update current references to current status.
-
-      Added alignment notes for in6_addr and sin6_addr.
-
-      Clarified further that AI_V4MAPPED must be used with a dotted IPv4
-      literal address for getipnodebyname(), when address family is
-      AF_INET6.
-
-      Added text to clarify "::" and "::1" when used by
-      getipnodebyaddr().
-
-Acknowledgments
-
-   Thanks to the many people who made suggestions and provided feedback
-   to this document, including: Werner Almesberger, Ran Atkinson, Fred
-   Baker, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve
-   Deering, Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tom
-   Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada,
-   Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave
-   Mitton, Thomas Narten, Josh Osborne, Craig Partridge, Jean-Luc
-   Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
-   Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
-   Waitzman, Carl Williams, and Kazu Yamamoto,
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 38]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The getaddrinfo() and getnameinfo() functions are taken from an
-   earlier Internet Draft by Keith Sklower.  As noted in that draft,
-   William Durst, Steven Wise, Michael Karels, and Eric Allman provided
-   many useful discussions on the subject of protocol-independent name-
-   to-address translation, and reviewed early versions of Keith
-   Sklower's original proposal.  Eric Allman implemented the first
-   prototype of getaddrinfo().  The observation that specifying the pair
-   of name and service would suffice for connecting to a service
-   independent of protocol details was made by Marshall Rose in a
-   proposal to X/Open for a "Uniform Network Interface".
-
-   Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
-   Kacker made many contributions to this document.  Ramesh Govindan
-   made a number of contributions and co-authored an earlier version of
-   this memo.
-
-References
-
-   [1]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
-        Specification", RFC 2460, December 1998.
-
-   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
-        Architecture", RFC 2373, July 1998.
-
-   [3]  IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
-        6.6, March 1997.
-
-   [4]  Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
-        2292, February 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 39]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-Authors' Addresses
-
-   Robert E. Gilligan
-   FreeGate Corporation
-   1208 E. Arques Ave.
-   Sunnyvale, CA 94086
-
-   Phone: +1 408 617 1004
-   EMail: gilligan@freegate.com
-
-
-   Susan Thomson
-   Bell Communications Research
-   MRE 2P-343, 445 South Street
-   Morristown, NJ 07960
-
-   Phone: +1 201 829 4514
-   EMail: set@thumper.bellcore.com
-
-
-   Jim Bound
-   Compaq Computer Corporation
-   110 Spitbrook Road ZK3-3/U14
-   Nashua, NH 03062-2698
-
-   Phone: +1 603 884 0400
-   EMail: bound@zk3.dec.com
-
-
-   W. Richard Stevens
-   1202 E. Paseo del Zorro
-   Tucson, AZ 85718-2826
-
-   Phone: +1 520 297 9416
-   EMail: rstevens@kohala.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 40]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 41]
-
diff --git a/doc/rfc/rfc2671.txt b/doc/rfc/rfc2671.txt
deleted file mode 100644
index ec05f808..00000000
--- a/doc/rfc/rfc2671.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            P. Vixie
-Request for Comments: 2671                                            ISC
-Category: Standards Track                                     August 1999
-
-
-                  Extension Mechanisms for DNS (EDNS0)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   The Domain Name System's wire protocol includes a number of fixed
-   fields whose range has been or soon will be exhausted and does not
-   allow clients to advertise their capabilities to servers.  This
-   document describes backward compatible mechanisms for allowing the
-   protocol to grow.
-
-1 - Rationale and Scope
-
-1.1. DNS (see [RFC1035]) specifies a Message Format and within such
-     messages there are standard formats for encoding options, errors,
-     and name compression.  The maximum allowable size of a DNS Message
-     is fixed.  Many of DNS's protocol limits are too small for uses
-     which are or which are desired to become common.  There is no way
-     for implementations to advertise their capabilities.
-
-1.2. Existing clients will not know how to interpret the protocol
-     extensions detailed here.  In practice, these clients will be
-     upgraded when they have need of a new feature, and only new
-     features will make use of the extensions.  We must however take
-     account of client behaviour in the face of extra fields, and design
-     a fallback scheme for interoperability with these clients.
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 1]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-2 - Affected Protocol Elements
-
-2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
-     word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
-     1-bit flags.  The original reserved Z bits have been allocated to
-     various purposes, and most of the RCODE values are now in use.
-     More flags and more possible RCODEs are needed.
-
-2.2. The first two bits of a wire format domain label are used to denote
-     the type of the label.  [RFC1035 4.1.4] allocates two of the four
-     possible types and reserves the other two.  Proposals for use of
-     the remaining types far outnumber those available.  More label
-     types are needed.
-
-2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
-     While the minimum maximum reassembly buffer size still allows a
-     limit of 512 octets of UDP payload, most of the hosts now connected
-     to the Internet are able to reassemble larger datagrams.  Some
-     mechanism must be created to allow requestors to advertise larger
-     buffer sizes to responders.
-
-3 - Extended Label Types
-
-3.1. The "0 1" label type will now indicate an extended label type,
-     whose value is encoded in the lower six bits of the first octet of
-     a label.  All subsequently developed label types should be encoded
-     using an extended label type.
-
-3.2. The "1 1 1 1 1 1" extended label type will be reserved for future
-     expansion of the extended label type code space.
-
-4 - OPT pseudo-RR
-
-4.1. One OPT pseudo-RR can be added to the additional data section of
-     either a request or a response.  An OPT is called a pseudo-RR
-     because it pertains to a particular transport level message and not
-     to any actual DNS data.  OPT RRs shall never be cached, forwarded,
-     or stored in or loaded from master files.  The quantity of OPT
-     pseudo-RRs per message shall be either zero or one, but not
-     greater.
-
-4.2. An OPT RR has a fixed part and a variable set of options expressed
-     as {attribute, value} pairs.  The fixed part holds some DNS meta
-     data and also a small collection of new protocol elements which we
-     expect to be so popular that it would be a waste of wire space to
-     encode them as {attribute, value} pairs.
-
-
-
-
-
-Vixie                       Standards Track                     [Page 2]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-4.3. The fixed part of an OPT RR is structured as follows:
-
-     Field Name   Field Type     Description
-     ------------------------------------------------------
-     NAME         domain name    empty (root domain)
-     TYPE         u_int16_t      OPT
-     CLASS        u_int16_t      sender's UDP payload size
-     TTL          u_int32_t      extended RCODE and flags
-     RDLEN        u_int16_t      describes RDATA
-     RDATA        octet stream   {attribute,value} pairs
-
-4.4. The variable part of an OPT RR is encoded in its RDATA and is
-     structured as zero or more of the following:
-
-                +0 (MSB)                            +1 (LSB)
-     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-  0: |                          OPTION-CODE                          |
-     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-  2: |                         OPTION-LENGTH                         |
-     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-  4: |                                                               |
-     /                          OPTION-DATA                          /
-     /                                                               /
-     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-   OPTION-CODE    (Assigned by IANA.)
-
-   OPTION-LENGTH  Size (in octets) of OPTION-DATA.
-
-   OPTION-DATA    Varies per OPTION-CODE.
-
-4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
-     field) is the number of octets of the largest UDP payload that can
-     be reassembled and delivered in the sender's network stack.  Note
-     that path MTU, with or without fragmentation, may be smaller than
-     this.
-
-4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
-       reassembly buffer.  Choosing 1280 on an Ethernet connected
-       requestor would be reasonable.  The consequence of choosing too
-       large a value may be an ICMP message from an intermediate
-       gateway, or even a silent drop of the response message.
-
-4.5.2. Both requestors and responders are advised to take account of the
-       path's discovered MTU (if already known) when considering message
-       sizes.
-
-
-
-
-
-Vixie                       Standards Track                     [Page 3]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-4.5.3. The requestor's maximum payload size can change over time, and
-       should therefore not be cached for use beyond the transaction in
-       which it is advertised.
-
-4.5.4. The responder's maximum payload size can change over time, but
-       can be reasonably expected to remain constant between two
-       sequential transactions; for example, a meaningless QUERY to
-       discover a responder's maximum UDP payload size, followed
-       immediately by an UPDATE which takes advantage of this size.
-       (This is considered preferrable to the outright use of TCP for
-       oversized requests, if there is any reason to suspect that the
-       responder implements EDNS, and if a request will not fit in the
-       default 512 payload size limit.)
-
-4.5.5. Due to transaction overhead, it is unwise to advertise an
-       architectural limit as a maximum UDP payload size.  Just because
-       your stack can reassemble 64KB datagrams, don't assume that you
-       want to spend more than about 4KB of state memory per ongoing
-       transaction.
-
-4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
-     are structured as follows:
-
-                 +0 (MSB)                            +1 (LSB)
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   0: |         EXTENDED-RCODE        |            VERSION            |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   2: |                               Z                               |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-   EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  Note
-                   that EXTENDED-RCODE value "0" indicates that an
-                   unextended RCODE is in use (values "0" through "15").
-
-   VERSION         Indicates the implementation level of whoever sets
-                   it.  Full conformance with this specification is
-                   indicated by version "0."  Requestors are encouraged
-                   to set this to the lowest implemented level capable
-                   of expressing a transaction, to minimize the
-                   responder and network load of discovering the
-                   greatest common implementation level between
-                   requestor and responder.  A requestor's version
-                   numbering strategy should ideally be a run time
-                   configuration option.
-
-                   If a responder does not implement the VERSION level
-                   of the request, then it answers with RCODE=BADVERS.
-                   All responses will be limited in format to the
-
-
-
-Vixie                       Standards Track                     [Page 4]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-                   VERSION level of the request, but the VERSION of each
-                   response will be the highest implementation level of
-                   the responder.  In this way a requestor will learn
-                   the implementation level of a responder as a side
-                   effect of every response, including error responses,
-                   including RCODE=BADVERS.
-
-   Z               Set to zero by senders and ignored by receivers,
-                   unless modified in a subsequent specification.
-
-5 - Transport Considerations
-
-5.1. The presence of an OPT pseudo-RR in a request should be taken as an
-     indication that the requestor fully implements the given version of
-     EDNS, and can correctly understand any response that conforms to
-     that feature's specification.
-
-5.2. Lack of use of these features in a request must be taken as an
-     indication that the requestor does not implement any part of this
-     specification and that the responder may make no use of any
-     protocol extension described here in its response.
-
-5.3. Responders who do not understand these protocol extensions are
-     expected to send a response with RCODE NOTIMPL, FORMERR, or
-     SERVFAIL.  Therefore use of extensions should be "probed" such that
-     a responder who isn't known to support them be allowed a retry with
-     no extensions if it responds with such an RCODE.  If a responder's
-     capability level is cached by a requestor, a new probe should be
-     sent periodically to test for changes to responder capability.
-
-6 - Security Considerations
-
-     Requestor-side specification of the maximum buffer size may open a
-     new DNS denial of service attack if responders can be made to send
-     messages which are too large for intermediate gateways to forward,
-     thus leading to potential ICMP storms between gateways and
-     responders.
-
-7 - IANA Considerations
-
-     The IANA has assigned RR type code 41 for OPT.
-
-     It is the recommendation of this document and its working group
-     that IANA create a registry for EDNS Extended Label Types, for EDNS
-     Option Codes, and for EDNS Version Numbers.
-
-     This document assigns label type 0b01xxxxxx as "EDNS Extended Label
-     Type."  We request that IANA record this assignment.
-
-
-
-Vixie                       Standards Track                     [Page 5]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-     This document assigns extended label type 0bxx111111 as "Reserved
-     for future extended label types."  We request that IANA record this
-     assignment.
-
-     This document assigns option code 65535 to "Reserved for future
-     expansion."
-
-     This document expands the RCODE space from 4 bits to 12 bits.  This
-     will allow IANA to assign more than the 16 distinct RCODE values
-     allowed in [RFC1035].
-
-     This document assigns EDNS Extended RCODE "16" to "BADVERS".
-
-     IESG approval should be required to create new entries in the EDNS
-     Extended Label Type or EDNS Version Number registries, while any
-     published RFC (including Informational, Experimental, or BCP)
-     should be grounds for allocation of an EDNS Option Code.
-
-8 - Acknowledgements
-
-     Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
-     Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
-     Narten were each instrumental in creating and refining this
-     specification.
-
-9 - References
-
-    [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-               Specification", STD 13, RFC 1035, November 1987.
-
-10 - Author's Address
-
-   Paul Vixie
-   Internet Software Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 779 7001
-   EMail: vixie@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 6]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-11 - Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 7]
-
diff --git a/doc/rfc/rfc2672.txt b/doc/rfc/rfc2672.txt
deleted file mode 100644
index 11030168..00000000
--- a/doc/rfc/rfc2672.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        M. Crawford
-Request for Comments: 2672                                      Fermilab
-Category: Standards Track                                    August 1999
-
-
-                   Non-Terminal DNS Name Redirection
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-1.  Introduction
-
-   This document defines a new DNS Resource Record called "DNAME", which
-   provides the capability to map an entire subtree of the DNS name
-   space to another domain.  It differs from the CNAME record which maps
-   a single node of the name space.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [KWORD].
-
-2.  Motivation
-
-   This Resource Record and its processing rules were conceived as a
-   solution to the problem of maintaining address-to-name mappings in a
-   context of network renumbering.  Without the DNAME mechanism, an
-   authoritative DNS server for the address-to-name mappings of some
-   network must be reconfigured when that network is renumbered.  With
-   DNAME, the zone can be constructed so that it needs no modification
-   when renumbered.  DNAME can also be useful in other situations, such
-   as when an organizational unit is renamed.
-
-3. The DNAME Resource Record
-
-   The DNAME RR has mnemonic DNAME and type code 39 (decimal).
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 1]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-   DNAME has the following format:
-
-      <owner> <ttl> <class> DNAME <target>
-
-   The format is not class-sensitive.  All fields are required.  The
-   RDATA field <target> is a <domain-name> [DNSIS].
-
-   The DNAME RR causes type NS additional section processing.
-
-   The effect of the DNAME record is the substitution of the record's
-   <target> for its <owner> as a suffix of a domain name.  A "no-
-   descendants" limitation governs the use of DNAMEs in a zone file:
-
-      If a DNAME RR is present at a node N, there may be other data at N
-      (except a CNAME or another DNAME), but there MUST be no data at
-      any descendant of N.  This restriction applies only to records of
-      the same class as the DNAME record.
-
-   This rule assures predictable results when a DNAME record is cached
-   by a server which is not authoritative for the record's zone.  It
-   MUST be enforced when authoritative zone data is loaded.  Together
-   with the rules for DNS zone authority [DNSCLR] it implies that DNAME
-   and NS records can only coexist at the top of a zone which has only
-   one node.
-
-   The compression scheme of [DNSIS] MUST NOT be applied to the RDATA
-   portion of a DNAME record unless the sending server has some way of
-   knowing that the receiver understands the DNAME record format.
-   Signalling such understanding is expected to be the subject of future
-   DNS Extensions.
-
-   Naming loops can be created with DNAME records or a combination of
-   DNAME and CNAME records, just as they can with CNAME records alone.
-   Resolvers, including resolvers embedded in DNS servers, MUST limit
-   the resources they devote to any query.  Implementors should note,
-   however, that fairly lengthy chains of DNAME records may be valid.
-
-4.  Query Processing
-
-   To exploit the DNAME mechanism the name resolution algorithms [DNSCF]
-   must be modified slightly for both servers and resolvers.
-
-   Both modified algorithms incorporate the operation of making a
-   substitution on a name (either QNAME or SNAME) under control of a
-   DNAME record.  This operation will be referred to as "the DNAME
-   substitution".
-
-
-
-
-
-Crawford                    Standards Track                     [Page 2]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-4.1.  Processing by Servers
-
-   For a server performing non-recursive service steps 3.c and 4 of
-   section 4.3.2 [DNSCF] are changed to check for a DNAME record before
-   checking for a wildcard ("*") label, and to return certain DNAME
-   records from zone data and the cache.
-
-   DNS clients sending Extended DNS [EDNS0] queries with Version 0 or
-   non-extended queries are presumed not to understand the semantics of
-   the DNAME record, so a server which implements this specification,
-   when answering a non-extended query, SHOULD synthesize a CNAME record
-   for each DNAME record encountered during query processing to help the
-   client reach the correct DNS data.  The behavior of clients and
-   servers under Extended DNS versions greater than 0 will be specified
-   when those versions are defined.
-
-   The synthesized CNAME RR, if provided, MUST have
-
-      The same CLASS as the QCLASS of the query,
-
-      TTL equal to zero,
-
-      An <owner> equal to the QNAME in effect at the moment the DNAME RR
-      was encountered, and
-
-      An RDATA field containing the new QNAME formed by the action of
-      the DNAME substitution.
-
-   If the server has the appropriate key on-line [DNSSEC, SECDYN], it
-   MAY generate and return a SIG RR for the synthesized CNAME RR.
-
-   The revised server algorithm is:
-
-   1. Set or clear the value of recursion available in the response
-      depending on whether the name server is willing to provide
-      recursive service.  If recursive service is available and
-      requested via the RD bit in the query, go to step 5, otherwise
-      step 2.
-
-   2. Search the available zones for the zone which is the nearest
-      ancestor to QNAME.  If such a zone is found, go to step 3,
-      otherwise step 4.
-
-   3. Start matching down, label by label, in the zone.  The matching
-      process can terminate several ways:
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 3]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-      a. If the whole of QNAME is matched, we have found the node.
-
-         If the data at the node is a CNAME, and QTYPE doesn't match
-         CNAME, copy the CNAME RR into the answer section of the
-         response, change QNAME to the canonical name in the CNAME RR,
-         and go back to step 1.
-
-         Otherwise, copy all RRs which match QTYPE into the answer
-         section and go to step 6.
-
-      b. If a match would take us out of the authoritative data, we have
-         a referral.  This happens when we encounter a node with NS RRs
-         marking cuts along the bottom of a zone.
-
-         Copy the NS RRs for the subzone into the authority section of
-         the reply.  Put whatever addresses are available into the
-         additional section, using glue RRs if the addresses are not
-         available from authoritative data or the cache.  Go to step 4.
-
-      c. If at some label, a match is impossible (i.e., the
-         corresponding label does not exist), look to see whether the
-         last label matched has a DNAME record.
-
-         If a DNAME record exists at that point, copy that record into
-         the answer section.  If substitution of its <target> for its
-         <owner> in QNAME would overflow the legal size for a <domain-
-         name>, set RCODE to YXDOMAIN [DNSUPD] and exit; otherwise
-         perform the substitution and continue.  If the query was not
-         extended [EDNS0] with a Version indicating understanding of the
-         DNAME record, the server SHOULD synthesize a CNAME record as
-         described above and include it in the answer section.  Go back
-         to step 1.
-
-         If there was no DNAME record, look to see if the "*" label
-         exists.
-
-         If the "*" label does not exist, check whether the name we are
-         looking for is the original QNAME in the query or a name we
-         have followed due to a CNAME.  If the name is original, set an
-         authoritative name error in the response and exit.  Otherwise
-         just exit.
-
-         If the "*" label does exist, match RRs at that node against
-         QTYPE.  If any match, copy them into the answer section, but
-         set the owner of the RR to be QNAME, and not the node with the
-         "*" label.  Go to step 6.
-
-
-
-
-
-Crawford                    Standards Track                     [Page 4]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-   4. Start matching down in the cache.  If QNAME is found in the cache,
-      copy all RRs attached to it that match QTYPE into the answer
-      section.  If QNAME is not found in the cache but a DNAME record is
-      present at an ancestor of QNAME, copy that DNAME record into the
-      answer section.  If there was no delegation from authoritative
-      data, look for the best one from the cache, and put it in the
-      authority section.  Go to step 6.
-
-   5. Use the local resolver or a copy of its algorithm (see resolver
-      section of this memo) to answer the query.  Store the results,
-      including any intermediate CNAMEs and DNAMEs, in the answer
-      section of the response.
-
-   6. Using local data only, attempt to add other RRs which may be
-      useful to the additional section of the query.  Exit.
-
-   Note that there will be at most one ancestor with a DNAME as
-   described in step 4 unless some zone's data is in violation of the
-   no-descendants limitation in section 3.  An implementation might take
-   advantage of this limitation by stopping the search of step 3c or
-   step 4 when a DNAME record is encountered.
-
-4.2.  Processing by Resolvers
-
-   A resolver or a server providing recursive service must be modified
-   to treat a DNAME as somewhat analogous to a CNAME.  The resolver
-   algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
-   as 4.e and insert a new 4.d.  The complete algorithm becomes:
-
-   1. See if the answer is in local information, and if so return it to
-      the client.
-
-   2. Find the best servers to ask.
-
-   3. Send them queries until one returns a response.
-
-   4. Analyze the response, either:
-
-      a. if the response answers the question or contains a name error,
-         cache the data as well as returning it back to the client.
-
-      b. if the response contains a better delegation to other servers,
-         cache the delegation information, and go to step 2.
-
-      c. if the response shows a CNAME and that is not the answer
-         itself, cache the CNAME, change the SNAME to the canonical name
-         in the CNAME RR and go to step 1.
-
-
-
-
-Crawford                    Standards Track                     [Page 5]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-      d. if the response shows a DNAME and that is not the answer
-         itself, cache the DNAME.  If substitution of the DNAME's
-         <target> for its <owner> in the SNAME would overflow the legal
-         size for a <domain-name>, return an implementation-dependent
-         error to the application; otherwise perform the substitution
-         and go to step 1.
-
-      e. if the response shows a server failure or other bizarre
-         contents, delete the server from the SLIST and go back to step
-         3.
-
-   A resolver or recursive server which understands DNAME records but
-   sends non-extended queries MUST augment step 4.c by deleting from the
-   reply any CNAME records which have an <owner> which is a subdomain of
-   the <owner> of any DNAME record in the response.
-
-5.  Examples of Use
-
-5.1.  Organizational Renaming
-
-   If an organization with domain name FROBOZZ.EXAMPLE became part of an
-   organization with domain name ACME.EXAMPLE, it might ease transition
-   by placing information such as this in its old zone.
-
-       frobozz.example.  DNAME    frobozz-division.acme.example.
-                         MX       10       mailhub.acme.example.
-
-   The response to an extended recursive query for www.frobozz.example
-   would contain, in the answer section, the DNAME record shown above
-   and the relevant RRs for www.frobozz-division.acme.example.
-
-5.2.  Classless Delegation of Shorter Prefixes
-
-   The classless scheme for in-addr.arpa delegation [INADDR] can be
-   extended to prefixes shorter than 24 bits by use of the DNAME record.
-   For example, the prefix 192.0.8.0/22 can be delegated by the
-   following records.
-
-       $ORIGIN 0.192.in-addr.arpa.
-       8/22    NS       ns.slash-22-holder.example.
-       8       DNAME    8.8/22
-       9       DNAME    9.8/22
-       10      DNAME    10.8/22
-       11      DNAME    11.8/22
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 6]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-   A typical entry in the resulting reverse zone for some host with
-   address 192.0.9.33 might be
-
-       $ORIGIN 8/22.0.192.in-addr.arpa.
-       33.9    PTR     somehost.slash-22-holder.example.
-
-   The same advisory remarks concerning the choice of the "/" character
-   apply here as in [INADDR].
-
-5.3.  Network Renumbering Support
-
-   If IPv4 network renumbering were common, maintenance of address space
-   delegation could be simplified by using DNAME records instead of NS
-   records to delegate.
-
-      $ORIGIN new-style.in-addr.arpa.
-      189.190           DNAME    in-addr.example.net.
-
-      $ORIGIN in-addr.example.net.
-      188               DNAME    in-addr.customer.example.
-
-      $ORIGIN in-addr.customer.example.
-      1                 PTR      www.customer.example.
-      2                 PTR      mailhub.customer.example.
-      ; etc ...
-
-   This would allow the address space 190.189.0.0/16 assigned to the ISP
-   "example.net" to be changed without the necessity of altering the
-   zone files describing the use of that space by the ISP and its
-   customers.
-
-   Renumbering IPv4 networks is currently so arduous a task that
-   updating the DNS is only a small part of the labor, so this scheme
-   may have a low value.  But it is hoped that in IPv6 the renumbering
-   task will be quite different and the DNAME mechanism may play a
-   useful part.
-
-6.  IANA Considerations
-
-   This document defines a new DNS Resource Record type with the
-   mnemonic DNAME and type code 39 (decimal).  The naming/numbering
-   space is defined in [DNSIS].  This name and number have already been
-   registered with the IANA.
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 7]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-7.  Security Considerations
-
-   The DNAME record is similar to the CNAME record with regard to the
-   consequences of insertion of a spoofed record into a DNS server or
-   resolver, differing in that the DNAME's effect covers a whole subtree
-   of the name space.  The facilities of [DNSSEC] are available to
-   authenticate this record type.
-
-8.  References
-
-   [DNSCF]  Mockapetris, P., "Domain names - concepts and facilities",
-            STD 13, RFC 1034, November 1987.
-
-   [DNSCLR] Elz, R. and R. Bush, "Clarifications to the DNS
-            Specification", RFC 2181, July 1997.
-
-   [DNSIS]  Mockapetris, P., "Domain names - implementation and
-            specification", STD 13, RFC 1035, November 1987.
-
-   [DNSSEC] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
-            Security Extensions", RFC 2065, January 1997.
-
-   [DNSUPD] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
-            "Dynamic Updates in the Domain Name System", RFC 2136, April
-            1997.
-
-   [EDNS0]  Vixie, P., "Extensions mechanisms for DNS (EDNS0)", RFC
-            2671, August 1999.
-
-   [INADDR] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
-            ADDR.ARPA delegation", RFC 2317, March 1998.
-
-   [KWORD]  Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels," BCP 14, RFC 2119, March 1997.
-
-   [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
-            Update", RFC 2137, April 1997.
-
-9.  Author's Address
-
-   Matt Crawford
-   Fermilab MS 368
-   PO Box 500
-   Batavia, IL 60510
-   USA
-
-   Phone: +1 630 840-3461
-   EMail: crawdad@fnal.gov
-
-
-
-Crawford                    Standards Track                     [Page 8]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-10.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 9]
-
diff --git a/doc/rfc/rfc2673.txt b/doc/rfc/rfc2673.txt
deleted file mode 100644
index 19d272e9..00000000
--- a/doc/rfc/rfc2673.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        M. Crawford
-Request for Comments: 2673                                      Fermilab
-Category: Standards Track                                    August 1999
-
-
-                Binary Labels in the Domain Name System
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-1.  Introduction and Terminology
-
-   This document defines a "Bit-String Label" which may appear within
-   domain names.  This new label type compactly represents a sequence of
-   "One-Bit Labels" and enables resource records to be stored at any
-   bit-boundary in a binary-named section of the domain name tree.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [KWORD].
-
-2.  Motivation
-
-   Binary labels are intended to efficiently solve the problem of
-   storing data and delegating authority on arbitrary boundaries when
-   the structure of underlying name space is most naturally represented
-   in binary.
-
-3.  Label Format
-
-   Up to 256 One-Bit Labels can be grouped into a single Bit-String
-   Label.  Within a Bit-String Label the most significant or "highest
-   level" bit appears first.  This is unlike the ordering of DNS labels
-   themselves, which has the least significant or "lowest level" label
-   first.  Nonetheless, this ordering seems to be the most natural and
-   efficient for representing binary labels.
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 1]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-   Among consecutive Bit-String Labels, the bits in the first-appearing
-   label are less significant or "at a lower level" than the bits in
-   subsequent Bit-String Labels, just as ASCII labels are ordered.
-
-3.1.  Encoding
-
-      0                   1                   2
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2     . . .
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
-     |0 1|    ELT    |     Count     |           Label ...         |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
-
-   (Each tic mark represents one bit.)
-
-
-   ELT       000001 binary, the six-bit extended label type [EDNS0]
-             assigned to the Bit-String Label.
-
-   Count     The number of significant bits in the Label field.  A Count
-             value of zero indicates that 256 bits are significant.
-             (Thus the null label representing the DNS root cannot be
-             represented as a Bit String Label.)
-
-   Label     The bit string representing a sequence of One-Bit Labels,
-             with the most significant bit first.  That is, the One-Bit
-             Label in position 17 in the diagram above represents a
-             subdomain of the domain represented by the One-Bit Label in
-             position 16, and so on.
-
-             The Label field is padded on the right with zero to seven
-             pad bits to make the entire field occupy an integral number
-             of octets.  These pad bits MUST be zero on transmission and
-             ignored on reception.
-
-   A sequence of bits may be split into two or more Bit-String Labels,
-   but the division points have no significance and need not be
-   preserved.  An excessively clever server implementation might split
-   Bit-String Labels so as to maximize the effectiveness of message
-   compression [DNSIS].  A simpler server might divide Bit-String Labels
-   at zone boundaries, if any zone boundaries happen to fall between
-   One-Bit Labels.
-
-3.2.  Textual Representation
-
-   A Bit-String Label is represented in text -- in a zone file, for
-   example -- as a <bit-spec> surrounded by the delimiters "\[" and "]".
-   The <bit-spec> is either a dotted quad or a base indicator and a
-   sequence of digits appropriate to that base, optionally followed by a
-
-
-
-Crawford                    Standards Track                     [Page 2]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-   slash and a length.  The base indicators are "b", "o" and "x",
-   denoting base 2, 8 and 16 respectively.  The length counts the
-   significant bits and MUST be between 1 and 32, inclusive, after a
-   dotted quad, or between 1 and 256, inclusive, after one of the other
-   forms.  If the length is omitted, the implicit length is 32 for a
-   dotted quad or 1, 3 or 4 times the number of binary, octal or
-   hexadecimal digits supplied, respectively, for the other forms.
-
-   In augmented Backus-Naur form [ABNF],
-
-     bit-string-label =  "\[" bit-spec "]"
-
-     bit-spec         =  bit-data [ "/" length ]
-                       / dotted-quad [ "/" slength ]
-
-     bit-data         =  "x" 1*64HEXDIG
-                       / "o" 1*86OCTDIG
-                       / "b" 1*256BIT
-
-     dotted-quad      =  decbyte "." decbyte "." decbyte "." decbyte
-
-     decbyte          =  1*3DIGIT
-
-     length           =  NZDIGIT *2DIGIT
-
-     slength          =  NZDIGIT [ DIGIT ]
-
-     OCTDIG           =  %x30-37
-
-     NZDIGIT          =  %x31-39
-
-   If a <length> is present, the number of digits in the <bit-data> MUST
-   be just sufficient to contain the number of bits specified by the
-   <length>.  If there are insignificant bits in a final hexadecimal or
-   octal digit, they MUST be zero.  A <dotted-quad> always has all four
-   parts even if the associated <slength> is less than 24, but, like the
-   other forms, insignificant bits MUST be zero.
-
-   Each number represented by a <decbyte> must be between 0 and 255,
-   inclusive.
-
-   The number represented by <length> must be between 1 and 256
-   inclusive.
-
-   The number represented by <slength> must be between 1 and 32
-   inclusive.
-
-
-
-
-
-Crawford                    Standards Track                     [Page 3]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-   When the textual form of a Bit-String Label is generated by machine,
-   the length SHOULD be explicit, not implicit.
-
-3.2.1.  Examples
-
-   The following four textual forms represent the same Bit-String Label.
-
-                             \[b11010000011101]
-                             \[o64072/14]
-                             \[xd074/14]
-                             \[208.116.0.0/14]
-
-   The following represents two consecutive Bit-String Labels which
-   denote the same relative point in the DNS tree as any of the above
-   single Bit-String Labels.
-
-                             \[b11101].\[o640]
-
-3.3.  Canonical Representation and Sort Order
-
-   Both the wire form and the text form of binary labels have a degree
-   of flexibility in their grouping into multiple consecutive Bit-String
-   Labels.  For generating and checking DNS signature records [DNSSEC]
-   binary labels must be in a predictable form.  This canonical form is
-   defined as the form which has the fewest possible Bit-String Labels
-   and in which all except possibly the first (least significant) label
-   in any sequence of consecutive Bit-String Labels is of maximum
-   length.
-
-   For example, the canonical form of any sequence of up to 256 One-Bit
-   Labels has a single Bit-String Label, and the canonical form of a
-   sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of
-   which the second and third contain 256 label bits.
-
-   The canonical sort order of domain names [DNSSEC] is extended to
-   encompass binary labels as follows.  Sorting is still label-by-label,
-   from most to least significant, where a label may now be a One-Bit
-   Label or a standard (code 00) label.  Any One-Bit Label sorts before
-   any standard label, and a 0 bit sorts before a 1 bit.  The absence of
-   a label sorts before any label, as specified in [DNSSEC].
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 4]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-   For example, the following domain names are correctly sorted.
-
-                         foo.example
-                         \[b1].foo.example
-                         \[b100].foo.example
-                         \[b101].foo.example
-                         bravo.\[b10].foo.example
-                         alpha.foo.example
-
-4.  Processing Rules
-
-   A One-Bit Label never matches any other kind of label.  In
-   particular, the DNS labels represented by the single ASCII characters
-   "0" and "1" do not match One-Bit Labels represented by the bit values
-   0 and 1.
-
-5.  Discussion
-
-   A Count of zero in the wire-form represents a 256-bit sequence, not
-   to optimize that particular case, but to make it completely
-   impossible to have a zero-bit label.
-
-6.  IANA Considerations
-
-   This document defines one Extended Label Type, termed the Bit-String
-   Label, and requests registration of the code point 000001 binary in
-   the space defined by [EDNS0].
-
-7.  Security Considerations
-
-   All security considerations which apply to traditional ASCII DNS
-   labels apply equally to binary labels.  he canonicalization and
-   sorting rules of section 3.3 allow these to be addressed by DNS
-   Security [DNSSEC].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 5]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-8.  References
-
-   [ABNF]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
-            Specifications: ABNF", RFC 2234, November 1997.
-
-   [DNSIS]  Mockapetris, P., "Domain names - implementation and
-            specification", STD 13, RFC 1035, November 1987.
-
-   [DNSSEC] Eastlake, D., 3rd, C. Kaufman, "Domain Name System Security
-            Extensions", RFC 2065, January 1997
-
-   [EDNS0]  Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 2671,
-            August 1999.
-
-   [KWORD]  Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels," BCP 14, RFC 2119, March 1997.
-
-9.  Author's Address
-
-   Matt Crawford
-   Fermilab MS 368
-   PO Box 500
-   Batavia, IL 60510
-   USA
-
-   Phone: +1 630 840-3461
-   EMail: crawdad@fnal.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 6]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-10.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 7]
-
diff --git a/doc/rfc/rfc2782.txt b/doc/rfc/rfc2782.txt
deleted file mode 100644
index 1827f104..00000000
--- a/doc/rfc/rfc2782.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     A. Gulbrandsen
-Request for Comments: 2782                            Troll Technologies
-Obsoletes: 2052                                                 P. Vixie
-Category: Standards Track                   Internet Software Consortium
-                                                               L. Esibov
-                                                         Microsoft Corp.
-                                                           February 2000
-
-
-       A DNS RR for specifying the location of services (DNS SRV)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This document describes a DNS RR which specifies the location of the
-   server(s) for a specific protocol and domain.
-
-Overview and rationale
-
-   Currently, one must either know the exact address of a server to
-   contact it, or broadcast a question.
-
-   The SRV RR allows administrators to use several servers for a single
-   domain, to move services from host to host with little fuss, and to
-   designate some hosts as primary servers for a service and others as
-   backups.
-
-   Clients ask for a specific service/protocol for a specific domain
-   (the word domain is used here in the strict RFC 1034 sense), and get
-   back the names of any available servers.
-
-   Note that where this document refers to "address records", it means A
-   RR's, AAAA RR's, or their most modern equivalent.
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 1]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-Definitions
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
-   used in this document are to be interpreted as specified in [BCP 14].
-   Other terms used in this document are defined in the DNS
-   specification, RFC 1034.
-
-Applicability Statement
-
-   In general, it is expected that SRV records will be used by clients
-   for applications where the relevant protocol specification indicates
-   that clients should use the SRV record. Such specification MUST
-   define the symbolic name to be used in the Service field of the SRV
-   record as described below. It also MUST include security
-   considerations. Service SRV records SHOULD NOT be used in the absence
-   of such specification.
-
-Introductory example
-
-   If a SRV-cognizant LDAP client wants to discover a LDAP server that
-   supports TCP protocol and provides LDAP service for the domain
-   example.com., it does a lookup of
-
-      _ldap._tcp.example.com
-
-   as described in [ARM].  The example zone file near the end of this
-   memo contains answering RRs for an SRV query.
-
-   Note: LDAP is chosen as an example for illustrative purposes only,
-   and the LDAP examples used in this document should not be considered
-   a definitive statement on the recommended way for LDAP to use SRV
-   records. As described in the earlier applicability section, consult
-   the appropriate LDAP documents for the recommended procedures.
-
-The format of the SRV RR
-
-   Here is the format of the SRV RR, whose DNS type code is 33:
-
-        _Service._Proto.Name TTL Class SRV Priority Weight Port Target
-
-        (There is an example near the end of this document.)
-
-   Service
-        The symbolic name of the desired service, as defined in Assigned
-        Numbers [STD 2] or locally.  An underscore (_) is prepended to
-        the service identifier to avoid collisions with DNS labels that
-        occur in nature.
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 2]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-        Some widely used services, notably POP, don't have a single
-        universal name.  If Assigned Numbers names the service
-        indicated, that name is the only name which is legal for SRV
-        lookups.  The Service is case insensitive.
-
-   Proto
-        The symbolic name of the desired protocol, with an underscore
-        (_) prepended to prevent collisions with DNS labels that occur
-        in nature.  _TCP and _UDP are at present the most useful values
-        for this field, though any name defined by Assigned Numbers or
-        locally may be used (as for Service).  The Proto is case
-        insensitive.
-
-   Name
-        The domain this RR refers to.  The SRV RR is unique in that the
-        name one searches for is not this name; the example near the end
-        shows this clearly.
-
-   TTL
-        Standard DNS meaning [RFC 1035].
-
-   Class
-        Standard DNS meaning [RFC 1035].   SRV records occur in the IN
-        Class.
-
-   Priority
-        The priority of this target host.  A client MUST attempt to
-        contact the target host with the lowest-numbered priority it can
-        reach; target hosts with the same priority SHOULD be tried in an
-        order defined by the weight field.  The range is 0-65535.  This
-        is a 16 bit unsigned integer in network byte order.
-
-   Weight
-        A server selection mechanism.  The weight field specifies a
-        relative weight for entries with the same priority. Larger
-        weights SHOULD be given a proportionately higher probability of
-        being selected. The range of this number is 0-65535.  This is a
-        16 bit unsigned integer in network byte order.  Domain
-        administrators SHOULD use Weight 0 when there isn't any server
-        selection to do, to make the RR easier to read for humans (less
-        noisy).  In the presence of records containing weights greater
-        than 0, records with weight 0 should have a very small chance of
-        being selected.
-
-        In the absence of a protocol whose specification calls for the
-        use of other weighting information, a client arranges the SRV
-        RRs of the same Priority in the order in which target hosts,
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 3]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-        specified by the SRV RRs, will be contacted. The following
-        algorithm SHOULD be used to order the SRV RRs of the same
-        priority:
-
-        To select a target to be contacted next, arrange all SRV RRs
-        (that have not been ordered yet) in any order, except that all
-        those with weight 0 are placed at the beginning of the list.
-
-        Compute the sum of the weights of those RRs, and with each RR
-        associate the running sum in the selected order. Then choose a
-        uniform random number between 0 and the sum computed
-        (inclusive), and select the RR whose running sum value is the
-        first in the selected order which is greater than or equal to
-        the random number selected. The target host specified in the
-        selected SRV RR is the next one to be contacted by the client.
-        Remove this SRV RR from the set of the unordered SRV RRs and
-        apply the described algorithm to the unordered SRV RRs to select
-        the next target host.  Continue the ordering process until there
-        are no unordered SRV RRs.  This process is repeated for each
-        Priority.
-
-   Port
-        The port on this target host of this service.  The range is 0-
-        65535.  This is a 16 bit unsigned integer in network byte order.
-        This is often as specified in Assigned Numbers but need not be.
-
-   Target
-        The domain name of the target host.  There MUST be one or more
-        address records for this name, the name MUST NOT be an alias (in
-        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
-        not required, to return the address record(s) in the Additional
-        Data section.  Unless and until permitted by future standards
-        action, name compression is not to be used for this field.
-
-        A Target of "." means that the service is decidedly not
-        available at this domain.
-
-Domain administrator advice
-
-   Expecting everyone to update their client applications when the first
-   server publishes a SRV RR is futile (even if desirable).  Therefore
-   SRV would have to coexist with address record lookups for existing
-   protocols, and DNS administrators should try to provide address
-   records to support old clients:
-
-      - Where the services for a single domain are spread over several
-        hosts, it seems advisable to have a list of address records at
-        the same DNS node as the SRV RR, listing reasonable (if perhaps
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 4]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-        suboptimal) fallback hosts for Telnet, NNTP and other protocols
-        likely to be used with this name.  Note that some programs only
-        try the first address they get back from e.g. gethostbyname(),
-        and we don't know how widespread this behavior is.
-
-      - Where one service is provided by several hosts, one can either
-        provide address records for all the hosts (in which case the
-        round-robin mechanism, where available, will share the load
-        equally) or just for one (presumably the fastest).
-
-      - If a host is intended to provide a service only when the main
-        server(s) is/are down, it probably shouldn't be listed in
-        address records.
-
-      - Hosts that are referenced by backup address records must use the
-        port number specified in Assigned Numbers for the service.
-
-      - Designers of future protocols for which "secondary servers" is
-        not useful (or meaningful) may choose to not use SRV's support
-        for secondary servers.  Clients for such protocols may use or
-        ignore SRV RRs with Priority higher than the RR with the lowest
-        Priority for a domain.
-
-   Currently there's a practical limit of 512 bytes for DNS replies.
-   Until all resolvers can handle larger responses, domain
-   administrators are strongly advised to keep their SRV replies below
-   512 bytes.
-
-   All round numbers, wrote Dr. Johnson, are false, and these numbers
-   are very round: A reply packet has a 30-byte overhead plus the name
-   of the service ("_ldap._tcp.example.com" for instance); each SRV RR
-   adds 20 bytes plus the name of the target host; each NS RR in the NS
-   section is 15 bytes plus the name of the name server host; and
-   finally each A RR in the additional data section is 20 bytes or so,
-   and there are A's for each SRV and NS RR mentioned in the answer.
-   This size estimate is extremely crude, but shouldn't underestimate
-   the actual answer size by much.  If an answer may be close to the
-   limit, using a DNS query tool (e.g. "dig") to look at the actual
-   answer is a good idea.
-
-The "Weight" field
-
-   Weight, the server selection field, is not quite satisfactory, but
-   the actual load on typical servers changes much too quickly to be
-   kept around in DNS caches.  It seems to the authors that offering
-   administrators a way to say "this machine is three times as fast as
-   that one" is the best that can practically be done.
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 5]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-   The only way the authors can see of getting a "better" load figure is
-   asking a separate server when the client selects a server and
-   contacts it.  For short-lived services an extra step in the
-   connection establishment seems too expensive, and for long-lived
-   services, the load figure may well be thrown off a minute after the
-   connection is established when someone else starts or finishes a
-   heavy job.
-
-   Note: There are currently various experiments at providing relative
-   network proximity estimation, available bandwidth estimation, and
-   similar services.  Use of the SRV record with such facilities, and in
-   particular the interpretation of the Weight field when these
-   facilities are used, is for further study.  Weight is only intended
-   for static, not dynamic, server selection.  Using SRV weight for
-   dynamic server selection would require assigning unreasonably short
-   TTLs to the SRV RRs, which would limit the usefulness of the DNS
-   caching mechanism, thus increasing overall network load and
-   decreasing overall reliability.  Server selection via SRV is only
-   intended to express static information such as "this server has a
-   faster CPU than that one" or "this server has a much better network
-   connection than that one".
-
-The Port number
-
-   Currently, the translation from service name to port number happens
-   at the client, often using a file such as /etc/services.
-
-   Moving this information to the DNS makes it less necessary to update
-   these files on every single computer of the net every time a new
-   service is added, and makes it possible to move standard services out
-   of the "root-only" port range on unix.
-
-Usage rules
-
-   A SRV-cognizant client SHOULD use this procedure to locate a list of
-   servers and connect to the preferred one:
-
-        Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
-        QTYPE=SRV.
-
-        If the reply is NOERROR, ANCOUNT>0 and there is at least one
-        SRV RR which specifies the requested Service and Protocol in
-        the reply:
-
-            If there is precisely one SRV RR, and its Target is "."
-            (the root domain), abort.
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 6]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-            Else, for all such RR's, build a list of (Priority, Weight,
-            Target) tuples
-
-            Sort the list by priority (lowest number first)
-
-            Create a new empty list
-
-            For each distinct priority level
-                While there are still elements left at this priority
-                level
-
-                    Select an element as specified above, in the
-                    description of Weight in "The format of the SRV
-                    RR" Section, and move it to the tail of the new
-                    list
-
-            For each element in the new list
-
-                query the DNS for address records for the Target or
-                use any such records found in the Additional Data
-                section of the earlier SRV response.
-
-                for each address record found, try to connect to the
-               (protocol, address, service).
-
-        else
-
-            Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
-
-            for each address record found, try to connect to the
-           (protocol, address, service)
-
-Notes:
-
-   - Port numbers SHOULD NOT be used in place of the symbolic service
-     or protocol names (for the same reason why variant names cannot
-     be allowed: Applications would have to do two or more lookups).
-
-   - If a truncated response comes back from an SRV query, the rules
-     described in [RFC 2181] shall apply.
-
-   - A client MUST parse all of the RR's in the reply.
-
-   - If the Additional Data section doesn't contain address records
-     for all the SRV RR's and the client may want to connect to the
-     target host(s) involved, the client MUST look up the address
-     record(s).  (This happens quite often when the address record
-     has shorter TTL than the SRV or NS RR's.)
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 7]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-   - Future protocols could be designed to use SRV RR lookups as the
-     means by which clients locate their servers.
-
-Fictional example
-
-   This example uses fictional service "foobar" as an aid in
-   understanding SRV records. If ever service "foobar" is implemented,
-   it is not intended that it will necessarily use SRV records.  This is
-   (part of) the zone file for example.com, a still-unused domain:
-
-      $ORIGIN example.com.
-      @               SOA server.example.com. root.example.com. (
-                          1995032001 3600 3600 604800 86400 )
-                      NS  server.example.com.
-                      NS  ns1.ip-provider.net.
-                      NS  ns2.ip-provider.net.
-      ; foobar - use old-slow-box or new-fast-box if either is
-      ; available, make three quarters of the logins go to
-      ; new-fast-box.
-      _foobar._tcp    SRV 0 1 9 old-slow-box.example.com.
-                       SRV 0 3 9 new-fast-box.example.com.
-      ; if neither old-slow-box or new-fast-box is up, switch to
-      ; using the sysdmin's box and the server
-                       SRV 1 0 9 sysadmins-box.example.com.
-                       SRV 1 0 9 server.example.com.
-      server           A   172.30.79.10
-      old-slow-box     A   172.30.79.11
-      sysadmins-box    A   172.30.79.12
-      new-fast-box     A   172.30.79.13
-      ; NO other services are supported
-      *._tcp          SRV  0 0 0 .
-      *._udp          SRV  0 0 0 .
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 8]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-   In this example, a client of the "foobar" service in the
-   "example.com." domain needs an SRV lookup of
-   "_foobar._tcp.example.com." and possibly A lookups of "new-fast-
-   box.example.com." and/or the other hosts named.  The size of the SRV
-   reply is approximately 365 bytes:
-
-      30 bytes general overhead
-      20 bytes for the query string, "_foobar._tcp.example.com."
-      130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
-        fast-box", "old-slow-box", "server" and "sysadmins-box" -
-        "example.com" in the query section is quoted here and doesn't
-        need to be counted again.
-      75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server",
-        "ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is
-        quoted and only needs to be counted once.
-      120 bytes for the 6 address records (assuming IPv4 only) mentioned
-        by the SRV and NS RR's.
-
-IANA Considerations
-
-   The IANA has assigned RR type value 33 to the SRV RR.  No other IANA
-   services are required by this document.
-
-Changes from RFC 2052
-
-   This document obsoletes RFC 2052.   The major change from that
-   previous, experimental, version of this specification is that now the
-   protocol and service labels are prepended with an underscore, to
-   lower the probability of an accidental clash with a similar name used
-   for unrelated purposes.  Aside from that, changes are only intended
-   to increase the clarity and completeness of the document. This
-   document especially clarifies the use of the Weight field of the SRV
-   records.
-
-Security Considerations
-
-   The authors believe this RR to not cause any new security problems.
-   Some problems become more visible, though.
-
-   - The ability to specify ports on a fine-grained basis obviously
-     changes how a router can filter packets.  It becomes impossible
-     to block internal clients from accessing specific external
-     services, slightly harder to block internal users from running
-     unauthorized services, and more important for the router
-     operations and DNS operations personnel to cooperate.
-
-   - There is no way a site can keep its hosts from being referenced
-     as servers.  This could lead to denial of service.
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 9]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-   - With SRV, DNS spoofers can supply false port numbers, as well as
-     host names and addresses.   Because this vulnerability exists
-     already, with names and addresses, this is not a new
-     vulnerability, merely a slightly extended one, with little
-     practical effect.
-
-References
-
-   STD 2:    Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
-             1700, October 1994.
-
-   RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
-             STD 13, RFC 1034, November 1987.
-
-   RFC 1035: Mockapetris, P., "Domain names - Implementation and
-             Specification", STD 13, RFC 1035, November 1987.
-
-   RFC 974:  Partridge, C., "Mail routing and the domain system", STD
-             14, RFC 974, January 1986.
-
-   BCP 14:   Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS
-             Specification", RFC 2181, July 1997.
-
-   RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
-             Services", BCP 17, RFC 2219, October 1997.
-
-   BCP 14:   Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   ARM:      Armijo, M., Esibov, L. and P. Leach, "Discovering LDAP
-             Services with DNS", Work in Progress.
-
-   KDC-DNS:  Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
-             Realm Information with DNS", Work in Progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                    [Page 10]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-Acknowledgements
-
-   The algorithm used to select from the weighted SRV RRs of equal
-   priority is adapted from one supplied by Dan Bernstein.
-
-Authors' Addresses
-
-   Arnt Gulbrandsen
-   Troll Tech
-   Waldemar Thranes gate 98B
-   N-0175 Oslo, Norway
-
-   Fax:   +47 22806380
-   Phone: +47 22806390
-   EMail: arnt@troll.no
-
-
-   Paul Vixie
-   Internet Software Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 779 7001
-
-
-   Levon Esibov
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   EMail: levone@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                    [Page 11]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                    [Page 12]
-
diff --git a/doc/rfc/rfc2825.txt b/doc/rfc/rfc2825.txt
deleted file mode 100644
index fd8ef7c8..00000000
--- a/doc/rfc/rfc2825.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-

-

-

-

-

-

-Network Working Group                  Internet Architecture Board (IAB)

-Request for Comments: 2825                             L. Daigle, Editor

-Category: Informational                                         May 2000

-

-

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

-                        Other Internet protocols

-

-Status of this Memo

-

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

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

-   memo is unlimited.

-

-Copyright Notice

-

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

-

-Abstract

-

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

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

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

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

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

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

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

-   national boundaries. These services must interoperate worldwide, or

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

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

-   communications among people, but opportunities of the areas involved

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

-   other activities at an international scale, thereby retarding

-   economic development.

-

-   There are several proposals for internationalizing domain names,

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

-   ensure this interoperability and global reach while addressing

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

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

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

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

-   the continued global network interoperation that is the deserved

-   expectation of all Internet users.

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 1]

-

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

-

-

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

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

-   of architectural issues that the internationalization of domain names

-   faces.

-

-1. A Definition of Success

-

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

-   component of the IETF's continuing comprehensive effort to

-   internationalize language representation facilities in the protocols

-   that support the global functioning of the Internet.

-

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

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

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

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

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

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

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

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

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

-   limitations on allowable characters, and in other cases

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

-   individual organizations) have in practice not implemented all the

-   requisite options of the standards.

-

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

-

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

-   other effort to enable multiple character set representations in

-   textual elements that were traditionally restricted to English

-   language characters.

-

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

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

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

-   proposals have been suggested to address these issues.

-

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

-   evolving draft requirements document; further discussion is deferred

-   to the WG and its documents.

-

-3. Integrating with Current Realities

-

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

-   intricately intertwined with other operational components of the

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

-   analysis of the impact on existing critical operational standards

-

-

-

-IAB                          Informational                      [Page 2]

-

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

-

-

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

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

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

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

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

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

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

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

-

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

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

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

-

-3.1 Domain Names and E-mail

-

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

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

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

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

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

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

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

-   characters allowed in the DNS specification. Certain characters are

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

-   specifications.  Some mailers, built to adhere to these

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

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

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

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

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

-

-3.2 Domain Names and Routing

-

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

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

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

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

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

-   possible to enter or retrieve network descriptions utilizing

-   internationalized domain names.

-

-3.3 Domain Names and Network Management

-

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

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

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

-   implementations of software libraries being used to build SNMP-

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

-

-

-

-IAB                          Informational                      [Page 3]

-

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

-

-

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

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

-

-3.4 Domain Names and Security

-

-   Critical components of Internet public key technologies (PKIX,

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

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

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

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

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

-   two.

-

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

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

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

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

-   service.

-

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

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

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

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

-   are now impossible or at least far more difficult.

-

-4. Conclusion

-

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

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

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

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

-   tools.  When designing a solution for internationalization of domain

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

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

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

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

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

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

-   Internet.

-

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

-   identifying and discussing solutions for such potential

-   interoperability issues.

-

-   Experience with deployment of other protocols has indicated that it

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

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

-   solutions from all quarters, including organizations hoping to

-

-

-

-IAB                          Informational                      [Page 4]

-

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

-

-

-   provide services that address visible-name representation and

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

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

-   way to ensure the continued global interoperation that is the

-   deserved expectation of all Internet users.

-

-5. Security Considerations

-

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

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

-   mechanisms are reliant on the current specification of domain names

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

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

-   response to current pressures to address national or regional

-   characterset representation) might result in name strings that are

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

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

-

-6. Acknowledgements

-

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

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

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

-

-7. References

-

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

-             821, August 1982.

-

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

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

-

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

-             STD 13, RFC 1034, November 1987.

-

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

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

-

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

-             Internet Protocol", RFC 2401, November 1998.

-

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

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

-

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

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

-             Bodies", RFC 2045, November 1996.

-

-

-

-

-IAB                          Informational                      [Page 5]

-

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

-

-

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

-             RFC 2246, January 1999.

-

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

-             X.509 Public Key Infrastructure Certificate and CRL

-             Profile", RFC 2459, January 1999.

-

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

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

-             April 1999.

-

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

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

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

-             June 1999.

-

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

-             2826, May 2000.

-

-8. Author's Address

-

-   Internet Architecture Board

-

-   EMail:  iab@iab.org

-

-

-   Membership at time this document was completed:

-

-      Harald Alvestrand

-      Ran Atkinson

-      Rob Austein

-      Brian Carpenter

-      Steve Bellovin

-      Jon Crowcroft

-      Leslie Daigle

-      Steve Deering

-      Tony Hain

-      Geoff Huston

-      John Klensin

-      Henning Schulzrinne

-

-

-

-

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 6]

-

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

-

-

-9. Full Copyright Statement

-

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

-

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

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

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

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

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

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

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

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

-   Internet organizations, except as needed for the purpose of

-   developing Internet standards in which case the procedures for

-   copyrights defined in the Internet Standards process must be

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

-   English.

-

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

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

-

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

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

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

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

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

-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-Acknowledgement

-

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

-   Internet Society.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 7]

-

diff --git a/doc/rfc/rfc2826.txt b/doc/rfc/rfc2826.txt
deleted file mode 100644
index b4d88696..00000000
--- a/doc/rfc/rfc2826.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-

-

-

-

-

-

-Network Working Group                        Internet Architecture Board

-Request for Comments: 2826                                      May 2000

-Category: Informational

-

-

-              IAB Technical Comment on the Unique DNS Root

-

-Status of this Memo

-

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

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

-   memo is unlimited.

-

-Copyright Notice

-

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

-

-Summary

-

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

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

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

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

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

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

-   of coordinated root servers administered by a unique naming

-   authority.

-

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

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

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

-   the will of the web page designers.

-

-   This does not preclude private networks from operating their own

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

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

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

-   coordinated root servers of the global DNS naming hierarchy.

-

-1.  Detailed Explanation

-

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

-   in order to operate properly.

-

-1.1.  Maintenance of a Common Symbol Set

-

-   Effective communications between two parties requires two essential

-   preconditions:

-

-

-

-IAB                          Informational                      [Page 1]

-

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

-

-

-   -  The existence of a common symbol set, and

-

-   -  The existence of a common semantic interpretation of these

-      symbols.

-

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

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

-   the communication is lost.

-

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

-   common symbol set with a common semantic interpretation must be

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

-   semantic interpretation.  This condition of uniqueness allows any

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

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

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

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

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

-

-   Within public digital communications networks such as the Internet

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

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

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

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

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

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

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

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

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

-   meaning of the original use.

-

-   The DNS fulfills an essential role within the Internet protocol

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

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

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

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

-   records uniquely describing protocol addresses, network resources and

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

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

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

-   symbols, whose interpretation does not specifically require knowledge

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

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

-   name.

-

-   Since the DNS is hierarchically structured into domains, the

-   uniqueness requirement for DNS names in their entirety implies that

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

-

-

-

-IAB                          Informational                      [Page 2]

-

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

-

-

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

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

-   requirement for uniqueness within a domain further implies that there

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

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

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

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

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

-   choice.

-

-1.2.  Coordination of Updates

-

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

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

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

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

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

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

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

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

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

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

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

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

-   to support a shared domain scenario.

-

-   Moreover, even supposing that some other means of resolving

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

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

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

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

-   that naming authority Z had been delegated authority to define

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

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

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

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

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

-   within a single domain.

-

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

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

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

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

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

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 3]

-

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

-

-

-1.3.  Difficulty of Relocating the Root Zone

-

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

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

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

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

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

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

-   years out of date at many sites.

-

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

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

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

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

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

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

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

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

-   route around a buggy root server.

-

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

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

-

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

-   specify the public root zone is significantly more difficult than

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

-   stability of the system calls for extremely conservative and cautious

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

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

-   closely coordinated.

-

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

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

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

-   root zone still requires tight coupling and coordinated management

-   even in the presence of DNSSEC.

-

-2.  Conclusion

-

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

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

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

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

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

-   vague or ambiguous references.  To preserve the many important

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

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

-   expect the result of directory lookups and identification of the

-

-

-

-IAB                          Informational                      [Page 4]

-

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

-

-

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

-   are then resolved normally, rather than having directory systems

-   "replace" the DNS.

-

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

-

-3.  Security Considerations

-

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

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

-   recurring technically naive proposals.

-

-4.  IANA Considerations

-

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

-

-5.  References

-

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

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

-

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

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

-                         1987.

-

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

-                         Extensions", RFC 2535, March 1999.

-

-6.  Author's Address

-

-   Internet Architecture Board

-

-   EMail: iab@iab.org

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 5]

-

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

-

-

-7.  Full Copyright Statement

-

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

-

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

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

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

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

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

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

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

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

-   Internet organizations, except as needed for the purpose of

-   developing Internet standards in which case the procedures for

-   copyrights defined in the Internet Standards process must be

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

-   English.

-

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

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

-

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

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

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

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

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

-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-Acknowledgement

-

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

-   Internet Society.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 6]

-

diff --git a/doc/rfc/rfc2845.txt b/doc/rfc/rfc2845.txt
deleted file mode 100644
index aa9f385a..00000000
--- a/doc/rfc/rfc2845.txt
+++ /dev/null
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             P. Vixie
-Request for Comments: 2845                                             ISC
-Category: Standards Track                                   O. Gudmundsson
-Updates: 1035                                                     NAI Labs
-                                                           D. Eastlake 3rd
-                                                                  Motorola
-                                                             B. Wellington
-                                                                   Nominum
-                                                                  May 2000
-
-
-          Secret Key Transaction Authentication for DNS (TSIG)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This protocol allows for transaction level authentication using
-   shared secrets and one way hashing.  It can be used to authenticate
-   dynamic updates as coming from an approved client, or to authenticate
-   responses as coming from an approved recursive name server.
-
-   No provision has been made here for distributing the shared secrets;
-   it is expected that a network administrator will statically configure
-   name servers and clients using some out of band mechanism such as
-   sneaker-net until a secure automated mechanism for key distribution
-   is available.
-
-1 - Introduction
-
-   1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated
-   hierarchical distributed database system that provides information
-   fundamental to Internet operations, such as name <=> address
-   translation and mail handling information.  DNS has recently been
-   extended [RFC2535] to provide for data origin authentication, and
-   public key distribution, all based on public key cryptography and
-   public key based digital signatures.  To be practical, this form of
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 1]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   security generally requires extensive local caching of keys and
-   tracing of authentication through multiple keys and signatures to a
-   pre-trusted locally configured key.
-
-   1.2. One difficulty with the [RFC2535] scheme is that common DNS
-   implementations include simple "stub" resolvers which do not have
-   caches.  Such resolvers typically rely on a caching DNS server on
-   another host.  It is impractical for these stub resolvers to perform
-   general [RFC2535] authentication and they would naturally depend on
-   their caching DNS server to perform such services for them.  To do so
-   securely requires secure communication of queries and responses.
-   [RFC2535] provides public key transaction signatures to support this,
-   but such signatures are very expensive computationally to generate.
-   In general, these require the same complex public key logic that is
-   impractical for stubs.  This document specifies use of a message
-   authentication code (MAC), specifically HMAC-MD5 (a keyed hash
-   function), to provide an efficient means of point-to-point
-   authentication and integrity checking for transactions.
-
-   1.3. A second area where use of straight [RFC2535] public key based
-   mechanisms may be impractical is authenticating dynamic update
-   [RFC2136] requests.  [RFC2535] provides for request signatures but
-   with [RFC2535] they, like transaction signatures, require
-   computationally expensive public key cryptography and complex
-   authentication logic.  Secure Domain Name System Dynamic Update
-   ([RFC2137]) describes how different keys are used in dynamically
-   updated zones.  This document's secret key based MACs can be used to
-   authenticate DNS update requests as well as transaction responses,
-   providing a lightweight alternative to the protocol described by
-   [RFC2137].
-
-   1.4. A further use of this mechanism is to protect zone transfers.
-   In this case the data covered would be the whole zone transfer
-   including any glue records sent.  The protocol described by [RFC2535]
-   does not protect glue records and unsigned records unless SIG(0)
-   (transaction signature) is used.
-
-   1.5. The authentication mechanism proposed in this document uses
-   shared secret keys to establish a trust relationship between two
-   entities.  Such keys must be protected in a fashion similar to
-   private keys, lest a third party masquerade as one of the intended
-   parties (forge MACs).  There is an urgent need to provide simple and
-   efficient authentication between clients and local servers and this
-   proposal addresses that need.  This proposal is unsuitable for
-   general server to server authentication for servers which speak with
-   many other servers, since key management would become unwieldy with
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 2]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   the number of shared keys going up quadratically.  But it is suitable
-   for many resolvers on hosts that only talk to a few recursive
-   servers.
-
-   1.6. A server acting as an indirect caching resolver -- a "forwarder"
-   in common usage -- might use transaction-based authentication when
-   communicating with its small number of preconfigured "upstream"
-   servers.  Other uses of DNS secret key authentication and possible
-   systems for automatic secret key distribution may be proposed in
-   separate future documents.
-
-   1.7. New Assigned Numbers
-
-      RRTYPE = TSIG (250)
-      ERROR = 0..15 (a DNS RCODE)
-      ERROR = 16 (BADSIG)
-      ERROR = 17 (BADKEY)
-      ERROR = 18 (BADTIME)
-
-   1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED",  and
-   "MAY" in this document are to be interpreted as described in [RFC
-   2119].
-
-2 - TSIG RR Format
-
-   2.1 TSIG RR Type
-
-   To provide secret key authentication, we use a new RR type whose
-   mnemonic is TSIG and whose type code is 250.  TSIG is a meta-RR and
-   MUST not be cached.  TSIG RRs are used for authentication between DNS
-   entities that have established a shared secret key.  TSIG RRs are
-   dynamically computed to cover a particular DNS transaction and are
-   not DNS RRs in the usual sense.
-
-   2.2 TSIG Calculation
-
-   As the TSIG RRs are related to one DNS request/response, there is no
-   value in storing or retransmitting them, thus the TSIG RR is
-   discarded once it has been used to authenticate a DNS message.  The
-   only message digest algorithm specified in this document is "HMAC-
-   MD5" (see [RFC1321], [RFC2104]).  The "HMAC-MD5" algorithm is
-   mandatory to implement for interoperability.  Other algorithms can be
-   specified at a later date.  Names and definitions of new algorithms
-   MUST be registered with IANA.  All multi-octet integers in the TSIG
-   record are sent in network byte order (see [RFC1035 2.3.2]).
-
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 3]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   2.3. Record Format
-
-    NAME The name of the key used in domain name syntax.  The name
-         should reflect the names of the hosts and uniquely identify
-         the key among a set of keys these two hosts may share at any
-         given time.  If hosts A.site.example and B.example.net share a
-         key, possibilities for the key name include
-         <id>.A.site.example, <id>.B.example.net, and
-         <id>.A.site.example.B.example.net.  It should be possible for
-         more than one key to be in simultaneous use among a set of
-         interacting hosts.  The name only needs to be meaningful to
-         the communicating hosts but a meaningful mnemonic name as
-         above is strongly recommended.
-
-         The name may be used as a local index to the key involved and
-         it is recommended that it be globally unique.  Where a key is
-         just shared between two hosts, its name actually only need
-         only be meaningful to them but it is recommended that the key
-         name be mnemonic and incorporate the resolver and server host
-         names in that order.
-
-    TYPE TSIG (250: Transaction SIGnature)
-
-    CLASS ANY
-
-    TTL  0
-
-    RdLen (variable)
-
-    RDATA
-
-      Field Name       Data Type      Notes
-      --------------------------------------------------------------
-      Algorithm Name   domain-name    Name of the algorithm
-                                      in domain name syntax.
-      Time Signed      u_int48_t      seconds since 1-Jan-70 UTC.
-      Fudge            u_int16_t      seconds of error permitted
-                                      in Time Signed.
-      MAC Size         u_int16_t      number of octets in MAC.
-      MAC              octet stream   defined by Algorithm Name.
-      Original ID      u_int16_t      original message ID
-      Error            u_int16_t      expanded RCODE covering
-                                      TSIG processing.
-      Other Len        u_int16_t      length, in octets, of
-                                      Other Data.
-      Other Data       octet stream   empty unless Error == BADTIME
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 4]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   2.4. Example
-
-      NAME   HOST.EXAMPLE.
-
-      TYPE   TSIG
-
-      CLASS  ANY
-
-      TTL    0
-
-      RdLen  as appropriate
-
-      RDATA
-
-         Field Name       Contents
-         -------------------------------------
-         Algorithm Name   SAMPLE-ALG.EXAMPLE.
-         Time Signed      853804800
-         Fudge            300
-         MAC Size         as appropriate
-         MAC              as appropriate
-         Original ID      as appropriate
-         Error            0 (NOERROR)
-         Other Len        0
-         Other Data       empty
-
-3 - Protocol Operation
-
-   3.1. Effects of adding TSIG to outgoing message
-
-   Once the outgoing message has been constructed, the keyed message
-   digest operation can be performed.  The resulting message digest will
-   then be stored in a TSIG which is appended to the additional data
-   section (the ARCOUNT is incremented to reflect this).  If the TSIG
-   record cannot be added without causing the message to be truncated,
-   the server MUST alter the response so that a TSIG can be included.
-   This response consists of only the question and a TSIG record, and
-   has the TC bit set and RCODE 0 (NOERROR).  The client SHOULD at this
-   point retry the request using TCP (per [RFC1035 4.2.2]).
-
-   3.2. TSIG processing on incoming messages
-
-   If an incoming message contains a TSIG record, it MUST be the last
-   record in the additional section.  Multiple TSIG records are not
-   allowed.  If a TSIG record is present in any other position, the
-   packet is dropped and a response with RCODE 1 (FORMERR) MUST be
-   returned.  Upon receipt of a message with a correctly placed TSIG RR,
-   the TSIG RR is copied to a safe location, removed from the DNS
-
-
-
-Vixie, et al.               Standards Track                     [Page 5]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   Message, and decremented out of the DNS message header's ARCOUNT.  At
-   this point the keyed message digest operation is performed.  If the
-   algorithm name or key name is unknown to the recipient, or if the
-   message digests do not match, the whole DNS message MUST be
-   discarded.  If the message is a query, a response with RCODE 9
-   (NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17
-   (BADKEY) or TSIG ERROR 16 (BADSIG).  If no key is available to sign
-   this message it MUST be sent unsigned (MAC size == 0 and empty MAC).
-   A message to the system operations log SHOULD be generated, to warn
-   the operations staff of a possible security incident in progress.
-   Care should be taken to ensure that logging of this type of event
-   does not open the system to a denial of service attack.
-
-   3.3. Time values used in TSIG calculations
-
-   The data digested includes the two timer values in the TSIG header in
-   order to defend against replay attacks.  If this were not done, an
-   attacker could replay old messages but update the "Time Signed" and
-   "Fudge" fields to make the message look new.  This data is named
-   "TSIG Timers", and for the purpose of digest calculation they are
-   invoked in their "on the wire" format, in the following order: first
-   Time Signed, then Fudge.  For example:
-
-Field Name    Value       Wire Format         Meaning
-----------------------------------------------------------------------
-Time Signed   853804800   00 00 32 e4 07 00   Tue Jan 21 00:00:00 1997
-Fudge         300         01 2C               5 minutes
-
-   3.4. TSIG Variables and Coverage
-
-   When generating or verifying the contents of a TSIG record, the
-   following data are digested, in network byte order or wire format, as
-   appropriate:
-
-   3.4.1. DNS Message
-
-   A whole and complete DNS message in wire format, before the TSIG RR
-   has been added to the additional data section and before the DNS
-   Message Header's ARCOUNT field has been incremented to contain the
-   TSIG RR.  If the message ID differs from the original message ID, the
-   original message ID is substituted for the message ID.  This could
-   happen when forwarding a dynamic update request, for example.
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 6]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   3.4.2. TSIG Variables
-
-Source       Field Name       Notes
------------------------------------------------------------------------
-TSIG RR      NAME             Key name, in canonical wire format
-TSIG RR      CLASS            (Always ANY in the current specification)
-TSIG RR      TTL              (Always 0 in the current specification)
-TSIG RDATA   Algorithm Name   in canonical wire format
-TSIG RDATA   Time Signed      in network byte order
-TSIG RDATA   Fudge            in network byte order
-TSIG RDATA   Error            in network byte order
-TSIG RDATA   Other Len        in network byte order
-TSIG RDATA   Other Data       exactly as transmitted
-
-   The RR RDLEN and RDATA MAC Length are not included in the hash since
-   they are not guaranteed to be knowable before the MAC is generated.
-
-   The Original ID field is not included in this section, as it has
-   already been substituted for the message ID in the DNS header and
-   hashed.
-
-   For each label type, there must be a defined "Canonical wire format"
-   that specifies how to express a label in an unambiguous way.  For
-   label type 00, this is defined in [RFC2535], for label type 01, this
-   is defined in [RFC2673].  The use of label types other than 00 and 01
-   is not defined for this specification.
-
-   3.4.3. Request MAC
-
-   When generating the MAC to be included in a response, the request MAC
-   must be included in the digest.  The request's MAC is digested in
-   wire format, including the following fields:
-
-   Field        Type           Description
-   ---------------------------------------------------
-   MAC Length   u_int16_t      in network byte order
-   MAC Data     octet stream   exactly as transmitted
-
-   3.5. Padding
-
-   Digested components are fed into the hashing function as a continuous
-   octet stream with no interfield padding.
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 7]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-4 - Protocol Details
-
-   4.1. TSIG generation on requests
-
-   Client performs the message digest operation and appends a TSIG
-   record to the additional data section and transmits the request to
-   the server.  The client MUST store the message digest from the
-   request while awaiting an answer.  The digest components for a
-   request are:
-
-      DNS Message (request)
-      TSIG Variables (request)
-
-   Note that some older name servers will not accept requests with a
-   nonempty additional data section.  Clients SHOULD only attempt signed
-   transactions with servers who are known to support TSIG and share
-   some secret key with the client -- so, this is not a problem in
-   practice.
-
-   4.2. TSIG on Answers
-
-   When a server has generated a response to a signed request, it signs
-   the response using the same algorithm and key.  The server MUST not
-   generate a signed response to an unsigned request.  The digest
-   components are:
-
-      Request MAC
-      DNS Message (response)
-      TSIG Variables (response)
-
-   4.3. TSIG on TSIG Error returns
-
-   When a server detects an error relating to the key or MAC, the server
-   SHOULD send back an unsigned error message (MAC size == 0 and empty
-   MAC).  If an error is detected relating to the TSIG validity period,
-   the server SHOULD send back a signed error message.  The digest
-   components are:
-
-      Request MAC (if the request MAC validated)
-      DNS Message (response)
-      TSIG Variables (response)
-
-   The reason that the request is not included in this digest in some
-   cases is to make it possible for the client to verify the error.  If
-   the error is not a TSIG error the response MUST be generated as
-   specified in [4.2].
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 8]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   4.4. TSIG on TCP connection
-
-   A DNS TCP session can include multiple DNS envelopes.  This is, for
-   example, commonly used by zone transfer.  Using TSIG on such a
-   connection can protect the connection from hijacking and provide data
-   integrity.  The TSIG MUST be included on the first and last DNS
-   envelopes.  It can be optionally placed on any intermediary
-   envelopes.  It is expensive to include it on every envelopes, but it
-   MUST be placed on at least every 100'th envelope.  The first envelope
-   is processed as a standard answer, and subsequent messages have the
-   following digest components:
-
-      Prior Digest (running)
-      DNS Messages (any unsigned messages since the last TSIG)
-      TSIG Timers (current message)
-
-   This allows the client to rapidly detect when the session has been
-   altered; at which point it can close the connection and retry.  If a
-   client TSIG verification fails, the client MUST close the connection.
-   If the client does not receive TSIG records frequently enough (as
-   specified above) it SHOULD assume the connection has been hijacked
-   and it SHOULD close the connection.  The client SHOULD treat this the
-   same way as they would any other interrupted transfer (although the
-   exact behavior is not specified).
-
-   4.5. Server TSIG checks
-
-   Upon receipt of a message, server will check if there is a TSIG RR.
-   If one exists, the server is REQUIRED to return a TSIG RR in the
-   response.  The server MUST perform the following checks in the
-   following order, check KEY, check TIME values, check MAC.
-
-   4.5.1. KEY check and error handling
-
-   If a non-forwarding server does not recognize the key used by the
-   client, the server MUST generate an error response with RCODE 9
-   (NOTAUTH) and TSIG ERROR 17 (BADKEY).  This response MUST be unsigned
-   as specified in [4.3].  The server SHOULD log the error.
-
-   4.5.2. TIME check and error handling
-
-   If the server time is outside the time interval specified by the
-   request (which is: Time Signed, plus/minus Fudge), the server MUST
-   generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18
-   (BADTIME).  The server SHOULD also cache the most recent time signed
-   value in a message generated by a key, and SHOULD return BADTIME if a
-   message received later has an earlier time signed value.  A response
-   indicating a BADTIME error MUST be signed by the same key as the
-
-
-
-Vixie, et al.               Standards Track                     [Page 9]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   request.  It MUST include the client's current time in the time
-   signed field, the server's current time (a u_int48_t) in the other
-   data field, and 6 in the other data length field.  This is done so
-   that the client can verify a message with a BADTIME error without the
-   verification failing due to another BADTIME error.  The data signed
-   is specified in [4.3].  The server SHOULD log the error.
-
-   4.5.3. MAC check and error handling
-
-   If a TSIG fails to verify, the server MUST generate an error response
-   as specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16
-   (BADSIG).  This response MUST be unsigned as specified in [4.3].  The
-   server SHOULD log the error.
-
-   4.6. Client processing of answer
-
-   When a client receives a response from a server and expects to see a
-   TSIG, it first checks if the TSIG RR is present in the response.
-   Otherwise, the response is treated as having a format error and
-   discarded.  The client then extracts the TSIG, adjusts the ARCOUNT,
-   and calculates the keyed digest in the same way as the server.  If
-   the TSIG does not validate, that response MUST be discarded, unless
-   the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to
-   verify the response as if it were a TSIG Error response, as specified
-   in [4.3].  A message containing an unsigned TSIG record or a TSIG
-   record which fails verification SHOULD not be considered an
-   acceptable response; the client SHOULD log an error and continue to
-   wait for a signed response until the request times out.
-
-   4.6.1. Key error handling
-
-   If an RCODE on a response is 9 (NOTAUTH), and the response TSIG
-   validates, and the TSIG key is different from the key used on the
-   request, then this is a KEY error.  The client MAY retry the request
-   using the key specified by the server.  This should never occur, as a
-   server MUST NOT sign a response with a different key than signed the
-   request.
-
-   4.6.2. Time error handling
-
-   If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18
-   (BADTIME), or the current time does not fall in the range specified
-   in the TSIG record, then this is a TIME error.  This is an indication
-   that the client and server clocks are not synchronized.  In this case
-   the client SHOULD log the event.  DNS resolvers MUST NOT adjust any
-   clocks in the client based on BADTIME errors, but the server's time
-   in the other data field SHOULD be logged.
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 10]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   4.6.3. MAC error handling
-
-   If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG),
-   this is a MAC error, and client MAY retry the request with a new
-   request ID but it would be better to try a different shared key if
-   one is available.  Client SHOULD keep track of how many MAC errors
-   are associated with each key.  Clients SHOULD log this event.
-
-   4.7. Special considerations for forwarding servers
-
-   A server acting as a forwarding server of a DNS message SHOULD check
-   for the existence of a TSIG record.  If the name on the TSIG is not
-   of a secret that the server shares with the originator the server
-   MUST forward the message unchanged including the TSIG.  If the name
-   of the TSIG is of a key this server shares with the originator, it
-   MUST process the TSIG.  If the TSIG passes all checks, the forwarding
-   server MUST, if possible, include a TSIG of his own, to the
-   destination or the next forwarder.  If no transaction security is
-   available to the destination and the response has the AD flag (see
-   [RFC2535]), the forwarder MUST unset the AD flag before adding the
-   TSIG to the answer.
-
-5 - Shared Secrets
-
-   5.1. Secret keys are very sensitive information and all available
-   steps should be taken to protect them on every host on which they are
-   stored.  Generally such hosts need to be physically protected.  If
-   they are multi-user machines, great care should be taken that
-   unprivileged users have no access to keying material.  Resolvers
-   often run unprivileged, which means all users of a host would be able
-   to see whatever configuration data is used by the resolver.
-
-   5.2. A name server usually runs privileged, which means its
-   configuration data need not be visible to all users of the host.  For
-   this reason, a host that implements transaction-based authentication
-   should probably be configured with a "stub resolver" and a local
-   caching and forwarding name server.  This presents a special problem
-   for [RFC2136] which otherwise depends on clients to communicate only
-   with a zone's authoritative name servers.
-
-   5.3. Use of strong random shared secrets is essential to the security
-   of TSIG.  See [RFC1750] for a discussion of this issue.  The secret
-   should be at least as long as the keyed message digest, i.e. 16 bytes
-   for HMAC-MD5 or 20 bytes for HMAC-SHA1.
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 11]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-6 - Security Considerations
-
-   6.1. The approach specified here is computationally much less
-   expensive than the signatures specified in [RFC2535].  As long as the
-   shared secret key is not compromised, strong authentication is
-   provided for the last hop from a local name server to the user
-   resolver.
-
-   6.2. Secret keys should be changed periodically.  If the client host
-   has been compromised, the server should suspend the use of all
-   secrets known to that client.  If possible, secrets should be stored
-   in encrypted form.  Secrets should never be transmitted in the clear
-   over any network.  This document does not address the issue on how to
-   distribute secrets. Secrets should never be shared by more than two
-   entities.
-
-   6.3. This mechanism does not authenticate source data, only its
-   transmission between two parties who share some secret.  The original
-   source data can come from a compromised zone master or can be
-   corrupted during transit from an authentic zone master to some
-   "caching forwarder."  However, if the server is faithfully performing
-   the full [RFC2535] security checks, then only security checked data
-   will be available to the client.
-
-   6.4. A fudge value that is too large may leave the server open to
-   replay attacks.  A fudge value that is too small may cause failures
-   if machines are not time synchronized or there are unexpected network
-   delays.  The recommended value in most situation is 300 seconds.
-
-7 - IANA Considerations
-
-   IANA is expected to create and maintain a registry of algorithm names
-   to be used as "Algorithm Names" as defined in Section 2.3.  The
-   initial value should be "HMAC-MD5.SIG-ALG.REG.INT".  Algorithm names
-   are text strings encoded using the syntax of a domain name.  There is
-   no structure required other than names for different algorithms must
-   be unique when compared as DNS names, i.e., comparison is case
-   insensitive.  Note that the initial value mentioned above is not a
-   domain name, and therefore need not be a registered name within the
-   DNS.  New algorithms are assigned using the IETF Consensus policy
-   defined in RFC 2434. The algorithm name HMAC-MD5.SIG-ALG.REG.INT
-   looks like a FQDN for historical reasons; future algorithm names are
-   expected to be simple (i.e., single-component) names.
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 12]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   IANA is expected to create and maintain a registry of "TSIG Error
-   values" to be used for "Error" values as defined in section 2.3.
-   Initial values should be those defined in section 1.7.  New TSIG
-   error codes for the TSIG error field are assigned using the IETF
-   Consensus policy defined in RFC 2434.
-
-8 - References
-
-   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1034, November 1987.
-
-   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-              April 1992.
-
-   [RFC1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-              Recommendations for Security", RFC 1750, December 1995.
-
-   [RFC2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC-MD5:
-              Keyed-MD5 for Message Authentication", RFC 2104, February
-              1997.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound "Dynamic
-              Updates in the Domain Name System", RFC 2136, April 1997.
-
-   [RFC2137]  Eastlake 3rd, D., "Secure Domain Name System Dynamic
-              Update", RFC 2137, April 1997.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
-              RFC 2673, August 1999.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 13]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-9 - Authors' Addresses
-
-   Paul Vixie
-   Internet Software Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 779 7001
-   EMail: vixie@isc.org
-
-
-   Olafur Gudmundsson
-   NAI Labs
-   3060 Washington Road, Route 97
-   Glenwood, MD 21738
-
-   Phone: +1 443 259 2389
-   EMail: ogud@tislabs.com
-
-
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
-
-   Phone: +1 508 261 5434
-   EMail: dee3@torque.pothole.com
-
-
-   Brian Wellington
-   Nominum, Inc.
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 779 6022
-   EMail: Brian.Wellington@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 14]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-10  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 15]
-
diff --git a/doc/rfc/rfc2874.txt b/doc/rfc/rfc2874.txt
deleted file mode 100644
index 915c104a..00000000
--- a/doc/rfc/rfc2874.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        M. Crawford
-Request for Comments: 2874                                      Fermilab
-Category: Standards Track                                     C. Huitema
-                                                   Microsoft Corporation
-                                                               July 2000
-
-
-   DNS Extensions to Support IPv6 Address Aggregation and Renumbering
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This document defines changes to the Domain Name System to support
-   renumberable and aggregatable IPv6 addressing.  The changes include a
-   new resource record type to store an IPv6 address in a manner which
-   expedites network renumbering and updated definitions of existing
-   query types that return Internet addresses as part of additional
-   section processing.
-
-   For lookups keyed on IPv6 addresses (often called reverse lookups),
-   this document defines a new zone structure which allows a zone to be
-   used without modification for parallel copies of an address space (as
-   for a multihomed provider or site) and across network renumbering
-   events.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 1]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-Table of Contents
-
-   1.  Introduction ...............................................  2
-   2.  Overview ...................................................  3
-       2.1.  Name-to-Address Lookup ...............................  4
-       2.2.  Underlying Mechanisms for Reverse Lookups ............  4
-           2.2.1.  Delegation on Arbitrary Boundaries .............  4
-           2.2.2.  Reusable Zones .................................  5
-   3.  Specifications .............................................  5
-       3.1.  The A6 Record Type ...................................  5
-           3.1.1.  Format .........................................  6
-           3.1.2.  Processing .....................................  6
-           3.1.3.  Textual Representation .........................  7
-           3.1.4.  Name Resolution Procedure ......................  7
-       3.2.  Zone Structure for Reverse Lookups ...................  7
-   4.  Modifications to Existing Query Types ......................  8
-   5.  Usage Illustrations ........................................  8
-       5.1.  A6 Record Chains .....................................  9
-           5.1.1.  Authoritative Data .............................  9
-           5.1.2.  Glue ........................................... 10
-           5.1.3.  Variations ..................................... 12
-       5.2.  Reverse Mapping Zones ................................ 13
-           5.2.1.  The TLA level .................................. 13
-           5.2.2.  The ISP level .................................. 13
-           5.2.3.  The Site Level ................................. 13
-       5.3.  Lookups .............................................. 14
-       5.4.  Operational Note ..................................... 15
-   6.  Transition from RFC 1886 and Deployment Notes .............. 15
-       6.1.  Transition from AAAA and Coexistence with A Records .. 16
-       6.2.  Transition from Nibble Labels to Binary Labels ....... 17
-   7.  Security Considerations .................................... 17
-   8.  IANA Considerations ........................................ 17
-   9.  Acknowledgments ............................................ 18
-   10.  References ................................................ 18
-   11.  Authors' Addresses ........................................ 19
-   12.  Full Copyright Statement .................................. 20
-
-1.  Introduction
-
-   Maintenance of address information in the DNS is one of several
-   obstacles which have prevented site and provider renumbering from
-   being feasible in IP version 4.  Arguments about the importance of
-   network renumbering for the preservation of a stable routing system
-   and for other purposes may be read in [RENUM1, RENUM2, RENUM3].  To
-   support the storage of IPv6 addresses without impeding renumbering we
-   define the following extensions.
-
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 2]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   o  A new resource record type, "A6", is defined to map a domain name
-      to an IPv6 address, with a provision for indirection for leading
-      "prefix" bits.
-
-   o  Existing queries that perform additional section processing to
-      locate IPv4 addresses are redefined to do that processing for both
-      IPv4 and IPv6 addresses.
-
-   o  A new domain, IP6.ARPA, is defined to support lookups based on
-      IPv6 address.
-
-   o  A new prefix-delegation method is defined, relying on new DNS
-      features [BITLBL, DNAME].
-
-   The changes are designed to be compatible with existing application
-   programming interfaces.  The existing support for IPv4 addresses is
-   retained.  Transition issues related to the coexistence of both IPv4
-   and IPv6 addresses in DNS are discussed in [TRANS].
-
-   This memo proposes a replacement for the specification in RFC 1886
-   [AAAA] and a departure from current implementation practices.  The
-   changes are designed to facilitate network renumbering and
-   multihoming.  Domains employing the A6 record for IPv6 addresses can
-   insert automatically-generated AAAA records in zone files to ease
-   transition.  It is expected that after a reasonable period, RFC 1886
-   will become Historic.
-
-   The next three major sections of this document are an overview of the
-   facilities defined or employed by this specification, the
-   specification itself, and examples of use.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [KWORD].  The key word
-   "SUGGESTED" signifies a strength between MAY and SHOULD: it is
-   believed that compliance with the suggestion has tangible benefits in
-   most instances.
-
-2.  Overview
-
-   This section provides an overview of the DNS facilities for storage
-   of IPv6 addresses and for lookups based on IPv6 address, including
-   those defined here and elsewhere.
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 3]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-2.1.  Name-to-Address Lookup
-
-   IPv6 addresses are stored in one or more A6 resource records.  A
-   single A6 record may include a complete IPv6 address, or a contiguous
-   portion of an address and information leading to one or more
-   prefixes.  Prefix information comprises a prefix length and a DNS
-   name which is in turn the owner of one or more A6 records defining
-   the prefix or prefixes which are needed to form one or more complete
-   IPv6 addresses.  When the prefix length is zero, no DNS name is
-   present and all the leading bits of the address are significant.
-   There may be multiple levels of indirection and the existence of
-   multiple A6 records at any level multiplies the number of IPv6
-   addresses which are formed.
-
-   An application looking up an IPv6 address will generally cause the
-   DNS resolver to access several A6 records, and multiple IPv6
-   addresses may be returned even if the queried name was the owner of
-   only one A6 record.  The authenticity of the returned address(es)
-   cannot be directly verified by DNS Security [DNSSEC].  The A6 records
-   which contributed to the address(es) may of course be verified if
-   signed.
-
-   Implementers are reminded of the necessity to limit the amount of
-   work a resolver will perform in response to a client request.  This
-   principle MUST be extended to also limit the generation of DNS
-   requests in response to one name-to-address (or address-to-name)
-   lookup request.
-
-2.2.  Underlying Mechanisms for Reverse Lookups
-
-   This section describes the new DNS features which this document
-   exploits.  This section is an overview, not a specification of those
-   features.  The reader is directed to the referenced documents for
-   more details on each.
-
-2.2.1.  Delegation on Arbitrary Boundaries
-
-   This new scheme for reverse lookups relies on a new type of DNS label
-   called the "bit-string label" [BITLBL].  This label compactly
-   represents an arbitrary string of bits which is treated as a
-   hierarchical sequence of one-bit domain labels.  Resource records can
-   thereby be stored at arbitrary bit-boundaries.
-
-   Examples in section 5 will employ the following textual
-   representation for bit-string labels, which is a subset of the syntax
-   defined in [BITLBL].  A base indicator "x" for hexadecimal and a
-   sequence of hexadecimal digits is enclosed between "\[" and "]".  The
-   bits denoted by the digits represent a sequence of one-bit domain
-
-
-
-Crawford, et al.            Standards Track                     [Page 4]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   labels ordered from most to least significant.  (This is the opposite
-   of the order they would appear if listed one bit at a time, but it
-   appears to be a convenient notation.)  The digit string may be
-   followed by a slash ("/") and a decimal count.  If omitted, the
-   implicit count is equal to four times the number of hexadecimal
-   digits.
-
-   Consecutive bit-string labels are equivalent (up to the limit imposed
-   by the size of the bit count field) to a single bit-string label
-   containing all the bits of the consecutive labels in the proper
-   order.  As an example, either of the following domain names could be
-   used in a QCLASS=IN, QTYPE=PTR query to find the name of the node
-   with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
-
-    \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
-
-    \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
-
-2.2.2.  Reusable Zones
-
-   DNS address space delegation is implemented not by zone cuts and NS
-   records, but by a new analogue to the CNAME record, called the DNAME
-   resource record [DNAME].  The DNAME record provides alternate naming
-   to an entire subtree of the domain name space, rather than to a
-   single node.  It causes some suffix of a queried name to be
-   substituted with a name from the DNAME record's RDATA.
-
-   For example, a resolver or server providing recursion, while looking
-   up a QNAME a.b.c.d.e.f may encounter a DNAME record
-
-                        d.e.f.     DNAME     w.xy.
-
-   which will cause it to look for a.b.c.w.xy.
-
-3.  Specifications
-
-3.1.  The A6 Record Type
-
-   The A6 record type is specific to the IN (Internet) class and has
-   type number 38 (decimal).
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 5]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-3.1.1.  Format
-
-   The RDATA portion of the A6 record contains two or three fields.
-
-           +-----------+------------------+-------------------+
-           |Prefix len.|  Address suffix  |    Prefix name    |
-           | (1 octet) |  (0..16 octets)  |  (0..255 octets)  |
-           +-----------+------------------+-------------------+
-
-   o  A prefix length, encoded as an eight-bit unsigned integer with
-      value between 0 and 128 inclusive.
-
-   o  An IPv6 address suffix, encoded in network order (high-order octet
-      first).  There MUST be exactly enough octets in this field to
-      contain a number of bits equal to 128 minus prefix length, with 0
-      to 7 leading pad bits to make this field an integral number of
-      octets.  Pad bits, if present, MUST be set to zero when loading a
-      zone file and ignored (other than for SIG [DNSSEC] verification)
-      on reception.
-
-   o  The name of the prefix, encoded as a domain name.  By the rules of
-      [DNSIS], this name MUST NOT be compressed.
-
-   The domain name component SHALL NOT be present if the prefix length
-   is zero.  The address suffix component SHALL NOT be present if the
-   prefix length is 128.
-
-   It is SUGGESTED that an A6 record intended for use as a prefix for
-   other A6 records have all the insignificant trailing bits in its
-   address suffix field set to zero.
-
-3.1.2.  Processing
-
-   A query with QTYPE=A6 causes type A6 and type NS additional section
-   processing for the prefix names, if any, in the RDATA field of the A6
-   records in the answer section.  This processing SHOULD be recursively
-   applied to the prefix names of A6 records included as additional
-   data.  When space in the reply packet is a limit, inclusion of
-   additional A6 records takes priority over NS records.
-
-   It is an error for an A6 record with prefix length L1 > 0 to refer to
-   a domain name which owns an A6 record with a prefix length L2 > L1.
-   If such a situation is encountered by a resolver, the A6 record with
-   the offending (larger) prefix length MUST be ignored.  Robustness
-   precludes signaling an error if addresses can still be formed from
-   valid A6 records, but it is SUGGESTED that zone maintainers from time
-   to time check all the A6 records their zones reference.
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 6]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-3.1.3.  Textual Representation
-
-   The textual representation of the RDATA portion of the A6 resource
-   record in a zone file comprises two or three fields separated by
-   whitespace.
-
-   o  A prefix length, represented as a decimal number between 0 and 128
-      inclusive,
-
-   o  the textual representation of an IPv6 address as defined in
-      [AARCH] (although some leading and/or trailing bits may not be
-      significant),
-
-   o  a domain name, if the prefix length is not zero.
-
-   The domain name MUST be absent if the prefix length is zero.  The
-   IPv6 address MAY be be absent if the prefix length is 128.  A number
-   of leading address bits equal to the prefix length SHOULD be zero,
-   either implicitly (through the :: notation) or explicitly, as
-   specified in section 3.1.1.
-
-3.1.4.  Name Resolution Procedure
-
-   To obtain the IPv6 address or addresses which belong to a given name,
-   a DNS client MUST obtain one or more complete chains of A6 records,
-   each chain beginning with a record owned by the given name and
-   including a record owned by the prefix name in that record, and so on
-   recursively, ending with an A6 record with a prefix length of zero.
-   One IPv6 address is formed from one such chain by taking the value of
-   each bit position from the earliest A6 record in the chain which
-   validly covers that position, as indicated by the prefix length.  The
-   set of all IPv6 addresses for the given name comprises the addresses
-   formed from all complete chains of A6 records beginning at that name,
-   discarding records which have invalid prefix lengths as defined in
-   section 3.1.2.
-
-   If some A6 queries fail and others succeed, a client might obtain a
-   non-empty but incomplete set of IPv6 addresses for a host.  In many
-   situations this may be acceptable.  The completeness of a set of A6
-   records may always be determined by inspection.
-
-3.2.  Zone Structure for Reverse Lookups
-
-   Very little of the new scheme's data actually appears under IP6.ARPA;
-   only the first level of delegation needs to be under that domain.
-   More levels of delegation could be placed under IP6.ARPA if some
-   top-level delegations were done via NS records instead of DNAME
-   records, but this would incur some cost in renumbering ease at the
-
-
-
-Crawford, et al.            Standards Track                     [Page 7]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   level of TLAs [AGGR].  Therefore, it is declared here that all
-   address space delegations SHOULD be done by the DNAME mechanism
-   rather than NS.
-
-   In addition, since uniformity in deployment will simplify maintenance
-   of address delegations, it is SUGGESTED that address and prefix
-   information be stored immediately below a DNS label "IP6".  Stated
-   another way, conformance with this suggestion would mean that "IP6"
-   is the first label in the RDATA field of DNAME records which support
-   IPv6 reverse lookups.
-
-   When any "reserved" or "must be zero" bits are adjacent to a
-   delegation boundary, the higher-level entity MUST retain those bits
-   in its own control and delegate only the bits over which the lower-
-   level entity has authority.
-
-   To find the name of a node given its IPv6 address, a DNS client MUST
-   perform a query with QCLASS=IN, QTYPE=PTR on the name formed from the
-   128 bit address as one or more bit-string labels [BITLBL], followed
-   by the two standard labels "IP6.ARPA".  If recursive service was not
-   obtained from a server and the desired PTR record was not returned,
-   the resolver MUST handle returned DNAME records as specified in
-   [DNAME], and NS records as specified in [DNSCF], and iterate.
-
-4.  Modifications to Existing Query Types
-
-   All existing query types that perform type A additional section
-   processing, i.e. the name server (NS), mail exchange (MX), and
-   mailbox (MB) query types, and the experimental AFS data base (AFSDB)
-   and route through (RT) types, must be redefined to perform type A, A6
-   and AAAA additional section processing, with type A having the
-   highest priority for inclusion and type AAAA the lowest.  This
-   redefinition means that a name server may add any relevant IPv4 and
-   IPv6 address information available locally to the additional section
-   of a response when processing any one of the above queries.  The
-   recursive inclusion of A6 records referenced by A6 records already
-   included in the additional section is OPTIONAL.
-
-5.  Usage Illustrations
-
-   This section provides examples of use of the mechanisms defined in
-   the previous section.  All addresses and domains mentioned here are
-   intended to be fictitious and for illustrative purposes only.
-   Example delegations will be on 4-bit boundaries solely for
-   readability; this specification is indifferent to bit alignment.
-
-   Use of the IPv6 aggregatable address format [AGGR] is assumed in the
-   examples.
-
-
-
-Crawford, et al.            Standards Track                     [Page 8]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-5.1.  A6 Record Chains
-
-   Let's take the example of a site X that is multi-homed to two
-   "intermediate" providers A and B.  The provider A is itself multi-
-   homed to two "transit" providers, C and D.  The provider B gets its
-   transit service from a single provider, E.  For simplicity suppose
-   that C, D and E all belong to the same top-level aggregate (TLA) with
-   identifier (including format prefix) '2345', and the TLA authority at
-   ALPHA-TLA.ORG assigns to C, D and E respectively the next level
-   aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 and
-   2345:000E::/32.
-
-   C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the
-   prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to
-   B.
-
-   A assigns to X the subscriber identification '11' and B assigns the
-   subscriber identification '22'.  As a result, the site X inherits
-   three address prefixes:
-
-   o  2345:00C1:CA11::/48 from A, for routes through C.
-   o  2345:00D2:DA11::/48 from A, for routes through D.
-   o  2345:000E:EB22::/48 from B, for routes through E.
-
-   Let us suppose that N is a node in the site X, that it is assigned to
-   subnet number 1 in this site, and that it uses the interface
-   identifier '1234:5678:9ABC:DEF0'.  In our configuration, this node
-   will have three addresses:
-
-   o  2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
-   o  2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
-   o  2345:000E:EB22:0001:1234:5678:9ABC:DEF0
-
-5.1.1.  Authoritative Data
-
-   We will assume that the site X is represented in the DNS by the
-   domain name X.EXAMPLE, while A, B, C, D and E are represented by
-   A.NET, B.NET, C.NET, D.NET and E.NET.  In each of these domains, we
-   assume a subdomain "IP6" that will hold the corresponding prefixes.
-   The node N is identified by the domain name N.X.EXAMPLE.  The
-   following records would then appear in X's DNS.
-
-          $ORIGIN X.EXAMPLE.
-          N            A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
-          SUBNET-1.IP6 A6 48 0:0:0:1::  IP6
-          IP6          A6 48 0::0       SUBSCRIBER-X.IP6.A.NET.
-          IP6          A6 48 0::0       SUBSCRIBER-X.IP6.B.NET.
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 9]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   And elsewhere there would appear
-
-        SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
-        SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
-
-        SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
-
-        A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
-
-        A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
-
-        B-NET.IP6.E.NET. A6 32 0:0:EB00::    E.NET.ALPHA-TLA.ORG.
-
-        C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
-        D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
-        E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
-
-5.1.2.  Glue
-
-   When, as is common, some or all DNS servers for X.EXAMPLE are within
-   the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry
-   enough "glue" information to enable DNS clients to reach those
-   nameservers.  This is true in IPv6 just as in IPv4.  However, the A6
-   record affords the DNS administrator some choices.  The glue could be
-   any of
-
-   o  a minimal set of A6 records duplicated from the X.EXAMPLE zone,
-
-   o  a (possibly smaller) set of records which collapse the structure
-      of that minimal set,
-
-   o  or a set of A6 records with prefix length zero, giving the entire
-      global addresses of the servers.
-
-   The trade-off is ease of maintenance against robustness.  The best
-   and worst of both may be had together by implementing either the
-   first or second option together with the third.  To illustrate the
-   glue options, suppose that X.EXAMPLE is served by two nameservers
-   NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers
-   ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively.
-   Then the top-level zone EXAMPLE would include one (or more) of the
-   following sets of A6 records as glue.
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 10]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   $ORIGIN EXAMPLE.            ; first option
-   X               NS NS1.X
-                   NS NS2.X
-   NS1.X           A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
-   NS2.X           A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
-   SUBNET-1.IP6.X  A6 48 0:0:0:1::       IP6.X
-   SUBNET-2.IP6.X  A6 48 0:0:0:2::       IP6.X
-   IP6.X           A6 48 0::0            SUBSCRIBER-X.IP6.A.NET.
-   IP6.X           A6 48 0::0            SUBSCRIBER-X.IP6.B.NET.
-
-
-   $ORIGIN EXAMPLE.            ; second option
-   X               NS NS1.X
-                   NS NS2.X
-   NS1.X           A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
-                   A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.
-   NS2.X           A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
-                   A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
-
-
-   $ORIGIN EXAMPLE.            ; third option
-   X               NS NS1.X
-                   NS NS2.X
-   NS1.X           A6 0  2345:00C1:CA11:1:1:11:111:1111
-                   A6 0  2345:00D2:DA11:1:1:11:111:1111
-                   A6 0  2345:000E:EB22:1:1:11:111:1111
-   NS2.X           A6 0  2345:00C1:CA11:2:2:22:222:2222
-                   A6 0  2345:00D2:DA11:2:2:22:222:2222
-                   A6 0  2345:000E:EB22:2:2:22:222:2222
-
-   The first and second glue options are robust against renumbering of
-   X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if
-   those providers' own DNS is unreachable.  The glue records of the
-   third option are robust against DNS failures elsewhere than the zones
-   EXAMPLE and X.EXAMPLE themselves, but must be updated when X's
-   address space is renumbered.
-
-   If the EXAMPLE zone includes redundant glue, for instance the union
-   of the A6 records of the first and third options, then under normal
-   circumstances duplicate IPv6 addresses will be derived by DNS
-   clients.  But if provider DNS fails, addresses will still be obtained
-   from the zero-prefix-length records, while if the EXAMPLE zone lags
-   behind a renumbering of X.EXAMPLE, half of the addresses obtained by
-   DNS clients will still be up-to-date.
-
-   The zero-prefix-length glue records can of course be automatically
-   generated and/or checked in practice.
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 11]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-5.1.3.  Variations
-
-   Several more-or-less arbitrary assumptions are reflected in the above
-   structure.  All of the following choices could have been made
-   differently, according to someone's notion of convenience or an
-   agreement between two parties.
-
-      First, that site X has chosen to put subnet information in a
-      separate A6 record rather than incorporate it into each node's A6
-      records.
-
-      Second, that site X is referred to as "SUBSCRIBER-X" by both of
-      its providers A and B.
-
-      Third, that site X chose to indirect its provider information
-      through A6 records at IP6.X.EXAMPLE containing no significant
-      bits.  An alternative would have been to replicate each subnet
-      record for each provider.
-
-      Fourth, B and E used a slightly different prefix naming convention
-      between themselves than did A, C and D.  Each hierarchical pair of
-      network entities must arrange this naming between themselves.
-
-      Fifth, that the upward prefix referral chain topped out at ALPHA-
-      TLA.ORG.  There could have been another level which assigned the
-      TLA values and holds A6 records containing those bits.
-
-   Finally, the above structure reflects an assumption that address
-   fields assigned by a given entity are recorded only in A6 records
-   held by that entity.  Those bits could be entered into A6 records in
-   the lower-level entity's zone instead, thus:
-
-                IP6.X.EXAMPLE. A6 40 0:0:11::   IP6.A.NET.
-                IP6.X.EXAMPLE. A6 40 0:0:22::   IP6.B.NET.
-
-                IP6.A.NET.     A6 28 0:1:CA00:: IP6.C.NET.
-                and so on.
-
-   Or the higher-level entities could hold both sorts of A6 records
-   (with different DNS owner names) and allow the lower-level entities
-   to choose either mode of A6 chaining.  But the general principle of
-   avoiding data duplication suggests that the proper place to store
-   assigned values is with the entity that assigned them.
-
-   It is possible, but not necessarily recommended, for a zone
-   maintainer to forego the renumbering support afforded by the chaining
-   of A6 records and to record entire IPv6 addresses within one zone
-   file.
-
-
-
-Crawford, et al.            Standards Track                    [Page 12]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-5.2.  Reverse Mapping Zones
-
-   Supposing that address space assignments in the TLAs with Format
-   Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
-   zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
-   the IP6.ARPA zone would include
-
-               $ORIGIN IP6.ARPA.
-               \[x234500/24]   DNAME   IP6.ALPHA-TLA.ORG.
-               \[x267800/24]   DNAME   IP6.BRAVO-TLA.ORG.
-               \[x29AB00/24]   DNAME   IP6.CHARLIE-TLA.XY.
-
-   Eight trailing zero bits have been included in each TLA ID to reflect
-   the eight reserved bits in the current aggregatable global unicast
-   addresses format [AGGR].
-
-5.2.1.  The TLA level
-
-   ALPHA-TLA's assignments to network providers C, D and E are reflected
-   in the reverse data as follows.
-
-              \[xC/4].IP6.ALPHA-TLA.ORG.   DNAME  IP6.C.NET.
-              \[xD/4].IP6.ALPHA-TLA.ORG.   DNAME  IP6.D.NET.
-              \[x0E/8].IP6.ALPHA-TLA.ORG.  DNAME  IP6.E.NET.
-
-5.2.2.  The ISP level
-
-   The providers A through E carry the following delegation information
-   in their zone files.
-
-               \[x1CA/12].IP6.C.NET.  DNAME  IP6.A.NET.
-               \[x2DA/12].IP6.D.NET.  DNAME  IP6.A.NET.
-               \[xEB/8].IP6.E.NET.    DNAME  IP6.B.NET.
-               \[x11/8].IP6.A.NET.    DNAME  IP6.X.EXAMPLE.
-               \[x22/8].IP6.B.NET.    DNAME  IP6.X.EXAMPLE.
-
-   Note that some domain names appear in the RDATA of more than one
-   DNAME record.  In those cases, one zone is being used to map multiple
-   prefixes.
-
-5.2.3.  The Site Level
-
-   Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
-   name translations.  This domain is now referenced by two different
-   DNAME records held by two different providers.
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 13]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-           $ORIGIN IP6.X.EXAMPLE.
-           \[x0001/16]                    DNAME   SUBNET-1
-           \[x123456789ABCDEF0].SUBNET-1  PTR     N.X.EXAMPLE.
-           and so on.
-
-   SUBNET-1 need not have been named in a DNAME record; the subnet bits
-   could have been joined with the interface identifier.  But if subnets
-   are treated alike in both the A6 records and in the reverse zone, it
-   will always be possible to keep the forward and reverse definition
-   data for each prefix in one zone.
-
-5.3.  Lookups
-
-   A DNS resolver looking for a hostname for the address
-   2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
-   DNAME records shown above and would form new queries.  Assuming that
-   it began the process knowing servers for IP6.ARPA, but that no server
-   it consulted provided recursion and none had other useful additional
-   information cached, the sequence of queried names and responses would
-   be (all with QCLASS=IN, QTYPE=PTR):
-
-   To a server for IP6.ARPA:
-   QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
-
-        Answer:
-        \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
-
-   To a server for IP6.ALPHA-TLA.ORG:
-   QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
-
-        Answer:
-        \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
-
-   To a server for IP6.C.NET.:
-   QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
-
-        Answer:
-        \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
-
-   To a server for IP6.A.NET.:
-   QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
-
-        Answer:
-        \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
-
-   To a server for IP6.X.EXAMPLE.:
-   QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 14]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-        Answer:
-        \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
-        \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
-
-   All the DNAME (and NS) records acquired along the way can be cached
-   to expedite resolution of addresses topologically near to this
-   address.  And if another global address of N.X.EXAMPLE were resolved
-   within the TTL of the final PTR record, that record would not have to
-   be fetched again.
-
-5.4.  Operational Note
-
-   In the illustrations in section 5.1, hierarchically adjacent
-   entities, such as a network provider and a customer, must agree on a
-   DNS name which will own the definition of the delegated prefix(es).
-   One simple convention would be to use a bit-string label representing
-   exactly the bits which are assigned to the lower-level entity by the
-   higher.  For example, "SUBSCRIBER-X" could be replaced by "\[x11/8]".
-   This would place the A6 record(s) defining the delegated prefix at
-   exactly the same point in the DNS tree as the DNAME record associated
-   with that delegation.  The cost of this simplification is that the
-   lower-level zone must update its upward-pointing A6 records when it
-   is renumbered.  This cost may be found quite acceptable in practice.
-
-6.  Transition from RFC 1886 and Deployment Notes
-
-   When prefixes have been "delegated upward" with A6 records, the
-   number of DNS resource records required to establish a single IPv6
-   address increases by some non-trivial factor.  Those records will
-   typically, but not necessarily, come from different DNS zones (which
-   can independently suffer failures for all the usual reasons).  When
-   obtaining multiple IPv6 addresses together, this increase in RR count
-   will be proportionally less -- and the total size of a DNS reply
-   might even decrease -- if the addresses are topologically clustered.
-   But the records could still easily exceed the space available in a
-   UDP response which returns a large RRset [DNSCLAR] to an MX, NS, or
-   SRV query, for example.  The possibilities for overall degradation of
-   performance and reliability of DNS lookups are numerous, and increase
-   with the number of prefix delegations involved, especially when those
-   delegations point to records in other zones.
-
-   DNS Security [DNSSEC] addresses the trustworthiness of cached data,
-   which is a problem intrinsic to DNS, but the cost of applying this to
-   an IPv6 address is multiplied by a factor which may be greater than
-   the number of prefix delegations involved if different signature
-   chains must be verified for different A6 records.  If a trusted
-   centralized caching server (as in [TSIG], for example) is used, this
-   cost might be amortized to acceptable levels.  One new phenomenon is
-
-
-
-Crawford, et al.            Standards Track                    [Page 15]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   the possibility that IPv6 addresses may be formed from a A6 records
-   from a combination of secure and unsecured zones.
-
-   Until more deployment experience is gained with the A6 record, it is
-   recommended that prefix delegations be limited to one or two levels.
-   A reasonable phasing-in mechanism would be to start with no prefix
-   delegations (all A6 records having prefix length 0) and then to move
-   to the use of a single level of delegation within a single zone.  (If
-   the TTL of the "prefix" A6 records is kept to an appropriate duration
-   the capability for rapid renumbering is not lost.)  More aggressively
-   flexible delegation could be introduced for a subset of hosts for
-   experimentation.
-
-6.1.  Transition from AAAA and Coexistence with A Records
-
-   Administrators of zones which contain A6 records can easily
-   accommodate deployed resolvers which understand AAAA records but not
-   A6 records.  Such administrators can do automatic generation of AAAA
-   records for all of a zone's names which own A6 records by a process
-   which mimics the resolution of a hostname to an IPv6 address (see
-   section 3.1.4).  Attention must be paid to the TTL assigned to a
-   generated AAAA record, which MUST be no more than the minimum of the
-   TTLs of the A6 records that were used to form the IPv6 address in
-   that record.  For full robustness, those A6 records which were in
-   different zones should be monitored for changes (in TTL or RDATA)
-   even when there are no changes to zone for which AAAA records are
-   being generated.  If the zone is secure [DNSSEC], the generated AAAA
-   records MUST be signed along with the rest of the zone data.
-
-   A zone-specific heuristic MAY be used to avoid generation of AAAA
-   records for A6 records which record prefixes, although such
-   superfluous records would be relatively few in number and harmless.
-   Examples of such heuristics include omitting A6 records with a prefix
-   length less than the largest value found in the zone file, or records
-   with an address suffix field with a certain number of trailing zero
-   bits.
-
-   On the client side, when looking up and IPv6 address, the order of A6
-   and AAAA queries MAY be configurable to be one of: A6, then AAAA;
-   AAAA, then A6; A6 only; or both in parallel.  The default order (or
-   only order, if not configurable) MUST be to try A6 first, then AAAA.
-   If and when the AAAA becomes deprecated a new document will change
-   the default.
-
-   The guidelines and options for precedence between IPv4 and IPv6
-   addresses are specified in [TRANS].  All mentions of AAAA records in
-   that document are henceforth to be interpreted as meaning A6 and/or
-   AAAA records in the order specified in the previous paragraph.
-
-
-
-Crawford, et al.            Standards Track                    [Page 16]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-6.2.  Transition from Nibble Labels to Binary Labels
-
-   Implementations conforming to RFC 1886 [AAAA] perform reverse lookups
-   as follows:
-
-      An IPv6 address is represented as a name in the IP6.INT domain by
-      a sequence of nibbles separated by dots with the suffix
-      ".IP6.INT". The sequence of nibbles is encoded in reverse order,
-      i.e. the low-order nibble is encoded first, followed by the next
-      low-order nibble and so on. Each nibble is represented by a
-      hexadecimal digit. For example, a name for the address
-      2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in section
-      5.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-
-      8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
-
-   Implementations conforming to this specification will perform a
-   lookup of a binary label in IP6.ARPA as specified in Section 3.2.  It
-   is RECOMMENDED that for a transition period implementations first
-   lookup the binary label in IP6.ARPA and if this fails try to lookup
-   the 'nibble' label in IP6.INT.
-
-7.  Security Considerations
-
-   The signing authority [DNSSEC] for the A6 records which determine an
-   IPv6 address is distributed among several entities, reflecting the
-   delegation path of the address space which that address occupies.
-   DNS Security is fully applicable to bit-string labels and DNAME
-   records.  And just as in IPv4, verification of name-to-address
-   mappings is logically independent of verification of address-to-name
-   mappings.
-
-   With or without DNSSEC, the incomplete but non-empty address set
-   scenario of section 3.1.4 could be caused by selective interference
-   with DNS lookups.  If in some situation this would be more harmful
-   than complete DNS failure, it might be mitigated on the client side
-   by refusing to act on an incomplete set, or on the server side by
-   listing all addresses in A6 records with prefix length 0.
-
-8.  IANA Considerations
-
-   The A6 resource record has been assigned a Type value of 38.
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 17]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-9.  Acknowledgments
-
-   The authors would like to thank the following persons for valuable
-   discussions and reviews:  Mark Andrews, Rob Austein, Jim Bound, Randy
-   Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont,
-   Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden,
-   Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik
-   Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
-
-10.  References
-
-   [AAAA]    Thomson, S. and C. Huitema, "DNS Extensions to support IP
-             version 6, RFC 1886, December 1995.
-
-   [AARCH]   Hinden, R. and S. Deering, "IP Version 6 Addressing
-             Architecture", RFC 2373, July 1998.
-
-   [AGGR]    Hinden, R., O'Dell, M. and S. Deering, "An IPv6
-             Aggregatable Global Unicast Address Format", RFC 2374, July
-             1998.
-
-   [BITLBL]  Crawford, M., "Binary Labels in the Domain Name System",
-             RFC 2673, August 1999.
-
-   [DNAME]   Crawford, M., "Non-Terminal DNS Name Redirection", RFC
-             2672, August 1999.
-
-   [DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS
-             Specification", RFC 2181, July 1997.
-
-   [DNSIS]   Mockapetris, P., "Domain names - implementation and
-             specification", STD 13, RFC 1035, November 1987.
-
-   [DNSSEC]  Eastlake, D. 3rd and C. Kaufman, "Domain Name System
-             Security Extensions", RFC 2535, March 1999.
-
-   [KWORD]   Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RENUM1]  Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
-             1900, February 1996.
-
-   [RENUM2]  Ferguson, P. and H. Berkowitz, "Network Renumbering
-             Overview:  Why would I want it and what is it anyway?", RFC
-             2071, January 1997.
-
-   [RENUM3]  Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
-             Behaviour Today", RFC 2101, February 1997.
-
-
-
-Crawford, et al.            Standards Track                    [Page 18]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   [TRANS]   Gilligan, R. and E. Nordmark, "Transition Mechanisms for
-             IPv6 Hosts and Routers", RFC 1933, April 1996.
-
-   [TSIG]    Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
-             Wellington, "Secret Key Transaction Authentication for DNS
-             (TSIG)", RFC 2845, May 2000.
-
-11.  Authors' Addresses
-
-   Matt Crawford
-   Fermilab
-   MS 368
-   PO Box 500
-   Batavia, IL 60510
-   USA
-
-   Phone: +1 630 840-3461
-   EMail: crawdad@fnal.gov
-
-
-   Christian Huitema
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052-6399
-
-   EMail: huitema@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 19]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-12.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 20]
-
diff --git a/doc/rfc/rfc2915.txt b/doc/rfc/rfc2915.txt
deleted file mode 100644
index 2022ba11..00000000
--- a/doc/rfc/rfc2915.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Mealling
-Request for Comments: 2915                        Network Solutions, Inc.
-Updates: 2168                                                   R. Daniel
-Category: Standards Track                                DATAFUSION, Inc.
-                                                           September 2000
-
-
-        The Naming Authority Pointer (NAPTR) DNS Resource Record
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Abstract
-
-   This document describes a Domain Name System (DNS) resource record
-   which specifies a regular expression based rewrite rule that, when
-   applied to an existing string, will produce a new domain label or
-   Uniform Resource Identifier (URI).  Depending on the value of the
-   flags field of the resource record, the resulting domain label or URI
-   may be used in subsequent queries for the Naming Authority Pointer
-   (NAPTR) resource records (to delegate the name lookup) or as the
-   output of the entire process for which this system is used (a
-   resolution server for URI resolution, a service URI for ENUM style
-   e.164 number to URI mapping, etc).
-
-   This allows the DNS to be used to lookup services for a wide variety
-   of resource names (including URIs) which are not in domain name
-   syntax.  Reasons for doing this range from URN Resource Discovery
-   Systems to moving out-of-date services to new domains.
-
-   This document updates the portions of RFC 2168 specifically dealing
-   with the definition of the NAPTR records and how other, non-URI
-   specific applications, might use NAPTR.
-
-
-
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 1]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
-   2.  NAPTR RR Format  . . . . . . . . . . . . . . . . . . . . . .   3
-   3.  Substitution Expression Grammar  . . . . . . . . . . . . . .   7
-   4.  The Basic NAPTR Algorithm  . . . . . . . . . . . . . . . . .   8
-   5.  Concerning How NAPTR Uses SRV Records  . . . . . . . . . . .   9
-   6.  Application Specifications . . . . . . . . . . . . . . . . .  10
-   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  10
-   7.1 Example 1  . . . . . . . . . . . . . . . . . . . . . . . . .  10
-   7.2 Example 2  . . . . . . . . . . . . . . . . . . . . . . . . .  12
-   7.3 Example 3  . . . . . . . . . . . . . . . . . . . . . . . . .  13
-   8.  DNS Packet Format  . . . . . . . . . . . . . . . . . . . . .  13
-   9.  Master File Format . . . . . . . . . . . . . . . . . . . . .  14
-   10. Advice for DNS Administrators  . . . . . . . . . . . . . . .  14
-   11. Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
-   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
-   13. Security Considerations  . . . . . . . . . . . . . . . . . .  15
-   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  16
-       References . . . . . . . . . . . . . . . . . . . . . . . . .  16
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17
-       Full Copyright Statement . . . . . . . . . . . . . . . . . .  18
-
-1. Introduction
-
-   This RR was originally produced by the URN Working Group [3] as a way
-   to encode rule-sets in DNS so that the delegated sections of a URI
-   could be decomposed in such a way that they could be changed and re-
-   delegated over time.  The result was a Resource Record that included
-   a regular expression that would be used by a client program to
-   rewrite a string into a domain name.  Regular expressions were chosen
-   for their compactness to expressivity ratio allowing for a great deal
-   of information to be encoded in a rather small DNS packet.
-
-   The function of rewriting a string according to the rules in a record
-   has usefulness in several different applications.  This document
-   defines the basic assumptions to which all of those applications must
-   adhere to.  It does not define the reasons the rewrite is used, what
-   the expected outcomes are, or what they are used for.  Those are
-   specified by applications that define how they use the NAPTR record
-   and algorithms within their contexts.
-
-   Flags and other fields are also specified in the RR to control the
-   rewrite procedure in various ways or to provide information on how to
-   communicate with the host at the domain name that was the result of
-   the rewrite.
-
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 2]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   The final result is a RR that has several fields that interact in a
-   non-trivial but implementable way.  This document specifies those
-   fields and their values.
-
-   This document does not define applications that utilizes this rewrite
-   functionality. Instead it specifies just the mechanics of how it is
-   done.  Why its done, what the rules concerning the inputs, and the
-   types of rules used are reserved for other documents that fully
-   specify a particular application.  This separation is due to several
-   different applications all wanting to take advantage of the rewrite
-   rule lookup process.  Each one has vastly different reasons for why
-   and how it uses the service, thus requiring that the definition of
-   the service be generic.
-
-      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
-      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
-      in this document are to be interpreted as described in RFC 2119.
-
-      All references to Uniform Resource Identifiers in this document
-      adhere to the 'absoluteURI' production of the "Collected ABNF"
-      found in RFC 2396 [9].  Specifically, the semantics of URI
-      References do not apply since the concept of a Base makes no sense
-      here.
-
-2. NAPTR RR Format
-
-   The format of the NAPTR RR is given below.  The DNS type code [1] for
-   NAPTR is 35.
-
-   Domain TTL Class Type Order Preference Flags Service Regexp
-   Replacement
-
-   Domain
-      The domain name to which this resource record refers.  This is the
-      'key' for this entry in the rule database.  This value will either
-      be the first well known key (<something>.uri.arpa for example) or
-      a new key that is the output of a replacement or regexp rewrite.
-      Beyond this, it has the standard DNS requirements [1].
-
-   TTL
-      Standard DNS meaning [1].
-
-   Class
-      Standard DNS meaning [1].
-
-   Type
-      The Type Code [1] for NAPTR is 35.
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 3]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   Order
-      A 16-bit unsigned integer specifying the order in which the NAPTR
-      records MUST be processed to ensure the correct ordering of
-      rules.  Low numbers are processed before high numbers, and once a
-      NAPTR is found whose rule "matches" the target, the client MUST
-      NOT consider any NAPTRs with a higher value for order (except as
-      noted below for the Flags field).
-
-   Preference
-      A 16-bit unsigned integer that specifies the order in which NAPTR
-      records with equal "order" values SHOULD be processed, low
-      numbers being processed before high numbers.  This is similar to
-      the preference field in an MX record, and is used so domain
-      administrators can direct clients towards more capable hosts or
-      lighter weight protocols.  A client MAY look at records with
-      higher preference values if it has a good reason to do so such as
-      not understanding the preferred protocol or service.
-
-      The important difference between Order and Preference is that
-      once a match is found the client MUST NOT consider records with a
-      different Order but they MAY process records with the same Order
-      but different Preferences.  I.e., Preference is used to give weight
-      to rules that are considered the same from an authority
-      standpoint but not from a simple load balancing standpoint.
-
-   Flags
-      A <character-string> containing flags to control aspects of the
-      rewriting and interpretation of the fields in the record.  Flags
-      are single characters from the set [A-Z0-9].  The case of the
-      alphabetic characters is not significant.
-
-      At this time only four flags, "S", "A", "U", and "P", are
-      defined.  The "S", "A" and "U" flags denote a terminal lookup.
-      This means that this NAPTR record is the last one and that the
-      flag determines what the next stage should be.  The "S" flag
-      means that the next lookup should be for SRV records [4].  See
-      Section 5 for additional information on how NAPTR uses the SRV
-      record type.  "A" means that the next lookup should be for either
-      an A, AAAA, or A6 record.  The "U" flag means that the next step
-      is not a DNS lookup but that the output of the Regexp field is an
-      URI that adheres to the 'absoluteURI' production found in the
-      ABNF of RFC 2396 [9].  Since there may be applications that use
-      NAPTR to also lookup aspects of URIs, implementors should be
-      aware that this may cause loop conditions and should act
-      accordingly.
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 4]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-      The "P" flag says that the remainder of the application side
-      algorithm shall be carried out in a Protocol-specific fashion.
-      The new set of rules is identified by the Protocol specified in
-      the Services field.  The record that contains the 'P' flag is the
-      last record that is interpreted by the rules specified in this
-      document.  The new rules are dependent on the application for
-      which they are being used and the protocol specified.  For
-      example, if the application is a URI RDS and the protocol is WIRE
-      then the new set of rules are governed by the algorithms
-      surrounding the WIRE HTTP specification and not this document.
-
-      The remaining alphabetic flags are reserved for future versions
-      of the NAPTR specification.  The numeric flags may be used for
-      local experimentation.  The S, A, U and P flags are all mutually
-      exclusive, and resolution libraries MAY signal an error if more
-      than one is given.  (Experimental code and code for assisting in
-      the creation of NAPTRs would be more likely to signal such an
-      error than a client such as a browser).  It is anticipated that
-      multiple flags will be allowed in the future, so implementers
-      MUST NOT assume that the flags field can only contain 0 or 1
-      characters.  Finally, if a client encounters a record with an
-      unknown flag, it MUST ignore it and move to the next record.  This
-      test takes precedence even over the "order" field.  Since flags
-      can control the interpretation placed on fields, a novel flag
-      might change the interpretation of the regexp and/or replacement
-      fields such that it is impossible to determine if a record
-      matched a given target.
-
-      The "S", "A", and "U"  flags are called 'terminal' flags since
-      they halt the looping rewrite algorithm.  If those flags are not
-      present, clients may assume that another NAPTR RR exists at the
-      domain name produced by the current rewrite rule.  Since the "P"
-      flag specifies a new algorithm, it may or may not be 'terminal'.
-      Thus, the client cannot assume that another NAPTR exists since
-      this case is determined elsewhere.
-
-      DNS servers MAY interpret these flags and values and use that
-      information to include appropriate SRV and A,AAAA, or A6 records
-      in the additional information portion of the DNS packet.  Clients
-      are encouraged to check for additional information but are not
-      required to do so.
-
-   Service
-      Specifies the service(s) available down this rewrite path.  It may
-      also specify the particular protocol that is used to talk with a
-      service.  A protocol MUST be specified if the flags field states
-      that the NAPTR is terminal.  If a protocol is specified, but the
-      flags field does not state that the NAPTR is terminal, the next
-
-
-
-Mealling & Daniel           Standards Track                     [Page 5]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-      lookup MUST be for a NAPTR.  The client MAY choose not to perform
-      the next lookup if the protocol is unknown, but that behavior
-      MUST NOT be relied upon.
-
-      The service field may take any of the values below (using the
-      Augmented BNF of RFC 2234 [5]):
-
-                 service_field = [ [protocol] *("+" rs)]
-                 protocol      = ALPHA *31ALPHANUM
-                 rs            = ALPHA *31ALPHANUM
-                 ; The protocol and rs fields are limited to 32
-                 ; characters and must start with an alphabetic.
-
-      For example, an optional protocol specification followed by 0 or
-      more resolution services.  Each resolution service is indicated by
-      an initial '+' character.
-
-      Note that the empty string is also a valid service field.  This
-      will typically be seen at the beginning of a series of rules,
-      when it is impossible to know what services and protocols will be
-      offered by a particular service.
-
-      The actual format of the service request and response will be
-      determined by the resolution protocol, and is the subject for
-      other documents.  Protocols need not offer all services.  The
-      labels for service requests shall be formed from the set of
-      characters [A-Z0-9].  The case of the alphabetic characters is
-      not significant.
-
-      The list of "valid" protocols for any given NAPTR record is any
-      protocol that implements some or all of the services defined for
-      a NAPTR application.  Currently, THTTP [6] is the only protocol
-      that is known to make that claim at the time of publication.  Any
-      other protocol that is to be used must have documentation
-      specifying:
-
-      *  how it implements the services of the application
-
-      *  how it is to appear in the NAPTR record (i.e., the string id
-         of the protocol)
-
-      The list of valid Resolution Services is defined by the documents
-      that specify individual NAPTR based applications.
-
-      It is worth noting that the interpretation of this field is
-      subject to being changed by new flags, and that the current
-      specification is oriented towards telling clients how to talk
-      with a URN resolver.
-
-
-
-Mealling & Daniel           Standards Track                     [Page 6]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   Regexp
-      A STRING containing a substitution expression that is applied to
-      the original string held by the client in order to construct the
-      next domain name to lookup.  The grammar of the substitution
-      expression is given in the next section.
-
-      The regular expressions MUST NOT be used in a cumulative fashion,
-      that is, they should only be applied to the original string held
-      by the client, never to the domain name produced by a previous
-      NAPTR rewrite.  The latter is tempting in some applications but
-      experience has shown such use to be extremely fault sensitive,
-      very error prone, and extremely difficult to debug.
-
-   Replacement
-      The next NAME to query for NAPTR, SRV, or address records
-      depending on the value of the flags field.  This MUST be a fully
-      qualified domain-name. Unless and until permitted by future
-      standards action, name compression is not to be used for this
-      field.
-
-3. Substitution Expression Grammar
-
-   The content of the regexp field is a substitution expression.  True
-   sed(1) and Perl style substitution expressions are not appropriate
-   for use in this application for a variety of reasons stemming from
-   internationalization requirements and backref limitations, therefore
-   the contents of the regexp field MUST follow the grammar below:
-
-subst_expr   = delim-char  ere  delim-char  repl  delim-char  *flags
-delim-char   = "/" / "!" / ... <Any non-digit or non-flag character
-               other than backslash '\'. All occurances of a delim_char
-               in a subst_expr must be the same character.>
-ere          = POSIX Extended Regular Expression
-repl         = 1 * ( OCTET /  backref )
-backref      = "\" 1POS_DIGIT
-flags        = "i"
-POS_DIGIT    = %x31-39                 ; 0 is not an allowed backref
-
-   The definition of a POSIX Extended Regular Expression can be found in
-   [8], section 2.8.4.
-
-   The result of applying the substitution expression to the original
-   URI MUST result in either a string that obeys the syntax for DNS
-   domain-names [1] or a URI [9] if the Flags field contains a 'u'.
-   Since it is possible for the regexp field to be improperly specified,
-   such that a non-conforming domain-name can be constructed, client
-   software SHOULD verify that the result is a legal DNS domain-name
-   before making queries on it.
-
-
-
-Mealling & Daniel           Standards Track                     [Page 7]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   Backref expressions in the repl portion of the substitution
-   expression are replaced by the (possibly empty) string of characters
-   enclosed by '(' and ')' in the ERE portion of the substitution
-   expression. N is a single digit from 1 through 9, inclusive.  It
-   specifies the N'th backref expression, the one that begins with the
-   N'th '(' and continues to the matching ')'.  For example, the ERE
-
-                            (A(B(C)DE)(F)G)
-
-         has backref expressions:
-
-                            \1  = ABCDEFG
-                            \2  = BCDE
-                            \3  = C
-                            \4  = F
-                            \5..\9  = error - no matching subexpression
-
-   The "i" flag indicates that the ERE matching SHALL be performed in a
-   case-insensitive fashion. Furthermore, any backref replacements MAY
-   be normalized to lower case when the "i" flag is given.
-
-   The first character in the substitution expression shall be used as
-   the character that delimits the components of the substitution
-   expression.  There must be exactly three non-escaped occurrences of
-   the delimiter character in a substitution expression.  Since escaped
-   occurrences of the delimiter character will be interpreted as
-   occurrences of that character, digits MUST NOT be used as delimiters.
-   Backrefs would be confused with literal digits were this allowed.
-   Similarly, if flags are specified in the substitution expression, the
-   delimiter character must not also be a flag character.
-
-4. The Basic NAPTR Algorithm
-
-   The behavior and meaning of the flags and services assume an
-   algorithm where the output of one rewrite is a new key that points to
-   another rule.  This looping algorithm allows NAPTR records to
-   incrementally specify a complete rule.  These incremental rules can
-   be delegated which allows other entities to specify rules so that one
-   entity does not need to understand _all_ rules.
-
-   The algorithm starts with a string and some known key (domain).
-   NAPTR records for this key are retrieved, those with unknown Flags or
-   inappropriate Services are discarded and the remaining records are
-   sorted by their Order field.  Within each value of Order, the records
-   are further sorted by the Preferences field.
-
-   The records are examined in sorted order until a matching record is
-   found.  A record is considered a match iff:
-
-
-
-Mealling & Daniel           Standards Track                     [Page 8]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   o  it has a Replacement field value instead of a Regexp field value.
-
-   o  or the Regexp field matches the string held by the client.
-
-   The first match MUST be the match that is used.  Once a match is
-   found, the Services field is examined for whether or not this rule
-   advances toward the desired result.  If so, the rule is applied to
-   the target string.  If not, the process halts.  The domain that
-   results from the regular expression is then used as the domain of the
-   next loop through the NAPTR algorithm.  Note that the same target
-   string is used throughout the algorithm.
-
-   This looping is extremely important since it is the method by which
-   complex rules are broken down into manageable delegated chunks.  The
-   flags fields simply determine at which point the looping should stop
-   (or other specialized behavior).
-
-   Since flags are valid at any level of the algorithm, the degenerative
-   case is to never loop but to look up the NAPTR and then stop.  In
-   many specialized cases this is all that is needed.  Implementors
-   should be aware that the degenerative case should not become the
-   common case.
-
-5. Concerning How NAPTR Uses SRV Records
-
-   When the SRV record type was originally specified it assumed that the
-   client did not know the specific domain-name before hand.  The client
-   would construct a domain-name more in the form of a question than the
-   usual case of knowing ahead of time that the domain-name should
-   exist.  I.e., if the client wants to know if there is a TCP based
-   HTTP server running at a particular domain, the client would
-   construct the domain-name _http._tcp.somedomain.com and ask the DNS
-   if that records exists. The underscores are used to avoid collisions
-   with potentially 'real' domain-names.
-
-   In the case of NAPTR, the actual domain-name is specified by the
-   various fields in the NAPTR record.  In this case the client isn't
-   asking a question but is instead attempting to get at information
-   that it has been told exists in an SRV record at that particular
-   domain-name.  While this usage of SRV is slightly different than the
-   SRV authors originally intended it does not break any of the
-   assumptions concerning what SRV contains.  Also, since the NAPTR
-   explicitly spells out the domain-name for which an SRV exists, that
-   domain-name MUST be used in SRV queries with NO transformations.  Any
-   given NAPTR record may result in a domain-name to be used for SRV
-   queries that may or may not contain the SRV standardized underscore
-
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 9]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   characters.  NAPTR applications that make use of SRV MUST NOT attempt
-   to understand these domains or use them according to how the SRV
-   specification structures its query domains.
-
-6. Application Specifications
-
-   It should be noted that the NAPTR algorithm is the basic assumption
-   about how NAPTR works.  The reasons for the rewrite and the expected
-   output and its use are specified by documents that define what
-   applications the NAPTR record and algorithm are used for.  Any
-   document that defines such an application must define the following:
-
-   o  The first known domain-name or how to build it
-
-   o  The valid Services and Protocols
-
-   o  What the expected use is for the output of the last rewrite
-
-   o  The validity and/or behavior of any 'P' flag protocols.
-
-   o  The general semantics surrounding why and how NAPTR and its
-      algorithm are being used.
-
-7. Examples
-
-   NOTE: These are examples only.  They are taken from ongoing work and
-   may not represent the end result of that work. They are here for
-   pedagogical reasons only.
-
-7.1 Example 1
-
-   NAPTR was originally specified for use with the a Uniform Resource
-   Name Resolver Discovery System.  This example details how a
-   particular URN would use the NAPTR record to find a resolver service.
-
-   Consider a URN namespace based on MIME Content-Ids.  The URN might
-   look like this:
-
-      urn:cid:39CB83F7.A8450130@fake.gatech.edu
-
-   (Note that this example is chosen for pedagogical purposes, and does
-   not conform to the CID URL scheme.)
-
-   The first step in the resolution process is to find out about the CID
-   namespace.  The namespace identifier [3], 'cid', is extracted from
-   the URN, prepended to urn.arpa. 'cid.urn.arpa' then becomes the first
-   'known' key in the NAPTR algorithm.  The NAPTR records for
-   cid.urn.arpa looked up and return a single record:
-
-
-
-Mealling & Daniel           Standards Track                    [Page 10]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   cid.urn.arpa.
-   ;;       order pref flags service        regexp           replacement
-   IN NAPTR 100   10   ""  ""  "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i"    .
-
-   There is only one NAPTR response, so ordering the responses is not a
-   problem.  The replacement field is empty, so the pattern provided in
-   the regexp field is used.  We apply that regexp to the entire URN to
-   see if it matches, which it does.  The \2 part of the substitution
-   expression returns the string "gatech.edu".  Since the flags field
-   does not contain "s" or "a", the lookup is not terminal and our next
-   probe to DNS is for more NAPTR records where the new domain is '
-   gatech.edu' and the string is the same string as before.
-
-   Note that the rule does not extract the full domain name from the
-   CID, instead it assumes the CID comes from a host and extracts its
-   domain.  While all hosts, such as mordred, could have their very own
-   NAPTR, maintaining those records for all the machines at a site as
-   large as Georgia Tech would be an intolerable burden.  Wildcards are
-   not appropriate here since they only return results when there is no
-   exactly matching names already in the system.
-
-   The record returned from the query on "gatech.edu" might look like:
-
-;;       order pref flags service           regexp  replacement
- IN NAPTR 100  50  "s"  "z3950+I2L+I2C"     ""  _z3950._tcp.gatech.edu.
- IN NAPTR 100  50  "s"  "rcds+I2C"          ""  _rcds._udp.gatech.edu.
- IN NAPTR 100  50  "s"  "http+I2L+I2C+I2R"  ""  _http._tcp.gatech.edu.
-
-   Continuing with the example, note that the values of the order and
-   preference fields are equal in all records, so the client is free to
-   pick any record.  The flags field tells us that these are the last
-   NAPTR patterns we should see, and after the rewrite (a simple
-   replacement in this case) we should look up SRV records to get
-   information on the hosts that can provide the necessary service.
-
-   Assuming we prefer the Z39.50 protocol, our lookup might return:
-
- ;;                        Pref Weight   Port Target
- _z3950._tcp.gatech.edu. IN SRV 0    0      1000 z3950.gatech.edu.
-                         IN SRV 0    0      1000 z3950.cc.gatech.edu.
-                         IN SRV 0    0      1000 z3950.uga.edu.
-
-   telling us three hosts that could actually do the resolution, and
-   giving us the port we should use to talk to their Z39.50 server.
-
-   Recall that the regular expression used \2 to extract a domain name
-   from the CID, and \. for matching the literal '.' characters
-   separating the domain name components. Since '\' is the escape
-
-
-
-Mealling & Daniel           Standards Track                    [Page 11]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   character, literal occurances of a backslash must be escaped by
-   another backslash.  For the case of the cid.urn.arpa record above,
-   the regular expression entered into the master file should be
-   "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i".  When the client code actually
-   receives the record, the pattern will have been converted to
-   "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i".
-
-7.2 Example 2
-
-   Even if URN systems were in place now, there would still be a
-   tremendous number of URLs.  It should be possible to develop a URN
-   resolution system that can also provide location independence for
-   those URLs.  This is related to the requirement that URNs be able to
-   grandfather in names from other naming systems, such as ISO Formal
-   Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
-   etc.
-
-   The NAPTR RR could also be used for URLs that have already been
-   assigned.  Assume we have the URL for a very popular piece of
-   software that the publisher wishes to mirror at multiple sites around
-   the world:
-
-   Using the rules specified for this application we extract the prefix,
-   "http", and lookup NAPTR records for http.uri.arpa.  This might
-   return a record of the form
-
-     http.uri.arpa. IN NAPTR
-     ;;  order   pref flags service      regexp             replacement
-          100     90   ""      ""   "!http://([^/:]+)!\1!i"       .
-
-   This expression returns everything after the first double slash and
-   before the next slash or colon.  (We use the '!' character to delimit
-   the parts of the substitution expression.  Otherwise we would have to
-   use backslashes to escape the forward slashes and would have a regexp
-   in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".).
-
-   Applying this pattern to the URL extracts "www.foo.com".  Looking up
-   NAPTR records for that might return:
-
-     www.foo.com.
-     ;;       order pref flags   service  regexp     replacement
-      IN NAPTR 100  100  "s"   "http+I2R"   ""    _http._tcp.foo.com.
-      IN NAPTR 100  100  "s"   "ftp+I2R"    ""    _ftp._tcp.foo.com.
-
-   Looking up SRV records for http.tcp.foo.com would return information
-   on the hosts that foo.com has designated to be its mirror sites.  The
-   client can then pick one for the user.
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 12]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-7.3 Example 3
-
-   A non-URI example is the ENUM application which uses a NAPTR record
-   to map an e.164 telephone number to a URI.  In order to convert the
-   phone number to a domain name for the first iteration all characters
-   other than digits are removed from the the telephone number, the
-   entire number is inverted, periods are put between each digit and the
-   string ".e164.arpa" is put on the left-hand side.  For example, the
-   E.164 phone number "+1-770-555-1212" converted to a domain-name it
-   would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa."
-
-   For this example telephone number we might get back the following
-   NAPTR records:
-
-$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
- IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:information@tele2.se!"     .
- IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information@tele2.se!"  .
-
-   This application uses the same 'u' flag as the URI Resolution
-   application. This flag states that the Rule is terminal and that the
-   output is a URI which contains the information needed to contact that
-   telephone service.  ENUM also uses the same format for its Service
-   field except that it defines the 'E2U' service instead of the 'I2*'
-   services that URI resolution uses.  The example above states that the
-   available protocols used to access that telephone's service are
-   either the Session Initiation Protocol or SMTP mail.
-
-8. DNS Packet Format
-
-         The packet format for the NAPTR record is:
-
-                                          1  1  1  1  1  1
-            0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          |                     ORDER                     |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          |                   PREFERENCE                  |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                     FLAGS                     /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                   SERVICES                    /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                    REGEXP                     /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                  REPLACEMENT                  /
-          /                                               /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 13]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-    where:
-
-   FLAGS A <character-string> which contains various flags.
-
-   SERVICES A <character-string> which contains protocol and service
-      identifiers.
-
-   REGEXP A <character-string> which contains a regular expression.
-
-   REPLACEMENT A <domain-name> which specifies the new value in the
-      case where the regular expression is a simple replacement
-      operation.
-
-   <character-string> and <domain-name> as used here are defined in
-   RFC1035 [1].
-
-9. Master File Format
-
-   The master file format follows the standard rules in RFC-1035 [1].
-   Order and preference, being 16-bit unsigned integers, shall be an
-   integer between 0 and 65535.  The Flags and Services and Regexp
-   fields are all quoted <character-string>s.  Since the Regexp field
-   can contain numerous backslashes and thus should be treated with
-   care.  See Section 10 for how to correctly enter and escape the
-   regular expression.
-
-10. Advice for DNS Administrators
-
-   Beware of regular expressions.  Not only are they difficult to get
-   correct on their own, but there is the previously mentioned
-   interaction with DNS.  Any backslashes in a regexp must be entered
-   twice in a zone file in order to appear once in a query response.
-   More seriously, the need for double backslashes has probably not been
-   tested by all implementors of DNS servers.
-
-   The "a" flag allows the next lookup to be for address records (A,
-   AAAA, A6) rather than SRV records.  Since there is no place for a
-   port specification in the NAPTR record, when the "A" flag is used the
-   specified protocol must be running on its default port.
-
-   The URN Syntax draft defines a canonical form for each URN, which
-   requires %encoding characters outside a limited repertoire.  The
-   regular expressions MUST be written to operate on that canonical
-   form.  Since international character sets will end up with extensive
-   use of %encoded characters, regular expressions operating on them
-   will be essentially impossible to read or write by hand.
-
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 14]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-11. Notes
-
-   o  A client MUST process multiple NAPTR records in the order
-      specified by the "order" field, it MUST NOT simply use the first
-      record that provides a known protocol and service combination.
-
-   o  When multiple RRs have the same "order" and all other criteria
-      being equal, the client should use the value of the preference
-      field to select the next NAPTR to consider.  However, because it
-      will often be the case where preferred protocols or services
-      exist, clients may use this additional criteria to sort
-      the records.
-
-   o  If the lookup after a rewrite fails, clients are strongly
-      encouraged to report a failure, rather than backing up to pursue
-      other rewrite paths.
-
-   o  Note that SRV RRs impose additional requirements on clients.
-
-12. IANA Considerations
-
-   The only registration function that impacts the IANA is for the
-   values that are standardized for the Services and Flags fields.  To
-   extend the valid values of the Flags field beyond what is specified
-   in this document requires a published specification that is approved
-   by the IESG.
-
-   The values for the Services field will be determined by the
-   application that makes use of the NAPTR record.  Those values must be
-   specified in a published specification and approved by the IESG.
-
-13. Security Considerations
-
-   The interactions with DNSSEC are currently being studied.  It is
-   expected that NAPTR records will be signed with SIG records once the
-   DNSSEC work is deployed.
-
-   The rewrite rules make identifiers from other namespaces subject to
-   the same attacks as normal domain names.  Since they have not been
-   easily resolvable before, this may or may not be considered a
-   problem.
-
-   Regular expressions should be checked for sanity, not blindly passed
-   to something like PERL.
-
-   This document has discussed a way of locating a service, but has not
-   discussed any detail of how the communication with that service takes
-   place.  There are significant security considerations attached to the
-
-
-
-Mealling & Daniel           Standards Track                    [Page 15]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   communication with a service.  Those considerations are outside the
-   scope of this document, and must be addressed by the specifications
-   for particular communication protocols.
-
-14. Acknowledgments
-
-   The editors would like to thank Keith Moore for all his consultations
-   during the development of this memo.  We would also like to thank
-   Paul Vixie for his assistance in debugging our implementation, and
-   his answers on our questions.  Finally, we would like to acknowledge
-   our enormous intellectual debt to the participants in the Knoxville
-   series of meetings, as well as to the participants in the URI and URN
-   working groups.
-
-References
-
-   [1]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [2]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [3]  Moats, R., "URN Syntax", RFC 2141, May 1997.
-
-   [4]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
-        specifying the location of services (DNS SRV)", RFC 2782,
-        February 2000.
-
-   [5]  Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
-        RFC 2234, November 1997.
-
-   [6]  Daniel, R., "A Trivial Convention for using HTTP in URN
-        Resolution", RFC 2169, June 1997.
-
-   [7]  Daniel, R. and M. Mealling, "Resolution of Uniform Resource
-        Identifiers using the Domain Name System", RFC 2168, June 1997.
-
-   [8]  IEEE, "IEEE Standard for Information Technology - Portable
-        Operating System Interface (POSIX) - Part 2: Shell and Utilities
-        (Vol. 1)", IEEE Std 1003.2-1992, January 1993.
-
-   [9]  Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
-        Resource Identifiers (URI): Generic Syntax", RFC 2396, August
-        1998.
-
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 16]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-Authors' Addresses
-
-   Michael Mealling
-   Network Solutions, Inc.
-   505 Huntmar Park Drive
-   Herndon, VA  22070
-   US
-
-   Phone: +1 770 921 2251
-   EMail: michaelm@netsol.com
-   URI:   http://www.netsol.com
-
-
-   Ron Daniel
-   DATAFUSION, Inc.
-   139 Townsend Street, Ste. 100
-   San Francisco, CA  94107
-   US
-
-   Phone: +1 415 222 0100
-   EMail: rdaniel@datafusion.net
-   URI:   http://www.datafusion.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 17]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 18]
-
diff --git a/doc/rfc/rfc2929.txt b/doc/rfc/rfc2929.txt
deleted file mode 100644
index f0559689..00000000
--- a/doc/rfc/rfc2929.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   D. Eastlake, 3rd
-Request for Comments: 2929                                      Motorola
-BCP: 42                                              E. Brunner-Williams
-Category: Best Current Practice                                   Engage
-                                                              B. Manning
-                                                                     ISI
-                                                          September 2000
-
-              Domain Name System (DNS) IANA Considerations
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   Internet Assigned Number Authority (IANA) parameter assignment
-   considerations are given for the allocation of Domain Name System
-   (DNS) classes, Resource Record (RR) types, operation codes, error
-   codes, etc.
-
-Table of Contents
-
-   1. Introduction.................................................  2
-   2. DNS Query/Response Headers...................................  2
-   2.1 One Spare Bit?..............................................  3
-   2.2 Opcode Assignment...........................................  3
-   2.3 RCODE Assignment............................................  4
-   3. DNS Resource Records.........................................  5
-   3.1 RR TYPE IANA Considerations.................................  6
-   3.1.1 Special Note on the OPT RR................................  7
-   3.2 RR CLASS IANA Considerations................................  7
-   3.3 RR NAME Considerations......................................  8
-   4. Security Considerations......................................  9
-   References......................................................  9
-   Authors' Addresses.............................................. 11
-   Full Copyright Statement........................................ 12
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 1]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-1. Introduction
-
-   The Domain Name System (DNS) provides replicated distributed secure
-   hierarchical databases which hierarchically store "resource records"
-   (RRs) under domain names.
-
-   This data is structured into CLASSes and zones which can be
-   independently maintained.  See [RFC 1034, 1035, 2136, 2181, 2535]
-   familiarity with which is assumed.
-
-   This document covers, either directly or by reference, general IANA
-   parameter assignment considerations applying across DNS query and
-   response headers and all RRs.  There may be additional IANA
-   considerations that apply to only a particular RR type or
-   query/response opcode.  See the specific RFC defining that RR type or
-   query/response opcode for such considerations if they have been
-   defined.
-
-   IANA currently maintains a web page of DNS parameters.  See
-   <http://www.iana.org/numbers.htm>.
-
-   "IETF Standards Action", "IETF Consensus", "Specification Required",
-   and "Private Use" are as defined in [RFC 2434].
-
-2. DNS Query/Response Headers
-
-   The header for DNS queries and responses contains field/bits in the
-   following diagram taken from [RFC 2136, 2535]:
-
-                                           1  1  1  1  1  1
-             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                      ID                       |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                QDCOUNT/ZOCOUNT                |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                ANCOUNT/PRCOUNT                |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                NSCOUNT/UPCOUNT                |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    ARCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   The ID field identifies the query and is echoed in the response so
-   they can be matched.
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 2]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-   The QR bit indicates whether the header is for a query or a response.
-
-   The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
-   only in queries or only in responses, depending on the bit.  However,
-   many DNS implementations copy the query header as the initial value
-   of the response header without clearing bits.  Thus any attempt to
-   use a "query" bit with a different meaning in a response or to define
-   a query meaning for a "response" bit is dangerous given existing
-   implementation.  Such meanings may only be assigned by an IETF
-   Standards Action.
-
-   The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
-   authority count (NSCOUNT), and additional information count (ARCOUNT)
-   express the number of records in each section for all opcodes except
-   Update.  These fields have the same structure and data type for
-   Update but are instead the counts for the zone (ZOCOUNT),
-   prerequisite (PRCOUNT), update (UPCOUNT), and additional information
-   (ARCOUNT) sections.
-
-2.1 One Spare Bit?
-
-   There have been ancient DNS implementations for which the Z bit being
-   on in a query meant that only a response from the primary server for
-   a zone is acceptable.  It is believed that current DNS
-   implementations ignore this bit.
-
-   Assigning a meaning to the Z bit requires an IETF Standards Action.
-
-2.2 Opcode Assignment
-
-   New OpCode assignments require an IETF Standards Action.
-
-   Currently DNS OpCodes are assigned as follows:
-
-       OpCode Name                      Reference
-
-        0     Query                     [RFC 1035]
-        1     IQuery  (Inverse Query)   [RFC 1035]
-        2     Status                    [RFC 1035]
-        3     available for assignment
-        4     Notify                    [RFC 1996]
-        5     Update                    [RFC 2136]
-       6-15   available for assignment
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 3]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-2.3 RCODE Assignment
-
-   It would appear from the DNS header above that only four bits of
-   RCODE, or response/error code are available.  However, RCODEs can
-   appear not only at the top level of a DNS response but also inside
-   OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
-   The OPT RR provides an eight bit extension resulting in a 12 bit
-   RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
-
-   Error codes appearing in the DNS header and in these three RR types
-   all refer to the same error code space with the single exception of
-   error code 16 which has a different meaning in the OPT RR from its
-   meaning in other contexts.  See table below.
-
-   RCODE   Name    Description                        Reference
-   Decimal
-     Hexadecimal
-    0    NoError   No Error                           [RFC 1035]
-    1    FormErr   Format Error                       [RFC 1035]
-    2    ServFail  Server Failure                     [RFC 1035]
-    3    NXDomain  Non-Existent Domain                [RFC 1035]
-    4    NotImp    Not Implemented                    [RFC 1035]
-    5    Refused   Query Refused                      [RFC 1035]
-    6    YXDomain  Name Exists when it should not     [RFC 2136]
-    7    YXRRSet   RR Set Exists when it should not   [RFC 2136]
-    8    NXRRSet   RR Set that should exist does not  [RFC 2136]
-    9    NotAuth   Server Not Authoritative for zone  [RFC 2136]
-   10    NotZone   Name not contained in zone         [RFC 2136]
-   11-15           available for assignment
-   16    BADVERS   Bad OPT Version                    [RFC 2671]
-   16    BADSIG    TSIG Signature Failure             [RFC 2845]
-   17    BADKEY    Key not recognized                 [RFC 2845]
-   18    BADTIME   Signature out of time window       [RFC 2845]
-   19    BADMODE   Bad TKEY Mode                      [RFC 2930]
-   20    BADNAME   Duplicate key name                 [RFC 2930]
-   21    BADALG    Algorithm not supported            [RFC 2930]
-   22-3840         available for assignment
-     0x0016-0x0F00
-   3841-4095       Private Use
-     0x0F01-0x0FFF
-   4096-65535      available for assignment
-     0x1000-0xFFFF
-
-   Since it is important that RCODEs be understood for interoperability,
-   assignment of new RCODE listed above as "available for assignment"
-   requires an IETF Consensus.
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 4]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-3. DNS Resource Records
-
-   All RRs have the same top level format shown in the figure below
-   taken from [RFC 1035]:
-
-                                         1  1  1  1  1  1
-           0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                                               |
-         /                                               /
-         /                      NAME                     /
-         |                                               |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                      TYPE                     |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                     CLASS                     |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                      TTL                      |
-         |                                               |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                   RDLENGTH                    |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
-         /                     RDATA                     /
-         /                                               /
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   NAME is an owner name, i.e., the name of the node to which this
-   resource record pertains.  NAMEs are specific to a CLASS as described
-   in section 3.2.  NAMEs consist of an ordered sequence of one or more
-   labels each of which has a label type [RFC 1035, 2671].
-
-   TYPE is a two octet unsigned integer containing one of the RR TYPE
-   codes.  See section 3.1.
-
-   CLASS is a two octet unsigned integer containing one of the RR CLASS
-   codes.  See section 3.2.
-
-   TTL is a four octet (32 bit) bit unsigned integer that specifies the
-   number of seconds that the resource record may be cached before the
-   source of the information should again be consulted.  Zero is
-   interpreted to mean that the RR can only be used for the transaction
-   in progress.
-
-   RDLENGTH is an unsigned 16 bit integer that specifies the length in
-   octets of the RDATA field.
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 5]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-   RDATA is a variable length string of octets that constitutes the
-   resource.  The format of this information varies according to the
-   TYPE and in some cases the CLASS of the resource record.
-
-3.1 RR TYPE IANA Considerations
-
-   There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
-   and MetaTYPEs.
-
-   Data TYPEs are the primary means of storing data.  QTYPES can only be
-   used in queries.  Meta-TYPEs designate transient data associated with
-   an particular DNS message and in some cases can also be used in
-   queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
-   the block from 100 through 103 while Q and Meta Types have been
-   assigned from 255 downwards (except for the OPT Meta-RR which is
-   assigned TYPE 41).  There have been DNS implementations which made
-   caching decisions based on the top bit of the bottom byte of the RR
-   TYPE.
-
-   There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
-   [RFC 2845], and TKEY [RFC 2930].
-
-   There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
-   AXFR, and IXFR.
-
-   Considerations for the allocation of new RR TYPEs are as follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
-          2535] and in other circumstances and must never be allocated
-          for ordinary use.
-
-     1 - 127
-   0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
-          TYPEs by IETF Consensus.
-
-     128 - 255
-   0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
-          Meta TYPEs by IETF Consensus.
-
-     256 - 32767
-   0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
-          Consensus.
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 6]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-     32768 - 65279
-   0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
-
-     65280 - 65535
-   0xFF00 - 0xFFFF - Private Use.
-
-3.1.1 Special Note on the OPT RR
-
-   The OPT (OPTion) RR, number 41, is specified in [RFC 2671].  Its
-   primary purpose is to extend the effective field size of various DNS
-   fields including RCODE, label type, flag bits, and RDATA size.  In
-   particular, for resolvers and servers that recognize it, it extends
-   the RCODE field from 4 to 12 bits.
-
-3.2 RR CLASS IANA Considerations
-
-   DNS CLASSes have been little used but constitute another dimension of
-   the DNS distributed database.  In particular, there is no necessary
-   relationship between the name space or root servers for one CLASS and
-   those for another CLASS.  The same name can have completely different
-   meanings in different CLASSes although the label types are the same
-   and the null label is usable only as root in every CLASS.  However,
-   as global networking and DNS have evolved, the IN, or Internet, CLASS
-   has dominated DNS use.
-
-   There are two subcategories of DNS CLASSes: normal data containing
-   classes and QCLASSes that are only meaningful in queries or updates.
-
-   The current CLASS assignments and considerations for future
-   assignments are as follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 - assignment requires an IETF Standards Action.
-
-     1
-   0x0001 - Internet (IN).
-
-     2
-   0x0002 - available for assignment by IETF Consensus as a data CLASS.
-
-     3
-   0x0003 - Chaos (CH) [Moon 1981].
-
-     4
-   0x0004 - Hesiod (HS) [Dyer 1987].
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 7]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-     5 - 127
-   0x0005 - 0x007F - available for assignment by IETF Consensus as data
-          CLASSes only.
-
-     128 - 253
-   0x0080 - 0x00FD - available for assignment by IETF Consensus as
-          QCLASSes only.
-
-     254
-   0x00FE - QCLASS None [RFC 2136].
-
-     255
-   0x00FF - QCLASS Any [RFC 1035].
-
-     256 - 32767
-   0x0100 - 0x7FFF - assigned by IETF Consensus.
-
-     32768 - 65280
-   0x8000 - 0xFEFF - assigned based on Specification Required as defined
-          in [RFC 2434].
-
-     65280 - 65534
-   0xFF00 - 0xFFFE - Private Use.
-
-     65535
-   0xFFFF - can only be assigned by an IETF Standards Action.
-
-3.3 RR NAME Considerations
-
-   DNS NAMEs are sequences of labels [RFC 1035].  The last label in each
-   NAME is "ROOT" which is the zero length label.  By definition, the
-   null or ROOT label can not be used for any other NAME purpose.
-
-   At the present time, there are two categories of label types, data
-   labels and compression labels.  Compression labels are pointers to
-   data labels elsewhere within an RR or DNS message and are intended to
-   shorten the wire encoding of NAMEs.  The two existing data label
-   types are sometimes referred to as Text and Binary.  Text labels can,
-   in fact, include any octet value including zero octets but most
-   current uses involve only [US-ASCII].  For retrieval, Text labels are
-   defined to treat ASCII upper and lower case letter codes as matching.
-   Binary labels are bit sequences [RFC 2673].
-
-   IANA considerations for label types are given in [RFC 2671].
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 8]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-   NAMEs are local to a CLASS.  The Hesiod [Dyer 1987] and Chaos [Moon
-   1981] CLASSes are essentially for local use.  The IN or Internet
-   CLASS is thus the only DNS CLASS in global use on the Internet at
-   this time.
-
-   A somewhat dated description of name allocation in the IN Class is
-   given in [RFC 1591].  Some information on reserved top level domain
-   names is in Best Current Practice 32 [RFC 2606].
-
-4. Security Considerations
-
-   This document addresses IANA considerations in the allocation of
-   general DNS parameters, not security.  See [RFC 2535] for secure DNS
-   considerations.
-
-References
-
-   [Dyer 1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
-               Plan - Name Service, April 1987,
-
-   [Moon 1981] D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
-               Institute of Technology Artificial Intelligence
-               Laboratory, June 1981.
-
-   [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]  Mockapetris, P., "Domain Names - Implementation and
-               Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 1591]  Postel, J., "Domain Name System Structure and
-               Delegation", RFC 1591, March 1994.
-
-   [RFC 1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
-               Changes (DNS NOTIFY)", RFC 1996, August 1996.
-
-   [RFC 2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
-               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-               RFC 2136, April 1997.
-
-   [RFC 2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-               Specification", RFC 2181, July 1997.
-
-   [RFC 2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-               October 1998.
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 9]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-   [RFC 2535]  Eastlake, D., "Domain Name System Security Extensions",
-               RFC 2535, March 1999.
-
-   [RFC 2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
-               Names", RFC 2606, June 1999.
-
-   [RFC 2671]  Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
-               2671, August 1999.
-
-   [RFC 2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
-               2672, August 1999.
-
-   [RFC 2673]  Crawford, M., "Binary Labels in the Domain Name System",
-               RFC 2673, August 1999.
-
-   [RFC 2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-               Wellington, "Secret Key Transaction Authentication for
-               DNS (TSIG)", RFC 2845, May 2000.
-
-   [RFC 2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
-               RR)", RFC 2930, September 2000.
-
-   [US-ASCII]  ANSI, "USA Standard Code for Information Interchange",
-               X3.4, American National Standards Institute: New York,
-               1968.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                 [Page 10]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-Authors' Addresses
-
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
-
-   Phone: +1-978-562-2827 (h)
-          +1-508-261-5434 (w)
-   Fax:   +1-508-261-4447 (w)
-   EMail: Donald.Eastlake@motorola.com
-
-
-   Eric Brunner-Williams
-   Engage
-   100 Brickstone Square, 2nd Floor
-   Andover, MA 01810
-
-   Phone: +1-207-797-0525 (h)
-          +1-978-684-7796 (w)
-   Fax:   +1-978-684-3118
-   EMail: brunner@engage.com
-
-
-   Bill Manning
-   USC/ISI
-   4676 Admiralty Way, #1001
-   Marina del Rey, CA 90292 USA
-
-   Phone: +1-310-822-1511
-   EMail: bmanning@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                 [Page 11]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                 [Page 12]
-
diff --git a/doc/rfc/rfc2930.txt b/doc/rfc/rfc2930.txt
deleted file mode 100644
index f99573dd..00000000
--- a/doc/rfc/rfc2930.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   D. Eastlake, 3rd
-Request for Comments: 2930                                      Motorola
-Category: Standards Track                                 September 2000
-
-
-               Secret Key Establishment for DNS (TKEY RR)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   [RFC 2845] provides a means of authenticating Domain Name System
-   (DNS) queries and responses using shared secret keys via the
-   Transaction Signature (TSIG) resource record (RR).  However, it
-   provides no mechanism for setting up such keys other than manual
-   exchange. This document describes a Transaction Key (TKEY) RR that
-   can be used in a number of different modes to establish shared secret
-   keys between a DNS resolver and server.
-
-Acknowledgments
-
-   The comments and ideas of the following persons (listed in alphabetic
-   order) have been incorporated herein and are gratefully acknowledged:
-
-         Olafur Gudmundsson (TIS)
-
-         Stuart Kwan (Microsoft)
-
-         Ed Lewis (TIS)
-
-         Erik Nordmark (SUN)
-
-         Brian Wellington (Nominum)
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-Table of Contents
-
-   1. Introduction...............................................  2
-   1.1 Overview of Contents......................................  3
-   2. The TKEY Resource Record...................................  4
-   2.1 The Name Field............................................  4
-   2.2 The TTL Field.............................................  5
-   2.3 The Algorithm Field.......................................  5
-   2.4 The Inception and Expiration Fields.......................  5
-   2.5 The Mode Field............................................  5
-   2.6 The Error Field...........................................  6
-   2.7 The Key Size and Data Fields..............................  6
-   2.8 The Other Size and Data Fields............................  6
-   3. General TKEY Considerations................................  7
-   4. Exchange via Resolver Query................................  8
-   4.1 Query for Diffie-Hellman Exchanged Keying.................  8
-   4.2 Query for TKEY Deletion...................................  9
-   4.3 Query for GSS-API Establishment........................... 10
-   4.4 Query for Server Assigned Keying.......................... 10
-   4.5 Query for Resolver Assigned Keying........................ 11
-   5. Spontaneous Server Inclusion............................... 12
-   5.1 Spontaneous Server Key Deletion........................... 12
-   6. Methods of Encryption...................................... 12
-   7. IANA Considerations........................................ 13
-   8. Security Considerations.................................... 13
-   References.................................................... 14
-   Author's Address.............................................. 15
-   Full Copyright Statement...................................... 16
-
-1. Introduction
-
-   The Domain Name System (DNS) is a hierarchical, distributed, highly
-   available database used for bi-directional mapping between domain
-   names and addresses, for email routing, and for other information
-   [RFC 1034, 1035].  It has been extended to provide for public key
-   security and dynamic update [RFC 2535, RFC 2136].  Familiarity with
-   these RFCs is assumed.
-
-   [RFC 2845] provides a means of efficiently authenticating DNS
-   messages using shared secret keys via the TSIG resource record (RR)
-   but provides no mechanism for setting up such keys other than manual
-   exchange. This document specifies a TKEY RR that can be used in a
-   number of different modes to establish and delete such shared secret
-   keys between a DNS resolver and server.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   Note that TKEY established keying material and TSIGs that use it are
-   associated with DNS servers or resolvers.  They are not associated
-   with zones.  They may be used to authenticate queries and responses
-   but they do not provide zone based DNS data origin or denial
-   authentication [RFC 2535].
-
-   Certain modes of TKEY perform encryption which may affect their
-   export or import status for some countries.  The affected modes
-   specified in this document are the server assigned mode and the
-   resolver assigned mode.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-   In all cases herein, the term "resolver" includes that part of a
-   server which may make full and incremental [RFC 1995] zone transfer
-   queries, forwards recursive queries, etc.
-
-1.1 Overview of Contents
-
-   Section 2 below specifies the TKEY RR and provides a description of
-   and considerations for its constituent fields.
-
-   Section 3 describes general principles of operations with TKEY.
-
-   Section 4 discusses key agreement and deletion via DNS requests with
-   the Query opcode for RR type TKEY.  This method is applicable to all
-   currently defined TKEY modes, although in some cases it is not what
-   would intuitively be called a "query".
-
-   Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
-   servers which is currently used only for key deletion.
-
-   Section 6 describes encryption methods for transmitting secret key
-   information. In this document these are used only for the server
-   assigned mode and the resolver assigned mode.
-
-   Section 7 covers IANA considerations in assignment of TKEY modes.
-
-   Finally, Section 8 provides the required security considerations
-   section.
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-2. The TKEY Resource Record
-
-   The TKEY resource record (RR) has the structure given below.  Its RR
-   type code is 249.
-
-      Field       Type         Comment
-      -----       ----         -------
-
-      NAME         domain      see description below
-      TTYPE        u_int16_t   TKEY = 249
-      CLASS        u_int16_t   ignored, SHOULD be 255 (ANY)
-      TTL          u_int32_t   ignored, SHOULD be zero
-      RDLEN        u_int16_t   size of RDATA
-      RDATA:
-       Algorithm:   domain
-       Inception:   u_int32_t
-       Expiration:  u_int32_t
-       Mode:        u_int16_t
-       Error:       u_int16_t
-       Key Size:    u_int16_t
-       Key Data:    octet-stream
-       Other Size:  u_int16_t
-       Other Data:  octet-stream  undefined by this specification
-
-2.1 The Name Field
-
-   The Name field relates to naming keys.  Its meaning differs somewhat
-   with mode and context as explained in subsequent sections.
-
-   At any DNS server or resolver only one octet string of keying
-   material may be in place for any particular key name.  An attempt to
-   establish another set of keying material at a server for an existing
-   name returns a BADNAME error.
-
-   For a TKEY with a non-root name appearing in a query, the TKEY RR
-   name SHOULD be a domain locally unique at the resolver, less than 128
-   octets long in wire encoding, and meaningful to the resolver to
-   assist in distinguishing keys and/or key agreement sessions.   For
-   TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
-   be a globally unique server assigned domain.
-
-   A reasonable key naming strategy is as follows:
-
-      If the key is generated as the result of a query with root as its
-      owner name, then the server SHOULD create a globally unique domain
-      name, to be the key name, by suffixing a pseudo-random [RFC 1750]
-      label with a domain name of the server.  For example
-      89n3mDgX072pp.server1.example.com.  If generation of a new
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-      pseudo-random name in each case is an excessive computation load
-      or entropy drain, a serial number prefix can be added to a fixed
-      pseudo-random name generated an DNS server start time, such as
-      1001.89n3mDgX072pp.server1.example.com.
-
-      If the key is generated as the result of a query with a non-root
-      name, say 789.resolver.example.net, then use the concatenation of
-      that with a name of the server.  For example
-      789.resolver.example.net.server1.example.com.
-
-2.2 The TTL Field
-
-   The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
-   be sure that older DNS implementations do not cache TKEY RRs.
-
-2.3 The Algorithm Field
-
-   The algorithm name is in the form of a domain name with the same
-   meaning as in [RFC 2845].  The algorithm determines how the secret
-   keying material agreed to using the TKEY RR is actually used to
-   derive the algorithm specific key.
-
-2.4 The Inception and Expiration Fields
-
-   The inception time and expiration times are in number of seconds
-   since the beginning of 1 January 1970 GMT ignoring leap seconds
-   treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
-   between a DNS resolver and a DNS server where these fields are
-   meaningful, they are either the requested validity interval for the
-   keying material asked for or specify the validity interval of keying
-   material provided.
-
-   To avoid different interpretations of the inception and expiration
-   times in TKEY RRs, resolvers and servers exchanging them must have
-   the same idea of what time it is.  One way of doing this is with the
-   NTP protocol [RFC 2030] but that or any other time synchronization
-   used for this purpose MUST be done securely.
-
-2.5 The Mode Field
-
-   The mode field specifies the general scheme for key agreement or the
-   purpose of the TKEY DNS message.  Servers and resolvers supporting
-   this specification MUST implement the Diffie-Hellman key agreement
-   mode and the key deletion mode for queries.  All other modes are
-   OPTIONAL.  A server supporting TKEY that receives a TKEY request with
-   a mode it does not support returns the BADMODE error.  The following
-   values of the Mode octet are defined, available, or reserved:
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-         Value    Description
-         -----    -----------
-          0        - reserved, see section 7
-          1       server assignment
-          2       Diffie-Hellman exchange
-          3       GSS-API negotiation
-          4       resolver assignment
-          5       key deletion
-         6-65534   - available, see section 7
-         65535     - reserved, see section 7
-
-2.6 The Error Field
-
-   The error code field is an extended RCODE.  The following values are
-   defined:
-
-         Value   Description
-         -----   -----------
-          0       - no error
-          1-15   a non-extended RCODE
-          16     BADSIG   (TSIG)
-          17     BADKEY   (TSIG)
-          18     BADTIME  (TSIG)
-          19     BADMODE
-          20     BADNAME
-          21     BADALG
-
-   When the TKEY Error Field is non-zero in a response to a TKEY query,
-   the DNS header RCODE field indicates no error. However, it is
-   possible if a TKEY is spontaneously included in a response the TKEY
-   RR and DNS header error field could have unrelated non-zero error
-   codes.
-
-2.7 The Key Size and Data Fields
-
-   The key data size field is an unsigned 16 bit integer in network
-   order which specifies the size of the key exchange data field in
-   octets. The meaning of this data depends on the mode.
-
-2.8 The Other Size and Data Fields
-
-   The Other Size and Other Data fields are not used in this
-   specification but may be used in future extensions.  The RDLEN field
-   MUST equal the length of the RDATA section through the end of Other
-   Data or the RR is to be considered malformed and rejected.
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-3. General TKEY Considerations
-
-   TKEY is a meta-RR that is not stored or cached in the DNS and does
-   not appear in zone files.  It supports a variety of modes for the
-   establishment and deletion of shared secret keys information between
-   DNS resolvers and servers.  The establishment of such a shared key
-   requires that state be maintained at both ends and the allocation of
-   the resources to maintain such state may require mutual agreement. In
-   the absence of willingness to provide such state, servers MUST return
-   errors such as NOTIMP or REFUSED for an attempt to use TKEY and
-   resolvers are free to ignore any TKEY RRs they receive.
-
-   The shared secret keying material developed by using TKEY is a plain
-   octet sequence.  The means by which this shared secret keying
-   material, exchanged via TKEY, is actually used in any particular TSIG
-   algorithm is algorithm dependent and is defined in connection with
-   that algorithm.  For example, see [RFC 2104] for how TKEY agreed
-   shared secret keying material is used in the HMAC-MD5 algorithm or
-   other HMAC algorithms.
-
-   There MUST NOT be more than one TKEY RR in a DNS query or response.
-
-   Except for GSS-API mode, TKEY responses MUST always have DNS
-   transaction authentication to protect the integrity of any keying
-   data, error codes, etc.  This authentication MUST use a previously
-   established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST
-   NOT use any key that the response to be verified is itself providing.
-
-   TKEY queries MUST be authenticated for all modes except GSS-API and,
-   under some circumstances, server assignment mode.  In particular, if
-   the query for a server assigned key is for a key to assert some
-   privilege, such as update authority, then the query must be
-   authenticated to avoid spoofing.  However, if the key is just to be
-   used for transaction security, then spoofing will lead at worst to
-   denial of service.  Query authentication SHOULD use an established
-   secret (TSIG) key authenticator if available.  Otherwise, it must use
-   a public (SIG(0)) key signature.  It MUST NOT use any key that the
-   query is itself providing.
-
-   In the absence of required TKEY authentication, a NOTAUTH error MUST
-   be returned.
-
-   To avoid replay attacks, it is necessary that a TKEY response or
-   query not be valid if replayed on the order of 2**32 second (about
-   136 years), or a multiple thereof, later.  To accomplish this, the
-   keying material used in any TSIG or SIG(0) RR that authenticates a
-   TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
-
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   (about 68 years).  Thus, on attempted replay, the authenticating TSIG
-   or SIG(0) RR will not be verifiable due to key expiration and the
-   replay will fail.
-
-4. Exchange via Resolver Query
-
-   One method for a resolver and a server to agree about shared secret
-   keying material for use in TSIG is through DNS requests from the
-   resolver which are syntactically DNS queries for type TKEY.  Such
-   queries MUST be accompanied by a TKEY RR in the additional
-   information section to indicate the mode in use and accompanied by
-   other information where required.
-
-   Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
-   ignore the recursive header bit in TKEY queries they receive.
-
-4.1 Query for Diffie-Hellman Exchanged Keying
-
-   Diffie-Hellman (DH) key exchange is a means whereby two parties can
-   derive some shared secret information without requiring any secrecy
-   of the messages they exchange [Schneier].  Provisions have been made
-   for the storage of DH public keys in the DNS [RFC 2539].
-
-   A resolver sends a query for type TKEY accompanied by a TKEY RR in
-   the additional information section specifying the Diffie-Hellman mode
-   and accompanied by a KEY RR also in the additional information
-   section specifying a resolver Diffie-Hellman key.  The TKEY RR
-   algorithm field is set to the authentication algorithm the resolver
-   plans to use. The "key data" provided in the TKEY is used as a random
-   [RFC 1750] nonce to avoid always deriving the same keying material
-   for the same pair of DH KEYs.
-
-   The server response contains a TKEY in its answer section with the
-   Diffie-Hellman mode. The "key data" provided in this TKEY is used as
-   an additional nonce to avoid always deriving the same keying material
-   for the same pair of DH KEYs. If the TKEY error field is non-zero,
-   the query failed for the reason given. FORMERR is given if the query
-   included no DH KEY and BADKEY is given if the query included an
-   incompatible DH KEY.
-
-   If the TKEY error field is zero, the resolver supplied Diffie-Hellman
-   KEY RR SHOULD be echoed in the additional information section and a
-   server Diffie-Hellman KEY RR will also be present in the answer
-   section of the response.  Both parties can then calculate the same
-   shared secret quantity from the pair of Diffie-Hellman (DH) keys used
-   [Schneier] (provided these DH keys use the same generator and
-   modulus) and the data in the TKEY RRs.  The TKEY RR data is mixed
-   with the DH result as follows:
-
-
-
-Eastlake                    Standards Track                     [Page 8]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-      keying material =
-           XOR ( DH value, MD5 ( query data | DH value ) |
-                           MD5 ( server data | DH value ) )
-
-   Where XOR is an exclusive-OR operation and "|" is byte-stream
-   concatenation.  The shorter of the two operands to XOR is byte-wise
-   left justified and padded with zero-valued bytes to match the length
-   of the other operand.  "DH value" is the Diffie-Hellman value derived
-   from the KEY RRs. Query data and server data are the values sent in
-   the TKEY RR data fields.  These "query data" and "server data" nonces
-   are suffixed by the DH value, digested by MD5, the results
-   concatenated, and then XORed with the DH value.
-
-   The inception and expiry times in the query TKEY RR are those
-   requested for the keying material.  The inception and expiry times in
-   the response TKEY RR are the maximum period the server will consider
-   the keying material valid.  Servers may pre-expire keys so this is
-   not a guarantee.
-
-4.2 Query for TKEY Deletion
-
-   Keys established via TKEY can be treated as soft state.  Since DNS
-   transactions are originated by the resolver, the resolver can simply
-   toss keys, although it may have to go through another key exchange if
-   it later needs one.  Similarly, the server can discard keys although
-   that will result in an error on receiving a query with a TSIG using
-   the discarded key.
-
-   To avoid attempted reliance in requests on keys no longer in effect,
-   servers MUST implement key deletion whereby the server "discards" a
-   key on receipt from a resolver of an authenticated delete request for
-   a TKEY RR with the key's name.  If the server has no record of a key
-   with that name, it returns BADNAME.
-
-   Key deletion TKEY queries MUST be authenticated.  This authentication
-   MAY be a TSIG RR using the key to be deleted.
-
-   For querier assigned and Diffie-Hellman keys, the server MUST truly
-   "discard" all active state associated with the key.  For server
-   assigned keys, the server MAY simply mark the key as no longer
-   retained by the client and may re-send it in response to a future
-   query for server assigned keying material.
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 9]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-4.3 Query for GSS-API Establishment
-
-   This mode is described in a separate document under preparation which
-   should be seen for the full description.  Basically the resolver and
-   server can exchange queries and responses for type TKEY with a TKEY
-   RR specifying the GSS-API mode in the additional information section
-   and a GSS-API token in the key data portion of the TKEY RR.
-
-   Any issues of possible encryption of parts the GSS-API token data
-   being transmitted are handled by the GSS-API level.  In addition, the
-   GSS-API level provides its own authentication so that this mode of
-   TKEY query and response MAY be, but do not need to be, authenticated
-   with TSIG RR or SIG(0) RR [RFC 2931].
-
-   The inception and expiry times in a GSS-API mode TKEY RR are ignored.
-
-4.4 Query for Server Assigned Keying
-
-   Optionally, the server can assign keying for the resolver.  It is
-   sent to the resolver encrypted under a resolver public key.  See
-   section 6 for description of encryption methods.
-
-   A resolver sends a query for type TKEY accompanied by a TKEY RR
-   specifying the "server assignment" mode and a resolver KEY RR to be
-   used in encrypting the response, both in the additional information
-   section. The TKEY algorithm field is set to the authentication
-   algorithm the resolver plans to use.  It is RECOMMENDED that any "key
-   data" provided in the query TKEY RR by the resolver be strongly mixed
-   by the server with server generated randomness [RFC 1750] to derive
-   the keying material to be used.  The KEY RR that appears in the query
-   need not be accompanied by a SIG(KEY) RR.  If the query is
-   authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
-   and that authentication is verified, then any SIG(KEY) provided in
-   the query SHOULD be ignored.  The KEY RR in such a query SHOULD have
-   a name that corresponds to the resolver but it is only essential that
-   it be a public key for which the resolver has the corresponding
-   private key so it can decrypt the response data.
-
-   The server response contains a TKEY RR in its answer section with the
-   server assigned mode and echoes the KEY RR provided in the query in
-   its additional information section.
-
-   If the response TKEY error field is zero, the key data portion of the
-   response TKEY RR will be the server assigned keying data encrypted
-   under the public key in the resolver provided KEY RR.  In this case,
-   the owner name of the answer TKEY RR will be the server assigned name
-   of the key.
-
-
-
-
-Eastlake                    Standards Track                    [Page 10]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   If the error field of the response TKEY is non-zero, the query failed
-   for the reason given.  FORMERR is given if the query specified no
-   encryption key.
-
-   The inception and expiry times in the query TKEY RR are those
-   requested for the keying material.  The inception and expiry times in
-   the response TKEY are the maximum period the server will consider the
-   keying material valid.  Servers may pre-expire keys so this is not a
-   guarantee.
-
-   The resolver KEY RR MUST be authenticated, through the authentication
-   of this query with a TSIG or SIG(0) or the signing of the resolver
-   KEY with a SIG(KEY).  Otherwise, an attacker can forge a resolver KEY
-   for which they know the private key, and thereby the attacker could
-   obtain a valid shared secret key from the server.
-
-4.5 Query for Resolver Assigned Keying
-
-   Optionally, a server can accept resolver assigned keys.  The keying
-   material MUST be encrypted under a server key for protection in
-   transmission as described in Section 6.
-
-   The resolver sends a TKEY query with a TKEY RR that specifies the
-   encrypted keying material and a KEY RR specifying the server public
-   key used to encrypt the data, both in the additional information
-   section.  The name of the key and the keying data are completely
-   controlled by the sending resolver so a globally unique key name
-   SHOULD be used.  The KEY RR used MUST be one for which the server has
-   the corresponding private key, or it will not be able to decrypt the
-   keying material and will return a FORMERR. It is also important that
-   no untrusted party (preferably no other party than the server) has
-   the private key corresponding to the KEY RR because, if they do, they
-   can capture the messages to the server, learn the shared secret, and
-   spoof valid TSIGs.
-
-   The query TKEY RR inception and expiry give the time period the
-   querier intends to consider the keying material valid.  The server
-   can return a lesser time interval to advise that it will not maintain
-   state for that long and can pre-expire keys in any case.
-
-   This mode of query MUST be authenticated with a TSIG or SIG(0).
-   Otherwise, an attacker can forge a resolver assigned TKEY query, and
-   thereby the attacker could specify a shared secret key that would be
-   accepted, used, and honored by the server.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 11]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-5. Spontaneous Server Inclusion
-
-   A DNS server may include a TKEY RR spontaneously as additional
-   information in responses.  This SHOULD only be done if the server
-   knows the querier understands TKEY and has this option implemented.
-   This technique can be used to delete a key and may be specified for
-   modes defined in the future.  A disadvantage of this technique is
-   that there is no way for the server to get any error or success
-   indication back and, in the case of UDP, no way to even know if the
-   DNS response reached the resolver.
-
-5.1 Spontaneous Server Key Deletion
-
-   A server can optionally tell a client that it has deleted a secret
-   key by spontaneously including a TKEY RR in the additional
-   information section of a response with the key's name and specifying
-   the key deletion mode.  Such a response SHOULD be authenticated.  If
-   authenticated, it "deletes" the key with the given name.  The
-   inception and expiry times of the delete TKEY RR are ignored. Failure
-   by a client to receive or properly process such additional
-   information in a response would mean that the client might use a key
-   that the server had discarded and would then get an error indication.
-
-   For server assigned and Diffie-Hellman keys, the client MUST
-   "discard" active state associated with the key.  For querier assigned
-   keys, the querier MAY simply mark the key as no longer retained by
-   the server and may re-send it in a future query specifying querier
-   assigned keying material.
-
-6. Methods of Encryption
-
-   For the server assigned and resolver assigned key agreement modes,
-   the keying material is sent within the key data field of a TKEY RR
-   encrypted under the public key in an accompanying KEY RR [RFC 2535].
-   This KEY RR MUST be for a public key algorithm where the public and
-   private keys can be used for encryption and the corresponding
-   decryption which recovers the originally encrypted data.  The KEY RR
-   SHOULD correspond to a name for the decrypting resolver/server such
-   that the decrypting process has access to the corresponding private
-   key to decrypt the data.  The secret keying material being sent will
-   generally be fairly short, usually less than 256 bits, because that
-   is adequate for very strong protection with modern keyed hash or
-   symmetric algorithms.
-
-   If the KEY RR specifies the RSA algorithm, then the keying material
-   is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
-   PKCS#1 [RFC 2437].  (Note, the secret keying material being sent is
-   directly RSA encrypted in PKCS#1 format. It is not "enveloped" under
-
-
-
-Eastlake                    Standards Track                    [Page 12]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   some other symmetric algorithm.)  In the unlikely event that the
-   keying material will not fit within one RSA modulus of the chosen
-   public key, additional RSA encryption blocks are included.  The
-   length of each block is clear from the public RSA key specified and
-   the RSAES-PKCS1-v1_5 padding makes it clear what part of the
-   encrypted data is actually keying material and what part is
-   formatting or the required at least eight bytes of random [RFC 1750]
-   padding.
-
-7. IANA Considerations
-
-   This section is to be interpreted as provided in [RFC 2434].
-
-   Mode field values 0x0000 and 0xFFFF are reserved.
-
-   Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
-   can only be assigned by an IETF Standards Action.
-
-   Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
-   are allocated by IESG approval or IETF consensus.
-
-   Mode field values 0x1000 through 0xEFFF are allocated based on
-   Specification Required as defined in [RFC 2434].
-
-   Mode values should not be changed when the status of their use
-   changes.  For example, a mode value assigned based just on providing
-   a specification should not be changed later just because that use's
-   status is changed to standards track.
-
-   The following assignments are documented herein:
-
-      RR Type 249 for TKEY.
-
-      TKEY Modes 1 through 5 as listed in section 2.5.
-
-      Extended RCODE Error values of 19, 20, and 21 as listed in section
-      2.6.
-
-8. Security Considerations
-
-   The entirety of this specification is concerned with the secure
-   establishment of a shared secret between DNS clients and servers in
-   support of TSIG [RFC 2845].
-
-   Protection against denial of service via the use of TKEY is not
-   provided.
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 13]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-References
-
-   [Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
-              Algorithms, and Source Code in C", 1996, John Wiley and
-              Sons
-
-   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
-              Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-              Recommendations for Security", RFC 1750, December 1994.
-
-   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
-              September 1996.
-
-   [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-              August 1996.
-
-   [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
-              for IPv4, IPv6 and OSI", RFC 2030, October 1996.
-
-   [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
-              Hashing for Message Authentication", RFC 2104, February
-              1997.
-
-   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
-              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-              April 1997.
-
-   [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-              October 1998.
-
-   [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
-              Specifications Version 2.0", RFC 2437, October 1998.
-
-   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
-              Domain Name System (DNS)", RFC 2539, March 1999.
-
-
-
-
-Eastlake                    Standards Track                    [Page 14]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures
-              (SIG(0)s )", RFC 2931, September 2000.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
-
-   Phone: +1 978-562-2827 (h)
-          +1 508-261-5434 (w)
-   Fax:   +1 508-261-4447 (w)
-   EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 15]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 16]
-
diff --git a/doc/rfc/rfc2931.txt b/doc/rfc/rfc2931.txt
deleted file mode 100644
index 84cc97e2..00000000
--- a/doc/rfc/rfc2931.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 2931                                      Motorola
-Updates: 2535                                             September 2000
-Category: Standards Track
-
-
-           DNS Request and Transaction Signatures ( SIG(0)s )
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   Extensions to the Domain Name System (DNS) are described in [RFC
-   2535] that can provide data origin and transaction integrity and
-   authentication to security aware resolvers and applications through
-   the use of cryptographic digital signatures.
-
-   Implementation experience has indicated the need for minor but non-
-   interoperable changes in Request and Transaction signature resource
-   records ( SIG(0)s ).  These changes are documented herein.
-
-Acknowledgments
-
-   The contributions and suggestions of the following persons (in
-   alphabetic order) to this memo are gratefully acknowledged:
-
-         Olafur Gudmundsson
-
-         Ed Lewis
-
-         Erik Nordmark
-
-         Brian Wellington
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-Table of Contents
-
-   1. Introduction.................................................  2
-   2. SIG(0) Design Rationale......................................  3
-   2.1 Transaction Authentication..................................  3
-   2.2 Request Authentication......................................  3
-   2.3 Keying......................................................  3
-   2.4 Differences Between TSIG and SIG(0).........................  4
-   3. The SIG(0) Resource Record...................................  4
-   3.1 Calculating Request and Transaction SIGs....................  5
-   3.2 Processing Responses and SIG(0) RRs.........................  6
-   3.3 SIG(0) Lifetime and Expiration..............................  7
-   4. Security Considerations......................................  7
-   5. IANA Considerations..........................................  7
-   References......................................................  7
-   Author's Address................................................  8
-   Appendix: SIG(0) Changes from RFC 2535..........................  9
-   Full Copyright Statement........................................ 10
-
-1. Introduction
-
-   This document makes minor but non-interoperable changes to part of
-   [RFC 2535], familiarity with which is assumed, and includes
-   additional explanatory text.  These changes concern SIG Resource
-   Records (RRs) that are used to digitally sign DNS requests and
-   transactions / responses.  Such a resource record, because it has a
-   type covered field of zero, is frequently called a SIG(0). The
-   changes are based on implementation and attempted implementation
-   experience with TSIG [RFC 2845] and the [RFC 2535] specification for
-   SIG(0).
-
-   Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
-   and 4.3.  No changes are made herein related to the KEY or NXT RRs or
-   to the processing involved with data origin and denial authentication
-   for DNS data.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-2. SIG(0) Design Rationale
-
-   SIG(0) provides protection for DNS transactions and requests that is
-   not provided by the regular SIG, KEY, and NXT RRs specified in [RFC
-   2535].  The authenticated data origin services of secure DNS either
-   provide protected data resource records (RRs) or authenticatably deny
-   their nonexistence.  These services provide no protection for glue
-   records, DNS requests, no protection for message headers on requests
-   or responses, and no protection of the overall integrity of a
-   response.
-
-2.1 Transaction Authentication
-
-   Transaction authentication means that a requester can be sure it is
-   at least getting the messages from the server it queried and that the
-   received messages are in response to the query it sent.  This is
-   accomplished by optionally adding either a TSIG RR [RFC 2845] or, as
-   described herein, a SIG(0) resource record at the end of the response
-   which digitally signs the concatenation of the server's response and
-   the corresponding resolver query.
-
-2.2 Request Authentication
-
-   Requests can also be authenticated by including a TSIG or, as
-   described herein, a special SIG(0) RR at the end of the request.
-   Authenticating requests serves no function in DNS servers that
-   predate the specification of dynamic update.  Requests with a non-
-   empty additional information section produce error returns or may
-   even be ignored by a few such older DNS servers. However, this syntax
-   for signing requests is defined for authenticating dynamic update
-   requests [RFC 2136], TKEY requests [RFC 2930], or future requests
-   requiring authentication.
-
-2.3 Keying
-
-   The private keys used in transaction security belong to the host
-   composing the DNS response message, not to the zone involved.
-   Request authentication may also involve the private key of the host
-   or other entity composing the request or of a zone to be affected by
-   the request or other private keys depending on the request authority
-   it is sought to establish. The corresponding public key(s) are
-   normally stored in and retrieved from the DNS for verification as KEY
-   RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY).
-
-   Because requests and replies are highly variable, message
-   authentication SIGs can not be pre-calculated.  Thus it will be
-   necessary to keep the private key on-line, for example in software or
-   in a directly connected piece of hardware.
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-2.4 Differences Between TSIG and SIG(0)
-
-   There are significant differences between TSIG and SIG(0).
-
-   Because TSIG involves secret keys installed at both the requester and
-   server the presence of such a key implies that the other party
-   understands TSIG and very likely has the same key installed.
-   Furthermore, TSIG uses keyed hash authentication codes which are
-   relatively inexpensive to compute.  Thus it is common to authenticate
-   requests with TSIG and responses are authenticated with TSIG if the
-   corresponding request is authenticated.
-
-   SIG(0) on the other hand, uses public key authentication, where the
-   public keys are stored in DNS as KEY RRs and a private key is stored
-   at the signer.  Existence of such a KEY RR does not necessarily imply
-   implementation of SIG(0).  In addition, SIG(0) involves relatively
-   expensive public key cryptographic operations that should be
-   minimized and the verification of a SIG(0) involves obtaining and
-   verifying the corresponding KEY which can be an expensive and lengthy
-   operation.  Indeed, a policy of using SIG(0) on all requests and
-   verifying it before responding would, for some configurations, lead
-   to a deadly embrace with the attempt to obtain and verify the KEY
-   needed to authenticate the request SIG(0) resulting in additional
-   requests accompanied by a SIG(0) leading to further requests
-   accompanied by a SIG(0), etc.  Furthermore, omitting SIG(0)s when not
-   required on requests halves the number of public key operations
-   required by the transaction.
-
-   For these reasons, SIG(0)s SHOULD only be used on requests when
-   necessary to authenticate that the requester has some required
-   privilege or identity.  SIG(0)s on replies are defined in such a way
-   as to not require a SIG(0) on the corresponding request and still
-   provide transaction protection.  For other replies, whether they are
-   authenticated by the server or required to be authenticated by the
-   requester SHOULD be a local configuration option.
-
-3. The SIG(0) Resource Record
-
-   The structure of and type number of SIG resource records (RRs) is
-   given in [RFC 2535] Section 4.1.  However all of Section 4.1.8.1 and
-   the parts of Sections 4.2 and 4.3 related to SIG(0) should be
-   considered replaced by the material below.  Any conflict between [RFC
-   2535] and this document concerning SIG(0) RRs should be resolved in
-   favor of this document.
-
-   For all transaction SIG(0)s, the signer field MUST be a name of the
-   originating host and there MUST be a KEY RR at that name with the
-   public key corresponding to the private key used to calculate the
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-   signature.  (The host domain name used may be the inverse IP address
-   mapping name for an IP address of the host if the relevant KEY is
-   stored there.)
-
-   For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
-   meaningless.  The TTL fields SHOULD be zero and the CLASS field
-   SHOULD be ANY.  To conserve space, the owner name SHOULD be root (a
-   single zero octet).  When SIG(0) authentication on a response is
-   desired, that SIG RR MUST be considered the highest priority of any
-   additional information for inclusion in the response. If the SIG(0)
-   RR cannot be added without causing the message to be truncated, the
-   server MUST alter the response so that a SIG(0) can be included.
-   This response consists of only the question and a SIG(0) record, and
-   has the TC bit set and RCODE 0 (NOERROR).  The client should at this
-   point retry the request using TCP.
-
-3.1 Calculating Request and Transaction SIGs
-
-   A DNS request may be optionally signed by including one SIG(0)s at
-   the end of the query additional information section.  Such a SIG is
-   identified by having a "type covered" field of zero. It signs the
-   preceding DNS request message including DNS header but not including
-   the UDP/IP header and before the request RR counts have been adjusted
-   for the inclusions of the request SIG(0).
-
-   It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of
-   (1) the SIG's RDATA section entirely omitting (not just zeroing) the
-   signature subfield itself, (2) the DNS query messages, including DNS
-   header, but not the UDP/IP header and before the reply RR counts have
-   been adjusted for the inclusion of the SIG(0).  That is
-
-      data = RDATA | request - SIG(0)
-
-   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
-   calculated less the signature itself.
-
-   Similarly, a SIG(0) can be used to secure a response and the request
-   that produced it.  Such transaction signatures are calculated by
-   using a "data" of (1) the SIG's RDATA section omitting the signature
-   itself, (2) the entire DNS query message that produced this response,
-   including the query's DNS header but not its UDP/IP header, and (3)
-   the entire DNS response message, including DNS header but not the
-   UDP/IP header and before the response RR counts have been adjusted
-   for the inclusion of the SIG(0).
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-   That is
-
-      data = RDATA | full query | response - SIG(0)
-
-   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
-   calculated less the signature itself.
-
-   Verification of a response SIG(0) (which is signed by the server host
-   key, not the zone key) by the requesting resolver shows that the
-   query and response were not tampered with in transit, that the
-   response corresponds to the intended query, and that the response
-   comes from the queried server.
-
-   In the case of a DNS message via TCP, a SIG(0) on the first data
-   packet is calculated with "data" as above and for each subsequent
-   packet, it is calculated as follows:
-
-      data = RDATA | DNS payload - SIG(0) | previous packet
-
-   where "|" is concatenations, RDATA is as above, and previous packet
-   is the previous DNS payload including DNS header and the SIG(0) but
-   not the TCP/IP header.  Support of SIG(0) for TCP is OPTIONAL.  As an
-   alternative, TSIG may be used after, if necessary, setting up a key
-   with TKEY [RFC 2930].
-
-   Except where needed to authenticate an update, TKEY, or similar
-   privileged request, servers are not required to check a request
-   SIG(0).
-
-   Note: requests and responses can either have a single TSIG or one
-   SIG(0) but not both a TSIG and a SIG(0).
-
-3.2 Processing Responses and SIG(0) RRs
-
-   If a SIG RR is at the end of the additional information section of a
-   response and has a type covered of zero, it is a transaction
-   signature covering the response and the query that produced the
-   response.  For TKEY responses, it MUST be checked and the message
-   rejected if the checks fail unless otherwise specified for the TKEY
-   mode in use.  For all other responses, it MAY be checked and the
-   message rejected if the checks fail.
-
-   If a response's SIG(0) check succeed, such a transaction
-   authentication SIG does NOT directly authenticate the validity any
-   data-RRs in the message.  However, it authenticates that they were
-   sent by the queried server and have not been diddled.  (Only a proper
-   SIG(0) RR signed by the zone or a key tracing its authority to the
-   zone or to static resolver configuration can directly authenticate
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-   data-RRs, depending on resolver policy.) If a resolver or server does
-   not implement transaction and/or request SIGs, it MUST ignore them
-   without error where they are optional and treat them as failing where
-   they are required.
-
-3.3 SIG(0) Lifetime and Expiration
-
-   The inception and expiration times in SIG(0)s are for the purpose of
-   resisting replay attacks.  They should be set to form a time bracket
-   such that messages outside that bracket can be ignored.  In IP
-   networks, this time bracket should not normally extend further than 5
-   minutes into the past and 5 minutes into the future.
-
-4. Security Considerations
-
-   No additional considerations beyond those in [RFC 2535].
-
-   The inclusion of the SIG(0) inception and expiration time under the
-   signature improves resistance to replay attacks.
-
-5. IANA Considerations
-
-   No new parameters are created or parameter values assigned by this
-   document.
-
-References
-
-   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
-              September 1996.
-
-   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
-              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-              April 1997.
-
-   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-              Wellington, "Secret Key Transaction Signatures for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC
-              2930, September 2000.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
-
-   Phone: +1-978-562-2827(h)
-          +1-508-261-5434(w)
-   Fax:   +1 978-567-7941(h)
-          +1-508-261-4447(w)
-   EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 8]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-Appendix: SIG(0) Changes from RFC 2535
-
-   Add explanatory text concerning the differences between TSIG and
-   SIG(0).
-
-   Change the data over which SIG(0) is calculated to include the SIG(0)
-   RDATA other than the signature itself so as to secure the signature
-   inception and expiration times and resist replay attacks.  Specify
-   SIG(0) for TCP.
-
-   Add discussion of appropriate inception and expiration times for
-   SIG(0).
-
-   Add wording to indicate that either a TSIG or one or more SIG(0)s may
-   be present but not both.
-
-   Reword some areas for clarity.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 9]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 10]
-
diff --git a/doc/rfc/rfc3007.txt b/doc/rfc/rfc3007.txt
deleted file mode 100644
index 16974753..00000000
--- a/doc/rfc/rfc3007.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      B. Wellington
-Request for Comments: 3007                                       Nominum
-Updates: 2535, 2136                                        November 2000
-Obsoletes: 2137
-Category: Standards Track
-
-
-             Secure Domain Name System (DNS) Dynamic Update
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This document proposes a method for performing secure Domain Name
-   System (DNS) dynamic updates.  The method described here is intended
-   to be flexible and useful while requiring as few changes to the
-   protocol as possible.  The authentication of the dynamic update
-   message is separate from later DNSSEC validation of the data.  Secure
-   communication based on authenticated requests and transactions is
-   used to provide authorization.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-1 - Introduction
-
-   This document defines a means to secure dynamic updates of the Domain
-   Name System (DNS), allowing only authorized sources to make changes
-   to a zone's contents.  The existing unsecured dynamic update
-   operations form the basis for this work.
-
-   Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update
-   [RFC2136] is helpful and is assumed by this document.  In addition,
-   knowledge of DNS security extensions [RFC2535], SIG(0) transaction
-   security [RFC2535, RFC2931], and TSIG transaction security [RFC2845]
-   is recommended.
-
-
-
-
-Wellington                  Standards Track                     [Page 1]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   This document updates portions of RFC 2535, in particular section
-   3.1.2, and RFC 2136.  This document obsoletes RFC 2137, an alternate
-   proposal for secure dynamic update, due to implementation experience.
-
-1.1 - Overview of DNS Dynamic Update
-
-   DNS dynamic update defines a new DNS opcode and a new interpretation
-   of the DNS message if that opcode is used.  An update can specify
-   insertions or deletions of data, along with prerequisites necessary
-   for the updates to occur.  All tests and changes for a DNS update
-   request are restricted to a single zone, and are performed at the
-   primary server for the zone.  The primary server for a dynamic zone
-   must increment the zone SOA serial number when an update occurs or
-   before the next retrieval of the SOA.
-
-1.2 - Overview of DNS Transaction Security
-
-   Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0)
-   [RFC2535, RFC2931] records allow two DNS entities to authenticate DNS
-   requests and responses sent between them.  A TSIG MAC (message
-   authentication code) is derived from a shared secret, and a SIG(0) is
-   generated from a private key whose public counterpart is stored in
-   DNS.  In both cases, a record containing the message signature/MAC is
-   included as the final resource record in a DNS message.  Keyed
-   hashes, used in TSIG, are inexpensive to calculate and verify.
-   Public key encryption, as used in SIG(0), is more scalable as the
-   public keys are stored in DNS.
-
-1.3 - Comparison of data authentication and message authentication
-
-   Message based authentication, using TSIG or SIG(0), provides
-   protection for the entire message with a single signing and single
-   verification which, in the case of TSIG, is a relatively inexpensive
-   MAC creation and check.  For update requests, this signature can
-   establish, based on policy or key negotiation, the authority to make
-   the request.
-
-   DNSSEC SIG records can be used to protect the integrity of individual
-   RRs or RRsets in a DNS message with the authority of the zone owner.
-   However, this cannot sufficiently protect the dynamic update request.
-
-   Using SIG records to secure RRsets in an update request is
-   incompatible with the design of update, as described below, and would
-   in any case require multiple expensive public key signatures and
-   verifications.
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 2]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   SIG records do not cover the message header, which includes record
-   counts.  Therefore, it is possible to maliciously insert or remove
-   RRsets in an update request without causing a verification failure.
-
-   If SIG records were used to protect the prerequisite section, it
-   would be impossible to determine whether the SIGs themselves were a
-   prerequisite or simply used for validation.
-
-   In the update section of an update request, signing requests to add
-   an RRset is straightforward, and this signature could be permanently
-   used to protect the data, as specified in [RFC2535].  However, if an
-   RRset is deleted, there is no data for a SIG to cover.
-
-1.4 - Data and message signatures
-
-   As specified in [RFC3008], the DNSSEC validation process performed by
-   a resolver MUST NOT process any non-zone keys unless local policy
-   dictates otherwise.  When performing secure dynamic update, all zone
-   data modified in a signed zone MUST be signed by a relevant zone key.
-   This completely disassociates authentication of an update request
-   from authentication of the data itself.
-
-   The primary usefulness of host and user keys, with respect to DNSSEC,
-   is to authenticate messages, including dynamic updates.  Thus, host
-   and user keys MAY be used to generate SIG(0) records to authenticate
-   updates and MAY be used in the TKEY [RFC2930] process to generate
-   TSIG shared secrets.  In both cases, no SIG records generated by
-   non-zone keys will be used in a DNSSEC validation process unless
-   local policy dictates.
-
-   Authentication of data, once it is present in DNS, only involves
-   DNSSEC zone keys and signatures generated by them.
-
-1.5 - Signatory strength
-
-   [RFC2535, section 3.1.2] defines the signatory field of a key as the
-   final 4 bits of the flags field, but does not define its value.  This
-   proposal leaves this field undefined.  Updating [RFC2535], this field
-   SHOULD be set to 0 in KEY records, and MUST be ignored.
-
-2 - Authentication
-
-   TSIG or SIG(0) records MUST be included in all secure dynamic update
-   messages.  This allows the server to verifiably determine the
-   originator of a message.  If the message contains authentication in
-   the form of a SIG(0), the identity of the sender (that is, the
-   principal) is the owner of the KEY RR that generated the SIG(0).  If
-   the message contains a TSIG generated by a statically configured
-
-
-
-Wellington                  Standards Track                     [Page 3]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   shared secret, the principal is the same as or derived from the
-   shared secret name.  If the message contains a TSIG generated by a
-   dynamically configured shared secret, the principal is the same as
-   the one that authenticated the TKEY process; if the TKEY process was
-   unauthenticated, no information is known about the principal, and the
-   associated TSIG shared secret MUST NOT be used for secure dynamic
-   update.
-
-   SIG(0) signatures SHOULD NOT be generated by zone keys, since
-   transactions are initiated by a host or user, not a zone.
-
-   DNSSEC SIG records (other than SIG(0)) MAY be included in an update
-   message, but MUST NOT be used to authenticate the update request.
-
-   If an update fails because it is signed with an unauthorized key, the
-   server MUST indicate failure by returning a message with RCODE
-   REFUSED.  Other TSIG, SIG(0), or dynamic update errors are returned
-   as specified in the appropriate protocol description.
-
-3 - Policy
-
-   All policy is configured by the zone administrator and enforced by
-   the zone's primary name server.  Policy dictates the authorized
-   actions that an authenticated principal can take.  Policy checks are
-   based on the principal and the desired action, where the principal is
-   derived from the message signing key and applied to dynamic update
-   messages signed with that key.
-
-   The server's policy defines criteria which determine if the key used
-   to sign the update is permitted to perform the requested updates.  By
-   default, a principal MUST NOT be permitted to make any changes to
-   zone data; any permissions MUST be enabled though configuration.
-
-   The policy is fully implemented in the primary zone server's
-   configuration for several reasons.  This removes limitations imposed
-   by encoding policy into a fixed number of bits (such as the KEY RR's
-   signatory field).  Policy is only relevant in the server applying it,
-   so there is no reason to expose it.  Finally, a change in policy or a
-   new type of policy should not affect the DNS protocol or data format,
-   and should not cause interoperability failures.
-
-3.1 - Standard policies
-
-   Implementations SHOULD allow access control policies to use the
-   principal as an authorization token, and MAY also allow policies to
-   grant permission to a signed message regardless of principal.
-
-
-
-
-
-Wellington                  Standards Track                     [Page 4]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   A common practice would be to restrict the permissions of a principal
-   by domain name.  That is, a principal could be permitted to add,
-   delete, or modify entries corresponding to one or more domain names.
-   Implementations SHOULD allow per-name access control, and SHOULD
-   provide a concise representation of the principal's own name, its
-   subdomains, and all names in the zone.
-
-   Additionally, a server SHOULD allow restricting updates by RR type,
-   so that a principal could add, delete, or modify specific record
-   types at certain names.  Implementations SHOULD allow per-type access
-   control, and SHOULD provide concise representations of all types and
-   all "user" types, where a user type is defined as one that does not
-   affect the operation of DNS itself.
-
-3.1.1 - User types
-
-   User types include all data types except SOA, NS, SIG, and NXT.  SOA
-   and NS records SHOULD NOT be modified by normal users, since these
-   types create or modify delegation points.  The addition of SIG
-   records can lead to attacks resulting in additional workload for
-   resolvers, and the deletion of SIG records could lead to extra work
-   for the server if the zone SIG was deleted.  Note that these records
-   are not forbidden, but not recommended for normal users.
-
-   NXT records MUST NOT be created, modified, or deleted by dynamic
-   update, as their update may cause instability in the protocol.  This
-   is an update to RFC 2136.
-
-   Issues concerning updates of KEY records are discussed in the
-   Security Considerations section.
-
-3.2 - Additional policies
-
-   Users are free to implement any policies.  Policies may be as
-   specific or general as desired, and as complex as desired.  They may
-   depend on the principal or any other characteristics of the signed
-   message.
-
-4 - Interaction with DNSSEC
-
-   Although this protocol does not change the way updates to secure
-   zones are processed, there are a number of issues that should be
-   clarified.
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 5]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-4.1 - Adding SIGs
-
-   An authorized update request MAY include SIG records with each RRset.
-   Since SIG records (except SIG(0) records) MUST NOT be used for
-   authentication of the update message, they are not required.
-
-   If a principal is authorized to update SIG records and there are SIG
-   records in the update, the SIG records are added without
-   verification.  The server MAY examine SIG records and drop SIGs with
-   a temporal validity period in the past.
-
-4.2 - Deleting SIGs
-
-   If a principal is authorized to update SIG records and the update
-   specifies the deletion of SIG records, the server MAY choose to
-   override the authority and refuse the update.  For example, the
-   server may allow all SIG records not generated by a zone key to be
-   deleted.
-
-4.3 - Non-explicit updates to SIGs
-
-   If the updated zone is secured, the RRset affected by an update
-   operation MUST, at the completion of the update, be signed in
-   accordance with the zone's signing policy.  This will usually require
-   one or more SIG records to be generated by one or more zone keys
-   whose private components MUST be online [RFC3008].
-
-   When the contents of an RRset are updated, the server MAY delete all
-   associated SIG records, since they will no longer be valid.
-
-4.4 - Effects on the zone
-
-   If any changes are made, the server MUST, if necessary, generate a
-   new SOA record and new NXT records, and sign these with the
-   appropriate zone keys.  Changes to NXT records by secure dynamic
-   update are explicitly forbidden.  SOA updates are allowed, since the
-   maintenance of SOA parameters is outside of the scope of the DNS
-   protocol.
-
-5 - Security Considerations
-
-   This document requires that a zone key and possibly other
-   cryptographic secret material be held in an on-line, network-
-   connected host, most likely a name server.  This material is at the
-   mercy of host security to remain a secret.  Exposing this secret puts
-   DNS data at risk of masquerade attacks.  The data at risk is that in
-   both zones served by the machine and delegated from this machine.
-
-
-
-
-Wellington                  Standards Track                     [Page 6]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   Allowing updates of KEY records may lead to undesirable results,
-   since a principal may be allowed to insert a public key without
-   holding the private key, and possibly masquerade as the key owner.
-
-6 - Acknowledgements
-
-   The author would like to thank the following people for review and
-   informative comments (in alphabetical order):
-
-   Harald Alvestrand
-   Donald Eastlake
-   Olafur Gudmundsson
-   Andreas Gustafsson
-   Bob Halley
-   Stuart Kwan
-   Ed Lewis
-
-7 - References
-
-   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
-              "Dynamic Updates in the Domain Name System", RFC 2136,
-              April 1997.
-
-   [RFC2137]  Eastlake, D., "Secure Domain Name System Dynamic Update",
-              RFC 2137, April 1997.
-
-   [RFC2535]  Eastlake, G., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-              Wellington, "Secret Key Transaction Signatures for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
-              RR)", RFC 2930, September 2000.
-
-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
-              (SIG(0)s)", RFC 2931, September 2000.
-
-   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
-              Signing Authority", RFC 3008, November 2000.
-
-
-
-
-Wellington                  Standards Track                     [Page 7]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-8 - Author's Address
-
-   Brian Wellington
-   Nominum, Inc.
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 381 6022
-   EMail: Brian.Wellington@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 8]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-9.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 9]
-
diff --git a/doc/rfc/rfc3008.txt b/doc/rfc/rfc3008.txt
deleted file mode 100644
index 08a4a8fa..00000000
--- a/doc/rfc/rfc3008.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      B. Wellington
-Request for Comments: 3008                                       Nominum
-Updates: 2535                                              November 2000
-Category: Standards Track
-
-
-         Domain Name System Security (DNSSEC) Signing Authority
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This document proposes a revised model of Domain Name System Security
-   (DNSSEC) Signing Authority.  The revised model is designed to clarify
-   earlier documents and add additional restrictions to simplify the
-   secure resolution process.  Specifically, this affects the
-   authorization of keys to sign sets of records.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-1 - Introduction
-
-   This document defines additional restrictions on DNSSEC signatures
-   (SIG) records relating to their authority to sign associated data.
-   The intent is to establish a standard policy followed by a secure
-   resolver; this policy can be augmented by local rules.  This builds
-   upon [RFC2535], updating section 2.3.6 of that document.
-
-   The most significant change is that in a secure zone, zone data is
-   required to be signed by the zone key.
-
-   Familiarity with the DNS system [RFC1034, RFC1035] and the DNS
-   security extensions [RFC2535] is assumed.
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 1]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-2 - The SIG Record
-
-   A SIG record is normally associated with an RRset, and "covers" (that
-   is, demonstrates the authenticity and integrity of) the RRset.  This
-   is referred to as a "data SIG".  Note that there can be multiple SIG
-   records covering an RRset, and the same validation process should be
-   repeated for each of them.  Some data SIGs are considered "material",
-   that is, relevant to a DNSSEC capable resolver, and some are
-   "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC
-   validation.  Immaterial SIGs may have application defined roles.  SIG
-   records may exist which are not bound to any RRset; these are also
-   considered immaterial.  The validation process determines which SIGs
-   are material; once a SIG is shown to be immaterial, no other
-   validation is necessary.
-
-   SIGs may also be used for transaction security.  In this case, a SIG
-   record with a type covered field of 0 is attached to a message, and
-   is used to protect message integrity.  This is referred to as a
-   SIG(0) [RFC2535, RFC2931].
-
-   The following sections define requirements for all of the fields of a
-   SIG record.  These requirements MUST be met in order for a DNSSEC
-   capable resolver to process this signature.  If any of these
-   requirements are not met, the SIG cannot be further processed.
-   Additionally, once a KEY has been identified as having generated this
-   SIG, there are requirements that it MUST meet.
-
-2.1 - Type Covered
-
-   For a data SIG, the type covered MUST be the same as the type of data
-   in the associated RRset.  For a SIG(0), the type covered MUST be 0.
-
-2.2 - Algorithm Number
-
-   The algorithm specified in a SIG MUST be recognized by the client,
-   and it MUST be an algorithm that has a defined SIG rdata format.
-
-2.3 - Labels
-
-   The labels count MUST be less than or equal to the number of labels
-   in the SIG owner name, as specified in [RFC2535, section 4.1.3].
-
-2.4 - Original TTL
-
-   The original TTL MUST be greater than or equal to the TTL of the SIG
-   record itself, since the TTL cannot be increased by intermediate
-   servers.  This field can be ignored for SIG(0) records.
-
-
-
-
-Wellington                  Standards Track                     [Page 2]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-2.5 - Signature Expiration and Inception
-
-   The current time at the time of validation MUST lie within the
-   validity period bounded by the inception and expiration times.
-
-2.6 - Key Tag
-
-   There are no restrictions on the Key Tag field, although it is
-   possible that future algorithms will impose constraints.
-
-2.7 - Signer's Name
-
-   The signer's name field of a data SIG MUST contain the name of the
-   zone to which the data and signature belong.  The combination of
-   signer's name, key tag, and algorithm MUST identify a zone key if the
-   SIG is to be considered material.  The only exception that the
-   signer's name field in a SIG KEY at a zone apex SHOULD contain the
-   parent zone's name, unless the KEY set is self-signed.  This document
-   defines a standard policy for DNSSEC validation; local policy may
-   override the standard policy.
-
-   There are no restrictions on the signer field of a SIG(0) record.
-   The combination of signer's name, key tag, and algorithm MUST
-   identify a key if this SIG(0) is to be processed.
-
-2.8 - Signature
-
-   There are no restrictions on the signature field.  The signature will
-   be verified at some point, but does not need to be examined prior to
-   verification unless a future algorithm imposes constraints.
-
-3 - The Signing KEY Record
-
-   Once a signature has been examined and its fields validated (but
-   before the signature has been verified), the resolver attempts to
-   locate a KEY that matches the signer name, key tag, and algorithm
-   fields in the SIG.  If one is not found, the SIG cannot be verified
-   and is considered immaterial.  If KEYs are found, several fields of
-   the KEY record MUST have specific values if the SIG is to be
-   considered material and authorized.  If there are multiple KEYs, the
-   following checks are performed on all of them, as there is no way to
-   determine which one generated the signature until the verification is
-   performed.
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 3]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-3.1 - Type Flags
-
-   The signing KEY record MUST have a flags value of 00 or 01
-   (authentication allowed, confidentiality optional) [RFC2535, 3.1.2].
-   A DNSSEC resolver MUST only trust signatures generated by keys that
-   are permitted to authenticate data.
-
-3.2 - Name Flags
-
-   The interpretation of this field is considerably different for data
-   SIGs and SIG(0) records.
-
-3.2.1 - Data SIG
-
-   If the SIG record covers an RRset, the name type of the associated
-   KEY MUST be 01 (zone) [RFC2535, 3.1.2].  This updates RFC 2535,
-   section 2.3.6.  The DNSSEC validation process performed by a resolver
-   MUST ignore all keys that are not zone keys unless local policy
-   dictates otherwise.
-
-   The primary reason that RFC 2535 allows host and user keys to
-   generate material DNSSEC signatures is to allow dynamic update
-   without online zone keys; that is, avoid storing private keys in an
-   online server.  The desire to avoid online signing keys cannot be
-   achieved, though, because they are necessary to sign NXT and SOA sets
-   [RFC3007].  These online zone keys can sign any incoming data.
-   Removing the goal of having no online keys removes the reason to
-   allow host and user keys to generate material signatures.
-
-   Limiting material signatures to zone keys simplifies the validation
-   process.  The length of the verification chain is bounded by the
-   name's label depth.  The authority of a key is clearly defined; a
-   resolver does not need to make a potentially complicated decision to
-   determine whether a key has the proper authority to sign data.
-
-   Finally, there is no additional flexibility granted by allowing
-   host/user key generated material signatures.  As long as users and
-   hosts have the ability to authenticate update requests to the primary
-   zone server, signatures by zone keys are sufficient to protect the
-   integrity of the data to the world at large.
-
-3.2.2 - SIG(0)
-
-   If the SIG record is a SIG(0) protecting a message, the name type of
-   the associated KEY SHOULD be 00 (user) or 10 (host/entity).
-   Transactions are initiated by a host or user, not a zone, so zone
-   keys SHOULD not generate SIG(0) records.
-
-
-
-
-Wellington                  Standards Track                     [Page 4]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-   A client is either explicitly executed by a user or on behalf of a
-   host, therefore the name type of a SIG(0) generated by a client
-   SHOULD be either user or host.  A nameserver is associated with a
-   host, and its use of SIG(0) is not associated with a particular zone,
-   so the name type of a SIG(0) generated by a nameserver SHOULD be
-   host.
-
-3.3 - Signatory Flags
-
-   This document does not assign any values to the signatory field, nor
-   require any values to be present.
-
-3.4 - Protocol
-
-   The signing KEY record MUST have a protocol value of 3 (DNSSEC) or
-   255 (ALL).  If a key is not specified for use with DNSSEC, a DNSSEC
-   resolver MUST NOT trust any signature that it generates.
-
-3.5 - Algorithm Number
-
-   The algorithm field MUST be identical to that of the generated SIG
-   record, and MUST meet all requirements for an algorithm value in a
-   SIG record.
-
-4 - Security Considerations
-
-   This document defines a standard baseline for a DNSSEC capable
-   resolver.  This is necessary for a thorough security analysis of
-   DNSSEC, if one is to be done.
-
-   Specifically, this document places additional restrictions on SIG
-   records that a resolver must validate before the signature can be
-   considered worthy of DNSSEC trust.  This simplifies the protocol,
-   making it more robust and able to withstand scrutiny by the security
-   community.
-
-5 - Acknowledgements
-
-   The author would like to thank the following people for review and
-   informative comments (in alphabetical order):
-
-   Olafur Gudmundsson
-   Ed Lewis
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 5]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-6 - References
-
-   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
-              "Dynamic Updates in the Domain Name System", RFC 2136,
-              April 1997.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
-              (SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC3007]      Wellington, B., "Simple Secure Domain Name System
-              (DNS) Dynamic Update", RFC 3007, November 2000.
-
-7 - Author's Address
-
-   Brian Wellington
-   Nominum, Inc.
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 381 6022
-   EMail: Brian.Wellington@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 6]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-8  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 7]
-
diff --git a/doc/rfc/rfc3071.txt b/doc/rfc/rfc3071.txt
deleted file mode 100644
index 2c4d52fc..00000000
--- a/doc/rfc/rfc3071.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         J. Klensin
-Request for Comments: 3071                                 February 2001
-Category: Informational
-
-
-      Reflections on the DNS, RFC 1591, and Categories of Domains
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   RFC 1591, "Domain Name System Structure and Delegation", laid out the
-   basic administrative design and principles for the allocation and
-   administration of domains, from the top level down.  It was written
-   before the introduction of the world wide web (WWW) and rapid growth
-   of the Internet put significant market, social, and political
-   pressure on domain name allocations.  In recent years, 1591 has been
-   cited by all sides in various debates, and attempts have been made by
-   various bodies to update it or adjust its provisions, sometimes under
-   pressures that have arguably produced policies that are less well
-   thought out than the original.  Some of those efforts have begun from
-   misconceptions about the provisions of 1591 or the motivation for
-   those provisions.  The current directions of the Internet Corporation
-   for Assigned Names and Numbers (ICANN) and other groups who now
-   determine the Domain Name System (DNS) policy directions appear to be
-   drifting away from the policies and philosophy of 1591.  This
-   document is being published primarily for historical context and
-   comparative purposes, essentially to document some thoughts about how
-   1591 might have been interpreted and adjusted by the Internet
-   Assigned Numbers Authority (IANA) and ICANN to better reflect today's
-   world while retaining characteristics and policies that have proven
-   to be effective in supporting Internet growth and stability.  An
-   earlier variation of this memo was submitted to ICANN as a comment on
-   its evolving Top-level Domain (TLD) policies.
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                      [Page 1]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-1.  Introduction
-
-   RFC 1591 [1] has been heavily discussed and referenced in the last
-   year or two, especially in discussions within ICANN and its
-   predecessors about the creation, delegation, and management of top-
-   level domains.  In particular, the ICANN Domain Name Supporting
-   Organization (DNSO), and especially its ccTLD constituency, have been
-   the home of many discussions in which 1591 and interpretations of it
-   have been cited in support of a variety of sometimes-contradictory
-   positions.  During that period, other discussions have gone on to try
-   to reconstruct the thinking that went into RFC 1591.  Those in turn
-   have led me and others to muse on how that original thinking might
-   relate to some of the issues being raised.  1591 is, I believe, one
-   of Jon Postel's masterpieces, drawing together very different
-   philosophies (e.g., his traditional view that people are basically
-   reasonable and will do the right thing if told what it is with some
-   stronger mechanisms when that model is not successful) into a single
-   whole.
-
-   RFC 1591 was written in the context of the assumption that what it
-   described as generic TLDs would be bound to policies and categories
-   of registration (see the "This domain is intended..."  text in
-   section 2) while ccTLDs were expected to be used primarily to support
-   users and uses within and for a country and its residents.  The
-   notion that different domains would be run in different ways --albeit
-   within the broad contexts of "public service on behalf of the
-   Internet community" and "trustee... for the global Internet
-   community"-- was considered a design feature and a safeguard against
-   a variety of potential abuses.  Obviously the world has changed in
-   many ways in the seven or eight years since 1591 was written.  In
-   particular, the Internet has become more heavily used and, because
-   the design of the world wide web has put domain names in front of
-   users, top-level domain names and registrations in them have been
-   heavily in demand: not only has the number of hosts increased
-   dramatically during that time, but the ratio between registered
-   domain names and physical hosts has increased very significantly.
-
-   The issues 1591 attempted to address when it was written and those we
-   face today have not changed significantly in principle.  But one
-   alternative to present trends would be to take a step back to refine
-   it into a model that can function effectively today.  Therefore, it
-   may be useful to try to reconstruct 1591's principles and think about
-   their applicability today as a model that could continue to be
-   applied: not because it is historically significant, but because many
-   of its elements have proven to work reasonably well, even in
-   difficult situations.  In particular, for many domains (some in
-   1591's "generic" list and others in its "country code" category) the
-   notion of "public service" --expected then to imply being carried out
-
-
-
-Klensin                      Informational                      [Page 2]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   at no or minimal cost to the users, not merely on a non-profit
-   basis-- has yielded to profitability calculations.  And, in most of
-   the rest, considerations of at least calculating and recovering costs
-   have crept in.  While many of us feel some nostalgia for the old
-   system, it is clear that its days are waning if not gone: perhaps the
-   public service notions as understood when 1591 was written just don't
-   scale to rapid internet growth and very large numbers of
-   yregistrations.
-
-   In particular, some ccTLDs have advertised for registrations outside
-   the designated countries (or other entities), while others have made
-   clear decisions to allow registrations by non-nationals.  These
-   decisions and others have produced protests from many sides,
-   suggesting, in turn, that a recategorization is in order.  For
-   example, we have heard concerns by governments and managers of
-   traditional, "public service", in-country, ccTLDs about excessive
-   ICANN interference and fears of being forced to conform to
-   internationally-set policies for dispute resolution when their
-   domestic ones are considered more appropriate.  We have also heard
-   concerns from registrars and operators of externally-marketed ccTLDs
-   about unreasonable government interference and from gTLD registrars
-   and registries about unreasonable competition from aggressively
-   marketed ccTLDs.  The appropriate distinction is no longer between
-   what RFC 1591 described as "generic" TLDs (but which were really
-   intended to be "purpose-specific", a term I will use again below) and
-   ccTLDs but among:
-
-      (i) true "generic" TLDs, in which any registration is acceptable
-      and, ordinarily, registrations from all sources are actively
-      promoted.  This list currently includes (the formerly purpose-
-      specific) COM, NET, and ORG, and some ccTLDs.  There have been
-      proposals from time to time for additional TLDs of this variety in
-      which, as with COM (and, more recently, NET and ORG) anyone
-      (generally subject only to name conflicts and national law) could
-      register who could pay the fees.
-
-      (ii) purpose-specific TLDs, in which registration is accepted only
-      from organizations or individuals meeting particular
-      qualifications, but where those qualifications are not tied to
-      national boundaries.  This list currently includes INT, EDU, the
-      infrastructure domain ARPA, and, arguably, the specialized US
-      Government TLDs MIL and GOV.  There have been proposals from time
-      to time for other international TLDs of this variety, e.g., for
-      medical entities such as physicians and hospitals and for museums.
-      ICANN has recently approved several TLDs of this type and
-      describes them as "sponsored" TLDs.
-
-
-
-
-
-Klensin                      Informational                      [Page 3]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-      (iii) Country domains, operated according to the original
-      underlying assumptions of 1591, i.e., registrants are largely
-      expected to be people or other entities within the country.  While
-      external registrations might be accepted by some of these, the
-      country does not aggressively advertise for such registrations,
-      nor does anyone expect to derive significant fee revenue from
-      them.  All current domains in this category are ccTLDs, but not
-      all ccTLDs are in this category.
-
-   These categories are clearly orthogonal to the association between
-   the use of the IS 3166-1 registered code list [2] and two-letter
-   "country" domain names.  If that relationship is to be maintained
-   (and I believe it is desirable), the only inherent requirement is
-   that no two-letter TLDs be created except from that list (in order to
-   avoid future conflicts).  ICANN should control the allocation and
-   delegation of TLDs using these, and other, criteria, but only
-   registered 3166-1 two letter codes should be used as two-letter TLDs.
-
-2. Implications of the Categories
-
-   If we had adopted this type of three-way categorization and could
-   make it work, I believe it would have presented several opportunities
-   for ICANN and the community more generally to reduce controversies
-   and move forward.  Of course, there will be cases where the
-   categorization of a particular domain and its operating style will
-   not be completely clear-cut (see section 3, below).  But having ICANN
-   work out procedures for dealing with those (probably few) situations
-   appears preferable to strategies that would tend to propel ICANN into
-   areas that are beyond its competence or that might require
-   significant expansion of its mandate.
-
-   First, the internally-operated ccTLDs (category iii above) should not
-   be required to have much interaction with ICANN or vice versa.  Once
-   a domain of this sort is established and delegated, and assuming that
-   the "admin contact in the country" rule is strictly observed, the
-   domain should be able to function effectively without ICANN
-   intervention or oversight.  In particular, while a country might
-   choose to adopt the general ICANN policies about dispute resolution
-   or name management, issues that arise in these areas might equally
-   well be dealt with exclusively under applicable national laws.  If a
-   domain chooses to use ICANN services that cost resources to provide,
-   it should contribute to ICANN's support, but, if it does not, ICANN
-   should not presume to charge it for other than a reasonable fraction
-   of the costs to ICANN of operating the root, root servers, and any
-   directory systems that are generally agreed upon to be necessary and
-   in which the domain participates.
-
-
-
-
-
-Klensin                      Informational                      [Page 4]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   By contrast, ccTLDs operated as generic domains ought to be treated
-   as generic domains.  ICANN dispute resolution and name management
-   policies and any special rules developed to protect the Internet
-   public in multiple registrar or registry situations should reasonably
-   apply.
-
-3.  Telling TLD types apart
-
-   If appropriate policies are adopted, ccTLDs operated as generic
-   domains (category (i) above) and those operated as country domains
-   (category (iii) above) ought to be able to be self-identified.  There
-   are several criteria that could be applied to make this
-   determination.  For example, either a domain is aggressively seeking
-   outside registrations or it is not and either the vast majority of
-   registrants in a domain are in-country or they are not.  One could
-   also think of this as the issue of having some tangible level of
-   presence in the jurisdiction - e.g., is the administrative contact
-   subject, in practical terms, to the in-country laws, or are the
-   registration rules such that it is reasonably likely that a court in
-   the jurisdiction of the country associated with the domain can
-   exercise jurisdiction and enforce a judgment against the registrant.
-
-   One (fairly non-intrusive) rule ICANN might well impose on all top-
-   level domains is that they identify and publish the policies they
-   intend to use.  E.g., registrants in a domain that will use the laws
-   of one particular country to resolve disputes should have a
-   reasonable opportunity to understand those policies prior to
-   registration and to make other arrangements (e.g., to register
-   elsewhere) if that mechanism for dispute resolution is not
-   acceptable.  Giving IANA (as the root registrar) incorrect
-   information about the purpose and use of a domain should be subject
-   to challenge, and should be grounds for reviewing the appropriateness
-   of the domain delegation, just as not acting consistently and
-   equitably provides such grounds under the original provisions of RFC
-   1591.
-
-   In order to ensure the availability of accurate and up-to-date
-   registration information the criteria must be consistent, and
-   consistent with more traditional gTLDs, for all nominally country
-   code domains operating as generic TLDs.
-
-4. The role of ICANN in country domains
-
-   ICANN (and IANA) should, as described above, have as little
-   involvement as possible in the direction of true country [code]
-   domains (i.e., category (iii)).  There is no particular reason why
-
-
-
-
-
-Klensin                      Informational                      [Page 5]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   these domains should be subject to ICANN regulation beyond the basic
-   principles of 1591 and associated arrangements needed to ensure
-   Internet interoperability and stability.
-
-   ICANN's avoiding such involvement strengthens it: the desirability of
-   avoiding collisions with national sovereignty, determinations about
-   government legitimacy, and the authority of someone purportedly
-   writing on behalf of a government, is as important today as it was
-   when 1591 was written.  The alternatives take us quickly from
-   "administration" into "internet governance" or, in the case of
-   determining which claimant is the legitimate government of a country,
-   "international relations", and the reasons for not moving in that
-   particular direction are legion.
-
-5. The role of governments
-
-   The history of IANA strategy in handling ccTLDs included three major
-   "things to avoid" considerations:
-
-      * Never get involved in determining which entities were countries
-        and which ones were not.
-
-      * Never get involved in determining who was, or was not, the
-        legitimate government of a country.  And, more generally, avoid
-        deciding what entity --government, religion, commercial,
-        academic, etc.-- has what legitimacy or rights.
-
-      * If possible, never become involved in in-country disputes.
-        Instead, very strongly encourage internal parties to work
-        problems out among themselves.  At most, adopt a role as
-        mediator and educator, rather than judge, unless abuses are very
-        clear and clearly will not be settled by any internal mechanism.
-
-   All three considerations were obviously intended to avoid IANA's
-   being dragged into a political morass in which it had (and, I
-   suggest, has) no competence to resolve the issues and could only get
-   bogged down.  The first consideration was the most visible (and the
-   easiest) and was implemented by strict and careful adherence (see
-   below) to the ISO 3166 registered Country Code list.  If an entity
-   had a code, it was eligible to be registered with a TLD (although
-   IANA was free to apply additional criteria-most of them stated in
-   1591).  If it did not, there were no exceptions: the applicant's only
-   recourse was a discussion with the 3166 Registration Authority (now
-   Maintenance Agency, often known just as "3166/MA") or the UN
-   Statistical Office (now Statistics Bureau), not with IANA.
-
-
-
-
-
-
-Klensin                      Informational                      [Page 6]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   There are actually five ccTLD exceptions to the strict rules.  One,
-   "UK", is historical: it predates the adoption of ISO 3166 for this
-   purpose.  The others --Ascension Island, Guernsey, Isle of Man, and
-   Jersey --are arguably, at least in retrospect, just mistakes.
-   Regardless of the historical reasons (about which there has been much
-   speculation), it is almost certainly the case that the right way to
-   handle mistakes of this sort is to acknowledge them and move on,
-   rather than trying to use them as precedents to justify more
-   mistakes.
-
-   This, obviously, is also the argument against use of the "reserved"
-   list (technically internal to the 3166 maintenance activity, and not
-   part of the Standard): since IANA (or ICANN) can ask that a name be
-   placed on that list, there is no rule of an absolute determination by
-   an external organization.  Purported countries can come to ICANN,
-   insist on having delegations made and persuade ICANN to ask that the
-   names be reserved.  Then, since the reserved name would exist, they
-   could insist that the domain be delegated.  Worse, someone could use
-   another organization to request reservation of the name by 3166/MA;
-   once it was reserved, ICANN might be hard-pressed not to do the
-   delegation.  Of course, ICANN could (and probably would be forced to)
-   adopt additional criteria other than appearance on the "reserved
-   list" in order to delegate such domains.  But those criteria would
-   almost certainly be nearly equivalent to determining which applicants
-   were legitimate and stable enough to be considered a country, the
-   exact decision process that 1591 strove to avoid.
-
-   The other two considerations were more subtle and not always
-   successful: from time to time, both before and after the formal
-   policy shifted toward "governments could have their way", IANA
-   received letters from people purporting to be competent government
-   authorities asking for changes.  Some of them turned out later to not
-   have that authority or appropriate qualifications.  The assumption of
-   1591 itself was that, if the "administrative contact in country" rule
-   was strictly observed, as was the rule that delegation changes
-   requested by the administrative contact would be honored, then, if a
-   government _really_ wanted to assert itself, it could pressure the
-   administrative contact into requesting the changes it wanted, using
-   whatever would pass for due process in that country.  And the ability
-   to apply that process and pressure would effectively determine who
-   was the government and who wasn't, and would do so far more
-   effectively than any IANA evaluation of, e.g., whether the letterhead
-   on a request looked authentic (and far more safely for ICANN than
-   asking the opinion of any particular other government or selection of
-   governments).
-
-
-
-
-
-
-Klensin                      Informational                      [Page 7]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   Specific language in 1591 permitted IANA to adopt a "work it out
-   yourselves; if we have to decide, we will strive for a solution that
-   is not satisfactory to any party" stance.  That approach was used
-   successfully, along with large doses of education, on many occasions
-   over the years, to avoid IANA's having to assume the role of judge
-   between conflicting parties.
-
-   Similar principles could be applied to the boundary between country-
-   code-based generic TLDs and country domains.  Different countries,
-   under different circumstances, might prefer to operate the ccTLD
-   either as a national service or as a profit center where the
-   "customers" were largely external.  Whatever decisions were made
-   historically, general Internet stability argues that changes should
-   not be made lightly.  At the same time, if a government wishes to
-   make a change, the best mechanism for doing so is not to involve
-   ICANN in a potential determination of legitimacy (or even to have
-   ICANN's Government Advisory Committee (GAC) try to formally make that
-   decision for individual countries) but for the relevant government to
-   use its own procedures to persuade the administrative contact to
-   request the change and for IANA to promptly and efficiently carry out
-   requests made by administrative contacts.
-
-6. Implications for the current ICANN DNSO structure.
-
-   The arguments by some of the ccTLD administrators that they are
-   different from the rest of the ICANN and DNSO structures are (in this
-   model) correct: they are different.  The ccTLDs that are operating as
-   generic TLDs should be separated from the ccTLD constituency and
-   joined to the gTLD constituency.  The country ccTLDs should be
-   separated from ICANN's immediate Supporting Organization structure,
-   and operate in a parallel and advisory capacity to ICANN, similar to
-   the arrangements used with the GAC.  The DNSO and country TLDs should
-   not be required to interact with each other except on a mutually
-   voluntary basis and, if ICANN needs interaction or advice from some
-   of all of those TLDs, it would be more appropriate to get it in the
-   form of an advisory body like the GAC rather than as DNSO
-   constituency.
-
-7. References
-
-   [1] Postel, J., "Domain Name System Structure and Delegation", RFC
-       1591, March 1994.
-
-   [2] ISO 3166. ISO 3166-1. Codes for the representation of names of
-       countries and their subdivisions - Part 1: Country codes (1997).
-
-
-
-
-
-
-Klensin                      Informational                      [Page 8]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-8. Acknowledgements and disclaimer
-
-   These reflections have been prepared in my individual capacity and do
-   not necessarily reflect the views of my past or present employers.
-   Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel,
-   Geoff Huston, Havard Eidnes, and several anonymous reviewers, made
-   suggestions or offered editorial comments about earlier versions of
-   this document.  Cord Wischhoefer, of the ISO 3166/MA, was also kind
-   enough to look at the draft and supplied some useful details.  Those
-   comments contributed significantly to whatever clarity the document
-   has, but the author bears responsibility for the selection of
-   comments which were ultimately incorporated and the way in which the
-   conclusions were presented.
-
-9.  Security Considerations
-
-   This memo addresses the context for a set of administrative decisions
-   and procedures, and does not raise or address security issues.
-
-10. Author's Address
-
-   John C. Klensin
-   1770 Massachusetts Ave, Suite 322
-   Cambridge, MA 02140, USA
-
-   EMail: klensin@jck.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                      [Page 9]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-11. Full Copyright Statement
-
-   Copyright (C) The Internet Society 2001. All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others provided that the above copyright notice and this paragraph
-   are included on all such copies.  However, this document itself may
-   not be modified in any way, such as by removing the copyright notice
-   or references to the Internet Society or other Internet
-   organizations, except as required to translate it into languages
-   other than English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR  IMPLIED, INCLUDING
-   BUT NOT  LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY  IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 10]
-
diff --git a/doc/rfc/rfc3090.txt b/doc/rfc/rfc3090.txt
deleted file mode 100644
index 08008f7a..00000000
--- a/doc/rfc/rfc3090.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           E. Lewis
-Request for Comments: 3090                                      NAI Labs
-Category: Standards Track                                     March 2001
-
-
-          DNS Security Extension Clarification on Zone Status
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   The definition of a secured zone is presented, clarifying and
-   updating sections of RFC 2535.  RFC 2535 defines a zone to be secured
-   based on a per algorithm basis, e.g., a zone can be secured with RSA
-   keys, and not secured with DSA keys.  This document changes this to
-   define a zone to be secured or not secured regardless of the key
-   algorithm used (or not used).  To further simplify the determination
-   of a zone's status, "experimentally secure" status is deprecated.
-
-1 Introduction
-
-   Whether a DNS zone is "secured" or not is a question asked in at
-   least four contexts.  A zone administrator asks the question when
-   configuring a zone to use DNSSEC.  A dynamic update server asks the
-   question when an update request arrives, which may require DNSSEC
-   processing.  A delegating zone asks the question of a child zone when
-   the parent enters data indicating the status the child.  A resolver
-   asks the question upon receipt of data belonging to the zone.
-
-1.1 When a Zone's Status is Important
-
-   A zone administrator needs to be able to determine what steps are
-   needed to make the zone as secure as it can be.  Realizing that due
-   to the distributed nature of DNS and its administration, any single
-   zone is at the mercy of other zones when it comes to the appearance
-   of security.  This document will define what makes a zone qualify as
-   secure.
-
-
-
-
-Lewis                       Standards Track                     [Page 1]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-   A name server performing dynamic updates needs to know whether a zone
-   being updated is to have signatures added to the updated data, NXT
-   records applied, and other required processing.  In this case, it is
-   conceivable that the name server is configured with the knowledge,
-   but being able to determine the status of a zone by examining the
-   data is a desirable alternative to configuration parameters.
-
-   A delegating zone is required to indicate whether a child zone is
-   secured.  The reason for this requirement lies in the way in which a
-   resolver makes its own determination about a zone (next paragraph).
-   To shorten a long story, a parent needs to know whether a child
-   should be considered secured.  This is a two part question.  Under
-   what circumstances does a parent consider a child zone to be secure,
-   and how does a parent know if the child conforms?
-
-   A resolver needs to know if a zone is secured when the resolver is
-   processing data from the zone.  Ultimately, a resolver needs to know
-   whether or not to expect a usable signature covering the data.  How
-   this determination is done is out of the scope of this document,
-   except that, in some cases, the resolver will need to contact the
-   parent of the zone to see if the parent states that the child is
-   secured.
-
-1.2 Islands of Security
-
-   The goal of DNSSEC is to have each zone secured, from the root zone
-   and the top-level domains down the hierarchy to the leaf zones.
-   Transitioning from an unsecured DNS, as we have now, to a fully
-   secured - or "as much as will be secured" - tree will take some time.
-   During this time, DNSSEC will be applied in various locations in the
-   tree, not necessarily "top down."
-
-   For example, at a particular instant, the root zone and the "test."
-   TLD might be secured, but region1.test. might not be.  (For
-   reference, let's assume that region2.test. is secured.)  However,
-   subarea1.region1.test. may have gone through the process of becoming
-   secured, along with its delegations.  The dilemma here is that
-   subarea1 cannot get its zone keys properly signed as its parent zone,
-   region1, is not secured.
-
-   The colloquial phrase describing the collection of contiguous secured
-   zones at or below subarea1.region1.test. is an "island of security."
-   The only way in which a DNSSEC resolver will come to trust any data
-   from this island is if the resolver is pre-configured with the zone
-   key(s) for subarea1.region1.test., i.e., the root of the island of
-   security.  Other resolvers (not so configured) will recognize this
-   island as unsecured.
-
-
-
-
-Lewis                       Standards Track                     [Page 2]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-   An island of security begins with one zone whose public key is pre-
-   configured in resolvers.  Within this island are subzones which are
-   also secured.  The "bottom" of the island is defined by delegations
-   to unsecured zones.  One island may also be on top of another -
-   meaning that there is at least one unsecured zone between the bottom
-   of the upper island and the root of the lower secured island.
-
-   Although both subarea1.region1.test. and region2.test. have both been
-   properly brought to a secured state by the administering staff, only
-   the latter of the two is actually "globally" secured - in the sense
-   that all DNSSEC resolvers can and will verify its data.  The former,
-   subarea1, will be seen as secured by a subset of those resolvers,
-   just those appropriately configured.  This document refers to such
-   zones as being "locally" secured.
-
-   In RFC 2535, there is a provision for "certification authorities,"
-   entities that will sign public keys for zones such as subarea1.
-   There is another document, [RFC3008], that restricts this activity.
-   Regardless of the other document, resolvers would still need proper
-   configuration to be able to use the certification authority to verify
-   the data for the subarea1 island.
-
-1.2.1 Determining the closest security root
-
-   Given a domain, in order to determine whether it is secure or not,
-   the first step is to determine the closest security root.  The
-   closest security root is the top of an island of security whose name
-   has the most matching (in order from the root) right-most labels to
-   the given domain.
-
-   For example, given a name "sub.domain.testing.signed.exp.test.", and
-   given the secure roots "exp.test.", "testing.signed.exp.test." and
-   "not-the-same.xy.", the middle one is the closest.  The first secure
-   root shares 2 labels, the middle 4, and the last 0.
-
-   The reason why the closest is desired is to eliminate false senses of
-   insecurity because of a NULL key.  Continuing with the example, the
-   reason both "testing..." and "exp.test." are listed as secure root is
-   presumably because "signed.exp.test." is unsecured (has a NULL key).
-   If we started to descend from "exp.test." to our given domain
-   (sub...), we would encounter a NULL key and conclude that sub... was
-   unsigned.  However, if we descend from "testing..." and find keys
-   "domain...." then we can conclude that "sub..." is secured.
-
-   Note that this example assumes one-label deep zones, and assumes that
-   we do not configure overlapping islands of security.  To be clear,
-   the definition given should exclude "short.xy.test." from being a
-   closest security root for "short.xy." even though 2 labels match.
-
-
-
-Lewis                       Standards Track                     [Page 3]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-   Overlapping islands of security introduce no conceptually interesting
-   ideas and do not impact the protocol in anyway.  However, protocol
-   implementers are advised to make sure their code is not thrown for a
-   loop by overlaps.  Overlaps are sure to be configuration problems as
-   islands of security grow to encompass larger regions of the name
-   space.
-
-1.3 Parent Statement of Child Security
-
-   In 1.1 of this document, there is the comment "the parent states that
-   the child is secured."  This has caused quite a bit of confusion.
-
-   The need to have the parent "state" the status of a child is derived
-   from the following observation.  If you are looking to see if an
-   answer is secured, that it comes from an "island of security" and is
-   properly signed, you must begin at the (appropriate) root of the
-   island of security.
-
-   To find the answer you are inspecting, you may have to descend
-   through zones within the island of security.  Beginning with the
-   trusted root of the island, you descend into the next zone down.  As
-   you trust the upper zone, you need to get data from it about the next
-   zone down, otherwise there is a vulnerable point in which a zone can
-   be hijacked. When or if you reach a point of traversing from a
-   secured zone to an unsecured zone, you have left the island of
-   security and should conclude that the answer is unsecured.
-
-   However, in RFC 2535, section 2.3.4, these words seem to conflict
-   with the need to have the parent "state" something about a child:
-
-      There MUST be a zone KEY RR, signed by its superzone, for every
-      subzone if the superzone is secure.  This will normally appear in
-      the subzone and may also be included in the superzone.  But, in
-      the case of an unsecured subzone which can not or will not be
-      modified to add any security RRs, a KEY declaring the subzone to
-      be unsecured MUST appear with the superzone signature in the
-      superzone, if the superzone is secure.
-
-   The confusion here is that in RFC 2535, a secured parent states that
-   a child is secured by SAYING NOTHING ("may also be" as opposed to
-   "MUST also be").  This is counter intuitive, the fact that an absence
-   of data means something is "secured."  This notion, while acceptable
-   in a theoretic setting has met with some discomfort in an operation
-   setting.  However, the use of "silence" to state something does
-   indeed work in this case, so there hasn't been sufficient need
-   demonstrated to change the definition.
-
-
-
-
-
-Lewis                       Standards Track                     [Page 4]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-1.4 Impact on RFC 2535
-
-   This document updates sections of RFC 2535.  The definition of a
-   secured zone is an update to section 3.4 of the RFC.  Section 3.4 is
-   updated to eliminate the definition of experimental keys and
-   illustrate a way to still achieve the functionality they were
-   designed to provide.  Section 3.1.3 is updated by the specifying the
-   value of the protocol octet in a zone key.
-
-1.5 "MUST" and other key words
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
-   in this document are to be interpreted as described in [RFC 2119].
-   Currently, only "MUST" is used in this document.
-
-2 Status of a Zone
-
-   In this section, rules governing a zone's DNSSEC status are
-   presented.  There are three levels of security defined: global,
-   local, and unsecured.  A zone is globally secure when it complies
-   with the strictest set of DNSSEC processing rules.  A zone is locally
-   secured when it is configured in such a way that only resolvers that
-   are appropriately configured see the zone as secured.  All other
-   zones are unsecured.
-
-   Note: there currently is no document completely defining DNSSEC
-   verification rules.  For the purposes of this document, the strictest
-   rules are assumed to state that the verification chain of zone keys
-   parallels the delegation tree up to the root zone.  (See 2.b below.)
-   This is not intended to disallow alternate verification paths, just
-   to establish a baseline definition.
-
-   To avoid repetition in the rules below, the following terms are
-   defined.
-
-   2.a Zone signing KEY RR - A KEY RR whose flag field has the value 01
-   for name type (indicating a zone key) and either value 00 or value 01
-   for key type (indicating a key permitted to authenticate data).  (See
-   RFC 2535, section 3.1.2).  The KEY RR also has a protocol octet value
-   of DNSSEC (3) or ALL (255).
-
-   The definition updates RFC 2535's definition of a zone key.  The
-   requirement that the protocol field be either DNSSEC or ALL is a new
-   requirement (a change to section 3.1.3.)
-
-   2.b On-tree Validation - The authorization model in which only the
-   parent zone is recognized to supply a DNSSEC-meaningful signature
-   that is used by a resolver to build a chain of trust from the child's
-
-
-
-Lewis                       Standards Track                     [Page 5]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-   keys to a recognized root of security.  The term "on-tree" refers to
-   following the DNS domain hierarchy (upwards) to reach a trusted key,
-   presumably the root key if no other key is available.  The term
-   "validation" refers to the digital signature by the parent to prove
-   the integrity, authentication and authorization of the child's key to
-   sign the child's zone data.
-
-   2.c Off-tree Validation - Any authorization model that permits domain
-   names other than the parent's to provide a signature over a child's
-   zone keys that will enable a resolver to trust the keys.
-
-2.1 Globally Secured
-
-   A globally secured zone, in a nutshell, is a zone that uses only
-   mandatory to implement algorithms (RFC 2535, section 3.2) and relies
-   on a key certification chain that parallels the delegation tree (on-
-   tree validation).  Globally secured zones are defined by the
-   following rules.
-
-   2.1.a. The zone's apex MUST have a KEY RR set.  There MUST be at
-   least one zone signing KEY RR (2.a) of a mandatory to implement
-   algorithm in the set.
-
-   2.1.b. The zone's apex KEY RR set MUST be signed by a private key
-   belonging to the parent zone.  The private key's public companion
-   MUST be a zone signing KEY RR (2.a) of a mandatory to implement
-   algorithm and owned by the parent's apex.
-
-   If a zone cannot get a conforming signature from the parent zone, the
-   child zone cannot be considered globally secured.  The only exception
-   to this is the root zone, for which there is no parent zone.
-
-   2.1.c. NXT records MUST be deployed throughout the zone.  (Clarifies
-   RFC 2535, section 2.3.2.)  Note: there is some operational discomfort
-   with the current NXT record.  This requirement is open to
-   modification when two things happen.  First, an alternate mechanism
-   to the NXT is defined and second, a means by which a zone can
-   indicate that it is using an alternate method.
-
-   2.1.d. Each RR set that qualifies for zone membership MUST be signed
-   by a key that is in the apex's KEY RR set and is a zone signing KEY
-   RR (2.a) of a mandatory to implement algorithm.  (Updates 2535,
-   section 2.3.1.)
-
-   Mentioned earlier, the root zone is a special case.  The root zone
-   will be considered to be globally secured provided that if conforms
-   to the rules for locally secured, with the exception that rule 2.1.a.
-   be also met (mandatory to implement requirement).
-
-
-
-Lewis                       Standards Track                     [Page 6]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-2.2 Locally Secured
-
-   The term "locally" stems from the likely hood that the only resolvers
-   to be configured for a particular zone will be resolvers "local" to
-   an organization.
-
-   A locally secured zone is a zone that complies with rules like those
-   for a globally secured zone with the following exceptions.  The
-   signing keys may be of an algorithm that is not mandatory to
-   implement and/or the verification of the zone keys in use may rely on
-   a verification chain that is not parallel to the delegation tree
-   (off-tree validation).
-
-   2.2.a. The zone's apex MUST have a KEY RR set.  There MUST be at
-   least one zone signing KEY RR (2.a) in the set.
-
-   2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
-   one of the following two subclauses MUST hold true.
-
-   2.2.b.1 The private key's public companion MUST be pre-configured in
-   all the resolvers of interest.
-
-   2.2.b.2 The private key's public companion MUST be a zone signing KEY
-   RR (2.a) authorized to provide validation of the zone's apex KEY RR
-   set, as recognized by resolvers of interest.
-
-   The previous sentence is trying to convey the notion of using a
-   trusted third party to provide validation of keys.  If the domain
-   name owning the validating key is not the parent zone, the domain
-   name must represent someone the resolver trusts to provide
-   validation.
-
-   2.2.c. NXT records MUST be deployed throughout the zone.  Note: see
-   the discussion following 2.1.c.
-
-   2.2.d. Each RR set that qualifies for zone membership MUST be signed
-   by a key that is in the apex's KEY RR set and is a zone signing KEY
-   RR (2.a).  (Updates 2535, section 2.3.1.)
-
-2.3 Unsecured
-
-   All other zones qualify as unsecured.  This includes zones that are
-   designed to be experimentally secure, as defined in a later section
-   on that topic.
-
-
-
-
-
-
-
-Lewis                       Standards Track                     [Page 7]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-2.4 Wrap up
-
-   The designation of globally secured, locally secured, and unsecured
-   are merely labels to apply to zones, based on their contents.
-   Resolvers, when determining whether a signature is expected or not,
-   will only see a zone as secured or unsecured.
-
-   Resolvers that follow the most restrictive DNSSEC verification rules
-   will only see globally secured zones as secured, and all others as
-   unsecured, including zones which are locally secured.  Resolvers that
-   are not as restrictive, such as those that implement algorithms in
-   addition to the mandatory to implement algorithms, will see some
-   locally secured zones as secured.
-
-   The intent of the labels "global" and "local" is to identify the
-   specific attributes of a zone.  The words are chosen to assist in the
-   writing of a document recommending the actions a zone administrator
-   take in making use of the DNS security extensions.  The words are
-   explicitly not intended to convey a state of compliance with DNS
-   security standards.
-
-3 Experimental Status
-
-   The purpose of an experimentally secured zone is to facilitate the
-   migration from an unsecured zone to a secured zone.  This distinction
-   is dropped.
-
-   The objective of facilitating the migration can be achieved without a
-   special designation of an experimentally secure status.
-   Experimentally secured is a special case of locally secured.  A zone
-   administrator can achieve this by publishing a zone with signatures
-   and configuring a set of test resolvers with the corresponding public
-   keys.  Even if the public key is published in a KEY RR, as long as
-   there is no parent signature, the resolvers will need some pre-
-   configuration to know to process the signatures.  This allows a zone
-   to be secured with in the sphere of the experiment, yet still be
-   registered as unsecured in the general Internet.
-
-4 IANA Considerations
-
-   This document does not request any action from an assigned number
-   authority nor recommends any actions.
-
-
-
-
-
-
-
-
-
-Lewis                       Standards Track                     [Page 8]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-5 Security Considerations
-
-   Without a means to enforce compliance with specified protocols or
-   recommended actions, declaring a DNS zone to be "completely" secured
-   is impossible.  Even if, assuming an omnipotent view of DNS, one can
-   declare a zone to be properly configured for security, and all of the
-   zones up to the root too, a misbehaving resolver could be duped into
-   believing bad data.  If a zone and resolver comply, a non-compliant
-   or subverted parent could interrupt operations.  The best that can be
-   hoped for is that all parties are prepared to be judged secure and
-   that security incidents can be traced to the cause in short order.
-
-6 Acknowledgements
-
-   The need to refine the definition of a secured zone has become
-   apparent through the efforts of the participants at two DNSSEC
-   workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA-
-   funded research network), and other workshops.  Further discussions
-   leading to the document include Olafur Gudmundsson, Russ Mundy,
-   Robert Watson, and Brian Wellington.  Roy Arends, Ted Lindgreen and
-   others have contributed significant input via the namedroppers
-   mailing list.
-
-7 References
-
-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-             STD 13, RFC 1034, November 1987.
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-             Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound,
-             "Dynamic Updates in the Domain Name System", RFC 2136,
-             April 1997.
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-             2535, March 1999.
-
-   [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS)
-             Dynamic Update", RFC 3007, November 2000.
-
-   [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
-             Signing Authority", RFC 3008, November 2000.
-
-
-
-
-
-Lewis                       Standards Track                     [Page 9]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-10 Author's Address
-
-   Edward Lewis
-   NAI Labs
-   3060 Washington Road Glenwood
-   MD 21738
-
-   Phone: +1 443 259 2352
-   EMail: lewis@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis                       Standards Track                    [Page 10]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-11 Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis                       Standards Track                    [Page 11]
-
diff --git a/doc/rfc/rfc3110.txt b/doc/rfc/rfc3110.txt
deleted file mode 100644
index 76469486..00000000
--- a/doc/rfc/rfc3110.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 3110                                      Motorola
-Obsoletes: 2537                                                 May 2001
-Category: Standards Track
-
-
-      RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document describes how to produce RSA/SHA1 SIG resource records
-   (RRs) in Section 3 and, so as to completely replace RFC 2537,
-   describes how to produce RSA KEY RRs in Section 2.
-
-   Since the adoption of a Proposed Standard for RSA signatures in the
-   DNS (Domain Name Space), advances in hashing have been made.  A new
-   DNS signature algorithm is defined to make these advances available
-   in SIG RRs.  The use of the previously specified weaker mechanism is
-   deprecated.  The algorithm number of the RSA KEY RR is changed to
-   correspond to this new SIG algorithm.  No other changes are made to
-   DNS security.
-
-Acknowledgements
-
-   Material and comments from the following have been incorporated and
-   are gratefully acknowledged:
-
-      Olafur Gudmundsson
-
-      The IESG
-
-      Charlie Kaufman
-
-      Steve Wang
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 1]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-Table of Contents
-
-   1. Introduction................................................... 2
-   2. RSA Public KEY Resource Records................................ 3
-   3. RSA/SHA1 SIG Resource Records.................................. 3
-   4. Performance Considerations..................................... 4
-   5. IANA Considerations............................................ 5
-   6. Security Considerations........................................ 5
-   References........................................................ 5
-   Author's Address.................................................. 6
-   Full Copyright Statement.......................................... 7
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information [RFC1034, 1035, etc.].  The DNS has been extended
-   to include digital signatures and cryptographic keys as described in
-   [RFC2535].  Thus the DNS can now be secured and used for secure key
-   distribution.
-
-   Familiarity with the RSA and SHA-1 algorithms is assumed [Schneier,
-   FIP180] in this document.
-
-   RFC 2537 described how to store RSA keys and RSA/MD5 based signatures
-   in the DNS.  However, since the adoption of RFC 2537, continued
-   cryptographic research has revealed hints of weakness in the MD5
-   [RFC1321] algorithm used in RFC 2537.  The SHA1 Secure Hash Algorithm
-   [FIP180], which produces a larger hash, has been developed.  By now
-   there has been sufficient experience with SHA1 that it is generally
-   acknowledged to be stronger than MD5.  While this stronger hash is
-   probably not needed today in most secure DNS zones, critical zones
-   such a root, most top level domains, and some second and third level
-   domains, are sufficiently valuable targets that it would be negligent
-   not to provide what are generally agreed to be stronger mechanisms.
-   Furthermore, future advances in cryptanalysis and/or computer speeds
-   may require a stronger hash everywhere.  In addition, the additional
-   computation required by SHA1 above that required by MD5 is
-   insignificant compared with the computational effort required by the
-   RSA modular exponentiation.
-
-   This document describes how to produce RSA/SHA1 SIG RRs in Section 3
-   and, so as to completely replace RFC 2537, describes how to produce
-   RSA KEY RRs in Section 2.
-
-   Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for
-   DNSSEC.  The generation of RSA/MD5 SIG RRs as described in RFC 2537
-   is NOT RECOMMENDED.
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 2]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "NOT
-   RECOMMENDED", and "MAY" in this document are to be interpreted as
-   described in RFC 2119.
-
-2. RSA Public KEY Resource Records
-
-   RSA public keys are stored in the DNS as KEY RRs using algorithm
-   number 5 [RFC2535].  The structure of the algorithm specific portion
-   of the RDATA part of such RRs is as shown below.
-
-         Field             Size
-         -----             ----
-         exponent length   1 or 3 octets (see text)
-         exponent          as specified by length field
-         modulus           remaining space
-
-   For interoperability, the exponent and modulus are each limited to
-   4096 bits in length.  The public key exponent is a variable length
-   unsigned integer.  Its length in octets is represented as one octet
-   if it is in the range of 1 to 255 and by a zero octet followed by a
-   two octet unsigned length if it is longer than 255 bytes.  The public
-   key modulus field is a multiprecision unsigned integer.  The length
-   of the modulus can be determined from the RDLENGTH and the preceding
-   RDATA fields including the exponent.  Leading zero octets are
-   prohibited in the exponent and modulus.
-
-   Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this
-   algorithm number (rather than the algorithm number specified in the
-   obsoleted RFC 2537).
-
-   Note: This changes the algorithm number for RSA KEY RRs to be the
-   same as the new algorithm number for RSA/SHA1 SIGs.
-
-3. RSA/SHA1 SIG Resource Records
-
-   RSA/SHA1 signatures are stored in the DNS using SIG resource records
-   (RRs) with algorithm number 5.
-
-   The signature portion of the SIG RR RDATA area, when using the
-   RSA/SHA1 algorithm, is calculated as shown below.  The data signed is
-   determined as specified in RFC 2535.  See RFC 2535 for fields in the
-   SIG RR RDATA which precede the signature itself.
-
-         hash = SHA1 ( data )
-
-         signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 3]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-   where SHA1 is the message digest algorithm documented in [FIP180],
-   "|" is concatenation, "e" is the private key exponent of the signer,
-   and "n" is the modulus of the signer's public key.  01, FF, and 00
-   are fixed octets of the corresponding hexadecimal value.  "prefix" is
-   the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1
-   [RFC2437], that is,
-
-         hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
-
-   This prefix is included to make it easier to use standard
-   cryptographic libraries.  The FF octet MUST be repeated the maximum
-   number of times such that the value of the quantity being
-   exponentiated is one octet shorter than the value of n.
-
-   (The above specifications are identical to the corresponding parts of
-   Public Key Cryptographic Standard #1 [RFC2437].)
-
-   The size of "n", including most and least significant bits (which
-   will be 1) MUST be not less than 512 bits and not more than 4096
-   bits.  "n" and "e" SHOULD be chosen such that the public exponent is
-   small.  These are protocol limits.  For a discussion of key size see
-   RFC 2541.
-
-   Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.
-
-4. Performance Considerations
-
-   General signature generation speeds are roughly the same for RSA and
-   DSA [RFC2536].  With sufficient pre-computation, signature generation
-   with DSA is faster than RSA.  Key generation is also faster for DSA.
-   However, signature verification is an order of magnitude slower with
-   DSA when the RSA public exponent is chosen to be small as is
-   recommended for KEY RRs used in domain name system (DNS) data
-   authentication.
-
-   A public exponent of 3 minimizes the effort needed to verify a
-   signature.  Use of 3 as the public exponent is weak for
-   confidentiality uses since, if the same data can be collected
-   encrypted under three different keys with an exponent of 3 then,
-   using the Chinese Remainder Theorem [NETSEC], the original plain text
-   can be easily recovered.  If a key is known to be used only for
-   authentication, as is the case with DNSSEC, then an exponent of 3 is
-   acceptable.  However other applications in the future may wish to
-   leverage DNS distributed keys for applications that do require
-   confidentiality.  For keys which might have such other uses, a more
-   conservative choice would be 65537 (F4, the fourth fermat number).
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 4]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including DNS overhead.  Larger
-   transfers will perform correctly and extensions have been
-   standardized [RFC2671] to make larger transfers more efficient, it is
-   still advisable at this time to make reasonable efforts to minimize
-   the size of KEY RR sets stored within the DNS consistent with
-   adequate security.  Keep in mind that in a secure zone, at least one
-   authenticating SIG RR will also be returned.
-
-5. IANA Considerations
-
-   The DNSSEC algorithm number 5 is allocated for RSA/SHA1 SIG RRs and
-   RSA KEY RRs.
-
-6. Security Considerations
-
-   Many of the general security considerations in RFC 2535 apply.  Keys
-   retrieved from the DNS should not be trusted unless (1) they have
-   been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is essential and
-   dependent on local policy.  For particularly critical applications,
-   implementers are encouraged to consider the range of available
-   algorithms and key sizes.  See also RFC 2541, "DNS Security
-   Operational Considerations".
-
-References
-
-   [FIP180]   U.S. Department of Commerce, "Secure Hash Standard", FIPS
-              PUB 180-1, 17 Apr 1995.
-
-   [NETSEC]   Network Security: PRIVATE Communications in a PUBLIC
-              World, Charlie Kaufman, Radia Perlman, & Mike Speciner,
-              Prentice Hall Series in Computer Networking and
-              Distributed Communications, 1995.
-
-   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-              April 1992.
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 5]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2437]  Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
-              Specifications Version 2.0", RFC 2437, October 1998.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
-              (DNS)", RFC 2536, March 1999.
-
-   [RFC2537]  Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
-              System (DNS)", RFC 2537, March 1999.
-
-   [RFC2541]  Eastlake, D., "DNS Security Operational Considerations",
-              RFC 2541, March 1999.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-              2671, August 1999.
-
-   [Schneier] Bruce Schneier, "Applied Cryptography Second Edition:
-              protocols, algorithms, and source code in C", 1996, John
-              Wiley and Sons, ISBN 0-471-11709-9.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Phone:   +1-508-261-5434 (w)
-            +1-508-634-2066 (h)
-   Fax      +1-508-261-4777 (w)
-   EMail:   Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 6]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 7]
-
diff --git a/doc/rfc/rfc3123.txt b/doc/rfc/rfc3123.txt
deleted file mode 100644
index 3b2fe00e..00000000
--- a/doc/rfc/rfc3123.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            P. Koch
-Request for Comments: 3123                        Universitaet Bielefeld
-Category: Experimental                                         June 2001
-
-
-          A DNS RR Type for Lists of Address Prefixes (APL RR)
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  It does not specify an Internet standard of any kind.
-   Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   The Domain Name System (DNS) is primarily used to translate domain
-   names into IPv4 addresses using A RRs (Resource Records).  Several
-   approaches exist to describe networks or address ranges.  This
-   document specifies a new DNS RR type "APL" for address prefix lists.
-
-1. Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   Domain names herein are for explanatory purposes only and should not
-   be expected to lead to useful information in real life [RFC2606].
-
-2. Background
-
-   The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
-   associate addresses and other Internet infrastructure elements with
-   hierarchically built domain names.  Various types of resource records
-   have been defined, especially those for IPv4 and IPv6 [RFC2874]
-   addresses.  In [RFC1101] a method is described to publish information
-   about the address space allocated to an organisation.  In older BIND
-   versions, a weak form of controlling access to zone data was
-   implemented using TXT RRs describing address ranges.
-
-   This document specifies a new RR type for address prefix lists.
-
-
-
-
-
-Koch                          Experimental                      [Page 1]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-3. APL RR Type
-
-   An APL record has the DNS type of "APL" and a numeric value of 42
-   [IANA].  The APL RR is defined in the IN class only.  APL RRs cause
-   no additional section processing.
-
-4. APL RDATA format
-
-   The RDATA section consists of zero or more items (<apitem>) of the
-   form
-
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-      |                          ADDRESSFAMILY                        |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-      |             PREFIX            | N |         AFDLENGTH         |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-      /                            AFDPART                            /
-      |                                                               |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-      ADDRESSFAMILY     16 bit unsigned value as assigned by IANA
-                        (see IANA Considerations)
-      PREFIX            8 bit unsigned binary coded prefix length.
-                        Upper and lower bounds and interpretation of
-                        this value are address family specific.
-      N                 negation flag, indicates the presence of the
-                        "!" character in the textual format.  It has
-                        the value "1" if the "!" was given, "0" else.
-      AFDLENGTH         length in octets of the following address
-                        family dependent part (7 bit unsigned).
-      AFDPART           address family dependent part.  See below.
-
-   This document defines the AFDPARTs for address families 1 (IPv4) and
-   2 (IPv6).  Future revisions may deal with additional address
-   families.
-
-4.1. AFDPART for IPv4
-
-   The encoding of an IPv4 address (address family 1) follows the
-   encoding specified for the A RR by [RFC1035], section 3.4.1.
-
-   PREFIX specifies the number of bits of the IPv4 address starting at
-   the most significant bit.  Legal values range from 0 to 32.
-
-   Trailing zero octets do not bear any information (e.g., there is no
-   semantic difference between 10.0.0.0/16 and 10/16) in an address
-   prefix, so the shortest possible AFDLENGTH can be used to encode it.
-   However, for DNSSEC [RFC2535] a single wire encoding must be used by
-
-
-
-Koch                          Experimental                      [Page 2]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-   all.  Therefore the sender MUST NOT include trailing zero octets in
-   the AFDPART regardless of the value of PREFIX.  This includes cases
-   in which AFDLENGTH times 8 results in a value less than PREFIX.  The
-   AFDPART is padded with zero bits to match a full octet boundary.
-
-   An IPv4 AFDPART has a variable length of 0 to 4 octets.
-
-4.2. AFDPART for IPv6
-
-   The 128 bit IPv6 address (address family 2) is encoded in network
-   byte order (high-order byte first).
-
-   PREFIX specifies the number of bits of the IPv6 address starting at
-   the most significant bit.  Legal values range from 0 to 128.
-
-   With the same reasoning as in 4.1 above, the sender MUST NOT include
-   trailing zero octets in the AFDPART regardless of the value of
-   PREFIX.  This includes cases in which AFDLENGTH times 8 results in a
-   value less than PREFIX.  The AFDPART is padded with zero bits to
-   match a full octet boundary.
-
-   An IPv6 AFDPART has a variable length of 0 to 16 octets.
-
-5. Zone File Syntax
-
-   The textual representation of an APL RR in a DNS zone file is as
-   follows:
-
-   <owner>   IN   <TTL>   APL   {[!]afi:address/prefix}*
-
-   The data consists of zero or more strings of the address family
-   indicator <afi>, immediately followed by a colon ":", an address,
-   immediately followed by the "/" character, immediately followed by a
-   decimal numeric value for the prefix length.  Any such string may be
-   preceded by a "!" character.  The strings are separated by
-   whitespace.  The <afi> is the decimal numeric value of that
-   particular address family.
-
-5.1. Textual Representation of IPv4 Addresses
-
-   An IPv4 address in the <address> part of an <apitem> is in dotted
-   quad notation, just as in an A RR.  The <prefix> has values from the
-   interval 0..32 (decimal).
-
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 3]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-5.2. Textual Representation of IPv6 Addresses
-
-   The representation of an IPv6 address in the <address> part of an
-   <apitem> follows [RFC2373], section 2.2.  Legal values for <prefix>
-   are from the interval 0..128 (decimal).
-
-6. APL RR usage
-
-   An APL RR with empty RDATA is valid and implements an empty list.
-   Multiple occurrences of the same <apitem> in a single APL RR are
-   allowed and MUST NOT be merged by a DNS server or resolver.
-   <apitems> MUST be kept in order and MUST NOT be rearranged or
-   aggregated.
-
-   A single APL RR may contain <apitems> belonging to different address
-   families.  The maximum number of <apitems> is upper bounded by the
-   available RDATA space.
-
-   RRSets consisting of more than one APL RR are legal but the
-   interpretation is left to the particular application.
-
-7. Applicability Statement
-
-   The APL RR defines a framework without specifying any particular
-   meaning for the list of prefixes.  It is expected that APL RRs will
-   be used in different application scenarios which have to be
-   documented separately.  Those scenarios may be distinguished by
-   characteristic prefixes placed in front of the DNS owner name.
-
-   An APL application specification MUST include information on
-
-   o  the characteristic prefix, if any
-
-   o  how to interpret APL RRSets consisting of more than one RR
-
-   o  how to interpret an empty APL RR
-
-   o  which address families are expected to appear in the APL RRs for
-      that application
-
-   o  how to deal with APL RR list elements which belong to other
-      address families, including those not yet defined
-
-   o  the exact semantics of list elements negated by the "!" character
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 4]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-   Possible applications include the publication of address ranges
-   similar to [RFC1101], description of zones built following [RFC2317]
-   and in-band access control to limit general access or zone transfer
-   (AXFR) availability for zone data held in DNS servers.
-
-   The specification of particular application scenarios is out of the
-   scope of this document.
-
-8. Examples
-
-   The following examples only illustrate some of the possible usages
-   outlined in the previous section.  None of those applications are
-   hereby specified nor is it implied that any particular APL RR based
-   application does exist now or will exist in the future.
-
-  ; RFC 1101-like announcement of address ranges for foo.example
-  foo.example.             IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
-
-  ; CIDR blocks covered by classless delegation
-  42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
-                                  1:192.168.42.128/25 )
-
-  ; Zone transfer restriction
-  _axfr.sbo.example.       IN APL 1:127.0.0.1/32 1:172.16.64.0/22
-
-  ; List of address ranges for multicast
-  multicast.example.       IN APL 1:224.0.0.0/4  2:FF00:0:0:0:0:0:0:0/8
-
-   Note that since trailing zeroes are ignored in the first APL RR the
-   AFDLENGTH of both <apitems> is three.
-
-9. Security Considerations
-
-   Any information obtained from the DNS should be regarded as unsafe
-   unless techniques specified in [RFC2535] or [RFC2845] were used.  The
-   definition of a new RR type does not introduce security problems into
-   the DNS, but usage of information made available by APL RRs may
-   compromise security.  This includes disclosure of network topology
-   information and in particular the use of APL RRs to construct access
-   control lists.
-
-
-
-
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 5]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-10. IANA Considerations
-
-   This section is to be interpreted as following [RFC2434].
-
-   This document does not define any new namespaces.  It uses the 16 bit
-   identifiers for address families maintained by IANA in
-   http://www.iana.org/numbers.html.
-
-   The IANA assigned numeric RR type value 42 for APL [IANA].
-
-11. Acknowledgements
-
-   The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed
-   Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review
-   and constructive comments.
-
-12. References
-
-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-             STD 13, RFC 1034, November 1987.
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-             Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other
-             Types", RFC 1101, April 1989.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
-             Specification", RFC 2181, July 1997.
-
-   [RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
-             ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
-
-   [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
-             Architecture", RFC 2373, July 1998.
-
-   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
-             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-             October 1998.
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-             2535, March 1999.
-
-   [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names",
-             BCP 32, RFC 2606, June 1999.
-
-
-
-Koch                          Experimental                      [Page 6]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-             "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-             2845, May 2000.
-
-   [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
-             IPv6 Address Aggregation and Renumbering", RFC 2874, July
-             2000.
-
-   [IANA]    http://www.iana.org/assignments/dns-parameters
-
-13. Author's Address
-
-   Peter Koch
-   Universitaet Bielefeld
-   Technische Fakultaet
-   D-33594 Bielefeld
-   Germany
-
-   Phone: +49 521 106 2902
-   EMail: pk@TechFak.Uni-Bielefeld.DE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 7]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-14. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 8]
-
diff --git a/doc/rfc/rfc3152.txt b/doc/rfc/rfc3152.txt
deleted file mode 100644
index b226ce64..00000000
--- a/doc/rfc/rfc3152.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            R. Bush
-Request for Comments: 3152                                         RGnet
-BCP: 49                                                      August 2001
-Updates: 2874, 2772, 2766, 2553, 1886
-Category: Best Current Practice
-
-
-                         Delegation of IP6.ARPA
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document discusses the need for delegation of the IP6.ARPA DNS
-   zone, and specifies a plan for the technical operation thereof.
-
-1. Why IP6.ARPA?
-
-   In the IPv6 address space, there is a need for 'reverse mapping' of
-   addresses to DNS names analogous to that provided by the IN-ADDR.ARPA
-   zone for IPv4.
-
-   The IAB recommended that the ARPA top level domain (the name is now
-   considered an acronym for "Address and Routing Parameters Area") be
-   used for technical infrastructure sub-domains when possible.  It is
-   already in use for IPv4 reverse mapping and has been established as
-   the location for E.164 numbering on the Internet [RFC2916 RFC3026].
-
-   IETF consensus was reached that the IP6.ARPA domain be used for
-   address to DNS name mapping for the IPv6 address space [RFC2874].
-
-2. Obsoleted Usage
-
-   This document deprecates references to IP6.INT in [RFC1886] section
-   2.5, [RFC2553] section 6.2.3, [RFC2766] section 4.1, [RFC2772]
-   section 7.1.c, and [RFC2874] section 2.5.
-
-   In this context, 'deprecate' means that the old usage is not
-   appropriate for new implementations, and IP6.INT will likely be
-   phased out in an orderly fashion.
-
-
-
-Bush                     Best Current Practice                  [Page 1]
-
-RFC 3152                 Delegation of IP6.ARPA              August 2001
-
-
-3. IANA Considerations
-
-   This memo requests that the IANA delegate the IP6.ARPA domain
-   following instructions to be provided by the IAB.  Names within this
-   zone are to be further delegated to the regional IP registries in
-   accordance with the delegation of IPv6 address space to those
-   registries.  The names allocated should be hierarchic in accordance
-   with the address space assignment.
-
-4. Security Considerations
-
-   While DNS spoofing of address to name mapping has been exploited in
-   IPv4, delegation of the IP6.ARPA zone creates no new threats to the
-   security of the internet.
-
-5. References
-
-   [RFC1886]   Thomson, S. and C. Huitema, "DNS Extensions to support IP
-               version 6", RFC 1886, December 1995.
-
-   [RFC2553]   Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
-               "Basic Socket Interface Extensions for IPv6", RFC 2553,
-               March 1999.
-
-   [RFC2766]   Tsirtsis, G. and P. Srisuresh, "Network Address
-               Translation - Protocol Translation (NAT-PT)", RFC 2766,
-               February 2000.
-
-   [RFC2772]   Rockell, R. and R. Fink, "6Bone Backbone Routing
-               Guidelines", RFC 2772, February 2000.
-
-   [RFC2874]   Crawford, M. and C. Huitema, "DNS Extensions to Support
-               IPv6 Address Aggregation and Renumbering", RFC 2874, July
-               2001.
-
-   [RFC2916]   Faltstrom, P., "E.164 number and DNS", RFC 2916,
-               September 2000.
-
-   [RFC3026]   Blane, R., "Liaison to IETF/ISOC on ENUM", RFC 3026,
-               January 2001.
-
-
-
-
-
-
-
-
-
-
-
-Bush                     Best Current Practice                  [Page 2]
-
-RFC 3152                 Delegation of IP6.ARPA              August 2001
-
-
-6. Author's Address
-
-   Randy Bush
-   5147 Crystal Springs
-   Bainbridge Island, WA US-98110
-
-   Phone: +1 206 780 0431
-   EMail: randy@psg.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush                     Best Current Practice                  [Page 3]
-
-RFC 3152                 Delegation of IP6.ARPA              August 2001
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush                     Best Current Practice                  [Page 4]
-
diff --git a/doc/rfc/rfc3197.txt b/doc/rfc/rfc3197.txt
deleted file mode 100644
index 94cefa4c..00000000
--- a/doc/rfc/rfc3197.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 3197                                 InterNetShare
-Category: Informational                                    November 2001
-
-
-             Applicability Statement for DNS MIB Extensions
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document explains why, after more than six years as proposed
-   standards, the DNS Server and Resolver MIB extensions were never
-   deployed, and recommends retiring these MIB extensions by moving them
-   to Historical status.
-
-1. History
-
-   The road to the DNS MIB extensions was paved with good intentions.
-
-   In retrospect, it's obvious that the working group never had much
-   agreement on what belonged in the MIB extensions, just that we should
-   have some.  This happened during the height of the craze for MIB
-   extensions in virtually every protocol that the IETF was working on
-   at the time, so the question of why we were doing this in the first
-   place never got a lot of scrutiny.  Very late in the development
-   cycle we discovered that much of the support for writing the MIB
-   extensions in the first place had come from people who wanted to use
-   SNMP SET operations to update DNS zones on the fly.  Examination of
-   the security model involved, however, led us to conclude that this
-   was not a good way to do dynamic update and that a separate DNS
-   Dynamic Update protocol would be necessary.
-
-   The MIB extensions started out being fairly specific to one
-   particular DNS implementation (BIND-4.8.3); as work progressed, the
-   BIND-specific portions were rewritten to be as implementation-neutral
-   as we knew how to make them, but somehow every revision of the MIB
-   extensions managed to create new counters that just happened to
-   closely match statistics kept by some version of BIND.  As a result,
-   the MIB extensions ended up being much too big, which raised a number
-
-
-
-Austein                      Informational                      [Page 1]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-   of concerns with the network management directorate, but the WG
-   resisted every attempt to remove any of these variables.  In the end,
-   large portions of the MIB extensions were moved into optional groups
-   in an attempt to get the required subset down to a manageable size.
-
-   The DNS Server and Resolver MIB extensions were one of the first
-   attempts to write MIB extensions for a protocol usually considered to
-   be at the application layer.  Fairly early on it became clear that,
-   while it was certainly possible to write MIB extensions for DNS, the
-   SMI was not really designed with this sort of thing in mind.  A case
-   in point was the attempt to provide direct indexing into the caches
-   in the resolver MIB extensions: while arguably the only sane way to
-   do this for a large cache, this required much more complex indexing
-   clauses than is usual, and ended up running into known length limits
-   for object identifiers in some SNMP implementations.
-
-   Furthermore, the lack of either real proxy MIB support in SNMP
-   managers or a standard subagent protocol meant that there was no
-   reasonable way to implement the MIB extensions in the dominant
-   implementation (BIND).  When the AgentX subagent protocol was
-   developed a few years later, we initially hoped that this would
-   finally clear the way for an implementation of the DNS MIB
-   extensions, but by the time AgentX was a viable protocol it had
-   become clear that nobody really wanted to implement these MIB
-   extensions.
-
-   Finally, the MIB extensions took much too long to produce.  In
-   retrospect, this should have been a clear warning sign, particularly
-   when the WG had clearly become so tired of the project that the
-   authors found it impossible to elicit any comments whatsoever on the
-   documents.
-
-2. Lessons
-
-   Observations based on the preceding list of mistakes, for the benefit
-   of anyone else who ever attempts to write DNS MIB extensions again:
-
-   -  Define a clear set of goals before writing any MIB extensions.
-      Know who the constituency is and make sure that what you write
-      solves their problem.
-
-   -  Keep the MIB extensions short, and don't add variables just
-      because somebody in the WG thinks they'd be a cool thing to
-      measure.
-
-   -  If some portion of the task seems to be very hard to do within the
-      SMI, that's a strong hint that SNMP is not the right tool for
-      whatever it is that you're trying to do.
-
-
-
-Austein                      Informational                      [Page 2]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-   -  If the entire project is taking too long, perhaps that's a hint
-      too.
-
-3. Recommendation
-
-   In view of the community's apparent total lack of interest in
-   deploying these MIB extensions, we recommend that RFCs 1611 and 1612
-   be reclassified as Historical documents.
-
-4. Security Considerations
-
-   Re-classifying an existing MIB document from Proposed Standard to
-   Historic should not have any negative impact on security for the
-   Internet.
-
-5. IANA Considerations
-
-   Getting rid of the DNS MIB extensions should not impose any new work
-   on IANA.
-
-6. Acknowledgments
-
-   The author would like to thank all the people who were involved in
-   this project over the years for their optimism and patience,
-   misguided though it may have been.
-
-7. References
-
-   [DNS-SERVER-MIB]     Austein, R. and J. Saperia, "DNS Server MIB
-                        Extensions", RFC 1611, May 1994.
-
-   [DNS-RESOLVER-MIB]   Austein, R. and J. Saperia, "DNS Resolver MIB
-                        Extensions", RFC 1612, May 1994.
-
-   [DNS-DYNAMIC-UPDATE] Vixie, P., Thomson, S., Rekhter, Y. and J.
-                        Bound, "Dynamic Updates in the Domain Name
-                        System (DNS UPDATE)", RFC 2136, April 1997.
-
-   [AGENTX]             Daniele, M., Wijnen, B., Ellison, M., and D.
-                        Francisco, "Agent Extensibility (AgentX)
-                        Protocol Version 1", RFC 2741, January 2000.
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 3]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-8. Author's Address
-
-   Rob Austein
-   InterNetShare, Incorporated
-   325M Sharon Park Drive, Suite 308
-   Menlo Park, CA  94025
-   USA
-
-   EMail: sra@hactrn.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 4]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-9. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 5]
-
diff --git a/doc/rfc/rfc3225.txt b/doc/rfc/rfc3225.txt
deleted file mode 100644
index 13e6768c..00000000
--- a/doc/rfc/rfc3225.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          D. Conrad
-Request for Comments: 3225                                 Nominum, Inc.
-Category: Standards Track                                  December 2001
-
-
-                 Indicating Resolver Support of DNSSEC
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   In order to deploy DNSSEC (Domain Name System Security Extensions)
-   operationally, DNSSEC aware servers should only perform automatic
-   inclusion of DNSSEC RRs when there is an explicit indication that the
-   resolver can understand those RRs.  This document proposes the use of
-   a bit in the EDNS0 header to provide that explicit indication and
-   describes the necessary protocol changes to implement that
-   notification.
-
-1. Introduction
-
-   DNSSEC [RFC2535] has been specified to provide data integrity and
-   authentication to security aware resolvers and applications through
-   the use of cryptographic digital signatures.  However, as DNSSEC is
-   deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware
-   servers.  In such situations, the DNSSEC-aware server (responding to
-   a request for data in a signed zone) will respond with SIG, KEY,
-   and/or NXT records.  For reasons described in the subsequent section,
-   such responses can have significant negative operational impacts for
-   the DNS infrastructure.
-
-   This document discusses a method to avoid these negative impacts,
-   namely DNSSEC-aware servers should only respond with SIG, KEY, and/or
-   NXT RRs when there is an explicit indication from the resolver that
-   it can understand those RRs.
-
-   For the purposes of this document, "DNSSEC security RRs" are
-   considered RRs of type SIG, KEY, or NXT.
-
-
-
-Conrad                      Standards Track                     [Page 1]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2. Rationale
-
-   Initially, as DNSSEC is deployed, the vast majority of queries will
-   be from resolvers that are not DNSSEC aware and thus do not
-   understand or support the DNSSEC security RRs.  When a query from
-   such a resolver is received for a DNSSEC signed zone, the DNSSEC
-   specification indicates the nameserver must respond with the
-   appropriate DNSSEC security RRs.  As DNS UDP datagrams are limited to
-   512 bytes [RFC1035], responses including DNSSEC security RRs have a
-   high probability of resulting in a truncated response being returned
-   and the resolver retrying the query using TCP.
-
-   TCP DNS queries result in significant overhead due to connection
-   setup and teardown.  Operationally, the impact of these TCP queries
-   will likely be quite detrimental in terms of increased network
-   traffic (typically five packets for a single query/response instead
-   of two), increased latency resulting from the additional round trip
-   times, increased incidences of queries failing due to timeouts, and
-   significantly increased load on nameservers.
-
-   In addition, in preliminary and experimental deployment of DNSSEC,
-   there have been reports of non-DNSSEC aware resolvers being unable to
-   handle responses which contain DNSSEC security RRs, resulting in the
-   resolver failing (in the worst case) or entire responses being
-   ignored (in the better case).
-
-   Given these operational implications, explicitly notifying the
-   nameserver that the client is prepared to receive (if not understand)
-   DNSSEC security RRs would be prudent.
-
-   Client-side support of DNSSEC is assumed to be binary -- either the
-   client is willing to receive all DNSSEC security RRs or it is not
-   willing to accept any.  As such, a single bit is sufficient to
-   indicate client-side DNSSEC support.  As effective use of DNSSEC
-   implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
-   enhanced DNS header) are scarce, and there may be situations in which
-   non-compliant caching or forwarding servers inappropriately copy data
-   from classic headers as queries are passed on to authoritative
-   servers, the use of a bit from the EDNS0 header is proposed.
-
-   An alternative approach would be to use the existence of an EDNS0
-   header as an implicit indication of client-side support of DNSSEC.
-   This approach was not chosen as there may be applications in which
-   EDNS0 is supported but in which the use of DNSSEC is inappropriate.
-
-
-
-Conrad                      Standards Track                     [Page 2]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-3. Protocol Changes
-
-   The mechanism chosen for the explicit notification of the ability of
-   the client to accept (if not understand) DNSSEC security RRs is using
-   the most significant bit of the Z field on the EDNS0 OPT header in
-   the query.  This bit is referred to as the "DNSSEC OK" (DO) bit.  In
-   the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of
-   the third and fourth bytes of the "extended RCODE and flags" portion
-   of the EDNS0 OPT meta-RR, structured as follows:
-
-                +0 (MSB)                +1 (LSB)
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      0: |   EXTENDED-RCODE      |       VERSION         |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      2: |DO|                    Z                       |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   Setting the DO bit to one in a query indicates to the server that the
-   resolver is able to accept DNSSEC security RRs.  The DO bit cleared
-   (set to zero) indicates the resolver is unprepared to handle DNSSEC
-   security RRs and those RRs MUST NOT be returned in the response
-   (unless DNSSEC security RRs are explicitly queried for).  The DO bit
-   of the query MUST be copied in the response.
-
-   More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
-   or NXT RRs to authenticate a response as specified in [RFC2535]
-   unless the DO bit was set on the request.  Security records that
-   match an explicit SIG, KEY, NXT, or ANY query, or are part of the
-   zone data for an AXFR or IXFR query, are included whether or not the
-   DO bit was set.
-
-   A recursive DNSSEC-aware server MUST set the DO bit on recursive
-   requests, regardless of the status of the DO bit on the initiating
-   resolver request.  If the initiating resolver request does not have
-   the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
-   security RRs before returning the data to the client, however cached
-   data MUST NOT be modified.
-
-   In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
-   to a query that has the DO bit set, the resolver SHOULD NOT expect
-   DNSSEC security RRs and SHOULD retry the query without EDNS0 in
-   accordance with section 5.3 of [RFC2671].
-
-
-
-
-
-
-
-
-
-Conrad                      Standards Track                     [Page 3]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-Security Considerations
-
-   The absence of DNSSEC data in response to a query with the DO bit set
-   MUST NOT be taken to mean no security information is available for
-   that zone as the response may be forged or a non-forged response of
-   an altered (DO bit cleared) query.
-
-IANA Considerations
-
-   EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record,
-   these bits are encoded into the TTL field of the OPT record (RFC2671
-   section 4.6).
-
-   This document reserves one of these bits as the OK bit.  It is
-   requested that the left most bit be allocated.  Thus the USE of the
-   OPT record TTL field would look like
-
-                +0 (MSB)                +1 (LSB)
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      0: |   EXTENDED-RCODE      |       VERSION         |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      2: |DO|                    Z                       |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Acknowledgements
-
-   This document is based on a rough draft by Bob Halley with input from
-   Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush,
-   Rob Austein, Steve Bellovin, and Erik Nordmark.
-
-References
-
-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-             STD 13, RFC 1034, November 1987.
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-             Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-             2535, March 1999.
-
-   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-             2671, August 1999.
-
-
-
-
-
-Conrad                      Standards Track                     [Page 4]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-Author's Address
-
-   David Conrad
-   Nominum Inc.
-   950 Charter Street
-   Redwood City, CA 94063
-   USA
-
-   Phone: +1 650 381 6003
-   EMail: david.conrad@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Conrad                      Standards Track                     [Page 5]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Conrad                      Standards Track                     [Page 6]
-
diff --git a/doc/rfc/rfc3226.txt b/doc/rfc/rfc3226.txt
deleted file mode 100644
index dac0e11c..00000000
--- a/doc/rfc/rfc3226.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     O. Gudmundsson
-Request for Comments: 3226                                 December 2001
-Updates: 2874, 2535
-Category: Standards Track
-
-
-   DNSSEC and IPv6 A6 aware server/resolver message size requirements
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document mandates support for EDNS0 (Extension Mechanisms for
-   DNS) in DNS entities claiming to support either DNS Security
-   Extensions or A6 records.  This requirement is necessary because
-   these new features increase the size of DNS messages.  If EDNS0 is
-   not supported fall back to TCP will happen, having a detrimental
-   impact on query latency and DNS server load.  This document updates
-   RFC 2535 and RFC 2874, by adding new requirements.
-
-1.  Introduction
-
-   Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions
-   [RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful.
-
-   STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP
-   have a data payload of 512 octets or less.  Most DNS software today
-   will not accept larger UDP datagrams.  Any answer that requires more
-   than 512 octets, results in a partial and sometimes useless reply
-   with the Truncation Bit set; in most cases the requester will then
-   retry using TCP.  Furthermore, server delivery of truncated responses
-   varies widely and resolver handling of these responses also varies,
-   leading to additional inefficiencies in handling truncation.
-
-   Compared to UDP, TCP is an expensive protocol to use for a simple
-   transaction like DNS: a TCP connection requires 5 packets for setup
-   and tear down, excluding data packets, thus requiring at least 3
-   round trips on top of the one for the original UDP query.  The DNS
-
-
-
-Gudmundsson                 Standards Track                     [Page 1]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-   server also needs to keep a state of the connection during this
-   transaction.  Many DNS servers answer thousands of queries per
-   second, requiring them to use TCP will cause significant overhead and
-   delays.
-
-1.1.  Requirements
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
-   in this document are to be interpreted as described in RFC 2119.
-
-2.  Motivating factors
-
-2.1.  DNSSEC motivations
-
-   DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each
-   RR set.  These signatures range in size from about 80 octets to 800
-   octets, most are going to be in the range of 80 to 200 octets.  The
-   addition of signatures on each or most RR sets in an answer
-   significantly increases the size of DNS answers from secure zones.
-
-   For performance reasons and to reduce load on DNS servers, it is
-   important that security aware servers and resolvers get all the data
-   in Answer and Authority section in one query without truncation.
-   Sending Additional Data in the same query is helpful when the server
-   is authoritative for the data, and this reduces round trips.
-
-   DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that
-   it is interested in receiving DNSSEC records.  The OK bit does not
-   eliminate the need for large answers for DNSSEC capable clients.
-
-2.1.1.  Message authentication or TSIG motivation
-
-   TSIG [RFC2845] allows for the light weight authentication of DNS
-   messages, but increases the size of the messages by at least 70
-   octets.  DNSSEC specifies for computationally expensive message
-   authentication SIG(0) using a standard public key signature.  As only
-   one TSIG or SIG(0) can be attached to each DNS answer the size
-   increase of message authentication is not significant, but may still
-   lead to a truncation.
-
-2.2.  IPv6 Motivations
-
-   IPv6 addresses [RFC2874] are 128 bits and can be represented in the
-   DNS by multiple A6 records, each consisting of a domain name and a
-   bit field.  The domain name refers to an address prefix that may
-   require additional A6 RRs to be included in the answer.  Answers
-   where the queried name has multiple A6 addresses may overflow a 512-
-   octet UDP packet size.
-
-
-
-Gudmundsson                 Standards Track                     [Page 2]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-2.3.  Root server and TLD server motivations
-
-   The current number of root servers is limited to 13 as that is the
-   maximum number of name servers and their address records that fit in
-   one 512-octet answer for a SOA record.  If root servers start
-   advertising A6 or KEY records then the answer for the root NS records
-   will not fit in a single 512-octet DNS message, resulting in a large
-   number of TCP query connections to the root servers.  Even if all
-   client resolver query their local name server for information, there
-   are millions of these servers.  Each name server must periodically
-   update its information about the high level servers.
-
-   For redundancy, latency and load balancing reasons, large numbers of
-   DNS servers are required for some zones.  Since the root zone is used
-   by the entire net, it is important to have as many servers as
-   possible.  Large TLDs (and many high-visibility SLDs) often have
-   enough servers that either A6 or KEY records would cause the NS
-   response to overflow the 512 byte limit.  Note that these zones with
-   large numbers of servers are often exactly those zones that are
-   critical to network operation and that already sustain fairly high
-   loads.
-
-2.4.  UDP vs TCP for DNS messages
-
-   Given all these factors, it is essential that any implementation that
-   supports DNSSEC and or A6 be able to use larger DNS messages than 512
-   octets.
-
-   The original 512 restriction was put in place to reduce the
-   probability of fragmentation of DNS responses.  A fragmented UDP
-   message that suffers a loss of one of the fragments renders the
-   answer useless and the query must be retried.  A TCP connection
-   requires a larger number of round trips for establishment, data
-   transfer and tear down, but only the lost data segments are
-   retransmitted.
-
-   In the early days a number of IP implementations did not handle
-   fragmentation well, but all modern operating systems have overcome
-   that issue thus sending fragmented messages is fine from that
-   standpoint.  The open issue is the effect of losses on fragmented
-   messages.  If connection has high loss ratio only TCP will allow
-   reliable transfer of DNS data, most links have low loss ratios thus
-   sending fragmented UDP packet in one round trip is better than
-   establishing a TCP connection to transfer a few thousand octets.
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 3]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-2.5.  EDNS0 and large UDP messages
-
-   EDNS0 [RFC2671] allows clients to declare the maximum size of UDP
-   message they are willing to handle.  Thus, if the expected answer is
-   between 512 octets and the maximum size that the client can accept,
-   the additional overhead of a TCP connection can be avoided.
-
-3.  Protocol changes:
-
-   This document updates RFC 2535 and RFC 2874, by adding new
-   requirements.
-
-   All RFC 2535 compliant servers and resolvers MUST support EDNS0 and
-   advertise message size of at least 1220 octets, but SHOULD advertise
-   message size of 4000.  This value might be too low to get full
-   answers for high level servers and successor of this document may
-   require a larger value.
-
-   All RFC 2874 compliant servers and resolver MUST support EDNS0 and
-   advertise message size of at least 1024 octets, but SHOULD advertise
-   message size of 2048.  The IPv6 datagrams should be 1024 octets,
-   unless the MTU of the path is known.  (Note that this is smaller than
-   the minimum IPv6 MTU to allow for some extension headers and/or
-   encapsulation without exceeding the minimum MTU.)
-
-   All RFC 2535 and RFC 2874 compliant entities MUST be able to handle
-   fragmented IPv4 and IPv6 UDP packets.
-
-   All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger
-   required value in EDNS0 advertisements.
-
-4.  Acknowledgments
-
-   Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas
-   Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis
-   Michael Patton and Kazu Yamamoto were instrumental in motivating and
-   shaping this document.
-
-5.  Security Considerations:
-
-   There are no additional security considerations other than those in
-   RFC 2671.
-
-6.  IANA Considerations:
-
-   None
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 4]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-7.  References
-
-   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2535]  Eastlake, D. "Domain Name System Security Extensions", RFC
-              2535, March 1999.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-              2671, August 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
-              IPv6 Address Aggregation and Renumbering", RFC 2874, July
-              2000.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-              3225, December 2001.
-
-8.  Author Address
-
-   Olafur Gudmundsson
-   3826 Legation Street, NW
-   Washington, DC 20015
-   USA
-
-   EMail: ogud@ogud.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 5]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-9.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 6]
-
diff --git a/doc/rfc/rfc3258.txt b/doc/rfc/rfc3258.txt
deleted file mode 100644
index dcd4b34b..00000000
--- a/doc/rfc/rfc3258.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          T. Hardie
-Request for Comments: 3258                                 Nominum, Inc.
-Category: Informational                                       April 2002
-
-
-  Distributing Authoritative Name Servers via Shared Unicast Addresses
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This memo describes a set of practices intended to enable an
-   authoritative name server operator to provide access to a single
-   named server in multiple locations.  The primary motivation for the
-   development and deployment of these practices is to increase the
-   distribution of Domain Name System (DNS) servers to previously
-   under-served areas of the network topology and to reduce the latency
-   for DNS  query responses in those areas.
-
-1.  Introduction
-
-   This memo describes a set of practices intended to enable an
-   authoritative name server operator to provide access to a single
-   named server in multiple locations.  The primary motivation for the
-   development and deployment of these practices is to increase the
-   distribution of DNS servers to previously under-served areas of the
-   network topology and to reduce the latency for DNS query responses in
-   those areas.  This document presumes a one-to-one mapping between
-   named authoritative servers and administrative entities (operators).
-   This document contains no guidelines or recommendations for caching
-   name servers.  The shared unicast system described here is specific
-   to IPv4; applicability to IPv6 is an area for further study.  It
-   should also be noted that the system described here is related to
-   that described in [ANYCAST], but it does not require dedicated
-   address space, routing changes, or the other elements of a full
-   anycast infrastructure which that document describes.
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 1]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-2.  Architecture
-
-2.1 Server Requirements
-
-   Operators of authoritative name servers may wish to refer to
-   [SECONDARY] and [ROOT] for general guidance on appropriate practice
-   for authoritative name servers.  In addition to proper configuration
-   as a standard authoritative name server, each of the hosts
-   participating in a shared-unicast system should be configured with
-   two network interfaces.  These interfaces may be either two physical
-   interfaces or one physical interface mapped to two logical
-   interfaces.  One of the network interfaces should use the IPv4 shared
-   unicast address associated with the authoritative name server.  The
-   other interface, referred to as the administrative interface below,
-   should use a distinct IPv4 address specific to that host.  The host
-   should respond to DNS queries only on the shared-unicast interface.
-   In order to provide the most consistent set of responses from the
-   mesh of anycast hosts, it is good practice to limit responses on that
-   interface to zones for which the host is authoritative.
-
-2.2 Zone file delivery
-
-   In order to minimize the risk of man-in-the-middle attacks, zone
-   files should be delivered to the administrative interface of the
-   servers participating in the mesh.  Secure file transfer methods and
-   strong authentication should be used for all transfers.  If the hosts
-   in the mesh make their zones available for zone transfer, the
-   administrative interfaces should be used for those transfers as well,
-   in order to avoid the problems with potential routing changes for TCP
-   traffic noted in section 2.5 below.
-
-2.3 Synchronization
-
-   Authoritative name servers may be loosely or tightly synchronized,
-   depending on the practices set by the operating organization.  As
-   noted below in section 4.1.2, lack of synchronization among servers
-   using the same shared unicast address could create problems for some
-   users of this service.  In order to minimize that risk, switch-overs
-   from one data set to another data set should be coordinated as much
-   as possible.  The use of synchronized clocks on the participating
-   hosts and set times for switch-overs provides a basic level of
-   coordination.  A more complete coordination process would involve:
-
-      a) receipt of zones at a distribution host
-      b) confirmation of the integrity of zones received
-      c) distribution of the zones to all of the servers in the mesh
-      d) confirmation of the integrity of the zones at each server
-
-
-
-
-Hardie                       Informational                      [Page 2]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-      e) coordination of the switchover times for the servers in the
-         mesh
-      f) institution of a failure process to ensure that servers that
-         did not receive correct data or could not switchover to the new
-         data ceased to respond to incoming queries until the problem
-         could be resolved.
-
-   Depending on the size of the mesh, the distribution host may also be
-   a participant; for authoritative servers, it may also be the host on
-   which zones are generated.
-
-   This document presumes that the usual DNS failover methods are the
-   only ones used to ensure reachability of the data for clients.  It
-   does not advise that the routes be withdrawn in the case of failure;
-   it advises instead that the DNS process shutdown so that servers on
-   other addresses are queried.  This recommendation reflects a choice
-   between performance and operational complexity.  While it would be
-   possible to have some process withdraw the route for a specific
-   server instance when it is not available, there is considerable
-   operational complexity involved in ensuring that this occurs
-   reliably.  Given the existing DNS failover methods, the marginal
-   improvement in performance will not be sufficient to justify the
-   additional complexity for most uses.
-
-2.4 Server Placement
-
-   Though the geographic diversity of server placement helps reduce the
-   effects of service disruptions due to local problems, it is diversity
-   of placement in the network topology which is the driving force
-   behind these distribution practices.  Server placement should
-   emphasize that diversity.  Ideally, servers should be placed
-   topologically near the points at which the operator exchanges routes
-   and traffic with other networks.
-
-2.5 Routing
-
-   The organization administering the mesh of servers sharing a unicast
-   address must have an autonomous system number and speak BGP to its
-   peers.  To those peers, the organization announces a route to the
-   network containing the shared-unicast address of the name server.
-   The organization's border routers must then deliver the traffic
-   destined for the name server to the nearest instantiation.  Routing
-   to the administrative interfaces for the servers can use the normal
-   routing methods for the administering organization.
-
-   One potential problem with using shared unicast addresses is that
-   routers forwarding traffic to them may have more than one available
-   route, and those routes may, in fact, reach different instances of
-
-
-
-Hardie                       Informational                      [Page 3]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-   the shared unicast address.  Applications like the DNS, whose
-   communication typically consists of independent request-response
-   messages each fitting in a single UDP packet present no problem.
-   Other applications, in which multiple packets must reach the same
-   endpoint (e.g., TCP) may fail or present unworkable performance
-   characteristics in some circumstances.  Split-destination failures
-   may occur when a router does per-packet (or round-robin) load
-   sharing, a topology change occurs that changes the relative metrics
-   of two paths to the same anycast destination, etc.
-
-   Four things mitigate the severity of this problem.  The first is that
-   UDP is a fairly high proportion of the query traffic to name servers.
-   The second is that the aim of this proposal is to diversify
-   topological placement; for most users, this means that the
-   coordination of placement will ensure that new instances of a name
-   server will be at a significantly different cost metric from existing
-   instances.  Some set of users may end up in the middle, but that
-   should be relatively rare.  The third is that per packet load sharing
-   is only one of the possible load sharing mechanisms, and other
-   mechanisms are increasing in popularity.
-
-   Lastly, in the case where the traffic is TCP, per packet load sharing
-   is used, and equal cost routes to different instances of a name
-   server are available, any DNS implementation which measures the
-   performance of servers to select a preferred server will quickly
-   prefer a server for which this problem does not occur.  For the DNS
-   failover mechanisms to reliably avoid this problem, however, those
-   using shared unicast distribution mechanisms must take care that all
-   of the servers for a specific zone are not participants in the same
-   shared-unicast mesh.  To guard even against the case where multiple
-   meshes have a set of users affected by per packet load sharing along
-   equal cost routes, organizations implementing these practices should
-   always provide at least one authoritative server which is not a
-   participant in any shared unicast mesh.  Those deploying shared-
-   unicast meshes should note that any specific host may become
-   unreachable to a client should a server fail, a path fail, or the
-   route to that host be withdrawn.  These error conditions are,
-   however, not specific to shared-unicast distributions, but would
-   occur for standard unicast hosts.
-
-   Since ICMP response packets might go to a different member of the
-   mesh than that sending a packet, packets sent with a shared unicast
-   source address should also avoid using path MTU discovery.
-
-   Appendix A. contains an ASCII diagram of an example of a simple
-   implementation of this system.  In it, the odd numbered routers
-   deliver traffic to the shared-unicast interface network and filter
-   traffic from the administrative network; the even numbered routers
-
-
-
-Hardie                       Informational                      [Page 4]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-   deliver traffic to the administrative network and filter traffic from
-   the shared-unicast network.  These are depicted as separate routers
-   for the ease this gives in explanation, but they could easily be
-   separate interfaces on the same router.  Similarly, a local NTP
-   source is depicted for synchronization, but the level of
-   synchronization needed would not require that source to be either
-   local or a stratum one NTP server.
-
-3. Administration
-
-3.1 Points of Contact
-
-   A single point of contact for reporting problems is crucial to the
-   correct administration of this system.  If an external user of the
-   system needs to report a problem related to the service, there must
-   be no ambiguity about whom to contact.  If internal monitoring does
-   not indicate a problem, the contact may, of course, need to work with
-   the external user to identify which server generated the error.
-
-4. Security Considerations
-
-   As a core piece of Internet infrastructure, authoritative name
-   servers are common targets of attack.  The practices outlined here
-   increase the risk of certain kinds of attacks and reduce the risk of
-   others.
-
-4.1 Increased Risks
-
-4.1.1 Increase in physical servers
-
-   The architecture outlined in this document increases the number of
-   physical servers, which could increase the possibility that a server
-   mis-configuration will occur which allows for a security breach.  In
-   general, the entity administering a mesh should ensure that patches
-   and security mechanisms applied to a single member of the mesh are
-   appropriate for and applied to all of the members of a mesh.
-   "Genetic diversity" (code from different code bases) can be a useful
-   security measure in avoiding attacks based on vulnerabilities in a
-   specific code base; in order to ensure consistency of responses from
-   a single named server, however, that diversity should be applied to
-   different shared-unicast meshes or between a mesh and a related
-   unicast authoritative server.
-
-4.1.2 Data synchronization problems
-
-   The level of systemic synchronization described above should be
-   augmented by synchronization of the data present at each of the
-   servers.  While the DNS itself is a loosely coupled system, debugging
-
-
-
-Hardie                       Informational                      [Page 5]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-   problems with data in specific zones would be far more difficult if
-   two different servers sharing a single unicast address might return
-   different responses to the same query.  For example, if the data
-   associated with www.example.com has changed and the administrators of
-   the domain are testing for the changes at the example.com
-   authoritative name servers, they should not need to check each
-   instance of a named authoritative server.  The use of NTP to provide
-   a synchronized time for switch-over eliminates some aspects of this
-   problem, but mechanisms to handle failure during the switchover are
-   required.  In particular, a server which cannot make the switchover
-   must not roll-back to a previous version; it must cease to respond to
-   queries so that other servers are queried.
-
-4.1.3 Distribution risks
-
-   If the mechanism used to distribute zone files among the servers is
-   not well secured, a man-in-the-middle attack could result in the
-   injection of false information.  Digital signatures will alleviate
-   this risk, but encrypted transport and tight access lists are a
-   necessary adjunct to them.  Since zone files will be distributed to
-   the administrative interfaces of meshed servers, the access control
-   list for distribution of the zone files should include the
-   administrative interface of the server or servers, rather than their
-   shared unicast addresses.
-
-4.2 Decreased Risks
-
-   The increase in number of physical servers reduces the likelihood
-   that a denial-of-service attack will take out a significant portion
-   of the DNS infrastructure.  The increase in servers also reduces the
-   effect of machine crashes, fiber cuts, and localized disasters by
-   reducing the number of users dependent on a specific machine.
-
-5. Acknowledgments
-
-   Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
-   Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato,
-   Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg all
-   provided input and commentary on this work.  The editor wishes to
-   remember in particular the contribution of the late Scott Tucker,
-   whose extensive systems experience and plain common sense both
-   contributed greatly to the editor's own deployment experience and are
-   missed by all who knew him.
-
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 6]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-6. References
-
-   [SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
-               and Operation of Secondary DNS Servers", BCP 16, RFC
-               2182, July 1997.
-
-   [ROOT]      Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
-               Name Server Operational Requirements", BCP 40, RFC 2870,
-               June 2000.
-
-   [ANYCAST]   Patridge, C., Mendez, T. and W. Milliken, "Host
-               Anycasting Service", RFC 1546, November 1993.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 7]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-Appendix A.
-
-       __________________
-Peer 1-|                |
-Peer 2-|                |
-Peer 3-|     Switch     |
-Transit|                |  _________                   _________
-etc    |                |--|Router1|---|----|----------|Router2|---WAN-|
-       |                |  ---------   |    |          ---------       |
-       |                |              |    |                          |
-       |                |              |    |                          |
-       ------------------            [NTP] [DNS]                       |
-                                                                       |
-                                                                       |
-                                                                       |
-                                                                       |
-       __________________                                              |
-Peer 1-|                |                                              |
-Peer 2-|                |                                              |
-Peer 3-|     Switch     |                                              |
-Transit|                |  _________                   _________       |
-etc    |                |--|Router3|---|----|----------|Router4|---WAN-|
-       |                |  ---------   |    |          ---------       |
-       |                |              |    |                          |
-       |                |              |    |                          |
-       ------------------            [NTP] [DNS]                       |
-                                                                       |
-                                                                       |
-                                                                       |
-                                                                       |
-       __________________                                              |
-Peer 1-|                |                                              |
-Peer 2-|                |                                              |
-Peer 3-|     Switch     |                                              |
-Transit|                |  _________                   _________       |
-etc    |                |--|Router5|---|----|----------|Router6|---WAN-|
-       |                |  ---------   |    |          ---------       |
-       |                |              |    |                          |
-       |                |              |    |                          |
-       ------------------            [NTP] [DNS]                       |
-                                                                       |
-                                                                       |
-                                                                       |
-
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 8]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-                                                                       |
-       __________________                                              |
-Peer 1-|                |                                              |
-Peer 2-|                |                                              |
-Peer 3-|     Switch     |                                              |
-Transit|                |  _________                   _________       |
-etc    |                |--|Router7|---|----|----------|Router8|---WAN-|
-       |                |  ---------   |    |          ---------
-       |                |              |    |
-       |                |              |    |
-       ------------------            [NTP] [DNS]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 9]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-7. Editor's Address
-
-   Ted Hardie
-   Nominum, Inc.
-   2385 Bay Road.
-   Redwood City, CA 94063
-
-   Phone: 1.650.381.6226
-   EMail: Ted.Hardie@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie                       Informational                     [Page 10]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-8.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie                       Informational                     [Page 11]
-
diff --git a/doc/rfc/rfc3363.txt b/doc/rfc/rfc3363.txt
deleted file mode 100644
index 9d7a39c2..00000000
--- a/doc/rfc/rfc3363.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            R. Bush
-Request for Comments: 3363                                     A. Durand
-Updates: 2673, 2874                                              B. Fink
-Category: Informational                                   O. Gudmundsson
-                                                                 T. Hain
-                                                                 Editors
-                                                             August 2002
-
-
-            Representing Internet Protocol version 6 (IPv6)
-               Addresses in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This document clarifies and updates the standards status of RFCs that
-   define direct and reverse map of IPv6 addresses in DNS.  This
-   document moves the A6 and Bit label specifications to experimental
-   status.
-
-1.  Introduction
-
-   The IETF had begun the process of standardizing two different address
-   formats for IPv6 addresses AAAA [RFC1886] and A6 [RFC2874] and both
-   are at proposed standard.  This had led to confusion and conflicts on
-   which one to deploy.  It is important for deployment that any
-   confusion in this area be cleared up, as there is a feeling in the
-   community that having more than one choice will lead to delays in the
-   deployment of IPv6.  The goal of this document is to clarify the
-   situation.
-
-   This document also discusses issues relating to the usage of Binary
-   Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.
-
-   This document is based on extensive technical discussion on various
-   relevant working groups mailing lists and a joint DNSEXT and NGTRANS
-   meeting at the 51st IETF in August 2001.  This document attempts to
-   capture the sense of the discussions and reflect them in this
-   document to represent the consensus of the community.
-
-
-
-Bush, et. al.                Informational                      [Page 1]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-   The main arguments and the issues are covered in a separate document
-   [RFC3364] that reflects the current understanding of the issues.
-   This document summarizes the outcome of these discussions.
-
-   The issue of the root of reverse IPv6 address map is outside the
-   scope of this document and is covered in a different document
-   [RFC3152].
-
-1.1 Standards Action Taken
-
-   This document changes the status of RFCs 2673 and 2874 from Proposed
-   Standard to Experimental.
-
-2.  IPv6 Addresses: AAAA RR vs A6 RR
-
-   Working group consensus as perceived by the chairs of the DNSEXT and
-   NGTRANS working groups is that:
-
-   a) AAAA records are preferable at the moment for production
-      deployment of IPv6, and
-
-   b) that A6 records have interesting properties that need to be better
-      understood before deployment.
-
-   c) It is not known if the benefits of A6 outweigh the costs and
-      risks.
-
-2.1 Rationale
-
-   There are several potential issues with A6 RRs that stem directly
-   from the feature that makes them different from AAAA RRs: the ability
-   to build up addresses via chaining.
-
-   Resolving a chain of A6 RRs involves resolving a series of what are
-   nearly-independent queries.  Each of these sub-queries takes some
-   non-zero amount of time, unless the answer happens to be in the
-   resolver's local cache already.  Other things being equal, we expect
-   that the time it takes to resolve an N-link chain of A6 RRs will be
-   roughly proportional to N.  What data we have suggests that users are
-   already impatient with the length of time it takes to resolve A RRs
-   in the IPv4 Internet, which suggests that users are not likely to be
-   patient with significantly longer delays in the IPv6 Internet, but
-   terminating queries prematurely is both a waste of resources and
-   another source of user frustration.  Thus, we are forced to conclude
-   that indiscriminate use of long A6 chains is likely to lead to
-   increased user frustration.
-
-
-
-
-
-Bush, et. al.                Informational                      [Page 2]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-   The probability of failure during the process of resolving an N-link
-   A6 chain also appears to be roughly proportional to N, since each of
-   the queries involved in resolving an A6 chain has roughly the same
-   probability of failure as a single AAAA query.
-
-   Last, several of the most interesting potential applications for A6
-   RRs involve situations where the prefix name field in the A6 RR
-   points to a target that is not only outside the DNS zone containing
-   the A6 RR, but is administered by a different organization entirely.
-   While pointers out of zone are not a problem per se, experience both
-   with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that
-   pointers to other organizations are often not maintained properly,
-   perhaps because they're less susceptible to automation than pointers
-   within a single organization would be.
-
-2.2 Recommended Standard Action
-
-   Based on the perceived consensus, this document recommends that RFC
-   1886 stay on standards track and be advanced, while moving RFC 2874
-   to Experimental status.
-
-3.  Bitlabels in the Reverse DNS Tree
-
-   RFC 2673 defines a new DNS label type.  This was the first new type
-   defined since RFC 1035 [RFC1035].  Since the development of 2673 it
-   has been learned that deployment of a new type is difficult since DNS
-   servers that do not support bitlabels reject queries containing bit
-   labels as being malformed.  The community has also indicated that
-   this new label type is not needed for mapping reverse addresses.
-
-3.1 Rationale
-
-   The hexadecimal text representation of IPv6 addresses appears to be
-   capable of expressing all of the delegation schemes that we expect to
-   be used in the DNS reverse tree.
-
-3.2 Recommended Standard Action
-
-   RFC 2673 standard status is to be changed from Proposed to
-   Experimental.  Future standardization of these documents is to be
-   done by the DNSEXT working group or its successor.
-
-
-
-
-
-
-
-
-
-
-Bush, et. al.                Informational                      [Page 3]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-4.  DNAME in IPv6 Reverse Tree
-
-   The issues for DNAME in the reverse mapping tree appears to be
-   closely tied to the need to use fragmented A6 in the main tree: if
-   one is necessary, so is the other, and if one isn't necessary, the
-   other isn't either.  Therefore, in moving RFC 2874 to experimental,
-   the intent of this document is that use of DNAME RRs in the reverse
-   tree be deprecated.
-
-5.  Acknowledgments
-
-   This document is based on input from many members of the various IETF
-   working groups involved in this issues.  Special thanks go to the
-   people that prepared reading material for the joint DNSEXT and
-   NGTRANS working group meeting at the 51st IETF in London, Rob
-   Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino,
-   Christian Huitema.  Number of other people have made number of
-   comments on mailing lists about this issue including Andrew W.
-   Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka
-   Savola, Paul Vixie.
-
-6.  Security Considerations
-
-   As this document specifies a course of action, there are no direct
-   security considerations.  There is an indirect security impact of the
-   choice, in that the relationship between A6 and DNSSEC is not well
-   understood throughout the community, while the choice of AAAA does
-   leads to a model for use of DNSSEC in IPv6 networks which parallels
-   current IPv4 practice.
-
-7.  IANA Considerations
-
-   None.
-
-Normative References
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1886]  Thompson, S. and C. Huitema, "DNS Extensions to support IP
-              version 6", RFC 1886, December 1995.
-
-   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
-              RFC 2673, August 1999.
-
-   [RFC2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
-              IPv6 Address Aggregation and Renumbering", RFC 2874, July
-              2000.
-
-
-
-Bush, et. al.                Informational                      [Page 4]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152
-              August 2001.
-
-Informative References
-
-   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
-              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
-              August 2002.
-
-Editors' Addresses
-
-   Randy Bush
-   EMail: randy@psg.com
-
-
-   Alain Durand
-   EMail: alain.durand@sun.com
-
-
-   Bob Fink
-   EMail: fink@es.net
-
-
-   Olafur Gudmundsson
-   EMail: ogud@ogud.com
-
-
-   Tony Hain
-   EMail: hain@tndh.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush, et. al.                Informational                      [Page 5]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush, et. al.                Informational                      [Page 6]
-
diff --git a/doc/rfc/rfc3364.txt b/doc/rfc/rfc3364.txt
deleted file mode 100644
index 189c0d2a..00000000
--- a/doc/rfc/rfc3364.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 3364                           Bourgeois Dilettant
-Updates: 2673, 2874                                          August 2002
-Category: Informational
-
-
-             Tradeoffs in Domain Name System (DNS) Support
-                 for Internet Protocol version 6 (IPv6)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   The IETF has two different proposals on the table for how to do DNS
-   support for IPv6, and has thus far failed to reach a clear consensus
-   on which approach is better.  This note attempts to examine the pros
-   and cons of each approach, in the hope of clarifying the debate so
-   that we can reach closure and move on.
-
-Introduction
-
-   RFC 1886 [RFC1886] specified straightforward mechanisms to support
-   IPv6 addresses in the DNS.  These mechanisms closely resemble the
-   mechanisms used to support IPv4, with a minor improvement to the
-   reverse mapping mechanism based on experience with CIDR.  RFC 1886 is
-   currently listed as a Proposed Standard.
-
-   RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6
-   addresses in the DNS.  These mechanisms provide new features that
-   make it possible for an IPv6 address stored in the DNS to be broken
-   up into multiple DNS resource records in ways that can reflect the
-   network topology underlying the address, thus making it possible for
-   the data stored in the DNS to reflect certain kinds of network
-   topology changes or routing architectures that are either impossible
-   or more difficult to represent without these mechanisms.  RFC 2874 is
-   also currently listed as a Proposed Standard.
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 1]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   Both of these Proposed Standards were the output of the IPNG Working
-   Group.  Both have been implemented, although implementation of
-   [RFC1886] is more widespread, both because it was specified earlier
-   and because it's simpler to implement.
-
-   There's little question that the mechanisms proposed in [RFC2874] are
-   more general than the mechanisms proposed in [RFC1886], and that
-   these enhanced mechanisms might be valuable if IPv6's evolution goes
-   in certain directions.  The questions are whether we really need the
-   more general mechanism, what new usage problems might come along with
-   the enhanced mechanisms, and what effect all this will have on IPv6
-   deployment.
-
-   The one thing on which there does seem to be widespread agreement is
-   that we should make up our minds about all this Real Soon Now.
-
-Main Advantages of Going with A6
-
-   While the A6 RR proposed in [RFC2874] is very general and provides a
-   superset of the functionality provided by the AAAA RR in [RFC1886],
-   many of the features of A6 can also be implemented with AAAA RRs via
-   preprocessing during zone file generation.
-
-   There is one specific area where A6 RRs provide something that cannot
-   be provided using AAAA RRs: A6 RRs can represent addresses in which a
-   prefix portion of the address can change without any action (or
-   perhaps even knowledge) by the parties controlling the DNS zone
-   containing the terminal portion (least significant bits) of the
-   address.  This includes both so-called "rapid renumbering" scenarios
-   (where an entire network's prefix may change very quickly) and
-   routing architectures such as the former "GSE" proposal [GSE] (where
-   the "routing goop" portion of an address may be subject to change
-   without warning).  A6 RRs do not completely remove the need to update
-   leaf zones during all renumbering events (for example, changing ISPs
-   would usually require a change to the upward delegation pointer), but
-   careful use of A6 RRs could keep the number of RRs that need to
-   change during such an event to a minimum.
-
-   Note that constructing AAAA RRs via preprocessing during zone file
-   generation requires exactly the sort of information that A6 RRs store
-   in the DNS.  This begs the question of where the hypothetical
-   preprocessor obtains that information if it's not getting it from the
-   DNS.
-
-   Note also that the A6 RR, when restricted to its zero-length-prefix
-   form ("A6 0"), is semantically equivalent to an AAAA RR (with one
-   "wasted" octet in the wire representation), so anything that can be
-   done with an AAAA RR can also be done with an A6 RR.
-
-
-
-Austein                      Informational                      [Page 2]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Main Advantages of Going with AAAA
-
-   The AAAA RR proposed in [RFC1886], while providing only a subset of
-   the functionality provided by the A6 RR proposed in [RFC2874], has
-   two main points to recommend it:
-
-   - AAAA RRs are essentially identical (other than their length) to
-     IPv4's A RRs, so we have more than 15 years of experience to help
-     us predict the usage patterns, failure scenarios and so forth
-     associated with AAAA RRs.
-
-   - The AAAA RR is "optimized for read", in the sense that, by storing
-     a complete address rather than making the resolver fetch the
-     address in pieces, it minimizes the effort involved in fetching
-     addresses from the DNS (at the expense of increasing the effort
-     involved in injecting new data into the DNS).
-
-Less Compelling Arguments in Favor of A6
-
-   Since the A6 RR allows a zone administrator to write zone files whose
-   description of addresses maps to the underlying network topology, A6
-   RRs can be construed as a "better" way of representing addresses than
-   AAAA.  This may well be a useful capability, but in and of itself
-   it's more of an argument for better tools for zone administrators to
-   use when constructing zone files than a justification for changing
-   the resolution protocol used on the wire.
-
-Less Compelling Arguments in Favor of AAAA
-
-   Some of the pressure to go with AAAA instead of A6 appears to be
-   based on the wider deployment of AAAA.  Since it is possible to
-   construct transition tools (see discussion of AAAA synthesis, later
-   in this note), this does not appear to be a compelling argument if A6
-   provides features that we really need.
-
-   Another argument in favor of AAAA RRs over A6 RRs appears to be that
-   the A6 RR's advanced capabilities increase the number of ways in
-   which a zone administrator could build a non-working configuration.
-   While operational issues are certainly important, this is more of
-   argument that we need better tools for zone administrators than it is
-   a justification for turning away from A6 if A6 provides features that
-   we really need.
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 3]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Potential Problems with A6
-
-   The enhanced capabilities of the A6 RR, while interesting, are not in
-   themselves justification for choosing A6 if we don't really need
-   those capabilities.  The A6 RR is "optimized for write", in the sense
-   that, by making it possible to store fragmented IPv6 addresses in the
-   DNS, it makes it possible to reduce the effort that it takes to
-   inject new data into the DNS (at the expense of increasing the effort
-   involved in fetching data from the DNS).  This may be justified if we
-   expect the effort involved in maintaining AAAA-style DNS entries to
-   be prohibitive, but in general, we expect the DNS data to be read
-   more frequently than it is written, so we need to evaluate this
-   particular tradeoff very carefully.
-
-   There are also several potential issues with A6 RRs that stem
-   directly from the feature that makes them different from AAAA RRs:
-   the ability to build up address via chaining.
-
-   Resolving a chain of A6 RRs involves resolving a series of what are
-   almost independent queries, but not quite.  Each of these sub-queries
-   takes some non-zero amount of time, unless the answer happens to be
-   in the resolver's local cache already.  Assuming that resolving an
-   AAAA RR takes time T as a baseline, we can guess that, on the
-   average, it will take something approaching time N*T to resolve an
-   N-link chain of A6 RRs, although we would expect to see a fairly good
-   caching factor for the A6 fragments representing the more significant
-   bits of an address.  This leaves us with two choices, neither of
-   which is very good:  we can decrease the amount of time that the
-   resolver is willing to wait for each fragment, or we can increase the
-   amount of time that a resolver is willing to wait before returning
-   failure to a client.  What little data we have on this subject
-   suggests that users are already impatient with the length of time it
-   takes to resolve A RRs in the IPv4 Internet, which suggests that they
-   are not likely to be patient with significantly longer delays in the
-   IPv6 Internet.  At the same time, terminating queries prematurely is
-   both a waste of resources and another source of user frustration.
-   Thus, we are forced to conclude that indiscriminate use of long A6
-   chains is likely to lead to problems.
-
-   To make matters worse, the places where A6 RRs are likely to be most
-   critical for rapid renumbering or GSE-like routing are situations
-   where the prefix name field in the A6 RR points to a target that is
-   not only outside the DNS zone containing the A6 RR, but is
-   administered by a different organization (for example, in the case of
-   an end user's site, the prefix name will most likely point to a name
-   belonging to an ISP that provides connectivity for the site).  While
-   pointers out of zone are not a problem per se, pointers to other
-   organizations are somewhat more difficult to maintain and less
-
-
-
-Austein                      Informational                      [Page 4]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   susceptible to automation than pointers within a single organization
-   would be.  Experience both with glue RRs and with PTR RRs in the IN-
-   ADDR.ARPA tree suggests that many zone administrators do not really
-   understand how to set up and maintain these pointers properly, and we
-   have no particular reason to believe that these zone administrators
-   will do a better job with A6 chains than they do today.  To be fair,
-   however, the alternative case of building AAAA RRs via preprocessing
-   before loading zones has many of the same problems; at best, one can
-   claim that using AAAA RRs for this purpose would allow DNS clients to
-   get the wrong answer somewhat more efficiently than with A6 RRs.
-
-   Finally, assuming near total ignorance of how likely a query is to
-   fail, the probability of failure with an N-link A6 chain would appear
-   to be roughly proportional to N, since each of the queries involved
-   in resolving an A6 chain would have the same probability of failure
-   as a single AAAA query.  Note again that this comment applies to
-   failures in the the process of resolving a query, not to the data
-   obtained via that process.  Arguably, in an ideal world, A6 RRs would
-   increase the probability of the answer a client (finally) gets being
-   right, assuming that nothing goes wrong in the query process, but we
-   have no real idea how to quantify that assumption at this point even
-   to the hand-wavey extent used elsewhere in this note.
-
-   One potential problem that has been raised in the past regarding A6
-   RRs turns out not to be a serious issue.  The A6 design includes the
-   possibility of there being more than one A6 RR matching the prefix
-   name portion of a leaf A6 RR.  That is, an A6 chain may not be a
-   simple linked list, it may in fact be a tree, where each branch
-   represents a possible prefix.  Some critics of A6 have been concerned
-   that this will lead to a wild expansion of queries, but this turns
-   out not to be a problem if a resolver simply follows the "bounded
-   work per query" rule described in RFC 1034 (page 35).  That rule
-   applies to all work resulting from attempts to process a query,
-   regardless of whether it's a simple query, a CNAME chain, an A6 tree,
-   or an infinite loop.  The client may not get back a useful answer in
-   cases where the zone has been configured badly, but a proper
-   implementation should not produce a query explosion as a result of
-   processing even the most perverse A6 tree, chain, or loop.
-
-Interactions with DNSSEC
-
-   One of the areas where AAAA and A6 RRs differ is in the precise
-   details of how they interact with DNSSEC.  The following comments
-   apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are
-   semantically equivalent to AAAA RRs).
-
-
-
-
-
-
-Austein                      Informational                      [Page 5]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   Other things being equal, the time it takes to re-sign all of the
-   addresses in a zone after a renumbering event is longer with AAAA RRs
-   than with A6 RRs (because each address record has to be re-signed
-   rather than just signing a common prefix A6 RR and a few A6 0 RRs
-   associated with the zone's name servers).  Note, however, that in
-   general this does not present a serious scaling problem, because the
-   re-signing is performed in the leaf zones.
-
-   Other things being equal, there's more work involved in verifying the
-   signatures received back for A6 RRs, because each address fragment
-   has a separate associated signature.  Similarly, a DNS message
-   containing a set of A6 address fragments and their associated
-   signatures will be larger than the equivalent packet with a single
-   AAAA (or A6 0) and a single associated signature.
-
-   Since AAAA RRs cannot really represent rapid renumbering or GSE-style
-   routing scenarios very well, it should not be surprising that DNSSEC
-   signatures of AAAA RRs are also somewhat problematic.  In cases where
-   the AAAA RRs would have to be changing very quickly to keep up with
-   prefix changes, the time required to re-sign the AAAA RRs may be
-   prohibitive.
-
-   Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that
-   333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the
-   BIND-9 dnssec-signzone program under NetBSD can generate roughly 40
-   1024-bit RSA signatures per second.  Extrapolating from this,
-   assuming one A RR, one AAAA RR, and one NXT RR per host, this
-   suggests that it would take this laptop a few hours to sign a zone
-   listing 10**5 hosts, or about a day to sign a zone listing 10**6
-   hosts using AAAA RRs.
-
-   This suggests that the additional effort of re-signing a large zone
-   full of AAAA RRs during a re-numbering event, while noticeable, is
-   only likely to be prohibitive in the rapid renumbering case where
-   AAAA RRs don't work well anyway.
-
-Interactions with Dynamic Update
-
-   DNS dynamic update appears to work equally well for AAAA or A6 RRs,
-   with one minor exception: with A6 RRs, the dynamic update client
-   needs to know the prefix length and prefix name.  At present, no
-   mechanism exists to inform a dynamic update client of these values,
-   but presumably such a mechanism could be provided via an extension to
-   DHCP, or some other equivalent could be devised.
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 6]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Transition from AAAA to A6 Via AAAA Synthesis
-
-   While AAAA is at present more widely deployed than A6, it is possible
-   to transition from AAAA-aware DNS software to A6-aware DNS software.
-   A rough plan for this was presented at IETF-50 in Minneapolis and has
-   been discussed on the ipng mailing list.  So if the IETF concludes
-   that A6's enhanced capabilities are necessary, it should be possible
-   to transition from AAAA to A6.
-
-   The details of this transition have been left to a separate document,
-   but the general idea is that the resolver that is performing
-   iterative resolution on behalf of a DNS client program could
-   synthesize AAAA RRs representing the result of performing the
-   equivalent A6 queries.  Note that in this case it is not possible to
-   generate an equivalent DNSSEC signature for the AAAA RR, so clients
-   that care about performing DNSSEC validation for themselves would
-   have to issue A6 queries directly rather than relying on AAAA
-   synthesis.
-
-Bitlabels
-
-   While the differences between AAAA and A6 RRs have generated most of
-   the discussion to date, there are also two proposed mechanisms for
-   building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-
-   ADDR.ARPA tree).
-
-   [RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA
-   mechanism used for IPv4 addresses: the RR name is the hexadecimal
-   representation of the IPv6 address, reversed and concatenated with a
-   well-known suffix, broken up with a dot between each hexadecimal
-   digit.  The resulting DNS names are somewhat tedious for humans to
-   type, but are very easy for programs to generate.  Making each
-   hexadecimal digit a separate label means that delegation on arbitrary
-   bit boundaries will result in a maximum of 16 NS RRsets per label
-   level; again, the mechanism is somewhat tedious for humans, but is
-   very easy to program.  As with IPv4's IN-ADDR.ARPA tree, the one
-   place where this scheme is weak is in handling delegations in the
-   least significant label; however, since there appears to be no real
-   need to delegate the least significant four bits of an IPv6 address,
-   this does not appear to be a serious restriction.
-
-   [RFC2874] proposed a radically different way of naming entries in the
-   reverse mapping tree: rather than using textual representations of
-   addresses, it proposes to use a new kind of DNS label (a "bit label")
-   to represent binary addresses directly in the DNS.  This has the
-   advantage of being significantly more compact than the textual
-   representation, and arguably might have been a better solution for
-   DNS to use for this purpose if it had been designed into the protocol
-
-
-
-Austein                      Informational                      [Page 7]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   from the outset.  Unfortunately, experience to date suggests that
-   deploying a new DNS label type is very hard: all of the DNS name
-   servers that are authoritative for any portion of the name in
-   question must be upgraded before the new label type can be used, as
-   must any resolvers involved in the resolution process.  Any name
-   server that has not been upgraded to understand the new label type
-   will reject the query as being malformed.
-
-   Since the main benefit of the bit label approach appears to be an
-   ability that we don't really need (delegation in the least
-   significant four bits of an IPv6 address), and since the upgrade
-   problem is likely to render bit labels unusable until a significant
-   portion of the DNS code base has been upgraded, it is difficult to
-   escape the conclusion that the textual solution is good enough.
-
-DNAME RRs
-
-   [RFC2874] also proposes using DNAME RRs as a way of providing the
-   equivalent of A6's fragmented addresses in the reverse mapping tree.
-   That is, by using DNAME RRs, one can write zone files for the reverse
-   mapping tree that have the same ability to cope with rapid
-   renumbering or GSE-style routing that the A6 RR offers in the main
-   portion of the DNS tree.  Consequently, the need to use DNAME in the
-   reverse mapping tree appears to be closely tied to the need to use
-   fragmented A6 in the main tree: if one is necessary, so is the other,
-   and if one isn't necessary, the other isn't either.
-
-   Other uses have also been proposed for the DNAME RR, but since they
-   are outside the scope of the IPv6 address discussion, they will not
-   be addressed here.
-
-Recommendation
-
-   Distilling the above feature comparisons down to their key elements,
-   the important questions appear to be:
-
-   (a) Is IPv6 going to do rapid renumbering or GSE-like routing?
-
-   (b) Is the reverse mapping tree for IPv6 going to require delegation
-       in the least significant four bits of the address?
-
-   Question (a) appears to be the key to the debate.  This is really a
-   decision for the IPv6 community to make, not the DNS community.
-
-   Question (b) is also for the IPv6 community to make, but it seems
-   fairly obvious that the answer is "no".
-
-
-
-
-
-Austein                      Informational                      [Page 8]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   Recommendations based on these questions:
-
-   (1) If the IPv6 working groups seriously intend to specify and deploy
-       rapid renumbering or GSE-like routing, we should transition to
-       using the A6 RR in the main tree and to using DNAME RRs as
-       necessary in the reverse tree.
-
-   (2) Otherwise, we should keep the simpler AAAA solution in the main
-       tree and should not use DNAME RRs in the reverse tree.
-
-   (3) In either case, the reverse tree should use the textual
-       representation described in [RFC1886] rather than the bit label
-       representation described in [RFC2874].
-
-   (4) If we do go to using A6 RRs in the main tree and to using DNAME
-       RRs in the reverse tree, we should write applicability statements
-       and implementation guidelines designed to discourage excessively
-       complex uses of these features; in general, any network that can
-       be described adequately using A6 0 RRs and without using DNAME
-       RRs should be described that way, and the enhanced features
-       should be used only when absolutely necessary, at least until we
-       have much more experience with them and have a better
-       understanding of their failure modes.
-
-Security Considerations
-
-   This note compares two mechanisms with similar security
-   characteristics, but there are a few security implications to the
-   choice between these two mechanisms:
-
-   (1) The two mechanisms have similar but not identical interactions
-       with DNSSEC.  Please see the section entitled "Interactions with
-       DNSSEC" (above) for a discussion of these issues.
-
-   (2) To the extent that operational complexity is the enemy of
-       security, the tradeoffs in operational complexity discussed
-       throughout this note have an impact on security.
-
-   (3) To the extent that protocol complexity is the enemy of security,
-       the additional protocol complexity of [RFC2874] as compared to
-       [RFC1886] has some impact on security.
-
-IANA Considerations
-
-   None, since all of these RR types have already been allocated.
-
-
-
-
-
-
-Austein                      Informational                      [Page 9]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Acknowledgments
-
-   This note is based on a number of discussions both public and private
-   over a period of (at least) eight years, but particular thanks go to
-   Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
-   Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush,
-   and Sue Thomson, none of whom are responsible for what the author did
-   with their ideas.
-
-References
-
-   [RFC1886]    Thomson, S. and C. Huitema, "DNS Extensions to support
-                IP version 6", RFC 1886, December 1995.
-
-   [RFC2874]    Crawford, M. and C. Huitema, "DNS Extensions to Support
-                IPv6 Address Aggregation and Renumbering", RFC 2874,
-                July 2000.
-
-   [Sommerfeld] Private message to the author from Bill Sommerfeld dated
-                21 March 2001, summarizing the result of experiments he
-                performed on a copy of the MIT.EDU zone.
-
-   [GSE]       "GSE" was an evolution of the so-called "8+8" proposal
-                discussed by the IPng working group in 1996 and 1997.
-                The GSE proposal itself was written up as an Internet-
-                Draft, which has long since expired.  Readers interested
-                in the details and history of GSE should review the IPng
-                working group's mailing list archives and minutes from
-                that period.
-
-Author's Address
-
-   Rob Austein
-
-   EMail: sra@hactrn.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                     [Page 10]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                     [Page 11]
-
diff --git a/doc/rfc/rfc3425.txt b/doc/rfc/rfc3425.txt
deleted file mode 100644
index 707cafd1..00000000
--- a/doc/rfc/rfc3425.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Lawrence
-Request for Comments: 3425                                       Nominum
-Updates: 1035                                              November 2002
-Category: Standards Track
-
-
-                           Obsoleting IQUERY
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   The IQUERY method of performing inverse DNS lookups, specified in RFC
-   1035, has not been generally implemented and has usually been
-   operationally disabled where it has been implemented.  Both reflect a
-   general view in the community that the concept was unwise and that
-   the widely-used alternate approach of using pointer (PTR) queries and
-   reverse-mapping records is preferable.  Consequently, this document
-   deprecates the IQUERY operation, declaring it entirely obsolete.
-   This document updates RFC 1035.
-
-1 - Introduction
-
-   As specified in RFC 1035 (section 6.4), the IQUERY operation for DNS
-   queries is used to look up the name(s) which are associated with the
-   given value.  The value being sought is provided in the query's
-   answer section and the response fills in the question section with
-   one or more 3-tuples of type, name and class.
-
-   As noted in [RFC1035], section 6.4.3, inverse query processing can
-   put quite an arduous burden on a server.  A server would need to
-   perform either an exhaustive search of its database or maintain a
-   separate database that is keyed by the values of the primary
-   database.  Both of these approaches could strain system resource use,
-   particularly for servers that are authoritative for millions of
-   names.
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 1]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-   Response packets from these megaservers could be exceptionally large,
-   and easily run into megabyte sizes.  For example, using IQUERY to
-   find every domain that is delegated to one of the nameservers of a
-   large ISP could return tens of thousands of 3-tuples in the question
-   section.  This could easily be used to launch denial of service
-   attacks.
-
-   Operators of servers that do support IQUERY in some form (such as
-   very old BIND 4 servers) generally opt to disable it.  This is
-   largely due to bugs in insufficiently-exercised code, or concerns
-   about exposure of large blocks of names in their zones by probes such
-   as inverse MX queries.
-
-   IQUERY is also somewhat inherently crippled by being unable to tell a
-   requester where it needs to go to get the information that was
-   requested.  The answer is very specific to the single server that was
-   queried.  This is sometimes a handy diagnostic tool, but apparently
-   not enough so that server operators like to enable it, or request
-   implementation where it is lacking.
-
-   No known clients use IQUERY to provide any meaningful service.  The
-   only common reverse mapping support on the Internet, mapping address
-   records to names, is provided through the use of pointer (PTR)
-   records in the in-addr.arpa tree and has served the community well
-   for many years.
-
-   Based on all of these factors, this document recommends that the
-   IQUERY operation for DNS servers be officially obsoleted.
-
-2 - Requirements
-
-   The key word "SHOULD" in this document is to be interpreted as
-   described in BCP 14, RFC 2119, namely that there may exist valid
-   reasons to ignore a particular item, but the full implications must
-   be understood and carefully weighed before choosing a different
-   course.
-
-3 - Effect on RFC 1035
-
-   The effect of this document is to change the definition of opcode 1
-   from that originally defined in section 4.1.1 of RFC 1035, and to
-   entirely supersede section 6.4 (including subsections) of RFC 1035.
-
-   The definition of opcode 1 is hereby changed to:
-
-      "1               an inverse query (IQUERY) (obsolete)"
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 2]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-   The text in section 6.4 of RFC 1035 is now considered obsolete.  The
-   following is an applicability statement regarding the IQUERY opcode:
-
-   Inverse queries using the IQUERY opcode were originally described as
-   the ability to look up the names that are associated with a
-   particular Resource Record (RR).  Their implementation was optional
-   and never achieved widespread use.  Therefore IQUERY is now obsolete,
-   and name servers SHOULD return a "Not Implemented" error when an
-   IQUERY request is received.
-
-4 - Security Considerations
-
-   Since this document obsoletes an operation that was once available,
-   it is conceivable that someone was using it as the basis of a
-   security policy.  However, since the most logical course for such a
-   policy to take in the face of a lack of positive response from a
-   server is to deny authentication/authorization, it is highly unlikely
-   that removing support for IQUERY will open any new security holes.
-
-   Note that if IQUERY is not obsoleted, securing the responses with DNS
-   Security (DNSSEC) is extremely difficult without out-on-the-fly
-   digital signing.
-
-5 - IANA Considerations
-
-   The IQUERY opcode of 1 should be permanently retired, not to be
-   assigned to any future opcode.
-
-6 - Acknowledgments
-
-   Olafur Gudmundsson instigated this action.  Matt Crawford, John
-   Klensin, Erik Nordmark and Keith Moore contributed some improved
-   wording in how to handle obsoleting functionality described by an
-   Internet Standard.
-
-7 - References
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
-              3", BCP 9, RFC 2026, October 1996.
-
-   [RFC2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 3]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-8 - Author's Address
-
-   David C Lawrence
-   Nominum, Inc.
-   2385 Bay Rd
-   Redwood City CA 94063
-   USA
-
-   Phone: +1.650.779.6042
-   EMail: tale@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 4]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-9 - Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 5]
-
diff --git a/doc/rfc/rfc3445.txt b/doc/rfc/rfc3445.txt
deleted file mode 100644
index 67f9b2d6..00000000
--- a/doc/rfc/rfc3445.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          D. Massey
-Request for Comments: 3445                                       USC/ISI
-Updates: 2535                                                    S. Rose
-Category: Standards Track                                           NIST
-                                                           December 2002
-
-
-           Limiting the Scope of the KEY Resource Record (RR)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This document limits the Domain Name System (DNS) KEY Resource Record
-   (RR) to only keys used by the Domain Name System Security Extensions
-   (DNSSEC).  The original KEY RR used sub-typing to store both DNSSEC
-   keys and arbitrary application keys.  Storing both DNSSEC and
-   application keys with the same record type is a mistake.  This
-   document removes application keys from the KEY record by redefining
-   the Protocol Octet field in the KEY RR Data.  As a result of removing
-   application keys, all but one of the flags in the KEY record become
-   unnecessary and are redefined.  Three existing application key sub-
-   types are changed to reserved, but the format of the KEY record is
-   not changed.  This document updates RFC 2535.
-
-1. Introduction
-
-   This document limits the scope of the KEY Resource Record (RR).  The
-   KEY RR was defined in [3] and used resource record sub-typing to hold
-   arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys.
-   This document eliminates the existing Email, IPSEC, and TLS sub-types
-   and prohibits the introduction of new sub-types.  DNSSEC will be the
-   only allowable sub-type for the KEY RR (hence sub-typing is
-   essentially eliminated) and all but one of the KEY RR flags are also
-   eliminated.
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 1]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   Section 2 presents the motivation for restricting the KEY record and
-   Section 3 defines the revised KEY RR.  Sections 4 and 5 summarize the
-   changes from RFC 2535 and discuss backwards compatibility.  It is
-   important to note that this document restricts the use of the KEY RR
-   and simplifies the flags, but does not change the definition or use
-   of DNSSEC keys.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [1].
-
-2. Motivation for Restricting the KEY RR
-
-   The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an
-   Algorithm type, and a Public Key.  The Protocol Octet identifies the
-   KEY RR sub-type.  DNSSEC public keys are stored in the KEY RR using a
-   Protocol Octet value of 3.  Email, IPSEC, and TLS keys were also
-   stored in the KEY RR and used Protocol Octet values of 1,2, and 4
-   (respectively).  Protocol Octet values 5-254 were available for
-   assignment by IANA and values were requested (but not assigned) for
-   applications such as SSH.
-
-   Any use of sub-typing has inherent limitations.  A resolver can not
-   specify the desired sub-type in a DNS query and most DNS operations
-   apply only to resource records sets.  For example, a resolver can not
-   directly request the DNSSEC subtype KEY RRs.  Instead, the resolver
-   has to request all KEY RRs associated with a DNS name and then search
-   the set for the desired DNSSEC sub-type.  DNSSEC signatures also
-   apply to the set of all KEY RRs associated with the DNS name,
-   regardless of sub-type.
-
-   In the case of the KEY RR, the inherent sub-type limitations are
-   exacerbated since the sub-type is used to distinguish between DNSSEC
-   keys and application keys.  DNSSEC keys and application keys differ
-   in virtually every respect and Section 2.1 discusses these
-   differences in more detail.  Combining these very different types of
-   keys into a single sub-typed resource record adds unnecessary
-   complexity and increases the potential for implementation and
-   deployment errors.  Limited experimental deployment has shown that
-   application keys stored in KEY RRs are problematic.
-
-   This document addresses these issues by removing all application keys
-   from the KEY RR.  Note that the scope of this document is strictly
-   limited to the KEY RR and this document does not endorse or restrict
-   the storage of application keys in other, yet undefined, resource
-   records.
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 2]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-2.1 Differences Between DNSSEC and Application Keys
-
-   DNSSEC keys are an essential part of the DNSSEC protocol and are used
-   by both name servers and resolvers in order to perform DNS tasks.  A
-   DNS zone key, used to sign and authenticate RR sets, is the most
-   common example of a DNSSEC key.  SIG(0) [4] and TKEY [3]  also use
-   DNSSEC keys.
-
-   Application keys such as Email keys, IPSEC keys, and TLS keys are
-   simply another type of data.  These keys have no special meaning to a
-   name server or resolver.
-
-   The following table summarizes some of the differences between DNSSEC
-   keys and application keys:
-
-      1.  They serve different purposes.
-
-      2.  They are managed by different administrators.
-
-      3.  They are authenticated according to different rules.
-
-      4.  Nameservers use different rules when including them in
-          responses.
-
-      5.  Resolvers process them in different ways.
-
-      6.  Faults/key compromises have different consequences.
-
-   1.  The purpose of a DNSSEC key is to sign resource records
-   associated with a DNS zone (or generate DNS transaction signatures in
-   the case of SIG(0)/TKEY).  But the purpose of an application key is
-   specific to the application.  Application keys, such as PGP/email,
-   IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and
-   the purpose and proper use of application keys is outside the scope
-   of DNS.
-
-   2.  DNSSEC keys are managed by DNS administrators, but application
-   keys are managed by application administrators.  The DNS zone
-   administrator determines the key lifetime, handles any suspected key
-   compromises, and manages any DNSSEC key changes.  Likewise, the
-   application administrator is responsible for the same functions for
-   the application keys related to the application.  For example, a user
-   typically manages her own PGP key and a server manages its own TLS
-   key.  Application key management tasks are outside the scope of DNS
-   administration.
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 3]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   3.  DNSSEC zone keys are used to authenticate application keys, but
-   by definition, application keys are not allowed to authenticate DNS
-   zone keys.  A DNS zone key is either configured as a trusted key or
-   authenticated by constructing a chain of trust in the DNS hierarchy.
-   To participate in the chain of trust, a DNS zone needs to exchange
-   zone key information with its parent zone [3].  Application keys are
-   not configured as trusted keys in the DNS and are never part of any
-   DNS chain of trust.  Application key data is not needed by the parent
-   and does not need to be exchanged with the parent zone for secure DNS
-   resolution to work.  A resolver considers an application key RRset as
-   authenticated DNS information if it has a valid signature from the
-   local DNS zone keys, but applications could impose additional
-   security requirements before the application key is accepted as
-   authentic for use with the application.
-
-   4.  It may be useful for nameservers to include DNS zone keys in the
-   additional section of a response, but application keys are typically
-   not useful unless they have been specifically requested.  For
-   example, it could be useful to include the example.com zone key along
-   with a response that contains the www.example.com A record and SIG
-   record.  A secure resolver will need the example.com zone key in
-   order to check the SIG and authenticate the www.example.com A record.
-   It is typically not useful to include the IPSEC, email, and TLS keys
-   along with the A record.  Note that by placing application keys in
-   the KEY record, a resolver would need the IPSEC, email, TLS, and
-   other key associated with example.com if the resolver intends to
-   authenticate the example.com zone key (since signatures only apply to
-   the entire KEY RR set).  Depending on the number of protocols
-   involved, the KEY RR set could grow unwieldy for resolvers, and DNS
-   administrators to manage.
-
-   5.  DNS zone keys require special handling by resolvers, but
-   application keys are treated the same as any other type of DNS data.
-   The DNSSEC keys are of no value to end applications, unless the
-   applications plan to do their own DNS authentication.  By definition,
-   secure resolvers are not allowed to use application keys as part of
-   the authentication process.  Application keys have no unique meaning
-   to resolvers and are only useful to the application requesting the
-   key.  Note that if sub-types are used to identify the application
-   key, then either the interface to the resolver needs to specify the
-   sub-type or the application needs to be able to accept all KEY RRs
-   and pick out the desired sub-type.
-
-   6.  A fault or compromise of a DNS zone key can lead to invalid or
-   forged DNS data, but a fault or compromise of an application key
-   should have no impact on other DNS data.  Incorrectly adding or
-   changing a DNS zone key can invalidate all of the DNS data in the
-   zone and in all of its subzones.  By using a compromised key, an
-
-
-
-Massey & Rose               Standards Track                     [Page 4]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   attacker can forge data from the effected zone and for any of its
-   sub-zones.  A fault or compromise of an application key has
-   implications for that application, but it should not have an impact
-   on the DNS.  Note that application key faults and key compromises can
-   have an impact on the entire DNS if the application key and DNS zone
-   keys are both stored in the KEY RR.
-
-   In summary, DNSSEC keys and application keys differ in most every
-   respect.  DNSSEC keys are an essential part of the DNS infrastructure
-   and require special handling by DNS administrators and DNS resolvers.
-   Application keys are simply another type of data and have no special
-   meaning to DNS administrators or resolvers.  These two different
-   types of data do not belong in the same resource record.
-
-3. Definition of the KEY RR
-
-   The KEY RR uses type 25 and is used as resource record for storing
-   DNSSEC keys.  The RDATA for a KEY RR consists of flags, a protocol
-   octet, the algorithm number octet, and the public key itself.  The
-   format is as follows:
-
-   ---------------------------------------------------------------------
-
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |              flags            |   protocol    |   algorithm   |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               /
-   /                        public key                             /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                             KEY RR Format
-
-   ---------------------------------------------------------------------
-
-   In the flags field, all bits except bit 7 are reserved and MUST be
-   zero.  If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone
-   key.  If Bit 7 is set to 0, the KEY is not a zone key.  SIG(0)/TKEY
-   are examples of DNSSEC keys that are not zone keys.
-
-   The protocol field MUST be set to 3.
-
-   The algorithm and public key fields are not changed.
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 5]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-4. Changes from RFC 2535 KEY RR
-
-   The KEY RDATA format is not changed.
-
-   All flags except for the zone key flag are eliminated:
-
-      The A/C bits (bits 0 and 1) are eliminated.  They MUST be set to 0
-      and MUST be ignored by the receiver.
-
-      The extended flags bit (bit 3) is eliminated.  It MUST be set to 0
-      and MUST be ignored by the receiver.
-
-      The host/user bit (bit 6) is eliminated.  It MUST be set to 0 and
-      MUST be ignored by the receiver.
-
-      The zone bit (bit 7) remains unchanged.
-
-      The signatory field (bits 12-15) are eliminated by [5].  They MUST
-      be set to 0 and MUST be ignored by the receiver.
-
-      Bits 2,4,5,8,9,10,11 remain unchanged.  They are reserved, MUST be
-      set to zero and MUST be ignored by the receiver.
-
-   Assignment of any future KEY RR Flag values requires a standards
-   action.
-
-   All Protocol Octet values except DNSSEC (3) are eliminated:
-
-      Value 1 (Email) is renamed to RESERVED.
-
-      Value 2 (IPSEC) is renamed to RESERVED.
-
-      Value 3 (DNSSEC) is unchanged.
-
-      Value 4 (TLS) is renamed to RESERVED.
-
-      Value 5-254 remains unchanged (reserved).
-
-      Value 255 (ANY) is renamed to RESERVED.
-
-   The authoritative data for a zone MUST NOT include any KEY records
-   with a protocol octet other than 3.  The registry maintained by IANA
-   for protocol values is closed for new assignments.
-
-   Name servers and resolvers SHOULD accept KEY RR sets that contain KEY
-   RRs with a value other than 3.  If out of date DNS zones contain
-   deprecated KEY RRs with a protocol octet value other than 3, then
-   simply dropping the deprecated KEY RRs from the KEY RR set would
-
-
-
-Massey & Rose               Standards Track                     [Page 6]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   invalidate any associated SIG record(s) and could create caching
-   consistency problems.  Note that KEY RRs with a protocol octet value
-   other than 3 MUST NOT be used to authenticate DNS data.
-
-   The algorithm and public key fields are not changed.
-
-5. Backward Compatibility
-
-   DNSSEC zone KEY RRs are not changed and remain backwards compatible.
-   A properly formatted RFC 2535 zone KEY would have all flag bits,
-   other than the Zone Bit (Bit 7), set to 0 and would have the Protocol
-   Octet set to 3.  This remains true under the restricted KEY.
-
-   DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible,
-   but the distinction between host and user keys (flag bit 6) is lost.
-
-   No backwards compatibility is provided for application keys.  Any
-   Email, IPSEC, or TLS keys are now deprecated.  Storing application
-   keys in the KEY RR created problems such as keys at the apex and
-   large RR sets and some change in the definition and/or usage of the
-   KEY RR would have been required even if the approach described here
-   were not adopted.
-
-   Overall, existing nameservers and resolvers will continue to
-   correctly process KEY RRs with a sub-type of DNSSEC keys.
-
-6. Storing Application Keys in the DNS
-
-   The scope of this document is strictly limited to the KEY record.
-   This document prohibits storing application keys in the KEY record,
-   but it does not endorse or restrict the storing application keys in
-   other record types.  Other documents can describe how DNS handles
-   application keys.
-
-7. IANA Considerations
-
-   RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet
-   values.  Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and
-   values 5-254 were made available for assignment by IANA.  This
-   document makes two sets of changes to this registry.
-
-   First, this document re-assigns DNS KEY RR Protocol Octet values 1,
-   2, 4, and 255 to "reserved".  DNS Key RR Protocol Octet Value 3
-   remains unchanged as "DNSSEC".
-
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 7]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   Second, new values are no longer available for assignment by IANA and
-   this document closes the IANA registry for DNS KEY RR Protocol Octet
-   Values.  Assignment of any future KEY RR Protocol Octet values
-   requires a standards action.
-
-8. Security Considerations
-
-   This document eliminates potential security problems that could arise
-   due to the coupling of DNS zone keys and application keys.  Prior to
-   the change described in this document, a correctly authenticated KEY
-   set could include both application keys and DNSSEC keys.  This
-   document restricts the KEY RR to DNS security usage only.  This is an
-   attempt to simplify the security model and make it less user-error
-   prone.  If one of the application keys is compromised, it could be
-   used as a false zone key to create false DNS signatures (SIG
-   records).  Resolvers that do not carefully check the KEY sub-type
-   could believe these false signatures and incorrectly authenticate DNS
-   data.  With this change, application keys cannot appear in an
-   authenticated KEY set and this vulnerability is eliminated.
-
-   The format and correct usage of DNSSEC keys is not changed by this
-   document and no new security considerations are introduced.
-
-9. Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [3]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
-        2930, September 2000.
-
-   [4]  Eastlake, D., "DNS Request and Transaction Signatures
-        (SIG(0)s)", RFC 2931, September 2000.
-
-   [5]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-        Update", RFC 3007, November 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 8]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-10. Authors' Addresses
-
-   Dan Massey
-   USC Information Sciences Institute
-   3811 N. Fairfax Drive
-   Arlington, VA  22203
-   USA
-
-   EMail: masseyd@isi.edu
-
-
-   Scott Rose
-   National Institute for Standards and Technology
-   100 Bureau Drive
-   Gaithersburg, MD  20899-3460
-   USA
-
-   EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 9]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-11.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Massey & Rose               Standards Track                    [Page 10]
-
diff --git a/doc/rfc/rfc3467.txt b/doc/rfc/rfc3467.txt
deleted file mode 100644
index 37ac7ec1..00000000
--- a/doc/rfc/rfc3467.txt
+++ /dev/null
@@ -1,1739 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         J. Klensin
-Request for Comments: 3467                                 February 2003
-Category: Informational
-
-
-                  Role of the Domain Name System (DNS)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document reviews the original function and purpose of the domain
-   name system (DNS).  It contrasts that history with some of the
-   purposes for which the DNS has recently been applied and some of the
-   newer demands being placed upon it or suggested for it.  A framework
-   for an alternative to placing these additional stresses on the DNS is
-   then outlined.  This document and that framework are not a proposed
-   solution, only a strong suggestion that the time has come to begin
-   thinking more broadly about the problems we are encountering and
-   possible approaches to solving them.
-
-Table of Contents
-
-   1.  Introduction and History .....................................  2
-      1.1 Context for DNS Development ...............................  3
-      1.2 Review of the DNS and Its Role as Designed ................  4
-      1.3 The Web and User-visible Domain Names .....................  6
-      1.4 Internet Applications Protocols and Their Evolution .......  7
-   2.  Signs of DNS Overloading .....................................  8
-   3.  Searching, Directories, and the DNS .......................... 12
-      3.1 Overview  ................................................. 12
-      3.2 Some Details and Comments ................................. 14
-   4.  Internationalization ......................................... 15
-      4.1 ASCII Isn't Just Because of English ....................... 16
-      4.2 The "ASCII Encoding" Approaches ........................... 17
-      4.3 "Stringprep" and Its Complexities ......................... 17
-      4.4 The Unicode Stability Problem ............................. 19
-      4.5 Audiences, End Users, and the User Interface Problem ...... 20
-      4.6 Business Cards and Other Natural Uses of Natural Languages. 22
-      4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22
-
-
-
-Klensin                      Informational                      [Page 1]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23
-   5.  Search-based Systems: The Key Controversies .................. 23
-   6.  Security Considerations ...................................... 24
-   7.  References ................................................... 25
-      7.1 Normative References ...................................... 25
-      7.2 Explanatory and Informative References .................... 25
-   8.  Acknowledgements ............................................. 30
-   9.  Author's Address ............................................. 30
-   10. Full Copyright Statement ..................................... 31
-
-1. Introduction and History
-
-   The DNS was designed as a replacement for the older "host table"
-   system.  Both were intended to provide names for network resources at
-   a more abstract level than network (IP) addresses (see, e.g.,
-   [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]).  In recent years,
-   the DNS has become a database of convenience for the Internet, with
-   many proposals to add new features.  Only some of these proposals
-   have been successful.  Often the main (or only) motivation for using
-   the DNS is because it exists and is widely deployed, not because its
-   existing structure, facilities, and content are appropriate for the
-   particular application of data involved.  This document reviews the
-   history of the DNS, including examination of some of those newer
-   applications.  It then argues that the overloading process is often
-   inappropriate.  Instead, it suggests that the DNS should be
-   supplemented by systems better matched to the intended applications
-   and outlines a framework and rationale for one such system.
-
-   Several of the comments that follow are somewhat revisionist.  Good
-   design and engineering often requires a level of intuition by the
-   designers about things that will be necessary in the future; the
-   reasons for some of these design decisions are not made explicit at
-   the time because no one is able to articulate them.  The discussion
-   below reconstructs some of the decisions about the Internet's primary
-   namespace (the "Class=IN" DNS) in the light of subsequent development
-   and experience.  In addition, the historical reasons for particular
-   decisions about the Internet were often severely underdocumented
-   contemporaneously and, not surprisingly, different participants have
-   different recollections about what happened and what was considered
-   important.  Consequently, the quasi-historical story below is just
-   one story.  There may be (indeed, almost certainly are) other stories
-   about how the DNS evolved to its present state, but those variants do
-   not invalidate the inferences and conclusions.
-
-   This document presumes a general understanding of the terminology of
-   RFC 1034 [RFC1034] or of any good DNS tutorial (see, e.g., [Albitz]).
-
-
-
-
-
-Klensin                      Informational                      [Page 2]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-1.1  Context for DNS Development
-
-   During the entire post-startup-period life of the ARPANET and nearly
-   the first decade or so of operation of the Internet, the list of host
-   names and their mapping to and from addresses was maintained in a
-   frequently-updated "host table" [RFC625], [RFC811], [RFC952].  The
-   names themselves were restricted to a subset of ASCII [ASCII] chosen
-   to avoid ambiguities in printed form, to permit interoperation with
-   systems using other character codings (notably EBCDIC), and to avoid
-   the "national use" code positions of ISO 646 [IS646].  These
-   restrictions later became collectively known as the "LDH" rules for
-   "letter-digit-hyphen", the permitted characters.  The table was just
-   a list with a common format that was eventually agreed upon; sites
-   were expected to frequently obtain copies of, and install, new
-   versions.  The host tables themselves were introduced to:
-
-   o  Eliminate the requirement for people to remember host numbers
-      (addresses).  Despite apparent experience to the contrary in the
-      conventional telephone system, numeric numbering systems,
-      including the numeric host number strategy, did not (and do not)
-      work well for more than a (large) handful of hosts.
-
-   o  Provide stability when addresses changed.  Since addresses -- to
-      some degree in the ARPANET and more importantly in the
-      contemporary Internet -- are a function of network topology and
-      routing, they often had to be changed when connectivity or
-      topology changed.  The names could be kept stable even as
-      addresses changed.
-
-   o  Provide the capability to have multiple addresses associated with
-      a given host to reflect different types of connectivity and
-      topology.  Use of names, rather than explicit addresses, avoided
-      the requirement that would otherwise exist for users and other
-      hosts to track these multiple host numbers and addresses and the
-      topological considerations for selecting one over others.
-
-   After several years of using the host table approach, the community
-   concluded that model did not scale adequately and that it would not
-   adequately support new service variations.  A number of discussions
-   and meetings were held which drew several ideas and incomplete
-   proposals together.  The DNS was the result of that effort.  It
-   continued to evolve during the design and initial implementation
-   period, with a number of documents recording the changes (see
-   [RFC819], [RFC830], and [RFC1034]).
-
-
-
-
-
-
-
-Klensin                      Informational                      [Page 3]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   The goals for the DNS included:
-
-   o  Preservation of the capabilities of the host table arrangements
-      (especially unique, unambiguous, host names),
-
-   o  Provision for addition of additional services (e.g., the special
-      record types for electronic mail routing which quickly followed
-      introduction of the DNS), and
-
-   o  Creation of a robust, hierarchical, distributed, name lookup
-      system to accomplish the other goals.
-
-   The DNS design also permitted distribution of name administration,
-   rather than requiring that each host be entered into a single,
-   central, table by a central administration.
-
-1.2 Review of the DNS and Its Role as Designed
-
-   The DNS was designed to identify network resources.  Although there
-   was speculation about including, e.g., personal names and email
-   addresses, it was not designed primarily to identify people, brands,
-   etc.  At the same time, the system was designed with the flexibility
-   to accommodate new data types and structures, both through the
-   addition of new record types to the initial "INternet" class, and,
-   potentially, through the introduction of new classes.  Since the
-   appropriate identifiers and content of those future extensions could
-   not be anticipated, the design provided that these fields could
-   contain any (binary) information, not just the restricted text forms
-   of the host table.
-
-   However, the DNS, as it is actually used, is intimately tied to the
-   applications and application protocols that utilize it, often at a
-   fairly low level.
-
-   In particular, despite the ability of the protocols and data
-   structures themselves to accommodate any binary representation, DNS
-   names as used were historically not even unrestricted ASCII, but a
-   very restricted subset of it, a subset that derives from the original
-   host table naming rules.  Selection of that subset was driven in part
-   by human factors considerations, including a desire to eliminate
-   possible ambiguities in an international context.  Hence character
-   codes that had international variations in interpretation were
-   excluded, the underscore character and case distinctions were
-   eliminated as being confusing (in the underscore's case, with the
-   hyphen character) when written or read by people, and so on.  These
-   considerations appear to be very similar to those that resulted in
-   similarly restricted character sets being used as protocol elements
-   in many ITU and ISO protocols (cf. [X29]).
-
-
-
-Klensin                      Informational                      [Page 4]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   Another assumption was that there would be a high ratio of physical
-   hosts to second level domains and, more generally, that the system
-   would be deeply hierarchical, with most systems (and names) at the
-   third level or below and a very large percentage of the total names
-   representing physical hosts.  There are domains that follow this
-   model: many university and corporate domains use fairly deep
-   hierarchies, as do a few country-oriented top level domains
-   ("ccTLDs").  Historically, the "US." domain has been an excellent
-   example of the deeply hierarchical approach.  However, by 1998,
-   comparison of several efforts to survey the DNS showed a count of SOA
-   records that approached (and may have passed) the number of distinct
-   hosts.  Looked at differently, we appear to be moving toward a
-   situation in which the number of delegated domains on the Internet is
-   approaching or exceeding the number of hosts, or at least the number
-   of hosts able to provide services to others on the network.  This
-   presumably results from synonyms or aliases that map a great many
-   names onto a smaller number of hosts.  While experience up to this
-   time has shown that the DNS is robust enough -- given contemporary
-   machines as servers and current bandwidth norms -- to be able to
-   continue to operate reasonably well when those historical assumptions
-   are not met (e.g., with a flat, structure under ".COM" containing
-   well over ten million delegated subdomains [COMSIZE]), it is still
-   useful to remember that the system could have been designed to work
-   optimally with a flat structure (and very large zones) rather than a
-   deeply hierarchical one, and was not.
-
-   Similarly, despite some early speculation about entering people's
-   names and email addresses into the DNS directly (e.g., see
-   [RFC1034]), electronic mail addresses in the Internet have preserved
-   the original, pre-DNS, "user (or mailbox) at location" conceptual
-   format rather than a flatter or strictly dot-separated one.
-   Location, in that instance, is a reference to a host. The sole
-   exception, at least in the "IN" class, has been one field of the SOA
-   record.
-
-   Both the DNS architecture itself and the two-level (host name and
-   mailbox name) provisions for email and similar functions (e.g., see
-   the finger protocol [FINGER]), also anticipated a relatively high
-   ratio of users to actual hosts.  Despite the observation in RFC 1034
-   that the DNS was expected to grow to be proportional to the number of
-   users (section 2.3), it has never been clear that the DNS was
-   seriously designed for, or could, scale to the order of magnitude of
-   number of users (or, more recently, products or document objects),
-   rather than that of physical hosts.
-
-   Just as was the case for the host table before it, the DNS provided
-   critical uniqueness for names, and universal accessibility to them,
-   as part of overall "single internet" and "end to end" models (cf.
-
-
-
-Klensin                      Informational                      [Page 5]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [RFC2826]).  However, there are many signs that, as new uses evolved
-   and original assumptions were abused (if not violated outright), the
-   system was being stretched to, or beyond, its practical limits.
-
-   The original design effort that led to the DNS included examination
-   of the directory technologies available at the time.  The design
-   group concluded that the DNS design, with its simplifying assumptions
-   and restricted capabilities, would be feasible to deploy and make
-   adequately robust, which the more comprehensive directory approaches
-   were not.  At the same time, some of the participants feared that the
-   limitations might cause future problems; this document essentially
-   takes the position that they were probably correct.  On the other
-   hand, directory technology and implementations have evolved
-   significantly in the ensuing years: it may be time to revisit the
-   assumptions, either in the context of the two- (or more) level
-   mechanism contemplated by the rest of this document or, even more
-   radically, as a path toward a DNS replacement.
-
-1.3 The Web and User-visible Domain Names
-
-   From the standpoint of the integrity of the domain name system -- and
-   scaling of the Internet, including optimal accessibility to content
-   -- the web design decision to use "A record" domain names directly in
-   URLs, rather than some system of indirection, has proven to be a
-   serious mistake in several respects.  Convenience of typing, and the
-   desire to make domain names out of easily-remembered product names,
-   has led to a flattening of the DNS, with many people now perceiving
-   that second-level names under COM (or in some countries, second- or
-   third-level names under the relevant ccTLD) are all that is
-   meaningful.  This perception has been reinforced by some domain name
-   registrars [REGISTRAR] who have been anxious to "sell" additional
-   names.  And, of course, the perception that one needed a second-level
-   (or even top-level) domain per product, rather than having names
-   associated with a (usually organizational) collection of network
-   resources, has led to a rapid acceleration in the number of names
-   being registered.  That acceleration has, in turn, clearly benefited
-   registrars charging on a per-name basis, "cybersquatters", and others
-   in the business of "selling" names, but it has not obviously
-   benefited the Internet as a whole.
-
-   This emphasis on second-level domain names has also created a problem
-   for the trademark community.  Since the Internet is international,
-   and names are being populated in a flat and unqualified space,
-   similarly-named entities are in conflict even if there would
-   ordinarily be no chance of confusing them in the marketplace.  The
-   problem appears to be unsolvable except by a choice between draconian
-   measures.  These might include significant changes to the legislation
-   and conventions that govern disputes over "names" and "marks".  Or
-
-
-
-Klensin                      Informational                      [Page 6]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   they might result in a situation in which the "rights" to a name are
-   typically not settled using the subtle and traditional product (or
-   industry) type and geopolitical scope rules of the trademark system.
-   Instead they have depended largely on political or economic power,
-   e.g., the organization with the greatest resources to invest in
-   defending (or attacking) names will ultimately win out.  The latter
-   raises not only important issues of equity, but also the risk of
-   backlash as the numerous small players are forced to relinquish names
-   they find attractive and to adopt less-desirable naming conventions.
-
-   Independent of these sociopolitical problems, content distribution
-   issues have made it clear that it should be possible for an
-   organization to have copies of data it wishes to make available
-   distributed around the network, with a user who asks for the
-   information by name getting the topologically-closest copy.  This is
-   not possible with simple, as-designed, use of the DNS: DNS names
-   identify target resources or, in the case of email "MX" records, a
-   preferentially-ordered list of resources "closest" to a target (not
-   to the source/user).  Several technologies (and, in some cases,
-   corresponding business models) have arisen to work around these
-   problems, including intercepting and altering DNS requests so as to
-   point to other locations.
-
-   Additional implications are still being discovered and evaluated.
-
-   Approaches that involve interception of DNS queries and rewriting of
-   DNS names (or otherwise altering the resolution process based on the
-   topological location of the user) seem, however, to risk disrupting
-   end-to-end applications in the general case and raise many of the
-   issues discussed by the IAB in [IAB-OPES].  These problems occur even
-   if the rewriting machinery is accompanied by additional workarounds
-   for particular applications.  For example, security associations and
-   applications that need to identify "the same host" often run into
-   problems if DNS names or other references are changed in the network
-   without participation of the applications that are trying to invoke
-   the associated services.
-
-1.4 Internet Applications Protocols and Their Evolution
-
-   At the applications level, few of the protocols in active,
-   widespread, use on the Internet reflect either contemporary knowledge
-   in computer science or human factors or experience accumulated
-   through deployment and use.  Instead, protocols tend to be deployed
-   at a just-past-prototype level, typically including the types of
-   expedient compromises typical with prototypes.  If they prove useful,
-   the nature of the network permits very rapid dissemination (i.e.,
-   they fill a vacuum, even if a vacuum that no one previously knew
-   existed).  But, once the vacuum is filled, the installed base
-
-
-
-Klensin                      Informational                      [Page 7]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   provides its own inertia: unless the design is so seriously faulty as
-   to prevent effective use (or there is a widely-perceived sense of
-   impending disaster unless the protocol is replaced), future
-   developments must maintain backward compatibility and workarounds for
-   problematic characteristics rather than benefiting from redesign in
-   the light of experience.  Applications that are "almost good enough"
-   prevent development and deployment of high-quality replacements.
-
-   The DNS is both an illustration of, and an exception to, parts of
-   this pessimistic interpretation. It was a second-generation
-   development, with the host table system being seen as at the end of
-   its useful life.  There was a serious attempt made to reflect the
-   computing state of the art at the time.  However, deployment was much
-   slower than expected (and very painful for many sites) and some fixed
-   (although relaxed several times) deadlines from a central network
-   administration were necessary for deployment to occur at all.
-   Replacing it now, in order to add functionality, while it continues
-   to perform its core functions at least reasonably well, would
-   presumably be extremely difficult.
-
-   There are many, perhaps obvious, examples of this.  Despite many
-   known deficiencies and weaknesses of definition, the "finger" and
-   "whois" [WHOIS] protocols have not been replaced (despite many
-   efforts to update or replace the latter [WHOIS-UPDATE]).  The Telnet
-   protocol and its many options drove out the SUPDUP [RFC734] one,
-   which was arguably much better designed for a diverse collection of
-   network hosts.  A number of efforts to replace the email or file
-   transfer protocols with models which their advocates considered much
-   better have failed.  And, more recently and below the applications
-   level, there is some reason to believe that this resistance to change
-   has been one of the factors impeding IPv6 deployment.
-
-2. Signs of DNS Overloading
-
-   Parts of the historical discussion above identify areas in which the
-   DNS has become overloaded (semantically if not in the mechanical
-   ability to resolve names).  Despite this overloading, it appears that
-   DNS performance and reliability are still within an acceptable range:
-   there is little evidence of serious performance degradation.  Recent
-   proposals and mechanisms to better respond to overloading and scaling
-   issues have all focused on patching or working around limitations
-   that develop when the DNS is utilized for out-of-design functions,
-   rather than on dramatic rethinking of either DNS design or those
-   uses.  The number of these issues that have arisen at much the same
-   time may argue for just that type of rethinking, and not just for
-   adding complexity and attempting to incrementally alter the design
-   (see, for example, the discussion of simplicity in section 2 of
-   [RFC3439]).
-
-
-
-Klensin                      Informational                      [Page 8]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   For example:
-
-   o  While technical approaches such as larger and higher-powered
-      servers and more bandwidth, and legal/political mechanisms such as
-      dispute resolution policies, have arguably kept the problems from
-      becoming critical, the DNS has not proven adequately responsive to
-      business and individual needs to describe or identify things (such
-      as product names and names of individuals) other than strict
-      network resources.
-
-   o  While stacks have been modified to better handle multiple
-      addresses on a physical interface and some protocols have been
-      extended to include DNS names for determining context, the DNS
-      does not deal especially well with many names associated with a
-      given host (e.g., web hosting facilities with multiple domains on
-      a server).
-
-   o  Efforts to add names deriving from languages or character sets
-      based on other than simple ASCII and English-like names (see
-      below), or even to utilize complex company or product names
-      without the use of hierarchy, have created apparent requirements
-      for names (labels) that are over 63 octets long.  This requirement
-      will undoubtedly increase over time; while there are workarounds
-      to accommodate longer names, they impose their own restrictions
-      and cause their own problems.
-
-   o  Increasing commercialization of the Internet, and visibility of
-      domain names that are assumed to match names of companies or
-      products, has turned the DNS and DNS names into a trademark
-      battleground.  The traditional trademark system in (at least) most
-      countries makes careful distinctions about fields of
-      applicability.  When the space is flattened, without
-      differentiation by either geography or industry sector, not only
-      are there likely conflicts between "Joe's Pizza" (of Boston) and
-      "Joe's Pizza" (of San Francisco) but between both and "Joe's Auto
-      Repair" (of Los Angeles).  All three would like to control
-      "Joes.com" (and would prefer, if it were permitted by DNS naming
-      rules, to also spell it as "Joe's.com" and have both resolve the
-      same way) and may claim trademark rights to do so, even though
-      conflict or confusion would not occur with traditional trademark
-      principles.
-
-   o  Many organizations wish to have different web sites under the same
-      URL and domain name.  Sometimes this is to create local variations
-      -- the Widget Company might want to present different material to
-      a UK user relative to a US one -- and sometimes it is to provide
-      higher performance by supplying information from the server
-      topologically closest to the user.  If the name resolution
-
-
-
-Klensin                      Informational                      [Page 9]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      mechanism is expected to provide this functionality, there are
-      three possible models (which might be combined):
-
-      -  supply information about multiple sites (or locations or
-         references).  Those sites would, in turn, provide information
-         associated with the name and sufficient site-specific
-         attributes to permit the application to make a sensible choice
-         of destination, or
-
-      -  accept client-site attributes and utilize them in the search
-         process, or
-
-      -  return different answers based on the location or identity of
-         the requestor.
-
-   While there are some tricks that can provide partial simulations of
-   these types of function, DNS responses cannot be reliably conditioned
-   in this way.
-
-   These, and similar, issues of performance or content choices can, of
-   course, be thought of as not involving the DNS at all.  For example,
-   the commonly-cited alternate approach of coupling these issues to
-   HTTP content negotiation (cf. [RFC2295]), requires that an HTTP
-   connection first be opened to some "common" or "primary" host so that
-   preferences can be negotiated and then the client redirected or sent
-   alternate data.  At least from the standpoint of improving
-   performance by accessing a "closer" location, both initially and
-   thereafter, this approach sacrifices the desired result before the
-   client initiates any action.  It could even be argued that some of
-   the characteristics of common content negotiation approaches are
-   workarounds for the non-optimal use of the DNS in web URLs.
-
-   o  Many existing and proposed systems for "finding things on the
-      Internet" require a true search capability in which near matches
-      can be reported to the user (or to some user agent with an
-      appropriate rule-set) and to which queries may be ambiguous or
-      fuzzy.  The DNS, by contrast, can accommodate only one set of
-      (quite rigid) matching rules.  Proposals to permit different rules
-      in different localities (e.g., matching rules that are TLD- or
-      zone-specific) help to identify the problem.  But they cannot be
-      applied directly to the DNS without either abandoning the desired
-      level of flexibility or isolating different parts of the Internet
-      from each other (or both).  Fuzzy or ambiguous searches are
-      desirable for resolution of names that might have spelling
-      variations and for names that can be resolved into different sets
-      of glyphs depending on context.  Especially when
-      internationalization is considered, variant name problems go
-      beyond simple differences in representation of a character or
-
-
-
-Klensin                      Informational                     [Page 10]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      ordering of a string.  Instead, avoiding user astonishment and
-      confusion requires consideration of relationships such as
-      languages that can be written with different alphabets, Kanji-
-      Hiragana relationships, Simplified and Traditional Chinese, etc.
-      See [Seng] for a discussion and suggestions for addressing a
-      subset of these issues in the context of characters based on
-      Chinese ones.  But that document essentially illustrates the
-      difficulty of providing the type of flexible matching that would
-      be anticipated by users; instead, it tries to protect against the
-      worst types of confusion (and opportunities for fraud).
-
-   o  The historical DNS, and applications that make assumptions about
-      how it works, impose significant risk (or forces technical kludges
-      and consequent odd restrictions), when one considers adding
-      mechanisms for use with various multi-character-set and
-      multilingual "internationalization" systems.  See the IAB's
-      discussion of some of these issues [RFC2825] for more information.
-
-   o  In order to provide proper functionality to the Internet, the DNS
-      must have a single unique root (the IAB provides more discussion
-      of this issue [RFC2826]).  There are many desires for local
-      treatment of names or character sets that cannot be accommodated
-      without either multiple roots (e.g., a separate root for
-      multilingual names, proposed at various times by MINC [MINC] and
-      others), or mechanisms that would have similar effects in terms of
-      Internet fragmentation and isolation.
-
-   o  For some purposes, it is desirable to be able to search not only
-      an index entry (labels or fully-qualified names in the DNS case),
-      but their values or targets (DNS data).  One might, for example,
-      want to locate all of the host (and virtual host) names which
-      cause mail to be directed to a given server via MX records.  The
-      DNS does not support this capability (see the discussion in
-      [IQUERY]) and it can be simulated only by extracting all of the
-      relevant records (perhaps by zone transfer if the source permits
-      doing so, but that permission is becoming less frequently
-      available) and then searching a file built from those records.
-
-   o  Finally, as additional types of personal or identifying
-      information are added to the DNS, issues arise with protection of
-      that information.  There are increasing calls to make different
-      information available based on the credentials and authorization
-      of the source of the inquiry.  As with information keyed to site
-      locations or proximity (as discussed above), the DNS protocols
-      make providing these differentiated services quite difficult if
-      not impossible.
-
-
-
-
-
-Klensin                      Informational                     [Page 11]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   In each of these cases, it is, or might be, possible to devise ways
-   to trick the DNS system into supporting mechanisms that were not
-   designed into it.  Several ingenious solutions have been proposed in
-   many of these areas already, and some have been deployed into the
-   marketplace with some success.  But the price of each of these
-   changes is added complexity and, with it, added risk of unexpected
-   and destabilizing problems.
-
-   Several of the above problems are addressed well by a good directory
-   system (supported by the LDAP protocol or some protocol more
-   precisely suited to these specific applications) or searching
-   environment (such as common web search engines) although not by the
-   DNS.  Given the difficulty of deploying new applications discussed
-   above, an important question is whether the tricks and kludges are
-   bad enough, or will become bad enough as usage grows, that new
-   solutions are needed and can be deployed.
-
-3. Searching, Directories, and the DNS
-
-3.1 Overview
-
-   The constraints of the DNS and the discussion above suggest the
-   introduction of an intermediate protocol mechanism, referred to below
-   as a "search layer" or "searchable system".  The terms "directory"
-   and "directory system" are used interchangeably with "searchable
-   system" in this document, although the latter is far more precise.
-   Search layer proposals would use a two (or more) stage lookup, not
-   unlike several of the proposals for internationalized names in the
-   DNS (see section 4), but all operations but the final one would
-   involve searching other systems, rather than looking up identifiers
-   in the DNS itself.  As explained below, this would permit relaxation
-   of several constraints, leading to a more capable and comprehensive
-   overall system.
-
-   Ultimately, many of the issues with domain names arise as the result
-   of efforts to use the DNS as a directory.  While, at the time this
-   document was written, sufficient pressure or demand had not occurred
-   to justify a change, it was already quite clear that, as a directory
-   system, the DNS is a good deal less than ideal.  This document
-   suggests that there actually is a requirement for a directory system,
-   and that the right solution to a searchable system requirement is a
-   searchable system, not a series of DNS patches, kludges, or
-   workarounds.
-
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 12]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   The following points illustrate particular aspects of this
-   conclusion.
-
-   o  A directory system would not require imposition of particular
-      length limits on names.
-
-   o  A directory system could permit explicit association of
-      attributes, e.g., language and country, with a name, without
-      having to utilize trick encodings to incorporate that information
-      in DNS labels (or creating artificial hierarchy for doing so).
-
-   o  There is considerable experience (albeit not much of it very
-      successful) in doing fuzzy and "sonex" (similar-sounding) matching
-      in directory systems.  Moreover, it is plausible to think about
-      different matching rules for different areas and sets of names so
-      that these can be adapted to local cultural requirements.
-      Specifically, it might be possible to have a single form of a name
-      in a directory, but to have great flexibility about what queries
-      matched that name (and even have different variations in different
-      areas).  Of course, the more flexibility that a system provides,
-      the greater the possibility of real or imagined trademark
-      conflicts.  But the opportunity would exist to design a directory
-      structure that dealt with those issues in an intelligent way,
-      while DNS constraints almost certainly make a general and
-      equitable DNS-only solution impossible.
-
-   o  If a directory system is used to translate to DNS names, and then
-      DNS names are looked up in the normal fashion, it may be possible
-      to relax several of the constraints that have been traditional
-      (and perhaps necessary) with the DNS.  For example, reverse-
-      mapping of addresses to directory names may not be a requirement
-      even if mapping of addresses to DNS names continues to be, since
-      the DNS name(s) would (continue to) uniquely identify the host.
-
-   o  Solutions to multilingual transcription problems that are common
-      in "normal life" (e.g., two-sided business cards to be sure that
-      recipients trying to contact a person can access romanized
-      spellings and numbers if the original language is not
-      comprehensible to them) can be easily handled in a directory
-      system by inserting both sets of entries.
-
-   o  A directory system could be designed that would return, not a
-      single name, but a set of names paired with network-locational
-      information or other context-establishing attributes.  This type
-      of information might be of considerable use in resolving the
-      "nearest (or best) server for a particular named resource"
-
-
-
-
-
-Klensin                      Informational                     [Page 13]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      problems that are a significant concern for organizations hosting
-      web and other sites that are accessed from a wide range of
-      locations and subnets.
-
-   o  Names bound to countries and languages might help to manage
-      trademark realities, while, as discussed in section 1.3 above, use
-      of the DNS in trademark-significant contexts tends to require
-      worldwide "flattening" of the trademark system.
-
-   Many of these issues are a consequence of another property of the
-   DNS:  names must be unique across the Internet.  The need to have a
-   system of unique identifiers is fairly obvious (see [RFC2826]).
-   However, if that requirement were to be eliminated in a search or
-   directory system that was visible to users instead of the DNS, many
-   difficult problems -- of both an engineering and a policy nature --
-   would be likely to vanish.
-
-3.2 Some Details and Comments
-
-   Almost any internationalization proposal for names that are in, or
-   map into, the DNS will require changing DNS resolver API calls
-   ("gethostbyname" or equivalent), or adding some pre-resolution
-   preparation mechanism, in almost all Internet applications -- whether
-   to cause the API to take a different character set (no matter how it
-   is then mapped into the bits used in the DNS or another system), to
-   accept or return more arguments with qualifying or identifying
-   information, or otherwise.  Once applications must be opened to make
-   such changes, it is a relatively small matter to switch from calling
-   into the DNS to calling a directory service and then the DNS (in many
-   situations, both actions could be accomplished in a single API call).
-
-   A directory approach can be consistent both with "flat" models and
-   multi-attribute ones.  The DNS requires strict hierarchies, limiting
-   its ability to differentiate among names by their properties.  By
-   contrast, modern directories can utilize independently-searched
-   attributes and other structured schema to provide flexibilities not
-   present in a strictly hierarchical system.
-
-   There is a strong historical argument for a single directory
-   structure (implying a need for mechanisms for registration,
-   delegation, etc.).  But a single structure is not a strict
-   requirement, especially if in-depth case analysis and design work
-   leads to the conclusion that reverse-mapping to directory names is
-   not a requirement (see section 5).  If a single structure is not
-   needed, then, unlike the DNS, there would be no requirement for a
-   global organization to authorize or delegate operation of portions of
-   the structure.
-
-
-
-
-Klensin                      Informational                     [Page 14]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   The "no single structure" concept could be taken further by moving
-   away from simple "names" in favor of, e.g., multiattribute,
-   multihierarchical, faceted systems in which most of the facets use
-   restricted vocabularies.  (These terms are fairly standard in the
-   information retrieval and classification system literature, see,
-   e.g., [IS5127].)  Such systems could be designed to avoid the need
-   for procedures to ensure uniqueness across, or even within, providers
-   and databases of the faceted entities for which the search is to be
-   performed.  (See [DNS-Search] for further discussion.)
-
-   While the discussion above includes very general comments about
-   attributes, it appears that only a very small number of attributes
-   would be needed.  The list would almost certainly include country and
-   language for internationalization purposes.  It might require
-   "charset" if we cannot agree on a character set and encoding,
-   although there are strong arguments for simply using ISO 10646 (also
-   known as Unicode or "UCS" (for Universal Character Set) [UNICODE],
-   [IS10646] coding in interchange.  Trademark issues might motivate
-   "commercial" and "non-commercial" (or other) attributes if they would
-   be helpful in bypassing trademark problems.  And applications to
-   resource location, such as those contemplated for Uniform Resource
-   Identifiers (URIs) [RFC2396, RFC3305] or the Service Location
-   Protocol [RFC2608], might argue for a few other attributes (as
-   outlined above).
-
-4.  Internationalization
-
-   Much of the thinking underlying this document was driven by
-   considerations of internationalizing the DNS or, more specifically,
-   providing access to the functions of the DNS from languages and
-   naming systems that cannot be accurately expressed in the traditional
-   DNS subset of ASCII.  Much of the relevant work was done in the
-   IETF's "Internationalized Domain Names" Working Group (IDN-WG),
-   although this document also draws on extensive parallel discussions
-   in other forums.  This section contains an evaluation of what was
-   learned as an "internationalized DNS" or "multilingual DNS" was
-   explored and suggests future steps based on that evaluation.
-
-   When the IDN-WG was initiated, it was obvious to several of the
-   participants that its first important task was an undocumented one:
-   to increase the understanding of the complexities of the problem
-   sufficiently that naive solutions could be rejected and people could
-   go to work on the harder problems.  The IDN-WG clearly accomplished
-   that task. The beliefs that the problems were simple, and in the
-   corresponding simplistic approaches and their promises of quick and
-   painless deployment, effectively disappeared as the WG's efforts
-   matured.
-
-
-
-
-Klensin                      Informational                     [Page 15]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   Some of the lessons learned from increased understanding and the
-   dissipation of naive beliefs should be taken as cautions by the wider
-   community: the problems are not simple. Specifically, extracting
-   small elements for solution rather than looking at whole systems, may
-   result in obscuring the problems but not solving any problem that is
-   worth the trouble.
-
-4.1 ASCII Isn't Just Because of English
-
-   The hostname rules chosen in the mid-70s weren't just "ASCII because
-   English uses ASCII", although that was a starting point.  We have
-   discovered that almost every other script (and even ASCII if we
-   permit the rest of the characters specified in the ISO 646
-   International Reference Version) is more complex than hostname-
-   restricted-ASCII (the "LDH" form, see section 1.1).  And ASCII isn't
-   sufficient to completely represent English -- there are several words
-   in the language that are correctly spelled only with characters or
-   diacritical marks that do not appear in ASCII.  With a broader
-   selection of scripts, in some examples, case mapping works from one
-   case to the other but is not reversible.  In others, there are
-   conventions about alternate ways to represent characters (in the
-   language, not [only] in character coding) that work most of the time,
-   but not always.  And there are issues in coding, with Unicode/10646
-   providing different ways to represent the same character
-   ("character", rather than "glyph", is used deliberately here).  And,
-   in still others, there are questions as to whether two glyphs
-   "match", which may be a distance-function question, not one with a
-   binary answer.  The IETF approach to these problems is to require
-   pre-matching canonicalization (see the "stringprep" discussion
-   below).
-
-   The IETF has resisted the temptations to either try to specify an
-   entirely new coded character set, or to pick and choose Unicode/10646
-   characters on a per-character basis rather than by using well-defined
-   blocks.  While it may appear that a character set designed to meet
-   Internet-specific needs would be very attractive, the IETF has never
-   had the expertise, resources, and representation from critically-
-   important communities to actually take on that job.  Perhaps more
-   important, a new effort might have chosen to make some of the many
-   complex tradeoffs differently than the Unicode committee did,
-   producing a code with somewhat different characteristics.  But there
-   is no evidence that doing so would produce a code with fewer problems
-   and side-effects.  It is much more likely that making tradeoffs
-   differently would simply result in a different set of problems, which
-   would be equally or more difficult.
-
-
-
-
-
-
-Klensin                      Informational                     [Page 16]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-4.2 The "ASCII Encoding" Approaches
-
-   While the DNS can handle arbitrary binary strings without known
-   internal problems (see [RFC2181]), some restrictions are imposed by
-   the requirement that text be interpreted in a case-independent way
-   ([RFC1034], [RFC1035]).  More important, most internet applications
-   assume the hostname-restricted "LDH" syntax that is specified in the
-   host table RFCs and as "prudent" in RFC 1035.  If those assumptions
-   are not met, many conforming implementations of those applications
-   may exhibit behavior that would surprise implementors and users.  To
-   avoid these potential problems, IETF internationalization work has
-   focused on "ASCII-Compatible Encodings" (ACE).  These encodings
-   preserve the LDH conventions in the DNS itself.  Implementations of
-   applications that have not been upgraded utilize the encoded forms,
-   while newer ones can be written to recognize the special codings and
-   map them into non-ASCII characters. These approaches are, however,
-   not problem-free even if human interface issues are ignored.  Among
-   other issues, they rely on what is ultimately a heuristic to
-   determine whether a DNS label is to be considered as an
-   internationalized name (i.e., encoded Unicode) or interpreted as an
-   actual LDH name in its own right.  And, while all determinations of
-   whether a particular query matches a stored object are traditionally
-   made by DNS servers, the ACE systems, when combined with the
-   complexities of international scripts and names, require that much of
-   the matching work be separated into a separate, client-side,
-   canonicalization or "preparation" process before the DNS matching
-   mechanisms are invoked [STRINGPREP].
-
-4.3 "Stringprep" and Its Complexities
-
-   As outlined above, the model for avoiding problems associated with
-   putting non-ASCII names in the DNS and elsewhere evolved into the
-   principle that strings are to be placed into the DNS only after being
-   passed through a string preparation function that eliminates or
-   rejects spurious character codes, maps some characters onto others,
-   performs some sequence canonicalization, and generally creates forms
-   that can be accurately compared.  The impact of this process on
-   hostname-restricted ASCII (i.e., "LDH") strings is trivial and
-   essentially adds only overhead.  For other scripts, the impact is, of
-   necessity, quite significant.
-
-   Although the general notion underlying stringprep is simple, the many
-   details are quite subtle and the associated tradeoffs are complex. A
-   design team worked on it for months, with considerable effort placed
-   into clarifying and fine-tuning the protocol and tables.  Despite
-   general agreement that the IETF would avoid getting into the business
-   of defining character sets, character codings, and the associated
-   conventions, the group several times considered and rejected special
-
-
-
-Klensin                      Informational                     [Page 17]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   treatment of code positions to more nearly match the distinctions
-   made by Unicode with user perceptions about similarities and
-   differences between characters.  But there were intense temptations
-   (and pressures) to incorporate language-specific or country-specific
-   rules.  Those temptations, even when resisted, were indicative of
-   parts of the ongoing controversy or of the basic unsuitability of the
-   DNS for fully internationalized names that are visible,
-   comprehensible, and predictable for end users.
-
-   There have also been controversies about how far one should go in
-   these processes of preparation and transformation and, ultimately,
-   about the validity of various analogies.  For example, each of the
-   following operations has been claimed to be similar to case-mapping
-   in ASCII:
-
-   o  stripping of vowels in Arabic or Hebrew
-
-   o  matching of "look-alike" characters such as upper-case Alpha in
-      Greek and upper-case A in Roman-based alphabets
-
-   o  matching of Traditional and Simplified Chinese characters that
-      represent the same words,
-
-   o  matching of Serbo-Croatian words whether written in Roman-derived
-      or Cyrillic characters
-
-   A decision to support any of these operations would have implications
-   for other scripts or languages and would increase the overall
-   complexity of the process.  For example, unless language-specific
-   information is somehow available, performing matching between
-   Traditional and Simplified Chinese has impacts on Japanese and Korean
-   uses of the same "traditional" characters (e.g., it would not be
-   appropriate to map Kanji into Simplified Chinese).
-
-   Even were the IDN-WG's other work to have been abandoned completely
-   or if it were to fail in the marketplace, the stringprep and nameprep
-   work will continue to be extremely useful, both in identifying issues
-   and problem code points and in providing a reasonable set of basic
-   rules.  Where problems remain, they are arguably not with nameprep,
-   but with the DNS-imposed requirement that its results, as with all
-   other parts of the matching and comparison process, yield a binary
-   "match or no match" answer, rather than, e.g., a value on a
-   similarity scale that can be evaluated by the user or by user-driven
-   heuristic functions.
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 18]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-4.4 The Unicode Stability Problem
-
-   ISO 10646 basically defines only code points, and not rules for using
-   or comparing the characters.  This is part of a long-standing
-   tradition with the work of what is now ISO/IEC JTC1/SC2: they have
-   performed code point assignments and have typically treated the ways
-   in which characters are used as beyond their scope.  Consequently,
-   they have not dealt effectively with the broader range of
-   internationalization issues.  By contrast, the Unicode Technical
-   Committee (UTC) has defined, in annexes and technical reports (see,
-   e.g., [UTR15]), some additional rules for canonicalization and
-   comparison.  Many of those rules and conventions have been factored
-   into the "stringprep" and "nameprep" work, but it is not
-   straightforward to make or define them in a fashion that is
-   sufficiently precise and permanent to be relied on by the DNS.
-
-   Perhaps more important, the discussions leading to nameprep also
-   identified several areas in which the UTC definitions are inadequate,
-   at least without additional information, to make matching precise and
-   unambiguous.  In some of these cases, the Unicode Standard permits
-   several alternate approaches, none of which are an exact and obvious
-   match to DNS needs.  That has left these sensitive choices up to
-   IETF, which lacks sufficient in-depth expertise, much less any
-   mechanism for deciding to optimize one language at the expense of
-   another.
-
-   For example, it is tempting to define some rules on the basis of
-   membership in particular scripts, or for punctuation characters, but
-   there is no precise definition of what characters belong to which
-   script or which ones are, or are not, punctuation.  The existence of
-   these areas of vagueness raises two issues: whether trying to do
-   precise matching at the character set level is actually possible
-   (addressed below) and whether driving toward more precision could
-   create issues that cause instability in the implementation and
-   resolution models for the DNS.
-
-   The Unicode definition also evolves.  Version 3.2 appeared shortly
-   after work on this document was initiated.  It added some characters
-   and functionality and included a few minor incompatible code point
-   changes.  IETF has secured an agreement about constraints on future
-   changes, but it remains to be seen how that agreement will work out
-   in practice.  The prognosis actually appears poor at this stage,
-   since UTC chose to ballot a recent possible change which should have
-   been prohibited by the agreement (the outcome of the ballot is not
-   relevant, only that the ballot was issued rather than having the
-   result be a foregone conclusion).  However, some members of the
-   community consider some of the changes between Unicode 3.0 and 3.1
-   and between 3.1 and 3.2, as well as this recent ballot, to be
-
-
-
-Klensin                      Informational                     [Page 19]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   evidence of instability and that these instabilities are better
-   handled in a system that can be more flexible about handling of
-   characters, scripts, and ancillary information than the DNS.
-
-   In addition, because the systems implications of internationalization
-   are considered out of scope in SC2, ISO/IEC JTC1 has assigned some of
-   those issues to its SC22/WG20 (the Internationalization working group
-   within the subcommittee that deals with programming languages,
-   systems, and environments).  WG20 has historically dealt with
-   internationalization issues thoughtfully and in depth, but its status
-   has several times been in doubt in recent years.  However, assignment
-   of these matters to WG20 increases the risk of eventual ISO
-   internationalization standards that specify different behavior than
-   the UTC specifications.
-
-4.5 Audiences, End Users, and the User Interface Problem
-
-   Part of what has "caused" the DNS internationalization problem, as
-   well as the DNS trademark problem and several others, is that we have
-   stopped thinking about "identifiers for objects" -- which normal
-   people are not expected to see -- and started thinking about "names"
-   -- strings that are expected not only to be readable, but to have
-   linguistically-sensible and culturally-dependent meaning to non-
-   specialist users.
-
-   Within the IETF, the IDN-WG, and sometimes other groups, avoided
-   addressing the implications of that transition by taking "outside our
-   scope -- someone else's problem" approaches or by suggesting that
-   people will just become accustomed to whatever conventions are
-   adopted.  The realities of user and vendor behavior suggest that
-   these approaches will not serve the Internet community well in the
-   long term:
-
-   o  If we want to make it a problem in a different part of the user
-      interface structure, we need to figure out where it goes in order
-      to have proof of concept of our solution.  Unlike vendors whose
-      sole [business] model is the selling or registering of names, the
-      IETF must produce solutions that actually work, in the
-      applications context as seen by the end user.
-
-   o  The principle that "they will get used to our conventions and
-      adapt" is fine if we are writing rules for programming languages
-      or an API.  But the conventions under discussion are not part of a
-      semi-mathematical system, they are deeply ingrained in culture.
-      No matter how often an English-speaking American is told that the
-      Internet requires that the correct spelling of "colour" be used,
-      he or she isn't going to be convinced. Getting a French-speaker in
-      Lyon to use exactly the same lexical conventions as a French-
-
-
-
-Klensin                      Informational                     [Page 20]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      speaker in Quebec in order to accommodate the decisions of the
-      IETF or of a registrar or registry is just not likely.  "Montreal"
-      is either a misspelling or an anglicization of a similar word with
-      an acute accent mark over the "e" (i.e., using the Unicode
-      character U+00E9 or one of its equivalents). But global agreement
-      on a rule that will determine whether the two forms should match
-      -- and that won't astonish end users and speakers of one language
-      or the other -- is as unlikely as agreement on whether
-      "misspelling" or "anglicization" is the greater travesty.
-
-   More generally, it is not clear that the outcome of any conceivable
-   nameprep-like process is going to be good enough for practical,
-   user-level, use.  In the use of human languages by humans, there are
-   many cases in which things that do not match are nonetheless
-   interpreted as matching.  The Norwegian/Danish character that appears
-   in U+00F8 (visually, a lower case 'o' overstruck with a forward
-   slash) and the "o-umlaut" German character that appears in U+00F6
-   (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly
-   different and no matching program should yield an "equal" comparison.
-   But they are more similar to each other than either of them is to,
-   e.g., "e".  Humans are able to mentally make the correction in
-   context, and do so easily, and they can be surprised if computers
-   cannot do so.  Worse, there is a Swedish character whose appearance
-   is identical to the German o-umlaut, and which shares code point
-   U+00F6, but that, if the languages are known and the sounds of the
-   letters or meanings of words including the character are considered,
-   actually should match the Norwegian/Danish use of U+00F8.
-
-   This text uses examples in Roman scripts because it is being written
-   in English and those examples are relatively easy to render.  But one
-   of the important lessons of the discussions about domain name
-   internationalization in recent years is that problems similar to
-   those described above exist in almost every language and script.
-   Each one has its idiosyncrasies, and each set of idiosyncracies is
-   tied to common usage and cultural issues that are very familiar in
-   the relevant group, and often deeply held as cultural values.  As
-   long as a schoolchild in the US can get a bad grade on a spelling
-   test for using a perfectly valid British spelling, or one in France
-   or Germany can get a poor grade for leaving off a diacritical mark,
-   there are issues with the relevant language.  Similarly, if children
-   in Egypt or Israel are taught that it is acceptable to write a word
-   with or without vowels or stress marks, but that, if those marks are
-   included, they must be the correct ones, or a user in Korea is
-   potentially offended or astonished by out-of-order sequences of Jamo,
-   systems based on character-at-a-time processing and simplistic
-   matching, with no contextual information, are not going to satisfy
-   user needs.
-
-
-
-
-Klensin                      Informational                     [Page 21]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   Users are demanding solutions that deal with language and culture.
-   Systems of identifier symbol-strings that serve specialists or
-   computers are, at best, a solution to a rather different (and, at the
-   time this document was written, somewhat ill-defined), problem.  The
-   recent efforts have made it ever more clear that, if we ignore the
-   distinction between the user requirements and narrowly-defined
-   identifiers, we are solving an insufficient problem.  And,
-   conversely, the approaches that have been proposed to approximate
-   solutions to the user requirement may be far more complex than simple
-   identifiers require.
-
-4.6 Business Cards and Other Natural Uses of Natural Languages
-
-   Over the last few centuries, local conventions have been established
-   in various parts of the world for dealing with multilingual
-   situations.  It may be helpful to examine some of these.  For
-   example, if one visits a country where the language is different from
-   ones own, business cards are often printed on two sides, one side in
-   each language.  The conventions are not completely consistent and the
-   technique assumes that recipients will be tolerant. Translations of
-   names or places are attempted in some situations and transliterations
-   in others.  Since it is widely understood that exact translations or
-   transliterations are often not possible, people typically smile at
-   errors, appreciate the effort, and move on.
-
-   The DNS situation differs from these practices in at least two ways.
-   Since a global solution is required, the business card would need a
-   number of sides approximating the number of languages in the world,
-   which is probably impossible without violating laws of physics.  More
-   important, the opportunities for tolerance don't exist:  the DNS
-   requires a exact match or the lookup fails.
-
-4.7 ASCII Encodings and the Roman Keyboard Assumption
-
-   Part of the argument for ACE-based solutions is that they provide an
-   escape for multilingual environments when applications have not been
-   upgraded.  When an older application encounters an ACE-based name,
-   the assumption is that the (admittedly ugly) ASCII-coded string will
-   be displayed and can be typed in.  This argument is reasonable from
-   the standpoint of mixtures of Roman-based alphabets, but may not be
-   relevant if user-level systems and devices are involved that do not
-   support the entry of Roman-based characters or which cannot
-   conveniently render such characters.  Such systems are few in the
-   world today, but the number can reasonably be expected to rise as the
-   Internet is increasingly used by populations whose primary concern is
-   with local issues, local information, and local languages.  It is,
-
-
-
-
-
-Klensin                      Informational                     [Page 22]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   for example, fairly easy to imagine populations who use Arabic or
-   Thai scripts and who do not have routine access to scripts or input
-   devices based on Roman-derived alphabets.
-
-4.8 Intra-DNS Approaches for "Multilingual Names"
-
-   It appears, from the cases above and others, that none of the intra-
-   DNS-based solutions for "multilingual names" are workable.  They rest
-   on too many assumptions that do not appear to be feasible -- that
-   people will adapt deeply-entrenched language habits to conventions
-   laid down to make the lives of computers easy; that we can make
-   "freeze it now, no need for changes in these areas" decisions about
-   Unicode and nameprep; that ACE will smooth over applications
-   problems, even in environments without the ability to key or render
-   Roman-based glyphs (or where user experience is such that such glyphs
-   cannot easily be distinguished from each other); that the Unicode
-   Consortium will never decide to repair an error in a way that creates
-   a risk of DNS incompatibility; that we can either deploy EDNS
-   [RFC2671] or that long names are not really important; that Japanese
-   and Chinese computer users (and others) will either give up their
-   local or IS 2022-based character coding solutions (for which addition
-   of a large fraction of a million new code points to Unicode is almost
-   certainly a necessary, but probably not sufficient, condition) or
-   build leakproof and completely accurate boundary conversion
-   mechanisms; that out of band or contextual information will always be
-   sufficient for the "map glyph onto script" problem; and so on.  In
-   each case, it is likely that about 80% or 90% of cases will work
-   satisfactorily, but it is unlikely that such partial solutions will
-   be good enough.  For example, suppose someone can spell her name 90%
-   correctly, or a company name is matched correctly 80% of the time but
-   the other 20% of attempts identify a competitor: are either likely to
-   be considered adequate?
-
-5. Search-based Systems: The Key Controversies
-
-   For many years, a common response to requirements to locate people or
-   resources on the Internet has been to invoke the term "directory".
-   While an in-depth analysis of the reasons would require a separate
-   document, the history of failure of these invocations has given
-   "directory" efforts a bad reputation.  The effort proposed here is
-   different from those predecessors for several reasons, perhaps the
-   most important of which is that it focuses on a fairly-well-
-   understood set of problems and needs, rather than on finding uses for
-   a particular technology.
-
-   As suggested in some of the text above, it is an open question as to
-   whether the needs of the community would be best served by a single
-   (even if functionally, and perhaps administratively, distributed)
-
-
-
-Klensin                      Informational                     [Page 23]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   directory with universal applicability, a single directory that
-   supports locally-tailored search (and, most important, matching)
-   functions, or multiple, locally-determined, directories.  Each has
-   its attractions.  Any but the first would essentially prevent
-   reverse-mapping (determination of the user-visible name of the host
-   or resource from target information such as an address or DNS name).
-   But reverse mapping has become less useful over the years --at least
-   to users -- as more and more names have been associated with many
-   host addresses and as CIDR [CIDR] has proven problematic for mapping
-   smaller address blocks to meaningful names.
-
-   Locally-tailored searches and mappings would permit national
-   variations on interpretation of which strings matched which other
-   ones, an arrangement that is especially important when different
-   localities apply different rules to, e.g., matching of characters
-   with and without diacriticals.  But, of course, this implies that a
-   URL may evaluate properly or not depending on either settings on a
-   client machine or the network connectivity of the user.  That is not,
-   in general, a desirable situation, since it implies that users could
-   not, in the general case, share URLs (or other host references) and
-   that a particular user might not be able to carry references from one
-   host or location to another.
-
-   And, of course, completely separate directories would permit
-   translation and transliteration functions to be embedded in the
-   directory, giving much of the Internet a different appearance
-   depending on which directory was chosen.  The attractions of this are
-   obvious, but, unless things were very carefully designed to preserve
-   uniqueness and precise identities at the right points (which may or
-   may not be possible), such a system would have many of the
-   difficulties associated with multiple DNS roots.
-
-   Finally, a system of separate directories and databases, if coupled
-   with removal of the DNS-imposed requirement for unique names, would
-   largely eliminate the need for a single worldwide authority to manage
-   the top of the naming hierarchy.
-
-6.  Security Considerations
-
-   The set of proposals implied by this document suggests an interesting
-   set of security issues (i.e., nothing important is ever easy).  A
-   directory system used for locating network resources would presumably
-   need to be as carefully protected against unauthorized changes as the
-   DNS itself.  There also might be new opportunities for problems in an
-   arrangement involving two or more (sub)layers, especially if such a
-   system were designed without central authority or uniqueness of
-   names.  It is uncertain how much greater those risks would be as
-   compared to a DNS lookup sequence that involved looking up one name,
-
-
-
-Klensin                      Informational                     [Page 24]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   getting back information, and then doing additional lookups
-   potentially in different subtrees.  That multistage lookup will often
-   be the case with, e.g., NAPTR records [RFC 2915] unless additional
-   restrictions are imposed.  But additional steps, systems, and
-   databases almost certainly involve some additional risks of
-   compromise.
-
-7.  References
-
-7.1 Normative References
-
-   None
-
-7.2 Explanatory and Informative References
-
-   [Albitz]       Any of the editions of Albitz, P. and C. Liu, DNS and
-                  BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001.
-
-   [ASCII]        American National Standards Institute (formerly United
-                  States of America Standards Institute), X3.4, 1968,
-                  "USA Code for Information Interchange". ANSI X3.4-1968
-                  has been replaced by newer versions with slight
-                  modifications, but the 1968 version remains definitive
-                  for the Internet.  Some time after ASCII was first
-                  formulated as a standard, ISO adopted international
-                  standard 646, which uses ASCII as a base.  IS 646
-                  actually contained two code tables: an "International
-                  Reference Version" (often referenced as ISO 646-IRV)
-                  which was essentially identical to the ASCII of the
-                  time, and a "Basic Version" (ISO 646-BV), which
-                  designates a number of character positions for
-                  national use.
-
-   [CIDR]         Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
-                  Inter-Domain Routing (CIDR): an Address Assignment and
-                  Aggregation Strategy", RFC 1519, September 1993.
-
-                  Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
-                  ADDR.ARPA delegation", RFC 2317, March 1998.
-
-   [COM-SIZE]     Size information supplied by Verisign Global Registry
-                  Services (the zone administrator, or "registry
-                  operator", for COM, see [REGISTRAR], below) to ICANN,
-                  third quarter 2002.
-
-   [DNS-Search]   Klensin, J., "A Search-based access model for the
-                  DNS", Work in Progress.
-
-
-
-
-Klensin                      Informational                     [Page 25]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [FINGER]       Zimmerman, D., "The Finger User Information Protocol",
-                  RFC 1288, December 1991.
-
-                  Harrenstien, K., "NAME/FINGER Protocol", RFC 742,
-                  December 1977.
-
-   [IAB-OPES]     Floyd, S. and L. Daigle, "IAB Architectural and Policy
-                  Considerations for Open Pluggable Edge Services", RFC
-                  3238, January 2002.
-
-   [IQUERY]       Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
-                  2002.
-
-   [IS646]        ISO/IEC 646:1991 Information technology -- ISO 7-bit
-                  coded character set for information interchange
-
-   [IS10646]      ISO/IEC 10646-1:2000 Information technology --
-                  Universal Multiple-Octet Coded Character Set (UCS) --
-                  Part 1: Architecture and Basic Multilingual Plane and
-                  ISO/IEC 10646-2:2001 Information technology --
-                  Universal Multiple-Octet Coded Character Set (UCS) --
-                  Part 2: Supplementary Planes
-
-   [MINC]         The Multilingual Internet Names Consortium,
-                  http://www.minc.org/ has been an early advocate for
-                  the importance of expansion of DNS names to
-                  accommodate non-ASCII characters.  Some of their
-                  specific proposals, while helping people to understand
-                  the problems better, were not compatible with the
-                  design of the DNS.
-
-   [NAPTR]        Mealling, M. and R. Daniel, "The Naming Authority
-                  Pointer (NAPTR) DNS Resource Record", RFC 2915,
-                  September 2000.
-
-                  Mealling, M., "Dynamic Delegation Discovery System
-                  (DDDS) Part One: The Comprehensive DDDS", RFC 3401,
-                  October 2002.
-
-                  Mealling, M., "Dynamic Delegation Discovery System
-                  (DDDS) Part Two: The Algorithm", RFC 3402, October
-                  2002.
-
-                  Mealling, M., "Dynamic Delegation Discovery System
-                  (DDDS) Part Three: The Domain Name System (DNS)
-                  Database", RFC 3403, October 2002.
-
-
-
-
-
-Klensin                      Informational                     [Page 26]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [REGISTRAR]    In an early stage of the process that created the
-                  Internet Corporation for Assigned Names and Numbers
-                  (ICANN), a "Green Paper" was released by the US
-                  Government.   That paper introduced new terminology
-                  and some concepts not needed by traditional DNS
-                  operations.  The term "registry" was applied to the
-                  actual operator and database holder of a domain
-                  (typically at the top level, since the Green Paper was
-                  little concerned with anything else), while
-                  organizations that marketed names and made them
-                  available to "registrants" were known as "registrars".
-                  In the classic DNS model, the function of "zone
-                  administrator" encompassed both registry and registrar
-                  roles, although that model did not anticipate a
-                  commercial market in names.
-
-   [RFC625]       Kudlick, M. and E. Feinler, "On-line hostnames
-                  service", RFC 625, March 1974.
-
-   [RFC734]       Crispin, M., "SUPDUP Protocol", RFC 734, October 1977.
-
-   [RFC811]       Harrenstien, K., White, V. and E. Feinler, "Hostnames
-                  Server", RFC 811, March 1982.
-
-   [RFC819]       Su, Z. and J. Postel, "Domain naming convention for
-                  Internet user applications", RFC 819, August 1982.
-
-   [RFC830]       Su, Z., "Distributed system for Internet name
-                  service", RFC 830, October 1982.
-
-   [RFC882]       Mockapetris, P., "Domain names: Concepts and
-                  facilities", RFC 882, November 1983.
-
-   [RFC883]       Mockapetris, P., "Domain names: Implementation
-                  specification", RFC 883, November 1983.
-
-   [RFC952]       Harrenstien, K, Stahl, M. and E. Feinler, "DoD
-                  Internet host table specification", RFC 952, October
-                  1985.
-
-   [RFC953]       Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME
-                  SERVER", RFC 953, October 1985.
-
-   [RFC1034]      Mockapetris, P., "Domain names, Concepts and
-                  facilities", STD 13, RFC 1034, November 1987.
-
-
-
-
-
-
-Klensin                      Informational                     [Page 27]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [RFC1035]      Mockapetris, P., "Domain names - implementation and
-                  specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1591]      Postel, J., "Domain Name System Structure and
-                  Delegation", RFC 1591, March 1994.
-
-   [RFC2181]      Elz, R. and  R. Bush, "Clarifications to the DNS
-                  Specification", RFC 2181, July 1997.
-
-   [RFC2295]      Holtman, K. and A. Mutz, "Transparent Content
-                  Negotiation in HTTP", RFC 2295, March 1998
-
-   [RFC2396]      Berners-Lee, T., Fielding, R. and L. Masinter,
-                  "Uniform Resource Identifiers (URI): Generic Syntax",
-                  RFC 2396, August 1998.
-
-   [RFC2608]      Guttman, E., Perkins, C., Veizades, J. and M. Day,
-                  "Service Location Protocol, Version 2", RFC 2608, June
-                  1999.
-
-   [RFC2671]      Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-                  2671, August 1999.
-
-   [RFC2825]      IAB, Daigle, L., Ed., "A Tangled Web: Issues of I18N,
-                  Domain Names, and the Other Internet protocols", RFC
-                  2825, May 2000.
-
-   [RFC2826]      IAB, "IAB Technical Comment on the Unique DNS Root",
-                  RFC 2826, May 2000.
-
-   [RFC2972]      Popp, N., Mealling, M., Masinter, L. and K. Sollins,
-                  "Context and Goals for Common Name Resolution", RFC
-                  2972, October 2000.
-
-   [RFC3305]      Mealling, M. and R. Denenberg, Eds., "Report from the
-                  Joint W3C/IETF URI Planning Interest Group: Uniform
-                  Resource Identifiers (URIs), URLs, and Uniform
-                  Resource Names (URNs):  Clarifications and
-                  Recommendations", RFC 3305, August 2002.
-
-   [RFC3439]      Bush, R. and D. Meyer, "Some Internet Architectural
-                  Guidelines and Philosophy", RFC 3439, December 2002.
-
-   [Seng]         Seng, J., et al., Eds., "Internationalized Domain
-                  Names:  Registration and Administration Guideline for
-                  Chinese, Japanese, and Korean", Work in Progress.
-
-
-
-
-
-Klensin                      Informational                     [Page 28]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [STRINGPREP]   Hoffman, P. and M. Blanchet, "Preparation of
-                  Internationalized Strings (stringprep)", RFC 3454,
-                  December 2002.
-
-                  The particular profile used for placing
-                  internationalized strings in the DNS is called
-                  "nameprep", described in Hoffman, P. and M. Blanchet,
-                  "Nameprep: A Stringprep Profile for Internationalized
-                  Domain Names", Work in Progress.
-
-   [TELNET]       Postel, J. and J. Reynolds, "Telnet Protocol
-                  Specification", STD 8, RFC 854, May 1983.
-
-                  Postel, J. and J. Reynolds, "Telnet Option
-                  Specifications", STD 8, RFC 855, May 1983.
-
-   [UNICODE]      The Unicode Consortium, The Unicode Standard, Version
-                  3.0, Addison-Wesley: Reading, MA, 2000.  Update to
-                  version 3.1, 2001.  Update to version 3.2, 2002.
-
-   [UTR15]        Davis, M. and M. Duerst, "Unicode Standard Annex #15:
-                  Unicode Normalization Forms", Unicode Consortium,
-                  March 2002.  An integral part of The Unicode Standard,
-                  Version 3.1.1.  Available at
-                  (http://www.unicode.org/reports/tr15/tr15-21.html).
-
-   [WHOIS]        Harrenstien, K, Stahl, M. and E. Feinler,
-                  "NICNAME/WHOIS", RFC 954, October 1985.
-
-   [WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network
-                  Information Lookup Service, Whois++", RFC 1834, August
-                  1995.
-
-                  Weider, C., Fullton, J. and S. Spero, "Architecture of
-                  the Whois++ Index Service", RFC 1913, February 1996.
-
-                  Williamson, S., Kosters, M., Blacka, D., Singh, J. and
-                  K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5",
-                  RFC 2167, June 1997;
-
-                  Daigle, L. and P. Faltstrom, "The
-                  application/whoispp-query Content-Type", RFC 2957,
-                  October 2000.
-
-                  Daigle, L. and P. Falstrom, "The application/whoispp-
-                  response Content-type", RFC 2958, October 2000.
-
-
-
-
-
-Klensin                      Informational                     [Page 29]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [X29]          International Telecommuncations Union, "Recommendation
-                  X.29: Procedures for the exchange of control
-                  information and user data between a Packet
-                  Assembly/Disassembly (PAD) facility and a packet mode
-                  DTE or another PAD", December 1997.
-
-8. Acknowledgements
-
-   Many people have contributed to versions of this document or the
-   thinking that went into it.  The author would particularly like to
-   thank Harald Alvestrand, Rob Austein, Bob Braden, Vinton Cerf, Matt
-   Crawford, Leslie Daigle, Patrik Faltstrom, Eric A. Hall, Ted Hardie,
-   Paul Hoffman, Erik Nordmark, and Zita Wenzel for making specific
-   suggestions and/or challenging the assumptions and presentation of
-   earlier versions and suggesting ways to improve them.
-
-9. Author's Address
-
-   John C. Klensin
-   1770 Massachusetts Ave, #322
-   Cambridge, MA 02140
-
-   EMail: klensin+srch@jck.com
-
-   A mailing list has been initiated for discussion of the topics
-   discussed in this document, and closely-related issues, at
-   ietf-irnss@lists.elistx.com.  See http://lists.elistx.com/archives/
-   for subscription and archival information.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 30]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-10. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 31]
-
diff --git a/doc/rfc/rfc3490.txt b/doc/rfc/rfc3490.txt
deleted file mode 100644
index d2e0b3b7..00000000
--- a/doc/rfc/rfc3490.txt
+++ /dev/null
@@ -1,1235 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       P. Faltstrom
-Request for Comments: 3490                                         Cisco
-Category: Standards Track                                     P. Hoffman
-                                                              IMC & VPNC
-                                                             A. Costello
-                                                             UC Berkeley
-                                                              March 2003
-
-
-         Internationalizing Domain Names in Applications (IDNA)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   Until now, there has been no standard method for domain names to use
-   characters outside the ASCII repertoire.  This document defines
-   internationalized domain names (IDNs) and a mechanism called
-   Internationalizing Domain Names in Applications (IDNA) for handling
-   them in a standard fashion.  IDNs use characters drawn from a large
-   repertoire (Unicode), but IDNA allows the non-ASCII characters to be
-   represented using only the ASCII characters already allowed in so-
-   called host names today.  This backward-compatible representation is
-   required in existing protocols like DNS, so that IDNs can be
-   introduced with no changes to the existing infrastructure.  IDNA is
-   only meant for processing domain names, not free text.
-
-Table of Contents
-
-   1. Introduction..................................................  2
-      1.1 Problem Statement.........................................  3
-      1.2 Limitations of IDNA.......................................  3
-      1.3 Brief overview for application developers.................  4
-   2. Terminology...................................................  5
-   3. Requirements and applicability................................  7
-      3.1 Requirements..............................................  7
-      3.2 Applicability.............................................  8
-         3.2.1. DNS resource records................................  8
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 1]
-
-RFC 3490                          IDNA                        March 2003
-
-
-         3.2.2. Non-domain-name data types stored in domain names...  9
-   4. Conversion operations.........................................  9
-      4.1 ToASCII................................................... 10
-      4.2 ToUnicode................................................. 11
-   5. ACE prefix.................................................... 12
-   6. Implications for typical applications using DNS............... 13
-      6.1 Entry and display in applications......................... 14
-      6.2 Applications and resolver libraries....................... 15
-      6.3 DNS servers............................................... 15
-      6.4 Avoiding exposing users to the raw ACE encoding........... 16
-      6.5  DNSSEC authentication of IDN domain names................ 16
-   7. Name server considerations.................................... 17
-   8. Root server considerations.................................... 17
-   9. References.................................................... 18
-      9.1 Normative References...................................... 18
-      9.2 Informative References.................................... 18
-   10. Security Considerations...................................... 19
-   11. IANA Considerations.......................................... 20
-   12. Authors' Addresses........................................... 21
-   13. Full Copyright Statement..................................... 22
-
-1. Introduction
-
-   IDNA works by allowing applications to use certain ASCII name labels
-   (beginning with a special prefix) to represent non-ASCII name labels.
-   Lower-layer protocols need not be aware of this; therefore IDNA does
-   not depend on changes to any infrastructure.  In particular, IDNA
-   does not depend on any changes to DNS servers, resolvers, or protocol
-   elements, because the ASCII name service provided by the existing DNS
-   is entirely sufficient for IDNA.
-
-   This document does not require any applications to conform to IDNA,
-   but applications can elect to use IDNA in order to support IDN while
-   maintaining interoperability with existing infrastructure.  If an
-   application wants to use non-ASCII characters in domain names, IDNA
-   is the only currently-defined option.  Adding IDNA support to an
-   existing application entails changes to the application only, and
-   leaves room for flexibility in the user interface.
-
-   A great deal of the discussion of IDN solutions has focused on
-   transition issues and how IDN will work in a world where not all of
-   the components have been updated.  Proposals that were not chosen by
-   the IDN Working Group would depend on user applications, resolvers,
-   and DNS servers being updated in order for a user to use an
-   internationalized domain name.  Rather than rely on widespread
-   updating of all components, IDNA depends on updates to user
-   applications only; no changes are needed to the DNS protocol or any
-   DNS servers or the resolvers on user's computers.
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 2]
-
-RFC 3490                          IDNA                        March 2003
-
-
-1.1 Problem Statement
-
-   The IDNA specification solves the problem of extending the repertoire
-   of characters that can be used in domain names to include the Unicode
-   repertoire (with some restrictions).
-
-   IDNA does not extend the service offered by DNS to the applications.
-   Instead, the applications (and, by implication, the users) continue
-   to see an exact-match lookup service.  Either there is a single
-   exactly-matching name or there is no match.  This model has served
-   the existing applications well, but it requires, with or without
-   internationalized domain names, that users know the exact spelling of
-   the domain names that the users type into applications such as web
-   browsers and mail user agents.  The introduction of the larger
-   repertoire of characters potentially makes the set of misspellings
-   larger, especially given that in some cases the same appearance, for
-   example on a business card, might visually match several Unicode code
-   points or several sequences of code points.
-
-   IDNA allows the graceful introduction of IDNs not only by avoiding
-   upgrades to existing infrastructure (such as DNS servers and mail
-   transport agents), but also by allowing some rudimentary use of IDNs
-   in applications by using the ASCII representation of the non-ASCII
-   name labels.  While such names are very user-unfriendly to read and
-   type, and hence are not suitable for user input, they allow (for
-   instance) replying to email and clicking on URLs even though the
-   domain name displayed is incomprehensible to the user.  In order to
-   allow user-friendly input and output of the IDNs, the applications
-   need to be modified to conform to this specification.
-
-   IDNA uses the Unicode character repertoire, which avoids the
-   significant delays that would be inherent in waiting for a different
-   and specific character set be defined for IDN purposes by some other
-   standards developing organization.
-
-1.2 Limitations of IDNA
-
-   The IDNA protocol does not solve all linguistic issues with users
-   inputting names in different scripts.  Many important language-based
-   and script-based mappings are not covered in IDNA and need to be
-   handled outside the protocol.  For example, names that are entered in
-   a mix of traditional and simplified Chinese characters will not be
-   mapped to a single canonical name.  Another example is Scandinavian
-   names that are entered with U+00F6 (LATIN SMALL LETTER O WITH
-   DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH
-   STROKE).
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 3]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   An example of an important issue that is not considered in detail in
-   IDNA is how to provide a high probability that a user who is entering
-   a domain name based on visual information (such as from a business
-   card or billboard) or aural information (such as from a telephone or
-   radio) would correctly enter the IDN.  Similar issues exist for ASCII
-   domain names, for example the possible visual confusion between the
-   letter 'O' and the digit zero, but the introduction of the larger
-   repertoire of characters creates more opportunities of similar
-   looking and similar sounding names.  Note that this is a complex
-   issue relating to languages, input methods on computers, and so on.
-   Furthermore, the kind of matching and searching necessary for a high
-   probability of success would not fit the role of the DNS and its
-   exact matching function.
-
-1.3 Brief overview for application developers
-
-   Applications can use IDNA to support internationalized domain names
-   anywhere that ASCII domain names are already supported, including DNS
-   master files and resolver interfaces.  (Applications can also define
-   protocols and interfaces that support IDNs directly using non-ASCII
-   representations.  IDNA does not prescribe any particular
-   representation for new protocols, but it still defines which names
-   are valid and how they are compared.)
-
-   The IDNA protocol is contained completely within applications.  It is
-   not a client-server or peer-to-peer protocol: everything is done
-   inside the application itself.  When used with a DNS resolver
-   library, IDNA is inserted as a "shim" between the application and the
-   resolver library.  When used for writing names into a DNS zone, IDNA
-   is used just before the name is committed to the zone.
-
-   There are two operations described in section 4 of this document:
-
-   -  The ToASCII operation is used before sending an IDN to something
-      that expects ASCII names (such as a resolver) or writing an IDN
-      into a place that expects ASCII names (such as a DNS master file).
-
-   -  The ToUnicode operation is used when displaying names to users,
-      for example names obtained from a DNS zone.
-
-   It is important to note that the ToASCII operation can fail.  If it
-   fails when processing a domain name, that domain name cannot be used
-   as an internationalized domain name and the application has to have
-   some method of dealing with this failure.
-
-   IDNA requires that implementations process input strings with
-   Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP],
-   and then with Punycode [PUNYCODE].  Implementations of IDNA MUST
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 4]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   fully implement Nameprep and Punycode; neither Nameprep nor Punycode
-   are optional.
-
-2. Terminology
-
-   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
-   and "MAY" in this document are to be interpreted as described in BCP
-   14, RFC 2119 [RFC2119].
-
-   A code point is an integer value associated with a character in a
-   coded character set.
-
-   Unicode [UNICODE] is a coded character set containing tens of
-   thousands of characters.  A single Unicode code point is denoted by
-   "U+" followed by four to six hexadecimal digits, while a range of
-   Unicode code points is denoted by two hexadecimal numbers separated
-   by "..", with no prefixes.
-
-   ASCII means US-ASCII [USASCII], a coded character set containing 128
-   characters associated with code points in the range 0..7F.  Unicode
-   is an extension of ASCII: it includes all the ASCII characters and
-   associates them with the same code points.
-
-   The term "LDH code points" is defined in this document to mean the
-   code points associated with ASCII letters, digits, and the hyphen-
-   minus; that is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an
-   abbreviation for "letters, digits, hyphen".
-
-   [STD13] talks about "domain names" and "host names", but many people
-   use the terms interchangeably.  Further, because [STD13] was not
-   terribly clear, many people who are sure they know the exact
-   definitions of each of these terms disagree on the definitions.  In
-   this document the term "domain name" is used in general.  This
-   document explicitly cites [STD3] whenever referring to the host name
-   syntax restrictions defined therein.
-
-   A label is an individual part of a domain name.  Labels are usually
-   shown separated by dots; for example, the domain name
-   "www.example.com" is composed of three labels: "www", "example", and
-   "com".  (The zero-length root label described in [STD13], which can
-   be explicit as in "www.example.com." or implicit as in
-   "www.example.com", is not considered a label in this specification.)
-   IDNA extends the set of usable characters in labels that are text.
-   For the rest of this document, the term "label" is shorthand for
-   "text label", and "every label" means "every text label".
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 5]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   An "internationalized label" is a label to which the ToASCII
-   operation (see section 4) can be applied without failing (with the
-   UseSTD3ASCIIRules flag unset).  This implies that every ASCII label
-   that satisfies the [STD13] length restriction is an internationalized
-   label.  Therefore the term "internationalized label" is a
-   generalization, embracing both old ASCII labels and new non-ASCII
-   labels.  Although most Unicode characters can appear in
-   internationalized labels, ToASCII will fail for some input strings,
-   and such strings are not valid internationalized labels.
-
-   An "internationalized domain name" (IDN) is a domain name in which
-   every label is an internationalized label.  This implies that every
-   ASCII domain name is an IDN (which implies that it is possible for a
-   name to be an IDN without it containing any non-ASCII characters).
-   This document does not attempt to define an "internationalized host
-   name".  Just as has been the case with ASCII names, some DNS zone
-   administrators may impose restrictions, beyond those imposed by DNS
-   or IDNA, on the characters or strings that may be registered as
-   labels in their zones.  Such restrictions have no impact on the
-   syntax or semantics of DNS protocol messages; a query for a name that
-   matches no records will yield the same response regardless of the
-   reason why it is not in the zone.  Clients issuing queries or
-   interpreting responses cannot be assumed to have any knowledge of
-   zone-specific restrictions or conventions.
-
-   In IDNA, equivalence of labels is defined in terms of the ToASCII
-   operation, which constructs an ASCII form for a given label, whether
-   or not the label was already an ASCII label.  Labels are defined to
-   be equivalent if and only if their ASCII forms produced by ToASCII
-   match using a case-insensitive ASCII comparison.  ASCII labels
-   already have a notion of equivalence: upper case and lower case are
-   considered equivalent.  The IDNA notion of equivalence is an
-   extension of that older notion.  Equivalent labels in IDNA are
-   treated as alternate forms of the same label, just as "foo" and "Foo"
-   are treated as alternate forms of the same label.
-
-   To allow internationalized labels to be handled by existing
-   applications, IDNA uses an "ACE label" (ACE stands for ASCII
-   Compatible Encoding).  An ACE label is an internationalized label
-   that can be rendered in ASCII and is equivalent to an
-   internationalized label that cannot be rendered in ASCII.  Given any
-   internationalized label that cannot be rendered in ASCII, the ToASCII
-   operation will convert it to an equivalent ACE label (whereas an
-   ASCII label will be left unaltered by ToASCII).  ACE labels are
-   unsuitable for display to users.  The ToUnicode operation will
-   convert any label to an equivalent non-ACE label.  In fact, an ACE
-   label is formally defined to be any label that the ToUnicode
-   operation would alter (whereas non-ACE labels are left unaltered by
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 6]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   ToUnicode).  Every ACE label begins with the ACE prefix specified in
-   section 5.  The ToASCII and ToUnicode operations are specified in
-   section 4.
-
-   The "ACE prefix" is defined in this document to be a string of ASCII
-   characters that appears at the beginning of every ACE label.  It is
-   specified in section 5.
-
-   A "domain name slot" is defined in this document to be a protocol
-   element or a function argument or a return value (and so on)
-   explicitly designated for carrying a domain name.  Examples of domain
-   name slots include: the QNAME field of a DNS query; the name argument
-   of the gethostbyname() library function; the part of an email address
-   following the at-sign (@) in the From: field of an email message
-   header; and the host portion of the URI in the src attribute of an
-   HTML <IMG> tag.  General text that just happens to contain a domain
-   name is not a domain name slot; for example, a domain name appearing
-   in the plain text body of an email message is not occupying a domain
-   name slot.
-
-   An "IDN-aware domain name slot" is defined in this document to be a
-   domain name slot explicitly designated for carrying an
-   internationalized domain name as defined in this document.  The
-   designation may be static (for example, in the specification of the
-   protocol or interface) or dynamic (for example, as a result of
-   negotiation in an interactive session).
-
-   An "IDN-unaware domain name slot" is defined in this document to be
-   any domain name slot that is not an IDN-aware domain name slot.
-   Obviously, this includes any domain name slot whose specification
-   predates IDNA.
-
-3. Requirements and applicability
-
-3.1 Requirements
-
-   IDNA conformance means adherence to the following four requirements:
-
-   1) Whenever dots are used as label separators, the following
-      characters MUST be recognized as dots: U+002E (full stop), U+3002
-      (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
-      (halfwidth ideographic full stop).
-
-   2) Whenever a domain name is put into an IDN-unaware domain name slot
-      (see section 2), it MUST contain only ASCII characters.  Given an
-      internationalized domain name (IDN), an equivalent domain name
-      satisfying this requirement can be obtained by applying the
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 7]
-
-RFC 3490                          IDNA                        March 2003
-
-
-      ToASCII operation (see section 4) to each label and, if dots are
-      used as label separators, changing all the label separators to
-      U+002E.
-
-   3) ACE labels obtained from domain name slots SHOULD be hidden from
-      users when it is known that the environment can handle the non-ACE
-      form, except when the ACE form is explicitly requested.  When it
-      is not known whether or not the environment can handle the non-ACE
-      form, the application MAY use the non-ACE form (which might fail,
-      such as by not being displayed properly), or it MAY use the ACE
-      form (which will look unintelligle to the user).  Given an
-      internationalized domain name, an equivalent domain name
-      containing no ACE labels can be obtained by applying the ToUnicode
-      operation (see section 4) to each label.  When requirements 2 and
-      3 both apply, requirement 2 takes precedence.
-
-   4) Whenever two labels are compared, they MUST be considered to match
-      if and only if they are equivalent, that is, their ASCII forms
-      (obtained by applying ToASCII) match using a case-insensitive
-      ASCII comparison.  Whenever two names are compared, they MUST be
-      considered to match if and only if their corresponding labels
-      match, regardless of whether the names use the same forms of label
-      separators.
-
-3.2 Applicability
-
-   IDNA is applicable to all domain names in all domain name slots
-   except where it is explicitly excluded.
-
-   This implies that IDNA is applicable to many protocols that predate
-   IDNA.  Note that IDNs occupying domain name slots in those protocols
-   MUST be in ASCII form (see section 3.1, requirement 2).
-
-3.2.1. DNS resource records
-
-   IDNA does not apply to domain names in the NAME and RDATA fields of
-   DNS resource records whose CLASS is not IN.  This exclusion applies
-   to every non-IN class, present and future, except where future
-   standards override this exclusion by explicitly inviting the use of
-   IDNA.
-
-   There are currently no other exclusions on the applicability of IDNA
-   to DNS resource records; it depends entirely on the CLASS, and not on
-   the TYPE.  This will remain true, even as new types are defined,
-   unless there is a compelling reason for a new type to complicate
-   matters by imposing type-specific rules.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 8]
-
-RFC 3490                          IDNA                        March 2003
-
-
-3.2.2. Non-domain-name data types stored in domain names
-
-   Although IDNA enables the representation of non-ASCII characters in
-   domain names, that does not imply that IDNA enables the
-   representation of non-ASCII characters in other data types that are
-   stored in domain names.  For example, an email address local part is
-   sometimes stored in a domain label (hostmaster@example.com would be
-   represented as hostmaster.example.com in the RDATA field of an SOA
-   record).  IDNA does not update the existing email standards, which
-   allow only ASCII characters in local parts.  Therefore, unless the
-   email standards are revised to invite the use of IDNA for local
-   parts, a domain label that holds the local part of an email address
-   SHOULD NOT begin with the ACE prefix, and even if it does, it is to
-   be interpreted literally as a local part that happens to begin with
-   the ACE prefix.
-
-4. Conversion operations
-
-   An application converts a domain name put into an IDN-unaware slot or
-   displayed to a user.  This section specifies the steps to perform in
-   the conversion, and the ToASCII and ToUnicode operations.
-
-   The input to ToASCII or ToUnicode is a single label that is a
-   sequence of Unicode code points (remember that all ASCII code points
-   are also Unicode code points).  If a domain name is represented using
-   a character set other than Unicode or US-ASCII, it will first need to
-   be transcoded to Unicode.
-
-   Starting from a whole domain name, the steps that an application
-   takes to do the conversions are:
-
-   1) Decide whether the domain name is a "stored string" or a "query
-      string" as described in [STRINGPREP].  If this conversion follows
-      the "queries" rule from [STRINGPREP], set the flag called
-      "AllowUnassigned".
-
-   2) Split the domain name into individual labels as described in
-      section 3.1.  The labels do not include the separator.
-
-   3) For each label, decide whether or not to enforce the restrictions
-      on ASCII characters in host names [STD3].  (Applications already
-      faced this choice before the introduction of IDNA, and can
-      continue to make the decision the same way they always have; IDNA
-      makes no new recommendations regarding this choice.)  If the
-      restrictions are to be enforced, set the flag called
-      "UseSTD3ASCIIRules" for that label.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 9]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   4) Process each label with either the ToASCII or the ToUnicode
-      operation as appropriate.  Typically, you use the ToASCII
-      operation if you are about to put the name into an IDN-unaware
-      slot, and you use the ToUnicode operation if you are displaying
-      the name to a user; section 3.1 gives greater detail on the
-      applicable requirements.
-
-   5) If ToASCII was applied in step 4 and dots are used as label
-      separators, change all the label separators to U+002E (full stop).
-
-   The following two subsections define the ToASCII and ToUnicode
-   operations that are used in step 4.
-
-   This description of the protocol uses specific procedure names, names
-   of flags, and so on, in order to facilitate the specification of the
-   protocol.  These names, as well as the actual steps of the
-   procedures, are not required of an implementation.  In fact, any
-   implementation which has the same external behavior as specified in
-   this document conforms to this specification.
-
-4.1 ToASCII
-
-   The ToASCII operation takes a sequence of Unicode code points that
-   make up one label and transforms it into a sequence of code points in
-   the ASCII range (0..7F).  If ToASCII succeeds, the original sequence
-   and the resulting sequence are equivalent labels.
-
-   It is important to note that the ToASCII operation can fail.  ToASCII
-   fails if any step of it fails.  If any step of the ToASCII operation
-   fails on any label in a domain name, that domain name MUST NOT be
-   used as an internationalized domain name.  The method for dealing
-   with this failure is application-specific.
-
-   The inputs to ToASCII are a sequence of code points, the
-   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
-   ToASCII is either a sequence of ASCII code points or a failure
-   condition.
-
-   ToASCII never alters a sequence of code points that are all in the
-   ASCII range to begin with (although it could fail).  Applying the
-   ToASCII operation multiple times has exactly the same effect as
-   applying it just once.
-
-   ToASCII consists of the following steps:
-
-   1. If the sequence contains any code points outside the ASCII range
-      (0..7F) then proceed to step 2, otherwise skip to step 3.
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 10]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   2. Perform the steps specified in [NAMEPREP] and fail if there is an
-      error.  The AllowUnassigned flag is used in [NAMEPREP].
-
-   3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
-
-     (a) Verify the absence of non-LDH ASCII code points; that is, the
-         absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
-
-     (b) Verify the absence of leading and trailing hyphen-minus; that
-         is, the absence of U+002D at the beginning and end of the
-         sequence.
-
-   4. If the sequence contains any code points outside the ASCII range
-      (0..7F) then proceed to step 5, otherwise skip to step 8.
-
-   5. Verify that the sequence does NOT begin with the ACE prefix.
-
-   6. Encode the sequence using the encoding algorithm in [PUNYCODE] and
-      fail if there is an error.
-
-   7. Prepend the ACE prefix.
-
-   8. Verify that the number of code points is in the range 1 to 63
-      inclusive.
-
-4.2 ToUnicode
-
-   The ToUnicode operation takes a sequence of Unicode code points that
-   make up one label and returns a sequence of Unicode code points.  If
-   the input sequence is a label in ACE form, then the result is an
-   equivalent internationalized label that is not in ACE form, otherwise
-   the original sequence is returned unaltered.
-
-   ToUnicode never fails.  If any step fails, then the original input
-   sequence is returned immediately in that step.
-
-   The ToUnicode output never contains more code points than its input.
-   Note that the number of octets needed to represent a sequence of code
-   points depends on the particular character encoding used.
-
-   The inputs to ToUnicode are a sequence of code points, the
-   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
-   ToUnicode is always a sequence of Unicode code points.
-
-   1. If all code points in the sequence are in the ASCII range (0..7F)
-      then skip to step 3.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 11]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   2. Perform the steps specified in [NAMEPREP] and fail if there is an
-      error.  (If step 3 of ToASCII is also performed here, it will not
-      affect the overall behavior of ToUnicode, but it is not
-      necessary.)  The AllowUnassigned flag is used in [NAMEPREP].
-
-   3. Verify that the sequence begins with the ACE prefix, and save a
-      copy of the sequence.
-
-   4. Remove the ACE prefix.
-
-   5. Decode the sequence using the decoding algorithm in [PUNYCODE] and
-      fail if there is an error.  Save a copy of the result of this
-      step.
-
-   6. Apply ToASCII.
-
-   7. Verify that the result of step 6 matches the saved copy from step
-      3, using a case-insensitive ASCII comparison.
-
-   8. Return the saved copy from step 5.
-
-5. ACE prefix
-
-   The ACE prefix, used in the conversion operations (section 4), is two
-   alphanumeric ASCII characters followed by two hyphen-minuses.  It
-   cannot be any of the prefixes already used in earlier documents,
-   which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--",
-   "ra--", "wq--" and "zq--".  The ToASCII and ToUnicode operations MUST
-   recognize the ACE prefix in a case-insensitive manner.
-
-   The ACE prefix for IDNA is "xn--" or any capitalization thereof.
-
-   This means that an ACE label might be "xn--de-jg4avhby1noc0d", where
-   "de-jg4avhby1noc0d" is the part of the ACE label that is generated by
-   the encoding steps in [PUNYCODE].
-
-   While all ACE labels begin with the ACE prefix, not all labels
-   beginning with the ACE prefix are necessarily ACE labels.  Non-ACE
-   labels that begin with the ACE prefix will confuse users and SHOULD
-   NOT be allowed in DNS zones.
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 12]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6. Implications for typical applications using DNS
-
-   In IDNA, applications perform the processing needed to input
-   internationalized domain names from users, display internationalized
-   domain names to users, and process the inputs and outputs from DNS
-   and other protocols that carry domain names.
-
-   The components and interfaces between them can be represented
-   pictorially as:
-
-                    +------+
-                    | User |
-                    +------+
-                       ^
-                       | Input and display: local interface methods
-                       | (pen, keyboard, glowing phosphorus, ...)
-   +-------------------|-------------------------------+
-   |                   v                               |
-   |          +-----------------------------+          |
-   |          |        Application          |          |
-   |          |   (ToASCII and ToUnicode    |          |
-   |          |      operations may be      |          |
-   |          |        called here)         |          |
-   |          +-----------------------------+          |
-   |                   ^        ^                      | End system
-   |                   |        |                      |
-   | Call to resolver: |        | Application-specific |
-   |              ACE  |        | protocol:            |
-   |                   v        | ACE unless the       |
-   |           +----------+     | protocol is updated  |
-   |           | Resolver |     | to handle other      |
-   |           +----------+     | encodings            |
-   |                 ^          |                      |
-   +-----------------|----------|----------------------+
-       DNS protocol: |          |
-                 ACE |          |
-                     v          v
-          +-------------+    +---------------------+
-          | DNS servers |    | Application servers |
-          +-------------+    +---------------------+
-
-   The box labeled "Application" is where the application splits a
-   domain name into labels, sets the appropriate flags, and performs the
-   ToASCII and ToUnicode operations.  This is described in section 4.
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 13]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6.1 Entry and display in applications
-
-   Applications can accept domain names using any character set or sets
-   desired by the application developer, and can display domain names in
-   any charset.  That is, the IDNA protocol does not affect the
-   interface between users and applications.
-
-   An IDNA-aware application can accept and display internationalized
-   domain names in two formats: the internationalized character set(s)
-   supported by the application, and as an ACE label.  ACE labels that
-   are displayed or input MUST always include the ACE prefix.
-   Applications MAY allow input and display of ACE labels, but are not
-   encouraged to do so except as an interface for special purposes,
-   possibly for debugging, or to cope with display limitations as
-   described in section 6.4..  ACE encoding is opaque and ugly, and
-   should thus only be exposed to users who absolutely need it.  Because
-   name labels encoded as ACE name labels can be rendered either as the
-   encoded ASCII characters or the proper decoded characters, the
-   application MAY have an option for the user to select the preferred
-   method of display; if it does, rendering the ACE SHOULD NOT be the
-   default.
-
-   Domain names are often stored and transported in many places.  For
-   example, they are part of documents such as mail messages and web
-   pages.  They are transported in many parts of many protocols, such as
-   both the control commands and the RFC 2822 body parts of SMTP, and
-   the headers and the body content in HTTP.  It is important to
-   remember that domain names appear both in domain name slots and in
-   the content that is passed over protocols.
-
-   In protocols and document formats that define how to handle
-   specification or negotiation of charsets, labels can be encoded in
-   any charset allowed by the protocol or document format.  If a
-   protocol or document format only allows one charset, the labels MUST
-   be given in that charset.
-
-   In any place where a protocol or document format allows transmission
-   of the characters in internationalized labels, internationalized
-   labels SHOULD be transmitted using whatever character encoding and
-   escape mechanism that the protocol or document format uses at that
-   place.
-
-   All protocols that use domain name slots already have the capacity
-   for handling domain names in the ASCII charset.  Thus, ACE labels
-   (internationalized labels that have been processed with the ToASCII
-   operation) can inherently be handled by those protocols.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 14]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6.2 Applications and resolver libraries
-
-   Applications normally use functions in the operating system when they
-   resolve DNS queries.  Those functions in the operating system are
-   often called "the resolver library", and the applications communicate
-   with the resolver libraries through a programming interface (API).
-
-   Because these resolver libraries today expect only domain names in
-   ASCII, applications MUST prepare labels that are passed to the
-   resolver library using the ToASCII operation.  Labels received from
-   the resolver library contain only ASCII characters; internationalized
-   labels that cannot be represented directly in ASCII use the ACE form.
-   ACE labels always include the ACE prefix.
-
-   An operating system might have a set of libraries for performing the
-   ToASCII operation.  The input to such a library might be in one or
-   more charsets that are used in applications (UTF-8 and UTF-16 are
-   likely candidates for almost any operating system, and script-
-   specific charsets are likely for localized operating systems).
-
-   IDNA-aware applications MUST be able to work with both non-
-   internationalized labels (those that conform to [STD13] and [STD3])
-   and internationalized labels.
-
-   It is expected that new versions of the resolver libraries in the
-   future will be able to accept domain names in other charsets than
-   ASCII, and application developers might one day pass not only domain
-   names in Unicode, but also in local script to a new API for the
-   resolver libraries in the operating system.  Thus the ToASCII and
-   ToUnicode operations might be performed inside these new versions of
-   the resolver libraries.
-
-   Domain names passed to resolvers or put into the question section of
-   DNS requests follow the rules for "queries" from [STRINGPREP].
-
-6.3 DNS servers
-
-   Domain names stored in zones follow the rules for "stored strings"
-   from [STRINGPREP].
-
-   For internationalized labels that cannot be represented directly in
-   ASCII, DNS servers MUST use the ACE form produced by the ToASCII
-   operation.  All IDNs served by DNS servers MUST contain only ASCII
-   characters.
-
-   If a signaling system which makes negotiation possible between old
-   and new DNS clients and servers is standardized in the future, the
-   encoding of the query in the DNS protocol itself can be changed from
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 15]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   ACE to something else, such as UTF-8.  The question whether or not
-   this should be used is, however, a separate problem and is not
-   discussed in this memo.
-
-6.4 Avoiding exposing users to the raw ACE encoding
-
-   Any application that might show the user a domain name obtained from
-   a domain name slot, such as from gethostbyaddr or part of a mail
-   header, will need to be updated if it is to prevent users from seeing
-   the ACE.
-
-   If an application decodes an ACE name using ToUnicode but cannot show
-   all of the characters in the decoded name, such as if the name
-   contains characters that the output system cannot display, the
-   application SHOULD show the name in ACE format (which always includes
-   the ACE prefix) instead of displaying the name with the replacement
-   character (U+FFFD).  This is to make it easier for the user to
-   transfer the name correctly to other programs.  Programs that by
-   default show the ACE form when they cannot show all the characters in
-   a name label SHOULD also have a mechanism to show the name that is
-   produced by the ToUnicode operation with as many characters as
-   possible and replacement characters in the positions where characters
-   cannot be displayed.
-
-   The ToUnicode operation does not alter labels that are not valid ACE
-   labels, even if they begin with the ACE prefix.  After ToUnicode has
-   been applied, if a label still begins with the ACE prefix, then it is
-   not a valid ACE label, and is not equivalent to any of the
-   intermediate Unicode strings constructed by ToUnicode.
-
-6.5  DNSSEC authentication of IDN domain names
-
-   DNS Security [RFC2535] is a method for supplying cryptographic
-   verification information along with DNS messages.  Public Key
-   Cryptography is used in conjunction with digital signatures to
-   provide a means for a requester of domain information to authenticate
-   the source of the data.  This ensures that it can be traced back to a
-   trusted source, either directly, or via a chain of trust linking the
-   source of the information to the top of the DNS hierarchy.
-
-   IDNA specifies that all internationalized domain names served by DNS
-   servers that cannot be represented directly in ASCII must use the ACE
-   form produced by the ToASCII operation.  This operation must be
-   performed prior to a zone being signed by the private key for that
-   zone.  Because of this ordering, it is important to recognize that
-   DNSSEC authenticates the ASCII domain name, not the Unicode form or
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 16]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   the mapping between the Unicode form and the ASCII form.  In the
-   presence of DNSSEC, this is the name that MUST be signed in the zone
-   and MUST be validated against.
-
-   One consequence of this for sites deploying IDNA in the presence of
-   DNSSEC is that any special purpose proxies or forwarders used to
-   transform user input into IDNs must be earlier in the resolution flow
-   than DNSSEC authenticating nameservers for DNSSEC to work.
-
-7. Name server considerations
-
-   Existing DNS servers do not know the IDNA rules for handling non-
-   ASCII forms of IDNs, and therefore need to be shielded from them.
-   All existing channels through which names can enter a DNS server
-   database (for example, master files [STD13] and DNS update messages
-   [RFC2136]) are IDN-unaware because they predate IDNA, and therefore
-   requirement 2 of section 3.1 of this document provides the needed
-   shielding, by ensuring that internationalized domain names entering
-   DNS server databases through such channels have already been
-   converted to their equivalent ASCII forms.
-
-   It is imperative that there be only one ASCII encoding for a
-   particular domain name.  Because of the design of the ToASCII and
-   ToUnicode operations, there are no ACE labels that decode to ASCII
-   labels, and therefore name servers cannot contain multiple ASCII
-   encodings of the same domain name.
-
-   [RFC2181] explicitly allows domain labels to contain octets beyond
-   the ASCII range (0..7F), and this document does not change that.
-   Note, however, that there is no defined interpretation of octets
-   80..FF as characters.  If labels containing these octets are returned
-   to applications, unpredictable behavior could result.  The ASCII form
-   defined by ToASCII is the only standard representation for
-   internationalized labels in the current DNS protocol.
-
-8. Root server considerations
-
-   IDNs are likely to be somewhat longer than current domain names, so
-   the bandwidth needed by the root servers is likely to go up by a
-   small amount.  Also, queries and responses for IDNs will probably be
-   somewhat longer than typical queries today, so more queries and
-   responses may be forced to go to TCP instead of UDP.
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 17]
-
-RFC 3490                          IDNA                        March 2003
-
-
-9. References
-
-9.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [NAMEPREP]   Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
-                Profile for Internationalized Domain Names (IDN)", RFC
-                3491, March 2003.
-
-   [PUNYCODE]   Costello, A., "Punycode: A Bootstring encoding of
-                Unicode for use with Internationalized Domain Names in
-                Applications (IDNA)", RFC 3492, March 2003.
-
-   [STD3]       Braden, R., "Requirements for Internet Hosts --
-                Communication Layers", STD 3, RFC 1122, and
-                "Requirements for Internet Hosts -- Application and
-                Support", STD 3, RFC 1123, October 1989.
-
-   [STD13]      Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034 and "Domain names -
-                implementation and specification", STD 13, RFC 1035,
-                November 1987.
-
-9.2 Informative References
-
-   [RFC2535]    Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RFC2181]    Elz, R. and R. Bush, "Clarifications to the DNS
-                Specification", RFC 2181, July 1997.
-
-   [UAX9]       Unicode Standard Annex #9, The Bidirectional Algorithm,
-                <http://www.unicode.org/unicode/reports/tr9/>.
-
-   [UNICODE]    The Unicode Consortium. The Unicode Standard, Version
-                3.2.0 is defined by The Unicode Standard, Version 3.0
-                (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
-                as amended by the Unicode Standard Annex #27: Unicode
-                3.1 (http://www.unicode.org/reports/tr27/) and by the
-                Unicode Standard Annex #28: Unicode 3.2
-                (http://www.unicode.org/reports/tr28/).
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 18]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   [USASCII]    Cerf, V., "ASCII format for Network Interchange", RFC
-                20, October 1969.
-
-10. Security Considerations
-
-   Security on the Internet partly relies on the DNS.  Thus, any change
-   to the characteristics of the DNS can change the security of much of
-   the Internet.
-
-   This memo describes an algorithm which encodes characters that are
-   not valid according to STD3 and STD13 into octet values that are
-   valid.  No security issues such as string length increases or new
-   allowed values are introduced by the encoding process or the use of
-   these encoded values, apart from those introduced by the ACE encoding
-   itself.
-
-   Domain names are used by users to identify and connect to Internet
-   servers.  The security of the Internet is compromised if a user
-   entering a single internationalized name is connected to different
-   servers based on different interpretations of the internationalized
-   domain name.
-
-   When systems use local character sets other than ASCII and Unicode,
-   this specification leaves the the problem of transcoding between the
-   local character set and Unicode up to the application.  If different
-   applications (or different versions of one application) implement
-   different transcoding rules, they could interpret the same name
-   differently and contact different servers.  This problem is not
-   solved by security protocols like TLS that do not take local
-   character sets into account.
-
-   Because this document normatively refers to [NAMEPREP], [PUNYCODE],
-   and [STRINGPREP], it includes the security considerations from those
-   documents as well.
-
-   If or when this specification is updated to use a more recent Unicode
-   normalization table, the new normalization table will need to be
-   compared with the old to spot backwards incompatible changes.  If
-   there are such changes, they will need to be handled somehow, or
-   there will be security as well as operational implications.  Methods
-   to handle the conflicts could include keeping the old normalization,
-   or taking care of the conflicting characters by operational means, or
-   some other method.
-
-   Implementations MUST NOT use more recent normalization tables than
-   the one referenced from this document, even though more recent tables
-   may be provided by operating systems.  If an application is unsure of
-   which version of the normalization tables are in the operating
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 19]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   system, the application needs to include the normalization tables
-   itself.  Using normalization tables other than the one referenced
-   from this specification could have security and operational
-   implications.
-
-   To help prevent confusion between characters that are visually
-   similar, it is suggested that implementations provide visual
-   indications where a domain name contains multiple scripts.  Such
-   mechanisms can also be used to show when a name contains a mixture of
-   simplified and traditional Chinese characters, or to distinguish zero
-   and one from O and l.  DNS zone adminstrators may impose restrictions
-   (subject to the limitations in section 2) that try to minimize
-   homographs.
-
-   Domain names (or portions of them) are sometimes compared against a
-   set of privileged or anti-privileged domains.  In such situations it
-   is especially important that the comparisons be done properly, as
-   specified in section 3.1 requirement 4.  For labels already in ASCII
-   form, the proper comparison reduces to the same case-insensitive
-   ASCII comparison that has always been used for ASCII labels.
-
-   The introduction of IDNA means that any existing labels that start
-   with the ACE prefix and would be altered by ToUnicode will
-   automatically be ACE labels, and will be considered equivalent to
-   non-ASCII labels, whether or not that was the intent of the zone
-   adminstrator or registrant.
-
-11. IANA Considerations
-
-   IANA has assigned the ACE prefix in consultation with the IESG.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 20]
-
-RFC 3490                          IDNA                        March 2003
-
-
-12. Authors' Addresses
-
-   Patrik Faltstrom
-   Cisco Systems
-   Arstaangsvagen 31 J
-   S-117 43 Stockholm  Sweden
-
-   EMail: paf@cisco.com
-
-
-   Paul Hoffman
-   Internet Mail Consortium and VPN Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060  USA
-
-   EMail: phoffman@imc.org
-
-
-   Adam M. Costello
-   University of California, Berkeley
-
-   URL: http://www.nicemice.net/amc/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 21]
-
-RFC 3490                          IDNA                        March 2003
-
-
-13. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 22]
-
diff --git a/doc/rfc/rfc3491.txt b/doc/rfc/rfc3491.txt
deleted file mode 100644
index dbc86c7f..00000000
--- a/doc/rfc/rfc3491.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         P. Hoffman
-Request for Comments: 3491                                    IMC & VPNC
-Category: Standards Track                                    M. Blanchet
-                                                                Viagenie
-                                                              March 2003
-
-
-                   Nameprep: A Stringprep Profile for
-                  Internationalized Domain Names (IDN)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document describes how to prepare internationalized domain name
-   (IDN) labels in order to increase the likelihood that name input and
-   name comparison work in ways that make sense for typical users
-   throughout the world.  This profile of the stringprep protocol is
-   used as part of a suite of on-the-wire protocols for
-   internationalizing the Domain Name System (DNS).
-
-1. Introduction
-
-   This document specifies processing rules that will allow users to
-   enter internationalized domain names (IDNs) into applications and
-   have the highest chance of getting the content of the strings
-   correct.  It is a profile of stringprep [STRINGPREP].  These
-   processing rules are only intended for internationalized domain
-   names, not for arbitrary text.
-
-   This profile defines the following, as required by [STRINGPREP].
-
-   -  The intended applicability of the profile: internationalized
-      domain names processed by IDNA.
-
-   -  The character repertoire that is the input and output to
-      stringprep:  Unicode 3.2, specified in section 2.
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 1]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-   -  The mappings used: specified in section 3.
-
-   -  The Unicode normalization used: specified in section 4.
-
-   -  The characters that are prohibited as output: specified in section
-      5.
-
-   -  Bidirectional character handling: specified in section 6.
-
-1.1 Interaction of protocol parts
-
-   Nameprep is used by the IDNA [IDNA] protocol for preparing domain
-   names; it is not designed for any other purpose.  It is explicitly
-   not designed for processing arbitrary free text and SHOULD NOT be
-   used for that purpose.  Nameprep is a profile of Stringprep
-   [STRINGPREP].  Implementations of Nameprep MUST fully implement
-   Stringprep.
-
-   Nameprep is used to process domain name labels, not domain names.
-   IDNA calls nameprep for each label in a domain name, not for the
-   whole domain name.
-
-1.2 Terminology
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
-   in this document are to be interpreted as described in BCP 14, RFC
-   2119 [RFC2119].
-
-2. Character Repertoire
-
-   This profile uses Unicode 3.2, as defined in [STRINGPREP] Appendix A.
-
-3. Mapping
-
-   This profile specifies mapping using the following tables from
-   [STRINGPREP]:
-
-   Table B.1
-   Table B.2
-
-4. Normalization
-
-   This profile specifies using Unicode normalization form KC, as
-   described in [STRINGPREP].
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 2]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-5. Prohibited Output
-
-   This profile specifies prohibiting using the following tables from
-   [STRINGPREP]:
-
-   Table C.1.2
-   Table C.2.2
-   Table C.3
-   Table C.4
-   Table C.5
-   Table C.6
-   Table C.7
-   Table C.8
-   Table C.9
-
-   IMPORTANT NOTE: This profile MUST be used with the IDNA protocol.
-   The IDNA protocol has additional prohibitions that are checked
-   outside of this profile.
-
-6. Bidirectional characters
-
-   This profile specifies checking bidirectional strings as described in
-   [STRINGPREP] section 6.
-
-7. Unassigned Code Points in Internationalized Domain Names
-
-   If the processing in [IDNA] specifies that a list of unassigned code
-   points be used, the system uses table A.1 from [STRINGPREP] as its
-   list of unassigned code points.
-
-8. References
-
-8.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [IDNA]       Faltstrom, P., Hoffman, P. and A. Costello,
-                "Internationalizing Domain Names in Applications
-                (IDNA)", RFC 3490, March 2003.
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 3]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-8.2 Informative references
-
-   [STD13]      Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034, and "Domain names -
-                implementation and specification", STD 13, RFC 1035,
-                November 1987.
-
-9. Security Considerations
-
-   The Unicode and ISO/IEC 10646 repertoires have many characters that
-   look similar.  In many cases, users of security protocols might do
-   visual matching, such as when comparing the names of trusted third
-   parties.  Because it is impossible to map similar-looking characters
-   without a great deal of context such as knowing the fonts used,
-   stringprep does nothing to map similar-looking characters together
-   nor to prohibit some characters because they look like others.
-
-   Security on the Internet partly relies on the DNS.  Thus, any change
-   to the characteristics of the DNS can change the security of much of
-   the Internet.
-
-   Domain names are used by users to connect to Internet servers.  The
-   security of the Internet would be compromised if a user entering a
-   single internationalized name could be connected to different servers
-   based on different interpretations of the internationalized domain
-   name.
-
-   Current applications might assume that the characters allowed in
-   domain names will always be the same as they are in [STD13].  This
-   document vastly increases the number of characters available in
-   domain names.  Every program that uses "special" characters in
-   conjunction with domain names may be vulnerable to attack based on
-   the new characters allowed by this specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 4]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-10. IANA Considerations
-
-   This is a profile of stringprep.  It has been registered by the IANA
-   in the stringprep profile registry
-   (www.iana.org/assignments/stringprep-profiles).
-
-      Name of this profile:
-         Nameprep
-
-      RFC in which the profile is defined:
-         This document.
-
-      Indicator whether or not this is the newest version of the
-      profile:
-         This is the first version of Nameprep.
-
-11. Acknowledgements
-
-   Many people from the IETF IDN Working Group and the Unicode Technical
-   Committee contributed ideas that went into this document.
-
-   The IDN Nameprep design team made many useful changes to the
-   document.  That team and its advisors include:
-
-      Asmus Freytag
-      Cathy Wissink
-      Francois Yergeau
-      James Seng
-      Marc Blanchet
-      Mark Davis
-      Martin Duerst
-      Patrik Faltstrom
-      Paul Hoffman
-
-   Additional significant improvements were proposed by:
-
-      Jonathan Rosenne
-      Kent Karlsson
-      Scott Hollenbeck
-      Dave Crocker
-      Erik Nordmark
-      Matitiahu Allouche
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 5]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-12. Authors' Addresses
-
-   Paul Hoffman
-   Internet Mail Consortium and VPN Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060 USA
-
-   EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org
-
-
-   Marc Blanchet
-   Viagenie inc.
-   2875 boul. Laurier, bur. 300
-   Ste-Foy, Quebec, Canada, G1V 2M2
-
-   EMail: Marc.Blanchet@viagenie.qc.ca
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 6]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-13.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 7]
-
diff --git a/doc/rfc/rfc3492.txt b/doc/rfc/rfc3492.txt
deleted file mode 100644
index e72ad81a..00000000
--- a/doc/rfc/rfc3492.txt
+++ /dev/null
@@ -1,1963 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        A. Costello
-Request for Comments: 3492                 Univ. of California, Berkeley
-Category: Standards Track                                     March 2003
-
-
-              Punycode: A Bootstring encoding of Unicode
-       for Internationalized Domain Names in Applications (IDNA)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   Punycode is a simple and efficient transfer encoding syntax designed
-   for use with Internationalized Domain Names in Applications (IDNA).
-   It uniquely and reversibly transforms a Unicode string into an ASCII
-   string.  ASCII characters in the Unicode string are represented
-   literally, and non-ASCII characters are represented by ASCII
-   characters that are allowed in host name labels (letters, digits, and
-   hyphens).  This document defines a general algorithm called
-   Bootstring that allows a string of basic code points to uniquely
-   represent any string of code points drawn from a larger set.
-   Punycode is an instance of Bootstring that uses particular parameter
-   values specified by this document, appropriate for IDNA.
-
-Table of Contents
-
-   1. Introduction...............................................2
-       1.1 Features..............................................2
-       1.2 Interaction of protocol parts.........................3
-   2. Terminology................................................3
-   3. Bootstring description.....................................4
-       3.1 Basic code point segregation..........................4
-       3.2 Insertion unsort coding...............................4
-       3.3 Generalized variable-length integers..................5
-       3.4 Bias adaptation.......................................7
-   4. Bootstring parameters......................................8
-   5. Parameter values for Punycode..............................8
-   6. Bootstring algorithms......................................9
-
-
-
-Costello                    Standards Track                     [Page 1]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-       6.1 Bias adaptation function.............................10
-       6.2 Decoding procedure...................................11
-       6.3 Encoding procedure...................................12
-       6.4 Overflow handling....................................13
-   7. Punycode examples.........................................14
-       7.1 Sample strings.......................................14
-       7.2 Decoding traces......................................17
-       7.3 Encoding traces......................................19
-   8. Security Considerations...................................20
-   9. References................................................21
-       9.1 Normative References.................................21
-       9.2 Informative References...............................21
-   A. Mixed-case annotation.....................................22
-   B. Disclaimer and license....................................22
-   C. Punycode sample implementation............................23
-   Author's Address.............................................34
-   Full Copyright Statement.....................................35
-
-1. Introduction
-
-   [IDNA] describes an architecture for supporting internationalized
-   domain names.  Labels containing non-ASCII characters can be
-   represented by ACE labels, which begin with a special ACE prefix and
-   contain only ASCII characters.  The remainder of the label after the
-   prefix is a Punycode encoding of a Unicode string satisfying certain
-   constraints.  For the details of the prefix and constraints, see
-   [IDNA] and [NAMEPREP].
-
-   Punycode is an instance of a more general algorithm called
-   Bootstring, which allows strings composed from a small set of "basic"
-   code points to uniquely represent any string of code points drawn
-   from a larger set.  Punycode is Bootstring with particular parameter
-   values appropriate for IDNA.
-
-1.1 Features
-
-   Bootstring has been designed to have the following features:
-
-   *  Completeness:  Every extended string (sequence of arbitrary code
-      points) can be represented by a basic string (sequence of basic
-      code points).  Restrictions on what strings are allowed, and on
-      length, can be imposed by higher layers.
-
-   *  Uniqueness:  There is at most one basic string that represents a
-      given extended string.
-
-   *  Reversibility:  Any extended string mapped to a basic string can
-      be recovered from that basic string.
-
-
-
-Costello                    Standards Track                     [Page 2]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   *  Efficient encoding:  The ratio of basic string length to extended
-      string length is small.  This is important in the context of
-      domain names because RFC 1034 [RFC1034] restricts the length of a
-      domain label to 63 characters.
-
-   *  Simplicity:  The encoding and decoding algorithms are reasonably
-      simple to implement.  The goals of efficiency and simplicity are
-      at odds; Bootstring aims at a good balance between them.
-
-   *  Readability:  Basic code points appearing in the extended string
-      are represented as themselves in the basic string (although the
-      main purpose is to improve efficiency, not readability).
-
-   Punycode can also support an additional feature that is not used by
-   the ToASCII and ToUnicode operations of [IDNA].  When extended
-   strings are case-folded prior to encoding, the basic string can use
-   mixed case to tell how to convert the folded string into a mixed-case
-   string.  See appendix A "Mixed-case annotation".
-
-1.2 Interaction of protocol parts
-
-   Punycode is used by the IDNA protocol [IDNA] for converting domain
-   labels into ASCII; it is not designed for any other purpose.  It is
-   explicitly not designed for processing arbitrary free text.
-
-2. Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14, RFC 2119
-   [RFC2119].
-
-   A code point is an integral value associated with a character in a
-   coded character set.
-
-   As in the Unicode Standard [UNICODE], Unicode code points are denoted
-   by "U+" followed by four to six hexadecimal digits, while a range of
-   code points is denoted by two hexadecimal numbers separated by "..",
-   with no prefixes.
-
-   The operators div and mod perform integer division; (x div y) is the
-   quotient of x divided by y, discarding the remainder, and (x mod y)
-   is the remainder, so (x div y) * y + (x mod y) == x.  Bootstring uses
-   these operators only with nonnegative operands, so the quotient and
-   remainder are always nonnegative.
-
-   The break statement jumps out of the innermost loop (as in C).
-
-
-
-
-Costello                    Standards Track                     [Page 3]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   An overflow is an attempt to compute a value that exceeds the maximum
-   value of an integer variable.
-
-3. Bootstring description
-
-   Bootstring represents an arbitrary sequence of code points (the
-   "extended string") as a sequence of basic code points (the "basic
-   string").  This section describes the representation.  Section 6
-   "Bootstring algorithms" presents the algorithms as pseudocode.
-   Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the
-   algorithms for sample inputs.
-
-   The following sections describe the four techniques used in
-   Bootstring.  "Basic code point segregation" is a very simple and
-   efficient encoding for basic code points occurring in the extended
-   string: they are simply copied all at once.  "Insertion unsort
-   coding" encodes the non-basic code points as deltas, and processes
-   the code points in numerical order rather than in order of
-   appearance, which typically results in smaller deltas.  The deltas
-   are represented as "generalized variable-length integers", which use
-   basic code points to represent nonnegative integers.  The parameters
-   of this integer representation are dynamically adjusted using "bias
-   adaptation", to improve efficiency when consecutive deltas have
-   similar magnitudes.
-
-3.1 Basic code point segregation
-
-   All basic code points appearing in the extended string are
-   represented literally at the beginning of the basic string, in their
-   original order, followed by a delimiter if (and only if) the number
-   of basic code points is nonzero.  The delimiter is a particular basic
-   code point, which never appears in the remainder of the basic string.
-   The decoder can therefore find the end of the literal portion (if
-   there is one) by scanning for the last delimiter.
-
-3.2 Insertion unsort coding
-
-   The remainder of the basic string (after the last delimiter if there
-   is one) represents a sequence of nonnegative integral deltas as
-   generalized variable-length integers, described in section 3.3.  The
-   meaning of the deltas is best understood in terms of the decoder.
-
-   The decoder builds the extended string incrementally.  Initially, the
-   extended string is a copy of the literal portion of the basic string
-   (excluding the last delimiter).  The decoder inserts non-basic code
-   points, one for each delta, into the extended string, ultimately
-   arriving at the final decoded string.
-
-
-
-
-Costello                    Standards Track                     [Page 4]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   At the heart of this process is a state machine with two state
-   variables: an index i and a counter n.  The index i refers to a
-   position in the extended string; it ranges from 0 (the first
-   position) to the current length of the extended string (which refers
-   to a potential position beyond the current end).  If the current
-   state is <n,i>, the next state is <n,i+1> if i is less than the
-   length of the extended string, or <n+1,0> if i equals the length of
-   the extended string.  In other words, each state change causes i to
-   increment, wrapping around to zero if necessary, and n counts the
-   number of wrap-arounds.
-
-   Notice that the state always advances monotonically (there is no way
-   for the decoder to return to an earlier state).  At each state, an
-   insertion is either performed or not performed.  At most one
-   insertion is performed in a given state.  An insertion inserts the
-   value of n at position i in the extended string.  The deltas are a
-   run-length encoding of this sequence of events: they are the lengths
-   of the runs of non-insertion states preceeding the insertion states.
-   Hence, for each delta, the decoder performs delta state changes, then
-   an insertion, and then one more state change.  (An implementation
-   need not perform each state change individually, but can instead use
-   division and remainder calculations to compute the next insertion
-   state directly.)  It is an error if the inserted code point is a
-   basic code point (because basic code points were supposed to be
-   segregated as described in section 3.1).
-
-   The encoder's main task is to derive the sequence of deltas that will
-   cause the decoder to construct the desired string.  It can do this by
-   repeatedly scanning the extended string for the next code point that
-   the decoder would need to insert, and counting the number of state
-   changes the decoder would need to perform, mindful of the fact that
-   the decoder's extended string will include only those code points
-   that have already been inserted.  Section 6.3 "Encoding procedure"
-   gives a precise algorithm.
-
-3.3 Generalized variable-length integers
-
-   In a conventional integer representation the base is the number of
-   distinct symbols for digits, whose values are 0 through base-1.  Let
-   digit_0 denote the least significant digit, digit_1 the next least
-   significant, and so on.  The value represented is the sum over j of
-   digit_j * w(j), where w(j) = base^j is the weight (scale factor) for
-   position j.  For example, in the base 8 integer 437, the digits are
-   7, 3, and 4, and the weights are 1, 8, and 64, so the value is 7 +
-   3*8 + 4*64 = 287.  This representation has two disadvantages:  First,
-   there are multiple encodings of each value (because there can be
-   extra zeros in the most significant positions), which is inconvenient
-
-
-
-
-Costello                    Standards Track                     [Page 5]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   when unique encodings are needed.  Second, the integer is not self-
-   delimiting, so if multiple integers are concatenated the boundaries
-   between them are lost.
-
-   The generalized variable-length representation solves these two
-   problems.  The digit values are still 0 through base-1, but now the
-   integer is self-delimiting by means of thresholds t(j), each of which
-   is in the range 0 through base-1.  Exactly one digit, the most
-   significant, satisfies digit_j < t(j).  Therefore, if several
-   integers are concatenated, it is easy to separate them, starting with
-   the first if they are little-endian (least significant digit first),
-   or starting with the last if they are big-endian (most significant
-   digit first).  As before, the value is the sum over j of digit_j *
-   w(j), but the weights are different:
-
-      w(0) = 1
-      w(j) = w(j-1) * (base - t(j-1)) for j > 0
-
-   For example, consider the little-endian sequence of base 8 digits
-   734251...  Suppose the thresholds are 2, 3, 5, 5, 5, 5...  This
-   implies that the weights are 1, 1*(8-2) = 6, 6*(8-3) = 30, 30*(8-5) =
-   90, 90*(8-5) = 270, and so on.  7 is not less than 2, and 3 is not
-   less than 3, but 4 is less than 5, so 4 is the last digit.  The value
-   of 734 is 7*1 + 3*6 + 4*30 = 145.  The next integer is 251, with
-   value 2*1 + 5*6 + 1*30 = 62.  Decoding this representation is very
-   similar to decoding a conventional integer:  Start with a current
-   value of N = 0 and a weight w = 1.  Fetch the next digit d and
-   increase N by d * w.  If d is less than the current threshold (t)
-   then stop, otherwise increase w by a factor of (base - t), update t
-   for the next position, and repeat.
-
-   Encoding this representation is similar to encoding a conventional
-   integer:  If N < t then output one digit for N and stop, otherwise
-   output the digit for t + ((N - t) mod (base - t)), then replace N
-   with (N - t) div (base - t), update t for the next position, and
-   repeat.
-
-   For any particular set of values of t(j), there is exactly one
-   generalized variable-length representation of each nonnegative
-   integral value.
-
-   Bootstring uses little-endian ordering so that the deltas can be
-   separated starting with the first.  The t(j) values are defined in
-   terms of the constants base, tmin, and tmax, and a state variable
-   called bias:
-
-      t(j) = base * (j + 1) - bias,
-      clamped to the range tmin through tmax
-
-
-
-Costello                    Standards Track                     [Page 6]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   The clamping means that if the formula yields a value less than tmin
-   or greater than tmax, then t(j) = tmin or tmax, respectively.  (In
-   the pseudocode in section 6 "Bootstring algorithms", the expression
-   base * (j + 1) is denoted by k for performance reasons.)  These t(j)
-   values cause the representation to favor integers within a particular
-   range determined by the bias.
-
-3.4 Bias adaptation
-
-   After each delta is encoded or decoded, bias is set for the next
-   delta as follows:
-
-   1. Delta is scaled in order to avoid overflow in the next step:
-
-         let delta = delta div 2
-
-      But when this is the very first delta, the divisor is not 2, but
-      instead a constant called damp.  This compensates for the fact
-      that the second delta is usually much smaller than the first.
-
-   2. Delta is increased to compensate for the fact that the next delta
-      will be inserting into a longer string:
-
-         let delta = delta + (delta div numpoints)
-
-      numpoints is the total number of code points encoded/decoded so
-      far (including the one corresponding to this delta itself, and
-      including the basic code points).
-
-   3. Delta is repeatedly divided until it falls within a threshold, to
-      predict the minimum number of digits needed to represent the next
-      delta:
-
-         while delta > ((base - tmin) * tmax) div 2
-         do let delta = delta div (base - tmin)
-
-   4. The bias is set:
-
-         let bias =
-           (base * the number of divisions performed in step 3) +
-           (((base - tmin + 1) * delta) div (delta + skew))
-
-      The motivation for this procedure is that the current delta
-      provides a hint about the likely size of the next delta, and so
-      t(j) is set to tmax for the more significant digits starting with
-      the one expected to be last, tmin for the less significant digits
-      up through the one expected to be third-last, and somewhere
-      between tmin and tmax for the digit expected to be second-last
-
-
-
-Costello                    Standards Track                     [Page 7]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-      (balancing the hope of the expected-last digit being unnecessary
-      against the danger of it being insufficient).
-
-4. Bootstring parameters
-
-   Given a set of basic code points, one needs to be designated as the
-   delimiter.  The base cannot be greater than the number of
-   distinguishable basic code points remaining.  The digit-values in the
-   range 0 through base-1 need to be associated with distinct non-
-   delimiter basic code points.  In some cases multiple code points need
-   to have the same digit-value; for example, uppercase and lowercase
-   versions of the same letter need to be equivalent if basic strings
-   are case-insensitive.
-
-   The initial value of n cannot be greater than the minimum non-basic
-   code point that could appear in extended strings.
-
-   The remaining five parameters (tmin, tmax, skew, damp, and the
-   initial value of bias) need to satisfy the following constraints:
-
-      0 <= tmin <= tmax <= base-1
-      skew >= 1
-      damp >= 2
-      initial_bias mod base <= base - tmin
-
-   Provided the constraints are satisfied, these five parameters affect
-   efficiency but not correctness.  They are best chosen empirically.
-
-   If support for mixed-case annotation is desired (see appendix A),
-   make sure that the code points corresponding to 0 through tmax-1 all
-   have both uppercase and lowercase forms.
-
-5. Parameter values for Punycode
-
-   Punycode uses the following Bootstring parameter values:
-
-      base         = 36
-      tmin         = 1
-      tmax         = 26
-      skew         = 38
-      damp         = 700
-      initial_bias = 72
-      initial_n    = 128 = 0x80
-
-   Although the only restriction Punycode imposes on the input integers
-   is that they be nonnegative, these parameters are especially designed
-   to work well with Unicode [UNICODE] code points, which are integers
-   in the range 0..10FFFF (but not D800..DFFF, which are reserved for
-
-
-
-Costello                    Standards Track                     [Page 8]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   use by the UTF-16 encoding of Unicode).  The basic code points are
-   the ASCII [ASCII] code points (0..7F), of which U+002D (-) is the
-   delimiter, and some of the others have digit-values as follows:
-
-      code points    digit-values
-      ------------   ----------------------
-      41..5A (A-Z) =  0 to 25, respectively
-      61..7A (a-z) =  0 to 25, respectively
-      30..39 (0-9) = 26 to 35, respectively
-
-   Using hyphen-minus as the delimiter implies that the encoded string
-   can end with a hyphen-minus only if the Unicode string consists
-   entirely of basic code points, but IDNA forbids such strings from
-   being encoded.  The encoded string can begin with a hyphen-minus, but
-   IDNA prepends a prefix.  Therefore IDNA using Punycode conforms to
-   the RFC 952 rule that host name labels neither begin nor end with a
-   hyphen-minus [RFC952].
-
-   A decoder MUST recognize the letters in both uppercase and lowercase
-   forms (including mixtures of both forms).  An encoder SHOULD output
-   only uppercase forms or only lowercase forms, unless it uses mixed-
-   case annotation (see appendix A).
-
-   Presumably most users will not manually write or type encoded strings
-   (as opposed to cutting and pasting them), but those who do will need
-   to be alert to the potential visual ambiguity between the following
-   sets of characters:
-
-      G 6
-      I l 1
-      O 0
-      S 5
-      U V
-      Z 2
-
-   Such ambiguities are usually resolved by context, but in a Punycode
-   encoded string there is no context apparent to humans.
-
-6. Bootstring algorithms
-
-   Some parts of the pseudocode can be omitted if the parameters satisfy
-   certain conditions (for which Punycode qualifies).  These parts are
-   enclosed in {braces}, and notes immediately following the pseudocode
-   explain the conditions under which they can be omitted.
-
-
-
-
-
-
-
-Costello                    Standards Track                     [Page 9]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Formally, code points are integers, and hence the pseudocode assumes
-   that arithmetic operations can be performed directly on code points.
-   In some programming languages, explicit conversion between code
-   points and integers might be necessary.
-
-6.1 Bias adaptation function
-
-   function adapt(delta,numpoints,firsttime):
-     if firsttime then let delta = delta div damp
-     else let delta = delta div 2
-     let delta = delta + (delta div numpoints)
-     let k = 0
-     while delta > ((base - tmin) * tmax) div 2 do begin
-       let delta = delta div (base - tmin)
-       let k = k + base
-     end
-     return k + (((base - tmin + 1) * delta) div (delta + skew))
-
-   It does not matter whether the modifications to delta and k inside
-   adapt() affect variables of the same name inside the
-   encoding/decoding procedures, because after calling adapt() the
-   caller does not read those variables before overwriting them.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 10]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-6.2 Decoding procedure
-
-   let n = initial_n
-   let i = 0
-   let bias = initial_bias
-   let output = an empty string indexed from 0
-   consume all code points before the last delimiter (if there is one)
-     and copy them to output, fail on any non-basic code point
-   if more than zero code points were consumed then consume one more
-     (which will be the last delimiter)
-   while the input is not exhausted do begin
-     let oldi = i
-     let w = 1
-     for k = base to infinity in steps of base do begin
-       consume a code point, or fail if there was none to consume
-       let digit = the code point's digit-value, fail if it has none
-       let i = i + digit * w, fail on overflow
-       let t = tmin if k <= bias {+ tmin}, or
-               tmax if k >= bias + tmax, or k - bias otherwise
-       if digit < t then break
-       let w = w * (base - t), fail on overflow
-     end
-     let bias = adapt(i - oldi, length(output) + 1, test oldi is 0?)
-     let n = n + i div (length(output) + 1), fail on overflow
-     let i = i mod (length(output) + 1)
-     {if n is a basic code point then fail}
-     insert n into output at position i
-     increment i
-   end
-
-   The full statement enclosed in braces (checking whether n is a basic
-   code point) can be omitted if initial_n exceeds all basic code points
-   (which is true for Punycode), because n is never less than initial_n.
-
-   In the assignment of t, where t is clamped to the range tmin through
-   tmax, "+ tmin" can always be omitted.  This makes the clamping
-   calculation incorrect when bias < k < bias + tmin, but that cannot
-   happen because of the way bias is computed and because of the
-   constraints on the parameters.
-
-   Because the decoder state can only advance monotonically, and there
-   is only one representation of any delta, there is therefore only one
-   encoded string that can represent a given sequence of integers.  The
-   only error conditions are invalid code points, unexpected end-of-
-   input, overflow, and basic code points encoded using deltas instead
-   of appearing literally.  If the decoder fails on these errors as
-   shown above, then it cannot produce the same output for two distinct
-   inputs.  Without this property it would have been necessary to re-
-
-
-
-Costello                    Standards Track                    [Page 11]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   encode the output and verify that it matches the input in order to
-   guarantee the uniqueness of the encoding.
-
-6.3 Encoding procedure
-
-   let n = initial_n
-   let delta = 0
-   let bias = initial_bias
-   let h = b = the number of basic code points in the input
-   copy them to the output in order, followed by a delimiter if b > 0
-   {if the input contains a non-basic code point < n then fail}
-   while h < length(input) do begin
-     let m = the minimum {non-basic} code point >= n in the input
-     let delta = delta + (m - n) * (h + 1), fail on overflow
-     let n = m
-     for each code point c in the input (in order) do begin
-       if c < n {or c is basic} then increment delta, fail on overflow
-       if c == n then begin
-         let q = delta
-         for k = base to infinity in steps of base do begin
-           let t = tmin if k <= bias {+ tmin}, or
-                   tmax if k >= bias + tmax, or k - bias otherwise
-           if q < t then break
-           output the code point for digit t + ((q - t) mod (base - t))
-           let q = (q - t) div (base - t)
-         end
-         output the code point for digit q
-         let bias = adapt(delta, h + 1, test h equals b?)
-         let delta = 0
-         increment h
-       end
-     end
-     increment delta and n
-   end
-
-   The full statement enclosed in braces (checking whether the input
-   contains a non-basic code point less than n) can be omitted if all
-   code points less than initial_n are basic code points (which is true
-   for Punycode if code points are unsigned).
-
-   The brace-enclosed conditions "non-basic" and "or c is basic" can be
-   omitted if initial_n exceeds all basic code points (which is true for
-   Punycode), because the code point being tested is never less than
-   initial_n.
-
-   In the assignment of t, where t is clamped to the range tmin through
-   tmax, "+ tmin" can always be omitted.  This makes the clamping
-   calculation incorrect when bias < k < bias + tmin, but that cannot
-
-
-
-Costello                    Standards Track                    [Page 12]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   happen because of the way bias is computed and because of the
-   constraints on the parameters.
-
-   The checks for overflow are necessary to avoid producing invalid
-   output when the input contains very large values or is very long.
-
-   The increment of delta at the bottom of the outer loop cannot
-   overflow because delta < length(input) before the increment, and
-   length(input) is already assumed to be representable.  The increment
-   of n could overflow, but only if h == length(input), in which case
-   the procedure is finished anyway.
-
-6.4 Overflow handling
-
-   For IDNA, 26-bit unsigned integers are sufficient to handle all valid
-   IDNA labels without overflow, because any string that needed a 27-bit
-   delta would have to exceed either the code point limit (0..10FFFF) or
-   the label length limit (63 characters).  However, overflow handling
-   is necessary because the inputs are not necessarily valid IDNA
-   labels.
-
-   If the programming language does not provide overflow detection, the
-   following technique can be used.  Suppose A, B, and C are
-   representable nonnegative integers and C is nonzero.  Then A + B
-   overflows if and only if B > maxint - A, and A + (B * C) overflows if
-   and only if B > (maxint - A) div C, where maxint is the greatest
-   integer for which maxint + 1 cannot be represented.  Refer to
-   appendix C "Punycode sample implementation" for demonstrations of
-   this technique in the C language.
-
-   The decoding and encoding algorithms shown in sections 6.2 and 6.3
-   handle overflow by detecting it whenever it happens.  Another
-   approach is to enforce limits on the inputs that prevent overflow
-   from happening.  For example, if the encoder were to verify that no
-   input code points exceed M and that the input length does not exceed
-   L, then no delta could ever exceed (M - initial_n) * (L + 1), and
-   hence no overflow could occur if integer variables were capable of
-   representing values that large.  This prevention approach would
-   impose more restrictions on the input than the detection approach
-   does, but might be considered simpler in some programming languages.
-
-   In theory, the decoder could use an analogous approach, limiting the
-   number of digits in a variable-length integer (that is, limiting the
-   number of iterations in the innermost loop).  However, the number of
-   digits that suffice to represent a given delta can sometimes
-   represent much larger deltas (because of the adaptation), and hence
-   this approach would probably need integers wider than 32 bits.
-
-
-
-
-Costello                    Standards Track                    [Page 13]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Yet another approach for the decoder is to allow overflow to occur,
-   but to check the final output string by re-encoding it and comparing
-   to the decoder input.  If and only if they do not match (using a
-   case-insensitive ASCII comparison) overflow has occurred.  This
-   delayed-detection approach would not impose any more restrictions on
-   the input than the immediate-detection approach does, and might be
-   considered simpler in some programming languages.
-
-   In fact, if the decoder is used only inside the IDNA ToUnicode
-   operation [IDNA], then it need not check for overflow at all, because
-   ToUnicode performs a higher level re-encoding and comparison, and a
-   mismatch has the same consequence as if the Punycode decoder had
-   failed.
-
-7. Punycode examples
-
-7.1 Sample strings
-
-   In the Punycode encodings below, the ACE prefix is not shown.
-   Backslashes show where line breaks have been inserted in strings too
-   long for one line.
-
-   The first several examples are all translations of the sentence "Why
-   can't they just speak in <language>?" (courtesy of Michael Kaplan's
-   "provincial" page [PROVINCIAL]).  Word breaks and punctuation have
-   been removed, as is often done in domain names.
-
-   (A) Arabic (Egyptian):
-       u+0644 u+064A u+0647 u+0645 u+0627 u+0628 u+062A u+0643 u+0644
-       u+0645 u+0648 u+0634 u+0639 u+0631 u+0628 u+064A u+061F
-       Punycode: egbpdaj6bu4bxfgehfvwxn
-
-   (B) Chinese (simplified):
-       u+4ED6 u+4EEC u+4E3A u+4EC0 u+4E48 u+4E0D u+8BF4 u+4E2D u+6587
-       Punycode: ihqwcrb4cv8a8dqg056pqjye
-
-   (C) Chinese (traditional):
-       u+4ED6 u+5011 u+7232 u+4EC0 u+9EBD u+4E0D u+8AAA u+4E2D u+6587
-       Punycode: ihqwctvzc91f659drss3x8bo0yb
-
-   (D) Czech: Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky
-       U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074
-       u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D
-       u+0065 u+0073 u+006B u+0079
-       Punycode: Proprostnemluvesky-uyb24dma41a
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 14]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   (E) Hebrew:
-       u+05DC u+05DE u+05D4 u+05D4 u+05DD u+05E4 u+05E9 u+05D5 u+05D8
-       u+05DC u+05D0 u+05DE u+05D3 u+05D1 u+05E8 u+05D9 u+05DD u+05E2
-       u+05D1 u+05E8 u+05D9 u+05EA
-       Punycode: 4dbcagdahymbxekheh6e0a7fei0b
-
-   (F) Hindi (Devanagari):
-       u+092F u+0939 u+0932 u+094B u+0917 u+0939 u+093F u+0928 u+094D
-       u+0926 u+0940 u+0915 u+094D u+092F u+094B u+0902 u+0928 u+0939
-       u+0940 u+0902 u+092C u+094B u+0932 u+0938 u+0915 u+0924 u+0947
-       u+0939 u+0948 u+0902
-       Punycode: i1baa7eci9glrd9b2ae1bj0hfcgg6iyaf8o0a1dig0cd
-
-   (G) Japanese (kanji and hiragana):
-       u+306A u+305C u+307F u+3093 u+306A u+65E5 u+672C u+8A9E u+3092
-       u+8A71 u+3057 u+3066 u+304F u+308C u+306A u+3044 u+306E u+304B
-       Punycode: n8jok5ay5dzabd5bym9f0cm5685rrjetr6pdxa
-
-   (H) Korean (Hangul syllables):
-       u+C138 u+ACC4 u+C758 u+BAA8 u+B4E0 u+C0AC u+B78C u+B4E4 u+C774
-       u+D55C u+AD6D u+C5B4 u+B97C u+C774 u+D574 u+D55C u+B2E4 u+BA74
-       u+C5BC u+B9C8 u+B098 u+C88B u+C744 u+AE4C
-       Punycode: 989aomsvi5e83db1d2a355cv1e0vak1dwrv93d5xbh15a0dt30a5j\
-                 psd879ccm6fea98c
-
-   (I) Russian (Cyrillic):
-       U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E
-       u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440
-       u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A
-       u+0438
-       Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l
-
-   (J) Spanish: Porqu<eacute>nopuedensimplementehablarenEspa<ntilde>ol
-       U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070
-       u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070
-       u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061
-       u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070
-       u+0061 u+00F1 u+006F u+006C
-       Punycode: PorqunopuedensimplementehablarenEspaol-fmd56a
-
-   (K) Vietnamese:
-       T<adotbelow>isaoh<odotbelow>kh<ocirc>ngth<ecirchookabove>ch\
-       <ihookabove>n<oacute>iti<ecircacute>ngVi<ecircdotbelow>t
-       U+0054 u+1EA1 u+0069 u+0073 u+0061 u+006F u+0068 u+1ECD u+006B
-       u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+1EC3 u+0063 u+0068
-       u+1EC9 u+006E u+00F3 u+0069 u+0074 u+0069 u+1EBF u+006E u+0067
-       U+0056 u+0069 u+1EC7 u+0074
-       Punycode: TisaohkhngthchnitingVit-kjcr8268qyxafd2f1b9g
-
-
-
-Costello                    Standards Track                    [Page 15]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   The next several examples are all names of Japanese music artists,
-   song titles, and TV programs, just because the author happens to have
-   them handy (but Japanese is useful for providing examples of single-
-   row text, two-row text, ideographic text, and various mixtures
-   thereof).
-
-   (L) 3<nen>B<gumi><kinpachi><sensei>
-       u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F
-       Punycode: 3B-ww4c5e180e575a65lsy2b
-
-   (M) <amuro><namie>-with-SUPER-MONKEYS
-       u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074
-       u+0068 u+002D U+0053 U+0055 U+0050 U+0045 U+0052 u+002D U+004D
-       U+004F U+004E U+004B U+0045 U+0059 U+0053
-       Punycode: -with-SUPER-MONKEYS-pc58ag80a8qai00g7n9n
-
-   (N) Hello-Another-Way-<sorezore><no><basho>
-       U+0048 u+0065 u+006C u+006C u+006F u+002D U+0041 u+006E u+006F
-       u+0074 u+0068 u+0065 u+0072 u+002D U+0057 u+0061 u+0079 u+002D
-       u+305D u+308C u+305E u+308C u+306E u+5834 u+6240
-       Punycode: Hello-Another-Way--fc4qua05auwb3674vfr0b
-
-   (O) <hitotsu><yane><no><shita>2
-       u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032
-       Punycode: 2-u9tlzr9756bt3uc0v
-
-   (P) Maji<de>Koi<suru>5<byou><mae>
-       U+004D u+0061 u+006A u+0069 u+3067 U+004B u+006F u+0069 u+3059
-       u+308B u+0035 u+79D2 u+524D
-       Punycode: MajiKoi5-783gue6qz075azm5e
-
-   (Q) <pafii>de<runba>
-       u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0
-       Punycode: de-jg4avhby1noc0d
-
-   (R) <sono><supiido><de>
-       u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067
-       Punycode: d9juau41awczczp
-
-   The last example is an ASCII string that breaks the existing rules
-   for host name labels.  (It is not a realistic example for IDNA,
-   because IDNA never encodes pure ASCII labels.)
-
-   (S) -> $1.00 <-
-       u+002D u+003E u+0020 u+0024 u+0031 u+002E u+0030 u+0030 u+0020
-       u+003C u+002D
-       Punycode: -> $1.00 <--
-
-
-
-
-Costello                    Standards Track                    [Page 16]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-7.2 Decoding traces
-
-   In the following traces, the evolving state of the decoder is shown
-   as a sequence of hexadecimal values, representing the code points in
-   the extended string.  An asterisk appears just after the most
-   recently inserted code point, indicating both n (the value preceeding
-   the asterisk) and i (the position of the value just after the
-   asterisk).  Other numerical values are decimal.
-
-   Decoding trace of example B from section 7.1:
-
-   n is 128, i is 0, bias is 72
-   input is "ihqwcrb4cv8a8dqg056pqjye"
-   there is no delimiter, so extended string starts empty
-   delta "ihq" decodes to 19853
-   bias becomes 21
-   4E0D *
-   delta "wc" decodes to 64
-   bias becomes 20
-   4E0D 4E2D *
-   delta "rb" decodes to 37
-   bias becomes 13
-   4E3A * 4E0D 4E2D
-   delta "4c" decodes to 56
-   bias becomes 17
-   4E3A 4E48 * 4E0D 4E2D
-   delta "v8a" decodes to 599
-   bias becomes 32
-   4E3A 4EC0 * 4E48 4E0D 4E2D
-   delta "8d" decodes to 130
-   bias becomes 23
-   4ED6 * 4E3A 4EC0 4E48 4E0D 4E2D
-   delta "qg" decodes to 154
-   bias becomes 25
-   4ED6 4EEC * 4E3A 4EC0 4E48 4E0D 4E2D
-   delta "056p" decodes to 46301
-   bias becomes 84
-   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 4E2D 6587 *
-   delta "qjye" decodes to 88531
-   bias becomes 90
-   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 * 4E2D 6587
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 17]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Decoding trace of example L from section 7.1:
-
-   n is 128, i is 0, bias is 72
-   input is "3B-ww4c5e180e575a65lsy2b"
-   literal portion is "3B-", so extended string starts as:
-   0033 0042
-   delta "ww4c" decodes to 62042
-   bias becomes 27
-   0033 0042 5148 *
-   delta "5e" decodes to 139
-   bias becomes 24
-   0033 0042 516B * 5148
-   delta "180e" decodes to 16683
-   bias becomes 67
-   0033 5E74 * 0042 516B 5148
-   delta "575a" decodes to 34821
-   bias becomes 82
-   0033 5E74 0042 516B 5148 751F *
-   delta "65l" decodes to 14592
-   bias becomes 67
-   0033 5E74 0042 7D44 * 516B 5148 751F
-   delta "sy2b" decodes to 42088
-   bias becomes 84
-   0033 5E74 0042 7D44 91D1 * 516B 5148 751F
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 18]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-7.3 Encoding traces
-
-   In the following traces, code point values are hexadecimal, while
-   other numerical values are decimal.
-
-   Encoding trace of example B from section 7.1:
-
-   bias is 72
-   input is:
-   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 4E2D 6587
-   there are no basic code points, so no literal portion
-   next code point to insert is 4E0D
-   needed delta is 19853, encodes as "ihq"
-   bias becomes 21
-   next code point to insert is 4E2D
-   needed delta is 64, encodes as "wc"
-   bias becomes 20
-   next code point to insert is 4E3A
-   needed delta is 37, encodes as "rb"
-   bias becomes 13
-   next code point to insert is 4E48
-   needed delta is 56, encodes as "4c"
-   bias becomes 17
-   next code point to insert is 4EC0
-   needed delta is 599, encodes as "v8a"
-   bias becomes 32
-   next code point to insert is 4ED6
-   needed delta is 130, encodes as "8d"
-   bias becomes 23
-   next code point to insert is 4EEC
-   needed delta is 154, encodes as "qg"
-   bias becomes 25
-   next code point to insert is 6587
-   needed delta is 46301, encodes as "056p"
-   bias becomes 84
-   next code point to insert is 8BF4
-   needed delta is 88531, encodes as "qjye"
-   bias becomes 90
-   output is "ihqwcrb4cv8a8dqg056pqjye"
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 19]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Encoding trace of example L from section 7.1:
-
-   bias is 72
-   input is:
-   0033 5E74 0042 7D44 91D1 516B 5148 751F
-   basic code points (0033, 0042) are copied to literal portion: "3B-"
-   next code point to insert is 5148
-   needed delta is 62042, encodes as "ww4c"
-   bias becomes 27
-   next code point to insert is 516B
-   needed delta is 139, encodes as "5e"
-   bias becomes 24
-   next code point to insert is 5E74
-   needed delta is 16683, encodes as "180e"
-   bias becomes 67
-   next code point to insert is 751F
-   needed delta is 34821, encodes as "575a"
-   bias becomes 82
-   next code point to insert is 7D44
-   needed delta is 14592, encodes as "65l"
-   bias becomes 67
-   next code point to insert is 91D1
-   needed delta is 42088, encodes as "sy2b"
-   bias becomes 84
-   output is "3B-ww4c5e180e575a65lsy2b"
-
-8. Security Considerations
-
-   Users expect each domain name in DNS to be controlled by a single
-   authority.  If a Unicode string intended for use as a domain label
-   could map to multiple ACE labels, then an internationalized domain
-   name could map to multiple ASCII domain names, each controlled by a
-   different authority, some of which could be spoofs that hijack
-   service requests intended for another.  Therefore Punycode is
-   designed so that each Unicode string has a unique encoding.
-
-   However, there can still be multiple Unicode representations of the
-   "same" text, for various definitions of "same".  This problem is
-   addressed to some extent by the Unicode standard under the topic of
-   canonicalization, and this work is leveraged for domain names by
-   Nameprep [NAMEPREP].
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 20]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-9. References
-
-9.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-9.2 Informative References
-
-   [RFC952]     Harrenstien, K., Stahl, M. and E. Feinler, "DOD Internet
-                Host Table Specification", RFC 952, October 1985.
-
-   [RFC1034]    Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [IDNA]       Faltstrom, P., Hoffman, P. and A. Costello,
-                "Internationalizing Domain Names in Applications
-                (IDNA)", RFC 3490, March 2003.
-
-   [NAMEPREP]   Hoffman, P. and  M. Blanchet, "Nameprep: A Stringprep
-                Profile for Internationalized Domain Names (IDN)", RFC
-                3491, March 2003.
-
-   [ASCII]      Cerf, V., "ASCII format for Network Interchange", RFC
-                20, October 1969.
-
-   [PROVINCIAL] Kaplan, M., "The 'anyone can be provincial!' page",
-                http://www.trigeminal.com/samples/provincial.html.
-
-   [UNICODE]    The Unicode Consortium, "The Unicode Standard",
-                http://www.unicode.org/unicode/standard/standard.html.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 21]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-A. Mixed-case annotation
-
-   In order to use Punycode to represent case-insensitive strings,
-   higher layers need to case-fold the strings prior to Punycode
-   encoding.  The encoded string can use mixed case as an annotation
-   telling how to convert the folded string into a mixed-case string for
-   display purposes.  Note, however, that mixed-case annotation is not
-   used by the ToASCII and ToUnicode operations specified in [IDNA], and
-   therefore implementors of IDNA can disregard this appendix.
-
-   Basic code points can use mixed case directly, because the decoder
-   copies them verbatim, leaving lowercase code points lowercase, and
-   leaving uppercase code points uppercase.  Each non-basic code point
-   is represented by a delta, which is represented by a sequence of
-   basic code points, the last of which provides the annotation.  If it
-   is uppercase, it is a suggestion to map the non-basic code point to
-   uppercase (if possible); if it is lowercase, it is a suggestion to
-   map the non-basic code point to lowercase (if possible).
-
-   These annotations do not alter the code points returned by decoders;
-   the annotations are returned separately, for the caller to use or
-   ignore.  Encoders can accept annotations in addition to code points,
-   but the annotations do not alter the output, except to influence the
-   uppercase/lowercase form of ASCII letters.
-
-   Punycode encoders and decoders need not support these annotations,
-   and higher layers need not use them.
-
-B. Disclaimer and license
-
-   Regarding this entire document or any portion of it (including the
-   pseudocode and C code), the author makes no guarantees and is not
-   responsible for any damage resulting from its use.  The author grants
-   irrevocable permission to anyone to use, modify, and distribute it in
-   any way that does not diminish the rights of anyone else to use,
-   modify, and distribute it, provided that redistributed derivative
-   works do not contain misleading author or version information.
-   Derivative works need not be licensed under similar terms.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 22]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-C. Punycode sample implementation
-
-/*
-punycode.c from RFC 3492
-http://www.nicemice.net/idn/
-Adam M. Costello
-http://www.nicemice.net/amc/
-
-This is ANSI C code (C89) implementing Punycode (RFC 3492).
-
-*/
-
-
-/************************************************************/
-/* Public interface (would normally go in its own .h file): */
-
-#include <limits.h>
-
-enum punycode_status {
-  punycode_success,
-  punycode_bad_input,   /* Input is invalid.                       */
-  punycode_big_output,  /* Output would exceed the space provided. */
-  punycode_overflow     /* Input needs wider integers to process.  */
-};
-
-#if UINT_MAX >= (1 << 26) - 1
-typedef unsigned int punycode_uint;
-#else
-typedef unsigned long punycode_uint;
-#endif
-
-enum punycode_status punycode_encode(
-  punycode_uint input_length,
-  const punycode_uint input[],
-  const unsigned char case_flags[],
-  punycode_uint *output_length,
-  char output[] );
-
-    /* punycode_encode() converts Unicode to Punycode.  The input     */
-    /* is represented as an array of Unicode code points (not code    */
-    /* units; surrogate pairs are not allowed), and the output        */
-    /* will be represented as an array of ASCII code points.  The     */
-    /* output string is *not* null-terminated; it will contain        */
-    /* zeros if and only if the input contains zeros.  (Of course     */
-    /* the caller can leave room for a terminator and add one if      */
-    /* needed.)  The input_length is the number of code points in     */
-    /* the input.  The output_length is an in/out argument: the       */
-    /* caller passes in the maximum number of code points that it     */
-
-
-
-Costello                    Standards Track                    [Page 23]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-    /* can receive, and on successful return it will contain the      */
-    /* number of code points actually output.  The case_flags array   */
-    /* holds input_length boolean values, where nonzero suggests that */
-    /* the corresponding Unicode character be forced to uppercase     */
-    /* after being decoded (if possible), and zero suggests that      */
-    /* it be forced to lowercase (if possible).  ASCII code points    */
-    /* are encoded literally, except that ASCII letters are forced    */
-    /* to uppercase or lowercase according to the corresponding       */
-    /* uppercase flags.  If case_flags is a null pointer then ASCII   */
-    /* letters are left as they are, and other code points are        */
-    /* treated as if their uppercase flags were zero.  The return     */
-    /* value can be any of the punycode_status values defined above   */
-    /* except punycode_bad_input; if not punycode_success, then       */
-    /* output_size and output might contain garbage.                  */
-
-enum punycode_status punycode_decode(
-  punycode_uint input_length,
-  const char input[],
-  punycode_uint *output_length,
-  punycode_uint output[],
-  unsigned char case_flags[] );
-
-    /* punycode_decode() converts Punycode to Unicode.  The input is  */
-    /* represented as an array of ASCII code points, and the output   */
-    /* will be represented as an array of Unicode code points.  The   */
-    /* input_length is the number of code points in the input.  The   */
-    /* output_length is an in/out argument: the caller passes in      */
-    /* the maximum number of code points that it can receive, and     */
-    /* on successful return it will contain the actual number of      */
-    /* code points output.  The case_flags array needs room for at    */
-    /* least output_length values, or it can be a null pointer if the */
-    /* case information is not needed.  A nonzero flag suggests that  */
-    /* the corresponding Unicode character be forced to uppercase     */
-    /* by the caller (if possible), while zero suggests that it be    */
-    /* forced to lowercase (if possible).  ASCII code points are      */
-    /* output already in the proper case, but their flags will be set */
-    /* appropriately so that applying the flags would be harmless.    */
-    /* The return value can be any of the punycode_status values      */
-    /* defined above; if not punycode_success, then output_length,    */
-    /* output, and case_flags might contain garbage.  On success, the */
-    /* decoder will never need to write an output_length greater than */
-    /* input_length, because of how the encoding is defined.          */
-
-/**********************************************************/
-/* Implementation (would normally go in its own .c file): */
-
-#include <string.h>
-
-
-
-
-Costello                    Standards Track                    [Page 24]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-/*** Bootstring parameters for Punycode ***/
-
-enum { base = 36, tmin = 1, tmax = 26, skew = 38, damp = 700,
-       initial_bias = 72, initial_n = 0x80, delimiter = 0x2D };
-
-/* basic(cp) tests whether cp is a basic code point: */
-#define basic(cp) ((punycode_uint)(cp) < 0x80)
-
-/* delim(cp) tests whether cp is a delimiter: */
-#define delim(cp) ((cp) == delimiter)
-
-/* decode_digit(cp) returns the numeric value of a basic code */
-/* point (for use in representing integers) in the range 0 to */
-/* base-1, or base if cp is does not represent a value.       */
-
-static punycode_uint decode_digit(punycode_uint cp)
-{
-  return  cp - 48 < 10 ? cp - 22 :  cp - 65 < 26 ? cp - 65 :
-          cp - 97 < 26 ? cp - 97 :  base;
-}
-
-/* encode_digit(d,flag) returns the basic code point whose value      */
-/* (when used for representing integers) is d, which needs to be in   */
-/* the range 0 to base-1.  The lowercase form is used unless flag is  */
-/* nonzero, in which case the uppercase form is used.  The behavior   */
-/* is undefined if flag is nonzero and digit d has no uppercase form. */
-
-static char encode_digit(punycode_uint d, int flag)
-{
-  return d + 22 + 75 * (d < 26) - ((flag != 0) << 5);
-  /*  0..25 map to ASCII a..z or A..Z */
-  /* 26..35 map to ASCII 0..9         */
-}
-
-/* flagged(bcp) tests whether a basic code point is flagged */
-/* (uppercase).  The behavior is undefined if bcp is not a  */
-/* basic code point.                                        */
-
-#define flagged(bcp) ((punycode_uint)(bcp) - 65 < 26)
-
-/* encode_basic(bcp,flag) forces a basic code point to lowercase */
-/* if flag is zero, uppercase if flag is nonzero, and returns    */
-/* the resulting code point.  The code point is unchanged if it  */
-/* is caseless.  The behavior is undefined if bcp is not a basic */
-/* code point.                                                   */
-
-static char encode_basic(punycode_uint bcp, int flag)
-{
-
-
-
-Costello                    Standards Track                    [Page 25]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-  bcp -= (bcp - 97 < 26) << 5;
-  return bcp + ((!flag && (bcp - 65 < 26)) << 5);
-}
-
-/*** Platform-specific constants ***/
-
-/* maxint is the maximum value of a punycode_uint variable: */
-static const punycode_uint maxint = -1;
-/* Because maxint is unsigned, -1 becomes the maximum value. */
-
-/*** Bias adaptation function ***/
-
-static punycode_uint adapt(
-  punycode_uint delta, punycode_uint numpoints, int firsttime )
-{
-  punycode_uint k;
-
-  delta = firsttime ? delta / damp : delta >> 1;
-  /* delta >> 1 is a faster way of doing delta / 2 */
-  delta += delta / numpoints;
-
-  for (k = 0;  delta > ((base - tmin) * tmax) / 2;  k += base) {
-    delta /= base - tmin;
-  }
-
-  return k + (base - tmin + 1) * delta / (delta + skew);
-}
-
-/*** Main encode function ***/
-
-enum punycode_status punycode_encode(
-  punycode_uint input_length,
-  const punycode_uint input[],
-  const unsigned char case_flags[],
-  punycode_uint *output_length,
-  char output[] )
-{
-  punycode_uint n, delta, h, b, out, max_out, bias, j, m, q, k, t;
-
-  /* Initialize the state: */
-
-  n = initial_n;
-  delta = out = 0;
-  max_out = *output_length;
-  bias = initial_bias;
-
-  /* Handle the basic code points: */
-
-
-
-
-Costello                    Standards Track                    [Page 26]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-  for (j = 0;  j < input_length;  ++j) {
-    if (basic(input[j])) {
-      if (max_out - out < 2) return punycode_big_output;
-      output[out++] =
-        case_flags ?  encode_basic(input[j], case_flags[j]) : input[j];
-    }
-    /* else if (input[j] < n) return punycode_bad_input; */
-    /* (not needed for Punycode with unsigned code points) */
-  }
-
-  h = b = out;
-
-  /* h is the number of code points that have been handled, b is the  */
-  /* number of basic code points, and out is the number of characters */
-  /* that have been output.                                           */
-
-  if (b > 0) output[out++] = delimiter;
-
-  /* Main encoding loop: */
-
-  while (h < input_length) {
-    /* All non-basic code points < n have been     */
-    /* handled already.  Find the next larger one: */
-
-    for (m = maxint, j = 0;  j < input_length;  ++j) {
-      /* if (basic(input[j])) continue; */
-      /* (not needed for Punycode) */
-      if (input[j] >= n && input[j] < m) m = input[j];
-    }
-
-    /* Increase delta enough to advance the decoder's    */
-    /* <n,i> state to <m,0>, but guard against overflow: */
-
-    if (m - n > (maxint - delta) / (h + 1)) return punycode_overflow;
-    delta += (m - n) * (h + 1);
-    n = m;
-
-    for (j = 0;  j < input_length;  ++j) {
-      /* Punycode does not need to check whether input[j] is basic: */
-      if (input[j] < n /* || basic(input[j]) */ ) {
-        if (++delta == 0) return punycode_overflow;
-      }
-
-      if (input[j] == n) {
-        /* Represent delta as a generalized variable-length integer: */
-
-        for (q = delta, k = base;  ;  k += base) {
-          if (out >= max_out) return punycode_big_output;
-
-
-
-Costello                    Standards Track                    [Page 27]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-          t = k <= bias /* + tmin */ ? tmin :     /* +tmin not needed */
-              k >= bias + tmax ? tmax : k - bias;
-          if (q < t) break;
-          output[out++] = encode_digit(t + (q - t) % (base - t), 0);
-          q = (q - t) / (base - t);
-        }
-
-        output[out++] = encode_digit(q, case_flags && case_flags[j]);
-        bias = adapt(delta, h + 1, h == b);
-        delta = 0;
-        ++h;
-      }
-    }
-
-    ++delta, ++n;
-  }
-
-  *output_length = out;
-  return punycode_success;
-}
-
-/*** Main decode function ***/
-
-enum punycode_status punycode_decode(
-  punycode_uint input_length,
-  const char input[],
-  punycode_uint *output_length,
-  punycode_uint output[],
-  unsigned char case_flags[] )
-{
-  punycode_uint n, out, i, max_out, bias,
-                 b, j, in, oldi, w, k, digit, t;
-
-  /* Initialize the state: */
-
-  n = initial_n;
-  out = i = 0;
-  max_out = *output_length;
-  bias = initial_bias;
-
-  /* Handle the basic code points:  Let b be the number of input code */
-  /* points before the last delimiter, or 0 if there is none, then    */
-  /* copy the first b code points to the output.                      */
-
-  for (b = j = 0;  j < input_length;  ++j) if (delim(input[j])) b = j;
-  if (b > max_out) return punycode_big_output;
-
-  for (j = 0;  j < b;  ++j) {
-
-
-
-Costello                    Standards Track                    [Page 28]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-    if (case_flags) case_flags[out] = flagged(input[j]);
-    if (!basic(input[j])) return punycode_bad_input;
-    output[out++] = input[j];
-  }
-
-  /* Main decoding loop:  Start just after the last delimiter if any  */
-  /* basic code points were copied; start at the beginning otherwise. */
-
-  for (in = b > 0 ? b + 1 : 0;  in < input_length;  ++out) {
-
-    /* in is the index of the next character to be consumed, and */
-    /* out is the number of code points in the output array.     */
-
-    /* Decode a generalized variable-length integer into delta,  */
-    /* which gets added to i.  The overflow checking is easier   */
-    /* if we increase i as we go, then subtract off its starting */
-    /* value at the end to obtain delta.                         */
-
-    for (oldi = i, w = 1, k = base;  ;  k += base) {
-      if (in >= input_length) return punycode_bad_input;
-      digit = decode_digit(input[in++]);
-      if (digit >= base) return punycode_bad_input;
-      if (digit > (maxint - i) / w) return punycode_overflow;
-      i += digit * w;
-      t = k <= bias /* + tmin */ ? tmin :     /* +tmin not needed */
-          k >= bias + tmax ? tmax : k - bias;
-      if (digit < t) break;
-      if (w > maxint / (base - t)) return punycode_overflow;
-      w *= (base - t);
-    }
-
-    bias = adapt(i - oldi, out + 1, oldi == 0);
-
-    /* i was supposed to wrap around from out+1 to 0,   */
-    /* incrementing n each time, so we'll fix that now: */
-
-    if (i / (out + 1) > maxint - n) return punycode_overflow;
-    n += i / (out + 1);
-    i %= (out + 1);
-
-    /* Insert n at position i of the output: */
-
-    /* not needed for Punycode: */
-    /* if (decode_digit(n) <= base) return punycode_invalid_input; */
-    if (out >= max_out) return punycode_big_output;
-
-    if (case_flags) {
-      memmove(case_flags + i + 1, case_flags + i, out - i);
-
-
-
-Costello                    Standards Track                    [Page 29]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-      /* Case of last character determines uppercase flag: */
-      case_flags[i] = flagged(input[in - 1]);
-    }
-
-    memmove(output + i + 1, output + i, (out - i) * sizeof *output);
-    output[i++] = n;
-  }
-
-  *output_length = out;
-  return punycode_success;
-}
-
-/******************************************************************/
-/* Wrapper for testing (would normally go in a separate .c file): */
-
-#include <assert.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-/* For testing, we'll just set some compile-time limits rather than */
-/* use malloc(), and set a compile-time option rather than using a  */
-/* command-line option.                                             */
-
-enum {
-  unicode_max_length = 256,
-  ace_max_length = 256
-};
-
-static void usage(char **argv)
-{
-  fprintf(stderr,
-    "\n"
-    "%s -e reads code points and writes a Punycode string.\n"
-    "%s -d reads a Punycode string and writes code points.\n"
-    "\n"
-    "Input and output are plain text in the native character set.\n"
-    "Code points are in the form u+hex separated by whitespace.\n"
-    "Although the specification allows Punycode strings to contain\n"
-    "any characters from the ASCII repertoire, this test code\n"
-    "supports only the printable characters, and needs the Punycode\n"
-    "string to be followed by a newline.\n"
-    "The case of the u in u+hex is the force-to-uppercase flag.\n"
-    , argv[0], argv[0]);
-  exit(EXIT_FAILURE);
-}
-
-static void fail(const char *msg)
-
-
-
-Costello                    Standards Track                    [Page 30]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-{
-  fputs(msg,stderr);
-  exit(EXIT_FAILURE);
-}
-
-static const char too_big[] =
-  "input or output is too large, recompile with larger limits\n";
-static const char invalid_input[] = "invalid input\n";
-static const char overflow[] = "arithmetic overflow\n";
-static const char io_error[] = "I/O error\n";
-
-/* The following string is used to convert printable */
-/* characters between ASCII and the native charset:  */
-
-static const char print_ascii[] =
-  "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
-  "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
-  " !\"#$%&'()*+,-./"
-  "0123456789:;<=>?"
-  "@ABCDEFGHIJKLMNO"
-  "PQRSTUVWXYZ[\\]^_"
-  "`abcdefghijklmno"
-  "pqrstuvwxyz{|}~\n";
-
-int main(int argc, char **argv)
-{
-  enum punycode_status status;
-  int r;
-  unsigned int input_length, output_length, j;
-  unsigned char case_flags[unicode_max_length];
-
-  if (argc != 2) usage(argv);
-  if (argv[1][0] != '-') usage(argv);
-  if (argv[1][2] != 0) usage(argv);
-
-  if (argv[1][1] == 'e') {
-    punycode_uint input[unicode_max_length];
-    unsigned long codept;
-    char output[ace_max_length+1], uplus[3];
-    int c;
-
-    /* Read the input code points: */
-
-    input_length = 0;
-
-    for (;;) {
-      r = scanf("%2s%lx", uplus, &codept);
-      if (ferror(stdin)) fail(io_error);
-
-
-
-Costello                    Standards Track                    [Page 31]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-      if (r == EOF || r == 0) break;
-
-      if (r != 2 || uplus[1] != '+' || codept > (punycode_uint)-1) {
-        fail(invalid_input);
-      }
-
-      if (input_length == unicode_max_length) fail(too_big);
-
-      if (uplus[0] == 'u') case_flags[input_length] = 0;
-      else if (uplus[0] == 'U') case_flags[input_length] = 1;
-      else fail(invalid_input);
-
-      input[input_length++] = codept;
-    }
-
-    /* Encode: */
-
-    output_length = ace_max_length;
-    status = punycode_encode(input_length, input, case_flags,
-                             &output_length, output);
-    if (status == punycode_bad_input) fail(invalid_input);
-    if (status == punycode_big_output) fail(too_big);
-    if (status == punycode_overflow) fail(overflow);
-    assert(status == punycode_success);
-
-    /* Convert to native charset and output: */
-
-    for (j = 0;  j < output_length;  ++j) {
-      c = output[j];
-      assert(c >= 0 && c <= 127);
-      if (print_ascii[c] == 0) fail(invalid_input);
-      output[j] = print_ascii[c];
-    }
-
-    output[j] = 0;
-    r = puts(output);
-    if (r == EOF) fail(io_error);
-    return EXIT_SUCCESS;
-  }
-
-  if (argv[1][1] == 'd') {
-    char input[ace_max_length+2], *p, *pp;
-    punycode_uint output[unicode_max_length];
-
-    /* Read the Punycode input string and convert to ASCII: */
-
-    fgets(input, ace_max_length+2, stdin);
-    if (ferror(stdin)) fail(io_error);
-
-
-
-Costello                    Standards Track                    [Page 32]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-    if (feof(stdin)) fail(invalid_input);
-    input_length = strlen(input) - 1;
-    if (input[input_length] != '\n') fail(too_big);
-    input[input_length] = 0;
-
-    for (p = input;  *p != 0;  ++p) {
-      pp = strchr(print_ascii, *p);
-      if (pp == 0) fail(invalid_input);
-      *p = pp - print_ascii;
-    }
-
-    /* Decode: */
-
-    output_length = unicode_max_length;
-    status = punycode_decode(input_length, input, &output_length,
-                             output, case_flags);
-    if (status == punycode_bad_input) fail(invalid_input);
-    if (status == punycode_big_output) fail(too_big);
-    if (status == punycode_overflow) fail(overflow);
-    assert(status == punycode_success);
-
-    /* Output the result: */
-
-    for (j = 0;  j < output_length;  ++j) {
-      r = printf("%s+%04lX\n",
-                 case_flags[j] ? "U" : "u",
-                 (unsigned long) output[j] );
-      if (r < 0) fail(io_error);
-    }
-
-    return EXIT_SUCCESS;
-  }
-
-  usage(argv);
-  return EXIT_SUCCESS;  /* not reached, but quiets compiler warning */
-}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 33]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-Author's Address
-
-   Adam M. Costello
-   University of California, Berkeley
-   http://www.nicemice.net/amc/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 34]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 35]
-
diff --git a/doc/rfc/rfc3493.txt b/doc/rfc/rfc3493.txt
deleted file mode 100644
index 5fea6c19..00000000
--- a/doc/rfc/rfc3493.txt
+++ /dev/null
@@ -1,2187 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Gilligan
-Request for Comments: 3493                                Intransa, Inc.
-Obsoletes: 2553                                               S. Thomson
-Category: Informational                                            Cisco
-                                                                J. Bound
-                                                               J. McCann
-                                                         Hewlett-Packard
-                                                              W. Stevens
-                                                           February 2003
-
-
-               Basic Socket Interface Extensions for IPv6
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   The de facto standard Application Program Interface (API) for TCP/IP
-   applications is the "sockets" interface.  Although this API was
-   developed for Unix in the early 1980s it has also been implemented on
-   a wide variety of non-Unix systems.  TCP/IP applications written
-   using the sockets API have in the past enjoyed a high degree of
-   portability and we would like the same portability with IPv6
-   applications.  But changes are required to the sockets API to support
-   IPv6 and this memo describes these changes.  These include a new
-   socket address structure to carry IPv6 addresses, new address
-   conversion functions, and some new socket options.  These extensions
-   are designed to provide access to the basic IPv6 features required by
-   TCP and UDP applications, including multicasting, while introducing a
-   minimum of change into the system and providing complete
-   compatibility for existing IPv4 applications.  Additional extensions
-   for advanced IPv6 features (raw sockets and access to the IPv6
-   extension headers) are defined in another document.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 1]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-Table of Contents
-
-   1.  Introduction................................................3
-   2.  Design Considerations.......................................4
-       2.1  What Needs to be Changed...............................4
-       2.2  Data Types.............................................6
-       2.3  Headers................................................6
-       2.4  Structures.............................................6
-   3.  Socket Interface............................................6
-       3.1  IPv6 Address Family and Protocol Family................6
-       3.2  IPv6 Address Structure.................................7
-       3.3  Socket Address Structure for 4.3BSD-Based Systems......7
-       3.4  Socket Address Structure for 4.4BSD-Based Systems......9
-       3.5  The Socket Functions...................................9
-       3.6  Compatibility with IPv4 Applications..................10
-       3.7  Compatibility with IPv4 Nodes.........................11
-       3.8  IPv6 Wildcard Address.................................11
-       3.9  IPv6 Loopback Address.................................13
-       3.10 Portability Additions.................................14
-   4.  Interface Identification...................................16
-       4.1  Name-to-Index.........................................17
-       4.2  Index-to-Name.........................................17
-       4.3  Return All Interface Names and Indexes................18
-       4.4  Free Memory...........................................18
-   5.  Socket Options.............................................18
-       5.1  Unicast Hop Limit.....................................19
-       5.2  Sending and Receiving Multicast Packets...............19
-       5.3  IPV6_V6ONLY option for AF_INET6 Sockets...............22
-   6.  Library Functions..........................................22
-       6.1  Protocol-Independent Nodename and
-            Service Name Translation..............................23
-       6.2  Socket Address Structure to Node Name
-            and Service Name......................................28
-       6.3  Address Conversion Functions..........................31
-       6.4  Address Testing Macros................................33
-   7.  Summary of New Definitions.................................33
-   8.  Security Considerations....................................35
-   9.  Changes from RFC 2553......................................35
-   10. Acknowledgments............................................36
-   11. References.................................................37
-   12. Authors' Addresses.........................................38
-   13. Full Copyright Statement...................................39
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 2]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-1. Introduction
-
-   While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits
-   long.  The socket interface makes the size of an IP address quite
-   visible to an application; virtually all TCP/IP applications for
-   BSD-based systems have knowledge of the size of an IP address.  Those
-   parts of the API that expose the addresses must be changed to
-   accommodate the larger IPv6 address size.  IPv6 also introduces new
-   features, some of which must be made visible to applications via the
-   API.  This memo defines a set of extensions to the socket interface
-   to support the larger address size and new features of IPv6.  It
-   defines "basic" extensions that are of use to a broad range of
-   applications.  A companion document, the "advanced" API [4], covers
-   extensions that are of use to more specialized applications, examples
-   of which include routing daemons, and the "ping" and "traceroute"
-   utilities.
-
-   The development of this API was started in 1994 in the IETF IPng
-   working group.  The API has evolved over the years, published first
-   in RFC 2133, then again in RFC 2553, and reaching its final form in
-   this document.
-
-   As the API matured and stabilized, it was incorporated into the Open
-   Group's Networking Services (XNS) specification, issue 5.2, which was
-   subsequently incorporated into a joint Open Group/IEEE/ISO standard
-   [3].
-
-   Effort has been made to ensure that this document and [3] contain the
-   same information with regard to the API definitions.  However, the
-   reader should note that this document is for informational purposes
-   only, and that the official standard specification of the sockets API
-   is [3].
-
-   It is expected that any future standardization work on this API would
-   be done by the Open Group Base Working Group [6].
-
-   It should also be noted that this document describes only those
-   portions of the API needed for IPv4 and IPv6 communications.  Other
-   potential uses of the API, for example the use of getaddrinfo() and
-   getnameinfo() with the AF_UNIX address family, are beyond the scope
-   of this document.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 3]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-2. Design Considerations
-
-   There are a number of important considerations in designing changes
-   to this well-worn API:
-
-   -  The API changes should provide both source and binary
-      compatibility for programs written to the original API.  That is,
-      existing program binaries should continue to operate when run on a
-      system supporting the new API.  In addition, existing applications
-      that are re-compiled and run on a system supporting the new API
-      should continue to operate.  Simply put, the API changes for IPv6
-      should not break existing programs.  An additional mechanism for
-      implementations to verify this is to verify the new symbols are
-      protected by Feature Test Macros as described in [3].  (Such
-      Feature Test Macros are not defined by this RFC.)
-
-   -  The changes to the API should be as small as possible in order to
-      simplify the task of converting existing IPv4 applications to
-      IPv6.
-
-   -  Where possible, applications should be able to use this API to
-      interoperate with both IPv6 and IPv4 hosts.  Applications should
-      not need to know which type of host they are communicating with.
-
-   -  IPv6 addresses carried in data structures should be 64-bit
-      aligned.  This is necessary in order to obtain optimum performance
-      on 64-bit machine architectures.
-
-   Because of the importance of providing IPv4 compatibility in the API,
-   these extensions are explicitly designed to operate on machines that
-   provide complete support for both IPv4 and IPv6.  A subset of this
-   API could probably be designed for operation on systems that support
-   only IPv6.  However, this is not addressed in this memo.
-
-2.1 What Needs to be Changed
-
-   The socket interface API consists of a few distinct components:
-
-   -  Core socket functions.
-
-   -  Address data structures.
-
-   -  Name-to-address translation functions.
-
-   -  Address conversion functions.
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 4]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   The core socket functions -- those functions that deal with such
-   things as setting up and tearing down TCP connections, and sending
-   and receiving UDP packets -- were designed to be transport
-   independent.  Where protocol addresses are passed as function
-   arguments, they are carried via opaque pointers.  A protocol-specific
-   address data structure is defined for each protocol that the socket
-   functions support.  Applications must cast pointers to these
-   protocol-specific address structures into pointers to the generic
-   "sockaddr" address structure when using the socket functions.  These
-   functions need not change for IPv6, but a new IPv6-specific address
-   data structure is needed.
-
-   The "sockaddr_in" structure is the protocol-specific data structure
-   for IPv4.  This data structure actually includes 8-octets of unused
-   space, and it is tempting to try to use this space to adapt the
-   sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
-   structure is not large enough to hold the 16-octet IPv6 address as
-   well as the other information (address family and port number) that
-   is needed.  So a new address data structure must be defined for IPv6.
-
-   IPv6 addresses are scoped [2] so they could be link-local, site,
-   organization, global, or other scopes at this time undefined.  To
-   support applications that want to be able to identify a set of
-   interfaces for a specific scope, the IPv6 sockaddr_in structure must
-   support a field that can be used by an implementation to identify a
-   set of interfaces identifying the scope for an IPv6 address.
-
-   The IPv4 name-to-address translation functions in the socket
-   interface are gethostbyname() and gethostbyaddr().  These are left as
-   is, and new functions are defined which support both IPv4 and IPv6.
-
-   The IPv4 address conversion functions -- inet_ntoa() and inet_addr()
-   -- convert IPv4 addresses between binary and printable form.  These
-   functions are quite specific to 32-bit IPv4 addresses.  We have
-   designed two analogous functions that convert both IPv4 and IPv6
-   addresses, and carry an address type parameter so that they can be
-   extended to other protocol families as well.
-
-   Finally, a few miscellaneous features are needed to support IPv6.  A
-   new interface is needed to support the IPv6 hop limit header field.
-   New socket options are needed to control the sending and receiving of
-   IPv6 multicast packets.
-
-   The socket interface will be enhanced in the future to provide access
-   to other IPv6 features.  Some of these extensions are described in
-   [4].
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 5]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-2.2 Data Types
-
-   The data types of the structure elements given in this memo are
-   intended to track the relevant standards.  uintN_t means an unsigned
-   integer of exactly N bits (e.g., uint16_t).  The sa_family_t and
-   in_port_t types are defined in [3].
-
-2.3 Headers
-
-   When function prototypes and structures are shown we show the headers
-   that must be #included to cause that item to be defined.
-
-2.4 Structures
-
-   When structures are described the members shown are the ones that
-   must appear in an implementation.  Additional, nonstandard members
-   may also be defined by an implementation.  As an additional
-   precaution nonstandard members could be verified by Feature Test
-   Macros as described in [3].  (Such Feature Test Macros are not
-   defined by this RFC.)
-
-   The ordering shown for the members of a structure is the recommended
-   ordering, given alignment considerations of multibyte members, but an
-   implementation may order the members differently.
-
-3. Socket Interface
-
-   This section specifies the socket interface changes for IPv6.
-
-3.1 IPv6 Address Family and Protocol Family
-
-   A new address family name, AF_INET6, is defined in <sys/socket.h>.
-   The AF_INET6 definition distinguishes between the original
-   sockaddr_in address data structure, and the new sockaddr_in6 data
-   structure.
-
-   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
-   Like most of the other protocol family names, this will usually be
-   defined to have the same value as the corresponding address family
-   name:
-
-      #define PF_INET6        AF_INET6
-
-   The AF_INET6 is used in the first argument to the socket() function
-   to indicate that an IPv6 socket is being created.
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 6]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-3.2 IPv6 Address Structure
-
-   A new in6_addr structure holds a single IPv6 address and is defined
-   as a result of including <netinet/in.h>:
-
-      struct in6_addr {
-          uint8_t  s6_addr[16];      /* IPv6 address */
-      };
-
-   This data structure contains an array of sixteen 8-bit elements,
-   which make up one 128-bit IPv6 address.  The IPv6 address is stored
-   in network byte order.
-
-   The structure in6_addr above is usually implemented with an embedded
-   union with extra fields that force the desired alignment level in a
-   manner similar to BSD implementations of "struct in_addr".  Those
-   additional implementation details are omitted here for simplicity.
-
-   An example is as follows:
-
-   struct in6_addr {
-        union {
-            uint8_t  _S6_u8[16];
-            uint32_t _S6_u32[4];
-            uint64_t _S6_u64[2];
-        } _S6_un;
-   };
-   #define s6_addr _S6_un._S6_u8
-
-3.3 Socket Address Structure for 4.3BSD-Based Systems
-
-   In the socket interface, a different protocol-specific data structure
-   is defined to carry the addresses for each protocol suite.  Each
-   protocol-specific data structure is designed so it can be cast into a
-   protocol-independent data structure -- the "sockaddr" structure.
-   Each has a "family" field that overlays the "sa_family" of the
-   sockaddr data structure.  This field identifies the type of the data
-   structure.
-
-   The sockaddr_in structure is the protocol-specific address data
-   structure for IPv4.  It is used to pass addresses between
-   applications and the system in the socket functions.  The following
-   sockaddr_in6 structure holds IPv6 addresses and is defined as a
-   result of including the <netinet/in.h> header:
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 7]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-struct sockaddr_in6 {
-    sa_family_t     sin6_family;    /* AF_INET6 */
-    in_port_t       sin6_port;      /* transport layer port # */
-    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
-    struct in6_addr sin6_addr;      /* IPv6 address */
-    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
-};
-
-   This structure is designed to be compatible with the sockaddr data
-   structure used in the 4.3BSD release.
-
-   The sin6_family field identifies this as a sockaddr_in6 structure.
-   This field overlays the sa_family field when the buffer is cast to a
-   sockaddr data structure.  The value of this field must be AF_INET6.
-
-   The sin6_port field contains the 16-bit UDP or TCP port number.  This
-   field is used in the same way as the sin_port field of the
-   sockaddr_in structure.  The port number is stored in network byte
-   order.
-
-   The sin6_flowinfo field is a 32-bit field intended to contain flow-
-   related information.  The exact way this field is mapped to or from a
-   packet is not currently specified.  Until such time as its use is
-   specified, applications should set this field to zero when
-   constructing a sockaddr_in6, and ignore this field in a sockaddr_in6
-   structure constructed by the system.
-
-   The sin6_addr field is a single in6_addr structure (defined in the
-   previous section).  This field holds one 128-bit IPv6 address.  The
-   address is stored in network byte order.
-
-   The ordering of elements in this structure is specifically designed
-   so that when sin6_addr field is aligned on a 64-bit boundary, the
-   start of the structure will also be aligned on a 64-bit boundary.
-   This is done for optimum performance on 64-bit architectures.
-
-   The sin6_scope_id field is a 32-bit integer that identifies a set of
-   interfaces as appropriate for the scope [2] of the address carried in
-   the sin6_addr field.  The mapping of sin6_scope_id to an interface or
-   set of interfaces is left to implementation and future specifications
-   on the subject of scoped addresses.
-
-   Notice that the sockaddr_in6 structure will normally be larger than
-   the generic sockaddr structure.  On many existing implementations the
-   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
-   being 16 bytes.  Any existing code that makes this assumption needs
-   to be examined carefully when converting to IPv6.
-
-
-
-
-Gilligan, et al.             Informational                      [Page 8]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-3.4 Socket Address Structure for 4.4BSD-Based Systems
-
-   The 4.4BSD release includes a small, but incompatible change to the
-   socket interface.  The "sa_family" field of the sockaddr data
-   structure was changed from a 16-bit value to an 8-bit value, and the
-   space saved used to hold a length field, named "sa_len".  The
-   sockaddr_in6 data structure given in the previous section cannot be
-   correctly cast into the newer sockaddr data structure.  For this
-   reason, the following alternative IPv6 address data structure is
-   provided to be used on systems based on 4.4BSD.  It is defined as a
-   result of including the <netinet/in.h> header.
-
-struct sockaddr_in6 {
-    uint8_t         sin6_len;       /* length of this struct */
-    sa_family_t     sin6_family;    /* AF_INET6 */
-    in_port_t       sin6_port;      /* transport layer port # */
-    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
-    struct in6_addr sin6_addr;      /* IPv6 address */
-    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
-};
-
-   The only differences between this data structure and the 4.3BSD
-   variant are the inclusion of the length field, and the change of the
-   family field to a 8-bit data type.  The definitions of all the other
-   fields are identical to the structure defined in the previous
-   section.
-
-   Systems that provide this version of the sockaddr_in6 data structure
-   must also declare SIN6_LEN as a result of including the
-   <netinet/in.h> header.  This macro allows applications to determine
-   whether they are being built on a system that supports the 4.3BSD or
-   4.4BSD variants of the data structure.
-
-3.5 The Socket Functions
-
-   Applications call the socket() function to create a socket descriptor
-   that represents a communication endpoint.  The arguments to the
-   socket() function tell the system which protocol to use, and what
-   format address structure will be used in subsequent functions.  For
-   example, to create an IPv4/TCP socket, applications make the call:
-
-      s = socket(AF_INET, SOCK_STREAM, 0);
-
-   To create an IPv4/UDP socket, applications make the call:
-
-      s = socket(AF_INET, SOCK_DGRAM, 0);
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 9]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Applications may create IPv6/TCP and IPv6/UDP sockets (which may also
-   handle IPv4 communication as described in section 3.7) by simply
-   using the constant AF_INET6 instead of AF_INET in the first argument.
-   For example, to create an IPv6/TCP socket, applications make the
-   call:
-
-      s = socket(AF_INET6, SOCK_STREAM, 0);
-
-   To create an IPv6/UDP socket, applications make the call:
-
-      s = socket(AF_INET6, SOCK_DGRAM, 0);
-
-   Once the application has created a AF_INET6 socket, it must use the
-   sockaddr_in6 address structure when passing addresses in to the
-   system.  The functions that the application uses to pass addresses
-   into the system are:
-
-      bind()
-      connect()
-      sendmsg()
-      sendto()
-
-   The system will use the sockaddr_in6 address structure to return
-   addresses to applications that are using AF_INET6 sockets.  The
-   functions that return an address from the system to an application
-   are:
-
-      accept()
-      recvfrom()
-      recvmsg()
-      getpeername()
-      getsockname()
-
-   No changes to the syntax of the socket functions are needed to
-   support IPv6, since all of the "address carrying" functions use an
-   opaque address pointer, and carry an address length as a function
-   argument.
-
-3.6 Compatibility with IPv4 Applications
-
-   In order to support the large base of applications using the original
-   API, system implementations must provide complete source and binary
-   compatibility with the original API.  This means that systems must
-   continue to support AF_INET sockets and the sockaddr_in address
-   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
-   sockets using the AF_INET constant in the socket() function, as
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 10]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   described in the previous section.  Applications should be able to
-   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
-   sockets simultaneously within the same process.
-
-   Applications using the original API should continue to operate as
-   they did on systems supporting only IPv4.  That is, they should
-   continue to interoperate with IPv4 nodes.
-
-3.7 Compatibility with IPv4 Nodes
-
-   The API also provides a different type of compatibility: the ability
-   for IPv6 applications to interoperate with IPv4 applications.  This
-   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
-   addressing architecture specification [2].  This address format
-   allows the IPv4 address of an IPv4 node to be represented as an IPv6
-   address.  The IPv4 address is encoded into the low-order 32 bits of
-   the IPv6 address, and the high-order 96 bits hold the fixed prefix
-   0:0:0:0:0:FFFF.  IPv4-mapped addresses are written as follows:
-
-      ::FFFF:<IPv4-address>
-
-   These addresses can be generated automatically by the getaddrinfo()
-   function, as described in Section 6.1.
-
-   Applications may use AF_INET6 sockets to open TCP connections to IPv4
-   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
-   destination's IPv4 address as an IPv4-mapped IPv6 address, and
-   passing that address, within a sockaddr_in6 structure, in the
-   connect() or sendto() call.  When applications use AF_INET6 sockets
-   to accept TCP connections from IPv4 nodes, or receive UDP packets
-   from IPv4 nodes, the system returns the peer's address to the
-   application in the accept(), recvfrom(), or getpeername() call using
-   a sockaddr_in6 structure encoded this way.
-
-   Few applications will likely need to know which type of node they are
-   interoperating with.  However, for those applications that do need to
-   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.4, is
-   provided.
-
-3.8 IPv6 Wildcard Address
-
-   While the bind() function allows applications to select the source IP
-   address of UDP packets and TCP connections, applications often want
-   the system to select the source address for them.  With IPv4, one
-   specifies the address as the symbolic constant INADDR_ANY (called the
-   "wildcard" address) in the bind() call, or simply omits the bind()
-   entirely.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 11]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Since the IPv6 address type is a structure (struct in6_addr), a
-   symbolic constant can be used to initialize an IPv6 address variable,
-   but cannot be used in an assignment.  Therefore systems provide the
-   IPv6 wildcard address in two forms.
-
-   The first version is a global variable named "in6addr_any" that is an
-   in6_addr structure.  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-      extern const struct in6_addr in6addr_any;
-
-   Applications use in6addr_any similarly to the way they use INADDR_ANY
-   in IPv4.  For example, to bind a socket to port number 23, but let
-   the system select the source address, an application could use the
-   following code:
-
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_family = AF_INET6;
-      sin6.sin6_flowinfo = 0;
-      sin6.sin6_port = htons(23);
-      sin6.sin6_addr = in6addr_any;  /* structure assignment */
-       . . .
-      if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-              . . .
-
-   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
-   is defined in <netinet/in.h>.  This constant can be used to
-   initialize an in6_addr structure:
-
-      struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
-   Note that this constant can be used ONLY at declaration time.  It can
-   not be used to assign a previously declared in6_addr structure.  For
-   example, the following code will not work:
-
-      /* This is the WRONG way to assign an unspecified address */
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
-   Be aware that the IPv4 INADDR_xxx constants are all defined in host
-   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
-   in6addr_xxx externals are defined in network byte order.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 12]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-3.9 IPv6 Loopback Address
-
-   Applications may need to send UDP packets to, or originate TCP
-   connections to, services residing on the local node.  In IPv4, they
-   can do this by using the constant IPv4 address INADDR_LOOPBACK in
-   their connect(), sendto(), or sendmsg() call.
-
-   IPv6 also provides a loopback address to contact local TCP and UDP
-   services.  Like the unspecified address, the IPv6 loopback address is
-   provided in two forms -- a global variable and a symbolic constant.
-
-   The global variable is an in6_addr structure named
-   "in6addr_loopback."  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-      extern const struct in6_addr in6addr_loopback;
-
-   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
-   in IPv4 applications (but beware of the byte ordering difference
-   mentioned at the end of the previous section).  For example, to open
-   a TCP connection to the local telnet server, an application could use
-   the following code:
-
-   struct sockaddr_in6 sin6;
-    . . .
-   sin6.sin6_family = AF_INET6;
-   sin6.sin6_flowinfo = 0;
-   sin6.sin6_port = htons(23);
-   sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
-    . . .
-   if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-           . . .
-
-   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
-   in <netinet/in.h>.  It can be used at declaration time ONLY; for
-   example:
-
-      struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
-   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
-   to a previously declared IPv6 address variable.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 13]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-3.10 Portability Additions
-
-   One simple addition to the sockets API that can help application
-   writers is the "struct sockaddr_storage".  This data structure can
-   simplify writing code that is portable across multiple address
-   families and platforms.  This data structure is designed with the
-   following goals.
-
-   - Large enough to accommodate all supported protocol-specific address
-      structures.
-
-   - Aligned at an appropriate boundary so that pointers to it can be
-      cast as pointers to protocol specific address structures and used
-      to access the fields of those structures without alignment
-      problems.
-
-   The sockaddr_storage structure contains field ss_family which is of
-   type sa_family_t.  When a sockaddr_storage structure is cast to a
-   sockaddr structure, the ss_family field of the sockaddr_storage
-   structure maps onto the sa_family field of the sockaddr structure.
-   When a sockaddr_storage structure is cast as a protocol specific
-   address structure, the ss_family field maps onto a field of that
-   structure that is of type sa_family_t and that identifies the
-   protocol's address family.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 14]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   An example implementation design of such a data structure would be as
-   follows.
-
-/*
- * Desired design of maximum size and alignment
- */
-#define _SS_MAXSIZE    128  /* Implementation specific max size */
-#define _SS_ALIGNSIZE  (sizeof (int64_t))
-                         /* Implementation specific desired alignment */
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE   (_SS_ALIGNSIZE - sizeof (sa_family_t))
-#define _SS_PAD2SIZE   (_SS_MAXSIZE - (sizeof (sa_family_t) +
-                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
-    sa_family_t  ss_family;     /* address family */
-    /* Following fields are implementation specific */
-    char      __ss_pad1[_SS_PAD1SIZE];
-              /* 6 byte pad, this is to make implementation
-              /* specific pad up to alignment field that */
-              /* follows explicit in the data structure */
-    int64_t   __ss_align;     /* field to force desired structure */
-               /* storage alignment */
-    char      __ss_pad2[_SS_PAD2SIZE];
-              /* 112 byte pad to achieve desired size, */
-              /* _SS_MAXSIZE value minus size of ss_family */
-              /* __ss_pad1, __ss_align fields is 112 */
-};
-
-   The above example implementation illustrates a data structure which
-   will align on a 64-bit boundary.  An implementation-specific field
-   "__ss_align" along with "__ss_pad1" is used to force a 64-bit
-   alignment which covers proper alignment good enough for the needs of
-   sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures.  The
-   size of padding field __ss_pad1 depends on the chosen alignment
-   boundary.  The size of padding field __ss_pad2 depends on the value
-   of overall size chosen for the total size of the structure.  This
-   size and alignment are represented in the above example by
-   implementation specific (not required) constants _SS_MAXSIZE (chosen
-   value 128) and _SS_ALIGNSIZE (with chosen value 8).  Constants
-   _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112)
-   are also for illustration and not required.  The derived values
-   assume sa_family_t is 2 bytes.  The implementation specific
-   definitions and structure field names above start with an underscore
-   to denote implementation private namespace.  Portable code is not
-   expected to access or reference those fields or constants.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 15]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   On implementations where the sockaddr data structure includes a
-   "sa_len" field this data structure would look like this:
-
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
-                            (sizeof (uint8_t) + sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE -
-                            (sizeof (uint8_t) + sizeof (sa_family_t) +
-                             _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
-    uint8_t      ss_len;        /* address length */
-    sa_family_t  ss_family;     /* address family */
-    /* Following fields are implementation specific */
-    char         __ss_pad1[_SS_PAD1SIZE];
-                  /* 6 byte pad, this is to make implementation
-                  /* specific pad up to alignment field that */
-                  /* follows explicit in the data structure */
-    int64_t      __ss_align;  /* field to force desired structure */
-                  /* storage alignment */
-    char         __ss_pad2[_SS_PAD2SIZE];
-                  /* 112 byte pad to achieve desired size, */
-                  /* _SS_MAXSIZE value minus size of ss_len, */
-                  /* __ss_family, __ss_pad1, __ss_align fields is 112 */
-};
-
-4. Interface Identification
-
-   This API uses an interface index (a small positive integer) to
-   identify the local interface on which a multicast group is joined
-   (Section 5.2).  Additionally, the advanced API [4] uses these same
-   interface indexes to identify the interface on which a datagram is
-   received, or to specify the interface on which a datagram is to be
-   sent.
-
-   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
-   and the like.  On Berkeley-derived implementations, when an interface
-   is made known to the system, the kernel assigns a unique positive
-   integer value (called the interface index) to that interface.  These
-   are small positive integers that start at 1.  (Note that 0 is never
-   used for an interface index.)  There may be gaps so that there is no
-   current interface for a particular positive interface index.
-
-   This API defines two functions that map between an interface name and
-   index, a third function that returns all the interface names and
-   indexes, and a fourth function to return the dynamic memory allocated
-   by the previous function.  How these functions are implemented is
-
-
-
-Gilligan, et al.             Informational                     [Page 16]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   left up to the implementation.  4.4BSD implementations can implement
-   these functions using the existing sysctl() function with the
-   NET_RT_IFLIST command.  Other implementations may wish to use ioctl()
-   for this purpose.
-
-4.1 Name-to-Index
-
-   The first function maps an interface name into its corresponding
-   index.
-
-      #include <net/if.h>
-
-      unsigned int  if_nametoindex(const char *ifname);
-
-   If ifname is the name of an interface, the if_nametoindex() function
-   shall return the interface index corresponding to name ifname;
-   otherwise, it shall return zero.  No errors are defined.
-
-4.2 Index-to-Name
-
-   The second function maps an interface index into its corresponding
-   name.
-
-      #include <net/if.h>
-
-      char  *if_indextoname(unsigned int ifindex, char *ifname);
-
-   When this function is called, the ifname argument shall point to a
-   buffer of at least IF_NAMESIZE bytes.  The function shall place in
-   this buffer the name of the interface with index ifindex.
-   (IF_NAMESIZE is also defined in <net/if.h> and its value includes a
-   terminating null byte at the end of the interface name.)  If ifindex
-   is an interface index, then the function shall return the value
-   supplied in ifname, which points to a buffer now containing the
-   interface name.  Otherwise, the function shall return a NULL pointer
-   and set errno to indicate the error.  If there is no interface
-   corresponding to the specified index, errno is set to ENXIO.  If
-   there was a system error (such as running out of memory), errno would
-   be set to the proper value (e.g., ENOMEM).
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 17]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-4.3 Return All Interface Names and Indexes
-
-   The if_nameindex structure holds the information about a single
-   interface and is defined as a result of including the <net/if.h>
-   header.
-
-   struct if_nameindex {
-     unsigned int   if_index;  /* 1, 2, ... */
-     char          *if_name;   /* null terminated name: "le0", ... */
-   };
-
-   The final function returns an array of if_nameindex structures, one
-   structure per interface.
-
-      #include <net/if.h>
-
-      struct if_nameindex  *if_nameindex(void);
-
-   The end of the array of structures is indicated by a structure with
-   an if_index of 0 and an if_name of NULL.  The function returns a NULL
-   pointer upon an error, and would set errno to the appropriate value.
-
-   The memory used for this array of structures along with the interface
-   names pointed to by the if_name members is obtained dynamically.
-   This memory is freed by the next function.
-
-4.4 Free Memory
-
-   The following function frees the dynamic memory that was allocated by
-   if_nameindex().
-
-      #include <net/if.h>
-
-      void  if_freenameindex(struct if_nameindex *ptr);
-
-   The ptr argument shall be a pointer that was returned by
-   if_nameindex().  After if_freenameindex() has been called, the
-   application shall not use the array of which ptr is the address.
-
-5. Socket Options
-
-   A number of new socket options are defined for IPv6.  All of these
-   new options are at the IPPROTO_IPV6 level.  That is, the "level"
-   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
-   when using these options.  The constant name prefix IPV6_ is used in
-   all of the new socket options.  This serves to clearly identify these
-   options as applying to IPv6.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 18]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
-   related constants defined in this section are obtained by including
-   the header <netinet/in.h>.
-
-5.1 Unicast Hop Limit
-
-   A new setsockopt() option controls the hop limit used in outgoing
-   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
-   and it is used at the IPPROTO_IPV6 layer.  The following example
-   illustrates how it is used:
-
-   int  hoplimit = 10;
-
-   if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                  (char *) &hoplimit, sizeof(hoplimit)) == -1)
-       perror("setsockopt IPV6_UNICAST_HOPS");
-
-   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
-   option value given is used as the hop limit for all subsequent
-   unicast packets sent via that socket.  If the option is not set, the
-   system selects a default value.  The integer hop limit value (called
-   x) is interpreted as follows:
-
-      x < -1:        return an error of EINVAL
-      x == -1:       use kernel default
-      0 <= x <= 255: use x
-      x >= 256:      return an error of EINVAL
-
-   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
-   determine the hop limit value that the system will use for subsequent
-   unicast packets sent via that socket.  For example:
-
-      int  hoplimit;
-      socklen_t  len = sizeof(hoplimit);
-
-      if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                     (char *) &hoplimit, &len) == -1)
-          perror("getsockopt IPV6_UNICAST_HOPS");
-      else
-          printf("Using %d for hop limit.\n", hoplimit);
-
-5.2 Sending and Receiving Multicast Packets
-
-   IPv6 applications may send multicast packets by simply specifying an
-   IPv6 multicast address as the destination address, for example in the
-   destination address argument of the sendto() function.
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 19]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Three socket options at the IPPROTO_IPV6 layer control some of the
-   parameters for sending multicast packets.  Setting these options is
-   not required: applications may send multicast packets without using
-   these options.  The setsockopt() options for controlling the sending
-   of multicast packets are summarized below.  These three options can
-   also be used with getsockopt().
-
-      IPV6_MULTICAST_IF
-
-         Set the interface to use for outgoing multicast packets.  The
-         argument is the index of the interface to use.  If the
-         interface index is specified as zero, the system selects the
-         interface (for example, by looking up the address in a routing
-         table and using the resulting interface).
-
-         Argument type: unsigned int
-
-      IPV6_MULTICAST_HOPS
-
-         Set the hop limit to use for outgoing multicast packets.  (Note
-         a separate option - IPV6_UNICAST_HOPS - is provided to set the
-         hop limit to use for outgoing unicast packets.)
-
-         The interpretation of the argument is the same as for the
-         IPV6_UNICAST_HOPS option:
-
-            x < -1:        return an error of EINVAL
-            x == -1:       use kernel default
-            0 <= x <= 255: use x
-            x >= 256:      return an error of EINVAL
-
-            If IPV6_MULTICAST_HOPS is not set, the default is 1
-            (same as IPv4 today)
-
-         Argument type: int
-
-      IPV6_MULTICAST_LOOP
-
-         If a multicast datagram is sent to a group to which the sending
-         host itself belongs (on the outgoing interface), a copy of the
-         datagram is looped back by the IP layer for local delivery if
-         this option is set to 1.  If this option is set to 0 a copy is
-         not looped back.  Other option values return an error of
-         EINVAL.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 20]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-         If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
-         same as IPv4 today).
-
-         Argument type: unsigned int
-
-   The reception of multicast packets is controlled by the two
-   setsockopt() options summarized below.  An error of EOPNOTSUPP is
-   returned if these two options are used with getsockopt().
-
-      IPV6_JOIN_GROUP
-
-         Join a multicast group on a specified local interface.
-         If the interface index is specified as 0,
-         the kernel chooses the local interface.
-         For example, some kernels look up the multicast group
-         in the normal IPv6 routing table and use the resulting
-         interface.
-
-         Argument type: struct ipv6_mreq
-
-      IPV6_LEAVE_GROUP
-
-         Leave a multicast group on a specified interface.
-         If the interface index is specified as 0, the system
-         may choose a multicast group membership to drop by
-         matching the multicast address only.
-
-         Argument type: struct ipv6_mreq
-
-   The argument type of both of these options is the ipv6_mreq
-   structure, defined as a result of including the <netinet/in.h>
-   header;
-
-   struct ipv6_mreq {
-       struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
-       unsigned int    ipv6mr_interface; /* interface index */
-   };
-
-   Note that to receive multicast datagrams a process must join the
-   multicast group to which datagrams will be sent.  UDP applications
-   must also bind the UDP port to which datagrams will be sent.  Some
-   processes also bind the multicast group address to the socket, in
-   addition to the port, to prevent other datagrams destined to that
-   same port from being delivered to the socket.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 21]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-5.3 IPV6_V6ONLY option for AF_INET6 Sockets
-
-   This socket option restricts AF_INET6 sockets to IPv6 communications
-   only.  As stated in section <3.7 Compatibility with IPv4 Nodes>,
-   AF_INET6 sockets may be used for both IPv4 and IPv6 communications.
-   Some applications may want to restrict their use of an AF_INET6
-   socket to IPv6 communications only.  For these applications the
-   IPV6_V6ONLY socket option is defined.  When this option is turned on,
-   the socket can be used to send and receive IPv6 packets only.  This
-   is an IPPROTO_IPV6 level option.  This option takes an int value.
-   This is a boolean option.  By default this option is turned off.
-
-   Here is an example of setting this option:
-
-      int on = 1;
-
-      if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,
-                     (char *)&on, sizeof(on)) == -1)
-          perror("setsockopt IPV6_V6ONLY");
-      else
-          printf("IPV6_V6ONLY set\n");
-
-   Note - This option has no effect on the use of IPv4 Mapped addresses
-   which enter a node as a valid IPv6 addresses for IPv6 communications
-   as defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5].
-
-   An example use of this option is to allow two versions of the same
-   server process to run on the same port, one providing service over
-   IPv6, the other providing the same service over IPv4.
-
-6. Library Functions
-
-   New library functions are needed to perform a variety of operations
-   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
-   in the Domain Name System (DNS).  Both forward lookup (nodename-to-
-   address translation) and reverse lookup (address-to-nodename
-   translation) need to be supported.  Functions are also needed to
-   convert IPv6 addresses between their binary and textual form.
-
-   We note that the two existing functions, gethostbyname() and
-   gethostbyaddr(), are left as-is.  New functions are defined to handle
-   both IPv4 and IPv6 addresses.
-
-   The commonly used function gethostbyname() is inadequate for many
-   applications, first because it provides no way for the caller to
-   specify anything about the types of addresses desired (IPv4 only,
-   IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
-   implementations of this function are not thread safe.  RFC 2133
-
-
-
-Gilligan, et al.             Informational                     [Page 22]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   defined a function named gethostbyname2() but this function was also
-   inadequate, first because its use required setting a global option
-   (RES_USE_INET6) when IPv6 addresses were required, and second because
-   a flag argument is needed to provide the caller with additional
-   control over the types of addresses required.  The gethostbyname2()
-   function was deprecated in RFC 2553 and is no longer part of the
-   basic API.
-
-6.1 Protocol-Independent Nodename and Service Name Translation
-
-   Nodename-to-address translation is done in a protocol-independent
-   fashion using the getaddrinfo() function.
-
-#include <sys/socket.h>
-#include <netdb.h>
-
-
-int getaddrinfo(const char *nodename, const char *servname,
-                const struct addrinfo *hints, struct addrinfo **res);
-
-void freeaddrinfo(struct addrinfo *ai);
-
-struct addrinfo {
-  int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME,
-                           AI_NUMERICHOST, .. */
-  int     ai_family;    /* AF_xxx */
-  int     ai_socktype;  /* SOCK_xxx */
-  int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
-  socklen_t  ai_addrlen;   /* length of ai_addr */
-  char   *ai_canonname; /* canonical name for nodename */
-  struct sockaddr  *ai_addr; /* binary address */
-  struct addrinfo  *ai_next; /* next structure in linked list */
-};
-
-   The getaddrinfo() function translates the name of a service location
-   (for example, a host name) and/or a service name and returns a set of
-   socket addresses and associated information to be used in creating a
-   socket with which to address the specified service.
-
-   The nodename and servname arguments are either null pointers or
-   pointers to null-terminated strings.  One or both of these two
-   arguments must be a non-null pointer.
-
-   The format of a valid name depends on the address family or families.
-   If a specific family is not given and the name could be interpreted
-   as valid within multiple supported families, the implementation will
-   attempt to resolve the name in all supported families and, in absence
-   of errors, one or more results shall be returned.
-
-
-
-Gilligan, et al.             Informational                     [Page 23]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   If the nodename argument is not null, it can be a descriptive name or
-   can be an address string.  If the specified address family is
-   AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host
-   names. If the specified address family is AF_INET or AF_UNSPEC,
-   address strings using Internet standard dot notation as specified in
-   inet_addr() are valid.  If the specified address family is AF_INET6
-   or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are
-   valid.
-
-   If nodename is not null, the requested service location is named by
-   nodename; otherwise, the requested service location is local to the
-   caller.
-
-   If servname is null, the call shall return network-level addresses
-   for the specified nodename.  If servname is not null, it is a null-
-   terminated character string identifying the requested service.  This
-   can be either a descriptive name or a numeric representation suitable
-   for use with the address family or families.  If the specified
-   address family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be
-   specified as a string specifying a decimal port number.
-
-   If the argument hints is not null, it refers to a structure
-   containing input values that may direct the operation by providing
-   options and by limiting the returned information to a specific socket
-   type, address family and/or protocol.  In this hints structure every
-   member other than ai_flags, ai_family, ai_socktype and ai_protocol
-   shall be set to zero or a null pointer.  A value of AF_UNSPEC for
-   ai_family means that the caller shall accept any address family.  A
-   value of zero for ai_socktype means that the caller shall accept any
-   socket type.  A value of zero for ai_protocol means that the caller
-   shall accept any protocol.  If hints is a null pointer, the behavior
-   shall be as if it referred to a structure containing the value zero
-   for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC
-   for the ai_family field.
-
-   Note:
-
-   1. If the caller handles only TCP and not UDP, for example, then the
-      ai_protocol member of the hints structure should be set to
-      IPPROTO_TCP when getaddrinfo() is called.
-
-   2. If the caller handles only IPv4 and not IPv6, then the ai_family
-      member of the hints structure should be set to AF_INET when
-      getaddrinfo() is called.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 24]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   The ai_flags field to which hints parameter points shall be set to
-   zero or be the bitwise-inclusive OR of one or more of the values
-   AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
-   AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.
-
-   If the AI_PASSIVE flag is specified, the returned address information
-   shall be suitable for use in binding a socket for accepting incoming
-   connections for the specified service (i.e., a call to bind()).  In
-   this case, if the nodename argument is null, then the IP address
-   portion of the socket address structure shall be set to INADDR_ANY
-   for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address.  If the
-   AI_PASSIVE flag is not specified, the returned address information
-   shall be suitable for a call to connect() (for a connection-mode
-   protocol) or for a call to connect(), sendto() or sendmsg() (for a
-   connectionless protocol).  In this case, if the nodename argument is
-   null, then the IP address portion of the socket address structure
-   shall be set to the loopback address.  This flag is ignored if the
-   nodename argument is not null.
-
-   If the AI_CANONNAME flag is specified and the nodename argument is
-   not null, the function shall attempt to determine the canonical name
-   corresponding to nodename (for example, if nodename is an alias or
-   shorthand notation for a complete name).
-
-   If the AI_NUMERICHOST flag is specified, then a non-null nodename
-   string supplied shall be a numeric host address string.  Otherwise,
-   an [EAI_NONAME] error is returned.  This flag shall prevent any type
-   of name resolution service (for example, the DNS) from being invoked.
-
-   If the AI_NUMERICSERV flag is specified, then a non-null servname
-   string supplied shall be a numeric port string.  Otherwise, an
-   [EAI_NONAME] error shall be returned.  This flag shall prevent any
-   type of name resolution service (for example, NIS+) from being
-   invoked.
-
-   If the AI_V4MAPPED flag is specified along with an ai_family of
-   AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses
-   on finding no matching IPv6 addresses (ai_addrlen shall be 16).
-
-      For example, when using the DNS, if no AAAA records are found then
-      a query is made for A records and any found are returned as IPv4-
-      mapped IPv6 addresses.
-
-   The AI_V4MAPPED flag shall be ignored unless ai_family equals
-   AF_INET6.
-
-   If the AI_ALL flag is used with the AI_V4MAPPED flag, then
-   getaddrinfo() shall return all matching IPv6 and IPv4 addresses.
-
-
-
-Gilligan, et al.             Informational                     [Page 25]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-      For example, when using the DNS, queries are made for both AAAA
-      records and A records, and getaddrinfo() returns the combined
-      results of both queries.  Any IPv4 addresses found are returned as
-      IPv4-mapped IPv6 addresses.
-
-   The AI_ALL flag without the AI_V4MAPPED flag is ignored.
-
-      Note:
-
-      When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and
-      AI_ALL flags will only be used if AF_INET6 is supported.
-
-   If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
-   returned only if an IPv4 address is configured on the local system,
-   and IPv6 addresses shall be returned only if an IPv6 address is
-   configured on the local system.  The loopback address is not
-   considered for this case as valid as a configured address.
-
-      For example, when using the DNS, a query for AAAA records should
-      occur only if the node has at least one IPv6 address configured
-      (other than IPv6 loopback) and a query for A records should occur
-      only if the node has at least one IPv4 address configured (other
-      than the IPv4 loopback).
-
-   The ai_socktype field to which argument hints points specifies the
-   socket type for the service, as defined for socket().  If a specific
-   socket type is not given (for example, a value of zero) and the
-   service name could be interpreted as valid with multiple supported
-   socket types, the implementation shall attempt to resolve the service
-   name for all supported socket types and, in the absence of errors,
-   all possible results shall be returned.  A non-zero socket type value
-   shall limit the returned information to values with the specified
-   socket type.
-
-   If the ai_family field to which hints points has the value AF_UNSPEC,
-   addresses shall be returned for use with any address family that can
-   be used with the specified nodename and/or servname.  Otherwise,
-   addresses shall be returned for use only with the specified address
-   family.  If ai_family is not AF_UNSPEC and ai_protocol is not zero,
-   then addresses are returned for use only with the specified address
-   family and protocol; the value of ai_protocol shall be interpreted as
-   in a call to the socket() function with the corresponding values of
-   ai_family and ai_protocol.
-
-   The freeaddrinfo() function frees one or more addrinfo structures
-   returned by getaddrinfo(), along with any additional storage
-   associated with those structures (for example, storage pointed to by
-   the ai_canonname and ai_addr fields; an application must not
-
-
-
-Gilligan, et al.             Informational                     [Page 26]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   reference this storage after the associated addrinfo structure has
-   been freed).  If the ai_next field of the structure is not null, the
-   entire list of structures is freed.  The freeaddrinfo() function must
-   support the freeing of arbitrary sublists of an addrinfo list
-   originally returned by getaddrinfo().
-
-   Functions getaddrinfo() and freeaddrinfo() must be thread-safe.
-
-   A zero return value for getaddrinfo() indicates successful
-   completion; a non-zero return value indicates failure.  The possible
-   values for the failures are listed below under Error Return Values.
-
-   Upon successful return of getaddrinfo(), the location to which res
-   points shall refer to a linked list of addrinfo structures, each of
-   which shall specify a socket address and information for use in
-   creating a socket with which to use that socket address.  The list
-   shall include at least one addrinfo structure.  The ai_next field of
-   each structure contains a pointer to the next structure on the list,
-   or a null pointer if it is the last structure on the list.  Each
-   structure on the list shall include values for use with a call to the
-   socket() function, and a socket address for use with the connect()
-   function or, if the AI_PASSIVE flag was specified, for use with the
-   bind() function.  The fields ai_family, ai_socktype, and ai_protocol
-   shall be usable as the arguments to the socket() function to create a
-   socket suitable for use with the returned address.  The fields
-   ai_addr and ai_addrlen are usable as the arguments to the connect()
-   or bind() functions with such a socket, according to the AI_PASSIVE
-   flag.
-
-   If nodename is not null, and if requested by the AI_CANONNAME flag,
-   the ai_canonname field of the first returned addrinfo structure shall
-   point to a null-terminated string containing the canonical name
-   corresponding to the input nodename; if the canonical name is not
-   available, then ai_canonname shall refer to the nodename argument or
-   a string with the same contents.  The contents of the ai_flags field
-   of the returned structures are undefined.
-
-   All fields in socket address structures returned by getaddrinfo()
-   that are not filled in through an explicit argument (for example,
-   sin6_flowinfo) shall be set to zero.
-
-   Note: This makes it easier to compare socket address structures.
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 27]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Error Return Values:
-
-   The getaddrinfo() function shall fail and return the corresponding
-   value if:
-
-   [EAI_AGAIN]     The name could not be resolved at this time.  Future
-                   attempts may succeed.
-
-   [EAI_BADFLAGS]  The flags parameter had an invalid value.
-
-   [EAI_FAIL]      A non-recoverable error occurred when attempting to
-                   resolve the name.
-
-   [EAI_FAMILY]    The address family was not recognized.
-
-   [EAI_MEMORY]    There was a memory allocation failure when trying to
-                   allocate storage for the return value.
-
-   [EAI_NONAME]    The name does not resolve for the supplied
-                   parameters.  Neither nodename nor servname were
-                   supplied.  At least one of these must be supplied.
-
-   [EAI_SERVICE]   The service passed was not recognized for the
-                   specified socket type.
-
-   [EAI_SOCKTYPE]  The intended socket type was not recognized.
-
-   [EAI_SYSTEM]    A system error occurred; the error code can be found
-                   in errno.
-
-   The gai_strerror() function provides a descriptive text string
-   corresponding to an EAI_xxx error value.
-
-      #include <netdb.h>
-
-      const char *gai_strerror(int ecode);
-
-   The argument is one of the EAI_xxx values defined for the
-   getaddrinfo() and getnameinfo() functions.  The return value points
-   to a string describing the error.  If the argument is not one of the
-   EAI_xxx values, the function still returns a pointer to a string
-   whose contents indicate an unknown error.
-
-6.2 Socket Address Structure to Node Name and Service Name
-
-   The getnameinfo() function is used to translate the contents of a
-   socket address structure to a node name and/or service name.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 28]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   #include <sys/socket.h>
-   #include <netdb.h>
-
-   int getnameinfo(const struct sockaddr *sa, socklen_t salen,
-                       char *node, socklen_t nodelen,
-                       char *service, socklen_t servicelen,
-                         int flags);
-
-   The getnameinfo() function shall translate a socket address to a node
-   name and service location, all of which are defined as in
-   getaddrinfo().
-
-   The sa argument points to a socket address structure to be
-   translated.
-
-   The salen argument holds the size of the socket address structure
-   pointed to by sa.
-
-   If the socket address structure contains an IPv4-mapped IPv6 address
-   or an IPv4-compatible IPv6 address, the implementation shall extract
-   the embedded IPv4 address and lookup the node name for that IPv4
-   address.
-
-      Note: The IPv6 unspecified address ("::") and the IPv6 loopback
-      address ("::1") are not IPv4-compatible addresses.  If the address
-      is the IPv6 unspecified address ("::"), a lookup is not performed,
-      and the [EAI_NONAME] error is returned.
-
-   If the node argument is non-NULL and the nodelen argument is nonzero,
-   then the node argument points to a buffer able to contain up to
-   nodelen characters that receives the node name as a null-terminated
-   string.  If the node argument is NULL or the nodelen argument is
-   zero, the node name shall not be returned.  If the node's name cannot
-   be located, the numeric form of the node's address is returned
-   instead of its name.
-
-   If the service argument is non-NULL and the servicelen argument is
-   non-zero, then the service argument points to a buffer able to
-   contain up to servicelen bytes that receives the service name as a
-   null-terminated string.  If the service argument is NULL or the
-   servicelen argument is zero, the service name shall not be returned.
-   If the service's name cannot be located, the numeric form of the
-   service address (for example, its port number) shall be returned
-   instead of its name.
-
-   The arguments node and service cannot both be NULL.
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 29]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   The flags argument is a flag that changes the default actions of the
-   function.  By default the fully-qualified domain name (FQDN) for the
-   host shall be returned, but:
-
-   -  If the flag bit NI_NOFQDN is set, only the node name portion of
-      the FQDN shall be returned for local hosts.
-
-   -  If the flag bit NI_NUMERICHOST is set, the numeric form of the
-      host's address shall be returned instead of its name, under all
-      circumstances.
-
-   -  If the flag bit NI_NAMEREQD is set, an error shall be returned if
-      the host's name cannot be located.
-
-   -  If the flag bit NI_NUMERICSERV is set, the numeric form of the
-      service address shall be returned (for example, its port number)
-      instead of its name, under all circumstances.
-
-   -  If the flag bit NI_DGRAM is set, this indicates that the service
-      is a datagram service (SOCK_DGRAM).  The default behavior shall
-      assume that the service is a stream service (SOCK_STREAM).
-
-   Note:
-
-   1. The NI_NUMERICxxx flags are required to support the "-n" flags
-      that many commands provide.
-
-   2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6
-      port numbers (for example, [512,514]) that represent different
-      services for UDP and TCP.
-
-   The getnameinfo() function shall be thread safe.
-
-   A zero return value for getnameinfo() indicates successful
-   completion; a non-zero return value indicates failure.
-
-   Upon successful completion, getnameinfo() shall return the node and
-   service names, if requested, in the buffers provided.  The returned
-   names are always null-terminated strings.
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 30]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Error Return Values:
-
-   The getnameinfo() function shall fail and return the corresponding
-   value if:
-
-   [EAI_AGAIN]    The name could not be resolved at this time.
-                  Future attempts may succeed.
-
-   [EAI_BADFLAGS] The flags had an invalid value.
-
-   [EAI_FAIL]     A non-recoverable error occurred.
-
-   [EAI_FAMILY]   The address family was not recognized or the address
-                  length was invalid for the specified family.
-
-   [EAI_MEMORY]   There was a memory allocation failure.
-
-   [EAI_NONAME]   The name does not resolve for the supplied parameters.
-                  NI_NAMEREQD is set and the host's name cannot be
-                  located, or both nodename and servname were null.
-
-   [EAI_OVERFLOW] An argument buffer overflowed.
-
-   [EAI_SYSTEM]   A system error occurred.  The error code can be found
-                  in errno.
-
-6.3 Address Conversion Functions
-
-   The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4
-   address between binary and text form.  IPv6 applications need similar
-   functions.  The following two functions convert both IPv6 and IPv4
-   addresses:
-
-   #include <arpa/inet.h>
-
-   int inet_pton(int af, const char *src, void *dst);
-
-   const char *inet_ntop(int af, const void *src,
-                            char *dst, socklen_t size);
-
-   The inet_pton() function shall convert an address in its standard
-   text presentation form into its numeric binary form.  The af argument
-   shall specify the family of the address.  The AF_INET and AF_INET6
-   address families shall be supported.  The src argument points to the
-   string being passed in.  The dst argument points to a buffer into
-   which the function stores the numeric address; this shall be large
-   enough to hold the numeric address (32 bits for AF_INET, 128 bits for
-   AF_INET6).  The inet_pton() function shall return 1 if the conversion
-
-
-
-Gilligan, et al.             Informational                     [Page 31]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   succeeds, with the address pointed to by dst in network byte order.
-   It shall return 0 if the input is not a valid IPv4 dotted-decimal
-   string or a valid IPv6 address string, or -1 with errno set to
-   EAFNOSUPPORT if the af argument is unknown.
-
-   If the af argument of inet_pton() is AF_INET, the src string shall be
-   in the standard IPv4 dotted-decimal form:
-
-      ddd.ddd.ddd.ddd
-
-   where "ddd" is a one to three digit decimal number between 0 and 255.
-   The inet_pton() function does not accept other formats (such as the
-   octal numbers, hexadecimal numbers, and fewer than four numbers that
-   inet_addr() accepts).
-
-   If the af argument of inet_pton() is AF_INET6, the src string shall
-   be in one of the standard IPv6 text forms defined in Section 2.2 of
-   the addressing architecture specification [2].
-
-   The inet_ntop() function shall convert a numeric address into a text
-   string suitable for presentation.  The af argument shall specify the
-   family of the address.  This can be AF_INET or AF_INET6.  The src
-   argument points to a buffer holding an IPv4 address if the af
-   argument is AF_INET, or an IPv6 address if the af argument is
-   AF_INET6; the address must be in network byte order.  The dst
-   argument points to a buffer where the function stores the resulting
-   text string; it shall not be NULL.  The size argument specifies the
-   size of this buffer, which shall be large enough to hold the text
-   string (INET_ADDRSTRLEN characters for IPv4, INET6_ADDRSTRLEN
-   characters for IPv6).
-
-   In order to allow applications to easily declare buffers of the
-   proper size to store IPv4 and IPv6 addresses in string form, the
-   following two constants are defined in <netinet/in.h>:
-
-      #define INET_ADDRSTRLEN    16
-      #define INET6_ADDRSTRLEN   46
-
-   The inet_ntop() function shall return a pointer to the buffer
-   containing the text string if the conversion succeeds, and NULL
-   otherwise.  Upon failure, errno is set to EAFNOSUPPORT if the af
-   argument is invalid or ENOSPC if the size of the result buffer is
-   inadequate.
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 32]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-6.4 Address Testing Macros
-
-   The following macros can be used to test for special IPv6 addresses.
-
-   #include <netinet/in.h>
-
-   int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
-   int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
-   int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
-   int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
-   int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
-   int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
-   int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
-
-   int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-   int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-   int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-   int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
-   int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
-
-   The first seven macros return true if the address is of the specified
-   type, or false otherwise.  The last five test the scope of a
-   multicast address and return true if the address is a multicast
-   address of the specified scope or false if the address is either not
-   a multicast address or not of the specified scope.
-
-   Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true
-   only for the two types of local-use IPv6 unicast addresses (Link-
-   Local and Site-Local) defined in [2], and that by this definition,
-   the IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback
-   address (::1).  These two macros do not return true for IPv6
-   multicast addresses of either link-local scope or site-local scope.
-
-7. Summary of New Definitions
-
-   The following list summarizes the constants, structure, and extern
-   definitions discussed in this memo, sorted by header.
-
-<net/if.h>      IF_NAMESIZE
-<net/if.h>      struct if_nameindex{};
-
-<netdb.h>       AI_ADDRCONFIG
-<netdb.h>       AI_ALL
-<netdb.h>       AI_CANONNAME
-<netdb.h>       AI_NUMERICHOST
-<netdb.h>       AI_NUMERICSERV
-<netdb.h>       AI_PASSIVE
-<netdb.h>       AI_V4MAPPED
-
-
-
-Gilligan, et al.             Informational                     [Page 33]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-<netdb.h>       EAI_AGAIN
-<netdb.h>       EAI_BADFLAGS
-<netdb.h>       EAI_FAIL
-<netdb.h>       EAI_FAMILY
-<netdb.h>       EAI_MEMORY
-<netdb.h>       EAI_NONAME
-<netdb.h>       EAI_OVERFLOW
-<netdb.h>       EAI_SERVICE
-<netdb.h>       EAI_SOCKTYPE
-<netdb.h>       EAI_SYSTEM
-<netdb.h>       NI_DGRAM
-<netdb.h>       NI_NAMEREQD
-<netdb.h>       NI_NOFQDN
-<netdb.h>       NI_NUMERICHOST
-<netdb.h>       NI_NUMERICSERV
-<netdb.h>       struct addrinfo{};
-
-<netinet/in.h>  IN6ADDR_ANY_INIT
-<netinet/in.h>  IN6ADDR_LOOPBACK_INIT
-<netinet/in.h>  INET6_ADDRSTRLEN
-<netinet/in.h>  INET_ADDRSTRLEN
-<netinet/in.h>  IPPROTO_IPV6
-<netinet/in.h>  IPV6_JOIN_GROUP
-<netinet/in.h>  IPV6_LEAVE_GROUP
-<netinet/in.h>  IPV6_MULTICAST_HOPS
-<netinet/in.h>  IPV6_MULTICAST_IF
-<netinet/in.h>  IPV6_MULTICAST_LOOP
-<netinet/in.h>  IPV6_UNICAST_HOPS
-<netinet/in.h>  IPV6_V6ONLY
-<netinet/in.h>  SIN6_LEN
-<netinet/in.h>  extern const struct in6_addr in6addr_any;
-<netinet/in.h>  extern const struct in6_addr in6addr_loopback;
-<netinet/in.h>  struct in6_addr{};
-<netinet/in.h>  struct ipv6_mreq{};
-<netinet/in.h>  struct sockaddr_in6{};
-
-<sys/socket.h>  AF_INET6
-<sys/socket.h>  PF_INET6
-<sys/socket.h>  struct sockaddr_storage;
-
-   The following list summarizes the function and macro prototypes
-   discussed in this memo, sorted by header.
-
-<arpa/inet.h>   int inet_pton(int, const char *, void *);
-<arpa/inet.h>   const char *inet_ntop(int, const void *,
-                               char *, socklen_t);
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 34]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-<net/if.h>      char *if_indextoname(unsigned int, char *);
-<net/if.h>      unsigned int if_nametoindex(const char *);
-<net/if.h>      void if_freenameindex(struct if_nameindex *);
-<net/if.h>      struct if_nameindex *if_nameindex(void);
-
-<netdb.h>       int getaddrinfo(const char *, const char *,
-                                const struct addrinfo *,
-                                struct addrinfo **);
-<netdb.h>       int getnameinfo(const struct sockaddr *, socklen_t,
-                  char *, socklen_t, char *, socklen_t, int);
-<netdb.h>       void freeaddrinfo(struct addrinfo *);
-<netdb.h>       const char *gai_strerror(int);
-
-<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-8. Security Considerations
-
-   IPv6 provides a number of new security mechanisms, many of which need
-   to be accessible to applications.  Companion memos detailing the
-   extensions to the socket interfaces to support IPv6 security are
-   being written.
-
-9. Changes from RFC 2553
-
-   1. Add brief description of the history of this API and its relation
-      to the Open Group/IEEE/ISO standards.
-
-   2. Alignments with [3].
-
-   3. Removed all references to getipnodebyname() and getipnodebyaddr(),
-      which are deprecated in favor of getaddrinfo() and getnameinfo().
-
-   4. Added IPV6_V6ONLY IP level socket option to permit nodes to not
-      process IPv4 packets as IPv4 Mapped addresses in implementations.
-
-   5. Added SIIT to references and added new contributors.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 35]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   6. In previous versions of this specification, the sin6_flowinfo
-      field was associated with the IPv6 traffic class and flow label,
-      but its usage was not completely specified.  The complete
-      definition of the sin6_flowinfo field, including its association
-      with the traffic class or flow label, is now deferred to a future
-      specification.
-
-10. Acknowledgments
-
-   This specification's evolution and completeness were significantly
-   influenced by the efforts of Richard Stevens, who has passed on.
-   Richard's wisdom and talent made the specification what it is today.
-   The co-authors will long think of Richard with great respect.
-
-   Thanks to the many people who made suggestions and provided feedback
-   to this document, including:
-
-   Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew
-   Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves,
-   Francis Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino,
-   Marc Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema,
-   Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan
-   McDonald, Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne,
-   Craig Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos,
-   Keith Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey
-   Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie,
-   David Waitzman, Carl Williams, Kazu Yamamoto, Vlad Yasevich, Stig
-   Venaas, and Brian Zill.
-
-   The getaddrinfo() and getnameinfo() functions are taken from an
-   earlier document by Keith Sklower.  As noted in that document,
-   William Durst, Steven Wise, Michael Karels, and Eric Allman provided
-   many useful discussions on the subject of protocol-independent name-
-   to-address translation, and reviewed early versions of Keith
-   Sklower's original proposal.  Eric Allman implemented the first
-   prototype of getaddrinfo().  The observation that specifying the pair
-   of name and service would suffice for connecting to a service
-   independent of protocol details was made by Marshall Rose in a
-   proposal to X/Open for a "Uniform Network Interface".
-
-   Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
-   Kacker made many contributions to this document.  Ramesh Govindan
-   made a number of contributions and co-authored an earlier version of
-   this memo.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 36]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-11. References
-
-   [1]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
-        Specification", RFC 2460, December 1998.
-
-   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
-        Architecture", RFC 2373, July 1998.
-
-   [3]  IEEE Std. 1003.1-2001 Standard for Information Technology --
-        Portable Operating System Interface (POSIX). Open Group
-        Technical Standard: Base Specifications, Issue 6, December 2001.
-        ISO/IEC 9945:2002.  http://www.opengroup.org/austin
-
-   [4]  Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
-        2292, February 1998.
-
-   [5]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
-        RFC 2765, February 2000.
-
-   [6]  The Open Group Base Working Group
-        http://www.opengroup.org/platform/base.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 37]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-12. Authors' Addresses
-
-   Bob Gilligan
-   Intransa, Inc.
-   2870 Zanker Rd.
-   San Jose, CA 95134
-
-   Phone: 408-678-8647
-   EMail: gilligan@intransa.com
-
-
-   Susan Thomson
-   Cisco Systems
-   499 Thornall Street, 8th floor
-   Edison, NJ 08837
-
-   Phone: 732-635-3086
-   EMail:  sethomso@cisco.com
-
-
-   Jim Bound
-   Hewlett-Packard Company
-   110 Spitbrook Road ZKO3-3/W20
-   Nashua, NH 03062
-
-   Phone: 603-884-0062
-   EMail: Jim.Bound@hp.com
-
-
-   Jack McCann
-   Hewlett-Packard Company
-   110 Spitbrook Road ZKO3-3/W20
-   Nashua, NH 03062
-
-   Phone: 603-884-2608
-   EMail: Jack.McCann@hp.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 38]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-13. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 39]
-
diff --git a/doc/rfc/rfc3513.txt b/doc/rfc/rfc3513.txt
deleted file mode 100644
index 49c0fa41..00000000
--- a/doc/rfc/rfc3513.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Hinden
-Request for Comments: 3513                                         Nokia
-Obsoletes: 2373                                               S. Deering
-Category: Standards Track                                  Cisco Systems
-                                                              April 2003
-
-
-       Internet Protocol Version 6 (IPv6) Addressing Architecture
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This specification defines the addressing architecture of the IP
-   Version 6 (IPv6) protocol.  The document includes the IPv6 addressing
-   model, text representations of IPv6 addresses, definition of IPv6
-   unicast addresses, anycast addresses, and multicast addresses, and an
-   IPv6 node's required addresses.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 1]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-Table of Contents
-
-   1. Introduction.................................................3
-   2. IPv6 Addressing..............................................3
-      2.1 Addressing Model.........................................4
-      2.2 Text Representation of Addresses.........................4
-      2.3 Text Representation of Address Prefixes..................5
-      2.4 Address Type Identification..............................6
-      2.5 Unicast Addresses........................................7
-          2.5.1 Interface Identifiers..............................8
-          2.5.2 The Unspecified Address............................9
-          2.5.3 The Loopback Address...............................9
-          2.5.4 Global Unicast Addresses..........................10
-          2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.......10
-          2.5.6 Local-use IPv6 Unicast Addresses..................11
-      2.6 Anycast Addresses.......................................12
-          2.6.1 Required Anycast Address..........................13
-      2.7 Multicast Addresses.....................................13
-          2.7.1 Pre-Defined Multicast Addresses...................15
-      2.8 A Node's Required Addresses.............................17
-   3. Security Considerations.....................................17
-   4. IANA Considerations.........................................18
-   5. References..................................................19
-      5.1 Normative References....................................19
-      5.2 Informative References..................................19
-   APPENDIX A: Creating Modified EUI-64 format Interface IDs......21
-   APPENDIX B: Changes from RFC-2373..............................24
-   Authors' Addresses.............................................25
-   Full Copyright Statement.......................................26
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 2]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-1.  Introduction
-
-   This specification defines the addressing architecture of the IP
-   Version 6 (IPv6) protocol.  It includes the basic formats for the
-   various types of IPv6 addresses (unicast, anycast, and multicast).
-
-   The authors would like to acknowledge the contributions of Paul
-   Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
-   Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
-   Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
-   Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
-   Sue Thomson, Markku Savela, and Larry Masinter.
-
-2. IPv6 Addressing
-
-   IPv6 addresses are 128-bit identifiers for interfaces and sets of
-   interfaces (where "interface" is as defined in section 2 of [IPV6]).
-   There are three types of addresses:
-
-   Unicast:   An identifier for a single interface.  A packet sent to a
-              unicast address is delivered to the interface identified
-              by that address.
-
-   Anycast:   An identifier for a set of interfaces (typically belonging
-              to different nodes).  A packet sent to an anycast address
-              is delivered to one of the interfaces identified by that
-              address (the "nearest" one, according to the routing
-              protocols' measure of distance).
-
-   Multicast: An identifier for a set of interfaces (typically belonging
-              to different nodes).  A packet sent to a multicast address
-              is delivered to all interfaces identified by that address.
-
-   There are no broadcast addresses in IPv6, their function being
-   superseded by multicast addresses.
-
-   In this document, fields in addresses are given a specific name, for
-   example "subnet".  When this name is used with the term "ID" for
-   identifier after the name (e.g., "subnet ID"), it refers to the
-   contents of the named field.  When it is used with the term "prefix"
-   (e.g., "subnet prefix") it refers to all of the address from the left
-   up to and including this field.
-
-   In IPv6, all zeros and all ones are legal values for any field,
-   unless specifically excluded.  Specifically, prefixes may contain, or
-   end with, zero-valued fields.
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 3]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-2.1 Addressing Model
-
-   IPv6 addresses of all types are assigned to interfaces, not nodes.
-   An IPv6 unicast address refers to a single interface.  Since each
-   interface belongs to a single node, any of that node's interfaces'
-   unicast addresses may be used as an identifier for the node.
-
-   All interfaces are required to have at least one link-local unicast
-   address (see section 2.8 for additional required addresses).  A
-   single interface may also have multiple IPv6 addresses of any type
-   (unicast, anycast, and multicast) or scope.  Unicast addresses with
-   scope greater than link-scope are not needed for interfaces that are
-   not used as the origin or destination of any IPv6 packets to or from
-   non-neighbors.  This is sometimes convenient for point-to-point
-   interfaces.  There is one exception to this addressing model:
-
-      A unicast address or a set of unicast addresses may be assigned to
-      multiple physical interfaces if the implementation treats the
-      multiple physical interfaces as one interface when presenting it
-      to the internet layer.  This is useful for load-sharing over
-      multiple physical interfaces.
-
-   Currently IPv6 continues the IPv4 model that a subnet prefix is
-   associated with one link.  Multiple subnet prefixes may be assigned
-   to the same link.
-
-2.2 Text Representation of Addresses
-
-   There are three conventional forms for representing IPv6 addresses as
-   text strings:
-
-   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
-      hexadecimal values of the eight 16-bit pieces of the address.
-
-      Examples:
-
-         FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
-
-         1080:0:0:0:8:800:200C:417A
-
-      Note that it is not necessary to write the leading zeros in an
-      individual field, but there must be at least one numeral in every
-      field (except for the case described in 2.).
-
-   2. Due to some methods of allocating certain styles of IPv6
-      addresses, it will be common for addresses to contain long strings
-      of zero bits.  In order to make writing addresses containing zero
-      bits easier a special syntax is available to compress the zeros.
-
-
-
-Hinden & Deering            Standards Track                     [Page 4]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-      The use of "::" indicates one or more groups of 16 bits of zeros.
-      The "::" can only appear once in an address.  The "::" can also be
-      used to compress leading or trailing zeros in an address.
-
-      For example, the following addresses:
-
-         1080:0:0:0:8:800:200C:417A  a unicast address
-         FF01:0:0:0:0:0:0:101        a multicast address
-         0:0:0:0:0:0:0:1             the loopback address
-         0:0:0:0:0:0:0:0             the unspecified addresses
-
-      may be represented as:
-
-         1080::8:800:200C:417A       a unicast address
-         FF01::101                   a multicast address
-         ::1                         the loopback address
-         ::                          the unspecified addresses
-
-   3. An alternative form that is sometimes more convenient when dealing
-      with a mixed environment of IPv4 and IPv6 nodes is
-      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
-      the six high-order 16-bit pieces of the address, and the 'd's are
-      the decimal values of the four low-order 8-bit pieces of the
-      address (standard IPv4 representation).  Examples:
-
-         0:0:0:0:0:0:13.1.68.3
-
-         0:0:0:0:0:FFFF:129.144.52.38
-
-      or in compressed form:
-
-         ::13.1.68.3
-
-         ::FFFF:129.144.52.38
-
-2.3 Text Representation of Address Prefixes
-
-   The text representation of IPv6 address prefixes is similar to the
-   way IPv4 addresses prefixes are written in CIDR notation [CIDR].  An
-   IPv6 address prefix is represented by the notation:
-
-      ipv6-address/prefix-length
-
-   where
-
-      ipv6-address    is an IPv6 address in any of the notations listed
-                      in section 2.2.
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 5]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-      prefix-length   is a decimal value specifying how many of the
-                      leftmost contiguous bits of the address comprise
-                      the prefix.
-
-   For example, the following are legal representations of the 60-bit
-   prefix 12AB00000000CD3 (hexadecimal):
-
-      12AB:0000:0000:CD30:0000:0000:0000:0000/60
-      12AB::CD30:0:0:0:0/60
-      12AB:0:0:CD30::/60
-
-   The following are NOT legal representations of the above prefix:
-
-      12AB:0:0:CD3/60   may drop leading zeros, but not trailing zeros,
-                        within any 16-bit chunk of the address
-
-      12AB::CD30/60     address to left of "/" expands to
-                        12AB:0000:0000:0000:0000:000:0000:CD30
-
-      12AB::CD3/60      address to left of "/" expands to
-                        12AB:0000:0000:0000:0000:000:0000:0CD3
-
-   When writing both a node address and a prefix of that node address
-   (e.g., the node's subnet prefix), the two can combined as follows:
-
-      the node address      12AB:0:0:CD30:123:4567:89AB:CDEF
-      and its subnet number 12AB:0:0:CD30::/60
-
-      can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
-
-2.4 Address Type Identification
-
-   The type of an IPv6 address is identified by the high-order bits of
-   the address, as follows:
-
-   Address type         Binary prefix        IPv6 notation   Section
-   ------------         -------------        -------------   -------
-   Unspecified          00...0  (128 bits)   ::/128          2.5.2
-   Loopback             00...1  (128 bits)   ::1/128         2.5.3
-   Multicast            11111111             FF00::/8        2.7
-   Link-local unicast   1111111010           FE80::/10       2.5.6
-   Site-local unicast   1111111011           FEC0::/10       2.5.6
-   Global unicast       (everything else)
-
-   Anycast addresses are taken from the unicast address spaces (of any
-   scope) and are not syntactically distinguishable from unicast
-   addresses.
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 6]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   The general format of global unicast addresses is described in
-   section 2.5.4.  Some special-purpose subtypes of global unicast
-   addresses which contain embedded IPv4 addresses (for the purposes of
-   IPv4-IPv6 interoperation) are described in section 2.5.5.
-
-   Future specifications may redefine one or more sub-ranges of the
-   global unicast space for other purposes, but unless and until that
-   happens, implementations must treat all addresses that do not start
-   with any of the above-listed prefixes as global unicast addresses.
-
-2.5 Unicast Addresses
-
-   IPv6 unicast addresses are aggregable with prefixes of arbitrary
-   bit-length similar to IPv4 addresses under Classless Interdomain
-   Routing.
-
-   There are several types of unicast addresses in IPv6, in particular
-   global unicast, site-local unicast, and link-local unicast.  There
-   are also some special-purpose subtypes of global unicast, such as
-   IPv6 addresses with embedded IPv4 addresses or encoded NSAP
-   addresses.  Additional address types or subtypes can be defined in
-   the future.
-
-   IPv6 nodes may have considerable or little knowledge of the internal
-   structure of the IPv6 address, depending on the role the node plays
-   (for instance, host versus router).  At a minimum, a node may
-   consider that unicast addresses (including its own) have no internal
-   structure:
-
-   |                           128 bits                              |
-   +-----------------------------------------------------------------+
-   |                          node address                           |
-   +-----------------------------------------------------------------+
-
-   A slightly sophisticated host (but still rather simple) may
-   additionally be aware of subnet prefix(es) for the link(s) it is
-   attached to, where different addresses may have different values for
-   n:
-
-   |                         n bits                 |   128-n bits   |
-   +------------------------------------------------+----------------+
-   |                   subnet prefix                | interface ID   |
-   +------------------------------------------------+----------------+
-
-   Though a very simple router may have no knowledge of the internal
-   structure of IPv6 unicast addresses, routers will more generally have
-   knowledge of one or more of the hierarchical boundaries for the
-   operation of routing protocols.  The known boundaries will differ
-
-
-
-Hinden & Deering            Standards Track                     [Page 7]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   from router to router, depending on what positions the router holds
-   in the routing hierarchy.
-
-2.5.1 Interface Identifiers
-
-   Interface identifiers in IPv6 unicast addresses are used to identify
-   interfaces on a link.  They are required to be unique within a subnet
-   prefix.  It is recommended that the same interface identifier not be
-   assigned to different nodes on a link.  They may also be unique over
-   a broader scope.  In some cases an interface's identifier will be
-   derived directly from that interface's link-layer address.  The same
-   interface identifier may be used on multiple interfaces on a single
-   node, as long as they are attached to different subnets.
-
-   Note that the uniqueness of interface identifiers is independent of
-   the uniqueness of IPv6 addresses.  For example, a global unicast
-   address may be created with a non-global scope interface identifier
-   and a site-local address may be created with a global scope interface
-   identifier.
-
-   For all unicast addresses, except those that start with binary value
-   000, Interface IDs are required to be 64 bits long and to be
-   constructed in Modified EUI-64 format.
-
-   Modified EUI-64 format based Interface identifiers may have global
-   scope when derived from a global token (e.g., IEEE 802 48-bit MAC or
-   IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
-   global token is not available (e.g., serial links, tunnel end-points,
-   etc.) or where global tokens are undesirable (e.g., temporary tokens
-   for privacy [PRIV]).
-
-   Modified EUI-64 format interface identifiers are formed by inverting
-   the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
-   forming the interface identifier from IEEE EUI-64 identifiers.  In
-   the resulting Modified EUI-64 format the "u" bit is set to one (1) to
-   indicate global scope, and it is set to zero (0) to indicate local
-   scope.  The first three octets in binary of an IEEE EUI-64 identifier
-   are as follows:
-
-       0       0 0       1 1       2
-      |0       7 8       5 6       3|
-      +----+----+----+----+----+----+
-      |cccc|ccug|cccc|cccc|cccc|cccc|
-      +----+----+----+----+----+----+
-
-   written in Internet standard bit-order , where "u" is the
-   universal/local bit, "g" is the individual/group bit, and "c" are the
-   bits of the company_id.  Appendix A: "Creating Modified EUI-64 format
-
-
-
-Hinden & Deering            Standards Track                     [Page 8]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   Interface Identifiers" provides examples on the creation of Modified
-   EUI-64 format based interface identifiers.
-
-   The motivation for inverting the "u" bit when forming an interface
-   identifier is to make it easy for system administrators to hand
-   configure non-global identifiers when hardware tokens are not
-   available.  This is expected to be case for serial links, tunnel end-
-   points, etc.  The alternative would have been for these to be of the
-   form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2,
-   etc.
-
-   The use of the universal/local bit in the Modified EUI-64 format
-   identifier is to allow development of future technology that can take
-   advantage of interface identifiers with global scope.
-
-   The details of forming interface identifiers are defined in the
-   appropriate "IPv6 over <link>" specification such as "IPv6 over
-   Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
-
-2.5.2 The Unspecified Address
-
-   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
-   must never be assigned to any node.  It indicates the absence of an
-   address.  One example of its use is in the Source Address field of
-   any IPv6 packets sent by an initializing host before it has learned
-   its own address.
-
-   The unspecified address must not be used as the destination address
-   of IPv6 packets or in IPv6 Routing Headers.  An IPv6 packet with a
-   source address of unspecified must never be forwarded by an IPv6
-   router.
-
-2.5.3 The Loopback Address
-
-   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
-   It may be used by a node to send an IPv6 packet to itself.  It may
-   never be assigned to any physical interface.   It is treated as
-   having link-local scope, and may be thought of as the link-local
-   unicast address of a virtual interface (typically called "the
-   loopback interface") to an imaginary link that goes nowhere.
-
-   The loopback address must not be used as the source address in IPv6
-   packets that are sent outside of a single node.  An IPv6 packet with
-   a destination address of loopback must never be sent outside of a
-   single node and must never be forwarded by an IPv6 router.  A packet
-   received on an interface with destination address of loopback must be
-   dropped.
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 9]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-2.5.4 Global Unicast Addresses
-
-   The general format for IPv6 global unicast addresses is as follows:
-
-   |         n bits         |   m bits  |       128-n-m bits         |
-   +------------------------+-----------+----------------------------+
-   | global routing prefix  | subnet ID |       interface ID         |
-   +------------------------+-----------+----------------------------+
-
-   where the global routing prefix is a (typically hierarchically-
-   structured) value assigned to a site (a cluster of subnets/links),
-   the subnet ID is an identifier of a link within the site, and the
-   interface ID is as defined in section 2.5.1.
-
-   All global unicast addresses other than those that start with binary
-   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
-   described in section 2.5.1.  Global unicast addresses that start with
-   binary 000 have no such constraint on the size or structure of the
-   interface ID field.
-
-   Examples of global unicast addresses that start with binary 000 are
-   the IPv6 address with embedded IPv4 addresses described in section
-   2.5.5 and the IPv6 address containing encoded NSAP addresses
-   specified in [NSAP].  An example of global addresses starting with a
-   binary value other than 000 (and therefore having a 64-bit interface
-   ID field) can be found in [AGGR].
-
-2.5.5 IPv6 Addresses with Embedded IPv4 Addresses
-
-   The IPv6 transition mechanisms [TRAN] include a technique for hosts
-   and routers to dynamically tunnel IPv6 packets over IPv4 routing
-   infrastructure.  IPv6 nodes that use this technique are assigned
-   special IPv6 unicast addresses that carry a global IPv4 address in
-   the low-order 32 bits.  This type of address is termed an "IPv4-
-   compatible IPv6 address" and has the format:
-
-   |                80 bits               | 16 |      32 bits        |
-   +--------------------------------------+--------------------------+
-   |0000..............................0000|0000|    IPv4 address     |
-   +--------------------------------------+----+---------------------+
-
-   Note: The IPv4 address used in the "IPv4-compatible IPv6 address"
-   must be a globally-unique IPv4 unicast address.
-
-   A second type of IPv6 address which holds an embedded IPv4 address is
-   also defined.  This address type is used to represent the addresses
-   of IPv4 nodes as IPv6 addresses.  This type of address is termed an
-   "IPv4-mapped IPv6 address" and has the format:
-
-
-
-Hinden & Deering            Standards Track                    [Page 10]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   |                80 bits               | 16 |      32 bits        |
-   +--------------------------------------+--------------------------+
-   |0000..............................0000|FFFF|    IPv4 address     |
-   +--------------------------------------+----+---------------------+
-
-2.5.6 Local-Use IPv6 Unicast Addresses
-
-   There are two types of local-use unicast addresses defined.  These
-   are Link-Local and Site-Local.  The Link-Local is for use on a single
-   link and the Site-Local is for use in a single site.  Link-Local
-   addresses have the following format:
-
-   |   10     |
-   |  bits    |         54 bits         |          64 bits           |
-   +----------+-------------------------+----------------------------+
-   |1111111010|           0             |       interface ID         |
-   +----------+-------------------------+----------------------------+
-
-   Link-Local addresses are designed to be used for addressing on a
-   single link for purposes such as automatic address configuration,
-   neighbor discovery, or when no routers are present.
-
-   Routers must not forward any packets with link-local source or
-   destination addresses to other links.
-
-   Site-Local addresses have the following format:
-
-   |   10     |
-   |  bits    |         54 bits         |         64 bits            |
-   +----------+-------------------------+----------------------------+
-   |1111111011|        subnet ID        |       interface ID         |
-   +----------+-------------------------+----------------------------+
-
-   Site-local addresses are designed to be used for addressing inside of
-   a site without the need for a global prefix.  Although a subnet ID
-   may be up to 54-bits long, it is expected that globally-connected
-   sites will use the same subnet IDs for site-local and global
-   prefixes.
-
-   Routers must not forward any packets with site-local source or
-   destination addresses outside of the site.
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 11]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-2.6 Anycast Addresses
-
-   An IPv6 anycast address is an address that is assigned to more than
-   one interface (typically belonging to different nodes), with the
-   property that a packet sent to an anycast address is routed to the
-   "nearest" interface having that address, according to the routing
-   protocols' measure of distance.
-
-   Anycast addresses are allocated from the unicast address space, using
-   any of the defined unicast address formats.  Thus, anycast addresses
-   are syntactically indistinguishable from unicast addresses.  When a
-   unicast address is assigned to more than one interface, thus turning
-   it into an anycast address, the nodes to which the address is
-   assigned must be explicitly configured to know that it is an anycast
-   address.
-
-   For any assigned anycast address, there is a longest prefix P of that
-   address that identifies the topological region in which all
-   interfaces belonging to that anycast address reside.  Within the
-   region identified by P, the anycast address must be maintained as a
-   separate entry in the routing system (commonly referred to as a "host
-   route"); outside the region identified by P, the anycast address may
-   be aggregated into the routing entry for prefix P.
-
-   Note that in the worst case, the prefix P of an anycast set may be
-   the null prefix, i.e., the members of the set may have no topological
-   locality.  In that case, the anycast address must be maintained as a
-   separate routing entry throughout the entire internet, which presents
-   a severe scaling limit on how many such "global" anycast sets may be
-   supported.  Therefore, it is expected that support for global anycast
-   sets may be unavailable or very restricted.
-
-   One expected use of anycast addresses is to identify the set of
-   routers belonging to an organization providing internet service.
-   Such addresses could be used as intermediate addresses in an IPv6
-   Routing header, to cause a packet to be delivered via a particular
-   service provider or sequence of service providers.
-
-   Some other possible uses are to identify the set of routers attached
-   to a particular subnet, or the set of routers providing entry into a
-   particular routing domain.
-
-   There is little experience with widespread, arbitrary use of internet
-   anycast addresses, and some known complications and hazards when
-   using them in their full generality [ANYCST].  Until more experience
-   has been gained and solutions are specified, the following
-   restrictions are imposed on IPv6 anycast addresses:
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 12]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   o  An anycast address must not be used as the source address of an
-      IPv6 packet.
-
-   o  An anycast address must not be assigned to an IPv6 host, that is,
-      it may be assigned to an IPv6 router only.
-
-2.6.1 Required Anycast Address
-
-   The Subnet-Router anycast address is predefined.  Its format is as
-   follows:
-
-   |                         n bits                 |   128-n bits   |
-   +------------------------------------------------+----------------+
-   |                   subnet prefix                | 00000000000000 |
-   +------------------------------------------------+----------------+
-
-   The "subnet prefix" in an anycast address is the prefix which
-   identifies a specific link.  This anycast address is syntactically
-   the same as a unicast address for an interface on the link with the
-   interface identifier set to zero.
-
-   Packets sent to the Subnet-Router anycast address will be delivered
-   to one router on the subnet.  All routers are required to support the
-   Subnet-Router anycast addresses for the subnets to which they have
-   interfaces.
-
-   The subnet-router anycast address is intended to be used for
-   applications where a node needs to communicate with any one of the
-   set of routers.
-
-2.7 Multicast Addresses
-
-   An IPv6 multicast address is an identifier for a group of interfaces
-   (typically on different nodes).  An interface may belong to any
-   number of multicast groups.  Multicast addresses have the following
-   format:
-
-   |   8    |  4 |  4 |                  112 bits                   |
-   +------ -+----+----+---------------------------------------------+
-   |11111111|flgs|scop|                  group ID                   |
-   +--------+----+----+---------------------------------------------+
-
-         binary 11111111 at the start of the address identifies the
-         address as being a multicast address.
-
-                                       +-+-+-+-+
-         flgs is a set of 4 flags:     |0|0|0|T|
-                                       +-+-+-+-+
-
-
-
-Hinden & Deering            Standards Track                    [Page 13]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-            The high-order 3 flags are reserved, and must be initialized
-            to 0.
-
-            T = 0 indicates a permanently-assigned ("well-known")
-            multicast address, assigned by the Internet Assigned Number
-            Authority (IANA).
-
-            T = 1 indicates a non-permanently-assigned ("transient")
-            multicast address.
-
-         scop is a 4-bit multicast scope value used to limit the scope
-         of the multicast group.  The values are:
-
-            0  reserved
-            1  interface-local scope
-            2  link-local scope
-            3  reserved
-            4  admin-local scope
-            5  site-local scope
-            6  (unassigned)
-            7  (unassigned)
-            8  organization-local scope
-            9  (unassigned)
-            A  (unassigned)
-            B  (unassigned)
-            C  (unassigned)
-            D  (unassigned)
-            E  global scope
-            F  reserved
-
-            interface-local scope spans only a single interface on a
-            node, and is useful only for loopback transmission of
-            multicast.
-
-            link-local and site-local multicast scopes span the same
-            topological regions as the corresponding unicast scopes.
-
-            admin-local scope is the smallest scope that must be
-            administratively configured, i.e., not automatically derived
-            from physical connectivity or other, non- multicast-related
-            configuration.
-
-            organization-local scope is intended to span multiple sites
-            belonging to a single organization.
-
-            scopes labeled "(unassigned)" are available for
-            administrators to define additional multicast regions.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 14]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-         group ID identifies the multicast group, either permanent or
-         transient, within the given scope.
-
-   The "meaning" of a permanently-assigned multicast address is
-   independent of the scope value.  For example, if the "NTP servers
-   group" is assigned a permanent multicast address with a group ID of
-   101 (hex), then:
-
-      FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface
-      (i.e., the same node) as the sender.
-
-      FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
-      sender.
-
-      FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the
-      sender.
-
-      FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.
-
-   Non-permanently-assigned multicast addresses are meaningful only
-   within a given scope.  For example, a group identified by the non-
-   permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
-   site bears no relationship to a group using the same address at a
-   different site, nor to a non-permanent group using the same group ID
-   with different scope, nor to a permanent group with the same group
-   ID.
-
-   Multicast addresses must not be used as source addresses in IPv6
-   packets or appear in any Routing header.
-
-   Routers must not forward any multicast packets beyond of the scope
-   indicated by the scop field in the destination multicast address.
-
-   Nodes must not originate a packet to a multicast address whose scop
-   field contains the reserved value 0; if such a packet is received, it
-   must be silently dropped.  Nodes should not originate a packet to a
-   multicast address whose scop field contains the reserved value F; if
-   such a packet is sent or received, it must be treated the same as
-   packets destined to a global (scop E) multicast address.
-
-2.7.1 Pre-Defined Multicast Addresses
-
-   The following well-known multicast addresses are pre-defined.  The
-   group ID's defined in this section are defined for explicit scope
-   values.
-
-   Use of these group IDs for any other scope values, with the T flag
-   equal to 0, is not allowed.
-
-
-
-Hinden & Deering            Standards Track                    [Page 15]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-      Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
-                                      FF01:0:0:0:0:0:0:0
-                                      FF02:0:0:0:0:0:0:0
-                                      FF03:0:0:0:0:0:0:0
-                                      FF04:0:0:0:0:0:0:0
-                                      FF05:0:0:0:0:0:0:0
-                                      FF06:0:0:0:0:0:0:0
-                                      FF07:0:0:0:0:0:0:0
-                                      FF08:0:0:0:0:0:0:0
-                                      FF09:0:0:0:0:0:0:0
-                                      FF0A:0:0:0:0:0:0:0
-                                      FF0B:0:0:0:0:0:0:0
-                                      FF0C:0:0:0:0:0:0:0
-                                      FF0D:0:0:0:0:0:0:0
-                                      FF0E:0:0:0:0:0:0:0
-                                      FF0F:0:0:0:0:0:0:0
-
-   The above multicast addresses are reserved and shall never be
-   assigned to any multicast group.
-
-      All Nodes Addresses:    FF01:0:0:0:0:0:0:1
-                              FF02:0:0:0:0:0:0:1
-
-   The above multicast addresses identify the group of all IPv6 nodes,
-   within scope 1 (interface-local) or 2 (link-local).
-
-      All Routers Addresses:   FF01:0:0:0:0:0:0:2
-                               FF02:0:0:0:0:0:0:2
-                               FF05:0:0:0:0:0:0:2
-
-   The above multicast addresses identify the group of all IPv6 routers,
-   within scope 1 (interface-local), 2 (link-local), or 5 (site-local).
-
-      Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX
-
-   Solicited-node multicast address are computed as a function of a
-   node's unicast and anycast addresses.  A solicited-node multicast
-   address is formed by taking the low-order 24 bits of an address
-   (unicast or anycast) and appending those bits to the prefix
-   FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
-   range
-
-      FF02:0:0:0:0:1:FF00:0000
-
-   to
-
-      FF02:0:0:0:0:1:FFFF:FFFF
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 16]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   For example, the solicited node multicast address corresponding to
-   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
-   addresses that differ only in the high-order bits, e.g., due to
-   multiple high-order prefixes associated with different aggregations,
-   will map to the same solicited-node address thereby, reducing the
-   number of multicast addresses a node must join.
-
-   A node is required to compute and join (on the appropriate interface)
-   the associated Solicited-Node multicast addresses for every unicast
-   and anycast address it is assigned.
-
-2.8 A Node's Required Addresses
-
-   A host is required to recognize the following addresses as
-   identifying itself:
-
-      o  Its required Link-Local Address for each interface.
-      o  Any additional Unicast and Anycast Addresses that have been
-         configured for the node's interfaces (manually or
-         automatically).
-      o  The loopback address.
-      o  The All-Nodes Multicast Addresses defined in section 2.7.1.
-      o  The Solicited-Node Multicast Address for each of its unicast
-         and anycast addresses.
-      o  Multicast Addresses of all other groups to which the node
-         belongs.
-
-   A router is required to recognize all addresses that a host is
-   required to recognize, plus the following addresses as identifying
-   itself:
-
-      o  The Subnet-Router Anycast Addresses for all interfaces for
-         which it is configured to act as a router.
-      o  All other Anycast Addresses with which the router has been
-         configured.
-      o  The All-Routers Multicast Addresses defined in section 2.7.1.
-
-3. Security Considerations
-
-   IPv6 addressing documents do not have any direct impact on Internet
-   infrastructure security.  Authentication of IPv6 packets is defined
-   in [AUTH].
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 17]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-4. IANA Considerations
-
-   The table and notes at http://www.isi.edu/in-
-   notes/iana/assignments/ipv6-address-space.txt should be replaced with
-   the following:
-
-   INTERNET PROTOCOL VERSION 6 ADDRESS SPACE
-
-   The initial assignment of IPv6 address space is as follows:
-
-   Allocation                            Prefix         Fraction of
-                                         (binary)       Address Space
-   -----------------------------------   --------       -------------
-   Unassigned (see Note 1 below)         0000 0000      1/256
-   Unassigned                            0000 0001      1/256
-   Reserved for NSAP Allocation          0000 001       1/128 [RFC1888]
-   Unassigned                            0000 01        1/64
-   Unassigned                            0000 1         1/32
-   Unassigned                            0001           1/16
-   Global Unicast                        001            1/8   [RFC2374]
-   Unassigned                            010            1/8
-   Unassigned                            011            1/8
-   Unassigned                            100            1/8
-   Unassigned                            101            1/8
-   Unassigned                            110            1/8
-   Unassigned                            1110           1/16
-   Unassigned                            1111 0         1/32
-   Unassigned                            1111 10        1/64
-   Unassigned                            1111 110       1/128
-   Unassigned                            1111 1110 0    1/512
-   Link-Local Unicast Addresses          1111 1110 10   1/1024
-   Site-Local Unicast Addresses          1111 1110 11   1/1024
-   Multicast Addresses                   1111 1111      1/256
-
-   Notes:
-
-   1. The "unspecified address", the "loopback address", and the IPv6
-      Addresses with Embedded IPv4 Addresses are assigned out of the
-      0000 0000 binary prefix space.
-
-   2. For now, IANA should limit its allocation of IPv6 unicast address
-      space to the range of addresses that start with binary value 001.
-      The rest of the global unicast address space (approximately 85% of
-      the IPv6 address space) is reserved for future definition and use,
-      and is not to be assigned by IANA at this time.
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 18]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-5.  References
-
-5.1  Normative References
-
-   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
-             (IPv6) Specification", RFC 2460, December 1998.
-
-   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
-             3", BCP 9 , RFC 2026, October 1996.
-
-5.2  Informative References
-
-   [ANYCST]  Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
-             Service", RFC 1546, November 1993.
-
-   [AUTH]    Kent, S. and R. Atkinson, "IP Authentication Header", RFC
-             2402, November 1998.
-
-   [AGGR]    Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable
-             Global Unicast Address Format", RFC 2374, July 1998.
-
-   [CIDR]    Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
-             Inter-Domain Routing (CIDR): An Address Assignment and
-             Aggregation Strategy", RFC 1519, September 1993.
-
-   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
-             Networks", RFC 2464, December 1998.
-
-   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
-             Registration Authority",
-             http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
-             March 1997.
-
-   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
-             Networks", RFC 2467, December 1998.
-
-   [MASGN]   Hinden, R. and S. Deering, "IPv6 Multicast Address
-             Assignments", RFC 2375, July 1998.
-
-   [NSAP]    Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.
-             and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
-
-   [PRIV]    Narten, T. and R. Draves, "Privacy Extensions for Stateless
-             Address Autoconfiguration in IPv6", RFC 3041, January 2001.
-
-   [TOKEN]   Crawford, M., Narten, T. and S. Thomas, "Transmission of
-             IPv6 Packets over Token Ring Networks", RFC 2470, December
-             1998.
-
-
-
-Hinden & Deering            Standards Track                    [Page 19]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   [TRAN]    Gilligan, R. and E. Nordmark, "Transition Mechanisms for
-             IPv6 Hosts and Routers", RFC 2893, August 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 20]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-APPENDIX A: Creating Modified EUI-64 format Interface Identifiers
-
-   Depending on the characteristics of a specific link or node there are
-   a number of approaches for creating Modified EUI-64 format interface
-   identifiers.  This appendix describes some of these approaches.
-
-Links or Nodes with IEEE EUI-64 Identifiers
-
-   The only change needed to transform an IEEE EUI-64 identifier to an
-   interface identifier is to invert the "u" (universal/local) bit.  For
-   example, a globally unique IEEE EUI-64 identifier of the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   where "c" are the bits of the assigned company_id, "0" is the value
-   of the universal/local bit to indicate global scope, "g" is
-   individual/group bit, and "m" are the bits of the manufacturer-
-   selected extension identifier.  The IPv6 interface identifier would
-   be of the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   The only change is inverting the value of the universal/local bit.
-
-Links or Nodes with IEEE 802 48 bit MAC's
-
-   [EUI64] defines a method to create a IEEE EUI-64 identifier from an
-   IEEE 48bit MAC identifier.  This is to insert two octets, with
-   hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC
-   (between the company_id and vendor supplied id).  For example, the 48
-   bit IEEE MAC with global scope:
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 21]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   |0              1|1              3|3              4|
-   |0              5|6              1|2              7|
-   +----------------+----------------+----------------+
-   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+
-
-   where "c" are the bits of the assigned company_id, "0" is the value
-   of the universal/local bit to indicate global scope, "g" is
-   individual/group bit, and "m" are the bits of the manufacturer-
-   selected extension identifier.  The interface identifier would be of
-   the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   When IEEE 802 48bit MAC addresses are available (on an interface or a
-   node), an implementation may use them to create interface identifiers
-   due to their availability and uniqueness properties.
-
-Links with Other Kinds of Identifiers
-
-   There are a number of types of links that have link-layer interface
-   identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs.  Examples
-   include LocalTalk and Arcnet.  The method to create an Modified EUI-
-   64 format identifier is to take the link identifier (e.g., the
-   LocalTalk 8 bit node identifier) and zero fill it to the left.  For
-   example, a LocalTalk 8 bit node identifier of hexadecimal value 0x4F
-   results in the following interface identifier:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
-   +----------------+----------------+----------------+----------------+
-
-   Note that this results in the universal/local bit set to "0" to
-   indicate local scope.
-
-Links without Identifiers
-
-   There are a number of links that do not have any type of built-in
-   identifier.  The most common of these are serial links and configured
-   tunnels.  Interface identifiers must be chosen that are unique within
-   a subnet-prefix.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 22]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   When no built-in identifier is available on a link the preferred
-   approach is to use a global interface identifier from another
-   interface or one which is assigned to the node itself.  When using
-   this approach no other interface connecting the same node to the same
-   subnet-prefix may use the same identifier.
-
-   If there is no global interface identifier available for use on the
-   link the implementation needs to create a local-scope interface
-   identifier.  The only requirement is that it be unique within a
-   subnet prefix.  There are many possible approaches to select a
-   subnet-prefix-unique interface identifier.  These include:
-
-      Manual Configuration
-      Node Serial Number
-      Other node-specific token
-
-   The subnet-prefix-unique interface identifier should be generated in
-   a manner that it does not change after a reboot of a node or if
-   interfaces are added or deleted from the node.
-
-   The selection of the appropriate algorithm is link and implementation
-   dependent.  The details on forming interface identifiers are defined
-   in the appropriate "IPv6 over <link>" specification.  It is strongly
-   recommended that a collision detection algorithm be implemented as
-   part of any automatic algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 23]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-APPENDIX B: Changes from RFC-2373
-
-   The following changes were made from RFC-2373 "IP Version 6
-   Addressing Architecture":
-
-   -  Clarified text in section 2.2 to allow "::" to represent one or
-      more groups of 16 bits of zeros.
-   -  Changed uniqueness requirement of Interface Identifiers from
-      unique on a link to unique within a subnet prefix.  Also added a
-      recommendation that the same interface identifier not be assigned
-      to different machines on a link.
-   -  Change site-local format to make the subnet ID field 54-bit long
-      and remove the 38-bit zero's field.
-   -  Added description of multicast scop values and rules to handle the
-      reserved scop value 0.
-   -  Revised sections 2.4 and 2.5.6 to simplify and clarify how
-      different address types  are identified.  This was done to insure
-      that implementations do not build in any knowledge about global
-      unicast format prefixes.  Changes include:
-         o  Removed Format Prefix (FP) terminology
-         o  Revised list of address types to only include exceptions to
-            global unicast and a singe entry that identifies everything
-            else as Global Unicast.
-         o  Removed list of defined prefix exceptions from section 2.5.6
-            as it is now the main part of section 2.4.
-   -  Clarified text relating to EUI-64 identifiers to distinguish
-      between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI-
-      64 identifiers.
-   -  Combined the sections on the Global Unicast Addresses and NSAP
-      Addresses into a single section on Global Unicast Addresses,
-      generalized the Global Unicast format, and cited [AGGR] and [NSAP]
-      as examples.
-   -  Reordered sections 2.5.4 and 2.5.5.
-   -  Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses
-      because this is being redefined elsewhere.
-   -  Added an IANA considerations section that updates the IANA IPv6
-      address allocations and documents the NSAP and AGGR allocations.
-   -  Added clarification that the "IPv4-compatible IPv6 address" must
-      use global IPv4 unicast addresses.
-   -  Divided references in to normative and non-normative sections.
-   -  Added reference to [PRIV] in section 2.5.1
-   -  Added clarification that routers must not forward multicast
-      packets outside of the scope indicated in the multicast address.
-   -  Added clarification that routers must not forward packets with
-       source address of the unspecified address.
-   -  Added clarification that routers must drop packets received on an
-      interface with destination address of loopback.
-   -  Clarified the definition of IPv4-mapped addresses.
-
-
-
-Hinden & Deering            Standards Track                    [Page 24]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   -  Removed the ABNF Description of Text Representations Appendix.
-   -  Removed the address block reserved for IPX addresses.
-   -  Multicast scope changes:
-         o  Changed name of scope value 1 from "node-local" to
-            "interface-local"
-         o  Defined scope value 4 as "admin-local"
-   -  Corrected reference to RFC1933 and updated references.
-   -  Many small changes to clarify and make the text more consistent.
-
-Authors' Addresses
-
-   Robert M. Hinden
-   Nokia
-   313 Fairchild Drive
-   Mountain View, CA 94043
-   USA
-
-   Phone: +1 650 625-2004
-   EMail: hinden@iprg.nokia.com
-
-
-   Stephen E. Deering
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-   USA
-
-   Phone: +1 408 527-8213
-   EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 25]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 26]
-
diff --git a/doc/rfc/rfc3596.txt b/doc/rfc/rfc3596.txt
deleted file mode 100644
index f65690c8..00000000
--- a/doc/rfc/rfc3596.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         S. Thomson
-Request for Comments: 3596                                         Cisco
-Obsoletes: 3152, 1886                                         C. Huitema
-Category: Standards Track                                      Microsoft
-                                                              V. Ksinant
-                                                                   6WIND
-                                                              M. Souissi
-                                                                   AFNIC
-                                                            October 2003
-
-
-                 DNS Extensions to Support IP Version 6
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document defines the changes that need to be made to the Domain
-   Name System (DNS) to support hosts running IP version 6 (IPv6).  The
-   changes include a resource record type to store an IPv6 address, a
-   domain to support lookups based on an IPv6 address, and updated
-   definitions of existing query types that return Internet addresses as
-   part of additional section processing.  The extensions are designed
-   to be compatible with existing applications and, in particular, DNS
-   implementations themselves.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  New resource record definition and domain. . . . . . . . . . .  2
-       2.1.  AAAA record type . . . . . . . . . . . . . . . . . . . .  3
-       2.2.  AAAA data format . . . . . . . . . . . . . . . . . . . .  3
-       2.3.  AAAA query . . . . . . . . . . . . . . . . . . . . . . .  3
-       2.4.  Textual format of AAAA records . . . . . . . . . . . . .  3
-       2.5.  IP6.ARPA domain. . . . . . . . . . . . . . . . . . . . .  3
-   3.  Modifications to existing query types. . . . . . . . . . . . .  4
-   4.  Security Considerations. . . . . . . . . . . . . . . . . . . .  4
-   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  4
-
-
-
-Thomson, et al.             Standards Track                     [Page 1]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-   6.  Intellectual Property Statement. . . . . . . . . . . . . . . .  4
-   Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   Appendix A: Changes from RFC 1886. . . . . . . . . . . . . . . . .  6
-   Normative References . . . . . . . . . . . . . . . . . . . . . . .  6
-   Informative References . . . . . . . . . . . . . . . . . . . . . .  6
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .  8
-
-1. Introduction
-
-   Current support for the storage of Internet addresses in the Domain
-   Name System (DNS) [1,2] cannot easily be extended to support IPv6
-   addresses [3] since applications assume that address queries return
-   32-bit IPv4 addresses only.
-
-   To support the storage of IPv6 addresses in the DNS, this document
-   defines the following extensions:
-
-      o A resource record type is defined to map a domain name to an
-        IPv6 address.
-
-      o A domain is defined to support lookups based on address.
-
-      o Existing queries that perform additional section processing to
-        locate IPv4 addresses are redefined to perform additional
-        section processing on both IPv4 and IPv6 addresses.
-
-   The changes are designed to be compatible with existing software.
-   The existing support for IPv4 addresses is retained.  Transition
-   issues related to the co-existence of both IPv4 and IPv6 addresses in
-   the DNS are discussed in [4].
-
-   The IP protocol version used for querying resource records is
-   independent of the protocol version of the resource records; e.g.,
-   IPv4 transport can be used to query IPv6 records and vice versa.
-
-   This document combines RFC 1886 [5] and changes to RFC 1886 made by
-   RFC 3152 [6], obsoleting both.  Changes mainly consist in replacing
-   the IP6.INT domain by IP6.ARPA as defined in RFC 3152.
-
-2. New resource record definition and domain
-
-   A record type is defined to store a host's IPv6 address.  A host that
-   has more than one IPv6 address must have more than one such record.
-
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 2]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-2.1 AAAA record type
-
-   The AAAA resource record type is a record specific to the Internet
-   class that stores a single IPv6 address.
-
-   The IANA assigned value of the type is 28 (decimal).
-
-2.2 AAAA data format
-
-   A 128 bit IPv6 address is encoded in the data portion of an AAAA
-   resource record in network byte order (high-order byte first).
-
-2.3 AAAA query
-
-   An AAAA query for a specified domain name in the Internet class
-   returns all associated AAAA resource records in the answer section of
-   a response.
-
-   A type AAAA query does not trigger additional section processing.
-
-2.4 Textual format of AAAA records
-
-   The textual representation of the data portion of the AAAA resource
-   record used in a master database file is the textual representation
-   of an IPv6 address as defined in [3].
-
-2.5 IP6.ARPA Domain
-
-   A special domain is defined to look up a record given an IPv6
-   address.  The intent of this domain is to provide a way of mapping an
-   IPv6 address to a host name, although it may be used for other
-   purposes as well.  The domain is rooted at IP6.ARPA.
-
-   An IPv6 address is represented as a name in the IP6.ARPA domain by a
-   sequence of nibbles separated by dots with the suffix ".IP6.ARPA".
-   The sequence of nibbles is encoded in reverse order, i.e., the
-   low-order nibble is encoded first, followed by the next low-order
-   nibble and so on.  Each nibble is represented by a hexadecimal digit.
-   For example, the reverse lookup domain name corresponding to the
-   address
-
-       4321:0:1:2:3:4:567:89ab
-
-   would be
-
-   b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
-                                                                  ARPA.
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 3]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-3. Modifications to existing query types
-
-   All existing query types that perform type A additional section
-   processing, i.e., name server (NS), location of services (SRV) and
-   mail exchange (MX) query types, must be redefined to perform both
-   type A and type AAAA additional section processing.  These
-   definitions mean that a name server must add any relevant IPv4
-   addresses and any relevant IPv6 addresses available locally to the
-   additional section of a response when processing any one of the above
-   queries.
-
-4. Security Considerations
-
-   Any information obtained from the DNS must be regarded as unsafe
-   unless techniques specified in [7] or [8] are used.  The definitions
-   of the AAAA record type and of the IP6.ARPA domain do not change the
-   model for use of these techniques.
-
-   So, this specification is not believed to cause any new security
-   problems, nor to solve any existing ones.
-
-5. IANA Considerations
-
-   There are no IANA assignments to be performed.
-
-6. Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 4]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-Acknowledgments
-
-   Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien
-   Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin
-   (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic
-   Roudaut (IRISA) and G6 group for their help during the RFC 1886
-   Interop tests sessions.
-
-   Many thanks to Alain Durand and Olafur Gudmundsson for their support.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 5]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-Appendix A: Changes from RFC 1886
-
-   The following changes were made from RFC 1886 "DNS Extensions to
-   support IP version 6":
-
-   - Replaced the "IP6.INT" domain by "IP6.ARPA".
-   - Mentioned SRV query types in section 3 "MODIFICATIONS TO
-     EXISTING QUERY TYPES"
-   - Added security considerations.
-   - Updated references :
-     * From RFC 1884 to RFC 3513 (IP Version 6 Addressing
-       Architecture).
-     * From "work in progress" to RFC 2893 (Transition Mechanisms for
-       IPv6 Hosts and Routers).
-     * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845.
-   - Updated document abstract
-   - Added table of contents
-   - Added full copyright statement
-   - Added IANA considerations section
-   - Added Intellectual Property Statement
-
-Normative References
-
-   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
-        13, RFC 1034, November 1987.
-
-   [2]  Mockapetris, P., "Domain Names - Implementation and
-        Specification", STD 13, RFC 1035, November 1987.
-
-   [3]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
-        Addressing Architecture", RFC 3513, April 2003.
-
-Informative References
-
-   [4]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
-        Hosts and Routers", RFC 2893, August 2000.
-
-   [5]  Thomson, S. and C. Huitema, "DNS Extensions to support IP
-        version 6", RFC 1886, December 1995.
-
-   [6]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August
-        2001.
-
-   [7]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 6]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-   [8]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-        "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-        2845, May 2000.
-
-Authors' Addresses
-
-   Susan Thomson
-   Cisco Systems
-   499 Thornall Street, 8th floor
-   Edison, NJ 08837
-
-   Phone: +1 732-635-3086
-   EMail:  sethomso@cisco.com
-
-
-   Christian Huitema
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052-6399
-
-   EMail: huitema@microsoft.com
-
-
-   Vladimir Ksinant
-   6WIND S.A.
-   Immeuble Central Gare - Bat.C
-   1, place Charles de Gaulle
-   78180, Montigny-Le-Bretonneux - France
-
-   Phone: +33 1 39 30 92 36
-   EMail: vladimir.ksinant@6wind.com
-
-
-   Mohsen Souissi
-   AFNIC
-   Immeuble International
-   2, rue Stephenson,
-   78181, Saint-Quentin en Yvelines Cedex - France
-
-   Phone: +33 1 39 30 83 40
-   EMail: Mohsen.Souissi@nic.fr
-
-
-
-
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 7]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 8]
-
diff --git a/doc/rfc/rfc3597.txt b/doc/rfc/rfc3597.txt
deleted file mode 100644
index 19e9a550..00000000
--- a/doc/rfc/rfc3597.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      A. Gustafsson
-Request for Comments: 3597                                  Nominum Inc.
-Category: Standards Track                                 September 2003
-
-
-           Handling of Unknown DNS Resource Record (RR) Types
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   Extending the Domain Name System (DNS) with new Resource Record (RR)
-   types currently requires changes to name server software.  This
-   document specifies the changes necessary to allow future DNS
-   implementations to handle new RR types transparently.
-
-1.  Introduction
-
-   The DNS is designed to be extensible to support new services through
-   the introduction of new resource record (RR) types.  In practice,
-   deploying a new RR type currently requires changes to the name server
-   software not only at the authoritative DNS server that is providing
-   the new information and the client making use of it, but also at all
-   slave servers for the zone containing it, and in some cases also at
-   caching name servers and forwarders used by the client.
-
-   Because the deployment of new server software is slow and expensive,
-   the potential of the DNS in supporting new services has never been
-   fully realized.  This memo proposes changes to name servers and to
-   procedures for defining new RR types aimed at simplifying the future
-   deployment of new RR types.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 1]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-2.  Definition
-
-   An "RR of unknown type" is an RR whose RDATA format is not known to
-   the DNS implementation at hand, and whose type is not an assigned
-   QTYPE or Meta-TYPE as specified in [RFC 2929] (section 3.1) nor
-   within the range reserved in that section for assignment only to
-   QTYPEs and Meta-TYPEs.  Such an RR cannot be converted to a type-
-   specific text format, compressed, or otherwise handled in a type-
-   specific way.
-
-   In the case of a type whose RDATA format is class specific, an RR is
-   considered to be of unknown type when the RDATA format for that
-   combination of type and class is not known.
-
-3.  Transparency
-
-   To enable new RR types to be deployed without server changes, name
-   servers and resolvers MUST handle RRs of unknown type transparently.
-   That is, they must treat the RDATA section of such RRs as
-   unstructured binary data, storing and transmitting it without change
-   [RFC1123].
-
-   To ensure the correct operation of equality comparison (section 6)
-   and of the DNSSEC canonical form (section 7) when an RR type is known
-   to some but not all of the servers involved, servers MUST also
-   exactly preserve the RDATA of RRs of known type, except for changes
-   due to compression or decompression where allowed by section 4 of
-   this memo.  In particular, the character case of domain names that
-   are not subject to compression MUST be preserved.
-
-4.  Domain Name Compression
-
-   RRs containing compression pointers in the RDATA part cannot be
-   treated transparently, as the compression pointers are only
-   meaningful within the context of a DNS message.  Transparently
-   copying the RDATA into a new DNS message would cause the compression
-   pointers to point at the corresponding location in the new message,
-   which now contains unrelated data.  This would cause the compressed
-   name to be corrupted.
-
-   To avoid such corruption, servers MUST NOT compress domain names
-   embedded in the RDATA of types that are class-specific or not well-
-   known.  This requirement was stated in [RFC1123] without defining the
-   term "well-known"; it is hereby specified that only the RR types
-   defined in [RFC1035] are to be considered "well-known".
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 2]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-   The specifications of a few existing RR types have explicitly allowed
-   compression contrary to this specification: [RFC2163] specified that
-   compression applies to the PX RR, and [RFC2535] allowed compression
-   in SIG RRs and NXT RRs records.  Since this specification disallows
-   compression in these cases, it is an update to [RFC2163] (section 4)
-   and [RFC2535] (sections 4.1.7 and 5.2).
-
-   Receiving servers MUST decompress domain names in RRs of well-known
-   type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
-   NXT, NAPTR, and SRV (although the current specification of the SRV RR
-   in [RFC2782] prohibits compression, [RFC2052] mandated it, and some
-   servers following that earlier specification are still in use).
-
-   Future specifications for new RR types that contain domain names
-   within their RDATA MUST NOT allow the use of name compression for
-   those names, and SHOULD explicitly state that the embedded domain
-   names MUST NOT be compressed.
-
-   As noted in [RFC1123], the owner name of an RR is always eligible for
-   compression.
-
-5.  Text Representation
-
-   In the "type" field of a master file line, an unknown RR type is
-   represented by the word "TYPE" immediately followed by the decimal RR
-   type number, with no intervening whitespace.  In the "class" field,
-   an unknown class is similarly represented as the word "CLASS"
-   immediately followed by the decimal class number.
-
-   This convention allows types and classes to be distinguished from
-   each other and from TTL values, allowing the "[<TTL>] [<class>]
-   <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
-   [RFC1035] to both be unambiguously parsed.
-
-   The RDATA section of an RR of unknown type is represented as a
-   sequence of white space separated words as follows:
-
-      The special token \# (a backslash immediately followed by a hash
-      sign), which identifies the RDATA as having the generic encoding
-      defined herein rather than a traditional type-specific encoding.
-
-      An unsigned decimal integer specifying the RDATA length in octets.
-
-      Zero or more words of hexadecimal data encoding the actual RDATA
-      field, each containing an even number of hexadecimal digits.
-
-   If the RDATA is of zero length, the text representation contains only
-   the \# token and the single zero representing the length.
-
-
-
-Gustafsson                  Standards Track                     [Page 3]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-   An implementation MAY also choose to represent some RRs of known type
-   using the above generic representations for the type, class and/or
-   RDATA, which carries the benefit of making the resulting master file
-   portable to servers where these types are unknown.  Using the generic
-   representation for the RDATA of an RR of known type can also be
-   useful in the case of an RR type where the text format varies
-   depending on a version, protocol, or similar field (or several)
-   embedded in the RDATA when such a field has a value for which no text
-   format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
-   0.
-
-   Even though an RR of known type represented in the \# format is
-   effectively treated as an unknown type for the purpose of parsing the
-   RDATA text representation, all further processing by the server MUST
-   treat it as a known type and take into account any applicable type-
-   specific rules regarding compression, canonicalization, etc.
-
-   The following are examples of RRs represented in this manner,
-   illustrating various combinations of generic and type-specific
-   encodings for the different fields of the master file format:
-
-      a.example.   CLASS32     TYPE731         \# 6 abcd (
-                                               ef 01 23 45 )
-      b.example.   HS          TYPE62347       \# 0
-      e.example.   IN          A               \# 4 0A000001
-      e.example.   CLASS1      TYPE1           10.0.0.2
-
-6.  Equality Comparison
-
-   Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
-   to be compared for equality.  Two RRs of the same unknown type are
-   considered equal when their RDATA is bitwise equal.  To ensure that
-   the outcome of the comparison is identical whether the RR is known to
-   the server or not, specifications for new RR types MUST NOT specify
-   type-specific comparison rules.
-
-   This implies that embedded domain names, being included in the
-   overall bitwise comparison, are compared in a case-sensitive manner.
-
-   As a result, when a new RR type contains one or more embedded domain
-   names, it is possible to have multiple RRs owned by the same name
-   that differ only in the character case of the embedded domain
-   name(s).  This is similar to the existing possibility of multiple TXT
-   records differing only in character case, and not expected to cause
-   any problems in practice.
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 4]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-7.  DNSSEC Canonical Form and Ordering
-
-   DNSSEC defines a canonical form and ordering for RRs [RFC2535]
-   (section 8.1).  In that canonical form, domain names embedded in the
-   RDATA are converted to lower case.
-
-   The downcasing is necessary to ensure the correctness of DNSSEC
-   signatures when case distinctions in domain names are lost due to
-   compression, but since it requires knowledge of the presence and
-   position of embedded domain names, it cannot be applied to unknown
-   types.
-
-   To ensure continued consistency of the canonical form of RR types
-   where compression is allowed, and for continued interoperability with
-   existing implementations that already implement the [RFC2535]
-   canonical form and apply it to their known RR types, the canonical
-   form remains unchanged for all RR types whose whose initial
-   publication as an RFC was prior to the initial publication of this
-   specification as an RFC (RFC 3597).
-
-   As a courtesy to implementors, it is hereby noted that the complete
-   set of such previously published RR types that contain embedded
-   domain names, and whose DNSSEC canonical form therefore involves
-   downcasing according to the DNS rules for character comparisons,
-   consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
-   HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
-   DNAME, and A6.
-
-   This document specifies that for all other RR types (whether treated
-   as unknown types or treated as known types according to an RR type
-   definition RFC more recent than RFC 3597), the canonical form is such
-   that no downcasing of embedded domain names takes place, and
-   otherwise identical to the canonical form specified in [RFC2535]
-   section 8.1.
-
-   Note that the owner name is always set to lower case according to the
-   DNS rules for character comparisons, regardless of the RR type.
-
-   The DNSSEC canonical RR ordering is as specified in [RFC2535] section
-   8.3, where the octet sequence is the canonical form as revised by
-   this specification.
-
-8.  Additional Section Processing
-
-   Unknown RR types cause no additional section processing.  Future RR
-   type specifications MAY specify type-specific additional section
-   processing rules, but any such processing MUST be optional as it can
-   only be performed by servers for which the RR type in case is known.
-
-
-
-Gustafsson                  Standards Track                     [Page 5]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-9.  IANA Considerations
-
-   This document does not require any IANA actions.
-
-10.  Security Considerations
-
-   This specification is not believed to cause any new security
-   problems, nor to solve any existing ones.
-
-11.  Normative References
-
-   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
-               Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts --
-               Application and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535]   Eastlake, D., "Domain Name System Security Extensions",
-               RFC 2535, March 1999.
-
-   [RFC2163]   Allocchio, C., "Using the Internet DNS to Distribute
-               MIXER Conformant Global Address Mapping (MCGAM)", RFC
-               2163, January 1998.
-
-   [RFC2929]   Eastlake, D., Brunner-Williams, E. and B. Manning,
-               "Domain Name System (DNS) IANA Considerations", BCP 42,
-               RFC 2929, September 2000.
-
-12.  Informative References
-
-   [RFC1876]   Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
-               Means for Expressing Location Information in the Domain
-               Name System", RFC 1876, January 1996.
-
-   [RFC2052]   Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
-               the location of services (DNS SRV)", RFC 2052, October
-               1996.
-
-   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
-               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-               RFC 2136, April 1997.
-
-
-
-
-Gustafsson                  Standards Track                     [Page 6]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-   [RFC2782]   Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
-               specifying the location of services (DNS SRV)", RFC 2782,
-               February 2000.
-
-13.  Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-14.  Author's Address
-
-   Andreas Gustafsson
-   Nominum, Inc.
-   2385 Bay Rd
-   Redwood City, CA 94063
-   USA
-
-   Phone: +1 650 381 6004
-   EMail: gson@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 7]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-15.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 8]
-
diff --git a/doc/rfc/rfc3645.txt b/doc/rfc/rfc3645.txt
deleted file mode 100644
index 61266786..00000000
--- a/doc/rfc/rfc3645.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            S. Kwan
-Request for Comments: 3645                                       P. Garg
-Updates: 2845                                                  J. Gilroy
-Category: Standards Track                                      L. Esibov
-                                                             J. Westhead
-                                                         Microsoft Corp.
-                                                                 R. Hall
-                                                     Lucent Technologies
-                                                            October 2003
-
-
-                 Generic Security Service Algorithm for
-        Secret Key Transaction Authentication for DNS (GSS-TSIG)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   The Secret Key Transaction Authentication for DNS (TSIG) protocol
-   provides transaction level authentication for DNS.  TSIG is
-   extensible through the definition of new algorithms.  This document
-   specifies an algorithm based on the Generic Security Service
-   Application Program Interface (GSS-API) (RFC2743).  This document
-   updates RFC 2845.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 1]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  Algorithm Overview . . . . . . . . . . . . . . . . . . . . . .  3
-       2.1.  GSS Details. . . . . . . . . . . . . . . . . . . . . . .  4
-       2.2.  Modifications to the TSIG protocol (RFC 2845). . . . . .  4
-   3.  Client Protocol Details. . . . . . . . . . . . . . . . . . . .  5
-       3.1.  Negotiating Context. . . . . . . . . . . . . . . . . . .  5
-           3.1.1.  Call GSS_Init_sec_context. . . . . . . . . . . . .  6
-           3.1.2.  Send TKEY Query to Server. . . . . . . . . . . . .  8
-           3.1.3.  Receive TKEY Query-Response from Server. . . . . .  8
-       3.2.  Context Established. . . . . . . . . . . . . . . . . . . 11
-           3.2.1.  Terminating a Context. . . . . . . . . . . . . . . 11
-   4.  Server Protocol Details. . . . . . . . . . . . . . . . . . . . 12
-       4.1.  Negotiating Context. . . . . . . . . . . . . . . . . . . 12
-           4.1.1.  Receive TKEY Query from Client . . . . . . . . . . 12
-           4.1.2.  Call GSS_Accept_sec_context. . . . . . . . . . . . 12
-           4.1.3.  Send TKEY Query-Response to Client . . . . . . . . 13
-       4.2.  Context Established. . . . . . . . . . . . . . . . . . . 15
-           4.2.1.  Terminating a Context. . . . . . . . . . . . . . . 15
-   5.  Sending and Verifying Signed Messages. . . . . . . . . . . . . 15
-       5.1.  Sending a Signed Message - Call GSS_GetMIC . . . . . . . 15
-       5.2.  Verifying a Signed Message - Call GSS_VerifyMIC. . . . . 16
-   6.  Example usage of GSS-TSIG algorithm. . . . . . . . . . . . . . 18
-   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 22
-   8.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
-   9.  Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . 22
-   10. Intellectual Property Statement. . . . . . . . . . . . . . . . 23
-   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
-   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
-       12.1.  Normative References. . . . . . . . . . . . . . . . . . 24
-       12.2.  Informative References. . . . . . . . . . . . . . . . . 24
-   13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
-   14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
-
-1.  Introduction
-
-   The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
-   protocol was developed to provide a lightweight authentication and
-   integrity of messages between two DNS entities, such as client and
-   server or server and server.  TSIG can be used to protect dynamic
-   update messages, authenticate regular message or to off-load
-   complicated DNSSEC [RFC2535] processing from a client to a server and
-   still allow the client to be assured of the integrity of the answers.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 2]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   The TSIG protocol [RFC2845] is extensible through the definition of
-   new algorithms.  This document specifies an algorithm based on the
-   Generic Security Service Application Program Interface (GSS-API)
-   [RFC2743].  GSS-API is a framework that provides an abstraction of
-   security to the application protocol developer.  The security
-   services offered can include authentication, integrity, and
-   confidentiality.
-
-   The GSS-API framework has several benefits:
-
-   *  Mechanism and protocol independence.  The underlying mechanisms
-      that realize the security services can be negotiated on the fly
-      and varied over time.  For example, a client and server MAY use
-      Kerberos [RFC1964] for one transaction, whereas that same server
-      MAY use SPKM [RFC2025] with a different client.
-
-   *  The protocol developer is removed from the responsibility of
-      creating and managing a security infrastructure.  For example, the
-      developer does not need to create new key distribution or key
-      management systems.  Instead the developer relies on the security
-      service mechanism to manage this on its behalf.
-
-   The scope of this document is limited to the description of an
-   authentication mechanism only.  It does not discuss and/or propose an
-   authorization mechanism.  Readers that are unfamiliar with GSS-API
-   concepts are encouraged to read the characteristics and concepts
-   section of [RFC2743] before examining this protocol in detail.  It is
-   also assumed that the reader is familiar with [RFC2845], [RFC2930],
-   [RFC1034] and [RFC1035].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
-   "RECOMMENDED", and "MAY" in this document are to be interpreted as
-   described in BCP 14, RFC 2119 [RFC2119].
-
-2.  Algorithm Overview
-
-   In GSS, client and server interact to create a "security context".
-   The security context can be used to create and verify transaction
-   signatures on messages between the two parties.  A unique security
-   context is required for each unique connection between client and
-   server.
-
-   Creating a security context involves a negotiation between client and
-   server.  Once a context has been established, it has a finite
-   lifetime for which it can be used to secure messages.  Thus there are
-   three states of a context associated with a connection:
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 3]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-                              +----------+
-                              |          |
-                              V          |
-                      +---------------+  |
-                      | Uninitialized |  |
-                      |               |  |
-                      +---------------+  |
-                              |          |
-                              V          |
-                      +---------------+  |
-                      | Negotiating   |  |
-                      | Context       |  |
-                      +---------------+  |
-                              |          |
-                              V          |
-                      +---------------+  |
-                      | Context       |  |
-                      | Established   |  |
-                      +---------------+  |
-                              |          |
-                              +----------+
-
-   Every connection begins in the uninitialized state.
-
-2.1.  GSS Details
-
-   Client and server MUST be locally authenticated and have acquired
-   default credentials before using this protocol as specified in
-   Section 1.1.1 "Credentials" in RFC 2743 [RFC2743].
-
-   The GSS-TSIG algorithm consists of two stages:
-
-   I.  Establish security context.  The Client and Server use the
-       GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate
-       the tokens that they pass to each other using [RFC2930] as a
-       transport mechanism.
-
-   II. Once the security context is established it is used to generate
-       and verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs.
-       These signatures are exchanged by the Client and Server as a part
-       of the TSIG records exchanged in DNS messages sent between the
-       Client and Server, as described in [RFC2845].
-
-2.2.  Modifications to the TSIG protocol (RFC 2845)
-
-   Modification to RFC 2845 allows use of TSIG through signing server's
-   response in an explicitly specified place in multi message exchange
-   between two DNS entities even if client's request wasn't signed.
-
-
-
-Kwan, et al.                Standards Track                     [Page 4]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   Specifically, Section 4.2 of RFC 2845 MUST be modified as follows:
-
-   Replace:
-      "The server MUST not generate a signed response to an unsigned
-      request."
-
-   With:
-      "The server MUST not generate a signed response to an unsigned
-      request, except in case of response to client's unsigned TKEY
-      query if secret key is established on server side after server
-      processed client's query.  Signing responses to unsigned TKEY
-      queries MUST be explicitly specified in the description of an
-      individual secret key establishment algorithm."
-
-3.  Client Protocol Details
-
-   A unique context is required for each server to which the client
-   sends secure messages.  A context is identified by a context handle.
-   A client maintains a mapping of servers to handles:
-
-      (target_name, key_name, context_handle)
-
-   The value key_name also identifies a context handle.  The key_name is
-   the owner name of the TKEY and TSIG records sent between a client and
-   a server to indicate to each other which context MUST be used to
-   process the current request.
-
-   DNS client and server MAY use various underlying security mechanisms
-   to establish security context as described in sections 3 and 4.  At
-   the same time, in order to guarantee interoperability between DNS
-   clients and servers that support GSS-TSIG it is REQUIRED that
-   security mechanism used by client enables use of Kerberos v5 (see
-   Section 9 for more information).
-
-3.1.  Negotiating Context
-
-   In GSS, establishing a security context involves the passing of
-   opaque tokens between the client and the server.  The client
-   generates the initial token and sends it to the server.  The server
-   processes the token and if necessary, returns a subsequent token to
-   the client.  The client processes this token, and so on, until the
-   negotiation is complete.  The number of times the client and server
-   exchange tokens depends on the underlying security mechanism.  A
-   completed negotiation results in a context handle.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 5]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   The TKEY resource record [RFC2930] is used as the vehicle to transfer
-   tokens between client and server.  The TKEY record is a general
-   mechanism for establishing secret keys for use with TSIG.  For more
-   information, see [RFC2930].
-
-3.1.1.  Call GSS_Init_sec_context
-
-   To obtain the first token to be sent to a server, a client MUST call
-   GSS_Init_sec_context API.
-
-   The following input parameters MUST be used.  The outcome of the call
-   is indicated with the output values below.  Consult Sections 2.2.1,
-   "GSS_Init_sec_context call", of [RFC2743] for syntax definitions.
-
-   INPUTS
-     CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use
-         default").  Client MAY instead specify some other valid
-         handle to its credentials.
-     CONTEXT HANDLE input_context_handle  = 0
-     INTERNAL NAME  targ_name             = "DNS@<target_server_name>"
-     OBJECT IDENTIFIER mech_type          = Underlying security
-         mechanism chosen by implementers.  To guarantee
-         interoperability of the implementations of the GSS-TSIG
-         mechanism client MUST specify a valid underlying security
-         mechanism that enables use of Kerberos v5 (see Section 9 for
-         more information).
-     OCTET STRING   input_token           = NULL
-     BOOLEAN        replay_det_req_flag   = TRUE
-     BOOLEAN        mutual_req_flag       = TRUE
-     BOOLEAN        deleg_req_flag        = TRUE
-     BOOLEAN        sequence_req_flag     = TRUE
-     BOOLEAN        anon_req_flag         = FALSE
-     BOOLEAN        integ_req_flag        = TRUE
-     INTEGER        lifetime_req          = 0 (0 requests a default
-         value).  Client MAY instead specify another upper bound for the
-         lifetime of the context to be established in seconds.
-     OCTET STRING   chan_bindings         = Any valid channel bindings
-         as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
-
-   OUTPUTS
-     INTEGER        major_status
-     CONTEXT HANDLE output_context_handle
-     OCTET STRING   output_token
-     BOOLEAN        replay_det_state
-     BOOLEAN        mutual_state
-     INTEGER        minor_status
-     OBJECT IDENTIFIER mech_type
-     BOOLEAN        deleg_state
-
-
-
-Kwan, et al.                Standards Track                     [Page 6]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-     BOOLEAN        sequence_state
-     BOOLEAN        anon_state
-     BOOLEAN        trans_state
-     BOOLEAN        prot_ready_state
-     BOOLEAN        conf_avail
-     BOOLEAN        integ_avail
-     INTEGER        lifetime_rec
-
-   If returned major_status is set to one of the following errors:
-
-     GSS_S_DEFECTIVE_TOKEN
-     GSS_S_DEFECTIVE_CREDENTIAL
-     GSS_S_BAD_SIG (GSS_S_BAD_MIC)
-     GSS_S_NO_CRED
-     GSS_S_CREDENTIALS_EXPIRED
-     GSS_S_BAD_BINDINGS
-     GSS_S_OLD_TOKEN
-     GSS_S_DUPLICATE_TOKEN
-     GSS_S_NO_CONTEXT
-     GSS_S_BAD_NAMETYPE
-     GSS_S_BAD_NAME
-     GSS_S_BAD_MECH
-     GSS_S_FAILURE
-
-   then the client MUST abandon the algorithm and MUST NOT use the GSS-
-   TSIG algorithm to establish this security context.  This document
-   does not prescribe which other mechanism could be used to establish a
-   security context.  Next time when this client needs to establish
-   security context, the client MAY use GSS-TSIG algorithm.
-
-   Success values of major_status are GSS_S_CONTINUE_NEEDED and
-   GSS_S_COMPLETE.  The exact success code is important during later
-   processing.
-
-   The values of replay_det_state and mutual_state indicate if the
-   security package provides replay detection and mutual authentication,
-   respectively.  If returned major_status is GSS_S_COMPLETE AND one or
-   both of these values are FALSE, the client MUST abandon this
-   algorithm.
-
-   Client's behavior MAY depend on other OUTPUT parameters according to
-   the policy local to the client.
-
-   The handle output_context_handle is unique to this negotiation and is
-   stored in the client's mapping table as the context_handle that maps
-   to target_name.
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 7]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-3.1.2.  Send TKEY Query to Server
-
-   An opaque output_token returned by GSS_Init_sec_context is
-   transmitted to the server in a query request with QTYPE=TKEY.  The
-   token itself will be placed in a Key Data field of the RDATA field in
-   the TKEY resource record in the additional records section of the
-   query.  The owner name of the TKEY resource record set queried for
-   and the owner name of the supplied TKEY resource record in the
-   additional records section MUST be the same.  This name uniquely
-   identifies the security context to both the client and server, and
-   thus the client SHOULD use a value which is globally unique as
-   described in [RFC2930].  To achieve global uniqueness, the name MAY
-   contain a UUID/GUID [ISO11578].
-
-      TKEY Record
-        NAME = client-generated globally unique domain name string
-               (as described in [RFC2930])
-        RDATA
-           Algorithm Name      = gss-tsig
-           Mode                = 3 (GSS-API negotiation - per [RFC2930])
-           Key Size            = size of output_token in octets
-           Key Data            = output_token
-
-   The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
-   Error, Other Size and Data Fields, MUST be set according to
-   [RFC2930].
-
-   The query is transmitted to the server.
-
-   Note: if the original client call to GSS_Init_sec_context returned
-   any major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE,
-   then the client MUST NOT send TKEY query.  Client's behavior in this
-   case is described above in Section 3.1.1.
-
-3.1.3.  Receive TKEY Query-Response from Server
-
-   Upon the reception of the TKEY query the DNS server MUST respond
-   according to the description in Section 4.  This section specifies
-   the behavior of the client after it receives the matching response to
-   its query.
-
-   The next processing step depends on the value of major_status from
-   the most recent call that client performed to GSS_Init_sec_context:
-   either GSS_S_COMPLETE or GSS_S_CONTINUE.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 8]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-3.1.3.1.  Value of major_status == GSS_S_COMPLETE
-
-   If the last call to GSS_Init_sec_context yielded a major_status value
-   of GSS_S_COMPLETE and a non-NULL output_token was sent to the server,
-   then the client side component of the negotiation is complete and the
-   client is awaiting confirmation from the server.
-
-   Confirmation is in the form of a query response with RCODE=NOERROR
-   and with the last client supplied TKEY record in the answer section
-   of the query.  The response MUST be signed with a TSIG record.  Note
-   that the server is allowed to sign a response to unsigned client's
-   query due to modification to the RFC 2845 specified in Section 2.2
-   above.  The signature in the TSIG record MUST be verified using the
-   procedure detailed in section 5, Sending and Verifying Signed
-   Messages.  If the response is not signed, OR if the response is
-   signed but the signature is invalid, then an attacker has tampered
-   with the message in transit or has attempted to send the client a
-   false response.  In this case, the client MAY continue waiting for a
-   response to its last TKEY query until the time period since the
-   client sent last TKEY query expires.  Such a time period is specified
-   by the policy local to the client.  This is a new option that allows
-   the DNS client to accept multiple answers for one query ID and select
-   one (not necessarily the first one) based on some criteria.
-
-   If the signature is verified, the context state is advanced to
-   Context Established.  Proceed to section 3.2 for usage of the
-   security context.
-
-3.1.3.2.  Value of major_status == GSS_S_CONTINUE_NEEDED
-
-   If the last call to GSS_Init_sec_context yielded a major_status value
-   of GSS_S_CONTINUE_NEEDED, then the negotiation is not yet complete.
-   The server will return to the client a query response with a TKEY
-   record in the Answer section.  If the DNS message error is not
-   NO_ERROR or error field in the TKEY record is not 0 (i.e., no error),
-   then the client MUST abandon this negotiation sequence.  The client
-   MUST delete an active context by calling GSS_Delete_sec_context
-   providing the associated context_handle.  The client MAY repeat the
-   negotiation sequence starting with the uninitialized state as
-   described in section 3.1.  To prevent infinite looping the number of
-   attempts to establish a security context MUST be limited to ten or
-   less.
-
-   If the DNS message error is NO_ERROR and the error field in the TKEY
-   record is 0 (i.e., no error), then the client MUST pass a token
-   specified in the Key Data field in the TKEY resource record to
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 9]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   GSS_Init_sec_context using the same parameters values as in previous
-   call except values for CONTEXT HANDLE input_context_handle and OCTET
-   STRING input_token as described below:
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = context_handle (this is the
-          context_handle corresponding to the key_name which is the
-          owner name of the TKEY record in the answer section in the
-          TKEY query response)
-
-     OCTET STRING   input_token           = token from Key field of
-                                            TKEY record
-
-   Depending on the following OUTPUT values of GSS_Init_sec_context
-
-        INTEGER        major_status
-        OCTET STRING   output_token
-
-   the client MUST take one of the following actions:
-
-   If OUTPUT major_status is set to one of the following values:
-
-        GSS_S_DEFECTIVE_TOKEN
-        GSS_S_DEFECTIVE_CREDENTIAL
-        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
-        GSS_S_NO_CRED
-        GSS_S_CREDENTIALS_EXPIRED
-        GSS_S_BAD_BINDINGS
-        GSS_S_OLD_TOKEN
-        GSS_S_DUPLICATE_TOKEN
-        GSS_S_NO_CONTEXT
-        GSS_S_BAD_NAMETYPE
-        GSS_S_BAD_NAME
-        GSS_S_BAD_MECH
-        GSS_S_FAILURE
-
-   the client MUST abandon this negotiation sequence.  This means that
-   the client MUST delete an active context by calling
-   GSS_Delete_sec_context providing the associated context_handle.  The
-   client MAY repeat the negotiation sequence starting with the
-   uninitialized state as described in section 3.1.  To prevent infinite
-   looping the number of attempts to establish a security context MUST
-   be limited to ten or less.
-
-   If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE
-   then client MUST act as described below.
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 10]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   If the response from the server was signed, and the OUTPUT
-   major_status is GSS_S_COMPLETE,then the signature in the TSIG record
-   MUST be verified using the procedure detailed in section 5, Sending
-   and Verifying Signed Messages.  If the signature is invalid, then the
-   client MUST abandon this negotiation sequence.  This means that the
-   client MUST delete an active context by calling
-   GSS_Delete_sec_context providing the associated context_handle.  The
-   client MAY repeat the negotiation sequence starting with the
-   uninitialized state as described in section 3.1.  To prevent infinite
-   looping the number of attempts to establish a security context MUST
-   be limited to ten or less.
-
-   If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
-   finished.  The token output_token MUST be passed to the server in a
-   TKEY record by repeating the negotiation sequence beginning with
-   section 3.1.2.  The client MUST place a limit on the number of
-   continuations in a context negotiation to prevent endless looping.
-   Such limit SHOULD NOT exceed value of 10.
-
-   If major_status is GSS_S_COMPLETE and output_token is non-NULL, the
-   client-side component of the negotiation is complete but the token
-   output_token MUST be passed to the server by repeating the
-   negotiation sequence beginning with section 3.1.2.
-
-   If major_status is GSS_S_COMPLETE and output_token is NULL, context
-   negotiation is complete.  The context state is advanced to Context
-   Established.  Proceed to section 3.2 for usage of the security
-   context.
-
-3.2.  Context Established
-
-   When context negotiation is complete, the handle context_handle MUST
-   be used for the generation and verification of transaction
-   signatures.
-
-   The procedures for sending and receiving signed messages are
-   described in section 5, Sending and Verifying Signed Messages.
-
-3.2.1.  Terminating a Context
-
-   When the client is not intended to continue using the established
-   security context, the client SHOULD delete an active context by
-   calling GSS_Delete_sec_context providing the associated
-   context_handle, AND client SHOULD delete the established context on
-   the DNS server by using TKEY RR with the Mode field set to 5, i.e.,
-   "key deletion" [RFC2930].
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 11]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-4.  Server Protocol Details
-
-   As on the client-side, the result of a successful context negotiation
-   is a context handle used in future generation and verification of the
-   transaction signatures.
-
-   A server MAY be managing several contexts with several clients.
-   Clients identify their contexts by providing a key name in their
-   request.  The server maintains a mapping of key names to handles:
-
-      (key_name, context_handle)
-
-4.1.  Negotiating Context
-
-   A server MUST recognize TKEY queries as security context negotiation
-   messages.
-
-4.1.1.  Receive TKEY Query from Client
-
-   Upon receiving a query with QTYPE = TKEY, the server MUST examine
-   whether the Mode and Algorithm Name fields of the TKEY record in the
-   additional records section of the message contain values of 3 and
-   gss-tsig, respectively.  If they do, then the (key_name,
-   context_handle) mapping table is searched for the key_name matching
-   the owner name of the TKEY record in the additional records section
-   of the query.  If the name is found in the table and the security
-   context for this name is established and not expired, then the server
-   MUST respond to the query with BADNAME error in the TKEY error field.
-   If the name is found in the table and the security context is not
-   established, the corresponding context_handle is used in subsequent
-   GSS operations.  If the name is found but the security context is
-   expired, then the server deletes this security context, as described
-   in Section 4.2.1, and interprets this query as a start of new
-   security context negotiation and performs operations described in
-   Section 4.1.2 and 4.1.3.  If the name is not found, then the server
-   interprets this query as a start of new security context negotiation
-   and performs operations described in Section 4.1.2 and 4.1.3.
-
-4.1.2.  Call GSS_Accept_sec_context
-
-   The server performs its side of a context negotiation by calling
-   GSS_Accept_sec_context.  The following input parameters MUST be used.
-   The outcome of the call is indicated with the output values below.
-   Consult Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743
-   [RFC2743] for syntax definitions.
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 12]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = 0 if new negotiation,
-                                            context_handle matching
-                                         key_name if ongoing negotiation
-     OCTET STRING   input_token           = token specified in the Key
-           field from TKEY RR (from Additional records Section of
-           the client's query)
-
-     CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use
-           default").  Server MAY instead specify some other valid
-           handle to its credentials.
-     OCTET STRING   chan_bindings          = Any valid channel bindings
-           as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
-
-   OUTPUTS
-     INTEGER        major_status
-     CONTEXT_HANDLE output_context_handle
-     OCTET STRING   output_token
-     INTEGER        minor_status
-     INTERNAL NAME  src_name
-     OBJECT IDENTIFIER  mech_type
-     BOOLEAN        deleg_state
-     BOOLEAN        mutual_state
-     BOOLEAN        replay_det_state
-     BOOLEAN        sequence_state
-     BOOLEAN        anon_state
-     BOOLEAN        trans_state
-     BOOLEAN        prot_ready_state
-     BOOLEAN        conf_avail
-     BOOLEAN        integ_avail
-     INTEGER        lifetime_rec
-     CONTEXT_HANDLE delegated_cred_handle
-
-   If this is the first call to GSS_Accept_sec_context in a new
-   negotiation, then output_context_handle is stored in the server's
-   key-mapping table as the context_handle that maps to the name of the
-   TKEY record.
-
-4.1.3.  Send TKEY Query-Response to Client
-
-   The server MUST respond to the client with a TKEY query response with
-   RCODE = NOERROR, that contains a TKEY record in the answer section.
-
-   If OUTPUT major_status is one of the following errors the error field
-   in the TKEY record set to BADKEY.
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 13]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-        GSS_S_DEFECTIVE_TOKEN
-        GSS_S_DEFECTIVE_CREDENTIAL
-        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
-        GSS_S_DUPLICATE_TOKEN
-        GSS_S_OLD_TOKEN
-        GSS_S_NO_CRED
-        GSS_S_CREDENTIALS_EXPIRED
-        GSS_S_BAD_BINDINGS
-        GSS_S_NO_CONTEXT
-        GSS_S_BAD_MECH
-        GSS_S_FAILURE
-
-   If OUTPUT major_status is set to  GSS_S_COMPLETE or
-   GSS_S_CONTINUE_NEEDED then server MUST act as described below.
-
-   If major_status is GSS_S_COMPLETE the server component of the
-   negotiation is finished.  If output_token is non-NULL, then it MUST
-   be returned to the client in a Key Data field of the RDATA in TKEY.
-   The error field in the TKEY record is set to NOERROR.  The message
-   MUST be signed with a TSIG record as described in section 5, Sending
-   and Verifying Signed Messages.  Note that server is allowed to sign a
-   response to unsigned client's query due to modification to the RFC
-   2845 specified in Section 2.2 above.  The context state is advanced
-   to Context Established.  Section 4.2 discusses the usage of the
-   security context.
-
-   If major_status is GSS_S_COMPLETE and output_token is NULL, then the
-   TKEY record received from the client MUST be returned in the Answer
-   section of the response.  The message MUST be signed with a TSIG
-   record as described in section 5, Sending and Verifying Signed
-   Messages.  Note that server is allowed to sign a response to unsigned
-   client's query due to modification to the RFC 2845 specified in
-   section 2.2 above.  The context state is advanced to Context
-   Established.  Section 4.2 discusses the usage of the security
-   context.
-
-   If major_status is GSS_S_CONTINUE_NEEDED, the server component of the
-   negotiation is not yet finished.  The server responds to the TKEY
-   query with a standard query response, placing in the answer section a
-   TKEY record containing output_token in the Key Data RDATA field.  The
-   error field in the TKEY record is set to NOERROR.  The server MUST
-   limit the number of times that a given context is allowed to repeat,
-   to prevent endless looping.  Such limit SHOULD NOT exceed value of
-   10.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 14]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   In all cases, except if major_status is GSS_S_COMPLETE and
-   output_token is NULL, other TKEY record fields MUST contain the
-   following values:
-
-        NAME = key_name
-        RDATA
-           Algorithm Name      = gss-tsig
-           Mode                = 3 (GSS-API negotiation - per [RFC2930])
-           Key Size            = size of output_token in octets
-
-   The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
-   Error, Other Size and Data Fields, MUST be set according to
-   [RFC2930].
-
-4.2.  Context Established
-
-   When context negotiation is complete, the handle context_handle is
-   used for the generation and verification of transaction signatures.
-   The handle is valid for a finite amount of time determined by the
-   underlying security mechanism.  A server MAY unilaterally terminate a
-   context at any time (see section 4.2.1).
-
-   Server SHOULD limit the amount of memory used to cache established
-   contexts.
-
-   The procedures for sending and receiving signed messages are given in
-   section 5, Sending and Verifying Signed Messages.
-
-4.2.1.  Terminating a Context
-
-   A server can terminate any established context at any time.  The
-   server MAY hint to the client that the context is being deleted by
-   including a TKEY RR in a response with the Mode field set to 5, i.e.,
-   "key deletion" [RFC2930].  An active context is deleted by calling
-   GSS_Delete_sec_context providing the associated context_handle.
-
-5.  Sending and Verifying Signed Messages
-
-5.1.  Sending a Signed Message - Call GSS_GetMIC
-
-   The procedure for sending a signature-protected message is specified
-   in [RFC2845].  The data to be passed to the signature routine
-   includes the whole DNS message with specific TSIG variables appended.
-   For the exact format, see [RFC2845].  For this protocol, use the
-   following TSIG variable values:
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 15]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-      TSIG Record
-        NAME = key_name that identifies this context
-        RDATA
-           Algorithm Name = gss-tsig
-
-   Assign the remaining fields in the TSIG RDATA appropriate values as
-   described in [RFC2845].
-
-   The signature is generated by calling GSS_GetMIC.  The following
-   input parameters MUST be used.  The outcome of the call is indicated
-   with the output values specified below.  Consult Sections 2.3.1
-   "GSS_GetMIC call" of the RFC 2743[RFC2743] for syntax definitions.
-
-   INPUTS
-     CONTEXT HANDLE context_handle = context_handle for key_name
-     OCTET STRING   message        = outgoing message plus TSIG
-                                     variables (per [RFC2845])
-     INTEGER qop_req               = 0 (0 requests a default
-         value).  Caller MAY instead specify other valid value (for
-         details see Section 1.2.4 in [RFC2743])
-
-   OUTPUTS
-     INTEGER        major_status
-     INTEGER        minor_status
-     OCTET STRING   per_msg_token
-
-   If major_status is GSS_S_COMPLETE, then signature generation
-   succeeded.  The signature in per_msg_token is inserted into the
-   Signature field of the TSIG RR and the message is transmitted.
-
-   If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED
-   or GSS_S_FAILURE the caller MUST delete the security context, return
-   to the uninitialized state and SHOULD negotiate a new security
-   context, as described above in Section 3.1
-
-   If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry
-   for key_name from the (target_ name, key_name, context_handle)
-   mapping table, return to the uninitialized state and SHOULD negotiate
-   a new security context, as described above in Section 3.1
-
-   If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the
-   GSS_GetMIC call with allowed QOP value.  The number of such
-   repetitions MUST be limited to prevent infinite loops.
-
-5.2.  Verifying a Signed Message - Call GSS_VerifyMIC
-
-   The procedure for verifying a signature-protected message is
-   specified in [RFC2845].
-
-
-
-Kwan, et al.                Standards Track                    [Page 16]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   The NAME of the TSIG record determines which context_handle maps to
-   the context that MUST be used to verify the signature.  If the NAME
-   does not map to an established context, the server MUST send a
-   standard TSIG error response to the client indicating BADKEY in the
-   TSIG error field (as described in [RFC2845]).
-
-   For the GSS algorithm, a signature is verified by using
-   GSS_VerifyMIC:
-
-   INPUTS
-     CONTEXT HANDLE context_handle = context_handle for key_name
-     OCTET STRING   message        = incoming message plus TSIG
-                                     variables (per [RFC2845])
-     OCTET STRING   per_msg_token  = Signature field from TSIG RR
-
-   OUTPUTS
-     INTEGER        major_status
-     INTEGER        minor_status
-     INTEGER        qop_state
-
-   If major_status is GSS_S_COMPLETE, the signature is authentic and the
-   message was delivered intact.  Per [RFC2845], the timer values of the
-   TSIG record MUST also be valid before considering the message to be
-   authentic.  The caller MUST not act on the request or response in the
-   message until these checks are verified.
-
-   When a server is processing a client request, the server MUST send a
-   standard TSIG error response to the client indicating BADKEY in the
-   TSIG error field as described in [RFC2845], if major_status is set to
-   one of the following values
-
-        GSS_S_DEFECTIVE_TOKEN
-        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
-        GSS_S_DUPLICATE_TOKEN
-        GSS_S_OLD_TOKEN
-        GSS_S_UNSEQ_TOKEN
-        GSS_S_GAP_TOKEN
-        GSS_S_CONTEXT_EXPIRED
-        GSS_S_NO_CONTEXT
-        GSS_S_FAILURE
-
-   If the timer values of the TSIG record are invalid, the message MUST
-   NOT be considered authentic.  If this error checking fails when a
-   server is processing a client request, the appropriate error response
-   MUST be sent to the client according to [RFC2845].
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 17]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-6.  Example usage of GSS-TSIG algorithm
-
-   This Section describes an example where a Client, client.example.com,
-   and a Server, server.example.com, establish a security context
-   according to the algorithm described above.
-
-  I.  Client initializes security context negotiation
-
-  To establish a security context with a server, server.example.com, the
-  Client calls GSS_Init_sec_context with the following parameters.
-  (Note that some INPUT and OUTPUT parameters not critical for this
-  algorithm are not described in this example.)
-
-     CONTEXT HANDLE input_context_handle  = 0
-     INTERNAL NAME  targ_name             = "DNS@server.example.com"
-     OCTET STRING   input_token           = NULL
-     BOOLEAN        replay_det_req_flag   = TRUE
-     BOOLEAN        mutual_req_flag       = TRUE
-
-  The OUTPUTS parameters returned by GSS_Init_sec_context include
-     INTEGER        major_status = GSS_S_CONTINUE_NEEDED
-     CONTEXT HANDLE output_context_handle context_handle
-     OCTET STRING   output_token output_token
-     BOOLEAN        replay_det_state = TRUE
-     BOOLEAN        mutual_state = TRUE
-
-  Client verifies that replay_det_state and mutual_state values are
-  TRUE.  Since the major_status is GSS_S_CONTINUE_NEEDED, which is a
-  success OUTPUT major_status value, client stores context_handle that
-  maps to "DNS@server.example.com" and proceeds to the next step.
-
-  II.  Client sends a query with QTYPE = TKEY to server
-
-  Client sends a query with QTYPE = TKEY for a client-generated globally
-  unique domain name string, 789.client.example.com.server.example.com.
-  Query contains a TKEY record in its Additional records section with
-  the following fields.  (Note that some fields not specific to this
-  algorithm are not specified.)
-
-     NAME = 789.client.example.com.server.example.com.
-     RDATA
-        Algorithm Name      = gss-tsig
-        Mode                = 3 (GSS-API negotiation - per [RFC2930])
-        Key Size            = size of output_token in octets
-        Key Data            = output_token
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 18]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-  After the key_name 789.client.example.com.server.example.com.
-  is generated it is stored in the client's (target_name, key_name,
-  context_handle) mapping table.
-
-  III.  Server receives a query with QTYPE = TKEY
-
-  When server receives a query with QTYPE = TKEY, the server verifies
-  that Mode and Algorithm fields in the TKEY record in the Additional
-  records section of the query are set to 3 and "gss-tsig" respectively.
-  It finds that the key_name 789.client.example.com.server.example.com.
-  is not listed in its (key_name, context_handle) mapping table.
-
-  IV.  Server calls GSS_Accept_sec_context
-
-  To continue security context negotiation server calls
-  GSS_Accept_sec_context with the following parameters.  (Note that
-  some INPUT and OUTPUT parameters not critical for this algorithm
-  are not described in this example.)
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = 0
-     OCTET STRING   input_token           = token specified in the Key
-                              field from TKEY RR (from Additional
-                              records section of the client's query)
-
-  The OUTPUTS parameters returned by GSS_Accept_sec_context include
-     INTEGER        major_status = GSS_S_CONTINUE_NEEDED
-     CONTEXT_HANDLE output_context_handle context_handle
-     OCTET STRING   output_token output_token
-
-  Server stores the mapping of the
-  789.client.example.com.server.example.com. to OUTPUT context_handle
-  in its (key_name, context_handle) mapping table.
-
-  V.  Server responds to the TKEY query
-
-  Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's
-  call to GSS_Accept_sec_context, the server responds to the TKEY query
-  placing in the answer section a TKEY record containing output_token in
-  the Key Data RDATA field.  The error field in the TKEY record is set
-  to 0.  The RCODE in the query response is set to NOERROR.
-
-  VI.  Client processes token returned by server
-
-  When the client receives the TKEY query response from the server, the
-  client calls GSS_Init_sec_context with the following parameters.
-  (Note that some INPUT and OUTPUT parameters not critical for this
-  algorithm are not described in this example.)
-
-
-
-Kwan, et al.                Standards Track                    [Page 19]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-     CONTEXT HANDLE input_context_handle  = the context_handle stored
-          in the client's mapping table entry (DNS@server.example.com.,
-          789.client.example.com.server.example.com., context_handle)
-     INTERNAL NAME  targ_name             = "DNS@server.example.com"
-     OCTET STRING   input_token           = token from Key field of TKEY
-          record from the Answer section of the server's response
-     BOOLEAN        replay_det_req_flag   = TRUE
-     BOOLEAN        mutual_req_flag       = TRUE
-
-  The OUTPUTS parameters returned by GSS_Init_sec_context include
-     INTEGER        major_status = GSS_S_COMPLETE
-     CONTEXT HANDLE output_context_handle = context_handle
-     OCTET STRING   output_token = output_token
-     BOOLEAN        replay_det_state = TRUE
-     BOOLEAN        mutual_state = TRUE
-
-  Since the major_status is set to GSS_S_COMPLETE the client side
-  security context is established, but since the output_token is not
-  NULL client MUST send a TKEY query to the server as described below.
-
-  VII.  Client sends a query with QTYPE = TKEY to server
-
-  Client sends to the server a TKEY query for the
-  789.client.example.com.server.example.com. name.  Query contains a
-  TKEY record in its Additional records section with the following
-  fields.  (Note that some INPUT and OUTPUT parameters not critical to
-  this algorithm are not described in this example.)
-
-     NAME = 789.client.example.com.server.example.com.
-     RDATA
-        Algorithm Name      = gss-tsig
-        Mode                = 3 (GSS-API negotiation - per [RFC2930])
-        Key Size            = size of output_token in octets
-        Key Data            = output_token
-
-  VIII.  Server receives a TKEY query
-
-  When the server receives a TKEY query, the server verifies that Mode
-  and Algorithm fields in the TKEY record in the Additional records
-  section of the query are set to 3 and gss-tsig, respectively.  It
-  finds that the key_name 789.client.example.com.server.example.com. is
-  listed in its (key_name, context_handle) mapping table.
-
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 20]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-  IX.  Server calls GSS_Accept_sec_context
-
-  To continue security context negotiation server calls
-  GSS_Accept_sec_context with the following parameters (Note that some
-  INPUT and OUTPUT parameters not critical for this algorithm are not
-  described in this example)
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = context_handle from the
-           (789.client.example.com.server.example.com., context_handle)
-           entry in the server's mapping table
-     OCTET STRING   input_token           = token specified in the Key
-           field of TKEY RR (from Additional records Section of
-           the client's query)
-
-  The OUTPUTS parameters returned by GSS_Accept_sec_context include
-     INTEGER        major_status = GSS_S_COMPLETE
-     CONTEXT_HANDLE output_context_handle = context_handle
-     OCTET STRING   output_token = NULL
-
-  Since major_status = GSS_S_COMPLETE, the security context on the
-  server side is established, but the server still needs to respond to
-  the client's TKEY query, as described below.  The security context
-  state is advanced to Context Established.
-
-  X.  Server responds to the TKEY query
-
-  Since the major_status = GSS_S_COMPLETE in the last server's call to
-  GSS_Accept_sec_context and the output_token is NULL, the server
-  responds to the TKEY query placing in the answer section a TKEY record
-  that was sent by the client in the Additional records section of the
-  client's latest TKEY query.  In addition, this server places a
-  TSIG record in additional records section of its response.  Server
-  calls GSS_GetMIC to generate a signature to include it in the TSIG
-  record.  The server specifies the following GSS_GetMIC INPUT
-  parameters:
-
-     CONTEXT HANDLE context_handle = context_handle from the
-           (789.client.example.com.server.example.com., context_handle)
-           entry in the server's mapping table
-     OCTET STRING   message        = outgoing message plus TSIG
-                                   variables (as described in [RFC2845])
-
-  The OUTPUTS parameters returned by GSS_GetMIC include
-     INTEGER        major_status = GSS_S_COMPLETE
-     OCTET STRING   per_msg_token
-
-  Signature field in the TSIG record is set to per_msg_token.
-
-
-
-Kwan, et al.                Standards Track                    [Page 21]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-  XI.  Client processes token returned by server
-
-  Client receives the TKEY query response from the server.  Since the
-  major_status was GSS_S_COMPLETE in the last client's call to
-  GSS_Init_sec_context, the client verifies that the server's response
-  is signed.  To validate the signature, the client calls
-  GSS_VerifyMIC with the following parameters:
-
-   INPUTS
-     CONTEXT HANDLE context_handle = context_handle for
-                  789.client.example.com.server.example.com. key_name
-     OCTET STRING   message        = incoming message plus TSIG
-                                  variables (as described in [RFC2845])
-     OCTET STRING   per_msg_token  = Signature field from TSIG RR
-                  included in the server's query response
-
-  Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the
-  signature is validated, security negotiation is complete and the
-  security context state is advanced to Context Established.  These
-  client and server will use the established security context to sign
-  and validate the signatures when they exchange packets with each
-  other until the context expires.
-
-7.  Security Considerations
-
-   This document describes a protocol for DNS security using GSS-API.
-   The security provided by this protocol is only as effective as the
-   security provided by the underlying GSS mechanisms.
-
-   All the security considerations from RFC 2845, RFC 2930 and RFC 2743
-   apply to the protocol described in this document.
-
-8.  IANA Considerations
-
-   The IANA has reserved the TSIG Algorithm name gss-tsig for the use in
-   the Algorithm fields of TKEY and TSIG resource records.  This
-   Algorithm name refers to the algorithm described in this document.
-   The requirement to have this name registered with IANA is specified
-   in RFC 2845.
-
-9.  Conformance
-
-   The GSS API using SPNEGO [RFC2478] provides maximum flexibility to
-   choose the underlying security mechanisms that enables security
-   context negotiation.  GSS API using SPNEGO [RFC2478] enables client
-   and server to negotiate and choose such underlying security
-   mechanisms on the fly.  To support such flexibility, DNS clients and
-   servers SHOULD specify SPNEGO mech_type in their GSS API calls.  At
-
-
-
-Kwan, et al.                Standards Track                    [Page 22]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   the same time, in order to guarantee interoperability between DNS
-   clients and servers that support GSS-TSIG it is required that
-
-   -  DNS servers specify SPNEGO mech_type
-   -  GSS APIs called by DNS client support Kerberos v5
-   -  GSS APIs called by DNS server support SPNEGO [RFC2478] and
-      Kerberos v5.
-
-   In addition to these, GSS APIs used by DNS client and server MAY also
-   support other underlying security mechanisms.
-
-10.  Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-11.  Acknowledgements
-
-   The authors of this document would like to thank the following people
-   for their contribution to this specification:  Chuck Chan, Mike
-   Swift, Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake, 3rd
-   and Erik Nordmark.
-
-
-
-
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 23]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-12.  References
-
-12.1.  Normative References
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
-             Negotiation Mechanism", RFC 2478, December 1998.
-
-   [RFC2743] Linn, J., "Generic Security Service Application Program
-             Interface, Version 2 , Update 1", RFC 2743, January 2000.
-
-   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
-             Wellington, "Secret Key Transaction Authentication for DNS
-             (TSIG)", RFC 2845, May 2000.
-
-   [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
-             RR)", RFC 2930, September 2000.
-
-12.2.  Informative References
-
-
-   [ISO11578] "Information technology", "Open Systems Interconnection",
-              "Remote Procedure Call", ISO/IEC 11578:1996,
-              http://www.iso.ch/cate/d2229.html.
-
-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-             STD 13, RFC 1034, November 1987.
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-             Specification", STD 13, RFC 1034, November 1987.
-
-   [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
-             1964, June 1996.
-
-   [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
-             (SPKM)", RFC 2025, October 1996.
-
-   [RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic
-             Update", RFC 2137, April 1997.
-
-   [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions",
-             RFC 2535, March 1999.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 24]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-13.  Authors' Addresses
-
-   Stuart Kwan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: skwan@microsoft.com
-
-   Praerit Garg
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: praeritg@microsoft.com
-
-   James Gilroy
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: jamesg@microsoft.com
-
-   Levon Esibov
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: levone@microsoft.com
-
-   Randy Hall
-   Lucent Technologies
-   400 Lapp Road
-   Malvern PA 19355
-   USA
-   EMail: randyhall@lucent.com
-
-   Jeff Westhead
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: jwesth@microsoft.com
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 25]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-14.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 26]
-
diff --git a/doc/rfc/rfc3655.txt b/doc/rfc/rfc3655.txt
deleted file mode 100644
index 13e586ba..00000000
--- a/doc/rfc/rfc3655.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      B. Wellington
-Request for Comments: 3655                                O. Gudmundsson
-Updates: 2535                                              November 2003
-Category: Standards Track
-
-
-            Redefinition of DNS Authenticated Data (AD) bit
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document alters the specification defined in RFC 2535.  Based on
-   implementation experience, the Authenticated Data (AD) bit in the DNS
-   header is not useful.  This document redefines the AD bit such that
-   it is only set if all answers or records proving that no answers
-   exist in the response has been cryptographically verified or
-   otherwise meets the server's local security policy.
-
-1.  Introduction
-
-   Familiarity with the DNS system [RFC1035] and DNS security extensions
-   [RFC2535] is helpful but not necessary.
-
-   As specified in RFC 2535 (section 6.1), the AD (Authenticated Data)
-   bit indicates in a response that all data included in the answer and
-   authority sections of the response have been authenticated by the
-   server according to the policies of that server.  This is not
-   especially useful in practice, since a conformant server SHOULD never
-   reply with data that failed its security policy.
-
-   This document redefines the AD bit such that it is only set if all
-   data in the response has been cryptographically verified or otherwise
-   meets the server's local security policy.  Thus, neither a response
-   containing properly delegated insecure data, nor a server configured
-   without DNSSEC keys, will have the AD set.  As before, data that
-   failed to verify will not be returned.  An application running on a
-   host that has a trust relationship with the server performing the
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 1]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-   recursive query can now use the value of the AD bit to determine
-   whether the data is secure.
-
-1.1.  Motivation
-
-   A full DNSSEC capable resolver called directly from an application
-   can return to the application the security status of the RRsets in
-   the answer.  However, most applications use a limited stub resolver
-   that relies on an external recursive name server which incorporates a
-   full resolver.  The recursive nameserver can use the AD bit in a
-   response to indicate the security status of the data in the answer,
-   and the local resolver can pass this information to the application.
-   The application in this context can be either a human using a DNS
-   tool or a software application.
-
-   The AD bit SHOULD be used by the local resolver if and only if it has
-   been explicitly configured to trust the remote resolver.  The AD bit
-   SHOULD be ignored when the recursive name server is not trusted.
-
-   An alternate solution would be to embed a full DNSSEC resolver into
-   every application, but this has several disadvantages.
-
-   -  DNSSEC validation is both CPU and network intensive, and caching
-      SHOULD be used whenever possible.
-
-   -  DNSSEC requires non-trivial configuration - the root key must be
-      configured, as well as keys for any "islands of security" that
-      will exist until DNSSEC is fully deployed.  The number of
-      configuration points should be minimized.
-
-1.2.  Requirements
-
-   The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD
-   NOT", "RECOMMENDED", in this document are to be interpreted as
-   described in BCP 14, RFC 2119 [RFC2119].
-
-1.3.  Updated documents and sections
-
-   The definition of the AD bit in RFC 2535, Section 6.1, is changed.
-
-2.  Setting of AD bit
-
-   The presence of the CD (Checking Disabled) bit in a query does not
-   affect the setting of the AD bit in the response.  If the CD bit is
-   set, the server will not perform checking, but SHOULD still set the
-   AD bit if the data has already been cryptographically verified or
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 2]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-   complies with local policy.  The AD bit MUST only be set if DNSSEC
-   records have been requested via the DO bit [RFC3225] and relevant SIG
-   records are returned.
-
-2.1.  Setting of AD bit by recursive servers
-
-   Section 6.1 of RFC 2535 says:
-
-   "The AD bit MUST NOT be set on a response unless all of the RRs in
-   the answer and authority sections of the response are either
-   Authenticated or Insecure."
-
-   The replacement text reads:
-
-   "The AD bit MUST NOT be set on a response unless all of the RRsets in
-   the answer and authority sections of the response are Authenticated."
-
-   "The AD bit SHOULD be set if and only if all RRs in the answer
-   section and any relevant negative response RRs in the authority
-   section are Authenticated."
-
-   A recursive DNS server following this modified specification will
-   only set the AD bit when it has cryptographically verified the data
-   in the answer.
-
-2.2.  Setting of AD bit by authoritative servers
-
-   A primary server for a secure zone MAY have the policy of treating
-   authoritative secure zones as Authenticated.  Secondary servers MAY
-   have the same policy, but SHOULD NOT consider zone data Authenticated
-   unless the zone was transferred securely and/or the data was
-   verified.  An authoritative server MUST only set the AD bit for
-   authoritative answers from a secure zone if it has been explicitly
-   configured to do so.  The default for this behavior SHOULD be off.
-
-   Note that having the AD bit clear on an authoritative answer is
-   normal and expected behavior.
-
-2.2.1.  Justification for setting AD bit w/o verifying data
-
-   The setting of the AD bit by authoritative servers affects only the
-   small set of resolvers that are configured to directly query and
-   trust authoritative servers.  This only affects servers that function
-   as both recursive and authoritative.  Iterative resolvers SHOULD
-   ignore the AD bit.
-
-   The cost of verifying all signatures on load by an authoritative
-   server can be high and increases the delay before it can begin
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 3]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-   answering queries.  Verifying signatures at query time is also
-   expensive and could lead to resolvers timing out on many queries
-   after the server reloads zones.
-
-   Organizations requiring that all DNS responses contain
-   cryptographically verified data will need to separate the
-   authoritative name server and signature verification functions, since
-   name servers are not required to validate signatures of data for
-   which they are authoritative.
-
-3.  Interpretation of the AD bit
-
-   A response containing data marked Insecure in the answer or authority
-   section MUST never have the AD bit set.  In this case, the resolver
-   SHOULD treat the data as Insecure whether or not SIG records are
-   present.
-
-   A resolver MUST NOT blindly trust the AD bit unless it communicates
-   with a recursive nameserver over a secure transport mechanism or
-   using a message authentication such as TSIG [RFC2845] or SIG(0)
-   [RFC2931] and is explicitly configured to trust this recursive name
-   server.
-
-4.  Applicability statement
-
-   The AD bit is intended to allow the transmission of the indication
-   that a resolver has verified the DNSSEC signatures accompanying the
-   records in the Answer and Authority section.  The AD bit MUST only be
-   trusted when the end consumer of the DNS data has confidence that the
-   intermediary resolver setting the AD bit is trustworthy.  This can
-   only be accomplished via an out of band mechanism such as:
-
-   -  Fiat: An organization that can dictate whether it is OK to trust
-      certain DNS servers.
-
-   -  Personal: Because of a personal relationship or the reputation of
-      a recursive nameserver operator, a DNS consumer can decide to
-      trust that recursive nameserver.
-
-   -  Knowledge: If a recursive nameserver operator posts the configured
-      policy of a recursive nameserver, a consumer can decide that
-      recursive nameserver is trustworthy.
-
-   In the absence of one or more of these factors AD bit from a
-   recursive name server SHOULD NOT be trusted.  For example, home users
-   frequently depend on their ISP to provide recursive DNS service; it
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 4]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-   is not advisable to trust these recursive nameservers.  A
-   roaming/traveling host SHOULD not use recursive DNS servers offered
-   by DHCP when looking up information where security status matters.
-
-   In the latter two cases, the end consumer must also completely trust
-   the path to the trusted recursive name servers, or a secure transport
-   must be employed to protect the traffic.
-
-   When faced with a situation where there are no satisfactory recursive
-   nameservers available, running one locally is RECOMMENDED.  This has
-   the advantage that it can be trusted, and the AD bit can still be
-   used to allow applications to use stub resolvers.
-
-5.  Security Considerations
-
-   This document redefines a bit in the DNS header.  If a resolver
-   trusts the value of the AD bit, it must be sure that the responder is
-   using the updated definition, which is any DNS server/resolver
-   supporting the DO bit [RFC3225].
-
-   Authoritative servers can be explicitly configured to set the AD bit
-   on answers without doing cryptographic checks.  This behavior MUST be
-   off by default.  The only affected resolvers are those that directly
-   query and trust the authoritative server, and this functionality
-   SHOULD only be used on servers that act both as authoritative and
-   recursive name servers.
-
-   Resolvers (full or stub) that blindly trust the AD bit without
-   knowing the security policy of the server generating the answer can
-   not be considered security aware.
-
-   A resolver MUST NOT blindly trust the AD bit unless it communicates
-   such as IPsec, or using message authentication such as TSIG [RFC2845]
-   or SIG(0) [RFC2931].  In addition, the resolver must have been
-   explicitly configured to trust this recursive name server.
-
-6.  IANA Considerations
-
-   None.
-
-7.  Internationalization Considerations
-
-   None.  This document does not change any textual data in any
-   protocol.
-
-
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 5]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-8.  Intellectual Property Rights Notice
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-9.  Acknowledgments
-
-   The following people have provided input on this document: Robert
-   Elz, Andreas Gustafsson, Bob Halley, Steven Jacob, Erik Nordmark,
-   Edward Lewis, Jakob Schlyter, Roy Arends, Ted Lindgreen.
-
-10.  Normative References
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-             Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-             2535, March 1999.
-
-   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
-             Wellington, "Secret Key Transaction Authentication for DNS
-             (TSIG)", RFC 2845, May 2000.
-
-   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
-             (SIG(0))", RFC 2931, September 2000.
-
-   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-             3225, December 2001.
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 6]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-11.  Authors' Addresses
-
-   Brian Wellington
-   Nominum Inc.
-   2385 Bay Road
-   Redwood City, CA, 94063
-   USA
-
-   EMail: Brian.Wellington@nominum.com
-
-
-   Olafur Gudmundsson
-   3821 Village Park Drive
-   Chevy Chase, MD, 20815
-   USA
-
-   EMail: ogud@ogud.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 7]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-12.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 8]
-
diff --git a/doc/rfc/rfc3658.txt b/doc/rfc/rfc3658.txt
deleted file mode 100644
index 88cfb5af..00000000
--- a/doc/rfc/rfc3658.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     O. Gudmundsson
-Request for Comments: 3658                                 December 2003
-Updates: 3090, 3008, 2535, 1035
-Category: Standards Track
-
-
-              Delegation Signer (DS) Resource Record (RR)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   The delegation signer (DS) resource record (RR) is inserted at a zone
-   cut (i.e., a delegation point) to indicate that the delegated zone is
-   digitally signed and that the delegated zone recognizes the indicated
-   key as a valid zone key for the delegated zone.  The DS RR is a
-   modification to the DNS Security Extensions definition, motivated by
-   operational considerations.  The intent is to use this resource
-   record as an explicit statement about the delegation, rather than
-   relying on inference.
-
-   This document defines the DS RR, gives examples of how it is used and
-   describes the implications on resolvers.  This change is not
-   backwards compatible with RFC 2535.  This document updates RFC 1035,
-   RFC 2535, RFC 3008 and RFC 3090.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 1]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-Table of Contents
-
-   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   3
-       1.2.  Reserved Words. . . . . . . . . . . . . . . . . . . . .   4
-   2.  Specification of the Delegation key Signer. . . . . . . . . .   4
-       2.1.  Delegation Signer Record Model. . . . . . . . . . . . .   4
-       2.2.  Protocol Change . . . . . . . . . . . . . . . . . . . .   5
-             2.2.1.  RFC 2535 2.3.4 and 3.4: Special Considerations
-                     at Delegation Points  . . . . . . . . . . . . .   6
-                     2.2.1.1. Special processing for DS queries. . .   6
-                     2.2.1.2. Special processing when child and an
-                              ancestor share nameserver. . . . . . .   7
-                     2.2.1.3. Modification on use of KEY RR in the
-                              construction of Responses. . . . . . .   8
-             2.2.2.  Signer's Name (replaces RFC3008 section 2.7). .   9
-             2.2.3.  Changes to RFC 3090 . . . . . . . . . . . . . .   9
-                     2.2.3.1. RFC 3090: Updates to section 1:
-                              Introduction . . . . . . . . . . . . .   9
-                     2.2.3.2. RFC 3090 section 2.1: Globally
-                              Secured. . . . . . . . . . . . . . . .  10
-                     2.2.3.3. RFC 3090 section 3: Experimental
-                              Status . . . . . . . . . . . . . . . .  10
-             2.2.4.  NULL KEY elimination. . . . . . . . . . . . . .  10
-       2.3.  Comments on Protocol Changes. . . . . . . . . . . . . .  10
-       2.4.  Wire Format of the DS record. . . . . . . . . . . . . .  11
-             2.4.1.  Justifications for Fields . . . . . . . . . . .  12
-       2.5.  Presentation Format of the DS Record. . . . . . . . . .  12
-       2.6.  Transition Issues for Installed Base. . . . . . . . . .  12
-             2.6.1.  Backwards compatibility with RFC 2535 and
-                     RFC 1035. . . . . . . . . . . . . . . . . . . .  12
-       2.7.  KEY and corresponding DS record example . . . . . . . .  13
-   3.  Resolver. . . . . . . . . . . . . . . . . . . . . . . . . . .  14
-       3.1.  DS Example" . . . . . . . . . . . . . . . . . . . . . .  14
-       3.2.  Resolver Cost Estimates for DS Records" . . . . . . . .  15
-   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
-   6.  Intellectual Property Statement . . . . . . . . . . . . . . .  16
-   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
-   8.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  17
-       8.1.  Normative References. . . . . . . . . . . . . . . . . .  17
-       8.2.  Informational References. . . . . . . . . . . . . . . .  17
-   9.  Author's Address. . . . . . . . . . . . . . . . . . . . . . .  18
-   10. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  19
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 2]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-1.  Introduction
-
-   Familiarity with the DNS system [RFC1035], DNS security extensions
-   [RFC2535], and DNSSEC terminology [RFC3090] is important.
-
-   Experience shows that when the same data can reside in two
-   administratively different DNS zones, the data frequently gets out of
-   sync.  The presence of an NS RRset in a zone anywhere other than at
-   the apex indicates a zone cut or delegation.  The RDATA of the NS
-   RRset specifies the authoritative nameservers for the delegated or
-   "child" zone.  Based on actual measurements, 10-30% of all
-   delegations on the Internet have differing NS RRsets at parent and
-   child.  There are a number of reasons for this, including a lack of
-   communication between parent and child and bogus name servers being
-   listed to meet registry requirements.
-
-   DNSSEC [RFC2535, RFC3008, RFC3090] specifies that a child zone needs
-   to have its KEY RRset signed by its parent to create a verifiable
-   chain of KEYs.  There has been some debate on where the signed KEY
-   RRset should reside, whether at the child [RFC2535] or at the parent.
-   If the KEY RRset resides at the child, maintaining the signed KEY
-   RRset in the child requires frequent two-way communication between
-   the two parties.  First, the child transmits the KEY RRset to the
-   parent and then the parent sends the signature(s) to the child.
-   Storing the KEY RRset at the parent was thought to simplify the
-   communication.
-
-   DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
-   an unsecure child zone to indicate that the child is unsecure.  A
-   NULL KEY record is a waste: an entire signed RRset is used to
-   communicate effectively one bit of information - that the child is
-   unsecure. Chasing down NULL KEY RRsets complicates the resolution
-   process in many cases, because nameservers for both parent and child
-   need to be queried for the KEY RRset if the child nameserver does not
-   return it.  Storing the KEY RRset only in the parent zone simplifies
-   this and would allow the elimination of the NULL KEY RRsets entirely.
-   For large delegation zones, the cost of NULL keys is a significant
-   barrier to deployment.
-
-   Prior to the restrictions imposed by RFC 3445 [RFC3445], another
-   implication of the DNSSEC key model is that the KEY record could be
-   used to store public keys for other protocols in addition to DNSSEC
-   keys.  There are a number of potential problems with this, including:
-
-   1. The KEY RRset can become quite large if many applications and
-      protocols store their keys at the zone apex.  Possible protocols
-      are IPSEC, HTTP, SMTP, SSH and others that use public key
-      cryptography.
-
-
-
-Gudmundsson                 Standards Track                     [Page 3]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   2. The KEY RRset may require frequent updates.
-
-   3. The probability of compromised or lost keys, which trigger
-      emergency key roll-over procedures, increases.
-
-   4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone
-      keys.
-
-   5. The parent may not meet the child's expectations of turnaround
-      time for resigning the KEY RRset.
-
-   Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
-
-1.2.  Reserved Words
-
-   The key words "MAY", "MAY NOT", "MUST", "MUST NOT", "REQUIRED",
-   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
-   interpreted as described in BCP 14, RFC 2119 [RFC2119].
-
-2.  Specification of the Delegation key Signer
-
-   This section defines the Delegation Signer (DS) RR type (type code
-   43) and the changes to DNS to accommodate it.
-
-2.1.  Delegation Signer Record Model
-
-   This document presents a replacement for the DNSSEC KEY record chain
-   of trust [RFC2535] that uses a new RR that resides only at the
-   parent.  This record identifies the key(s) that the child uses to
-   self-sign its own KEY RRset.
-
-   Even though DS identifies two roles for KEYs, Key Signing Key (KSK)
-   and Zone Signing Key (ZSK), there is no requirement that zone uses
-   two different keys for these roles.  It is expected that many small
-   zones will only use one key, while larger zones will be more likely
-   to use multiple keys.
-
-   The chain of trust is now established by verifying the parent KEY
-   RRset, the DS RRset from the parent and the KEY RRset at the child.
-   This is cryptographically equivalent to using just KEY records.
-
-   Communication between the parent and child is greatly reduced, since
-   the child only needs to notify the parent about changes in keys that
-   sign its apex KEY RRset.  The parent is ignorant of all other keys in
-   the child's apex KEY RRset.  Furthermore, the child maintains full
-   control over the apex KEY RRset and its content.  The child can
-   maintain any policies regarding its KEY usage for DNSSEC with minimal
-   impact on the parent.  Thus, if the child wants to have frequent key
-
-
-
-Gudmundsson                 Standards Track                     [Page 4]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   roll-over for its DNS zone keys, the parent does not need to be aware
-   of it.  The child can use one key to sign only its apex KEY RRset and
-   a different key to sign the other RRsets in the zone.
-
-   This model fits well with a slow roll out of DNSSEC and the islands
-   of security model.  In this model, someone who trusts "good.example."
-   can preconfigure a key from "good.example." as a trusted key, and
-   from then on trusts any data signed by that key or that has a chain
-   of trust to that key.  If "example." starts advertising DS records,
-   "good.example." does not have to change operations by suspending
-   self-signing.  DS records can be used in configuration files to
-   identify trusted keys instead of KEY records.  Another significant
-   advantage is that the amount of information stored in large
-   delegation zones is reduced: rather than the NULL KEY record at every
-   unsecure delegation demanded by RFC 2535, only secure delegations
-   require additional information in the form of a signed DS RRset.
-
-   The main disadvantage of this approach is that verifying a zone's KEY
-   RRset requires two signature verification operations instead of the
-   one in RFC 2535 chain of trust.  There is no impact on the number of
-   signatures verified for other types of RRsets.
-
-2.2.  Protocol Change
-
-   All DNS servers and resolvers that support DS MUST support the OK bit
-   [RFC3225] and a larger message size [RFC3226].  In order for a
-   delegation to be considered secure the delegation MUST contain a DS
-   RRset.  If a query contains the OK bit, a nameserver returning a
-   referral for the delegation MUST include the following RRsets in the
-   authority section in this order:
-
-   If DS RRset is present:
-      parent's copy of child's NS RRset
-      DS and SIG(DS)
-
-   If no DS RRset is present:
-      parent's copy of child's NS RRset
-      parent's zone NXT and SIG(NXT)
-
-   This increases the size of referral messages, possibly causing some
-   or all glue to be omitted.  If the DS or NXT RRsets with signatures
-   do not fit in the DNS message, the TC bit MUST be set.  Additional
-   section processing is not changed.
-
-   A DS RRset accompanying a NS RRset indicates that the child zone is
-   secure.  If a NS RRset exists without a DS RRset, the child zone is
-   unsecure (from the parents point of view).  DS RRsets MUST NOT appear
-   at non-delegation points or at a zone's apex.
-
-
-
-Gudmundsson                 Standards Track                     [Page 5]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   Section 2.2.1 defines special considerations related to authoritative
-   nameservers responding to DS queries and replaces RFC 2535 sections
-   2.3.4 and 3.4.  Section 2.2.2 replaces RFC 3008 section 2.7, and
-   section 2.2.3 updates RFC 3090.
-
-2.2.1.  RFC 2535 2.3.4 and 3.4: Special Considerations at Delegation
-        Points
-
-   DNS security views each zone as a unit of data completely under the
-   control of the zone owner with each entry (RRset) signed by a special
-   private key held by the zone manager.  But the DNS protocol views the
-   leaf nodes in a zone that are also the apex nodes of a child zone
-   (i.e., delegation points) as "really" belonging to the child zone.
-   The corresponding domain names appear in two master files and might
-   have RRsets signed by both the parent and child zones' keys.  A
-   retrieval could get a mixture of these RRsets and SIGs, especially
-   since one nameserver could be serving both the zone above and below a
-   delegation point [RFC2181].
-
-   Each DS RRset stored in the parent zone MUST be signed by at least
-   one of the parent zone's private keys.  The parent zone MUST NOT
-   contain a KEY RRset at any delegation point.  Delegations in the
-   parent MAY contain only the following RR types: NS, DS, NXT and SIG.
-   The NS RRset MUST NOT be signed.  The NXT RRset is the exceptional
-   case: it will always appear differently and authoritatively in both
-   the parent and child zones, if both are secure.
-
-   A secure zone MUST contain a self-signed KEY RRset at its apex.  Upon
-   verifying the DS RRset from the parent, a resolver MAY trust any KEY
-   identified in the DS RRset as a valid signer of the child's apex KEY
-   RRset.  Resolvers configured to trust one of the keys signing the KEY
-   RRset MAY now treat any data signed by the zone keys in the KEY RRset
-   as secure.  In all other cases, resolvers MUST consider the zone
-   unsecure.
-
-   An authoritative nameserver queried for type DS MUST return the DS
-   RRset in the answer section.
-
-2.2.1.1.  Special processing for DS queries
-
-   When a nameserver is authoritative for the parent zone at a
-   delegation point and receives a query for the DS record at that name,
-   it MUST answer based on data in the parent zone, return DS or
-   negative answer.  This is true whether or not it is also
-   authoritative for the child zone.
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 6]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   When the nameserver is authoritative for the child zone at a
-   delegation point but not the parent zone, there is no natural
-   response, since the child zone is not authoritative for the DS record
-   at the zone's apex.  As these queries are only expected to originate
-   from recursive nameservers which are not DS-aware, the authoritative
-   nameserver MUST answer with:
-
-      RCODE:             NOERROR
-      AA bit:            set
-      Answer Section:    Empty
-      Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
-
-   That is, it answers as if it is authoritative and the DS record does
-   not exist.  DS-aware recursive nameservers will query the parent zone
-   at delegation points, so will not be affected by this.
-
-   A nameserver authoritative for only the child zone, that is also a
-   caching server MAY (if the RD bit is set in the query) perform
-   recursion to find the DS record at the delegation point, or MAY
-   return the DS record from its cache.  In this case, the AA bit MUST
-   NOT be set in the response.
-
-2.2.1.2.  Special processing when child and an ancestor share
-          nameserver
-
-   Special rules are needed to permit DS RR aware nameservers to
-   gracefully interact with older caches which otherwise might falsely
-   label a nameserver as lame because of the placement of the DS RR set.
-
-   Such a situation might arise when a nameserver is authoritative for
-   both a zone and it's grandparent, but not the parent.  This sounds
-   like an obscure example, but it is very real.  The root zone is
-   currently served on 13 machines, and "root-servers.net." is served on
-   4 of the 13, but "net." is severed on different nameservers.
-
-   When a nameserver receives a query for (<QNAME>, DS, <QCLASS>), the
-   response MUST be determined from reading these rules in order:
-
-   1) If the nameserver is authoritative for the zone that holds the DS
-      RR set (i.e., the zone that delegates <QNAME>, a.k.a. the "parent"
-      zone), the response contains the DS RR set as an authoritative
-      answer.
-
-   2) If the nameserver is offering recursive service and the RD bit is
-      set in the query, the nameserver performs the query itself
-      (according to the rules for resolvers described below) and returns
-      its findings.
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 7]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   3) If the nameserver is authoritative for the zone that holds the
-      <QNAME>'s SOA RR set, the response is an authoritative negative
-      answer as described in 2.2.1.1.
-
-   4) If the nameserver is authoritative for a zone or zones above the
-      QNAME, a referral to the most enclosing (deepest match) zone's
-      servers is made.
-
-   5) If the nameserver is not authoritative for any part of the QNAME,
-      a response indicating a lame nameserver for QNAME is given.
-
-   Using these rules will require some special processing on the part of
-   a DS RR aware resolver.  To illustrate this, an example is used.
-
-   Assuming a nameserver is authoritative for roots.example.net. and for
-   the root zone but not the intervening two zones (or the intervening
-   two label deep zone).  Assume that QNAME=roots.example.net.,
-   QTYPE=DS, and QCLASS=IN.
-
-   The resolver will issue this request (assuming no cached data)
-   expecting a referral to a nameserver for .net.  Instead, rule number
-   3 above applies and a negative answer is returned by the nameserver.
-   The reaction by the resolver is not to accept this answer as final,
-   as it can determine from the SOA RR in the negative answer the
-   context within which the nameserver has answered.
-
-   A solution would be to instruct the resolver to hunt for the
-   authoritative zone of the data in a brute force manner.
-
-   This can be accomplished by taking the owner name of the returned SOA
-   RR and striping off enough left-hand labels until a successful NS
-   response is obtained.  A successful response here means that the
-   answer has NS records in it.  (Entertaining the possibility that a
-   cut point can be two labels down in a zone.)
-
-   Returning to the example, the response will include a negative answer
-   with either the SOA RR for "roots.example.net." or "example.net."
-   depending on whether roots.example.net is a delegated domain.  In
-   either case, removing the left most label of the SOA owner name will
-   lead to the location of the desired data.
-
-2.2.1.3.  Modification on use of KEY RR in the construction of Responses
-
-   This section updates RFC 2535 section 3.5 by replacing it with the
-   following:
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 8]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   A query for KEY RR MUST NOT trigger any additional section
-   processing.  Security aware resolvers will include corresponding SIG
-   records in the answer section.
-
-   KEY records SHOULD NOT be added to the additional records section in
-   response to any query.
-
-   RFC 2535 specified that KEY records be added to the additional
-   section when SOA or NS records were included in an answer.  This was
-   done to reduce round trips (in the case of SOA) and to force out NULL
-   KEYs (in the NS case).  As this document obsoletes NULL keys, there
-   is no need for the inclusion of KEYs with NSs.  Furthermore, as SOAs
-   are included in the authority section of negative answers, including
-   the KEYs each time will cause redundant transfers of KEYs.
-
-   RFC 2535 section 3.5 also included a rule for adding the KEY RRset to
-   the response for a query for A and AAAA types.  As Restrict KEY
-   [RFC3445] eliminated use of KEY RR by all applications, this rule is
-   no longer needed.
-
-2.2.2.  Signer's Name (replaces RFC 3008 section 2.7)
-
-   The signer's name field of a SIG RR MUST contain the name of the zone
-   to which the data and signature belong.  The combination of signer's
-   name, key tag, and algorithm MUST identify a zone key if the SIG is
-   to be considered material.  This document defines a standard policy
-   for DNSSEC validation; local policy MAY override the standard policy.
-
-   There are no restrictions on the signer field of a SIG(0) record. The
-   combination of signer's name, key tag, and algorithm MUST identify a
-   key if this SIG(0) is to be processed.
-
-2.2.3.  Changes to RFC 3090
-
-   A number of sections in RFC 3090 need to be updated to reflect the DS
-   record.
-
-2.2.3.1.  RFC 3090: Updates to section 1: Introduction
-
-   Most of the text is still relevant but the words "NULL key" are to be
-   replaced with "missing DS RRset".  In section 1.3, the last three
-   paragraphs discuss the confusion in sections of RFC 2535 that are
-   replaced in section 2.2.1 above.  Therefore, these paragraphs are now
-   obsolete.
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 9]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-2.2.3.2.  RFC 3090 section 2.1: Globally Secured
-
-   Rule 2.1.b is replaced by the following rule:
-
-   2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a
-   private key whose public counterpart MUST appear in a zone signing
-   KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-
-   implement algorithm.  This KEY RR MUST be identified by a DS RR in a
-   signed DS RRset in the parent zone.
-
-   If a zone cannot get its parent to advertise a DS record for it, the
-   child zone cannot be considered globally secured.  The only exception
-   to this is the root zone, for which there is no parent zone.
-
-2.2.3.3.  RFC 3090 section 3: Experimental Status.
-
-   The only difference between experimental status and globally secured
-   is the missing DS RRset in the parent zone.  All locally secured
-   zones are experimental.
-
-2.2.4.  NULL KEY elimination
-
-   RFC 3445 section 3 eliminates the top two bits in the flags field of
-   KEY RR.  These two bits were used to indicate NULL KEY or NO KEY. RFC
-   3090 defines that zone as either secure or not and these rules
-   eliminate the need to put NULL keys in the zone apex to indicate that
-   the zone is not secured for a algorithm.  Along with this document,
-   these other two eliminate all uses for the NULL KEY.  This document
-   obsoletes NULL KEY.
-
-2.3.  Comments on Protocol Changes
-
-   Over the years, there have been various discussions surrounding the
-   DNS delegation model, declaring it to be broken because there is no
-   good way to assert if a delegation exists.  In the RFC 2535 version
-   of DNSSEC, the presence of the NS bit in the NXT bit map proves there
-   is a delegation at this name.  Something more explicit is required
-   and the DS record addresses this need for secure delegations.
-
-   The DS record is a major change to DNS: it is the first resource
-   record that can appear only on the upper side of a delegation.
-   Adding it will cause interoperability problems and requires a flag
-   day for DNSSEC.  Many old nameservers and resolvers MUST be upgraded
-   to take advantage of DS.  Some old nameservers will be able to be
-   authoritative for zones with DS records but will not add the NXT or
-   DS records to the authority section.  The same is true for caching
-   nameservers; in fact, some might even refuse to pass on the DS or NXT
-   records.
-
-
-
-Gudmundsson                 Standards Track                    [Page 10]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-2.4.  Wire Format of the DS record
-
-   The DS (type=43) record contains these fields: key tag, algorithm,
-   digest type, and the digest of a public key KEY record that is
-   allowed and/or used to sign the child's apex KEY RRset.  Other keys
-   MAY sign the child's apex KEY RRset.
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |           key tag             |  algorithm    |  Digest type  |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                digest  (length depends on type)               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                (SHA-1 digest is 20 bytes)                     |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-   |                                                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-   |                                                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   The key tag is calculated as specified in RFC 2535.  Algorithm MUST
-   be allowed to sign DNS data.  The digest type is an identifier for
-   the digest algorithm used.  The digest is calculated over the
-   canonical name of the delegated domain name followed by the whole
-   RDATA of the KEY record (all four fields).
-
-      digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
-
-      KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
-
-   Digest type value 0 is reserved, value 1 is SHA-1, and reserving
-   other types requires IETF standards action.  For interoperability
-   reasons, keeping number of digest algorithms low is strongly
-   RECOMMENDED.  The only reason to reserve additional digest types is
-   to increase security.
-
-   DS records MUST point to zone KEY records that are allowed to
-   authenticate DNS data.  The indicated KEY records protocol field MUST
-   be set to 3; flag field bit 7 MUST be set to 1.  The value of other
-   flag bits is not significant for the purposes of this document.
-
-   The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
-   of key size.  New digest types probably will have larger digests.
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 11]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-2.4.1.  Justifications for Fields
-
-   The algorithm and key tag fields are present to allow resolvers to
-   quickly identify the candidate KEY records to examine.  SHA-1 is a
-   strong cryptographic checksum: it is computationally infeasible for
-   an attacker to generate a KEY record that has the same SHA-1 digest.
-   Combining the name of the key and the key rdata as input to the
-   digest provides stronger assurance of the binding.  Having the key
-   tag in the DS record adds greater assurance than the SHA-1 digest
-   alone, as there are now two different mapping functions.
-
-   This format allows concise representation of the keys that the child
-   will use, thus keeping down the size of the answer for the
-   delegation, reducing the probability of DNS message overflow.  The
-   SHA-1 hash is strong enough to uniquely identify the key and is
-   similar to the PGP key footprint.  The digest type field is present
-   for possible future expansion.
-
-   The DS record is well suited to listing trusted keys for islands of
-   security in configuration files.
-
-2.5.  Presentation Format of the DS Record
-
-   The presentation format of the DS record consists of three numbers
-   (key tag, algorithm, and digest type) followed by the digest itself
-   presented in hex:
-
-      example.   DS  12345 3 1 123456789abcdef67890123456789abcdef67890
-
-2.6.  Transition Issues for Installed Base
-
-   No backwards compatibility with RFC 2535 is provided.
-
-   RFC 2535-compliant resolvers will assume that all DS-secured
-   delegations are locally secure.  This is bad, but the DNSEXT Working
-   Group has determined that rather than dealing with both RFC 2535-
-   secured zones and DS-secured zones, a rapid adoption of DS is
-   preferable.  Thus, the only option for early adopters is to upgrade
-   to DS as soon as possible.
-
-2.6.1.  Backwards compatibility with RFC 2535 and RFC 1035
-
-   This section documents how a resolver determines the type of
-   delegation.
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 12]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   RFC 1035 delegation (in parent) has:
-
-   RFC 1035           NS
-
-   RFC 2535 adds the following two cases:
-
-   Secure RFC 2535:   NS + NXT + SIG(NXT)
-                      NXT bit map contains: NS SIG NXT
-   Unsecure RFC 2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
-                      NXT bit map contains: NS SIG KEY NXT
-                      KEY must be a NULL key.
-
-   DNSSEC with DS has the following two states:
-
-   Secure DS:         NS + DS + SIG(DS)
-                      NXT bit map contains: NS SIG NXT DS
-   Unsecure DS:       NS + NXT + SIG(NXT)
-                      NXT bit map contains: NS SIG NXT
-
-   It is difficult for a resolver to determine if a delegation is secure
-   RFC 2535 or unsecure DS.  This could be overcome by adding a flag to
-   the NXT bit map, but only upgraded resolvers would understand this
-   flag, anyway.  Having both parent and child signatures for a KEY
-   RRset might allow old resolvers to accept a zone as secure, but the
-   cost of doing this for a long time is much higher than just
-   prohibiting RFC 2535-style signatures at child zone apexes and
-   forcing rapid deployment of DS-enabled nameservers and resolvers.
-
-   RFC 2535 and DS can, in theory, be deployed in parallel, but this
-   would require resolvers to deal with RFC 2535 configurations forever.
-   This document obsoletes the NULL KEY in parent zones, which is a
-   difficult enough change that to cause a flag day.
-
-2.7.  KEY and corresponding DS record example
-
-   This is an example of a KEY record and the corresponding DS record.
-
-   dskey.example. KEY  256 3 1 (
-                  AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
-                  4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
-                  ) ; key id = 28668
-             DS   28668 1  1  49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 13]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-3.  Resolver
-
-3.1.  DS Example
-
-   To create a chain of trust, a resolver goes from trusted KEY to DS to
-   KEY.
-
-      Assume the key for domain "example." is trusted.  Zone "example."
-      contains at least the following records:
-      example.          SOA     <soa stuff>
-      example.          NS       ns.example.
-      example.          KEY     <stuff>
-      example.          NXT      secure.example. NS SOA KEY SIG NXT
-      example.          SIG(SOA)
-      example.          SIG(NS)
-      example.          SIG(NXT)
-      example.          SIG(KEY)
-      secure.example.   NS      ns1.secure.example.
-      secure.example.   DS      tag=12345 alg=3 digest_type=1 <foofoo>
-      secure.example.   NXT     unsecure.example. NS SIG NXT DS
-      secure.example.   SIG(NXT)
-      secure.example.   SIG(DS)
-      unsecure.example  NS      ns1.unsecure.example.
-      unsecure.example. NXT     example. NS SIG NXT
-      unsecure.example. SIG(NXT)
-
-      In zone "secure.example." following records exist:
-      secure.example.   SOA      <soa stuff>
-      secure.example.   NS       ns1.secure.example.
-      secure.example.   KEY      <tag=12345 alg=3>
-      secure.example.   KEY      <tag=54321 alg=5>
-      secure.example.   NXT      <nxt stuff>
-      secure.example.   SIG(KEY) <key-tag=12345 alg=3>
-      secure.example.   SIG(SOA) <key-tag=54321 alg=5>
-      secure.example.   SIG(NS)  <key-tag=54321 alg=5>
-      secure.example.   SIG(NXT) <key-tag=54321 alg=5>
-
-   In this example, the private key for "example." signs the DS record
-   for "secure.example.", making that a secure delegation.  The DS
-   record states which key is expected to sign the KEY RRset at
-   "secure.example.".  Here "secure.example." signs its KEY RRset with
-   the KEY identified in the DS RRset, thus the KEY RRset is validated
-   and trusted.
-
-   This example has only one DS record for the child, but parents MUST
-   allow multiple DS records to facilitate key roll-over and multiple
-   KEY algorithms.
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 14]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   The resolver determines the security status of "unsecure.example." by
-   examining the parent zone's NXT record for this name.  The absence of
-   the DS bit indicates an unsecure delegation.  Note the NXT record
-   SHOULD only be examined after verifying the corresponding signature.
-
-3.2.  Resolver Cost Estimates for DS Records
-
-   From a RFC 2535 recursive resolver point of view, for each delegation
-   followed to chase down an answer, one KEY RRset has to be verified.
-   Additional RRsets might also need to be verified based on local
-   policy (e.g., the contents of the NS RRset).  Once the resolver gets
-   to the appropriate delegation, validating the answer might require
-   verifying one or more signatures.  A simple A record lookup requires
-   at least N delegations to be verified and one RRset.  For a DS-
-   enabled recursive resolver, the cost is 2N+1.  For an MX record,
-   where the target of the MX record is in the same zone as the MX
-   record, the costs are N+2 and 2N+2, for RFC 2535 and DS,
-   respectively.  In the case of a negative answer, the same ratios hold
-   true.
-
-   The recursive resolver has to do an extra query to get the DS record,
-   which will increase the overall cost of resolving this question, but
-   it will never be worse than chasing down NULL KEY records from the
-   parent in RFC 2535 DNSSEC.
-
-   DS adds processing overhead on resolvers and increases the size of
-   delegation answers, but much less than storing signatures in the
-   parent zone.
-
-4.  Security Considerations
-
-   This document proposes a change to the validation chain of KEY
-   records in DNSSEC.  The change is not believed to reduce security in
-   the overall system.  In RFC 2535 DNSSEC, the child zone has to
-   communicate keys to its parent and prudent parents will require some
-   authentication with that transaction.  The modified protocol will
-   require the same authentication, but allows the child to exert more
-   local control over its own KEY RRset.
-
-   There is a remote possibility that an attacker could generate a valid
-   KEY that matches all the DS fields, of a specific DS set, and thus
-   forge data from the child.  This possibility is considered
-   impractical, as on average more than
-
-      2 ^ (160 - <Number of keys in DS set>)
-
-   keys would have to be generated before a match would be found.
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 15]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   An attacker that wants to match any DS record will have to generate
-   on average at least 2^80 keys.
-
-   The DS record represents a change to the DNSSEC protocol and there is
-   an installed base of implementations, as well as textbooks on how to
-   set up secure delegations.  Implementations that do not understand
-   the DS record will not be able to follow the KEY to DS to KEY chain
-   and will consider all zones secured that way as unsecure.
-
-5.  IANA Considerations
-
-   IANA has allocated an RR type code for DS from the standard RR type
-   space (type 43).
-
-   IANA has established a new registry for the DS RR type for digest
-   algorithms.  Defined types are:
-
-      0 is Reserved,
-      1 is SHA-1.
-
-   Adding new reservations requires IETF standards action.
-
-6.  Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 16]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-7.  Acknowledgments
-
-   Over the last few years a number of people have contributed ideas
-   that are captured in this document.  The core idea of using one key
-   to sign only the KEY RRset comes from discussions with Bill Manning
-   and Perry Metzger on how to put in a single root key in all
-   resolvers. Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie,
-   Jakob Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt
-   Larson, Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker,
-   Miek Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David
-   Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark
-   Andrews, Harald Alvestrand, and others have provided useful comments.
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
-              Signing Authority", RFC 3008, November 2000.
-
-   [RFC3090]  Lewis, E., "DNS Security Extension Clarification on Zone
-              Status", RFC 3090, March 2001.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-              3225, December 2001.
-
-   [RFC3445]  Massey, D. and S. Rose, "Limiting the scope of the KEY
-              Resource Record (RR)", RFC 3445, December 2002.
-
-8.2.  Informational References
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
-              message size requirements", RFC 3226, December 2001.
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 17]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-9.  Author's Address
-
-   Olafur Gudmundsson
-   3821 Village Park Drive
-   Chevy Chase, MD,  20815
-
-   EMail: ds-rfc@ogud.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 18]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-10.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 19]
-
diff --git a/doc/rfc/rfc3755.txt b/doc/rfc/rfc3755.txt
deleted file mode 100644
index a9a7cf26..00000000
--- a/doc/rfc/rfc3755.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          S. Weiler
-Request for Comments: 3755                                  SPARTA, Inc.
-Updates: 3658, 2535                                             May 2004
-Category: Standards Track
-
-
-        Legacy Resolver Compatibility for Delegation Signer (DS)
-
-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
-
-   As the DNS Security (DNSSEC) specifications have evolved, the syntax
-   and semantics of the DNSSEC resource records (RRs) have changed.
-   Many deployed nameservers understand variants of these semantics.
-   Dangerous interactions can occur when a resolver that understands an
-   earlier version of these semantics queries an authoritative server
-   that understands the new delegation signer semantics, including at
-   least one failure scenario that will cause an unsecured zone to be
-   unresolvable.  This document changes the type codes and mnemonics of
-   the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions.
-
-1.  Introduction
-
-   The DNSSEC protocol has been through many iterations whose syntax and
-   semantics are not completely compatible.  This has occurred as part
-   of the ordinary process of proposing a protocol, implementing it,
-   testing it in the increasingly complex and diverse environment of the
-   Internet, and refining the definitions of the initial Proposed
-   Standard.  In the case of DNSSEC, the process has been complicated by
-   DNS's criticality and wide deployment and the need to add security
-   while minimizing daily operational complexity.
-
-   A weak area for previous DNS specifications has been lack of detail
-   in specifying resolver behavior, leaving implementors largely on
-   their own to determine many details of resolver function.  This,
-   combined with the number of iterations the DNSSEC specifications have
-   been through, has resulted in fielded code with a wide variety of
-
-
-
-Weiler                      Standards Track                     [Page 1]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-   behaviors.  This variety makes it difficult to predict how a protocol
-   change will be handled by all deployed resolvers.  The risk that a
-   change will cause unacceptable or even catastrophic failures makes it
-   difficult to design and deploy a protocol change.  One strategy for
-   managing that risk is to structure protocol changes so that existing
-   resolvers can completely ignore input that might confuse them or
-   trigger undesirable failure modes.
-
-   This document addresses a specific problem caused by Delegation
-   Signer's (DS) [RFC3658] introduction of new semantics for the NXT RR
-   that are incompatible with the semantics in [RFC2535].  Answers
-   provided by DS-aware servers can trigger an unacceptable failure mode
-   in some resolvers that implement RFC 2535, which provides a great
-   disincentive to sign zones with DS.  The changes defined in this
-   document allow for the incremental deployment of DS.
-
-1.1.  Terminology
-
-   In this document, the term "unsecure delegation" means any delegation
-   for which no DS record appears at the parent.  An "unsecure referral"
-   is an answer from the parent containing an NS RRset and a proof that
-   no DS record exists for that name.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-1.2.  The Problem
-
-   Delegation Signer (DS) introduces new semantics for the NXT RR that
-   are incompatible with the semantics in RFC 2535.  In RFC 2535, NXT
-   records were only required to be returned as part of a non-existence
-   proof.  With DS, an unsecure referral returns, in addition to the NS,
-   a proof of non-existence of a DS RR in the form of an NXT and
-   SIG(NXT).  RFC 2535 didn't specify how a resolver was to interpret a
-   response with RCODE=0, AA=0, and both an NS and an NXT in the
-   authority section.  Some widely deployed 2535-aware resolvers
-   interpret any answer with an NXT as a proof of non-existence of the
-   requested record.  This results in unsecure delegations being
-   invisible to 2535-aware resolvers and violates the basic
-   architectural principle that DNSSEC must do no harm -- the signing of
-   zones must not prevent the resolution of unsecured delegations.
-
-2.  Possible Solutions
-
-   This section presents several solutions that were considered.
-   Section 3 describes the one selected.
-
-
-
-
-Weiler                      Standards Track                     [Page 2]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-2.1.  Change SIG, KEY, and NXT type codes
-
-   To avoid the problem described above, legacy (RFC2535-aware)
-   resolvers need to be kept from seeing unsecure referrals that include
-   NXT records in the authority section.  The simplest way to do that is
-   to change the type codes for SIG, KEY, and NXT.
-
-   The obvious drawback to this is that new resolvers will not be able
-   to validate zones signed with the old RRs.  This problem already
-   exists, however, because of the changes made by DS, and resolvers
-   that understand the old RRs (and have compatibility issues with DS)
-   are far more prevalent than 2535-signed zones.
-
-2.2.  Change a subset of type codes
-
-   The observed problem with unsecure referrals could be addressed by
-   changing only the NXT type code or another subset of the type codes
-   that includes NXT.  This has the virtue of apparent simplicity, but
-   it risks introducing new problems or not going far enough.  It's
-   quite possible that more incompatibilities exist between DS and
-   earlier semantics.  Legacy resolvers may also be confused by seeing
-   records they recognize (SIG and KEY) while being unable to find NXTs.
-   Although it may seem unnecessary to fix that which is not obviously
-   broken, it's far cleaner to change all of the type codes at once.
-   This will leave legacy resolvers and tools completely blinded to
-   DNSSEC -- they will see only unknown RRs.
-
-2.3.  Replace the DO bit
-
-   Another way to keep legacy resolvers from ever seeing DNSSEC records
-   with DS semantics is to have authoritative servers only send that
-   data to DS-aware resolvers.  It's been proposed that assigning a new
-   EDNS0 flag bit to signal DS-awareness (tentatively called "DA"), and
-   having authoritative servers send DNSSEC data only in response to
-   queries with the DA bit set, would accomplish this.  This bit would
-   presumably supplant the DO bit described in [RFC3225].
-
-   This solution is sufficient only if all 2535-aware resolvers zero out
-   EDNS0 flags that they don't understand.  If one passed through the DA
-   bit unchanged, it would still see the new semantics, and it would
-   probably fail to see unsecure delegations.  Since it's impractical to
-   know how every DNS implementation handles unknown EDNS0 flags, this
-   is not a universal solution.  It could, though, be considered in
-   addition to changing the RR type codes.
-
-
-
-
-
-
-
-Weiler                      Standards Track                     [Page 3]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-2.4.  Increment the EDNS version
-
-   Another possible solution is to increment the EDNS version number as
-   defined in [RFC2671], on the assumption that all existing
-   implementations will reject higher versions than they support, and
-   retain the DO bit as the signal for DNSSEC awareness.  This approach
-   has not been tested.
-
-2.5.  Do nothing
-
-   There is a large deployed base of DNS resolvers that understand
-   DNSSEC as defined by the standards track RFC 2535 and [RFC2065] and,
-   due to under specification in those documents, interpret any answer
-   with an NXT as a non-existence proof.  So long as that is the case,
-   zone owners will have a strong incentive to not sign any zones that
-   contain unsecure delegations, lest those delegations be invisible to
-   such a large installed base.  This will dramatically slow DNSSEC
-   adoption.
-
-   Unfortunately, without signed zones there's no clear incentive for
-   operators of resolvers to upgrade their software to support the new
-   version of DNSSEC, as defined in RFC 3658.  Historical data suggests
-   that resolvers are rarely upgraded, and that old nameserver code
-   never dies.
-
-   Rather than wait years for resolvers to be upgraded through natural
-   processes before signing zones with unsecure delegations, addressing
-   this problem with a protocol change will immediately remove the
-   disincentive for signing zones and allow widespread deployment of
-   DNSSEC.
-
-3.  Protocol changes
-
-   This document changes the type codes of SIG, KEY, and NXT.  This
-   approach is the cleanest and safest of those discussed above, largely
-   because the behavior of resolvers that receive unknown type codes is
-   well understood.  This approach has also received the most testing.
-
-   To avoid operational confusion, it's also necessary to change the
-   mnemonics for these RRs.  DNSKEY will be the replacement for KEY,
-   with the mnemonic indicating that these keys are not for application
-   use, per [RFC3445].  RRSIG (Resource Record SIGnature) will replace
-   SIG, and NSEC (Next SECure) will replace NXT.  These new types
-   completely replace the old types, except that SIG(0) [RFC2931] and
-   TKEY [RFC2930] will continue to use SIG and KEY.
-
-
-
-
-
-
-Weiler                      Standards Track                     [Page 4]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-   The new types will have exactly the same syntax and semantics as
-   specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for
-   the following:
-
-   1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC
-      RRs MUST NOT be compressed,
-
-   2) Embedded domain names in RRSIG and NSEC RRs are not downcased for
-      purposes of DNSSEC canonical form and ordering nor for equality
-      comparison, and
-
-   3) An RRSIG with a type-covered field of zero has undefined
-      semantics.  The meaning of such a resource record may only be
-      defined by IETF Standards Action.
-
-   If a resolver receives the old types, it SHOULD treat them as unknown
-   RRs and SHOULD NOT assign any special meaning to them or give them
-   any special treatment.  It MUST NOT use them for DNSSEC validations
-   or other DNS operational decision making.  For example, a resolver
-   MUST NOT use DNSKEYs to validate SIGs or use KEYs to validate RRSIGs.
-   If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive
-   special treatment.  As an example, if a SIG is included in a signed
-   zone, there MUST be an RRSIG for it.  Authoritative servers may wish
-   to give error messages when loading zones containing SIG or NXT
-   records (KEY records may be included for SIG(0) or TKEY).
-
-   As a clarification to previous documents, some positive responses,
-   particularly wildcard proofs and unsecure referrals, will contain
-   NSEC RRs.  Resolvers MUST NOT treat answers with NSEC RRs as negative
-   answers merely because they contain an NSEC.
-
-4.  IANA Considerations
-
-4.1.  DNS Resource Record Types
-
-   This document updates the IANA registry for DNS Resource Record Types
-   by assigning types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs,
-   respectively.
-
-   Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
-   TKEY [RFC2930] use only.
-
-   Type 30 (NXT) should be marked as Obsolete.
-
-
-
-
-
-
-
-
-Weiler                      Standards Track                     [Page 5]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-4.2.  DNS Security Algorithm Numbers
-
-   To allow zone signing (DNSSEC) and transaction security mechanisms
-   (SIG(0) and TKEY) to use different sets of algorithms, the existing
-   "DNS Security Algorithm Numbers" registry is modified to include the
-   applicability of each algorithm.  Specifically, two new columns are
-   added to the registry, showing whether each algorithm may be used for
-   zone signing, transaction security mechanisms, or both.  Only
-   algorithms usable for zone signing may be used in DNSKEY, RRSIG, and
-   DS RRs.  Only algorithms usable for SIG(0) and/or TSIG may be used in
-   SIG and KEY RRs.
-
-   All currently defined algorithms except for Indirect (algorithm 252)
-   remain usable for transaction security mechanisms.  Only RSA/SHA-1
-   [RFC3110], DSA/SHA-1 [RFC2536], and private algorithms (types 253 and
-   254) may be used for zone signing.  Note that the registry does not
-   contain the requirement level of each algorithm, only whether or not
-   an algorithm may be used for the given purposes.  For example,
-   RSA/MD5, while allowed for transaction security mechanisms, is NOT
-   RECOMMENDED, per [RFC3110].
-
-   Additionally, the presentation format algorithm mnemonics from
-   [RFC2535] Section 7 are added to the registry.  This document assigns
-   RSA/SHA-1 the mnemonic RSASHA1.
-
-   As before, assignment of new algorithms in this registry requires
-   IETF Standards Action.  Additionally, modification of algorithm
-   mnemonics or applicability requires IETF Standards Action.  Documents
-   defining a new algorithm must address the applicability of the
-   algorithm and should assign a presentation mnemonic to the algorithm.
-
-4.3.  DNSKEY Flags
-
-   Like the KEY resource record, DNSKEY contains a 16-bit flags field.
-   This document creates a new registry for the DNSKEY flags field.
-
-   Initially, this registry only contains an assignment for bit 7 (the
-   ZONE bit).  Bits 0-6 and 8-15 are available for assignment by IETF
-   Standards Action.
-
-4.4.  DNSKEY Protocol Octet
-
-   Like the KEY resource record, DNSKEY contains an eight bit protocol
-   field.  The only defined value for this field is 3 (DNSSEC).  No
-   other values are allowed, hence no IANA registry is needed for this
-   field.
-
-
-
-
-
-Weiler                      Standards Track                     [Page 6]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-5.  Security Considerations
-
-   The changes introduced here do not materially affect security.  The
-   implications of trying to use both new and legacy types together are
-   not well understood, and attempts to do so would probably lead to
-   unintended and dangerous results.
-
-   Changing type codes will leave code paths in legacy resolvers that
-   are never exercised.  Unexercised code paths are a frequent source of
-   security holes, largely because those code paths do not get frequent
-   scrutiny.
-
-   Doing nothing, as described in section 2.5, will slow DNSSEC
-   deployment.  While this does not decrease security, it also fails to
-   increase it.
-
-6.  References
-
-6.1.  Normative References
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-             2535, March 1999.
-
-   [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
-             (DNS)", RFC 2536, March 1999.
-
-   [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.
-
-   [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-             Name System (DNS)", RFC 3110, May 2001.
-
-   [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
-             (RR)", RFC 3658, December 2003.
-
-
-
-
-
-
-
-
-
-
-
-Weiler                      Standards Track                     [Page 7]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-6.2.  Informative References
-
-   [RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
-             Security Extensions", RFC 2065, January 1997.
-
-   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-             2671, August 1999.
-
-   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-             3225, December 2001.
-
-   [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
-             Resource Record (RR)", RFC 3445, December 2002.
-
-   [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
-             (RR) Types", RFC 3597, September 2003.
-
-7.  Acknowledgments
-
-   The changes introduced here and the analysis of alternatives had many
-   contributors.  With apologies to anyone overlooked, those include:
-   Michael Graff, Johan Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis,
-   Bill Manning, Paul Vixie, and Suzanne Woolf.
-
-   Thanks to Jakob Schlyter and Mark Andrews for identifying the
-   incompatibility described in section 1.2.
-
-   In addition to the above, the author would like to thank Scott Rose,
-   Olafur Gudmundsson, and Sandra Murphy for their substantive comments.
-
-8.  Author's Address
-
-   Samuel Weiler
-   SPARTA, Inc.
-   7075 Samuel Morse Drive
-   Columbia, MD 21046
-   USA
-
-   EMail: weiler@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler                      Standards Track                     [Page 8]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 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/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.
-
-
-
-
-
-
-
-
-
-Weiler                      Standards Track                     [Page 9]
-
diff --git a/doc/rfc/rfc3757.txt b/doc/rfc/rfc3757.txt
deleted file mode 100644
index 31890a4b..00000000
--- a/doc/rfc/rfc3757.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         O. Kolkman
-Request for Comments: 3757                                      RIPE NCC
-Updates: 3755, 2535                                          J. Schlyter
-Category: Standards Track                                         NIC-SE
-                                                                E. Lewis
-                                                                    ARIN
-                                                              April 2004
-
-
-         Domain Name System KEY (DNSKEY) Resource Record (RR)
-                     Secure Entry Point (SEP) Flag
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   With the Delegation Signer (DS) resource record (RR), the concept of
-   a public key acting as a secure entry point (SEP) has been
-   introduced.  During exchanges of public keys with the parent there is
-   a need to differentiate SEP keys from other public keys in the Domain
-   Name System KEY (DNSKEY) resource record set.  A flag bit in the
-   DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.
-   The flag bit is intended to assist in operational procedures to
-   correctly generate DS resource records, or to indicate what DNSKEYs
-   are intended for static configuration.  The flag bit is not to be
-   used in the DNS verification protocol.  This document updates RFC
-   2535 and RFC 3755.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 1]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . .  4
-   3.  DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . .  4
-   4.  Operational Guidelines . . . . . . . . . . . . . . . . . . . .  4
-   5.  Security Considerations. . . . . . . . . . . . . . . . . . . .  5
-   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  6
-   7.  Internationalization Considerations. . . . . . . . . . . . . .  6
-   8.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  6
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-       9.1.  Normative References . . . . . . . . . . . . . . . . . .  6
-       9.2.  Informative References . . . . . . . . . . . . . . . . .  6
-   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  7
-   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8
-
-1.  Introduction
-
-   "All keys are equal but some keys are more equal than others" [6].
-
-   With the definition of the Delegation Signer Resource Record (DS RR)
-   [5], it has become important to differentiate between the keys in the
-   DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
-   other keys in the DNSKEY RR set.  We refer to these public keys as
-   Secure Entry Point (SEP) keys.  A SEP key either used to generate a
-   DS RR or is distributed to resolvers that use the key as the root of
-   a trusted subtree [3].
-
-   In early deployment tests, the use of two (kinds of) key pairs for
-   each zone has been prevalent.  For one kind of key pair the private
-   key is used to sign just the zone's DNSKEY resource record (RR) set.
-   Its public key is intended to be referenced by a DS RR at the parent
-   or configured statically in a resolver.  The private key of the other
-   kind of key pair is used to sign the rest of the zone's data sets.
-   The former key pair is called a key-signing key (KSK) and the latter
-   is called a zone-signing key (ZSK).  In practice there have been
-   usually one of each kind of key pair, but there will be multiples of
-   each at times.
-
-   It should be noted that division of keys pairs into KSK's and ZSK's
-   is not mandatory in any definition of DNSSEC, not even with the
-   introduction of the DS RR.  But, in testing, this distinction has
-   been helpful when designing key roll over (key super-cession)
-   schemes.  Given that the distinction has proven helpful, the labels
-   KSK and ZSK have begun to stick.
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 2]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-   There is a need to differentiate the public keys for the key pairs
-   that are used for key signing from keys that are not used key signing
-   (KSKs vs ZSKs).  This need is driven by knowing which DNSKEYs are to
-   be sent for generating DS RRs, which DNSKEYs are to be distributed to
-   resolvers, and which keys are fed to the signer application at the
-   appropriate time.
-
-   In other words, the SEP bit provides an in-band method to communicate
-   a DNSKEY RR's intended use to third parties.  As an example we
-   present 3 use cases in which the bit is useful:
-
-      The parent is a registry, the parent and the child use secured DNS
-      queries and responses, with a preexisting trust-relation, or plain
-      DNS over a secured channel to exchange the child's DNSKEY RR sets.
-      Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP
-      bit can be used to isolate the DNSKEYs for which a DS RR needs to
-      be created.
-
-      An administrator has configured a DNSKEY as root for a trusted
-      subtree into security aware resolver.  Using a special purpose
-      tool that queries for the KEY RRs from that domain's apex, the
-      administrator will be able to notice the roll over of the trusted
-      anchor by a change of the subset of KEY RRs with the DS flag set.
-
-      A signer might use the SEP bit on the public key to determine
-      which private key to use to exclusively sign the DNSKEY RRset and
-      which private key to use to sign the other RRsets in the zone.
-
-   As demonstrated in the above examples it is important to be able to
-   differentiate the SEP keys from the other keys in a DNSKEY RR set in
-   the flow between signer and (parental) key-collector and in the flow
-   between the signer and the resolver configuration.  The SEP flag is
-   to be of no interest to the flow between the verifier and the
-   authoritative data store.
-
-   The reason for the term "SEP" is a result of the observation that the
-   distinction between KSK and ZSK key pairs is made by the signer, a
-   key pair could be used as both a KSK and a ZSK at the same time.  To
-   be clear, the term SEP was coined to lessen the confusion caused by
-   the overlap.  (Once this label was applied, it had the side effect of
-   removing the temptation to have both a KSK flag bit and a ZSK flag
-   bit.)
-
-   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
-   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
-   interpreted as described in BCP 14, RFC 2119 [1].
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 3]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-2.  The Secure Entry Point (SEP) Flag
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |              flags          |S|   protocol    |   algorithm   |
-   |                             |E|               |               |
-   |                             |P|               |               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               /
-   /                        public key                             /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                          DNSKEY RR Format
-   This document assigns the 15th bit in the flags field as the secure
-   entry point (SEP) bit.  If the bit is set to 1 the key is intended to
-   be used as secure entry point key.  One SHOULD NOT assign special
-   meaning to the key if the bit is set to 0.  Operators can recognize
-   the secure entry point key by the even or odd-ness of the decimal
-   representation of the flag field.
-
-3.  DNSSEC Protocol Changes
-
-   The bit MUST NOT be used during the resolving and verification
-   process.  The SEP flag is only used to provide a hint about the
-   different administrative properties of the key and therefore the use
-   of the SEP flag does not change the DNS resolution protocol or the
-   resolution process.
-
-4.  Operational Guidelines
-
-   The SEP bit is set by the key-pair-generator and MAY be used by the
-   zone signer to decide whether the public part of the key pair is to
-   be prepared for input to a DS RR generation function.  The SEP bit is
-   recommended to be set (to 1) whenever the public key of the key pair
-   will be distributed to the parent zone to build the authentication
-   chain or if the public key is to be distributed for static
-   configuration in verifiers.
-
-   When a key pair is created, the operator needs to indicate whether
-   the SEP bit is to be set in the DNSKEY RR.  As the SEP bit is within
-   the data that is used to compute the 'key tag field' in the SIG RR,
-   changing the SEP bit will change the identity of the key within DNS.
-   In other words, once a key is used to generate signatures, the
-   setting of the SEP bit is to remain constant.  If not, a verifier
-   will not be able to find the relevant KEY RR.
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 4]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-   When signing a zone, it is intended that the key(s) with the SEP bit
-   set (if such keys exist) are used to sign the KEY RR set of the zone.
-   The same key can be used to sign the rest of the zone data too.  It
-   is conceivable that not all keys with a SEP bit set will sign the
-   DNSKEY RR set, such keys might be pending retirement or not yet in
-   use.
-
-   When verifying a RR set, the SEP bit is not intended to play a role.
-   How the key is used by the verifier is not intended to be a
-   consideration at key creation time.
-
-   Although the SEP flag provides a hint on which public key is to be
-   used as trusted root, administrators can choose to ignore the fact
-   that a DNSKEY has its SEP bit set or not when configuring a trusted
-   root for their resolvers.
-
-   Using the SEP flag a key roll over can be automated.  The parent can
-   use an existing trust relation to verify DNSKEY RR sets in which a
-   new DNSKEY RR with the SEP flag appears.
-
-5.  Security Considerations
-
-   As stated in Section 3 the flag is not to be used in the resolution
-   protocol or to determine the security status of a key.  The flag is
-   to be used for administrative purposes only.
-
-   No trust in a key should be inferred from this flag - trust MUST be
-   inferred from an existing chain of trust or an out-of-band exchange.
-
-   Since this flag might be used for automating public key exchanges, we
-   think the following consideration is in place.
-
-   Automated mechanisms for roll over of the DS RR might be vulnerable
-   to a class of replay attacks.  This might happen after a public key
-   exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
-   SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
-   RR set with the existing trust relation and creates the new DS RR
-   from the DNSKEY RR that the current DS RR is not pointing to.  This
-   key exchange might be replayed.  Parents are encouraged to implement
-   a replay defense.  A simple defense can be based on a registry of
-   keys that have been used to generate DS RRs during the most recent
-   roll over.  These same considerations apply to entities that
-   configure keys in resolvers.
-
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 5]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-6.  IANA Considerations
-
-   IANA has assigned the 15th bit in the DNSKEY Flags Registry (see
-   Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
-
-7.  Internationalization Considerations
-
-   Although SEP is a popular acronym in many different languages, there
-   are no internationalization considerations.
-
-8.  Acknowledgments
-
-   The ideas documented in this document are inspired by communications
-   we had with numerous people and ideas published by other folk.  Among
-   others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
-   Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
-   have contributed ideas and provided feedback.
-
-   This document saw the light during a workshop on DNSSEC operations
-   hosted by USC/ISI in August 2002.
-
-9.  References
-
-9.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
-        Status", RFC 3090, March 2001.
-
-   [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
-        (DS)", RFC 3755, April 2004.
-
-9.2.  Informative References
-
-   [5]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
-        RFC 3658, December 2003.
-
-   [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
-        Story", ISBN 0151002177 (50th anniversary edition), April 1996.
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 6]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-10.  Authors' Addresses
-
-   Olaf M. Kolkman
-   RIPE NCC
-   Singel 256
-   Amsterdam  1016 AB
-   NL
-
-   Phone: +31 20 535 4444
-   EMail: olaf@ripe.net
-   URI:   http://www.ripe.net/
-
-
-   Jakob Schlyter
-   NIC-SE
-   Box 5774
-   SE-114 87 Stockholm
-   Sweden
-
-   EMail: jakob@nic.se
-   URI:   http://www.nic.se/
-
-
-   Edward P. Lewis
-   ARIN
-   3635 Concorde Parkway Suite 200
-   Chantilly, VA  20151
-   US
-
-   Phone: +1 703 227 9854
-   EMail: edlewis@arin.net
-   URI:   http://www.arin.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 7]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-11.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78 and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed
-   to pertain to the implementation or use of the technology
-   described in this document or the extent to which any license
-   under such rights might or might not be available; nor does it
-   represent that it has made any independent effort to identify any
-   such rights.  Information on the procedures with respect to
-   rights in RFC documents can be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use
-   of such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository
-   at http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention
-   any copyrights, patents or patent applications, or other
-   proprietary rights that may cover technology that may be required
-   to implement this standard.  Please address the information to the
-   IETF at ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 8]
-
diff --git a/doc/rfc/rfc3833.txt b/doc/rfc/rfc3833.txt
deleted file mode 100644
index 8ce4d34e..00000000
--- a/doc/rfc/rfc3833.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          D. Atkins
-Request for Comments: 3833                              IHTFP Consulting
-Category: Informational                                       R. Austein
-                                                                     ISC
-                                                             August 2004
-
-
-            Threat Analysis of the Domain Name System (DNS)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   Although the DNS Security Extensions (DNSSEC) have been under
-   development for most of the last decade, the IETF has never written
-   down the specific set of threats against which DNSSEC is designed to
-   protect.  Among other drawbacks, this cart-before-the-horse situation
-   has made it difficult to determine whether DNSSEC meets its design
-   goals, since its design goals are not well specified.  This note
-   attempts to document some of the known threats to the DNS, and, in
-   doing so, attempts to measure to what extent (if any) DNSSEC is a
-   useful tool in defending against these threats.
-
-1. Introduction
-
-   The earliest organized work on DNSSEC within the IETF was an open
-   design team meeting organized by members of the DNS working group in
-   November 1993 at the 28th IETF meeting in Houston.  The broad
-   outlines of DNSSEC as we know it today are already clear in Jim
-   Galvin's summary of the results of that meeting [Galvin93]:
-
-   - While some participants in the meeting were interested in
-     protecting against disclosure of DNS data to unauthorized parties,
-     the design team made an explicit decision that "DNS data is
-     `public'", and ruled all threats of data disclosure explicitly out
-     of scope for DNSSEC.
-
-   - While some participants in the meeting were interested in
-     authentication of DNS clients and servers as a basis for access
-     control, this work was also ruled out of scope for DNSSEC per se.
-
-
-
-Atkins & Austein             Informational                      [Page 1]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   - Backwards compatibility and co-existence with "insecure DNS" was
-     listed as an explicit requirement.
-
-   - The resulting list of desired security services was
-     1) data integrity, and
-     2) data origin authentication.
-
-   - The design team noted that a digital signature mechanism would
-     support the desired services.
-
-   While a number of detail decisions were yet to be made (and in some
-   cases remade after implementation experience) over the subsequent
-   decade, the basic model and design goals have remained fixed.
-
-   Nowhere, however, does any of the DNSSEC work attempt to specify in
-   any detail the sorts of attacks against which DNSSEC is intended to
-   protect, or the reasons behind the list of desired security services
-   that came out of the Houston meeting.  For that, we have to go back
-   to a paper originally written by Steve Bellovin in 1990 but not
-   published until 1995, for reasons that Bellovin explained in the
-   paper's epilogue [Bellovin95].
-
-   While it may seem a bit strange to publish the threat analysis a
-   decade after starting work on the protocol designed to defend against
-   it, that is, nevertheless, what this note attempts to do.  Better
-   late than never.
-
-   This note assumes that the reader is familiar with both the DNS and
-   with DNSSEC, and does not attempt to provide a tutorial on either.
-   The DNS documents most relevant to the subject of this note are:
-   [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308],
-   [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535].
-
-   For purposes of discussion, this note uses the term "DNSSEC" to refer
-   to the core hierarchical public key and signature mechanism specified
-   in the DNSSEC documents, and refers to TKEY and TSIG as separate
-   mechanisms, even though channel security mechanisms such as TKEY and
-   TSIG are also part of the larger problem of "securing DNS" and thus
-   are often considered part of the overall set of "DNS security
-   extensions".  This is an arbitrary distinction that in part reflects
-   the way in which the protocol has evolved (introduction of a
-   putatively simpler channel security model for certain operations such
-   as zone transfers and dynamic update requests), and perhaps should be
-   changed in a future revision of this note.
-
-
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 2]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-2.  Known Threats
-
-   There are several distinct classes of threats to the DNS, most of
-   which are DNS-related instances of more general problems, but a few
-   of which are specific to peculiarities of the DNS protocol.
-
-2.1.  Packet Interception
-
-   Some of the simplest threats against DNS are various forms of packet
-   interception: monkey-in-the-middle attacks, eavesdropping on requests
-   combined with spoofed responses that beat the real response back to
-   the resolver, and so forth.  In any of these scenarios, the attacker
-   can simply tell either party (usually the resolver) whatever it wants
-   that party to believe.  While packet interception attacks are far
-   from unique to DNS, DNS's usual behavior of sending an entire query
-   or response in a single unsigned, unencrypted UDP packet makes these
-   attacks particularly easy for any bad guy with the ability to
-   intercept packets on a shared or transit network.
-
-   To further complicate things, the DNS query the attacker intercepts
-   may just be a means to an end for the attacker: the attacker might
-   even choose to return the correct result in the answer section of a
-   reply message while using other parts of the message to set the stage
-   for something more complicated, for example, a name chaining attack
-   (see section 2.3).
-
-   While it certainly would be possible to sign DNS messages using a
-   channel security mechanism such as TSIG or IPsec, or even to encrypt
-   them using IPsec, this would not be a very good solution for
-   interception attacks.  First, this approach would impose a fairly
-   high processing cost per DNS message, as well as a very high cost
-   associated with establishing and maintaining bilateral trust
-   relationships between all the parties that might be involved in
-   resolving any particular query.  For heavily used name servers (such
-   as the servers for the root zone), this cost would almost certainly
-   be prohibitively high.  Even more important, however, is that the
-   underlying trust model in such a design would be wrong, since at best
-   it would only provide a hop-by-hop integrity check on DNS messages
-   and would not provide any sort of end-to-end integrity check between
-   the producer of DNS data (the zone administrator) and the consumer of
-   DNS data (the application that triggered the query).
-
-   By contrast, DNSSEC (when used properly) does provide an end-to-end
-   data integrity check, and is thus a much better solution for this
-   class of problems during basic DNS lookup operations.
-
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 3]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   TSIG does have its place in corners of the DNS protocol where there's
-   a specific trust relationship between a particular client and a
-   particular server, such as zone transfer, dynamic update, or a
-   resolver (stub or otherwise) that is not going to check all the
-   DNSSEC signatures itself.
-
-   Note that DNSSEC does not provide any protection against modification
-   of the DNS message header, so any properly paranoid resolver must:
-
-   - Perform all of the DNSSEC signature checking on its own,
-
-   - Use TSIG (or some equivalent mechanism) to ensure the integrity of
-     its communication with whatever name servers it chooses to trust,
-     or
-
-   - Resign itself to the possibility of being attacked via packet
-     interception (and via other techniques discussed below).
-
-2.2.  ID Guessing and Query Prediction
-
-   Since DNS is for the most part used over UDP/IP, it is relatively
-   easy for an attacker to generate packets which will match the
-   transport protocol parameters.  The ID field in the DNS header is
-   only a 16-bit field and the server UDP port associated with DNS is a
-   well-known value, so there are only 2**32 possible combinations of ID
-   and client UDP port for a given client and server.  This is not a
-   particularly large range, and is not sufficient to protect against a
-   brute force search; furthermore, in practice both the client UDP port
-   and the ID can often be predicted from previous traffic, and it is
-   not uncommon for the client port to be a known fixed value as well
-   (due to firewalls or other restrictions), thus frequently reducing
-   the search space to a range smaller than 2**16.
-
-   By itself, ID guessing is not enough to allow an attacker to inject
-   bogus data, but combined with knowledge (or guesses) about QNAMEs and
-   QTYPEs for which a resolver might be querying, this leaves the
-   resolver only weakly defended against injection of bogus responses.
-
-   Since this attack relies on predicting a resolver's behavior, it's
-   most likely to be successful when the victim is in a known state,
-   whether because the victim rebooted recently, or because the victim's
-   behavior has been influenced by some other action by the attacker, or
-   because the victim is responding (in a predictable way) to some third
-   party action known to the attacker.
-
-
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 4]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   This attack is both more and less difficult for the attacker than the
-   simple interception attack described above: more difficult, because
-   the attack only works when the attacker guesses correctly; less
-   difficult, because the attacker doesn't need to be on a transit or
-   shared network.
-
-   In most other respects, this attack is similar to a packet
-   interception attack.  A resolver that checks DNSSEC signatures will
-   be able to detect the forged response; resolvers that do not perform
-   DNSSEC signature checking themselves should use TSIG or some
-   equivalent mechanism to ensure the integrity of their communication
-   with a recursive name server that does perform DNSSEC signature
-   checking.
-
-2.3.  Name Chaining
-
-   Perhaps the most interesting class of DNS-specific threats are the
-   name chaining attacks.  These are a subset of a larger class of
-   name-based attacks, sometimes called "cache poisoning" attacks.  Most
-   name-based attacks can be partially mitigated by the long-standing
-   defense of checking RRs in response messages for relevance to the
-   original query, but such defenses do not catch name chaining attacks.
-   There are several variations on the basic attack, but what they all
-   have in common is that they all involve DNS RRs whose RDATA portion
-   (right hand side) includes a DNS name (or, in a few cases, something
-   that is not a DNS name but which directly maps to a DNS name).  Any
-   such RR is, at least in principle, a hook that lets an attacker feed
-   bad data into a victim's cache, thus potentially subverting
-   subsequent decisions based on DNS names.
-
-   The worst examples in this class of RRs are CNAME, NS, and DNAME RRs
-   because they can redirect a victim's query to a location of the
-   attacker's choosing.  RRs like MX and SRV are somewhat less
-   dangerous, but in principle they can also be used to trigger further
-   lookups at a location of the attacker's choosing.  Address RR types
-   such as A or AAAA don't have DNS names in their RDATA, but since the
-   IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of
-   IPv4 and IPv6 addresses, these record types can also be used in a
-   name chaining attack.
-
-   The general form of a name chaining attack is something like this:
-
-   - Victim issues a query, perhaps at the instigation of the attacker
-     or some third party; in some cases the query itself may be
-     unrelated to the name under attack (that is, the attacker is just
-     using this query as a means to inject false information about some
-     other name).
-
-
-
-
-Atkins & Austein             Informational                      [Page 5]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   - Attacker injects response, whether via packet interception, query
-     guessing, or by being a legitimate name server that's involved at
-     some point in the process of answering the query that the victim
-     issued.
-
-   - Attacker's response includes one or more RRs with DNS names in
-     their RDATA; depending on which particular form this attack takes,
-     the object may be to inject false data associated with those names
-     into the victim's cache via the Additional section of this
-     response, or may be to redirect the next stage of the query to a
-     server of the attacker's choosing (in order to inject more complex
-     lies into the victim's cache than will fit easily into a single
-     response, or in order to place the lies in the Authority or Answer
-     section of a response where they will have a better chance of
-     sneaking past a resolver's defenses).
-
-   Any attacker who can insert resource records into a victim's cache
-   can almost certainly do some kind of damage, so there are cache
-   poisoning attacks which are not name chaining attacks in the sense
-   discussed here.  However, in the case of name chaining attacks, the
-   cause and effect relationship between the initial attack and the
-   eventual result may be significantly more complex than in the other
-   forms of cache poisoning, so name chaining attacks merit special
-   attention.
-
-   The common thread in all of the name chaining attacks is that
-   response messages allow the attacker to introduce arbitrary DNS names
-   of the attacker's choosing and provide further information that the
-   attacker claims is associated with those names; unless the victim has
-   better knowledge of the data associated with those names, the victim
-   is going to have a hard time defending against this class of attacks.
-
-   This class of attack is particularly insidious given that it's quite
-   easy for an attacker to provoke a victim into querying for a
-   particular name of the attacker's choosing, for example, by embedding
-   a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail
-   to the victim.  If the victim's mail reading program attempts to
-   follow such a link, the result will be a DNS query for a name chosen
-   by the attacker.
-
-   DNSSEC should provide a good defense against most (all?) variations
-   on this class of attack.  By checking signatures, a resolver can
-   determine whether the data associated with a name really was inserted
-   by the delegated authority for that portion of the DNS name space.
-   More precisely, a resolver can determine whether the entity that
-   injected the data had access to an allegedly secret key whose
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 6]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   corresponding public key appears at an expected location in the DNS
-   name space with an expected chain of parental signatures that start
-   with a public key of which the resolver has prior knowledge.
-
-   DNSSEC signatures do not cover glue records, so there's still a
-   possibility of a name chaining attack involving glue, but with DNSSEC
-   it is possible to detect the attack by temporarily accepting the glue
-   in order to fetch the signed authoritative version of the same data,
-   then checking the signatures on the authoritative version.
-
-2.4.  Betrayal By Trusted Server
-
-   Another variation on the packet interception attack is the trusted
-   server that turns out not to be so trustworthy, whether by accident
-   or by intent.  Many client machines are only configured with stub
-   resolvers, and use trusted servers to perform all of their DNS
-   queries on their behalf.  In many cases the trusted server is
-   furnished by the user's ISP and advertised to the client via DHCP or
-   PPP options.  Besides accidental betrayal of this trust relationship
-   (via server bugs, successful server break-ins, etc), the server
-   itself may be configured to give back answers that are not what the
-   user would expect, whether in an honest attempt to help the user or
-   to promote some other goal such as furthering a business partnership
-   between the ISP and some third party.
-
-   This problem is particularly acute for frequent travelers who carry
-   their own equipment and expect it to work in much the same way
-   wherever they go.  Such travelers need trustworthy DNS service
-   without regard to who operates the network into which their equipment
-   is currently plugged or what brand of middle boxes the local
-   infrastructure might use.
-
-   While the obvious solution to this problem would be for the client to
-   choose a more trustworthy server, in practice this may not be an
-   option for the client.  In many network environments a client machine
-   has only a limited set of recursive name servers from which to
-   choose, and none of them may be particularly trustworthy.  In extreme
-   cases, port filtering or other forms of packet interception may
-   prevent the client host from being able to run an iterative resolver
-   even if the owner of the client machine is willing and able to do so.
-   Thus, while the initial source of this problem is not a DNS protocol
-   attack per se, this sort of betrayal is a threat to DNS clients, and
-   simply switching to a different recursive name server is not an
-   adequate defense.
-
-   Viewed strictly from the DNS protocol standpoint, the only difference
-   between this sort of betrayal and a packet interception attack is
-   that in this case the client has voluntarily sent its request to the
-
-
-
-Atkins & Austein             Informational                      [Page 7]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   attacker.  The defense against this is the same as with a packet
-   interception attack: the resolver must either check DNSSEC signatures
-   itself or use TSIG (or equivalent) to authenticate the server that it
-   has chosen to trust.  Note that use of TSIG does not by itself
-   guarantee that a name server is at all trustworthy: all TSIG can do
-   is help a resolver protect its communication with a name server that
-   it has already decided to trust for other reasons.  Protecting a
-   resolver's communication with a server that's giving out bogus
-   answers is not particularly useful.
-
-   Also note that if the stub resolver does not trust the name server
-   that is doing work on its behalf and wants to check the DNSSEC
-   signatures itself, the resolver really does need to have independent
-   knowledge of the DNSSEC public key(s) it needs in order to perform
-   the check.  Usually the public key for the root zone is enough, but
-   in some cases knowledge of additional keys may also be appropriate.
-
-   It is difficult to escape the conclusion that a properly paranoid
-   resolver must always perform its own signature checking, and that
-   this rule even applies to stub resolvers.
-
-2.5.  Denial of Service
-
-   As with any network service (or, indeed, almost any service of any
-   kind in any domain of discourse), DNS is vulnerable to denial of
-   service attacks.  DNSSEC does not help this, and may in fact make the
-   problem worse for resolvers that check signatures, since checking
-   signatures both increases the processing cost per DNS message and in
-   some cases can also increase the number of messages needed to answer
-   a query.  TSIG (and similar mechanisms) have equivalent problems.
-
-   DNS servers are also at risk of being used as denial of service
-   amplifiers, since DNS response packets tend to be significantly
-   longer than DNS query packets.  Unsurprisingly, DNSSEC doesn't help
-   here either.
-
-2.6.  Authenticated Denial of Domain Names
-
-   Much discussion has taken place over the question of authenticated
-   denial of domain names.  The particular question is whether there is
-   a requirement for authenticating the non-existence of a name.  The
-   issue is whether the resolver should be able to detect when an
-   attacker removes RRs from a response.
-
-   General paranoia aside, the existence of RR types whose absence
-   causes an action other than immediate failure (such as missing MX and
-   SRV RRs, which fail over to A RRs) constitutes a real threat.
-   Arguably, in some cases, even the absence of an RR might be
-
-
-
-Atkins & Austein             Informational                      [Page 8]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   considered a problem.  The question remains: how serious is this
-   threat?  Clearly the threat does exist; general paranoia says that
-   some day it'll be on the front page of some major newspaper, even if
-   we cannot conceive of a plausible scenario involving this attack
-   today.  This implies that some mitigation of this risk is required.
-
-   Note that it's necessary to prove the non-existence of applicable
-   wildcard RRs as part of the authenticated denial mechanism, and that,
-   in a zone that is more than one label deep, such a proof may require
-   proving the non-existence of multiple discrete sets of wildcard RRs.
-
-   DNSSEC does include mechanisms which make it possible to determine
-   which authoritative names exist in a zone, and which authoritative
-   resource record types exist at those names.  The DNSSEC protections
-   do not cover non-authoritative data such as glue records.
-
-2.7.  Wildcards
-
-   Much discussion has taken place over whether and how to provide data
-   integrity and data origin authentication for "wildcard" DNS names.
-   Conceptually, RRs with wildcard names are patterns for synthesizing
-   RRs on the fly according to the matching rules described in section
-   4.3.2 of RFC 1034.  While the rules that control the behavior of
-   wildcard names have a few quirks that can make them a trap for the
-   unwary zone administrator, it's clear that a number of sites make
-   heavy use of wildcard RRs, particularly wildcard MX RRs.
-
-   In order to provide the desired services for wildcard RRs, we need to
-   do two things:
-
-   - We need a way to attest to the existence of the wildcard RR itself
-     (that is, we need to show that the synthesis rule exists), and
-
-   - We need a way to attest to the non-existence of any RRs which, if
-     they existed, would make the wildcard RR irrelevant according to
-     the synthesis rules that govern the way in which wildcard RRs are
-     used (that is, we need to show that the synthesis rule is
-     applicable).
-
-   Note that this makes the wildcard mechanisms dependent upon the
-   authenticated denial mechanism described in the previous section.
-
-   DNSSEC includes mechanisms along the lines described above, which
-   make it possible for a resolver to verify that a name server applied
-   the wildcard expansion rules correctly when generating an answer.
-
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 9]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-3.  Weaknesses of DNSSEC
-
-   DNSSEC has some problems of its own:
-
-   - DNSSEC is complex to implement and includes some nasty edge cases
-     at the zone cuts that require very careful coding.  Testbed
-     experience to date suggests that trivial zone configuration errors
-     or expired keys can cause serious problems for a DNSSEC-aware
-     resolver, and that the current protocol's error reporting
-     capabilities may leave something to be desired.
-
-   - DNSSEC significantly increases the size of DNS response packets;
-     among other issues, this makes DNSSEC-aware DNS servers even more
-     effective as denial of service amplifiers.
-
-   - DNSSEC answer validation increases the resolver's work load, since
-     a DNSSEC-aware resolver will need to perform signature validation
-     and in some cases will also need to issue further queries.  This
-     increased workload will also increase the time it takes to get an
-     answer back to the original DNS client, which is likely to trigger
-     both timeouts and re-queries in some cases.  Arguably, many current
-     DNS clients are already too impatient even before taking the
-     further delays that DNSSEC will impose into account, but that topic
-     is beyond the scope of this note.
-
-   - Like DNS itself, DNSSEC's trust model is almost totally
-     hierarchical.  While DNSSEC does allow resolvers to have special
-     additional knowledge of public keys beyond those for the root, in
-     the general case the root key is the one that matters.  Thus any
-     compromise in any of the zones between the root and a particular
-     target name can damage DNSSEC's ability to protect the integrity of
-     data owned by that target name.  This is not a change, since
-     insecure DNS has the same model.
-
-   - Key rollover at the root is really hard.  Work to date has not even
-     come close to adequately specifying how the root key rolls over, or
-     even how it's configured in the first place.
-
-   - DNSSEC creates a requirement of loose time synchronization between
-     the validating resolver and the entity creating the DNSSEC
-     signatures.  Prior to DNSSEC, all time-related actions in DNS could
-     be performed by a machine that only knew about "elapsed" or
-     "relative" time.  Because the validity period of a DNSSEC signature
-     is based on "absolute" time, a validating resolver must have the
-     same concept of absolute time as the zone signer in order to
-     determine whether the signature is within its validity period or
-     has expired.  An attacker that can change a resolver's opinion of
-     the current absolute time can fool the resolver using expired
-
-
-
-Atkins & Austein             Informational                     [Page 10]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-     signatures.  An attacker that can change the zone signer's opinion
-     of the current absolute time can fool the zone signer into
-     generating signatures whose validity period does not match what the
-     signer intended.
-
-   - The possible existence of wildcard RRs in a zone complicates the
-     authenticated denial mechanism considerably.  For most of the
-     decade that DNSSEC has been under development these issues were
-     poorly understood.  At various times there have been questions as
-     to whether the authenticated denial mechanism is completely
-     airtight and whether it would be worthwhile to optimize the
-     authenticated denial mechanism for the common case in which
-     wildcards are not present in a zone.  However, the main problem is
-     just the inherent complexity of the wildcard mechanism itself.
-     This complexity probably makes the code for generating and checking
-     authenticated denial attestations somewhat fragile, but since the
-     alternative of giving up wildcards entirely is not practical due to
-     widespread use, we are going to have to live with wildcards. The
-     question just becomes one of whether or not the proposed
-     optimizations would make DNSSEC's mechanisms more or less fragile.
-
-   - Even with DNSSEC, the class of attacks discussed in section 2.4 is
-     not easy to defeat.  In order for DNSSEC to be effective in this
-     case, it must be possible to configure the resolver to expect
-     certain categories of DNS records to be signed.  This may require
-     manual configuration of the resolver, especially during the initial
-     DNSSEC rollout period when the resolver cannot reasonably expect
-     the root and TLD zones to be signed.
-
-4.  Topics for Future Work
-
-   This section lists a few subjects not covered above which probably
-   need additional study, additional mechanisms, or both.
-
-4.1.  Interactions With Other Protocols
-
-   The above discussion has concentrated exclusively on attacks within
-   the boundaries of the DNS protocol itself, since those are (some of)
-   the problems against which DNSSEC was intended to protect.  There
-   are, however, other potential problems at the boundaries where DNS
-   interacts with other protocols.
-
-4.2.  Securing DNS Dynamic Update
-
-   DNS dynamic update opens a number of potential problems when combined
-   with DNSSEC.  Dynamic update of a non-secure zone can use TSIG to
-   authenticate the updating client to the server.  While TSIG does not
-   scale very well (it requires manual configuration of shared keys
-
-
-
-Atkins & Austein             Informational                     [Page 11]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   between the DNS name server and each TSIG client), it works well in a
-   limited or closed environment such as a DHCP server updating a local
-   DNS name server.
-
-   Major issues arise when trying to use dynamic update on a secure
-   zone.  TSIG can similarly be used in a limited fashion to
-   authenticate the client to the server, but TSIG only protects DNS
-   transactions, not the actual data, and the TSIG is not inserted into
-   the DNS zone, so resolvers cannot use the TSIG as a way of verifying
-   the changes to the zone.  This means that either:
-
-   a) The updating client must have access to a zone-signing key in
-      order to sign the update before sending it to the server, or
-
-   b) The DNS name server must have access to an online zone-signing key
-      in order to sign the update.
-
-   In either case, a zone-signing key must be available to create signed
-   RRsets to place in the updated zone.  The fact that this key must be
-   online (or at least available) is a potential security risk.
-
-   Dynamic update also requires an update to the SERIAL field of the
-   zone's SOA RR.  In theory, this could also be handled via either of
-   the above options, but in practice (a) would almost certainly be
-   extremely fragile, so (b) is the only workable mechanism.
-
-   There are other threats in terms of describing the policy of who can
-   make what changes to which RRsets in the zone.  The current access
-   control scheme in Secure Dynamic Update is fairly limited.  There is
-   no way to give fine-grained access to updating DNS zone information
-   to multiple entities, each of whom may require different kinds of
-   access.  For example, Alice may need to be able to add new nodes to
-   the zone or change existing nodes, but not remove them; Bob may need
-   to be able to remove zones but not add them; Carol may need to be
-   able to add, remove, or modify nodes, but only A records.
-
-   Scaling properties of the key management problem here are a
-   particular concern that needs more study.
-
-4.3.  Securing DNS Zone Replication
-
-   As discussed in previous sections, DNSSEC per se attempts to provide
-   data integrity and data origin authentication services on top of the
-   normal DNS query protocol.  Using the terminology discussed in
-   [RFC3552], DNSSEC provides "object security" for the normal DNS query
-   protocol.  For purposes of replicating entire DNS zones, however,
-   DNSSEC does not provide object security, because zones include
-   unsigned NS RRs and glue at delegation points.  Use of TSIG to
-
-
-
-Atkins & Austein             Informational                     [Page 12]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   protect zone transfer (AXFR or IXFR) operations provides "channel
-   security", but still does not provide object security for complete
-   zones. The trust relationships involved in zone transfer are still
-   very much a hop-by-hop matter of name server operators trusting other
-   name server operators rather than an end-to-end matter of name server
-   operators trusting zone administrators.
-
-   Zone object security was not an explicit design goal of DNSSEC, so
-   failure to provide this service should not be a surprise.
-   Nevertheless, there are some zone replication scenarios for which
-   this would be a very useful additional service, so this seems like a
-   useful area for future work.  In theory it should not be difficult to
-   add zone object security as a backwards compatible enhancement to the
-   existing DNSSEC model, but the DNSEXT WG has not yet discussed either
-   the desirability of or the requirements for such an enhancement.
-
-5.  Conclusion
-
-   Based on the above analysis, the DNSSEC extensions do appear to solve
-   a set of problems that do need to be solved, and are worth deploying.
-
-Security Considerations
-
-   This entire document is about security considerations of the DNS.
-   The authors believe that deploying DNSSEC will help to address some,
-   but not all, of the known threats to the DNS.
-
-Acknowledgments
-
-   This note is based both on previous published works by others and on
-   a number of discussions both public and private over a period of many
-   years, but particular thanks go to
-
-   Jaap Akkerhuis,
-   Steve Bellovin,
-   Dan Bernstein,
-   Randy Bush,
-   Steve Crocker,
-   Olafur Gudmundsson,
-   Russ Housley,
-   Rip Loomis,
-   Allison Mankin,
-   Paul Mockapetris,
-   Thomas Narten
-   Mans Nilsson,
-   Pekka Savola,
-   Paul Vixie,
-   Xunhua Wang,
-
-
-
-Atkins & Austein             Informational                     [Page 13]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working
-   groups whose names and contributions the authors have forgotten, none
-   of whom are responsible for what the authors did with their ideas.
-
-   As with any work of this nature, the authors of this note acknowledge
-   that we are standing on the toes of those who have gone before us.
-   Readers interested in this subject may also wish to read
-   [Bellovin95], [Schuba93], and [Vixie95].
-
-Normative References
-
-   [RFC1034]    Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC1035]    Mockapetris, P., "Domain names - implementation and
-                specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1123]    Braden, R., "Requirements for Internet Hosts -
-                Application and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC2181]    Elz, R. and R. Bush, "Clarifications to the DNS
-                Specification", RFC 2181, July 1997.
-
-   [RFC2308]    Andrews, M., "Negative Caching of DNS Queries (DNS
-                NCACHE)", RFC 2308, March 1998.
-
-   [RFC2671]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-                2671, August 1999.
-
-   [RFC2845]    Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-                Wellington, "Secret Key Transaction Authentication for
-                DNS (TSIG)", RFC 2845, May 2000.
-
-   [RFC2930]    Eastlake 3rd, D., "Secret Key Establishment for DNS
-                (TKEY RR)", RFC 2930, September 2000.
-
-   [RFC3007]    Wellington, B., "Secure Domain Name System (DNS) Dynamic
-                Update", RFC 3007, November 2000.
-
-   [RFC2535]    Eastlake 3rd, D., "Domain Name System Security
-                Extensions", RFC 2535, March 1999.
-
-
-
-
-
-
-
-
-
-
-Atkins & Austein             Informational                     [Page 14]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-Informative References
-
-   [RFC3552]    Rescorla, E. and B. Korver, "Guidelines for Writing RFC
-                Text on Security Considerations", BCP 72, RFC 3552, July
-                2003.
-
-   [Bellovin95] Bellovin, S., "Using the Domain Name System for System
-                Break-Ins", Proceedings of the Fifth Usenix Unix
-                Security Symposium, June 1995.
-
-   [Galvin93]   Design team meeting summary message posted to dns-
-                security@tis.com mailing list by Jim Galvin on 19
-                November 1993.
-
-   [Schuba93]   Schuba, C., "Addressing Weaknesses in the Domain Name
-                System Protocol", Master's thesis, Purdue University
-                Department of Computer Sciences,  August 1993.
-
-   [Vixie95]    Vixie, P, "DNS and BIND Security Issues", Proceedings of
-                the Fifth Usenix Unix Security Symposium, June 1995.
-
-Authors' Addresses
-
-   Derek Atkins
-   IHTFP Consulting, Inc.
-   6 Farragut Ave
-   Somerville, MA  02144
-   USA
-
-   EMail: derek@ihtfp.com
-
-
-   Rob Austein
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-   USA
-
-   EMail: sra@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-Atkins & Austein             Informational                     [Page 15]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-Atkins & Austein             Informational                     [Page 16]
-
diff --git a/doc/rfc/rfc3845.txt b/doc/rfc/rfc3845.txt
deleted file mode 100644
index 9887a20a..00000000
--- a/doc/rfc/rfc3845.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   J. Schlyter, Ed.
-Request for Comments: 3845                                   August 2004
-Updates: 3755, 2535
-Category: Standards Track
-
-
-          DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document redefines the wire format of the "Type Bit Map" field
-   in the DNS NextSECure (NSEC) resource record RDATA format to cover
-   the full resource record (RR) type space.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . .  2
-       2.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . .  3
-             2.1.1.  The Next Domain Name Field . . . . . . . . . . .  3
-             2.1.2.  The List of Type Bit Map(s) Field  . . . . . . .  3
-             2.1.3.  Inclusion of Wildcard Names in NSEC RDATA  . . .  4
-       2.2.  The NSEC RR Presentation Format  . . . . . . . . . . . .  4
-       2.3.  NSEC RR Example  . . . . . . . . . . . . . . . . . . . .  5
-   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-       5.1.  Normative References . . . . . . . . . . . . . . . . . .  6
-       5.2.  Informative References . . . . . . . . . . . . . . . . .  6
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
-   7.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
-   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  7
-
-
-
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 1]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-1.  Introduction
-
-   The DNS [6][7] NSEC [5] Resource Record (RR) is used for
-   authenticated proof of the non-existence of DNS owner names and
-   types.  The NSEC RR is based on the NXT RR as described in RFC 2535
-   [2], and is similar except for the name and typecode.  The RDATA
-   format for the NXT RR has the limitation in that the RDATA could only
-   carry information about the existence of the first 127 types.  RFC
-   2535 did reserve a bit to specify an extension mechanism, but the
-   mechanism was never actually defined.
-
-   In order to avoid needing to develop an extension mechanism into a
-   deployed base of DNSSEC aware servers and resolvers once the first
-   127 type codes are allocated, this document redefines the wire format
-   of the "Type Bit Map" field in the NSEC RDATA to cover the full RR
-   type space.
-
-   This document introduces a new format for the type bit map.  The
-   properties of the type bit map format are that it can cover the full
-   possible range of typecodes, that it is relatively economical in the
-   amount of space it uses for the common case of a few types with an
-   owner name, that it can represent owner names with all possible types
-   present in packets of approximately 8.5 kilobytes, and that the
-   representation is simple to implement.  Efficient searching of the
-   type bitmap for the presence of certain types is not a requirement.
-
-   For convenience and completeness, this document presents the syntax
-   and semantics for the NSEC RR based on the specification in RFC 2535
-   [2] and as updated by RFC 3755 [5], thereby not introducing changes
-   except for the syntax of the type bit map.
-
-   This document updates RFC 2535 [2] and RFC 3755 [5].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14, RFC 2119 [1].
-
-2.  The NSEC Resource Record
-
-   The NSEC resource record lists two separate things: the owner name of
-   the next RRset in the canonical ordering of the zone, and the set of
-   RR types present at the NSEC RR's owner name.  The complete set of
-   NSEC RRs in a zone indicate which RRsets exist in a zone, and form a
-   chain of owner names in the zone.  This information is used to
-   provide authenticated denial of existence for DNS data, as described
-   in RFC 2535 [2].
-
-   The type value for the NSEC RR is 47.
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 2]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-   The NSEC RR RDATA format is class independent and defined for all
-   classes.
-
-   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
-   field.  This is in the spirit of negative caching [8].
-
-2.1.  NSEC RDATA Wire Format
-
-   The RDATA of the NSEC RR is as shown below:
-
-                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /                      Next Domain Name                         /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /                   List of Type Bit Map(s)                     /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-2.1.1.  The Next Domain Name Field
-
-   The Next Domain Name field contains the owner name of the next RR in
-   the canonical ordering of the zone.  The value of the Next Domain
-   Name field in the last NSEC record in the zone is the name of the
-   zone apex (the owner name of the zone's SOA RR).
-
-   A sender MUST NOT use DNS name compression on the Next Domain Name
-   field when transmitting an NSEC RR.
-
-   Owner names of RRsets that are not authoritative for the given zone
-   (such as glue records) MUST NOT be listed in the Next Domain Name
-   unless at least one authoritative RRset exists at the same owner
-   name.
-
-2.1.2.  The List of Type Bit Map(s) Field
-
-   The RR type space is split into 256 window blocks, each representing
-   the low-order 8 bits of the 16-bit RR type space.  Each block that
-   has at least one active RR type is encoded using a single octet
-   window number (from 0 to 255), a single octet bitmap length (from 1
-   to 32) indicating the number of octets used for the window block's
-   bitmap, and up to 32 octets (256 bits) of bitmap.
-
-   Window blocks are present in the NSEC RR RDATA in increasing
-   numerical order.
-
-   "|" denotes concatenation
-
-   Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 3]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-   Each bitmap encodes the low-order 8 bits of RR types within the
-   window block, in network bit order.  The first bit is bit 0.  For
-   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
-   to RR type 2 (NS), and so forth.  For window block 1, bit 1
-   corresponds to RR type 257, and bit 2 to RR type 258.  If a bit is
-   set to 1, it indicates that an RRset of that type is present for the
-   NSEC RR's owner name.  If a bit is set to 0, it indicates that no
-   RRset of that type is present for the NSEC RR's owner name.
-
-   Since bit 0 in window block 0 refers to the non-existing RR type 0,
-   it MUST be set to 0.  After verification, the validator MUST ignore
-   the value of bit 0 in window block 0.
-
-   Bits representing Meta-TYPEs or QTYPEs, as specified in RFC 2929 [3]
-   (section 3.1), or within the range reserved for assignment only to
-   QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
-   zone data.  If encountered, they must be ignored upon reading.
-
-   Blocks with no types present MUST NOT be included.  Trailing zero
-   octets in the bitmap MUST be omitted.  The length of each block's
-   bitmap is determined by the type code with the largest numerical
-   value within that block, among the set of RR types present at the
-   NSEC RR's owner name.  Trailing zero octets not specified MUST be
-   interpreted as zero octets.
-
-2.1.3.  Inclusion of Wildcard Names in NSEC RDATA
-
-   If a wildcard owner name appears in a zone, the wildcard label ("*")
-   is treated as a literal symbol and is treated the same as any other
-   owner name for purposes of generating NSEC RRs.  Wildcard owner names
-   appear in the Next Domain Name field without any wildcard expansion.
-   RFC 2535 [2] describes the impact of wildcards on authenticated
-   denial of existence.
-
-2.2.  The NSEC RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Next Domain Name field is represented as a domain name.
-
-   The List of Type Bit Map(s) Field is represented as a sequence of RR
-   type mnemonics.  When the mnemonic is not known, the TYPE
-   representation as described in RFC 3597 [4] (section 5) MUST be used.
-
-
-
-
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 4]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-2.3.  NSEC RR Example
-
-   The following NSEC RR identifies the RRsets associated with
-   alfa.example.com. and the next authoritative name after
-   alfa.example.com.
-
-   alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC
-   TYPE1234
-
-   The first four text fields specify the name, TTL, Class, and RR type
-   (NSEC).  The entry host.example.com. is the next authoritative name
-   after alfa.example.com. in canonical order.  The A, MX, RRSIG, NSEC,
-   and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and
-   TYPE1234 RRsets associated with the name alfa.example.com.
-
-   The RDATA section of the NSEC RR above would be encoded as:
-
-      0x04 'h'  'o'  's'  't'
-      0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
-      0x03 'c'  'o'  'm'  0x00
-      0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
-      0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
-      0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
-      0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
-      0x00 0x00 0x00 0x00 0x20
-
-   Assuming that the resolver can authenticate this NSEC record, it
-   could be used to prove that beta.example.com does not exist, or could
-   be used to prove that there is no AAAA record associated with
-   alfa.example.com.  Authenticated denial of existence is discussed in
-   RFC 2535 [2].
-
-3.  IANA Considerations
-
-   This document introduces no new IANA considerations, because all of
-   the protocol parameters used in this document have already been
-   assigned by RFC 3755 [5].
-
-4.  Security Considerations
-
-   The update of the RDATA format and encoding does not affect the
-   security of the use of NSEC RRs.
-
-
-
-
-
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 5]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-5.  References
-
-5.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [3]  Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain
-        Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
-        September 2000.
-
-   [4]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-        Types", RFC 3597, September 2003.
-
-   [5]  Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
-        (DS)", RFC 3755, May 2004.
-
-5.2.  Informative References
-
-   [6]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [7]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [8]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
-        2308, March 1998.
-
-6.  Acknowledgements
-
-   The encoding described in this document was initially proposed by
-   Mark Andrews.  Other encodings where proposed by David Blacka and
-   Michael Graff.
-
-7.  Author's Address
-
-   Jakob Schlyter (editor)
-   NIC-SE
-   Box 5774
-   Stockholm  SE-114 87
-   Sweden
-
-   EMail: jakob@nic.se
-   URI: http://www.nic.se/
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 6]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-8.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the IETF's procedures with respect to rights in IETF Documents can
-   be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 7]
-
diff --git a/doc/rfc/rfc3901.txt b/doc/rfc/rfc3901.txt
deleted file mode 100644
index 43b7356e..00000000
--- a/doc/rfc/rfc3901.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          A. Durand
-Request for Comments: 3901                        SUN Microsystems, Inc.
-BCP: 91                                                         J. Ihren
-Category: Best Current Practice                               Autonomica
-                                                          September 2004
-
-
-               DNS IPv6 Transport Operational Guidelines
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This memo provides guidelines and Best Current Practice for operating
-   DNS in a world where queries and responses are carried in a mixed
-   environment of IPv4 and IPv6 networks.
-
-1.  Introduction to the Problem of Name Space Fragmentation:
-    following the referral chain
-
-   A resolver that tries to look up a name starts out at the root, and
-   follows referrals until it is referred to a name server that is
-   authoritative for the name.  If somewhere down the chain of referrals
-   it is referred to a name server that is only accessible over a
-   transport which the resolver cannot use, the resolver is unable to
-   finish the task.
-
-   When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
-   only a matter of time until this starts to happen.  The complete DNS
-   hierarchy then starts to fragment into a graph where authoritative
-   name servers for certain nodes are only accessible over a certain
-   transport.  The concern is that a resolver using only a particular
-   version of IP and querying information about another node using the
-   same version of IP can not do it because somewhere in the chain of
-   servers accessed during the resolution process, one or more of them
-   will only be accessible with the other version of IP.
-
-   With all DNS data only available over IPv4 transport everything is
-   simple.  IPv4 resolvers can use the intended mechanism of following
-   referrals from the root and down while IPv6 resolvers have to work
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 1]
-
-RFC 3901             DNS IPv6 Transport Guidelines        September 2004
-
-
-   through a "translator", i.e., they have to use a recursive name
-   server on a so-called "dual stack" host as a "forwarder" since they
-   cannot access the DNS data directly.
-
-   With all DNS data only available over IPv6 transport everything would
-   be equally simple, with the exception of IPv4 recursive name servers
-   having to switch to a forwarding configuration.
-
-   However, the second situation will not arise in the foreseeable
-   future.  Instead, the transition will be from IPv4 only to a mixture
-   of IPv4 and IPv6, with three categories of DNS data depending on
-   whether the information is available only over IPv4 transport, only
-   over IPv6 or both.
-
-   Having DNS data available on both transports is the best situation.
-   The major question is how to ensure that it becomes the norm as
-   quickly as possible.  However, while it is obvious that some DNS data
-   will only be available over v4 transport for a long time it is also
-   obvious that it is important to avoid fragmenting the name space
-   available to IPv4 only hosts.  For example, during transition it is
-   not acceptable to break the name space that we presently have
-   available for IPv4-only hosts.
-
-2.  Terminology
-
-   The phrase "IPv4 name server" indicates a name server available over
-   IPv4 transport.  It does not imply anything about what DNS [1,2] data
-   is served.  Likewise, "IPv6 [4,5,6] name server" indicates a name
-   server available over IPv6 transport.  The phrase "dual-stack name
-   server" indicates a name server that is actually configured to run
-   both protocols, IPv4 and IPv6, and not merely a server running on a
-   system capable of running both but actually configured to run only
-   one.
-
-3.  Policy Based Avoidance of Name Space Fragmentation
-
-   Today there are only a few DNS "zones" on the public Internet that
-   are available over IPv6 transport, and most of them can be regarded
-   as "experimental".  However, as soon as the root and top level
-   domains are available over IPv6 transport, it is reasonable to expect
-   that it will become more common to have zones served by IPv6 servers.
-
-   Having those zones served only by IPv6-only name server would not be
-   a good development, since this will fragment the previously
-   unfragmented IPv4 name space and there are strong reasons to find a
-   mechanism to avoid it.
-
-
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 2]
-
-RFC 3901             DNS IPv6 Transport Guidelines        September 2004
-
-
-   The recommended approach to maintain name space continuity is to use
-   administrative policies, as described in the next section.
-
-4.  DNS IPv6 Transport recommended Guidelines
-
-   In order to preserve name space continuity, the following
-   administrative policies are recommended:
-
-      - every recursive name server SHOULD be either IPv4-only or dual
-        stack,
-
-         This rules out IPv6-only recursive servers.  However, one might
-         design configurations where a chain of IPv6-only name server
-         forward queries to a set of dual stack recursive name server
-         actually performing those recursive queries.
-
-      - every DNS zone SHOULD be served by at least one IPv4-reachable
-        authoritative name server.
-
-         This rules out DNS zones served only by IPv6-only authoritative
-         name servers.
-
-   Note: zone validation processes SHOULD ensure that there is at least
-   one IPv4 address record available for the name servers of any child
-   delegations within the zone.
-
-5.  Security Considerations
-
-   The guidelines described in this memo introduce no new security
-   considerations into the DNS protocol or associated operational
-   scenarios.
-
-6.  Acknowledgment
-
-   This document is the result of many conversations that happened in
-   the DNS community at IETF and elsewhere since 2001.  During that
-   period of time, a number of Internet drafts have been published to
-   clarify various aspects of the issues at stake.  This document
-   focuses on the conclusion of those discussions.
-
-   The authors would like to acknowledge the role of Pekka Savola in his
-   thorough review of the document.
-
-
-
-
-
-
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 3]
-
-RFC 3901             DNS IPv6 Transport Guidelines        September 2004
-
-
-7.  Normative References
-
-   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [2]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [3]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
-        9, RFC 2026, October 1996.
-
-   [4]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
-        Specification", RFC 2460, December 1998.
-
-   [5]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
-        Addressing Architecture", RFC 3513, April 2003.
-
-   [6]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
-        Extensions to Support IP Version 6", RFC 3596, October 2003.
-
-8.  Authors' Addresses
-
-   Alain Durand
-   SUN Microsystems, Inc
-   17 Network circle UMPK17-202
-   Menlo Park, CA, 94025
-   USA
-
-   EMail: Alain.Durand@sun.com
-
-
-   Johan Ihren
-   Autonomica
-   Bellmansgatan 30
-   SE-118 47 Stockholm
-   Sweden
-
-   EMail: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 4]
-
-RFC 3901             DNS IPv6 Transport Guidelines        September 2004
-
-
-9.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the IETF's procedures with respect to rights in IETF Documents can
-   be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 5]
-
diff --git a/doc/rfc/rfc4025.txt b/doc/rfc/rfc4025.txt
deleted file mode 100644
index 92e7f400..00000000
--- a/doc/rfc/rfc4025.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      M. Richardson
-Request for Comments: 4025                                           SSW
-Category: Standards Track                                   February 2005
-
-
-           A Method for Storing IPsec Keying Material in DNS
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes a new resource record for the Domain Name
-   System (DNS).  This record may be used to store public keys for use
-   in IP security (IPsec) systems.  The record also includes provisions
-   for indicating what system should be contacted when an IPsec tunnel
-   is established with the entity in question.
-
-   This record replaces the functionality of the sub-type #4 of the KEY
-   Resource Record, which has been obsoleted by RFC 3445.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-       1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  2
-       1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and
-             IP6.ARPA)  . . . . . . . . . . . . . . . . . . . . . . .  3
-       1.3.  Usage Criteria . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Storage Formats  . . . . . . . . . . . . . . . . . . . . . . .  3
-       2.1.  IPSECKEY RDATA Format  . . . . . . . . . . . . . . . . .  3
-       2.2.  RDATA Format - Precedence  . . . . . . . . . . . . . . .  4
-       2.3.  RDATA Format - Gateway Type  . . . . . . . . . . . . . .  4
-       2.4.  RDATA Format - Algorithm Type  . . . . . . . . . . . . .  4
-       2.5.  RDATA Format - Gateway . . . . . . . . . . . . . . . . .  5
-       2.6.  RDATA Format - Public Keys . . . . . . . . . . . . . . .  5
-   3.  Presentation Formats . . . . . . . . . . . . . . . . . . . . .  6
-       3.1.  Representation of IPSECKEY RRs . . . . . . . . . . . . .  6
-       3.2.  Examples . . . . . . . . . . . . . . . . . . . . . . . .  6
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-
-
-
-Richardson                  Standards Track                     [Page 1]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-       4.1.  Active Attacks Against Unsecured IPSECKEY Resource
-             Records  . . . . . . . . . . . . . . . . . . . . . . . .  8
-             4.1.1.  Active Attacks Against IPSECKEY Keying
-                     Materials. . . . . . . . . . . . . . . . . . . .  8
-             4.1.2.  Active Attacks Against IPSECKEY Gateway
-                     Material. . . . . . . . . . . . . . . . . . . .   8
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-       7.1.  Normative References . . . . . . . . . . . . . . . . . . 10
-       7.2.  Informative References . . . . . . . . . . . . . . . . . 10
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12
-
-1.  Introduction
-
-   Suppose a host wishes (or is required by policy) to establish an
-   IPsec tunnel with some remote entity on the network prior to allowing
-   normal communication to take place.  In many cases, this end system
-   will be able to determine the DNS name for the remote entity (either
-   by having the DNS name given explicitly, by performing a DNS PTR
-   query for a particular IP address, or through some other means, e.g.,
-   by extracting the DNS portion of a "user@FQDN" name for a remote
-   entity).  In these cases, the host will need to obtain a public key
-   to authenticate the remote entity, and may also need some guidance
-   about whether it should contact the entity directly or use another
-   node as a gateway to the target entity.  The IPSECKEY RR provides a
-   mechanism for storing such information.
-
-   The type number for the IPSECKEY RR is 45.
-
-   This record replaces the functionality of the sub-type #4 of the KEY
-   Resource Record, which has been obsoleted by RFC 3445 [11].
-
-1.1.  Overview
-
-   The IPSECKEY resource record (RR) is used to publish a public key
-   that is to be associated with a Domain Name System (DNS) [1] name for
-   use with the IPsec protocol suite.  This can be the public key of a
-   host, network, or application (in the case of per-port keying).
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [3].
-
-
-
-
-
-
-
-Richardson                  Standards Track                     [Page 2]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and IP6.ARPA)
-
-   Often a security gateway will only have access to the IP address of
-   the node with which communication is desired and will not know any
-   other name for the target node.  Because of this, frequently the best
-   way of looking up IPSECKEY RRs will be by using the IP address as an
-   index into one of the reverse mapping trees (IN-ADDR.ARPA for IPv4 or
-   IP6.ARPA for IPv6).
-
-   The lookup is done in the fashion usual for PTR records.  The IP
-   address' octets (IPv4) or nibbles (IPv6) are reversed and looked up
-   with the appropriate suffix.  Any CNAMEs or DNAMEs found MUST be
-   followed.
-
-   Note: even when the IPsec function is contained in the end-host,
-   often only the application will know the forward name used.  Although
-   the case where the application knows the forward name is common, the
-   user could easily have typed in a literal IP address.  This storage
-   mechanism does not preclude using the forward name when it is
-   available but does not require it.
-
-1.3.  Usage Criteria
-
-   An IPSECKEY resource record SHOULD be used in combination with DNSSEC
-   [8] unless some other means of authenticating the IPSECKEY resource
-   record is available.
-
-   It is expected that there will often be multiple IPSECKEY resource
-   records at the same name.  This will be due to the presence of
-   multiple gateways and a need to roll over keys.
-
-   This resource record is class independent.
-
-2.  Storage Formats
-
-2.1.  IPSECKEY RDATA Format
-
-   The RDATA for an IPSECKEY RR consists of a precedence value, a
-   gateway type, a public key, algorithm type, and an optional gateway
-   address.
-
-
-
-
-
-
-
-
-
-
-
-Richardson                  Standards Track                     [Page 3]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-       0                   1                   2                   3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |  precedence   | gateway type  |  algorithm  |     gateway     |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
-      ~                            gateway                            ~
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                                                               /
-      /                          public key                           /
-      /                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-2.2.  RDATA Format - Precedence
-
-   This is an 8-bit precedence for this record.  It is interpreted in
-   the same way as the PREFERENCE field described in section 3.3.9 of
-   RFC 1035 [2].
-
-   Gateways listed in IPSECKEY records with lower precedence are to be
-   attempted first.  Where there is a tie in precedence, the order
-   should be non-deterministic.
-
-2.3.  RDATA Format - Gateway Type
-
-   The gateway type field indicates the format of the information that
-   is stored in the gateway field.
-
-   The following values are defined:
-   0  No gateway is present.
-   1  A 4-byte IPv4 address is present.
-   2  A 16-byte IPv6 address is present.
-   3  A wire-encoded domain name is present.  The wire-encoded format is
-      self-describing, so the length is implicit.  The domain name MUST
-      NOT be compressed.  (See Section 3.3 of RFC 1035 [2].)
-
-2.4.  RDATA Format - Algorithm Type
-
-   The algorithm type field identifies the public key's cryptographic
-   algorithm and determines the format of the public key field.
-
-   A value of 0 indicates that no key is present.
-
-   The following values are defined:
-   1  A DSA key is present, in the format defined in RFC 2536 [9].
-   2  A RSA key is present, in the format defined in RFC 3110 [10].
-
-
-
-
-
-
-Richardson                  Standards Track                     [Page 4]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-2.5.  RDATA Format - Gateway
-
-   The gateway field indicates a gateway to which an IPsec tunnel may be
-   created in order to reach the entity named by this resource record.
-
-   There are three formats:
-
-   A 32-bit IPv4 address is present in the gateway field.  The data
-   portion is an IPv4 address as described in section 3.4.1 of RFC 1035
-   [2].  This is a 32-bit number in network byte order.
-
-   A 128-bit IPv6 address is present in the gateway field.  The data
-   portion is an IPv6 address as described in section 2.2 of RFC 3596
-   [12].  This is a 128-bit number in network byte order.
-
-   The gateway field is a normal wire-encoded domain name, as described
-   in section 3.3 of RFC 1035 [2].  Compression MUST NOT be used.
-
-2.6.  RDATA Format - Public Keys
-
-   Both the public key types defined in this document (RSA and DSA)
-   inherit their public key formats from the corresponding KEY RR
-   formats.  Specifically, the public key field contains the
-   algorithm-specific portion of the KEY RR RDATA, which is all the KEY
-   RR DATA after the first four octets.  This is the same portion of the
-   KEY RR that must be specified by documents that define a DNSSEC
-   algorithm.  Those documents also specify a message digest to be used
-   for generation of SIG RRs; that specification is not relevant for
-   IPSECKEY RRs.
-
-   Future algorithms, if they are to be used by both DNSSEC (in the KEY
-   RR) and IPSECKEY, are likely to use the same public key encodings in
-   both records.  Unless otherwise specified, the IPSECKEY public key
-   field will contain the algorithm-specific portion of the KEY RR RDATA
-   for the corresponding algorithm.  The algorithm must still be
-   designated for use by IPSECKEY, and an IPSECKEY algorithm type number
-   (which might be different from the DNSSEC algorithm number) must be
-   assigned to it.
-
-   The DSA key format is defined in RFC 2536 [9]
-
-   The RSA key format is defined in RFC 3110 [10], with the following
-   changes:
-
-   The earlier definition of RSA/MD5 in RFC 2065 [4] limited the
-   exponent and modulus to 2552 bits in length.  RFC 3110 extended that
-   limit to 4096 bits for RSA/SHA1 keys.  The IPSECKEY RR imposes no
-   length limit on RSA public keys, other than the 65535 octet limit
-
-
-
-Richardson                  Standards Track                     [Page 5]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   imposed by the two-octet length encoding.  This length extension is
-   applicable only to IPSECKEY; it is not applicable to KEY RRs.
-
-3.  Presentation Formats
-
-3.1.  Representation of IPSECKEY RRs
-
-   IPSECKEY RRs may appear in a zone data master file.  The precedence,
-   gateway type, algorithm, and gateway fields are REQUIRED.  The base64
-   encoded public key block is OPTIONAL; if it is not present, the
-   public key field of the resource record MUST be construed to be zero
-   octets in length.
-
-   The algorithm field is an unsigned integer.  No mnemonics are
-   defined.
-
-   If no gateway is to be indicated, then the gateway type field MUST be
-   zero, and the gateway field MUST be "."
-
-   The Public Key field is represented as a Base64 encoding of the
-   Public Key.  Whitespace is allowed within the Base64 text.  For a
-   definition of Base64 encoding, see RFC 3548 [6], Section 5.2.
-
-   The general presentation for the record is as follows:
-
-   IN     IPSECKEY ( precedence gateway-type algorithm
-                     gateway base64-encoded-public-key )
-
-3.2.  Examples
-
-   An example of a node, 192.0.2.38, that will accept IPsec tunnels on
-   its own behalf.
-
-   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
-                    192.0.2.38
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-   An example of a node, 192.0.2.38, that has published its key only.
-
-   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 2
-                    .
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-
-
-
-
-
-
-
-
-Richardson                  Standards Track                     [Page 6]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   An example of a node, 192.0.2.38, that has delegated authority to the
-   node 192.0.2.3.
-
-   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
-                    192.0.2.3
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-   An example of a node, 192.0.1.38 that has delegated authority to the
-   node with the identity "mygateway.example.com".
-
-   38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
-                    mygateway.example.com.
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-   An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0, that has
-   delegated authority to the node 2001:0DB8:c000:0200:2::1
-
-   $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.
-   0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 2
-                    2001:0DB8:0:8002::2000:1
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-4.  Security Considerations
-
-   This entire memo pertains to the provision of public keying material
-   for use by key management protocols such as ISAKMP/IKE (RFC 2407)
-   [7].
-
-   The IPSECKEY resource record contains information that SHOULD be
-   communicated to the end client in an integral fashion; i.e., free
-   from modification.  The form of this channel is up to the consumer of
-   the data; there must be a trust relationship between the end consumer
-   of this resource record and the server.  This relationship may be
-   end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another
-   secure source, a secure local channel on the host, or some
-   combination of the above.
-
-   The keying material provided by the IPSECKEY resource record is not
-   sensitive to passive attacks.  The keying material may be freely
-   disclosed to any party without any impact on the security properties
-   of the resulting IPsec session.  IPsec and IKE provide defense
-   against both active and passive attacks.
-
-   Any derivative specification that makes use of this resource record
-   MUST carefully document its trust model and why the trust model of
-   DNSSEC is appropriate, if that is the secure channel used.
-
-
-
-
-
-Richardson                  Standards Track                     [Page 7]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   An active attack on the DNS that caused the wrong IP address to be
-   retrieved (via forged address), and therefore the wrong QNAME to be
-   queried, would also result in a man-in-the-middle attack.  This
-   situation is independent of whether the IPSECKEY RR is used.
-
-4.1.  Active Attacks Against Unsecured IPSECKEY Resource Records
-
-   This section deals with active attacks against the DNS.  These
-   attacks require that DNS requests and responses be intercepted and
-   changed.  DNSSEC is designed to defend against attacks of this kind.
-   This section deals with the situation in which DNSSEC is not
-   available.  This is not the recommended deployment scenario.
-
-4.1.1.  Active Attacks Against IPSECKEY Keying Materials
-
-   The first kind of active attack is when the attacker replaces the
-   keying material with either a key under its control or with garbage.
-
-   The gateway field is either untouched or is null.  The IKE
-   negotiation will therefore occur with the original end-system.  For
-   this attack to succeed, the attacker must perform a man-in-the-middle
-   attack on the IKE negotiation.  This attack requires that the
-   attacker be able to intercept and modify packets on the forwarding
-   path for the IKE and data packets.
-
-   If the attacker is not able to perform this man-in-the-middle attack
-   on the IKE negotiation, then a denial of service will result, as the
-   IKE negotiation will fail.
-
-   If the attacker is not only able to mount active attacks against DNS
-   but also in a position to perform a man-in-the-middle attack on IKE
-   and IPsec negotiations, then the attacker will be able to compromise
-   the resulting IPsec channel.  Note that an attacker must be able to
-   perform active DNS attacks on both sides of the IKE negotiation for
-   this to succeed.
-
-4.1.2.  Active Attacks Against IPSECKEY Gateway Material
-
-   The second kind of active attack is one in which the attacker
-   replaces the gateway address to point to a node under the attacker's
-   control.  The attacker then either replaces the public key or removes
-   it.  If the public key were removed, then the attacker could provide
-   an accurate public key of its own in a second record.
-
-   This second form creates a simple man-in-the-middle attacks since the
-   attacker can then create a second tunnel to the real destination.
-   Note that, as before, this requires that the attacker also mount an
-   active attack against the responder.
-
-
-
-Richardson                  Standards Track                     [Page 8]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   Note that the man-in-the-middle cannot just forward cleartext packets
-   to the original destination.  While the destination may be willing to
-   speak in the clear, replying to the original sender, the sender will
-   already have created a policy expecting ciphertext.  Thus, the
-   attacker will need to intercept traffic in both directions.  In some
-   cases, the attacker may be able to accomplish the full intercept by
-   use of Network Address/Port Translation (NAT/NAPT) technology.
-
-   This attack is easier than the first one because the attacker does
-   NOT need to be on the end-to-end forwarding path.  The attacker need
-   only be able to modify DNS replies.  This can be done by packet
-   modification, by various kinds of race attacks, or through methods
-   that pollute DNS caches.
-
-   If the end-to-end integrity of the IPSECKEY RR is suspect, the end
-   client MUST restrict its use of the IPSECKEY RR to cases where the RR
-   owner name matches the content of the gateway field.  As the RR owner
-   name is assumed when the gateway field is null, a null gateway field
-   is considered a match.
-
-   Thus, any records obtained under unverified conditions (e.g., no
-   DNSSEC or trusted path to source) that have a non-null gateway field
-   MUST be ignored.
-
-   This restriction eliminates attacks against the gateway field, which
-   are considered much easier, as the attack does not need to be on the
-   forwarding path.
-
-   In the case of an IPSECKEY RR with a value of three in its gateway
-   type field, the gateway field contains a domain name.  The subsequent
-   query required to translate that name into an IP address or IPSECKEY
-   RR will also be subject to man-in-the-middle attacks.  If the
-   end-to-end integrity of this second query is suspect, then the
-   provisions above also apply.  The IPSECKEY RR MUST be ignored
-   whenever the resulting gateway does not match the QNAME of the
-   original IPSECKEY RR query.
-
-5.  IANA Considerations
-
-   This document updates the IANA Registry for DNS Resource Record Types
-   by assigning type 45 to the IPSECKEY record.
-
-   This document creates two new IANA registries, both specific to the
-   IPSECKEY Resource Record:
-
-   This document creates an IANA registry for the algorithm type field.
-
-
-
-
-
-Richardson                  Standards Track                     [Page 9]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   Values 0, 1, and 2 are defined in Section 2.4.  Algorithm numbers 3
-   through 255 can be assigned by IETF Consensus (see RFC 2434 [5]).
-
-   This document creates an IANA registry for the gateway type field.
-
-   Values 0, 1, 2, and 3 are defined in Section 2.3.  Gateway type
-   numbers 4 through 255 can be assigned by Standards Action (see RFC
-   2434 [5]).
-
-6.  Acknowledgements
-
-   My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
-   Austein, and Olafur Gudmundsson, who reviewed this document
-   carefully.  Additional thanks to Olafur Gurmundsson for a reference
-   implementation.
-
-7.  References
-
-7.1.  Normative References
-
-   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [2]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]  Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security
-        Extensions", RFC 2065, January 1997.
-
-   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [6]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-        RFC 3548, July 2003.
-
-7.2.  Informative References
-
-   [7]  Piper, D., "The Internet IP Security Domain of Interpretation
-        for ISAKMP", RFC 2407, November 1998.
-
-   [8]  Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [9]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System
-        (DNS)", RFC 2536, March 1999.
-
-
-
-Richardson                  Standards Track                    [Page 10]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   [10] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-        Name System (DNS)", RFC 3110, May 2001.
-
-   [11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
-        Record (RR)", RFC 3445, December 2002.
-
-   [12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
-        Extensions to Support IP Version 6", RFC 3596, October 2003.
-
-Author's Address
-
-   Michael C. Richardson
-   Sandelman Software Works
-   470 Dawson Avenue
-   Ottawa, ON  K1Z 5V7
-   CA
-
-   EMail: mcr@sandelman.ottawa.on.ca
-   URI:   http://www.sandelman.ottawa.on.ca/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson                  Standards Track                    [Page 11]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the IETF's procedures with respect to rights in IETF Documents can
-   be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Richardson                  Standards Track                    [Page 12]
-
diff --git a/doc/rfc/rfc4033.txt b/doc/rfc/rfc4033.txt
deleted file mode 100644
index 7f0a4647..00000000
--- a/doc/rfc/rfc4033.txt
+++ /dev/null
@@ -1,1179 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Arends
-Request for Comments: 4033                          Telematica Instituut
-Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
-           3755, 3757, 3845                                          ISC
-Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
-         3007, 3597, 3226                                       VeriSign
-Category: Standards Track                                      D. Massey
-                                               Colorado State University
-                                                                 S. Rose
-                                                                    NIST
-                                                              March 2005
-
-
-               DNS Security Introduction and Requirements
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   The Domain Name System Security Extensions (DNSSEC) add data origin
-   authentication and data integrity to the Domain Name System.  This
-   document introduces these extensions and describes their capabilities
-   and limitations.  This document also discusses the services that the
-   DNS security extensions do and do not provide.  Last, this document
-   describes the interrelationships between the documents that
-   collectively describe DNSSEC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 1]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
-   2.  Definitions of Important DNSSEC Terms  . . . . . . . . . . .   3
-   3.  Services Provided by DNS Security  . . . . . . . . . . . . .   7
-       3.1.  Data Origin Authentication and Data Integrity  . . . .   7
-       3.2.  Authenticating Name and Type Non-Existence . . . . . .   9
-   4.  Services Not Provided by DNS Security  . . . . . . . . . . .   9
-   5.  Scope of the DNSSEC Document Set and Last Hop Issues . . . .   9
-   6.  Resolver Considerations  . . . . . . . . . . . . . . . . . .  10
-   7.  Stub Resolver Considerations . . . . . . . . . . . . . . . .  11
-   8.  Zone Considerations  . . . . . . . . . . . . . . . . . . . .  12
-       8.1.  TTL Values vs. RRSIG Validity Period . . . . . . . . .  13
-       8.2.  New Temporal Dependency Issues for Zones . . . . . . .  13
-   9.  Name Server Considerations . . . . . . . . . . . . . . . . .  13
-   10. DNS Security Document Family . . . . . . . . . . . . . . . .  14
-   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
-   12. Security Considerations  . . . . . . . . . . . . . . . . . .  15
-   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  17
-   14. References . . . . . . . . . . . . . . . . . . . . . . . . .  17
-       14.1. Normative References . . . . . . . . . . . . . . . . .  17
-       14.2. Informative References . . . . . . . . . . . . . . . .  18
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  20
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  21
-
-1.  Introduction
-
-   This document introduces the Domain Name System Security Extensions
-   (DNSSEC).  This document and its two companion documents ([RFC4034]
-   and [RFC4035]) update, clarify, and refine the security extensions
-   defined in [RFC2535] and its predecessors.  These security extensions
-   consist of a set of new resource record types and modifications to
-   the existing DNS protocol ([RFC1035]).  The new records and protocol
-   modifications are not fully described in this document, but are
-   described in a family of documents outlined in Section 10.  Sections
-   3 and 4 describe the capabilities and limitations of the security
-   extensions in greater detail.  Section 5 discusses the scope of the
-   document set.  Sections 6, 7, 8, and 9 discuss the effect that these
-   security extensions will have on resolvers, stub resolvers, zones,
-   and name servers.
-
-   This document and its two companions obsolete [RFC2535], [RFC3008],
-   [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
-   [RFC3845].  This document set also updates but does not obsolete
-   [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
-   [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
-   DNSSEC.
-
-
-
-
-Arends, et al.              Standards Track                     [Page 2]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   The DNS security extensions provide origin authentication and
-   integrity protection for DNS data, as well as a means of public key
-   distribution.  These extensions do not provide confidentiality.
-
-2.  Definitions of Important DNSSEC Terms
-
-   This section defines a number of terms used in this document set.
-   Because this is intended to be useful as a reference while reading
-   the rest of the document set, first-time readers may wish to skim
-   this section quickly, read the rest of this document, and then come
-   back to this section.
-
-   Authentication Chain: An alternating sequence of DNS public key
-      (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of
-      signed data, with each link in the chain vouching for the next.  A
-      DNSKEY RR is used to verify the signature covering a DS RR and
-      allows the DS RR to be authenticated.  The DS RR contains a hash
-      of another DNSKEY RR and this new DNSKEY RR is authenticated by
-      matching the hash in the DS RR.  This new DNSKEY RR in turn
-      authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in
-      this set may be used to authenticate another DS RR, and so forth
-      until the chain finally ends with a DNSKEY RR whose corresponding
-      private key signs the desired DNS data.  For example, the root
-      DNSKEY RRset can be used to authenticate the DS RRset for
-      "example."  The "example." DS RRset contains a hash that matches
-      some "example." DNSKEY, and this DNSKEY's corresponding private
-      key signs the "example." DNSKEY RRset.  Private key counterparts
-      of the "example." DNSKEY RRset sign data records such as
-      "www.example." and DS RRs for delegations such as
-      "subzone.example."
-
-   Authentication Key: A public key that a security-aware resolver has
-      verified and can therefore use to authenticate data.  A
-      security-aware resolver can obtain authentication keys in three
-      ways.  First, the resolver is generally configured to know about
-      at least one public key; this configured data is usually either
-      the public key itself or a hash of the public key as found in the
-      DS RR (see "trust anchor").  Second, the resolver may use an
-      authenticated public key to verify a DS RR and the DNSKEY RR to
-      which the DS RR refers.  Third, the resolver may be able to
-      determine that a new public key has been signed by the private key
-      corresponding to another public key that the resolver has
-      verified.  Note that the resolver must always be guided by local
-      policy when deciding whether to authenticate a new public key,
-      even if the local policy is simply to authenticate any new public
-      key for which the resolver is able verify the signature.
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 3]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Authoritative RRset: Within the context of a particular zone, an
-      RRset is "authoritative" if and only if the owner name of the
-      RRset lies within the subset of the name space that is at or below
-      the zone apex and at or above the cuts that separate the zone from
-      its children, if any.  All RRsets at the zone apex are
-      authoritative, except for certain RRsets at this domain name that,
-      if present, belong to this zone's parent.  These RRset could
-      include a DS RRset, the NSEC RRset referencing this DS RRset (the
-      "parental NSEC"), and RRSIG RRs associated with these RRsets, all
-      of which are authoritative in the parent zone.  Similarly, if this
-      zone contains any delegation points, only the parental NSEC RRset,
-      DS RRsets, and any RRSIG RRs associated with these RRsets are
-      authoritative for this zone.
-
-   Delegation Point: Term used to describe the name at the parental side
-      of a zone cut.  That is, the delegation point for "foo.example"
-      would be the foo.example node in the "example" zone (as opposed to
-      the zone apex of the "foo.example" zone).  See also zone apex.
-
-   Island of Security: Term used to describe a signed, delegated zone
-      that does not have an authentication chain from its delegating
-      parent.  That is, there is no DS RR containing a hash of a DNSKEY
-      RR for the island in its delegating parent zone (see [RFC4034]).
-      An island of security is served by security-aware name servers and
-      may provide authentication chains to any delegated child zones.
-      Responses from an island of security or its descendents can only
-      be authenticated if its authentication keys can be authenticated
-      by some trusted means out of band from the DNS protocol.
-
-   Key Signing Key (KSK): An authentication key that corresponds to a
-      private key used to sign one or more other authentication keys for
-      a given zone.  Typically, the private key corresponding to a key
-      signing key will sign a zone signing key, which in turn has a
-      corresponding private key that will sign other zone data.  Local
-      policy may require that the zone signing key be changed
-      frequently, while the key signing key may have a longer validity
-      period in order to provide a more stable secure entry point into
-      the zone.  Designating an authentication key as a key signing key
-      is purely an operational issue: DNSSEC validation does not
-      distinguish between key signing keys and other DNSSEC
-      authentication keys, and it is possible to use a single key as
-      both a key signing key and a zone signing key.  Key signing keys
-      are discussed in more detail in [RFC3757].  Also see zone signing
-      key.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 4]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Non-Validating Security-Aware Stub Resolver: A security-aware stub
-      resolver that trusts one or more security-aware recursive name
-      servers to perform most of the tasks discussed in this document
-      set on its behalf.  In particular, a non-validating security-aware
-      stub resolver is an entity that sends DNS queries, receives DNS
-      responses, and is capable of establishing an appropriately secured
-      channel to a security-aware recursive name server that will
-      provide these services on behalf of the security-aware stub
-      resolver.  See also security-aware stub resolver, validating
-      security-aware stub resolver.
-
-   Non-Validating Stub Resolver: A less tedious term for a
-      non-validating security-aware stub resolver.
-
-   Security-Aware Name Server: An entity acting in the role of a name
-      server (defined in section 2.4 of [RFC1034]) that understands the
-      DNS security extensions defined in this document set.  In
-      particular, a security-aware name server is an entity that
-      receives DNS queries, sends DNS responses, supports the EDNS0
-      ([RFC2671]) message size extension and the DO bit ([RFC3225]), and
-      supports the RR types and message header bits defined in this
-      document set.
-
-   Security-Aware Recursive Name Server: An entity that acts in both the
-      security-aware name server and security-aware resolver roles.  A
-      more cumbersome but equivalent phrase would be "a security-aware
-      name server that offers recursive service".
-
-   Security-Aware Resolver: An entity acting in the role of a resolver
-      (defined in section 2.4 of [RFC1034]) that understands the DNS
-      security extensions defined in this document set.  In particular,
-      a security-aware resolver is an entity that sends DNS queries,
-      receives DNS responses, supports the EDNS0 ([RFC2671]) message
-      size extension and the DO bit ([RFC3225]), and is capable of using
-      the RR types and message header bits defined in this document set
-      to provide DNSSEC services.
-
-   Security-Aware Stub Resolver: An entity acting in the role of a stub
-      resolver (defined in section 5.3.1 of [RFC1034]) that has enough
-      of an understanding the DNS security extensions defined in this
-      document set to provide additional services not available from a
-      security-oblivious stub resolver.  Security-aware stub resolvers
-      may be either "validating" or "non-validating", depending on
-      whether the stub resolver attempts to verify DNSSEC signatures on
-      its own or trusts a friendly security-aware name server to do so.
-      See also validating stub resolver, non-validating stub resolver.
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 5]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Security-Oblivious <anything>: An <anything> that is not
-      "security-aware".
-
-   Signed Zone: A zone whose RRsets are signed and that contains
-      properly constructed DNSKEY, Resource Record Signature (RRSIG),
-      Next Secure (NSEC), and (optionally) DS records.
-
-   Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.  A
-      validating security-aware resolver uses this public key or hash as
-      a starting point for building the authentication chain to a signed
-      DNS response.  In general, a validating resolver will have to
-      obtain the initial values of its trust anchors via some secure or
-      trusted means outside the DNS protocol.  Presence of a trust
-      anchor also implies that the resolver should expect the zone to
-      which the trust anchor points to be signed.
-
-   Unsigned Zone: A zone that is not signed.
-
-   Validating Security-Aware Stub Resolver: A security-aware resolver
-      that sends queries in recursive mode but that performs signature
-      validation on its own rather than just blindly trusting an
-      upstream security-aware recursive name server.  See also
-      security-aware stub resolver, non-validating security-aware stub
-      resolver.
-
-   Validating Stub Resolver: A less tedious term for a validating
-      security-aware stub resolver.
-
-   Zone Apex: Term used to describe the name at the child's side of a
-      zone cut.  See also delegation point.
-
-   Zone Signing Key (ZSK): An authentication key that corresponds to a
-      private key used to sign a zone.  Typically, a zone signing key
-      will be part of the same DNSKEY RRset as the key signing key whose
-      corresponding private key signs this DNSKEY RRset, but the zone
-      signing key is used for a slightly different purpose and may
-      differ from the key signing key in other ways, such as validity
-      lifetime.  Designating an authentication key as a zone signing key
-      is purely an operational issue; DNSSEC validation does not
-      distinguish between zone signing keys and other DNSSEC
-      authentication keys, and it is possible to use a single key as
-      both a key signing key and a zone signing key.  See also key
-      signing key.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 6]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-3.  Services Provided by DNS Security
-
-   The Domain Name System (DNS) security extensions provide origin
-   authentication and integrity assurance services for DNS data,
-   including mechanisms for authenticated denial of existence of DNS
-   data.  These mechanisms are described below.
-
-   These mechanisms require changes to the DNS protocol.  DNSSEC adds
-   four new resource record types: Resource Record Signature (RRSIG),
-   DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure
-   (NSEC).  It also adds two new message header bits: Checking Disabled
-   (CD) and Authenticated Data (AD).  In order to support the larger DNS
-   message sizes that result from adding the DNSSEC RRs, DNSSEC also
-   requires EDNS0 support ([RFC2671]).  Finally, DNSSEC requires support
-   for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a
-   security-aware resolver can indicate in its queries that it wishes to
-   receive DNSSEC RRs in response messages.
-
-   These services protect against most of the threats to the Domain Name
-   System described in [RFC3833].  Please see Section 12 for a
-   discussion of the limitations of these extensions.
-
-3.1.  Data Origin Authentication and Data Integrity
-
-   DNSSEC provides authentication by associating cryptographically
-   generated digital signatures with DNS RRsets.  These digital
-   signatures are stored in a new resource record, the RRSIG record.
-   Typically, there will be a single private key that signs a zone's
-   data, but multiple keys are possible.  For example, there may be keys
-   for each of several different digital signature algorithms.  If a
-   security-aware resolver reliably learns a zone's public key, it can
-   authenticate that zone's signed data.  An important DNSSEC concept is
-   that the key that signs a zone's data is associated with the zone
-   itself and not with the zone's authoritative name servers.  (Public
-   keys for DNS transaction authentication mechanisms may also appear in
-   zones, as described in [RFC2931], but DNSSEC itself is concerned with
-   object security of DNS data, not channel security of DNS
-   transactions.  The keys associated with transaction security may be
-   stored in different RR types.  See [RFC3755] for details.)
-
-   A security-aware resolver can learn a zone's public key either by
-   having a trust anchor configured into the resolver or by normal DNS
-   resolution.  To allow the latter, public keys are stored in a new
-   type of resource record, the DNSKEY RR.  Note that the private keys
-   used to sign zone data must be kept secure and should be stored
-   offline when practical.  To discover a public key reliably via DNS
-   resolution, the target key itself has to be signed by either a
-   configured authentication key or another key that has been
-
-
-
-Arends, et al.              Standards Track                     [Page 7]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   authenticated previously.  Security-aware resolvers authenticate zone
-   information by forming an authentication chain from a newly learned
-   public key back to a previously known authentication public key,
-   which in turn either has been configured into the resolver or must
-   have been learned and verified previously.  Therefore, the resolver
-   must be configured with at least one trust anchor.
-
-   If the configured trust anchor is a zone signing key, then it will
-   authenticate the associated zone; if the configured key is a key
-   signing key, it will authenticate a zone signing key.  If the
-   configured trust anchor is the hash of a key rather than the key
-   itself, the resolver may have to obtain the key via a DNS query.  To
-   help security-aware resolvers establish this authentication chain,
-   security-aware name servers attempt to send the signature(s) needed
-   to authenticate a zone's public key(s) in the DNS reply message along
-   with the public key itself, provided that there is space available in
-   the message.
-
-   The Delegation Signer (DS) RR type simplifies some of the
-   administrative tasks involved in signing delegations across
-   organizational boundaries.  The DS RRset resides at a delegation
-   point in a parent zone and indicates the public key(s) corresponding
-   to the private key(s) used to self-sign the DNSKEY RRset at the
-   delegated child zone's apex.  The administrator of the child zone, in
-   turn, uses the private key(s) corresponding to one or more of the
-   public keys in this DNSKEY RRset to sign the child zone's data.  The
-   typical authentication chain is therefore
-   DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
-   DS->DNSKEY subchains.  DNSSEC permits more complex authentication
-   chains, such as additional layers of DNSKEY RRs signing other DNSKEY
-   RRs within a zone.
-
-   A security-aware resolver normally constructs this authentication
-   chain from the root of the DNS hierarchy down to the leaf zones based
-   on configured knowledge of the public key for the root.  Local
-   policy, however, may also allow a security-aware resolver to use one
-   or more configured public keys (or hashes of public keys) other than
-   the root public key, may not provide configured knowledge of the root
-   public key, or may prevent the resolver from using particular public
-   keys for arbitrary reasons, even if those public keys are properly
-   signed with verifiable signatures.  DNSSEC provides mechanisms by
-   which a security-aware resolver can determine whether an RRset's
-   signature is "valid" within the meaning of DNSSEC.  In the final
-   analysis, however, authenticating both DNS keys and data is a matter
-   of local policy, which may extend or even override the protocol
-   extensions defined in this document set.  See Section 5 for further
-   discussion.
-
-
-
-
-Arends, et al.              Standards Track                     [Page 8]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-3.2.  Authenticating Name and Type Non-Existence
-
-   The security mechanism described in Section 3.1 only provides a way
-   to sign existing RRsets in a zone.  The problem of providing negative
-   responses with the same level of authentication and integrity
-   requires the use of another new resource record type, the NSEC
-   record.  The NSEC record allows a security-aware resolver to
-   authenticate a negative reply for either name or type non-existence
-   with the same mechanisms used to authenticate other DNS replies.  Use
-   of NSEC records requires a canonical representation and ordering for
-   domain names in zones.  Chains of NSEC records explicitly describe
-   the gaps, or "empty space", between domain names in a zone and list
-   the types of RRsets present at existing names.  Each NSEC record is
-   signed and authenticated using the mechanisms described in Section
-   3.1.
-
-4.  Services Not Provided by DNS Security
-
-   DNS was originally designed with the assumptions that the DNS will
-   return the same answer to any given query regardless of who may have
-   issued the query, and that all data in the DNS is thus visible.
-   Accordingly, DNSSEC is not designed to provide confidentiality,
-   access control lists, or other means of differentiating between
-   inquirers.
-
-   DNSSEC provides no protection against denial of service attacks.
-   Security-aware resolvers and security-aware name servers are
-   vulnerable to an additional class of denial of service attacks based
-   on cryptographic operations.  Please see Section 12 for details.
-
-   The DNS security extensions provide data and origin authentication
-   for DNS data.  The mechanisms outlined above are not designed to
-   protect operations such as zone transfers and dynamic update
-   ([RFC2136], [RFC3007]).  Message authentication schemes described in
-   [RFC2845] and [RFC2931] address security operations that pertain to
-   these transactions.
-
-5.  Scope of the DNSSEC Document Set and Last Hop Issues
-
-   The specification in this document set defines the behavior for zone
-   signers and security-aware name servers and resolvers in such a way
-   that the validating entities can unambiguously determine the state of
-   the data.
-
-   A validating resolver can determine the following 4 states:
-
-   Secure: The validating resolver has a trust anchor, has a chain of
-      trust, and is able to verify all the signatures in the response.
-
-
-
-Arends, et al.              Standards Track                     [Page 9]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Insecure: The validating resolver has a trust anchor, a chain of
-      trust, and, at some delegation point, signed proof of the
-      non-existence of a DS record.  This indicates that subsequent
-      branches in the tree are provably insecure.  A validating resolver
-      may have a local policy to mark parts of the domain space as
-      insecure.
-
-   Bogus: The validating resolver has a trust anchor and a secure
-      delegation indicating that subsidiary data is signed, but the
-      response fails to validate for some reason: missing signatures,
-      expired signatures, signatures with unsupported algorithms, data
-      missing that the relevant NSEC RR says should be present, and so
-      forth.
-
-   Indeterminate: There is no trust anchor that would indicate that a
-      specific portion of the tree is secure.  This is the default
-      operation mode.
-
-   This specification only defines how security-aware name servers can
-   signal non-validating stub resolvers that data was found to be bogus
-   (using RCODE=2, "Server Failure"; see [RFC4035]).
-
-   There is a mechanism for security-aware name servers to signal
-   security-aware stub resolvers that data was found to be secure (using
-   the AD bit; see [RFC4035]).
-
-   This specification does not define a format for communicating why
-   responses were found to be bogus or marked as insecure.  The current
-   signaling mechanism does not distinguish between indeterminate and
-   insecure states.
-
-   A method for signaling advanced error codes and policy between a
-   security-aware stub resolver and security-aware recursive nameservers
-   is a topic for future work, as is the interface between a security-
-   aware resolver and the applications that use it.  Note, however, that
-   the lack of the specification of such communication does not prohibit
-   deployment of signed zones or the deployment of security aware
-   recursive name servers that prohibit propagation of bogus data to the
-   applications.
-
-6.  Resolver Considerations
-
-   A security-aware resolver has to be able to perform cryptographic
-   functions necessary to verify digital signatures using at least the
-   mandatory-to-implement algorithm(s).  Security-aware resolvers must
-   also be capable of forming an authentication chain from a newly
-   learned zone back to an authentication key, as described above.  This
-   process might require additional queries to intermediate DNS zones to
-
-
-
-Arends, et al.              Standards Track                    [Page 10]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   obtain necessary DNSKEY, DS, and RRSIG records.  A security-aware
-   resolver should be configured with at least one trust anchor as the
-   starting point from which it will attempt to establish authentication
-   chains.
-
-   If a security-aware resolver is separated from the relevant
-   authoritative name servers by a recursive name server or by any sort
-   of intermediary device that acts as a proxy for DNS, and if the
-   recursive name server or intermediary device is not security-aware,
-   the security-aware resolver may not be capable of operating in a
-   secure mode.  For example, if a security-aware resolver's packets are
-   routed through a network address translation (NAT) device that
-   includes a DNS proxy that is not security-aware, the security-aware
-   resolver may find it difficult or impossible to obtain or validate
-   signed DNS data.  The security-aware resolver may have a particularly
-   difficult time obtaining DS RRs in such a case, as DS RRs do not
-   follow the usual DNS rules for ownership of RRs at zone cuts.  Note
-   that this problem is not specific to NATs: any security-oblivious DNS
-   software of any kind between the security-aware resolver and the
-   authoritative name servers will interfere with DNSSEC.
-
-   If a security-aware resolver must rely on an unsigned zone or a name
-   server that is not security aware, the resolver may not be able to
-   validate DNS responses and will need a local policy on whether to
-   accept unverified responses.
-
-   A security-aware resolver should take a signature's validation period
-   into consideration when determining the TTL of data in its cache, to
-   avoid caching signed data beyond the validity period of the
-   signature.  However, it should also allow for the possibility that
-   the security-aware resolver's own clock is wrong.  Thus, a
-   security-aware resolver that is part of a security-aware recursive
-   name server will have to pay careful attention to the DNSSEC
-   "checking disabled" (CD) bit ([RFC4034]).  This is in order to avoid
-   blocking valid signatures from getting through to other
-   security-aware resolvers that are clients of this recursive name
-   server.  See [RFC4035] for how a secure recursive server handles
-   queries with the CD bit set.
-
-7.  Stub Resolver Considerations
-
-   Although not strictly required to do so by the protocol, most DNS
-   queries originate from stub resolvers.  Stub resolvers, by
-   definition, are minimal DNS resolvers that use recursive query mode
-   to offload most of the work of DNS resolution to a recursive name
-   server.  Given the widespread use of stub resolvers, the DNSSEC
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 11]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   architecture has to take stub resolvers into account, but the
-   security features needed in a stub resolver differ in some respects
-   from those needed in a security-aware iterative resolver.
-
-   Even a security-oblivious stub resolver may benefit from DNSSEC if
-   the recursive name servers it uses are security-aware, but for the
-   stub resolver to place any real reliance on DNSSEC services, the stub
-   resolver must trust both the recursive name servers in question and
-   the communication channels between itself and those name servers.
-   The first of these issues is a local policy issue: in essence, a
-   security-oblivious stub resolver has no choice but to place itself at
-   the mercy of the recursive name servers that it uses, as it does not
-   perform DNSSEC validity checks on its own.  The second issue requires
-   some kind of channel security mechanism; proper use of DNS
-   transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
-   TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
-   Particular implementations may have other choices available, such as
-   operating system specific interprocess communication mechanisms.
-   Confidentiality is not needed for this channel, but data integrity
-   and message authentication are.
-
-   A security-aware stub resolver that does trust both its recursive
-   name servers and its communication channel to them may choose to
-   examine the setting of the Authenticated Data (AD) bit in the message
-   header of the response messages it receives.  The stub resolver can
-   use this flag bit as a hint to find out whether the recursive name
-   server was able to validate signatures for all of the data in the
-   Answer and Authority sections of the response.
-
-   There is one more step that a security-aware stub resolver can take
-   if, for whatever reason, it is not able to establish a useful trust
-   relationship with the recursive name servers that it uses: it can
-   perform its own signature validation by setting the Checking Disabled
-   (CD) bit in its query messages.  A validating stub resolver is thus
-   able to treat the DNSSEC signatures as trust relationships between
-   the zone administrators and the stub resolver itself.
-
-8.  Zone Considerations
-
-   There are several differences between signed and unsigned zones.  A
-   signed zone will contain additional security-related records (RRSIG,
-   DNSKEY, DS, and NSEC records).  RRSIG and NSEC records may be
-   generated by a signing process prior to serving the zone.  The RRSIG
-   records that accompany zone data have defined inception and
-   expiration times that establish a validity period for the signatures
-   and the zone data the signatures cover.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 12]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-8.1.  TTL Values vs. RRSIG Validity Period
-
-   It is important to note the distinction between a RRset's TTL value
-   and the signature validity period specified by the RRSIG RR covering
-   that RRset.  DNSSEC does not change the definition or function of the
-   TTL value, which is intended to maintain database coherency in
-   caches.  A caching resolver purges RRsets from its cache no later
-   than the end of the time period specified by the TTL fields of those
-   RRsets, regardless of whether the resolver is security-aware.
-
-   The inception and expiration fields in the RRSIG RR ([RFC4034]), on
-   the other hand, specify the time period during which the signature
-   can be used to validate the covered RRset.  The signatures associated
-   with signed zone data are only valid for the time period specified by
-   these fields in the RRSIG RRs in question.  TTL values cannot extend
-   the validity period of signed RRsets in a resolver's cache, but the
-   resolver may use the time remaining before expiration of the
-   signature validity period of a signed RRset as an upper bound for the
-   TTL of the signed RRset and its associated RRSIG RR in the resolver's
-   cache.
-
-8.2.  New Temporal Dependency Issues for Zones
-
-   Information in a signed zone has a temporal dependency that did not
-   exist in the original DNS protocol.  A signed zone requires regular
-   maintenance to ensure that each RRset in the zone has a current valid
-   RRSIG RR.  The signature validity period of an RRSIG RR is an
-   interval during which the signature for one particular signed RRset
-   can be considered valid, and the signatures of different RRsets in a
-   zone may expire at different times.  Re-signing one or more RRsets in
-   a zone will change one or more RRSIG RRs, which will in turn require
-   incrementing the zone's SOA serial number to indicate that a zone
-   change has occurred and re-signing the SOA RRset itself.  Thus,
-   re-signing any RRset in a zone may also trigger DNS NOTIFY messages
-   and zone transfer operations.
-
-9.  Name Server Considerations
-
-   A security-aware name server should include the appropriate DNSSEC
-   records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries
-   from resolvers that have signaled their willingness to receive such
-   records via use of the DO bit in the EDNS header, subject to message
-   size limitations.  Because inclusion of these DNSSEC RRs could easily
-   cause UDP message truncation and fallback to TCP, a security-aware
-   name server must also support the EDNS "sender's UDP payload"
-   mechanism.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 13]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   If possible, the private half of each DNSSEC key pair should be kept
-   offline, but this will not be possible for a zone for which DNS
-   dynamic update has been enabled.  In the dynamic update case, the
-   primary master server for the zone will have to re-sign the zone when
-   it is updated, so the private key corresponding to the zone signing
-   key will have to be kept online.  This is an example of a situation
-   in which the ability to separate the zone's DNSKEY RRset into zone
-   signing key(s) and key signing key(s) may be useful, as the key
-   signing key(s) in such a case can still be kept offline and may have
-   a longer useful lifetime than the zone signing key(s).
-
-   By itself, DNSSEC is not enough to protect the integrity of an entire
-   zone during zone transfer operations, as even a signed zone contains
-   some unsigned, nonauthoritative data if the zone has any children.
-   Therefore, zone maintenance operations will require some additional
-   mechanisms (most likely some form of channel security, such as TSIG,
-   SIG(0), or IPsec).
-
-10.  DNS Security Document Family
-
-   The DNSSEC document set can be partitioned into several main groups,
-   under the larger umbrella of the DNS base protocol documents.
-
-   The "DNSSEC protocol document set" refers to the three documents that
-   form the core of the DNS security extensions:
-
-   1.  DNS Security Introduction and Requirements (this document)
-
-   2.  Resource Records for DNS Security Extensions [RFC4034]
-
-   3.  Protocol Modifications for the DNS Security Extensions [RFC4035]
-
-   Additionally, any document that would add to or change the core DNS
-   Security extensions would fall into this category.  This includes any
-   future work on the communication between security-aware stub
-   resolvers and upstream security-aware recursive name servers.
-
-   The "Digital Signature Algorithm Specification" document set refers
-   to the group of documents that describe how specific digital
-   signature algorithms should be implemented to fit the DNSSEC resource
-   record format.  Each document in this set deals with a specific
-   digital signature algorithm.  Please see the appendix on "DNSSEC
-   Algorithm and Digest Types" in [RFC4034] for a list of the algorithms
-   that were defined when this core specification was written.
-
-   The "Transaction Authentication Protocol" document set refers to the
-   group of documents that deal with DNS message authentication,
-   including secret key establishment and verification.  Although not
-
-
-
-Arends, et al.              Standards Track                    [Page 14]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   strictly part of the DNSSEC specification as defined in this set of
-   documents, this group is noted because of its relationship to DNSSEC.
-
-   The final document set, "New Security Uses", refers to documents that
-   seek to use proposed DNS Security extensions for other security
-   related purposes.  DNSSEC does not provide any direct security for
-   these new uses but may be used to support them.  Documents that fall
-   in this category include those describing the use of DNS in the
-   storage and distribution of certificates ([RFC2538]).
-
-11.  IANA Considerations
-
-   This overview document introduces no new IANA considerations.  Please
-   see [RFC4034] for a complete review of the IANA considerations
-   introduced by DNSSEC.
-
-12.  Security Considerations
-
-   This document introduces DNS security extensions and describes the
-   document set that contains the new security records and DNS protocol
-   modifications.  The extensions provide data origin authentication and
-   data integrity using digital signatures over resource record sets.
-   This section discusses the limitations of these extensions.
-
-   In order for a security-aware resolver to validate a DNS response,
-   all zones along the path from the trusted starting point to the zone
-   containing the response zones must be signed, and all name servers
-   and resolvers involved in the resolution process must be
-   security-aware, as defined in this document set.  A security-aware
-   resolver cannot verify responses originating from an unsigned zone,
-   from a zone not served by a security-aware name server, or for any
-   DNS data that the resolver is only able to obtain through a recursive
-   name server that is not security-aware.  If there is a break in the
-   authentication chain such that a security-aware resolver cannot
-   obtain and validate the authentication keys it needs, then the
-   security-aware resolver cannot validate the affected DNS data.
-
-   This document briefly discusses other methods of adding security to a
-   DNS query, such as using a channel secured by IPsec or using a DNS
-   transaction authentication mechanism such as TSIG ([RFC2845]) or
-   SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC
-   per se.
-
-   A non-validating security-aware stub resolver, by definition, does
-   not perform DNSSEC signature validation on its own and thus is
-   vulnerable both to attacks on (and by) the security-aware recursive
-   name servers that perform these checks on its behalf and to attacks
-   on its communication with those security-aware recursive name
-
-
-
-Arends, et al.              Standards Track                    [Page 15]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   servers.  Non-validating security-aware stub resolvers should use
-   some form of channel security to defend against the latter threat.
-   The only known defense against the former threat would be for the
-   security-aware stub resolver to perform its own signature validation,
-   at which point, again by definition, it would no longer be a
-   non-validating security-aware stub resolver.
-
-   DNSSEC does not protect against denial of service attacks.  DNSSEC
-   makes DNS vulnerable to a new class of denial of service attacks
-   based on cryptographic operations against security-aware resolvers
-   and security-aware name servers, as an attacker can attempt to use
-   DNSSEC mechanisms to consume a victim's resources.  This class of
-   attacks takes at least two forms.  An attacker may be able to consume
-   resources in a security-aware resolver's signature validation code by
-   tampering with RRSIG RRs in response messages or by constructing
-   needlessly complex signature chains.  An attacker may also be able to
-   consume resources in a security-aware name server that supports DNS
-   dynamic update, by sending a stream of update messages that force the
-   security-aware name server to re-sign some RRsets in the zone more
-   frequently than would otherwise be necessary.
-
-   Due to a deliberate design choice, DNSSEC does not provide
-   confidentiality.
-
-   DNSSEC introduces the ability for a hostile party to enumerate all
-   the names in a zone by following the NSEC chain.  NSEC RRs assert
-   which names do not exist in a zone by linking from existing name to
-   existing name along a canonical ordering of all the names within a
-   zone.  Thus, an attacker can query these NSEC RRs in sequence to
-   obtain all the names in a zone.  Although this is not an attack on
-   the DNS itself, it could allow an attacker to map network hosts or
-   other resources by enumerating the contents of a zone.
-
-   DNSSEC introduces significant additional complexity to the DNS and
-   thus introduces many new opportunities for implementation bugs and
-   misconfigured zones.  In particular, enabling DNSSEC signature
-   validation in a resolver may cause entire legitimate zones to become
-   effectively unreachable due to DNSSEC configuration errors or bugs.
-
-   DNSSEC does not protect against tampering with unsigned zone data.
-   Non-authoritative data at zone cuts (glue and NS RRs in the parent
-   zone) are not signed.  This does not pose a problem when validating
-   the authentication chain, but it does mean that the non-authoritative
-   data itself is vulnerable to tampering during zone transfer
-   operations.  Thus, while DNSSEC can provide data origin
-   authentication and data integrity for RRsets, it cannot do so for
-   zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be
-   used to protect zone transfer operations.
-
-
-
-Arends, et al.              Standards Track                    [Page 16]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Please see [RFC4034] and [RFC4035] for additional security
-   considerations.
-
-13.  Acknowledgements
-
-   This document was created from the input and ideas of the members of
-   the DNS Extensions Working Group.  Although explicitly listing
-   everyone who has contributed during the decade in which DNSSEC has
-   been under development would be impossible, the editors would
-   particularly like to thank the following people for their
-   contributions to and comments on this document set: Jaap Akkerhuis,
-   Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
-   David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
-   Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
-   Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip
-   Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
-   Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
-   Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
-   Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
-   Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
-   Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob
-   Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz,
-   Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler,
-   Brian Wellington, and Suzanne Woolf.
-
-   No doubt the above list is incomplete.  We apologize to anyone we
-   left out.
-
-14.  References
-
-14.1.  Normative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
-              Extensions", RFC 2535, March 1999.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-              2671, August 1999.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-              3225, December 2001.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 17]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
-              message size requirements", RFC 3226, December 2001.
-
-   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
-              Resource Record (RR)", RFC 3445, December 2002.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for DNS Security Extensions", RFC
-              4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-14.2.  Informative References
-
-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
-              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-              RFC 2136, April 1997.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2308, March 1998.
-
-   [RFC2538]  Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates
-              in the Domain Name System (DNS)", RFC 2538, March 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
-              ( SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-              Update", RFC 3007, November 2000.
-
-   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
-              Signing Authority", RFC 3008, November 2000.
-
-   [RFC3090]  Lewis, E., "DNS Security Extension Clarification on Zone
-              Status", RFC 3090, March 2001.
-
-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
-              (RR) Types", RFC 3597, September 2003.
-
-
-
-
-Arends, et al.              Standards Track                    [Page 18]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
-              Authenticated Data (AD) bit", RFC 3655, November 2003.
-
-   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
-              (RR)", RFC 3658, December 2003.
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer (DS)", RFC 3755, May 2004.
-
-   [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
-              System KEY (DNSKEY) Resource Record (RR) Secure Entry
-              Point (SEP) Flag", RFC 3757, April 2004.
-
-   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
-              Name System (DNS)", RFC 3833, August 2004.
-
-   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
-              RDATA Format", RFC 3845, August 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 19]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Brouwerijstraat 1
-   7523 XC  Enschede
-   NL
-
-   EMail: roy.arends@telin.nl
-
-
-   Rob Austein
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   EMail: sra@isc.org
-
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: mlarson@verisign.com
-
-
-   Dan Massey
-   Colorado State University
-   Department of Computer Science
-   Fort Collins, CO 80523-1873
-
-   EMail: massey@cs.colostate.edu
-
-
-   Scott Rose
-   National Institute for Standards and Technology
-   100 Bureau Drive
-   Gaithersburg, MD  20899-8920
-   USA
-
-   EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 20]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 21]
-
diff --git a/doc/rfc/rfc4034.txt b/doc/rfc/rfc4034.txt
deleted file mode 100644
index 6a12c6b8..00000000
--- a/doc/rfc/rfc4034.txt
+++ /dev/null
@@ -1,1627 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Arends
-Request for Comments: 4034                          Telematica Instituut
-Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
-           3755, 3757, 3845                                          ISC
-Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
-         3007, 3597, 3226                                       VeriSign
-Category: Standards Track                                      D. Massey
-                                               Colorado State University
-                                                                 S. Rose
-                                                                    NIST
-                                                              March 2005
-
-
-            Resource Records for the DNS Security Extensions
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document is part of a family of documents that describe the DNS
-   Security Extensions (DNSSEC).  The DNS Security Extensions are a
-   collection of resource records and protocol modifications that
-   provide source authentication for the DNS.  This document defines the
-   public key (DNSKEY), delegation signer (DS), resource record digital
-   signature (RRSIG), and authenticated denial of existence (NSEC)
-   resource records.  The purpose and format of each resource record is
-   described in detail, and an example of each resource record is given.
-
-   This document obsoletes RFC 2535 and incorporates changes from all
-   updates to RFC 2535.
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 1]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-       1.1.  Background and Related Documents . . . . . . . . . . .  3
-       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . .  3
-   2.  The DNSKEY Resource Record . . . . . . . . . . . . . . . . .  4
-       2.1.  DNSKEY RDATA Wire Format . . . . . . . . . . . . . . .  4
-             2.1.1.  The Flags Field. . . . . . . . . . . . . . . .  4
-             2.1.2.  The Protocol Field . . . . . . . . . . . . . .  5
-             2.1.3.  The Algorithm Field. . . . . . . . . . . . . .  5
-             2.1.4.  The Public Key Field . . . . . . . . . . . . .  5
-             2.1.5.  Notes on DNSKEY RDATA Design . . . . . . . . .  5
-       2.2.  The DNSKEY RR Presentation Format. . . . . . . . . . .  5
-       2.3.  DNSKEY RR Example  . . . . . . . . . . . . . . . . . .  6
-   3.  The RRSIG Resource Record  . . . . . . . . . . . . . . . . .  6
-       3.1.  RRSIG RDATA Wire Format. . . . . . . . . . . . . . . .  7
-             3.1.1.  The Type Covered Field . . . . . . . . . . . .  7
-             3.1.2.  The Algorithm Number Field . . . . . . . . . .  8
-             3.1.3.  The Labels Field . . . . . . . . . . . . . . .  8
-             3.1.4.  Original TTL Field . . . . . . . . . . . . . .  8
-             3.1.5.  Signature Expiration and Inception Fields. . .  9
-             3.1.6.  The Key Tag Field. . . . . . . . . . . . . . .  9
-             3.1.7.  The Signer's Name Field. . . . . . . . . . . .  9
-             3.1.8.  The Signature Field. . . . . . . . . . . . . .  9
-       3.2.  The RRSIG RR Presentation Format . . . . . . . . . . . 10
-       3.3.  RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
-   4.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
-       4.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
-             4.1.1.  The Next Domain Name Field . . . . . . . . . . 13
-             4.1.2.  The Type Bit Maps Field. . . . . . . . . . . . 13
-             4.1.3.  Inclusion of Wildcard Names in NSEC RDATA. . . 14
-       4.2.  The NSEC RR Presentation Format. . . . . . . . . . . . 14
-       4.3.  NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
-   5.  The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
-       5.1.  DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
-             5.1.1.  The Key Tag Field. . . . . . . . . . . . . . . 16
-             5.1.2.  The Algorithm Field. . . . . . . . . . . . . . 16
-             5.1.3.  The Digest Type Field. . . . . . . . . . . . . 17
-             5.1.4.  The Digest Field . . . . . . . . . . . . . . . 17
-       5.2.  Processing of DS RRs When Validating Responses . . . . 17
-       5.3.  The DS RR Presentation Format. . . . . . . . . . . . . 17
-       5.4.  DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
-   6.  Canonical Form and Order of Resource Records . . . . . . . . 18
-       6.1.  Canonical DNS Name Order . . . . . . . . . . . . . . . 18
-       6.2.  Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
-       6.3.  Canonical RR Ordering within an RRset. . . . . . . . . 20
-   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
-   8.  Security Considerations. . . . . . . . . . . . . . . . . . . 21
-
-
-
-Arends, et al.              Standards Track                     [Page 2]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
-       10.1. Normative References . . . . . . . . . . . . . . . . . 22
-       10.2. Informative References . . . . . . . . . . . . . . . . 23
-   A.  DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
-       A.1.  DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
-             A.1.1.  Private Algorithm Types. . . . . . . . . . . . 25
-       A.2.  DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
-   B.  Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
-       B.1.  Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29
-
-1.  Introduction
-
-   The DNS Security Extensions (DNSSEC) introduce four new DNS resource
-   record types: DNS Public Key (DNSKEY), Resource Record Signature
-   (RRSIG), Next Secure (NSEC), and Delegation Signer (DS).  This
-   document defines the purpose of each resource record (RR), the RR's
-   RDATA format, and its presentation format (ASCII representation).
-
-1.1.  Background and Related Documents
-
-   This document is part of a family of documents defining DNSSEC, which
-   should be read together as a set.
-
-   [RFC4033] contains an introduction to DNSSEC and definition of common
-   terms; the reader is assumed to be familiar with this document.
-   [RFC4033] also contains a list of other documents updated by and
-   obsoleted by this document set.
-
-   [RFC4035] defines the DNSSEC protocol operations.
-
-   The reader is also assumed to be familiar with the basic DNS concepts
-   described in [RFC1034], [RFC1035], and the subsequent documents that
-   update them, particularly [RFC2181] and [RFC2308].
-
-   This document defines the DNSSEC resource records.  All numeric DNS
-   type codes given in this document are decimal integers.
-
-1.2.  Reserved Words
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 3]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-2.  The DNSKEY Resource Record
-
-   DNSSEC uses public key cryptography to sign and authenticate DNS
-   resource record sets (RRsets).  The public keys are stored in DNSKEY
-   resource records and are used in the DNSSEC authentication process
-   described in [RFC4035]: A zone signs its authoritative RRsets by
-   using a private key and stores the corresponding public key in a
-   DNSKEY RR.  A resolver can then use the public key to validate
-   signatures covering the RRsets in the zone, and thus to authenticate
-   them.
-
-   The DNSKEY RR is not intended as a record for storing arbitrary
-   public keys and MUST NOT be used to store certificates or public keys
-   that do not directly relate to the DNS infrastructure.
-
-   The Type value for the DNSKEY RR type is 48.
-
-   The DNSKEY RR is class independent.
-
-   The DNSKEY RR has no special TTL requirements.
-
-2.1.  DNSKEY RDATA Wire Format
-
-   The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
-   octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
-   Field.
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |              Flags            |    Protocol   |   Algorithm   |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                                                               /
-   /                            Public Key                         /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-2.1.1.  The Flags Field
-
-   Bit 7 of the Flags field is the Zone Key flag.  If bit 7 has value 1,
-   then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's
-   owner name MUST be the name of a zone.  If bit 7 has value 0, then
-   the DNSKEY record holds some other type of DNS public key and MUST
-   NOT be used to verify RRSIGs that cover RRsets.
-
-   Bit 15 of the Flags field is the Secure Entry Point flag, described
-   in [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a
-   key intended for use as a secure entry point.  This flag is only
-
-
-
-Arends, et al.              Standards Track                     [Page 4]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   intended to be a hint to zone signing or debugging software as to the
-   intended use of this DNSKEY record; validators MUST NOT alter their
-   behavior during the signature validation process in any way based on
-   the setting of this bit.  This also means that a DNSKEY RR with the
-   SEP bit set would also need the Zone Key flag set in order to be able
-   to generate signatures legally.  A DNSKEY RR with the SEP set and the
-   Zone Key flag not set MUST NOT be used to verify RRSIGs that cover
-   RRsets.
-
-   Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
-   creation of the DNSKEY RR and MUST be ignored upon receipt.
-
-2.1.2.  The Protocol Field
-
-   The Protocol Field MUST have value 3, and the DNSKEY RR MUST be
-   treated as invalid during signature verification if it is found to be
-   some value other than 3.
-
-2.1.3.  The Algorithm Field
-
-   The Algorithm field identifies the public key's cryptographic
-   algorithm and determines the format of the Public Key field.  A list
-   of DNSSEC algorithm types can be found in Appendix A.1
-
-2.1.4.  The Public Key Field
-
-   The Public Key Field holds the public key material.  The format
-   depends on the algorithm of the key being stored and is described in
-   separate documents.
-
-2.1.5.  Notes on DNSKEY RDATA Design
-
-   Although the Protocol Field always has value 3, it is retained for
-   backward compatibility with early versions of the KEY record.
-
-2.2.  The DNSKEY RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Flag field MUST be represented as an unsigned decimal integer.
-   Given the currently defined flags, the possible values are: 0, 256,
-   and 257.
-
-   The Protocol Field MUST be represented as an unsigned decimal integer
-   with a value of 3.
-
-   The Algorithm field MUST be represented either as an unsigned decimal
-   integer or as an algorithm mnemonic as specified in Appendix A.1.
-
-
-
-Arends, et al.              Standards Track                     [Page 5]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   The Public Key field MUST be represented as a Base64 encoding of the
-   Public Key.  Whitespace is allowed within the Base64 text.  For a
-   definition of Base64 encoding, see [RFC3548].
-
-2.3.  DNSKEY RR Example
-
-   The following DNSKEY RR stores a DNS zone key for example.com.
-
-   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
-                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
-                                          kfzj31GajIQKY+5CptLr3buXA10h
-                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
-                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
-                                          742iU/TpPSEDhm2SNKLijfUppn1U
-                                          aNvv4w==  )
-
-   The first four text fields specify the owner name, TTL, Class, and RR
-   type (DNSKEY).  Value 256 indicates that the Zone Key bit (bit 7) in
-   the Flags field has value 1.  Value 3 is the fixed Protocol value.
-   Value 5 indicates the public key algorithm.  Appendix A.1 identifies
-   algorithm type 5 as RSA/SHA1 and indicates that the format of the
-   RSA/SHA1 public key field is defined in [RFC3110].  The remaining
-   text is a Base64 encoding of the public key.
-
-3.  The RRSIG Resource Record
-
-   DNSSEC uses public key cryptography to sign and authenticate DNS
-   resource record sets (RRsets).  Digital signatures are stored in
-   RRSIG resource records and are used in the DNSSEC authentication
-   process described in [RFC4035].  A validator can use these RRSIG RRs
-   to authenticate RRsets from the zone.  The RRSIG RR MUST only be used
-   to carry verification material (digital signatures) used to secure
-   DNS operations.
-
-   An RRSIG record contains the signature for an RRset with a particular
-   name, class, and type.  The RRSIG RR specifies a validity interval
-   for the signature and uses the Algorithm, the Signer's Name, and the
-   Key Tag to identify the DNSKEY RR containing the public key that a
-   validator can use to verify the signature.
-
-   Because every authoritative RRset in a zone must be protected by a
-   digital signature, RRSIG RRs must be present for names containing a
-   CNAME RR.  This is a change to the traditional DNS specification
-   [RFC1034], which stated that if a CNAME is present for a name, it is
-   the only type allowed at that name.  A RRSIG and NSEC (see Section 4)
-   MUST exist for the same name as a CNAME resource record in a signed
-   zone.
-
-
-
-
-Arends, et al.              Standards Track                     [Page 6]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   The Type value for the RRSIG RR type is 46.
-
-   The RRSIG RR is class independent.
-
-   An RRSIG RR MUST have the same class as the RRset it covers.
-
-   The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
-   covers.  This is an exception to the [RFC2181] rules for TTL values
-   of individual RRs within a RRset: individual RRSIG RRs with the same
-   owner name will have different TTL values if the RRsets they cover
-   have different TTL values.
-
-3.1.  RRSIG RDATA Wire Format
-
-   The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
-   1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
-   TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
-   Inception field, a 2 octet Key tag, the Signer's Name field, and the
-   Signature field.
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |        Type Covered           |  Algorithm    |     Labels    |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                         Original TTL                          |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                      Signature Expiration                     |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                      Signature Inception                      |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |            Key Tag            |                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                                                               /
-   /                            Signature                          /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-3.1.1.  The Type Covered Field
-
-   The Type Covered field identifies the type of the RRset that is
-   covered by this RRSIG record.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 7]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-3.1.2.  The Algorithm Number Field
-
-   The Algorithm Number field identifies the cryptographic algorithm
-   used to create the signature.  A list of DNSSEC algorithm types can
-   be found in Appendix A.1
-
-3.1.3.  The Labels Field
-
-   The Labels field specifies the number of labels in the original RRSIG
-   RR owner name.  The significance of this field is that a validator
-   uses it to determine whether the answer was synthesized from a
-   wildcard.  If so, it can be used to determine what owner name was
-   used in generating the signature.
-
-   To validate a signature, the validator needs the original owner name
-   that was used to create the signature.  If the original owner name
-   contains a wildcard label ("*"), the owner name may have been
-   expanded by the server during the response process, in which case the
-   validator will have to reconstruct the original owner name in order
-   to validate the signature.  [RFC4035] describes how to use the Labels
-   field to reconstruct the original owner name.
-
-   The value of the Labels field MUST NOT count either the null (root)
-   label that terminates the owner name or the wildcard label (if
-   present).  The value of the Labels field MUST be less than or equal
-   to the number of labels in the RRSIG owner name.  For example,
-   "www.example.com." has a Labels field value of 3, and
-   "*.example.com." has a Labels field value of 2.  Root (".") has a
-   Labels field value of 0.
-
-   Although the wildcard label is not included in the count stored in
-   the Labels field of the RRSIG RR, the wildcard label is part of the
-   RRset's owner name when the signature is generated or verified.
-
-3.1.4.  Original TTL Field
-
-   The Original TTL field specifies the TTL of the covered RRset as it
-   appears in the authoritative zone.
-
-   The Original TTL field is necessary because a caching resolver
-   decrements the TTL value of a cached RRset.  In order to validate a
-   signature, a validator requires the original TTL.  [RFC4035]
-   describes how to use the Original TTL field value to reconstruct the
-   original TTL.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 8]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-3.1.5.  Signature Expiration and Inception Fields
-
-   The Signature Expiration and Inception fields specify a validity
-   period for the signature.  The RRSIG record MUST NOT be used for
-   authentication prior to the inception date and MUST NOT be used for
-   authentication after the expiration date.
-
-   The Signature Expiration and Inception field values specify a date
-   and time in the form of a 32-bit unsigned number of seconds elapsed
-   since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
-   byte order.  The longest interval that can be expressed by this
-   format without wrapping is approximately 136 years.  An RRSIG RR can
-   have an Expiration field value that is numerically smaller than the
-   Inception field value if the expiration field value is near the
-   32-bit wrap-around point or if the signature is long lived.  Because
-   of this, all comparisons involving these fields MUST use "Serial
-   number arithmetic", as defined in [RFC1982].  As a direct
-   consequence, the values contained in these fields cannot refer to
-   dates more than 68 years in either the past or the future.
-
-3.1.6.  The Key Tag Field
-
-   The Key Tag field contains the key tag value of the DNSKEY RR that
-   validates this signature, in network byte order.  Appendix B explains
-   how to calculate Key Tag values.
-
-3.1.7.  The Signer's Name Field
-
-   The Signer's Name field value identifies the owner name of the DNSKEY
-   RR that a validator is supposed to use to validate this signature.
-   The Signer's Name field MUST contain the name of the zone of the
-   covered RRset.  A sender MUST NOT use DNS name compression on the
-   Signer's Name field when transmitting a RRSIG RR.
-
-3.1.8.  The Signature Field
-
-   The Signature field contains the cryptographic signature that covers
-   the RRSIG RDATA (excluding the Signature field) and the RRset
-   specified by the RRSIG owner name, RRSIG class, and RRSIG Type
-   Covered field.  The format of this field depends on the algorithm in
-   use, and these formats are described in separate companion documents.
-
-3.1.8.1.  Signature Calculation
-
-   A signature covers the RRSIG RDATA (excluding the Signature Field)
-   and covers the data RRset specified by the RRSIG owner name, RRSIG
-   class, and RRSIG Type Covered fields.  The RRset is in canonical form
-   (see Section 6), and the set RR(1),...RR(n) is signed as follows:
-
-
-
-Arends, et al.              Standards Track                     [Page 9]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-         signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
-
-            "|" denotes concatenation;
-
-            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
-               with the Signer's Name field in canonical form and
-               the Signature field excluded;
-
-            RR(i) = owner | type | class | TTL | RDATA length | RDATA
-
-               "owner" is the fully qualified owner name of the RRset in
-               canonical form (for RRs with wildcard owner names, the
-               wildcard label is included in the owner name);
-
-               Each RR MUST have the same owner name as the RRSIG RR;
-
-               Each RR MUST have the same class as the RRSIG RR;
-
-               Each RR in the RRset MUST have the RR type listed in the
-               RRSIG RR's Type Covered field;
-
-               Each RR in the RRset MUST have the TTL listed in the
-               RRSIG Original TTL Field;
-
-               Any DNS names in the RDATA field of each RR MUST be in
-               canonical form; and
-
-               The RRset MUST be sorted in canonical order.
-
-   See Sections 6.2 and 6.3 for details on canonical form and ordering
-   of RRsets.
-
-3.2.  The RRSIG RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Type Covered field is represented as an RR type mnemonic.  When
-   the mnemonic is not known, the TYPE representation as described in
-   [RFC3597], Section 5, MUST be used.
-
-   The Algorithm field value MUST be represented either as an unsigned
-   decimal integer or as an algorithm mnemonic, as specified in Appendix
-   A.1.
-
-   The Labels field value MUST be represented as an unsigned decimal
-   integer.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 10]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   The Original TTL field value MUST be represented as an unsigned
-   decimal integer.
-
-   The Signature Expiration Time and Inception Time field values MUST be
-   represented either as an unsigned decimal integer indicating seconds
-   since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in
-   UTC, where:
-
-      YYYY is the year (0001-9999, but see Section 3.1.5);
-      MM is the month number (01-12);
-      DD is the day of the month (01-31);
-      HH is the hour, in 24 hour notation (00-23);
-      mm is the minute (00-59); and
-      SS is the second (00-59).
-
-   Note that it is always possible to distinguish between these two
-   formats because the YYYYMMDDHHmmSS format will always be exactly 14
-   digits, while the decimal representation of a 32-bit unsigned integer
-   can never be longer than 10 digits.
-
-   The Key Tag field MUST be represented as an unsigned decimal integer.
-
-   The Signer's Name field value MUST be represented as a domain name.
-
-   The Signature field is represented as a Base64 encoding of the
-   signature.  Whitespace is allowed within the Base64 text.  See
-   Section 2.2.
-
-3.3.  RRSIG RR Example
-
-   The following RRSIG RR stores the signature for the A RRset of
-   host.example.com:
-
-   host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
-                                  20030220173103 2642 example.com.
-                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
-                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
-                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
-                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
-                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
-
-   The first four fields specify the owner name, TTL, Class, and RR type
-   (RRSIG).  The "A" represents the Type Covered field.  The value 5
-   identifies the algorithm used (RSA/SHA1) to create the signature.
-   The value 3 is the number of Labels in the original owner name.  The
-   value 86400 in the RRSIG RDATA is the Original TTL for the covered A
-   RRset.  20030322173103 and 20030220173103 are the expiration and
-
-
-
-
-Arends, et al.              Standards Track                    [Page 11]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   inception dates, respectively.  2642 is the Key Tag, and example.com.
-   is the Signer's Name.  The remaining text is a Base64 encoding of the
-   signature.
-
-   Note that combination of RRSIG RR owner name, class, and Type Covered
-   indicates that this RRSIG covers the "host.example.com" A RRset.  The
-   Label value of 3 indicates that no wildcard expansion was used.  The
-   Algorithm, Signer's Name, and Key Tag indicate that this signature
-   can be authenticated using an example.com zone DNSKEY RR whose
-   algorithm is 5 and whose key tag is 2642.
-
-4.  The NSEC Resource Record
-
-   The NSEC resource record lists two separate things: the next owner
-   name (in the canonical ordering of the zone) that contains
-   authoritative data or a delegation point NS RRset, and the set of RR
-   types present at the NSEC RR's owner name [RFC3845].  The complete
-   set of NSEC RRs in a zone indicates which authoritative RRsets exist
-   in a zone and also form a chain of authoritative owner names in the
-   zone.  This information is used to provide authenticated denial of
-   existence for DNS data, as described in [RFC4035].
-
-   Because every authoritative name in a zone must be part of the NSEC
-   chain, NSEC RRs must be present for names containing a CNAME RR.
-   This is a change to the traditional DNS specification [RFC1034],
-   which stated that if a CNAME is present for a name, it is the only
-   type allowed at that name.  An RRSIG (see Section 3) and NSEC MUST
-   exist for the same name as does a CNAME resource record in a signed
-   zone.
-
-   See [RFC4035] for discussion of how a zone signer determines
-   precisely which NSEC RRs it has to include in a zone.
-
-   The type value for the NSEC RR is 47.
-
-   The NSEC RR is class independent.
-
-   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
-   field.  This is in the spirit of negative caching ([RFC2308]).
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 12]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-4.1.  NSEC RDATA Wire Format
-
-   The RDATA of the NSEC RR is as shown below:
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                      Next Domain Name                         /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                       Type Bit Maps                           /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-4.1.1.  The Next Domain Name Field
-
-   The Next Domain field contains the next owner name (in the canonical
-   ordering of the zone) that has authoritative data or contains a
-   delegation point NS RRset; see Section 6.1 for an explanation of
-   canonical ordering.  The value of the Next Domain Name field in the
-   last NSEC record in the zone is the name of the zone apex (the owner
-   name of the zone's SOA RR).  This indicates that the owner name of
-   the NSEC RR is the last name in the canonical ordering of the zone.
-
-   A sender MUST NOT use DNS name compression on the Next Domain Name
-   field when transmitting an NSEC RR.
-
-   Owner names of RRsets for which the given zone is not authoritative
-   (such as glue records) MUST NOT be listed in the Next Domain Name
-   unless at least one authoritative RRset exists at the same owner
-   name.
-
-4.1.2.  The Type Bit Maps Field
-
-   The Type Bit Maps field identifies the RRset types that exist at the
-   NSEC RR's owner name.
-
-   The RR type space is split into 256 window blocks, each representing
-   the low-order 8 bits of the 16-bit RR type space.  Each block that
-   has at least one active RR type is encoded using a single octet
-   window number (from 0 to 255), a single octet bitmap length (from 1
-   to 32) indicating the number of octets used for the window block's
-   bitmap, and up to 32 octets (256 bits) of bitmap.
-
-   Blocks are present in the NSEC RR RDATA in increasing numerical
-   order.
-
-      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
-
-      where "|" denotes concatenation.
-
-
-
-Arends, et al.              Standards Track                    [Page 13]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   Each bitmap encodes the low-order 8 bits of RR types within the
-   window block, in network bit order.  The first bit is bit 0.  For
-   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
-   to RR type 2 (NS), and so forth.  For window block 1, bit 1
-   corresponds to RR type 257, and bit 2 to RR type 258.  If a bit is
-   set, it indicates that an RRset of that type is present for the NSEC
-   RR's owner name.  If a bit is clear, it indicates that no RRset of
-   that type is present for the NSEC RR's owner name.
-
-   Bits representing pseudo-types MUST be clear, as they do not appear
-   in zone data.  If encountered, they MUST be ignored upon being read.
-
-   Blocks with no types present MUST NOT be included.  Trailing zero
-   octets in the bitmap MUST be omitted.  The length of each block's
-   bitmap is determined by the type code with the largest numerical
-   value, within that block, among the set of RR types present at the
-   NSEC RR's owner name.  Trailing zero octets not specified MUST be
-   interpreted as zero octets.
-
-   The bitmap for the NSEC RR at a delegation point requires special
-   attention.  Bits corresponding to the delegation NS RRset and the RR
-   types for which the parent zone has authoritative data MUST be set;
-   bits corresponding to any non-NS RRset for which the parent is not
-   authoritative MUST be clear.
-
-   A zone MUST NOT include an NSEC RR for any domain name that only
-   holds glue records.
-
-4.1.3.  Inclusion of Wildcard Names in NSEC RDATA
-
-   If a wildcard owner name appears in a zone, the wildcard label ("*")
-   is treated as a literal symbol and is treated the same as any other
-   owner name for the purposes of generating NSEC RRs.  Wildcard owner
-   names appear in the Next Domain Name field without any wildcard
-   expansion.  [RFC4035] describes the impact of wildcards on
-   authenticated denial of existence.
-
-4.2.  The NSEC RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Next Domain Name field is represented as a domain name.
-
-   The Type Bit Maps field is represented as a sequence of RR type
-   mnemonics.  When the mnemonic is not known, the TYPE representation
-   described in [RFC3597], Section 5, MUST be used.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 14]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-4.3.  NSEC RR Example
-
-   The following NSEC RR identifies the RRsets associated with
-   alfa.example.com. and identifies the next authoritative name after
-   alfa.example.com.
-
-   alfa.example.com. 86400 IN NSEC host.example.com. (
-                                   A MX RRSIG NSEC TYPE1234 )
-
-   The first four text fields specify the name, TTL, Class, and RR type
-   (NSEC).  The entry host.example.com. is the next authoritative name
-   after alfa.example.com. in canonical order.  The A, MX, RRSIG, NSEC,
-   and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC,
-   and TYPE1234 RRsets associated with the name alfa.example.com.
-
-   The RDATA section of the NSEC RR above would be encoded as:
-
-            0x04 'h'  'o'  's'  't'
-            0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
-            0x03 'c'  'o'  'm'  0x00
-            0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
-            0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
-            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
-            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
-            0x00 0x00 0x00 0x00 0x20
-
-   Assuming that the validator can authenticate this NSEC record, it
-   could be used to prove that beta.example.com does not exist, or to
-   prove that there is no AAAA record associated with alfa.example.com.
-   Authenticated denial of existence is discussed in [RFC4035].
-
-5.  The DS Resource Record
-
-   The DS Resource Record refers to a DNSKEY RR and is used in the DNS
-   DNSKEY authentication process.  A DS RR refers to a DNSKEY RR by
-   storing the key tag, algorithm number, and a digest of the DNSKEY RR.
-   Note that while the digest should be sufficient to identify the
-   public key, storing the key tag and key algorithm helps make the
-   identification process more efficient.  By authenticating the DS
-   record, a resolver can authenticate the DNSKEY RR to which the DS
-   record points.  The key authentication process is described in
-   [RFC4035].
-
-   The DS RR and its corresponding DNSKEY RR have the same owner name,
-   but they are stored in different locations.  The DS RR appears only
-   on the upper (parental) side of a delegation, and is authoritative
-   data in the parent zone.  For example, the DS RR for "example.com" is
-   stored in the "com" zone (the parent zone) rather than in the
-
-
-
-Arends, et al.              Standards Track                    [Page 15]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   "example.com" zone (the child zone).  The corresponding DNSKEY RR is
-   stored in the "example.com" zone (the child zone).  This simplifies
-   DNS zone management and zone signing but introduces special response
-   processing requirements for the DS RR; these are described in
-   [RFC4035].
-
-   The type number for the DS record is 43.
-
-   The DS resource record is class independent.
-
-   The DS RR has no special TTL requirements.
-
-5.1.  DS RDATA Wire Format
-
-   The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet
-   Algorithm field, a 1 octet Digest Type field, and a Digest field.
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |           Key Tag             |  Algorithm    |  Digest Type  |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                                                               /
-   /                            Digest                             /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-5.1.1.  The Key Tag Field
-
-   The Key Tag field lists the key tag of the DNSKEY RR referred to by
-   the DS record, in network byte order.
-
-   The Key Tag used by the DS RR is identical to the Key Tag used by
-   RRSIG RRs.  Appendix B describes how to compute a Key Tag.
-
-5.1.2.  The Algorithm Field
-
-   The Algorithm field lists the algorithm number of the DNSKEY RR
-   referred to by the DS record.
-
-   The algorithm number used by the DS RR is identical to the algorithm
-   number used by RRSIG and DNSKEY RRs.  Appendix A.1 lists the
-   algorithm number types.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 16]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-5.1.3.  The Digest Type Field
-
-   The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
-   RR.  The Digest Type field identifies the algorithm used to construct
-   the digest.  Appendix A.2 lists the possible digest algorithm types.
-
-5.1.4.  The Digest Field
-
-   The DS record refers to a DNSKEY RR by including a digest of that
-   DNSKEY RR.
-
-   The digest is calculated by concatenating the canonical form of the
-   fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
-   and then applying the digest algorithm.
-
-     digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
-
-      "|" denotes concatenation
-
-     DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
-
-   The size of the digest may vary depending on the digest algorithm and
-   DNSKEY RR size.  As of the time of this writing, the only defined
-   digest algorithm is SHA-1, which produces a 20 octet digest.
-
-5.2.  Processing of DS RRs When Validating Responses
-
-   The DS RR links the authentication chain across zone boundaries, so
-   the DS RR requires extra care in processing.  The DNSKEY RR referred
-   to in the DS RR MUST be a DNSSEC zone key.  The DNSKEY RR Flags MUST
-   have Flags bit 7 set.  If the DNSKEY flags do not indicate a DNSSEC
-   zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be
-   used in the validation process.
-
-5.3.  The DS RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Key Tag field MUST be represented as an unsigned decimal integer.
-
-   The Algorithm field MUST be represented either as an unsigned decimal
-   integer or as an algorithm mnemonic specified in Appendix A.1.
-
-   The Digest Type field MUST be represented as an unsigned decimal
-   integer.
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 17]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   The Digest MUST be represented as a sequence of case-insensitive
-   hexadecimal digits.  Whitespace is allowed within the hexadecimal
-   text.
-
-5.4.  DS RR Example
-
-   The following example shows a DNSKEY RR and its corresponding DS RR.
-
-   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
-                                             fwJr1AYtsmx3TGkJaNXVbfi/
-                                             2pHm822aJ5iI9BMzNXxeYCmZ
-                                             DRD99WYwYqUSdjMmmAphXdvx
-                                             egXd/M5+X7OrzKBaMbCVdFLU
-                                             Uh6DhweJBjEVv5f2wwjM9Xzc
-                                             nOf+EPbtG9DMBmADjFDc2w/r
-                                             ljwvFw==
-                                             ) ;  key id = 60485
-
-   dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
-                                              98631FAD1A292118 )
-
-   The first four text fields specify the name, TTL, Class, and RR type
-   (DS).  Value 60485 is the key tag for the corresponding
-   "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
-   used by this "dskey.example.com." DNSKEY RR.  The value 1 is the
-   algorithm used to construct the digest, and the rest of the RDATA
-   text is the digest in hexadecimal.
-
-6.  Canonical Form and Order of Resource Records
-
-   This section defines a canonical form for resource records, a
-   canonical ordering of DNS names, and a canonical ordering of resource
-   records within an RRset.  A canonical name order is required to
-   construct the NSEC name chain.  A canonical RR form and ordering
-   within an RRset are required in order to construct and verify RRSIG
-   RRs.
-
-6.1.  Canonical DNS Name Order
-
-   For the purposes of DNS security, owner names are ordered by treating
-   individual labels as unsigned left-justified octet strings.  The
-   absence of a octet sorts before a zero value octet, and uppercase
-   US-ASCII letters are treated as if they were lowercase US-ASCII
-   letters.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 18]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   To compute the canonical ordering of a set of DNS names, start by
-   sorting the names according to their most significant (rightmost)
-   labels.  For names in which the most significant label is identical,
-   continue sorting according to their next most significant label, and
-   so forth.
-
-   For example, the following names are sorted in canonical DNS name
-   order.  The most significant label is "example".  At this level,
-   "example" sorts first, followed by names ending in "a.example", then
-   by names ending "z.example".  The names within each level are sorted
-   in the same way.
-
-             example
-             a.example
-             yljkjljk.a.example
-             Z.a.example
-             zABC.a.EXAMPLE
-             z.example
-             \001.z.example
-             *.z.example
-             \200.z.example
-
-6.2.  Canonical RR Form
-
-   For the purposes of DNS security, the canonical form of an RR is the
-   wire format of the RR where:
-
-   1.  every domain name in the RR is fully expanded (no DNS name
-       compression) and fully qualified;
-
-   2.  all uppercase US-ASCII letters in the owner name of the RR are
-       replaced by the corresponding lowercase US-ASCII letters;
-
-   3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
-       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
-       SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
-       the DNS names contained within the RDATA are replaced by the
-       corresponding lowercase US-ASCII letters;
-
-   4.  if the owner name of the RR is a wildcard name, the owner name is
-       in its original unexpanded form, including the "*" label (no
-       wildcard substitution); and
-
-   5.  the RR's TTL is set to its original value as it appears in the
-       originating authoritative zone or the Original TTL field of the
-       covering RRSIG RR.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 19]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-6.3.  Canonical RR Ordering within an RRset
-
-   For the purposes of DNS security, RRs with the same owner name,
-   class, and type are sorted by treating the RDATA portion of the
-   canonical form of each RR as a left-justified unsigned octet sequence
-   in which the absence of an octet sorts before a zero octet.
-
-   [RFC2181] specifies that an RRset is not allowed to contain duplicate
-   records (multiple RRs with the same owner name, class, type, and
-   RDATA).  Therefore, if an implementation detects duplicate RRs when
-   putting the RRset in canonical form, it MUST treat this as a protocol
-   error.  If the implementation chooses to handle this protocol error
-   in the spirit of the robustness principle (being liberal in what it
-   accepts), it MUST remove all but one of the duplicate RR(s) for the
-   purposes of calculating the canonical form of the RRset.
-
-7.  IANA Considerations
-
-   This document introduces no new IANA considerations, as all of the
-   protocol parameters used in this document have already been assigned
-   by previous specifications.  However, since the evolution of DNSSEC
-   has been long and somewhat convoluted, this section attempts to
-   describe the current state of the IANA registries and other protocol
-   parameters that are (or once were) related to DNSSEC.
-
-   Please refer to [RFC4035] for additional IANA considerations.
-
-   DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
-      the SIG, KEY, and NXT RRs, respectively.  [RFC3658] assigned DNS
-      Resource Record Type 43 to DS.  [RFC3755] assigned types 46, 47,
-      and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
-      [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use
-      of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
-      security protocol described in [RFC2931] and to the transaction
-      KEY Resource Record described in [RFC2930].
-
-   DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
-      for DNSSEC Resource Record Algorithm field numbers and assigned
-      values 1-4 and 252-255.  [RFC3110] assigned value 5.  [RFC3755]
-      altered this registry to include flags for each entry regarding
-      its use with the DNS security extensions.  Each algorithm entry
-      could refer to an algorithm that can be used for zone signing,
-      transaction security (see [RFC2931]), or both.  Values 6-251 are
-      available for assignment by IETF standards action ([RFC3755]).
-      See Appendix A for a full listing of the DNS Security Algorithm
-      Numbers entries at the time of this writing and their status for
-      use in DNSSEC.
-
-
-
-
-Arends, et al.              Standards Track                    [Page 20]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-      [RFC3658] created an IANA registry for DNSSEC DS Digest Types and
-      assigned value 0 to reserved and value 1 to SHA-1.
-
-   KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
-      Protocol Values, but [RFC3445] reassigned all values other than 3
-      to reserved and closed this IANA registry.  The registry remains
-      closed, and all KEY and DNSKEY records are required to have a
-      Protocol Octet value of 3.
-
-   Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
-      registry for the DNSSEC KEY and DNSKEY RR flag bits.  Initially,
-      this registry only contains assignments for bit 7 (the ZONE bit)
-      and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]).
-      As stated in [RFC3755], bits 0-6 and 8-14 are available for
-      assignment by IETF Standards Action.
-
-8.  Security Considerations
-
-   This document describes the format of four DNS resource records used
-   by the DNS security extensions and presents an algorithm for
-   calculating a key tag for a public key.  Other than the items
-   described below, the resource records themselves introduce no
-   security considerations.  Please see [RFC4033] and [RFC4035] for
-   additional security considerations related to the use of these
-   records.
-
-   The DS record points to a DNSKEY RR by using a cryptographic digest,
-   the key algorithm type, and a key tag.  The DS record is intended to
-   identify an existing DNSKEY RR, but it is theoretically possible for
-   an attacker to generate a DNSKEY that matches all the DS fields.  The
-   probability of constructing a matching DNSKEY depends on the type of
-   digest algorithm in use.  The only currently defined digest algorithm
-   is SHA-1, and the working group believes that constructing a public
-   key that would match the algorithm, key tag, and SHA-1 digest given
-   in a DS record would be a sufficiently difficult problem that such an
-   attack is not a serious threat at this time.
-
-   The key tag is used to help select DNSKEY resource records
-   efficiently, but it does not uniquely identify a single DNSKEY
-   resource record.  It is possible for two distinct DNSKEY RRs to have
-   the same owner name, the same algorithm type, and the same key tag.
-   An implementation that uses only the key tag to select a DNSKEY RR
-   might select the wrong public key in some circumstances.  Please see
-   Appendix B for further details.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 21]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   The table of algorithms in Appendix A and the key tag calculation
-   algorithms in Appendix B include the RSA/MD5 algorithm for
-   completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as
-   explained in [RFC3110].
-
-9.  Acknowledgements
-
-   This document was created from the input and ideas of the members of
-   the DNS Extensions Working Group and working group mailing list.  The
-   editors would like to express their thanks for the comments and
-   suggestions received during the revision of these security extension
-   specifications.  Although explicitly listing everyone who has
-   contributed during the decade in which DNSSEC has been under
-   development would be impossible, [RFC4033] includes a list of some of
-   the participants who were kind enough to comment on these documents.
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
-              August 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2308, March 1998.
-
-   [RFC2536]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
-              System (DNS)", RFC 2536, March 1999.
-
-   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
-              ( SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC3110]  Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
-              Domain Name System (DNS)", RFC 3110, May 2001.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 22]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
-              Resource Record (RR)", RFC 3445, December 2002.
-
-   [RFC3548]  Josefsson, S., "The Base16, Base32, and Base64 Data
-              Encodings", RFC 3548, July 2003.
-
-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
-              (RR) Types", RFC 3597, September 2003.
-
-   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
-              (RR)", RFC 3658, December 2003.
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer (DS)", RFC 3755, May 2004.
-
-   [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
-              System KEY (DNSKEY) Resource Record (RR) Secure Entry
-              Point (SEP) Flag", RFC 3757, April 2004.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements", RFC
-              4033, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-10.2.  Informative References
-
-   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
-              Extensions", RFC 2535, March 1999.
-
-   [RFC2537]  Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain
-              Name System (DNS)", RFC 2537, March 1999.
-
-   [RFC2539]  Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
-              Domain Name System (DNS)", RFC 2539, March 1999.
-
-   [RFC2930]  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
-              RR)", RFC 2930, September 2000.
-
-   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
-              RDATA Format", RFC 3845, August 2004.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 23]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-Appendix A.  DNSSEC Algorithm and Digest Types
-
-   The DNS security extensions are designed to be independent of the
-   underlying cryptographic algorithms.  The DNSKEY, RRSIG, and DS
-   resource records all use a DNSSEC Algorithm Number to identify the
-   cryptographic algorithm in use by the resource record.  The DS
-   resource record also specifies a Digest Algorithm Number to identify
-   the digest algorithm used to construct the DS record.  The currently
-   defined Algorithm and Digest Types are listed below.  Additional
-   Algorithm or Digest Types could be added as advances in cryptography
-   warrant them.
-
-   A DNSSEC aware resolver or name server MUST implement all MANDATORY
-   algorithms.
-
-A.1.  DNSSEC Algorithm Types
-
-   The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the
-   security algorithm being used.  These values are stored in the
-   "Algorithm number" field in the resource record RDATA.
-
-   Some algorithms are usable only for zone signing (DNSSEC), some only
-   for transaction security mechanisms (SIG(0) and TSIG), and some for
-   both.  Those usable for zone signing may appear in DNSKEY, RRSIG, and
-   DS RRs.  Those usable for transaction security would be present in
-   SIG(0) and KEY RRs, as described in [RFC2931].
-
-                                Zone
-   Value Algorithm [Mnemonic]  Signing  References   Status
-   ----- -------------------- --------- ----------  ---------
-     0   reserved
-     1   RSA/MD5 [RSAMD5]         n      [RFC2537]  NOT RECOMMENDED
-     2   Diffie-Hellman [DH]      n      [RFC2539]   -
-     3   DSA/SHA-1 [DSA]          y      [RFC2536]  OPTIONAL
-     4   Elliptic Curve [ECC]              TBA       -
-     5   RSA/SHA-1 [RSASHA1]      y      [RFC3110]  MANDATORY
-   252   Indirect [INDIRECT]      n                  -
-   253   Private [PRIVATEDNS]     y      see below  OPTIONAL
-   254   Private [PRIVATEOID]     y      see below  OPTIONAL
-   255   reserved
-
-   6 - 251  Available for assignment by IETF Standards Action.
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 24]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-A.1.1.  Private Algorithm Types
-
-   Algorithm number 253 is reserved for private use and will never be
-   assigned to a specific algorithm.  The public key area in the DNSKEY
-   RR and the signature area in the RRSIG RR begin with a wire encoded
-   domain name, which MUST NOT be compressed.  The domain name indicates
-   the private algorithm to use, and the remainder of the public key
-   area is determined by that algorithm.  Entities should only use
-   domain names they control to designate their private algorithms.
-
-   Algorithm number 254 is reserved for private use and will never be
-   assigned to a specific algorithm.  The public key area in the DNSKEY
-   RR and the signature area in the RRSIG RR begin with an unsigned
-   length byte followed by a BER encoded Object Identifier (ISO OID) of
-   that length.  The OID indicates the private algorithm in use, and the
-   remainder of the area is whatever is required by that algorithm.
-   Entities should only use OIDs they control to designate their private
-   algorithms.
-
-A.2.  DNSSEC Digest Types
-
-   A "Digest Type" field in the DS resource record types identifies the
-   cryptographic digest algorithm used by the resource record.  The
-   following table lists the currently defined digest algorithm types.
-
-              VALUE   Algorithm                 STATUS
-                0      Reserved                   -
-                1      SHA-1                   MANDATORY
-              2-255    Unassigned                 -
-
-Appendix B.  Key Tag Calculation
-
-   The Key Tag field in the RRSIG and DS resource record types provides
-   a mechanism for selecting a public key efficiently.  In most cases, a
-   combination of owner name, algorithm, and key tag can efficiently
-   identify a DNSKEY record.  Both the RRSIG and DS resource records
-   have corresponding DNSKEY records.  The Key Tag field in the RRSIG
-   and DS records can be used to help select the corresponding DNSKEY RR
-   efficiently when more than one candidate DNSKEY RR is available.
-
-   However, it is essential to note that the key tag is not a unique
-   identifier.  It is theoretically possible for two distinct DNSKEY RRs
-   to have the same owner name, the same algorithm, and the same key
-   tag.  The key tag is used to limit the possible candidate keys, but
-   it does not uniquely identify a DNSKEY record.  Implementations MUST
-   NOT assume that the key tag uniquely identifies a DNSKEY RR.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 25]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   The key tag is the same for all DNSKEY algorithm types except
-   algorithm 1 (please see Appendix B.1 for the definition of the key
-   tag for algorithm 1).  The key tag algorithm is the sum of the wire
-   format of the DNSKEY RDATA broken into 2 octet groups.  First, the
-   RDATA (in wire format) is treated as a series of 2 octet groups.
-   These groups are then added together, ignoring any carry bits.
-
-   A reference implementation of the key tag algorithm is as an ANSI C
-   function is given below, with the RDATA portion of the DNSKEY RR is
-   used as input.  It is not necessary to use the following reference
-   code verbatim, but the numerical value of the Key Tag MUST be
-   identical to what the reference implementation would generate for the
-   same input.
-
-   Please note that the algorithm for calculating the Key Tag is almost
-   but not completely identical to the familiar ones-complement checksum
-   used in many other Internet protocols.  Key Tags MUST be calculated
-   using the algorithm described here rather than the ones complement
-   checksum.
-
-   The following ANSI C reference implementation calculates the value of
-   a Key Tag.  This reference implementation applies to all algorithm
-   types except algorithm 1 (see Appendix B.1).  The input is the wire
-   format of the RDATA portion of the DNSKEY RR.  The code is written
-   for clarity, not efficiency.
-
-   /*
-    * Assumes that int is at least 16 bits.
-    * First octet of the key tag is the most significant 8 bits of the
-    * return value;
-    * Second octet of the key tag is the least significant 8 bits of the
-    * return value.
-    */
-
-   unsigned int
-   keytag (
-           unsigned char key[],  /* the RDATA part of the DNSKEY RR */
-           unsigned int keysize  /* the RDLENGTH */
-          )
-   {
-           unsigned long ac;     /* assumed to be 32 bits or larger */
-           int i;                /* loop index */
-
-           for ( ac = 0, i = 0; i < keysize; ++i )
-                   ac += (i & 1) ? key[i] : key[i] << 8;
-           ac += (ac >> 16) & 0xFFFF;
-           return ac & 0xFFFF;
-   }
-
-
-
-Arends, et al.              Standards Track                    [Page 26]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-B.1.  Key Tag for Algorithm 1 (RSA/MD5)
-
-   The key tag for algorithm 1 (RSA/MD5) is defined differently from the
-   key tag for all other algorithms, for historical reasons.  For a
-   DNSKEY RR with algorithm 1, the key tag is defined to be the most
-   significant 16 bits of the least significant 24 bits in the public
-   key modulus (in other words, the 4th to last and 3rd to last octets
-   of the public key modulus).
-
-   Please note that Algorithm 1 is NOT RECOMMENDED.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 27]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Brouwerijstraat 1
-   7523 XC  Enschede
-   NL
-
-   EMail: roy.arends@telin.nl
-
-
-   Rob Austein
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   EMail: sra@isc.org
-
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: mlarson@verisign.com
-
-
-   Dan Massey
-   Colorado State University
-   Department of Computer Science
-   Fort Collins, CO 80523-1873
-
-   EMail: massey@cs.colostate.edu
-
-
-   Scott Rose
-   National Institute for Standards and Technology
-   100 Bureau Drive
-   Gaithersburg, MD  20899-8920
-   USA
-
-   EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 28]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 29]
-
diff --git a/doc/rfc/rfc4035.txt b/doc/rfc/rfc4035.txt
deleted file mode 100644
index b701cd2f..00000000
--- a/doc/rfc/rfc4035.txt
+++ /dev/null
@@ -1,2971 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Arends
-Request for Comments: 4035                          Telematica Instituut
-Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
-           3755, 3757, 3845                                          ISC
-Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
-         3007, 3597, 3226                                       VeriSign
-Category: Standards Track                                      D. Massey
-                                               Colorado State University
-                                                                 S. Rose
-                                                                    NIST
-                                                              March 2005
-
-
-         Protocol Modifications for the DNS Security Extensions
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document is part of a family of documents that describe the DNS
-   Security Extensions (DNSSEC).  The DNS Security Extensions are a
-   collection of new resource records and protocol modifications that
-   add data origin authentication and data integrity to the DNS.  This
-   document describes the DNSSEC protocol modifications.  This document
-   defines the concept of a signed zone, along with the requirements for
-   serving and resolving by using DNSSEC.  These techniques allow a
-   security-aware resolver to authenticate both DNS resource records and
-   authoritative DNS error indications.
-
-   This document obsoletes RFC 2535 and incorporates changes from all
-   updates to RFC 2535.
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 1]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-       1.1.  Background and Related Documents . . . . . . . . . . . .  4
-       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . .  4
-       2.1.  Including DNSKEY RRs in a Zone . . . . . . . . . . . . .  5
-       2.2.  Including RRSIG RRs in a Zone  . . . . . . . . . . . . .  5
-       2.3.  Including NSEC RRs in a Zone . . . . . . . . . . . . . .  6
-       2.4.  Including DS RRs in a Zone . . . . . . . . . . . . . . .  7
-       2.5.  Changes to the CNAME Resource Record.  . . . . . . . . .  7
-       2.6.  DNSSEC RR Types Appearing at Zone Cuts.  . . . . . . . .  8
-       2.7.  Example of a Secure Zone . . . . . . . . . . . . . . . .  8
-   3.  Serving  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.  Authoritative Name Servers . . . . . . . . . . . . . . .  9
-             3.1.1.  Including RRSIG RRs in a Response  . . . . . . . 10
-             3.1.2.  Including DNSKEY RRs in a Response . . . . . . . 11
-             3.1.3.  Including NSEC RRs in a Response . . . . . . . . 11
-             3.1.4.  Including DS RRs in a Response . . . . . . . . . 14
-             3.1.5.  Responding to Queries for Type AXFR or IXFR  . . 15
-             3.1.6.  The AD and CD Bits in an Authoritative Response. 16
-       3.2.  Recursive Name Servers . . . . . . . . . . . . . . . . . 17
-             3.2.1.  The DO Bit . . . . . . . . . . . . . . . . . . . 17
-             3.2.2.  The CD Bit . . . . . . . . . . . . . . . . . . . 17
-             3.2.3.  The AD Bit . . . . . . . . . . . . . . . . . . . 18
-       3.3.  Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
-   4.  Resolving  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
-       4.1.  EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
-       4.2.  Signature Verification Support . . . . . . . . . . . . . 19
-       4.3.  Determining Security Status of Data  . . . . . . . . . . 20
-       4.4.  Configured Trust Anchors . . . . . . . . . . . . . . . . 21
-       4.5.  Response Caching . . . . . . . . . . . . . . . . . . . . 21
-       4.6.  Handling of the CD and AD Bits . . . . . . . . . . . . . 22
-       4.7.  Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
-       4.8.  Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
-       4.9.  Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
-             4.9.1.  Handling of the DO Bit . . . . . . . . . . . . . 24
-             4.9.2.  Handling of the CD Bit . . . . . . . . . . . . . 24
-             4.9.3.  Handling of the AD Bit . . . . . . . . . . . . . 24
-   5.  Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
-       5.1.  Special Considerations for Islands of Security . . . . . 26
-       5.2.  Authenticating Referrals . . . . . . . . . . . . . . . . 26
-       5.3.  Authenticating an RRset with an RRSIG RR . . . . . . . . 28
-             5.3.1.  Checking the RRSIG RR Validity . . . . . . . . . 28
-             5.3.2.  Reconstructing the Signed Data . . . . . . . . . 29
-             5.3.3.  Checking the Signature . . . . . . . . . . . . . 31
-             5.3.4.  Authenticating a Wildcard Expanded RRset
-                     Positive Response. . . . . . . . . . . . . . . . 32
-
-
-
-Arends, et al.              Standards Track                     [Page 2]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-       5.4.  Authenticated Denial of Existence  . . . . . . . . . . . 32
-       5.5.  Resolver Behavior When Signatures Do Not Validate  . . . 33
-       5.6.  Authentication Example . . . . . . . . . . . . . . . . . 33
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
-       9.1.  Normative References . . . . . . . . . . . . . . . . . . 34
-       9.2.  Informative References . . . . . . . . . . . . . . . . . 35
-   A.  Signed Zone Example  . . . . . . . . . . . . . . . . . . . . . 36
-   B.  Example Responses  . . . . . . . . . . . . . . . . . . . . . . 41
-       B.1.  Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
-       B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
-       B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 44
-       B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 44
-       B.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 45
-       B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
-       B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
-       B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 48
-   C.  Authentication Examples  . . . . . . . . . . . . . . . . . . . 49
-       C.1.  Authenticating an Answer . . . . . . . . . . . . . . . . 49
-             C.1.1.  Authenticating the Example DNSKEY RR . . . . . . 49
-       C.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
-       C.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 50
-       C.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 50
-       C.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 51
-       C.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
-       C.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
-       C.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 51
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
-
-1.  Introduction
-
-   The DNS Security Extensions (DNSSEC) are a collection of new resource
-   records and protocol modifications that add data origin
-   authentication and data integrity to the DNS.  This document defines
-   the DNSSEC protocol modifications.  Section 2 of this document
-   defines the concept of a signed zone and lists the requirements for
-   zone signing.  Section 3 describes the modifications to authoritative
-   name server behavior necessary for handling signed zones.  Section 4
-   describes the behavior of entities that include security-aware
-   resolver functions.  Finally, Section 5 defines how to use DNSSEC RRs
-   to authenticate a response.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 3]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-1.1.  Background and Related Documents
-
-   This document is part of a family of documents defining DNSSEC that
-   should be read together as a set.
-
-   [RFC4033] contains an introduction to DNSSEC and definitions of
-   common terms; the reader is assumed to be familiar with this
-   document.  [RFC4033] also contains a list of other documents updated
-   by and obsoleted by this document set.
-
-   [RFC4034] defines the DNSSEC resource records.
-
-   The reader is also assumed to be familiar with the basic DNS concepts
-   described in [RFC1034], [RFC1035], and the subsequent documents that
-   update them; particularly, [RFC2181] and [RFC2308].
-
-   This document defines the DNSSEC protocol operations.
-
-1.2.  Reserved Words
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Zone Signing
-
-   DNSSEC introduces the concept of signed zones.  A signed zone
-   includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
-   Next Secure (NSEC), and (optionally) Delegation Signer (DS) records
-   according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4,
-   respectively.  A zone that does not include these records according
-   to the rules in this section is an unsigned zone.
-
-   DNSSEC requires a change to the definition of the CNAME resource
-   record ([RFC1035]).  Section 2.5 changes the CNAME RR to allow RRSIG
-   and NSEC RRs to appear at the same owner name as does a CNAME RR.
-
-   DNSSEC specifies the placement of two new RR types, NSEC and DS,
-   which can be placed at the parental side of a zone cut (that is, at a
-   delegation point).  This is an exception to the general prohibition
-   against putting data in the parent zone at a zone cut.  Section 2.6
-   describes this change.
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 4]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-2.1.  Including DNSKEY RRs in a Zone
-
-   To sign a zone, the zone's administrator generates one or more
-   public/private key pairs and uses the private key(s) to sign
-   authoritative RRsets in the zone.  For each private key used to
-   create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
-   containing the corresponding public key.  A zone key DNSKEY RR MUST
-   have the Zone Key bit of the flags RDATA field set (see Section 2.1.1
-   of [RFC4034]).  Public keys associated with other DNS operations MAY
-   be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT
-   be used to verify RRSIGs.
-
-   If the zone administrator intends a signed zone to be usable other
-   than as an island of security, the zone apex MUST contain at least
-   one DNSKEY RR to act as a secure entry point into the zone.  This
-   secure entry point could then be used as the target of a secure
-   delegation via a corresponding DS RR in the parent zone (see
-   [RFC4034]).
-
-2.2.  Including RRSIG RRs in a Zone
-
-   For each authoritative RRset in a signed zone, there MUST be at least
-   one RRSIG record that meets the following requirements:
-
-   o  The RRSIG owner name is equal to the RRset owner name.
-
-   o  The RRSIG class is equal to the RRset class.
-
-   o  The RRSIG Type Covered field is equal to the RRset type.
-
-   o  The RRSIG Original TTL field is equal to the TTL of the RRset.
-
-   o  The RRSIG RR's TTL is equal to the TTL of the RRset.
-
-   o  The RRSIG Labels field is equal to the number of labels in the
-      RRset owner name, not counting the null root label and not
-      counting the leftmost label if it is a wildcard.
-
-   o  The RRSIG Signer's Name field is equal to the name of the zone
-      containing the RRset.
-
-   o  The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
-      zone key DNSKEY record at the zone apex.
-
-   The process for constructing the RRSIG RR for a given RRset is
-   described in [RFC4034].  An RRset MAY have multiple RRSIG RRs
-   associated with it.  Note that as RRSIG RRs are closely tied to the
-   RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
-
-
-
-Arends, et al.              Standards Track                     [Page 5]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   RR types, do not form RRsets.  In particular, the TTL values among
-   RRSIG RRs with a common owner name do not follow the RRset rules
-   described in [RFC2181].
-
-   An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would
-   add no value and would create an infinite loop in the signing
-   process.
-
-   The NS RRset that appears at the zone apex name MUST be signed, but
-   the NS RRsets that appear at delegation points (that is, the NS
-   RRsets in the parent zone that delegate the name to the child zone's
-   name servers) MUST NOT be signed.  Glue address RRsets associated
-   with delegations MUST NOT be signed.
-
-   There MUST be an RRSIG for each RRset using at least one DNSKEY of
-   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
-   itself MUST be signed by each algorithm appearing in the DS RRset
-   located at the delegating parent (if any).
-
-2.3.  Including NSEC RRs in a Zone
-
-   Each owner name in the zone that has authoritative data or a
-   delegation point NS RRset MUST have an NSEC resource record.  The
-   format of NSEC RRs and the process for constructing the NSEC RR for a
-   given name is described in [RFC4034].
-
-   The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
-   value field in the zone SOA RR.
-
-   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
-   RRset at any particular owner name.  That is, the signing process
-   MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
-   the owner name of any RRset before the zone was signed.  The main
-   reasons for this are a desire for namespace consistency between
-   signed and unsigned versions of the same zone and a desire to reduce
-   the risk of response inconsistency in security oblivious recursive
-   name servers.
-
-   The type bitmap of every NSEC resource record in a signed zone MUST
-   indicate the presence of both the NSEC record itself and its
-   corresponding RRSIG record.
-
-   The difference between the set of owner names that require RRSIG
-   records and the set of owner names that require NSEC records is
-   subtle and worth highlighting.  RRSIG records are present at the
-   owner names of all authoritative RRsets.  NSEC records are present at
-   the owner names of all names for which the signed zone is
-   authoritative and also at the owner names of delegations from the
-
-
-
-Arends, et al.              Standards Track                     [Page 6]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   signed zone to its children.  Neither NSEC nor RRSIG records are
-   present (in the parent zone) at the owner names of glue address
-   RRsets.  Note, however, that this distinction is for the most part
-   visible only during the zone signing process, as NSEC RRsets are
-   authoritative data and are therefore signed.  Thus, any owner name
-   that has an NSEC RRset will have RRSIG RRs as well in the signed
-   zone.
-
-   The bitmap for the NSEC RR at a delegation point requires special
-   attention.  Bits corresponding to the delegation NS RRset and any
-   RRsets for which the parent zone has authoritative data MUST be set;
-   bits corresponding to any non-NS RRset for which the parent is not
-   authoritative MUST be clear.
-
-2.4.  Including DS RRs in a Zone
-
-   The DS resource record establishes authentication chains between DNS
-   zones.  A DS RRset SHOULD be present at a delegation point when the
-   child zone is signed.  The DS RRset MAY contain multiple records,
-   each referencing a public key in the child zone used to verify the
-   RRSIGs in that zone.  All DS RRsets in a zone MUST be signed, and DS
-   RRsets MUST NOT appear at a zone's apex.
-
-   A DS RR SHOULD point to a DNSKEY RR that is present in the child's
-   apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
-   by the corresponding private key.  DS RRs that fail to meet these
-   conditions are not useful for validation, but because the DS RR and
-   its corresponding DNSKEY RR are in different zones, and because the
-   DNS is only loosely consistent, temporary mismatches can occur.
-
-   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
-   (that is, the NS RRset from the same zone containing the DS RRset).
-
-   Construction of a DS RR requires knowledge of the corresponding
-   DNSKEY RR in the child zone, which implies communication between the
-   child and parent zones.  This communication is an operational matter
-   not covered by this document.
-
-2.5.  Changes to the CNAME Resource Record
-
-   If a CNAME RRset is present at a name in a signed zone, appropriate
-   RRSIG and NSEC RRsets are REQUIRED at that name.  A KEY RRset at that
-   name for secure dynamic update purposes is also allowed ([RFC3007]).
-   Other types MUST NOT be present at that name.
-
-   This is a modification to the original CNAME definition given in
-   [RFC1034].  The original definition of the CNAME RR did not allow any
-   other types to coexist with a CNAME record, but a signed zone
-
-
-
-Arends, et al.              Standards Track                     [Page 7]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   requires NSEC and RRSIG RRs for every authoritative name.  To resolve
-   this conflict, this specification modifies the definition of the
-   CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
-
-2.6.  DNSSEC RR Types Appearing at Zone Cuts
-
-   DNSSEC introduced two new RR types that are unusual in that they can
-   appear at the parental side of a zone cut.  At the parental side of a
-   zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
-   the owner name.  A DS RR could also be present if the zone being
-   delegated is signed and seeks to have a chain of authentication to
-   the parent zone.  This is an exception to the original DNS
-   specification ([RFC1034]), which states that only NS RRsets could
-   appear at the parental side of a zone cut.
-
-   This specification updates the original DNS specification to allow
-   NSEC and DS RR types at the parent side of a zone cut.  These RRsets
-   are authoritative for the parent when they appear at the parent side
-   of a zone cut.
-
-2.7.  Example of a Secure Zone
-
-   Appendix A shows a complete example of a small signed zone.
-
-3.  Serving
-
-   This section describes the behavior of entities that include
-   security-aware name server functions.  In many cases such functions
-   will be part of a security-aware recursive name server, but a
-   security-aware authoritative name server has some of the same
-   requirements.  Functions specific to security-aware recursive name
-   servers are described in Section 3.2; functions specific to
-   authoritative servers are described in Section 3.1.
-
-   In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"
-   are as used in [RFC1034].
-
-   A security-aware name server MUST support the EDNS0 ([RFC2671])
-   message size extension, MUST support a message size of at least 1220
-   octets, and SHOULD support a message size of 4000 octets.  As IPv6
-   packets can only be fragmented by the source host, a security aware
-   name server SHOULD take steps to ensure that UDP datagrams it
-   transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
-   MTU, unless the path MTU is known.  Please see [RFC1122], [RFC2460],
-   and [RFC3226] for further discussion of packet size and fragmentation
-   issues.
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 8]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   A security-aware name server that receives a DNS query that does not
-   include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
-   treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
-   MUST NOT perform any of the additional processing described below.
-   Because the DS RR type has the peculiar property of only existing in
-   the parent zone at delegation points, DS RRs always require some
-   special processing, as described in Section 3.1.4.1.
-
-   Security aware name servers that receive explicit queries for
-   security RR types that match the content of more than one zone that
-   it serves (for example, NSEC and RRSIG RRs above and below a
-   delegation point where the server is authoritative for both zones)
-   should behave self-consistently.  As long as the response is always
-   consistent for each query to the name server, the name server MAY
-   return one of the following:
-
-   o  The above-delegation RRsets.
-   o  The below-delegation RRsets.
-   o  Both above and below-delegation RRsets.
-   o  Empty answer section (no records).
-   o  Some other response.
-   o  An error.
-
-   DNSSEC allocates two new bits in the DNS message header: the CD
-   (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit
-   is controlled by resolvers; a security-aware name server MUST copy
-   the CD bit from a query into the corresponding response.  The AD bit
-   is controlled by name servers; a security-aware name server MUST
-   ignore the setting of the AD bit in queries.  See Sections 3.1.6,
-   3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
-
-   A security aware name server that synthesizes CNAME RRs from DNAME
-   RRs as described in [RFC2672] SHOULD NOT generate signatures for the
-   synthesized CNAME RRs.
-
-3.1.  Authoritative Name Servers
-
-   Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT
-   pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name
-   server for a signed zone MUST include additional RRSIG, NSEC, and DS
-   RRs, according to the following rules:
-
-   o  RRSIG RRs that can be used to authenticate a response MUST be
-      included in the response according to the rules in Section 3.1.1.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 9]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   o  NSEC RRs that can be used to provide authenticated denial of
-      existence MUST be included in the response automatically according
-      to the rules in Section 3.1.3.
-
-   o  Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
-      be included in referrals automatically according to the rules in
-      Section 3.1.4.
-
-   These rules only apply to responses where the semantics convey
-   information about the presence or absence of resource records.  That
-   is, these rules are not intended to rule out responses such as RCODE
-   4 ("Not Implemented") or RCODE 5 ("Refused").
-
-   DNSSEC does not change the DNS zone transfer protocol.  Section 3.1.5
-   discusses zone transfer requirements.
-
-3.1.1.  Including RRSIG RRs in a Response
-
-   When responding to a query that has the DO bit set, a security-aware
-   authoritative name server SHOULD attempt to send RRSIG RRs that a
-   security-aware resolver can use to authenticate the RRsets in the
-   response.  A name server SHOULD make every attempt to keep the RRset
-   and its associated RRSIG(s) together in a response.  Inclusion of
-   RRSIG RRs in a response is subject to the following rules:
-
-   o  When placing a signed RRset in the Answer section, the name server
-      MUST also place its RRSIG RRs in the Answer section.  The RRSIG
-      RRs have a higher priority for inclusion than any other RRsets
-      that may have to be included.  If space does not permit inclusion
-      of these RRSIG RRs, the name server MUST set the TC bit.
-
-   o  When placing a signed RRset in the Authority section, the name
-      server MUST also place its RRSIG RRs in the Authority section.
-      The RRSIG RRs have a higher priority for inclusion than any other
-      RRsets that may have to be included.  If space does not permit
-      inclusion of these RRSIG RRs, the name server MUST set the TC bit.
-
-   o  When placing a signed RRset in the Additional section, the name
-      server MUST also place its RRSIG RRs in the Additional section.
-      If space does not permit inclusion of both the RRset and its
-      associated RRSIG RRs, the name server MAY retain the RRset while
-      dropping the RRSIG RRs.  If this happens, the name server MUST NOT
-      set the TC bit solely because these RRSIG RRs didn't fit.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 10]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-3.1.2.  Including DNSKEY RRs in a Response
-
-   When responding to a query that has the DO bit set and that requests
-   the SOA or NS RRs at the apex of a signed zone, a security-aware
-   authoritative name server for that zone MAY return the zone apex
-   DNSKEY RRset in the Additional section.  In this situation, the
-   DNSKEY RRset and associated RRSIG RRs have lower priority than does
-   any other information that would be placed in the additional section.
-   The name server SHOULD NOT include the DNSKEY RRset unless there is
-   enough space in the response message for both the DNSKEY RRset and
-   its associated RRSIG RR(s).  If there is not enough space to include
-   these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
-   NOT set the TC bit solely because these RRs didn't fit (see Section
-   3.1.1).
-
-3.1.3.  Including NSEC RRs in a Response
-
-   When responding to a query that has the DO bit set, a security-aware
-   authoritative name server for a signed zone MUST include NSEC RRs in
-   each of the following cases:
-
-   No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>
-      but does not contain any RRsets that exactly match <SNAME, SCLASS,
-      STYPE>.
-
-   Name Error: The zone does not contain any RRsets that match <SNAME,
-      SCLASS> either exactly or via wildcard name expansion.
-
-   Wildcard Answer: The zone does not contain any RRsets that exactly
-      match <SNAME, SCLASS> but does contain an RRset that matches
-      <SNAME, SCLASS, STYPE> via wildcard name expansion.
-
-   Wildcard No Data: The zone does not contain any RRsets that exactly
-      match <SNAME, SCLASS> and does contain one or more RRsets that
-      match <SNAME, SCLASS> via wildcard name expansion, but does not
-      contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard
-      name expansion.
-
-   In each of these cases, the name server includes NSEC RRs in the
-   response to prove that an exact match for <SNAME, SCLASS, STYPE> was
-   not present in the zone and that the response that the name server is
-   returning is correct given the data in the zone.
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 11]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-3.1.3.1.  Including NSEC RRs: No Data Response
-
-   If the zone contains RRsets matching <SNAME, SCLASS> but contains no
-   RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
-   include the NSEC RR for <SNAME, SCLASS> along with its associated
-   RRSIG RR(s) in the Authority section of the response (see Section
-   3.1.1).  If space does not permit inclusion of the NSEC RR or its
-   associated RRSIG RR(s), the name server MUST set the TC bit (see
-   Section 3.1.1).
-
-   Since the search name exists, wildcard name expansion does not apply
-   to this query, and a single signed NSEC RR suffices to prove that the
-   requested RR type does not exist.
-
-3.1.3.2.  Including NSEC RRs: Name Error Response
-
-   If the zone does not contain any RRsets matching <SNAME, SCLASS>
-   either exactly or via wildcard name expansion, then the name server
-   MUST include the following NSEC RRs in the Authority section, along
-   with their associated RRSIG RRs:
-
-   o  An NSEC RR proving that there is no exact match for <SNAME,
-      SCLASS>.
-
-   o  An NSEC RR proving that the zone contains no RRsets that would
-      match <SNAME, SCLASS> via wildcard name expansion.
-
-   In some cases, a single NSEC RR may prove both of these points.  If
-   it does, the name server SHOULD only include the NSEC RR and its
-   RRSIG RR(s) once in the Authority section.
-
-   If space does not permit inclusion of these NSEC and RRSIG RRs, the
-   name server MUST set the TC bit (see Section 3.1.1).
-
-   The owner names of these NSEC and RRSIG RRs are not subject to
-   wildcard name expansion when these RRs are included in the Authority
-   section of the response.
-
-   Note that this form of response includes cases in which SNAME
-   corresponds to an empty non-terminal name within the zone (a name
-   that is not the owner name for any RRset but that is the parent name
-   of one or more RRsets).
-
-3.1.3.3.  Including NSEC RRs: Wildcard Answer Response
-
-   If the zone does not contain any RRsets that exactly match <SNAME,
-   SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>
-   via wildcard name expansion, the name server MUST include the
-
-
-
-Arends, et al.              Standards Track                    [Page 12]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   wildcard-expanded answer and the corresponding wildcard-expanded
-   RRSIG RRs in the Answer section and MUST include in the Authority
-   section an NSEC RR and associated RRSIG RR(s) proving that the zone
-   does not contain a closer match for <SNAME, SCLASS>.  If space does
-   not permit inclusion of the answer, NSEC and RRSIG RRs, the name
-   server MUST set the TC bit (see Section 3.1.1).
-
-3.1.3.4.  Including NSEC RRs: Wildcard No Data Response
-
-   This case is a combination of the previous cases.  The zone does not
-   contain an exact match for <SNAME, SCLASS>, and although the zone
-   does contain RRsets that match <SNAME, SCLASS> via wildcard
-   expansion, none of those RRsets matches STYPE.  The name server MUST
-   include the following NSEC RRs in the Authority section, along with
-   their associated RRSIG RRs:
-
-   o  An NSEC RR proving that there are no RRsets matching STYPE at the
-      wildcard owner name that matched <SNAME, SCLASS> via wildcard
-      expansion.
-
-   o  An NSEC RR proving that there are no RRsets in the zone that would
-      have been a closer match for <SNAME, SCLASS>.
-
-   In some cases, a single NSEC RR may prove both of these points.  If
-   it does, the name server SHOULD only include the NSEC RR and its
-   RRSIG RR(s) once in the Authority section.
-
-   The owner names of these NSEC and RRSIG RRs are not subject to
-   wildcard name expansion when these RRs are included in the Authority
-   section of the response.
-
-   If space does not permit inclusion of these NSEC and RRSIG RRs, the
-   name server MUST set the TC bit (see Section 3.1.1).
-
-3.1.3.5.  Finding the Right NSEC RRs
-
-   As explained above, there are several situations in which a
-   security-aware authoritative name server has to locate an NSEC RR
-   that proves that no RRsets matching a particular SNAME exist.
-   Locating such an NSEC RR within an authoritative zone is relatively
-   simple, at least in concept.  The following discussion assumes that
-   the name server is authoritative for the zone that would have held
-   the non-existent RRsets matching SNAME.  The algorithm below is
-   written for clarity, not for efficiency.
-
-   To find the NSEC that proves that no RRsets matching name N exist in
-   the zone Z that would have held them, construct a sequence, S,
-   consisting of the owner names of every RRset in Z, sorted into
-
-
-
-Arends, et al.              Standards Track                    [Page 13]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   canonical order ([RFC4034]), with no duplicate names.  Find the name
-   M that would have immediately preceded N in S if any RRsets with
-   owner name N had existed.  M is the owner name of the NSEC RR that
-   proves that no RRsets exist with owner name N.
-
-   The algorithm for finding the NSEC RR that proves that a given name
-   is not covered by any applicable wildcard is similar but requires an
-   extra step.  More precisely, the algorithm for finding the NSEC
-   proving that no RRsets exist with the applicable wildcard name is
-   precisely the same as the algorithm for finding the NSEC RR that
-   proves that RRsets with any other owner name do not exist.  The part
-   that's missing is a method of determining the name of the non-
-   existent applicable wildcard.  In practice, this is easy, because the
-   authoritative name server has already checked for the presence of
-   precisely this wildcard name as part of step (1)(c) of the normal
-   lookup algorithm described in Section 4.3.2 of [RFC1034].
-
-3.1.4.  Including DS RRs in a Response
-
-   When responding to a query that has the DO bit set, a security-aware
-   authoritative name server returning a referral includes DNSSEC data
-   along with the NS RRset.
-
-   If a DS RRset is present at the delegation point, the name server
-   MUST return both the DS RRset and its associated RRSIG RR(s) in the
-   Authority section along with the NS RRset.
-
-   If no DS RRset is present at the delegation point, the name server
-   MUST return both the NSEC RR that proves that the DS RRset is not
-   present and the NSEC RR's associated RRSIG RR(s) along with the NS
-   RRset.  The name server MUST place the NS RRset before the NSEC RRset
-   and its associated RRSIG RR(s).
-
-   Including these DS, NSEC, and RRSIG RRs increases the size of
-   referral messages and may cause some or all glue RRs to be omitted.
-   If space does not permit inclusion of the DS or NSEC RRset and
-   associated RRSIG RRs, the name server MUST set the TC bit (see
-   Section 3.1.1).
-
-3.1.4.1.  Responding to Queries for DS RRs
-
-   The DS resource record type is unusual in that it appears only on the
-   parent zone's side of a zone cut.  For example, the DS RRset for the
-   delegation of "foo.example" is stored in the "example" zone rather
-   than in the "foo.example" zone.  This requires special processing
-   rules for both name servers and resolvers, as the name server for the
-   child zone is authoritative for the name at the zone cut by the
-   normal DNS rules but the child zone does not contain the DS RRset.
-
-
-
-Arends, et al.              Standards Track                    [Page 14]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   A security-aware resolver sends queries to the parent zone when
-   looking for a needed DS RR at a delegation point (see Section 4.2).
-   However, special rules are necessary to avoid confusing
-   security-oblivious resolvers which might become involved in
-   processing such a query (for example, in a network configuration that
-   forces a security-aware resolver to channel its queries through a
-   security-oblivious recursive name server).  The rest of this section
-   describes how a security-aware name server processes DS queries in
-   order to avoid this problem.
-
-   The need for special processing by a security-aware name server only
-   arises when all the following conditions are met:
-
-   o  The name server has received a query for the DS RRset at a zone
-      cut.
-
-   o  The name server is authoritative for the child zone.
-
-   o  The name server is not authoritative for the parent zone.
-
-   o  The name server does not offer recursion.
-
-   In all other cases, the name server either has some way of obtaining
-   the DS RRset or could not have been expected to have the DS RRset
-   even by the pre-DNSSEC processing rules, so the name server can
-   return either the DS RRset or an error response according to the
-   normal processing rules.
-
-   If all the above conditions are met, however, the name server is
-   authoritative for SNAME but cannot supply the requested RRset.  In
-   this case, the name server MUST return an authoritative "no data"
-   response showing that the DS RRset does not exist in the child zone's
-   apex.  See Appendix B.8 for an example of such a response.
-
-3.1.5.  Responding to Queries for Type AXFR or IXFR
-
-   DNSSEC does not change the DNS zone transfer process.  A signed zone
-   will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
-   records have no special meaning with respect to a zone transfer
-   operation.
-
-   An authoritative name server is not required to verify that a zone is
-   properly signed before sending or accepting a zone transfer.
-   However, an authoritative name server MAY choose to reject the entire
-   zone transfer if the zone fails to meet any of the signing
-   requirements described in Section 2.  The primary objective of a zone
-   transfer is to ensure that all authoritative name servers have
-   identical copies of the zone.  An authoritative name server that
-
-
-
-Arends, et al.              Standards Track                    [Page 15]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   chooses to perform its own zone validation MUST NOT selectively
-   reject some RRs and accept others.
-
-   DS RRsets appear only on the parental side of a zone cut and are
-   authoritative data in the parent zone.  As with any other
-   authoritative RRset, the DS RRset MUST be included in zone transfers
-   of the zone in which the RRset is authoritative data.  In the case of
-   the DS RRset, this is the parent zone.
-
-   NSEC RRs appear in both the parent and child zones at a zone cut and
-   are authoritative data in both the parent and child zones.  The
-   parental and child NSEC RRs at a zone cut are never identical to each
-   other, as the NSEC RR in the child zone's apex will always indicate
-   the presence of the child zone's SOA RR whereas the parental NSEC RR
-   at the zone cut will never indicate the presence of an SOA RR.  As
-   with any other authoritative RRs, NSEC RRs MUST be included in zone
-   transfers of the zone in which they are authoritative data.  The
-   parental NSEC RR at a zone cut MUST be included in zone transfers of
-   the parent zone, and the NSEC at the zone apex of the child zone MUST
-   be included in zone transfers of the child zone.
-
-   RRSIG RRs appear in both the parent and child zones at a zone cut and
-   are authoritative in whichever zone contains the authoritative RRset
-   for which the RRSIG RR provides the signature.  That is, the RRSIG RR
-   for a DS RRset or a parental NSEC RR at a zone cut will be
-   authoritative in the parent zone, and the RRSIG for any RRset in the
-   child zone's apex will be authoritative in the child zone.  Parental
-   and child RRSIG RRs at a zone cut will never be identical to each
-   other, as the Signer's Name field of an RRSIG RR in the child zone's
-   apex will indicate a DNSKEY RR in the child zone's apex whereas the
-   same field of a parental RRSIG RR at the zone cut will indicate a
-   DNSKEY RR in the parent zone's apex.  As with any other authoritative
-   RRs, RRSIG RRs MUST be included in zone transfers of the zone in
-   which they are authoritative data.
-
-3.1.6.  The AD and CD Bits in an Authoritative Response
-
-   The CD and AD bits are designed for use in communication between
-   security-aware resolvers and security-aware recursive name servers.
-   These bits are for the most part not relevant to query processing by
-   security-aware authoritative name servers.
-
-   A security-aware name server does not perform signature validation
-   for authoritative data during query processing, even when the CD bit
-   is clear.  A security-aware name server SHOULD clear the CD bit when
-   composing an authoritative response.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 16]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   A security-aware name server MUST NOT set the AD bit in a response
-   unless the name server considers all RRsets in the Answer and
-   Authority sections of the response to be authentic.  A security-aware
-   name server's local policy MAY consider data from an authoritative
-   zone to be authentic without further validation.  However, the name
-   server MUST NOT do so unless the name server obtained the
-   authoritative zone via secure means (such as a secure zone transfer
-   mechanism) and MUST NOT do so unless this behavior has been
-   configured explicitly.
-
-   A security-aware name server that supports recursion MUST follow the
-   rules for the CD and AD bits given in Section 3.2 when generating a
-   response that involves data obtained via recursion.
-
-3.2.  Recursive Name Servers
-
-   As explained in [RFC4033], a security-aware recursive name server is
-   an entity that acts in both the security-aware name server and
-   security-aware resolver roles.  This section uses the terms "name
-   server side" and "resolver side" to refer to the code within a
-   security-aware recursive name server that implements the
-   security-aware name server role and the code that implements the
-   security-aware resolver role, respectively.
-
-   The resolver side follows the usual rules for caching and negative
-   caching that would apply to any security-aware resolver.
-
-3.2.1.  The DO Bit
-
-   The resolver side of a security-aware recursive name server MUST set
-   the DO bit when sending requests, regardless of the state of the DO
-   bit in the initiating request received by the name server side.  If
-   the DO bit in an initiating query is not set, the name server side
-   MUST strip any authenticating DNSSEC RRs from the response but MUST
-   NOT strip any DNSSEC RR types that the initiating query explicitly
-   requested.
-
-3.2.2.  The CD Bit
-
-   The CD bit exists in order to allow a security-aware resolver to
-   disable signature validation in a security-aware name server's
-   processing of a particular query.
-
-   The name server side MUST copy the setting of the CD bit from a query
-   to the corresponding response.
-
-   The name server side of a security-aware recursive name server MUST
-   pass the state of the CD bit to the resolver side along with the rest
-
-
-
-Arends, et al.              Standards Track                    [Page 17]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   of an initiating query, so that the resolver side will know whether
-   it is required to verify the response data it returns to the name
-   server side.  If the CD bit is set, it indicates that the originating
-   resolver is willing to perform whatever authentication its local
-   policy requires.  Thus, the resolver side of the recursive name
-   server need not perform authentication on the RRsets in the response.
-   When the CD bit is set, the recursive name server SHOULD, if
-   possible, return the requested data to the originating resolver, even
-   if the recursive name server's local authentication policy would
-   reject the records in question.  That is, by setting the CD bit, the
-   originating resolver has indicated that it takes responsibility for
-   performing its own authentication, and the recursive name server
-   should not interfere.
-
-   If the resolver side implements a BAD cache (see Section 4.7) and the
-   name server side receives a query that matches an entry in the
-   resolver side's BAD cache, the name server side's response depends on
-   the state of the CD bit in the original query.  If the CD bit is set,
-   the name server side SHOULD return the data from the BAD cache; if
-   the CD bit is not set, the name server side MUST return RCODE 2
-   (server failure).
-
-   The intent of the above rule is to provide the raw data to clients
-   that are capable of performing their own signature verification
-   checks while protecting clients that depend on the resolver side of a
-   security-aware recursive name server to perform such checks.  Several
-   of the possible reasons why signature validation might fail involve
-   conditions that may not apply equally to the recursive name server
-   and the client that invoked it.  For example, the recursive name
-   server's clock may be set incorrectly, or the client may have
-   knowledge of a relevant island of security that the recursive name
-   server does not share.  In such cases, "protecting" a client that is
-   capable of performing its own signature validation from ever seeing
-   the "bad" data does not help the client.
-
-3.2.3.  The AD Bit
-
-   The name server side of a security-aware recursive name server MUST
-   NOT set the AD bit in a response unless the name server considers all
-   RRsets in the Answer and Authority sections of the response to be
-   authentic.  The name server side SHOULD set the AD bit if and only if
-   the resolver side considers all RRsets in the Answer section and any
-   relevant negative response RRs in the Authority section to be
-   authentic.  The resolver side MUST follow the procedure described in
-   Section 5 to determine whether the RRs in question are authentic.
-   However, for backward compatibility, a recursive name server MAY set
-   the AD bit when a response includes unsigned CNAME RRs if those CNAME
-
-
-
-
-Arends, et al.              Standards Track                    [Page 18]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   RRs demonstrably could have been synthesized from an authentic DNAME
-   RR that is also included in the response according to the synthesis
-   rules described in [RFC2672].
-
-3.3.  Example DNSSEC Responses
-
-   See Appendix B for example response packets.
-
-4.  Resolving
-
-   This section describes the behavior of entities that include
-   security-aware resolver functions.  In many cases such functions will
-   be part of a security-aware recursive name server, but a stand-alone
-   security-aware resolver has many of the same requirements.  Functions
-   specific to security-aware recursive name servers are described in
-   Section 3.2.
-
-4.1.  EDNS Support
-
-   A security-aware resolver MUST include an EDNS ([RFC2671]) OPT
-   pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
-
-   A security-aware resolver MUST support a message size of at least
-   1220 octets, SHOULD support a message size of 4000 octets, and MUST
-   use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
-   to advertise the message size that it is willing to accept.  A
-   security-aware resolver's IP layer MUST handle fragmented UDP packets
-   correctly regardless of whether any such fragmented packets were
-   received via IPv4 or IPv6.  Please see [RFC1122], [RFC2460], and
-   [RFC3226] for discussion of these requirements.
-
-4.2.  Signature Verification Support
-
-   A security-aware resolver MUST support the signature verification
-   mechanisms described in Section 5 and SHOULD apply them to every
-   received response, except when:
-
-   o  the security-aware resolver is part of a security-aware recursive
-      name server, and the response is the result of recursion on behalf
-      of a query received with the CD bit set;
-
-   o  the response is the result of a query generated directly via some
-      form of application interface that instructed the security-aware
-      resolver not to perform validation for this query; or
-
-   o  validation for this query has been disabled by local policy.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 19]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   A security-aware resolver's support for signature verification MUST
-   include support for verification of wildcard owner names.
-
-   Security-aware resolvers MAY query for missing security RRs in an
-   attempt to perform validation; implementations that choose to do so
-   must be aware that the answers received may not be sufficient to
-   validate the original response.  For example, a zone update may have
-   changed (or deleted) the desired information between the original and
-   follow-up queries.
-
-   When attempting to retrieve missing NSEC RRs that reside on the
-   parental side at a zone cut, a security-aware iterative-mode resolver
-   MUST query the name servers for the parent zone, not the child zone.
-
-   When attempting to retrieve a missing DS, a security-aware
-   iterative-mode resolver MUST query the name servers for the parent
-   zone, not the child zone.  As explained in Section 3.1.4.1,
-   security-aware name servers need to apply special processing rules to
-   handle the DS RR, and in some situations the resolver may also need
-   to apply special rules to locate the name servers for the parent zone
-   if the resolver does not already have the parent's NS RRset.  To
-   locate the parent NS RRset, the resolver can start with the
-   delegation name, strip off the leftmost label, and query for an NS
-   RRset by that name.  If no NS RRset is present at that name, the
-   resolver then strips off the leftmost remaining label and retries the
-   query for that name, repeating this process of walking up the tree
-   until it either finds the NS RRset or runs out of labels.
-
-4.3.  Determining Security Status of Data
-
-   A security-aware resolver MUST be able to determine whether it should
-   expect a particular RRset to be signed.  More precisely, a
-   security-aware resolver must be able to distinguish between four
-   cases:
-
-   Secure: An RRset for which the resolver is able to build a chain of
-      signed DNSKEY and DS RRs from a trusted security anchor to the
-      RRset.  In this case, the RRset should be signed and is subject to
-      signature validation, as described above.
-
-   Insecure: An RRset for which the resolver knows that it has no chain
-      of signed DNSKEY and DS RRs from any trusted starting point to the
-      RRset.  This can occur when the target RRset lies in an unsigned
-      zone or in a descendent of an unsigned zone.  In this case, the
-      RRset may or may not be signed, but the resolver will not be able
-      to verify the signature.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 20]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   Bogus: An RRset for which the resolver believes that it ought to be
-      able to establish a chain of trust but for which it is unable to
-      do so, either due to signatures that for some reason fail to
-      validate or due to missing data that the relevant DNSSEC RRs
-      indicate should be present.  This case may indicate an attack but
-      may also indicate a configuration error or some form of data
-      corruption.
-
-   Indeterminate: An RRset for which the resolver is not able to
-      determine whether the RRset should be signed, as the resolver is
-      not able to obtain the necessary DNSSEC RRs.  This can occur when
-      the security-aware resolver is not able to contact security-aware
-      name servers for the relevant zones.
-
-4.4.  Configured Trust Anchors
-
-   A security-aware resolver MUST be capable of being configured with at
-   least one trusted public key or DS RR and SHOULD be capable of being
-   configured with multiple trusted public keys or DS RRs.  Since a
-   security-aware resolver will not be able to validate signatures
-   without such a configured trust anchor, the resolver SHOULD have some
-   reasonably robust mechanism for obtaining such keys when it boots;
-   examples of such a mechanism would be some form of non-volatile
-   storage (such as a disk drive) or some form of trusted local network
-   configuration mechanism.
-
-   Note that trust anchors also cover key material that is updated in a
-   secure manner.  This secure manner could be through physical media, a
-   key exchange protocol, or some other out-of-band means.
-
-4.5.  Response Caching
-
-   A security-aware resolver SHOULD cache each response as a single
-   atomic entry containing the entire answer, including the named RRset
-   and any associated DNSSEC RRs.  The resolver SHOULD discard the
-   entire atomic entry when any of the RRs contained in it expire.  In
-   most cases the appropriate cache index for the atomic entry will be
-   the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
-   form described in Section 3.1.3.2 the appropriate cache index will be
-   the double <QNAME,QCLASS>.
-
-   The reason for these recommendations is that, between the initial
-   query and the expiration of the data from the cache, the
-   authoritative data might have been changed (for example, via dynamic
-   update).
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 21]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   There are two situations for which this is relevant:
-
-   1.  By using the RRSIG record, it is possible to deduce that an
-       answer was synthesized from a wildcard.  A security-aware
-       recursive name server could store this wildcard data and use it
-       to generate positive responses to queries other than the name for
-       which the original answer was first received.
-
-   2.  NSEC RRs received to prove the non-existence of a name could be
-       reused by a security-aware resolver to prove the non-existence of
-       any name in the name range it spans.
-
-   In theory, a resolver could use wildcards or NSEC RRs to generate
-   positive and negative responses (respectively) until the TTL or
-   signatures on the records in question expire.  However, it seems
-   prudent for resolvers to avoid blocking new authoritative data or
-   synthesizing new data on their own.  Resolvers that follow this
-   recommendation will have a more consistent view of the namespace.
-
-4.6.  Handling of the CD and AD Bits
-
-   A security-aware resolver MAY set a query's CD bit in order to
-   indicate that the resolver takes responsibility for performing
-   whatever authentication its local policy requires on the RRsets in
-   the response.  See Section 3.2 for the effect this bit has on the
-   behavior of security-aware recursive name servers.
-
-   A security-aware resolver MUST clear the AD bit when composing query
-   messages to protect against buggy name servers that blindly copy
-   header bits that they do not understand from the query message to the
-   response message.
-
-   A resolver MUST disregard the meaning of the CD and AD bits in a
-   response unless the response was obtained by using a secure channel
-   or the resolver was specifically configured to regard the message
-   header bits without using a secure channel.
-
-4.7.  Caching BAD Data
-
-   While many validation errors will be transient, some are likely to be
-   more persistent, such as those caused by administrative error
-   (failure to re-sign a zone, clock skew, and so forth).  Since
-   requerying will not help in these cases, validating resolvers might
-   generate a significant amount of unnecessary DNS traffic as a result
-   of repeated queries for RRsets with persistent validation failures.
-
-   To prevent such unnecessary DNS traffic, security-aware resolvers MAY
-   cache data with invalid signatures, with some restrictions.
-
-
-
-Arends, et al.              Standards Track                    [Page 22]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   Conceptually, caching such data is similar to negative caching
-   ([RFC2308]), except that instead of caching a valid negative
-   response, the resolver is caching the fact that a particular answer
-   failed to validate.  This document refers to a cache of data with
-   invalid signatures as a "BAD cache".
-
-   Resolvers that implement a BAD cache MUST take steps to prevent the
-   cache from being useful as a denial-of-service attack amplifier,
-   particularly the following:
-
-   o  Since RRsets that fail to validate do not have trustworthy TTLs,
-      the implementation MUST assign a TTL.  This TTL SHOULD be small,
-      in order to mitigate the effect of caching the results of an
-      attack.
-
-   o  In order to prevent caching of a transient validation failure
-      (which might be the result of an attack), resolvers SHOULD track
-      queries that result in validation failures and SHOULD only answer
-      from the BAD cache after the number of times that responses to
-      queries for that particular <QNAME, QTYPE, QCLASS> have failed to
-      validate exceeds a threshold value.
-
-   Resolvers MUST NOT return RRsets from the BAD cache unless the
-   resolver is not required to validate the signatures of the RRsets in
-   question under the rules given in Section 4.2 of this document.  See
-   Section 3.2.2 for discussion of how the responses returned by a
-   security-aware recursive name server interact with a BAD cache.
-
-4.8.  Synthesized CNAMEs
-
-   A validating security-aware resolver MUST treat the signature of a
-   valid signed DNAME RR as also covering unsigned CNAME RRs that could
-   have been synthesized from the DNAME RR, as described in [RFC2672],
-   at least to the extent of not rejecting a response message solely
-   because it contains such CNAME RRs.  The resolver MAY retain such
-   CNAME RRs in its cache or in the answers it hands back, but is not
-   required to do so.
-
-4.9.  Stub Resolvers
-
-   A security-aware stub resolver MUST support the DNSSEC RR types, at
-   least to the extent of not mishandling responses just because they
-   contain DNSSEC RRs.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 23]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-4.9.1.  Handling of the DO Bit
-
-   A non-validating security-aware stub resolver MAY include the DNSSEC
-   RRs returned by a security-aware recursive name server as part of the
-   data that the stub resolver hands back to the application that
-   invoked it, but is not required to do so.  A non-validating stub
-   resolver that seeks to do this will need to set the DO bit in order
-   to receive DNSSEC RRs from the recursive name server.
-
-   A validating security-aware stub resolver MUST set the DO bit,
-   because otherwise it will not receive the DNSSEC RRs it needs to
-   perform signature validation.
-
-4.9.2.  Handling of the CD Bit
-
-   A non-validating security-aware stub resolver SHOULD NOT set the CD
-   bit when sending queries unless it is requested by the application
-   layer, as by definition, a non-validating stub resolver depends on
-   the security-aware recursive name server to perform validation on its
-   behalf.
-
-   A validating security-aware stub resolver SHOULD set the CD bit,
-   because otherwise the security-aware recursive name server will
-   answer the query using the name server's local policy, which may
-   prevent the stub resolver from receiving data that would be
-   acceptable to the stub resolver's local policy.
-
-4.9.3.  Handling of the AD Bit
-
-   A non-validating security-aware stub resolver MAY chose to examine
-   the setting of the AD bit in response messages that it receives in
-   order to determine whether the security-aware recursive name server
-   that sent the response claims to have cryptographically verified the
-   data in the Answer and Authority sections of the response message.
-   Note, however, that the responses received by a security-aware stub
-   resolver are heavily dependent on the local policy of the
-   security-aware recursive name server.  Therefore, there may be little
-   practical value in checking the status of the AD bit, except perhaps
-   as a debugging aid.  In any case, a security-aware stub resolver MUST
-   NOT place any reliance on signature validation allegedly performed on
-   its behalf, except when the security-aware stub resolver obtained the
-   data in question from a trusted security-aware recursive name server
-   via a secure channel.
-
-   A validating security-aware stub resolver SHOULD NOT examine the
-   setting of the AD bit in response messages, as, by definition, the
-   stub resolver performs its own signature validation regardless of the
-   setting of the AD bit.
-
-
-
-Arends, et al.              Standards Track                    [Page 24]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-5.  Authenticating DNS Responses
-
-   To use DNSSEC RRs for authentication, a security-aware resolver
-   requires configured knowledge of at least one authenticated DNSKEY or
-   DS RR.  The process for obtaining and authenticating this initial
-   trust anchor is achieved via some external mechanism.  For example, a
-   resolver could use some off-line authenticated exchange to obtain a
-   zone's DNSKEY RR or to obtain a DS RR that identifies and
-   authenticates a zone's DNSKEY RR.  The remainder of this section
-   assumes that the resolver has somehow obtained an initial set of
-   trust anchors.
-
-   An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
-   RRset.  To authenticate an apex DNSKEY RRset by using an initial key,
-   the resolver MUST:
-
-   1.  verify that the initial DNSKEY RR appears in the apex DNSKEY
-       RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
-       bit 7) set; and
-
-   2.  verify that there is some RRSIG RR that covers the apex DNSKEY
-       RRset, and that the combination of the RRSIG RR and the initial
-       DNSKEY RR authenticates the DNSKEY RRset.  The process for using
-       an RRSIG RR to authenticate an RRset is described in Section 5.3.
-
-   Once the resolver has authenticated the apex DNSKEY RRset by using an
-   initial DNSKEY RR, delegations from that zone can be authenticated by
-   using DS RRs.  This allows a resolver to start from an initial key
-   and use DS RRsets to proceed recursively down the DNS tree, obtaining
-   other apex DNSKEY RRsets.  If the resolver were configured with a
-   root DNSKEY RR, and if every delegation had a DS RR associated with
-   it, then the resolver could obtain and validate any apex DNSKEY
-   RRset.  The process of using DS RRs to authenticate referrals is
-   described in Section 5.2.
-
-   Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
-   DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
-   RRsets in the zone once the resolver has authenticated a zone's apex
-   DNSKEY RRset.  Section 5.4 shows how the resolver can use
-   authenticated NSEC RRsets from the zone to prove that an RRset is not
-   present in the zone.
-
-   When a resolver indicates support for DNSSEC (by setting the DO bit),
-   a security-aware name server should attempt to provide the necessary
-   DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
-   However, a security-aware resolver may still receive a response that
-   lacks the appropriate DNSSEC RRs, whether due to configuration issues
-   such as an upstream security-oblivious recursive name server that
-
-
-
-Arends, et al.              Standards Track                    [Page 25]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   accidentally interferes with DNSSEC RRs or due to a deliberate attack
-   in which an adversary forges a response, strips DNSSEC RRs from a
-   response, or modifies a query so that DNSSEC RRs appear not to be
-   requested.  The absence of DNSSEC data in a response MUST NOT by
-   itself be taken as an indication that no authentication information
-   exists.
-
-   A resolver SHOULD expect authentication information from signed
-   zones.  A resolver SHOULD believe that a zone is signed if the
-   resolver has been configured with public key information for the
-   zone, or if the zone's parent is signed and the delegation from the
-   parent contains a DS RRset.
-
-5.1.  Special Considerations for Islands of Security
-
-   Islands of security (see [RFC4033]) are signed zones for which it is
-   not possible to construct an authentication chain to the zone from
-   its parent.  Validating signatures within an island of security
-   requires that the validator have some other means of obtaining an
-   initial authenticated zone key for the island.  If a validator cannot
-   obtain such a key, it SHOULD switch to operating as if the zones in
-   the island of security are unsigned.
-
-   All the normal processes for validating responses apply to islands of
-   security.  The only difference between normal validation and
-   validation within an island of security is in how the validator
-   obtains a trust anchor for the authentication chain.
-
-5.2.  Authenticating Referrals
-
-   Once the apex DNSKEY RRset for a signed parent zone has been
-   authenticated, DS RRsets can be used to authenticate the delegation
-   to a signed child zone.  A DS RR identifies a DNSKEY RR in the child
-   zone's apex DNSKEY RRset and contains a cryptographic digest of the
-   child zone's DNSKEY RR.  Use of a strong cryptographic digest
-   algorithm ensures that it is computationally infeasible for an
-   adversary to generate a DNSKEY RR that matches the digest.  Thus,
-   authenticating the digest allows a resolver to authenticate the
-   matching DNSKEY RR.  The resolver can then use this child DNSKEY RR
-   to authenticate the entire child apex DNSKEY RRset.
-
-   Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
-   can be authenticated if all of the following hold:
-
-   o  The DS RR has been authenticated using some DNSKEY RR in the
-      parent's apex DNSKEY RRset (see Section 5.3).
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 26]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   o  The Algorithm and Key Tag in the DS RR match the Algorithm field
-      and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
-      RRset, and, when the DNSKEY RR's owner name and RDATA are hashed
-      using the digest algorithm specified in the DS RR's Digest Type
-      field, the resulting digest value matches the Digest field of the
-      DS RR.
-
-   o  The matching DNSKEY RR in the child zone has the Zone Flag bit
-      set, the corresponding private key has signed the child zone's
-      apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
-      child zone's apex DNSKEY RRset.
-
-   If the referral from the parent zone did not contain a DS RRset, the
-   response should have included a signed NSEC RRset proving that no DS
-   RRset exists for the delegated name (see Section 3.1.4).  A
-   security-aware resolver MUST query the name servers for the parent
-   zone for the DS RRset if the referral includes neither a DS RRset nor
-   a NSEC RRset proving that the DS RRset does not exist (see Section
-   4).
-
-   If the validator authenticates an NSEC RRset that proves that no DS
-   RRset is present for this zone, then there is no authentication path
-   leading from the parent to the child.  If the resolver has an initial
-   DNSKEY or DS RR that belongs to the child zone or to any delegation
-   below the child zone, this initial DNSKEY or DS RR MAY be used to
-   re-establish an authentication path.  If no such initial DNSKEY or DS
-   RR exists, the validator cannot authenticate RRsets in or below the
-   child zone.
-
-   If the validator does not support any of the algorithms listed in an
-   authenticated DS RRset, then the resolver has no supported
-   authentication path leading from the parent to the child.  The
-   resolver should treat this case as it would the case of an
-   authenticated NSEC RRset proving that no DS RRset exists, as
-   described above.
-
-   Note that, for a signed delegation, there are two NSEC RRs associated
-   with the delegated name.  One NSEC RR resides in the parent zone and
-   can be used to prove whether a DS RRset exists for the delegated
-   name.  The second NSEC RR resides in the child zone and identifies
-   which RRsets are present at the apex of the child zone.  The parent
-   NSEC RR and child NSEC RR can always be distinguished because the SOA
-   bit will be set in the child NSEC RR and clear in the parent NSEC RR.
-   A security-aware resolver MUST use the parent NSEC RR when attempting
-   to prove that a DS RRset does not exist.
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 27]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   If the resolver does not support any of the algorithms listed in an
-   authenticated DS RRset, then the resolver will not be able to verify
-   the authentication path to the child zone.  In this case, the
-   resolver SHOULD treat the child zone as if it were unsigned.
-
-5.3.  Authenticating an RRset with an RRSIG RR
-
-   A validator can use an RRSIG RR and its corresponding DNSKEY RR to
-   attempt to authenticate RRsets.  The validator first checks the RRSIG
-   RR to verify that it covers the RRset, has a valid time interval, and
-   identifies a valid DNSKEY RR.  The validator then constructs the
-   canonical form of the signed data by appending the RRSIG RDATA
-   (excluding the Signature Field) with the canonical form of the
-   covered RRset.  Finally, the validator uses the public key and
-   signature to authenticate the signed data.  Sections 5.3.1, 5.3.2,
-   and 5.3.3 describe each step in detail.
-
-5.3.1.  Checking the RRSIG RR Validity
-
-   A security-aware resolver can use an RRSIG RR to authenticate an
-   RRset if all of the following conditions hold:
-
-   o  The RRSIG RR and the RRset MUST have the same owner name and the
-      same class.
-
-   o  The RRSIG RR's Signer's Name field MUST be the name of the zone
-      that contains the RRset.
-
-   o  The RRSIG RR's Type Covered field MUST equal the RRset's type.
-
-   o  The number of labels in the RRset owner name MUST be greater than
-      or equal to the value in the RRSIG RR's Labels field.
-
-   o  The validator's notion of the current time MUST be less than or
-      equal to the time listed in the RRSIG RR's Expiration field.
-
-   o  The validator's notion of the current time MUST be greater than or
-      equal to the time listed in the RRSIG RR's Inception field.
-
-   o  The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
-      match the owner name, algorithm, and key tag for some DNSKEY RR in
-      the zone's apex DNSKEY RRset.
-
-   o  The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
-      RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
-      set.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 28]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   It is possible for more than one DNSKEY RR to match the conditions
-   above.  In this case, the validator cannot predetermine which DNSKEY
-   RR to use to authenticate the signature, and it MUST try each
-   matching DNSKEY RR until either the signature is validated or the
-   validator has run out of matching public keys to try.
-
-   Note that this authentication process is only meaningful if the
-   validator authenticates the DNSKEY RR before using it to validate
-   signatures.  The matching DNSKEY RR is considered to be authentic if:
-
-   o  the apex DNSKEY RRset containing the DNSKEY RR is considered
-      authentic; or
-
-   o  the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
-      and the DNSKEY RR either matches an authenticated DS RR from the
-      parent zone or matches a trust anchor.
-
-5.3.2.  Reconstructing the Signed Data
-
-   Once the RRSIG RR has met the validity requirements described in
-   Section 5.3.1, the validator has to reconstruct the original signed
-   data.  The original signed data includes RRSIG RDATA (excluding the
-   Signature field) and the canonical form of the RRset.  Aside from
-   being ordered, the canonical form of the RRset might also differ from
-   the received RRset due to DNS name compression, decremented TTLs, or
-   wildcard expansion.  The validator should use the following to
-   reconstruct the original signed data:
-
-         signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where
-
-            "|" denotes concatenation
-
-            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
-               with the Signature field excluded and the Signer's Name
-               in canonical form.
-
-            RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
-
-               name is calculated according to the function below
-
-               class is the RRset's class
-
-               type is the RRset type and all RRs in the class
-
-               OrigTTL is the value from the RRSIG Original TTL field
-
-               All names in the RDATA field are in canonical form
-
-
-
-
-Arends, et al.              Standards Track                    [Page 29]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-               The set of all RR(i) is sorted into canonical order.
-
-            To calculate the name:
-               let rrsig_labels = the value of the RRSIG Labels field
-
-               let fqdn = RRset's fully qualified domain name in
-                               canonical form
-
-               let fqdn_labels = Label count of the fqdn above.
-
-               if rrsig_labels = fqdn_labels,
-                   name = fqdn
-
-               if rrsig_labels < fqdn_labels,
-                  name = "*." | the rightmost rrsig_label labels of the
-                                fqdn
-
-               if rrsig_labels > fqdn_labels
-                  the RRSIG RR did not pass the necessary validation
-                  checks and MUST NOT be used to authenticate this
-                  RRset.
-
-   The canonical forms for names and RRsets are defined in [RFC4034].
-
-   NSEC RRsets at a delegation boundary require special processing.
-   There are two distinct NSEC RRsets associated with a signed delegated
-   name.  One NSEC RRset resides in the parent zone, and specifies which
-   RRsets are present at the parent zone.  The second NSEC RRset resides
-   at the child zone and identifies which RRsets are present at the apex
-   in the child zone.  The parent NSEC RRset and child NSEC RRset can
-   always be distinguished as only a child NSEC RR will indicate that an
-   SOA RRset exists at the name.  When reconstructing the original NSEC
-   RRset for the delegation from the parent zone, the NSEC RRs MUST NOT
-   be combined with NSEC RRs from the child zone.  When reconstructing
-   the original NSEC RRset for the apex of the child zone, the NSEC RRs
-   MUST NOT be combined with NSEC RRs from the parent zone.
-
-   Note that each of the two NSEC RRsets at a delegation point has a
-   corresponding RRSIG RR with an owner name matching the delegated
-   name, and each of these RRSIG RRs is authoritative data associated
-   with the same zone that contains the corresponding NSEC RRset.  If
-   necessary, a resolver can tell these RRSIG RRs apart by checking the
-   Signer's Name field.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 30]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-5.3.3.  Checking the Signature
-
-   Once the resolver has validated the RRSIG RR as described in Section
-   5.3.1 and reconstructed the original signed data as described in
-   Section 5.3.2, the validator can attempt to use the cryptographic
-   signature to authenticate the signed data, and thus (finally!)
-   authenticate the RRset.
-
-   The Algorithm field in the RRSIG RR identifies the cryptographic
-   algorithm used to generate the signature.  The signature itself is
-   contained in the Signature field of the RRSIG RDATA, and the public
-   key used to verify the signature is contained in the Public Key field
-   of the matching DNSKEY RR(s) (found in Section 5.3.1).  [RFC4034]
-   provides a list of algorithm types and provides pointers to the
-   documents that define each algorithm's use.
-
-   Note that it is possible for more than one DNSKEY RR to match the
-   conditions in Section 5.3.1.  In this case, the validator can only
-   determine which DNSKEY RR is correct by trying each matching public
-   key until the validator either succeeds in validating the signature
-   or runs out of keys to try.
-
-   If the Labels field of the RRSIG RR is not equal to the number of
-   labels in the RRset's fully qualified owner name, then the RRset is
-   either invalid or the result of wildcard expansion.  The resolver
-   MUST verify that wildcard expansion was applied properly before
-   considering the RRset to be authentic.  Section 5.3.4 describes how
-   to determine whether a wildcard was applied properly.
-
-   If other RRSIG RRs also cover this RRset, the local resolver security
-   policy determines whether the resolver also has to test these RRSIG
-   RRs and how to resolve conflicts if these RRSIG RRs lead to differing
-   results.
-
-   If the resolver accepts the RRset as authentic, the validator MUST
-   set the TTL of the RRSIG RR and each RR in the authenticated RRset to
-   a value no greater than the minimum of:
-
-   o  the RRset's TTL as received in the response;
-
-   o  the RRSIG RR's TTL as received in the response;
-
-   o  the value in the RRSIG RR's Original TTL field; and
-
-   o  the difference of the RRSIG RR's Signature Expiration time and the
-      current time.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 31]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-5.3.4.  Authenticating a Wildcard Expanded RRset Positive Response
-
-   If the number of labels in an RRset's owner name is greater than the
-   Labels field of the covering RRSIG RR, then the RRset and its
-   covering RRSIG RR were created as a result of wildcard expansion.
-   Once the validator has verified the signature, as described in
-   Section 5.3, it must take additional steps to verify the non-
-   existence of an exact match or closer wildcard match for the query.
-   Section 5.4 discusses these steps.
-
-   Note that the response received by the resolver should include all
-   NSEC RRs needed to authenticate the response (see Section 3.1.3).
-
-5.4.  Authenticated Denial of Existence
-
-   A resolver can use authenticated NSEC RRs to prove that an RRset is
-   not present in a signed zone.  Security-aware name servers should
-   automatically include any necessary NSEC RRs for signed zones in
-   their responses to security-aware resolvers.
-
-   Denial of existence is determined by the following rules:
-
-   o  If the requested RR name matches the owner name of an
-      authenticated NSEC RR, then the NSEC RR's type bit map field lists
-      all RR types present at that owner name, and a resolver can prove
-      that the requested RR type does not exist by checking for the RR
-      type in the bit map.  If the number of labels in an authenticated
-      NSEC RR's owner name equals the Labels field of the covering RRSIG
-      RR, then the existence of the NSEC RR proves that wildcard
-      expansion could not have been used to match the request.
-
-   o  If the requested RR name would appear after an authenticated NSEC
-      RR's owner name and before the name listed in that NSEC RR's Next
-      Domain Name field according to the canonical DNS name order
-      defined in [RFC4034], then no RRsets with the requested name exist
-      in the zone.  However, it is possible that a wildcard could be
-      used to match the requested RR owner name and type, so proving
-      that the requested RRset does not exist also requires proving that
-      no possible wildcard RRset exists that could have been used to
-      generate a positive response.
-
-   In addition, security-aware resolvers MUST authenticate the NSEC
-   RRsets that comprise the non-existence proof as described in Section
-   5.3.
-
-   To prove the non-existence of an RRset, the resolver must be able to
-   verify both that the queried RRset does not exist and that no
-   relevant wildcard RRset exists.  Proving this may require more than
-
-
-
-Arends, et al.              Standards Track                    [Page 32]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   one NSEC RRset from the zone.  If the complete set of necessary NSEC
-   RRsets is not present in a response (perhaps due to message
-   truncation), then a security-aware resolver MUST resend the query in
-   order to attempt to obtain the full collection of NSEC RRs necessary
-   to verify the non-existence of the requested RRset.  As with all DNS
-   operations, however, the resolver MUST bound the work it puts into
-   answering any particular query.
-
-   Since a validated NSEC RR proves the existence of both itself and its
-   corresponding RRSIG RR, a validator MUST ignore the settings of the
-   NSEC and RRSIG bits in an NSEC RR.
-
-5.5.  Resolver Behavior When Signatures Do Not Validate
-
-   If for whatever reason none of the RRSIGs can be validated, the
-   response SHOULD be considered BAD.  If the validation was being done
-   to service a recursive query, the name server MUST return RCODE 2 to
-   the originating client.  However, it MUST return the full response if
-   and only if the original query had the CD bit set.  Also see Section
-   4.7 on caching responses that do not validate.
-
-5.6.  Authentication Example
-
-   Appendix C shows an example of the authentication process.
-
-6.  IANA Considerations
-
-   [RFC4034] contains a review of the IANA considerations introduced by
-   DNSSEC.  The following are additional IANA considerations discussed
-   in this document:
-
-   [RFC2535] reserved the CD and AD bits in the message header.  The
-   meaning of the AD bit was redefined in [RFC3655], and the meaning of
-   both the CD and AD bit are restated in this document.  No new bits in
-   the DNS message header are defined in this document.
-
-   [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit
-   and defined its use.  The use is restated but not altered in this
-   document.
-
-7.  Security Considerations
-
-   This document describes how the DNS security extensions use public
-   key cryptography to sign and authenticate DNS resource record sets.
-   Please see [RFC4033] for terminology and general security
-   considerations related to DNSSEC; see [RFC4034] for considerations
-   specific to the DNSSEC resource record types.
-
-
-
-
-Arends, et al.              Standards Track                    [Page 33]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   An active attacker who can set the CD bit in a DNS query message or
-   the AD bit in a DNS response message can use these bits to defeat the
-   protection that DNSSEC attempts to provide to security-oblivious
-   recursive-mode resolvers.  For this reason, use of these control bits
-   by a security-aware recursive-mode resolver requires a secure
-   channel.  See Sections 3.2.2 and 4.9 for further discussion.
-
-   The protocol described in this document attempts to extend the
-   benefits of DNSSEC to security-oblivious stub resolvers.  However, as
-   recovery from validation failures is likely to be specific to
-   particular applications, the facilities that DNSSEC provides for stub
-   resolvers may prove inadequate.  Operators of security-aware
-   recursive name servers will have to pay close attention to the
-   behavior of the applications that use their services when choosing a
-   local validation policy; failure to do so could easily result in the
-   recursive name server accidentally denying service to the clients it
-   is intended to support.
-
-8.  Acknowledgements
-
-   This document was created from the input and ideas of the members of
-   the DNS Extensions Working Group and working group mailing list.  The
-   editors would like to express their thanks for the comments and
-   suggestions received during the revision of these security extension
-   specifications.  Although explicitly listing everyone who has
-   contributed during the decade in which DNSSEC has been under
-   development would be impossible, [RFC4033] includes a list of some of
-   the participants who were kind enough to comment on these documents.
-
-9.  References
-
-9.1.  Normative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
-              Communication Layers", STD 3, RFC 1122, October 1989.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-
-
-
-Arends, et al.              Standards Track                    [Page 34]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
-              (IPv6) Specification", RFC 2460, December 1998.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-              2671, August 1999.
-
-   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
-              2672, August 1999.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-              3225, December 2001.
-
-   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
-              message size requirements", RFC 3226, December 2001.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements", RFC
-              4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for DNS Security Extensions", RFC
-              4034, March 2005.
-
-9.2.  Informative References
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2308, March 1998.
-
-   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
-              Extensions", RFC 2535, March 1999.
-
-   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-              Update", RFC 3007, November 2000.
-
-   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
-              Authenticated Data (AD) bit", RFC 3655, November 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 35]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-Appendix A.  Signed Zone Example
-
-   The following example shows a (small) complete signed zone.
-
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-                  3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-                  3600 NS     ns1.example.
-                  3600 NS     ns2.example.
-                  3600 RRSIG  NS 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
-                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
-                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
-                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
-                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
-                  3600 MX     1 xx.example.
-                  3600 RRSIG  MX 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
-                              2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
-                              VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
-                              6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
-                              W6OISukd1EQt7a0kygkg+PEDxdI= )
-                  3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
-                  3600 RRSIG  NSEC 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
-                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
-                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
-                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
-                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
-                  3600 DNSKEY 256 3 5 (
-                              AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
-                              rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
-                              k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
-                              vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
-
-
-
-Arends, et al.              Standards Track                    [Page 36]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
-                              )
-                  3600 DNSKEY 257 3 5 (
-                              AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
-                              LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
-                              syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
-                              RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
-                              Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
-                              )
-                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
-                              20040409183619 9465 example.
-                              ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
-                              xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
-                              XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
-                              hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
-                              NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
-                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
-                              DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
-                              bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
-                              eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
-                              7z5OXogYVaFzHKillDt3HRxHIZM= )
-   a.example.     3600 IN NS  ns1.a.example.
-                  3600 IN NS  ns2.a.example.
-                  3600 DS     57855 5 1 (
-                              B6DCD485719ADCA18E5F3D48A2331627FDD3
-                              636B )
-                  3600 RRSIG  DS 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
-                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
-                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
-                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
-                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
-                  3600 NSEC   ai.example. NS DS RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
-                              U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
-                              039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
-                              BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
-                              sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
-   ns1.a.example. 3600 IN A   192.0.2.5
-   ns2.a.example. 3600 IN A   192.0.2.6
-   ai.example.    3600 IN A   192.0.2.9
-                  3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-
-
-
-Arends, et al.              Standards Track                    [Page 37]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
-                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
-                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
-                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
-                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
-                  3600 HINFO  "KLH-10" "ITS"
-                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
-                              e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
-                              ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
-                              AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
-                              FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
-                  3600 AAAA   2001:db8::f00:baa9
-                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
-                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
-                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
-                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
-                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
-                  3600 NSEC   b.example. A HINFO AAAA RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
-                              CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
-                              P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
-                              3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
-                              AhS+JOVfDI/79QtyTI0SaDWcg8U= )
-   b.example.     3600 IN NS  ns1.b.example.
-                  3600 IN NS  ns2.b.example.
-                  3600 NSEC   ns1.example. NS RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
-                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
-                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
-                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
-                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
-   ns1.b.example. 3600 IN A   192.0.2.7
-   ns2.b.example. 3600 IN A   192.0.2.8
-   ns1.example.   3600 IN A   192.0.2.1
-                  3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
-                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
-                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
-                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
-
-
-
-Arends, et al.              Standards Track                    [Page 38]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
-                  3600 NSEC   ns2.example. A RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
-                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
-                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
-                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
-                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
-   ns2.example.   3600 IN A   192.0.2.2
-                  3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
-                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
-                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
-                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
-                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
-                  3600 NSEC   *.w.example. A RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
-                              VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
-                              3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
-                              l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
-                              Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
-   *.w.example.   3600 IN MX  1 ai.example.
-                  3600 RRSIG  MX 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
-                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
-                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
-                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
-                              4kX18MMR34i8lC36SR5xBni8vHI= )
-                  3600 NSEC   x.w.example. MX RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
-                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
-                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
-                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
-                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
-   x.w.example.   3600 IN MX  1 xx.example.
-                  3600 RRSIG  MX 5 3 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
-                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
-                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
-                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
-
-
-
-Arends, et al.              Standards Track                    [Page 39]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
-                  3600 NSEC   x.y.w.example. MX RRSIG NSEC
-                  3600 RRSIG  NSEC 5 3 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
-                              vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
-                              mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
-                              NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
-                              IjgiM8PXkBQtxPq37wDKALkyn7Q= )
-   x.y.w.example. 3600 IN MX  1 xx.example.
-                  3600 RRSIG  MX 5 4 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
-                              t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
-                              q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
-                              GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
-                              +gLcMZBnHJ326nb/TOOmrqNmQQE= )
-                  3600 NSEC   xx.example. MX RRSIG NSEC
-                  3600 RRSIG  NSEC 5 4 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
-                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
-                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
-                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
-                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
-   xx.example.    3600 IN A   192.0.2.10
-                  3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
-                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
-                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
-                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
-                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
-                  3600 HINFO  "KLH-10" "TOPS-20"
-                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
-                              t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
-                              BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
-                              3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
-                              RgNvuwbioFSEuv2pNlkq0goYxNY= )
-                  3600 AAAA   2001:db8::f00:baaa
-                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
-                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
-                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
-                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
-
-
-
-Arends, et al.              Standards Track                    [Page 40]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
-                  3600 NSEC   example. A HINFO AAAA RRSIG NSEC
-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
-                              9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
-                              mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
-                              asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
-                              GghLahumFIpg4MO3LS/prgzVVWo= )
-
-   The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
-   Flags indicate that each of these DNSKEY RRs is a zone key.  One of
-   these DNSKEY RRs also has the SEP flag set and has been used to sign
-   the apex DNSKEY RRset; this is the key that should be hashed to
-   generate a DS record to be inserted into the parent zone.  The other
-   DNSKEY is used to sign all the other RRsets in the zone.
-
-   The zone includes a wildcard entry, "*.w.example".  Note that the
-   name "*.w.example" is used in constructing NSEC chains, and that the
-   RRSIG covering the "*.w.example" MX RRset has a label count of 2.
-
-   The zone also includes two delegations.  The delegation to
-   "b.example" includes an NS RRset, glue address records, and an NSEC
-   RR; note that only the NSEC RRset is signed.  The delegation to
-   "a.example" provides a DS RR; note that only the NSEC and DS RRsets
-   are signed.
-
-Appendix B.  Example Responses
-
-   The examples in this section show response messages using the signed
-   zone example in Appendix A.
-
-B.1.  Answer
-
-   A successful query to an authoritative server.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   x.w.example.        IN MX
-
-   ;; Answer
-   x.w.example.   3600 IN MX  1 xx.example.
-   x.w.example.   3600 RRSIG  MX 5 3 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
-                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
-                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
-
-
-
-Arends, et al.              Standards Track                    [Page 41]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
-                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
-
-   ;; Authority
-   example.       3600 NS     ns1.example.
-   example.       3600 NS     ns2.example.
-   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
-                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
-                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
-                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
-                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
-
-   ;; Additional
-   xx.example.    3600 IN A   192.0.2.10
-   xx.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
-                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
-                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
-                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
-                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
-   xx.example.    3600 AAAA   2001:db8::f00:baaa
-   xx.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
-                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
-                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
-                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
-                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
-   ns1.example.   3600 IN A   192.0.2.1
-   ns1.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
-                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
-                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
-                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
-                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
-   ns2.example.   3600 IN A   192.0.2.2
-   ns2.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
-                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
-                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
-                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
-                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
-
-
-
-
-Arends, et al.              Standards Track                    [Page 42]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-B.2.  Name Error
-
-   An authoritative name error.  The NSEC RRs prove that the name does
-   not exist and that no covering wildcard exists.
-
-   ;; Header: QR AA DO RCODE=3
-   ;;
-   ;; Question
-   ml.example.         IN A
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
-   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
-                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
-                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
-                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
-                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
-   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
-   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
-                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
-                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
-                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
-                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
-
-   ;; Additional
-   ;; (empty)
-
-
-
-
-Arends, et al.              Standards Track                    [Page 43]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-B.3.  No Data Error
-
-   A "no data" response.  The NSEC RR proves that the name exists and
-   that the requested RR type does not.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   ns1.example.        IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-   ns1.example.   3600 NSEC   ns2.example. A RRSIG NSEC
-   ns1.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
-                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
-                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
-                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
-                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
-
-   ;; Additional
-   ;; (empty)
-
-B.4.  Referral to Signed Zone
-
-   Referral to a signed zone.  The DS RR contains the data which the
-   resolver will need to validate the corresponding DNSKEY RR in the
-   child zone's apex.
-
-   ;; Header: QR DO RCODE=0
-   ;;
-
-
-
-Arends, et al.              Standards Track                    [Page 44]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   ;; Question
-   mc.a.example.       IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   a.example.     3600 IN NS  ns1.a.example.
-   a.example.     3600 IN NS  ns2.a.example.
-   a.example.     3600 DS     57855 5 1 (
-                              B6DCD485719ADCA18E5F3D48A2331627FDD3
-                              636B )
-   a.example.     3600 RRSIG  DS 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
-                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
-                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
-                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
-                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
-
-   ;; Additional
-   ns1.a.example. 3600 IN A   192.0.2.5
-   ns2.a.example. 3600 IN A   192.0.2.6
-
-B.5.  Referral to Unsigned Zone
-
-   Referral to an unsigned zone.  The NSEC RR proves that no DS RR for
-   this delegation exists in the parent zone.
-
-   ;; Header: QR DO RCODE=0
-   ;;
-   ;; Question
-   mc.b.example.       IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   b.example.     3600 IN NS  ns1.b.example.
-   b.example.     3600 IN NS  ns2.b.example.
-   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
-   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
-                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
-                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
-                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
-                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
-
-
-
-Arends, et al.              Standards Track                    [Page 45]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   ;; Additional
-   ns1.b.example. 3600 IN A   192.0.2.7
-   ns2.b.example. 3600 IN A   192.0.2.8
-
-B.6.  Wildcard Expansion
-
-   A successful query that was answered via wildcard expansion.  The
-   label count in the answer's RRSIG RR indicates that a wildcard RRset
-   was expanded to produce this response, and the NSEC RR proves that no
-   closer match exists in the zone.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example.      IN MX
-
-   ;; Answer
-   a.z.w.example. 3600 IN MX  1 ai.example.
-   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
-                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
-                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
-                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
-                              4kX18MMR34i8lC36SR5xBni8vHI= )
-
-   ;; Authority
-   example.       3600 NS     ns1.example.
-   example.       3600 NS     ns2.example.
-   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
-                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
-                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
-                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
-                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
-   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
-   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
-                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
-                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
-                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
-                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
-
-   ;; Additional
-   ai.example.    3600 IN A   192.0.2.9
-   ai.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
-
-
-
-Arends, et al.              Standards Track                    [Page 46]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              20040409183619 38519 example.
-                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
-                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
-                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
-                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
-                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
-   ai.example.    3600 AAAA   2001:db8::f00:baa9
-   ai.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
-                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
-                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
-                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
-                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
-
-B.7.  Wildcard No Data Error
-
-   A "no data" response for a name covered by a wildcard.  The NSEC RRs
-   prove that the matching wildcard name does not have any RRs of the
-   requested type and that no closer match exists in the zone.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example.      IN AAAA
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
-   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
-
-
-
-Arends, et al.              Standards Track                    [Page 47]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
-                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
-                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
-                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
-   *.w.example.   3600 NSEC   x.w.example. MX RRSIG NSEC
-   *.w.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
-                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
-                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
-                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
-                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
-
-   ;; Additional
-   ;; (empty)
-
-B.8.  DS Child Zone No Data Error
-
-   A "no data" response for a QTYPE=DS query that was mistakenly sent to
-   a name server for the child zone.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   example.            IN DS
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1081539377
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
-                              jV7j86HyQgM5e7+miRAz8V01b0I= )
-   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
-   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
-                              20040409183619 38519 example.
-                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
-
-
-
-Arends, et al.              Standards Track                    [Page 48]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
-                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
-                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
-                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
-
-   ;; Additional
-   ;; (empty)
-
-Appendix C.  Authentication Examples
-
-   The examples in this section show how the response messages in
-   Appendix B are authenticated.
-
-C.1.  Authenticating an Answer
-
-   The query in Appendix B.1 returned an MX RRset for "x.w.example.com".
-   The corresponding RRSIG indicates that the MX RRset was signed by an
-   "example" DNSKEY with algorithm 5 and key tag 38519.  The resolver
-   needs the corresponding DNSKEY RR in order to authenticate this
-   answer.  The discussion below describes how a resolver might obtain
-   this DNSKEY RR.
-
-   The RRSIG indicates the original TTL of the MX RRset was 3600, and,
-   for the purpose of authentication, the current TTL is replaced by
-   3600.  The RRSIG labels field value of 3 indicates that the answer
-   was not the result of wildcard expansion.  The "x.w.example.com" MX
-   RRset is placed in canonical form, and, assuming the current time
-   falls between the signature inception and expiration dates, the
-   signature is authenticated.
-
-C.1.1.  Authenticating the Example DNSKEY RR
-
-   This example shows the logical authentication process that starts
-   from the a configured root DNSKEY (or DS RR) and moves down the tree
-   to authenticate the desired "example" DNSKEY RR.  Note that the
-   logical order is presented for clarity.  An implementation may choose
-   to construct the authentication as referrals are received or to
-   construct the authentication chain only after all RRsets have been
-   obtained, or in any other combination it sees fit.  The example here
-   demonstrates only the logical process and does not dictate any
-   implementation rules.
-
-   We assume the resolver starts with a configured DNSKEY RR for the
-   root zone (or a configured DS RR for the root zone).  The resolver
-   checks whether this configured DNSKEY RR is present in the root
-   DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root
-   DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY
-   RRset, and whether the signature lifetime is valid.  If all these
-
-
-
-Arends, et al.              Standards Track                    [Page 49]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   conditions are met, all keys in the DNSKEY RRset are considered
-   authenticated.  The resolver then uses one (or more) of the root
-   DNSKEY RRs to authenticate the "example" DS RRset.  Note that the
-   resolver may have to query the root zone to obtain the root DNSKEY
-   RRset or "example" DS RRset.
-
-   Once the DS RRset has been authenticated using the root DNSKEY, the
-   resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
-   RR that matches one of the authenticated "example" DS RRs.  If such a
-   matching "example" DNSKEY is found, the resolver checks whether this
-   DNSKEY RR has signed the "example" DNSKEY RRset and the signature
-   lifetime is valid.  If these conditions are met, all keys in the
-   "example" DNSKEY RRset are considered authenticated.
-
-   Finally, the resolver checks that some DNSKEY RR in the "example"
-   DNSKEY RRset uses algorithm 5 and has a key tag of 38519.  This
-   DNSKEY is used to authenticate the RRSIG included in the response.
-   If multiple "example" DNSKEY RRs match this algorithm and key tag,
-   then each DNSKEY RR is tried, and the answer is authenticated if any
-   of the matching DNSKEY RRs validate the signature as described above.
-
-C.2.  Name Error
-
-   The query in Appendix B.2 returned NSEC RRs that prove that the
-   requested data does not exist and no wildcard applies.  The negative
-   reply is authenticated by verifying both NSEC RRs.  The NSEC RRs are
-   authenticated in a manner identical to that of the MX RRset discussed
-   above.
-
-C.3.  No Data Error
-
-   The query in Appendix B.3 returned an NSEC RR that proves that the
-   requested name exists, but the requested RR type does not exist.  The
-   negative reply is authenticated by verifying the NSEC RR.  The NSEC
-   RR is authenticated in a manner identical to that of the MX RRset
-   discussed above.
-
-C.4.  Referral to Signed Zone
-
-   The query in Appendix B.4 returned a referral to the signed
-   "a.example." zone.  The DS RR is authenticated in a manner identical
-   to that of the MX RRset discussed above.  This DS RR is used to
-   authenticate the "a.example" DNSKEY RRset.
-
-   Once the "a.example" DS RRset has been authenticated using the
-   "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
-   for some "a.example" DNSKEY RR that matches the DS RR.  If such a
-   matching "a.example" DNSKEY is found, the resolver checks whether
-
-
-
-Arends, et al.              Standards Track                    [Page 50]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
-   the signature lifetime is valid.  If all these conditions are met,
-   all keys in the "a.example" DNSKEY RRset are considered
-   authenticated.
-
-C.5.  Referral to Unsigned Zone
-
-   The query in Appendix B.5 returned a referral to an unsigned
-   "b.example." zone.  The NSEC proves that no authentication leads from
-   "example" to "b.example", and the NSEC RR is authenticated in a
-   manner identical to that of the MX RRset discussed above.
-
-C.6.  Wildcard Expansion
-
-   The query in Appendix B.6 returned an answer that was produced as a
-   result of wildcard expansion.  The answer section contains a wildcard
-   RRset expanded as it would be in a traditional DNS response, and the
-   corresponding RRSIG indicates that the expanded wildcard MX RRset was
-   signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
-   The RRSIG indicates that the original TTL of the MX RRset was 3600,
-   and, for the purpose of authentication, the current TTL is replaced
-   by 3600.  The RRSIG labels field value of 2 indicates that the answer
-   is the result of wildcard expansion, as the "a.z.w.example" name
-   contains 4 labels.  The name "a.z.w.w.example" is replaced by
-   "*.w.example", the MX RRset is placed in canonical form, and,
-   assuming that the current time falls between the signature inception
-   and expiration dates, the signature is authenticated.
-
-   The NSEC proves that no closer match (exact or closer wildcard) could
-   have been used to answer this query, and the NSEC RR must also be
-   authenticated before the answer is considered valid.
-
-C.7.  Wildcard No Data Error
-
-   The query in Appendix B.7 returned NSEC RRs that prove that the
-   requested data does not exist and no wildcard applies.  The negative
-   reply is authenticated by verifying both NSEC RRs.
-
-C.8.  DS Child Zone No Data Error
-
-   The query in Appendix B.8 returned NSEC RRs that shows the requested
-   was answered by a child server ("example" server).  The NSEC RR
-   indicates the presence of an SOA RR, showing that the answer is from
-   the child .  Queries for the "example" DS RRset should be sent to the
-   parent servers ("root" servers).
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 51]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Brouwerijstraat 1
-   7523 XC  Enschede
-   NL
-
-   EMail: roy.arends@telin.nl
-
-
-   Rob Austein
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   EMail: sra@isc.org
-
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: mlarson@verisign.com
-
-
-   Dan Massey
-   Colorado State University
-   Department of Computer Science
-   Fort Collins, CO 80523-1873
-
-   EMail: massey@cs.colostate.edu
-
-
-   Scott Rose
-   National Institute for Standards and Technology
-   100 Bureau Drive
-   Gaithersburg, MD  20899-8920
-   USA
-
-   EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 52]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 53]
-
diff --git a/doc/rfc/rfc4074.txt b/doc/rfc/rfc4074.txt
deleted file mode 100644
index d9252b39..00000000
--- a/doc/rfc/rfc4074.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       Y. Morishita
-Request for Comments: 4074                                          JPRS
-Category: Informational                                        T. Jinmei
-                                                                 Toshiba
-                                                                May 2005
-
-
-       Common Misbehavior Against DNS Queries for IPv6 Addresses
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   There is some known misbehavior of DNS authoritative servers when
-   they are queried for AAAA resource records.  Such behavior can block
-   IPv4 communication that should actually be available, cause a
-   significant delay in name resolution, or even make a denial of
-   service attack.  This memo describes details of known cases and
-   discusses their effects.
-
-1.  Introduction
-
-   Many existing DNS clients (resolvers) that support IPv6 first search
-   for AAAA Resource Records (RRs) of a target host name, and then for A
-   RRs of the same name.  This fallback mechanism is based on the DNS
-   specifications, which if not obeyed by authoritative servers, can
-   produce unpleasant results.  In some cases, for example, a web
-   browser fails to connect to a web server it could otherwise reach.
-   In the following sections, this memo describes some typical cases of
-   such misbehavior and its (bad) effects.
-
-   Note that the misbehavior is not specific to AAAA RRs.  In fact, all
-   known examples also apply to the cases of queries for MX, NS, and SOA
-   RRs.  The authors believe this can be generalized for all types of
-   queries other than those for A RRs.  In this memo, however, we
-   concentrate on the case for AAAA queries, since the problem is
-   particularly severe for resolvers that support IPv6, which thus
-   affects many end users.  Resolvers at end users normally send A
-   and/or AAAA queries only, so the problem for the other cases is
-   relatively minor.
-
-
-
-Morishita & Jinmei           Informational                      [Page 1]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-2.  Network Model
-
-   In this memo, we assume a typical network model of name resolution
-   environment using DNS.  It consists of three components: stub
-   resolvers, caching servers, and authoritative servers.  A stub
-   resolver issues a recursive query to a caching server, which then
-   handles the entire name resolution procedure recursively.  The
-   caching server caches the result of the query and sends the result to
-   the stub resolver.  The authoritative servers respond to queries for
-   names for which they have the authority, normally in a non-recursive
-   manner.
-
-3.  Expected Behavior
-
-   Suppose that an authoritative server has an A RR but has no AAAA RR
-   for a host name.  Then, the server should return a response to a
-   query for an AAAA RR of the name with the response code (RCODE) being
-   0 (indicating no error) and with an empty answer section (see
-   Sections 4.3.2 and 6.2.4 of [1]).  Such a response indicates that
-   there is at least one RR of a different type than AAAA for the
-   queried name, and the stub resolver can then look for A RRs.
-
-   This way, the caching server can cache the fact that the queried name
-   has no AAAA RR (but may have other types of RRs), and thus improve
-   the response time to further queries for an AAAA RR of the name.
-
-4.  Problematic Behaviors
-
-   There are some known cases at authoritative servers that do not
-   conform to the expected behavior.  This section describes those
-   problematic cases.
-
-4.1.  Ignore Queries for AAAA
-
-   Some authoritative servers seem to ignore queries for an AAAA RR,
-   causing a delay at the stub resolver to fall back to a query for an A
-   RR.  This behavior may cause a fatal timeout at the resolver or at
-   the application that calls the resolver.  Even if the resolver
-   eventually falls back, the result can be an unacceptable delay for
-   the application user, especially with interactive applications like
-   web browsing.
-
-4.2.  Return "Name Error"
-
-   This type of server returns a response with RCODE 3 ("Name Error") to
-   a query for an AAAA RR, indicating that it does not have any RRs of
-   any type for the queried name.
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 2]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-   With this response, the stub resolver may immediately give up and
-   never fall back.  Even if the resolver retries with a query for an A
-   RR, the negative response for the name has been cached in the caching
-   server, and the caching server will simply return the negative
-   response.  As a result, the stub resolver considers this to be a
-   fatal error in name resolution.
-
-   Several examples of this behavior are known to the authors.  As of
-   this writing, all have been fixed.
-
-4.3.  Return Other Erroneous Codes
-
-   Other authoritative servers return a response with erroneous response
-   codes other than RCODE 3 ("Name Error").  One such RCODE is 4 ("Not
-   Implemented"), indicating that the servers do not support the
-   requested type of query.
-
-   These cases are less harmful than the previous one; if the stub
-   resolver falls back to querying for an A RR, the caching server will
-   process the query correctly and return an appropriate response.
-
-   However, these can still cause a serious effect.  There was an
-   authoritative server implementation that returned RCODE 2 ("Server
-   failure") to queries for AAAA RRs.  One widely deployed mail server
-   implementation with a certain type of resolver library interpreted
-   this result as an indication of retry and did not fall back to
-   queries for A RRs, causing message delivery failure.
-
-   If the caching server receives a response with these response codes,
-   it does not cache the fact that the queried name has no AAAA RR,
-   resulting in redundant queries for AAAA RRs in the future.  The
-   behavior will waste network bandwidth and increase the load of the
-   authoritative server.
-
-   Using RCODE 1 ("Format error") would cause a similar effect, though
-   the authors have not seen such implementations yet.
-
-4.4.  Return a Broken Response
-
-   Another type of authoritative servers returns broken responses to
-   AAAA queries.  Returning a response whose RR type is AAAA with the
-   length of the RDATA being 4 bytes is a known behavior of this
-   category.  The 4-byte data looks like the IPv4 address of the queried
-   host name.
-
-
-
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 3]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-   That is, the RR in the answer section would be described as follows:
-
-     www.bad.example. 600 IN AAAA 192.0.2.1
-
-   which is, of course, bogus (or at least meaningless).
-
-   A widely deployed caching server implementation transparently returns
-   the broken response (and caches it) to the stub resolver.  Another
-   known server implementation parses the response by itself, and sends
-   a separate response with RCODE 2 ("Server failure").
-
-   In either case, the broken response does not affect queries for an A
-   RR of the same name.  If the stub resolver falls back to A queries,
-   it will get an appropriate response.
-
-   The latter case, however, causes the same bad effect as that
-   described in the previous section: redundant queries for AAAA RRs.
-
-4.5.  Make Lame Delegation
-
-   Some authoritative servers respond to AAAA queries in a way that
-   causes lame delegation.  In this case, the parent zone specifies that
-   the authoritative server should have the authority of a zone, but the
-   server should not return an authoritative response for AAAA queries
-   within the zone (i.e., the AA bit in the response is not set).  On
-   the other hand, the authoritative server returns an authoritative
-   response for A queries.
-
-   When a caching server asks the server for AAAA RRs in the zone, it
-   recognizes the delegation is lame, and returns a response with RCODE
-   2 ("Server failure") to the stub resolver.
-
-   Furthermore, some caching servers record the authoritative server as
-   lame for the zone and will not use it for a certain period of time.
-   With this type of caching server, even if the stub resolver falls
-   back to querying for an A RR, the caching server will simply return a
-   response with RCODE 2, since all the servers are known to be "lame."
-
-   There is also an implementation that relaxes the behavior a little
-   bit.  It tries to avoid using the lame server, but continues to try
-   it as a last resort.  With this type of caching server, the stub
-   resolver will get a correct response if it falls back after Server
-   failure.  However, this still causes redundant AAAA queries, as
-   explained in the previous sections.
-
-
-
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 4]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-5.  Security Considerations
-
-   The CERT/CC pointed out that the response with RCODE 3 ("Name
-   Error"), described in Section 4.2, can be used for a denial of
-   service attack [2].  The same argument applies to the case of "lame
-   delegation", described in Section 4.5, with a certain type of caching
-   server.
-
-6.  Acknowledgements
-
-   Erik Nordmark encouraged the authors to publish this document as an
-   RFC.  Akira Kato and Paul Vixie reviewed a preliminary version of
-   this document.  Pekka Savola carefully reviewed a previous version
-   and provided detailed comments.  Bill Fenner, Scott Hollenbeck,
-   Thomas Narten, and Alex Zinin reviewed and helped improve the
-   document at the last stage for publication.
-
-7.  Informative References
-
-   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [2]  The CERT Coordination Center, "Incorrect NXDOMAIN responses from
-        AAAA queries could cause denial-of-service conditions",
-        March 2003, <http://www.kb.cert.org/vuls/id/714121>.
-
-Authors' Addresses
-
-   MORISHITA Orange Yasuhiro
-   Research and Development Department, Japan Registry Services Co.,Ltd.
-   Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
-   Chiyoda-ku, Tokyo  101-0065
-   Japan
-
-   EMail: yasuhiro@jprs.co.jp
-
-
-   JINMEI Tatuya
-   Corporate Research & Development Center, Toshiba Corporation
-   1 Komukai Toshiba-cho, Saiwai-ku
-   Kawasaki-shi, Kanagawa  212-8582
-   Japan
-
-   EMail: jinmei@isl.rdc.toshiba.co.jp
-
-
-
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 5]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 6]
-
diff --git a/doc/rfc/rfc4159.txt b/doc/rfc/rfc4159.txt
deleted file mode 100644
index 1ab4bd1a..00000000
--- a/doc/rfc/rfc4159.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          G. Huston
-Request for Comments: 4159                                         APNIC
-BCP: 109                                                     August 2005
-Category: Best Current Practice
-
-
-                        Deprecation of "ip6.int"
-
-Status of This Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document advises of the deprecation of the use of "ip6.int" for
-   Standards Conformant IPv6 implementations.
-
-1.  IPv6 Standards Action
-
-   In August 2001 the IETF published [RFC3152], which advised that the
-   use of "ip6.int" as the domain for reverse-mapping of IPv6 addresses
-   to DNS names was deprecated.  The document noted that the use of
-   "ip6.int" would be phased out in an orderly fashion.
-
-   As of 1 September 2005, the IETF advises the community that the DNS
-   domain "ip6.int" should no longer be used to perform reverse mapping
-   of IPv6 addresses to domain names, and that the domain "ip6.arpa"
-   should be used henceforth, in accordance with the IANA Considerations
-   described in [RFC3596].  The domain "ip6.int" is deprecated, and its
-   use in IPv6 implementations that conform to the IPv6 Internet
-   Standards is discontinued.
-
-   The Regional Internet Registries (RIRs) are advised that maintenance
-   of delegation of entries in "ip6.int" is no longer required as part
-   of infrastructure services in support of Internet Standards
-   Conformant IPv6 implementations as of 1 September 2005.  The RIRs are
-   requested to work with their communities to adopt a schedule
-   regarding the cessation of support of registration services for the
-   "ip6.int" domain.
-
-
-
-
-
-
-Huston                   Best Current Practice                  [Page 1]
-
-RFC 4159                        ip6.int                      August 2005
-
-
-2.  IANA Considerations
-
-   IANA is advised that the "ip6.int" domain for reverse mapping of IPv6
-   addresses to domain names is no longer part of Internet Standards
-   Conformant support of IPv6 as of 1 September 2005.
-
-3.  Security Considerations
-
-   While DNS spoofing of address to name mapping has been exploited in
-   IPv4, removal of the "ip6.int" zone from the standard IPv6
-   specification creates no new threats to the security of the internet.
-
-4.  Acknowledgements
-
-   The document was prepared with the assistance of Kurt Lindqvist,
-   Thomas Narten, Paul Wilson, David Kessens, Bob Hinden, Brian
-   Haberman, and Bill Manning.
-
-5.  Normative References
-
-   [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
-             August 2001.
-
-   [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
-             Extensions to Support IP Version 6", RFC 3596, October
-             2003.
-
-Author's Address
-
-   Geoff Huston
-   APNIC
-
-   EMail: gih@apnic.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Huston                   Best Current Practice                  [Page 2]
-
-RFC 4159                        ip6.int                      August 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Huston                   Best Current Practice                  [Page 3]
-
diff --git a/doc/rfc/rfc4193.txt b/doc/rfc/rfc4193.txt
deleted file mode 100644
index 17e2c0b4..00000000
--- a/doc/rfc/rfc4193.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Hinden
-Request for Comments: 4193                                         Nokia
-Category: Standards Track                                    B. Haberman
-                                                                 JHU-APL
-                                                            October 2005
-
-
-                  Unique Local IPv6 Unicast Addresses
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document defines an IPv6 unicast address format that is globally
-   unique and is intended for local communications, usually inside of a
-   site.  These addresses are not expected to be routable on the global
-   Internet.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Acknowledgements ................................................3
-   3. Local IPv6 Unicast Addresses ....................................3
-      3.1. Format .....................................................3
-           3.1.1. Background ..........................................4
-      3.2. Global ID ..................................................4
-           3.2.1. Locally Assigned Global IDs .........................5
-           3.2.2. Sample Code for Pseudo-Random Global ID Algorithm ...5
-           3.2.3. Analysis of the Uniqueness of Global IDs ............6
-      3.3. Scope Definition ...........................................6
-   4. Operational Guidelines ..........................................7
-      4.1. Routing ....................................................7
-      4.2. Renumbering and Site Merging ...............................7
-      4.3. Site Border Router and Firewall Packet Filtering ...........8
-      4.4. DNS Issues .................................................8
-      4.5. Application and Higher Level Protocol Issues ...............9
-      4.6. Use of Local IPv6 Addresses for Local Communication ........9
-      4.7. Use of Local IPv6 Addresses with VPNs .....................10
-
-
-
-Hinden & Haberman           Standards Track                     [Page 1]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   5. Global Routing Considerations ..................................11
-      5.1. From the Standpoint of the Internet .......................11
-      5.2. From the Standpoint of a Site .............................11
-   6. Advantages and Disadvantages ...................................12
-      6.1. Advantages ................................................12
-      6.2. Disadvantages .............................................13
-   7. Security Considerations ........................................13
-   8. IANA Considerations ............................................13
-   9. References .....................................................13
-      9.1. Normative References ......................................13
-      9.2. Informative References ....................................14
-
-1.  Introduction
-
-   This document defines an IPv6 unicast address format that is globally
-   unique and is intended for local communications [IPV6].  These
-   addresses are called Unique Local IPv6 Unicast Addresses and are
-   abbreviated in this document as Local IPv6 addresses.  They are not
-   expected to be routable on the global Internet.  They are routable
-   inside of a more limited area such as a site.  They may also be
-   routed between a limited set of sites.
-
-   Local IPv6 unicast addresses have the following characteristics:
-
-      - Globally unique prefix (with high probability of uniqueness).
-
-      - Well-known prefix to allow for easy filtering at site
-        boundaries.
-
-      - Allow sites to be combined or privately interconnected without
-        creating any address conflicts or requiring renumbering of
-        interfaces that use these prefixes.
-
-      - Internet Service Provider independent and can be used for
-        communications inside of a site without having any permanent or
-        intermittent Internet connectivity.
-
-      - If accidentally leaked outside of a site via routing or DNS,
-        there is no conflict with any other addresses.
-
-      - In practice, applications may treat these addresses like global
-        scoped addresses.
-
-   This document defines the format of Local IPv6 addresses, how to
-   allocate them, and usage considerations including routing, site
-   border routers, DNS, application support, VPN usage, and guidelines
-   for how to use for local communication inside a site.
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 2]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Acknowledgements
-
-   The underlying idea of creating Local IPv6 addresses described in
-   this document has been proposed a number of times by a variety of
-   people.  The authors of this document do not claim exclusive credit.
-   Credit goes to Brian Carpenter, Christian Huitema, Aidan Williams,
-   Andrew White, Charlie Perkins, and many others.  The authors would
-   also like to thank Brian Carpenter, Charlie Perkins, Harald
-   Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens, Alan
-   Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian Huitema, Tim
-   Chown, Steve Bellovin, Alex Zinin, Tony Hain, Bill Fenner, Sam
-   Hartman, and Elwyn Davies for their comments and suggestions on this
-   document.
-
-3.  Local IPv6 Unicast Addresses
-
-3.1.  Format
-
-   The Local IPv6 addresses are created using a pseudo-randomly
-   allocated global ID.  They have the following format:
-
-      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
-      +--------+-+------------+-----------+----------------------------+
-      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
-      +--------+-+------------+-----------+----------------------------+
-
-   Where:
-
-      Prefix            FC00::/7 prefix to identify Local IPv6 unicast
-                        addresses.
-
-      L                 Set to 1 if the prefix is locally assigned.
-                        Set to 0 may be defined in the future.  See
-                        Section 3.2 for additional information.
-
-      Global ID         40-bit global identifier used to create a
-                        globally unique prefix.  See Section 3.2 for
-                        additional information.
-
-      Subnet ID         16-bit Subnet ID is an identifier of a subnet
-                        within the site.
-
-      Interface ID      64-bit Interface ID as defined in [ADDARCH].
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 3]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-3.1.1.  Background
-
-   There were a range of choices available when choosing the size of the
-   prefix and Global ID field length.  There is a direct tradeoff
-   between having a Global ID field large enough to support foreseeable
-   future growth and not using too much of the IPv6 address space
-   needlessly.  A reasonable way of evaluating a specific field length
-   is to compare it to a projected 2050 world population of 9.3 billion
-   [POPUL] and the number of resulting /48 prefixes per person.  A range
-   of prefix choices is shown in the following table:
-
-    Prefix  Global ID     Number of          Prefixes    % of IPv6
-            Length        /48 Prefixes       per Person  Address Space
-
-    /11       37           137,438,953,472     15         0.049%
-    /10       38           274,877,906,944     30         0.098%
-    /9        39           549,755,813,888     59         0.195%
-    /8        40         1,099,511,627,776    118         0.391%
-    /7        41         2,199,023,255,552    236         0.781%
-    /6        42         4,398,046,511,104    473         1.563%
-
-   A very high utilization ratio of these allocations can be assumed
-   because the Global ID field does not require internal structure, and
-   there is no reason to be able to aggregate the prefixes.
-
-   The authors believe that a /7 prefix resulting in a 41-bit Global ID
-   space (including the L bit) is a good choice.  It provides for a
-   large number of assignments (i.e., 2.2 trillion) and at the same time
-   uses less than .8% of the total IPv6 address space.  It is unlikely
-   that this space will be exhausted.  If more than this were to be
-   needed, then additional IPv6 address space could be allocated for
-   this purpose.
-
-3.2.  Global ID
-
-   The allocation of Global IDs is pseudo-random [RANDOM].  They MUST
-   NOT be assigned sequentially or with well-known numbers.  This is to
-   ensure that there is not any relationship between allocations and to
-   help clarify that these prefixes are not intended to be routed
-   globally.  Specifically, these prefixes are not designed to
-   aggregate.
-
-   This document defines a specific local method to allocate Global IDs,
-   indicated by setting the L bit to 1.  Another method, indicated by
-   clearing the L bit, may be defined later.  Apart from the allocation
-   method, all Local IPv6 addresses behave and are treated identically.
-
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 4]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   The local assignments are self-generated and do not need any central
-   coordination or assignment, but have an extremely high probability of
-   being unique.
-
-3.2.1.  Locally Assigned Global IDs
-
-   Locally assigned Global IDs MUST be generated with a pseudo-random
-   algorithm consistent with [RANDOM].  Section 3.2.2 describes a
-   suggested algorithm.  It is important that all sites generating
-   Global IDs use a functionally similar algorithm to ensure there is a
-   high probability of uniqueness.
-
-   The use of a pseudo-random algorithm to generate Global IDs in the
-   locally assigned prefix gives an assurance that any network numbered
-   using such a prefix is highly unlikely to have that address space
-   clash with any other network that has another locally assigned prefix
-   allocated to it.  This is a particularly useful property when
-   considering a number of scenarios including networks that merge,
-   overlapping VPN address space, or hosts mobile between such networks.
-
-3.2.2.  Sample Code for Pseudo-Random Global ID Algorithm
-
-   The algorithm described below is intended to be used for locally
-   assigned Global IDs.  In each case the resulting global ID will be
-   used in the appropriate prefix as defined in Section 3.2.
-
-     1) Obtain the current time of day in 64-bit NTP format [NTP].
-
-     2) Obtain an EUI-64 identifier from the system running this
-        algorithm.  If an EUI-64 does not exist, one can be created from
-        a 48-bit MAC address as specified in [ADDARCH].  If an EUI-64
-        cannot be obtained or created, a suitably unique identifier,
-        local to the node, should be used (e.g., system serial number).
-
-     3) Concatenate the time of day with the system-specific identifier
-        in order to create a key.
-
-     4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
-        the resulting value is 160 bits.
-
-     5) Use the least significant 40 bits as the Global ID.
-
-     6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global
-        ID to create a Local IPv6 address prefix.
-
-   This algorithm will result in a Global ID that is reasonably unique
-   and can be used to create a locally assigned Local IPv6 address
-   prefix.
-
-
-
-Hinden & Haberman           Standards Track                     [Page 5]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-3.2.3.  Analysis of the Uniqueness of Global IDs
-
-   The selection of a pseudo random Global ID is similar to the
-   selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of
-   [RTP].  This analysis is adapted from that document.
-
-   Since Global IDs are chosen randomly (and independently), it is
-   possible that separate networks have chosen the same Global ID.  For
-   any given network, with one or more random Global IDs, that has
-   inter-connections to other such networks, having a total of N such
-   IDs, the probability that two or more of these IDs will collide can
-   be approximated using the formula:
-
-      P = 1 - exp(-N**2 / 2**(L+1))
-
-   where P is the probability of collision, N is the number of
-   interconnected Global IDs, and L is the length of the Global ID.
-
-   The following table shows the probability of a collision for a range
-   of connections using a 40-bit Global ID field.
-
-      Connections      Probability of Collision
-
-          2                1.81*10^-12
-         10                4.54*10^-11
-        100                4.54*10^-09
-       1000                4.54*10^-07
-      10000                4.54*10^-05
-
-   Based on this analysis, the uniqueness of locally generated Global
-   IDs is adequate for sites planning a small to moderate amount of
-   inter-site communication using locally generated Global IDs.
-
-3.3.  Scope Definition
-
-   By default, the scope of these addresses is global.  That is, they
-   are not limited by ambiguity like the site-local addresses defined in
-   [ADDARCH].  Rather, these prefixes are globally unique, and as such,
-   their applicability is greater than site-local addresses.  Their
-   limitation is in the routability of the prefixes, which is limited to
-   a site and any explicit routing agreements with other sites to
-   propagate them (also see Section 4.1).  Also, unlike site-locals, a
-   site may have more than one of these prefixes and use them at the
-   same time.
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 6]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-4.  Operational Guidelines
-
-   The guidelines in this section do not require any change to the
-   normal routing and forwarding functionality in an IPv6 host or
-   router.  These are configuration and operational usage guidelines.
-
-4.1.  Routing
-
-   Local IPv6 addresses are designed to be routed inside of a site in
-   the same manner as other types of unicast addresses.  They can be
-   carried in any IPv6 routing protocol without any change.
-
-   It is expected that they would share the same Subnet IDs with
-   provider-based global unicast addresses, if they were being used
-   concurrently [GLOBAL].
-
-   The default behavior of exterior routing protocol sessions between
-   administrative routing regions must be to ignore receipt of and not
-   advertise prefixes in the FC00::/7 block.  A network operator may
-   specifically configure prefixes longer than FC00::/7 for inter-site
-   communication.
-
-   If BGP is being used at the site border with an ISP, the default BGP
-   configuration must filter out any Local IPv6 address prefixes, both
-   incoming and outgoing.  It must be set both to keep any Local IPv6
-   address prefixes from being advertised outside of the site as well as
-   to keep these prefixes from being learned from another site.  The
-   exception to this is if there are specific /48 or longer routes
-   created for one or more Local IPv6 prefixes.
-
-   For link-state IGPs, it is suggested that a site utilizing IPv6 local
-   address prefixes be contained within one IGP domain or area.  By
-   containing an IPv6 local address prefix to a single link-state area
-   or domain, the distribution of prefixes can be controlled.
-
-4.2.  Renumbering and Site Merging
-
-   The use of Local IPv6 addresses in a site results in making
-   communication that uses these addresses independent of renumbering a
-   site's provider-based global addresses.
-
-   When merging multiple sites, the addresses created with these
-   prefixes are unlikely to need to be renumbered because all of the
-   addresses have a high probability of being unique.  Routes for each
-   specific prefix would have to be configured to allow routing to work
-   correctly between the formerly separate sites.
-
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 7]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-4.3.  Site Border Router and Firewall Packet Filtering
-
-   While no serious harm will be done if packets with these addresses
-   are sent outside of a site via a default route, it is recommended
-   that routers be configured by default to keep any packets with Local
-   IPv6 addresses from leaking outside of the site and to keep any site
-   prefixes from being advertised outside of their site.
-
-   Site border routers and firewalls should be configured to not forward
-   any packets with Local IPv6 source or destination addresses outside
-   of the site, unless they have been explicitly configured with routing
-   information about specific /48 or longer Local IPv6 prefixes.  This
-   will ensure that packets with Local IPv6 destination addresses will
-   not be forwarded outside of the site via a default route.  The
-   default behavior of these devices should be to install a "reject"
-   route for these prefixes.  Site border routers should respond with
-   the appropriate ICMPv6 Destination Unreachable message to inform the
-   source that the packet was not forwarded. [ICMPV6].  This feedback is
-   important to avoid transport protocol timeouts.
-
-   Routers that maintain peering arrangements between Autonomous Systems
-   throughout the Internet should obey the recommendations for site
-   border routers, unless configured otherwise.
-
-4.4.  DNS Issues
-
-   At the present time, AAAA and PTR records for locally assigned local
-   IPv6 addresses are not recommended to be installed in the global DNS.
-
-   For background on this recommendation, one of the concerns about
-   adding AAAA and PTR records to the global DNS for locally assigned
-   Local IPv6 addresses stems from the lack of complete assurance that
-   the prefixes are unique.  There is a small possibility that the same
-   locally assigned IPv6 Local addresses will be used by two different
-   organizations both claiming to be authoritative with different
-   contents.  In this scenario, it is likely there will be a connection
-   attempt to the closest host with the corresponding locally assigned
-   IPv6 Local address.  This may result in connection timeouts,
-   connection failures indicated by ICMP Destination Unreachable
-   messages, or successful connections to the wrong host.  Due to this
-   concern, adding AAAA records for these addresses to the global DNS is
-   thought to be unwise.
-
-   Reverse (address-to-name) queries for locally assigned IPv6 Local
-   addresses MUST NOT be sent to name servers for the global DNS, due to
-   the load that such queries would create for the authoritative name
-   servers for the ip6.arpa zone.  This form of query load is not
-   specific to locally assigned Local IPv6 addresses; any current form
-
-
-
-Hinden & Haberman           Standards Track                     [Page 8]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   of local addressing creates additional load of this kind, due to
-   reverse queries leaking out of the site.  However, since allowing
-   such queries to escape from the site serves no useful purpose, there
-   is no good reason to make the existing load problems worse.
-
-   The recommended way to avoid sending such queries to nameservers for
-   the global DNS is for recursive name server implementations to act as
-   if they were authoritative for an empty d.f.ip6.arpa zone and return
-   RCODE 3 for any such query.  Implementations that choose this
-   strategy should allow it to be overridden, but returning an RCODE 3
-   response for such queries should be the default, both because this
-   will reduce the query load problem and also because, if the site
-   administrator has not set up the reverse tree corresponding to the
-   locally assigned IPv6 Local addresses in use, returning RCODE 3 is in
-   fact the correct answer.
-
-4.5.  Application and Higher Level Protocol Issues
-
-   Application and other higher level protocols can treat Local IPv6
-   addresses in the same manner as other types of global unicast
-   addresses.  No special handling is required.  This type of address
-   may not be reachable, but that is no different from other types of
-   IPv6 global unicast address.  Applications need to be able to handle
-   multiple addresses that may or may not be reachable at any point in
-   time.  In most cases, this complexity should be hidden in APIs.
-
-   From a host's perspective, the difference between Local IPv6 and
-   other types of global unicast addresses shows up as different
-   reachability and could be handled by default in that way.  In some
-   cases, it is better for nodes and applications to treat them
-   differently from global unicast addresses.  A starting point might be
-   to give them preference over global unicast, but fall back to global
-   unicast if a particular destination is found to be unreachable.  Much
-   of this behavior can be controlled by how they are allocated to nodes
-   and put into the DNS.  However, it is useful if a host can have both
-   types of addresses and use them appropriately.
-
-   Note that the address selection mechanisms of [ADDSEL], and in
-   particular the policy override mechanism replacing default address
-   selection, are expected to be used on a site where Local IPv6
-   addresses are configured.
-
-4.6.  Use of Local IPv6 Addresses for Local Communication
-
-   Local IPv6 addresses, like global scope unicast addresses, are only
-   assigned to nodes if their use has been enabled (via IPv6 address
-   autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually).  They are
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 9]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   not created automatically in the way that IPv6 link-local addresses
-   are and will not appear or be used unless they are purposely
-   configured.
-
-   In order for hosts to autoconfigure Local IPv6 addresses, routers
-   have to be configured to advertise Local IPv6 /64 prefixes in router
-   advertisements, or a DHCPv6 server must have been configured to
-   assign them.  In order for a node to learn the Local IPv6 address of
-   another node, the Local IPv6 address must have been installed in a
-   naming system (e.g., DNS, proprietary naming system, etc.)  For these
-   reasons, controlling their usage in a site is straightforward.
-
-   To limit the use of Local IPv6 addresses the following guidelines
-   apply:
-
-      - Nodes that are to only be reachable inside of a site:  The local
-        DNS should be configured to only include the Local IPv6
-        addresses of these nodes.  Nodes with only Local IPv6 addresses
-        must not be installed in the global DNS.
-
-      - Nodes that are to be limited to only communicate with other
-        nodes in the site:  These nodes should be set to only
-        autoconfigure Local IPv6 addresses via [ADDAUTO] or to only
-        receive Local IPv6 addresses via [DHCP6].  Note: For the case
-        where both global and Local IPv6 prefixes are being advertised
-        on a subnet, this will require a switch in the devices to only
-        autoconfigure Local IPv6 addresses.
-
-      - Nodes that are to be reachable from inside of the site and from
-        outside of the site:  The DNS should be configured to include
-        the global addresses of these nodes.  The local DNS may be
-        configured to also include the Local IPv6 addresses of these
-        nodes.
-
-      - Nodes that can communicate with other nodes inside of the site
-        and outside of the site: These nodes should autoconfigure global
-        addresses via [ADDAUTO] or receive global address via [DHCP6].
-        They may also obtain Local IPv6 addresses via the same
-        mechanisms.
-
-4.7.  Use of Local IPv6 Addresses with VPNs
-
-   Local IPv6 addresses can be used for inter-site Virtual Private
-   Networks (VPN) if appropriate routes are set up.  Because the
-   addresses are unique, these VPNs will work reliably and without the
-   need for translation.  They have the additional property that they
-   will continue to work if the individual sites are renumbered or
-   merged.
-
-
-
-Hinden & Haberman           Standards Track                    [Page 10]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-5.  Global Routing Considerations
-
-   Section 4.1 provides operational guidelines that forbid default
-   routing of local addresses between sites.  Concerns were raised to
-   the IPv6 working group and to the IETF as a whole that sites may
-   attempt to use local addresses as globally routed provider-
-   independent addresses.  This section describes why using local
-   addresses as globally-routed provider-independent addresses is
-   unadvisable.
-
-5.1.  From the Standpoint of the Internet
-
-   There is a mismatch between the structure of IPv6 local addresses and
-   the normal IPv6 wide area routing model.  The /48 prefix of an IPv6
-   local addresses fits nowhere in the normal hierarchy of IPv6 unicast
-   addresses.  Normal IPv6 unicast addresses can be routed
-   hierarchically down to physical subnet (link) level and only have to
-   be flat-routed on the physical subnet.  IPv6 local addresses would
-   have to be flat-routed even over the wide area Internet.
-
-   Thus, packets whose destination address is an IPv6 local address
-   could be routed over the wide area only if the corresponding /48
-   prefix were carried by the wide area routing protocol in use, such as
-   BGP.  This contravenes the operational assumption that long prefixes
-   will be aggregated into many fewer short prefixes, to limit the table
-   size and convergence time of the routing protocol.  If a network uses
-   both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these
-   types of addresses will certainly not aggregate with each other,
-   since they differ from the most significant bit onwards.  Neither
-   will IPv6 local addresses aggregate with each other, due to their
-   random bit patterns.  This means that there would be a very
-   significant operational penalty for attempting to use IPv6 local
-   address prefixes generically with currently known wide area routing
-   technology.
-
-5.2.  From the Standpoint of a Site
-
-   There are a number of design factors in IPv6 local addresses that
-   reduce the likelihood that IPv6 local addresses will be used as
-   arbitrary global unicast addresses.  These include:
-
-      - The default rules to filter packets and routes make it very
-        difficult to use IPv6 local addresses for arbitrary use across
-        the Internet.  For a site to use them as general purpose unicast
-        addresses, it would have to make sure that the default rules
-        were not being used by all other sites and intermediate ISPs
-        used for their current and future communication.
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 11]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-      - They are not mathematically guaranteed to be unique and are not
-        registered in public databases.  Collisions, while highly
-        unlikely, are possible and a collision can compromise the
-        integrity of the communications.  The lack of public
-        registration creates operational problems.
-
-      - The addresses are allocated randomly.  If a site had multiple
-        prefixes that it wanted to be used globally, the cost of
-        advertising them would be very high because they could not be
-        aggregated.
-
-      - They have a long prefix (i.e., /48) so a single local address
-        prefix doesn't provide enough address space to be used
-        exclusively by the largest organizations.
-
-6.  Advantages and Disadvantages
-
-6.1.  Advantages
-
-   This approach has the following advantages:
-
-      - Provides Local IPv6 prefixes that can be used independently of
-        any provider-based IPv6 unicast address allocations.  This is
-        useful for sites not always connected to the Internet or sites
-        that wish to have a distinct prefix that can be used to localize
-        traffic inside of the site.
-
-      - Applications can treat these addresses in an identical manner as
-        any other type of global IPv6 unicast addresses.
-
-      - Sites can be merged without any renumbering of the Local IPv6
-        addresses.
-
-      - Sites can change their provider-based IPv6 unicast address
-        without disrupting any communication that uses Local IPv6
-        addresses.
-
-      - Well-known prefix that allows for easy filtering at site
-        boundary.
-
-      - Can be used for inter-site VPNs.
-
-      - If accidently leaked outside of a site via routing or DNS, there
-        is no conflict with any other addresses.
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 12]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-6.2.  Disadvantages
-
-   This approach has the following disadvantages:
-
-      - Not possible to route Local IPv6 prefixes on the global Internet
-        with current routing technology.  Consequentially, it is
-        necessary to have the default behavior of site border routers to
-        filter these addresses.
-
-      - There is a very low probability of non-unique locally assigned
-        Global IDs being generated by the algorithm in Section 3.2.3.
-        This risk can be ignored for all practical purposes, but it
-        leads to a theoretical risk of clashing address prefixes.
-
-7.  Security Considerations
-
-   Local IPv6 addresses do not provide any inherent security to the
-   nodes that use them.  They may be used with filters at site
-   boundaries to keep Local IPv6 traffic inside of the site, but this is
-   no more or less secure than filtering any other type of global IPv6
-   unicast addresses.
-
-   Local IPv6 addresses do allow for address-based security mechanisms,
-   including IPsec, across end to end VPN connections.
-
-8.  IANA Considerations
-
-   The IANA has assigned the FC00::/7 prefix to "Unique Local Unicast".
-
-9.  References
-
-9.1.  Normative References
-
-   [ADDARCH]  Hinden, R. and S. Deering, "Internet Protocol Version 6
-             (IPv6) Addressing Architecture", RFC 3513, April 2003.
-
-   [FIPS]    "Federal Information Processing Standards Publication",
-             (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
-
-   [GLOBAL]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
-             Unicast Address Format", RFC 3587, August 2003.
-
-   [ICMPV6]  Conta, A. and S. Deering, "Internet Control Message
-             Protocol (ICMPv6) for the Internet Protocol Version 6
-             (IPv6) Specification", RFC 2463, December 1998.
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 13]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
-             (IPv6) Specification", RFC 2460, December 1998.
-
-   [NTP]     Mills, D., "Network Time Protocol (Version 3)
-             Specification, Implementation and Analysis", RFC 1305,
-             March 1992.
-
-   [RANDOM]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-             "Randomness Requirements for Security", BCP 106, RFC 4086,
-             June 2005.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [SHA1]    Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
-             (SHA1)", RFC 3174, September 2001.
-
-9.2.  Informative References
-
-   [ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address
-             Autoconfiguration", RFC 2462, December 1998.
-
-   [ADDSEL]  Draves, R., "Default Address Selection for Internet
-             Protocol version 6 (IPv6)", RFC 3484, February 2003.
-
-   [DHCP6]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
-             M. Carney, "Dynamic Host Configuration Protocol for IPv6
-             (DHCPv6)", RFC 3315, July 2003.
-
-   [POPUL]   Population Reference Bureau, "World Population Data Sheet
-             of the Population Reference Bureau 2002",  August 2002.
-
-   [RTP]     Schulzrinne, H.,  Casner, S., Frederick, R., and V.
-             Jacobson, "RTP: A Transport Protocol for Real-Time
-             Applications", STD 64, RFC 3550, July 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 14]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-Authors' Addresses
-
-   Robert M. Hinden
-   Nokia
-   313 Fairchild Drive
-   Mountain View, CA 94043
-   USA
-
-   Phone: +1 650 625-2004
-   EMail: bob.hinden@nokia.com
-
-
-   Brian Haberman
-   Johns Hopkins University
-   Applied Physics Lab
-   11100 Johns Hopkins Road
-   Laurel, MD 20723
-   USA
-
-   Phone: +1 443 778 1319
-   EMail: brian@innovationslab.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 15]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 16]
-
diff --git a/doc/rfc/rfc4255.txt b/doc/rfc/rfc4255.txt
deleted file mode 100644
index f350b7af..00000000
--- a/doc/rfc/rfc4255.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        J. Schlyter
-Request for Comments: 4255                                       OpenSSH
-Category: Standards Track                                     W. Griffin
-                                                                  SPARTA
-                                                            January 2006
-
-
-   Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a method of verifying Secure Shell (SSH) host
-   keys using Domain Name System Security (DNSSEC).  The document
-   defines a new DNS resource record that contains a standard SSH key
-   fingerprint.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. SSH Host Key Verification .......................................2
-      2.1. Method .....................................................2
-      2.2. Implementation Notes .......................................2
-      2.3. Fingerprint Matching .......................................3
-      2.4. Authentication .............................................3
-   3. The SSHFP Resource Record .......................................3
-      3.1. The SSHFP RDATA Format .....................................4
-           3.1.1. Algorithm Number Specification ......................4
-           3.1.2. Fingerprint Type Specification ......................4
-           3.1.3. Fingerprint .........................................5
-      3.2. Presentation Format of the SSHFP RR ........................5
-   4. Security Considerations .........................................5
-   5. IANA Considerations .............................................6
-   6. Normative References ............................................7
-   7. Informational References ........................................7
-   8. Acknowledgements ................................................8
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 1]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-1.  Introduction
-
-   The SSH [6] protocol provides secure remote login and other secure
-   network services over an insecure network.  The security of the
-   connection relies on the server authenticating itself to the client
-   as well as the user authenticating itself to the server.
-
-   If a connection is established to a server whose public key is not
-   already known to the client, a fingerprint of the key is presented to
-   the user for verification.  If the user decides that the fingerprint
-   is correct and accepts the key, the key is saved locally and used for
-   verification for all following connections.  While some security-
-   conscious users verify the fingerprint out-of-band before accepting
-   the key, many users blindly accept the presented key.
-
-   The method described here can provide out-of-band verification by
-   looking up a fingerprint of the server public key in the DNS [1][2]
-   and using DNSSEC [5] to verify the lookup.
-
-   In order to distribute the fingerprint using DNS, this document
-   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
-
-   Basic understanding of the DNS system [1][2] and the DNS security
-   extensions [5] is assumed by this document.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [3].
-
-2.  SSH Host Key Verification
-
-2.1.  Method
-
-   Upon connection to an SSH server, the SSH client MAY look up the
-   SSHFP resource record(s) for the host it is connecting to.  If the
-   algorithm and fingerprint of the key received from the SSH server
-   match the algorithm and fingerprint of one of the SSHFP resource
-   record(s) returned from DNS, the client MAY accept the identity of
-   the server.
-
-2.2.  Implementation Notes
-
-   Client implementors SHOULD provide a configurable policy used to
-   select the order of methods used to verify a host key.  This document
-   defines one method: Fingerprint storage in DNS.  Another method
-   defined in the SSH Architecture [6] uses local files to store keys
-   for comparison.  Other methods that could be defined in the future
-   might include storing fingerprints in LDAP or other databases.  A
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 2]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-   configurable policy will allow administrators to determine which
-   methods they want to use and in what order the methods should be
-   prioritized.  This will allow administrators to determine how much
-   trust they want to place in the different methods.
-
-   One specific scenario for having a configurable policy is where
-   clients do not use fully qualified host names to connect to servers.
-   In this scenario, the implementation SHOULD verify the host key
-   against a local database before verifying the key via the fingerprint
-   returned from DNS.  This would help prevent an attacker from
-   injecting a DNS search path into the local resolver and forcing the
-   client to connect to a different host.
-
-2.3.  Fingerprint Matching
-
-   The public key and the SSHFP resource record are matched together by
-   comparing algorithm number and fingerprint.
-
-      The public key algorithm and the SSHFP algorithm number MUST
-      match.
-
-      A message digest of the public key, using the message digest
-      algorithm specified in the SSHFP fingerprint type, MUST match the
-      SSHFP fingerprint.
-
-2.4.  Authentication
-
-   A public key verified using this method MUST NOT be trusted if the
-   SSHFP resource record (RR) used for verification was not
-   authenticated by a trusted SIG RR.
-
-   Clients that do validate the DNSSEC signatures themselves SHOULD use
-   standard DNSSEC validation procedures.
-
-   Clients that do not validate the DNSSEC signatures themselves MUST
-   use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8])
-   between themselves and the entity performing the signature
-   validation.
-
-3.  The SSHFP Resource Record
-
-   The SSHFP resource record (RR) is used to store a fingerprint of an
-   SSH public host key that is associated with a Domain Name System
-   (DNS) name.
-
-   The RR type code for the SSHFP RR is 44.
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 3]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-3.1.  The SSHFP RDATA Format
-
-   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
-   type and the fingerprint of the public host key.
-
-       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |   algorithm   |    fp type    |                               /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
-       /                                                               /
-       /                          fingerprint                          /
-       /                                                               /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-3.1.1.  Algorithm Number Specification
-
-   This algorithm number octet describes the algorithm of the public
-   key.  The following values are assigned:
-
-          Value    Algorithm name
-          -----    --------------
-          0        reserved
-          1        RSA
-          2        DSS
-
-   Reserving other types requires IETF consensus [4].
-
-3.1.2.  Fingerprint Type Specification
-
-   The fingerprint type octet describes the message-digest algorithm
-   used to calculate the fingerprint of the public key.  The following
-   values are assigned:
-
-          Value    Fingerprint type
-          -----    ----------------
-          0        reserved
-          1        SHA-1
-
-   Reserving other types requires IETF consensus [4].
-
-   For interoperability reasons, as few fingerprint types as possible
-   should be reserved.  The only reason to reserve additional types is
-   to increase security.
-
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 4]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-3.1.3.  Fingerprint
-
-   The fingerprint is calculated over the public key blob as described
-   in [7].
-
-   The message-digest algorithm is presumed to produce an opaque octet
-   string output, which is placed as-is in the RDATA fingerprint field.
-
-3.2.  Presentation Format of the SSHFP RR
-
-   The RDATA of the presentation format of the SSHFP resource record
-   consists of two numbers (algorithm and fingerprint type) followed by
-   the fingerprint itself, presented in hex, e.g.:
-
-       host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
-
-   The use of mnemonics instead of numbers is not allowed.
-
-4.  Security Considerations
-
-   Currently, the amount of trust a user can realistically place in a
-   server key is proportional to the amount of attention paid to
-   verifying that the public key presented actually corresponds to the
-   private key of the server.  If a user accepts a key without verifying
-   the fingerprint with something learned through a secured channel, the
-   connection is vulnerable to a man-in-the-middle attack.
-
-   The overall security of using SSHFP for SSH host key verification is
-   dependent on the security policies of the SSH host administrator and
-   DNS zone administrator (in transferring the fingerprint), detailed
-   aspects of how verification is done in the SSH implementation, and in
-   the client's diligence in accessing the DNS in a secure manner.
-
-   One such aspect is in which order fingerprints are looked up (e.g.,
-   first checking local file and then SSHFP).  We note that, in addition
-   to protecting the first-time transfer of host keys, SSHFP can
-   optionally be used for stronger host key protection.
-
-      If SSHFP is checked first, new SSH host keys may be distributed by
-      replacing the corresponding SSHFP in DNS.
-
-      If SSH host key verification can be configured to require SSHFP,
-      SSH host key revocation can be implemented by removing the
-      corresponding SSHFP from DNS.
-
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 5]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-   As stated in Section 2.2, we recommend that SSH implementors provide
-   a policy mechanism to control the order of methods used for host key
-   verification.  One specific scenario for having a configurable policy
-   is where clients use unqualified host names to connect to servers.
-   In this case, we recommend that SSH implementations check the host
-   key against a local database before verifying the key via the
-   fingerprint returned from DNS.  This would help prevent an attacker
-   from injecting a DNS search path into the local resolver and forcing
-   the client to connect to a different host.
-
-   A different approach to solve the DNS search path issue would be for
-   clients to use a trusted DNS search path, i.e., one not acquired
-   through DHCP or other autoconfiguration mechanisms.  Since there is
-   no way with current DNS lookup APIs to tell whether a search path is
-   from a trusted source, the entire client system would need to be
-   configured with this trusted DNS search path.
-
-   Another dependency is on the implementation of DNSSEC itself.  As
-   stated in Section 2.4, we mandate the use of secure methods for
-   lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
-   is especially important if SSHFP is to be used as a basis for host
-   key rollover and/or revocation, as described above.
-
-   Since DNSSEC only protects the integrity of the host key fingerprint
-   after it is signed by the DNS zone administrator, the fingerprint
-   must be transferred securely from the SSH host administrator to the
-   DNS zone administrator.  This could be done manually between the
-   administrators or automatically using secure DNS dynamic update [11]
-   between the SSH server and the nameserver.  We note that this is no
-   different from other key enrollment situations, e.g., a client
-   sending a certificate request to a certificate authority for signing.
-
-5.  IANA Considerations
-
-   IANA has allocated the RR type code 44 for SSHFP from the standard RR
-   type space.
-
-   IANA has opened a new registry for the SSHFP RR type for public key
-   algorithms.  The defined types are:
-
-      0 is reserved
-      1 is RSA
-      2 is DSA
-
-   Adding new reservations requires IETF consensus [4].
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 6]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-   IANA has opened a new registry for the SSHFP RR type for fingerprint
-   types.  The defined types are:
-
-      0 is reserved
-      1 is SHA-1
-
-   Adding new reservations requires IETF consensus [4].
-
-6.  Normative References
-
-   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
-         13, RFC 1034, November 1987.
-
-   [2]   Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-         Considerations Section in RFCs", BCP 26, RFC 2434, October
-         1998.
-
-   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033, March
-         2005.
-
-         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Protocol Modifications for the DNS Security Extensions", RFC
-         4035, March 2005.
-
-   [6]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
-         Protocol Architecture", RFC 4251, January 2006.
-
-   [7]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
-         Transport Layer Protocol", RFC 4253, January 2006.
-
-7.  Informational References
-
-   [8]   Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
-         Roadmap", RFC 2411, November 1998.
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 7]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-   [9]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-         Wellington, "Secret Key Transaction Authentication for DNS
-         (TSIG)", RFC 2845, May 2000.
-
-   [10]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
-         ( SIG(0)s )", RFC 2931, September 2000.
-
-   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-         Update", RFC 3007, November 2000.
-
-8.  Acknowledgements
-
-   The authors gratefully acknowledge, in no particular order, the
-   contributions of the following persons:
-
-      Martin Fredriksson
-
-      Olafur Gudmundsson
-
-      Edward Lewis
-
-      Bill Sommerfeld
-
-Authors' Addresses
-
-   Jakob Schlyter
-   OpenSSH
-   812 23rd Avenue SE
-   Calgary, Alberta  T2G 1N8
-   Canada
-
-   EMail: jakob@openssh.com
-   URI:   http://www.openssh.com/
-
-
-   Wesley Griffin
-   SPARTA
-   7075 Samuel Morse Drive
-   Columbia, MD  21046
-   USA
-
-   EMail: wgriffin@sparta.com
-   URI:   http://www.sparta.com/
-
-
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 8]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 9]
-
diff --git a/doc/rfc/rfc4294.txt b/doc/rfc/rfc4294.txt
deleted file mode 100644
index 8fea5c31..00000000
--- a/doc/rfc/rfc4294.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   J. Loughney, Ed.
-Request for Comments: 4294                                         Nokia
-Category: Informational                                       April 2006
-
-
-                         IPv6 Node Requirements
-
-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 requirements for IPv6 nodes.  It is expected
-   that IPv6 will be deployed in a wide range of devices and situations.
-   Specifying the requirements for IPv6 nodes allows IPv6 to function
-   well and interoperate in a large number of situations and
-   deployments.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-      1.1. Requirement Language .......................................3
-      1.2. Scope of This Document .....................................3
-      1.3. Description of IPv6 Nodes ..................................3
-   2. Abbreviations Used in This Document .............................3
-   3. Sub-IP Layer ....................................................4
-      3.1. Transmission of IPv6 Packets over Ethernet Networks
-           - RFC 2464 .................................................4
-      3.2. IP version 6 over PPP - RFC 2472 ...........................4
-      3.3. IPv6 over ATM Networks - RFC 2492 ..........................4
-   4. IP Layer ........................................................5
-      4.1. Internet Protocol Version 6 - RFC 2460 .....................5
-      4.2. Neighbor Discovery for IPv6 - RFC 2461 .....................5
-      4.3. Path MTU Discovery and Packet Size .........................6
-      4.4. ICMP for the Internet Protocol Version 6 (IPv6) -
-           RFC 2463 ...................................................7
-      4.5. Addressing .................................................7
-      4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 .....8
-   5. DNS and DHCP ....................................................8
-      5.1. DNS ........................................................8
-
-
-
-
-Loughney                     Informational                      [Page 1]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-      5.2. Dynamic Host Configuration Protocol for IPv6
-           (DHCPv6) - RFC 3315 ........................................9
-   6. IPv4 Support and Transition ....................................10
-      6.1. Transition Mechanisms .....................................10
-   7. Mobile IP ......................................................10
-   8. Security .......................................................10
-      8.1. Basic Architecture ........................................10
-      8.2. Security Protocols ........................................11
-      8.3. Transforms and Algorithms .................................11
-      8.4. Key Management Methods ....................................12
-   9. Router-Specific Functionality ..................................12
-      9.1. General ...................................................12
-   10. Network Management ............................................12
-      10.1. Management Information Base Modules (MIBs) ...............12
-   11. Security Considerations .......................................13
-   12. References ....................................................13
-      12.1. Normative References .....................................13
-      12.2. Informative References ...................................16
-   13. Authors and Acknowledgements ..................................18
-
-1.  Introduction
-
-   The goal of this document is to define the common functionality
-   required from both IPv6 hosts and routers.  Many IPv6 nodes will
-   implement optional or additional features, but this document
-   summarizes requirements from other published Standards Track
-   documents in one place.
-
-   This document tries to avoid discussion of protocol details, and
-   references RFCs for this purpose.  This document is informational in
-   nature and does not update Standards Track RFCs.
-
-   Although the document points to different specifications, it should
-   be noted that in most cases, the granularity of requirements are
-   smaller than a single specification, as many specifications define
-   multiple, independent pieces, some of which may not be mandatory.
-
-   As it is not always possible for an implementer to know the exact
-   usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
-   that they should adhere to Jon Postel's Robustness Principle:
-
-      Be conservative in what you do, be liberal in what you accept from
-      others [RFC-793].
-
-
-
-
-
-
-
-
-Loughney                     Informational                      [Page 2]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-1.1.  Requirement Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC-2119].
-
-1.2.  Scope of This Document
-
-   IPv6 covers many specifications.  It is intended that IPv6 will be
-   deployed in many different situations and environments.  Therefore,
-   it is important to develop the requirements for IPv6 nodes to ensure
-   interoperability.
-
-   This document assumes that all IPv6 nodes meet the minimum
-   requirements specified here.
-
-1.3.  Description of IPv6 Nodes
-
-   From the Internet Protocol, Version 6 (IPv6) Specification
-   [RFC-2460], we have the following definitions:
-
-      Description of an IPv6 Node
-
-         -  a device that implements IPv6.
-
-      Description of an IPv6 router
-
-         -  a node that forwards IPv6 packets not explicitly addressed
-            to itself.
-
-      Description of an IPv6 Host
-
-      -  any node that is not a router.
-
-2.  Abbreviations Used in This Document
-
-   ATM   Asynchronous Transfer Mode
-
-   AH    Authentication Header
-
-   DAD   Duplicate Address Detection
-
-   ESP   Encapsulating Security Payload
-
-   ICMP  Internet Control Message Protocol
-
-   IKE   Internet Key Exchange
-
-
-
-
-Loughney                     Informational                      [Page 3]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-   MIB   Management Information Base
-
-   MLD   Multicast Listener Discovery
-
-   MTU   Maximum Transfer Unit
-
-   NA    Neighbor Advertisement
-
-   NBMA  Non-Broadcast Multiple Access
-
-   ND    Neighbor Discovery
-
-   NS    Neighbor Solicitation
-
-   NUD   Neighbor Unreachability Detection
-
-   PPP   Point-to-Point Protocol
-
-   PVC   Permanent Virtual Circuit
-
-   SVC   Switched Virtual Circuit
-
-3.  Sub-IP Layer
-
-   An IPv6 node must include support for one or more IPv6 link-layer
-   specifications.  Which link-layer specifications are included will
-   depend upon what link-layers are supported by the hardware available
-   on the system.  It is possible for a conformant IPv6 node to support
-   IPv6 on some of its interfaces and not on others.
-
-   As IPv6 is run over new layer 2 technologies, it is expected that new
-   specifications will be issued.  This section highlights some major
-   layer 2 technologies and is not intended to be complete.
-
-3.1.  Transmission of IPv6 Packets over Ethernet Networks - RFC 2464
-
-   Nodes supporting IPv6 over Ethernet interfaces MUST implement
-   Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
-
-3.2.  IP version 6 over PPP - RFC 2472
-
-   Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP
-   [RFC-2472].
-
-3.3.  IPv6 over ATM Networks - RFC 2492
-
-   Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM
-   Networks [RFC-2492].  Additionally, RFC 2492 states:
-
-
-
-Loughney                     Informational                      [Page 4]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-      A minimally conforming IPv6/ATM driver SHALL support the PVC mode
-      of operation.  An IPv6/ATM driver that supports the full SVC mode
-      SHALL also support PVC mode of operation.
-
-4.  IP Layer
-
-4.1.  Internet Protocol Version 6 - RFC 2460
-
-   The Internet Protocol Version 6 is specified in [RFC-2460].  This
-   specification MUST be supported.
-
-   Unrecognized options in Hop-by-Hop Options or Destination Options
-   extensions MUST be processed as described in RFC 2460.
-
-   The node MUST follow the packet transmission rules in RFC 2460.
-
-   Nodes MUST always be able to send, receive, and process fragment
-   headers.  All conformant IPv6 implementations MUST be capable of
-   sending and receiving IPv6 packets; the forwarding functionality MAY
-   be supported.
-
-   RFC 2460 specifies extension headers and the processing for these
-   headers.
-
-      A full implementation of IPv6 includes implementation of the
-      following extension headers: Hop-by-Hop Options, Routing (Type 0),
-      Fragment, Destination Options, Authentication and Encapsulating
-      Security Payload [RFC-2460].
-
-   An IPv6 node MUST be able to process these headers.  It should be
-   noted that there is some discussion about the use of Routing Headers
-   and possible security threats [IPv6-RH] that they cause.
-
-4.2.  Neighbor Discovery for IPv6 - RFC 2461
-
-   Neighbor Discovery SHOULD be supported.  [RFC-2461] states:
-
-      "Unless specified otherwise (in a document that covers operating
-      IP over a particular link type) this document applies to all link
-      types.  However, because ND uses link-layer multicast for some of
-      its services, it is possible that on some link types (e.g., NBMA
-      links) alternative protocols or mechanisms to implement those
-      services will be specified (in the appropriate document covering
-      the operation of IP over a particular link type).  The services
-      described in this document that are not directly dependent on
-      multicast, such as Redirects, Next-hop determination, Neighbor
-      Unreachability Detection, etc., are expected to be provided as
-
-
-
-
-Loughney                     Informational                      [Page 5]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-      specified in this document.  The details of how one uses ND on
-      NBMA links is an area for further study."
-
-   Some detailed analysis of Neighbor Discovery follows:
-
-   Router Discovery is how hosts locate routers that reside on an
-   attached link.  Router Discovery MUST be supported for
-   implementations.
-
-   Prefix Discovery is how hosts discover the set of address prefixes
-   that define which destinations are on-link for an attached link.
-   Prefix discovery MUST be supported for implementations.  Neighbor
-   Unreachability Detection (NUD) MUST be supported for all paths
-   between hosts and neighboring nodes.  It is not required for paths
-   between routers.  However, when a node receives a unicast Neighbor
-   Solicitation (NS) message (that may be a NUD's NS), the node MUST
-   respond to it (i.e., send a unicast Neighbor Advertisement).
-
-   Duplicate Address Detection MUST be supported on all links supporting
-   link-layer multicast (RFC 2462, Section 5.4, specifies DAD MUST take
-   place on all unicast addresses).
-
-   A host implementation MUST support sending Router Solicitations.
-
-   Receiving and processing Router Advertisements MUST be supported for
-   host implementations.  The ability to understand specific Router
-   Advertisement options is dependent on supporting the specification
-   where the RA is specified.
-
-   Sending and Receiving Neighbor Solicitation (NS) and Neighbor
-   Advertisement (NA) MUST be supported.  NS and NA messages are
-   required for Duplicate Address Detection (DAD).
-
-   Redirect functionality SHOULD be supported.  If the node is a router,
-   Redirect functionality MUST be supported.
-
-4.3.  Path MTU Discovery and Packet Size
-
-4.3.1.  Path MTU Discovery - RFC 1981
-
-   Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal
-   implementations MAY choose to not support it and avoid large packets.
-   The rules in RFC 2460 MUST be followed for packet fragmentation and
-   reassembly.
-
-4.3.2.  IPv6 Jumbograms - RFC 2675
-
-   IPv6 Jumbograms [RFC-2675] MAY be supported.
-
-
-
-Loughney                     Informational                      [Page 6]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-4.4.  ICMP for the Internet Protocol Version 6 (IPv6) - RFC 2463
-
-   ICMPv6 [RFC-2463] MUST be supported.
-
-4.5.  Addressing
-
-4.5.1.  IP Version 6 Addressing Architecture - RFC 3513
-
-   The IPv6 Addressing Architecture [RFC-3513] MUST be supported as
-   updated by [RFC-3879].
-
-4.5.2.  IPv6 Stateless Address Autoconfiguration - RFC 2462
-
-   IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
-   This specification MUST be supported for nodes that are hosts.
-   Static address can be supported as well.
-
-   Nodes that are routers MUST be able to generate link local addresses
-   as described in RFC 2462 [RFC-2462].
-
-   From 2462:
-
-      The autoconfiguration process specified in this document applies
-      only to hosts and not routers.  Since host autoconfiguration uses
-      information advertised by routers, routers will need to be
-      configured by some other means.  However, it is expected that
-      routers will generate link-local addresses using the mechanism
-      described in this document.  In addition, routers are expected to
-      successfully pass the Duplicate Address Detection procedure
-      described in this document on all addresses prior to assigning
-      them to an interface.
-
-   Duplicate Address Detection (DAD) MUST be supported.
-
-4.5.3.  Privacy Extensions for Address Configuration in IPv6 - RFC 3041
-
-   Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041]
-   SHOULD be supported.  It is recommended that this behavior be
-   configurable on a connection basis within each application when
-   available.  It is noted that a number of applications do not work
-   with addresses generated with this method, while other applications
-   work quite well with them.
-
-4.5.4.  Default Address Selection for IPv6 - RFC 3484
-
-   The rules specified in the Default Address Selection for IPv6
-   [RFC-3484] document MUST be implemented.  It is expected that IPv6
-   nodes will need to deal with multiple addresses.
-
-
-
-Loughney                     Informational                      [Page 7]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-4.5.5.  Stateful Address Autoconfiguration
-
-   Stateful Address Autoconfiguration MAY be supported.  DHCPv6
-   [RFC-3315] is the standard stateful address configuration protocol;
-   see Section 5.3 for DHCPv6 support.
-
-   Nodes which do not support Stateful Address Autoconfiguration may be
-   unable to obtain any IPv6 addresses, aside from link-local addresses,
-   when it receives a router advertisement with the 'M' flag (Managed
-   address configuration) set and that contains no prefixes advertised
-   for Stateless Address Autoconfiguration (see Section 4.5.2).
-   Additionally, such nodes will be unable to obtain other configuration
-   information, such as the addresses of DNS servers when it is
-   connected to a link over which the node receives a router
-   advertisement in which the 'O' flag ("Other stateful configuration")
-   is set.
-
-4.6.  Multicast Listener Discovery (MLD) for IPv6 - RFC 2710
-
-   Nodes that need to join multicast groups SHOULD implement MLDv2
-   [RFC-3810].  However, if the node has applications that only need
-   support for Any-Source Multicast [RFC-3569], the node MAY implement
-   MLDv1 [RFC-2710] instead.  If the node has applications that need
-   support for Source-Specific Multicast [RFC-3569, SSM-ARCH], the node
-   MUST support MLDv2 [RFC-3810].
-
-   When MLD is used, the rules in the "Source Address Selection for the
-   Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be
-   followed.
-
-5.  DNS and DHCP
-
-5.1.  DNS
-
-   DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363],
-   and [RFC-3596].  Not all nodes will need to resolve names; those that
-   will never need to resolve DNS names do not need to implement
-   resolver functionality.  However, the ability to resolve names is a
-   basic infrastructure capability that applications rely on and
-   generally needs to be supported.  All nodes that need to resolve
-   names SHOULD implement stub-resolver [RFC-1034] functionality, as in
-   RFC 1034, Section 5.3.1, with support for:
-
-      -  AAAA type Resource Records [RFC-3596];
-
-      -  reverse addressing in ip6.arpa using PTR records [RFC-3152];
-
-
-
-
-
-Loughney                     Informational                      [Page 8]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-      -  EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
-         octets.
-
-   Those nodes are RECOMMENDED to support DNS security extensions
-   [RFC-4033], [RFC-4034], and [RFC-4035].
-
-   Those nodes are NOT RECOMMENDED to support the experimental A6 and
-   DNAME Resource Records [RFC-3363].
-
-5.2.  Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315
-
-5.2.1.  Managed Address Configuration
-
-   The method by which IPv6 nodes that use DHCP for address assignment
-   can obtain IPv6 addresses and other configuration information upon
-   receipt of a Router Advertisement with the 'M' flag set is described
-   in Section 5.5.3 of RFC 2462.
-
-   In addition, in the absence of a router, those IPv6 nodes that use
-   DHCP for address assignment MUST initiate DHCP to obtain IPv6
-   addresses and other configuration information, as described in
-   Section 5.5.2 of RFC 2462.  Those IPv6 nodes that do not use DHCP for
-   address assignment can ignore the 'M' flag in Router Advertisements.
-
-5.2.2.  Other Configuration Information
-
-   The method by which IPv6 nodes that use DHCP to obtain other
-   configuration information can obtain other configuration information
-   upon receipt of a Router Advertisement with the 'O' flag set is
-   described in Section 5.5.3 of RFC 2462.
-
-   Those IPv6 nodes that use DHCP to obtain other configuration
-   information initiate DHCP for other configuration information upon
-   receipt of a Router Advertisement with the 'O' flag set, as described
-   in Section 5.5.3 of RFC 2462.  Those IPv6 nodes that do not use DHCP
-   for other configuration information can ignore the 'O' flag in Router
-   Advertisements.
-
-   An IPv6 node can use the subset of DHCP (described in [RFC-3736]) to
-   obtain other configuration information.
-
-5.3.3.  Use of Router Advertisements in Managed Environments
-
-   Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
-   are expected to determine their default router information and on-
-   link prefix information from received Router Advertisements.
-
-
-
-
-
-Loughney                     Informational                      [Page 9]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-6.  IPv4 Support and Transition
-
-   IPv6 nodes MAY support IPv4.
-
-6.1.  Transition Mechanisms
-
-6.1.1.  Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893
-
-   If an IPv6 node implements dual stack and tunneling, then [RFC-4213]
-   MUST be supported.
-
-7.  Mobile IP
-
-   The Mobile IPv6 [RFC-3775] specification defines requirements for the
-   following types of nodes:
-
-      -  mobile nodes
-
-      -  correspondent nodes with support for route optimization
-
-      -  home agents
-
-      -  all IPv6 routers
-
-   Hosts MAY support mobile node functionality described in Section 8.5
-   of [RFC-3775], including support of generic packet tunneling [RFC-
-   2473] and secure home agent communications [RFC-3776].
-
-   Hosts SHOULD support route optimization requirements for
-   correspondent nodes described in Section 8.2 of [RFC-3775].
-
-   Routers SHOULD support the generic mobility-related requirements for
-   all IPv6 routers described in Section 8.3 of [RFC-3775].  Routers MAY
-   support the home agent functionality described in Section 8.4 of
-   [RFC-3775], including support of [RFC-2473] and [RFC-3776].
-
-8.  Security
-
-   This section describes the specification of IPsec for the IPv6 node.
-
-8.1.  Basic Architecture
-
-   Security Architecture for the Internet Protocol [RFC-4301] MUST be
-   supported.
-
-
-
-
-
-
-
-Loughney                     Informational                     [Page 10]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-8.2.  Security Protocols
-
-   ESP [RFC-4303] MUST be supported.  AH [RFC-4302] MUST be supported.
-
-8.3.  Transforms and Algorithms
-
-   Current IPsec RFCs specify the support of transforms and algorithms
-   for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and
-   HMAC-MD5-96.  However, "Cryptographic Algorithm Implementation
-   Requirements For ESP And AH" [RFC-4305] contains the current set of
-   mandatory to implement algorithms for ESP and AH.  It also specifies
-   algorithms that should be implemented because they are likely to be
-   promoted to mandatory at some future time.  IPv6 nodes SHOULD conform
-   to the requirements in [RFC-4305], as well as the requirements
-   specified below.
-
-   Since ESP encryption and authentication are both optional, support
-   for the NULL encryption algorithm [RFC-2410] and the NULL
-   authentication algorithm [RFC-4303] MUST be provided to maintain
-   consistency with the way these services are negotiated.  However,
-   while authentication and encryption can each be NULL, they MUST NOT
-   both be NULL.  The NULL encryption algorithm is also useful for
-   debugging.
-
-   The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported
-   within ESP.  Security issues related to the use of DES are discussed
-   in [DESDIFF], [DESINT], and [DESCRACK].  DES-CBC is still listed as
-   required by the existing IPsec RFCs, but updates to these RFCs will
-   be published in the near future.  DES provides 56 bits of protection,
-   which is no longer considered sufficient.
-
-   The use of the HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP
-   MUST be supported.  The use of the HMAC-MD5-96 algorithm [RFC-2403]
-   within AH and ESP MAY also be supported.
-
-   The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the
-   same security issues as DES-CBC, and the 3DES-CBC algorithm within
-   ESP MUST be supported to ensure interoperability.
-
-   The AES-128-CBC algorithm [RFC-3602] MUST also be supported within
-   ESP.  AES-128 is expected to be a widely available, secure, and
-   efficient algorithm.  While AES-128-CBC is not required by the
-   current IPsec RFCs, it is expected to become required in the future.
-
-
-
-
-
-
-
-
-Loughney                     Informational                     [Page 11]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-8.4.  Key Management Methods
-
-   An implementation MUST support the manual configuration of the
-   security key and SPI.  The SPI configuration is needed in order to
-   delineate between multiple keys.
-
-   Key management SHOULD be supported.  Examples of key management
-   systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include
-   key management functions.
-
-   Where key refresh, anti-replay features of AH and ESP, or on-demand
-   creation of Security Associations (SAs) is required, automated keying
-   MUST be supported.
-
-   Key management methods for multicast traffic are also being worked on
-   by the MSEC WG.
-
-9.  Router-Specific Functionality
-
-   This section defines general host considerations for IPv6 nodes that
-   act as routers.  Currently, this section does not discuss routing-
-   specific requirements.
-
-9.1.  General
-
-9.1.1.  IPv6 Router Alert Option - RFC 2711
-
-   The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by-
-   Hop Header that is used in conjunction with some protocols (e.g.,
-   RSVP [RFC-2205] or MLD [RFC-2710]).  The Router Alert option will
-   need to be implemented whenever protocols that mandate its usage are
-   implemented.  See Section 4.6.
-
-9.1.2.  Neighbor Discovery for IPv6 - RFC 2461
-
-   Sending Router Advertisements and processing Router Solicitation MUST
-   be supported.
-
-10.  Network Management
-
-   Network Management MAY be supported by IPv6 nodes.  However, for IPv6
-   nodes that are embedded devices, network management may be the only
-   possible way of controlling these nodes.
-
-10.1.  Management Information Base Modules (MIBs)
-
-   The following two MIBs SHOULD be supported by nodes that support an
-   SNMP agent.
-
-
-
-Loughney                     Informational                     [Page 12]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-10.1.1.  IP Forwarding Table MIB
-
-   IP Forwarding Table MIB [RFC-4292] SHOULD be supported by nodes that
-   support an SNMP agent.
-
-10.1.2.  Management Information Base for the Internet Protocol (IP)
-
-   IP MIB [RFC-4293] SHOULD be supported by nodes that support an SNMP
-   agent.
-
-11.  Security Considerations
-
-   This document does not affect the security of the Internet, but
-   implementations of IPv6 are expected to support a minimum set of
-   security features to ensure security on the Internet.  "IP Security
-   Document Roadmap" [RFC-2411] is important for everyone to read.
-
-   The security considerations in RFC 2460 state the following:
-
-      The security features of IPv6 are described in the Security
-      Architecture for the Internet Protocol [RFC-2401].
-
-   RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for
-   the security features of IPv6.
-
-12.  References
-
-12.1.  Normative References
-
-   [RFC-1035]     Mockapetris, P., "Domain names - implementation and
-                  specification", STD 13, RFC 1035, November 1987.
-
-   [RFC-1981]     McCann, J., Deering, S., and J. Mogul, "Path MTU
-                  Discovery for IP version 6", RFC 1981, August 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-2403]     Madson, C. and R. Glenn, "The Use of HMAC-MD5-96
-                  within ESP and AH", RFC 2403, November 1998.
-
-   [RFC-2404]     Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
-                  within ESP and AH", RFC 2404, November 1998.
-
-
-
-
-Loughney                     Informational                     [Page 13]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-   [RFC-2405]     Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
-                  Algorithm With Explicit IV", RFC 2405, November 1998.
-
-   [RFC-2410]     Glenn, R. and S. Kent, "The NULL Encryption Algorithm
-                  and Its Use With IPsec", RFC 2410, November 1998.
-
-   [RFC-2411]     Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
-                  Document Roadmap", RFC 2411, November 1998.
-
-   [RFC-2451]     Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
-                  Algorithms", RFC 2451, November 1998.
-
-   [RFC-2460]     Deering, S. and R. Hinden, "Internet Protocol, Version
-                  6 (IPv6) Specification", RFC 2460, December 1998.
-
-   [RFC-2461]     Narten, T., Nordmark, E., and W. Simpson, "Neighbor
-                  Discovery for IP Version 6 (IPv6)", RFC 2461, December
-                  1998.
-
-   [RFC-2462]     Thomson, S. and T. Narten, "IPv6 Stateless Address
-                  Autoconfiguration", RFC 2462, December 1998.
-
-   [RFC-2463]     Conta, A. and S. Deering, "Internet Control Message
-                  Protocol (ICMPv6) for the Internet Protocol Version 6
-                  (IPv6) Specification", RFC 2463, December 1998.
-
-   [RFC-2472]     Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC
-                  2472, December 1998.
-
-   [RFC-2473]     Conta, A. and S. Deering, "Generic Packet Tunneling in
-                  IPv6 Specification", RFC 2473, December 1998.
-
-   [RFC-2671]     Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-                  2671, August 1999.
-
-   [RFC-2710]     Deering, S., Fenner, W., and B. Haberman, "Multicast
-                  Listener Discovery (MLD) for IPv6", RFC 2710, October
-                  1999.
-
-   [RFC-2711]     Partridge, C. and A. Jackson, "IPv6 Router Alert
-                  Option", RFC 2711, October 1999.
-
-   [RFC-3041]     Narten, T. and R. Draves, "Privacy Extensions for
-                  Stateless Address Autoconfiguration in IPv6", RFC
-                  3041, January 2001.
-
-   [RFC-3152]     Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
-                  August 2001.
-
-
-
-Loughney                     Informational                     [Page 14]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-   [RFC-3315]     Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
-                  C., and M. Carney, "Dynamic Host Configuration
-                  Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-   [RFC-3363]     Bush, R., Durand, A., Fink, B., Gudmundsson, O., and
-                  T. Hain, "Representing Internet Protocol version 6
-                  (IPv6) Addresses in the Domain Name System (DNS)", RFC
-                  3363, August 2002.
-
-   [RFC-3484]     Frye, R., Levi, D., Routhier, S., and B. Wijnen,
-                  "Coexistence between Version 1, Version 2, and Version
-                  3 of the Internet-standard Network Management
-                  Framework", BCP 74, RFC 3584, August 2003.
-
-   [RFC-3513]     Hinden, R. and S. Deering, "Internet Protocol Version
-                  6 (IPv6) Addressing Architecture", RFC 3513, April
-                  2003.
-
-   [RFC-3590]     Haberman, B., "Source Address Selection for the
-                  Multicast Listener Discovery (MLD) Protocol", RFC
-                  3590, September 2003.
-
-   [RFC-3596]     Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
-                  "DNS Extensions to Support IP Version 6", RFC 3596,
-                  October 2003.
-
-   [RFC-3602]     Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
-                  Cipher Algorithm and Its Use with IPsec", RFC 3602,
-                  September 2003.
-
-   [RFC-3775]     Johnson, D., Perkins, C., and J. Arkko, "Mobility
-                  Support in IPv6", RFC 3775, June 2004.
-
-   [RFC-3776]     Arkko, J., Devarapalli, V., and F. Dupont, "Using
-                  IPsec to Protect Mobile IPv6 Signaling Between Mobile
-                  Nodes and Home Agents", RFC 3776, June 2004.
-
-   [RFC-3810]     Vida, R. and L. Costa, "Multicast Listener Discovery
-                  Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
-
-   [RFC-3879]     Huitema, C. and B. Carpenter, "Deprecating Site Local
-                  Addresses", RFC 3879, September 2004.
-
-   [RFC-4292]     Haberman, B., "IP Forwarding Table MIB", RFC 4292,
-                  April 2006.
-
-   [RFC-4293]     Routhier, S., Ed., "Management Information Base for
-                  the Internet Protocol (IP)", RFC 4293, April 2006.
-
-
-
-Loughney                     Informational                     [Page 15]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-   [RFC-4301]     Kent, S. and R. Atkinson, "Security Architecture for
-                  the Internet Protocol", RFC 4301, December 2005.
-
-   [RFC-4302]     Kent, S., "IP Authentication Header", RFC 4302,
-                  December 2005.
-
-   [RFC-4303]     Kent, S., "IP Encapsulating Security Payload (ESP)",
-                  RFC 4303, December 2005.
-
-   [RFC-4305]     Eastlake 3rd, D., "Cryptographic Algorithm
-                  Implementation Requirements for Encapsulating Security
-                  Payload (ESP) and Authentication Header (AH)", RFC
-                  4305, December 2005.
-
-12.2.  Informative References
-
-   [DESDIFF]      Biham, E., Shamir, A., "Differential Cryptanalysis of
-                  DES-like cryptosystems", Journal of Cryptology Vol 4,
-                  Jan 1991.
-
-   [DESCRACK]     Cracking DES, O'Reilly & Associates, Sebastapol, CA
-                  2000.
-
-   [DESINT]       Bellovin, S., "An Issue With DES-CBC When Used Without
-                  Strong Integrity", Proceedings of the 32nd IETF,
-                  Danvers, MA, April 1995.
-
-   [IPv6-RH]      P. Savola, "Security of IPv6 Routing Header and Home
-                  Address Options", Work in Progress.
-
-   [RFC-793]      Postel, J., "Transmission Control Protocol", STD 7,
-                  RFC 793, September 1981.
-
-   [RFC-1034]     Mockapetris, P., "Domain names - concepts and
-                  facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC-2205]     Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
-                  Jamin, "Resource ReSerVation Protocol (RSVP) --
-                  Version 1 Functional Specification", RFC 2205,
-                  September 1997.
-
-   [RFC-2464]     Crawford, M., "Transmission of IPv6 Packets over
-                  Ethernet Networks", RFC 2464, December 1998.
-
-   [RFC-2492]     Armitage, G., Schulter, P., and M. Jork, "IPv6 over
-                  ATM Networks", RFC 2492, January 1999.
-
-
-
-
-
-Loughney                     Informational                     [Page 16]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-   [RFC-2675]     Borman, D., Deering, S., and R. Hinden, "IPv6
-                  Jumbograms", RFC 2675, August 1999.
-
-   [RFC-4213]     Nordmark, E. and R. Gilligan, "Basic Transition
-                  Mechanisms for IPv6 Hosts and Routers", RFC 4213,
-                  October 2005.
-
-   [RFC-3569]     Bhattacharyya, S., "An Overview of Source-Specific
-                  Multicast (SSM)", RFC 3569, July 2003.
-
-   [RFC-3736]     Droms, R., "Stateless Dynamic Host Configuration
-                  Protocol (DHCP) Service for IPv6", RFC 3736, April
-                  2004.
-
-   [RFC-4001]     Daniele, M., Haberman, B., Routhier, S., and J.
-                  Schoenwaelder, "Textual Conventions for Internet
-                  Network Addresses", RFC 4001, February 2005.
-
-   [RFC-4033]     Arends, R., Austein, R., Larson, M., Massey, D., and
-                  S. Rose, "DNS Security Introduction and Requirements",
-                  RFC 4033, March 2005.
-
-   [RFC-4034]     Arends, R., Austein, R., Larson, M., Massey, D., and
-                  S. Rose, "Resource Records for the DNS Security
-                  Extensions", RFC 4034, March 2005.
-
-   [RFC-4035]     Arends, R., Austein, R., Larson, M., Massey, D., and
-                  S. Rose, "Protocol Modifications for the DNS Security
-                  Extensions", RFC 4035, March 2005.
-
-   [RFC-4306]     Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
-                  Protocol", RFC 4306, December 2005.
-
-   [SSM-ARCH]     H. Holbrook, B. Cain, "Source-Specific Multicast for
-                  IP", Work in Progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Loughney                     Informational                     [Page 17]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-13.  Authors and Acknowledgements
-
-   This document was written by the IPv6 Node Requirements design team:
-
-   Jari Arkko
-   [jari.arkko@ericsson.com]
-
-   Marc Blanchet
-   [marc.blanchet@viagenie.qc.ca]
-
-   Samita Chakrabarti
-   [samita.chakrabarti@eng.sun.com]
-
-   Alain Durand
-   [alain.durand@sun.com]
-
-   Gerard Gastaud
-   [gerard.gastaud@alcatel.fr]
-
-   Jun-ichiro itojun Hagino
-   [itojun@iijlab.net]
-
-   Atsushi Inoue
-   [inoue@isl.rdc.toshiba.co.jp]
-
-   Masahiro Ishiyama
-   [masahiro@isl.rdc.toshiba.co.jp]
-
-   John Loughney
-   [john.loughney@nokia.com]
-
-   Rajiv Raghunarayan
-   [raraghun@cisco.com]
-
-   Shoichi Sakane
-   [shouichi.sakane@jp.yokogawa.com]
-
-   Dave Thaler
-   [dthaler@windows.microsoft.com]
-
-   Juha Wiljakka
-   [juha.wiljakka@Nokia.com]
-
-   The authors would like to thank Ran Atkinson, Jim Bound, Brian
-   Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas
-   Narten, Juha Ollila, and Pekka Savola for their comments.
-
-
-
-
-
-Loughney                     Informational                     [Page 18]
-
-RFC 4294                 IPv6 Node Requirements               April 2006
-
-
-Editor's Contact Information
-
-   Comments or questions regarding this document should be sent to the
-   IPv6 Working Group mailing list (ipv6@ietf.org) or to:
-
-   John Loughney
-   Nokia Research Center
-   Itamerenkatu 11-13
-   00180 Helsinki
-   Finland
-
-   Phone: +358 50 483 6242
-   EMail: John.Loughney@Nokia.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Loughney                     Informational                     [Page 19]
-
-RFC 4294                 IPv6 Node Requirements               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).
-
-
-
-
-
-
-
-Loughney                     Informational                     [Page 20]
-
diff --git a/doc/rfc/rfc4339.txt b/doc/rfc/rfc4339.txt
deleted file mode 100644
index a6f29d9f..00000000
--- a/doc/rfc/rfc4339.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      J. Jeong, Ed.
-Request for Comments: 4339                  ETRI/University of Minnesota
-Category: Informational                                    February 2006
-
-
-      IPv6 Host Configuration of DNS Server Information Approaches
-
-
-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).
-
-IESG Note
-
-   This document describes three different approaches for the
-   configuration of DNS name resolution server information in IPv6
-   hosts.
-
-   There is not an IETF consensus on which approach is preferred.  The
-   analysis in this document was developed by the proponents for each
-   approach and does not represent an IETF consensus.
-
-   The 'RA option' and 'Well-known anycast' approaches described in this
-   document are not standardized.  Consequently the analysis for these
-   approaches might not be completely applicable to any specific
-   proposal that might be proposed in the future.
-
-Abstract
-
-   This document describes three approaches for IPv6 recursive DNS
-   server address configuration.  It details the operational attributes
-   of three solutions: RA option, DHCPv6 option, and well-known anycast
-   addresses for recursive DNS servers.  Additionally, it suggests the
-   deployment scenarios in four kinds of networks (ISP, enterprise,
-   3GPP, and unmanaged networks) considering multi-solution resolution.
-
-
-
-
-
-
-
-
-
-
-Jeong                        Informational                      [Page 1]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. Terminology .....................................................3
-   3. IPv6 DNS Configuration Approaches ...............................3
-      3.1. RA Option ..................................................3
-           3.1.1. Advantages ..........................................4
-           3.1.2. Disadvantages .......................................5
-           3.1.3. Observations ........................................5
-      3.2. DHCPv6 Option ..............................................6
-           3.2.1. Advantages ..........................................7
-           3.2.2. Disadvantages .......................................8
-           3.2.3. Observations ........................................9
-      3.3. Well-known Anycast Addresses ...............................9
-           3.3.1. Advantages .........................................10
-           3.3.2. Disadvantages ......................................10
-           3.3.3. Observations .......................................10
-   4. Interworking among IPv6 DNS Configuration Approaches ...........11
-   5. Deployment Scenarios ...........................................12
-      5.1. ISP Network ...............................................12
-           5.1.1. RA Option Approach .................................13
-           5.1.2. DHCPv6 Option Approach .............................13
-           5.1.3. Well-known Anycast Addresses Approach ..............14
-      5.2. Enterprise Network ........................................14
-      5.3. 3GPP Network ..............................................15
-           5.3.1. Currently Available Mechanisms and
-                  Recommendations ....................................15
-           5.3.2. RA Extension .......................................16
-           5.3.3. Stateless DHCPv6 ...................................16
-           5.3.4. Well-known Addresses ...............................17
-           5.3.5. Recommendations ....................................18
-      5.4. Unmanaged Network .........................................18
-           5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18
-           5.4.2. Case B: A Dual-stack Gateway Connected to a
-                  Dual-stack ISP .....................................19
-           5.4.3. Case C: A Dual-stack Gateway Connected to
-                  an IPv4-only ISP ...................................19
-           5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19
-   6. Security Considerations ........................................19
-      6.1. RA Option .................................................20
-      6.2. DHCPv6 Option .............................................21
-      6.3. Well-known Anycast Addresses ..............................21
-   7. Contributors ...................................................21
-   8. Acknowledgements ...............................................23
-   9. References .....................................................23
-      9.1. Normative References ......................................23
-      9.2. Informative References ....................................23
-
-
-
-
-Jeong                        Informational                      [Page 2]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-1.  Introduction
-
-   Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
-   Autoconfiguration provide ways to configure either fixed or mobile
-   nodes with one or more IPv6 addresses, default routes, and some other
-   parameters [1][2].  To support the access to additional services in
-   the Internet that are identified by a DNS name, such as a web server,
-   the configuration of at least one recursive DNS server is also needed
-   for DNS name resolution.
-
-   This document describes three approaches of recursive DNS server
-   address configuration for IPv6 host: (a) RA option [6], (b) DHCPv6
-   option [3]-[5], and (c) well-known anycast addresses for recursive
-   DNS servers [7].  Also, it suggests the applicable scenarios for four
-   kinds of networks: (a) ISP network, (b) enterprise network, (c) 3GPP
-   network, and (d) unmanaged network.
-
-   This document is just an analysis of each possible approach, and it
-   does not recommend a particular approach or combination of
-   approaches.  Some approaches may even not be adopted at all as a
-   result of further discussion.
-
-   Therefore, the objective of this document is to help the audience
-   select the approaches suitable for IPv6 host configuration of
-   recursive DNS servers.
-
-2.  Terminology
-
-   This document uses the terminology described in [1]-[7].  In
-   addition, a new term is defined below:
-
-   o  Recursive DNS Server (RDNSS): Server which provides a recursive
-      DNS resolution service.
-
-3.  IPv6 DNS Configuration Approaches
-
-   In this section, the operational attributes of the three solutions
-   are described in detail.
-
-3.1.  RA Option
-
-   The RA approach defines a new ND option, called the RDNSS option,
-   that contains a recursive DNS server address [6].  Existing ND
-   transport mechanisms (i.e., advertisements and solicitations) are
-   used.  This works in the same way that nodes learn about routers and
-   prefixes.  An IPv6 host can configure the IPv6 addresses of one or
-   more RDNSSes via RA message periodically sent by a router or
-   solicited by a Router Solicitation (RS).
-
-
-
-Jeong                        Informational                      [Page 3]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   This approach needs RDNSS information to be configured in the routers
-   doing the advertisements.  The configuration of RDNSS addresses can
-   be performed manually by an operator or in other ways, such as
-   automatic configuration through a DHCPv6 client running on the
-   router.  An RA message with one RDNSS option can include as many
-   RDNSS addresses as needed [6].
-
-   Through the ND protocol and RDNSS option, along with a prefix
-   information option, an IPv6 host can perform network configuration of
-   its IPv6 address and RDNSS simultaneously [1][2].  The RA option for
-   RDNSS can be used on any network that supports the use of ND.
-
-   The RA approach is useful in some mobile environments where the
-   addresses of the RDNSSes are changing because the RA option includes
-   a lifetime field that allows client to use RDNSSes nearer to the
-   client.  This can be configured to a value that will require the
-   client to time out the entry and switch over to another RDNSS address
-   [6].  However, from the viewpoint of implementation, the lifetime
-   field would seem to make matters a bit more complex.  Instead of just
-   writing to a DNS configuration file, such as resolv.conf for the list
-   of RDNSS addresses, we have to have a daemon around (or a program
-   that is called at the defined intervals) that keeps monitoring the
-   lifetime of RDNSSes all the time.
-
-   The preference value of RDNSS, included in the RDNSS option, allows
-   IPv6 hosts to select primary RDNSS among several RDNSSes [6]; this
-   can be used for the load balancing of RDNSSes.
-
-3.1.1.  Advantages
-
-   The RA option for RDNSS has a number of advantages.  These include:
-
-   1.  The RA option is an extension of existing ND/Autoconfig
-       mechanisms [1][2] and does not require a change in the base ND
-       protocol.
-
-   2.  This approach, like ND, works well on a variety of link types,
-       including point-to-point links, point-to-multipoint, and
-       multipoint-to-multipoint (i.e., Ethernet LANs).  RFC 2461 [1]
-       states, however, that there may be some link types on which ND is
-       not feasible; on such links, some other mechanisms will be needed
-       for DNS configuration.
-
-   3.  All the information a host needs to run the basic Internet
-       applications (such as the email, web, ftp, etc.) can be obtained
-       with the addition of this option to ND and address
-       autoconfiguration.  The use of a single mechanism is more
-       reliable and easier to provide than when the RDNSS information is
-
-
-
-Jeong                        Informational                      [Page 4]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-       learned via another protocol mechanism.  Debugging problems when
-       multiple protocol mechanisms are being used is harder and much
-       more complex.
-
-   4.  This mechanism works over a broad range of scenarios and
-       leverages IPv6 ND.  This works well on links that are high
-       performance (e.g., Ethernet LANs) and low performance (e.g.,
-       cellular networks).  In the latter case, by combining the RDNSS
-       information with the other information in the RA, the host can
-       learn all the information needed to use most Internet
-       applications, such as the web, in a single packet.  This not only
-       saves bandwidth, but also minimizes the delay needed to learn the
-       RDNSS information.
-
-   5.  The RA approach could be used as a model for similar types of
-       configuration information.  New RA options for other server
-       addresses, such as NTP server address, that are common to all
-       clients on a subnet would be easy to define.
-
-3.1.2.  Disadvantages
-
-   1.  ND is mostly implemented in the kernel of the operating system.
-       Therefore, if ND supports the configuration of some additional
-       services, such as DNS servers, ND should be extended in the
-       kernel and complemented by a user-land process.  DHCPv6, however,
-       has more flexibility for the extension of service discovery
-       because it is an application layer protocol.
-
-   2.  The current ND framework should be modified to facilitate the
-       synchronization between another ND cache for RDNSSes in the
-       kernel space and the DNS configuration file in the user space.
-       Because it is unacceptable to write and rewrite to the DNS
-       configuration file (e.g., resolv.conf) from the kernel, another
-       approach is needed.  One simple approach to solve this is to have
-       a daemon listening to what the kernel conveys, and to have the
-       daemon do these steps, but such a daemon is not needed with the
-       current ND framework.
-
-   3.  It is necessary to configure RDNSS addresses at least at one
-       router on every link where this information needs to be
-       configured via the RA option.
-
-3.1.3.  Observations
-
-   The proposed RDNSS RA option, along with the IPv6 ND and
-   Autoconfiguration, allows a host to obtain all of the information it
-   needs to access basic Internet services like the web, email, ftp,
-   etc.  This is preferable in the environments where hosts use RAs to
-
-
-
-Jeong                        Informational                      [Page 5]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   autoconfigure their addresses and all the hosts on the subnet share
-   the same router and server addresses.  If the configuration
-   information can be obtained from a single mechanism, it is preferable
-   because it does not add additional delay, and because it uses a
-   minimum of bandwidth.  Environments like this include homes, public
-   cellular networks, and enterprise environments where no per host
-   configuration is needed.
-
-   DHCPv6 is preferable where it is being used for address configuration
-   and if there is a need for host specific configuration [3]-[5].
-   Environments like this are most likely to be the enterprise
-   environments where the local administration chooses to have per host
-   configuration control.
-
-3.2.  DHCPv6 Option
-
-   DHCPv6 [3] includes the "DNS Recursive Name Server" option, through
-   which a host can obtain a list of IP addresses of recursive DNS
-   servers [5].  The DNS Recursive Name Server option carries a list of
-   IPv6 addresses of RDNSSes to which the host may send DNS queries.
-   The DNS servers are listed in the order of preference for use by the
-   DNS resolver on the host.
-
-   The DNS Recursive Name Server option can be carried in any DHCPv6
-   Reply message, in response to either a Request or an Information
-   request message.  Thus, the DNS Recursive Name Server option can be
-   used either when DHCPv6 is used for address assignment, or when
-   DHCPv6 is used only for other configuration information as stateless
-   DHCPv6 [4].
-
-   Stateless DHCPv6 can be deployed either by using DHCPv6 servers
-   running on general-purpose computers, or on router hardware.  Several
-   router vendors currently implement stateless DHCPv6 servers.
-   Deploying stateless DHCPv6 in routers has the advantage that no
-   special hardware is required, and it should work well for networks
-   where DHCPv6 is needed for very straightforward configuration of
-   network devices.
-
-   However, routers can also act as DHCPv6 relay agents.  In this case,
-   the DHCPv6 server need not be on the router; it can be on a general
-   purpose computer.  This has the potential to give the operator of the
-   DHCPv6 server more flexibility in how the DHCPv6 server responds to
-   individual clients that can easily be given different configuration
-   information based on their identity, or for any other reason.
-   Nothing precludes adding this flexibility to a router, but generally,
-   in current practice, DHCP servers running on general-purpose hosts
-   tend to have more configuration options than those that are embedded
-   in routers.
-
-
-
-Jeong                        Informational                      [Page 6]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
-   clients that use a stateful configuration assignment.  To do this,
-   the DHCPv6 server sends a Reconfigure message to the client.  The
-   client validates the Reconfigure message, and then contacts the
-   DHCPv6 server to obtain updated configuration information.  By using
-   this mechanism, it is currently possible to propagate new
-   configuration information to DHCPv6 clients as this information
-   changes.
-
-   The DHC Working Group has standardized an additional mechanism
-   through which configuration information, including the list of
-   RDNSSes, can be updated.  The lifetime option for DHCPv6 [8] assigns
-   a lifetime to configuration information obtained through DHCPv6.  At
-   the expiration of the lifetime, the host contacts the DHCPv6 server
-   to obtain updated configuration information, including the list of
-   RDNSSes.  This lifetime gives the network administrator another
-   mechanism to configure hosts with new RDNSSes by controlling the time
-   at which the host refreshes the list.
-
-   The DHC Working Group has also discussed the possibility of defining
-   an extension to DHCPv6 that would allow the use of multicast to
-   provide configuration information to multiple hosts with a single
-   DHCPv6 message.  Because of the lack of deployment experience, the WG
-   has deferred consideration of multicast DHCPv6 configuration at this
-   time.  Experience with DHCPv4 has not identified a requirement for
-   multicast message delivery, even in large service provider networks
-   with tens of thousands of hosts that may initiate a DHCPv4 message
-   exchange simultaneously.
-
-3.2.1.  Advantages
-
-   The DHCPv6 option for RDNSS has a number of advantages.  These
-   include:
-
-   1.  DHCPv6 currently provides a general mechanism for conveying
-       network configuration information to clients.  Configuring DHCPv6
-       servers in this way allows the network administrator to configure
-       RDNSSes, the addresses of other network services, and location-
-       specific information, such as time zones.
-
-   2.  As a consequence, when the network administrator goes to
-       configure DHCPv6, all the configuration information can be
-       managed through a single service, typically with a single user
-       interface and a single configuration database.
-
-
-
-
-
-
-
-Jeong                        Informational                      [Page 7]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   3.  DHCPv6 allows for the configuration of a host with information
-       specific to that host, so that hosts on the same link can be
-       configured with different RDNSSes and with other configuration
-       information.
-
-   4.  A mechanism exists for extending DHCPv6 to support the
-       transmission of additional configuration that has not yet been
-       anticipated.
-
-   5.  Hosts that require other configuration information, such as the
-       addresses of SIP servers and NTP servers, are likely to need
-       DHCPv6 for other configuration information.
-
-   6.  The specification for configuration of RDNSSes through DHCPv6 is
-       available as an RFC.  No new protocol extensions (such as new
-       options) are necessary.
-
-   7.  Interoperability among independent implementations has been
-       demonstrated.
-
-3.2.2.  Disadvantages
-
-   The DHCPv6 option for RDNSS has a few disadvantages.  These include:
-
-   1.  Update currently requires a message from server (however, see
-       [8]).
-
-   2.  Because DNS information is not contained in RA messages, the host
-       must receive two messages from the router and must transmit at
-       least one message to the router.  On networks where bandwidth is
-       at a premium, this is a disadvantage, although on most networks
-       it is not a practical concern.
-
-   3.  There is an increased latency for initial configuration.  In
-       addition to waiting for an RA message, the client must now
-       exchange packets with a DHCPv6 server.  Even if it is locally
-       installed on a router, this will slightly extend the time
-       required to configure the client.  For clients that are moving
-       rapidly from one network to another, this will be a disadvantage.
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                        Informational                      [Page 8]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-3.2.3.  Observations
-
-   In the general case, on general-purpose networks, stateless DHCPv6
-   provides significant advantages and no significant disadvantages.
-   Even in the case where bandwidth is at a premium and low latency is
-   desired, if hosts require other configuration information in addition
-   to a list of RDNSSes or if hosts must be configured selectively,
-   those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive
-   name server option will be advantageous.
-
-   However, we are aware of some applications where it would be
-   preferable to put the RDNSS information into an RA packet; for
-   example, in a mobile phone network, where bandwidth is at a premium
-   and extremely low latency is desired.  The DNS configuration based on
-   RA should be standardized so as to allow these special applications
-   to be handled using DNS information in the RA packet.
-
-3.3.  Well-known Anycast Addresses
-
-   Anycast uses the same routing system as unicast [9].  However,
-   administrative entities are local ones.  The local entities may
-   accept unicast routes (including default routes) to anycast servers
-   from adjacent entities.  The administrative entities should not
-   advertise their peer routes to their internal anycast servers, if
-   they want to prohibit external access from some peers to the servers.
-   If some advertisement is inevitable (such as the case with default
-   routes), the packets to the servers should be blocked at the boundary
-   of the entities.  Thus, for this anycast, not only unicast routing
-   but also unicast ND protocols can be used as is.
-
-   First of all, the well-known anycast addresses approach is much
-   different from that discussed by the IPv6 Working Group in the past
-   [7].  Note that "anycast" in this memo is simpler than that of RFC
-   1546 [9] and RFC 3513 [10], where it is assumed to be prohibited to
-   have multiple servers on a single link sharing an anycast address.
-   That is, on a link, an anycast address is assumed to be unique.  DNS
-   clients today already have redundancy by having multiple well-known
-   anycast addresses configured as RDNSS addresses.  There is no point
-   in having multiple RDNSSes sharing an anycast address on a single
-   link.
-
-   The approach with well-known anycast addresses is to set multiple
-   well-known anycast addresses in clients' resolver configuration files
-   from the beginning as, say, factory default.  Thus, there is no
-   transport mechanism and no packet format [7].
-
-   An anycast address is an address shared by multiple servers (in this
-   case, the servers are RDNSSes).  A request from a client to the
-
-
-
-Jeong                        Informational                      [Page 9]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   anycast address is routed to a server selected by the routing system.
-   However, it is a bad idea to mandate "site" boundary on anycast
-   addresses, because most users do not have their own servers and want
-   to access their ISPs across their site boundaries.  Larger sites may
-   also depend on their ISPs or may have their own RDNSSes within "site"
-   boundaries.
-
-3.3.1.  Advantages
-
-   The basic advantage of the well-known addresses approach is that it
-   uses no transport mechanism.  Thus, the following apply:
-
-   1.  There is no delay to get the response and no further delay by
-       packet losses.
-
-   2.  The approach can be combined with any other configuration
-       mechanisms, such as the RA-based approach and DHCP-based
-       approach, as well as the factory default configuration.
-
-   3.  The approach works over any environment where DNS works.
-
-   Another advantage is that this approach only needs configuration of
-   the DNS servers as a router (or configuration of a proxy router).
-   Considering that DNS servers do need configuration, the amount of
-   overall configuration effort is proportional to the number of DNS
-   servers and it scales linearly.  Note that, in the simplest case,
-   where a subscriber to an ISP does not have a DNS server, the
-   subscriber naturally accesses DNS servers of the ISP, even though the
-   subscriber and the ISP do nothing and there is no protocol to
-   exchange DNS server information between the subscriber and the ISP.
-
-3.3.2.  Disadvantages
-
-   The well-known anycast addresses approach requires that DNS servers
-   (or routers near to them as a proxy) act as routers to advertise
-   their anycast addresses to the routing system, which requires some
-   configuration (see the last paragraph of the previous section on the
-   scalability of the effort).  In addition, routers at the boundary of
-   the "site" might need the configuration of route filters to prevent
-   providing DNS services for parties outside the "site" and the
-   possibility of denial of service attacks on the internal DNS
-   infrastructure.
-
-3.3.3.  Observations
-
-   If other approaches are used in addition, the well-known anycast
-   addresses should also be set in RA or DHCP configuration files to
-   reduce the configuration effort of users.
-
-
-
-Jeong                        Informational                     [Page 10]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   The redundancy by multiple RDNSSes is better provided by multiple
-   servers with different anycast addresses than by multiple servers
-   sharing the same anycast address, because the former approach allows
-   stale servers to generate routes to their anycast addresses.  Thus,
-   in a routing domain (or domains sharing DNS servers), there will be
-   only one server with an anycast address unless the domain is so large
-   that load distribution is necessary.
-
-   Small ISPs will operate one RDNSS at each anycast address that is
-   shared by all the subscribers.  Large ISPs may operate multiple
-   RDNSSes at each anycast address to distribute and reduce load, where
-   the boundary between RDNSSes may be fixed (redundancy is still
-   provided by multiple addresses) or change dynamically.  DNS packets
-   with the well-known anycast addresses are not expected (though not
-   prohibited) to cross ISP boundaries, as ISPs are expected to be able
-   to take care of themselves.
-
-   Because "anycast" in this memo is simpler than that of RFC 1546 [9]
-   and RFC 3513 [10], where it is assumed to be administratively
-   prohibited to have multiple servers on a single link sharing an
-   anycast address, anycast in this memo should be implemented as
-   UNICAST of RFC 2461 [1] and RFC 3513 [10].  As a result, ND-related
-   instability disappears.  Thus, in the well-known anycast addresses
-   approach, anycast can and should use the anycast address as a source
-   unicast (according to RFC 3513 [10]) address of packets of UDP and
-   TCP responses.  With TCP, if a route flips and packets to an anycast
-   address are routed to a new server, it is expected that the flip is
-   detected by ICMP or sequence number inconsistency, and that the TCP
-   connection is reset and retried.
-
-4.  Interworking among IPv6 DNS Configuration Approaches
-
-   Three approaches can work together for IPv6 host configuration of
-   RDNSS.  This section shows a consideration on how these approaches
-   can interwork.
-
-   For ordering between RA and DHCP approaches, the O (Other stateful
-   configuration) flag in the RA message can be used [6][28].  If no
-   RDNSS option is included, an IPv6 host may perform DNS configuration
-   through DHCPv6 [3]-[5] regardless of whether the O flag is set or
-   not.
-
-   The well-known anycast addresses approach fully interworks with the
-   other approaches.  That is, the other approaches can remove the
-   configuration effort on servers by using the well-known addresses as
-   the default configuration.  Moreover, the clients preconfigured with
-   the well-known anycast addresses can be further configured to use
-   other approaches to override the well-known addresses, if the
-
-
-
-Jeong                        Informational                     [Page 11]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   configuration information from other approaches is available.
-   Otherwise, all the clients need to have the well-known anycast
-   addresses preconfigured.  In order to use the anycast approach along
-   with two other approaches, there are three choices as follows:
-
-   1.  The first choice is that well-known addresses are used as last
-       resort, when an IPv6 host cannot get RDNSS information through RA
-       and DHCP.  The well-known anycast addresses have to be
-       preconfigured in all of IPv6 hosts' resolver configuration files.
-
-   2.  The second is that an IPv6 host can configure well-known
-       addresses as the most preferable in its configuration file even
-       though either an RA option or DHCP option is available.
-
-   3.  The last is that the well-known anycast addresses can be set in
-       RA or DHCP configuration to reduce the configuration effort of
-       users.  According to either the RA or DHCP mechanism, the well-
-       known addresses can be obtained by an IPv6 host.  Because this
-       approach is the most convenient for users, the last option is
-       recommended.
-
-   Note: This section does not necessarily mean that this document
-   suggests adopting all of these three approaches and making them
-   interwork in the way described here.  In fact, as a result of further
-   discussion some approaches may not even be adopted at all.
-
-5.  Deployment Scenarios
-
-   Regarding the DNS configuration on the IPv6 host, several mechanisms
-   are being considered by the DNSOP Working Group, such as RA option,
-   DHCPv6 option, and well-known preconfigured anycast addresses as of
-   today, and this document is a final result from the long thread.  In
-   this section, we suggest four applicable scenarios of three
-   approaches for IPv6 DNS configuration.
-
-   Note: In the applicable scenarios, authors do not implicitly push any
-   specific approaches into the restricted environments.  No enforcement
-   is in each scenario, and all mentioned scenarios are probable.  The
-   main objective of this work is to provide a useful guideline for IPv6
-   DNS configuration.
-
-5.1.  ISP Network
-
-   A characteristic of an ISP network is that multiple Customer Premises
-   Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
-   routers and that each PE connects multiple CPE devices to the
-   backbone network infrastructure [11].  The CPEs may be hosts or
-   routers.
-
-
-
-Jeong                        Informational                     [Page 12]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   If the CPE is a router, there is a customer network that is connected
-   to the ISP backbone through the CPE.  Typically, each customer
-   network gets a different IPv6 prefix from an IPv6 PE router, but the
-   same RDNSS configuration will be distributed.
-
-   This section discusses how the different approaches to distributing
-   DNS information are compared in an ISP network.
-
-5.1.1.  RA Option Approach
-
-   When the CPE is a host, the RA option for RDNSS can be used to allow
-   the CPE to get RDNSS information and /64 prefix information for
-   stateless address autoconfiguration at the same time when the host is
-   attached to a new subnet [6].  Because an IPv6 host must receive at
-   least one RA message for stateless address autoconfiguration and
-   router configuration, the host could receive RDNSS configuration
-   information in the RA without the overhead of an additional message
-   exchange.
-
-   When the CPE is a router, the CPE may accept the RDNSS information
-   from the RA on the interface connected to the ISP and copy that
-   information into the RAs advertised in the customer network.
-
-   This approach is more valuable in the mobile host scenario, in which
-   the host must receive at least an RA message for detecting a new
-   network, than in other scenarios generally, although the
-   administrator should configure RDNSS information on the routers.
-   Secure ND [12] can provide extended security when RA messages are
-   used.
-
-5.1.2.  DHCPv6 Option Approach
-
-   DHCPv6 can be used for RDNSS configuration through the use of the DNS
-   option, and can provide other configuration information in the same
-   message with RDNSS configuration [3]-[5].  The DHCPv6 DNS option is
-   already in place for DHCPv6, as RFC 3646 [5] and DHCPv6-lite or
-   stateless DHCP [4] is not nearly as complex as a full DHCPv6
-   implementation.  DHCP is a client-server model protocol, so ISPs can
-   handle user identification on its network intentionally; also,
-   authenticated DHCP [13] can be used for secure message exchange.
-
-   The expected model for deployment of IPv6 service by ISPs is to
-   assign a prefix to each customer, which will be used by the customer
-   gateway to assign a /64 prefix to each network in the customer's
-   network.  Prefix delegation with DHCP (DHCPv6 PD) has already been
-   adopted by ISPs for automating the assignment of the customer prefix
-   to the customer gateway [15].  DNS configuration can be carried in
-   the same DHCPv6 message exchange used for DHCPv6 to provide that
-
-
-
-Jeong                        Informational                     [Page 13]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   information efficiently, along with any other configuration
-   information needed by the customer gateway or customer network.  This
-   service model can be useful to Home or SOHO subscribers.  The Home or
-   SOHO gateway, which is a customer gateway for ISP, can then pass that
-   RDNSS configuration information to the hosts in the customer network
-   through DHCP.
-
-5.1.3.  Well-known Anycast Addresses Approach
-
-   The well-known anycast addresses approach is also a feasible and
-   simple mechanism for ISP [7].  The use of well-known anycast
-   addresses avoids some of the security risks in rogue messages sent
-   through an external protocol such as RA or DHCPv6.  The configuration
-   of hosts for the use of well-known anycast addresses requires no
-   protocol or manual configuration, but the configuration of routing
-   for the anycast addresses requires intervention on the part of the
-   network administrator.  Also, the number of special addresses would
-   be equal to the number of RDNSSes that could be made available to
-   subscribers.
-
-5.2.  Enterprise Network
-
-   An enterprise network is defined as a network that has multiple
-   internal links, one or more router connections to one or more
-   providers, and is actively managed by a network operations entity
-   [14].  An enterprise network can get network prefixes from an ISP by
-   either manual configuration or prefix delegation [15].  In most
-   cases, because an enterprise network manages its own DNS domains, it
-   operates its own DNS servers for the domains.  These DNS servers
-   within enterprise networks process recursive DNS name resolution
-   requests from IPv6 hosts as RDNSSes.  The RDNSS configuration in the
-   enterprise network can be performed as it is in Section 4, in which
-   three approaches can be used together as follows:
-
-   1.  An IPv6 host can decide which approach is or may be used in its
-       subnet with the O flag in RA message [6][28].  As the first
-       choice in Section 4, well-known anycast addresses can be used as
-       a last resort when RDNSS information cannot be obtained through
-       either an RA option or a DHCP option.  This case needs IPv6 hosts
-       to preconfigure the well-known anycast addresses in their DNS
-       configuration files.
-
-   2.  When the enterprise prefers the well-known anycast approach to
-       others, IPv6 hosts should preconfigure the well-known anycast
-       addresses as it is in the first choice.
-
-   3.  The last choice, a more convenient and transparent way, does not
-       need IPv6 hosts to preconfigure the well-known anycast addresses
-
-
-
-Jeong                        Informational                     [Page 14]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-       because the addresses are delivered to IPv6 hosts via either the
-       RA option or DHCPv6 option as if they were unicast addresses.
-       This way is most recommended for the sake of the user's
-       convenience.
-
-5.3.  3GPP Network
-
-   The IPv6 DNS configuration is a missing part of IPv6
-   autoconfiguration and an important part of the basic IPv6
-   functionality in the 3GPP User Equipment (UE).  The higher-level
-   description of the 3GPP architecture can be found in [16], and
-   transition to IPv6 in 3GPP networks is analyzed in [17] and [18].
-
-   In the 3GPP architecture, there is a dedicated link between the UE
-   and the GGSN called the Packet Data Protocol (PDP) Context.  This
-   link is created through the PDP Context activation procedure [19].
-   There is a separate PDP context type for IPv4 and IPv6 traffic.  If a
-   3GPP UE user is communicating by using IPv6 (i.e., by having an
-   active IPv6 PDP context), it cannot be assumed that the user
-   simultaneously has an active IPv4 PDP context, and DNS queries could
-   be done using IPv4.  A 3GPP UE can thus be an IPv6 node, and somehow
-   it needs to discover the address of the RDNSS.  Before IP-based
-   services (e.g., web browsing or e-mail) can be used, the IPv6 (and
-   IPv4) RDNSS addresses need to be discovered in the 3GPP UE.
-
-   Section 5.3.1 briefly summarizes currently available mechanisms in
-   3GPP networks and recommendations. 5.3.2 analyzes the Router
-   Advertisement-based solution, 5.3.3 analyzes the Stateless DHCPv6
-   mechanism, and 5.3.4 analyzes the well-known addresses approach.
-   Section 5.3.5 summarizes the recommendations.
-
-5.3.1.  Currently Available Mechanisms and Recommendations
-
-   3GPP has defined a mechanism in which RDNSS addresses can be received
-   in the PDP context activation (a control plane mechanism).  That is
-   called the Protocol Configuration Options Information Element (PCO-
-   IE) mechanism [20].  The RDNSS addresses can also be received over
-   the air (using text messages) or typed in manually in the UE.  Note
-   that the two last mechanisms are not very well scalable.  The UE user
-   most probably does not want to type IPv6 RDNSS addresses manually in
-   the user's UE.  The use of well-known addresses is briefly discussed
-   in section 5.3.4.
-
-   It is seen that the mechanisms above most probably are not sufficient
-   for the 3GPP environment.  IPv6 is intended to operate in a zero-
-   configuration manner, no matter what the underlying network
-   infrastructure is.  Typically, the RDNSS address is needed to make an
-   IPv6 node operational, and the DNS configuration should be as simple
-
-
-
-Jeong                        Informational                     [Page 15]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   as the address autoconfiguration mechanism.  Note that there will be
-   additional IP interfaces in some near-future 3GPP UEs; e.g., 3GPP-
-   specific DNS configuration mechanisms (such as PCO-IE [20]) do not
-   work for those IP interfaces.  In other words, a good IPv6 DNS
-   configuration mechanism should also work in a multi-access network
-   environment.
-
-   From a 3GPP point of view, the best IPv6 DNS configuration solution
-   is feasible for a very large number of IPv6-capable UEs (even
-   hundreds of millions in one operator's network), is automatic, and
-   thus requires no user action.  It is suggested that a lightweight,
-   stateless mechanism be standardized for use in all network
-   environments.  The solution could then be used for 3GPP, 3GPP2, and
-   other access network technologies.  Thus, not only is a light,
-   stateless IPv6 DNS configuration mechanism needed in 3GPP networks,
-   but also 3GPP networks and UEs would certainly benefit from the new
-   mechanism.
-
-5.3.2.  RA Extension
-
-   Router Advertisement extension [6] is a lightweight IPv6 DNS
-   configuration mechanism that requires minor changes in the 3GPP UE
-   IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in
-   the 3GPP architecture) IPv6 stack.  This solution can be specified in
-   the IETF (no action is needed in the 3GPP) and taken in use in 3GPP
-   UEs and GGSNs.
-
-   In this solution, an IPv6-capable UE configures DNS information via
-   an RA message sent by its default router (GGSN); i.e., the RDNSS
-   option for a recursive DNS server is included in the RA message.
-   This solution is easily scalable for a very large number of UEs.  The
-   operator can configure the RDNSS addresses in the GGSN as a part of
-   normal GGSN configuration.  The IPv6 RDNSS address is received in the
-   Router Advertisement, and an extra Round Trip Time (RTT) for asking
-   RDNSS addresses can be avoided.
-
-   When one considers the cons, this mechanism still requires
-   standardization effort in the IETF, and the end nodes and routers
-   need to support this mechanism.  The equipment software update
-   should, however, be pretty straightforward, and new IPv6 equipment
-   could support RA extension already from the beginning.
-
-5.3.3.  Stateless DHCPv6
-
-   A DHCPv6-based solution needs the implementation of Stateless DHCP
-   [4] and DHCPv6 DNS options [5] in the UE, and a DHCPv6 server in the
-   operator's network.  A possible configuration is such that the GGSN
-   works as a DHCP relay.
-
-
-
-Jeong                        Informational                     [Page 16]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   The pros of a stateless DHCPv6-based solution are:
-
-   1.  Stateless DHCPv6 is a standardized mechanism.
-
-   2.  DHCPv6 can be used for receiving configuration information other
-       than RDNSS addresses; e.g., SIP server addresses.
-
-   3.  DHCPv6 works in different network environments.
-
-   4.  When DHCPv6 service is deployed through a single, centralized
-       server, the RDNSS configuration information can be updated by the
-       network administrator at a single source.
-
-   Some issues with DHCPv6 in 3GPP networks are listed below:
-
-   1.  DHCPv6 requires an additional server in the network unless the
-       (Stateless) DHCPv6 functionality is integrated into an existing
-       router.  This means that there might be one additional server to
-       be maintained.
-
-   2.  DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
-       (3GPP Stateless Address Autoconfiguration is typically used) and
-       is not automatically implemented in 3GPP IPv6 UEs.
-
-   3.  Scalability and reliability of DHCPv6 in very large 3GPP networks
-       (with tens or hundreds of millions of UEs) may be an issue; at
-       least the redundancy needs to be taken care of.  However, if the
-       DHCPv6 service is integrated into the network elements, such as a
-       router operating system, scalability and reliability is
-       comparable with other DNS configuration approaches.
-
-   4.  It is sub-optimal to utilize the radio resources in 3GPP networks
-       for DHCPv6 messages if there is a simpler alternative is
-       available.
-
-       *  The use of stateless DHCPv6 adds one round-trip delay to the
-          case in which the UE can start transmitting data right after
-          the Router Advertisement.
-
-   5.  If the DNS information (suddenly) changes, Stateless DHCPv6
-       cannot automatically update the UE; see [21].
-
-5.3.4.  Well-known Addresses
-
-   Using well-known addresses is also a feasible and light mechanism for
-   3GPP UEs.  Those well-known addresses can be preconfigured in the UE
-   software and the operator can make the corresponding configuration on
-   the network side.  Thus, this is a very easy mechanism for the UE,
-
-
-
-Jeong                        Informational                     [Page 17]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   but it requires some configuration work in the network.  When using
-   well-known addresses, UE forwards queries to any of the preconfigured
-   addresses.  In the current proposal [7], IPv6 anycast addresses are
-   suggested.
-
-   Note: An IPv6 DNS configuration proposal, based on the use of well-
-   known site-local addresses, was developed by the IPv6 Working Group;
-   it was seen as a feasible mechanism for 3GPP UEs, although no IETF
-   consensus was reached on this proposal.  In the end, the deprecation
-   of IPv6 site-local addresses made it impossible to standardize a
-   mechanism that uses site-local addresses as well-known addresses.
-   However, as of this writing, this mechanism is implemented in some
-   operating systems and 3GPP UEs as a last resort of IPv6 DNS
-   configuration.
-
-5.3.5.  Recommendations
-
-   It is suggested that a lightweight, stateless DNS configuration
-   mechanism be specified as soon as possible.  From a 3GPP UE and
-   network point of view, the Router Advertisement-based mechanism looks
-   most promising.  The sooner a light, stateless mechanism is
-   specified, the sooner we can stop using well-known site-local
-   addresses for IPv6 DNS configuration.
-
-5.4.  Unmanaged Network
-
-   There are four deployment scenarios of interest in unmanaged networks
-   [22]:
-
-   1.  A gateway that does not provide IPv6 at all,
-
-   2.  A dual-stack gateway connected to a dual-stack ISP,
-
-   3.  A dual-stack gateway connected to an IPv4-only ISP, and
-
-   4.  A gateway connected to an IPv6-only ISP.
-
-5.4.1.  Case A: Gateway Does Not Provide IPv6 at All
-
-   In this case, the gateway does not provide IPv6; the ISP may or may
-   not provide IPv6.  Automatic or Configured tunnels are the
-   recommended transition mechanisms for this scenario.
-
-   The case where dual-stack hosts behind an NAT need access to an IPv6
-   RDNSS cannot be entirely ruled out.  The DNS configuration mechanism
-   has to work over the tunnel, and the underlying tunneling mechanism
-   could implement NAT traversal.  The tunnel server assumes the role of
-   a relay (for both DHCP and well-known anycast addresses approaches).
-
-
-
-Jeong                        Informational                     [Page 18]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   The RA-based mechanism is relatively straightforward in its
-   operation, assuming the tunnel server is also the IPv6 router
-   emitting RAs.  The well-known anycast addresses approach also seems
-   simple in operation across the tunnel, but the deployment model using
-   well-known anycast addresses in a tunneled environment is unclear or
-   not well understood.
-
-5.4.2.  Case B: A Dual-stack Gateway Connected to a Dual-stack ISP
-
-   This is similar to a typical IPv4 home user scenario, where DNS
-   configuration parameters are obtained using DHCP.  The exception is
-   that Stateless DHCPv6 is used, as opposed to the IPv4 scenario, where
-   the DHCP server is stateful (it maintains the state for clients).
-
-5.4.3.  Case C: A Dual-stack Gateway Connected to an IPv4-only ISP
-
-   This is similar to Case B.  If a gateway provides IPv6 connectivity
-   by managing tunnels, then it is also supposed to provide access to an
-   RDNSS.  Like this, the tunnel for IPv6 connectivity originates from
-   the dual-stack gateway instead of from the host.
-
-5.4.4.  Case D: A Gateway Connected to an IPv6-only ISP
-
-   This is similar to Case B.
-
-6.  Security Considerations
-
-   As security requirements depend solely on applications and differ
-   from application to application, there can be no generic requirement
-   defined at the IP or application layer for DNS.
-
-   However, note that cryptographic security requires configured secret
-   information and that full autoconfiguration and cryptographic
-   security are mutually exclusive.  People insisting on secure, full
-   autoconfiguration will get false security, false autoconfiguration,
-   or both.
-
-   In some deployment scenarios [17], where cryptographic security is
-   required for applications, the secret information for the
-   cryptographic security is preconfigured, through which application-
-   specific configuration data, including those for DNS, can be securely
-   configured.  Note that if applications requiring cryptographic
-   security depend on DNS, the applications also require cryptographic
-   security to DNS.  Therefore, the full autoconfiguration of DNS is not
-   acceptable.
-
-   However, with full autoconfiguration, weaker but still reasonable
-   security is being widely accepted and will continue to be acceptable.
-
-
-
-Jeong                        Informational                     [Page 19]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   That is, with full autoconfiguration, which means there is no
-   cryptographic security for the autoconfiguration, it is already
-   assumed that the local environment is secure enough that the
-   information from the local autoconfiguration server has acceptable
-   security even without cryptographic security.  Thus, the
-   communication between the local DNS client and local DNS server has
-   acceptable security.
-
-   In autoconfiguring recursive servers, DNSSEC may be overkill, because
-   DNSSEC [23]-[25] needs the configuration and reconfiguration of
-   clients at root key roll-over [26][27].  Even if additional keys for
-   secure key roll-over are added at the initial configuration, they are
-   as vulnerable as the original keys to some forms of attack, such as
-   social hacking.  Another problem of using DNSSEC and
-   autoconfiguration together is that DNSSEC requires secure time, which
-   means secure communication with autoconfigured time servers, which
-   requires configured secret information.  Therefore, in order that the
-   autoconfiguration may be secure, configured secret information is
-   required.
-
-   If DNSSEC [23]-[25] is used and the signatures are verified on the
-   client host, the misconfiguration of a DNS server may simply be
-   denial of service.  Also, if local routing environment is not
-   reliable, clients may be directed to a false resolver with the same
-   IP address as the true one.
-
-6.1.  RA Option
-
-   The security of RA option for RDNSS is the same as the ND protocol
-   security [1][6].  The RA option does not add any new vulnerability.
-
-   Note that the vulnerability of ND is not worse and is a subset of the
-   attacks that any node attached to a LAN can do independently of ND.
-   A malicious node on a LAN can promiscuously receive packets for any
-   router's MAC address and send packets with the router's MAC address
-   as the source MAC address in the L2 header.  As a result, the L2
-   switches send packets addressed to the router to the malicious node.
-   Also, this attack can send redirects that tell the hosts to send
-   their traffic somewhere else.  The malicious node can send
-   unsolicited RA or NA replies, answer RS or NS requests, etc.  All of
-   this can be done independently of implementing ND.  Therefore, the RA
-   option for RDNSS does not add to the vulnerability.
-
-   Security issues regarding the ND protocol were discussed by the IETF
-   SEND (Securing Neighbor Discovery) Working Group, and RFC 3971 for
-   the ND security has been published [12].
-
-
-
-
-
-Jeong                        Informational                     [Page 20]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-6.2.  DHCPv6 Option
-
-   The DNS Recursive Name Server option may be used by an intruder DHCP
-   server to cause DHCP clients to send DNS queries to an intruder DNS
-   recursive name server [5].  The results of these misdirected DNS
-   queries may be used to spoof DNS names.
-
-   To avoid attacks through the DNS Recursive Name Server option, the
-   DHCP client SHOULD require DHCP authentication (see "Authentication
-   of DHCP messages" in RFC 3315 [3][13]) before installing a list of
-   DNS recursive name servers obtained through authenticated DHCP.
-
-6.3.  Well-known Anycast Addresses
-
-   The well-known anycast addresses approach is not a protocol, thus
-   there is no need to secure the protocol itself.
-
-   However, denial of service attacks on the DNS resolver system might
-   be easier to achieve as the anycast addresses used are by definition
-   well known.
-
-7.  Contributors
-
-   Ralph Droms
-   Cisco Systems, Inc.
-   1414 Massachusetts Ave.
-   Boxboro, MA  01719
-   US
-
-   Phone: +1 978 936 1674
-   EMail: rdroms@cisco.com
-
-
-   Robert M. Hinden
-   Nokia
-   313 Fairchild Drive
-   Mountain View, CA  94043
-   US
-
-   Phone: +1 650 625 2004
-   EMail: bob.hinden@nokia.com
-
-
-
-
-
-
-
-
-
-
-Jeong                        Informational                     [Page 21]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   Ted Lemon
-   Nominum, Inc.
-   950 Charter Street
-   Redwood City, CA  94043
-   US
-
-   EMail: Ted.Lemon@nominum.com
-
-   Masataka Ohta
-   Tokyo Institute of Technology
-   2-12-1, O-okayama, Meguro-ku
-   Tokyo  152-8552
-   Japan
-
-   Phone: +81 3 5734 3299
-   Fax:   +81 3 5734 3299
-   EMail: mohta@necom830.hpcl.titech.ac.jp
-
-
-   Soohong Daniel Park
-   Mobile Platform Laboratory, SAMSUNG Electronics
-   416 Maetan-3dong, Yeongtong-Gu
-   Suwon, Gyeonggi-Do  443-742
-   Korea
-
-   Phone: +82 31 200 4508
-   EMail: soohong.park@samsung.com
-
-
-   Suresh Satapati
-   Cisco Systems, Inc.
-   San Jose, CA  95134
-   US
-
-   EMail: satapati@cisco.com
-
-
-   Juha Wiljakka
-   Nokia
-   Visiokatu 3
-   FIN-33720, TAMPERE
-   Finland
-
-   Phone: +358 7180 48372
-   EMail: juha.wiljakka@nokia.com
-
-
-
-
-
-
-Jeong                        Informational                     [Page 22]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-8.  Acknowledgements
-
-   This document has greatly benefited from inputs by David Meyer, Rob
-   Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
-   Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley.
-   Also, Tony Bonanno proofread this document.  The authors appreciate
-   their contribution.
-
-9.  References
-
-9.1.  Normative References
-
-   [1]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
-        for IP Version 6 (IPv6)", RFC 2461, December 1998.
-
-   [2]  Thomson, S. and T. Narten, "IPv6 Stateless Address
-        Autoconfiguration", RFC 2462, December 1998.
-
-   [3]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
-        Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
-        RFC 3315, July 2003.
-
-   [4]  Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
-        Service for IPv6", RFC 3736, April 2004.
-
-   [5]  Droms, R., "DNS Configuration options for Dynamic Host
-        Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
-        2003.
-
-9.2.  Informative References
-
-   [6]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6
-        Router Advertisement Option for DNS Configuration", Work in
-        Progress, September 2005.
-
-   [7]  Ohta, M., "Preconfigured DNS Server Addresses", Work in
-        Progress, February 2004.
-
-   [8]  Venaas, S., Chown, T., and B. Volz, "Information Refresh Time
-        Option for Dynamic Host Configuration Protocol for IPv6
-        (DHCPv6)", RFC 4242, November 2005.
-
-   [9]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
-        Service", RFC 1546, November 1993.
-
-   [10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
-        Addressing Architecture", RFC 3513, April 2003.
-
-
-
-
-Jeong                        Informational                     [Page 23]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   [11] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola,
-        "Scenarios and Analysis for Introducing IPv6 into ISP Networks",
-        RFC 4029, March 2005.
-
-   [12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
-        Neighbor Discovery (SEND)", RFC 3971, March 2005.
-
-   [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
-        RFC 3118, June 2001.
-
-   [14] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June
-        2005.
-
-   [15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
-        Configuration Protocol (DHCP) version 6", RFC 3633, December
-        2003.
-
-   [16] Wasserman, M., "Recommendations for IPv6 in Third Generation
-        Partnership Project (3GPP) Standards", RFC 3314, September 2002.
-
-   [17] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC
-        3574, August 2003.
-
-   [18] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation
-        Partnership Project (3GPP) Networks", RFC 4215, October 2005.
-
-   [19] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
-        Service description; Stage 2 (Release 5)", December 2002.
-
-   [20] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
-        specification; Core network protocols; Stage 3 (Release 5)",
-        June 2003.
-
-   [21] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
-        Requirements for Stateless Dynamic Host Configuration Protocol
-        for IPv6 (DHCPv6)", RFC 4076, May 2005.
-
-   [22] Huitema, C., Austein, R., Satapati, S., and R. van der Pol,
-        "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April
-        2004.
-
-   [23] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033, March
-        2005.
-
-   [24] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-
-
-Jeong                        Informational                     [Page 24]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
-
-
-   [25] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions", RFC
-        4035, March 2005.
-
-   [26] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", Work
-        in Progress, October 2005.
-
-   [27] Guette, G. and O. Courtay, "Requirements for Automated Key
-        Rollover in DNSSEC", Work in Progress, January 2005.
-
-   [28] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M
-        and O Flags of IPv6 Router Advertisement", Work in Progress,
-        March 2005.
-
-Author's Address
-
-   Jaehoon Paul Jeong (editor)
-   ETRI/Department of Computer Science and Engineering
-   University of Minnesota
-   117 Pleasant Street SE
-   Minneapolis, MN  55455
-   US
-
-   Phone: +1 651 587 7774
-   Fax:   +1 612 625 2002
-   EMail: jjeong@cs.umn.edu
-   URI:   http://www.cs.umn.edu/~jjeong/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                        Informational                     [Page 25]
-
-RFC 4339         IPv6 Host Configuration of DNS Server     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).
-
-
-
-
-
-
-
-Jeong                        Informational                     [Page 26]
-
diff --git a/doc/rfc/rfc4343.txt b/doc/rfc/rfc4343.txt
deleted file mode 100644
index 621420a4..00000000
--- a/doc/rfc/rfc4343.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 4343                         Motorola Laboratories
-Updates: 1034, 1035, 2181                                   January 2006
-Category: Standards Track
-
-
-       Domain Name System (DNS) Case Insensitivity Clarification
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   Domain Name System (DNS) names are "case insensitive".  This document
-   explains exactly what that means and provides a clear specification
-   of the rules.  This clarification updates RFCs 1034, 1035, and 2181.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Case Insensitivity of DNS Labels ................................2
-      2.1. Escaping Unusual DNS Label Octets ..........................2
-      2.2. Example Labels with Escapes ................................3
-   3. Name Lookup, Label Types, and CLASS .............................3
-      3.1. Original DNS Label Types ...................................4
-      3.2. Extended Label Type Case Insensitivity Considerations ......4
-      3.3. CLASS Case Insensitivity Considerations ....................4
-   4. Case on Input and Output ........................................5
-      4.1. DNS Output Case Preservation ...............................5
-      4.2. DNS Input Case Preservation ................................5
-   5. Internationalized Domain Names ..................................6
-   6. Security Considerations .........................................6
-   7. Acknowledgements ................................................7
-   Normative References................................................7
-   Informative References..............................................8
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 1]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-1.  Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information.  Each node in the DNS tree has a name consisting
-   of zero or more labels [STD13, RFC1591, RFC2606] that are treated in
-   a case insensitive fashion.  This document clarifies the meaning of
-   "case insensitive" for the DNS.  This clarification updates RFCs
-   1034, 1035 [STD13], and [RFC2181].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Case Insensitivity of DNS Labels
-
-   DNS was specified in the era of [ASCII].  DNS names were expected to
-   look like most host names or Internet email address right halves (the
-   part after the at-sign, "@") or to be numeric, as in the in-addr.arpa
-   part of the DNS name space.  For example,
-
-       foo.example.net.
-       aol.com.
-       www.gnu.ai.mit.edu.
-   or  69.2.0.192.in-addr.arpa.
-
-   Case-varied alternatives to the above [RFC3092] would be DNS names
-   like
-
-       Foo.ExamplE.net.
-       AOL.COM.
-       WWW.gnu.AI.mit.EDU.
-   or  69.2.0.192.in-ADDR.ARPA.
-
-   However, the individual octets of which DNS names consist are not
-   limited to valid ASCII character codes.  They are 8-bit bytes, and
-   all values are allowed.  Many applications, however, interpret them
-   as ASCII characters.
-
-2.1.  Escaping Unusual DNS Label Octets
-
-   In Master Files [STD13] and other human-readable and -writable ASCII
-   contexts, an escape is needed for the byte value for period (0x2E,
-   ".") and all octet values outside of the inclusive range from 0x21
-   ("!") to 0x7E ("~").  That is to say, 0x2E and all octet values in
-   the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF.
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 2]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   One typographic convention for octets that do not correspond to an
-   ASCII printing graphic is to use a back-slash followed by the value
-   of the octet as an unsigned integer represented by exactly three
-   decimal digits.
-
-   The same convention can be used for printing ASCII characters so that
-   they will be treated as a normal label character.  This includes the
-   back-slash character used in this convention itself, which can be
-   expressed as \092 or \\, and the special label separator period
-   ("."), which can be expressed as and \046 or \.  It is advisable to
-   avoid using a backslash to quote an immediately following non-
-   printing ASCII character code to avoid implementation difficulties.
-
-   A back-slash followed by only one or two decimal digits is undefined.
-   A back-slash followed by four decimal digits produces two octets, the
-   first octet having the value of the first three digits considered as
-   a decimal number, and the second octet being the character code for
-   the fourth decimal digit.
-
-2.2.  Example Labels with Escapes
-
-   The first example below shows embedded spaces and a period (".")
-   within a label.  The second one shows a 5-octet label where the
-   second octet has all bits zero, the third is a backslash, and the
-   fourth octet has all bits one.
-
-         Donald\032E\.\032Eastlake\0323rd.example.
-   and   a\000\\\255z.example.
-
-3.  Name Lookup, Label Types, and CLASS
-
-   According to the original DNS design decision, comparisons on name
-   lookup for DNS queries should be case insensitive [STD13].  That is
-   to say, a lookup string octet with a value in the inclusive range
-   from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the
-   identical value and also match the corresponding value in the
-   inclusive range from 0x61 to 0x7A, the lowercase ASCII letters.  A
-   lookup string octet with a lowercase ASCII letter value MUST
-   similarly match the identical value and also match the corresponding
-   value in the uppercase ASCII letter range.
-
-   (Historical note: The terms "uppercase" and "lowercase" were invented
-   after movable type.  The terms originally referred to the two font
-   trays for storing, in partitioned areas, the different physical type
-   elements.  Before movable type, the nearest equivalent terms were
-   "majuscule" and "minuscule".)
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 3]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   One way to implement this rule would be to subtract 0x20 from all
-   octets in the inclusive range from 0x61 to 0x7A before comparing
-   octets.  Such an operation is commonly known as "case folding", but
-   implementation via case folding is not required.  Note that the DNS
-   case insensitivity does NOT correspond to the case folding specified
-   in [ISO-8859-1] or [ISO-8859-2].  For example, the octets 0xDD (\221)
-   and 0xFD (\253) do NOT match, although in other contexts, where they
-   are interpreted as the upper- and lower-case version of "Y" with an
-   acute accent, they might.
-
-3.1.  Original DNS Label Types
-
-   DNS labels in wire-encoded names have a type associated with them.
-   The original DNS standard [STD13] had only two types: ASCII labels,
-   with a length from zero to 63 octets, and indirect (or compression)
-   labels, which consist of an offset pointer to a name location
-   elsewhere in the wire encoding on a DNS message.  (The ASCII label of
-   length zero is reserved for use as the name of the root node of the
-   name tree.)  ASCII labels follow the ASCII case conventions described
-   herein and, as stated above, can actually contain arbitrary byte
-   values.  Indirect labels are, in effect, replaced by the name to
-   which they point, which is then treated with the case insensitivity
-   rules in this document.
-
-3.2.  Extended Label Type Case Insensitivity Considerations
-
-   DNS was extended by [RFC2671] so that additional label type numbers
-   would be available.  (The only such type defined so far is the BINARY
-   type [RFC2673], which is now Experimental [RFC3363].)
-
-   The ASCII case insensitivity conventions only apply to ASCII labels;
-   that is to say, label type 0x0, whether appearing directly or invoked
-   by indirect labels.
-
-3.3.  CLASS Case Insensitivity Considerations
-
-   As described in [STD13] and [RFC2929], DNS has an additional axis for
-   data location called CLASS.  The only CLASS in global use at this
-   time is the "IN" (Internet) CLASS.
-
-   The handling of DNS label case is not CLASS dependent.  With the
-   original design of DNS, it was intended that a recursive DNS resolver
-   be able to handle new CLASSes that were unknown at the time of its
-   implementation.  This requires uniform handling of label case
-   insensitivity.  Should it become desirable, for example, to allocate
-   a CLASS with "case sensitive ASCII labels", it would be necessary to
-   allocate a new label type for these labels.
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 4]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-4.  Case on Input and Output
-
-   While ASCII label comparisons are case insensitive, [STD13] says case
-   MUST be preserved on output and preserved when convenient on input.
-   However, this means less than it would appear, since the preservation
-   of case on output is NOT required when output is optimized by the use
-   of indirect labels, as explained below.
-
-4.1.  DNS Output Case Preservation
-
-   [STD13] views the DNS namespace as a node tree.  ASCII output is as
-   if a name were marshaled by taking the label on the node whose name
-   is to be output, converting it to a typographically encoded ASCII
-   string, walking up the tree outputting each label encountered, and
-   preceding all labels but the first with a period (".").  Wire output
-   follows the same sequence, but each label is wire encoded, and no
-   periods are inserted.  No "case conversion" or "case folding" is done
-   during such output operations, thus "preserving" case.  However, to
-   optimize output, indirect labels may be used to point to names
-   elsewhere in the DNS answer.  In determining whether the name to be
-   pointed to (for example, the QNAME) is the "same" as the remainder of
-   the name being optimized, the case insensitive comparison specified
-   above is done.  Thus, such optimization may easily destroy the output
-   preservation of case.  This type of optimization is commonly called
-   "name compression".
-
-4.2.  DNS Input Case Preservation
-
-   Originally, DNS data came from an ASCII Master File as defined in
-   [STD13] or a zone transfer.  DNS Dynamic update and incremental zone
-   transfers [RFC1995] have been added as a source of DNS data [RFC2136,
-   RFC3007].  When a node in the DNS name tree is created by any of such
-   inputs, no case conversion is done.  Thus, the case of ASCII labels
-   is preserved if they are for nodes being created.  However, when a
-   name label is input for a node that already exists in DNS data being
-   held, the situation is more complex.  Implementations are free to
-   retain the case first loaded for such a label, to allow new input to
-   override the old case, or even to maintain separate copies preserving
-   the input case.
-
-   For example, if data with owner name "foo.bar.example" [RFC3092] is
-   loaded and then later data with owner name "xyz.BAR.example" is
-   input, the name of the label on the "bar.example" node (i.e., "bar")
-   might or might not be changed to "BAR" in the DNS stored data.  Thus,
-   later retrieval of data stored under "xyz.bar.example" in this case
-   can use "xyz.BAR.example" in all returned data, use "xyz.bar.example"
-   in all returned data, or even, when more than one RR is being
-   returned, use a mixture of these two capitalizations.  This last case
-
-
-
-Eastlake 3rd                Standards Track                     [Page 5]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   is unlikely, as optimization of answer length through indirect labels
-   tends to cause only one copy of the name tail ("bar.example" or
-   "BAR.example") to be used for all returned RRs.  Note that none of
-   this has any effect on the number or completeness of the RR set
-   returned, only on the case of the names in the RR set returned.
-
-   The same considerations apply when inputting multiple data records
-   with owner names differing only in case.  For example, if an "A"
-   record is the first resource record stored under owner name
-   "xyz.BAR.example" and then a second "A" record is stored under
-   "XYZ.BAR.example", the second MAY be stored with the first (lower
-   case initial label) name, the second MAY override the first so that
-   only an uppercase initial label is retained, or both capitalizations
-   MAY be kept in the DNS stored data.  In any case, a retrieval with
-   either capitalization will retrieve all RRs with either
-   capitalization.
-
-   Note that the order of insertion into a server database of the DNS
-   name tree nodes that appear in a Master File is not defined so that
-   the results of inconsistent capitalization in a Master File are
-   unpredictable output capitalization.
-
-5.  Internationalized Domain Names
-
-   A scheme has been adopted for "internationalized domain names" and
-   "internationalized labels" as described in [RFC3490, RFC3454,
-   RFC3491, and RFC3492].  It makes most of [UNICODE] available through
-   a separate application level transformation from internationalized
-   domain name to DNS domain name and from DNS domain name to
-   internationalized domain name.  Any case insensitivity that
-   internationalized domain names and labels have varies depending on
-   the script and is handled entirely as part of the transformation
-   described in [RFC3454] and [RFC3491], which should be seen for
-   further details.  This is not a part of the DNS as standardized in
-   STD 13.
-
-6.  Security Considerations
-
-   The equivalence of certain DNS label types with case differences, as
-   clarified in this document, can lead to security problems.  For
-   example, a user could be confused by believing that two domain names
-   differing only in case were actually different names.
-
-   Furthermore, a domain name may be used in contexts other than the
-   DNS.  It could be used as a case sensitive index into some database
-   or file system.  Or it could be interpreted as binary data by some
-   integrity or authentication code system.  These problems can usually
-   be handled by using a standardized or "canonical" form of the DNS
-
-
-
-Eastlake 3rd                Standards Track                     [Page 6]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   ASCII type labels; that is, always mapping the ASCII letter value
-   octets in ASCII labels to some specific pre-chosen case, either
-   uppercase or lower case.  An example of a canonical form for domain
-   names (and also a canonical ordering for them) appears in Section 6
-   of [RFC4034].  See also [RFC3597].
-
-   Finally, a non-DNS name may be stored into DNS with the false
-   expectation that case will always be preserved.  For example,
-   although this would be quite rare, on a system with case sensitive
-   email address local parts, an attempt to store two Responsible Person
-   (RP) [RFC1183] records that differed only in case would probably
-   produce unexpected results that might have security implications.
-   That is because the entire email address, including the possibly case
-   sensitive local or left-hand part, is encoded into a DNS name in a
-   readable fashion where the case of some letters might be changed on
-   output as described above.
-
-7.  Acknowledgements
-
-   The contributions to this document by Rob Austein, Olafur
-   Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
-   Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
-   are gratefully acknowledged.
-
-Normative References
-
-   [ASCII]      ANSI, "USA Standard Code for Information Interchange",
-                X3.4, American National Standards Institute: New York,
-                1968.
-
-   [RFC1995]    Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-                August 1996.
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136]    Vixie, P., Thomson,  S., Rekhter, Y., and J. Bound,
-                "Dynamic Updates in the Domain Name System (DNS
-                UPDATE)", RFC 2136, April 1997.
-
-   [RFC2181]     Elz, R. and R. Bush, "Clarifications to the DNS
-                Specification", RFC 2181, July 1997.
-
-   [RFC3007]    Wellington, B., "Secure Domain Name System (DNS) Dynamic
-                Update", RFC 3007, November 2000.
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 7]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   [RFC3597]    Gustafsson, A., "Handling of Unknown DNS Resource Record
-                (RR) Types", RFC 3597, September 2003.
-
-   [RFC4034]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
-                Rose, "Resource Records for the DNS Security
-                Extensions", RFC 4034, March 2005.
-
-   [STD13]      Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034, November 1987.
-
-                Mockapetris, P., "Domain names - implementation and
-                specification", STD 13, RFC 1035, November 1987.
-
-Informative References
-
-   [ISO-8859-1] International Standards Organization, Standard for
-                Character Encodings, Latin-1.
-
-   [ISO-8859-2] International Standards Organization, Standard for
-                Character Encodings, Latin-2.
-
-   [RFC1183]    Everhart, C., Mamakos, L., Ullmann, R., and P.
-                Mockapetris, "New DNS RR Definitions", RFC 1183, October
-                1990.
-
-   [RFC1591]    Postel, J., "Domain Name System Structure and
-                Delegation", RFC 1591, March 1994.
-
-   [RFC2606]    Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
-                Names", BCP 32, RFC 2606, June 1999.
-
-   [RFC2929]    Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
-                "Domain Name System (DNS) IANA Considerations", BCP 42,
-                RFC 2929, September 2000.
-
-   [RFC2671]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-                2671, August 1999.
-
-   [RFC2673]    Crawford, M., "Binary Labels in the Domain Name System",
-                RFC 2673, August 1999.
-
-   [RFC3092]    Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
-                of "Foo"", RFC 3092, 1 April 2001.
-
-   [RFC3363]    Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
-                Hain, "Representing Internet Protocol version 6 (IPv6)
-                Addresses in the Domain Name System (DNS)", RFC 3363,
-                August 2002.
-
-
-
-Eastlake 3rd                Standards Track                     [Page 8]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
-                "Internationalizing Domain Names in Applications
-                (IDNA)", RFC 3490, March 2003.
-
-   [RFC3491]    Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
-                Profile for Internationalized Domain Names (IDN)", RFC
-                3491, March 2003.
-
-   [RFC3492]    Costello, A., "Punycode: A Bootstring encoding of
-                Unicode for Internationalized Domain Names in
-                Applications (IDNA)", RFC 3492, March 2003.
-
-   [UNICODE]    The Unicode Consortium, "The Unicode Standard",
-                <http://www.unicode.org/unicode/standard/standard.html>.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Phone: +1 508-786-7554 (w)
-   EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 9]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                    [Page 10]
-
diff --git a/doc/rfc/rfc4367.txt b/doc/rfc/rfc4367.txt
deleted file mode 100644
index f066b646..00000000
--- a/doc/rfc/rfc4367.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                  J. Rosenberg, Ed.
-Request for Comments: 4367                                           IAB
-Category: Informational                                    February 2006
-
-
-          What's in a Name: False Assumptions about DNS Names
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   The Domain Name System (DNS) provides an essential service on the
-   Internet, mapping structured names to a variety of data, usually IP
-   addresses.  These names appear in email addresses, Uniform Resource
-   Identifiers (URIs), and other application-layer identifiers that are
-   often rendered to human users.  Because of this, there has been a
-   strong demand to acquire names that have significance to people,
-   through equivalence to registered trademarks, company names, types of
-   services, and so on.  There is a danger in this trend; the humans and
-   automata that consume and use such names will associate specific
-   semantics with some names and thereby make assumptions about the
-   services that are, or should be, provided by the hosts associated
-   with the names.  Those assumptions can often be false, resulting in a
-   variety of failure conditions.  This document discusses this problem
-   in more detail and makes recommendations on how it can be avoided.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg                    Informational                      [Page 1]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Target Audience .................................................4
-   3. Modeling Usage of the DNS .......................................4
-   4. Possible Assumptions ............................................5
-      4.1. By the User ................................................5
-      4.2. By the Client ..............................................6
-      4.3. By the Server ..............................................7
-   5. Consequences of False Assumptions ...............................8
-   6. Reasons Why the Assumptions Can Be False ........................9
-      6.1. Evolution ..................................................9
-      6.2. Leakage ...................................................10
-      6.3. Sub-Delegation ............................................10
-      6.4. Mobility ..................................................12
-      6.5. Human Error ...............................................12
-   7. Recommendations ................................................12
-   8. A Note on RFC 2219 and RFC 2782 ................................13
-   9. Security Considerations ........................................14
-   10. Acknowledgements ..............................................14
-   11. IAB Members ...................................................14
-   12. Informative References ........................................15
-
-1.  Introduction
-
-   The Domain Name System (DNS) [1] provides an essential service on the
-   Internet, mapping structured names to a variety of different types of
-   data.  Most often it is used to obtain the IP address of a host
-   associated with that name [2] [1] [3].  However, it can be used to
-   obtain other information, and proposals have been made for nearly
-   everything, including geographic information [4].
-
-   Domain names are most often used in identifiers used by application
-   protocols.  The most well known include email addresses and URIs,
-   such as the HTTP URL [5], Real Time Streaming Protocol (RTSP) URL
-   [6], and SIP URI [7].  These identifiers are ubiquitous, appearing on
-   business cards, web pages, street signs, and so on.  Because of this,
-   there has been a strong demand to acquire domain names that have
-   significance to people through equivalence to registered trademarks,
-   company names, types of services, and so on.  Such identifiers serve
-   many business purposes, including extension of brand, advertising,
-   and so on.
-
-   People often make assumptions about the type of service that is or
-   should be provided by a host associated with that name, based on
-   their expectations and understanding of what the name implies.  This,
-   in turn, triggers attempts by organizations to register domain names
-   based on that presumed user expectation.  Examples of this are the
-
-
-
-Rosenberg                    Informational                      [Page 2]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   various proposals for a Top-Level Domain (TLD) that could be
-   associated with adult content [8], the requests for creation of TLDs
-   associated with mobile devices and services, and even phishing
-   attacks.
-
-   When these assumptions are codified into the behavior of an
-   automaton, such as an application client or server, as a result of
-   implementor choice, management directive, or domain owner policy, the
-   overall system can fail in various ways.  This document describes a
-   number of typical ways in which these assumptions can be codified,
-   how they can be wrong, the consequences of those mistakes, and the
-   recommended ways in which they can be avoided.
-
-   Section 4 describes some of the possible assumptions that clients,
-   servers, and people can make about a domain name.  In this context,
-   an "assumption" is defined as any behavior that is expected when
-   accessing a service at a domain name, even though the behavior is not
-   explicitly codified in protocol specifications.  Frequently, these
-   assumptions involve ignoring parts of a specification based on an
-   assumption that the client or server is deployed in an environment
-   that is more rigid than the specification allows.  Section 5
-   overviews some of the consequences of these false assumptions.
-   Generally speaking, these consequences can include a variety of
-   different interoperability failures, user experience failures, and
-   system failures.  Section 6 discusses why these assumptions can be
-   false from the very beginning or become false at some point in the
-   future.  Most commonly, they become false because the environment
-   changes in unexpected ways over time, and what was a valid assumption
-   before, no longer is.  Other times, the assumptions prove wrong
-   because they were based on the belief that a specific community of
-   clients and servers was participating, and an element outside of that
-   community began participating.
-
-   Section 7 then provides some recommendations.  These recommendations
-   encapsulate some of the engineering mantras that have been at the
-   root of Internet protocol design for decades.  These include:
-
-      Follow the specifications.
-
-      Use the capability negotiation techniques provided in the
-      protocols.
-
-      Be liberal in what you accept, and conservative in what you send.
-      [18]
-
-   Overall, automata should not change their behavior within a protocol
-   based on the domain name, or some component of the domain name, of
-   the host they are communicating with.
-
-
-
-Rosenberg                    Informational                      [Page 3]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-2.  Target Audience
-
-   This document has several audiences.  Firstly, it is aimed at
-   implementors who ultimately develop the software that make the false
-   assumptions that are the subject of this document.  The
-   recommendations described here are meant to reinforce the engineering
-   guidelines that are often understood by implementors, but frequently
-   forgotten as deadlines near and pressures mount.
-
-   The document is also aimed at technology managers, who often develop
-   the requirements that lead to these false assumptions.  For them,
-   this document serves as a vehicle for emphasizing the importance of
-   not taking shortcuts in the scope of applicability of a project.
-
-   Finally, this document is aimed at domain name policy makers and
-   administrators.  For them, it points out the perils in establishing
-   domain policies that get codified into the operation of applications
-   running within that domain.
-
-3.  Modeling Usage of the DNS
-
-
-                       +--------+
-                       |        |
-                       |        |
-                       |  DNS   |
-                       |Service |
-                       |        |
-                       +--------+
-                         ^   |
-                         |   |
-                         |   |
-                         |   |
-          /--\           |   |
-         |    |          |   V
-         |    |        +--------+                     +--------+
-          \--/         |        |                     |        |
-            |          |        |                     |        |
-         ---+---       | Client |-------------------->| Server |
-            |          |        |                     |        |
-            |          |        |                     |        |
-           /\          +--------+                     +--------+
-          /  \
-         /    \
-
-         User
-                                 Figure 1
-
-
-
-
-Rosenberg                    Informational                      [Page 4]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   Figure 1 shows a simple conceptual model of how the DNS is used by
-   applications.  A user of the application obtains an identifier for
-   particular content or service it wishes to obtain.  This identifier
-   is often a URL or URI that contains a domain name.  The user enters
-   this identifier into its client application (for example, by typing
-   in the URL in a web browser window).  The client is the automaton (a
-   software and/or hardware system) that contacts a server for that
-   application in order to provide service to the user.  To do that, it
-   contacts a DNS server to resolve the domain name in the identifier to
-   an IP address.  It then contacts the server at that IP address.  This
-   simple model applies to application protocols such as HTTP [5], SIP
-   [7], RTSP [6], and SMTP [9].
-
-   >From this model, it is clear that three entities in the system can
-   potentially make false assumptions about the service provided by the
-   server.  The human user may form expectations relating to the content
-   of the service based on a parsing of the host name from which the
-   content originated.  The server might assume that the client
-   connecting to it supports protocols that it does not, can process
-   content that it cannot, or has capabilities that it does not.
-   Similarly, the client might assume that the server supports
-   protocols, content, or capabilities that it does not.  Furthermore,
-   applications can potentially contain a multiplicity of humans,
-   clients, and servers, all of which can independently make these false
-   assumptions.
-
-4.  Possible Assumptions
-
-   For each of the three elements, there are many types of false
-   assumptions that can be made.
-
-4.1.  By the User
-
-   The set of possible assumptions here is nearly boundless.  Users
-   might assume that an HTTP URL that looks like a company name maps to
-   a server run by that company.  They might assume that an email from a
-   email address in the .gov TLD is actually from a government employee.
-   They might assume that the content obtained from a web server within
-   a TLD labeled as containing adult materials (for example, .sex)
-   actually contains adult content [8].  These assumptions are
-   unavoidable, may all be false, and are not the focus of this
-   document.
-
-
-
-
-
-
-
-
-
-Rosenberg                    Informational                      [Page 5]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-4.2.  By the Client
-
-   Even though the client is an automaton, it can make some of the same
-   assumptions that a human user might make.  For example, many clients
-   assume that any host with a hostname that begins with "www" is a web
-   server, even though this assumption may be false.
-
-   In addition, the client concerns itself with the protocols needed to
-   communicate with the server.  As a result, it might make assumptions
-   about the operation of the protocols for communicating with the
-   server.  These assumptions manifest themselves in an implementation
-   when a standardized protocol negotiation technique defined by the
-   protocol is ignored, and instead, some kind of rule is coded into the
-   software that comes to its own conclusion about what the negotiation
-   would have determined.  The result is often a loss of
-   interoperability, degradation in reliability, and worsening of user
-   experience.
-
-   Authentication Algorithm: Though a protocol might support a
-      multiplicity of authentication techniques, a client might assume
-      that a server always supports one that is only optional according
-      to the protocol.  For example, a SIP client contacting a SIP
-      server in a domain that is apparently used to identify mobile
-      devices (for example, www.example.cellular) might assume that the
-      server supports the optional Authentication and Key Agreement
-      (AKA) digest technique [10], just because of the domain name that
-      was used to access the server.  As another example, a web client
-      might assume that a server with the name https.example.com
-      supports HTTP over Transport Layer Security (TLS) [16].
-
-   Data Formats: Though a protocol might allow a multiplicity of data
-      formats to be sent from the server to the client, the client might
-      assume a specific one, rather than using the content labeling and
-      negotiation capabilities of the underlying protocol.  For example,
-      an RTSP client might assume that all audio content delivered to it
-      from media.example.cellular uses a low-bandwidth codec.  As
-      another example, a mail client might assume that the contents of
-      messages it retrieves from a mail server at mail.example.cellular
-      are always text, instead of checking the MIME headers [11] in the
-      message in order to determine the actual content type.
-
-   Protocol Extensions: A client may attempt an operation on the server
-      that requires the server to support an optional protocol
-      extension.  However, rather than implementing the necessary
-      fallback logic, the client may falsely assume that the extension
-      is supported.  As an example, a SIP client that requires reliable
-      provisional responses to its request (RFC 3262 [17]) might assume
-      that this extension is supported on servers in the domain
-
-
-
-Rosenberg                    Informational                      [Page 6]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-      sip.example.telecom.  Furthermore, the client would not implement
-      the fallback behavior defined in RFC 3262, since it would assume
-      that all servers it will communicate with are in this domain and
-      that all therefore support this extension.  However, if the
-      assumptions prove wrong, the client is unable to make any phone
-      calls.
-
-   Languages: A client may support facilities for processing text
-      content differently depending on the language of the text.  Rather
-      than determining the language from markers in the message from the
-      server, the client might assume a language based on the domain
-      name.  This assumption can easily be wrong.  For example, a client
-      might assume that any text in a web page retrieved from a server
-      within the .de country code TLD (ccTLD) is in German, and attempt
-      a translation to Finnish.  This would fail dramatically if the
-      text was actually in French.  Unfortunately, this client behavior
-      is sometimes exhibited because the server has not properly labeled
-      the language of the content in the first place, often because the
-      server assumed such a labeling was not needed.  This is an example
-      of how these false assumptions can create vicious cycles.
-
-4.3.  By the Server
-
-   The server, like the client, is an automaton.  Let us consider one
-   servicing a particular domain -- www.company.cellular, for example.
-   It might assume that all clients connecting to this domain support
-   particular capabilities, rather than using the underlying protocol to
-   make this determination.  Some examples include:
-
-   Authentication Algorithm: The server can assume that a client
-      supports a particular, optional, authentication technique, and it
-      therefore does not support the mandatory one.
-
-   Language: The server can serve content in a particular language,
-      based on an assumption that clients accessing the domain speak a
-      particular language, or based on an assumption that clients coming
-      from a particular IP address speak a certain language.
-
-   Data Formats: The server can assume that the client supports a
-      particular set of MIME types and is only capable of sending ones
-      within that set.  When it generates content in a protocol
-      response, it ignores any content negotiation headers that were
-      present in the request.  For example, a web server might ignore
-      the Accept HTTP header field and send a specific image format.
-
-
-
-
-
-
-
-Rosenberg                    Informational                      [Page 7]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   Protocol Extensions: The server might assume that the client supports
-      a particular optional protocol extension, and so it does not
-      support the fallback behavior necessary in the case where the
-      client does not.
-
-   Client Characteristics: The server might assume certain things about
-      the physical characteristics of its clients, such as memory
-      footprint, processing power, screen sizes, screen colors, pointing
-      devices, and so on.  Based on these assumptions, it might choose
-      specific behaviors when processing a request.  For example, a web
-      server might always assume that clients connect through cell
-      phones, and therefore return content that lacks images and is
-      tuned for such devices.
-
-5.  Consequences of False Assumptions
-
-   There are numerous negative outcomes that can arise from the various
-   false assumptions that users, servers, and clients can make.  These
-   include:
-
-   Interoperability Failure: In these cases, the client or server
-      assumed some kind of protocol operation, and this assumption was
-      wrong.  The result is that the two are unable to communicate, and
-      the user receives some kind of an error.  This represents a total
-      interoperability failure, manifesting itself as a lack of service
-      to users of the system.  Unfortunately, this kind of failure
-      persists.  Repeated attempts over time by the client to access the
-      service will fail.  Only a change in the server or client software
-      can fix this problem.
-
-   System Failure: In these cases, the client or server misinterpreted a
-      protocol operation, and this misinterpretation was serious enough
-      to uncover a bug in the implementation.  The bug causes a system
-      crash or some kind of outage, either transient or permanent (until
-      user reset).  If this failure occurs in a server, not only will
-      the connecting client lose service, but other clients attempting
-      to connect will not get service.  As an example, if a web server
-      assumes that content passed to it from a client (created, for
-      example, by a digital camera) is of a particular content type, and
-      it always passes image content to a codec for decompression prior
-      to storage, the codec might crash when it unexpectedly receives an
-      image compressed in a different format.  Of course, it might crash
-      even if the Content-Type was correct, but the compressed bitstream
-      was invalid.  False assumptions merely introduce additional
-      failure cases.
-
-
-
-
-
-
-Rosenberg                    Informational                      [Page 8]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   Poor User Experience: In these cases, the client and server
-      communicate, but the user receives a diminished user experience.
-      For example, if a client on a PC connects to a web site that
-      provides content for mobile devices, the content may be
-      underwhelming when viewed on the PC.  Or, a client accessing a
-      streaming media service may receive content of very low bitrate,
-      even though the client supported better codecs.  Indeed, if a user
-      wishes to access content from both a cellular device and a PC
-      using a shared address book (that is, an address book shared
-      across multiple devices), the user would need two entries in that
-      address book, and would need to use the right one from the right
-      device.  This is a poor user experience.
-
-   Degraded Security: In these cases, a weaker security mechanism is
-      used than the one that ought to have been used.  As an example, a
-      server in a domain might assume that it is only contacted by
-      clients with a limited set of authentication algorithms, even
-      though the clients have been recently upgraded to support a
-      stronger set.
-
-6.  Reasons Why the Assumptions Can Be False
-
-   Assumptions made by clients and servers about the operation of
-   protocols when contacting a particular domain are brittle, and can be
-   wrong for many reasons.  On the server side, many of the assumptions
-   are based on the notion that a domain name will only be given to, or
-   used by, a restricted set of clients.  If the holder of the domain
-   name assumes something about those clients, and can assume that only
-   those clients use the domain name, then it can configure or program
-   the server to operate specifically for those clients.  Both parts of
-   this assumption can be wrong, as discussed in more detail below.
-
-   On the client side, the notion is similar, being based on the
-   assumption that a server within a particular domain will provide a
-   specific type of service.  Sub-delegation and evolution, both
-   discussed below, can make these assumptions wrong.
-
-6.1.  Evolution
-
-   The Internet and the devices that access it are constantly evolving,
-   often at a rapid pace.  Unfortunately, there is a tendency to build
-   for the here and now, and then worry about the future at a later
-   time.  Many of the assumptions above are predicated on
-   characteristics of today's clients and servers.  Support for specific
-   protocols, authentication techniques, or content are based on today's
-   standards and today's devices.  Even though they may, for the most
-   part, be true, they won't always be.  An excellent example is mobile
-   devices.  A server servicing a domain accessed by mobile devices
-
-
-
-Rosenberg                    Informational                      [Page 9]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   might try to make assumptions about the protocols, protocol
-   extensions, security mechanisms, screen sizes, or processor power of
-   such devices.  However, all of these characteristics can and will
-   change over time.
-
-   When they do change, the change is usually evolutionary.  The result
-   is that the assumptions remain valid in some cases, but not in
-   others.  It is difficult to fix such systems, since it requires the
-   server to detect what type of client is connecting, and what its
-   capabilities are.  Unless the system is built and deployed with these
-   capability negotiation techniques built in to begin with, such
-   detection can be extremely difficult.  In fact, fixing it will often
-   require the addition of such capability negotiation features that, if
-   they had been in place and used to begin with, would have avoided the
-   problem altogether.
-
-6.2.  Leakage
-
-   Servers also make assumptions because of the belief that they will
-   only be accessed by specific clients, and in particular, those that
-   are configured or provisioned to use the domain name.  In essence,
-   there is an assumption of community -- that a specific community
-   knows and uses the domain name, while others outside of the community
-   do not.
-
-   The problem is that this notion of community is a false one.  The
-   Internet is global.  The DNS is global.  There is no technical
-   barrier that separates those inside of the community from those
-   outside.  The ease with which information propagates across the
-   Internet makes it extremely likely that such domain names will
-   eventually find their way into clients outside of the presumed
-   community.  The ubiquitous presence of domain names in various URI
-   formats, coupled with the ease of conveyance of URIs, makes such
-   leakage merely a matter of time.  Furthermore, since the DNS is
-   global, and since it can only have one root [12], it becomes possible
-   for clients outside of the community to search and find and use such
-   "special" domain names.
-
-   Indeed, this leakage is a strength of the Internet architecture, not
-   a weakness.  It enables global access to services from any client
-   with a connection to the Internet.  That, in turn, allows for rapid
-   growth in the number of customers for any particular service.
-
-6.3.  Sub-Delegation
-
-   Clients and users make assumptions about domains because of the
-   notion that there is some kind of centralized control that can
-   enforce those assumptions.  However, the DNS is not centralized; it
-
-
-
-Rosenberg                    Informational                     [Page 10]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   is distributed.  If a domain doesn't delegate its sub-domains and has
-   its records within a single zone, it is possible to maintain a
-   centralized policy about operation of its domain.  However, once a
-   domain gets sufficiently large that the domain administrators begin
-   to delegate sub-domains to other authorities, it becomes increasingly
-   difficult to maintain any kind of central control on the nature of
-   the service provided in each sub-domain.
-
-   Similarly, the usage of domain names with human semantic connotation
-   tends to lead to a registration of multiple domains in which a
-   particular service is to run.  As an example, a service provider with
-   the name "example" might register and set up its services in
-   "example.com", "example.net", and generally example.foo for each foo
-   that is a valid TLD.  This, like sub-delegation, results in a growth
-   in the number of domains over which it is difficult to maintain
-   centralized control.
-
-   Not that it is not possible, since there are many examples of
-   successful administration of policies across sub-domains many levels
-   deep.  However, it takes an increasing amount of effort to ensure
-   this result, as it requires human intervention and the creation of
-   process and procedure.  Automated validation of adherence to policies
-   is very difficult to do, as there is no way to automatically verify
-   many policies that might be put into place.
-
-   A less costly process for providing centralized management of
-   policies is to just hope that any centralized policies are being
-   followed, and then wait for complaints or perform random audits.
-   Those approaches have many problems.
-
-   The invalidation of assumptions due to sub-delegation is discussed in
-   further detail in Section 4.1.3 of [8] and in Section 3.3 of [20].
-
-   As a result of the fragility of policy continuity across sub-
-   delegations, if a client or user assumes some kind of property
-   associated with a TLD (such as ".wifi"), it becomes increasingly more
-   likely with the number of sub-domains that this property will not
-   exist in a server identified by a particular name.  For example, in
-   "store.chain.company.provider.wifi", there may be four levels of
-   delegation from ".wifi", making it quite likely that, unless the
-   holder of ".wifi" is working diligently, the properties that the
-   holder of ".wifi" wishes to enforce are not present.  These
-   properties may not be present due to human error or due to a willful
-   decision not to adhere to them.
-
-
-
-
-
-
-
-Rosenberg                    Informational                     [Page 11]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-6.4.  Mobility
-
-   One of the primary value propositions of a hostname as an identifier
-   is its persistence.  A client can change IP addresses, yet still
-   retain a persistent identifier used by other hosts to reach it.
-   Because their value derives from their persistence, hostnames tend to
-   move with a host not just as it changes IP addresses, but as it
-   changes access network providers and technologies.  For this reason,
-   assumptions made about a host based on the presumed access network
-   corresponding to that hostname tend to be wrong over time.  As an
-   example, a PC might normally be connected to its broadband provider,
-   and through dynamic DNS have a hostname within the domain of that
-   provider.  However, one cannot assume that any host within that
-   network has access over a broadband link; the user could connect
-   their PC over a low-bandwidth wireless access network and still
-   retain its domain name.
-
-6.5.  Human Error
-
-   Of course, human error can be the source of errors in any system, and
-   the same is true here.  There are many examples relevant to the
-   problem under discussion.
-
-   A client implementation may make the assumption that, just because a
-   DNS SRV record exists for a particular protocol in a particular
-   domain, indicating that the service is available on some port, that
-   the service is, in fact, running there.  This assumption could be
-   wrong because the SRV records haven't been updated by the system
-   administrators to reflect the services currently running.  As another
-   example, a client might assume that a particular domain policy
-   applies to all sub-domains.  However, a system administrator might
-   have omitted to apply the policy to servers running in one of those
-   sub-domains.
-
-7.  Recommendations
-
-   Based on these problems, the clear conclusion is that clients,
-   servers, and users should not make assumptions on the nature of the
-   service provided to, or by, a domain.  More specifically, however,
-   the following can be said:
-
-   Follow the specifications: When specifications define mandatory
-      baseline procedures and formats, those should be implemented and
-      supported, even if the expectation is that optional procedures
-      will most often be used.  For example, if a specification mandates
-      a particular baseline authentication technique, but allows others
-      to be negotiated and used, implementations need to implement the
-      baseline authentication algorithm even if the other ones are used
-
-
-
-Rosenberg                    Informational                     [Page 12]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-      most of the time.  Put more simply, the behavior of the protocol
-      machinery should never change based on the domain name of the
-      host.
-
-   Use capability negotiation: Many protocols are engineered with
-      capability negotiation mechanisms.  For example, a content
-      negotiation framework has been defined for protocols using MIME
-      content [13] [14] [15].  SIP allows for clients to negotiate the
-      media types used in the multimedia session, as well as protocol
-      parameters.  HTTP allows for clients to negotiate the media types
-      returned in requests for content.  When such features are
-      available in a protocol, client and servers should make use of
-      them rather than making assumptions about supported capabilities.
-      A corollary is that protocol designers should include such
-      mechanisms when evolution is expected in the usage of the
-      protocol.
-
-   "Be liberal in what you accept, and conservative in what you send"
-      [18]:  This axiom of Internet protocol design is applicable here
-      as well.  Implementations should be prepared for the full breadth
-      of what a protocol allows another entity to send, rather than be
-      limiting in what it is willing to receive.
-
-   To summarize -- there is never a need to make assumptions.  Rather
-   than doing so, utilize the specifications and the negotiation
-   capabilities they provide, and the overall system will be robust and
-   interoperable.
-
-8.  A Note on RFC 2219 and RFC 2782
-
-   Based on the definition of an assumption given here, the behavior
-   hinted at by records in the DNS also represents an assumption.  RFC
-   2219 [19] defines well-known aliases that can be used to construct
-   domain names for reaching various well-known services in a domain.
-   This approach was later followed by the definition of a new resource
-   record, the SRV record [2], which specifies that a particular service
-   is running on a server in a domain.  Although both of these
-   mechanisms are useful as a hint that a particular service is running
-   in a domain, both of them represent assumptions that may be false.
-   However, they differ in the set of reasons why those assumptions
-   might be false.
-
-   A client that assumes that "ftp.example.com" is an FTP server may be
-   wrong because the presumed naming convention in RFC 2219 was not
-   known by, or not followed by, the owner of domain.com.  With RFC
-   2782, an SRV record for a particular service would be present only by
-   explicit choice of the domain administrator, and thus a client that
-
-
-
-
-Rosenberg                    Informational                     [Page 13]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   assumes that the corresponding host provides this service would be
-   wrong only because of human error in configuration.  In this case,
-   the assumption is less likely to be wrong, but it certainly can be.
-
-   The only way to determine with certainty that a service is running on
-   a host is to initiate a connection to the port for that service, and
-   check.  Implementations need to be careful not to codify any
-   behaviors that cause failures should the information provided in the
-   record actually be false.  This borders on common sense for robust
-   implementations, but it is valuable to raise this point explicitly.
-
-9.  Security Considerations
-
-   One of the assumptions that can be made by clients or servers is the
-   availability and usage (or lack thereof) of certain security
-   protocols and algorithms.  For example, a client accessing a service
-   in a particular domain might assume a specific authentication
-   algorithm or hash function in the application protocol.  It is
-   possible that, over time, weaknesses are found in such a technique,
-   requiring usage of a different mechanism.  Similarly, a system might
-   start with an insecure mechanism, and then decide later on to use a
-   secure one.  In either case, assumptions made on security properties
-   can result in interoperability failures, or worse yet, providing
-   service in an insecure way, even though the client asked for, and
-   thought it would get, secure service.  These kinds of assumptions are
-   fundamentally unsound even if the records themselves are secured with
-   DNSSEC.
-
-10.  Acknowledgements
-
-   The IAB would like to thank John Klensin, Keith Moore and Peter Koch
-   for their comments.
-
-11.  IAB Members
-
-   Internet Architecture Board members at the time of writing of this
-   document are:
-
-      Bernard Aboba
-
-      Loa Andersson
-
-      Brian Carpenter
-
-      Leslie Daigle
-
-      Patrik Faltstrom
-
-
-
-
-Rosenberg                    Informational                     [Page 14]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-      Bob Hinden
-
-      Kurtis Lindqvist
-
-      David Meyer
-
-      Pekka Nikander
-
-      Eric Rescorla
-
-      Pete Resnick
-
-      Jonathan Rosenberg
-
-12.  Informative References
-
-   [1]   Mockapetris, P., "Domain names - concepts and facilities",
-         STD 13, RFC 1034, November 1987.
-
-   [2]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-         specifying the location of services (DNS SRV)", RFC 2782,
-         February 2000.
-
-   [3]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
-         Three: The Domain Name System (DNS) Database", RFC 3403,
-         October 2002.
-
-   [4]   Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means
-         for Expressing Location Information in the Domain Name System",
-         RFC 1876, January 1996.
-
-   [5]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
-         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
-         HTTP/1.1", RFC 2616, June 1999.
-
-   [6]   Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
-         Protocol (RTSP)", RFC 2326, April 1998.
-
-   [7]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
-         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
-         Session Initiation Protocol", RFC 3261, June 2002.
-
-   [8]   Eastlake, D., ".sex Considered Dangerous", RFC 3675,
-         February 2004.
-
-   [9]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
-         April 2001.
-
-
-
-
-Rosenberg                    Informational                     [Page 15]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   [10]  Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
-         Protocol (HTTP) Digest Authentication Using Authentication and
-         Key Agreement (AKA)", RFC 3310, September 2002.
-
-   [11]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-         Extensions (MIME) Part One: Format of Internet Message Bodies",
-         RFC 2045, November 1996.
-
-   [12]  Internet Architecture Board, "IAB Technical Comment on the
-         Unique DNS Root", RFC 2826, May 2000.
-
-   [13]  Klyne, G., "Indicating Media Features for MIME Content",
-         RFC 2912, September 2000.
-
-   [14]  Klyne, G., "A Syntax for Describing Media Feature Sets",
-         RFC 2533, March 1999.
-
-   [15]  Klyne, G., "Protocol-independent Content Negotiation
-         Framework", RFC 2703, September 1999.
-
-   [16]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
-
-   [17]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
-         Responses in Session Initiation Protocol (SIP)", RFC 3262,
-         June 2002.
-
-   [18]  Braden, R., "Requirements for Internet Hosts - Communication
-         Layers", STD 3, RFC 1122, October 1989.
-
-   [19]  Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
-         Services", BCP 17, RFC 2219, October 1997.
-
-   [20]  Faltstrom, P., "Design Choices When Expanding DNS", Work in
-         Progress, June 2005.
-
-Author's Address
-
-   Jonathan Rosenberg, Editor
-   IAB
-   600 Lanidex Plaza
-   Parsippany, NJ  07054
-   US
-
-   Phone: +1 973 952-5000
-   EMail: jdrosen@cisco.com
-   URI:   http://www.jdrosen.net
-
-
-
-
-
-Rosenberg                    Informational                     [Page 16]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Rosenberg                    Informational                     [Page 17]
-
diff --git a/doc/rfc/rfc4398.txt b/doc/rfc/rfc4398.txt
deleted file mode 100644
index 6437436e..00000000
--- a/doc/rfc/rfc4398.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       S. Josefsson
-Request for Comments: 4398                                    March 2006
-Obsoletes: 2538
-Category: Standards Track
-
-
-          Storing Certificates in the Domain Name System (DNS)
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   Cryptographic public keys are frequently published, and their
-   authenticity is demonstrated by certificates.  A CERT resource record
-   (RR) is defined so that such certificates and related certificate
-   revocation lists can be stored in the Domain Name System (DNS).
-
-   This document obsoletes RFC 2538.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 1]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. The CERT Resource Record ........................................3
-      2.1. Certificate Type Values ....................................4
-      2.2. Text Representation of CERT RRs ............................6
-      2.3. X.509 OIDs .................................................6
-   3. Appropriate Owner Names for CERT RRs ............................7
-      3.1. Content-Based X.509 CERT RR Names ..........................8
-      3.2. Purpose-Based X.509 CERT RR Names ..........................9
-      3.3. Content-Based OpenPGP CERT RR Names ........................9
-      3.4. Purpose-Based OpenPGP CERT RR Names .......................10
-      3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10
-   4. Performance Considerations .....................................11
-   5. Contributors ...................................................11
-   6. Acknowledgements ...............................................11
-   7. Security Considerations ........................................12
-   8. IANA Considerations ............................................12
-   9. Changes since RFC 2538 .........................................13
-   10. References ....................................................14
-      10.1. Normative References .....................................14
-      10.2. Informative References ...................................15
-   Appendix A.  Copying Conditions ...................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 2]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-1.  Introduction
-
-   Public keys are frequently published in the form of a certificate,
-   and their authenticity is commonly demonstrated by certificates and
-   related certificate revocation lists (CRLs).  A certificate is a
-   binding, through a cryptographic digital signature, of a public key,
-   a validity interval and/or conditions, and identity, authorization,
-   or other information.  A certificate revocation list is a list of
-   certificates that are revoked, and of incidental information, all
-   signed by the signer (issuer) of the revoked certificates.  Examples
-   are X.509 certificates/CRLs in the X.500 directory system or OpenPGP
-   certificates/revocations used by OpenPGP software.
-
-   Section 2 specifies a CERT resource record (RR) for the storage of
-   certificates in the Domain Name System [1] [2].
-
-   Section 3 discusses appropriate owner names for CERT RRs.
-
-   Sections 4, 7, and 8 cover performance, security, and IANA
-   considerations, respectively.
-
-   Section 9 explains the changes in this document compared to RFC 2538.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [3].
-
-2.  The CERT Resource Record
-
-   The CERT resource record (RR) has the structure given below.  Its RR
-   type code is 37.
-
-                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |             type              |             key tag           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |   algorithm   |                                               /
-   +---------------+            certificate or CRL                 /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-   The type field is the certificate type as defined in Section 2.1
-   below.
-
-   The key tag field is the 16-bit value computed for the key embedded
-   in the certificate, using the RRSIG Key Tag algorithm described in
-   Appendix B of [12].  This field is used as an efficiency measure to
-
-
-
-Josefsson                   Standards Track                     [Page 3]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   pick which CERT RRs may be applicable to a particular key.  The key
-   tag can be calculated for the key in question, and then only CERT RRs
-   with the same key tag need to be examined.  Note that two different
-   keys can have the same key tag.  However, the key MUST be transformed
-   to the format it would have as the public key portion of a DNSKEY RR
-   before the key tag is computed.  This is only possible if the key is
-   applicable to an algorithm and complies to limits (such as key size)
-   defined for DNS security.  If it is not, the algorithm field MUST be
-   zero and the tag field is meaningless and SHOULD be zero.
-
-   The algorithm field has the same meaning as the algorithm field in
-   DNSKEY and RRSIG RRs [12], except that a zero algorithm field
-   indicates that the algorithm is unknown to a secure DNS, which may
-   simply be the result of the algorithm not having been standardized
-   for DNSSEC [11].
-
-2.1.  Certificate Type Values
-
-   The following values are defined or reserved:
-
-         Value  Mnemonic  Certificate Type
-         -----  --------  ----------------
-             0            Reserved
-             1  PKIX      X.509 as per PKIX
-             2  SPKI      SPKI certificate
-             3  PGP       OpenPGP packet
-             4  IPKIX     The URL of an X.509 data object
-             5  ISPKI     The URL of an SPKI certificate
-             6  IPGP      The fingerprint and URL of an OpenPGP packet
-             7  ACPKIX    Attribute Certificate
-             8  IACPKIX   The URL of an Attribute Certificate
-         9-252            Available for IANA assignment
-           253  URI       URI private
-           254  OID       OID private
-           255            Reserved
-     256-65279            Available for IANA assignment
-   65280-65534            Experimental
-         65535            Reserved
-
-   These values represent the initial content of the IANA registry; see
-   Section 8.
-
-   The PKIX type is reserved to indicate an X.509 certificate conforming
-   to the profile defined by the IETF PKIX working group [8].  The
-   certificate section will start with a one-octet unsigned OID length
-   and then an X.500 OID indicating the nature of the remainder of the
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 4]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   certificate section (see Section 2.3, below).  (NOTE: X.509
-   certificates do not include their X.500 directory-type-designating
-   OID as a prefix.)
-
-   The SPKI and ISPKI types are reserved to indicate the SPKI
-   certificate format [15], for use when the SPKI documents are moved
-   from experimental status.  The format for these two CERT RR types
-   will need to be specified later.
-
-   The PGP type indicates an OpenPGP packet as described in [5] and its
-   extensions and successors.  This is used to transfer public key
-   material and revocation signatures.  The data is binary and MUST NOT
-   be encoded into an ASCII armor.  An implementation SHOULD process
-   transferable public keys as described in Section 10.1 of [5], but it
-   MAY handle additional OpenPGP packets.
-
-   The ACPKIX type indicates an Attribute Certificate format [9].
-
-   The IPKIX and IACPKIX types indicate a URL that will serve the
-   content that would have been in the "certificate, CRL, or URL" field
-   of the corresponding type (PKIX or ACPKIX, respectively).
-
-   The IPGP type contains both an OpenPGP fingerprint for the key in
-   question, as well as a URL.  The certificate portion of the IPGP CERT
-   RR is defined as a one-octet fingerprint length, followed by the
-   OpenPGP fingerprint, followed by the URL.  The OpenPGP fingerprint is
-   calculated as defined in RFC 2440 [5].  A zero-length fingerprint or
-   a zero-length URL are legal, and indicate URL-only IPGP data or
-   fingerprint-only IPGP data, respectively.  A zero-length fingerprint
-   and a zero-length URL are meaningless and invalid.
-
-   The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect".
-   These types MUST be used when the content is too large to fit in the
-   CERT RR and MAY be used at the implementer's discretion.  They SHOULD
-   NOT be used where the DNS message is 512 octets or smaller and could
-   thus be expected to fit a UDP packet.
-
-   The URI private type indicates a certificate format defined by an
-   absolute URI.  The certificate portion of the CERT RR MUST begin with
-   a null-terminated URI [10], and the data after the null is the
-   private format certificate itself.  The URI SHOULD be such that a
-   retrieval from it will lead to documentation on the format of the
-   certificate.  Recognition of private certificate types need not be
-   based on URI equality but can use various forms of pattern matching
-   so that, for example, subtype or version information can also be
-   encoded into the URI.
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 5]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   The OID private type indicates a private format certificate specified
-   by an ISO OID prefix.  The certificate section will start with a
-   one-octet unsigned OID length and then a BER-encoded OID indicating
-   the nature of the remainder of the certificate section.  This can be
-   an X.509 certificate format or some other format.  X.509 certificates
-   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
-   type, not the OID private type.  Recognition of private certificate
-   types need not be based on OID equality but can use various forms of
-   pattern matching such as OID prefix.
-
-2.2.  Text Representation of CERT RRs
-
-   The RDATA portion of a CERT RR has the type field as an unsigned
-   decimal integer or as a mnemonic symbol as listed in Section 2.1,
-   above.
-
-   The key tag field is represented as an unsigned decimal integer.
-
-   The algorithm field is represented as an unsigned decimal integer or
-   a mnemonic symbol as listed in [12].
-
-   The certificate/CRL portion is represented in base 64 [16] and may be
-   divided into any number of white-space-separated substrings, down to
-   single base-64 digits, which are concatenated to obtain the full
-   signature.  These substrings can span lines using the standard
-   parenthesis.
-
-   Note that the certificate/CRL portion may have internal sub-fields,
-   but these do not appear in the master file representation.  For
-   example, with type 254, there will be an OID size, an OID, and then
-   the certificate/CRL proper.  However, only a single logical base-64
-   string will appear in the text representation.
-
-2.3.  X.509 OIDs
-
-   OIDs have been defined in connection with the X.500 directory for
-   user certificates, certification authority certificates, revocations
-   of certification authority, and revocations of user certificates.
-   The following table lists the OIDs, their BER encoding, and their
-   length-prefixed hex format for use in CERT RRs:
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 6]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-       id-at-userCertificate
-           = { joint-iso-ccitt(2) ds(5) at(4) 36 }
-              == 0x 03 55 04 24
-       id-at-cACertificate
-           = { joint-iso-ccitt(2) ds(5) at(4) 37 }
-              == 0x 03 55 04 25
-       id-at-authorityRevocationList
-           = { joint-iso-ccitt(2) ds(5) at(4) 38 }
-              == 0x 03 55 04 26
-       id-at-certificateRevocationList
-           = { joint-iso-ccitt(2) ds(5) at(4) 39 }
-              == 0x 03 55 04 27
-
-3.  Appropriate Owner Names for CERT RRs
-
-   It is recommended that certificate CERT RRs be stored under a domain
-   name related to their subject, i.e., the name of the entity intended
-   to control the private key corresponding to the public key being
-   certified.  It is recommended that certificate revocation list CERT
-   RRs be stored under a domain name related to their issuer.
-
-   Following some of the guidelines below may result in DNS names with
-   characters that require DNS quoting as per Section 5.1 of RFC 1035
-   [2].
-
-   The choice of name under which CERT RRs are stored is important to
-   clients that perform CERT queries.  In some situations, the clients
-   may not know all information about the CERT RR object it wishes to
-   retrieve.  For example, a client may not know the subject name of an
-   X.509 certificate, or the email address of the owner of an OpenPGP
-   key.  Further, the client might only know the hostname of a service
-   that uses X.509 certificates or the Key ID of an OpenPGP key.
-
-   Therefore, two owner name guidelines are defined: content-based owner
-   names and purpose-based owner names.  A content-based owner name is
-   derived from the content of the CERT RR data; for example, the
-   Subject field in an X.509 certificate or the User ID field in OpenPGP
-   keys.  A purpose-based owner name is a name that a client retrieving
-   CERT RRs ought to know already; for example, the host name of an
-   X.509 protected service or the Key ID of an OpenPGP key.  The
-   content-based and purpose-based owner name may be the same; for
-   example, when a client looks up a key based on the From: address of
-   an incoming email.
-
-   Implementations SHOULD use the purpose-based owner name guidelines
-   described in this document and MAY use CNAME RRs at content-based
-   owner names (or other names), pointing to the purpose-based owner
-   name.
-
-
-
-Josefsson                   Standards Track                     [Page 7]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   Note that this section describes an application-based mapping from
-   the name space used in a certificate to the name space used by DNS.
-   The DNS does not infer any relationship amongst CERT resource records
-   based on similarities or differences of the DNS owner name(s) of CERT
-   resource records.  For example, if multiple labels are used when
-   mapping from a CERT identifier to a domain name, then care must be
-   taken in understanding wildcard record synthesis.
-
-3.1.  Content-Based X.509 CERT RR Names
-
-   Some X.509 versions, such as the PKIX profile of X.509 [8], permit
-   multiple names to be associated with subjects and issuers under
-   "Subject Alternative Name" and "Issuer Alternative Name".  For
-   example, the PKIX profile has such Alternate Names with an ASN.1
-   specification as follows:
-
-      GeneralName ::= CHOICE {
-           otherName                       [0]     OtherName,
-           rfc822Name                      [1]     IA5String,
-           dNSName                         [2]     IA5String,
-           x400Address                     [3]     ORAddress,
-           directoryName                   [4]     Name,
-           ediPartyName                    [5]     EDIPartyName,
-           uniformResourceIdentifier       [6]     IA5String,
-           iPAddress                       [7]     OCTET STRING,
-           registeredID                    [8]     OBJECT IDENTIFIER }
-
-   The recommended locations of CERT storage are as follows, in priority
-   order:
-
-   1.  If a domain name is included in the identification in the
-       certificate or CRL, that ought to be used.
-   2.  If a domain name is not included but an IP address is included,
-       then the translation of that IP address into the appropriate
-       inverse domain name ought to be used.
-   3.  If neither of the above is used, but a URI containing a domain
-       name is present, that domain name ought to be used.
-   4.  If none of the above is included but a character string name is
-       included, then it ought to be treated as described below for
-       OpenPGP names.
-   5.  If none of the above apply, then the distinguished name (DN)
-       ought to be mapped into a domain name as specified in [4].
-
-   Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
-   DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
-   string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
-   URI <https://www.secure.john-doe.com:8080/>.  The storage locations
-   recommended, in priority order, would be
-
-
-
-Josefsson                   Standards Track                     [Page 8]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   1.  john-doe.com,
-   2.  www.secure.john-doe.com, and
-   3.  Doe.com.xy.
-
-   Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
-   L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
-   domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
-   (c) string "James Hacker <hacker@mail.widget.foo.example>".  The
-   storage locations recommended, in priority order, would be
-
-   1.  widget.foo.example,
-   2.  201.13.251.10.in-addr.arpa, and
-   3.  hacker.mail.widget.foo.example.
-
-3.2.  Purpose-Based X.509 CERT RR Names
-
-   Due to the difficulty for clients that do not already possess a
-   certificate to reconstruct the content-based owner name,
-   purpose-based owner names are recommended in this section.
-   Recommendations for purpose-based owner names vary per scenario.  The
-   following table summarizes the purpose-based X.509 CERT RR owner name
-   guidelines for use with S/MIME [17], SSL/TLS [13], and IPsec [14]:
-
-    Scenario             Owner name
-    ------------------   ----------------------------------------------
-    S/MIME Certificate   Standard translation of an RFC 2822 email
-                         address.  Example: An S/MIME certificate for
-                         "postmaster@example.org" will use a standard
-                         hostname translation of the owner name,
-                         "postmaster.example.org".
-
-    TLS Certificate      Hostname of the TLS server.
-
-    IPsec Certificate    Hostname of the IPsec machine and/or, for IPv4
-                         or IPv6 addresses, the fully qualified domain
-                         name in the appropriate reverse domain.
-
-   An alternate approach for IPsec is to store raw public keys [18].
-
-3.3.  Content-Based OpenPGP CERT RR Names
-
-   OpenPGP signed keys (certificates) use a general character string
-   User ID [5].  However, it is recommended by OpenPGP that such names
-   include the RFC 2822 [7] email address of the party, as in "Leslie
-   Example <Leslie@host.example>".  If such a format is used, the CERT
-   ought to be under the standard translation of the email address into
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 9]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   a domain name, which would be leslie.host.example in this case.  If
-   no RFC 2822 name can be extracted from the string name, no specific
-   domain name is recommended.
-
-   If a user has more than one email address, the CNAME type can be used
-   to reduce the amount of data stored in the DNS.  For example:
-
-      $ORIGIN example.org.
-      smith        IN CERT PGP 0 0 <OpenPGP binary>
-      john.smith   IN CNAME smith
-      js           IN CNAME smith
-
-3.4.  Purpose-Based OpenPGP CERT RR Names
-
-   Applications that receive an OpenPGP packet containing encrypted or
-   signed data but do not know the email address of the sender will have
-   difficulties constructing the correct owner name and cannot use the
-   content-based owner name guidelines.  However, these clients commonly
-   know the key fingerprint or the Key ID.  The key ID is found in
-   OpenPGP packets, and the key fingerprint is commonly found in
-   auxiliary data that may be available.  In this case, use of an owner
-   name identical to the key fingerprint and the key ID expressed in
-   hexadecimal [16] is recommended.  For example:
-
-      $ORIGIN example.org.
-      0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
-      F835EDA21E94B565716F                     IN CERT PGP ...
-      B565716F                                 IN CERT PGP ...
-
-   If the same key material is stored for several owner names, the use
-   of CNAME may help avoid data duplication.  Note that CNAME is not
-   always applicable, because it maps one owner name to the other for
-   all purposes, which may be sub-optimal when two keys with the same
-   Key ID are stored.
-
-3.5.  Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX
-
-   These types are stored under the same owner names, both purpose- and
-   content-based, as the PKIX, SPKI, PGP, and ACPKIX types.
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 10]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-4.  Performance Considerations
-
-   The Domain Name System (DNS) protocol was designed for small
-   transfers, typically below 512 octets.  While larger transfers will
-   perform correctly and work is underway to make larger transfers more
-   efficient, it is still advisable at this time that every reasonable
-   effort be made to minimize the size of certificates stored within the
-   DNS.  Steps that can be taken may include using the fewest possible
-   optional or extension fields and using short field values for
-   necessary variable-length fields.
-
-   The RDATA field in the DNS protocol may only hold data of size 65535
-   octets (64kb) or less.  This means that each CERT RR MUST NOT contain
-   more than 64kb of payload, even if the corresponding certificate or
-   certificate revocation list is larger.  This document addresses this
-   by defining "indirect" data types for each normal type.
-
-   Deploying CERT RRs to support digitally signed email changes the
-   access patterns of DNS lookups from per-domain to per-user.  If
-   digitally signed email and a key/certificate lookup based on CERT RRs
-   are deployed on a wide scale, this may lead to an increased DNS load,
-   with potential performance and cache effectiveness consequences.
-   Whether or not this load increase will be noticeable is not known.
-
-5.  Contributors
-
-   The majority of this document is copied verbatim from RFC 2538, by
-   Donald Eastlake 3rd and Olafur Gudmundsson.
-
-6.  Acknowledgements
-
-   Thanks to David Shaw and Michael Graff for their contributions to
-   earlier works that motivated, and served as inspiration for, this
-   document.
-
-   This document was improved by suggestions and comments from Olivier
-   Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.
-   Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,
-   Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel
-   Weiler, and Florian Weimer.  No doubt the list is incomplete.  We
-   apologize to anyone we left out.
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 11]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-7.  Security Considerations
-
-   By definition, certificates contain their own authenticating
-   signatures.  Thus, it is reasonable to store certificates in
-   non-secure DNS zones or to retrieve certificates from DNS with DNS
-   security checking not implemented or deferred for efficiency.  The
-   results may be trusted if the certificate chain is verified back to a
-   known trusted key and this conforms with the user's security policy.
-
-   Alternatively, if certificates are retrieved from a secure DNS zone
-   with DNS security checking enabled and are verified by DNS security,
-   the key within the retrieved certificate may be trusted without
-   verifying the certificate chain if this conforms with the user's
-   security policy.
-
-   If an organization chooses to issue certificates for its employees,
-   placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC)
-   is in use, it is possible for someone to enumerate all employees of
-   the organization.  This is usually not considered desirable, for the
-   same reason that enterprise phone listings are not often publicly
-   published and are even marked confidential.
-
-   Using the URI type introduces another level of indirection that may
-   open a new vulnerability.  One method of securing that indirection is
-   to include a hash of the certificate in the URI itself.
-
-   If DNSSEC is used, then the non-existence of a CERT RR and,
-   consequently, certificates or revocation lists can be securely
-   asserted.  Without DNSSEC, this is not possible.
-
-8.  IANA Considerations
-
-   The IANA has created a new registry for CERT RR: certificate types.
-   The initial contents of this registry is:
-
-       Decimal   Type     Meaning                           Reference
-       -------   ----     -------                           ---------
-             0            Reserved                          RFC 4398
-             1   PKIX     X.509 as per PKIX                 RFC 4398
-             2   SPKI     SPKI certificate                  RFC 4398
-             3   PGP      OpenPGP packet                    RFC 4398
-             4   IPKIX    The URL of an X.509 data object   RFC 4398
-             5   ISPKI    The URL of an SPKI certificate    RFC 4398
-             6   IPGP     The fingerprint and URL           RFC 4398
-                          of an OpenPGP packet
-             7   ACPKIX   Attribute Certificate             RFC 4398
-             8   IACPKIX  The URL of an Attribute           RFC 4398
-                             Certificate
-
-
-
-Josefsson                   Standards Track                    [Page 12]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-         9-252            Available for IANA assignment
-                             by IETF Standards action
-           253   URI      URI private                       RFC 4398
-           254   OID      OID private                       RFC 4398
-           255            Reserved                          RFC 4398
-     256-65279            Available for IANA assignment
-                          by IETF Consensus
-   65280-65534            Experimental                      RFC 4398
-         65535            Reserved                          RFC 4398
-
-   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
-   only be assigned by an IETF standards action [6].  This document
-   assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE.  Certificate
-   types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
-   based on RFC documentation of the certificate type.  The availability
-   of private types under 0x00FD and 0x00FE ought to satisfy most
-   requirements for proprietary or private types.
-
-   The CERT RR reuses the DNS Security Algorithm Numbers registry.  In
-   particular, the CERT RR requires that algorithm number 0 remain
-   reserved, as described in Section 2.  The IANA will reference the
-   CERT RR as a user of this registry and value 0, in particular.
-
-9.  Changes since RFC 2538
-
-   1.   Editorial changes to conform with new document requirements,
-        including splitting reference section into two parts and
-        updating the references to point at latest versions, and to add
-        some additional references.
-   2.   Improve terminology.  For example replace "PGP" with "OpenPGP",
-        to align with RFC 2440.
-   3.   In Section 2.1, clarify that OpenPGP public key data are binary,
-        not the ASCII armored format, and reference 10.1 in RFC 2440 on
-        how to deal with OpenPGP keys, and acknowledge that
-        implementations may handle additional packet types.
-   4.   Clarify that integers in the representation format are decimal.
-   5.   Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
-        terminology.  Improve reference for Key Tag Algorithm
-        calculations.
-   6.   Add examples that suggest use of CNAME to reduce bandwidth.
-   7.   In Section 3, appended the last paragraphs that discuss
-        "content-based" vs "purpose-based" owner names.  Add Section 3.2
-        for purpose-based X.509 CERT owner names, and Section 3.4 for
-        purpose-based OpenPGP CERT owner names.
-   8.   Added size considerations.
-   9.   The SPKI types has been reserved, until RFC 2692/2693 is moved
-        from the experimental status.
-   10.  Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX.
-
-
-
-Josefsson                   Standards Track                    [Page 13]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   11.  An IANA registry of CERT type values was created.
-
-10.  References
-
-10.1.  Normative References
-
-   [1]   Mockapetris, P., "Domain names - concepts and facilities",
-         STD 13, RFC 1034, November 1987.
-
-   [2]   Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]   Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
-         "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
-         January 1998.
-
-   [5]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
-         "OpenPGP Message Format", RFC 2440, November 1998.
-
-   [6]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-         Considerations Section in RFCs", BCP 26, RFC 2434,
-         October 1998.
-
-   [7]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.
-
-   [8]   Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
-         Public Key Infrastructure Certificate and Certificate
-         Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-   [9]   Farrell, S. and R. Housley, "An Internet Attribute Certificate
-         Profile for Authorization", RFC 3281, April 2002.
-
-   [10]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
-         January 2005.
-
-   [11]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033,
-         March 2005.
-
-   [12]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 14]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-10.2.  Informative References
-
-   [13]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-         RFC 2246, January 1999.
-
-   [14]  Kent, S. and K. Seo, "Security Architecture for the Internet
-         Protocol", RFC 4301, December 2005.
-
-   [15]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
-         and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
-         September 1999.
-
-   [16]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-         RFC 3548, July 2003.
-
-   [17]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
-         (S/MIME) Version 3.1 Message Specification", RFC 3851,
-         July 2004.
-
-   [18]  Richardson, M., "A Method for Storing IPsec Keying Material in
-         DNS", RFC 4025, March 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 15]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-Appendix A.  Copying Conditions
-
-   Regarding the portion of this document that was written by Simon
-   Josefsson ("the author", for the remainder of this section), the
-   author makes no guarantees and is not responsible for any damage
-   resulting from its use.  The author grants irrevocable permission to
-   anyone to use, modify, and distribute it in any way that does not
-   diminish the rights of anyone else to use, modify, and distribute it,
-   provided that redistributed derivative works do not contain
-   misleading author or version information.  Derivative works need not
-   be licensed under similar terms.
-
-Author's Address
-
-   Simon Josefsson
-
-   EMail: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 16]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 17]
-
diff --git a/doc/rfc/rfc4408.txt b/doc/rfc/rfc4408.txt
deleted file mode 100644
index bc1b3f53..00000000
--- a/doc/rfc/rfc4408.txt
+++ /dev/null
@@ -1,2691 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            M. Wong
-Request for Comments: 4408                                    W. Schlitt
-Category: Experimental                                        April 2006
-
-
-                   Sender Policy Framework (SPF) for
-            Authorizing Use of Domains in E-Mail, Version 1
-
-Status of This Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  It does not specify an Internet standard of any kind.
-   Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-IESG Note
-
-   The following documents  (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)
-   are published simultaneously as Experimental RFCs, although there is
-   no general technical consensus and efforts to reconcile the two
-   approaches have failed.  As such, these documents have not received
-   full IETF review and are published "AS-IS" to document the different
-   approaches as they were considered in the MARID working group.
-
-   The IESG takes no position about which approach is to be preferred
-   and cautions the reader that there are serious open issues for each
-   approach and concerns about using them in tandem.  The IESG believes
-   that documenting the different approaches does less harm than not
-   documenting them.
-
-   Note that the Sender ID experiment may use DNS records that may have
-   been created for the current SPF experiment or earlier versions in
-   this set of experiments.  Depending on the content of the record,
-   this may mean that Sender-ID heuristics would be applied incorrectly
-   to a message.  Depending on the actions associated by the recipient
-   with those heuristics, the message may not be delivered or may be
-   discarded on receipt.
-
-   Participants relying on Sender ID experiment DNS records are warned
-   that they may lose valid messages in this set of circumstances.
-   aParticipants publishing SPF experiment DNS records should consider
-   the advice given in section 3.4 of RFC 4406 and may wish to publish
-   both v=spf1 and spf2.0 records to avoid the conflict.
-
-
-
-
-Wong & Schlitt                Experimental                      [Page 1]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Participants in the Sender-ID experiment need to be aware that the
-   way Resent-* header fields are used will result in failure to receive
-   legitimate email when interacting with standards-compliant systems
-   (specifically automatic forwarders which comply with the standards by
-   not adding Resent-* headers, and systems which comply with RFC 822
-   but have not yet implemented RFC 2822 Resent-* semantics).  It would
-   be inappropriate to advance Sender-ID on the standards track without
-   resolving this interoperability problem.
-
-   The community is invited to observe the success or failure of the two
-   approaches during the two years following publication, in order that
-   a community consensus can be reached in the future.
-
-Abstract
-
-   E-mail on the Internet can be forged in a number of ways.  In
-   particular, existing protocols place no restriction on what a sending
-   host can use as the reverse-path of a message or the domain given on
-   the SMTP HELO/EHLO commands.  This document describes version 1 of
-   the Sender Policy Framework (SPF) protocol, whereby a domain may
-   explicitly authorize the hosts that are allowed to use its domain
-   name, and a receiving host may check such authorization.
-
-Table of Contents
-
-   1. Introduction ....................................................4
-      1.1. Protocol Status ............................................4
-      1.2. Terminology ................................................5
-   2. Operation .......................................................5
-      2.1. The HELO Identity ..........................................5
-      2.2. The MAIL FROM Identity .....................................5
-      2.3. Publishing Authorization ...................................6
-      2.4. Checking Authorization .....................................6
-      2.5. Interpreting the Result ....................................7
-           2.5.1. None ................................................8
-           2.5.2. Neutral .............................................8
-           2.5.3. Pass ................................................8
-           2.5.4. Fail ................................................8
-           2.5.5. SoftFail ............................................9
-           2.5.6. TempError ...........................................9
-           2.5.7. PermError ...........................................9
-   3. SPF Records .....................................................9
-      3.1. Publishing ................................................10
-           3.1.1. DNS Resource Record Types ..........................10
-           3.1.2. Multiple DNS Records ...............................11
-           3.1.3. Multiple Strings in a Single DNS record ............11
-           3.1.4. Record Size ........................................11
-           3.1.5. Wildcard Records ...................................11
-
-
-
-Wong & Schlitt                Experimental                      [Page 2]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   4. The check_host() Function ......................................12
-      4.1. Arguments .................................................12
-      4.2. Results ...................................................13
-      4.3. Initial Processing ........................................13
-      4.4. Record Lookup .............................................13
-      4.5. Selecting Records .........................................13
-      4.6. Record Evaluation .........................................14
-           4.6.1. Term Evaluation ....................................14
-           4.6.2. Mechanisms .........................................15
-           4.6.3. Modifiers ..........................................15
-      4.7. Default Result ............................................16
-      4.8. Domain Specification ......................................16
-   5. Mechanism Definitions ..........................................16
-      5.1. "all" .....................................................17
-      5.2. "include" .................................................18
-      5.3. "a" .......................................................19
-      5.4. "mx" ......................................................20
-      5.5. "ptr" .....................................................20
-      5.6. "ip4" and "ip6" ...........................................21
-      5.7. "exists" ..................................................22
-   6. Modifier Definitions ...........................................22
-      6.1. redirect: Redirected Query ................................23
-      6.2. exp: Explanation ..........................................23
-   7. The Received-SPF Header Field ..................................25
-   8. Macros .........................................................27
-      8.1. Macro Definitions .........................................27
-      8.2. Expansion Examples ........................................30
-   9. Implications ...................................................31
-      9.1. Sending Domains ...........................................31
-      9.2. Mailing Lists .............................................32
-      9.3. Forwarding Services and Aliases ...........................32
-      9.4. Mail Services .............................................34
-      9.5. MTA Relays ................................................34
-   10. Security Considerations .......................................35
-      10.1. Processing Limits ........................................35
-      10.2. SPF-Authorized E-Mail May Contain Other False
-            Identities ...............................................37
-      10.3. Spoofed DNS and IP Data ..................................37
-      10.4. Cross-User Forgery .......................................37
-      10.5. Untrusted Information Sources ............................38
-      10.6. Privacy Exposure .........................................38
-   11. Contributors and Acknowledgements .............................38
-   12. IANA Considerations ...........................................39
-      12.1. The SPF DNS Record Type ..................................39
-      12.2. The Received-SPF Mail Header Field .......................39
-   13. References ....................................................39
-      13.1. Normative References .....................................39
-      13.2. Informative References ...................................40
-
-
-
-Wong & Schlitt                Experimental                      [Page 3]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Appendix A.  Collected ABNF .......................................42
-   Appendix B.  Extended Examples ....................................44
-      B.1.  Simple Examples ..........................................44
-      B.2.  Multiple Domain Example ..................................45
-      B.3.  DNSBL Style Example ......................................46
-      B.4.  Multiple Requirements Example ............................46
-
-1.  Introduction
-
-   The current E-Mail infrastructure has the property that any host
-   injecting mail into the mail system can identify itself as any domain
-   name it wants.  Hosts can do this at a variety of levels: in
-   particular, the session, the envelope, and the mail headers.
-   Although this feature is desirable in some circumstances, it is a
-   major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam).
-   Furthermore, many domain name holders are understandably concerned
-   about the ease with which other entities may make use of their domain
-   names, often with malicious intent.
-
-   This document defines a protocol by which domain owners may authorize
-   hosts to use their domain name in the "MAIL FROM" or "HELO" identity.
-   Compliant domain holders publish Sender Policy Framework (SPF)
-   records specifying which hosts are permitted to use their names, and
-   compliant mail receivers use the published SPF records to test the
-   authorization of sending Mail Transfer Agents (MTAs) using a given
-   "HELO" or "MAIL FROM" identity during a mail transaction.
-
-   An additional benefit to mail receivers is that after the use of an
-   identity is verified, local policy decisions about the mail can be
-   made based on the sender's domain, rather than the host's IP address.
-   This is advantageous because reputation of domain names is likely to
-   be more accurate than reputation of host IP addresses.  Furthermore,
-   if a claimed identity fails verification, local policy can take
-   stronger action against such E-Mail, such as rejecting it.
-
-1.1.  Protocol Status
-
-   SPF has been in development since the summer of 2003 and has seen
-   deployment beyond the developers beginning in December 2003.  The
-   design of SPF slowly evolved until the spring of 2004 and has since
-   stabilized.  There have been quite a number of forms of SPF, some
-   written up as documents, some submitted as Internet Drafts, and many
-   discussed and debated in development forums.
-
-   The goal of this document is to clearly document the protocol defined
-   by earlier draft specifications of SPF as used in existing
-   implementations.  This conception of SPF is sometimes called "SPF
-   Classic".  It is understood that particular implementations and
-
-
-
-Wong & Schlitt                Experimental                      [Page 4]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   deployments may differ from, and build upon, this work.  It is hoped
-   that we have nonetheless captured the common understanding of SPF
-   version 1.
-
-1.2.  Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   This document is concerned with the portion of a mail message
-   commonly called "envelope sender", "return path", "reverse path",
-   "bounce address", "2821 FROM", or "MAIL FROM".  Since these terms are
-   either not well defined or often used casually, this document defines
-   the "MAIL FROM" identity in Section 2.2.  Note that other terms that
-   may superficially look like the common terms, such as "reverse-path",
-   are used only with the defined meanings from normative documents.
-
-2.  Operation
-
-2.1.  The HELO Identity
-
-   The "HELO" identity derives from either the SMTP HELO or EHLO command
-   (see [RFC2821]).  These commands supply the SMTP client (sending
-   host) for the SMTP session.  Note that requirements for the domain
-   presented in the EHLO or HELO command are not always clear to the
-   sending party, and SPF clients must be prepared for the "HELO"
-   identity to be malformed or an IP address literal.  At the time of
-   this writing, many legitimate E-Mails are delivered with invalid HELO
-   domains.
-
-   It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
-   identity, but also separately check the "HELO" identity by applying
-   the check_host() function (Section 4) to the "HELO" identity as the
-   <sender>.
-
-2.2.  The MAIL FROM Identity
-
-   The "MAIL FROM" identity derives from the SMTP MAIL command (see
-   [RFC2821]).  This command supplies the "reverse-path" for a message,
-   which generally consists of the sender mailbox, and is the mailbox to
-   which notification messages are to be sent if there are problems
-   delivering the message.
-
-   [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in
-   RFC 2821).  In this case, there is no explicit sender mailbox, and
-   such a message can be assumed to be a notification message from the
-   mail system itself.  When the reverse-path is null, this document
-
-
-
-Wong & Schlitt                Experimental                      [Page 5]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   defines the "MAIL FROM" identity to be the mailbox composed of the
-   localpart "postmaster" and the "HELO" identity (which may or may not
-   have been checked separately before).
-
-   SPF clients MUST check the "MAIL FROM" identity.  SPF clients check
-   the "MAIL FROM" identity by applying the check_host() function to the
-   "MAIL FROM" identity as the <sender>.
-
-2.3.  Publishing Authorization
-
-   An SPF-compliant domain MUST publish a valid SPF record as described
-   in Section 3.  This record authorizes the use of the domain name in
-   the "HELO" and "MAIL FROM" identities by the MTAs it specifies.
-
-   If domain owners choose to publish SPF records, it is RECOMMENDED
-   that they end in "-all", or redirect to other records that do, so
-   that a definitive determination of authorization can be made.
-
-   Domain holders may publish SPF records that explicitly authorize no
-   hosts if mail should never originate using that domain.
-
-   When changing SPF records, care must be taken to ensure that there is
-   a transition period so that the old policy remains valid until all
-   legitimate E-Mail has been checked.
-
-2.4.  Checking Authorization
-
-   A mail receiver can perform a set of SPF checks for each mail message
-   it receives.  An SPF check tests the authorization of a client host
-   to emit mail with a given identity.  Typically, such checks are done
-   by a receiving MTA, but can be performed elsewhere in the mail
-   processing chain so long as the required information is available and
-   reliable.  At least the "MAIL FROM" identity MUST be checked, but it
-   is RECOMMENDED that the "HELO" identity also be checked beforehand.
-
-   Without explicit approval of the domain owner, checking other
-   identities against SPF version 1 records is NOT RECOMMENDED because
-   there are cases that are known to give incorrect results.  For
-   example, almost all mailing lists rewrite the "MAIL FROM" identity
-   (see Section 9.2), but some do not change any other identities in the
-   message.  The scenario described in Section 9.3, sub-section 1.2, is
-   another example.  Documents that define other identities should
-   define the method for explicit approval.
-
-   It is possible that mail receivers will use the SPF check as part of
-   a larger set of tests on incoming mail.  The results of other tests
-   may influence whether or not a particular SPF check is performed.
-   For example, finding the sending host's IP address on a local white
-
-
-
-Wong & Schlitt                Experimental                      [Page 6]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   list may cause all other tests to be skipped and all mail from that
-   host to be accepted.
-
-   When a mail receiver decides to perform an SPF check, it MUST use a
-   correctly-implemented check_host() function (Section 4) evaluated
-   with the correct parameters.  Although the test as a whole is
-   optional, once it has been decided to perform a test it must be
-   performed as specified so that the correct semantics are preserved
-   between publisher and receiver.
-
-   To make the test, the mail receiver MUST evaluate the check_host()
-   function with the arguments set as follows:
-
-   <ip>     - the IP address of the SMTP client that is emitting the
-              mail, either IPv4 or IPv6.
-
-   <domain> - the domain portion of the "MAIL FROM" or "HELO" identity.
-
-   <sender> - the "MAIL FROM" or "HELO" identity.
-
-   Note that the <domain> argument may not be a well-formed domain name.
-   For example, if the reverse-path was null, then the EHLO/HELO domain
-   is used, with its associated problems (see Section 2.1).  In these
-   cases, check_host() is defined in Section 4.3 to return a "None"
-   result.
-
-   Although invalid, malformed, or non-existent domains cause SPF checks
-   to return "None" because no SPF record can be found, it has long been
-   the policy of many MTAs to reject E-Mail from such domains,
-   especially in the case of invalid "MAIL FROM".  In order to prevent
-   the circumvention of SPF records, rejecting E-Mail from invalid
-   domains should be considered.
-
-   Implementations must take care to correctly extract the <domain> from
-   the data given with the SMTP MAIL FROM command as many MTAs will
-   still accept such things as source routes (see [RFC2821], Appendix
-   C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).
-   These archaic features have been maliciously used to bypass security
-   systems.
-
-2.5.  Interpreting the Result
-
-   This section describes how software that performs the authorization
-   should interpret the results of the check_host() function.  The
-   authorization check SHOULD be performed during the processing of the
-   SMTP transaction that sends the mail.  This allows errors to be
-   returned directly to the sending MTA by way of SMTP replies.
-
-
-
-
-Wong & Schlitt                Experimental                      [Page 7]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Performing the authorization after the SMTP transaction has finished
-   may cause problems, such as the following: (1) It may be difficult to
-   accurately extract the required information from potentially
-   deceptive headers; (2) legitimate E-Mail may fail because the
-   sender's policy may have since changed.
-
-   Generating non-delivery notifications to forged identities that have
-   failed the authorization check is generally abusive and against the
-   explicit wishes of the identity owner.
-
-2.5.1.  None
-
-   A result of "None" means that no records were published by the domain
-   or that no checkable sender domain could be determined from the given
-   identity.  The checking software cannot ascertain whether or not the
-   client host is authorized.
-
-2.5.2.  Neutral
-
-   The domain owner has explicitly stated that he cannot or does not
-   want to assert whether or not the IP address is authorized.  A
-   "Neutral" result MUST be treated exactly like the "None" result; the
-   distinction exists only for informational purposes.  Treating
-   "Neutral" more harshly than "None" would discourage domain owners
-   from testing the use of SPF records (see Section 9.1).
-
-2.5.3.  Pass
-
-   A "Pass" result means that the client is authorized to inject mail
-   with the given identity.  The domain can now, in the sense of
-   reputation, be considered responsible for sending the message.
-   Further policy checks can now proceed with confidence in the
-   legitimate use of the identity.
-
-2.5.4.  Fail
-
-   A "Fail" result is an explicit statement that the client is not
-   authorized to use the domain in the given identity.  The checking
-   software can choose to mark the mail based on this or to reject the
-   mail outright.
-
-   If the checking software chooses to reject the mail during the SMTP
-   transaction, then it SHOULD use an SMTP reply code of 550 (see
-   [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification
-   (DSN) code (see [RFC3464]), in addition to an appropriate reply text.
-   The check_host() function may return either a default explanation
-   string or one from the domain that published the SPF records (see
-   Section 6.2).  If the information does not originate with the
-
-
-
-Wong & Schlitt                Experimental                      [Page 8]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   checking software, it should be made clear that the text is provided
-   by the sender's domain.  For example:
-
-       550-5.7.1 SPF MAIL FROM check failed:
-       550-5.7.1 The domain example.com explains:
-       550 5.7.1 Please see http://www.example.com/mailpolicy.html
-
-2.5.5.  SoftFail
-
-   A "SoftFail" result should be treated as somewhere between a "Fail"
-   and a "Neutral".  The domain believes the host is not authorized but
-   is not willing to make that strong of a statement.  Receiving
-   software SHOULD NOT reject the message based solely on this result,
-   but MAY subject the message to closer scrutiny than normal.
-
-   The domain owner wants to discourage the use of this host and thus
-   desires limited feedback when a "SoftFail" result occurs.  For
-   example, the recipient's Mail User Agent (MUA) could highlight the
-   "SoftFail" status, or the receiving MTA could give the sender a
-   message using a technique called "greylisting" whereby the MTA can
-   issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the
-   first time the message is received, but accept it the second time.
-
-2.5.6.  TempError
-
-   A "TempError" result means that the SPF client encountered a
-   transient error while performing the check.  Checking software can
-   choose to accept or temporarily reject the message.  If the message
-   is rejected during the SMTP transaction for this reason, the software
-   SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN
-   code.
-
-2.5.7.  PermError
-
-   A "PermError" result means that the domain's published records could
-   not be correctly interpreted.  This signals an error condition that
-   requires manual intervention to be resolved, as opposed to the
-   TempError result.  Be aware that if the domain owner uses macros
-   (Section 8), it is possible that this result is due to the checked
-   identities having an unexpected format.
-
-3.  SPF Records
-
-   An SPF record is a DNS Resource Record (RR) that declares which hosts
-   are, and are not, authorized to use a domain name for the "HELO" and
-   "MAIL FROM" identities.  Loosely, the record partitions all hosts
-   into permitted and not-permitted sets (though some hosts might fall
-   into neither category).
-
-
-
-Wong & Schlitt                Experimental                      [Page 9]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   The SPF record is a single string of text.  An example record is the
-   following:
-
-      v=spf1 +mx a:colo.example.com/28 -all
-
-   This record has a version of "spf1" and three directives: "+mx",
-   "a:colo.example.com/28" (the + is implied), and "-all".
-
-3.1.  Publishing
-
-   Domain owners wishing to be SPF compliant must publish SPF records
-   for the hosts that are used in the "MAIL FROM" and "HELO" identities.
-   The SPF records are placed in the DNS tree at the host name it
-   pertains to, not a subdomain under it, such as is done with SRV
-   records.  This is the same whether the TXT or SPF RR type (see
-   Section 3.1.1) is used.
-
-   The example above in Section 3 might be published via these lines in
-   a domain zone file:
-
-      example.com.          TXT "v=spf1 +mx a:colo.example.com/28 -all"
-      smtp-out.example.com. TXT "v=spf1 a -all"
-
-   When publishing via TXT records, beware of other TXT records
-   published there for other purposes.  They may cause problems with
-   size limits (see Section 3.1.4).
-
-3.1.1.  DNS Resource Record Types
-
-   This document defines a new DNS RR of type SPF, code 99.  The format
-   of this type is identical to the TXT RR [RFC1035].  For either type,
-   the character content of the record is encoded as [US-ASCII].
-
-   It is recognized that the current practice (using a TXT record) is
-   not optimal, but it is necessary because there are a number of DNS
-   server and resolver implementations in common use that cannot handle
-   the new RR type.  The two-record-type scheme provides a forward path
-   to the better solution of using an RR type reserved for this purpose.
-
-   An SPF-compliant domain name SHOULD have SPF records of both RR
-   types.  A compliant domain name MUST have a record of at least one
-   type.  If a domain has records of both types, they MUST have
-   identical content.  For example, instead of publishing just one
-   record as in Section 3.1 above, it is better to publish:
-
-      example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
-      example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 10]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Example RRs in this document are shown with the TXT record type;
-   however, they could be published with the SPF type or with both
-   types.
-
-3.1.2.  Multiple DNS Records
-
-   A domain name MUST NOT have multiple records that would cause an
-   authorization check to select more than one record.  See Section 4.5
-   for the selection rules.
-
-3.1.3.  Multiple Strings in a Single DNS record
-
-   As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
-   record (either TXT or SPF RR types) can be composed of more than one
-   string.  If a published record contains multiple strings, then the
-   record MUST be treated as if those strings are concatenated together
-   without adding spaces.  For example:
-
-      IN TXT "v=spf1 .... first" "second string..."
-
-   MUST be treated as equivalent to
-
-      IN TXT "v=spf1 .... firstsecond string..."
-
-   SPF or TXT records containing multiple strings are useful in
-   constructing records that would exceed the 255-byte maximum length of
-   a string within a single TXT or SPF RR record.
-
-3.1.4.  Record Size
-
-   The published SPF record for a given domain name SHOULD remain small
-   enough that the results of a query for it will fit within 512 octets.
-   This will keep even older DNS implementations from falling over to
-   TCP.  Since the answer size is dependent on many things outside the
-   scope of this document, it is only possible to give this guideline:
-   If the combined length of the DNS name and the text of all the
-   records of a given type (TXT or SPF) is under 450 characters, then
-   DNS answers should fit in UDP packets.  Note that when computing the
-   sizes for queries of the TXT format, one must take into account any
-   other TXT records published at the domain name.  Records that are too
-   long to fit in a single UDP packet MAY be silently ignored by SPF
-   clients.
-
-3.1.5.  Wildcard Records
-
-   Use of wildcard records for publishing is not recommended.  Care must
-   be taken if wildcard records are used.  If a domain publishes
-   wildcard MX records, it may want to publish wildcard declarations,
-
-
-
-Wong & Schlitt                Experimental                     [Page 11]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   subject to the same requirements and problems.  In particular, the
-   declaration must be repeated for any host that has any RR records at
-   all, and for subdomains thereof.  For example, the example given in
-   [RFC1034], Section 4.3.3, could be extended with the following:
-
-       X.COM.          MX      10      A.X.COM
-       X.COM.          TXT     "v=spf1 a:A.X.COM -all"
-
-       *.X.COM.        MX      10      A.X.COM
-       *.X.COM.        TXT     "v=spf1 a:A.X.COM -all"
-
-       A.X.COM.        A       1.2.3.4
-       A.X.COM.        MX      10      A.X.COM
-       A.X.COM.        TXT     "v=spf1 a:A.X.COM -all"
-
-       *.A.X.COM.      MX      10      A.X.COM
-       *.A.X.COM.      TXT     "v=spf1 a:A.X.COM -all"
-
-   Notice that SPF records must be repeated twice for every name within
-   the domain: once for the name, and once with a wildcard to cover the
-   tree under the name.
-
-   Use of wildcards is discouraged in general as they cause every name
-   under the domain to exist and queries against arbitrary names will
-   never return RCODE 3 (Name Error).
-
-4.  The check_host() Function
-
-   The check_host() function fetches SPF records, parses them, and
-   interprets them to determine whether a particular host is or is not
-   permitted to send mail with a given identity.  Mail receivers that
-   perform this check MUST correctly evaluate the check_host() function
-   as described here.
-
-   Implementations MAY use a different algorithm than the canonical
-   algorithm defined here, so long as the results are the same in all
-   cases.
-
-4.1.  Arguments
-
-   The check_host() function takes these arguments:
-
-   <ip>     - the IP address of the SMTP client that is emitting the
-              mail, either IPv4 or IPv6.
-
-   <domain> - the domain that provides the sought-after authorization
-              information; initially, the domain portion of the "MAIL
-              FROM" or "HELO" identity.
-
-
-
-Wong & Schlitt                Experimental                     [Page 12]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   <sender> - the "MAIL FROM" or "HELO" identity.
-
-   The domain portion of <sender> will usually be the same as the
-   <domain> argument when check_host() is initially evaluated.  However,
-   this will generally not be true for recursive evaluations (see
-   Section 5.2 below).
-
-   Actual implementations of the check_host() function may need
-   additional arguments.
-
-4.2.  Results
-
-   The function check_host() can return one of several results described
-   in Section 2.5.  Based on the result, the action to be taken is
-   determined by the local policies of the receiver.
-
-4.3.  Initial Processing
-
-   If the <domain> is malformed (label longer than 63 characters, zero-
-   length label not at the end, etc.) or is not a fully qualified domain
-   name, or if the DNS lookup returns "domain does not exist" (RCODE 3),
-   check_host() immediately returns the result "None".
-
-   If the <sender> has no localpart, substitute the string "postmaster"
-   for the localpart.
-
-4.4.  Record Lookup
-
-   In accordance with how the records are published (see Section 3.1
-   above), a DNS query needs to be made for the <domain> name, querying
-   for either RR type TXT, SPF, or both.  If both SPF and TXT RRs are
-   looked up, the queries MAY be done in parallel.
-
-   If all DNS lookups that are made return a server failure (RCODE 2),
-   or other error (RCODE other than 0 or 3), or time out, then
-   check_host() exits immediately with the result "TempError".
-
-4.5.  Selecting Records
-
-   Records begin with a version section:
-
-   record           = version terms *SP
-   version          = "v=spf1"
-
-   Starting with the set of records that were returned by the lookup,
-   record selection proceeds in two steps:
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 13]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   1. Records that do not begin with a version section of exactly
-      "v=spf1" are discarded.  Note that the version section is
-      terminated either by an SP character or the end of the record.  A
-      record with a version section of "v=spf10" does not match and must
-      be discarded.
-
-   2. If any records of type SPF are in the set, then all records of
-      type TXT are discarded.
-
-   After the above steps, there should be exactly one record remaining
-   and evaluation can proceed.  If there are two or more records
-   remaining, then check_host() exits immediately with the result of
-   "PermError".
-
-   If no matching records are returned, an SPF client MUST assume that
-   the domain makes no SPF declarations.  SPF processing MUST stop and
-   return "None".
-
-4.6.  Record Evaluation
-
-   After one SPF record has been selected, the check_host() function
-   parses and interprets it to find a result for the current test.  If
-   there are any syntax errors, check_host() returns immediately with
-   the result "PermError".
-
-   Implementations MAY choose to parse the entire record first and
-   return "PermError" if the record is not syntactically well formed.
-   However, in all cases, any syntax errors anywhere in the record MUST
-   be detected.
-
-4.6.1.  Term Evaluation
-
-   There are two types of terms: mechanisms and modifiers.  A record
-   contains an ordered list of these as specified in the following
-   Augmented Backus-Naur Form (ABNF).
-
-   terms            = *( 1*SP ( directive / modifier ) )
-
-   directive        = [ qualifier ] mechanism
-   qualifier        = "+" / "-" / "?" / "~"
-   mechanism        = ( all / include
-                      / A / MX / PTR / IP4 / IP6 / exists )
-   modifier         = redirect / explanation / unknown-modifier
-   unknown-modifier = name "=" macro-string
-
-   name             = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
-
-   Most mechanisms allow a ":" or "/" character after the name.
-
-
-
-Wong & Schlitt                Experimental                     [Page 14]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Modifiers always contain an equals ('=') character immediately after
-   the name, and before any ":" or "/" characters that may be part of
-   the macro-string.
-
-   Terms that do not contain any of "=", ":", or "/" are mechanisms, as
-   defined in Section 5.
-
-   As per the definition of the ABNF notation in [RFC4234], mechanism
-   and modifier names are case-insensitive.
-
-4.6.2.  Mechanisms
-
-   Each mechanism is considered in turn from left to right.  If there
-   are no more mechanisms, the result is specified in Section 4.7.
-
-   When a mechanism is evaluated, one of three things can happen: it can
-   match, not match, or throw an exception.
-
-   If it matches, processing ends and the qualifier value is returned as
-   the result of that record.  If it does not match, processing
-   continues with the next mechanism.  If it throws an exception,
-   mechanism processing ends and the exception value is returned.
-
-   The possible qualifiers, and the results they return are as follows:
-
-      "+" Pass
-      "-" Fail
-      "~" SoftFail
-      "?" Neutral
-
-   The qualifier is optional and defaults to "+".
-
-   When a mechanism matches and the qualifier is "-", then a "Fail"
-   result is returned and the explanation string is computed as
-   described in Section 6.2.
-
-   The specific mechanisms are described in Section 5.
-
-4.6.3.  Modifiers
-
-   Modifiers are not mechanisms: they do not return match or not-match.
-   Instead they provide additional information.  Although modifiers do
-   not directly affect the evaluation of the record, the "redirect"
-   modifier has an effect after all the mechanisms have been evaluated.
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 15]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-4.7.  Default Result
-
-   If none of the mechanisms match and there is no "redirect" modifier,
-   then the check_host() returns a result of "Neutral", just as if
-   "?all" were specified as the last directive.  If there is a
-   "redirect" modifier, check_host() proceeds as defined in Section 6.1.
-
-   Note that records SHOULD always use either a "redirect" modifier or
-   an "all" mechanism to explicitly terminate processing.
-
-   For example:
-
-      v=spf1 +mx -all
-   or
-      v=spf1 +mx redirect=_spf.example.com
-
-4.8.  Domain Specification
-
-   Several of these mechanisms and modifiers have a <domain-spec>
-   section.  The <domain-spec> string is macro expanded (see Section 8).
-   The resulting string is the common presentation form of a fully-
-   qualified DNS name: a series of labels separated by periods.  This
-   domain is called the <target-name> in the rest of this document.
-
-   Note: The result of the macro expansion is not subject to any further
-   escaping.  Hence, this facility cannot produce all characters that
-   are legal in a DNS label (e.g., the control characters).  However,
-   this facility is powerful enough to express legal host names and
-   common utility labels (such as "_spf") that are used in DNS.
-
-   For several mechanisms, the <domain-spec> is optional.  If it is not
-   provided, the <domain> is used as the <target-name>.
-
-5.  Mechanism Definitions
-
-   This section defines two types of mechanisms.
-
-   Basic mechanisms contribute to the language framework.  They do not
-   specify a particular type of authorization scheme.
-
-      all
-      include
-
-   Designated sender mechanisms are used to designate a set of <ip>
-   addresses as being permitted or not permitted to use the <domain> for
-   sending mail.
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 16]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-      a
-      mx
-      ptr
-      ip4
-      ip6
-      exists
-
-   The following conventions apply to all mechanisms that perform a
-   comparison between <ip> and an IP address at any point:
-
-   If no CIDR-length is given in the directive, then <ip> and the IP
-   address are compared for equality. (Here, CIDR is Classless Inter-
-   Domain Routing.)
-
-   If a CIDR-length is specified, then only the specified number of
-   high-order bits of <ip> and the IP address are compared for equality.
-
-   When any mechanism fetches host addresses to compare with <ip>, when
-   <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
-   address, AAAA records are fetched.  Even if the SMTP connection is
-   via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section
-   2.5.5) MUST still be considered an IPv4 address.
-
-   Several mechanisms rely on information fetched from DNS.  For these
-   DNS queries, except where noted, if the DNS server returns an error
-   (RCODE other than 0 or 3) or the query times out, the mechanism
-   throws the exception "TempError".  If the server returns "domain does
-   not exist" (RCODE 3), then evaluation of the mechanism continues as
-   if the server returned no error (RCODE 0) and zero answer records.
-
-5.1.  "all"
-
-   all              = "all"
-
-   The "all" mechanism is a test that always matches.  It is used as the
-   rightmost mechanism in a record to provide an explicit default.
-
-   For example:
-
-      v=spf1 a mx -all
-
-   Mechanisms after "all" will never be tested.  Any "redirect" modifier
-   (Section 6.1) has no effect when there is an "all" mechanism.
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 17]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-5.2.  "include"
-
-      include          = "include"  ":" domain-spec
-
-   The "include" mechanism triggers a recursive evaluation of
-   check_host().  The domain-spec is expanded as per Section 8.  Then
-   check_host() is evaluated with the resulting string as the <domain>.
-   The <ip> and <sender> arguments remain the same as in the current
-   evaluation of check_host().
-
-   In hindsight, the name "include" was poorly chosen.  Only the
-   evaluated result of the referenced SPF record is used, rather than
-   acting as if the referenced SPF record was literally included in the
-   first.  For example, evaluating a "-all" directive in the referenced
-   record does not terminate the overall processing and does not
-   necessarily result in an overall "Fail".  (Better names for this
-   mechanism would have been "if-pass", "on-pass", etc.)
-
-   The "include" mechanism makes it possible for one domain to designate
-   multiple administratively-independent domains.  For example, a vanity
-   domain "example.net" might send mail using the servers of
-   administratively-independent domains example.com and example.org.
-
-   Example.net could say
-
-      IN TXT "v=spf1 include:example.com include:example.org -all"
-
-   This would direct check_host() to, in effect, check the records of
-   example.com and example.org for a "Pass" result.  Only if the host
-   were not permitted for either of those domains would the result be
-   "Fail".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 18]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Whether this mechanism matches, does not match, or throws an
-   exception depends on the result of the recursive evaluation of
-   check_host():
-
-   +---------------------------------+---------------------------------+
-   | A recursive check_host() result | Causes the "include" mechanism  |
-   | of:                             | to:                             |
-   +---------------------------------+---------------------------------+
-   | Pass                            | match                           |
-   |                                 |                                 |
-   | Fail                            | not match                       |
-   |                                 |                                 |
-   | SoftFail                        | not match                       |
-   |                                 |                                 |
-   | Neutral                         | not match                       |
-   |                                 |                                 |
-   | TempError                       | throw TempError                 |
-   |                                 |                                 |
-   | PermError                       | throw PermError                 |
-   |                                 |                                 |
-   | None                            | throw PermError                 |
-   +---------------------------------+---------------------------------+
-
-   The "include" mechanism is intended for crossing administrative
-   boundaries.  Although it is possible to use includes to consolidate
-   multiple domains that share the same set of designated hosts, domains
-   are encouraged to use redirects where possible, and to minimize the
-   number of includes within a single administrative domain.  For
-   example, if example.com and example.org were managed by the same
-   entity, and if the permitted set of hosts for both domains was
-   "mx:example.com", it would be possible for example.org to specify
-   "include:example.com", but it would be preferable to specify
-   "redirect=example.com" or even "mx:example.com".
-
-5.3.  "a"
-
-   This mechanism matches if <ip> is one of the <target-name>'s IP
-   addresses.
-
-   A                = "a"      [ ":" domain-spec ] [ dual-cidr-length ]
-
-   An address lookup is done on the <target-name>.  The <ip> is compared
-   to the returned address(es).  If any address matches, the mechanism
-   matches.
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 19]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-5.4.  "mx"
-
-   This mechanism matches if <ip> is one of the MX hosts for a domain
-   name.
-
-   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
-
-   check_host() first performs an MX lookup on the <target-name>.  Then
-   it performs an address lookup on each MX name returned.  The <ip> is
-   compared to each returned IP address.  To prevent Denial of Service
-   (DoS) attacks, more than 10 MX names MUST NOT be looked up during the
-   evaluation of an "mx" mechanism (see Section 10).  If any address
-   matches, the mechanism matches.
-
-   Note regarding implicit MXs: If the <target-name> has no MX records,
-   check_host() MUST NOT pretend the target is its single MX, and MUST
-   NOT default to an A lookup on the <target-name> directly.  This
-   behavior breaks with the legacy "implicit MX" rule.  See [RFC2821],
-   Section 5.  If such behavior is desired, the publisher should specify
-   an "a" directive.
-
-5.5.  "ptr"
-
-   This mechanism tests whether the DNS reverse-mapping for <ip> exists
-   and correctly points to a domain name within a particular domain.
-
-   PTR              = "ptr"    [ ":" domain-spec ]
-
-   First, the <ip>'s name is looked up using this procedure: perform a
-   DNS reverse-mapping for <ip>, looking up the corresponding PTR record
-   in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa."
-   if it is an IPv6 address.  For each record returned, validate the
-   domain name by looking up its IP address.  To prevent DoS attacks,
-   more than 10 PTR names MUST NOT be looked up during the evaluation of
-   a "ptr" mechanism (see Section 10).  If <ip> is among the returned IP
-   addresses, then that domain name is validated.  In pseudocode:
-
-   sending-domain_names := ptr_lookup(sending-host_IP); if more than 10
-   sending-domain_names are found, use at most 10.  for each name in
-   (sending-domain_names) {
-     IP_addresses := a_lookup(name);
-     if the sending-domain_IP is one of the IP_addresses {
-       validated-sending-domain_names += name;
-     } }
-
-   Check all validated domain names to see if they end in the
-   <target-name> domain.  If any do, this mechanism matches.  If no
-   validated domain name can be found, or if none of the validated
-
-
-
-Wong & Schlitt                Experimental                     [Page 20]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   domain names end in the <target-name>, this mechanism fails to match.
-   If a DNS error occurs while doing the PTR RR lookup, then this
-   mechanism fails to match.  If a DNS error occurs while doing an A RR
-   lookup, then that domain name is skipped and the search continues.
-
-   Pseudocode:
-
-   for each name in (validated-sending-domain_names) {
-     if name ends in <domain-spec>, return match.
-     if name is <domain-spec>, return match.
-   }
-   return no-match.
-
-   This mechanism matches if the <target-name> is either an ancestor of
-   a validated domain name or if the <target-name> and a validated
-   domain name are the same.  For example: "mail.example.com" is within
-   the domain "example.com", but "mail.bad-example.com" is not.
-
-   Note: Use of this mechanism is discouraged because it is slow, it is
-   not as reliable as other mechanisms in cases of DNS errors, and it
-   places a large burden on the arpa name servers.  If used, proper PTR
-   records must be in place for the domain's hosts and the "ptr"
-   mechanism should be one of the last mechanisms checked.
-
-5.6.  "ip4" and "ip6"
-
-   These mechanisms test whether <ip> is contained within a given IP
-   network.
-
-   IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
-   IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
-
-   ip4-cidr-length  = "/" 1*DIGIT
-   ip6-cidr-length  = "/" 1*DIGIT
-   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
-
-   ip4-network      = qnum "." qnum "." qnum "." qnum
-   qnum             = DIGIT                 ; 0-9
-                      / %x31-39 DIGIT       ; 10-99
-                      / "1" 2DIGIT          ; 100-199
-                      / "2" %x30-34 DIGIT   ; 200-249
-                      / "25" %x30-35        ; 250-255
-            ; as per conventional dotted quad notation.  e.g., 192.0.2.0
-   ip6-network      = <as per [RFC 3513], section 2.2>
-            ; e.g., 2001:DB8::CD30
-
-   The <ip> is compared to the given network.  If CIDR-length high-order
-   bits match, the mechanism matches.
-
-
-
-Wong & Schlitt                Experimental                     [Page 21]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   If ip4-cidr-length is omitted, it is taken to be "/32".  If
-   ip6-cidr-length is omitted, it is taken to be "/128".  It is not
-   permitted to omit parts of the IP address instead of using CIDR
-   notations.  That is, use 192.0.2.0/24 instead of 192.0.2.
-
-5.7.  "exists"
-
-   This mechanism is used to construct an arbitrary domain name that is
-   used for a DNS A record query.  It allows for complicated schemes
-   involving arbitrary parts of the mail envelope to determine what is
-   permitted.
-
-   exists           = "exists"   ":" domain-spec
-
-   The domain-spec is expanded as per Section 8.  The resulting domain
-   name is used for a DNS A RR lookup.  If any A record is returned,
-   this mechanism matches.  The lookup type is A even when the
-   connection type is IPv6.
-
-   Domains can use this mechanism to specify arbitrarily complex
-   queries.  For example, suppose example.com publishes the record:
-
-      v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
-
-   The <target-name> might expand to
-   "1.2.0.192.someuser._spf.example.com".  This makes fine-grained
-   decisions possible at the level of the user and client IP address.
-
-   This mechanism enables queries that mimic the style of tests that
-   existing anti-spam DNS blacklists (DNSBL) use.
-
-6.  Modifier Definitions
-
-   Modifiers are name/value pairs that provide additional information.
-   Modifiers always have an "=" separating the name and the value.
-
-   The modifiers defined in this document ("redirect" and "exp") MAY
-   appear anywhere in the record, but SHOULD appear at the end, after
-   all mechanisms.  Ordering of these two modifiers does not matter.
-   These two modifiers MUST NOT appear in a record more than once each.
-   If they do, then check_host() exits with a result of "PermError".
-
-   Unrecognized modifiers MUST be ignored no matter where in a record,
-   or how often.  This allows implementations of this document to
-   gracefully handle records with modifiers that are defined in other
-   specifications.
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 22]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-6.1.  redirect: Redirected Query
-
-   If all mechanisms fail to match, and a "redirect" modifier is
-   present, then processing proceeds as follows:
-
-   redirect         = "redirect" "=" domain-spec
-
-   The domain-spec portion of the redirect section is expanded as per
-   the macro rules in Section 8.  Then check_host() is evaluated with
-   the resulting string as the <domain>.  The <ip> and <sender>
-   arguments remain the same as current evaluation of check_host().
-
-   The result of this new evaluation of check_host() is then considered
-   the result of the current evaluation with the exception that if no
-   SPF record is found, or if the target-name is malformed, the result
-   is a "PermError" rather than "None".
-
-   Note that the newly-queried domain may itself specify redirect
-   processing.
-
-   This facility is intended for use by organizations that wish to apply
-   the same record to multiple domains.  For example:
-
-     la.example.com. TXT "v=spf1 redirect=_spf.example.com"
-     ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
-     sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
-   _spf.example.com. TXT "v=spf1 mx:example.com -all"
-
-   In this example, mail from any of the three domains is described by
-   the same record.  This can be an administrative advantage.
-
-   Note: In general, the domain "A" cannot reliably use a redirect to
-   another domain "B" not under the same administrative control.  Since
-   the <sender> stays the same, there is no guarantee that the record at
-   domain "B" will correctly work for mailboxes in domain "A",
-   especially if domain "B" uses mechanisms involving localparts.  An
-   "include" directive may be more appropriate.
-
-   For clarity, it is RECOMMENDED that any "redirect" modifier appear as
-   the very last term in a record.
-
-6.2.  exp: Explanation
-
-   explanation      = "exp" "=" domain-spec
-
-   If check_host() results in a "Fail" due to a mechanism match (such as
-   "-all"), and the "exp" modifier is present, then the explanation
-   string returned is computed as described below.  If no "exp" modifier
-
-
-
-Wong & Schlitt                Experimental                     [Page 23]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   is present, then either a default explanation string or an empty
-   explanation string may be returned.
-
-   The <domain-spec> is macro expanded (see Section 8) and becomes the
-   <target-name>.  The DNS TXT record for the <target-name> is fetched.
-
-   If <domain-spec> is empty, or there are any DNS processing errors
-   (any RCODE other than 0), or if no records are returned, or if more
-   than one record is returned, or if there are syntax errors in the
-   explanation string, then proceed as if no exp modifier was given.
-
-   The fetched TXT record's strings are concatenated with no spaces, and
-   then treated as an <explain-string>, which is macro-expanded.  This
-   final result is the explanation string.  Implementations MAY limit
-   the length of the resulting explanation string to allow for other
-   protocol constraints and/or reasonable processing limits.  Since the
-   explanation string is intended for an SMTP response and [RFC2821]
-   Section 2.4 says that responses are in [US-ASCII], the explanation
-   string is also limited to US-ASCII.
-
-   Software evaluating check_host() can use this string to communicate
-   information from the publishing domain in the form of a short message
-   or URL.  Software SHOULD make it clear that the explanation string
-   comes from a third party.  For example, it can prepend the macro
-   string "%{o} explains: " to the explanation, such as shown in Section
-   2.5.4.
-
-   Suppose example.com has this record:
-
-      v=spf1 mx -all exp=explain._spf.%{d}
-
-   Here are some examples of possible explanation TXT records at
-   explain._spf.example.com:
-
-      "Mail from example.com should only be sent by its own servers."
-         -- a simple, constant message
-
-      "%{i} is not one of %{d}'s designated mail servers."
-         -- a message with a little more information, including the IP
-            address that failed the check
-
-      "See http://%{d}/why.html?s=%{S}&i=%{I}"
-         -- a complicated example that constructs a URL with the
-            arguments to check_host() so that a web page can be
-            generated with detailed, custom instructions
-
-   Note: During recursion into an "include" mechanism, an exp= modifier
-   from the <target-name> MUST NOT be used.  In contrast, when executing
-
-
-
-Wong & Schlitt                Experimental                     [Page 24]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   a "redirect" modifier, an exp= modifier from the original domain MUST
-   NOT be used.
-
-7.  The Received-SPF Header Field
-
-   It is RECOMMENDED that SMTP receivers record the result of SPF
-   processing in the message header.  If an SMTP receiver chooses to do
-   so, it SHOULD use the "Received-SPF" header field defined here for
-   each identity that was checked.  This information is intended for the
-   recipient.  (Information intended for the sender is described in
-   Section 6.2, Explanation.)
-
-   The Received-SPF header field is a trace field (see [RFC2822] Section
-   3.6.7) and SHOULD be prepended to the existing header, above the
-   Received: field that is generated by the SMTP receiver.  It MUST
-   appear above all other Received-SPF fields in the message.  The
-   header field has the following format:
-
-   header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
-                      [ key-value-list ] CRLF
-
-   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
-                      "None" / "TempError" / "PermError"
-
-   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
-                      [";"]
-
-   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )
-
-   key              = "client-ip" / "envelope-from" / "helo" /
-                      "problem" / "receiver" / "identity" /
-                       mechanism / "x-" name / name
-
-   identity         = "mailfrom"   ; for the "MAIL FROM" identity
-                      / "helo"     ; for the "HELO" identity
-                      / name       ; other identities
-
-   dot-atom         = <unquoted word as per [RFC2822]>
-   quoted-string    = <quoted string as per [RFC2822]>
-   comment          = <comment string as per [RFC2822]>
-   CFWS             = <comment or folding white space as per [RFC2822]>
-   FWS              = <folding white space as per [RFC2822]>
-   CRLF             = <standard end-of-line token as per [RFC2822]>
-
-   The header field SHOULD include a "(...)" style <comment> after the
-   result, conveying supporting information for the result, such as
-   <ip>, <sender>, and <domain>.
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 25]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   The following key-value pairs are designed for later machine parsing.
-   SPF clients SHOULD give enough information so that the SPF results
-   can be verified.  That is, at least "client-ip", "helo", and, if the
-   "MAIL FROM" identity was checked, "envelope-from".
-
-   client-ip      the IP address of the SMTP client
-
-   envelope-from  the envelope sender mailbox
-
-   helo           the host name given in the HELO or EHLO command
-
-   mechanism      the mechanism that matched (if no mechanisms matched,
-                  substitute the word "default")
-
-   problem        if an error was returned, details about the error
-
-   receiver       the host name of the SPF client
-
-   identity       the identity that was checked; see the <identity> ABNF
-                  rule
-
-   Other keys may be defined by SPF clients.  Until a new key name
-   becomes widely accepted, new key names should start with "x-".
-
-   SPF clients MUST make sure that the Received-SPF header field does
-   not contain invalid characters, is not excessively long, and does not
-   contain malicious data that has been provided by the sender.
-
-   Examples of various header styles that could be generated are the
-   following:
-
-   Received-SPF: Pass (mybox.example.org: domain of
-    myname@example.com designates 192.0.2.1 as permitted sender)
-       receiver=mybox.example.org; client-ip=192.0.2.1;
-       envelope-from=<myname@example.com>; helo=foo.example.com;
-
-   Received-SPF: Fail (mybox.example.org: domain of
-                     myname@example.com does not designate
-                     192.0.2.1 as permitted sender)
-                     identity=mailfrom; client-ip=192.0.2.1;
-                     envelope-from=<myname@example.com>;
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 26]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-8.  Macros
-
-8.1.  Macro Definitions
-
-   Many mechanisms and modifiers perform macro expansion on part of the
-   term.
-
-   domain-spec      = macro-string domain-end
-   domain-end       = ( "." toplabel [ "." ] ) / macro-expand
-
-   toplabel         = ( *alphanum ALPHA *alphanum ) /
-                      ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
-                      ; LDH rule plus additional TLD restrictions
-                      ; (see [RFC3696], Section 2)
-   alphanum         = ALPHA / DIGIT
-
-   explain-string   = *( macro-string / SP )
-
-   macro-string     = *( macro-expand / macro-literal )
-   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
-                      / "%%" / "%_" / "%-"
-   macro-literal    = %x21-24 / %x26-7E
-                      ; visible characters except "%"
-   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
-                      "c" / "r" / "t"
-   transformers     = *DIGIT [ "r" ]
-   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="
-
-   A literal "%" is expressed by "%%".
-
-      "%_" expands to a single " " space.
-      "%-" expands to a URL-encoded space, viz., "%20".
-
-   The following macro letters are expanded in term arguments:
-
-      s = <sender>
-      l = local-part of <sender>
-      o = domain of <sender>
-      d = <domain>
-      i = <ip>
-      p = the validated domain name of <ip>
-      v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
-      h = HELO/EHLO domain
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 27]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   The following macro letters are allowed only in "exp" text:
-
-      c = SMTP client IP (easily readable format)
-      r = domain name of host performing the check
-      t = current timestamp
-
-   A '%' character not followed by a '{', '%', '-', or '_' character is
-   a syntax error.  So
-
-      -exists:%(ir).sbl.spamhaus.example.org
-
-   is incorrect and will cause check_host() to return a "PermError".
-   Instead, say
-
-      -exists:%{ir}.sbl.spamhaus.example.org
-
-   Optional transformers are the following:
-
-      *DIGIT = zero or more digits
-      'r'    = reverse value, splitting on dots by default
-
-   If transformers or delimiters are provided, the replacement value for
-   a macro letter is split into parts.  After performing any reversal
-   operation and/or removal of left-hand parts, the parts are rejoined
-   using "." and not the original splitting characters.
-
-   By default, strings are split on "." (dots).  Note that no special
-   treatment is given to leading, trailing, or consecutive delimiters,
-   and so the list of parts may contain empty strings.  Older
-   implementations of SPF prohibit trailing dots in domain names, so
-   trailing dots should not be published by domain owners, although they
-   must be accepted by implementations conforming to this document.
-   Macros may specify delimiter characters that are used instead of ".".
-
-   The 'r' transformer indicates a reversal operation: if the client IP
-   address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1"
-   and the macro %{ir} would expand to "1.2.0.192".
-
-   The DIGIT transformer indicates the number of right-hand parts to
-   use, after optional reversal.  If a DIGIT is specified, the value
-   MUST be nonzero.  If no DIGITs are specified, or if the value
-   specifies more parts than are available, all the available parts are
-   used.  If the DIGIT was 5, and only 3 parts were available, the macro
-   interpreter would pretend the DIGIT was 3.  Implementations MUST
-   support at least a value of 128, as that is the maximum number of
-   labels in a domain name.
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 28]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   The "s" macro expands to the <sender> argument.  It is an E-Mail
-   address with a localpart, an "@" character, and a domain.  The "l"
-   macro expands to just the localpart.  The "o" macro expands to just
-   the domain part.  Note that these values remain the same during
-   recursive and chained evaluations due to "include" and/or "redirect".
-   Note also that if the original <sender> had no localpart, the
-   localpart was set to "postmaster" in initial processing (see Section
-   4.3).
-
-   For IPv4 addresses, both the "i" and "c" macros expand to the
-   standard dotted-quad format.
-
-   For IPv6 addresses, the "i" macro expands to a dot-format address; it
-   is intended for use in %{ir}.  The "c" macro may expand to any of the
-   hexadecimal colon-format addresses specified in [RFC3513], Section
-   2.2.  It is intended for humans to read.
-
-   The "p" macro expands to the validated domain name of <ip>.  The
-   procedure for finding the validated domain name is defined in Section
-   5.5.  If the <domain> is present in the list of validated domains, it
-   SHOULD be used.  Otherwise, if a subdomain of the <domain> is
-   present, it SHOULD be used.  Otherwise, any name from the list may be
-   used.  If there are no validated domain names or if a DNS error
-   occurs, the string "unknown" is used.
-
-   The "r" macro expands to the name of the receiving MTA.  This SHOULD
-   be a fully qualified domain name, but if one does not exist (as when
-   the checking is done by a MUA) or if policy restrictions dictate
-   otherwise, the word "unknown" SHOULD be substituted.  The domain name
-   may be different from the name found in the MX record that the client
-   MTA used to locate the receiving MTA.
-
-   The "t" macro expands to the decimal representation of the
-   approximate number of seconds since the Epoch (Midnight, January 1,
-   1970, UTC).  This is the same value as is returned by the POSIX
-   time() function in most standards-compliant libraries.
-
-   When the result of macro expansion is used in a domain name query, if
-   the expanded domain name exceeds 253 characters (the maximum length
-   of a domain name), the left side is truncated to fit, by removing
-   successive domain labels until the total length does not exceed 253
-   characters.
-
-   Uppercased macros expand exactly as their lowercased equivalents, and
-   are then URL escaped.  URL escaping must be performed for characters
-   not in the "uric" set, which is defined in [RFC3986].
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 29]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Note: Care must be taken so that macro expansion for legitimate
-   E-Mail does not exceed the 63-character limit on DNS labels.  The
-   localpart of E-Mail addresses, in particular, can have more than 63
-   characters between dots.
-
-   Note: Domains should avoid using the "s", "l", "o", or "h" macros in
-   conjunction with any mechanism directive.  Although these macros are
-   powerful and allow per-user records to be published, they severely
-   limit the ability of implementations to cache results of check_host()
-   and they reduce the effectiveness of DNS caches.
-
-   Implementations should be aware that if no directive processed during
-   the evaluation of check_host() contains an "s", "l", "o", or "h"
-   macro, then the results of the evaluation can be cached on the basis
-   of <domain> and <ip> alone for as long as the shortest Time To Live
-   (TTL) of all the DNS records involved.
-
-8.2.  Expansion Examples
-
-      The <sender> is strong-bad@email.example.com.
-      The IPv4 SMTP client IP is 192.0.2.3.
-      The IPv6 SMTP client IP is 2001:DB8::CB01.
-      The PTR domain name of the client IP is mx.example.org.
-
-   macro                       expansion
-   -------  ----------------------------
-   %{s}     strong-bad@email.example.com
-   %{o}                email.example.com
-   %{d}                email.example.com
-   %{d4}               email.example.com
-   %{d3}               email.example.com
-   %{d2}                     example.com
-   %{d1}                             com
-   %{dr}               com.example.email
-   %{d2r}                  example.email
-   %{l}                       strong-bad
-   %{l-}                      strong.bad
-   %{lr}                      strong-bad
-   %{lr-}                     bad.strong
-   %{l1r-}                        strong
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 30]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   macro-string                                               expansion
-   --------------------------------------------------------------------
-   %{ir}.%{v}._spf.%{d2}             3.2.0.192.in-addr._spf.example.com
-   %{lr-}.lp._spf.%{d2}                  bad.strong.lp._spf.example.com
-
-   %{lr-}.lp.%{ir}.%{v}._spf.%{d2}
-                       bad.strong.lp.3.2.0.192.in-addr._spf.example.com
-
-   %{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
-                           3.2.0.192.in-addr.strong.lp._spf.example.com
-
-   %{d2}.trusted-domains.example.net
-                                example.com.trusted-domains.example.net
-
-   IPv6:
-   %{ir}.%{v}._spf.%{d2}                               1.0.B.C.0.0.0.0.
-   0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com
-
-9.  Implications
-
-   This section outlines the major implications that adoption of this
-   document will have on various entities involved in Internet E-Mail.
-   It is intended to make clear to the reader where this document
-   knowingly affects the operation of such entities.  This section is
-   not a "how-to" manual, or a "best practices" document, and it is not
-   a comprehensive list of what such entities should do in light of this
-   document.
-
-   This section is non-normative.
-
-9.1.  Sending Domains
-
-   Domains that wish to be compliant with this specification will need
-   to determine the list of hosts that they allow to use their domain
-   name in the "HELO" and "MAIL FROM" identities.  It is recognized that
-   forming such a list is not just a simple technical exercise, but
-   involves policy decisions with both technical and administrative
-   considerations.
-
-   It can be helpful to publish records that include a "tracking
-   exists:" mechanism.  By looking at the name server logs, a rough list
-   may then be generated.  For example:
-
-      v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 31]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-9.2.  Mailing Lists
-
-   Mailing lists must be aware of how they re-inject mail that is sent
-   to the list.  Mailing lists MUST comply with the requirements in
-   [RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that
-   the reverse-path MUST be changed to be the mailbox of a person or
-   other entity who administers the list.  Whereas the reasons for
-   changing the reverse-path are many and long-standing, SPF adds
-   enforcement to this requirement.
-
-   In practice, almost all mailing list software in use already complies
-   with this requirement.  Mailing lists that do not comply may or may
-   not encounter problems depending on how access to the list is
-   restricted.  Such lists that are entirely internal to a domain (only
-   people in the domain can send to or receive from the list) are not
-   affected.
-
-9.3.  Forwarding Services and Aliases
-
-   Forwarding services take mail that is received at a mailbox and
-   direct it to some external mailbox.  At the time of this writing, the
-   near-universal practice of such services is to use the original "MAIL
-   FROM" of a message when re-injecting it for delivery to the external
-   mailbox.  [RFC1123] and [RFC2821] describe this action as an "alias"
-   rather than a "mail list".  This means that the external mailbox's
-   MTA sees all such mail in a connection from a host of the forwarding
-   service, and so the "MAIL FROM" identity will not, in general, pass
-   authorization.
-
-   There are three places that techniques can be used to ameliorate this
-   problem.
-
-   1. The beginning, when E-Mail is first sent.
-
-       1. "Neutral" results could be given for IP addresses that may be
-          forwarders, instead of "Fail" results.  For example:
-
-             "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"
-
-          This would cause a lookup on an anti-spam DNS blacklist
-          (DNSBL) and cause a result of "Fail" only for E-Mail coming
-          from listed sources.  All other E-Mail, including E-Mail sent
-          through forwarders, would receive a "Neutral" result.  By
-          checking the DNSBL after the known good sources, problems with
-          incorrect listing on the DNSBL are greatly reduced.
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 32]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-       2. The "MAIL FROM" identity could have additional information in
-          the localpart that cryptographically identifies the mail as
-          coming from an authorized source.  In this case, such an SPF
-          record could be used:
-
-             "v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
-
-          Then, a specialized DNS server can be set up to serve the
-          _spf_verify subdomain that validates the localpart.  Although
-          this requires an extra DNS lookup, this happens only when the
-          E-Mail would otherwise be rejected as not coming from a known
-          good source.
-
-          Note that due to the 63-character limit for domain labels,
-          this approach only works reliably if the localpart signature
-          scheme is guaranteed either to only produce localparts with a
-          maximum of 63 characters or to gracefully handle truncated
-          localparts.
-
-       3. Similarly, a specialized DNS server could be set up that will
-          rate-limit the E-Mail coming from unexpected IP addresses.
-
-             "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
-
-       4. SPF allows the creation of per-user policies for special
-          cases.  For example, the following SPF record and appropriate
-          wildcard DNS records can be used:
-
-                 "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
-
-   2.  The middle, when E-Mail is forwarded.
-
-       1. Forwarding services can solve the problem by rewriting the
-          "MAIL FROM" to be in their own domain.  This means that mail
-          bounced from the external mailbox will have to be re-bounced
-          by the forwarding service.  Various schemes to do this exist
-          though they vary widely in complexity and resource
-          requirements on the part of the forwarding service.
-
-       2. Several popular MTAs can be forced from "alias" semantics to
-          "mailing list" semantics by configuring an additional alias
-          with "owner-" prepended to the original alias name (e.g., an
-          alias of "friends: george@example.com, fred@example.org" would
-          need another alias of the form "owner-friends:  localowner").
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 33]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   3. The end, when E-Mail is received.
-
-       1. If the owner of the external mailbox wishes to trust the
-          forwarding service, he can direct the external mailbox's MTA
-          to skip SPF tests when the client host belongs to the
-          forwarding service.
-
-       2. Tests against other identities, such as the "HELO" identity,
-          may be used to override a failed test against the "MAIL FROM"
-          identity.
-
-       3. For larger domains, it may not be possible to have a complete
-          or accurate list of forwarding services used by the owners of
-          the domain's mailboxes.  In such cases, whitelists of
-          generally-recognized forwarding services could be employed.
-
-9.4.  Mail Services
-
-   Service providers that offer mail services to third-party domains,
-   such as sending of bulk mail, may want to adjust their setup in light
-   of the authorization check described in this document.  If the "MAIL
-   FROM" identity used for such E-Mail uses the domain of the service
-   provider, then the provider needs only to ensure that its sending
-   host is authorized by its own SPF record, if any.
-
-   If the "MAIL FROM" identity does not use the mail service provider's
-   domain, then extra care must be taken.  The SPF record format has
-   several options for the third-party domain to authorize the service
-   provider's MTAs to send mail on its behalf.  For mail service
-   providers, such as ISPs, that have a wide variety of customers using
-   the same MTA, steps should be taken to prevent cross-customer forgery
-   (see Section 10.4).
-
-9.5.  MTA Relays
-
-   The authorization check generally precludes the use of arbitrary MTA
-   relays between sender and receiver of an E-Mail message.
-
-   Within an organization, MTA relays can be effectively deployed.
-   However, for purposes of this document, such relays are effectively
-   transparent.  The SPF authorization check is a check between border
-   MTAs of different domains.
-
-   For mail senders, this means that published SPF records must
-   authorize any MTAs that actually send across the Internet.  Usually,
-   these are just the border MTAs as internal MTAs simply forward mail
-   to these MTAs for delivery.
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 34]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Mail receivers will generally want to perform the authorization check
-   at the border MTAs, specifically including all secondary MXs.  This
-   allows mail that fails to be rejected during the SMTP session rather
-   than bounced.  Internal MTAs then do not perform the authorization
-   test.  To perform the authorization test other than at the border,
-   the host that first transferred the message to the organization must
-   be determined, which can be difficult to extract from the message
-   header.  Testing other than at the border is not recommended.
-
-10.  Security Considerations
-
-10.1.  Processing Limits
-
-   As with most aspects of E-Mail, there are a number of ways that
-   malicious parties could use the protocol as an avenue for a
-   Denial-of-Service (DoS) attack.  The processing limits outlined here
-   are designed to prevent attacks such as the following:
-
-   o  A malicious party could create an SPF record with many references
-      to a victim's domain and send many E-Mails to different SPF
-      clients; those SPF clients would then create a DoS attack.  In
-      effect, the SPF clients are being used to amplify the attacker's
-      bandwidth by using fewer bytes in the SMTP session than are used
-      by the DNS queries.  Using SPF clients also allows the attacker to
-      hide the true source of the attack.
-
-   o  Whereas implementations of check_host() are supposed to limit the
-      number of DNS lookups, malicious domains could publish records
-      that exceed these limits in an attempt to waste computation effort
-      at their targets when they send them mail.  Malicious domains
-      could also design SPF records that cause particular
-      implementations to use excessive memory or CPU usage, or to
-      trigger bugs.
-
-   o  Malicious parties could send a large volume of mail purporting to
-      come from the intended target to a wide variety of legitimate mail
-      hosts.  These legitimate machines would then present a DNS load on
-      the target as they fetched the relevant records.
-
-   Of these, the case of a third party referenced in the SPF record is
-   the easiest for a DoS attack to effectively exploit.  As a result,
-   limits that may seem reasonable for an individual mail server can
-   still allow an unreasonable amount of bandwidth amplification.
-   Therefore, the processing limits need to be quite low.
-
-   SPF implementations MUST limit the number of mechanisms and modifiers
-   that do DNS lookups to at most 10 per SPF check, including any
-   lookups caused by the use of the "include" mechanism or the
-
-
-
-Wong & Schlitt                Experimental                     [Page 35]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   "redirect" modifier.  If this number is exceeded during a check, a
-   PermError MUST be returned.  The "include", "a", "mx", "ptr", and
-   "exists" mechanisms as well as the "redirect" modifier do count
-   against this limit.  The "all", "ip4", and "ip6" mechanisms do not
-   require DNS lookups and therefore do not count against this limit.
-   The "exp" modifier does not count against this limit because the DNS
-   lookup to fetch the explanation string occurs after the SPF record
-   has been evaluated.
-
-   When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
-   there MUST be a limit of no more than 10 MX or PTR RRs looked up and
-   checked.
-
-   SPF implementations SHOULD limit the total amount of data obtained
-   from the DNS queries.  For example, when DNS over TCP or EDNS0 are
-   available, there may need to be an explicit limit to how much data
-   will be accepted to prevent excessive bandwidth usage or memory usage
-   and DoS attacks.
-
-   MTAs or other processors MAY also impose a limit on the maximum
-   amount of elapsed time to evaluate check_host().  Such a limit SHOULD
-   allow at least 20 seconds.  If such a limit is exceeded, the result
-   of authorization SHOULD be "TempError".
-
-   Domains publishing records SHOULD try to keep the number of "include"
-   mechanisms and chained "redirect" modifiers to a minimum.  Domains
-   SHOULD also try to minimize the amount of other DNS information
-   needed to evaluate a record.  This can be done by choosing directives
-   that require less DNS information and placing lower-cost mechanisms
-   earlier in the SPF record.
-
-   For example, consider a domain set up as follows:
-
-   example.com.      IN MX   10 mx.example.com.
-   mx.example.com.   IN A    192.0.2.1
-   a.example.com.    IN TXT  "v=spf1 mx:example.com -all"
-   b.example.com.    IN TXT  "v=spf1 a:mx.example.com -all"
-   c.example.com.    IN TXT  "v=spf1 ip4:192.0.2.1 -all"
-
-   Evaluating check_host() for the domain "a.example.com" requires the
-   MX records for "example.com", and then the A records for the listed
-   hosts.  Evaluating for "b.example.com" requires only the A records.
-   Evaluating for "c.example.com" requires none.
-
-   However, there may be administrative considerations: using "a" over
-   "ip4" allows hosts to be renumbered easily.  Using "mx" over "a"
-   allows the set of mail hosts to be changed easily.
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 36]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-10.2.  SPF-Authorized E-Mail May Contain Other False Identities
-
-   The "MAIL FROM" and "HELO" identity authorizations must not be
-   construed to provide more assurance than they do.  It is entirely
-   possible for a malicious sender to inject a message using his own
-   domain in the identities used by SPF, to have that domain's SPF
-   record authorize the sending host, and yet the message can easily
-   list other identities in its header.  Unless the user or the MUA
-   takes care to note that the authorized identity does not match the
-   other more commonly-presented identities (such as the From:  header
-   field), the user may be lulled into a false sense of security.
-
-10.3.  Spoofed DNS and IP Data
-
-   There are two aspects of this protocol that malicious parties could
-   exploit to undermine the validity of the check_host() function:
-
-   o  The evaluation of check_host() relies heavily on DNS.  A malicious
-      attacker could attack the DNS infrastructure and cause
-      check_host() to see spoofed DNS data, and then return incorrect
-      results.  This could include returning "Pass" for an <ip> value
-      where the actual domain's record would evaluate to "Fail".  See
-      [RFC3833] for a description of DNS weaknesses.
-
-   o  The client IP address, <ip>, is assumed to be correct.  A
-      malicious attacker could spoof TCP sequence numbers to make mail
-      appear to come from a permitted host for a domain that the
-      attacker is impersonating.
-
-10.4.  Cross-User Forgery
-
-   By definition, SPF policies just map domain names to sets of
-   authorized MTAs, not whole E-Mail addresses to sets of authorized
-   users.  Although the "l" macro (Section 8) provides a limited way to
-   define individual sets of authorized MTAs for specific E-Mail
-   addresses, it is generally impossible to verify, through SPF, the use
-   of specific E-Mail addresses by individual users of the same MTA.
-
-   It is up to mail services and their MTAs to directly prevent
-   cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be
-   restricted to using only those E-Mail addresses that are actually
-   under their control (see [RFC4409], Section 6.1).  Another means to
-   verify the identity of individual users is message cryptography such
-   as PGP ([RFC2440]) or S/MIME ([RFC3851]).
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 37]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-10.5.  Untrusted Information Sources
-
-   SPF uses information supplied by third parties, such as the "HELO"
-   domain name, the "MAIL FROM" address, and SPF records.  This
-   information is then passed to the receiver in the Received-SPF: trace
-   fields and possibly returned to the client MTA in the form of an SMTP
-   rejection message.  This information must be checked for invalid
-   characters and excessively long lines.
-
-   When the authorization check fails, an explanation string may be
-   included in the reject response.  Both the sender and the rejecting
-   receiver need to be aware that the explanation was determined by the
-   publisher of the SPF record checked and, in general, not the
-   receiver.  The explanation may contain malicious URLs, or it may be
-   offensive or misleading.
-
-   This is probably less of a concern than it may initially seem since
-   such messages are returned to the sender, and the explanation strings
-   come from the sender policy published by the domain in the identity
-   claimed by that very sender.  As long as the DSN is not redirected to
-   someone other than the actual sender, the only people who see
-   malicious explanation strings are people whose messages claim to be
-   from domains that publish such strings in their SPF records.  In
-   practice, DSNs can be misdirected, such as when an MTA accepts an
-   E-Mail and then later generates a DSN to a forged address, or when an
-   E-Mail forwarder does not direct the DSN back to the original sender.
-
-10.6.  Privacy Exposure
-
-   Checking SPF records causes DNS queries to be sent to the domain
-   owner.  These DNS queries, especially if they are caused by the
-   "exists" mechanism, can contain information about who is sending
-   E-Mail and likely to which MTA the E-Mail is being sent.  This can
-   introduce some privacy concerns, which may be more or less of an
-   issue depending on local laws and the relationship between the domain
-   owner and the person sending the E-Mail.
-
-11.  Contributors and Acknowledgements
-
-   This document is largely based on the work of Meng Weng Wong and Mark
-   Lentczner.  Although, as this section acknowledges, many people have
-   contributed to this document, a very large portion of the writing and
-   editing are due to Meng and Mark.
-
-   This design owes a debt of parentage to [RMX] by Hadmut Danisch and
-   to [DMP] by Gordon Fecyk.  The idea of using a DNS record to check
-   the legitimacy of an E-Mail address traces its ancestry further back
-   through messages on the namedroppers mailing list by Paul Vixie
-
-
-
-Wong & Schlitt                Experimental                     [Page 38]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   [Vixie] (based on suggestion by Jim Miller) and by David Green
-   [Green].
-
-   Philip Gladstone contributed the concept of macros to the
-   specification, multiplying the expressiveness of the language and
-   making per-user and per-IP lookups possible.
-
-   The authors would also like to thank the literally hundreds of
-   individuals who have participated in the development of this design.
-   They are far too numerous to name, but they include the following:
-
-      The folks on the spf-discuss mailing list.
-      The folks on the SPAM-L mailing list.
-      The folks on the IRTF ASRG mailing list.
-      The folks on the IETF MARID mailing list.
-      The folks on #perl.
-
-12.  IANA Considerations
-
-12.1.  The SPF DNS Record Type
-
-   The IANA has assigned a new Resource Record Type and Qtype from the
-   DNS Parameters Registry for the SPF RR type with code 99.
-
-12.2.  The Received-SPF Mail Header Field
-
-   Per [RFC3864], the "Received-SPF:" header field is added to the IANA
-   Permanent Message Header Field Registry.  The following is the
-   registration template:
-
-      Header field name: Received-SPF
-      Applicable protocol: mail ([RFC2822])
-      Status: Experimental
-      Author/Change controller: IETF
-      Specification document(s): RFC 4408
-      Related information:
-      Requesting SPF Council review of any proposed changes and
-      additions to this field are recommended.  For information about
-      the SPF Council see http://www.openspf.org/Council
-
-13.  References
-
-13.1.  Normative References
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 39]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
-              and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
-              April 2001.
-
-   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
-              2001.
-
-   [RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
-              for Delivery Status Notifications", RFC 3464, January
-              2003.
-
-   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
-              (IPv6) Addressing Architecture", RFC 3513, April 2003.
-
-   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
-              Procedures for Message Header Fields", BCP 90, RFC 3864,
-              September 2004.
-
-   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-              Resource Identifier (URI): Generic Syntax", STD 66, RFC
-              3986, January 2005.
-
-   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
-              Specifications: ABNF", RFC 4234, October 2005.
-
-   [US-ASCII] American National Standards Institute (formerly United
-              States of America Standards Institute), "USA Code for
-              Information Interchange, X3.4", 1968.
-
-   ANSI X3.4-1968 has been replaced by newer versions with slight
-              modifications, but the 1968 version remains definitive for
-              the Internet.
-
-13.2  Informative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1983]  Malkin, G., "Internet Users' Glossary", RFC 1983, August
-              1996.
-
-   [RFC2440]  Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
-              "OpenPGP Message Format", RFC 2440, November 1998.
-
-
-
-Wong & Schlitt                Experimental                     [Page 40]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   [RFC2554]  Myers, J., "SMTP Service Extension for Authentication",
-              RFC 2554, March 1999.
-
-   [RFC3696]  Klensin, J., "Application Techniques for Checking and
-              Transformation of Names", RFC 3696, February 2004.
-
-   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
-              Name System (DNS)", RFC 3833, August 2004.
-
-   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
-              Extensions (S/MIME) Version 3.1 Message Specification",
-              RFC 3851, July 2004.
-
-   [RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
-              RFC 4409, April 2006.
-
-   [RMX]      Danish, H., "The RMX DNS RR Type for light weight sender
-              authentication", Work In Progress
-
-   [DMP]      Fecyk, G., "Designated Mailers Protocol", Work In Progress
-
-   [Vixie]    Vixie, P., "Repudiating MAIL FROM", 2002.
-
-   [Green]    Green, D., "Domain-Authorized SMTP Mail", 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 41]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-Appendix A.  Collected ABNF
-
-   This section is normative and any discrepancies with the ABNF
-   fragments in the preceding text are to be resolved in favor of this
-   grammar.
-
-   See [RFC4234] for ABNF notation.  Please note that as per this ABNF
-   definition, literal text strings (those in quotes) are case-
-   insensitive.  Hence, "mx" matches "mx", "MX", "mX", and "Mx".
-
-   record           = version terms *SP
-   version          = "v=spf1"
-
-   terms            = *( 1*SP ( directive / modifier ) )
-
-   directive        = [ qualifier ] mechanism
-   qualifier        = "+" / "-" / "?" / "~"
-   mechanism        = ( all / include
-                      / A / MX / PTR / IP4 / IP6 / exists )
-
-   all              = "all"
-   include          = "include"  ":" domain-spec
-   A                = "a"      [ ":" domain-spec ] [ dual-cidr-length ]
-   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
-   PTR              = "ptr"    [ ":" domain-spec ]
-   IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
-   IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
-   exists           = "exists"   ":" domain-spec
-
-   modifier         = redirect / explanation / unknown-modifier
-   redirect         = "redirect" "=" domain-spec
-   explanation      = "exp" "=" domain-spec
-   unknown-modifier = name "=" macro-string
-
-   ip4-cidr-length  = "/" 1*DIGIT
-   ip6-cidr-length  = "/" 1*DIGIT
-   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
-
-   ip4-network      = qnum "." qnum "." qnum "." qnum
-   qnum             = DIGIT                 ; 0-9
-                      / %x31-39 DIGIT       ; 10-99
-                      / "1" 2DIGIT          ; 100-199
-                      / "2" %x30-34 DIGIT   ; 200-249
-                      / "25" %x30-35        ; 250-255
-             ; conventional dotted quad notation.  e.g., 192.0.2.0
-   ip6-network      = <as per [RFC 3513], section 2.2>
-             ; e.g., 2001:DB8::CD30
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 42]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   domain-spec      = macro-string domain-end
-   domain-end       = ( "." toplabel [ "." ] ) / macro-expand
-   toplabel         = ( *alphanum ALPHA *alphanum ) /
-                      ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
-                      ; LDH rule plus additional TLD restrictions
-                      ; (see [RFC3696], Section 2)
-
-   alphanum         = ALPHA / DIGIT
-
-   explain-string   = *( macro-string / SP )
-
-   macro-string     = *( macro-expand / macro-literal )
-   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
-                      / "%%" / "%_" / "%-"
-   macro-literal    = %x21-24 / %x26-7E
-                      ; visible characters except "%"
-   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
-                      "c" / "r" / "t"
-   transformers     = *DIGIT [ "r" ]
-   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="
-
-   name             = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
-
-   header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
-                      [ key-value-list ] CRLF
-
-   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
-                      "None" / "TempError" / "PermError"
-
-   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
-                      [";"]
-
-   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )
-
-   key              = "client-ip" / "envelope-from" / "helo" /
-                      "problem" / "receiver" / "identity" /
-                       mechanism / "x-" name / name
-
-   identity         = "mailfrom"   ; for the "MAIL FROM" identity
-                      / "helo"     ; for the "HELO" identity
-                      / name       ; other identities
-
-   dot-atom         = <unquoted word as per [RFC2822]>
-   quoted-string    = <quoted string as per [RFC2822]>
-   comment          = <comment string as per [RFC2822]>
-   CFWS             = <comment or folding white space as per [RFC2822]>
-   FWS              = <folding white space as per [RFC2822]>
-   CRLF             = <standard end-of-line token as per [RFC2822]>
-
-
-
-Wong & Schlitt                Experimental                     [Page 43]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-Appendix B.  Extended Examples
-
-   These examples are based on the following DNS setup:
-
-   ; A domain with two mail servers, two hosts
-   ; and two servers at the domain name
-   $ORIGIN example.com.
-   @           MX  10 mail-a
-               MX  20 mail-b
-               A   192.0.2.10
-               A   192.0.2.11
-   amy         A   192.0.2.65
-   bob         A   192.0.2.66
-   mail-a      A   192.0.2.129
-   mail-b      A   192.0.2.130
-   www         CNAME example.com.
-
-   ; A related domain
-   $ORIGIN example.org.
-   @           MX  10 mail-c
-   mail-c      A   192.0.2.140
-
-   ; The reverse IP for those addresses
-   $ORIGIN 2.0.192.in-addr.arpa.
-   10          PTR example.com.
-   11          PTR example.com.
-   65          PTR amy.example.com.
-   66          PTR bob.example.com.
-   129         PTR mail-a.example.com.
-   130         PTR mail-b.example.com.
-   140         PTR mail-c.example.org.
-
-   ; A rogue reverse IP domain that claims to be
-   ; something it's not
-   $ORIGIN 0.0.10.in-addr.arpa.
-   4           PTR bob.example.com.
-
-B.1.  Simple Examples
-
-   These examples show various possible published records for
-   example.com and which values if <ip> would cause check_host() to
-   return "Pass".  Note that <domain> is "example.com".
-
-   v=spf1 +all
-      -- any <ip> passes
-
-   v=spf1 a -all
-      -- hosts 192.0.2.10 and 192.0.2.11 pass
-
-
-
-Wong & Schlitt                Experimental                     [Page 44]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   v=spf1 a:example.org -all
-      -- no sending hosts pass since example.org has no A records
-
-   v=spf1 mx -all
-      -- sending hosts 192.0.2.129 and 192.0.2.130 pass
-
-   v=spf1 mx:example.org -all
-      -- sending host 192.0.2.140 passes
-
-   v=spf1 mx mx:example.org -all
-      -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass
-
-   v=spf1 mx/30 mx:example.org/30 -all
-      -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes
-
-   v=spf1 ptr -all
-      -- sending host 192.0.2.65 passes (reverse DNS is valid and is in
-         example.com)
-      -- sending host 192.0.2.140 fails (reverse DNS is valid, but not
-         in example.com)
-      -- sending host 10.0.0.4 fails (reverse IP is not valid)
-
-   v=spf1 ip4:192.0.2.128/28 -all
-      -- sending host 192.0.2.65 fails
-      -- sending host 192.0.2.129 passes
-
-B.2.  Multiple Domain Example
-
-   These examples show the effect of related records:
-
-      example.org: "v=spf1 include:example.com include:example.net -all"
-
-   This record would be used if mail from example.org actually came
-   through servers at example.com and example.net.  Example.org's
-   designated servers are the union of example.com's and example.net's
-   designated servers.
-
-      la.example.org: "v=spf1 redirect=example.org"
-      ny.example.org: "v=spf1 redirect=example.org"
-      sf.example.org: "v=spf1 redirect=example.org"
-
-   These records allow a set of domains that all use the same mail
-   system to make use of that mail system's record.  In this way, only
-   the mail system's record needs to be updated when the mail setup
-   changes.  These domains' records never have to change.
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 45]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-B.3.  DNSBL Style Example
-
-   Imagine that, in addition to the domain records listed above, there
-   are these:
-
-   $ORIGIN _spf.example.com.  mary.mobile-users                   A
-   127.0.0.2 fred.mobile-users                   A 127.0.0.2
-   15.15.168.192.joel.remote-users     A 127.0.0.2
-   16.15.168.192.joel.remote-users     A 127.0.0.2
-
-   The following records describe users at example.com who mail from
-   arbitrary servers, or who mail from personal servers.
-
-   example.com:
-
-   v=spf1 mx
-          include:mobile-users._spf.%{d}
-          include:remote-users._spf.%{d}
-          -all
-
-   mobile-users._spf.example.com:
-
-   v=spf1 exists:%{l1r+}.%{d}
-
-   remote-users._spf.example.com:
-
-   v=spf1 exists:%{ir}.%{l1r+}.%{d}
-
-B.4.  Multiple Requirements Example
-
-   Say that your sender policy requires both that the IP address is
-   within a certain range and that the reverse DNS for the IP matches.
-   This can be done several ways, including the following:
-
-   example.com.           SPF  ( "v=spf1 "
-                                 "-include:ip4._spf.%{d} "
-                                 "-include:ptr._spf.%{d} "
-                                 "+all" )
-   ip4._spf.example.com.  SPF  "v=spf1 -ip4:192.0.2.0/24 +all"
-   ptr._spf.example.com.  SPF  "v=spf1 -ptr +all"
-
-   This example shows how the "-include" mechanism can be useful, how an
-   SPF record that ends in "+all" can be very restrictive, and the use
-   of De Morgan's Law.
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 46]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-Authors' Addresses
-
-   Meng Weng Wong
-   Singapore
-
-   EMail: mengwong+spf@pobox.com
-
-
-   Wayne Schlitt
-   4615 Meredeth #9
-   Lincoln Nebraska, NE  68506
-   United States of America
-
-   EMail: wayne@schlitt.net
-   URI:   http://www.schlitt.net/spf/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 47]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 48]
-
diff --git a/doc/rfc/rfc4431.txt b/doc/rfc/rfc4431.txt
deleted file mode 100644
index 8b388722..00000000
--- a/doc/rfc/rfc4431.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Andrews
-Request for Comments: 4431                   Internet Systems Consortium
-Category: Informational                                        S. Weiler
-                                                            SPARTA, Inc.
-                                                           February 2006
-
-
-       The DNSSEC Lookaside Validation (DLV) DNS Resource Record
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document defines a new DNS resource record, called the DNSSEC
-   Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors
-   outside of the DNS delegation chain.
-
-1.  Introduction
-
-   DNSSEC [1] [2] [3] authenticates DNS data by building public-key
-   signature chains along the DNS delegation chain from a trust anchor,
-   ideally a trust anchor for the DNS root.
-
-   This document defines a new resource record for publishing such trust
-   anchors outside of the DNS's normal delegation chain.  Use of these
-   records by DNSSEC validators is outside the scope of this document,
-   but it is expected that these records will help resolvers validate
-   DNSSEC-signed data from zones whose ancestors either aren't signed or
-   refuse to publish delegation signer (DS) records for their children.
-
-2.  DLV Resource Record
-
-   The DLV resource record has exactly the same wire and presentation
-   formats as the DS resource record, defined in RFC 4034, Section 5.
-   It uses the same IANA-assigned values in the algorithm and digest
-   type fields as the DS record.  (Those IANA registries are known as
-   the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
-   Numbers" registries.)
-
-
-
-
-
-Andrews & Weiler             Informational                      [Page 1]
-
-RFC 4431                  DLV Resource Record              February 2006
-
-
-   The DLV record is a normal DNS record type without any special
-   processing requirements.  In particular, the DLV record does not
-   inherit any of the special processing or handling requirements of the
-   DS record type (described in Section 3.1.4.1 of RFC 4035).  Unlike
-   the DS record, the DLV record may not appear on the parent's side of
-   a zone cut.  A DLV record may, however, appear at the apex of a zone.
-
-3.  Security Considerations
-
-   For authoritative servers and resolvers that do not attempt to use
-   DLV RRs as part of DNSSEC validation, there are no particular
-   security concerns -- DLV RRs are just like any other DNS data.
-
-   Software using DLV RRs as part of DNSSEC validation will almost
-   certainly want to impose constraints on their use, but those
-   constraints are best left to be described by the documents that more
-   fully describe the particulars of how the records are used.  At a
-   minimum, it would be unwise to use the records without some sort of
-   cryptographic authentication.  More likely than not, DNSSEC itself
-   will be used to authenticate the DLV RRs.  Depending on how a DLV RR
-   is used, failure to properly authenticate it could lead to
-   significant additional security problems including failure to detect
-   spoofed DNS data.
-
-   RFC 4034, Section 8, describes security considerations specific to
-   the DS RR.  Those considerations are equally applicable to DLV RRs.
-   Of particular note, the key tag field is used to help select DNSKEY
-   RRs efficiently, but it does not uniquely identify a single DNSKEY
-   RR.  It is possible for two distinct DNSKEY RRs to have the same
-   owner name, the same algorithm type, and the same key tag.  An
-   implementation that uses only the key tag to select a DNSKEY RR might
-   select the wrong public key in some circumstances.
-
-   For further discussion of the security implications of DNSSEC, see
-   RFC 4033, RFC 4034, and RFC 4035.
-
-4.  IANA Considerations
-
-   IANA has assigned DNS type code 32769 to the DLV resource record from
-   the Specification Required portion of the DNS Resource Record Type
-   registry, as defined in [4].
-
-   The DLV resource record reuses the same algorithm and digest type
-   registries already used for the DS resource record, currently known
-   as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
-   Numbers" registries.
-
-
-
-
-
-Andrews & Weiler             Informational                      [Page 2]
-
-RFC 4431                  DLV Resource Record              February 2006
-
-
-5.  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [4]  Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name
-        System (DNS) IANA Considerations", BCP 42, RFC 2929,
-        September 2000.
-
-Authors' Addresses
-
-   Mark Andrews
-   Internet Systems Consortium
-   950 Charter St.
-   Redwood City, CA  94063
-   US
-
-   EMail: Mark_Andrews@isc.org
-
-
-   Samuel Weiler
-   SPARTA, Inc.
-   7075 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   EMail: weiler@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews & Weiler             Informational                      [Page 3]
-
-RFC 4431                  DLV Resource Record              February 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Andrews & Weiler             Informational                      [Page 4]
-
diff --git a/doc/rfc/rfc4470.txt b/doc/rfc/rfc4470.txt
deleted file mode 100644
index ac12d65c..00000000
--- a/doc/rfc/rfc4470.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          S. Weiler
-Request for Comments: 4470                                  SPARTA, Inc.
-Updates: 4035, 4034                                             J. Ihren
-Category: Standards Track                                  Autonomica AB
-                                                              April 2006
-
-
-       Minimally Covering NSEC Records and DNSSEC On-line Signing
-
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes how to construct DNSSEC NSEC resource records
-   that cover a smaller range of names than called for by RFC 4034.  By
-   generating and signing these records on demand, authoritative name
-   servers can effectively stop the disclosure of zone contents
-   otherwise made possible by walking the chain of NSEC records in a
-   signed zone.
-
-Table of Contents
-
-   1. Introduction ....................................................1
-   2. Applicability of This Technique .................................2
-   3. Minimally Covering NSEC Records .................................2
-   4. Better Epsilon Functions ........................................4
-   5. Security Considerations .........................................5
-   6. Acknowledgements ................................................6
-   7. Normative References ............................................6
-
-1.  Introduction
-
-   With DNSSEC [1], an NSEC record lists the next instantiated name in
-   its zone, proving that no names exist in the "span" between the
-   NSEC's owner name and the name in the "next name" field.  In this
-   document, an NSEC record is said to "cover" the names between its
-   owner name and next name.
-
-
-
-Weiler & Ihren              Standards Track                     [Page 1]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-   Through repeated queries that return NSEC records, it is possible to
-   retrieve all of the names in the zone, a process commonly called
-   "walking" the zone.  Some zone owners have policies forbidding zone
-   transfers by arbitrary clients; this side effect of the NSEC
-   architecture subverts those policies.
-
-   This document presents a way to prevent zone walking by constructing
-   NSEC records that cover fewer names.  These records can make zone
-   walking take approximately as many queries as simply asking for all
-   possible names in a zone, making zone walking impractical.  Some of
-   these records must be created and signed on demand, which requires
-   on-line private keys.  Anyone contemplating use of this technique is
-   strongly encouraged to review the discussion of the risks of on-line
-   signing in Section 5.
-
-1.2.  Keywords
-
-   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [4].
-
-2.  Applicability of This Technique
-
-   The technique presented here may be useful to a zone owner that wants
-   to use DNSSEC, is concerned about exposure of its zone contents via
-   zone walking, and is willing to bear the costs of on-line signing.
-
-   As discussed in Section 5, on-line signing has several security
-   risks, including an increased likelihood of private keys being
-   disclosed and an increased risk of denial of service attack.  Anyone
-   contemplating use of this technique is strongly encouraged to review
-   the discussion of the risks of on-line signing in Section 5.
-
-   Furthermore, at the time this document was published, the DNSEXT
-   working group was actively working on a mechanism to prevent zone
-   walking that does not require on-line signing (tentatively called
-   NSEC3).  The new mechanism is likely to expose slightly more
-   information about the zone than this technique (e.g., the number of
-   instantiated names), but it may be preferable to this technique.
-
-3.  Minimally Covering NSEC Records
-
-   This mechanism involves changes to NSEC records for instantiated
-   names, which can still be generated and signed in advance, as well as
-   the on-demand generation and signing of new NSEC records whenever a
-   name must be proven not to exist.
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 2]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-   In the "next name" field of instantiated names' NSEC records, rather
-   than list the next instantiated name in the zone, list any name that
-   falls lexically after the NSEC's owner name and before the next
-   instantiated name in the zone, according to the ordering function in
-   RFC 4034 [2] Section 6.1.  This relaxes the requirement in Section
-   4.1.1 of RFC 4034 that the "next name" field contains the next owner
-   name in the zone.  This change is expected to be fully compatible
-   with all existing DNSSEC validators.  These NSEC records are returned
-   whenever proving something specifically about the owner name (e.g.,
-   that no resource records of a given type appear at that name).
-
-   Whenever an NSEC record is needed to prove the non-existence of a
-   name, a new NSEC record is dynamically produced and signed.  The new
-   NSEC record has an owner name lexically before the QNAME but
-   lexically following any existing name and a "next name" lexically
-   following the QNAME but before any existing name.
-
-   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
-   bits set and SHOULD NOT have any other bits set.  This relaxes the
-   requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
-   names that did not exist before the zone was signed.
-
-   The functions to generate the lexically following and proceeding
-   names need not be perfect or consistent, but the generated NSEC
-   records must not cover any existing names.  Furthermore, this
-   technique works best when the generated NSEC records cover as few
-   names as possible.  In this document, the functions that generate the
-   nearby names are called "epsilon" functions, a reference to the
-   mathematical convention of using the greek letter epsilon to
-   represent small deviations.
-
-   An NSEC record denying the existence of a wildcard may be generated
-   in the same way.  Since the NSEC record covering a non-existent
-   wildcard is likely to be used in response to many queries,
-   authoritative name servers using the techniques described here may
-   want to pregenerate or cache that record and its corresponding RRSIG.
-
-   For example, a query for an A record at the non-instantiated name
-   example.com might produce the following two NSEC records, the first
-   denying the existence of the name example.com and the second denying
-   the existence of a wildcard:
-
-          exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
-
-          \).com 3600 IN NSEC +.com ( RRSIG NSEC )
-
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 3]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-   Before answering a query with these records, an authoritative server
-   must test for the existence of names between these endpoints.  If the
-   generated NSEC would cover existing names (e.g., exampldd.com or
-   *bizarre.example.com), a better epsilon function may be used or the
-   covered name closest to the QNAME could be used as the NSEC owner
-   name or next name, as appropriate.  If an existing name is used as
-   the NSEC owner name, that name's real NSEC record MUST be returned.
-   Using the same example, assuming an exampldd.com delegation exists,
-   this record might be returned from the parent:
-
-          exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
-
-   Like every authoritative record in the zone, each generated NSEC
-   record MUST have corresponding RRSIGs generated using each algorithm
-   (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
-   described in RFC 4035 [3] Section 2.2.  To minimize the number of
-   signatures that must be generated, a zone may wish to limit the
-   number of algorithms in its DNSKEY RRset.
-
-4.  Better Epsilon Functions
-
-   Section 6.1 of RFC 4034 defines a strict ordering of DNS names.
-   Working backward from that definition, it should be possible to
-   define epsilon functions that generate the immediately following and
-   preceding names, respectively.  This document does not define such
-   functions.  Instead, this section presents functions that come
-   reasonably close to the perfect ones.  As described above, an
-   authoritative server should still ensure than no generated NSEC
-   covers any existing name.
-
-   To increment a name, add a leading label with a single null (zero-
-   value) octet.
-
-   To decrement a name, decrement the last character of the leftmost
-   label, then fill that label to a length of 63 octets with octets of
-   value 255.  To decrement a null (zero-value) octet, remove the octet
-   -- if an empty label is left, remove the label.  Defining this
-   function numerically: fill the leftmost label to its maximum length
-   with zeros (numeric, not ASCII zeros) and subtract one.
-
-   In response to a query for the non-existent name foo.example.com,
-   these functions produce NSEC records of the following:
-
-
-
-
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 4]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-     fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
-
-     \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
-
-   The first of these NSEC RRs proves that no exact match for
-   foo.example.com exists, and the second proves that there is no
-   wildcard in example.com.
-
-   Both of these functions are imperfect: they do not take into account
-   constraints on number of labels in a name nor total length of a name.
-   As noted in the previous section, though, this technique does not
-   depend on the use of perfect epsilon functions: it is sufficient to
-   test whether any instantiated names fall into the span covered by the
-   generated NSEC and, if so, substitute those instantiated owner names
-   for the NSEC owner name or next name, as appropriate.
-
-5.  Security Considerations
-
-   This approach requires on-demand generation of RRSIG records.  This
-   creates several new vulnerabilities.
-
-   First, on-demand signing requires that a zone's authoritative servers
-   have access to its private keys.  Storing private keys on well-known
-   Internet-accessible servers may make them more vulnerable to
-   unintended disclosure.
-
-   Second, since generation of digital signatures tends to be
-   computationally demanding, the requirement for on-demand signing
-   makes authoritative servers vulnerable to a denial of service attack.
-
-   Last, if the epsilon functions are predictable, on-demand signing may
-   enable a chosen-plaintext attack on a zone's private keys.  Zones
-   using this approach should attempt to use cryptographic algorithms
-   that are resistant to chosen-plaintext attacks.  It is worth noting
-   that although DNSSEC has a "mandatory to implement" algorithm, that
-   is a requirement on resolvers and validators -- there is no
-   requirement that a zone be signed with any given algorithm.
-
-   The success of using minimally covering NSEC records to prevent zone
-   walking depends greatly on the quality of the epsilon functions
-
-
-
-Weiler & Ihren              Standards Track                     [Page 5]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-   chosen.  An increment function that chooses a name obviously derived
-   from the next instantiated name may be easily reverse engineered,
-   destroying the value of this technique.  An increment function that
-   always returns a name close to the next instantiated name is likewise
-   a poor choice.  Good choices of epsilon functions are the ones that
-   produce the immediately following and preceding names, respectively,
-   though zone administrators may wish to use less perfect functions
-   that return more human-friendly names than the functions described in
-   Section 4 above.
-
-   Another obvious but misguided concern is the danger from synthesized
-   NSEC records being replayed.  It is possible for an attacker to
-   replay an old but still validly signed NSEC record after a new name
-   has been added in the span covered by that NSEC, incorrectly proving
-   that there is no record at that name.  This danger exists with DNSSEC
-   as defined in [3].  The techniques described here actually decrease
-   the danger, since the span covered by any NSEC record is smaller than
-   before.  Choosing better epsilon functions will further reduce this
-   danger.
-
-6.  Acknowledgements
-
-   Many individuals contributed to this design.  They include, in
-   addition to the authors of this document, Olaf Kolkman, Ed Lewis,
-   Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
-   Jakob Schlyter, Bill Manning, and Joao Damas.
-
-   In addition, the editors would like to thank Ed Lewis, Scott Rose,
-   and David Blacka for their careful review of the document.
-
-7.  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033, March
-        2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions", RFC
-        4035, March 2005.
-
-   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 6]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-Authors' Addresses
-
-   Samuel Weiler
-   SPARTA, Inc.
-   7075 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   EMail: weiler@tislabs.com
-
-
-   Johan Ihren
-   Autonomica AB
-   Bellmansgatan 30
-   Stockholm  SE-118 47
-   Sweden
-
-   EMail: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 7]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 8]
-
diff --git a/doc/rfc/rfc4471.txt b/doc/rfc/rfc4471.txt
deleted file mode 100644
index eb338e6b..00000000
--- a/doc/rfc/rfc4471.txt
+++ /dev/null
@@ -1,1291 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          G. Sisson
-Request for Comments: 4471                                     B. Laurie
-Category: Experimental                                           Nominet
-                                                          September 2006
-
-
-            Derivation of DNS Name Predecessor and Successor
-
-
-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).
-
-Abstract
-
-   This document describes two methods for deriving the canonically-
-   ordered predecessor and successor of a DNS name.  These methods may
-   be used for dynamic NSEC resource record synthesis, enabling
-   security-aware name servers to provide authenticated denial of
-   existence without disclosing other owner names in a DNSSEC secured
-   zone.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Notational Conventions ..........................................3
-   3. Derivations .....................................................3
-      3.1. Absolute Method ............................................3
-           3.1.1. Derivation of DNS Name Predecessor ..................3
-           3.1.2. Derivation of DNS Name Successor ....................4
-      3.2. Modified Method ............................................4
-           3.2.1. Derivation of DNS Name Predecessor ..................5
-           3.2.2. Derivation of DNS Name Successor ....................6
-   4. Notes ...........................................................6
-      4.1. Test for Existence .........................................6
-      4.2. Case Considerations ........................................7
-      4.3. Choice of Range ............................................7
-      4.4. Wild Card Considerations ...................................8
-      4.5. Possible Modifications .....................................8
-           4.5.1. Restriction of Effective Maximum DNS Name Length ....8
-           4.5.2. Use of Modified Method with Zones Containing
-
-
-
-Sisson & Laurie               Experimental                      [Page 1]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-                  SRV RRs .............................................8
-   5. Examples ........................................................9
-      5.1. Examples of Immediate Predecessors Using Absolute Method ..10
-      5.2. Examples of Immediate Successors Using Absolute Method ....14
-      5.3. Examples of Predecessors Using Modified Method ............19
-      5.4. Examples of Successors Using Modified Method ..............20
-   6. Security Considerations ........................................21
-   7. Acknowledgements ...............................................21
-   8. References .....................................................21
-      8.1. Normative References ......................................21
-      8.2. Informative References ....................................22
-
-1.  Introduction
-
-   One of the proposals for avoiding the exposure of zone information
-   during the deployment DNSSEC is dynamic NSEC resource record (RR)
-   synthesis.  This technique is described in [DNSSEC-TRANS] and
-   [RFC4470], and involves the generation of NSEC RRs that just span the
-   query name for non-existent owner names.  In order to do this, the
-   DNS names that would occur just prior to and just following a given
-   query name must be calculated in real time, as maintaining a list of
-   all possible owner names that might occur in a zone would be
-   impracticable.
-
-   Section 6.1 of [RFC4034] defines canonical DNS name order.  This
-   document does not amend or modify this definition.  However, the
-   derivation of immediate predecessor and successor, although trivial,
-   is non-obvious.  Accordingly, several methods are described here as
-   an aid to implementors and a reference to other interested parties.
-
-   This document describes two methods:
-
-   1.  An "absolute method", which returns the immediate predecessor or
-       successor of a domain name such that no valid DNS name could
-       exist between that DNS name and the predecessor or successor.
-
-   2.  A "modified method", which returns a predecessor and successor
-       that are more economical in size and computation.  This method is
-       restricted to use with zones consisting exclusively of owner
-       names that contain no more than one label more than the owner
-       name of the apex, where the longest possible owner name (i.e.,
-       one with a maximum length left-most label) would not exceed the
-       maximum DNS name length.  This is, however, the type of zone for
-       which the technique of online signing is most likely to be used.
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                      [Page 2]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-2.  Notational Conventions
-
-   The following notational conventions are used in this document for
-   economy of expression:
-
-   N: An unspecified DNS name.
-
-   P(N): Immediate predecessor to N (absolute method).
-
-   S(N): Immediate successor to N (absolute method).
-
-   P'(N): Predecessor to N (modified method).
-
-   S'(N): Successor to N (modified method).
-
-3.  Derivations
-
-   These derivations assume that all uppercase US-ASCII letters in N
-   have already been replaced by their corresponding lowercase
-   equivalents.  Unless otherwise specified, processing stops after the
-   first step in which a condition is met.
-
-   The derivations make reference to maximum label length and maximum
-   DNS name length; these are defined in Section 3.1 of [RFC1034] to be
-   63 and 255 octets, respectively.
-
-3.1.  Absolute Method
-
-3.1.1.  Derivation of DNS Name Predecessor
-
-   To derive P(N):
-
-   1.  If N is the same as the owner name of the zone apex, prepend N
-       repeatedly with labels of the maximum length possible consisting
-       of octets of the maximum sort value (e.g., 0xff) until N is the
-       maximum length possible; otherwise proceed to the next step.
-
-   2.  If the least significant (left-most) label of N consists of a
-       single octet of the minimum sort value (e.g., 0x00), remove that
-       label; otherwise proceed to the next step.
-
-   3.  If the least significant (right-most) octet in the least
-       significant (left-most) label of N is the minimum sort value,
-       remove the least significant octet and proceed to step 5.
-
-   4.  Decrement the value of the least significant (right-most) octet
-       of the least significant (left-most) label, skipping any values
-       that correspond to uppercase US-ASCII letters, and then append
-
-
-
-Sisson & Laurie               Experimental                      [Page 3]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-       the least significant (left-most) label with as many octets as
-       possible of the maximum sort value.  Proceed to the next step.
-
-   5.  Prepend N repeatedly with labels of as long a length as possible
-       consisting of octets of the maximum sort value until N is the
-       maximum length possible.
-
-3.1.2.  Derivation of DNS Name Successor
-
-   To derive S(N):
-
-   1.  If N is two or more octets shorter than the maximum DNS name
-       length, prepend N with a label containing a single octet of the
-       minimum sort value (e.g., 0x00); otherwise proceed to the next
-       step.
-
-   2.  If N is one octet shorter than the maximum DNS name length and
-       the least significant (left-most) label is one or more octets
-       shorter than the maximum label length, append an octet of the
-       minimum sort value to the least significant label; otherwise
-       proceed to the next step.
-
-   3.  Increment the value of the least significant (right-most) octet
-       in the least significant (left-most) label that is less than the
-       maximum sort value (e.g., 0xff), skipping any values that
-       correspond to uppercase US-ASCII letters, and then remove any
-       octets to the right of that one.  If all octets in the label are
-       the maximum sort value, then proceed to the next step.
-
-   4.  Remove the least significant (left-most) label.  Unless N is now
-       the same as the owner name of the zone apex (this will occur only
-       if N was the maximum possible name in canonical DNS name order,
-       and thus has wrapped to the owner name of zone apex), repeat
-       starting at step 2.
-
-3.2.  Modified Method
-
-   This method is for use with zones consisting only of single-label
-   owner names where an owner name consisting of label of maximum length
-   would not result in a DNS name that exceeded the maximum DNS name
-   length.  This method is computationally simpler and returns values
-   that are more economical in size than the absolute method.  It
-   differs from the absolute method detailed above in the following
-   ways:
-
-   1.  Step 1 of the derivation P(N) has been omitted as the existence
-       of the owner name of the zone apex never requires denial.
-
-
-
-
-Sisson & Laurie               Experimental                      [Page 4]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-   2.  A new step 1 has been introduced that removes unnecessary labels.
-
-   3.  Step 4 of the derivation P(N) has been omitted as it is only
-       necessary for zones containing owner names consisting of more
-       than one label.  This omission generally results in a significant
-       reduction of the length of derived predecessors.
-
-   4.  Step 1 of the derivation S(N) had been omitted as it is only
-       necessary for zones containing owner names consisting of more
-       than one label.  This omission results in a tiny reduction of the
-       length of derived successors, and maintains consistency with the
-       modification of step 4 of the derivation P(N) described above.
-
-   5.  Steps 2 and 4 of the derivation S(N) have been modified to
-       eliminate checks for maximum DNS name length, as it is an
-       assumption of this method that no DNS name in the zone can exceed
-       the maximum DNS name length.
-
-3.2.1.  Derivation of DNS Name Predecessor
-
-   To derive P'(N):
-
-   1.  If N is two or more labels longer than the owner name of the
-       apex, repeatedly remove the least significant (left-most) label
-       until N is only one label longer than the owner name of the apex;
-       otherwise proceed to the next step.
-
-   2.  If the least significant (left-most) label of N consists of a
-       single octet of the minimum sort value (e.g., 0x00), remove that
-       label; otherwise proceed to the next step.  (If this condition is
-       met, P'(N) is the owner name of the apex.)
-
-   3.  If the least significant (right-most) octet in the least
-       significant (left-most) label of N is the minimum sort value,
-       remove the least significant octet.
-
-   4.  Decrement the value of the least significant (right-most) octet,
-       skipping any values that correspond to uppercase US-ASCII
-       letters, and then append the label with as many octets as
-       possible of the maximum sort value.
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                      [Page 5]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-3.2.2.  Derivation of DNS Name Successor
-
-   To derive S'(N):
-
-   1.  If N is two or more labels longer than the owner name of the
-       apex, repeatedly remove the least significant (left-most) label
-       until N is only one label longer than the owner name of the apex.
-       Proceed to the next step.
-
-   2.  If the least significant (left-most) label of N is one or more
-       octets shorter than the maximum label length, append an octet of
-       the minimum sort value to the least significant label; otherwise
-       proceed to the next step.
-
-   3.  Increment the value of the least significant (right-most) octet
-       in the least significant (left-most) label that is less than the
-       maximum sort value (e.g., 0xff), skipping any values that
-       correspond to uppercase US-ASCII letters, and then remove any
-       octets to the right of that one.  If all octets in the label are
-       the maximum sort value, then proceed to the next step.
-
-   4.  Remove the least significant (left-most) label.  (This will occur
-       only if the least significant label is the maximum label length
-       and consists entirely of octets of the maximum sort value, and
-       thus has wrapped to the owner name of the zone apex.)
-
-4.  Notes
-
-4.1.  Test for Existence
-
-   Before using the result of P(N) or P'(N) as the owner name of an NSEC
-   RR in a DNS response, a name server should test to see whether the
-   name exists.  If it does, either a standard non-synthesised NSEC RR
-   should be used, or the synthesised NSEC RR should reflect the RRset
-   types that exist at the NSEC RR's owner name in the Type Bit Map
-   field as specified by Section 4.1.2 of [RFC4034].  Implementors will
-   likely find it simpler to use a non-synthesised NSEC RR.  For further
-   details, see Section 2 of [RFC4470].
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                      [Page 6]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-4.2.  Case Considerations
-
-   Section 3.5 of [RFC1034] specifies that "while upper and lower case
-   letters are allowed in names, no significance is attached to the
-   case".  Additionally, Section 6.1 of [RFC4034] states that when
-   determining canonical DNS name order, "uppercase US-ASCII letters are
-   treated as if they were lowercase US-ASCII letters".  Consequently,
-   values corresponding to US-ASCII uppercase letters must be skipped
-   when decrementing and incrementing octets in the derivations
-   described in Section 3.
-
-   The following pseudo-code is illustrative:
-
-   Decrement the value of an octet:
-
-      if (octet == '[')       // '[' is just after uppercase 'Z'
-              octet = '@';    // '@' is just prior to uppercase 'A'
-      else
-              octet--;
-
-   Increment the value of an octet:
-
-      if (octet == '@')       // '@' is just prior to uppercase 'A'
-              octet = '[';    // '[' is just after uppercase 'Z'
-      else
-              octet++;
-
-4.3.  Choice of Range
-
-   [RFC2181] makes the clarification that "any binary string whatever
-   can be used as the label of any resource record".  Consequently, the
-   minimum sort value may be set as 0x00 and the maximum sort value as
-   0xff, and the range of possible values will be any DNS name that
-   contains octets of any value other than those corresponding to
-   uppercase US-ASCII letters.
-
-   However, if all owner names in a zone are in the letter-digit-hyphen,
-   or LDH, format specified in [RFC1034], it may be desirable to
-   restrict the range of possible values to DNS names containing only
-   LDH values.  This has the effect of
-
-   1.  making the output of tools such as `dig' and `nslookup' less
-       subject to confusion,
-
-   2.  minimising the impact that NSEC RRs containing DNS names with
-       non-LDH values (or non-printable values) might have on faulty DNS
-       resolver implementations, and
-
-
-
-
-Sisson & Laurie               Experimental                      [Page 7]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-   3.  preventing the possibility of results that are wildcard DNS names
-       (see Section 4.4).
-
-   This may be accomplished by using a minimum sort value of 0x1f (US-
-   ASCII character `-') and a maximum sort value of 0x7a (US-ASCII
-   character lowercase `z'), and then skipping non-LDH, non-lowercase
-   values when incrementing or decrementing octets.
-
-4.4.  Wild Card Considerations
-
-   Neither derivation avoids the possibility that the result may be a
-   DNS name containing a wildcard label, i.e., a label containing a
-   single octet with the value 0x2a (US-ASCII character `*').  With
-   additional tests, wildcard DNS names may be explicitly avoided;
-   alternatively, if the range of octet values can be restricted to
-   those corresponding to letter-digit-hyphen, or LDH, characters (see
-   Section 4.3), such DNS names will not occur.
-
-   Note that it is improbable that a result that is a wildcard DNS name
-   will occur unintentionally; even if one does occur either as the
-   owner name of, or in the RDATA of an NSEC RR, it is treated as a
-   literal DNS name with no special meaning.
-
-4.5.  Possible Modifications
-
-4.5.1.  Restriction of Effective Maximum DNS Name Length
-
-   [RFC1034] specifies that "the total number of octets that represent a
-   name (i.e., the sum of all label octets and label lengths) is limited
-   to 255", including the null (zero-length) label that represents the
-   root.  For the purpose of deriving predecessors and successors during
-   NSEC RR synthesis, the maximum DNS name length may be effectively
-   restricted to the length of the longest DNS name in the zone.  This
-   will minimise the size of responses containing synthesised NSEC RRs
-   but, especially in the case of the modified method, may result in
-   some additional computational complexity.
-
-   Note that this modification will have the effect of revealing
-   information about the longest name in the zone.  Moreover, when the
-   contents of the zone changes, e.g., during dynamic updates and zone
-   transfers, care must be taken to ensure that the effective maximum
-   DNS name length agrees with the new contents.
-
-4.5.2.  Use of Modified Method with Zones Containing SRV RRs
-
-   Normally, the modified method cannot be used in zones that contain
-   Service Record (SRV) RRs [RFC2782], as SRV RRs have owner names that
-   contain multiple labels.  However, the use of SRV RRs can be
-
-
-
-Sisson & Laurie               Experimental                      [Page 8]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-   accommodated by various techniques.  There are at least four possible
-   ways to do this:
-
-   1.  Use conventional NSEC RRs for the region of the zone that
-       contains first-level labels beginning with the underscore (`_')
-       character.  For the purposes of generating these NSEC RRs, the
-       existence of (possibly fictional) ownernames `9{63}' and `a'
-       could be assumed, providing a lower and upper bound for this
-       region.  Then all queries where the QNAME does not exist but
-       contains a first-level label beginning with an underscore could
-       be handled using the normal DNSSEC protocol.
-
-       This approach would make it possible to enumerate all DNS names
-       in the zone containing a first-level label beginning with
-       underscore, including all SRV RRs, but this may be of less a
-       concern to the zone administrator than incurring the overhead of
-       the absolute method or of the following variants of the modified
-       method.
-
-   2.  The absolute method could be used for synthesising NSEC RRs for
-       all queries where the QNAME contains a leading underscore.
-       However, this re-introduces the susceptibility of the absolute
-       method to denial of service activity, as an attacker could send
-       queries for an effectively inexhaustible supply of domain names
-       beginning with a leading underscore.
-
-   3.  A variant of the modified method could be used for synthesising
-       NSEC RRs for all queries where the QNAME contains a leading
-       underscore.  This variant would assume that all predecessors and
-       successors to queries where the QNAME contains a leading
-       underscore may consist of two labels rather than only one.  This
-       introduces a little additional complexity without incurring the
-       full increase in response size and computational complexity as
-       the absolute method.
-
-   4.  Finally, a variant of the modified method that assumes that all
-       owner names in the zone consist of one or two labels could be
-       used.  However, this negates much of the reduction in response
-       size of the modified method and may be nearly as computationally
-       complex as the absolute method.
-
-5.  Examples
-
-   In the following examples,
-
-      the owner name of the zone apex is "example.com.",
-
-
-
-
-
-Sisson & Laurie               Experimental                      [Page 9]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-      the range of octet values is 0x00 - 0xff excluding values
-      corresponding to uppercase US-ASCII letters, and
-
-      non-printable octet values are expressed as three-digit decimal
-      numbers preceded by a backslash (as specified in Section 5.1 of
-      [RFC1035]).
-
-5.1.  Examples of Immediate Predecessors Using Absolute Method
-
-   Example of a typical case:
-
-      P(foo.example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.fon\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.fon\255{60}.example.com.
-
-      where {n} represents the number of repetitions of an octet.
-
-   Example where least significant (left-most) label of DNS name
-   consists of a single octet of the minimum sort value:
-
-      P(\000.foo.example.com.) = foo.example.com.
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 10]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-   Example where least significant (right-most) octet of least
-   significant (left-most) label has the minimum sort value:
-
-      P(foo\000.example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.foo.example.com.
-
-      or, in alternate notation:
-
-           \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 11]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-   Example where DNS name contains an octet that must be decremented by
-   skipping values corresponding to US-ASCII uppercase letters:
-
-      P(fo\[.example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.fo\@\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com.
-
-      where {n} represents the number of repetitions of an octet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 12]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-   Example where DNS name is the owner name of the zone apex, and
-   consequently wraps to the DNS name with the maximum possible sort
-   order in the zone:
-
-      P(example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 13]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-5.2.  Examples of Immediate Successors Using Absolute Method
-
-   Example of typical case:
-
-      S(foo.example.com.) = \000.foo.example.com.
-
-   Example where DNS name is one octet short of the maximum DNS name
-   length:
-
-      N =  fooooooooooooooooooooooooooooooooooooooooooooooo
-           .ooooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooo.ooooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooo.ooooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooooooooooo
-           \000.ooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooooo.ooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooooo.ooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}\000.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 14]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-   Example where DNS name is the maximum DNS name length:
-
-      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
-           o.oooooooooooooooooooooooooooooooooooooooooooooo
-           ooooooooooooooooo.oooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooooo.oooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           o.example.com.
-
-      or, in alternate notation:
-
-           fo{48}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooooooooooo
-           p.oooooooooooooooooooooooooooooooooooooooooooooo
-           ooooooooooooooooo.oooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooooo.oooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           o.example.com.
-
-      or, in alternate notation:
-
-           fo{47}p.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 15]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-   Example where DNS name is the maximum DNS name length and the least
-   significant (left-most) label has the maximum sort value:
-
-      N =  \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.ooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooooo.ooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooooo.ooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooo.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooop.oooooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooo.oooooooooooooooo
-           ooooooooooooooooooooooooooooooooooooooooooooooo.
-           example.com.
-
-      or, in alternate notation:
-
-           o{62}p.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 16]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-   Example where DNS name is the maximum DNS name length and the eight
-   least significant (right-most) octets of the least significant
-   (left-most) label have the maximum sort value:
-
-      N  = foooooooooooooooooooooooooooooooooooooooo\255
-           \255\255\255\255\255\255\255.ooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooo.ooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooo.ooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooo.example.com.
-
-      or, in alternate notation:
-
-           fo{40}\255{8}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooop.oooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           ooooooooo.oooooooooooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooo.oooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooooooooooooo.example.com.
-
-      or, in alternate notation:
-
-           fo{39}p.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 17]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-   Example where DNS name is the maximum DNS name length and contains an
-   octet that must be incremented by skipping values corresponding to
-   US-ASCII uppercase letters:
-
-      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
-           \@.ooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooo.ooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooo.ooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}\@.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooooooooooo
-           \[.ooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooo.ooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooo.ooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}\[.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 18]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-   Example where DNS name has the maximum possible sort order in the
-   zone, and consequently wraps to the owner name of the zone apex:
-
-      N  = \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
-
-      S(N) = example.com.
-
-5.3.  Examples of Predecessors Using Modified Method
-
-   Example of a typical case:
-
-      P'(foo.example.com.) =
-
-           fon\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.example.com.
-
-      or, in alternate notation:
-
-           fon\255{60}.example.com.
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 19]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-   Example where DNS name contains more labels than DNS names in the
-   zone:
-
-      P'(bar.foo.example.com.) = foo.example.com.
-
-   Example where least significant (right-most) octet of least
-   significant (left-most) label has the minimum sort value:
-
-      P'(foo\000.example.com.) = foo.example.com.
-
-   Example where least significant (left-most) label has the minimum
-   sort value:
-
-      P'(\000.example.com.) = example.com.
-
-   Example where DNS name is the owner name of the zone apex, and
-   consequently wraps to the DNS name with the maximum possible sort
-   order in the zone:
-
-      P'(example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{63}.example.com.
-
-5.4.  Examples of Successors Using Modified Method
-
-   Example of a typical case:
-
-      S'(foo.example.com.) = foo\000.example.com.
-
-   Example where DNS name contains more labels than DNS names in the
-   zone:
-
-      S'(bar.foo.example.com.) = foo\000.example.com.
-
-
-   Example where least significant (left-most) label has the maximum
-   sort value, and consequently wraps to the owner name of the zone
-   apex:
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 20]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-      N  = \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{63}.example.com.
-
-      S'(N) = example.com.
-
-6.  Security Considerations
-
-   The derivation of some predecessors/successors requires the testing
-   of more conditions than others.  Consequently, the effectiveness of a
-   denial-of-service attack may be enhanced by sending queries that
-   require more conditions to be tested.  The modified method involves
-   the testing of fewer conditions than the absolute method and
-   consequently is somewhat less susceptible to this exposure.
-
-7.  Acknowledgements
-
-   The authors would like to thank Sam Weiler, Olaf Kolkman, Olafur
-   Gudmundsson, and Niall O'Reilly for their review and input.
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC1034]      Mockapetris, P., "Domain names - concepts and
-                  facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC1035]      Mockapetris, P., "Domain names - implementation and
-                  specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2181]      Elz, R. and R. Bush, "Clarifications to the DNS
-                  Specification", RFC 2181, July 1997.
-
-   [RFC2782]      Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
-                  for specifying the location of services (DNS SRV)",
-                  RFC 2782, February 2000.
-
-   [RFC4034]      Arends, R., Austein, R., Larson, M., Massey, D., and
-                  S. Rose, "Resource Records for the DNS Security
-                  Extensions", RFC 4034, March 2005.
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 21]
-
-RFC 4471           DNS Name Predecessor and Successor     September 2006
-
-
-8.2.  Informative References
-
-   [RFC4470]      Weiler, S. and J. Ihren, "Minimally Covering NSEC
-                  Records and DNSSEC On-line Signing", RFC 4470, April
-                  2006.
-
-   [DNSSEC-TRANS] Arends, R., Koch, P., and J. Schlyter, "Evaluating
-                  DNSSEC Transition Mechanisms", Work in Progress,
-                  February 2005.
-
-Authors' Addresses
-
-   Geoffrey Sisson
-   Nominet
-   Sandford Gate
-   Sandy Lane West
-   Oxford
-   OX4 6LB
-   GB
-
-   Phone: +44 1865 332211
-   EMail: geoff@nominet.org.uk
-
-
-   Ben Laurie
-   Nominet
-   17 Perryn Road
-   London
-   W3 7LR
-   GB
-
-   Phone: +44 20 8735 0686
-   EMail: ben@algroup.co.uk
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 22]
-
-RFC 4471           DNS Name Predecessor and Successor     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).
-
-
-
-
-
-
-
-Sisson & Laurie               Experimental                     [Page 23]
-
diff --git a/doc/rfc/rfc4472.txt b/doc/rfc/rfc4472.txt
deleted file mode 100644
index b396e9a1..00000000
--- a/doc/rfc/rfc4472.txt
+++ /dev/null
@@ -1,1627 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          A. Durand
-Request for Comments: 4472                                       Comcast
-Category: Informational                                         J. Ihren
-                                                              Autonomica
-                                                               P. Savola
-                                                               CSC/FUNET
-                                                              April 2006
-
-
-          Operational Considerations and Issues with IPv6 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 (2006).
-
-Abstract
-
-   This memo presents operational considerations and issues with IPv6
-   Domain Name System (DNS), including a summary of special IPv6
-   addresses, documentation of known DNS implementation misbehavior,
-   recommendations and considerations on how to perform DNS naming for
-   service provisioning and for DNS resolver IPv6 support,
-   considerations for DNS updates for both the forward and reverse
-   trees, and miscellaneous issues.  This memo is aimed to include a
-   summary of information about IPv6 DNS considerations for those who
-   have experience with IPv4 DNS.
-
-Table of Contents
-
-   1. Introduction ....................................................3
-      1.1. Representing IPv6 Addresses in DNS Records .................3
-      1.2. Independence of DNS Transport and DNS Records ..............4
-      1.3. Avoiding IPv4/IPv6 Name Space Fragmentation ................4
-      1.4. Query Type '*' and A/AAAA Records ..........................4
-   2. DNS Considerations about Special IPv6 Addresses .................5
-      2.1. Limited-Scope Addresses ....................................5
-      2.2. Temporary Addresses ........................................5
-      2.3. 6to4 Addresses .............................................5
-      2.4. Other Transition Mechanisms ................................5
-   3. Observed DNS Implementation Misbehavior .........................6
-      3.1. Misbehavior of DNS Servers and Load-balancers ..............6
-      3.2. Misbehavior of DNS Resolvers ...............................6
-
-
-
-Durand, et al.               Informational                      [Page 1]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   4. Recommendations for Service Provisioning Using DNS ..............7
-      4.1. Use of Service Names instead of Node Names .................7
-      4.2. Separate vs. the Same Service Names for IPv4 and IPv6 ......8
-      4.3. Adding the Records Only When Fully IPv6-enabled ............8
-      4.4. The Use of TTL for IPv4 and IPv6 RRs .......................9
-           4.4.1. TTL with Courtesy Additional Data ...................9
-           4.4.2. TTL with Critical Additional Data ..................10
-      4.5. IPv6 Transport Guidelines for DNS Servers .................10
-   5. Recommendations for DNS Resolver IPv6 Support ..................10
-      5.1. DNS Lookups May Query IPv6 Records Prematurely ............10
-      5.2. Obtaining a List of DNS Recursive Resolvers ...............12
-      5.3. IPv6 Transport Guidelines for Resolvers ...................12
-   6. Considerations about Forward DNS Updating ......................13
-      6.1. Manual or Custom DNS Updates ..............................13
-      6.2. Dynamic DNS ...............................................13
-   7. Considerations about Reverse DNS Updating ......................14
-      7.1. Applicability of Reverse DNS ..............................14
-      7.2. Manual or Custom DNS Updates ..............................15
-      7.3. DDNS with Stateless Address Autoconfiguration .............16
-      7.4. DDNS with DHCP ............................................17
-      7.5. DDNS with Dynamic Prefix Delegation .......................17
-   8. Miscellaneous DNS Considerations ...............................18
-      8.1. NAT-PT with DNS-ALG .......................................18
-      8.2. Renumbering Procedures and Applications' Use of DNS .......18
-   9. Acknowledgements ...............................................19
-   10. Security Considerations .......................................19
-   11. References ....................................................20
-      11.1. Normative References .....................................20
-      11.2. Informative References ...................................22
-   Appendix A. Unique Local Addressing Considerations for DNS ........24
-   Appendix B. Behavior of Additional Data in IPv4/IPv6
-               Environments ..........................................24
-      B.1. Description of Additional Data Scenarios ..................24
-      B.2. Which Additional Data to Keep, If Any? ....................26
-      B.3. Discussion of the Potential Problems ......................27
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al.               Informational                      [Page 2]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-1.  Introduction
-
-   This memo presents operational considerations and issues with IPv6
-   DNS; it is meant to be an extensive summary and a list of pointers
-   for more information about IPv6 DNS considerations for those with
-   experience with IPv4 DNS.
-
-   The purpose of this document is to give information about various
-   issues and considerations related to DNS operations with IPv6; it is
-   not meant to be a normative specification or standard for IPv6 DNS.
-
-   The first section gives a brief overview of how IPv6 addresses and
-   names are represented in the DNS, how transport protocols and
-   resource records (don't) relate, and what IPv4/IPv6 name space
-   fragmentation means and how to avoid it; all of these are described
-   at more length in other documents.
-
-   The second section summarizes the special IPv6 address types and how
-   they relate to DNS.  The third section describes observed DNS
-   implementation misbehaviors that have a varying effect on the use of
-   IPv6 records with DNS.  The fourth section lists recommendations and
-   considerations for provisioning services with DNS.  The fifth section
-   in turn looks at recommendations and considerations about providing
-   IPv6 support in the resolvers.  The sixth and seventh sections
-   describe considerations with forward and reverse DNS updates,
-   respectively.  The eighth section introduces several miscellaneous
-   IPv6 issues relating to DNS for which no better place has been found
-   in this memo.  Appendix A looks briefly at the requirements for
-   unique local addressing.  Appendix B discusses additional data.
-
-1.1.  Representing IPv6 Addresses in DNS Records
-
-   In the forward zones, IPv6 addresses are represented using AAAA
-   records.  In the reverse zones, IPv6 address are represented using
-   PTR records in the nibble format under the ip6.arpa. tree.  See
-   [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
-   for background information.
-
-   In particular, one should note that the use of A6 records in the
-   forward tree or Bitlabels in the reverse tree is not recommended
-   [RFC3363].  Using DNAME records is not recommended in the reverse
-   tree in conjunction with A6 records; the document did not mean to
-   take a stance on any other use of DNAME records [RFC3364].
-
-
-
-
-
-
-
-
-Durand, et al.               Informational                      [Page 3]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-1.2.  Independence of DNS Transport and DNS Records
-
-   DNS has been designed to present a single, globally unique name space
-   [RFC2826].  This property should be maintained, as described here and
-   in Section 1.3.
-
-   The IP version used to transport the DNS queries and responses is
-   independent of the records being queried: AAAA records can be queried
-   over IPv4, and A records over IPv6.  The DNS servers must not make
-   any assumptions about what data to return for Answer and Authority
-   sections based on the underlying transport used in a query.
-
-   However, there is some debate whether the addresses in Additional
-   section could be selected or filtered using hints obtained from which
-   transport was being used; this has some obvious problems because in
-   many cases the transport protocol does not correlate with the
-   requests, and because a "bad" answer is in a way worse than no answer
-   at all (consider the case where the client is led to believe that a
-   name received in the additional record does not have any AAAA records
-   at all).
-
-   As stated in [RFC3596]:
-
-      The IP protocol version used for querying resource records is
-      independent of the protocol version of the resource records; e.g.,
-      IPv4 transport can be used to query IPv6 records and vice versa.
-
-1.3.  Avoiding IPv4/IPv6 Name Space Fragmentation
-
-   To avoid the DNS name space from fragmenting into parts where some
-   parts of DNS are only visible using IPv4 (or IPv6) transport, the
-   recommendation is to always keep at least one authoritative server
-   IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
-   See DNS IPv6 transport guidelines [RFC3901] for more information.
-
-1.4.  Query Type '*' and A/AAAA Records
-
-   QTYPE=* is typically only used for debugging or management purposes;
-   it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
-   any available RRsets, not *all* the RRsets, because the caches do not
-   necessarily have all the RRsets and have no way of guaranteeing that
-   they have all the RRsets.  Therefore, to get both A and AAAA records
-   reliably, two separate queries must be made.
-
-
-
-
-
-
-
-
-Durand, et al.               Informational                      [Page 4]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-2.  DNS Considerations about Special IPv6 Addresses
-
-   There are a couple of IPv6 address types that are somewhat special;
-   these are considered here.
-
-2.1.  Limited-Scope Addresses
-
-   The IPv6 addressing architecture [RFC4291] includes two kinds of
-   local-use addresses: link-local (fe80::/10) and site-local
-   (fec0::/10).  The site-local addresses have been deprecated [RFC3879]
-   but are discussed with unique local addresses in Appendix A.
-
-   Link-local addresses should never be published in DNS (whether in
-   forward or reverse tree), because they have only local (to the
-   connected link) significance [WIP-DC2005].
-
-2.2.  Temporary Addresses
-
-   Temporary addresses defined in RFC 3041 [RFC3041] (sometimes called
-   "privacy addresses") use a random number as the interface identifier.
-   Having DNS AAAA records that are updated to always contain the
-   current value of a node's temporary address would defeat the purpose
-   of the mechanism and is not recommended.  However, it would still be
-   possible to return a non-identifiable name (e.g., the IPv6 address in
-   hexadecimal format), as described in [RFC3041].
-
-2.3.  6to4 Addresses
-
-   6to4 [RFC3056] specifies an automatic tunneling mechanism that maps a
-   public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
-
-   If the reverse DNS population would be desirable (see Section 7.1 for
-   applicability), there are a number of possible ways to do so.
-
-   [WIP-H2005] aims to design an autonomous reverse-delegation system
-   that anyone being capable of communicating using a specific 6to4
-   address would be able to set up a reverse delegation to the
-   corresponding 6to4 prefix.  This could be deployed by, e.g., Regional
-   Internet Registries (RIRs).  This is a practical solution, but may
-   have some scalability concerns.
-
-2.4.  Other Transition Mechanisms
-
-   6to4 is mentioned as a case of an IPv6 transition mechanism requiring
-   special considerations.  In general, mechanisms that include a
-   special prefix may need a custom solution; otherwise, for example,
-   when IPv4 address is embedded as the suffix or not embedded at all,
-   special solutions are likely not needed.
-
-
-
-Durand, et al.               Informational                      [Page 5]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   Note that it does not seem feasible to provide reverse DNS with
-   another automatic tunneling mechanism, Teredo [RFC4380]; this is
-   because the IPv6 address is based on the IPv4 address and UDP port of
-   the current Network Address Translation (NAT) mapping, which is
-   likely to be relatively short-lived.
-
-3.  Observed DNS Implementation Misbehavior
-
-   Several classes of misbehavior in DNS servers, load-balancers, and
-   resolvers have been observed.  Most of these are rather generic, not
-   only applicable to IPv6 -- but in some cases, the consequences of
-   this misbehavior are extremely severe in IPv6 environments and
-   deserve to be mentioned.
-
-3.1.  Misbehavior of DNS Servers and Load-balancers
-
-   There are several classes of misbehavior in certain DNS servers and
-   load-balancers that have been noticed and documented [RFC4074]: some
-   implementations silently drop queries for unimplemented DNS records
-   types, or provide wrong answers to such queries (instead of a proper
-   negative reply).  While typically these issues are not limited to
-   AAAA records, the problems are aggravated by the fact that AAAA
-   records are being queried instead of (mainly) A records.
-
-   The problems are serious because when looking up a DNS name, typical
-   getaddrinfo() implementations, with AF_UNSPEC hint given, first try
-   to query the AAAA records of the name, and after receiving a
-   response, query the A records.  This is done in a serial fashion --
-   if the first query is never responded to (instead of properly
-   returning a negative answer), significant time-outs will occur.
-
-   In consequence, this is an enormous problem for IPv6 deployments, and
-   in some cases, IPv6 support in the software has even been disabled
-   due to these problems.
-
-   The solution is to fix or retire those misbehaving implementations,
-   but that is likely not going to be effective.  There are some
-   possible ways to mitigate the problem, e.g., by performing the
-   lookups somewhat in parallel and reducing the time-out as long as at
-   least one answer has been received, but such methods remain to be
-   investigated; slightly more on this is included in Section 5.
-
-3.2.  Misbehavior of DNS Resolvers
-
-   Several classes of misbehavior have also been noticed in DNS
-   resolvers [WIP-LB2005].  However, these do not seem to directly
-   impair IPv6 use, and are only referred to for completeness.
-
-
-
-
-Durand, et al.               Informational                      [Page 6]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-4.  Recommendations for Service Provisioning Using DNS
-
-   When names are added in the DNS to facilitate a service, there are
-   several general guidelines to consider to be able to do it as
-   smoothly as possible.
-
-4.1.  Use of Service Names instead of Node Names
-
-   It makes sense to keep information about separate services logically
-   separate in the DNS by using a different DNS hostname for each
-   service.  There are several reasons for doing this, for example:
-
-   o  It allows more flexibility and ease for migration of (only a part
-      of) services from one node to another,
-
-   o  It allows configuring different properties (e.g., Time to Live
-      (TTL)) for each service, and
-
-   o  It allows deciding separately for each service whether or not to
-      publish the IPv6 addresses (in cases where some services are more
-      IPv6-ready than others).
-
-   Using SRV records [RFC2782] would avoid these problems.
-   Unfortunately, those are not sufficiently widely used to be
-   applicable in most cases.  Hence an operation technique is to use
-   service names instead of node names (or "hostnames").  This
-   operational technique is not specific to IPv6, but required to
-   understand the considerations described in Section 4.2 and
-   Section 4.3.
-
-   For example, assume a node named "pobox.example.com" provides both
-   SMTP and IMAP service.  Instead of configuring the MX records to
-   point at "pobox.example.com", and configuring the mail clients to
-   look up the mail via IMAP from "pobox.example.com", one could use,
-   e.g., "smtp.example.com" for SMTP (for both message submission and
-   mail relaying between SMTP servers) and "imap.example.com" for IMAP.
-   Note that in the specific case of SMTP relaying, the server itself
-   must typically also be configured to know all its names to ensure
-   that loops do not occur.  DNS can provide a layer of indirection
-   between service names and where the service actually is, and using
-   which addresses.  (Obviously, when wanting to reach a specific node,
-   one should use the hostname rather than a service name.)
-
-
-
-
-
-
-
-
-
-Durand, et al.               Informational                      [Page 7]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-4.2.  Separate vs. the Same Service Names for IPv4 and IPv6
-
-   The service naming can be achieved in basically two ways: when a
-   service is named "service.example.com" for IPv4, the IPv6-enabled
-   service could either be added to "service.example.com" or added
-   separately under a different name, e.g., in a sub-domain like
-   "service.ipv6.example.com".
-
-   These two methods have different characteristics.  Using a different
-   name allows for easier service piloting, minimizing the disturbance
-   to the "regular" users of IPv4 service; however, the service would
-   not be used transparently, without the user/application explicitly
-   finding it and asking for it -- which would be a disadvantage in most
-   cases.  When the different name is under a sub-domain, if the
-   services are deployed within a restricted network (e.g., inside an
-   enterprise), it's possible to prefer them transparently, at least to
-   a degree, by modifying the DNS search path; however, this is a
-   suboptimal solution.  Using the same service name is the "long-term"
-   solution, but may degrade performance for those clients whose IPv6
-   performance is lower than IPv4, or does not work as well (see
-   Section 4.3 for more).
-
-   In most cases, it makes sense to pilot or test a service using
-   separate service names, and move to the use of the same name when
-   confident enough that the service level will not degrade for the
-   users unaware of IPv6.
-
-4.3.  Adding the Records Only When Fully IPv6-enabled
-
-   The recommendation is that AAAA records for a service should not be
-   added to the DNS until all of following are true:
-
-   1.  The address is assigned to the interface on the node.
-
-   2.  The address is configured on the interface.
-
-   3.  The interface is on a link that is connected to the IPv6
-       infrastructure.
-
-   In addition, if the AAAA record is added for the node, instead of
-   service as recommended, all the services of the node should be IPv6-
-   enabled prior to adding the resource record.
-
-   For example, if an IPv6 node is isolated from an IPv6 perspective
-   (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
-   that it should not have an address in the DNS.
-
-
-
-
-
-Durand, et al.               Informational                      [Page 8]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   Consider the case of two dual-stack nodes, which both are IPv6-
-   enabled, but the server does not have (global) IPv6 connectivity.  As
-   the client looks up the server's name, only A records are returned
-   (if the recommendations above are followed), and no IPv6
-   communication, which would have been unsuccessful, is even attempted.
-
-   The issues are not always so black-and-white.  Usually, it's
-   important that the service offered using both protocols is of roughly
-   equal quality, using the appropriate metrics for the service (e.g.,
-   latency, throughput, low packet loss, general reliability, etc.).
-   This is typically very important especially for interactive or real-
-   time services.  In many cases, the quality of IPv6 connectivity may
-   not yet be equal to that of IPv4, at least globally; this has to be
-   taken into consideration when enabling services.
-
-4.4.  The Use of TTL for IPv4 and IPv6 RRs
-
-   The behavior of DNS caching when different TTL values are used for
-   different RRsets of the same name calls for explicit discussion.  For
-   example, let's consider two unrelated zone fragments:
-
-      example.com.        300    IN    MX     foo.example.com.
-      foo.example.com.    300    IN    A      192.0.2.1
-      foo.example.com.    100    IN    AAAA   2001:db8::1
-
-   ...
-
-      child.example.com.    300  IN    NS     ns.child.example.com.
-      ns.child.example.com. 300  IN    A      192.0.2.1
-      ns.child.example.com. 100  IN    AAAA   2001:db8::1
-
-   In the former case, we have "courtesy" additional data; in the
-   latter, we have "critical" additional data.  See more extensive
-   background discussion of additional data handling in Appendix B.
-
-4.4.1.  TTL with Courtesy Additional Data
-
-   When a caching resolver asks for the MX record of example.com, it
-   gets back "foo.example.com".  It may also get back either one or both
-   of the A and AAAA records in the additional section.  The resolver
-   must explicitly query for both A and AAAA records [RFC2821].
-
-   After 100 seconds, the AAAA record is removed from the cache(s)
-   because its TTL expired.  It could be argued to be useful for the
-   caching resolvers to discard the A record when the shorter TTL (in
-   this case, for the AAAA record) expires; this would avoid the
-   situation where there would be a window of 200 seconds when
-   incomplete information is returned from the cache.  Further argument
-
-
-
-Durand, et al.               Informational                      [Page 9]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   for discarding is that in the normal operation, the TTL values are so
-   high that very likely the incurred additional queries would not be
-   noticeable, compared to the obtained performance optimization.  The
-   behavior in this scenario is unspecified.
-
-4.4.2.  TTL with Critical Additional Data
-
-   The difference to courtesy additional data is that the A/AAAA records
-   served by the parent zone cannot be queried explicitly.  Therefore,
-   after 100 seconds the AAAA record is removed from the cache(s), but
-   the A record remains.  Queries for the remaining 200 seconds
-   (provided that there are no further queries from the parent that
-   could refresh the caches) only return the A record, leading to a
-   potential operational situation with unreachable servers.
-
-   Similar cache flushing strategies apply in this scenario; the
-   behavior is likewise unspecified.
-
-4.5.  IPv6 Transport Guidelines for DNS Servers
-
-   As described in Section 1.3 and [RFC3901], there should continue to
-   be at least one authoritative IPv4 DNS server for every zone, even if
-   the zone has only IPv6 records.  (Note that obviously, having more
-   servers with robust connectivity would be preferable, but this is the
-   minimum recommendation; also see [RFC2182].)
-
-5.  Recommendations for DNS Resolver IPv6 Support
-
-   When IPv6 is enabled on a node, there are several things to consider
-   to ensure that the process is as smooth as possible.
-
-5.1.  DNS Lookups May Query IPv6 Records Prematurely
-
-   The system library that implements the getaddrinfo() function for
-   looking up names is a critical piece when considering the robustness
-   of enabling IPv6; it may come in basically three flavors:
-
-   1.  The system library does not know whether IPv6 has been enabled in
-       the kernel of the operating system: it may start looking up AAAA
-       records with getaddrinfo() and AF_UNSPEC hint when the system is
-       upgraded to a system library version that supports IPv6.
-
-   2.  The system library might start to perform IPv6 queries with
-       getaddrinfo() only when IPv6 has been enabled in the kernel.
-       However, this does not guarantee that there exists any useful
-       IPv6 connectivity (e.g., the node could be isolated from the
-       other IPv6 networks, only having link-local addresses).
-
-
-
-
-Durand, et al.               Informational                     [Page 10]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   3.  The system library might implement a toggle that would apply some
-       heuristics to the "IPv6-readiness" of the node before starting to
-       perform queries; for example, it could check whether only link-
-       local IPv6 address(es) exists, or if at least one global IPv6
-       address exists.
-
-   First, let us consider generic implications of unnecessary queries
-   for AAAA records: when looking up all the records in the DNS, AAAA
-   records are typically tried first, and then A records.  These are
-   done in serial, and the A query is not performed until a response is
-   received to the AAAA query.  Considering the misbehavior of DNS
-   servers and load-balancers, as described in Section 3.1, the lookup
-   delay for AAAA may incur additional unnecessary latency, and
-   introduce a component of unreliability.
-
-   One option here could be to do the queries partially in parallel; for
-   example, if the final response to the AAAA query is not received in
-   0.5 seconds, start performing the A query while waiting for the
-   result.  (Immediate parallelism might not be optimal, at least
-   without information-sharing between the lookup threads, as that would
-   probably lead to duplicate non-cached delegation chain lookups.)
-
-   An additional concern is the address selection, which may, in some
-   circumstances, prefer AAAA records over A records even when the node
-   does not have any IPv6 connectivity [WIP-RDP2004].  In some cases,
-   the implementation may attempt to connect or send a datagram on a
-   physical link [WIP-R2006], incurring very long protocol time-outs,
-   instead of quickly falling back to IPv4.
-
-   Now, we can consider the issues specific to each of the three
-   possibilities:
-
-   In the first case, the node performs a number of completely useless
-   DNS lookups as it will not be able to use the returned AAAA records
-   anyway.  (The only exception is where the application desires to know
-   what's in the DNS, but not use the result for communication.)  One
-   should be able to disable these unnecessary queries, for both latency
-   and reliability reasons.  However, as IPv6 has not been enabled, the
-   connections to IPv6 addresses fail immediately, and if the
-   application is programmed properly, the application can fall
-   gracefully back to IPv4 [RFC4038].
-
-   The second case is similar to the first, except it happens to a
-   smaller set of nodes when IPv6 has been enabled but connectivity has
-   not been provided yet.  Similar considerations apply, with the
-   exception that IPv6 records, when returned, will be actually tried
-   first, which may typically lead to long time-outs.
-
-
-
-
-Durand, et al.               Informational                     [Page 11]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   The third case is a bit more complex: optimizing away the DNS lookups
-   with only link-locals is probably safe (but may be desirable with
-   different lookup services that getaddrinfo() may support), as the
-   link-locals are typically automatically generated when IPv6 is
-   enabled, and do not indicate any form of IPv6 connectivity.  That is,
-   performing DNS lookups only when a non-link-local address has been
-   configured on any interface could be beneficial -- this would be an
-   indication that the address has been configured either from a router
-   advertisement, Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
-   [RFC3315], or manually.  Each would indicate at least some form of
-   IPv6 connectivity, even though there would not be guarantees of it.
-
-   These issues should be analyzed at more depth, and the fixes found
-   consensus on, perhaps in a separate document.
-
-5.2.  Obtaining a List of DNS Recursive Resolvers
-
-   In scenarios where DHCPv6 is available, a host can discover a list of
-   DNS recursive resolvers through the DHCPv6 "DNS Recursive Name
-   Server" option [RFC3646].  This option can be passed to a host
-   through a subset of DHCPv6 [RFC3736].
-
-   The IETF is considering the development of alternative mechanisms for
-   obtaining the list of DNS recursive name servers when DHCPv6 is
-   unavailable or inappropriate.  No decision about taking on this
-   development work has been reached as of this writing [RFC4339].
-
-   In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
-   under consideration for development include the use of [WIP-O2004]
-   and the use of Router Advertisements to convey the information
-   [WIP-J2006].
-
-   Note that even though IPv6 DNS resolver discovery is a recommended
-   procedure, it is not required for dual-stack nodes in dual-stack
-   networks as IPv6 DNS records can be queried over IPv4 as well as
-   IPv6.  Obviously, nodes that are meant to function without manual
-   configuration in IPv6-only networks must implement the DNS resolver
-   discovery function.
-
-5.3.  IPv6 Transport Guidelines for Resolvers
-
-   As described in Section 1.3 and [RFC3901], the recursive resolvers
-   should be IPv4-only or dual-stack to be able to reach any IPv4-only
-   DNS server.  Note that this requirement is also fulfilled by an IPv6-
-   only stub resolver pointing to a dual-stack recursive DNS resolver.
-
-
-
-
-
-
-Durand, et al.               Informational                     [Page 12]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-6.  Considerations about Forward DNS Updating
-
-   While the topic of how to enable updating the forward DNS, i.e., the
-   mapping from names to the correct new addresses, is not specific to
-   IPv6, it should be considered especially due to the advent of
-   Stateless Address Autoconfiguration [RFC2462].
-
-   Typically, forward DNS updates are more manageable than doing them in
-   the reverse DNS, because the updater can often be assumed to "own" a
-   certain DNS name -- and we can create a form of security relationship
-   with the DNS name and the node that is allowed to update it to point
-   to a new address.
-
-   A more complex form of DNS updates -- adding a whole new name into a
-   DNS zone, instead of updating an existing name -- is considered out
-   of scope for this memo as it could require zone-wide authentication.
-   Adding a new name in the forward zone is a problem that is still
-   being explored with IPv4, and IPv6 does not seem to add much new in
-   that area.
-
-6.1.  Manual or Custom DNS Updates
-
-   The DNS mappings can also be maintained by hand, in a semi-automatic
-   fashion or by running non-standardized protocols.  These are not
-   considered at more length in this memo.
-
-6.2.  Dynamic DNS
-
-   Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized
-   mechanism for dynamically updating the DNS.  It works equally well
-   with Stateless Address Autoconfiguration (SLAAC), DHCPv6, or manual
-   address configuration.  It is important to consider how each of these
-   behave if IP address-based authentication, instead of stronger
-   mechanisms [RFC3007], was used in the updates.
-
-   1.  Manual addresses are static and can be configured.
-
-   2.  DHCPv6 addresses could be reasonably static or dynamic, depending
-       on the deployment, and could or could not be configured on the
-       DNS server for the long term.
-
-   3.  SLAAC addresses are typically stable for a long time, but could
-       require work to be configured and maintained.
-
-   As relying on IP addresses for Dynamic DNS is rather insecure at
-   best, stronger authentication should always be used; however, this
-   requires that the authorization keying will be explicitly configured
-   using unspecified operational methods.
-
-
-
-Durand, et al.               Informational                     [Page 13]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   Note that with DHCP it is also possible that the DHCP server updates
-   the DNS, not the host.  The host might only indicate in the DHCP
-   exchange which hostname it would prefer, and the DHCP server would
-   make the appropriate updates.  Nonetheless, while this makes setting
-   up a secure channel between the updater and the DNS server easier, it
-   does not help much with "content" security, i.e., whether the
-   hostname was acceptable -- if the DNS server does not include
-   policies, they must be included in the DHCP server (e.g., a regular
-   host should not be able to state that its name is "www.example.com").
-   DHCP-initiated DDNS updates have been extensively described in
-   [WIP-SV2005], [WIP-S2005a], and [WIP-S2005b].
-
-   The nodes must somehow be configured with the information about the
-   servers where they will attempt to update their addresses, sufficient
-   security material for authenticating themselves to the server, and
-   the hostname they will be updating.  Unless otherwise configured, the
-   first could be obtained by looking up the authoritative name servers
-   for the hostname; the second must be configured explicitly unless one
-   chooses to trust the IP address-based authentication (not a good
-   idea); and lastly, the nodename is typically pre-configured somehow
-   on the node, e.g., at install time.
-
-   Care should be observed when updating the addresses not to use longer
-   TTLs for addresses than are preferred lifetimes for the addresses, so
-   that if the node is renumbered in a managed fashion, the amount of
-   stale DNS information is kept to the minimum.  That is, if the
-   preferred lifetime of an address expires, the TTL of the record needs
-   to be modified unless it was already done before the expiration.  For
-   better flexibility, the DNS TTL should be much shorter (e.g., a half
-   or a third) than the lifetime of an address; that way, the node can
-   start lowering the DNS TTL if it seems like the address has not been
-   renewed/refreshed in a while.  Some discussion on how an
-   administrator could manage the DNS TTL is included in [RFC4192]; this
-   could be applied to (smart) hosts as well.
-
-7.  Considerations about Reverse DNS Updating
-
-   Updating the reverse DNS zone may be difficult because of the split
-   authority over an address.  However, first we have to consider the
-   applicability of reverse DNS in the first place.
-
-7.1.  Applicability of Reverse DNS
-
-   Today, some applications use reverse DNS either to look up some hints
-   about the topological information associated with an address (e.g.,
-   resolving web server access logs) or (as a weak form of a security
-   check) to get a feel whether the user's network administrator has
-
-
-
-
-Durand, et al.               Informational                     [Page 14]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   "authorized" the use of the address (on the premise that adding a
-   reverse record for an address would signal some form of
-   authorization).
-
-   One additional, maybe slightly more useful usage is ensuring that the
-   reverse and forward DNS contents match (by looking up the pointer to
-   the name by the IP address from the reverse tree, and ensuring that a
-   record under the name in the forward tree points to the IP address)
-   and correspond to a configured name or domain.  As a security check,
-   it is typically accompanied by other mechanisms, such as a user/
-   password login; the main purpose of the reverse+forward DNS check is
-   to weed out the majority of unauthorized users, and if someone
-   managed to bypass the checks, he would still need to authenticate
-   "properly".
-
-   It may also be desirable to store IPsec keying material corresponding
-   to an IP address in the reverse DNS, as justified and described in
-   [RFC4025].
-
-   It is not clear whether it makes sense to require or recommend that
-   reverse DNS records be updated.  In many cases, it would just make
-   more sense to use proper mechanisms for security (or topological
-   information lookup) in the first place.  At minimum, the applications
-   that use it as a generic authorization (in the sense that a record
-   exists at all) should be modified as soon as possible to avoid such
-   lookups completely.
-
-   The applicability is discussed at more length in [WIP-S2005c].
-
-7.2.  Manual or Custom DNS Updates
-
-   Reverse DNS can of course be updated using manual or custom methods.
-   These are not further described here, except for one special case.
-
-   One way to deploy reverse DNS would be to use wildcard records, for
-   example, by configuring one name for a subnet (/64) or a site (/48).
-   As a concrete example, a site (or the site's ISP) could configure the
-   reverses of the prefix 2001:db8:f00::/48 to point to one name using a
-   wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
-   site.example.com.".  Naturally, such a name could not be verified
-   from the forward DNS, but would at least provide some form of
-   "topological information" or "weak authorization" if that is really
-   considered to be useful.  Note that this is not actually updating the
-   DNS as such, as the whole point is to avoid DNS updates completely by
-   manually configuring a generic name.
-
-
-
-
-
-
-Durand, et al.               Informational                     [Page 15]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-7.3.  DDNS with Stateless Address Autoconfiguration
-
-   Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
-   some regard, while being more difficult in another, as described
-   below.
-
-   The address space administrator decides whether or not the hosts are
-   trusted to update their reverse DNS records.  If they are trusted and
-   deployed at the same site (e.g., not across the Internet), a simple
-   address-based authorization is typically sufficient (i.e., check that
-   the DNS update is done from the same IP address as the record being
-   updated); stronger security can also be used [RFC3007].  If they
-   aren't allowed to update the reverses, no update can occur.  However,
-   such address-based update authorization operationally requires that
-   ingress filtering [RFC3704] has been set up at the border of the site
-   where the updates occur, and as close to the updater as possible.
-
-   Address-based authorization is simpler with reverse DNS (as there is
-   a connection between the record and the address) than with forward
-   DNS.  However, when a stronger form of security is used, forward DNS
-   updates are simpler to manage because the host can be assumed to have
-   an association with the domain.  Note that the user may roam to
-   different networks and does not necessarily have any association with
-   the owner of that address space.  So, assuming a stronger form of
-   authorization for reverse DNS updates than an address association is
-   generally infeasible.
-
-   Moreover, the reverse zones must be cleaned up by an unspecified
-   janitorial process: the node does not typically know a priori that it
-   will be disconnected, and it cannot send a DNS update using the
-   correct source address to remove a record.
-
-   A problem with defining the clean-up process is that it is difficult
-   to ensure that a specific IP address and the corresponding record are
-   no longer being used.  Considering the huge address space, and the
-   unlikelihood of collision within 64 bits of the interface
-   identifiers, a process that would remove the record after no traffic
-   has been seen from a node in a long period of time (e.g., a month or
-   year) might be one possible approach.
-
-   To insert or update the record, the node must discover the DNS server
-   to send the update to somehow, similar to as discussed in
-   Section 6.2.  One way to automate this is looking up the DNS server
-   authoritative (e.g., through SOA record) for the IP address being
-   updated, but the security material (unless the IP address-based
-   authorization is trusted) must also be established by some other
-   means.
-
-
-
-
-Durand, et al.               Informational                     [Page 16]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   One should note that Cryptographically Generated Addresses (CGAs)
-   [RFC3972] may require a slightly different kind of treatment.  CGAs
-   are addresses where the interface identifier is calculated from a
-   public key, a modifier (used as a nonce), the subnet prefix, and
-   other data.  Depending on the usage profile, CGAs might or might not
-   be changed periodically due to, e.g., privacy reasons.  As the CGA
-   address is not predictable, a reverse record can only reasonably be
-   inserted in the DNS by the node that generates the address.
-
-7.4.  DDNS with DHCP
-
-   With DHCPv4, the reverse DNS name is typically already inserted to
-   the DNS that reflects the name (e.g., "dhcp-67.example.com").  One
-   can assume similar practice may become commonplace with DHCPv6 as
-   well; all such mappings would be pre-configured and would require no
-   updating.
-
-   If a more explicit control is required, similar considerations as
-   with SLAAC apply, except for the fact that typically one must update
-   a reverse DNS record instead of inserting one (if an address
-   assignment policy that reassigns disused addresses is adopted) and
-   updating a record seems like a slightly more difficult thing to
-   secure.  However, it is yet uncertain how DHCPv6 is going to be used
-   for address assignment.
-
-   Note that when using DHCP, either the host or the DHCP server could
-   perform the DNS updates; see the implications in Section 6.2.
-
-   If disused addresses were to be reassigned, host-based DDNS reverse
-   updates would need policy considerations for DNS record modification,
-   as noted above.  On the other hand, if disused address were not to be
-   assigned, host-based DNS reverse updates would have similar
-   considerations as SLAAC in Section 7.3.  Server-based updates have
-   similar properties except that the janitorial process could be
-   integrated with DHCP address assignment.
-
-7.5.  DDNS with Dynamic Prefix Delegation
-
-   In cases where a prefix, instead of an address, is being used and
-   updated, one should consider what is the location of the server where
-   DDNS updates are made.  That is, where the DNS server is located:
-
-   1.  At the same organization as the prefix delegator.
-
-   2.  At the site where the prefixes are delegated to.  In this case,
-       the authority of the DNS reverse zone corresponding to the
-       delegated prefix is also delegated to the site.
-
-
-
-
-Durand, et al.               Informational                     [Page 17]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   3.  Elsewhere; this implies a relationship between the site and where
-       the DNS server is located, and such a relationship should be
-       rather straightforward to secure as well.  Like in the previous
-       case, the authority of the DNS reverse zone is also delegated.
-
-   In the first case, managing the reverse DNS (delegation) is simpler
-   as the DNS server and the prefix delegator are in the same
-   administrative domain (as there is no need to delegate anything at
-   all); alternatively, the prefix delegator might forgo DDNS reverse
-   capability altogether, and use, e.g., wildcard records (as described
-   in Section 7.2).  In the other cases, it can be slightly more
-   difficult, particularly as the site will have to configure the DNS
-   server to be authoritative for the delegated reverse zone, implying
-   automatic configuration of the DNS server -- as the prefix may be
-   dynamic.
-
-   Managing the DDNS reverse updates is typically simple in the second
-   case, as the updated server is located at the local site, and
-   arguably IP address-based authentication could be sufficient (or if
-   not, setting up security relationships would be simpler).  As there
-   is an explicit (security) relationship between the parties in the
-   third case, setting up the security relationships to allow reverse
-   DDNS updates should be rather straightforward as well (but IP
-   address-based authentication might not be acceptable).  In the first
-   case, however, setting up and managing such relationships might be a
-   lot more difficult.
-
-8.  Miscellaneous DNS Considerations
-
-   This section describes miscellaneous considerations about DNS that
-   seem related to IPv6, for which no better place has been found in
-   this document.
-
-8.1.  NAT-PT with DNS-ALG
-
-   The DNS-ALG component of NAT-PT [RFC2766] mangles A records to look
-   like AAAA records to the IPv6-only nodes.  Numerous problems have
-   been identified with [WIP-AD2005].  This is a strong reason not to
-   use NAT-PT in the first place.
-
-8.2.  Renumbering Procedures and Applications' Use of DNS
-
-   One of the most difficult problems of systematic IP address
-   renumbering procedures [RFC4192] is that an application that looks up
-   a DNS name disregards information such as TTL, and uses the result
-   obtained from DNS as long as it happens to be stored in the memory of
-   the application.  For applications that run for a long time, this
-
-
-
-
-Durand, et al.               Informational                     [Page 18]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   could be days, weeks, or even months.  Some applications may be
-   clever enough to organize the data structures and functions in such a
-   manner that lookups get refreshed now and then.
-
-   While the issue appears to have a clear solution, "fix the
-   applications", practically, this is not reasonable immediate advice.
-   The TTL information is not typically available in the APIs and
-   libraries (so, the advice becomes "fix the applications, APIs, and
-   libraries"), and a lot more analysis is needed on how to practically
-   go about to achieve the ultimate goal of avoiding using the names
-   longer than expected.
-
-9.  Acknowledgements
-
-   Some recommendations (Section 4.3, Section 5.1) about IPv6 service
-   provisioning were moved here from [RFC4213] by Erik Nordmark and Bob
-   Gilligan.  Havard Eidnes and Michael Patton provided useful feedback
-   and improvements.  Scott Rose, Rob Austein, Masataka Ohta, and Mark
-   Andrews helped in clarifying the issues regarding additional data and
-   the use of TTL.  Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei
-   Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided
-   useful feedback during the WG last call.  Thomas Narten provided
-   extensive feedback during the IESG evaluation.
-
-10.  Security Considerations
-
-   This document reviews the operational procedures for IPv6 DNS
-   operations and does not have security considerations in itself.
-
-   However, it is worth noting that in particular with Dynamic DNS
-   updates, security models based on the source address validation are
-   very weak and cannot be recommended -- they could only be considered
-   in the environments where ingress filtering [RFC3704] has been
-   deployed.  On the other hand, it should be noted that setting up an
-   authorization mechanism (e.g., a shared secret, or public-private
-   keys) between a node and the DNS server has to be done manually, and
-   may require quite a bit of time and expertise.
-
-   To re-emphasize what was already stated, the reverse+forward DNS
-   check provides very weak security at best, and the only
-   (questionable) security-related use for them may be in conjunction
-   with other mechanisms when authenticating a user.
-
-
-
-
-
-
-
-
-
-Durand, et al.               Informational                     [Page 19]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-11.  References
-
-11.1.  Normative References
-
-   [RFC1034]     Mockapetris, P., "Domain names - concepts and
-                 facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC2136]     Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
-                 "Dynamic Updates in the Domain Name System (DNS
-                 UPDATE)", RFC 2136, April 1997.
-
-   [RFC2181]     Elz, R. and R. Bush, "Clarifications to the DNS
-                 Specification", RFC 2181, July 1997.
-
-   [RFC2182]     Elz, R., Bush, R., Bradner, S., and M. Patton,
-                 "Selection and Operation of Secondary DNS Servers",
-                 BCP 16, RFC 2182, July 1997.
-
-   [RFC2462]     Thomson, S. and T. Narten, "IPv6 Stateless Address
-                 Autoconfiguration", RFC 2462, December 1998.
-
-   [RFC2671]     Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-                 RFC 2671, August 1999.
-
-   [RFC2821]     Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
-                 April 2001.
-
-   [RFC3007]     Wellington, B., "Secure Domain Name System (DNS)
-                 Dynamic Update", RFC 3007, November 2000.
-
-   [RFC3041]     Narten, T. and R. Draves, "Privacy Extensions for
-                 Stateless Address Autoconfiguration in IPv6", RFC 3041,
-                 January 2001.
-
-   [RFC3056]     Carpenter, B. and K. Moore, "Connection of IPv6 Domains
-                 via IPv4 Clouds", RFC 3056, February 2001.
-
-   [RFC3152]     Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
-                 August 2001.
-
-   [RFC3315]     Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
-                 and M. Carney, "Dynamic Host Configuration Protocol for
-                 IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-   [RFC3363]     Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
-                 Hain, "Representing Internet Protocol version 6 (IPv6)
-                 Addresses in the Domain Name System (DNS)", RFC 3363,
-                 August 2002.
-
-
-
-Durand, et al.               Informational                     [Page 20]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   [RFC3364]     Austein, R., "Tradeoffs in Domain Name System (DNS)
-                 Support for Internet Protocol version 6 (IPv6)",
-                 RFC 3364, August 2002.
-
-   [RFC3596]     Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
-                 "DNS Extensions to Support IP Version 6", RFC 3596,
-                 October 2003.
-
-   [RFC3646]     Droms, R., "DNS Configuration options for Dynamic Host
-                 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
-                 December 2003.
-
-   [RFC3736]     Droms, R., "Stateless Dynamic Host Configuration
-                 Protocol (DHCP) Service for IPv6", RFC 3736,
-                 April 2004.
-
-   [RFC3879]     Huitema, C. and B. Carpenter, "Deprecating Site Local
-                 Addresses", RFC 3879, September 2004.
-
-   [RFC3901]     Durand, A. and J. Ihren, "DNS IPv6 Transport
-                 Operational Guidelines", BCP 91, RFC 3901,
-                 September 2004.
-
-   [RFC4038]     Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
-                 Castro, "Application Aspects of IPv6 Transition",
-                 RFC 4038, March 2005.
-
-   [RFC4074]     Morishita, Y. and T. Jinmei, "Common Misbehavior
-                 Against DNS Queries for IPv6 Addresses", RFC 4074,
-                 May 2005.
-
-   [RFC4192]     Baker, F., Lear, E., and R. Droms, "Procedures for
-                 Renumbering an IPv6 Network without a Flag Day",
-                 RFC 4192, September 2005.
-
-   [RFC4193]     Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
-                 Addresses", RFC 4193, October 2005.
-
-   [RFC4291]     Hinden, R. and S. Deering, "IP Version 6 Addressing
-                 Architecture", RFC 4291, February 2006.
-
-   [RFC4339]     Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
-                 Information Approaches", RFC 4339, February 2006.
-
-
-
-
-
-
-
-
-Durand, et al.               Informational                     [Page 21]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-11.2.  Informative References
-
-   [RFC2766]     Tsirtsis, G. and P. Srisuresh, "Network Address
-                 Translation - Protocol Translation (NAT-PT)", RFC 2766,
-                 February 2000.
-
-   [RFC2782]     Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
-                 for specifying the location of services (DNS SRV)",
-                 RFC 2782, February 2000.
-
-   [RFC2826]     Internet Architecture Board, "IAB Technical Comment on
-                 the Unique DNS Root", RFC 2826, May 2000.
-
-   [RFC3704]     Baker, F. and P. Savola, "Ingress Filtering for
-                 Multihomed Networks", BCP 84, RFC 3704, March 2004.
-
-   [RFC3972]     Aura, T., "Cryptographically Generated Addresses
-                 (CGA)", RFC 3972, March 2005.
-
-   [RFC4025]     Richardson, M., "A Method for Storing IPsec Keying
-                 Material in DNS", RFC 4025, March 2005.
-
-   [RFC4213]     Nordmark, E. and R. Gilligan, "Basic Transition
-                 Mechanisms for IPv6 Hosts and Routers", RFC 4213,
-                 October 2005.
-
-   [RFC4215]     Wiljakka, J., "Analysis on IPv6 Transition in Third
-                 Generation Partnership Project (3GPP) Networks",
-                 RFC 4215, October 2005.
-
-   [RFC4380]     Huitema, C., "Teredo: Tunneling IPv6 over UDP through
-                 Network Address Translations (NATs)", RFC 4380,
-                 February 2006.
-
-   [TC-TEST]     Jinmei, T., "Thread "RFC2181 section 9.1: TC bit
-                 handling and additional data" on DNSEXT mailing list,
-                 Message-
-                 Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August
-                 1, 2005, <http://ops.ietf.org/lists/namedroppers/
-                 namedroppers.2005/msg01102.html>.
-
-   [WIP-AD2005]  Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
-                 Experimental", Work in Progress, October 2005.
-
-   [WIP-DC2005]  Durand, A. and T. Chown, "To publish, or not to
-                 publish, that is the question", Work in Progress,
-                 October 2005.
-
-
-
-
-Durand, et al.               Informational                     [Page 22]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   [WIP-H2005]   Huston, G., "6to4 Reverse DNS Delegation
-                 Specification", Work in Progress, November 2005.
-
-   [WIP-J2006]   Jeong, J., "IPv6 Router Advertisement Option for DNS
-                 Configuration", Work in Progress, January 2006.
-
-   [WIP-LB2005]  Larson, M. and P. Barber, "Observed DNS Resolution
-                 Misbehavior", Work in Progress, February 2006.
-
-   [WIP-O2004]   Ohta, M., "Preconfigured DNS Server Addresses", Work in
-                 Progress, February 2004.
-
-   [WIP-R2006]   Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
-                 Considered Harmful", Work in Progress, January 2006.
-
-   [WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual
-                 Stack IPv6 on by Default", Work in Progress, July 2004.
-
-   [WIP-S2005a]  Stapp, M., "The DHCP Client FQDN Option", Work in
-                 Progress, March 2006.
-
-   [WIP-S2005b]  Stapp, M., "A DNS RR for Encoding DHCP Information
-                 (DHCID RR)", Work in Progress, March 2006.
-
-   [WIP-S2005c]  Senie, D., "Encouraging the use of DNS IN-ADDR
-                 Mapping", Work in Progress, August 2005.
-
-   [WIP-SV2005]  Stapp, M. and B. Volz, "Resolution of FQDN Conflicts
-                 among DHCP Clients", Work in Progress, March 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al.               Informational                     [Page 23]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-Appendix A.  Unique Local Addressing Considerations for DNS
-
-   Unique local addresses [RFC4193] have replaced the now-deprecated
-   site-local addresses [RFC3879].  From the perspective of the DNS, the
-   locally generated unique local addresses (LUL) and site-local
-   addresses have similar properties.
-
-   The interactions with DNS come in two flavors: forward and reverse
-   DNS.
-
-   To actually use local addresses within a site, this implies the
-   deployment of a "split-faced" or a fragmented DNS name space, for the
-   zones internal to the site, and the outsiders' view to it.  The
-   procedures to achieve this are not elaborated here.  The implication
-   is that local addresses must not be published in the public DNS.
-
-   To facilitate reverse DNS (if desired) with local addresses, the stub
-   resolvers must look for DNS information from the local DNS servers,
-   not, e.g., starting from the root servers, so that the local
-   information may be provided locally.  Note that the experience of
-   private addresses in IPv4 has shown that the root servers get loaded
-   for requests for private address lookups in any case.  This
-   requirement is discussed in [RFC4193].
-
-Appendix B.  Behavior of Additional Data in IPv4/IPv6 Environments
-
-   DNS responses do not always fit in a single UDP packet.  We'll
-   examine the cases that happen when this is due to too much data in
-   the Additional section.
-
-B.1.  Description of Additional Data Scenarios
-
-   There are two kinds of additional data:
-
-   1.  "critical" additional data; this must be included in all
-       scenarios, with all the RRsets, and
-
-   2.  "courtesy" additional data; this could be sent in full, with only
-       a few RRsets, or with no RRsets, and can be fetched separately as
-       well, but at the cost of additional queries.
-
-   The responding server can algorithmically determine which type the
-   additional data is by checking whether it's at or below a zone cut.
-
-   Only those additional data records (even if sometimes carelessly
-   termed "glue") are considered "critical" or real "glue" if and only
-   if they meet the above-mentioned condition, as specified in Section
-   4.2.1 of [RFC1034].
-
-
-
-Durand, et al.               Informational                     [Page 24]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-   Remember that resource record sets (RRsets) are never "broken up", so
-   if a name has 4 A records and 5 AAAA records, you can either return
-   all 9, all 4 A records, all 5 AAAA records, or nothing.  In
-   particular, notice that for the "critical" additional data getting
-   all the RRsets can be critical.
-
-   In particular, [RFC2181] specifies (in Section 9) that:
-
-   a.  if all the "critical" RRsets do not fit, the sender should set
-       the TC bit, and the recipient should discard the whole response
-       and retry using mechanism allowing larger responses such as TCP.
-
-   b.  "courtesy" additional data should not cause the setting of the TC
-       bit, but instead all the non-fitting additional data RRsets
-       should be removed.
-
-   An example of the "courtesy" additional data is A/AAAA records in
-   conjunction with MX records as shown in Section 4.4; an example of
-   the "critical" additional data is shown below (where getting both the
-   A and AAAA RRsets is critical with respect to the NS RR):
-
-      child.example.com.    IN   NS ns.child.example.com.
-      ns.child.example.com. IN    A 192.0.2.1
-      ns.child.example.com. IN AAAA 2001:db8::1
-
-   When there is too much "courtesy" additional data, at least the non-
-   fitting RRsets should be removed [RFC2181]; however, as the
-   additional data is not critical, even all of it could be safely
-   removed.
-
-   When there is too much "critical" additional data, TC bit will have
-   to be set, and the recipient should ignore the response and retry
-   using TCP; if some data were to be left in the UDP response, the
-   issue is which data could be retained.
-
-   However, the practice may differ from the specification.  Testing and
-   code analysis of three recent implementations [TC-TEST] confirm this.
-   None of the tested implementations have a strict separation of
-   critical and courtesy additional data, while some forms of additional
-   data may be treated preferably.  All the implementations remove some
-   (critical or courtesy) additional data RRsets without setting the TC
-   bit if the response would not otherwise fit.
-
-   Failing to discard the response with the TC bit or omitting critical
-   information but not setting the TC bit lead to an unrecoverable
-   problem.  Omitting only some of the RRsets if all would not fit (but
-   not setting the TC bit) leads to a performance problem.  These are
-   discussed in the next two subsections.
-
-
-
-Durand, et al.               Informational                     [Page 25]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-B.2.  Which Additional Data to Keep, If Any?
-
-   NOTE: omitting some critical additional data instead of setting the
-   TC bit violates a 'should' in Section 9 of RFC2181.  However, as many
-   implementations still do that [TC-TEST], operators need to understand
-   its implications, and we describe that behavior as well.
-
-   If the implementation decides to keep as much data (whether
-   "critical" or "courtesy") as possible in the UDP responses, it might
-   be tempting to use the transport of the DNS query as a hint in either
-   of these cases: return the AAAA records if the query was done over
-   IPv6, or return the A records if the query was done over IPv4.
-   However, this breaks the model of independence of DNS transport and
-   resource records, as noted in Section 1.2.
-
-   With courtesy additional data, as long as enough RRsets will be
-   removed so that TC will not be set, it is allowed to send as many
-   complete RRsets as the implementations prefers.  However, the
-   implementations are also free to omit all such RRsets, even if
-   complete.  Omitting all the RRsets (when removing only some would
-   suffice) may create a performance penalty, whereby the client may
-   need to issue one or more additional queries to obtain necessary
-   and/or consistent information.
-
-   With critical additional data, the alternatives are either returning
-   nothing (and absolutely requiring a retry with TCP) or returning
-   something (working also in the case if the recipient does not discard
-   the response and retry using TCP) in addition to setting the TC bit.
-   If the process for selecting "something" from the critical data would
-   otherwise be practically "flipping the coin" between A and AAAA
-   records, it could be argued that if one looked at the transport of
-   the query, it would have a larger possibility of being right than
-   just 50/50.  In other words, if the returned critical additional data
-   would have to be selected somehow, using something more sophisticated
-   than a random process would seem justifiable.
-
-   That is, leaving in some intelligently selected critical additional
-   data is a trade-off between creating an optimization for those
-   resolvers that ignore the "should discard" recommendation and causing
-   a protocol problem by propagating inconsistent information about
-   "critical" records in the caches.
-
-   Similarly, leaving in the complete courtesy additional data RRsets
-   instead of removing all the RRsets is a performance trade-off as
-   described in the next section.
-
-
-
-
-
-
-Durand, et al.               Informational                     [Page 26]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-B.3.  Discussion of the Potential Problems
-
-   As noted above, the temptation for omitting only some of the
-   additional data could be problematic.  This is discussed more below.
-
-   For courtesy additional data, this causes a potential performance
-   problem as this requires that the clients issue re-queries for the
-   potentially omitted RRsets.  For critical additional data, this
-   causes a potential unrecoverable problem if the response is not
-   discarded and the query not re-tried with TCP, as the nameservers
-   might be reachable only through the omitted RRsets.
-
-   If an implementation would look at the transport used for the query,
-   it is worth remembering that often the host using the records is
-   different from the node requesting them from the authoritative DNS
-   server (or even a caching resolver).  So, whichever version the
-   requestor (e.g., a recursive server in the middle) uses makes no
-   difference to the ultimate user of the records, whose transport
-   capabilities might differ from those of the requestor.  This might
-   result in, e.g., inappropriately returning A records to an IPv6-only
-   node, going through a translation, or opening up another IP-level
-   session (e.g., a Packet Data Protocol (PDP) context [RFC4215]).
-   Therefore, at least in many scenarios, it would be very useful if the
-   information returned would be consistent and complete -- or if that
-   is not feasible, leave it to the client to query again.
-
-   The problem of too much additional data seems to be an operational
-   one: the zone administrator entering too many records that will be
-   returned truncated (or missing some RRsets, depending on
-   implementations) to the users.  A protocol fix for this is using
-   Extension Mechanisms for DNS (EDNS0) [RFC2671] to signal the capacity
-   for larger UDP packet sizes, pushing up the relevant threshold.
-   Further, DNS server implementations should omit courtesy additional
-   data completely rather than including only some RRsets [RFC2181].  An
-   operational fix for this is having the DNS server implementations
-   return a warning when the administrators create zones that would
-   result in too much additional data being returned.  Further, DNS
-   server implementations should warn of or disallow such zone
-   configurations that are recursive or otherwise difficult to manage by
-   the protocol.
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al.               Informational                     [Page 27]
-
-RFC 4472              Considerations with IPv6 DNS            April 2006
-
-
-Authors' Addresses
-
-   Alain Durand
-   Comcast
-   1500 Market St.
-   Philadelphia, PA  19102
-   USA
-
-   EMail: Alain_Durand@cable.comcast.com
-
-
-   Johan Ihren
-   Autonomica
-   Bellmansgatan 30
-   SE-118 47 Stockholm
-   Sweden
-
-   EMail: johani@autonomica.se
-
-
-   Pekka Savola
-   CSC/FUNET
-   Espoo
-   Finland
-
-   EMail: psavola@funet.fi
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al.               Informational                     [Page 28]
-
-RFC 4472              Considerations with IPv6 DNS            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).
-
-
-
-
-
-
-
-Durand, et al.               Informational                     [Page 29]
-
diff --git a/doc/rfc/rfc4509.txt b/doc/rfc/rfc4509.txt
deleted file mode 100644
index 4eaf296c..00000000
--- a/doc/rfc/rfc4509.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        W. Hardaker
-Request for Comments: 4509                                        Sparta
-Category: Standards Track                                       May 2006
-
-
- Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
-
-
-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 specifies how to use the SHA-256 digest type in DNS
-   Delegation Signer (DS) Resource Records (RRs).  DS records, when
-   stored in a parent zone, point to DNSKEYs in a child zone.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Implementing the SHA-256 Algorithm for DS Record Support ........2
-      2.1. DS Record Field Values .....................................2
-      2.2. DS Record with SHA-256 Wire Format .........................3
-      2.3. Example DS Record Using SHA-256 ............................3
-   3. Implementation Requirements .....................................3
-   4. Deployment Considerations .......................................4
-   5. IANA Considerations .............................................4
-   6. Security Considerations .........................................4
-      6.1. Potential Digest Type Downgrade Attacks ....................4
-      6.2. SHA-1 vs SHA-256 Considerations for DS Records .............5
-   7. Acknowledgements ................................................5
-   8. References ......................................................6
-      8.1. Normative References .......................................6
-      8.2. Informative References .....................................6
-
-
-
-
-
-
-
-
-Hardaker                    Standards Track                     [Page 1]
-
-RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
-
-
-1.  Introduction
-
-   The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
-   zones to distribute a cryptographic digest of one key in a child's
-   DNSKEY RRset.  The DS RRset is signed by at least one of the parent
-   zone's private zone data signing keys for each algorithm in use by
-   the parent.  Each signature is published in an RRSIG resource record,
-   owned by the same domain as the DS RRset, with a type covered of DS.
-
-   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 [RFC2119].
-
-2.  Implementing the SHA-256 Algorithm for DS Record Support
-
-   This document specifies that the digest type code 2 has been assigned
-   to SHA-256 [SHA256] [SHA256CODE] for use within DS records.  The
-   results of the digest algorithm MUST NOT be truncated, and the entire
-   32 byte digest result is to be published in the DS record.
-
-2.1.  DS Record Field Values
-
-   Using the SHA-256 digest algorithm within a DS record will make use
-   of the following DS-record fields:
-
-   Digest type: 2
-
-   Digest: A SHA-256 bit digest value calculated by using the following
-      formula ("|" denotes concatenation).  The resulting value is not
-      truncated, and the entire 32 byte result is to be used in the
-      resulting DS record and related calculations.
-
-        digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
-
-      where DNSKEY RDATA is defined by [RFC4034] as:
-
-        DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
-
-   The Key Tag field and Algorithm fields remain unchanged by this
-   document and are specified in the [RFC4034] specification.
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                    Standards Track                     [Page 2]
-
-RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
-
-
-2.2.  DS Record with SHA-256 Wire Format
-
-   The resulting on-the-wire format for the resulting DS record will be
-   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
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |           Key Tag             |  Algorithm    | DigestType=2  |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     /                                                               /
-     /            Digest  (length for SHA-256 is 32 bytes)           /
-     /                                                               /
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-2.3.  Example DS Record Using SHA-256
-
-   The following is an example DNSKEY and matching DS record.  This
-   DNSKEY record comes from the example DNSKEY/DS records found in
-   section 5.4 of [RFC4034].
-
-   The DNSKEY record:
-
-   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
-                                                fwJr1AYtsmx3TGkJaNXVbfi/
-                                                2pHm822aJ5iI9BMzNXxeYCmZ
-                                                DRD99WYwYqUSdjMmmAphXdvx
-                                                egXd/M5+X7OrzKBaMbCVdFLU
-                                                Uh6DhweJBjEVv5f2wwjM9Xzc
-                                                nOf+EPbtG9DMBmADjFDc2w/r
-                                                ljwvFw==
-                                                ) ;  key id = 60485
-
-   The resulting DS record covering the above DNSKEY record using a
-   SHA-256 digest:
-
-   dskey.example.com. 86400 IN DS 60485 5 2   ( D4B7D520E7BB5F0F67674A0C
-                                                CEB1E3E0614B93C4F9E99B83
-                                                83F6A1E4469DA50A )
-
-3.  Implementation Requirements
-
-   Implementations MUST support the use of the SHA-256 algorithm in DS
-   RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1
-   digests if DS RRs with SHA-256 digests are present in the DS RRset.
-
-
-
-
-
-
-Hardaker                    Standards Track                     [Page 3]
-
-RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
-
-
-4.  Deployment Considerations
-
-   If a validator does not support the SHA-256 digest type and no other
-   DS RR exists in a zone's DS RRset with a supported digest type, then
-   the validator has no supported authentication path leading from the
-   parent to the child.  The resolver should treat this case as it would
-   the case of an authenticated NSEC RRset proving that no DS RRset
-   exists, as described in [RFC4035], Section 5.2.
-
-   Because zone administrators cannot control the deployment speed of
-   support for SHA-256 in validators that may be referencing any of
-   their zones, zone operators should consider deploying both SHA-1 and
-   SHA-256 based DS records.  This should be done for every DNSKEY for
-   which DS records are being generated.  Whether to make use of both
-   digest types and for how long is a policy decision that extends
-   beyond the scope of this document.
-
-5.  IANA Considerations
-
-   Only one IANA action is required by this document:
-
-   The Digest Type to be used for supporting SHA-256 within DS records
-   has been assigned by IANA.
-
-   At the time of this writing, the current digest types assigned for
-   use in DS records are as follows:
-
-      VALUE     Digest Type          Status
-        0       Reserved                -
-        1       SHA-1                MANDATORY
-        2       SHA-256              MANDATORY
-      3-255    Unassigned               -
-
-6.  Security Considerations
-
-6.1.  Potential Digest Type Downgrade Attacks
-
-   A downgrade attack from a stronger digest type to a weaker one is
-   possible if all of the following are true:
-
-   o  A zone includes multiple DS records for a given child's DNSKEY,
-      each of which uses a different digest type.
-
-   o  A validator accepts a weaker digest even if a stronger one is
-      present but invalid.
-
-
-
-
-
-
-Hardaker                    Standards Track                     [Page 4]
-
-RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
-
-
-   For example, if the following conditions are all true:
-
-   o  Both SHA-1 and SHA-256 based digests are published in DS records
-      within a parent zone for a given child zone's DNSKEY.
-
-   o  The DS record with the SHA-1 digest matches the digest computed
-      using the child zone's DNSKEY.
-
-   o  The DS record with the SHA-256 digest fails to match the digest
-      computed using the child zone's DNSKEY.
-
-   Then, if the validator accepts the above situation as secure, then
-   this can be used as a downgrade attack since the stronger SHA-256
-   digest is ignored.
-
-6.2.  SHA-1 vs. SHA-256 Considerations for DS Records
-
-   Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
-   implementations allow for it.  SHA-256 is widely believed to be more
-   resilient to attack than SHA-1, and confidence in SHA-1's strength is
-   being eroded by recently announced attacks.  Regardless of whether
-   the attacks on SHA-1 will affect DNSSEC, it is believed (at the time
-   of this writing) that SHA-256 is the better choice for use in DS
-   records.
-
-   At the time of this publication, the SHA-256 digest algorithm is
-   considered sufficiently strong for the immediate future.  It is also
-   considered sufficient for use in DNSSEC DS RRs for the immediate
-   future.  However, future published attacks may weaken the usability
-   of this algorithm within the DS RRs.  It is beyond the scope of this
-   document to speculate extensively on the cryptographic strength of
-   the SHA-256 digest algorithm.
-
-   Likewise, it is also beyond the scope of this document to specify
-   whether or for how long SHA-1 based DS records should be
-   simultaneously published alongside SHA-256 based DS records.
-
-7.  Acknowledgements
-
-   This document is a minor extension to the existing DNSSEC documents
-   and those authors are gratefully appreciated for the hard work that
-   went into the base documents.
-
-   The following people contributed to portions of this document in some
-   fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
-   Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
-   Weiler.
-
-
-
-
-Hardaker                    Standards Track                     [Page 5]
-
-RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4033]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
-                Rose, "DNS Security Introduction and Requirements", RFC
-                4033, March 2005.
-
-   [RFC4034]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
-                Rose, "Resource Records for the DNS Security
-                Extensions", RFC 4034, March 2005.
-
-   [RFC4035]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
-                Rose, "Protocol Modifications for the DNS Security
-                Extensions", RFC 4035, March 2005.
-
-   [SHA256]     National Institute of Standards and Technology, "Secure
-                Hash Algorithm. NIST FIPS 180-2", August 2002.
-
-8.2.  Informative References
-
-   [SHA256CODE] Eastlake, D., "US Secure Hash Algorithms (SHA)", Work in
-                Progress.
-
-Author's Address
-
-   Wes Hardaker
-   Sparta
-   P.O. Box 382
-   Davis, CA  95617
-   USA
-
-   EMail: hardaker@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                    Standards Track                     [Page 6]
-
-RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 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).
-
-
-
-
-
-
-
-Hardaker                    Standards Track                     [Page 7]
-
diff --git a/doc/rfc/rfc4634.txt b/doc/rfc/rfc4634.txt
deleted file mode 100644
index b672df8a..00000000
--- a/doc/rfc/rfc4634.txt
+++ /dev/null
@@ -1,6051 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 4634                                 Motorola Labs
-Updates: 3174                                                  T. Hansen
-Category: Informational                                        AT&T Labs
-                                                               July 2006
-
-
-              US Secure Hash Algorithms (SHA and HMAC-SHA)
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   The United States of America has adopted a suite of Secure Hash
-   Algorithms (SHAs), including four beyond SHA-1, as part of a Federal
-   Information Processing Standard (FIPS), specifically SHA-224 (RFC
-   3874), SHA-256, SHA-384, and SHA-512.  The purpose of this document
-   is to make source code performing these hash functions conveniently
-   available to the Internet community.  The sample code supports input
-   strings of arbitrary bit length.  SHA-1's sample code from RFC 3174
-   has also been updated to handle input strings of arbitrary bit
-   length.  Most of the text herein was adapted by the authors from FIPS
-   180-2.
-
-   Code to perform SHA-based HMACs, with arbitrary bit length text, is
-   also included.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 1]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-Table of Contents
-
-   1. Overview of Contents ............................................3
-      1.1. License ....................................................4
-   2. Notation for Bit Strings and Integers ...........................4
-   3. Operations on Words .............................................5
-   4. Message Padding and Parsing .....................................6
-      4.1. SHA-224 and SHA-256 ........................................7
-      4.2. SHA-384 and SHA-512 ........................................8
-   5. Functions and Constants Used ....................................9
-      5.1. SHA-224 and SHA-256 ........................................9
-      5.2. SHA-384 and SHA-512 .......................................10
-   6. Computing the Message Digest ...................................11
-      6.1. SHA-224 and SHA-256 Initialization ........................11
-      6.2. SHA-224 and SHA-256 Processing ............................11
-      6.3. SHA-384 and SHA-512 Initialization ........................13
-      6.4. SHA-384 and SHA-512 Processing ............................14
-   7. SHA-Based HMACs ................................................15
-   8. C Code for SHAs ................................................15
-      8.1. The .h File ...............................................18
-      8.2. The SHA Code ..............................................24
-           8.2.1. sha1.c .............................................24
-           8.2.2. sha224-256.c .......................................33
-           8.2.3. sha384-512.c .......................................45
-           8.2.4. usha.c .............................................67
-           8.2.5. sha-private.h ......................................72
-      8.3. The HMAC Code .............................................73
-      8.4. The Test Driver ...........................................78
-   9. Security Considerations .......................................106
-   10. Normative References .........................................106
-   11. Informative References .......................................106
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 2]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-1.  Overview of Contents
-
-   NOTE: Much of the text below is taken from [FIPS180-2] and assertions
-   therein of the security of the algorithms described are made by the
-   US Government, the author of [FIPS180-2], and not by the authors of
-   this document.
-
-   The text below specifies Secure Hash Algorithms, SHA-224 [RFC3874],
-   SHA-256, SHA-384, and SHA-512, for computing a condensed
-   representation of a message or a data file. (SHA-1 is specified in
-   [RFC3174].)  When a message of any length < 2^64 bits (for SHA-224
-   and SHA-256) or < 2^128 bits (for SHA-384 and SHA-512) is input to
-   one of these algorithms, the result is an output called a message
-   digest.  The message digests range in length from 224 to 512 bits,
-   depending on the algorithm.  Secure hash algorithms are typically
-   used with other cryptographic algorithms, such as digital signature
-   algorithms and keyed hash authentication codes, or in the generation
-   of random numbers [RFC4086].
-
-   The four algorithms specified in this document are called secure
-   because it is computationally infeasible to (1) find a message that
-   corresponds to a given message digest, or (2) find two different
-   messages that produce the same message digest.  Any change to a
-   message in transit will, with very high probability, result in a
-   different message digest.  This will result in a verification failure
-   when the secure hash algorithm is used with a digital signature
-   algorithm or a keyed-hash message authentication algorithm.
-
-   The code provided herein supports input strings of arbitrary bit
-   length.  SHA-1's sample code from [RFC3174] has also been updated to
-   handle input strings of arbitrary bit length.  See Section 1.1 for
-   license information for this code.
-
-   Section 2 below defines the terminology and functions used as
-   building blocks to form these algorithms.  Section 3 describes the
-   fundamental operations on words from which these algorithms are
-   built.  Section 4 describes how messages are padded up to an integral
-   multiple of the required block size and then parsed into blocks.
-   Section 5 defines the constants and the composite functions used to
-   specify these algorithms.  Section 6 gives the actual specification
-   for the SHA-224, SHA-256, SHA-384, and SHA-512 functions.  Section 7
-   provides pointers to the specification of HMAC keyed message
-   authentication codes based on the SHA algorithms.  Section 8 gives
-   sample code for the SHA algorithms and Section 9 code for SHA-based
-   HMACs.  The SHA-based HMACs will accept arbitrary bit length text.
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 3]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-1.1.  License
-
-   Permission is granted for all uses, commercial and non-commercial, of
-   the sample code found in Section 8.  Royalty free license to use,
-   copy, modify and distribute the software found in Section 8 is
-   granted, provided that this document is identified in all material
-   mentioning or referencing this software, and provided that
-   redistributed derivative works do not contain misleading author or
-   version information.
-
-   The authors make no representations concerning either the
-   merchantability of this software or the suitability of this software
-   for any particular purpose.  It is provided "as is" without express
-   or implied warranty of any kind.
-
-2.  Notation for Bit Strings and Integers
-
-   The following terminology related to bit strings and integers will be
-   used:
-
-    a.  A hex digit is an element of the set {0, 1, ... , 9, A, ... ,
-        F}.  A hex digit is the representation of a 4-bit string.
-        Examples: 7 = 0111, A = 1010.
-
-    b.  A word equals a 32-bit or 64-bit string, which may be
-        represented as a sequence of 8 or 16 hex digits, respectively.
-        To convert a word to hex digits, each 4-bit string is converted
-        to its hex equivalent as described in (a) above.  Example:
-
-        1010 0001 0000 0011 1111 1110 0010 0011 = A103FE23.
-
-        Throughout this document, the "big-endian" convention is used
-        when expressing both 32-bit and 64-bit words, so that within
-        each word the most significant bit is shown in the left-most bit
-        position.
-
-    c.  An integer may be represented as a word or pair of words.
-
-        An integer between 0 and 2^32 - 1 inclusive may be represented
-        as a 32-bit word.  The least significant four bits of the
-        integer are represented by the right-most hex digit of the word
-        representation.  Example: the integer 291 = 2^8+2^5+2^1+2^0 =
-        256+32+2+1 is represented by the hex word 00000123.
-
-        The same holds true for an integer between 0 and 2^64-1
-        inclusive, which may be represented as a 64-bit word.
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 4]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        If Z is an integer, 0 <= z < 2^64, then z = (2^32)x + y where 0
-        <= x < 2^32 and 0 <= y < 2^32.  Since x and y can be represented
-        as words X and Y, respectively, z can be represented as the pair
-        of words (X,Y).
-
-    d.  block = 512-bit or 1024-bit string.  A block (e.g., B) may be
-        represented as a sequence of 32-bit or 64-bit words.
-
-3.  Operations on Words
-
-   The following logical operators will be applied to words in all four
-   hash operations specified herein.  SHA-224 and SHA-256 operate on
-   32-bit words, while SHA-384 and SHA-512 operate on 64-bit words.
-
-   In the operations below, x<<n is obtained as follows: discard the
-   left-most n bits of x and then pad the result with n zeroed bits on
-   the right (the result will still be the same number of bits).
-
-    a.  Bitwise logical word operations
-
-        X AND Y  =  bitwise logical "and" of  X and Y.
-
-        X OR Y   =  bitwise logical "inclusive-or" of X and Y.
-
-        X XOR Y  =  bitwise logical "exclusive-or" of X and Y.
-
-        NOT X    =  bitwise logical "complement" of X.
-
-        Example:
-                 01101100101110011101001001111011
-           XOR   01100101110000010110100110110111
-                 --------------------------------
-             =   00001001011110001011101111001100
-
-    b.  The operation X + Y is defined as follows: words X and Y
-        represent w-bit integers x and y, where 0 <= x < 2^w and
-        0 <= y < 2^w.  For positive integers n and m, let
-
-             n mod m
-
-        be the remainder upon dividing n by m.  Compute
-
-             z  =  (x + y) mod 2^w.
-
-        Then 0 <= z < 2^w.  Convert z to a word, Z, and define Z = X +
-        Y.
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 5]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    c.  The right shift operation SHR^n(x), where x is a w-bit word and
-        n is an integer with 0 <= n < w, is defined by
-
-             SHR^n(x) = x>>n
-
-    d.  The rotate right (circular right shift) operation ROTR^n(x),
-        where x is a w-bit word and n is an integer with 0 <= n < w, is
-        defined by
-
-             ROTR^n(x) = (x>>n) OR (x<<(w-n))
-
-    e.  The rotate left (circular left shift) operation ROTL^n(x), where
-        x is a w-bit word and n is an integer with 0 <= n < w, is
-        defined by
-
-             ROTL^n(X)  =  (x<<n) OR (x>>w-n)
-
-        Note the following equivalence relationships, where w is fixed
-        in each relationship:
-
-             ROTL^n(x) = ROTR^(w-x)(x)
-
-             ROTR^n(x) = ROTL^(w-n)(x)
-
-4.  Message Padding and Parsing
-
-   The hash functions specified herein are used to compute a message
-   digest for a message or data file that is provided as input.  The
-   message or data file should be considered to be a bit string.  The
-   length of the message is the number of bits in the message (the empty
-   message has length 0).  If the number of bits in a message is a
-   multiple of 8, for compactness we can represent the message in hex.
-   The purpose of message padding is to make the total length of a
-   padded message a multiple of 512 for SHA-224 and SHA-256 or a
-   multiple of 1024 for SHA-384 and SHA-512.
-
-   The following specifies how this padding shall be performed.  As a
-   summary, a "1" followed by a number of "0"s followed by a 64-bit or
-   128-bit integer are appended to the end of the message to produce a
-   padded message of length 512*n or 1024*n.  The minimum number of "0"s
-   necessary to meet this criterion is used.  The appended integer is
-   the length of the original message.  The padded message is then
-   processed by the hash function as n 512-bit or 1024-bit blocks.
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 6]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-4.1.  SHA-224 and SHA-256
-
-   Suppose a message has length L < 2^64.  Before it is input to the
-   hash function, the message is padded on the right as follows:
-
-    a.  "1" is appended.  Example: if the original message is
-        "01010000", this is padded to "010100001".
-
-    b.  K "0"s are appended where K is the smallest, non-negative
-        solution to the equation
-
-             L + 1 + K = 448 (mod 512)
-
-    c.  Then append the 64-bit block that is L in binary representation.
-        After appending this block, the length of the message will be a
-        multiple of 512 bits.
-
-        Example:  Suppose the original message is the bit string
-
-             01100001 01100010 01100011 01100100 01100101
-
-        After step (a), this gives
-
-             01100001 01100010 01100011 01100100 01100101 1
-
-        Since L = 40, the number of bits in the above is 41 and K = 407
-        "0"s are appended, making the total now 448.  This gives the
-        following in hex:
-
-             61626364 65800000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000
-
-        The 64-bit representation of L = 40 is hex 00000000 00000028.
-        Hence the final padded message is the following hex:
-
-             61626364 65800000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000028
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 7]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-4.2.  SHA-384 and SHA-512
-
-   Suppose a message has length L < 2^128.  Before it is input to the
-   hash function, the message is padded on the right as follows:
-
-    a.  "1" is appended.  Example: if the original message is
-        "01010000", this is padded to "010100001".
-
-    b.  K "0"s are appended where K is the smallest, non-negative
-        solution to the equation
-
-             L + 1 + K = 896 (mod 1024)
-
-    c.  Then append the 128-bit block that is L in binary
-        representation.  After appending this block, the length of the
-        message will be a multiple of 1024 bits.
-
-        Example:  Suppose the original message is the bit string
-
-             01100001 01100010 01100011 01100100 01100101
-
-        After step (a) this gives
-
-             01100001 01100010 01100011 01100100 01100101 1
-
-        Since L = 40, the number of bits in the above is 41 and K = 855
-        "0"s are appended, making the total now 896.  This gives the
-        following in hex:
-
-             61626364 65800000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-
-        The 128-bit representation of L = 40 is hex 00000000 00000000
-        00000000 00000028.  Hence the final padded message is the
-        following hex:
-
-             61626364 65800000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 8]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000028
-
-5.  Functions and Constants Used
-
-   The following subsections give the six logical functions and the
-   table of constants used in each of the hash functions.
-
-5.1.  SHA-224 and SHA-256
-
-   SHA-224 and SHA-256 use six logical functions, where each function
-   operates on 32-bit words, which are represented as x, y, and z.  The
-   result of each function is a new 32-bit word.
-
-        CH( x, y, z) = (x AND y) XOR ( (NOT x) AND z)
-
-        MAJ( x, y, z) = (x AND y) XOR (x AND z) XOR (y AND z)
-
-        BSIG0(x) = ROTR^2(x) XOR ROTR^13(x) XOR ROTR^22(x)
-
-        BSIG1(x) = ROTR^6(x) XOR ROTR^11(x) XOR ROTR^25(x)
-
-        SSIG0(x) = ROTR^7(x) XOR ROTR^18(x) XOR SHR^3(x)
-
-        SSIG1(x) = ROTR^17(x) XOR ROTR^19(x) XOR SHR^10(x)
-
-   SHA-224 and SHA-256 use the same sequence of sixty-four constant
-   32-bit words, K0, K1, ..., K63.  These words represent the first
-   thirty-two bits of the fractional parts of the cube roots of the
-   first sixty-four prime numbers.  In hex, these constant words are as
-   follows (from left to right):
-
-        428a2f98 71374491 b5c0fbcf e9b5dba5
-        3956c25b 59f111f1 923f82a4 ab1c5ed5
-        d807aa98 12835b01 243185be 550c7dc3
-        72be5d74 80deb1fe 9bdc06a7 c19bf174
-        e49b69c1 efbe4786 0fc19dc6 240ca1cc
-        2de92c6f 4a7484aa 5cb0a9dc 76f988da
-        983e5152 a831c66d b00327c8 bf597fc7
-        c6e00bf3 d5a79147 06ca6351 14292967
-        27b70a85 2e1b2138 4d2c6dfc 53380d13
-        650a7354 766a0abb 81c2c92e 92722c85
-        a2bfe8a1 a81a664b c24b8b70 c76c51a3
-        d192e819 d6990624 f40e3585 106aa070
-        19a4c116 1e376c08 2748774c 34b0bcb5
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 9]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        391c0cb3 4ed8aa4a 5b9cca4f 682e6ff3
-        748f82ee 78a5636f 84c87814 8cc70208
-        90befffa a4506ceb bef9a3f7 c67178f2
-
-5.2.  SHA-384 and SHA-512
-
-   SHA-384 and SHA-512 each use six logical functions, where each
-   function operates on 64-bit words, which are represented as x, y, and
-   z.  The result of each function is a new 64-bit word.
-
-        CH( x, y, z) = (x AND y) XOR ( (NOT x) AND z)
-
-        MAJ( x, y, z) = (x AND y) XOR (x AND z) XOR (y AND z)
-
-        BSIG0(x) = ROTR^28(x) XOR ROTR^34(x) XOR ROTR^39(x)
-
-        BSIG1(x) = ROTR^14(x) XOR ROTR^18(x) XOR ROTR^41(x)
-
-        SSIG0(x) = ROTR^1(x) XOR ROTR^8(x) XOR SHR^7(x)
-
-        SSIG1(x) = ROTR^19(x) XOR ROTR^61(x) XOR SHR^6(x)
-
-   SHA-384 and SHA-512 use the same sequence of eighty constant 64-bit
-   words, K0, K1, ... K79.  These words represent the first sixty-four
-   bits of the fractional parts of the cube roots of the first eighty
-   prime numbers.  In hex, these constant words are as follows (from
-   left to right):
-
-   428a2f98d728ae22 7137449123ef65cd b5c0fbcfec4d3b2f e9b5dba58189dbbc
-   3956c25bf348b538 59f111f1b605d019 923f82a4af194f9b ab1c5ed5da6d8118
-   d807aa98a3030242 12835b0145706fbe 243185be4ee4b28c 550c7dc3d5ffb4e2
-   72be5d74f27b896f 80deb1fe3b1696b1 9bdc06a725c71235 c19bf174cf692694
-   e49b69c19ef14ad2 efbe4786384f25e3 0fc19dc68b8cd5b5 240ca1cc77ac9c65
-   2de92c6f592b0275 4a7484aa6ea6e483 5cb0a9dcbd41fbd4 76f988da831153b5
-   983e5152ee66dfab a831c66d2db43210 b00327c898fb213f bf597fc7beef0ee4
-   c6e00bf33da88fc2 d5a79147930aa725 06ca6351e003826f 142929670a0e6e70
-   27b70a8546d22ffc 2e1b21385c26c926 4d2c6dfc5ac42aed 53380d139d95b3df
-   650a73548baf63de 766a0abb3c77b2a8 81c2c92e47edaee6 92722c851482353b
-   a2bfe8a14cf10364 a81a664bbc423001 c24b8b70d0f89791 c76c51a30654be30
-   d192e819d6ef5218 d69906245565a910 f40e35855771202a 106aa07032bbd1b8
-   19a4c116b8d2d0c8 1e376c085141ab53 2748774cdf8eeb99 34b0bcb5e19b48a8
-   391c0cb3c5c95a63 4ed8aa4ae3418acb 5b9cca4f7763e373 682e6ff3d6b2b8a3
-   748f82ee5defb2fc 78a5636f43172f60 84c87814a1f0ab72 8cc702081a6439ec
-   90befffa23631e28 a4506cebde82bde9 bef9a3f7b2c67915 c67178f2e372532b
-   ca273eceea26619c d186b8c721c0c207 eada7dd6cde0eb1e f57d4f7fee6ed178
-   06f067aa72176fba 0a637dc5a2c898a6 113f9804bef90dae 1b710b35131c471b
-   28db77f523047d84 32caab7b40c72493 3c9ebe0a15c9bebc 431d67c49c100d4c
-   4cc5d4becb3e42b6 597f299cfc657e2a 5fcb6fab3ad6faec 6c44198c4a475817
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 10]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-6.  Computing the Message Digest
-
-   The output of each of the secure hash functions, after being applied
-   to a message of N blocks, is the hash quantity H(N).  For SHA-224 and
-   SHA-256, H(i) can be considered to be eight 32-bit words, H(i)0,
-   H(i)1, ... H(i)7.  For SHA-384 and SHA-512, it can be considered to
-   be eight 64-bit words, H(i)0, H(i)1, ..., H(i)7.
-
-   As described below, the hash words are initialized, modified as each
-   message block is processed, and finally concatenated after processing
-   the last block to yield the output.  For SHA-256 and SHA-512, all of
-   the H(N) variables are concatenated while the SHA-224 and SHA-384
-   hashes are produced by omitting some from the final concatenation.
-
-6.1.  SHA-224 and SHA-256 Initialization
-
-   For SHA-224, the initial hash value, H(0), consists of the following
-   32-bit words in hex:
-
-        H(0)0 = c1059ed8
-        H(0)1 = 367cd507
-        H(0)2 = 3070dd17
-        H(0)3 = f70e5939
-        H(0)4 = ffc00b31
-        H(0)5 = 68581511
-        H(0)6 = 64f98fa7
-        H(0)7 = befa4fa4
-
-   For SHA-256, the initial hash value, H(0), consists of the following
-   eight 32-bit words, in hex.  These words were obtained by taking the
-   first thirty-two bits of the fractional parts of the square roots of
-   the first eight prime numbers.
-
-        H(0)0 = 6a09e667
-        H(0)1 = bb67ae85
-        H(0)2 = 3c6ef372
-        H(0)3 = a54ff53a
-        H(0)4 = 510e527f
-        H(0)5 = 9b05688c
-        H(0)6 = 1f83d9ab
-        H(0)7 = 5be0cd19
-
-6.2.  SHA-224 and SHA-256 Processing
-
-   SHA-224 and SHA-256 perform identical processing on messages blocks
-   and differ only in how H(0) is initialized and how they produce their
-   final output.  They may be used to hash a message, M, having a length
-   of L bits, where 0 <= L < 2^64.  The algorithm uses (1) a message
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 11]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-   schedule of sixty-four 32-bit words, (2) eight working variables of
-   32 bits each, and (3) a hash value of eight 32-bit words.
-
-   The words of the message schedule are labeled W0, W1, ..., W63.  The
-   eight working variables are labeled a, b, c, d, e, f, g, and h.  The
-   words of the hash value are labeled H(i)0, H(i)1, ..., H(i)7, which
-   will hold the initial hash value, H(0), replaced by each successive
-   intermediate hash value (after each message block is processed),
-   H(i), and ending with the final hash value, H(N), after all N blocks
-   are processed.  They also use two temporary words, T1 and T2.
-
-   The input message is padded as described in Section 4.1 above then
-   parsed into 512-bit blocks, which are considered to be composed of 16
-   32-bit words M(i)0, M(i)1, ..., M(i)15.  The following computations
-   are then performed for each of the N message blocks.  All addition is
-   performed modulo 2^32.
-
-   For i = 1 to N
-
-      1. Prepare the message schedule W:
-         For t = 0 to 15
-            Wt = M(i)t
-         For t = 16 to 63
-            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)
-
-      2. Initialize the working variables:
-         a = H(i-1)0
-         b = H(i-1)1
-         c = H(i-1)2
-         d = H(i-1)3
-         e = H(i-1)4
-         f = H(i-1)5
-         g = H(i-1)6
-         h = H(i-1)7
-
-      3. Perform the main hash computation:
-         For t = 0 to 63
-            T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt
-            T2 = BSIG0(a) + MAJ(a,b,c)
-            h = g
-            g = f
-            f = e
-            e = d + T1
-            d = c
-            c = b
-            b = a
-            a = T1 + T2
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 12]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      4. Compute the intermediate hash value H(i):
-         H(i)0 = a + H(i-1)0
-         H(i)1 = b + H(i-1)1
-         H(i)2 = c + H(i-1)2
-         H(i)3 = d + H(i-1)3
-         H(i)4 = e + H(i-1)4
-         H(i)5 = f + H(i-1)5
-         H(i)6 = g + H(i-1)6
-         H(i)7 = h + H(i-1)7
-
-   After the above computations have been sequentially performed for all
-   of the blocks in the message, the final output is calculated.  For
-   SHA-256, this is the concatenation of all of H(N)0, H(N)1, through
-   H(N)7.  For SHA-224, this is the concatenation of H(N)0, H(N)1,
-   through H(N)6.
-
-6.3.  SHA-384 and SHA-512 Initialization
-
-   For SHA-384, the initial hash value, H(0), consists of the following
-   eight 64-bit words, in hex.  These words were obtained by taking the
-   first sixty-four bits of the fractional parts of the square roots of
-   the ninth through sixteenth prime numbers.
-
-        H(0)0 = cbbb9d5dc1059ed8
-        H(0)1 = 629a292a367cd507
-        H(0)2 = 9159015a3070dd17
-        H(0)3 = 152fecd8f70e5939
-        H(0)4 = 67332667ffc00b31
-        H(0)5 = 8eb44a8768581511
-        H(0)6 = db0c2e0d64f98fa7
-        H(0)7 = 47b5481dbefa4fa4
-
-   For SHA-512, the initial hash value, H(0), consists of the following
-   eight 64-bit words, in hex.  These words were obtained by taking the
-   first sixty-four bits of the fractional parts of the square roots of
-   the first eight prime numbers.
-
-        H(0)0 = 6a09e667f3bcc908
-        H(0)1 = bb67ae8584caa73b
-        H(0)2 = 3c6ef372fe94f82b
-        H(0)3 = a54ff53a5f1d36f1
-        H(0)4 = 510e527fade682d1
-        H(0)5 = 9b05688c2b3e6c1f
-        H(0)6 = 1f83d9abfb41bd6b
-        H(0)7 = 5be0cd19137e2179
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 13]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-6.4.  SHA-384 and SHA-512 Processing
-
-   SHA-384 and SHA-512 perform identical processing on message blocks
-   and differ only in how H(0) is initialized and how they produce their
-   final output.  They may be used to hash a message, M, having a length
-   of L bits, where 0 <= L < 2^128.  The algorithm uses (1) a message
-   schedule of eighty 64-bit words, (2) eight working variables of 64
-   bits each, and (3) a hash value of eight 64-bit words.
-
-   The words of the message schedule are labeled W0, W1, ..., W79.  The
-   eight working variables are labeled a, b, c, d, e, f, g, and h.  The
-   words of the hash value are labeled H(i)0, H(i)1, ..., H(i)7, which
-   will hold the initial hash value, H(0), replaced by each successive
-   intermediate hash value (after each message block is processed),
-   H(i), and ending with the final hash value, H(N) after all N blocks
-   are processed.
-
-   The input message is padded as described in Section 4.2 above, then
-   parsed into 1024-bit blocks, which are considered to be composed of
-   16 64-bit words M(i)0, M(i)1, ..., M(i)15.  The following
-   computations are then performed for each of the N message blocks.
-   All addition is performed modulo 2^64.
-
-   For i = 1 to N
-
-      1. Prepare the message schedule W:
-         For t = 0 to 15
-            Wt = M(i)t
-         For t = 16 to 79
-            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)
-
-      2. Initialize the working variables:
-         a = H(i-1)0
-         b = H(i-1)1
-         c = H(i-1)2
-         d = H(i-1)3
-         e = H(i-1)4
-         f = H(i-1)5
-         g = H(i-1)6
-         h = H(i-1)7
-
-      3. Perform the main hash computation:
-         For t = 0 to 79
-            T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt
-            T2 = BSIG0(a) + MAJ(a,b,c)
-            h = g
-            g = f
-            f = e
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 14]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-            e = d + T1
-            d = c
-            c = b
-            b = a
-            a = T1 + T2
-
-      4. Compute the intermediate hash value H(i):
-         H(i)0 = a + H(i-1)0
-         H(i)1 = b + H(i-1)1
-         H(i)2 = c + H(i-1)2
-         H(i)3 = d + H(i-1)3
-         H(i)4 = e + H(i-1)4
-         H(i)5 = f + H(i-1)5
-         H(i)6 = g + H(i-1)6
-         H(i)7 = h + H(i-1)7
-
-   After the above computations have been sequentially performed for all
-   of the blocks in the message, the final output is calculated.  For
-   SHA-512, this is the concatenation of all of H(N)0, H(N)1, through
-   H(N)7.  For SHA-384, this is the concatenation of H(N)0, H(N)1,
-   through H(N)5.
-
-7.  SHA-Based HMACs
-
-   HMAC is a method for computing a keyed MAC (message authentication
-   code) using a hash function as described in [RFC2104].  It uses a key
-   to mix in with the input text to produce the final hash.
-
-   Sample code is also provided, in Section 8.3 below, to perform HMAC
-   based on any of the SHA algorithms described herein.  The sample code
-   found in [RFC2104] was written in terms of a specified text size.
-   Since SHA is defined in terms of an arbitrary number of bits, the
-   sample HMAC code has been written to allow the text input to HMAC to
-   have an arbitrary number of octets and bits.  A fixed-length
-   interface is also provided.
-
-8.  C Code for SHAs
-
-   Below is a demonstration implementation of these secure hash
-   functions in C.  Section 8.1 contains the header file sha.h, which
-   declares all constants, structures, and functions used by the sha and
-   hmac functions.  Section 8.2 contains the C code for sha1.c,
-   sha224-256.c, sha384-512.c, and usha.c along with sha-private.h,
-   which provides some declarations common to all the sha functions.
-   Section 8.3 contains the C code for the hmac functions.  Section 8.4
-   contains a test driver to exercise the code.
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 15]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-   For each of the digest length $$$, there is the following set of
-   constants, a structure, and functions:
-
-   Constants:
-      SHA$$$HashSize      number of octets in the hash
-      SHA$$$HashSizeBits  number of bits in the hash
-      SHA$$$_Message_Block_Size
-                          number of octets used in the intermediate
-                          message blocks
-      shaSuccess = 0      constant returned by each function on success
-      shaNull = 1         constant returned by each function when
-                          presented with a null pointer parameter
-      shaInputTooLong = 2  constant returned by each function when the
-                          input data is too long
-      shaStateError       constant returned by each function when
-                          SHA$$$Input is called after SHA$$$FinalBits or
-                          SHA$$$Result.
-
-   Structure:
-      typedef SHA$$$Context
-                          an opaque structure holding the complete state
-                          for producing the hash
-
-   Functions:
-                  int SHA$$$Reset(SHA$$$Context *);
-            Reset the hash context state
-      int SHA$$$Input(SHA$$$Context *, const uint8_t *octets,
-                  unsigned int bytecount);
-            Incorporate bytecount octets into the hash.
-      int SHA$$$FinalBits(SHA$$$Context *, const uint8_t octet,
-                  unsigned int bitcount);
-            Incorporate bitcount bits into the hash.  The bits are in
-            the upper portion of the octet.  SHA$$$Input() cannot be
-            called after this.
-      int SHA$$$Result(SHA$$$Context *,
-                  uint8_t Message_Digest[SHA$$$HashSize]);
-            Do the final calculations on the hash and copy the value
-            into Message_Digest.
-
-   In addition, functions with the prefix USHA are provided that take a
-   SHAversion value (SHA$$$) to select the SHA function suite.  They add
-   the following constants, structure, and functions:
-
-   Constants:
-      shaBadParam         constant returned by USHA functions when
-                          presented with a bad SHAversion (SHA$$$)
-                          parameter
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 16]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      SHA$$$              SHAversion enumeration values, used by usha
-                          and hmac functions to select the SHA function
-                          suite
-
-   Structure:
-      typedef USHAContext
-                          an opaque structure holding the complete state
-                          for producing the hash
-
-   Functions:
-      int USHAReset(USHAContext *, SHAversion whichSha);
-            Reset the hash context state.
-      int USHAInput(USHAContext *,
-                  const uint8_t *bytes, unsigned int bytecount);
-            Incorporate bytecount octets into the hash.
-      int USHAFinalBits(USHAContext *,
-                  const uint8_t bits, unsigned int bitcount);
-                  Incorporate bitcount bits into the hash.
-      int USHAResult(USHAContext *,
-                  uint8_t Message_Digest[USHAMaxHashSize]);
-            Do the final calculations on the hash and copy the value
-            into Message_Digest.  Octets in Message_Digest beyond
-      USHAHashSize(whichSha) are left untouched.
-                  int USHAHashSize(enum SHAversion whichSha);
-            The number of octets in the given hash.
-      int USHAHashSizeBits(enum SHAversion whichSha);
-            The number of bits in the given hash.
-      int USHABlockSize(enum SHAversion whichSha);
-            The internal block size for the given hash.
-
-   The hmac functions follow the same pattern to allow any length of
-   text input to be used.
-
-   Structure:
-      typedef HMACContext an opaque structure holding the complete state
-                          for producing the hash
-
-   Functions:
-      int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
-                  const unsigned char *key, int key_len);
-            Reset the hash context state.
-      int hmacInput(HMACContext *ctx, const unsigned char *text,
-                  int text_len);
-            Incorporate text_len octets into the hash.
-      int hmacFinalBits(HMACContext *ctx, const uint8_t bits,
-                  unsigned int bitcount);
-            Incorporate bitcount bits into the hash.
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 17]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      int hmacResult(HMACContext *ctx,
-                  uint8_t Message_Digest[USHAMaxHashSize]);
-            Do the final calculations on the hash and copy the value
-            into Message_Digest.  Octets in Message_Digest beyond
-            USHAHashSize(whichSha) are left untouched.
-
-   In addition, a combined interface is provided, similar to that shown
-   in RFC 2104, that allows a fixed-length text input to be used.
-
-      int hmac(SHAversion whichSha,
-                  const unsigned char *text, int text_len,
-                  const unsigned char *key, int key_len,
-                  uint8_t Message_Digest[USHAMaxHashSize]);
-            Calculate the given digest for the given text and key, and
-            return the resulting hash.  Octets in Message_Digest beyond
-            USHAHashSize(whichSha) are left untouched.
-
-8.1.  The .h File
-
-/**************************** sha.h ****************************/
-/******************* See RFC 4634 for details ******************/
-#ifndef _SHA_H_
-#define _SHA_H_
-
-/*
- *  Description:
- *      This file implements the Secure Hash Signature Standard
- *      algorithms as defined in the National Institute of Standards
- *      and Technology Federal Information Processing Standards
- *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
- *      published on August 1, 2002, and the FIPS PUB 180-2 Change
- *      Notice published on February 28, 2004.
- *
- *      A combined document showing all algorithms is available at
- *              http://csrc.nist.gov/publications/fips/
- *              fips180-2/fips180-2withchangenotice.pdf
- *
- *      The five hashes are defined in these sizes:
- *              SHA-1           20 byte / 160 bit
- *              SHA-224         28 byte / 224 bit
- *              SHA-256         32 byte / 256 bit
- *              SHA-384         48 byte / 384 bit
- *              SHA-512         64 byte / 512 bit
- */
-
-#include <stdint.h>
-/*
- * If you do not have the ISO standard stdint.h header file, then you
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 18]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * must typedef the following:
- *    name              meaning
- *  uint64_t         unsigned 64 bit integer
- *  uint32_t         unsigned 32 bit integer
- *  uint8_t          unsigned 8 bit integer (i.e., unsigned char)
- *  int_least16_t    integer of >= 16 bits
- *
- */
-
-#ifndef _SHA_enum_
-#define _SHA_enum_
-/*
- *  All SHA functions return one of these values.
- */
-enum {
-    shaSuccess = 0,
-    shaNull,            /* Null pointer parameter */
-    shaInputTooLong,    /* input data too long */
-    shaStateError,      /* called Input after FinalBits or Result */
-    shaBadParam         /* passed a bad parameter */
-};
-#endif /* _SHA_enum_ */
-
-/*
- *  These constants hold size information for each of the SHA
- *  hashing operations
- */
-enum {
-    SHA1_Message_Block_Size = 64, SHA224_Message_Block_Size = 64,
-    SHA256_Message_Block_Size = 64, SHA384_Message_Block_Size = 128,
-    SHA512_Message_Block_Size = 128,
-    USHA_Max_Message_Block_Size = SHA512_Message_Block_Size,
-
-    SHA1HashSize = 20, SHA224HashSize = 28, SHA256HashSize = 32,
-    SHA384HashSize = 48, SHA512HashSize = 64,
-    USHAMaxHashSize = SHA512HashSize,
-
-    SHA1HashSizeBits = 160, SHA224HashSizeBits = 224,
-    SHA256HashSizeBits = 256, SHA384HashSizeBits = 384,
-    SHA512HashSizeBits = 512, USHAMaxHashSizeBits = SHA512HashSizeBits
-};
-
-/*
- *  These constants are used in the USHA (unified sha) functions.
- */
-typedef enum SHAversion {
-    SHA1, SHA224, SHA256, SHA384, SHA512
-} SHAversion;
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 19]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- *  This structure will hold context information for the SHA-1
- *  hashing operation.
- */
-typedef struct SHA1Context {
-    uint32_t Intermediate_Hash[SHA1HashSize/4]; /* Message Digest */
-
-    uint32_t Length_Low;                /* Message length in bits */
-    uint32_t Length_High;               /* Message length in bits */
-
-    int_least16_t Message_Block_Index;  /* Message_Block array index */
-                                        /* 512-bit message blocks */
-    uint8_t Message_Block[SHA1_Message_Block_Size];
-
-    int Computed;                       /* Is the digest computed? */
-    int Corrupted;                      /* Is the digest corrupted? */
-} SHA1Context;
-
-/*
- *  This structure will hold context information for the SHA-256
- *  hashing operation.
- */
-typedef struct SHA256Context {
-    uint32_t Intermediate_Hash[SHA256HashSize/4]; /* Message Digest */
-
-    uint32_t Length_Low;                /* Message length in bits */
-    uint32_t Length_High;               /* Message length in bits */
-
-    int_least16_t Message_Block_Index;  /* Message_Block array index */
-                                        /* 512-bit message blocks */
-    uint8_t Message_Block[SHA256_Message_Block_Size];
-
-    int Computed;                       /* Is the digest computed? */
-    int Corrupted;                      /* Is the digest corrupted? */
-} SHA256Context;
-
-/*
- *  This structure will hold context information for the SHA-512
- *  hashing operation.
- */
-typedef struct SHA512Context {
-#ifdef USE_32BIT_ONLY
-    uint32_t Intermediate_Hash[SHA512HashSize/4]; /* Message Digest  */
-    uint32_t Length[4];                 /* Message length in bits */
-#else /* !USE_32BIT_ONLY */
-    uint64_t Intermediate_Hash[SHA512HashSize/8]; /* Message Digest */
-    uint64_t Length_Low, Length_High;   /* Message length in bits */
-#endif /* USE_32BIT_ONLY */
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 20]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    int_least16_t Message_Block_Index;  /* Message_Block array index */
-                                        /* 1024-bit message blocks */
-    uint8_t Message_Block[SHA512_Message_Block_Size];
-
-    int Computed;                       /* Is the digest computed?*/
-    int Corrupted;                      /* Is the digest corrupted? */
-} SHA512Context;
-
-/*
- *  This structure will hold context information for the SHA-224
- *  hashing operation. It uses the SHA-256 structure for computation.
- */
-typedef struct SHA256Context SHA224Context;
-
-/*
- *  This structure will hold context information for the SHA-384
- *  hashing operation. It uses the SHA-512 structure for computation.
- */
-typedef struct SHA512Context SHA384Context;
-
-/*
- *  This structure holds context information for all SHA
- *  hashing operations.
- */
-typedef struct USHAContext {
-    int whichSha;               /* which SHA is being used */
-    union {
-      SHA1Context sha1Context;
-      SHA224Context sha224Context; SHA256Context sha256Context;
-      SHA384Context sha384Context; SHA512Context sha512Context;
-    } ctx;
-} USHAContext;
-
-/*
- *  This structure will hold context information for the HMAC
- *  keyed hashing operation.
- */
-typedef struct HMACContext {
-    int whichSha;               /* which SHA is being used */
-    int hashSize;               /* hash size of SHA being used */
-    int blockSize;              /* block size of SHA being used */
-    USHAContext shaContext;     /* SHA context */
-    unsigned char k_opad[USHA_Max_Message_Block_Size];
-                        /* outer padding - key XORd with opad */
-} HMACContext;
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 21]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- *  Function Prototypes
- */
-
-/* SHA-1 */
-extern int SHA1Reset(SHA1Context *);
-extern int SHA1Input(SHA1Context *, const uint8_t *bytes,
-                     unsigned int bytecount);
-extern int SHA1FinalBits(SHA1Context *, const uint8_t bits,
-                         unsigned int bitcount);
-extern int SHA1Result(SHA1Context *,
-                      uint8_t Message_Digest[SHA1HashSize]);
-
-/* SHA-224 */
-extern int SHA224Reset(SHA224Context *);
-extern int SHA224Input(SHA224Context *, const uint8_t *bytes,
-                       unsigned int bytecount);
-extern int SHA224FinalBits(SHA224Context *, const uint8_t bits,
-                           unsigned int bitcount);
-extern int SHA224Result(SHA224Context *,
-                        uint8_t Message_Digest[SHA224HashSize]);
-
-/* SHA-256 */
-extern int SHA256Reset(SHA256Context *);
-extern int SHA256Input(SHA256Context *, const uint8_t *bytes,
-                       unsigned int bytecount);
-extern int SHA256FinalBits(SHA256Context *, const uint8_t bits,
-                           unsigned int bitcount);
-extern int SHA256Result(SHA256Context *,
-                        uint8_t Message_Digest[SHA256HashSize]);
-
-/* SHA-384 */
-extern int SHA384Reset(SHA384Context *);
-extern int SHA384Input(SHA384Context *, const uint8_t *bytes,
-                       unsigned int bytecount);
-extern int SHA384FinalBits(SHA384Context *, const uint8_t bits,
-                           unsigned int bitcount);
-extern int SHA384Result(SHA384Context *,
-                        uint8_t Message_Digest[SHA384HashSize]);
-
-/* SHA-512 */
-extern int SHA512Reset(SHA512Context *);
-extern int SHA512Input(SHA512Context *, const uint8_t *bytes,
-                       unsigned int bytecount);
-extern int SHA512FinalBits(SHA512Context *, const uint8_t bits,
-                           unsigned int bitcount);
-extern int SHA512Result(SHA512Context *,
-                        uint8_t Message_Digest[SHA512HashSize]);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 22]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/* Unified SHA functions, chosen by whichSha */
-extern int USHAReset(USHAContext *, SHAversion whichSha);
-extern int USHAInput(USHAContext *,
-                     const uint8_t *bytes, unsigned int bytecount);
-extern int USHAFinalBits(USHAContext *,
-                         const uint8_t bits, unsigned int bitcount);
-extern int USHAResult(USHAContext *,
-                      uint8_t Message_Digest[USHAMaxHashSize]);
-extern int USHABlockSize(enum SHAversion whichSha);
-extern int USHAHashSize(enum SHAversion whichSha);
-extern int USHAHashSizeBits(enum SHAversion whichSha);
-
-/*
- * HMAC Keyed-Hashing for Message Authentication, RFC2104,
- * for all SHAs.
- * This interface allows a fixed-length text input to be used.
- */
-extern int hmac(SHAversion whichSha, /* which SHA algorithm to use */
-    const unsigned char *text,     /* pointer to data stream */
-    int text_len,                  /* length of data stream */
-    const unsigned char *key,      /* pointer to authentication key */
-    int key_len,                   /* length of authentication key */
-    uint8_t digest[USHAMaxHashSize]); /* caller digest to fill in */
-
-/*
- * HMAC Keyed-Hashing for Message Authentication, RFC2104,
- * for all SHAs.
- * This interface allows any length of text input to be used.
- */
-extern int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
-                     const unsigned char *key, int key_len);
-extern int hmacInput(HMACContext *ctx, const unsigned char *text,
-                     int text_len);
-
-extern int hmacFinalBits(HMACContext *ctx, const uint8_t bits,
-                         unsigned int bitcount);
-extern int hmacResult(HMACContext *ctx,
-                      uint8_t digest[USHAMaxHashSize]);
-
-#endif /* _SHA_H_ */
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 23]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-8.2.  The SHA Code
-
-   This code is primarily intended as expository and could be optimized
-   further.  For example, the assignment rotations through the variables
-   a, b, ..., h could be treated as a cycle and the loop unrolled,
-   rather than doing the explicit copying.
-
-   Note that there are alternative representations of the Ch() and Maj()
-   functions controlled by an ifdef.
-
-8.2.1.  sha1.c
-
-/**************************** sha1.c ****************************/
-/******************** See RFC 4634 for details ******************/
-/*
- *  Description:
- *      This file implements the Secure Hash Signature Standard
- *      algorithms as defined in the National Institute of Standards
- *      and Technology Federal Information Processing Standards
- *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
- *      published on August 1, 2002, and the FIPS PUB 180-2 Change
- *      Notice published on February 28, 2004.
- *
- *      A combined document showing all algorithms is available at
- *              http://csrc.nist.gov/publications/fips/
- *              fips180-2/fips180-2withchangenotice.pdf
- *
- *      The SHA-1 algorithm produces a 160-bit message digest for a
- *      given data stream.  It should take about 2**n steps to find a
- *      message with the same digest as a given message and
- *      2**(n/2) to find any two messages with the same digest,
- *      when n is the digest size in bits.  Therefore, this
- *      algorithm can serve as a means of providing a
- *      "fingerprint" for a message.
- *
- *  Portability Issues:
- *      SHA-1 is defined in terms of 32-bit "words".  This code
- *      uses <stdint.h> (included via "sha.h") to define 32 and 8
- *      bit unsigned integer types.  If your C compiler does not
- *      support 32 bit unsigned integers, this code is not
- *      appropriate.
- *
- *  Caveats:
- *      SHA-1 is designed to work with messages less than 2^64 bits
- *      long. This implementation uses SHA1Input() to hash the bits
- *      that are a multiple of the size of an 8-bit character, and then
- *      uses SHA1FinalBits() to hash the final few bits of the input.
- */
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 24]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-#include "sha.h"
-#include "sha-private.h"
-
-/*
- *  Define the SHA1 circular left shift macro
- */
-#define SHA1_ROTL(bits,word) \
-                (((word) << (bits)) | ((word) >> (32-(bits))))
-
-/*
- * add "length" to the length
- */
-static uint32_t addTemp;
-#define SHA1AddLength(context, length)                     \
-    (addTemp = (context)->Length_Low,                      \
-     (context)->Corrupted =                                \
-        (((context)->Length_Low += (length)) < addTemp) && \
-        (++(context)->Length_High == 0) ? 1 : 0)
-
-/* Local Function Prototypes */
-static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte);
-static void SHA1PadMessage(SHA1Context *, uint8_t Pad_Byte);
-static void SHA1ProcessMessageBlock(SHA1Context *);
-
-/*
- *  SHA1Reset
- *
- *  Description:
- *      This function will initialize the SHA1Context in preparation
- *      for computing a new SHA1 message digest.
- *
- *  Parameters:
- *      context: [in/out]
- *          The context to reset.
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int SHA1Reset(SHA1Context *context)
-{
-    if (!context)
-        return shaNull;
-
-    context->Length_Low             = 0;
-    context->Length_High            = 0;
-    context->Message_Block_Index    = 0;
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 25]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    /* Initial Hash Values: FIPS-180-2 section 5.3.1 */
-    context->Intermediate_Hash[0]   = 0x67452301;
-    context->Intermediate_Hash[1]   = 0xEFCDAB89;
-    context->Intermediate_Hash[2]   = 0x98BADCFE;
-    context->Intermediate_Hash[3]   = 0x10325476;
-    context->Intermediate_Hash[4]   = 0xC3D2E1F0;
-
-    context->Computed   = 0;
-    context->Corrupted  = 0;
-
-    return shaSuccess;
-}
-
-/*
- *  SHA1Input
- *
- *  Description:
- *      This function accepts an array of octets as the next portion
- *      of the message.
- *
- *  Parameters:
- *      context: [in/out]
- *          The SHA context to update
- *      message_array: [in]
- *          An array of characters representing the next portion of
- *          the message.
- *      length: [in]
- *          The length of the message in message_array
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int SHA1Input(SHA1Context *context,
-    const uint8_t *message_array, unsigned length)
-{
-  if (!length)
-    return shaSuccess;
-
-  if (!context || !message_array)
-    return shaNull;
-
-  if (context->Computed) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 26]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-     return context->Corrupted;
-
-  while (length-- && !context->Corrupted) {
-    context->Message_Block[context->Message_Block_Index++] =
-      (*message_array & 0xFF);
-
-    if (!SHA1AddLength(context, 8) &&
-      (context->Message_Block_Index == SHA1_Message_Block_Size))
-      SHA1ProcessMessageBlock(context);
-
-    message_array++;
-  }
-
-  return shaSuccess;
-}
-
-/*
- * SHA1FinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA1FinalBits(SHA1Context *context, const uint8_t message_bits,
-    unsigned int length)
-{
-  uint8_t masks[8] = {
-      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
-      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
-      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
-      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
-  };
-  uint8_t markbit[8] = {
-      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
-      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
-      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 27]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
-  };
-
-  if (!length)
-    return shaSuccess;
-
-  if (!context)
-    return shaNull;
-
-  if (context->Computed || (length >= 8) || (length == 0)) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-     return context->Corrupted;
-
-  SHA1AddLength(context, length);
-  SHA1Finalize(context,
-    (uint8_t) ((message_bits & masks[length]) | markbit[length]));
-
-  return shaSuccess;
-}
-
-/*
- * SHA1Result
- *
- * Description:
- *   This function will return the 160-bit message digest into the
- *   Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 19th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA-1 hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA1Result(SHA1Context *context,
-    uint8_t Message_Digest[SHA1HashSize])
-{
-  int i;
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 28]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  if (!context || !Message_Digest)
-    return shaNull;
-
-  if (context->Corrupted)
-    return context->Corrupted;
-
-  if (!context->Computed)
-    SHA1Finalize(context, 0x80);
-
-  for (i = 0; i < SHA1HashSize; ++i)
-    Message_Digest[i] = (uint8_t) (context->Intermediate_Hash[i>>2]
-              >> 8 * ( 3 - ( i & 0x03 ) ));
-
-  return shaSuccess;
-}
-
-/*
- * SHA1Finalize
- *
- * Description:
- *   This helper function finishes off the digest calculations.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte)
-{
-  int i;
-  SHA1PadMessage(context, Pad_Byte);
-  /* message may be sensitive, clear it out */
-  for (i = 0; i < SHA1_Message_Block_Size; ++i)
-    context->Message_Block[i] = 0;
-  context->Length_Low = 0;  /* and clear length */
-  context->Length_High = 0;
-  context->Computed = 1;
-}
-
-/*
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 29]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * SHA1PadMessage
- *
- * Description:
- *   According to the standard, the message must be padded to an
- *   even 512 bits. The first padding bit must be a '1'. The last
- *   64 bits represent the length of the original message. All bits
- *   in between should be 0. This helper function will pad the
- *   message according to those rules by filling the Message_Block
- *   array accordingly. When it returns, it can be assumed that the
- *   message digest has been computed.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to pad
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   Nothing.
- */
-static void SHA1PadMessage(SHA1Context *context, uint8_t Pad_Byte)
-{
-  /*
-   * Check to see if the current message block is too small to hold
-   * the initial padding bits and length. If so, we will pad the
-   * block, process it, and then continue padding into a second
-   * block.
-   */
-  if (context->Message_Block_Index >= (SHA1_Message_Block_Size - 8)) {
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-    while (context->Message_Block_Index < SHA1_Message_Block_Size)
-      context->Message_Block[context->Message_Block_Index++] = 0;
-
-    SHA1ProcessMessageBlock(context);
-  } else
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-
-  while (context->Message_Block_Index < (SHA1_Message_Block_Size - 8))
-    context->Message_Block[context->Message_Block_Index++] = 0;
-
-  /*
-   * Store the message length as the last 8 octets
-   */
-  context->Message_Block[56] = (uint8_t) (context->Length_High >> 24);
-  context->Message_Block[57] = (uint8_t) (context->Length_High >> 16);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 30]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  context->Message_Block[58] = (uint8_t) (context->Length_High >> 8);
-  context->Message_Block[59] = (uint8_t) (context->Length_High);
-  context->Message_Block[60] = (uint8_t) (context->Length_Low >> 24);
-  context->Message_Block[61] = (uint8_t) (context->Length_Low >> 16);
-  context->Message_Block[62] = (uint8_t) (context->Length_Low >> 8);
-  context->Message_Block[63] = (uint8_t) (context->Length_Low);
-
-  SHA1ProcessMessageBlock(context);
-}
-
-/*
- * SHA1ProcessMessageBlock
- *
- * Description:
- *   This helper function will process the next 512 bits of the
- *   message stored in the Message_Block array.
- *
- * Parameters:
- *   None.
- *
- * Returns:
- *   Nothing.
- *
- * Comments:
- *   Many of the variable names in this code, especially the
- *   single character names, were used because those were the
- *   names used in the publication.
- */
-static void SHA1ProcessMessageBlock(SHA1Context *context)
-{
-  /* Constants defined in FIPS-180-2, section 4.2.1 */
-  const uint32_t K[4] = {
-      0x5A827999, 0x6ED9EBA1, 0x8F1BBCDC, 0xCA62C1D6
-  };
-  int        t;               /* Loop counter */
-  uint32_t   temp;            /* Temporary word value */
-  uint32_t   W[80];           /* Word sequence */
-  uint32_t   A, B, C, D, E;   /* Word buffers */
-
-  /*
-   * Initialize the first 16 words in the array W
-   */
-  for (t = 0; t < 16; t++) {
-    W[t]  = ((uint32_t)context->Message_Block[t * 4]) << 24;
-    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 1]) << 16;
-    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 2]) << 8;
-    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 3]);
-  }
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 31]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  for (t = 16; t < 80; t++)
-    W[t] = SHA1_ROTL(1, W[t-3] ^ W[t-8] ^ W[t-14] ^ W[t-16]);
-
-  A = context->Intermediate_Hash[0];
-  B = context->Intermediate_Hash[1];
-  C = context->Intermediate_Hash[2];
-  D = context->Intermediate_Hash[3];
-  E = context->Intermediate_Hash[4];
-
-  for (t = 0; t < 20; t++) {
-    temp = SHA1_ROTL(5,A) + SHA_Ch(B, C, D) + E + W[t] + K[0];
-    E = D;
-    D = C;
-    C = SHA1_ROTL(30,B);
-    B = A;
-    A = temp;
-  }
-
-  for (t = 20; t < 40; t++) {
-    temp = SHA1_ROTL(5,A) + SHA_Parity(B, C, D) + E + W[t] + K[1];
-    E = D;
-    D = C;
-    C = SHA1_ROTL(30,B);
-    B = A;
-    A = temp;
-  }
-
-  for (t = 40; t < 60; t++) {
-    temp = SHA1_ROTL(5,A) + SHA_Maj(B, C, D) + E + W[t] + K[2];
-    E = D;
-    D = C;
-    C = SHA1_ROTL(30,B);
-    B = A;
-    A = temp;
-  }
-
-  for (t = 60; t < 80; t++) {
-    temp = SHA1_ROTL(5,A) + SHA_Parity(B, C, D) + E + W[t] + K[3];
-    E = D;
-    D = C;
-    C = SHA1_ROTL(30,B);
-    B = A;
-    A = temp;
-  }
-
-  context->Intermediate_Hash[0] += A;
-  context->Intermediate_Hash[1] += B;
-  context->Intermediate_Hash[2] += C;
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 32]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  context->Intermediate_Hash[3] += D;
-  context->Intermediate_Hash[4] += E;
-
-  context->Message_Block_Index = 0;
-}
-
-8.2.2.  sha224-256.c
-
-/*************************** sha224-256.c ***************************/
-/********************* See RFC 4634 for details *********************/
-/*
- * Description:
- *   This file implements the Secure Hash Signature Standard
- *   algorithms as defined in the National Institute of Standards
- *   and Technology Federal Information Processing Standards
- *   Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
- *   published on August 1, 2002, and the FIPS PUB 180-2 Change
- *   Notice published on February 28, 2004.
- *
- *   A combined document showing all algorithms is available at
- *       http://csrc.nist.gov/publications/fips/
- *       fips180-2/fips180-2withchangenotice.pdf
- *
- *   The SHA-224 and SHA-256 algorithms produce 224-bit and 256-bit
- *   message digests for a given data stream. It should take about
- *   2**n steps to find a message with the same digest as a given
- *   message and 2**(n/2) to find any two messages with the same
- *   digest, when n is the digest size in bits. Therefore, this
- *   algorithm can serve as a means of providing a
- *   "fingerprint" for a message.
- *
- * Portability Issues:
- *   SHA-224 and SHA-256 are defined in terms of 32-bit "words".
- *   This code uses <stdint.h> (included via "sha.h") to define 32
- *   and 8 bit unsigned integer types. If your C compiler does not
- *   support 32 bit unsigned integers, this code is not
- *   appropriate.
- *
- * Caveats:
- *   SHA-224 and SHA-256 are designed to work with messages less
- *   than 2^64 bits long. This implementation uses SHA224/256Input()
- *   to hash the bits that are a multiple of the size of an 8-bit
- *   character, and then uses SHA224/256FinalBits() to hash the
- *   final few bits of the input.
- */
-
-#include "sha.h"
-#include "sha-private.h"
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 33]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/* Define the SHA shift, rotate left and rotate right macro */
-#define SHA256_SHR(bits,word)      ((word) >> (bits))
-#define SHA256_ROTL(bits,word)                         \
-  (((word) << (bits)) | ((word) >> (32-(bits))))
-#define SHA256_ROTR(bits,word)                         \
-  (((word) >> (bits)) | ((word) << (32-(bits))))
-
-/* Define the SHA SIGMA and sigma macros */
-#define SHA256_SIGMA0(word)   \
-  (SHA256_ROTR( 2,word) ^ SHA256_ROTR(13,word) ^ SHA256_ROTR(22,word))
-#define SHA256_SIGMA1(word)   \
-  (SHA256_ROTR( 6,word) ^ SHA256_ROTR(11,word) ^ SHA256_ROTR(25,word))
-#define SHA256_sigma0(word)   \
-  (SHA256_ROTR( 7,word) ^ SHA256_ROTR(18,word) ^ SHA256_SHR( 3,word))
-#define SHA256_sigma1(word)   \
-  (SHA256_ROTR(17,word) ^ SHA256_ROTR(19,word) ^ SHA256_SHR(10,word))
-
-/*
- * add "length" to the length
- */
-static uint32_t addTemp;
-#define SHA224_256AddLength(context, length)               \
-  (addTemp = (context)->Length_Low, (context)->Corrupted = \
-    (((context)->Length_Low += (length)) < addTemp) &&     \
-    (++(context)->Length_High == 0) ? 1 : 0)
-
-/* Local Function Prototypes */
-static void SHA224_256Finalize(SHA256Context *context,
-  uint8_t Pad_Byte);
-static void SHA224_256PadMessage(SHA256Context *context,
-  uint8_t Pad_Byte);
-static void SHA224_256ProcessMessageBlock(SHA256Context *context);
-static int SHA224_256Reset(SHA256Context *context, uint32_t *H0);
-static int SHA224_256ResultN(SHA256Context *context,
-  uint8_t Message_Digest[], int HashSize);
-
-/* Initial Hash Values: FIPS-180-2 Change Notice 1 */
-static uint32_t SHA224_H0[SHA256HashSize/4] = {
-    0xC1059ED8, 0x367CD507, 0x3070DD17, 0xF70E5939,
-    0xFFC00B31, 0x68581511, 0x64F98FA7, 0xBEFA4FA4
-};
-
-/* Initial Hash Values: FIPS-180-2 section 5.3.2 */
-static uint32_t SHA256_H0[SHA256HashSize/4] = {
-  0x6A09E667, 0xBB67AE85, 0x3C6EF372, 0xA54FF53A,
-  0x510E527F, 0x9B05688C, 0x1F83D9AB, 0x5BE0CD19
-};
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 34]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- * SHA224Reset
- *
- * Description:
- *   This function will initialize the SHA384Context in preparation
- *   for computing a new SHA224 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA224Reset(SHA224Context *context)
-{
-  return SHA224_256Reset(context, SHA224_H0);
-}
-
-/*
- * SHA224Input
- *
- * Description:
- *   This function accepts an array of octets as the next portion
- *   of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_array: [in]
- *     An array of characters representing the next portion of
- *     the message.
- *   length: [in]
- *     The length of the message in message_array
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA224Input(SHA224Context *context, const uint8_t *message_array,
-    unsigned int length)
-{
-  return SHA256Input(context, message_array, length);
-}
-
-/*
- * SHA224FinalBits
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 35]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA224FinalBits( SHA224Context *context,
-    const uint8_t message_bits, unsigned int length)
-{
-  return SHA256FinalBits(context, message_bits, length);
-}
-
-/*
- * SHA224Result
- *
- * Description:
- *   This function will return the 224-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 28th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA224Result(SHA224Context *context,
-    uint8_t Message_Digest[SHA224HashSize])
-{
-  return SHA224_256ResultN(context, Message_Digest, SHA224HashSize);
-}
-
-/*
- * SHA256Reset
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 36]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- * Description:
- *   This function will initialize the SHA256Context in preparation
- *   for computing a new SHA256 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA256Reset(SHA256Context *context)
-{
-  return SHA224_256Reset(context, SHA256_H0);
-}
-
-/*
- * SHA256Input
- *
- * Description:
- *   This function accepts an array of octets as the next portion
- *   of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_array: [in]
- *     An array of characters representing the next portion of
- *     the message.
- *   length: [in]
- *     The length of the message in message_array
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA256Input(SHA256Context *context, const uint8_t *message_array,
-    unsigned int length)
-{
-  if (!length)
-    return shaSuccess;
-
-  if (!context || !message_array)
-    return shaNull;
-
-  if (context->Computed) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 37]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  }
-
-  if (context->Corrupted)
-     return context->Corrupted;
-
-  while (length-- && !context->Corrupted) {
-    context->Message_Block[context->Message_Block_Index++] =
-            (*message_array & 0xFF);
-
-    if (!SHA224_256AddLength(context, 8) &&
-      (context->Message_Block_Index == SHA256_Message_Block_Size))
-      SHA224_256ProcessMessageBlock(context);
-
-    message_array++;
-  }
-
-  return shaSuccess;
-
-}
-
-/*
- * SHA256FinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA256FinalBits(SHA256Context *context,
-    const uint8_t message_bits, unsigned int length)
-{
-  uint8_t masks[8] = {
-      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
-      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
-      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
-      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
-  };
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 38]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  uint8_t markbit[8] = {
-      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
-      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
-      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
-      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
-  };
-
-  if (!length)
-    return shaSuccess;
-
-  if (!context)
-    return shaNull;
-
-  if ((context->Computed) || (length >= 8) || (length == 0)) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-    return context->Corrupted;
-
-  SHA224_256AddLength(context, length);
-  SHA224_256Finalize(context, (uint8_t)
-    ((message_bits & masks[length]) | markbit[length]));
-
-  return shaSuccess;
-}
-
-/*
- * SHA256Result
- *
- * Description:
- *   This function will return the 256-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 32nd element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA256Result(SHA256Context *context, uint8_t Message_Digest[])
-{
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 39]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  return SHA224_256ResultN(context, Message_Digest, SHA256HashSize);
-}
-
-/*
- * SHA224_256Finalize
- *
- * Description:
- *   This helper function finishes off the digest calculations.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   sha Error Code.
- */
-static void SHA224_256Finalize(SHA256Context *context,
-    uint8_t Pad_Byte)
-{
-  int i;
-  SHA224_256PadMessage(context, Pad_Byte);
-  /* message may be sensitive, so clear it out */
-  for (i = 0; i < SHA256_Message_Block_Size; ++i)
-    context->Message_Block[i] = 0;
-  context->Length_Low = 0;  /* and clear length */
-  context->Length_High = 0;
-  context->Computed = 1;
-}
-
-/*
- * SHA224_256PadMessage
- *
- * Description:
- *   According to the standard, the message must be padded to an
- *   even 512 bits. The first padding bit must be a '1'. The
- *   last 64 bits represent the length of the original message.
- *   All bits in between should be 0. This helper function will pad
- *   the message according to those rules by filling the
- *   Message_Block array accordingly. When it returns, it can be
- *   assumed that the message digest has been computed.
- *
- * Parameters:
- *   context: [in/out]
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 40]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *     The context to pad
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   Nothing.
- */
-static void SHA224_256PadMessage(SHA256Context *context,
-    uint8_t Pad_Byte)
-{
-  /*
-   * Check to see if the current message block is too small to hold
-   * the initial padding bits and length. If so, we will pad the
-   * block, process it, and then continue padding into a second
-   * block.
-   */
-  if (context->Message_Block_Index >= (SHA256_Message_Block_Size-8)) {
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-    while (context->Message_Block_Index < SHA256_Message_Block_Size)
-      context->Message_Block[context->Message_Block_Index++] = 0;
-    SHA224_256ProcessMessageBlock(context);
-  } else
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-
-  while (context->Message_Block_Index < (SHA256_Message_Block_Size-8))
-    context->Message_Block[context->Message_Block_Index++] = 0;
-
-  /*
-   * Store the message length as the last 8 octets
-   */
-  context->Message_Block[56] = (uint8_t)(context->Length_High >> 24);
-  context->Message_Block[57] = (uint8_t)(context->Length_High >> 16);
-  context->Message_Block[58] = (uint8_t)(context->Length_High >> 8);
-  context->Message_Block[59] = (uint8_t)(context->Length_High);
-  context->Message_Block[60] = (uint8_t)(context->Length_Low >> 24);
-  context->Message_Block[61] = (uint8_t)(context->Length_Low >> 16);
-  context->Message_Block[62] = (uint8_t)(context->Length_Low >> 8);
-  context->Message_Block[63] = (uint8_t)(context->Length_Low);
-
-  SHA224_256ProcessMessageBlock(context);
-}
-
-/*
- * SHA224_256ProcessMessageBlock
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 41]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Description:
- *   This function will process the next 512 bits of the message
- *   stored in the Message_Block array.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *
- * Returns:
- *   Nothing.
- *
- * Comments:
- *   Many of the variable names in this code, especially the
- *   single character names, were used because those were the
- *   names used in the publication.
- */
-static void SHA224_256ProcessMessageBlock(SHA256Context *context)
-{
-  /* Constants defined in FIPS-180-2, section 4.2.2 */
-  static const uint32_t K[64] = {
-      0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b,
-      0x59f111f1, 0x923f82a4, 0xab1c5ed5, 0xd807aa98, 0x12835b01,
-      0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7,
-      0xc19bf174, 0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc,
-      0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da, 0x983e5152,
-      0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147,
-      0x06ca6351, 0x14292967, 0x27b70a85, 0x2e1b2138, 0x4d2c6dfc,
-      0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
-      0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819,
-      0xd6990624, 0xf40e3585, 0x106aa070, 0x19a4c116, 0x1e376c08,
-      0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f,
-      0x682e6ff3, 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208,
-      0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
-  };
-  int        t, t4;                   /* Loop counter */
-  uint32_t   temp1, temp2;            /* Temporary word value */
-  uint32_t   W[64];                   /* Word sequence */
-  uint32_t   A, B, C, D, E, F, G, H;  /* Word buffers */
-
-  /*
-   * Initialize the first 16 words in the array W
-   */
-  for (t = t4 = 0; t < 16; t++, t4 += 4)
-    W[t] = (((uint32_t)context->Message_Block[t4]) << 24) |
-           (((uint32_t)context->Message_Block[t4 + 1]) << 16) |
-           (((uint32_t)context->Message_Block[t4 + 2]) << 8) |
-           (((uint32_t)context->Message_Block[t4 + 3]));
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 42]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  for (t = 16; t < 64; t++)
-    W[t] = SHA256_sigma1(W[t-2]) + W[t-7] +
-        SHA256_sigma0(W[t-15]) + W[t-16];
-
-  A = context->Intermediate_Hash[0];
-  B = context->Intermediate_Hash[1];
-  C = context->Intermediate_Hash[2];
-  D = context->Intermediate_Hash[3];
-  E = context->Intermediate_Hash[4];
-  F = context->Intermediate_Hash[5];
-  G = context->Intermediate_Hash[6];
-  H = context->Intermediate_Hash[7];
-
-  for (t = 0; t < 64; t++) {
-    temp1 = H + SHA256_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
-    temp2 = SHA256_SIGMA0(A) + SHA_Maj(A,B,C);
-    H = G;
-    G = F;
-    F = E;
-    E = D + temp1;
-    D = C;
-    C = B;
-    B = A;
-    A = temp1 + temp2;
-  }
-
-  context->Intermediate_Hash[0] += A;
-  context->Intermediate_Hash[1] += B;
-  context->Intermediate_Hash[2] += C;
-  context->Intermediate_Hash[3] += D;
-  context->Intermediate_Hash[4] += E;
-  context->Intermediate_Hash[5] += F;
-  context->Intermediate_Hash[6] += G;
-  context->Intermediate_Hash[7] += H;
-
-  context->Message_Block_Index = 0;
-}
-
-/*
- * SHA224_256Reset
- *
- * Description:
- *   This helper function will initialize the SHA256Context in
- *   preparation for computing a new SHA256 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 43]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   H0
- *     The initial hash value to use.
- *
- * Returns:
- *   sha Error Code.
- */
-static int SHA224_256Reset(SHA256Context *context, uint32_t *H0)
-{
-  if (!context)
-    return shaNull;
-
-  context->Length_Low           = 0;
-  context->Length_High          = 0;
-  context->Message_Block_Index  = 0;
-
-  context->Intermediate_Hash[0] = H0[0];
-  context->Intermediate_Hash[1] = H0[1];
-  context->Intermediate_Hash[2] = H0[2];
-  context->Intermediate_Hash[3] = H0[3];
-  context->Intermediate_Hash[4] = H0[4];
-  context->Intermediate_Hash[5] = H0[5];
-  context->Intermediate_Hash[6] = H0[6];
-  context->Intermediate_Hash[7] = H0[7];
-
-  context->Computed  = 0;
-  context->Corrupted = 0;
-
-  return shaSuccess;
-}
-
-/*
- * SHA224_256ResultN
- *
- * Description:
- *   This helper function will return the 224-bit or 256-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 28th/32nd element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *   HashSize: [in]
- *     The size of the hash, either 28 or 32.
- *
- * Returns:
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 44]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   sha Error Code.
- */
-static int SHA224_256ResultN(SHA256Context *context,
-    uint8_t Message_Digest[], int HashSize)
-{
-  int i;
-
-  if (!context || !Message_Digest)
-    return shaNull;
-
-  if (context->Corrupted)
-    return context->Corrupted;
-
-  if (!context->Computed)
-    SHA224_256Finalize(context, 0x80);
-
-  for (i = 0; i < HashSize; ++i)
-    Message_Digest[i] = (uint8_t)
-      (context->Intermediate_Hash[i>>2] >> 8 * ( 3 - ( i & 0x03 ) ));
-
-  return shaSuccess;
-}
-
-8.2.3.  sha384-512.c
-
-/*************************** sha384-512.c ***************************/
-/********************* See RFC 4634 for details *********************/
-/*
- * Description:
- *   This file implements the Secure Hash Signature Standard
- *   algorithms as defined in the National Institute of Standards
- *   and Technology Federal Information Processing Standards
- *   Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
- *   published on August 1, 2002, and the FIPS PUB 180-2 Change
- *   Notice published on February 28, 2004.
- *
- *   A combined document showing all algorithms is available at
- *       http://csrc.nist.gov/publications/fips/
- *       fips180-2/fips180-2withchangenotice.pdf
- *
- *   The SHA-384 and SHA-512 algorithms produce 384-bit and 512-bit
- *   message digests for a given data stream. It should take about
- *   2**n steps to find a message with the same digest as a given
- *   message and 2**(n/2) to find any two messages with the same
- *   digest, when n is the digest size in bits. Therefore, this
- *   algorithm can serve as a means of providing a
- *   "fingerprint" for a message.
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 45]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Portability Issues:
- *   SHA-384 and SHA-512 are defined in terms of 64-bit "words",
- *   but if USE_32BIT_ONLY is #defined, this code is implemented in
- *   terms of 32-bit "words". This code uses <stdint.h> (included
- *   via "sha.h") to define the 64, 32 and 8 bit unsigned integer
- *   types. If your C compiler does not support 64 bit unsigned
- *   integers, and you do not #define USE_32BIT_ONLY, this code is
- *   not appropriate.
- *
- * Caveats:
- *   SHA-384 and SHA-512 are designed to work with messages less
- *   than 2^128 bits long. This implementation uses
- *   SHA384/512Input() to hash the bits that are a multiple of the
- *   size of an 8-bit character, and then uses SHA384/256FinalBits()
- *   to hash the final few bits of the input.
- *
- */
-
-#include "sha.h"
-#include "sha-private.h"
-
-#ifdef USE_32BIT_ONLY
-/*
- * Define 64-bit arithmetic in terms of 32-bit arithmetic.
- * Each 64-bit number is represented in a 2-word array.
- * All macros are defined such that the result is the last parameter.
- */
-
-/*
- * Define shift, rotate left and rotate right functions
- */
-#define SHA512_SHR(bits, word, ret) (                          \
-    /* (((uint64_t)((word))) >> (bits)) */                     \
-    (ret)[0] = (((bits) < 32) && ((bits) >= 0)) ?              \
-      ((word)[0] >> (bits)) : 0,                               \
-    (ret)[1] = ((bits) > 32) ? ((word)[0] >> ((bits) - 32)) :  \
-      ((bits) == 32) ? (word)[0] :                             \
-      ((bits) >= 0) ?                                          \
-        (((word)[0] << (32 - (bits))) |                        \
-        ((word)[1] >> (bits))) : 0 )
-
-#define SHA512_SHL(bits, word, ret) (                          \
-    /* (((uint64_t)(word)) << (bits)) */                       \
-    (ret)[0] = ((bits) > 32) ? ((word)[1] << ((bits) - 32)) :  \
-         ((bits) == 32) ? (word)[1] :                          \
-         ((bits) >= 0) ?                                       \
-           (((word)[0] << (bits)) |                            \
-           ((word)[1] >> (32 - (bits)))) :                     \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 46]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-         0,                                                    \
-    (ret)[1] = (((bits) < 32) && ((bits) >= 0)) ?              \
-        ((word)[1] << (bits)) : 0 )
-
-/*
- * Define 64-bit OR
- */
-#define SHA512_OR(word1, word2, ret) (                         \
-    (ret)[0] = (word1)[0] | (word2)[0],                        \
-    (ret)[1] = (word1)[1] | (word2)[1] )
-
-/*
- * Define 64-bit XOR
- */
-#define SHA512_XOR(word1, word2, ret) (                        \
-    (ret)[0] = (word1)[0] ^ (word2)[0],                        \
-    (ret)[1] = (word1)[1] ^ (word2)[1] )
-
-/*
- * Define 64-bit AND
- */
-#define SHA512_AND(word1, word2, ret) (                        \
-    (ret)[0] = (word1)[0] & (word2)[0],                        \
-    (ret)[1] = (word1)[1] & (word2)[1] )
-
-/*
- * Define 64-bit TILDA
- */
-#define SHA512_TILDA(word, ret)                                \
-  ( (ret)[0] = ~(word)[0], (ret)[1] = ~(word)[1] )
-
-/*
- * Define 64-bit ADD
- */
-#define SHA512_ADD(word1, word2, ret) (                        \
-    (ret)[1] = (word1)[1], (ret)[1] += (word2)[1],             \
-    (ret)[0] = (word1)[0] + (word2)[0] + ((ret)[1] < (word1)[1]) )
-
-/*
- * Add the 4word value in word2 to word1.
- */
-static uint32_t ADDTO4_temp, ADDTO4_temp2;
-#define SHA512_ADDTO4(word1, word2) (                          \
-    ADDTO4_temp = (word1)[3],                                  \
-    (word1)[3] += (word2)[3],                                  \
-    ADDTO4_temp2 = (word1)[2],                                 \
-    (word1)[2] += (word2)[2] + ((word1)[3] < ADDTO4_temp),     \
-    ADDTO4_temp = (word1)[1],                                  \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 47]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    (word1)[1] += (word2)[1] + ((word1)[2] < ADDTO4_temp2),    \
-    (word1)[0] += (word2)[0] + ((word1)[1] < ADDTO4_temp) )
-
-/*
- * Add the 2word value in word2 to word1.
- */
-static uint32_t ADDTO2_temp;
-#define SHA512_ADDTO2(word1, word2) (                          \
-    ADDTO2_temp = (word1)[1],                                  \
-    (word1)[1] += (word2)[1],                                  \
-    (word1)[0] += (word2)[0] + ((word1)[1] < ADDTO2_temp) )
-
-/*
- * SHA rotate   ((word >> bits) | (word << (64-bits)))
- */
-static uint32_t ROTR_temp1[2], ROTR_temp2[2];
-#define SHA512_ROTR(bits, word, ret) (                         \
-    SHA512_SHR((bits), (word), ROTR_temp1),                    \
-    SHA512_SHL(64-(bits), (word), ROTR_temp2),                 \
-    SHA512_OR(ROTR_temp1, ROTR_temp2, (ret)) )
-
-/*
- * Define the SHA SIGMA and sigma macros
- *  SHA512_ROTR(28,word) ^ SHA512_ROTR(34,word) ^ SHA512_ROTR(39,word)
- */
-static uint32_t SIGMA0_temp1[2], SIGMA0_temp2[2],
-  SIGMA0_temp3[2], SIGMA0_temp4[2];
-#define SHA512_SIGMA0(word, ret) (                             \
-    SHA512_ROTR(28, (word), SIGMA0_temp1),                     \
-    SHA512_ROTR(34, (word), SIGMA0_temp2),                     \
-    SHA512_ROTR(39, (word), SIGMA0_temp3),                     \
-    SHA512_XOR(SIGMA0_temp2, SIGMA0_temp3, SIGMA0_temp4),      \
-    SHA512_XOR(SIGMA0_temp1, SIGMA0_temp4, (ret)) )
-
-/*
- * SHA512_ROTR(14,word) ^ SHA512_ROTR(18,word) ^ SHA512_ROTR(41,word)
- */
-static uint32_t SIGMA1_temp1[2], SIGMA1_temp2[2],
-  SIGMA1_temp3[2], SIGMA1_temp4[2];
-#define SHA512_SIGMA1(word, ret) (                             \
-    SHA512_ROTR(14, (word), SIGMA1_temp1),                     \
-    SHA512_ROTR(18, (word), SIGMA1_temp2),                     \
-    SHA512_ROTR(41, (word), SIGMA1_temp3),                     \
-    SHA512_XOR(SIGMA1_temp2, SIGMA1_temp3, SIGMA1_temp4),      \
-    SHA512_XOR(SIGMA1_temp1, SIGMA1_temp4, (ret)) )
-
-/*
- * (SHA512_ROTR( 1,word) ^ SHA512_ROTR( 8,word) ^ SHA512_SHR( 7,word))
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 48]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- */
-static uint32_t sigma0_temp1[2], sigma0_temp2[2],
-  sigma0_temp3[2], sigma0_temp4[2];
-#define SHA512_sigma0(word, ret) (                             \
-    SHA512_ROTR( 1, (word), sigma0_temp1),                     \
-    SHA512_ROTR( 8, (word), sigma0_temp2),                     \
-    SHA512_SHR( 7, (word), sigma0_temp3),                      \
-    SHA512_XOR(sigma0_temp2, sigma0_temp3, sigma0_temp4),      \
-    SHA512_XOR(sigma0_temp1, sigma0_temp4, (ret)) )
-
-/*
- * (SHA512_ROTR(19,word) ^ SHA512_ROTR(61,word) ^ SHA512_SHR( 6,word))
- */
-static uint32_t sigma1_temp1[2], sigma1_temp2[2],
-  sigma1_temp3[2], sigma1_temp4[2];
-#define SHA512_sigma1(word, ret) (                             \
-    SHA512_ROTR(19, (word), sigma1_temp1),                     \
-    SHA512_ROTR(61, (word), sigma1_temp2),                     \
-    SHA512_SHR( 6, (word), sigma1_temp3),                      \
-    SHA512_XOR(sigma1_temp2, sigma1_temp3, sigma1_temp4),      \
-    SHA512_XOR(sigma1_temp1, sigma1_temp4, (ret)) )
-
-#undef SHA_Ch
-#undef SHA_Maj
-
-#ifndef USE_MODIFIED_MACROS
-/*
- * These definitions are the ones used in FIPS-180-2, section 4.1.3
- *  Ch(x,y,z)   ((x & y) ^ (~x & z))
- */
-static uint32_t Ch_temp1[2], Ch_temp2[2], Ch_temp3[2];
-#define SHA_Ch(x, y, z, ret) (                                 \
-    SHA512_AND(x, y, Ch_temp1),                                \
-    SHA512_TILDA(x, Ch_temp2),                                 \
-    SHA512_AND(Ch_temp2, z, Ch_temp3),                         \
-    SHA512_XOR(Ch_temp1, Ch_temp3, (ret)) )
-/*
- *  Maj(x,y,z)  (((x)&(y)) ^ ((x)&(z)) ^ ((y)&(z)))
- */
-static uint32_t Maj_temp1[2], Maj_temp2[2],
-  Maj_temp3[2], Maj_temp4[2];
-#define SHA_Maj(x, y, z, ret) (                                \
-    SHA512_AND(x, y, Maj_temp1),                               \
-    SHA512_AND(x, z, Maj_temp2),                               \
-    SHA512_AND(y, z, Maj_temp3),                               \
-    SHA512_XOR(Maj_temp2, Maj_temp3, Maj_temp4),               \
-    SHA512_XOR(Maj_temp1, Maj_temp4, (ret)) )
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 49]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-#else /* !USE_32BIT_ONLY */
-/*
- * These definitions are potentially faster equivalents for the ones
- * used in FIPS-180-2, section 4.1.3.
- *   ((x & y) ^ (~x & z)) becomes
- *   ((x & (y ^ z)) ^ z)
- */
-#define SHA_Ch(x, y, z, ret) (                                 \
-   (ret)[0] = (((x)[0] & ((y)[0] ^ (z)[0])) ^ (z)[0]),         \
-   (ret)[1] = (((x)[1] & ((y)[1] ^ (z)[1])) ^ (z)[1]) )
-
-/*
- *   ((x & y) ^ (x & z) ^ (y & z)) becomes
- *   ((x & (y | z)) | (y & z))
- */
-#define SHA_Maj(x, y, z, ret) (                                 \
-   ret[0] = (((x)[0] & ((y)[0] | (z)[0])) | ((y)[0] & (z)[0])), \
-   ret[1] = (((x)[1] & ((y)[1] | (z)[1])) | ((y)[1] & (z)[1])) )
-#endif /* USE_MODIFIED_MACROS */
-
-/*
- * add "length" to the length
- */
-static uint32_t addTemp[4] = { 0, 0, 0, 0 };
-#define SHA384_512AddLength(context, length) (                        \
-    addTemp[3] = (length), SHA512_ADDTO4((context)->Length, addTemp), \
-    (context)->Corrupted = (((context)->Length[3] == 0) &&            \
-       ((context)->Length[2] == 0) && ((context)->Length[1] == 0) &&  \
-       ((context)->Length[0] < 8)) ? 1 : 0 )
-
-/* Local Function Prototypes */
-static void SHA384_512Finalize(SHA512Context *context,
-  uint8_t Pad_Byte);
-static void SHA384_512PadMessage(SHA512Context *context,
-  uint8_t Pad_Byte);
-static void SHA384_512ProcessMessageBlock(SHA512Context *context);
-static int SHA384_512Reset(SHA512Context *context, uint32_t H0[]);
-static int SHA384_512ResultN( SHA512Context *context,
-  uint8_t Message_Digest[], int HashSize);
-
-/* Initial Hash Values: FIPS-180-2 sections 5.3.3 and 5.3.4 */
-static uint32_t SHA384_H0[SHA512HashSize/4] = {
-    0xCBBB9D5D, 0xC1059ED8, 0x629A292A, 0x367CD507, 0x9159015A,
-    0x3070DD17, 0x152FECD8, 0xF70E5939, 0x67332667, 0xFFC00B31,
-    0x8EB44A87, 0x68581511, 0xDB0C2E0D, 0x64F98FA7, 0x47B5481D,
-    0xBEFA4FA4
-};
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 50]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-static uint32_t SHA512_H0[SHA512HashSize/4] = {
-    0x6A09E667, 0xF3BCC908, 0xBB67AE85, 0x84CAA73B, 0x3C6EF372,
-    0xFE94F82B, 0xA54FF53A, 0x5F1D36F1, 0x510E527F, 0xADE682D1,
-    0x9B05688C, 0x2B3E6C1F, 0x1F83D9AB, 0xFB41BD6B, 0x5BE0CD19,
-    0x137E2179
-};
-
-#else /* !USE_32BIT_ONLY */
-
-/* Define the SHA shift, rotate left and rotate right macro */
-#define SHA512_SHR(bits,word)  (((uint64_t)(word)) >> (bits))
-#define SHA512_ROTR(bits,word) ((((uint64_t)(word)) >> (bits)) | \
-                                (((uint64_t)(word)) << (64-(bits))))
-
-/* Define the SHA SIGMA and sigma macros */
-#define SHA512_SIGMA0(word)   \
- (SHA512_ROTR(28,word) ^ SHA512_ROTR(34,word) ^ SHA512_ROTR(39,word))
-#define SHA512_SIGMA1(word)   \
- (SHA512_ROTR(14,word) ^ SHA512_ROTR(18,word) ^ SHA512_ROTR(41,word))
-#define SHA512_sigma0(word)   \
- (SHA512_ROTR( 1,word) ^ SHA512_ROTR( 8,word) ^ SHA512_SHR( 7,word))
-#define SHA512_sigma1(word)   \
- (SHA512_ROTR(19,word) ^ SHA512_ROTR(61,word) ^ SHA512_SHR( 6,word))
-
-/*
- * add "length" to the length
- */
-static uint64_t addTemp;
-#define SHA384_512AddLength(context, length)                   \
-   (addTemp = context->Length_Low, context->Corrupted =        \
-    ((context->Length_Low += length) < addTemp) &&             \
-    (++context->Length_High == 0) ? 1 : 0)
-
-/* Local Function Prototypes */
-static void SHA384_512Finalize(SHA512Context *context,
-  uint8_t Pad_Byte);
-static void SHA384_512PadMessage(SHA512Context *context,
-  uint8_t Pad_Byte);
-static void SHA384_512ProcessMessageBlock(SHA512Context *context);
-static int SHA384_512Reset(SHA512Context *context, uint64_t H0[]);
-static int SHA384_512ResultN(SHA512Context *context,
-  uint8_t Message_Digest[], int HashSize);
-
-/* Initial Hash Values: FIPS-180-2 sections 5.3.3 and 5.3.4 */
-static uint64_t SHA384_H0[] = {
-    0xCBBB9D5DC1059ED8ll, 0x629A292A367CD507ll, 0x9159015A3070DD17ll,
-    0x152FECD8F70E5939ll, 0x67332667FFC00B31ll, 0x8EB44A8768581511ll,
-    0xDB0C2E0D64F98FA7ll, 0x47B5481DBEFA4FA4ll
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 51]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-};
-static uint64_t SHA512_H0[] = {
-    0x6A09E667F3BCC908ll, 0xBB67AE8584CAA73Bll, 0x3C6EF372FE94F82Bll,
-    0xA54FF53A5F1D36F1ll, 0x510E527FADE682D1ll, 0x9B05688C2B3E6C1Fll,
-    0x1F83D9ABFB41BD6Bll, 0x5BE0CD19137E2179ll
-};
-
-#endif /* USE_32BIT_ONLY */
-
-/*
- * SHA384Reset
- *
- * Description:
- *   This function will initialize the SHA384Context in preparation
- *   for computing a new SHA384 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA384Reset(SHA384Context *context)
-{
-  return SHA384_512Reset(context, SHA384_H0);
-}
-
-/*
- * SHA384Input
- *
- * Description:
- *   This function accepts an array of octets as the next portion
- *   of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_array: [in]
- *     An array of characters representing the next portion of
- *     the message.
- *   length: [in]
- *     The length of the message in message_array
- *
- * Returns:
- *   sha Error Code.
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 52]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- */
-int SHA384Input(SHA384Context *context,
-    const uint8_t *message_array, unsigned int length)
-{
-  return SHA512Input(context, message_array, length);
-}
-
-/*
- * SHA384FinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA384FinalBits(SHA384Context *context,
-    const uint8_t message_bits, unsigned int length)
-{
-  return SHA512FinalBits(context, message_bits, length);
-}
-
-/*
- * SHA384Result
- *
- * Description:
- *   This function will return the 384-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 48th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 53]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA384Result(SHA384Context *context,
-    uint8_t Message_Digest[SHA384HashSize])
-{
-  return SHA384_512ResultN(context, Message_Digest, SHA384HashSize);
-}
-
-/*
- * SHA512Reset
- *
- * Description:
- *   This function will initialize the SHA512Context in preparation
- *   for computing a new SHA512 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA512Reset(SHA512Context *context)
-{
-  return SHA384_512Reset(context, SHA512_H0);
-}
-
-/*
- * SHA512Input
- *
- * Description:
- *   This function accepts an array of octets as the next portion
- *   of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_array: [in]
- *     An array of characters representing the next portion of
- *     the message.
- *   length: [in]
- *     The length of the message in message_array
- *
- * Returns:
- *   sha Error Code.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 54]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- */
-int SHA512Input(SHA512Context *context,
-        const uint8_t *message_array,
-        unsigned int length)
-{
-  if (!length)
-    return shaSuccess;
-
-  if (!context || !message_array)
-    return shaNull;
-
-  if (context->Computed) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-     return context->Corrupted;
-
-  while (length-- && !context->Corrupted) {
-    context->Message_Block[context->Message_Block_Index++] =
-            (*message_array & 0xFF);
-
-    if (!SHA384_512AddLength(context, 8) &&
-      (context->Message_Block_Index == SHA512_Message_Block_Size))
-      SHA384_512ProcessMessageBlock(context);
-
-    message_array++;
-  }
-
-  return shaSuccess;
-}
-
-/*
- * SHA512FinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 55]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA512FinalBits(SHA512Context *context,
-    const uint8_t message_bits, unsigned int length)
-{
-  uint8_t masks[8] = {
-      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
-      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
-      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
-      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
-  };
-  uint8_t markbit[8] = {
-      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
-      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
-      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
-      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
-  };
-
-  if (!length)
-    return shaSuccess;
-
-  if (!context)
-    return shaNull;
-
-  if ((context->Computed) || (length >= 8) || (length == 0)) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-     return context->Corrupted;
-
-  SHA384_512AddLength(context, length);
-  SHA384_512Finalize(context, (uint8_t)
-    ((message_bits & masks[length]) | markbit[length]));
-
-  return shaSuccess;
-}
-
-/*
- * SHA384_512Finalize
- *
- * Description:
- *   This helper function finishes off the digest calculations.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 56]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-static void SHA384_512Finalize(SHA512Context *context,
-    uint8_t Pad_Byte)
-{
-  int_least16_t i;
-  SHA384_512PadMessage(context, Pad_Byte);
-  /* message may be sensitive, clear it out */
-  for (i = 0; i < SHA512_Message_Block_Size; ++i)
-    context->Message_Block[i] = 0;
-#ifdef USE_32BIT_ONLY    /* and clear length */
-  context->Length[0] = context->Length[1] = 0;
-  context->Length[2] = context->Length[3] = 0;
-#else /* !USE_32BIT_ONLY */
-  context->Length_Low = 0;
-  context->Length_High = 0;
-#endif /* USE_32BIT_ONLY */
-  context->Computed = 1;
-}
-
-/*
- * SHA512Result
- *
- * Description:
- *   This function will return the 512-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 64th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 57]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   sha Error Code.
- *
- */
-int SHA512Result(SHA512Context *context,
-    uint8_t Message_Digest[SHA512HashSize])
-{
-  return SHA384_512ResultN(context, Message_Digest, SHA512HashSize);
-}
-
-/*
- * SHA384_512PadMessage
- *
- * Description:
- *   According to the standard, the message must be padded to an
- *   even 1024 bits. The first padding bit must be a '1'. The
- *   last 128 bits represent the length of the original message.
- *   All bits in between should be 0. This helper function will
- *   pad the message according to those rules by filling the
- *   Message_Block array accordingly. When it returns, it can be
- *   assumed that the message digest has been computed.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to pad
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   Nothing.
- *
- */
-static void SHA384_512PadMessage(SHA512Context *context,
-    uint8_t Pad_Byte)
-{
-  /*
-   * Check to see if the current message block is too small to hold
-   * the initial padding bits and length. If so, we will pad the
-   * block, process it, and then continue padding into a second
-   * block.
-   */
-  if (context->Message_Block_Index >= (SHA512_Message_Block_Size-16)) {
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-    while (context->Message_Block_Index < SHA512_Message_Block_Size)
-      context->Message_Block[context->Message_Block_Index++] = 0;
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 58]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    SHA384_512ProcessMessageBlock(context);
-  } else
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-
-  while (context->Message_Block_Index < (SHA512_Message_Block_Size-16))
-    context->Message_Block[context->Message_Block_Index++] = 0;
-
-  /*
-   * Store the message length as the last 16 octets
-   */
-#ifdef USE_32BIT_ONLY
-  context->Message_Block[112] = (uint8_t)(context->Length[0] >> 24);
-  context->Message_Block[113] = (uint8_t)(context->Length[0] >> 16);
-  context->Message_Block[114] = (uint8_t)(context->Length[0] >> 8);
-  context->Message_Block[115] = (uint8_t)(context->Length[0]);
-  context->Message_Block[116] = (uint8_t)(context->Length[1] >> 24);
-  context->Message_Block[117] = (uint8_t)(context->Length[1] >> 16);
-  context->Message_Block[118] = (uint8_t)(context->Length[1] >> 8);
-  context->Message_Block[119] = (uint8_t)(context->Length[1]);
-
-  context->Message_Block[120] = (uint8_t)(context->Length[2] >> 24);
-  context->Message_Block[121] = (uint8_t)(context->Length[2] >> 16);
-  context->Message_Block[122] = (uint8_t)(context->Length[2] >> 8);
-  context->Message_Block[123] = (uint8_t)(context->Length[2]);
-  context->Message_Block[124] = (uint8_t)(context->Length[3] >> 24);
-  context->Message_Block[125] = (uint8_t)(context->Length[3] >> 16);
-  context->Message_Block[126] = (uint8_t)(context->Length[3] >> 8);
-  context->Message_Block[127] = (uint8_t)(context->Length[3]);
-#else /* !USE_32BIT_ONLY */
-  context->Message_Block[112] = (uint8_t)(context->Length_High >> 56);
-  context->Message_Block[113] = (uint8_t)(context->Length_High >> 48);
-  context->Message_Block[114] = (uint8_t)(context->Length_High >> 40);
-  context->Message_Block[115] = (uint8_t)(context->Length_High >> 32);
-  context->Message_Block[116] = (uint8_t)(context->Length_High >> 24);
-  context->Message_Block[117] = (uint8_t)(context->Length_High >> 16);
-  context->Message_Block[118] = (uint8_t)(context->Length_High >> 8);
-  context->Message_Block[119] = (uint8_t)(context->Length_High);
-
-  context->Message_Block[120] = (uint8_t)(context->Length_Low >> 56);
-  context->Message_Block[121] = (uint8_t)(context->Length_Low >> 48);
-  context->Message_Block[122] = (uint8_t)(context->Length_Low >> 40);
-  context->Message_Block[123] = (uint8_t)(context->Length_Low >> 32);
-  context->Message_Block[124] = (uint8_t)(context->Length_Low >> 24);
-  context->Message_Block[125] = (uint8_t)(context->Length_Low >> 16);
-  context->Message_Block[126] = (uint8_t)(context->Length_Low >> 8);
-  context->Message_Block[127] = (uint8_t)(context->Length_Low);
-#endif /* USE_32BIT_ONLY */
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 59]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  SHA384_512ProcessMessageBlock(context);
-}
-
-/*
- * SHA384_512ProcessMessageBlock
- *
- * Description:
- *   This helper function will process the next 1024 bits of the
- *   message stored in the Message_Block array.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *
- * Returns:
- *   Nothing.
- *
- * Comments:
- *   Many of the variable names in this code, especially the
- *   single character names, were used because those were the
- *   names used in the publication.
- *
- *
- */
-static void SHA384_512ProcessMessageBlock(SHA512Context *context)
-{
-  /* Constants defined in FIPS-180-2, section 4.2.3 */
-#ifdef USE_32BIT_ONLY
-  static const uint32_t K[80*2] = {
-      0x428A2F98, 0xD728AE22, 0x71374491, 0x23EF65CD, 0xB5C0FBCF,
-      0xEC4D3B2F, 0xE9B5DBA5, 0x8189DBBC, 0x3956C25B, 0xF348B538,
-      0x59F111F1, 0xB605D019, 0x923F82A4, 0xAF194F9B, 0xAB1C5ED5,
-      0xDA6D8118, 0xD807AA98, 0xA3030242, 0x12835B01, 0x45706FBE,
-      0x243185BE, 0x4EE4B28C, 0x550C7DC3, 0xD5FFB4E2, 0x72BE5D74,
-      0xF27B896F, 0x80DEB1FE, 0x3B1696B1, 0x9BDC06A7, 0x25C71235,
-      0xC19BF174, 0xCF692694, 0xE49B69C1, 0x9EF14AD2, 0xEFBE4786,
-      0x384F25E3, 0x0FC19DC6, 0x8B8CD5B5, 0x240CA1CC, 0x77AC9C65,
-      0x2DE92C6F, 0x592B0275, 0x4A7484AA, 0x6EA6E483, 0x5CB0A9DC,
-      0xBD41FBD4, 0x76F988DA, 0x831153B5, 0x983E5152, 0xEE66DFAB,
-      0xA831C66D, 0x2DB43210, 0xB00327C8, 0x98FB213F, 0xBF597FC7,
-      0xBEEF0EE4, 0xC6E00BF3, 0x3DA88FC2, 0xD5A79147, 0x930AA725,
-      0x06CA6351, 0xE003826F, 0x14292967, 0x0A0E6E70, 0x27B70A85,
-      0x46D22FFC, 0x2E1B2138, 0x5C26C926, 0x4D2C6DFC, 0x5AC42AED,
-      0x53380D13, 0x9D95B3DF, 0x650A7354, 0x8BAF63DE, 0x766A0ABB,
-      0x3C77B2A8, 0x81C2C92E, 0x47EDAEE6, 0x92722C85, 0x1482353B,
-      0xA2BFE8A1, 0x4CF10364, 0xA81A664B, 0xBC423001, 0xC24B8B70,
-      0xD0F89791, 0xC76C51A3, 0x0654BE30, 0xD192E819, 0xD6EF5218,
-      0xD6990624, 0x5565A910, 0xF40E3585, 0x5771202A, 0x106AA070,
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 60]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      0x32BBD1B8, 0x19A4C116, 0xB8D2D0C8, 0x1E376C08, 0x5141AB53,
-      0x2748774C, 0xDF8EEB99, 0x34B0BCB5, 0xE19B48A8, 0x391C0CB3,
-      0xC5C95A63, 0x4ED8AA4A, 0xE3418ACB, 0x5B9CCA4F, 0x7763E373,
-      0x682E6FF3, 0xD6B2B8A3, 0x748F82EE, 0x5DEFB2FC, 0x78A5636F,
-      0x43172F60, 0x84C87814, 0xA1F0AB72, 0x8CC70208, 0x1A6439EC,
-      0x90BEFFFA, 0x23631E28, 0xA4506CEB, 0xDE82BDE9, 0xBEF9A3F7,
-      0xB2C67915, 0xC67178F2, 0xE372532B, 0xCA273ECE, 0xEA26619C,
-      0xD186B8C7, 0x21C0C207, 0xEADA7DD6, 0xCDE0EB1E, 0xF57D4F7F,
-      0xEE6ED178, 0x06F067AA, 0x72176FBA, 0x0A637DC5, 0xA2C898A6,
-      0x113F9804, 0xBEF90DAE, 0x1B710B35, 0x131C471B, 0x28DB77F5,
-      0x23047D84, 0x32CAAB7B, 0x40C72493, 0x3C9EBE0A, 0x15C9BEBC,
-      0x431D67C4, 0x9C100D4C, 0x4CC5D4BE, 0xCB3E42B6, 0x597F299C,
-      0xFC657E2A, 0x5FCB6FAB, 0x3AD6FAEC, 0x6C44198C, 0x4A475817
-  };
-  int     t, t2, t8;                  /* Loop counter */
-  uint32_t  temp1[2], temp2[2],       /* Temporary word values */
-        temp3[2], temp4[2], temp5[2];
-  uint32_t  W[2*80];                  /* Word sequence */
-  uint32_t  A[2], B[2], C[2], D[2],   /* Word buffers */
-        E[2], F[2], G[2], H[2];
-
-  /* Initialize the first 16 words in the array W */
-  for (t = t2 = t8 = 0; t < 16; t++, t8 += 8) {
-    W[t2++] = ((((uint32_t)context->Message_Block[t8    ])) << 24) |
-              ((((uint32_t)context->Message_Block[t8 + 1])) << 16) |
-              ((((uint32_t)context->Message_Block[t8 + 2])) << 8) |
-              ((((uint32_t)context->Message_Block[t8 + 3])));
-    W[t2++] = ((((uint32_t)context->Message_Block[t8 + 4])) << 24) |
-              ((((uint32_t)context->Message_Block[t8 + 5])) << 16) |
-              ((((uint32_t)context->Message_Block[t8 + 6])) << 8) |
-              ((((uint32_t)context->Message_Block[t8 + 7])));
-  }
-
-  for (t = 16; t < 80; t++, t2 += 2) {
-    /* W[t] = SHA512_sigma1(W[t-2]) + W[t-7] +
-      SHA512_sigma0(W[t-15]) + W[t-16]; */
-    uint32_t *Wt2 = &W[t2-2*2];
-    uint32_t *Wt7 = &W[t2-7*2];
-    uint32_t *Wt15 = &W[t2-15*2];
-    uint32_t *Wt16 = &W[t2-16*2];
-    SHA512_sigma1(Wt2, temp1);
-    SHA512_ADD(temp1, Wt7, temp2);
-    SHA512_sigma0(Wt15, temp1);
-    SHA512_ADD(temp1, Wt16, temp3);
-    SHA512_ADD(temp2, temp3, &W[t2]);
-  }
-
-  A[0] = context->Intermediate_Hash[0];
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 61]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  A[1] = context->Intermediate_Hash[1];
-  B[0] = context->Intermediate_Hash[2];
-  B[1] = context->Intermediate_Hash[3];
-  C[0] = context->Intermediate_Hash[4];
-  C[1] = context->Intermediate_Hash[5];
-  D[0] = context->Intermediate_Hash[6];
-  D[1] = context->Intermediate_Hash[7];
-  E[0] = context->Intermediate_Hash[8];
-  E[1] = context->Intermediate_Hash[9];
-  F[0] = context->Intermediate_Hash[10];
-  F[1] = context->Intermediate_Hash[11];
-  G[0] = context->Intermediate_Hash[12];
-  G[1] = context->Intermediate_Hash[13];
-  H[0] = context->Intermediate_Hash[14];
-  H[1] = context->Intermediate_Hash[15];
-
-  for (t = t2 = 0; t < 80; t++, t2 += 2) {
-    /*
-     * temp1 = H + SHA512_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
-     */
-    SHA512_SIGMA1(E,temp1);
-    SHA512_ADD(H, temp1, temp2);
-    SHA_Ch(E,F,G,temp3);
-    SHA512_ADD(temp2, temp3, temp4);
-    SHA512_ADD(&K[t2], &W[t2], temp5);
-    SHA512_ADD(temp4, temp5, temp1);
-    /*
-     * temp2 = SHA512_SIGMA0(A) + SHA_Maj(A,B,C);
-     */
-    SHA512_SIGMA0(A,temp3);
-    SHA_Maj(A,B,C,temp4);
-    SHA512_ADD(temp3, temp4, temp2);
-    H[0] = G[0]; H[1] = G[1];
-    G[0] = F[0]; G[1] = F[1];
-    F[0] = E[0]; F[1] = E[1];
-    SHA512_ADD(D, temp1, E);
-    D[0] = C[0]; D[1] = C[1];
-    C[0] = B[0]; C[1] = B[1];
-    B[0] = A[0]; B[1] = A[1];
-    SHA512_ADD(temp1, temp2, A);
-  }
-
-  SHA512_ADDTO2(&context->Intermediate_Hash[0], A);
-  SHA512_ADDTO2(&context->Intermediate_Hash[2], B);
-  SHA512_ADDTO2(&context->Intermediate_Hash[4], C);
-  SHA512_ADDTO2(&context->Intermediate_Hash[6], D);
-  SHA512_ADDTO2(&context->Intermediate_Hash[8], E);
-  SHA512_ADDTO2(&context->Intermediate_Hash[10], F);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 62]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  SHA512_ADDTO2(&context->Intermediate_Hash[12], G);
-  SHA512_ADDTO2(&context->Intermediate_Hash[14], H);
-
-#else /* !USE_32BIT_ONLY */
-  static const uint64_t K[80] = {
-      0x428A2F98D728AE22ll, 0x7137449123EF65CDll, 0xB5C0FBCFEC4D3B2Fll,
-      0xE9B5DBA58189DBBCll, 0x3956C25BF348B538ll, 0x59F111F1B605D019ll,
-      0x923F82A4AF194F9Bll, 0xAB1C5ED5DA6D8118ll, 0xD807AA98A3030242ll,
-      0x12835B0145706FBEll, 0x243185BE4EE4B28Cll, 0x550C7DC3D5FFB4E2ll,
-      0x72BE5D74F27B896Fll, 0x80DEB1FE3B1696B1ll, 0x9BDC06A725C71235ll,
-      0xC19BF174CF692694ll, 0xE49B69C19EF14AD2ll, 0xEFBE4786384F25E3ll,
-      0x0FC19DC68B8CD5B5ll, 0x240CA1CC77AC9C65ll, 0x2DE92C6F592B0275ll,
-      0x4A7484AA6EA6E483ll, 0x5CB0A9DCBD41FBD4ll, 0x76F988DA831153B5ll,
-      0x983E5152EE66DFABll, 0xA831C66D2DB43210ll, 0xB00327C898FB213Fll,
-      0xBF597FC7BEEF0EE4ll, 0xC6E00BF33DA88FC2ll, 0xD5A79147930AA725ll,
-      0x06CA6351E003826Fll, 0x142929670A0E6E70ll, 0x27B70A8546D22FFCll,
-      0x2E1B21385C26C926ll, 0x4D2C6DFC5AC42AEDll, 0x53380D139D95B3DFll,
-      0x650A73548BAF63DEll, 0x766A0ABB3C77B2A8ll, 0x81C2C92E47EDAEE6ll,
-      0x92722C851482353Bll, 0xA2BFE8A14CF10364ll, 0xA81A664BBC423001ll,
-      0xC24B8B70D0F89791ll, 0xC76C51A30654BE30ll, 0xD192E819D6EF5218ll,
-      0xD69906245565A910ll, 0xF40E35855771202All, 0x106AA07032BBD1B8ll,
-      0x19A4C116B8D2D0C8ll, 0x1E376C085141AB53ll, 0x2748774CDF8EEB99ll,
-      0x34B0BCB5E19B48A8ll, 0x391C0CB3C5C95A63ll, 0x4ED8AA4AE3418ACBll,
-      0x5B9CCA4F7763E373ll, 0x682E6FF3D6B2B8A3ll, 0x748F82EE5DEFB2FCll,
-      0x78A5636F43172F60ll, 0x84C87814A1F0AB72ll, 0x8CC702081A6439ECll,
-      0x90BEFFFA23631E28ll, 0xA4506CEBDE82BDE9ll, 0xBEF9A3F7B2C67915ll,
-      0xC67178F2E372532Bll, 0xCA273ECEEA26619Cll, 0xD186B8C721C0C207ll,
-      0xEADA7DD6CDE0EB1Ell, 0xF57D4F7FEE6ED178ll, 0x06F067AA72176FBAll,
-      0x0A637DC5A2C898A6ll, 0x113F9804BEF90DAEll, 0x1B710B35131C471Bll,
-      0x28DB77F523047D84ll, 0x32CAAB7B40C72493ll, 0x3C9EBE0A15C9BEBCll,
-      0x431D67C49C100D4Cll, 0x4CC5D4BECB3E42B6ll, 0x597F299CFC657E2All,
-      0x5FCB6FAB3AD6FAECll, 0x6C44198C4A475817ll
-  };
-  int        t, t8;                   /* Loop counter */
-  uint64_t   temp1, temp2;            /* Temporary word value */
-  uint64_t   W[80];                   /* Word sequence */
-  uint64_t   A, B, C, D, E, F, G, H;  /* Word buffers */
-
-  /*
-   * Initialize the first 16 words in the array W
-   */
-  for (t = t8 = 0; t < 16; t++, t8 += 8)
-    W[t] = ((uint64_t)(context->Message_Block[t8  ]) << 56) |
-           ((uint64_t)(context->Message_Block[t8 + 1]) << 48) |
-           ((uint64_t)(context->Message_Block[t8 + 2]) << 40) |
-           ((uint64_t)(context->Message_Block[t8 + 3]) << 32) |
-           ((uint64_t)(context->Message_Block[t8 + 4]) << 24) |
-           ((uint64_t)(context->Message_Block[t8 + 5]) << 16) |
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 63]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-           ((uint64_t)(context->Message_Block[t8 + 6]) << 8) |
-           ((uint64_t)(context->Message_Block[t8 + 7]));
-
-  for (t = 16; t < 80; t++)
-    W[t] = SHA512_sigma1(W[t-2]) + W[t-7] +
-        SHA512_sigma0(W[t-15]) + W[t-16];
-
-  A = context->Intermediate_Hash[0];
-  B = context->Intermediate_Hash[1];
-  C = context->Intermediate_Hash[2];
-  D = context->Intermediate_Hash[3];
-  E = context->Intermediate_Hash[4];
-  F = context->Intermediate_Hash[5];
-  G = context->Intermediate_Hash[6];
-  H = context->Intermediate_Hash[7];
-
-  for (t = 0; t < 80; t++) {
-    temp1 = H + SHA512_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
-    temp2 = SHA512_SIGMA0(A) + SHA_Maj(A,B,C);
-    H = G;
-    G = F;
-    F = E;
-    E = D + temp1;
-    D = C;
-    C = B;
-    B = A;
-    A = temp1 + temp2;
-  }
-
-  context->Intermediate_Hash[0] += A;
-  context->Intermediate_Hash[1] += B;
-  context->Intermediate_Hash[2] += C;
-  context->Intermediate_Hash[3] += D;
-  context->Intermediate_Hash[4] += E;
-  context->Intermediate_Hash[5] += F;
-  context->Intermediate_Hash[6] += G;
-  context->Intermediate_Hash[7] += H;
-#endif /* USE_32BIT_ONLY */
-
-  context->Message_Block_Index = 0;
-}
-
-/*
- * SHA384_512Reset
- *
- * Description:
- *   This helper function will initialize the SHA512Context in
- *   preparation for computing a new SHA384 or SHA512 message
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 64]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *   H0
- *     The initial hash value to use.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-#ifdef USE_32BIT_ONLY
-static int SHA384_512Reset(SHA512Context *context, uint32_t H0[])
-#else /* !USE_32BIT_ONLY */
-static int SHA384_512Reset(SHA512Context *context, uint64_t H0[])
-#endif /* USE_32BIT_ONLY */
-{
-  int i;
-  if (!context)
-    return shaNull;
-
-  context->Message_Block_Index = 0;
-
-#ifdef USE_32BIT_ONLY
-  context->Length[0] = context->Length[1] = 0;
-  context->Length[2] = context->Length[3] = 0;
-
-  for (i = 0; i < SHA512HashSize/4; i++)
-    context->Intermediate_Hash[i] = H0[i];
-#else /* !USE_32BIT_ONLY */
-  context->Length_High = context->Length_Low = 0;
-
-  for (i = 0; i < SHA512HashSize/8; i++)
-    context->Intermediate_Hash[i] = H0[i];
-#endif /* USE_32BIT_ONLY */
-
-  context->Computed = 0;
-  context->Corrupted = 0;
-
-  return shaSuccess;
-}
-
-/*
- * SHA384_512ResultN
- *
- * Description:
- *   This helper function will return the 384-bit or 512-bit message
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 65]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 48th/64th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *   HashSize: [in]
- *     The size of the hash, either 48 or 64.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-static int SHA384_512ResultN(SHA512Context *context,
-    uint8_t Message_Digest[], int HashSize)
-{
-  int i;
-
-#ifdef USE_32BIT_ONLY
-  int i2;
-#endif /* USE_32BIT_ONLY */
-
-  if (!context || !Message_Digest)
-    return shaNull;
-
-  if (context->Corrupted)
-    return context->Corrupted;
-
-  if (!context->Computed)
-    SHA384_512Finalize(context, 0x80);
-
-#ifdef USE_32BIT_ONLY
-  for (i = i2 = 0; i < HashSize; ) {
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>24);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>16);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>8);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2++]);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>24);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>16);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>8);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2++]);
-  }
-#else /* !USE_32BIT_ONLY */
-  for (i = 0; i < HashSize; ++i)
-    Message_Digest[i] = (uint8_t)
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 66]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      (context->Intermediate_Hash[i>>3] >> 8 * ( 7 - ( i % 8 ) ));
-#endif /* USE_32BIT_ONLY */
-
-  return shaSuccess;
-}
-
-8.2.4.  usha.c
-
-/**************************** usha.c ****************************/
-/******************** See RFC 4634 for details ******************/
-/*
- *  Description:
- *     This file implements a unified interface to the SHA algorithms.
- */
-
-#include "sha.h"
-
-/*
- *  USHAReset
- *
- *  Description:
- *      This function will initialize the SHA Context in preparation
- *      for computing a new SHA message digest.
- *
- *  Parameters:
- *      context: [in/out]
- *          The context to reset.
- *      whichSha: [in]
- *          Selects which SHA reset to call
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int USHAReset(USHAContext *ctx, enum SHAversion whichSha)
-{
-  if (ctx) {
-    ctx->whichSha = whichSha;
-    switch (whichSha) {
-      case SHA1:   return SHA1Reset((SHA1Context*)&ctx->ctx);
-      case SHA224: return SHA224Reset((SHA224Context*)&ctx->ctx);
-      case SHA256: return SHA256Reset((SHA256Context*)&ctx->ctx);
-      case SHA384: return SHA384Reset((SHA384Context*)&ctx->ctx);
-      case SHA512: return SHA512Reset((SHA512Context*)&ctx->ctx);
-      default: return shaBadParam;
-    }
-  } else {
-    return shaNull;
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 67]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  }
-}
-
-/*
- *  USHAInput
- *
- *  Description:
- *      This function accepts an array of octets as the next portion
- *      of the message.
- *
- *  Parameters:
- *      context: [in/out]
- *          The SHA context to update
- *      message_array: [in]
- *          An array of characters representing the next portion of
- *          the message.
- *      length: [in]
- *          The length of the message in message_array
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int USHAInput(USHAContext *ctx,
-              const uint8_t *bytes, unsigned int bytecount)
-{
-  if (ctx) {
-    switch (ctx->whichSha) {
-      case SHA1:
-        return SHA1Input((SHA1Context*)&ctx->ctx, bytes, bytecount);
-      case SHA224:
-        return SHA224Input((SHA224Context*)&ctx->ctx, bytes,
-            bytecount);
-      case SHA256:
-        return SHA256Input((SHA256Context*)&ctx->ctx, bytes,
-            bytecount);
-      case SHA384:
-        return SHA384Input((SHA384Context*)&ctx->ctx, bytes,
-            bytecount);
-      case SHA512:
-        return SHA512Input((SHA512Context*)&ctx->ctx, bytes,
-            bytecount);
-      default: return shaBadParam;
-    }
-  } else {
-    return shaNull;
-  }
-}
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 68]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- * USHAFinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int USHAFinalBits(USHAContext *ctx,
-                  const uint8_t bits, unsigned int bitcount)
-{
-  if (ctx) {
-    switch (ctx->whichSha) {
-      case SHA1:
-        return SHA1FinalBits((SHA1Context*)&ctx->ctx, bits, bitcount);
-      case SHA224:
-        return SHA224FinalBits((SHA224Context*)&ctx->ctx, bits,
-            bitcount);
-      case SHA256:
-        return SHA256FinalBits((SHA256Context*)&ctx->ctx, bits,
-            bitcount);
-      case SHA384:
-        return SHA384FinalBits((SHA384Context*)&ctx->ctx, bits,
-            bitcount);
-      case SHA512:
-        return SHA512FinalBits((SHA512Context*)&ctx->ctx, bits,
-            bitcount);
-      default: return shaBadParam;
-    }
-  } else {
-    return shaNull;
-  }
-}
-
-/*
- * USHAResult
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 69]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Description:
- *   This function will return the 160-bit message digest into the
- *   Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 19th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA-1 hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int USHAResult(USHAContext *ctx,
-               uint8_t Message_Digest[USHAMaxHashSize])
-{
-  if (ctx) {
-    switch (ctx->whichSha) {
-      case SHA1:
-        return SHA1Result((SHA1Context*)&ctx->ctx, Message_Digest);
-      case SHA224:
-        return SHA224Result((SHA224Context*)&ctx->ctx, Message_Digest);
-      case SHA256:
-        return SHA256Result((SHA256Context*)&ctx->ctx, Message_Digest);
-      case SHA384:
-        return SHA384Result((SHA384Context*)&ctx->ctx, Message_Digest);
-      case SHA512:
-        return SHA512Result((SHA512Context*)&ctx->ctx, Message_Digest);
-      default: return shaBadParam;
-    }
-  } else {
-    return shaNull;
-  }
-}
-
-/*
- * USHABlockSize
- *
- * Description:
- *   This function will return the blocksize for the given SHA
- *   algorithm.
- *
- * Parameters:
- *   whichSha:
- *     which SHA algorithm to query
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 70]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- * Returns:
- *   block size
- *
- */
-int USHABlockSize(enum SHAversion whichSha)
-{
-  switch (whichSha) {
-    case SHA1:   return SHA1_Message_Block_Size;
-    case SHA224: return SHA224_Message_Block_Size;
-    case SHA256: return SHA256_Message_Block_Size;
-    case SHA384: return SHA384_Message_Block_Size;
-    default:
-    case SHA512: return SHA512_Message_Block_Size;
-  }
-}
-
-/*
- * USHAHashSize
- *
- * Description:
- *   This function will return the hashsize for the given SHA
- *   algorithm.
- *
- * Parameters:
- *   whichSha:
- *     which SHA algorithm to query
- *
- * Returns:
- *   hash size
- *
- */
-int USHAHashSize(enum SHAversion whichSha)
-{
-  switch (whichSha) {
-    case SHA1:   return SHA1HashSize;
-    case SHA224: return SHA224HashSize;
-    case SHA256: return SHA256HashSize;
-    case SHA384: return SHA384HashSize;
-    default:
-    case SHA512: return SHA512HashSize;
-  }
-}
-
-/*
- * USHAHashSizeBits
- *
- * Description:
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 71]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   This function will return the hashsize for the given SHA
- *   algorithm, expressed in bits.
- *
- * Parameters:
- *   whichSha:
- *     which SHA algorithm to query
- *
- * Returns:
- *   hash size in bits
- *
- */
-int USHAHashSizeBits(enum SHAversion whichSha)
-{
-  switch (whichSha) {
-    case SHA1:   return SHA1HashSizeBits;
-    case SHA224: return SHA224HashSizeBits;
-    case SHA256: return SHA256HashSizeBits;
-    case SHA384: return SHA384HashSizeBits;
-    default:
-    case SHA512: return SHA512HashSizeBits;
-  }
-}
-
-8.2.5.  sha-private.h
-
-/*************************** sha-private.h ***************************/
-/********************** See RFC 4634 for details *********************/
-#ifndef _SHA_PRIVATE__H
-#define _SHA_PRIVATE__H
-/*
- * These definitions are defined in FIPS-180-2, section 4.1.
- * Ch() and Maj() are defined identically in sections 4.1.1,
- * 4.1.2 and 4.1.3.
- *
- * The definitions used in FIPS-180-2 are as follows:
- */
-
-#ifndef USE_MODIFIED_MACROS
-#define SHA_Ch(x,y,z)        (((x) & (y)) ^ ((~(x)) & (z)))
-#define SHA_Maj(x,y,z)       (((x) & (y)) ^ ((x) & (z)) ^ ((y) & (z)))
-
-#else /* USE_MODIFIED_MACROS */
-/*
- * The following definitions are equivalent and potentially faster.
- */
-
-#define SHA_Ch(x, y, z)      (((x) & ((y) ^ (z))) ^ (z))
-#define SHA_Maj(x, y, z)     (((x) & ((y) | (z))) | ((y) & (z)))
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 72]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-#endif /* USE_MODIFIED_MACROS */
-
-#define SHA_Parity(x, y, z)  ((x) ^ (y) ^ (z))
-
-#endif /* _SHA_PRIVATE__H */
-
-8.3 The HMAC Code
-
-/**************************** hmac.c ****************************/
-/******************** See RFC 4634 for details ******************/
-/*
- *  Description:
- *      This file implements the HMAC algorithm (Keyed-Hashing for
- *      Message Authentication, RFC2104), expressed in terms of the
- *      various SHA algorithms.
- */
-
-#include "sha.h"
-
-/*
- *  hmac
- *
- *  Description:
- *      This function will compute an HMAC message digest.
- *
- *  Parameters:
- *      whichSha: [in]
- *          One of SHA1, SHA224, SHA256, SHA384, SHA512
- *      key: [in]
- *          The secret shared key.
- *      key_len: [in]
- *          The length of the secret shared key.
- *      message_array: [in]
- *          An array of characters representing the message.
- *      length: [in]
- *          The length of the message in message_array
- *      digest: [out]
- *          Where the digest is returned.
- *          NOTE: The length of the digest is determined by
- *              the value of whichSha.
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int hmac(SHAversion whichSha, const unsigned char *text, int text_len,
-    const unsigned char *key, int key_len,
-    uint8_t digest[USHAMaxHashSize])
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 73]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-{
-  HMACContext ctx;
-  return hmacReset(&ctx, whichSha, key, key_len) ||
-         hmacInput(&ctx, text, text_len) ||
-         hmacResult(&ctx, digest);
-}
-
-/*
- *  hmacReset
- *
- *  Description:
- *      This function will initialize the hmacContext in preparation
- *      for computing a new HMAC message digest.
- *
- *  Parameters:
- *      context: [in/out]
- *          The context to reset.
- *      whichSha: [in]
- *          One of SHA1, SHA224, SHA256, SHA384, SHA512
- *      key: [in]
- *          The secret shared key.
- *      key_len: [in]
- *          The length of the secret shared key.
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
-    const unsigned char *key, int key_len)
-{
-  int i, blocksize, hashsize;
-
-  /* inner padding - key XORd with ipad */
-  unsigned char k_ipad[USHA_Max_Message_Block_Size];
-
-  /* temporary buffer when keylen > blocksize */
-  unsigned char tempkey[USHAMaxHashSize];
-
-  if (!ctx) return shaNull;
-
-  blocksize = ctx->blockSize = USHABlockSize(whichSha);
-  hashsize = ctx->hashSize = USHAHashSize(whichSha);
-
-  ctx->whichSha = whichSha;
-
-  /*
-   * If key is longer than the hash blocksize,
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 74]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-   * reset it to key = HASH(key).
-   */
-  if (key_len > blocksize) {
-    USHAContext tctx;
-    int err = USHAReset(&tctx, whichSha) ||
-              USHAInput(&tctx, key, key_len) ||
-              USHAResult(&tctx, tempkey);
-    if (err != shaSuccess) return err;
-
-    key = tempkey;
-    key_len = hashsize;
-  }
-
-  /*
-   * The HMAC transform looks like:
-   *
-   * SHA(K XOR opad, SHA(K XOR ipad, text))
-   *
-   * where K is an n byte key.
-   * ipad is the byte 0x36 repeated blocksize times
-   * opad is the byte 0x5c repeated blocksize times
-   * and text is the data being protected.
-   */
-
-  /* store key into the pads, XOR'd with ipad and opad values */
-  for (i = 0; i < key_len; i++) {
-    k_ipad[i] = key[i] ^ 0x36;
-    ctx->k_opad[i] = key[i] ^ 0x5c;
-  }
-  /* remaining pad bytes are '\0' XOR'd with ipad and opad values */
-  for ( ; i < blocksize; i++) {
-    k_ipad[i] = 0x36;
-    ctx->k_opad[i] = 0x5c;
-  }
-
-  /* perform inner hash */
-  /* init context for 1st pass */
-  return USHAReset(&ctx->shaContext, whichSha) ||
-         /* and start with inner pad */
-         USHAInput(&ctx->shaContext, k_ipad, blocksize);
-}
-
-/*
- *  hmacInput
- *
- *  Description:
- *      This function accepts an array of octets as the next portion
- *      of the message.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 75]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- *  Parameters:
- *      context: [in/out]
- *          The HMAC context to update
- *      message_array: [in]
- *          An array of characters representing the next portion of
- *          the message.
- *      length: [in]
- *          The length of the message in message_array
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int hmacInput(HMACContext *ctx, const unsigned char *text,
-    int text_len)
-{
-  if (!ctx) return shaNull;
-  /* then text of datagram */
-  return USHAInput(&ctx->shaContext, text, text_len);
-}
-
-/*
- * HMACFinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The HMAC context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int hmacFinalBits(HMACContext *ctx,
-    const uint8_t bits,
-    unsigned int bitcount)
-{
-  if (!ctx) return shaNull;
-  /* then final bits of datagram */
-  return USHAFinalBits(&ctx->shaContext, bits, bitcount);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 76]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-}
-
-/*
- * HMACResult
- *
- * Description:
- *   This function will return the N-byte message digest into the
- *   Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the Nth element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the HMAC hash.
- *   digest: [out]
- *     Where the digest is returned.
- *   NOTE 2: The length of the hash is determined by the value of
- *      whichSha that was passed to hmacReset().
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int hmacResult(HMACContext *ctx, uint8_t *digest)
-{
-  if (!ctx) return shaNull;
-
-  /* finish up 1st pass */
-  /* (Use digest here as a temporary buffer.) */
-  return USHAResult(&ctx->shaContext, digest) ||
-
-         /* perform outer SHA */
-         /* init context for 2nd pass */
-         USHAReset(&ctx->shaContext, ctx->whichSha) ||
-
-         /* start with outer pad */
-         USHAInput(&ctx->shaContext, ctx->k_opad, ctx->blockSize) ||
-
-         /* then results of 1st hash */
-         USHAInput(&ctx->shaContext, digest, ctx->hashSize) ||
-
-         /* finish up 2nd pass */
-         USHAResult(&ctx->shaContext, digest);
-}
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 77]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-8.4.  The Test Driver
-
-   The following code is a main program test driver to exercise the code
-   in sha1.c, sha224-256.c, and sha384-512.c.  The test driver can also
-   be used as a stand-alone program for generating the hashes.
-
-   See also [RFC2202], [RFC4231], and [SHAVS].
-
-/**************************** shatest.c ****************************/
-/********************* See RFC 4634 for details ********************/
-/*
- *  Description:
- *    This file will exercise the SHA code performing
- *      the three tests documented in FIPS PUB 180-2
- *        (http://csrc.nist.gov/publications/fips/
- *         fips180-2/fips180-2withchangenotice.pdf)
- *      one that calls SHAInput with an exact multiple of 512 bits
- *      the seven tests documented for each algorithm in
- *        "The Secure Hash Algorithm Validation System (SHAVS)",
- *        three of which are bit-level tests
- *        (http://csrc.nist.gov/cryptval/shs/SHAVS.pdf)
- *
- *    This file will exercise the HMAC SHA1 code performing
- *      the seven tests documented in RFCs 2202 and 4231.
- *
- *    To run the tests and just see PASSED/FAILED, use the -p option.
- *
- *    Other options exercise:
- *      hashing an arbitrary string
- *      hashing a file's contents
- *      a few error test checks
- *      printing the results in raw format
- *
- *  Portability Issues:
- *    None.
- *
- */
-
-#include <stdint.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <ctype.h>
-#include "sha.h"
-
-static int xgetopt(int argc, char **argv, const char *optstring);
-extern char *xoptarg;
-static int scasecmp(const char *s1, const char *s2);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 78]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- *  Define patterns for testing
- */
-#define TEST1    "abc"
-#define TEST2_1  \
-        "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq"
-#define TEST2_2a \
-        "abcdefghbcdefghicdefghijdefghijkefghijklfghijklmghijklmn"
-#define TEST2_2b \
-        "hijklmnoijklmnopjklmnopqklmnopqrlmnopqrsmnopqrstnopqrstu"
-#define TEST2_2  TEST2_2a TEST2_2b
-#define TEST3    "a"                            /* times 1000000 */
-#define TEST4a   "01234567012345670123456701234567"
-#define TEST4b   "01234567012345670123456701234567"
-    /* an exact multiple of 512 bits */
-#define TEST4   TEST4a TEST4b                   /* times 10 */
-
-#define TEST7_1 \
-  "\x49\xb2\xae\xc2\x59\x4b\xbe\x3a\x3b\x11\x75\x42\xd9\x4a\xc8"
-#define TEST8_1 \
-  "\x9a\x7d\xfd\xf1\xec\xea\xd0\x6e\xd6\x46\xaa\x55\xfe\x75\x71\x46"
-#define TEST9_1 \
-  "\x65\xf9\x32\x99\x5b\xa4\xce\x2c\xb1\xb4\xa2\xe7\x1a\xe7\x02\x20" \
-  "\xaa\xce\xc8\x96\x2d\xd4\x49\x9c\xbd\x7c\x88\x7a\x94\xea\xaa\x10" \
-  "\x1e\xa5\xaa\xbc\x52\x9b\x4e\x7e\x43\x66\x5a\x5a\xf2\xcd\x03\xfe" \
-  "\x67\x8e\xa6\xa5\x00\x5b\xba\x3b\x08\x22\x04\xc2\x8b\x91\x09\xf4" \
-  "\x69\xda\xc9\x2a\xaa\xb3\xaa\x7c\x11\xa1\xb3\x2a"
-#define TEST10_1 \
-  "\xf7\x8f\x92\x14\x1b\xcd\x17\x0a\xe8\x9b\x4f\xba\x15\xa1\xd5\x9f" \
-  "\x3f\xd8\x4d\x22\x3c\x92\x51\xbd\xac\xbb\xae\x61\xd0\x5e\xd1\x15" \
-  "\xa0\x6a\x7c\xe1\x17\xb7\xbe\xea\xd2\x44\x21\xde\xd9\xc3\x25\x92" \
-  "\xbd\x57\xed\xea\xe3\x9c\x39\xfa\x1f\xe8\x94\x6a\x84\xd0\xcf\x1f" \
-  "\x7b\xee\xad\x17\x13\xe2\xe0\x95\x98\x97\x34\x7f\x67\xc8\x0b\x04" \
-  "\x00\xc2\x09\x81\x5d\x6b\x10\xa6\x83\x83\x6f\xd5\x56\x2a\x56\xca" \
-  "\xb1\xa2\x8e\x81\xb6\x57\x66\x54\x63\x1c\xf1\x65\x66\xb8\x6e\x3b" \
-  "\x33\xa1\x08\xb0\x53\x07\xc0\x0a\xff\x14\xa7\x68\xed\x73\x50\x60" \
-  "\x6a\x0f\x85\xe6\xa9\x1d\x39\x6f\x5b\x5c\xbe\x57\x7f\x9b\x38\x80" \
-  "\x7c\x7d\x52\x3d\x6d\x79\x2f\x6e\xbc\x24\xa4\xec\xf2\xb3\xa4\x27" \
-  "\xcd\xbb\xfb"
-#define TEST7_224 \
-  "\xf0\x70\x06\xf2\x5a\x0b\xea\x68\xcd\x76\xa2\x95\x87\xc2\x8d"
-#define TEST8_224 \
-  "\x18\x80\x40\x05\xdd\x4f\xbd\x15\x56\x29\x9d\x6f\x9d\x93\xdf\x62"
-#define TEST9_224 \
-  "\xa2\xbe\x6e\x46\x32\x81\x09\x02\x94\xd9\xce\x94\x82\x65\x69\x42" \
-  "\x3a\x3a\x30\x5e\xd5\xe2\x11\x6c\xd4\xa4\xc9\x87\xfc\x06\x57\x00" \
-  "\x64\x91\xb1\x49\xcc\xd4\xb5\x11\x30\xac\x62\xb1\x9d\xc2\x48\xc7" \
-  "\x44\x54\x3d\x20\xcd\x39\x52\xdc\xed\x1f\x06\xcc\x3b\x18\xb9\x1f" \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 79]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  "\x3f\x55\x63\x3e\xcc\x30\x85\xf4\x90\x70\x60\xd2"
-#define TEST10_224 \
-  "\x55\xb2\x10\x07\x9c\x61\xb5\x3a\xdd\x52\x06\x22\xd1\xac\x97\xd5" \
-  "\xcd\xbe\x8c\xb3\x3a\xa0\xae\x34\x45\x17\xbe\xe4\xd7\xba\x09\xab" \
-  "\xc8\x53\x3c\x52\x50\x88\x7a\x43\xbe\xbb\xac\x90\x6c\x2e\x18\x37" \
-  "\xf2\x6b\x36\xa5\x9a\xe3\xbe\x78\x14\xd5\x06\x89\x6b\x71\x8b\x2a" \
-  "\x38\x3e\xcd\xac\x16\xb9\x61\x25\x55\x3f\x41\x6f\xf3\x2c\x66\x74" \
-  "\xc7\x45\x99\xa9\x00\x53\x86\xd9\xce\x11\x12\x24\x5f\x48\xee\x47" \
-  "\x0d\x39\x6c\x1e\xd6\x3b\x92\x67\x0c\xa5\x6e\xc8\x4d\xee\xa8\x14" \
-  "\xb6\x13\x5e\xca\x54\x39\x2b\xde\xdb\x94\x89\xbc\x9b\x87\x5a\x8b" \
-  "\xaf\x0d\xc1\xae\x78\x57\x36\x91\x4a\xb7\xda\xa2\x64\xbc\x07\x9d" \
-  "\x26\x9f\x2c\x0d\x7e\xdd\xd8\x10\xa4\x26\x14\x5a\x07\x76\xf6\x7c" \
-  "\x87\x82\x73"
-#define TEST7_256 \
-  "\xbe\x27\x46\xc6\xdb\x52\x76\x5f\xdb\x2f\x88\x70\x0f\x9a\x73"
-#define TEST8_256 \
-  "\xe3\xd7\x25\x70\xdc\xdd\x78\x7c\xe3\x88\x7a\xb2\xcd\x68\x46\x52"
-#define TEST9_256 \
-  "\x3e\x74\x03\x71\xc8\x10\xc2\xb9\x9f\xc0\x4e\x80\x49\x07\xef\x7c" \
-  "\xf2\x6b\xe2\x8b\x57\xcb\x58\xa3\xe2\xf3\xc0\x07\x16\x6e\x49\xc1" \
-  "\x2e\x9b\xa3\x4c\x01\x04\x06\x91\x29\xea\x76\x15\x64\x25\x45\x70" \
-  "\x3a\x2b\xd9\x01\xe1\x6e\xb0\xe0\x5d\xeb\xa0\x14\xeb\xff\x64\x06" \
-  "\xa0\x7d\x54\x36\x4e\xff\x74\x2d\xa7\x79\xb0\xb3"
-#define TEST10_256 \
-  "\x83\x26\x75\x4e\x22\x77\x37\x2f\x4f\xc1\x2b\x20\x52\x7a\xfe\xf0" \
-  "\x4d\x8a\x05\x69\x71\xb1\x1a\xd5\x71\x23\xa7\xc1\x37\x76\x00\x00" \
-  "\xd7\xbe\xf6\xf3\xc1\xf7\xa9\x08\x3a\xa3\x9d\x81\x0d\xb3\x10\x77" \
-  "\x7d\xab\x8b\x1e\x7f\x02\xb8\x4a\x26\xc7\x73\x32\x5f\x8b\x23\x74" \
-  "\xde\x7a\x4b\x5a\x58\xcb\x5c\x5c\xf3\x5b\xce\xe6\xfb\x94\x6e\x5b" \
-  "\xd6\x94\xfa\x59\x3a\x8b\xeb\x3f\x9d\x65\x92\xec\xed\xaa\x66\xca" \
-  "\x82\xa2\x9d\x0c\x51\xbc\xf9\x33\x62\x30\xe5\xd7\x84\xe4\xc0\xa4" \
-  "\x3f\x8d\x79\xa3\x0a\x16\x5c\xba\xbe\x45\x2b\x77\x4b\x9c\x71\x09" \
-  "\xa9\x7d\x13\x8f\x12\x92\x28\x96\x6f\x6c\x0a\xdc\x10\x6a\xad\x5a" \
-  "\x9f\xdd\x30\x82\x57\x69\xb2\xc6\x71\xaf\x67\x59\xdf\x28\xeb\x39" \
-  "\x3d\x54\xd6"
-#define TEST7_384 \
-  "\x8b\xc5\x00\xc7\x7c\xee\xd9\x87\x9d\xa9\x89\x10\x7c\xe0\xaa"
-#define TEST8_384 \
-  "\xa4\x1c\x49\x77\x79\xc0\x37\x5f\xf1\x0a\x7f\x4e\x08\x59\x17\x39"
-#define TEST9_384 \
-  "\x68\xf5\x01\x79\x2d\xea\x97\x96\x76\x70\x22\xd9\x3d\xa7\x16\x79" \
-  "\x30\x99\x20\xfa\x10\x12\xae\xa3\x57\xb2\xb1\x33\x1d\x40\xa1\xd0" \
-  "\x3c\x41\xc2\x40\xb3\xc9\xa7\x5b\x48\x92\xf4\xc0\x72\x4b\x68\xc8" \
-  "\x75\x32\x1a\xb8\xcf\xe5\x02\x3b\xd3\x75\xbc\x0f\x94\xbd\x89\xfe" \
-  "\x04\xf2\x97\x10\x5d\x7b\x82\xff\xc0\x02\x1a\xeb\x1c\xcb\x67\x4f" \
-  "\x52\x44\xea\x34\x97\xde\x26\xa4\x19\x1c\x5f\x62\xe5\xe9\xa2\xd8" \
-  "\x08\x2f\x05\x51\xf4\xa5\x30\x68\x26\xe9\x1c\xc0\x06\xce\x1b\xf6" \
-  "\x0f\xf7\x19\xd4\x2f\xa5\x21\xc8\x71\xcd\x23\x94\xd9\x6e\xf4\x46" \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 80]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  "\x8f\x21\x96\x6b\x41\xf2\xba\x80\xc2\x6e\x83\xa9"
-#define TEST10_384 \
-  "\x39\x96\x69\xe2\x8f\x6b\x9c\x6d\xbc\xbb\x69\x12\xec\x10\xff\xcf" \
-  "\x74\x79\x03\x49\xb7\xdc\x8f\xbe\x4a\x8e\x7b\x3b\x56\x21\xdb\x0f" \
-  "\x3e\x7d\xc8\x7f\x82\x32\x64\xbb\xe4\x0d\x18\x11\xc9\xea\x20\x61" \
-  "\xe1\xc8\x4a\xd1\x0a\x23\xfa\xc1\x72\x7e\x72\x02\xfc\x3f\x50\x42" \
-  "\xe6\xbf\x58\xcb\xa8\xa2\x74\x6e\x1f\x64\xf9\xb9\xea\x35\x2c\x71" \
-  "\x15\x07\x05\x3c\xf4\xe5\x33\x9d\x52\x86\x5f\x25\xcc\x22\xb5\xe8" \
-  "\x77\x84\xa1\x2f\xc9\x61\xd6\x6c\xb6\xe8\x95\x73\x19\x9a\x2c\xe6" \
-  "\x56\x5c\xbd\xf1\x3d\xca\x40\x38\x32\xcf\xcb\x0e\x8b\x72\x11\xe8" \
-  "\x3a\xf3\x2a\x11\xac\x17\x92\x9f\xf1\xc0\x73\xa5\x1c\xc0\x27\xaa" \
-  "\xed\xef\xf8\x5a\xad\x7c\x2b\x7c\x5a\x80\x3e\x24\x04\xd9\x6d\x2a" \
-  "\x77\x35\x7b\xda\x1a\x6d\xae\xed\x17\x15\x1c\xb9\xbc\x51\x25\xa4" \
-  "\x22\xe9\x41\xde\x0c\xa0\xfc\x50\x11\xc2\x3e\xcf\xfe\xfd\xd0\x96" \
-  "\x76\x71\x1c\xf3\xdb\x0a\x34\x40\x72\x0e\x16\x15\xc1\xf2\x2f\xbc" \
-  "\x3c\x72\x1d\xe5\x21\xe1\xb9\x9b\xa1\xbd\x55\x77\x40\x86\x42\x14" \
-  "\x7e\xd0\x96"
-#define TEST7_512 \
-  "\x08\xec\xb5\x2e\xba\xe1\xf7\x42\x2d\xb6\x2b\xcd\x54\x26\x70"
-#define TEST8_512 \
-  "\x8d\x4e\x3c\x0e\x38\x89\x19\x14\x91\x81\x6e\x9d\x98\xbf\xf0\xa0"
-#define TEST9_512 \
-  "\x3a\xdd\xec\x85\x59\x32\x16\xd1\x61\x9a\xa0\x2d\x97\x56\x97\x0b" \
-  "\xfc\x70\xac\xe2\x74\x4f\x7c\x6b\x27\x88\x15\x10\x28\xf7\xb6\xa2" \
-  "\x55\x0f\xd7\x4a\x7e\x6e\x69\xc2\xc9\xb4\x5f\xc4\x54\x96\x6d\xc3" \
-  "\x1d\x2e\x10\xda\x1f\x95\xce\x02\xbe\xb4\xbf\x87\x65\x57\x4c\xbd" \
-  "\x6e\x83\x37\xef\x42\x0a\xdc\x98\xc1\x5c\xb6\xd5\xe4\xa0\x24\x1b" \
-  "\xa0\x04\x6d\x25\x0e\x51\x02\x31\xca\xc2\x04\x6c\x99\x16\x06\xab" \
-  "\x4e\xe4\x14\x5b\xee\x2f\xf4\xbb\x12\x3a\xab\x49\x8d\x9d\x44\x79" \
-  "\x4f\x99\xcc\xad\x89\xa9\xa1\x62\x12\x59\xed\xa7\x0a\x5b\x6d\xd4" \
-  "\xbd\xd8\x77\x78\xc9\x04\x3b\x93\x84\xf5\x49\x06"
-#define TEST10_512 \
-  "\xa5\x5f\x20\xc4\x11\xaa\xd1\x32\x80\x7a\x50\x2d\x65\x82\x4e\x31" \
-  "\xa2\x30\x54\x32\xaa\x3d\x06\xd3\xe2\x82\xa8\xd8\x4e\x0d\xe1\xde" \
-  "\x69\x74\xbf\x49\x54\x69\xfc\x7f\x33\x8f\x80\x54\xd5\x8c\x26\xc4" \
-  "\x93\x60\xc3\xe8\x7a\xf5\x65\x23\xac\xf6\xd8\x9d\x03\xe5\x6f\xf2" \
-  "\xf8\x68\x00\x2b\xc3\xe4\x31\xed\xc4\x4d\xf2\xf0\x22\x3d\x4b\xb3" \
-  "\xb2\x43\x58\x6e\x1a\x7d\x92\x49\x36\x69\x4f\xcb\xba\xf8\x8d\x95" \
-  "\x19\xe4\xeb\x50\xa6\x44\xf8\xe4\xf9\x5e\xb0\xea\x95\xbc\x44\x65" \
-  "\xc8\x82\x1a\xac\xd2\xfe\x15\xab\x49\x81\x16\x4b\xbb\x6d\xc3\x2f" \
-  "\x96\x90\x87\xa1\x45\xb0\xd9\xcc\x9c\x67\xc2\x2b\x76\x32\x99\x41" \
-  "\x9c\xc4\x12\x8b\xe9\xa0\x77\xb3\xac\xe6\x34\x06\x4e\x6d\x99\x28" \
-  "\x35\x13\xdc\x06\xe7\x51\x5d\x0d\x73\x13\x2e\x9a\x0d\xc6\xd3\xb1" \
-  "\xf8\xb2\x46\xf1\xa9\x8a\x3f\xc7\x29\x41\xb1\xe3\xbb\x20\x98\xe8" \
-  "\xbf\x16\xf2\x68\xd6\x4f\x0b\x0f\x47\x07\xfe\x1e\xa1\xa1\x79\x1b" \
-  "\xa2\xf3\xc0\xc7\x58\xe5\xf5\x51\x86\x3a\x96\xc9\x49\xad\x47\xd7" \
-  "\xfb\x40\xd2"
-#define SHA1_SEED "\xd0\x56\x9c\xb3\x66\x5a\x8a\x43\xeb\x6e\xa2\x3d" \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 81]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  "\x75\xa3\xc4\xd2\x05\x4a\x0d\x7d"
-#define SHA224_SEED "\xd0\x56\x9c\xb3\x66\x5a\x8a\x43\xeb\x6e\xa2" \
-  "\x3d\x75\xa3\xc4\xd2\x05\x4a\x0d\x7d\x66\xa9\xca\x99\xc9\xce\xb0" \
-  "\x27"
-#define SHA256_SEED "\xf4\x1e\xce\x26\x13\xe4\x57\x39\x15\x69\x6b" \
-  "\x5a\xdc\xd5\x1c\xa3\x28\xbe\x3b\xf5\x66\xa9\xca\x99\xc9\xce\xb0" \
-  "\x27\x9c\x1c\xb0\xa7"
-#define SHA384_SEED "\x82\x40\xbc\x51\xe4\xec\x7e\xf7\x6d\x18\xe3" \
-  "\x52\x04\xa1\x9f\x51\xa5\x21\x3a\x73\xa8\x1d\x6f\x94\x46\x80\xd3" \
-  "\x07\x59\x48\xb7\xe4\x63\x80\x4e\xa3\xd2\x6e\x13\xea\x82\x0d\x65" \
-  "\xa4\x84\xbe\x74\x53"
-#define SHA512_SEED "\x47\x3f\xf1\xb9\xb3\xff\xdf\xa1\x26\x69\x9a" \
-  "\xc7\xef\x9e\x8e\x78\x77\x73\x09\x58\x24\xc6\x42\x55\x7c\x13\x99" \
-  "\xd9\x8e\x42\x20\x44\x8d\xc3\x5b\x99\xbf\xdd\x44\x77\x95\x43\x92" \
-  "\x4c\x1c\xe9\x3b\xc5\x94\x15\x38\x89\x5d\xb9\x88\x26\x1b\x00\x77" \
-  "\x4b\x12\x27\x20\x39"
-
-#define TESTCOUNT 10
-#define HASHCOUNT 5
-#define RANDOMCOUNT 4
-#define HMACTESTCOUNT 7
-
-#define PRINTNONE 0
-#define PRINTTEXT 1
-#define PRINTRAW 2
-#define PRINTHEX 3
-#define PRINTBASE64 4
-
-#define PRINTPASSFAIL 1
-#define PRINTFAIL 2
-
-#define length(x) (sizeof(x)-1)
-
-/* Test arrays for hashes. */
-struct hash {
-    const char *name;
-    SHAversion whichSha;
-    int hashsize;
-    struct {
-        const char *testarray;
-        int length;
-        long repeatcount;
-        int extrabits;
-        int numberExtrabits;
-        const char *resultarray;
-    } tests[TESTCOUNT];
-    const char *randomtest;
-    const char *randomresults[RANDOMCOUNT];
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 82]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-} hashes[HASHCOUNT] = {
-  { "SHA1", SHA1, SHA1HashSize,
-    {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
-        "A9993E364706816ABA3E25717850C26C9CD0D89D" },
-      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0,
-        "84983E441C3BD26EBAAE4AA1F95129E5E54670F1" },
-      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
-        "34AA973CD4C4DAA4F61EEB2BDBAD27316534016F" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
-        "DEA356A2CDDD90C7A7ECEDC5EBB563934F460452" },
-      /* 5 */ { "", 0, 0, 0x98, 5,
-        "29826B003B906E660EFF4027CE98AF3531AC75BA" },
-      /* 6 */ { "\x5e", 1, 1, 0, 0,
-        "5E6F80A34A9798CAFC6A5DB96CC57BA4C4DB59C2" },
-      /* 7 */ { TEST7_1, length(TEST7_1), 1, 0x80, 3,
-        "6239781E03729919C01955B3FFA8ACB60B988340" },
-      /* 8 */ { TEST8_1, length(TEST8_1), 1, 0, 0,
-        "82ABFF6605DBE1C17DEF12A394FA22A82B544A35" },
-      /* 9 */ { TEST9_1, length(TEST9_1), 1, 0xE0, 3,
-        "8C5B2A5DDAE5A97FC7F9D85661C672ADBF7933D4" },
-      /* 10 */ { TEST10_1, length(TEST10_1), 1, 0, 0,
-        "CB0082C8F197D260991BA6A460E76E202BAD27B3" }
-    }, SHA1_SEED, { "E216836819477C7F78E0D843FE4FF1B6D6C14CD4",
-        "A2DBC7A5B1C6C0A8BCB7AAA41252A6A7D0690DBC",
-        "DB1F9050BB863DFEF4CE37186044E2EEB17EE013",
-        "127FDEDF43D372A51D5747C48FBFFE38EF6CDF7B"
-     } },
-  { "SHA224", SHA224, SHA224HashSize,
-    {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
-        "23097D223405D8228642A477BDA255B32AADBCE4BDA0B3F7E36C9DA7" },
-      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0,
-        "75388B16512776CC5DBA5DA1FD890150B0C6455CB4F58B1952522525" },
-      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
-        "20794655980C91D8BBB4C1EA97618A4BF03F42581948B2EE4EE7AD67" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
-        "567F69F168CD7844E65259CE658FE7AADFA25216E68ECA0EB7AB8262" },
-      /* 5 */ { "", 0, 0, 0x68, 5,
-        "E3B048552C3C387BCAB37F6EB06BB79B96A4AEE5FF27F51531A9551C" },
-      /* 6 */ { "\x07", 1, 1, 0, 0,
-        "00ECD5F138422B8AD74C9799FD826C531BAD2FCABC7450BEE2AA8C2A" },
-      /* 7 */ { TEST7_224, length(TEST7_224), 1, 0xA0, 3,
-        "1B01DB6CB4A9E43DED1516BEB3DB0B87B6D1EA43187462C608137150" },
-      /* 8 */ { TEST8_224, length(TEST8_224), 1, 0, 0,
-        "DF90D78AA78821C99B40BA4C966921ACCD8FFB1E98AC388E56191DB1" },
-      /* 9 */ { TEST9_224, length(TEST9_224), 1, 0xE0, 3,
-        "54BEA6EAB8195A2EB0A7906A4B4A876666300EEFBD1F3B8474F9CD57" },
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 83]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      /* 10 */ { TEST10_224, length(TEST10_224), 1, 0, 0,
-        "0B31894EC8937AD9B91BDFBCBA294D9ADEFAA18E09305E9F20D5C3A4" }
-    }, SHA224_SEED, { "100966A5B4FDE0B42E2A6C5953D4D7F41BA7CF79FD"
-        "2DF431416734BE", "1DCA396B0C417715DEFAAE9641E10A2E99D55A"
-        "BCB8A00061EB3BE8BD", "1864E627BDB2319973CD5ED7D68DA71D8B"
-        "F0F983D8D9AB32C34ADB34", "A2406481FC1BCAF24DD08E6752E844"
-        "709563FB916227FED598EB621F"
-     } },
-  { "SHA256", SHA256, SHA256HashSize,
-  {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0, "BA7816BF8F01CFEA4141"
-        "40DE5DAE2223B00361A396177A9CB410FF61F20015AD" },
-      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0, "248D6A61D20638B8"
-        "E5C026930C3E6039A33CE45964FF2167F6ECEDD419DB06C1" },
-      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0, "CDC76E5C9914FB92"
-        "81A1C7E284D73E67F1809A48A497200E046D39CCC7112CD0" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0, "594847328451BDFA"
-        "85056225462CC1D867D877FB388DF0CE35F25AB5562BFBB5" },
-      /* 5 */ { "", 0, 0, 0x68, 5, "D6D3E02A31A84A8CAA9718ED6C2057BE"
-        "09DB45E7823EB5079CE7A573A3760F95" },
-      /* 6 */ { "\x19", 1, 1, 0, 0, "68AA2E2EE5DFF96E3355E6C7EE373E3D"
-        "6A4E17F75F9518D843709C0C9BC3E3D4" },
-      /* 7 */ { TEST7_256, length(TEST7_256), 1, 0x60, 3, "77EC1DC8"
-        "9C821FF2A1279089FA091B35B8CD960BCAF7DE01C6A7680756BEB972" },
-      /* 8 */ { TEST8_256, length(TEST8_256), 1, 0, 0, "175EE69B02BA"
-        "9B58E2B0A5FD13819CEA573F3940A94F825128CF4209BEABB4E8" },
-      /* 9 */ { TEST9_256, length(TEST9_256), 1, 0xA0, 3, "3E9AD646"
-        "8BBBAD2AC3C2CDC292E018BA5FD70B960CF1679777FCE708FDB066E9" },
-      /* 10 */ { TEST10_256, length(TEST10_256), 1, 0, 0, "97DBCA7D"
-        "F46D62C8A422C941DD7E835B8AD3361763F7E9B2D95F4F0DA6E1CCBC" },
-    }, SHA256_SEED, { "83D28614D49C3ADC1D6FC05DB5F48037C056F8D2A4CE44"
-        "EC6457DEA5DD797CD1", "99DBE3127EF2E93DD9322D6A07909EB33B6399"
-        "5E529B3F954B8581621BB74D39", "8D4BE295BB64661CA3C7EFD129A2F7"
-        "25B33072DBDDE32385B9A87B9AF88EA76F", "40AF5D3F9716B040DF9408"
-        "E31536B70FF906EC51B00447CA97D7DD97C12411F4"
-    } },
-  { "SHA384", SHA384, SHA384HashSize,
-    {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
-        "CB00753F45A35E8BB5A03D699AC65007272C32AB0EDED163"
-        "1A8B605A43FF5BED8086072BA1E7CC2358BAECA134C825A7" },
-      /* 2 */ { TEST2_2, length(TEST2_2), 1, 0, 0,
-        "09330C33F71147E83D192FC782CD1B4753111B173B3B05D2"
-        "2FA08086E3B0F712FCC7C71A557E2DB966C3E9FA91746039" },
-      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
-        "9D0E1809716474CB086E834E310A4A1CED149E9C00F24852"
-        "7972CEC5704C2A5B07B8B3DC38ECC4EBAE97DDD87F3D8985" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 84]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        "2FC64A4F500DDB6828F6A3430B8DD72A368EB7F3A8322A70"
-        "BC84275B9C0B3AB00D27A5CC3C2D224AA6B61A0D79FB4596" },
-      /* 5 */ { "", 0, 0, 0x10, 5,
-        "8D17BE79E32B6718E07D8A603EB84BA0478F7FCFD1BB9399"
-        "5F7D1149E09143AC1FFCFC56820E469F3878D957A15A3FE4" },
-      /* 6 */ { "\xb9", 1, 1, 0, 0,
-        "BC8089A19007C0B14195F4ECC74094FEC64F01F90929282C"
-        "2FB392881578208AD466828B1C6C283D2722CF0AD1AB6938" },
-      /* 7 */ { TEST7_384, length(TEST7_384), 1, 0xA0, 3,
-        "D8C43B38E12E7C42A7C9B810299FD6A770BEF30920F17532"
-        "A898DE62C7A07E4293449C0B5FA70109F0783211CFC4BCE3" },
-      /* 8 */ { TEST8_384, length(TEST8_384), 1, 0, 0,
-        "C9A68443A005812256B8EC76B00516F0DBB74FAB26D66591"
-        "3F194B6FFB0E91EA9967566B58109CBC675CC208E4C823F7" },
-      /* 9 */ { TEST9_384, length(TEST9_384), 1, 0xE0, 3,
-        "5860E8DE91C21578BB4174D227898A98E0B45C4C760F0095"
-        "49495614DAEDC0775D92D11D9F8CE9B064EEAC8DAFC3A297" },
-      /* 10 */ { TEST10_384, length(TEST10_384), 1, 0, 0,
-        "4F440DB1E6EDD2899FA335F09515AA025EE177A79F4B4AAF"
-        "38E42B5C4DE660F5DE8FB2A5B2FBD2A3CBFFD20CFF1288C0" }
-    }, SHA384_SEED, { "CE44D7D63AE0C91482998CF662A51EC80BF6FC68661A3C"
-        "57F87566112BD635A743EA904DEB7D7A42AC808CABE697F38F", "F9C6D2"
-        "61881FEE41ACD39E67AA8D0BAD507C7363EB67E2B81F45759F9C0FD7B503"
-        "DF1A0B9E80BDE7BC333D75B804197D", "D96512D8C9F4A7A4967A366C01"
-        "C6FD97384225B58343A88264847C18E4EF8AB7AEE4765FFBC3E30BD485D3"
-        "638A01418F", "0CA76BD0813AF1509E170907A96005938BC985628290B2"
-        "5FEF73CF6FAD68DDBA0AC8920C94E0541607B0915A7B4457F7"
-    } },
-  { "SHA512", SHA512, SHA512HashSize,
-    {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
-        "DDAF35A193617ABACC417349AE20413112E6FA4E89A97EA2"
-        "0A9EEEE64B55D39A2192992A274FC1A836BA3C23A3FEEBBD"
-        "454D4423643CE80E2A9AC94FA54CA49F" },
-      /* 2 */ { TEST2_2, length(TEST2_2), 1, 0, 0,
-        "8E959B75DAE313DA8CF4F72814FC143F8F7779C6EB9F7FA1"
-        "7299AEADB6889018501D289E4900F7E4331B99DEC4B5433A"
-        "C7D329EEB6DD26545E96E55B874BE909" },
-       /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
-        "E718483D0CE769644E2E42C7BC15B4638E1F98B13B204428"
-        "5632A803AFA973EBDE0FF244877EA60A4CB0432CE577C31B"
-        "EB009C5C2C49AA2E4EADB217AD8CC09B" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
-        "89D05BA632C699C31231DED4FFC127D5A894DAD412C0E024"
-        "DB872D1ABD2BA8141A0F85072A9BE1E2AA04CF33C765CB51"
-        "0813A39CD5A84C4ACAA64D3F3FB7BAE9" },
-      /* 5 */ { "", 0, 0, 0xB0, 5,
-        "D4EE29A9E90985446B913CF1D1376C836F4BE2C1CF3CADA0"
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 85]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        "720A6BF4857D886A7ECB3C4E4C0FA8C7F95214E41DC1B0D2"
-        "1B22A84CC03BF8CE4845F34DD5BDBAD4" },
-      /* 6 */ { "\xD0", 1, 1, 0, 0,
-        "9992202938E882E73E20F6B69E68A0A7149090423D93C81B"
-        "AB3F21678D4ACEEEE50E4E8CAFADA4C85A54EA8306826C4A"
-        "D6E74CECE9631BFA8A549B4AB3FBBA15" },
-      /* 7 */ { TEST7_512, length(TEST7_512), 1, 0x80, 3,
-        "ED8DC78E8B01B69750053DBB7A0A9EDA0FB9E9D292B1ED71"
-        "5E80A7FE290A4E16664FD913E85854400C5AF05E6DAD316B"
-        "7359B43E64F8BEC3C1F237119986BBB6" },
-      /* 8 */ { TEST8_512, length(TEST8_512), 1, 0, 0,
-        "CB0B67A4B8712CD73C9AABC0B199E9269B20844AFB75ACBD"
-        "D1C153C9828924C3DDEDAAFE669C5FDD0BC66F630F677398"
-        "8213EB1B16F517AD0DE4B2F0C95C90F8" },
-      /* 9 */ { TEST9_512, length(TEST9_512), 1, 0x80, 3,
-        "32BA76FC30EAA0208AEB50FFB5AF1864FDBF17902A4DC0A6"
-        "82C61FCEA6D92B783267B21080301837F59DE79C6B337DB2"
-        "526F8A0A510E5E53CAFED4355FE7C2F1" },
-      /* 10 */ { TEST10_512, length(TEST10_512), 1, 0, 0,
-        "C665BEFB36DA189D78822D10528CBF3B12B3EEF726039909"
-        "C1A16A270D48719377966B957A878E720584779A62825C18"
-        "DA26415E49A7176A894E7510FD1451F5" }
-    }, SHA512_SEED, { "2FBB1E7E00F746BA514FBC8C421F36792EC0E11FF5EFC3"
-        "78E1AB0C079AA5F0F66A1E3EDBAEB4F9984BE14437123038A452004A5576"
-        "8C1FD8EED49E4A21BEDCD0", "25CBE5A4F2C7B1D7EF07011705D50C62C5"
-        "000594243EAFD1241FC9F3D22B58184AE2FEE38E171CF8129E29459C9BC2"
-        "EF461AF5708887315F15419D8D17FE7949", "5B8B1F2687555CE2D7182B"
-        "92E5C3F6C36547DA1C13DBB9EA4F73EA4CBBAF89411527906D35B1B06C1B"
-        "6A8007D05EC66DF0A406066829EAB618BDE3976515AAFC", "46E36B007D"
-        "19876CDB0B29AD074FE3C08CDD174D42169D6ABE5A1414B6E79707DF5877"
-        "6A98091CF431854147BB6D3C66D43BFBC108FD715BDE6AA127C2B0E79F"
-    }
-  }
-};
-
-/* Test arrays for HMAC. */
-struct hmachash {
-    const char *keyarray[5];
-    int keylength[5];
-    const char *dataarray[5];
-    int datalength[5];
-    const char *resultarray[5];
-    int resultlength[5];
-} hmachashes[HMACTESTCOUNT] = {
-  { /* 1 */ {
-      "\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b"
-      "\x0b\x0b\x0b\x0b\x0b"
-    }, { 20 }, {
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 86]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      "\x48\x69\x20\x54\x68\x65\x72\x65" /* "Hi There" */
-    }, { 8 }, {
-      /* HMAC-SHA-1 */
-      "B617318655057264E28BC0B6FB378C8EF146BE00",
-      /* HMAC-SHA-224 */
-      "896FB1128ABBDF196832107CD49DF33F47B4B1169912BA4F53684B22",
-      /* HMAC-SHA-256 */
-      "B0344C61D8DB38535CA8AFCEAF0BF12B881DC200C9833DA726E9376C2E32"
-      "CFF7",
-      /* HMAC-SHA-384 */
-      "AFD03944D84895626B0825F4AB46907F15F9DADBE4101EC682AA034C7CEB"
-      "C59CFAEA9EA9076EDE7F4AF152E8B2FA9CB6",
-      /* HMAC-SHA-512 */
-      "87AA7CDEA5EF619D4FF0B4241A1D6CB02379F4E2CE4EC2787AD0B30545E1"
-      "7CDEDAA833B7D6B8A702038B274EAEA3F4E4BE9D914EEB61F1702E696C20"
-      "3A126854"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-  { /* 2 */ {
-      "\x4a\x65\x66\x65" /* "Jefe" */
-    }, { 4 }, {
-      "\x77\x68\x61\x74\x20\x64\x6f\x20\x79\x61\x20\x77\x61\x6e\x74"
-      "\x20\x66\x6f\x72\x20\x6e\x6f\x74\x68\x69\x6e\x67\x3f"
-      /* "what do ya want for nothing?" */
-    }, { 28 }, {
-      /* HMAC-SHA-1 */
-      "EFFCDF6AE5EB2FA2D27416D5F184DF9C259A7C79",
-      /* HMAC-SHA-224 */
-      "A30E01098BC6DBBF45690F3A7E9E6D0F8BBEA2A39E6148008FD05E44",
-      /* HMAC-SHA-256 */
-      "5BDCC146BF60754E6A042426089575C75A003F089D2739839DEC58B964EC"
-      "3843",
-      /* HMAC-SHA-384 */
-      "AF45D2E376484031617F78D2B58A6B1B9C7EF464F5A01B47E42EC3736322"
-      "445E8E2240CA5E69E2C78B3239ECFAB21649",
-      /* HMAC-SHA-512 */
-      "164B7A7BFCF819E2E395FBE73B56E0A387BD64222E831FD610270CD7EA25"
-      "05549758BF75C05A994A6D034F65F8F0E6FDCAEAB1A34D4A6B4B636E070A"
-      "38BCE737"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-  { /* 3 */
-    {
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa"
-    }, { 20 }, {
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 87]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
-      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
-      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
-      "\xdd\xdd\xdd\xdd\xdd"
-    }, { 50 }, {
-      /* HMAC-SHA-1 */
-      "125D7342B9AC11CD91A39AF48AA17B4F63F175D3",
-      /* HMAC-SHA-224 */
-      "7FB3CB3588C6C1F6FFA9694D7D6AD2649365B0C1F65D69D1EC8333EA",
-      /* HMAC-SHA-256 */
-      "773EA91E36800E46854DB8EBD09181A72959098B3EF8C122D9635514CED5"
-      "65FE",
-      /* HMAC-SHA-384 */
-      "88062608D3E6AD8A0AA2ACE014C8A86F0AA635D947AC9FEBE83EF4E55966"
-      "144B2A5AB39DC13814B94E3AB6E101A34F27",
-      /* HMAC-SHA-512 */
-      "FA73B0089D56A284EFB0F0756C890BE9B1B5DBDD8EE81A3655F83E33B227"
-      "9D39BF3E848279A722C806B485A47E67C807B946A337BEE8942674278859"
-      "E13292FB"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-  { /* 4 */ {
-      "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"
-      "\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19"
-    }, { 25 }, {
-      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
-      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
-      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
-      "\xcd\xcd\xcd\xcd\xcd"
-    }, { 50 }, {
-      /* HMAC-SHA-1 */
-      "4C9007F4026250C6BC8414F9BF50C86C2D7235DA",
-      /* HMAC-SHA-224 */
-      "6C11506874013CAC6A2ABC1BB382627CEC6A90D86EFC012DE7AFEC5A",
-      /* HMAC-SHA-256 */
-      "82558A389A443C0EA4CC819899F2083A85F0FAA3E578F8077A2E3FF46729"
-      "665B",
-      /* HMAC-SHA-384 */
-      "3E8A69B7783C25851933AB6290AF6CA77A9981480850009CC5577C6E1F57"
-      "3B4E6801DD23C4A7D679CCF8A386C674CFFB",
-      /* HMAC-SHA-512 */
-      "B0BA465637458C6990E5A8C5F61D4AF7E576D97FF94B872DE76F8050361E"
-      "E3DBA91CA5C11AA25EB4D679275CC5788063A5F19741120C4F2DE2ADEBEB"
-      "10A298DD"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 88]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  { /* 5 */ {
-      "\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c"
-      "\x0c\x0c\x0c\x0c\x0c"
-    }, { 20 }, {
-      "Test With Truncation"
-    }, { 20 }, {
-      /* HMAC-SHA-1 */
-      "4C1A03424B55E07FE7F27BE1",
-      /* HMAC-SHA-224 */
-      "0E2AEA68A90C8D37C988BCDB9FCA6FA8",
-      /* HMAC-SHA-256 */
-      "A3B6167473100EE06E0C796C2955552B",
-      /* HMAC-SHA-384 */
-      "3ABF34C3503B2A23A46EFC619BAEF897",
-      /* HMAC-SHA-512 */
-      "415FAD6271580A531D4179BC891D87A6"
-    }, { 12, 16, 16, 16, 16 }
-  },
-  { /* 6 */ {
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-    }, { 80, 131 }, {
-      "Test Using Larger Than Block-Size Key - Hash Key First"
-    }, { 54 }, {
-      /* HMAC-SHA-1 */
-      "AA4AE5E15272D00E95705637CE8A3B55ED402112",
-      /* HMAC-SHA-224 */
-      "95E9A0DB962095ADAEBE9B2D6F0DBCE2D499F112F2D2B7273FA6870E",
-      /* HMAC-SHA-256 */
-      "60E431591EE0B67F0D8A26AACBF5B77F8E0BC6213728C5140546040F0EE3"
-      "7F54",
-      /* HMAC-SHA-384 */
-      "4ECE084485813E9088D2C63A041BC5B44F9EF1012A2B588F3CD11F05033A"
-      "C4C60C2EF6AB4030FE8296248DF163F44952",
-      /* HMAC-SHA-512 */
-      "80B24263C7C1A3EBB71493C1DD7BE8B49B46D1F41B4AEEC1121B013783F8"
-      "F3526B56D037E05F2598BD0FD2215D6A1E5295E64F73F63F0AEC8B915A98"
-      "5D786598"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 89]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  { /* 7 */ {
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-    }, { 80, 131 }, {
-      "Test Using Larger Than Block-Size Key and "
-      "Larger Than One Block-Size Data",
-      "\x54\x68\x69\x73\x20\x69\x73\x20\x61\x20\x74\x65\x73\x74\x20"
-      "\x75\x73\x69\x6e\x67\x20\x61\x20\x6c\x61\x72\x67\x65\x72\x20"
-      "\x74\x68\x61\x6e\x20\x62\x6c\x6f\x63\x6b\x2d\x73\x69\x7a\x65"
-      "\x20\x6b\x65\x79\x20\x61\x6e\x64\x20\x61\x20\x6c\x61\x72\x67"
-      "\x65\x72\x20\x74\x68\x61\x6e\x20\x62\x6c\x6f\x63\x6b\x2d\x73"
-      "\x69\x7a\x65\x20\x64\x61\x74\x61\x2e\x20\x54\x68\x65\x20\x6b"
-      "\x65\x79\x20\x6e\x65\x65\x64\x73\x20\x74\x6f\x20\x62\x65\x20"
-      "\x68\x61\x73\x68\x65\x64\x20\x62\x65\x66\x6f\x72\x65\x20\x62"
-      "\x65\x69\x6e\x67\x20\x75\x73\x65\x64\x20\x62\x79\x20\x74\x68"
-      "\x65\x20\x48\x4d\x41\x43\x20\x61\x6c\x67\x6f\x72\x69\x74\x68"
-      "\x6d\x2e"
-      /* "This is a test using a larger than block-size key and a "
-          "larger than block-size data. The key needs to be hashed "
-          "before being used by the HMAC algorithm." */
-    }, { 73, 152 }, {
-      /* HMAC-SHA-1 */
-      "E8E99D0F45237D786D6BBAA7965C7808BBFF1A91",
-      /* HMAC-SHA-224 */
-      "3A854166AC5D9F023F54D517D0B39DBD946770DB9C2B95C9F6F565D1",
-      /* HMAC-SHA-256 */
-      "9B09FFA71B942FCB27635FBCD5B0E944BFDC63644F0713938A7F51535C3A"
-      "35E2",
-      /* HMAC-SHA-384 */
-      "6617178E941F020D351E2F254E8FD32C602420FEB0B8FB9ADCCEBB82461E"
-      "99C5A678CC31E799176D3860E6110C46523E",
-      /* HMAC-SHA-512 */
-      "E37B6A775DC87DBAA4DFA9F96E5E3FFDDEBD71F8867289865DF5A32D20CD"
-      "C944B6022CAC3C4982B10D5EEB55C3E4DE15134676FB6DE0446065C97440"
-      "FA8C6A58"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  }
-};
-
-/*
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 90]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Check the hash value against the expected string, expressed in hex
- */
-static const char hexdigits[] = "0123456789ABCDEF";
-int checkmatch(const unsigned char *hashvalue,
-  const char *hexstr, int hashsize)
-{
-  int i;
-  for (i = 0; i < hashsize; ++i) {
-    if (*hexstr++ != hexdigits[(hashvalue[i] >> 4) & 0xF])
-      return 0;
-    if (*hexstr++ != hexdigits[hashvalue[i] & 0xF]) return 0;
-  }
-  return 1;
-}
-
-/*
- * Print the string, converting non-printable characters to "."
- */
-void printstr(const char *str, int len)
-{
-  for ( ; len-- > 0; str++)
-    putchar(isprint((unsigned char)*str) ? *str : '.');
-}
-
-/*
- * Print the string, converting non-printable characters to hex "## ".
- */
-void printxstr(const char *str, int len)
-{
-  for ( ; len-- > 0; str++)
-    printf("%c%c ", hexdigits[(*str >> 4) & 0xF],
-      hexdigits[*str & 0xF]);
-}
-
-/*
- * Print a usage message.
- */
-void usage(const char *argv0)
-{
-  fprintf(stderr,
-    "Usage:\n"
-    "Common options: [-h hash] [-w|-x] [-H]\n"
-    "Standard tests:\n"
-      "\t%s [-m] [-l loopcount] [-t test#] [-e]\n"
-      "\t\t[-r randomseed] [-R randomloop-count] "
-        "[-p] [-P|-X]\n"
-    "Hash a string:\n"
-      "\t%s [-S expectedresult] -s hashstr [-k key]\n"
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 91]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    "Hash a file:\n"
-      "\t%s [-S expectedresult] -f file [-k key]\n"
-    "Hash a file, ignoring whitespace:\n"
-      "\t%s [-S expectedresult] -F file [-k key]\n"
-    "Additional bits to add in: [-B bitcount -b bits]\n"
-    "-h\thash to test: "
-      "0|SHA1, 1|SHA224, 2|SHA256, 3|SHA384, 4|SHA512\n"
-    "-m\tperform hmac test\n"
-    "-k\tkey for hmac test\n"
-    "-t\ttest case to run, 1-10\n"
-    "-l\thow many times to run the test\n"
-    "-e\ttest error returns\n"
-    "-p\tdo not print results\n"
-    "-P\tdo not print PASSED/FAILED\n"
-    "-X\tprint FAILED, but not PASSED\n"
-    "-r\tseed for random test\n"
-    "-R\thow many times to run random test\n"
-    "-s\tstring to hash\n"
-    "-S\texpected result of hashed string, in hex\n"
-    "-w\toutput hash in raw format\n"
-    "-x\toutput hash in hex format\n"
-    "-B\t# extra bits to add in after string or file input\n"
-    "-b\textra bits to add (high order bits of #, 0# or 0x#)\n"
-    "-H\tinput hashstr or randomseed is in hex\n"
-    , argv0, argv0, argv0, argv0);
-  exit(1);
-}
-
-/*
- * Print the results and PASS/FAIL.
- */
-void printResult(uint8_t *Message_Digest, int hashsize,
-    const char *hashname, const char *testtype, const char *testname,
-    const char *resultarray, int printResults, int printPassFail)
-{
-  int i, k;
-  if (printResults == PRINTTEXT) {
-    putchar('\t');
-    for (i = 0; i < hashsize ; ++i) {
-      putchar(hexdigits[(Message_Digest[i] >> 4) & 0xF]);
-      putchar(hexdigits[Message_Digest[i] & 0xF]);
-      putchar(' ');
-    }
-    putchar('\n');
-  } else if (printResults == PRINTRAW) {
-    fwrite(Message_Digest, 1, hashsize, stdout);
-  } else if (printResults == PRINTHEX) {
-    for (i = 0; i < hashsize ; ++i) {
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 92]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      putchar(hexdigits[(Message_Digest[i] >> 4) & 0xF]);
-      putchar(hexdigits[Message_Digest[i] & 0xF]);
-    }
-    putchar('\n');
-  }
-
-  if (printResults && resultarray) {
-    printf("    Should match:\n\t");
-    for (i = 0, k = 0; i < hashsize; i++, k += 2) {
-      putchar(resultarray[k]);
-      putchar(resultarray[k+1]);
-      putchar(' ');
-    }
-    putchar('\n');
-  }
-
-  if (printPassFail && resultarray) {
-    int ret = checkmatch(Message_Digest, resultarray, hashsize);
-    if ((printPassFail == PRINTPASSFAIL) || !ret)
-      printf("%s %s %s: %s\n", hashname, testtype, testname,
-        ret ? "PASSED" : "FAILED");
-  }
-}
-
-/*
- * Exercise a hash series of functions. The input is the testarray,
- * repeated repeatcount times, followed by the extrabits. If the
- * result is known, it is in resultarray in uppercase hex.
- */
-int hash(int testno, int loopno, int hashno,
-  const char *testarray, int length, long repeatcount,
-  int numberExtrabits, int extrabits, const unsigned char *keyarray,
-  int keylen, const char *resultarray, int hashsize, int printResults,
-  int printPassFail)
-{
-  USHAContext sha;
-  HMACContext hmac;
-  int err, i;
-  uint8_t Message_Digest[USHAMaxHashSize];
-  char buf[20];
-
-  if (printResults == PRINTTEXT) {
-    printf("\nTest %d: Iteration %d, Repeat %ld\n\t'", testno+1,
-      loopno, repeatcount);
-    printstr(testarray, length);
-    printf("'\n\t'");
-    printxstr(testarray, length);
-    printf("'\n");
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 93]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    printf("    Length=%d bytes (%d bits), ", length, length * 8);
-    printf("ExtraBits %d: %2.2x\n", numberExtrabits, extrabits);
-  }
-
-  memset(&sha, '\343', sizeof(sha)); /* force bad data into struct */
-  memset(&hmac, '\343', sizeof(hmac));
-  err = keyarray ? hmacReset(&hmac, hashes[hashno].whichSha,
-                             keyarray, keylen) :
-                   USHAReset(&sha, hashes[hashno].whichSha);
-  if (err != shaSuccess) {
-    fprintf(stderr, "hash(): %sReset Error %d.\n",
-            keyarray ? "hmac" : "sha", err);
-    return err;
-  }
-
-  for (i = 0; i < repeatcount; ++i) {
-    err = keyarray ? hmacInput(&hmac, (const uint8_t *) testarray,
-                               length) :
-                     USHAInput(&sha, (const uint8_t *) testarray,
-                               length);
-    if (err != shaSuccess) {
-      fprintf(stderr, "hash(): %sInput Error %d.\n",
-              keyarray ? "hmac" : "sha", err);
-      return err;
-    }
-  }
-
-  if (numberExtrabits > 0) {
-    err = keyarray ? hmacFinalBits(&hmac, (uint8_t) extrabits,
-                                   numberExtrabits) :
-                     USHAFinalBits(&sha, (uint8_t) extrabits,
-                                   numberExtrabits);
-    if (err != shaSuccess) {
-      fprintf(stderr, "hash(): %sFinalBits Error %d.\n",
-              keyarray ? "hmac" : "sha", err);
-      return err;
-    }
-  }
-
-  err = keyarray ? hmacResult(&hmac, Message_Digest) :
-                   USHAResult(&sha, Message_Digest);
-  if (err != shaSuccess) {
-    fprintf(stderr, "hash(): %s Result Error %d, could not "
-      "compute message digest.\n", keyarray ? "hmac" : "sha", err);
-    return err;
-  }
-
-  sprintf(buf, "%d", testno+1);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 94]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  printResult(Message_Digest, hashsize, hashes[hashno].name,
-    keyarray ? "hmac standard test" : "sha standard test", buf,
-    resultarray, printResults, printPassFail);
-
-  return err;
-}
-
-/*
- * Exercise a hash series of functions. The input is a filename.
- * If the result is known, it is in resultarray in uppercase hex.
- */
-int hashfile(int hashno, const char *hashfilename, int bits,
-  int bitcount, int skipSpaces, const unsigned char *keyarray,
-  int keylen, const char *resultarray, int hashsize,
-  int printResults, int printPassFail)
-{
-  USHAContext sha;
-  HMACContext hmac;
-  int err, nread, c;
-  unsigned char buf[4096];
-  uint8_t Message_Digest[USHAMaxHashSize];
-  unsigned char cc;
-  FILE *hashfp = (strcmp(hashfilename, "-") == 0) ? stdin :
-    fopen(hashfilename, "r");
-
-  if (!hashfp) {
-    fprintf(stderr, "cannot open file '%s'\n", hashfilename);
-    return shaStateError;
-  }
-
-  memset(&sha, '\343', sizeof(sha)); /* force bad data into struct */
-  memset(&hmac, '\343', sizeof(hmac));
-  err = keyarray ? hmacReset(&hmac, hashes[hashno].whichSha,
-                             keyarray, keylen) :
-                   USHAReset(&sha, hashes[hashno].whichSha);
-
-  if (err != shaSuccess) {
-    fprintf(stderr, "hashfile(): %sReset Error %d.\n",
-            keyarray ? "hmac" : "sha", err);
-    return err;
-  }
-
-  if (skipSpaces)
-    while ((c = getc(hashfp)) != EOF) {
-      if (!isspace(c)) {
-        cc = (unsigned char)c;
-        err = keyarray ? hmacInput(&hmac, &cc, 1) :
-                         USHAInput(&sha, &cc, 1);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 95]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        if (err != shaSuccess) {
-          fprintf(stderr, "hashfile(): %sInput Error %d.\n",
-                  keyarray ? "hmac" : "sha", err);
-          if (hashfp != stdin) fclose(hashfp);
-          return err;
-        }
-      }
-    }
-  else
-    while ((nread = fread(buf, 1, sizeof(buf), hashfp)) > 0) {
-      err = keyarray ? hmacInput(&hmac, buf, nread) :
-                       USHAInput(&sha, buf, nread);
-      if (err != shaSuccess) {
-        fprintf(stderr, "hashfile(): %s Error %d.\n",
-                keyarray ? "hmacInput" : "shaInput", err);
-        if (hashfp != stdin) fclose(hashfp);
-        return err;
-      }
-    }
-
-  if (bitcount > 0)
-    err = keyarray ? hmacFinalBits(&hmac, bits, bitcount) :
-                   USHAFinalBits(&sha, bits, bitcount);
-  if (err != shaSuccess) {
-    fprintf(stderr, "hashfile(): %s Error %d.\n",
-            keyarray ? "hmacResult" : "shaResult", err);
-    if (hashfp != stdin) fclose(hashfp);
-    return err;
-  }
-
-  err = keyarray ? hmacResult(&hmac, Message_Digest) :
-                   USHAResult(&sha, Message_Digest);
-  if (err != shaSuccess) {
-    fprintf(stderr, "hashfile(): %s Error %d.\n",
-            keyarray ? "hmacResult" : "shaResult", err);
-    if (hashfp != stdin) fclose(hashfp);
-    return err;
-  }
-
-  printResult(Message_Digest, hashsize, hashes[hashno].name, "file",
-    hashfilename, resultarray, printResults, printPassFail);
-
-  if (hashfp != stdin) fclose(hashfp);
-  return err;
-}
-
-/*
- * Exercise a hash series of functions through multiple permutations.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 96]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * The input is an initial seed. That seed is replicated 3 times.
- * For 1000 rounds, the previous three results are used as the input.
- * This result is then checked, and used to seed the next cycle.
- * If the result is known, it is in resultarrays in uppercase hex.
- */
-void randomtest(int hashno, const char *seed, int hashsize,
-    const char **resultarrays, int randomcount,
-    int printResults, int printPassFail)
-{
-  int i, j; char buf[20];
-  unsigned char SEED[USHAMaxHashSize], MD[1003][USHAMaxHashSize];
-
-  /* INPUT: Seed - A random seed n bits long */
-  memcpy(SEED, seed, hashsize);
-  if (printResults == PRINTTEXT) {
-    printf("%s random test seed= '", hashes[hashno].name);
-    printxstr(seed, hashsize);
-    printf("'\n");
-  }
-
-  for (j = 0; j < randomcount; j++) {
-    /* MD0 = MD1 = MD2 = Seed; */
-    memcpy(MD[0], SEED, hashsize);
-    memcpy(MD[1], SEED, hashsize);
-    memcpy(MD[2], SEED, hashsize);
-    for (i=3; i<1003; i++) {
-      /* Mi = MDi-3 || MDi-2 || MDi-1; */
-      USHAContext Mi;
-      memset(&Mi, '\343', sizeof(Mi)); /* force bad data into struct */
-      USHAReset(&Mi, hashes[hashno].whichSha);
-      USHAInput(&Mi, MD[i-3], hashsize);
-      USHAInput(&Mi, MD[i-2], hashsize);
-      USHAInput(&Mi, MD[i-1], hashsize);
-      /* MDi = SHA(Mi); */
-      USHAResult(&Mi, MD[i]);
-    }
-
-    /* MDj = Seed = MDi; */
-    memcpy(SEED, MD[i-1], hashsize);
-
-    /* OUTPUT: MDj */
-    sprintf(buf, "%d", j);
-    printResult(SEED, hashsize, hashes[hashno].name, "random test",
-      buf, resultarrays ? resultarrays[j] : 0, printResults,
-      (j < RANDOMCOUNT) ? printPassFail : 0);
-  }
-}
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 97]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- * Look up a hash name.
- */
-int findhash(const char *argv0, const char *opt)
-{
-  int i;
-  const char *names[HASHCOUNT][2] = {
-    { "0", "sha1" }, { "1", "sha224" }, { "2", "sha256" },
-    { "3", "sha384" }, { "4", "sha512" }
-  };
-
-  for (i = 0; i < HASHCOUNT; i++)
-    if ((strcmp(opt, names[i][0]) == 0) ||
-        (scasecmp(opt, names[i][1]) == 0))
-      return i;
-
-  fprintf(stderr, "%s: Unknown hash name: '%s'\n", argv0, opt);
-  usage(argv0);
-  return 0;
-}
-
-/*
- * Run some tests that should invoke errors.
- */
-void testErrors(int hashnolow, int hashnohigh, int printResults,
-    int printPassFail)
-{
-  USHAContext usha;
-  uint8_t Message_Digest[USHAMaxHashSize];
-  int hashno, err;
-
-  for (hashno = hashnolow; hashno <= hashnohigh; hashno++) {
-    memset(&usha, '\343', sizeof(usha)); /* force bad data */
-    USHAReset(&usha, hashno);
-    USHAResult(&usha, Message_Digest);
-    err = USHAInput(&usha, (const unsigned char *)"foo", 3);
-    if (printResults == PRINTTEXT)
-      printf ("\nError %d. Should be %d.\n", err, shaStateError);
-    if ((printPassFail == PRINTPASSFAIL) ||
-        ((printPassFail == PRINTFAIL) && (err != shaStateError)))
-      printf("%s se: %s\n", hashes[hashno].name,
-        (err == shaStateError) ? "PASSED" : "FAILED");
-
-    err = USHAFinalBits(&usha, 0x80, 3);
-    if (printResults == PRINTTEXT)
-      printf ("\nError %d. Should be %d.\n", err, shaStateError);
-    if ((printPassFail == PRINTPASSFAIL) ||
-        ((printPassFail == PRINTFAIL) && (err != shaStateError)))
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 98]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      printf("%s se: %s\n", hashes[hashno].name,
-        (err == shaStateError) ? "PASSED" : "FAILED");
-
-    err = USHAReset(0, hashes[hashno].whichSha);
-    if (printResults == PRINTTEXT)
-       printf("\nError %d. Should be %d.\n", err, shaNull);
-    if ((printPassFail == PRINTPASSFAIL) ||
-        ((printPassFail == PRINTFAIL) && (err != shaNull)))
-       printf("%s usha null: %s\n", hashes[hashno].name,
-        (err == shaNull) ? "PASSED" : "FAILED");
-
-    switch (hashno) {
-      case SHA1: err = SHA1Reset(0); break;
-      case SHA224: err = SHA224Reset(0); break;
-      case SHA256: err = SHA256Reset(0); break;
-      case SHA384: err = SHA384Reset(0); break;
-      case SHA512: err = SHA512Reset(0); break;
-    }
-    if (printResults == PRINTTEXT)
-       printf("\nError %d. Should be %d.\n", err, shaNull);
-    if ((printPassFail == PRINTPASSFAIL) ||
-        ((printPassFail == PRINTFAIL) && (err != shaNull)))
-       printf("%s sha null: %s\n", hashes[hashno].name,
-        (err == shaNull) ? "PASSED" : "FAILED");
-  }
-}
-
-/* replace a hex string in place with its value */
-int unhexStr(char *hexstr)
-{
-  char *o = hexstr;
-  int len = 0, nibble1 = 0, nibble2 = 0;
-  if (!hexstr) return 0;
-  for ( ; *hexstr; hexstr++) {
-    if (isalpha((int)(unsigned char)(*hexstr))) {
-      nibble1 = tolower(*hexstr) - 'a' + 10;
-    } else if (isdigit((int)(unsigned char)(*hexstr))) {
-      nibble1 = *hexstr - '0';
-    } else {
-      printf("\nError: bad hex character '%c'\n", *hexstr);
-    }
-    if (!*++hexstr) break;
-    if (isalpha((int)(unsigned char)(*hexstr))) {
-      nibble2 = tolower(*hexstr) - 'a' + 10;
-    } else if (isdigit((int)(unsigned char)(*hexstr))) {
-      nibble2 = *hexstr - '0';
-    } else {
-      printf("\nError: bad hex character '%c'\n", *hexstr);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 99]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    }
-    *o++ = (char)((nibble1 << 4) | nibble2);
-    len++;
-  }
-  return len;
-}
-
-int main(int argc, char **argv)
-{
-  int i, err;
-  int loopno, loopnohigh = 1;
-  int hashno, hashnolow = 0, hashnohigh = HASHCOUNT - 1;
-  int testno, testnolow = 0, testnohigh;
-  int ntestnohigh = 0;
-  int printResults = PRINTTEXT;
-  int printPassFail = 1;
-  int checkErrors = 0;
-  char *hashstr = 0;
-  int hashlen = 0;
-  const char *resultstr = 0;
-  char *randomseedstr = 0;
-  int runHmacTests = 0;
-  char *hmacKey = 0;
-  int hmaclen = 0;
-  int randomcount = RANDOMCOUNT;
-  const char *hashfilename = 0;
-  const char *hashFilename = 0;
-  int extrabits = 0, numberExtrabits = 0;
-  int strIsHex = 0;
-
-  while ((i = xgetopt(argc, argv, "b:B:ef:F:h:Hk:l:mpPr:R:s:S:t:wxX"))
-         != -1)
-    switch (i) {
-      case 'b': extrabits = strtol(xoptarg, 0, 0); break;
-      case 'B': numberExtrabits = atoi(xoptarg); break;
-      case 'e': checkErrors = 1; break;
-      case 'f': hashfilename = xoptarg; break;
-      case 'F': hashFilename = xoptarg; break;
-      case 'h': hashnolow = hashnohigh = findhash(argv[0], xoptarg);
-        break;
-      case 'H': strIsHex = 1; break;
-      case 'k': hmacKey = xoptarg; hmaclen = strlen(xoptarg); break;
-      case 'l': loopnohigh = atoi(xoptarg); break;
-      case 'm': runHmacTests = 1; break;
-      case 'P': printPassFail = 0; break;
-      case 'p': printResults = PRINTNONE; break;
-      case 'R': randomcount = atoi(xoptarg); break;
-      case 'r': randomseedstr = xoptarg; break;
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 100]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      case 's': hashstr = xoptarg; hashlen = strlen(hashstr); break;
-      case 'S': resultstr = xoptarg; break;
-      case 't': testnolow = ntestnohigh = atoi(xoptarg) - 1; break;
-      case 'w': printResults = PRINTRAW; break;
-      case 'x': printResults = PRINTHEX; break;
-      case 'X': printPassFail = 2; break;
-      default: usage(argv[0]);
-      }
-
-  if (strIsHex) {
-    hashlen = unhexStr(hashstr);
-    unhexStr(randomseedstr);
-    hmaclen = unhexStr(hmacKey);
-  }
-  testnohigh = (ntestnohigh != 0) ? ntestnohigh:
-               runHmacTests ? (HMACTESTCOUNT-1) : (TESTCOUNT-1);
-  if ((testnolow < 0) ||
-      (testnohigh >= (runHmacTests ? HMACTESTCOUNT : TESTCOUNT)) ||
-      (hashnolow < 0) || (hashnohigh >= HASHCOUNT) ||
-      (hashstr && (testnolow == testnohigh)) ||
-      (randomcount < 0) ||
-      (resultstr && (!hashstr && !hashfilename && !hashFilename)) ||
-      ((runHmacTests || hmacKey) && randomseedstr) ||
-      (hashfilename && hashFilename))
-    usage(argv[0]);
-
-  /*
-   *  Perform SHA/HMAC tests
-   */
-  for (hashno = hashnolow; hashno <= hashnohigh; ++hashno) {
-    if (printResults == PRINTTEXT)
-      printf("Hash %s\n", hashes[hashno].name);
-    err = shaSuccess;
-
-    for (loopno = 1; (loopno <= loopnohigh) && (err == shaSuccess);
-         ++loopno) {
-      if (hashstr)
-        err = hash(0, loopno, hashno, hashstr, hashlen, 1,
-          numberExtrabits, extrabits, (const unsigned char *)hmacKey,
-          hmaclen, resultstr, hashes[hashno].hashsize, printResults,
-          printPassFail);
-
-      else if (randomseedstr)
-        randomtest(hashno, randomseedstr, hashes[hashno].hashsize, 0,
-          randomcount, printResults, printPassFail);
-
-      else if (hashfilename)
-        err = hashfile(hashno, hashfilename, extrabits,
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 101]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-                       numberExtrabits, 0,
-                       (const unsigned char *)hmacKey, hmaclen,
-                       resultstr, hashes[hashno].hashsize,
-                       printResults, printPassFail);
-
-      else if (hashFilename)
-        err = hashfile(hashno, hashFilename, extrabits,
-                       numberExtrabits, 1,
-                       (const unsigned char *)hmacKey, hmaclen,
-                       resultstr, hashes[hashno].hashsize,
-                       printResults, printPassFail);
-
-      else /* standard tests */ {
-        for (testno = testnolow;
-             (testno <= testnohigh) && (err == shaSuccess); ++testno) {
-          if (runHmacTests) {
-            err = hash(testno, loopno, hashno,
-                       hmachashes[testno].dataarray[hashno] ?
-                       hmachashes[testno].dataarray[hashno] :
-                       hmachashes[testno].dataarray[1] ?
-                       hmachashes[testno].dataarray[1] :
-                       hmachashes[testno].dataarray[0],
-                       hmachashes[testno].datalength[hashno] ?
-                       hmachashes[testno].datalength[hashno] :
-                       hmachashes[testno].datalength[1] ?
-                       hmachashes[testno].datalength[1] :
-                       hmachashes[testno].datalength[0],
-                       1, 0, 0,
-                       (const unsigned char *)(
-                        hmachashes[testno].keyarray[hashno] ?
-                        hmachashes[testno].keyarray[hashno] :
-                        hmachashes[testno].keyarray[1] ?
-                        hmachashes[testno].keyarray[1] :
-                        hmachashes[testno].keyarray[0]),
-                       hmachashes[testno].keylength[hashno] ?
-                       hmachashes[testno].keylength[hashno] :
-                       hmachashes[testno].keylength[1] ?
-                       hmachashes[testno].keylength[1] :
-                       hmachashes[testno].keylength[0],
-                       hmachashes[testno].resultarray[hashno],
-                       hmachashes[testno].resultlength[hashno],
-                       printResults, printPassFail);
-          } else {
-            err = hash(testno, loopno, hashno,
-                       hashes[hashno].tests[testno].testarray,
-                       hashes[hashno].tests[testno].length,
-                       hashes[hashno].tests[testno].repeatcount,
-                       hashes[hashno].tests[testno].numberExtrabits,
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 102]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-                       hashes[hashno].tests[testno].extrabits, 0, 0,
-                       hashes[hashno].tests[testno].resultarray,
-                       hashes[hashno].hashsize,
-                       printResults, printPassFail);
-          }
-        }
-
-        if (!runHmacTests) {
-          randomtest(hashno, hashes[hashno].randomtest,
-            hashes[hashno].hashsize, hashes[hashno].randomresults,
-            RANDOMCOUNT, printResults, printPassFail);
-        }
-      }
-    }
-  }
-
-  /* Test some error returns */
-  if (checkErrors) {
-    testErrors(hashnolow, hashnohigh, printResults, printPassFail);
-  }
-
-  return 0;
-}
-
-/*
- * Compare two strings, case independently.
- * Equivalent to strcasecmp() found on some systems.
- */
-int scasecmp(const char *s1, const char *s2)
-{
-  for (;;) {
-    char u1 = tolower(*s1++);
-    char u2 = tolower(*s2++);
-    if (u1 != u2)
-      return u1 - u2;
-    if (u1 == '\0')
-      return 0;
-   }
-}
-
-/*
- * This is a copy of getopt provided for those systems that do not
- * have it. The name was changed to xgetopt to not conflict on those
- * systems that do have it. Similarly, optarg, optind and opterr
- * were renamed to xoptarg, xoptind and xopterr.
- *
- * Copyright 1990, 1991, 1992 by the Massachusetts Institute of
- * Technology and UniSoft Group Limited.
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 103]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- * Permission to use, copy, modify, distribute, and sell this software
- * and its documentation for any purpose is hereby granted without fee,
- * provided that the above copyright notice appear in all copies and
- * that both that copyright notice and this permission notice appear in
- * supporting documentation, and that the names of MIT and UniSoft not
- * be used in advertising or publicity pertaining to distribution of
- * the software without specific, written prior permission.  MIT and
- * UniSoft make no representations about the suitability of this
- * software for any purpose.  It is provided "as is" without express
- * or implied warranty.
- *
- * $XConsortium: getopt.c,v 1.2 92/07/01 11:59:04 rws Exp $
- * NB: Reformatted to match above style.
- */
-
-char    *xoptarg;
-int     xoptind = 1;
-int     xopterr = 1;
-
-static int xgetopt(int argc, char **argv, const char *optstring)
-{
-  static int avplace;
-  char    *ap;
-  char    *cp;
-  int     c;
-
-  if (xoptind >= argc)
-    return EOF;
-
-  ap = argv[xoptind] + avplace;
-
-  /* At beginning of arg but not an option */
-  if (avplace == 0) {
-    if (ap[0] != '-')
-      return EOF;
-    else if (ap[1] == '-') {
-      /* Special end of options option */
-      xoptind++;
-      return EOF;
-    } else if (ap[1] == '\0')
-      return EOF;  /* single '-' is not allowed */
-  }
-
-  /* Get next letter */
-  avplace++;
-  c = *++ap;
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 104]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  cp = strchr(optstring, c);
-  if (cp == NULL || c == ':') {
-    if (xopterr)
-      fprintf(stderr, "Unrecognised option -- %c\n", c);
-    return '?';
-  }
-
-  if (cp[1] == ':') {
-    /* There should be an option arg */
-    avplace = 0;
-    if (ap[1] == '\0') {
-      /* It is a separate arg */
-      if (++xoptind >= argc) {
-        if (xopterr)
-          fprintf(stderr, "Option requires an argument\n");
-        return '?';
-      }
-      xoptarg = argv[xoptind++];
-    } else {
-      /* is attached to option letter */
-      xoptarg = ap + 1;
-      ++xoptind;
-    }
-  } else {
-    /* If we are out of letters then go to next arg */
-    if (ap[1] == '\0') {
-      ++xoptind;
-      avplace = 0;
-    }
-
-    xoptarg = NULL;
-  }
-  return c;
-}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 105]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-9.  Security Considerations
-
-   This document is intended to provides the Internet community
-   convenient access to source code that implements the United States of
-   America Federal Information Processing Standard Secure Hash
-   Algorithms (SHAs) [FIPS180-2] and HMACs based upon these one-way hash
-   functions.  See license in Section 1.1.  No independent assertion of
-   the security of this hash function by the authors for any particular
-   use is intended.
-
-10.  Normative References
-
-   [FIPS180-2] "Secure Hash Standard", United States of America,
-               National Institute of Standards and Technology, Federal
-               Information Processing Standard (FIPS) 180-2,
-               http://csrc.nist.gov/publications/fips/fips180-2/
-               fips180-2withchangenotice.pdf.
-
-   [RFC2104]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-               Hashing for Message Authentication", RFC 2104, February
-               1997.
-
-11.  Informative References
-
-   [RFC2202]   Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
-               HMAC-SHA-1", RFC 2202, September 1997.
-
-   [RFC3174]   Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
-               1 (SHA1)", RFC 3174, September 2001.
-
-   [RFC3874]   Housley, R., "A 224-bit One-way Hash Function: SHA-224",
-               RFC 3874, September 2004.
-
-   [RFC4086]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-               "Randomness Requirements for Security", BCP 106, RFC
-               4086, June 2005.
-
-   [RFC4231]   Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
-               224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC
-               4231, December 2005.
-
-   [SHAVS]     "The Secure Hash Algorithm Validation System (SHAVS)",
-               http://csrc.nist.gov/cryptval/shs/SHAVS.pdf.
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 106]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-Authors' Addresses
-
-   Donald E. Eastlake, 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Phone: +1-508-786-7554 (w)
-   EMail: donald.eastlake@motorola.com
-
-
-   Tony Hansen
-   AT&T Laboratories
-   200 Laurel Ave.
-   Middletown, NJ 07748 USA
-
-   Phone: +1-732-420-8934 (w)
-   EMail: tony+shs@maillennium.att.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 107]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 108]
-
diff --git a/doc/rfc/rfc4635.txt b/doc/rfc/rfc4635.txt
deleted file mode 100644
index 554502dc..00000000
--- a/doc/rfc/rfc4635.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 4635                         Motorola Laboratories
-Category: Standards Track                                    August 2006
-
-
-                  HMAC SHA TSIG Algorithm Identifiers
-
-                          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
-
-   Use of the Domain Name System TSIG resource record requires
-   specification of a cryptographic message authentication code.
-   Currently, identifiers have been specified only for HMAC MD5 (Hashed
-   Message Authentication Code, Message Digest 5) and GSS (Generic
-   Security Service) TSIG algorithms.  This document standardizes
-   identifiers and implementation requirements for additional HMAC SHA
-   (Secure Hash Algorithm) TSIG algorithms and standardizes how to
-   specify and handle the truncation of HMAC values in TSIG.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Algorithms and Identifiers ......................................2
-   3. Specifying Truncation ...........................................3
-      3.1. Truncation Specification ...................................4
-   4. TSIG Truncation Policy and Error Provisions .....................4
-   5. IANA Considerations .............................................5
-   6. Security Considerations .........................................5
-   7. Normative References ............................................6
-   8. Informative References. .........................................7
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 1]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
-
-
-1.  Introduction
-
-   [RFC2845] specifies a TSIG Resource Record (RR) that can be used to
-   authenticate DNS (Domain Name System [STD13]) queries and responses.
-   This RR contains a domain name syntax data item that names the
-   authentication algorithm used.  [RFC2845] defines the
-   HMAC-MD5.SIG-ALG.REG.INT name for authentication codes using the HMAC
-   (Hashed Message Authentication Code) [RFC2104] algorithm with the MD5
-   (Message Digest 5) [RFC1321] hash algorithm.  IANA has also
-   registered "gss-tsig" as an identifier for TSIG authentication where
-   the cryptographic operations are delegated to the Generic Security
-   Service (GSS) [RFC3645].
-
-   Note that use of TSIG presumes prior agreement, between the resolver
-   and server involved, as to the algorithm and key to be used.
-
-   In Section 2, this document specifies additional names for TSIG
-   authentication algorithms based on US NIST SHA (United States,
-   National Institute of Science and Technology, Secure Hash Algorithm)
-   algorithms and HMAC and specifies the implementation requirements for
-   those algorithms.
-
-   In Section 3, this document specifies the effect of inequality
-   between the normal output size of the specified hash function and the
-   length of MAC (Message Authentication Code) data given in the TSIG
-   RR.  In particular, it specifies that a shorter-length field value
-   specifies truncation and that a longer-length field is an error.
-
-   In Section 4, policy restrictions and implications related to
-   truncation are described and specified, as is a new error code to
-   indicate truncation shorter than that permitted by policy.
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", in
-   this document are to be interpreted as described in [RFC2119].
-
-2.  Algorithms and Identifiers
-
-   TSIG Resource Records (RRs) [RFC2845] are used to authenticate DNS
-   queries and responses.  They are intended to be efficient symmetric
-   authentication codes based on a shared secret.  (Asymmetric
-   signatures can be provided using the SIG RR [RFC2931].  In
-   particular, SIG(0) can be used for transaction signatures.)  Used
-   with a strong hash function, HMAC [RFC2104] provides a way to
-   calculate such symmetric authentication codes.  The only specified
-   HMAC-based TSIG algorithm identifier has been HMAC-MD5.SIG-
-   ALG.REG.INT, based on MD5 [RFC1321].
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 2]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
-
-
-   The use of SHA-1 [FIPS180-2, RFC3174], which is a 160-bit hash, as
-   compared with the 128 bits for MD5, and additional hash algorithms in
-   the SHA family [FIPS180-2, RFC3874, RFC4634] with 224, 256, 384, and
-   512 bits may be preferred in some cases.  This is because
-   increasingly successful cryptanalytic attacks are being made on the
-   shorter hashes.
-
-   Use of TSIG between a DNS resolver and server is by mutual agreement.
-   That agreement can include the support of additional algorithms and
-   criteria as to which algorithms and truncations are acceptable,
-   subject to the restriction and guidelines in Sections 3 and 4 below.
-   Key agreement can be by the TKEY mechanism [RFC2930] or some other
-   mutually agreeable method.
-
-   The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
-   included in the table below for convenience.  Implementations that
-   support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
-   implement gss-tsig and the other algorithms listed below.
-
-      Mandatory      HMAC-MD5.SIG-ALG.REG.INT
-      Optional       gss-tsig
-      Mandatory      hmac-sha1
-      Optional       hmac-sha224
-      Mandatory      hmac-sha256
-      Optional       hamc-sha384
-      Optional       hmac-sha512
-
-   SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
-
-3.  Specifying Truncation
-
-   When space is at a premium and the strength of the full length of an
-   HMAC is not needed, it is reasonable to truncate the HMAC output and
-   use the truncated value for authentication.  HMAC SHA-1 truncated to
-   96 bits is an option available in several IETF protocols, including
-   IPsec and TLS.
-
-   The TSIG RR [RFC2845] includes a "MAC size" field, which gives the
-   size of the MAC field in octets.  However, [RFC2845] does not specify
-   what to do if this MAC size differs from the length of the output of
-   HMAC for a particular hash function.  Truncation is indicated by a
-   MAC size less than the HMAC size, as specified below.
-
-
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 3]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
-
-
-3.1.  Truncation Specification
-
-   The specification for TSIG handling is changed as follows:
-
-   1. If "MAC size" field is greater than HMAC output length:
-
-         This case MUST NOT be generated and, if received, MUST cause
-      the packet to be dropped and RCODE 1 (FORMERR) to be returned.
-
-   2. If "MAC size" field equals HMAC output length:
-
-         Operation is as described in [RFC2845], and the entire output
-      HMAC output is present.
-
-   3. "MAC size" field is less than HMAC output length but greater than
-      that specified in case 4, below:
-
-         This is sent when the signer has truncated the HMAC output to
-      an allowable length, as described in RFC 2104, taking initial
-      octets and discarding trailing octets.  TSIG truncation can only
-      be to an integral number of octets.  On receipt of a packet with
-      truncation thus indicated, the locally calculated MAC is similarly
-      truncated and only the truncated values are compared for
-      authentication.  The request MAC used when calculating the TSIG
-      MAC for a reply is the truncated request MAC.
-
-   4. "MAC size" field is less than the larger of 10 (octets) and half
-      the length of the hash function in use:
-
-         With the exception of certain TSIG error messages described in
-      RFC 2845, Section 3.2, where it is permitted that the MAC size be
-      zero, this case MUST NOT be generated and, if received, MUST cause
-      the packet to be dropped and RCODE 1 (FORMERR) to be returned.
-      The size limit for this case can also, for the hash functions
-      mentioned in this document, be stated as less than half the hash
-      function length for hash functions other than MD5 and less than 10
-      octets for MD5.
-
-4.  TSIG Truncation Policy and Error Provisions
-
-   Use of TSIG is by mutual agreement between a resolver and server.
-   Implicit in such "agreement" are criterion as to acceptable keys and
-   algorithms and, with the extensions in this document, truncations.
-   Note that it is common for implementations to bind the TSIG secret
-   key or keys that may be in place at a resolver and server to
-   particular algorithms.  Thus, such implementations only permit the
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 4]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
-
-
-   use of an algorithm if there is an associated key in place.  Receipt
-   of an unknown, unimplemented, or disabled algorithm typically results
-   in a BADKEY error.
-
-      Local policies MAY require the rejection of TSIGs, even though
-   they use an algorithm for which implementation is mandatory.
-
-      When a local policy permits acceptance of a TSIG with a particular
-   algorithm and a particular non-zero amount of truncation, it SHOULD
-   also permit the use of that algorithm with lesser truncation (a
-   longer MAC) up to the full HMAC output.
-
-      Regardless of a lower acceptable truncated MAC length specified by
-   local policy, a reply SHOULD be sent with a MAC at least as long as
-   that in the corresponding request, unless the request specified a MAC
-   length longer than the HMAC output.
-
-      Implementations permitting multiple acceptable algorithms and/or
-   truncations SHOULD permit this list to be ordered by presumed
-   strength and SHOULD allow different truncations for the same
-   algorithm to be treated as separate entities in this list.  When so
-   implemented, policies SHOULD accept a presumed stronger algorithm and
-   truncation than the minimum strength required by the policy.
-
-      If a TSIG is received with truncation that is permitted under
-   Section 3 above but the MAC is too short for the local policy in
-   force, an RCODE of 22 (BADTRUNC) MUST be returned.
-
-5.  IANA Considerations
-
-   This document (1) registers the new TSIG algorithm identifiers listed
-   in Section 2 with IANA and (2) allocates the BADTRUNC RCODE 22 in
-   Section 4 [RFC2845].
-
-6.  Security Considerations
-
-   For all of the message authentication code algorithms listed herein,
-   those producing longer values are believed to be stronger; however,
-   while there have been some arguments that mild truncation can
-   strengthen a MAC by reducing the information available to an
-   attacker, excessive truncation clearly weakens authentication by
-   reducing the number of bits an attacker has to try to break the
-   authentication by brute force [RFC2104].
-
-   Significant progress has been made recently in cryptanalysis of hash
-   function of the types used herein, all of which ultimately derive
-   from the design of MD4.  While the results so far should not effect
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 5]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
-
-
-   HMAC, the stronger SHA-1 and SHA-256 algorithms are being made
-   mandatory due to caution.
-
-   See the Security Considerations section of [RFC2845].  See also the
-   Security Considerations section of [RFC2104] from which the limits on
-   truncation in this RFC were taken.
-
-7.  Normative References
-
-   [FIPS180-2] "Secure Hash Standard", (SHA-1/224/256/384/512) US
-               Federal Information Processing Standard, with Change
-               Notice 1, February 2004.
-
-   [RFC1321]   Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
-               1321, April 1992.
-
-   [RFC2104]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
-               Keyed-Hashing 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.
-
-   [RFC2845]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-               Wellington, "Secret Key Transaction Authentication for
-               DNS (TSIG)", RFC 2845, May 2000.
-
-   [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.
-
-   [RFC4634]   Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
-               (SHA)", RFC 4634, July 2006.
-
-   [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.
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 6]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
-
-
-8.  Informative References.
-
-   [RFC2930]   Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
-               RR)", RFC 2930, September 2000.
-
-   [RFC2931]   Eastlake 3rd, D., "DNS Request and Transaction Signatures
-               ( SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC3645]   Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
-               and R. Hall, "Generic Security Service Algorithm for
-               Secret Key Transaction Authentication for DNS (GSS-
-               TSIG)", RFC 3645, October 2003.
-
-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 7]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 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 8]
-
diff --git a/doc/rfc/rfc4641.txt b/doc/rfc/rfc4641.txt
deleted file mode 100644
index 0a013bcb..00000000
--- a/doc/rfc/rfc4641.txt
+++ /dev/null
@@ -1,1963 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         O. Kolkman
-Request for Comments: 4641                                     R. Gieben
-Obsoletes: 2541                                               NLnet Labs
-Category: Informational                                   September 2006
-
-
-                      DNSSEC Operational Practices
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a set of practices for operating the DNS with
-   security extensions (DNSSEC).  The target audience is zone
-   administrators deploying DNSSEC.
-
-   The document discusses operational aspects of using keys and
-   signatures in the DNS.  It discusses issues of key generation, key
-   storage, signature generation, key rollover, and related policies.
-
-   This document obsoletes RFC 2541, as it covers more operational
-   ground and gives more up-to-date requirements with respect to key
-   sizes and the new DNSSEC specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 1]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-      1.1. The Use of the Term 'key' ..................................4
-      1.2. Time Definitions ...........................................4
-   2. Keeping the Chain of Trust Intact ...............................5
-   3. Keys Generation and Storage .....................................6
-      3.1. Zone and Key Signing Keys ..................................6
-           3.1.1. Motivations for the KSK and ZSK Separation ..........6
-           3.1.2. KSKs for High-Level Zones ...........................7
-      3.2. Key Generation .............................................8
-      3.3. Key Effectivity Period .....................................8
-      3.4. Key Algorithm ..............................................9
-      3.5. Key Sizes ..................................................9
-      3.6. Private Key Storage .......................................11
-   4. Signature Generation, Key Rollover, and Related Policies .......12
-      4.1. Time in DNSSEC ............................................12
-           4.1.1. Time Considerations ................................12
-      4.2. Key Rollovers .............................................14
-           4.2.1. Zone Signing Key Rollovers .........................14
-                  4.2.1.1. Pre-Publish Key Rollover ..................15
-                  4.2.1.2. Double Signature Zone Signing Key
-                           Rollover ..................................17
-                  4.2.1.3. Pros and Cons of the Schemes ..............18
-           4.2.2. Key Signing Key Rollovers ..........................18
-           4.2.3. Difference Between ZSK and KSK Rollovers ...........20
-           4.2.4. Automated Key Rollovers ............................21
-      4.3. Planning for Emergency Key Rollover .......................21
-           4.3.1. KSK Compromise .....................................22
-                  4.3.1.1. Keeping the Chain of Trust Intact .........22
-                  4.3.1.2. Breaking the Chain of Trust ...............23
-           4.3.2. ZSK Compromise .....................................23
-           4.3.3. Compromises of Keys Anchored in Resolvers ..........24
-      4.4. Parental Policies .........................................24
-           4.4.1. Initial Key Exchanges and Parental Policies
-                  Considerations .....................................24
-           4.4.2. Storing Keys or Hashes? ............................25
-           4.4.3. Security Lameness ..................................25
-           4.4.4. DS Signature Validity Period .......................26
-   5. Security Considerations ........................................26
-   6. Acknowledgments ................................................26
-   7. References .....................................................27
-      7.1. Normative References ......................................27
-      7.2. Informative References ....................................28
-   Appendix A. Terminology ...........................................30
-   Appendix B. Zone Signing Key Rollover How-To ......................31
-   Appendix C. Typographic Conventions ...............................32
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 2]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-1.  Introduction
-
-   This document describes how to run a DNS Security (DNSSEC)-enabled
-   environment.  It is intended for operators who have knowledge of the
-   DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC.
-   See RFC 4033 [4] for an introduction to DNSSEC, RFC 4034 [5] for the
-   newly introduced Resource Records (RRs), and RFC 4035 [6] for the
-   protocol changes.
-
-   During workshops and early operational deployment tests, operators
-   and system administrators have gained experience about operating the
-   DNS with security extensions (DNSSEC).  This document translates
-   these experiences into a set of practices for zone administrators.
-   At the time of writing, there exists very little experience with
-   DNSSEC in production environments; this document should therefore
-   explicitly not be seen as representing 'Best Current Practices'.
-
-   The procedures herein are focused on the maintenance of signed zones
-   (i.e., signing and publishing zones on authoritative servers).  It is
-   intended that maintenance of zones such as re-signing or key
-   rollovers be transparent to any verifying clients on the Internet.
-
-   The structure of this document is as follows.  In Section 2, we
-   discuss the importance of keeping the "chain of trust" intact.
-   Aspects of key generation and storage of private keys are discussed
-   in Section 3; the focus in this section is mainly on the private part
-   of the key(s).  Section 4 describes considerations concerning the
-   public part of the keys.  Since these public keys appear in the DNS
-   one has to take into account all kinds of timing issues, which are
-   discussed in Section 4.1.  Section 4.2 and Section 4.3 deal with the
-   rollover, or supercession, of keys.  Finally, Section 4.4 discusses
-   considerations on how parents deal with their children's public keys
-   in order to maintain chains of trust.
-
-   The typographic conventions used in this document are explained in
-   Appendix C.
-
-   Since this is a document with operational suggestions and there are
-   no protocol specifications, the RFC 2119 [7] language does not apply.
-
-   This document obsoletes RFC 2541 [12] to reflect the evolution of the
-   underlying DNSSEC protocol since then.  Changes in the choice of
-   cryptographic algorithms, DNS record types and type names, and the
-   parent-child key and signature exchange demanded a major rewrite and
-   additional information and explanation.
-
-
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 3]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-1.1.  The Use of the Term 'key'
-
-   It is assumed that the reader is familiar with the concept of
-   asymmetric keys on which DNSSEC is based (public key cryptography
-   [17]).  Therefore, this document will use the term 'key' rather
-   loosely.  Where it is written that 'a key is used to sign data' it is
-   assumed that the reader understands that it is the private part of
-   the key pair that is used for signing.  It is also assumed that the
-   reader understands that the public part of the key pair is published
-   in the DNSKEY Resource Record and that it is the public part that is
-   used in key exchanges.
-
-1.2.  Time Definitions
-
-   In this document, we will be using a number of time-related terms.
-   The following definitions apply:
-
-   o  "Signature validity period" The period that a signature is valid.
-      It starts at the time specified in the signature inception field
-      of the RRSIG RR and ends at the time specified in the expiration
-      field of the RRSIG RR.
-
-   o  "Signature publication period" Time after which a signature (made
-      with a specific key) is replaced with a new signature (made with
-      the same key).  This replacement takes place by publishing the
-      relevant RRSIG in the master zone file.  After one stops
-      publishing an RRSIG in a zone, it may take a while before the
-      RRSIG has expired from caches and has actually been removed from
-      the DNS.
-
-   o  "Key effectivity period" The period during which a key pair is
-      expected to be effective.  This period is defined as the time
-      between the first inception time stamp and the last expiration
-      date of any signature made with this key, regardless of any
-      discontinuity in the use of the key.  The key effectivity period
-      can span multiple signature validity periods.
-
-   o  "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum
-      value of the TTLs from the complete set of RRs in a zone.  Note
-      that the minimum TTL is not the same as the MINIMUM field in the
-      SOA RR.  See [11] for more information.
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 4]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-2.  Keeping the Chain of Trust Intact
-
-   Maintaining a valid chain of trust is important because broken chains
-   of trust will result in data being marked as Bogus (as defined in [4]
-   Section 5), which may cause entire (sub)domains to become invisible
-   to verifying clients.  The administrators of secured zones have to
-   realize that their zone is, to verifying clients, part of a chain of
-   trust.
-
-   As mentioned in the introduction, the procedures herein are intended
-   to ensure that maintenance of zones, such as re-signing or key
-   rollovers, will be transparent to the verifying clients on the
-   Internet.
-
-   Administrators of secured zones will have to keep in mind that data
-   published on an authoritative primary server will not be immediately
-   seen by verifying clients; it may take some time for the data to be
-   transferred to other secondary authoritative nameservers and clients
-   may be fetching data from caching non-authoritative servers.  In this
-   light, note that the time for a zone transfer from master to slave is
-   negligible when using NOTIFY [9] and incremental transfer (IXFR) [8].
-   It increases when full zone transfers (AXFR) are used in combination
-   with NOTIFY.  It increases even more if you rely on full zone
-   transfers based on only the SOA timing parameters for refresh.
-
-   For the verifying clients, it is important that data from secured
-   zones can be used to build chains of trust regardless of whether the
-   data came directly from an authoritative server, a caching
-   nameserver, or some middle box.  Only by carefully using the
-   available timing parameters can a zone administrator ensure that the
-   data necessary for verification can be obtained.
-
-   The responsibility for maintaining the chain of trust is shared by
-   administrators of secured zones in the chain of trust.  This is most
-   obvious in the case of a 'key compromise' when a trade-off between
-   maintaining a valid chain of trust and replacing the compromised keys
-   as soon as possible must be made.  Then zone administrators will have
-   to make a trade-off, between keeping the chain of trust intact --
-   thereby allowing for attacks with the compromised key -- or
-   deliberately breaking the chain of trust and making secured
-   subdomains invisible to security-aware resolvers.  Also see Section
-   4.3.
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 5]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-3.  Keys Generation and Storage
-
-   This section describes a number of considerations with respect to the
-   security of keys.  It deals with the generation, effectivity period,
-   size, and storage of private keys.
-
-3.1.  Zone and Key Signing Keys
-
-   The DNSSEC validation protocol does not distinguish between different
-   types of DNSKEYs.  All DNSKEYs can be used during the validation.  In
-   practice, operators use Key Signing and Zone Signing Keys and use the
-   so-called Secure Entry Point (SEP) [3] flag to distinguish between
-   them during operations.  The dynamics and considerations are
-   discussed below.
-
-   To make zone re-signing and key rollover procedures easier to
-   implement, it is possible to use one or more keys as Key Signing Keys
-   (KSKs).  These keys will only sign the apex DNSKEY RRSet in a zone.
-   Other keys can be used to sign all the RRSets in a zone and are
-   referred to as Zone Signing Keys (ZSKs).  In this document, we assume
-   that KSKs are the subset of keys that are used for key exchanges with
-   the parent and potentially for configuration as trusted anchors --
-   the SEP keys.  In this document, we assume a one-to-one mapping
-   between KSK and SEP keys and we assume the SEP flag to be set on all
-   KSKs.
-
-3.1.1.  Motivations for the KSK and ZSK Separation
-
-   Differentiating between the KSK and ZSK functions has several
-   advantages:
-
-   o  No parent/child interaction is required when ZSKs are updated.
-
-   o  The KSK can be made stronger (i.e., using more bits in the key
-      material).  This has little operational impact since it is only
-      used to sign a small fraction of the zone data.  Also, the KSK is
-      only used to verify the zone's key set, not for other RRSets in
-      the zone.
-
-   o  As the KSK is only used to sign a key set, which is most probably
-      updated less frequently than other data in the zone, it can be
-      stored separately from and in a safer location than the ZSK.
-
-   o  A KSK can have a longer key effectivity period.
-
-   For almost any method of key management and zone signing, the KSK is
-   used less frequently than the ZSK.  Once a key set is signed with the
-   KSK, all the keys in the key set can be used as ZSKs.  If a ZSK is
-
-
-
-Kolkman & Gieben             Informational                      [Page 6]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   compromised, it can be simply dropped from the key set.  The new key
-   set is then re-signed with the KSK.
-
-   Given the assumption that for KSKs the SEP flag is set, the KSK can
-   be distinguished from a ZSK by examining the flag field in the DNSKEY
-   RR.  If the flag field is an odd number it is a KSK.  If it is an
-   even number it is a ZSK.
-
-   The Zone Signing Key can be used to sign all the data in a zone on a
-   regular basis.  When a Zone Signing Key is to be rolled, no
-   interaction with the parent is needed.  This allows for signature
-   validity periods on the order of days.
-
-   The Key Signing Key is only to be used to sign the DNSKEY RRs in a
-   zone.  If a Key Signing Key is to be rolled over, there will be
-   interactions with parties other than the zone administrator.  These
-   can include the registry of the parent zone or administrators of
-   verifying resolvers that have the particular key configured as secure
-   entry points.  Hence, the key effectivity period of these keys can
-   and should be made much longer.  Although, given a long enough key,
-   the key effectivity period can be on the order of years, we suggest
-   planning for a key effectivity on the order of a few months so that a
-   key rollover remains an operational routine.
-
-3.1.2.  KSKs for High-Level Zones
-
-   Higher-level zones are generally more sensitive than lower-level
-   zones.  Anyone controlling or breaking the security of a zone thereby
-   obtains authority over all of its subdomains (except in the case of
-   resolvers that have locally configured the public key of a subdomain,
-   in which case this, and only this, subdomain wouldn't be affected by
-   the compromise of the parent zone).  Therefore, extra care should be
-   taken with high-level zones, and strong keys should be used.
-
-   The root zone is the most critical of all zones.  Someone controlling
-   or compromising the security of the root zone would control the
-   entire DNS namespace of all resolvers using that root zone (except in
-   the case of resolvers that have locally configured the public key of
-   a subdomain).  Therefore, the utmost care must be taken in the
-   securing of the root zone.  The strongest and most carefully handled
-   keys should be used.  The root zone private key should always be kept
-   off-line.
-
-   Many resolvers will start at a root server for their access to and
-   authentication of DNS data.  Securely updating the trust anchors in
-   an enormous population of resolvers around the world will be
-   extremely difficult.
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 7]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-3.2.  Key Generation
-
-   Careful generation of all keys is a sometimes overlooked but
-   absolutely essential element in any cryptographically secure system.
-   The strongest algorithms used with the longest keys are still of no
-   use if an adversary can guess enough to lower the size of the likely
-   key space so that it can be exhaustively searched.  Technical
-   suggestions for the generation of random keys will be found in RFC
-   4086 [14].  One should carefully assess if the random number
-   generator used during key generation adheres to these suggestions.
-
-   Keys with a long effectivity period are particularly sensitive as
-   they will represent a more valuable target and be subject to attack
-   for a longer time than short-period keys.  It is strongly recommended
-   that long-term key generation occur off-line in a manner isolated
-   from the network via an air gap or, at a minimum, high-level secure
-   hardware.
-
-3.3.  Key Effectivity Period
-
-   For various reasons, keys in DNSSEC need to be changed once in a
-   while.  The longer a key is in use, the greater the probability that
-   it will have been compromised through carelessness, accident,
-   espionage, or cryptanalysis.  Furthermore, when key rollovers are too
-   rare an event, they will not become part of the operational habit and
-   there is risk that nobody on-site will remember the procedure for
-   rollover when the need is there.
-
-   From a purely operational perspective, a reasonable key effectivity
-   period for Key Signing Keys is 13 months, with the intent to replace
-   them after 12 months.  An intended key effectivity period of a month
-   is reasonable for Zone Signing Keys.
-
-   For key sizes that match these effectivity periods, see Section 3.5.
-
-   As argued in Section 3.1.2, securely updating trust anchors will be
-   extremely difficult.  On the other hand, the "operational habit"
-   argument does also apply to trust anchor reconfiguration.  If a short
-   key effectivity period is used and the trust anchor configuration has
-   to be revisited on a regular basis, the odds that the configuration
-   tends to be forgotten is smaller.  The trade-off is against a system
-   that is so dynamic that administrators of the validating clients will
-   not be able to follow the modifications.
-
-   Key effectivity periods can be made very short, as in a few minutes.
-   But when replacing keys one has to take the considerations from
-   Section 4.1 and Section 4.2 into account.
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 8]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-3.4.  Key Algorithm
-
-   There are currently three different types of algorithms that can be
-   used in DNSSEC: RSA, DSA, and elliptic curve cryptography.  The
-   latter is fairly new and has yet to be standardized for usage in
-   DNSSEC.
-
-   RSA has been developed in an open and transparent manner.  As the
-   patent on RSA expired in 2000, its use is now also free.
-
-   DSA has been developed by the National Institute of Standards and
-   Technology (NIST).  The creation of signatures takes roughly the same
-   time as with RSA, but is 10 to 40 times as slow for verification
-   [17].
-
-   We suggest the use of RSA/SHA-1 as the preferred algorithm for the
-   key.  The current known attacks on RSA can be defeated by making your
-   key longer.  As the MD5 hashing algorithm is showing cracks, we
-   recommend the usage of SHA-1.
-
-   At the time of publication, it is known that the SHA-1 hash has
-   cryptanalysis issues.  There is work in progress on addressing these
-   issues.  We recommend the use of public key algorithms based on
-   hashes stronger than SHA-1 (e.g., SHA-256), as soon as these
-   algorithms are available in protocol specifications (see [19] and
-   [20]) and implementations.
-
-3.5.  Key Sizes
-
-   When choosing key sizes, zone administrators will need to take into
-   account how long a key will be used, how much data will be signed
-   during the key publication period (see Section 8.10 of [17]), and,
-   optionally, how large the key size of the parent is.  As the chain of
-   trust really is "a chain", there is not much sense in making one of
-   the keys in the chain several times larger then the others.  As
-   always, it's the weakest link that defines the strength of the entire
-   chain.  Also see Section 3.1.1 for a discussion of how keys serving
-   different roles (ZSK vs. KSK) may need different key sizes.
-
-   Generating a key of the correct size is a difficult problem; RFC 3766
-   [13] tries to deal with that problem.  The first part of the
-   selection procedure in Section 1 of the RFC states:
-
-      1. Determine the attack resistance necessary to satisfy the
-         security requirements of the application.  Do this by
-         estimating the minimum number of computer operations that the
-         attacker will be forced to do in order to compromise the
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 9]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-         security of the system and then take the logarithm base two of
-         that number.  Call that logarithm value "n".
-
-         A 1996 report recommended 90 bits as a good all-around choice
-         for system security.  The 90 bit number should be increased by
-         about 2/3 bit/year, or about 96 bits in 2005.
-
-   [13] goes on to explain how this number "n" can be used to calculate
-   the key sizes in public key cryptography.  This culminated in the
-   table given below (slightly modified for our purpose):
-
-      +-------------+-----------+--------------+
-      | System      |           |              |
-      | requirement | Symmetric | RSA or DSA   |
-      | for attack  | key size  | modulus size |
-      | resistance  | (bits)    | (bits)       |
-      | (bits)      |           |              |
-      +-------------+-----------+--------------+
-      |     70      |     70    |      947     |
-      |     80      |     80    |     1228     |
-      |     90      |     90    |     1553     |
-      |    100      |    100    |     1926     |
-      |    150      |    150    |     4575     |
-      |    200      |    200    |     8719     |
-      |    250      |    250    |    14596     |
-      +-------------+-----------+--------------+
-
-   The key sizes given are rather large.  This is because these keys are
-   resilient against a trillionaire attacker.  Assuming this rich
-   attacker will not attack your key and that the key is rolled over
-   once a year, we come to the following recommendations about KSK
-   sizes: 1024 bits for low-value domains, 1300 bits for medium-value
-   domains, and 2048 bits for high-value domains.
-
-   Whether a domain is of low, medium, or high value depends solely on
-   the views of the zone owner.  One could, for instance, view leaf
-   nodes in the DNS as of low value, and top-level domains (TLDs) or the
-   root zone of high value.  The suggested key sizes should be safe for
-   the next 5 years.
-
-   As ZSKs can be rolled over more easily (and thus more often), the key
-   sizes can be made smaller.  But as said in the introduction of this
-   paragraph, making the ZSKs' key sizes too small (in relation to the
-   KSKs' sizes) doesn't make much sense.  Try to limit the difference in
-   size to about 100 bits.
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 10]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   Note that nobody can see into the future and that these key sizes are
-   only provided here as a guide.  Further information can be found in
-   [16] and Section 7.5 of [17].  It should be noted though that [16] is
-   already considered overly optimistic about what key sizes are
-   considered safe.
-
-   One final note concerning key sizes.  Larger keys will increase the
-   sizes of the RRSIG and DNSKEY records and will therefore increase the
-   chance of DNS UDP packet overflow.  Also, the time it takes to
-   validate and create RRSIGs increases with larger keys, so don't
-   needlessly double your key sizes.
-
-3.6.  Private Key Storage
-
-   It is recommended that, where possible, zone private keys and the
-   zone file master copy that is to be signed be kept and used in off-
-   line, non-network-connected, physically secure machines only.
-   Periodically, an application can be run to add authentication to a
-   zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
-   transferred.
-
-   When relying on dynamic update to manage a signed zone [10], be aware
-   that at least one private key of the zone will have to reside on the
-   master server.  This key is only as secure as the amount of exposure
-   the server receives to unknown clients and the security of the host.
-   Although not mandatory, one could administer the DNS in the following
-   way.  The master that processes the dynamic updates is unavailable
-   from generic hosts on the Internet, it is not listed in the NS RR
-   set, although its name appears in the SOA RRs MNAME field.  The
-   nameservers in the NS RRSet are able to receive zone updates through
-   NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism.  This
-   approach is known as the "hidden master" setup.
-
-   The ideal situation is to have a one-way information flow to the
-   network to avoid the possibility of tampering from the network.
-   Keeping the zone master file on-line on the network and simply
-   cycling it through an off-line signer does not do this.  The on-line
-   version could still be tampered with if the host it resides on is
-   compromised.  For maximum security, the master copy of the zone file
-   should be off-net and should not be updated based on an unsecured
-   network mediated communication.
-
-   In general, keeping a zone file off-line will not be practical and
-   the machines on which zone files are maintained will be connected to
-   a network.  Operators are advised to take security measures to shield
-   unauthorized access to the master copy.
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 11]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   For dynamically updated secured zones [10], both the master copy and
-   the private key that is used to update signatures on updated RRs will
-   need to be on-line.
-
-4.  Signature Generation, Key Rollover, and Related Policies
-
-4.1.  Time in DNSSEC
-
-   Without DNSSEC, all times in the DNS are relative.  The SOA fields
-   REFRESH, RETRY, and EXPIRATION are timers used to determine the time
-   elapsed after a slave server synchronized with a master server.  The
-   Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
-   are used to determine how long a forwarder should cache data after it
-   has been fetched from an authoritative server.  By using a signature
-   validity period, DNSSEC introduces the notion of an absolute time in
-   the DNS.  Signatures in DNSSEC have an expiration date after which
-   the signature is marked as invalid and the signed data is to be
-   considered Bogus.
-
-4.1.1.  Time Considerations
-
-   Because of the expiration of signatures, one should consider the
-   following:
-
-   o  We suggest the Maximum Zone TTL of your zone data to be a fraction
-      of your signature validity period.
-
-         If the TTL would be of similar order as the signature validity
-         period, then all RRSets fetched during the validity period
-         would be cached until the signature expiration time.  Section
-         7.1 of [4] suggests that "the resolver may use the time
-         remaining before expiration of the signature validity period of
-         a signed RRSet as an upper bound for the TTL".  As a result,
-         query load on authoritative servers would peak at signature
-         expiration time, as this is also the time at which records
-         simultaneously expire from caches.
-
-         To avoid query load peaks, we suggest the TTL on all the RRs in
-         your zone to be at least a few times smaller than your
-         signature validity period.
-
-   o  We suggest the signature publication period to end at least one
-      Maximum Zone TTL duration before the end of the signature validity
-      period.
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 12]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-         Re-signing a zone shortly before the end of the signature
-         validity period may cause simultaneous expiration of data from
-         caches.  This in turn may lead to peaks in the load on
-         authoritative servers.
-
-   o  We suggest the Minimum Zone TTL to be long enough to both fetch
-      and verify all the RRs in the trust chain.  In workshop
-      environments, it has been demonstrated [18] that a low TTL (under
-      5 to 10 minutes) caused disruptions because of the following two
-      problems:
-
-         1.  During validation, some data may expire before the
-             validation is complete.  The validator should be able to
-             keep all data until it is completed.  This applies to all
-             RRs needed to complete the chain of trust: DSes, DNSKEYs,
-             RRSIGs, and the final answers, i.e., the RRSet that is
-             returned for the initial query.
-
-         2.  Frequent verification causes load on recursive nameservers.
-             Data at delegation points, DSes, DNSKEYs, and RRSIGs
-             benefit from caching.  The TTL on those should be
-             relatively long.
-
-   o  Slave servers will need to be able to fetch newly signed zones
-      well before the RRSIGs in the zone served by the slave server pass
-      their signature expiration time.
-
-         When a slave server is out of sync with its master and data in
-         a zone is signed by expired signatures, it may be better for
-         the slave server not to give out any answer.
-
-         Normally, a slave server that is not able to contact a master
-         server for an extended period will expire a zone.  When that
-         happens, the server will respond differently to queries for
-         that zone.  Some servers issue SERVFAIL, whereas others turn
-         off the 'AA' bit in the answers.  The time of expiration is set
-         in the SOA record and is relative to the last successful
-         refresh between the master and the slave servers.  There exists
-         no coupling between the signature expiration of RRSIGs in the
-         zone and the expire parameter in the SOA.
-
-         If the server serves a DNSSEC zone, then it may well happen
-         that the signatures expire well before the SOA expiration timer
-         counts down to zero.  It is not possible to completely prevent
-         this from happening by tweaking the SOA parameters.  However,
-         the effects can be minimized where the SOA expiration time is
-         equal to or shorter than the signature validity period.  The
-         consequence of an authoritative server not being able to update
-
-
-
-Kolkman & Gieben             Informational                     [Page 13]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-         a zone, whilst that zone includes expired signatures, is that
-         non-secure resolvers will continue to be able to resolve data
-         served by the particular slave servers while security-aware
-         resolvers will experience problems because of answers being
-         marked as Bogus.
-
-         We suggest the SOA expiration timer being approximately one
-         third or one fourth of the signature validity period.  It will
-         allow problems with transfers from the master server to be
-         noticed before the actual signature times out.  We also suggest
-         that operators of nameservers that supply secondary services
-         develop 'watch dogs' to spot upcoming signature expirations in
-         zones they slave, and take appropriate action.
-
-         When determining the value for the expiration parameter one has
-         to take the following into account: What are the chances that
-         all my secondaries expire the zone? How quickly can I reach an
-         administrator of secondary servers to load a valid zone?  These
-         questions are not DNSSEC specific but may influence the choice
-         of your signature validity intervals.
-
-4.2.  Key Rollovers
-
-   A DNSSEC key cannot be used forever (see Section 3.3).  So key
-   rollovers -- or supercessions, as they are sometimes called -- are a
-   fact of life when using DNSSEC.  Zone administrators who are in the
-   process of rolling their keys have to take into account that data
-   published in previous versions of their zone still lives in caches.
-   When deploying DNSSEC, this becomes an important consideration;
-   ignoring data that may be in caches may lead to loss of service for
-   clients.
-
-   The most pressing example of this occurs when zone material signed
-   with an old key is being validated by a resolver that does not have
-   the old zone key cached.  If the old key is no longer present in the
-   current zone, this validation fails, marking the data "Bogus".
-   Alternatively, an attempt could be made to validate data that is
-   signed with a new key against an old key that lives in a local cache,
-   also resulting in data being marked "Bogus".
-
-4.2.1.  Zone Signing Key Rollovers
-
-   For "Zone Signing Key rollovers", there are two ways to make sure
-   that during the rollover data still cached can be verified with the
-   new key sets or newly generated signatures can be verified with the
-   keys still in caches.  One schema, described in Section 4.2.1.2, uses
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 14]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   double signatures; the other uses key pre-publication (Section
-   4.2.1.1).  The pros, cons, and recommendations are described in
-   Section 4.2.1.3.
-
-4.2.1.1.  Pre-Publish Key Rollover
-
-   This section shows how to perform a ZSK rollover without the need to
-   sign all the data in a zone twice -- the "pre-publish key rollover".
-   This method has advantages in the case of a key compromise.  If the
-   old key is compromised, the new key has already been distributed in
-   the DNS.  The zone administrator is then able to quickly switch to
-   the new key and remove the compromised key from the zone.  Another
-   major advantage is that the zone size does not double, as is the case
-   with the double signature ZSK rollover.  A small "how-to" for this
-   kind of rollover can be found in Appendix B.
-
-   Pre-publish key rollover involves four stages as follows:
-
-      ----------------------------------------------------------------
-      initial         new DNSKEY       new RRSIGs      DNSKEY removal
-      ----------------------------------------------------------------
-      SOA0            SOA1             SOA2            SOA3
-      RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)
-
-      DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1
-      DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11
-      DNSKEY11         DNSKEY11
-      RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)
-      RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)
-      ----------------------------------------------------------------
-
-                         Pre-Publish Key Rollover
-
-   initial: Initial version of the zone: DNSKEY 1 is the Key Signing
-      Key.  DNSKEY 10 is used to sign all the data of the zone, the Zone
-      Signing Key.
-
-   new DNSKEY: DNSKEY 11 is introduced into the key set.  Note that no
-      signatures are generated with this key yet, but this does not
-      secure against brute force attacks on the public key.  The minimum
-      duration of this pre-roll phase is the time it takes for the data
-      to propagate to the authoritative servers plus TTL value of the
-      key set.
-
-   new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is
-      used to sign the data in the zone exclusively (i.e., all the
-      signatures from DNSKEY 10 are removed from the zone).  DNSKEY 10
-      remains published in the key set.  This way data that was loaded
-
-
-
-Kolkman & Gieben             Informational                     [Page 15]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-      into caches from version 1 of the zone can still be verified with
-      key sets fetched from version 2 of the zone.  The minimum time
-      that the key set including DNSKEY 10 is to be published is the
-      time that it takes for zone data from the previous version of the
-      zone to expire from old caches, i.e., the time it takes for this
-      zone to propagate to all authoritative servers plus the Maximum
-      Zone TTL value of any of the data in the previous version of the
-      zone.
-
-   DNSKEY removal: DNSKEY 10 is removed from the zone.  The key set, now
-      only containing DNSKEY 1 and DNSKEY 11, is re-signed with the
-      DNSKEY 1.
-
-   The above scheme can be simplified by always publishing the "future"
-   key immediately after the rollover.  The scheme would look as follows
-   (we show two rollovers); the future key is introduced in "new DNSKEY"
-   as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
-   (II)":
-
-      ----------------------------------------------------------------
-      initial             new RRSIGs          new DNSKEY
-      ----------------------------------------------------------------
-      SOA0                SOA1                SOA2
-      RRSIG10(SOA0)       RRSIG11(SOA1)       RRSIG11(SOA2)
-
-      DNSKEY1             DNSKEY1             DNSKEY1
-      DNSKEY10            DNSKEY10            DNSKEY11
-      DNSKEY11            DNSKEY11            DNSKEY12
-      RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
-      RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)
-      ----------------------------------------------------------------
-
-      ----------------------------------------------------------------
-      new RRSIGs (II)     new DNSKEY (II)
-      ----------------------------------------------------------------
-      SOA3                SOA4
-      RRSIG12(SOA3)       RRSIG12(SOA4)
-
-      DNSKEY1             DNSKEY1
-      DNSKEY11            DNSKEY12
-      DNSKEY12            DNSKEY13
-      RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
-      RRSIG12(DNSKEY)     RRSIG12(DNSKEY)
-      ----------------------------------------------------------------
-
-              Pre-Publish Key Rollover, Showing Two Rollovers
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 16]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   Note that the key introduced in the "new DNSKEY" phase is not used
-   for production yet; the private key can thus be stored in a
-   physically secure manner and does not need to be 'fetched' every time
-   a zone needs to be signed.
-
-4.2.1.2.  Double Signature Zone Signing Key Rollover
-
-   This section shows how to perform a ZSK key rollover using the double
-   zone data signature scheme, aptly named "double signature rollover".
-
-   During the "new DNSKEY" stage the new version of the zone file will
-   need to propagate to all authoritative servers and the data that
-   exists in (distant) caches will need to expire, requiring at least
-   the Maximum Zone TTL.
-
-   Double signature ZSK rollover involves three stages as follows:
-
-      ----------------------------------------------------------------
-      initial             new DNSKEY         DNSKEY removal
-      ----------------------------------------------------------------
-      SOA0                SOA1               SOA2
-      RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
-      RRSIG11(SOA1)
-
-      DNSKEY1             DNSKEY1            DNSKEY1
-      DNSKEY10            DNSKEY10           DNSKEY11
-      DNSKEY11
-      RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
-      RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
-      RRSIG11(DNSKEY)
-      ----------------------------------------------------------------
-
-                Double Signature Zone Signing Key Rollover
-
-   initial: Initial Version of the zone: DNSKEY 1 is the Key Signing
-      Key.  DNSKEY 10 is used to sign all the data of the zone, the Zone
-      Signing Key.
-
-   new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
-      introduced into the key set and all the data in the zone is signed
-      with DNSKEY 10 and DNSKEY 11.  The rollover period will need to
-      continue until all data from version 0 of the zone has expired
-      from remote caches.  This will take at least the Maximum Zone TTL
-      of version 0 of the zone.
-
-   DNSKEY removal: DNSKEY 10 is removed from the zone.  All the
-      signatures from DNSKEY 10 are removed from the zone.  The key set,
-      now only containing DNSKEY 11, is re-signed with DNSKEY 1.
-
-
-
-Kolkman & Gieben             Informational                     [Page 17]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   At every instance, RRSIGs from the previous version of the zone can
-   be verified with the DNSKEY RRSet from the current version and the
-   other way around.  The data from the current version can be verified
-   with the data from the previous version of the zone.  The duration of
-   the "new DNSKEY" phase and the period between rollovers should be at
-   least the Maximum Zone TTL.
-
-   Making sure that the "new DNSKEY" phase lasts until the signature
-   expiration time of the data in initial version of the zone is
-   recommended.  This way all caches are cleared of the old signatures.
-   However, this duration could be considerably longer than the Maximum
-   Zone TTL, making the rollover a lengthy procedure.
-
-   Note that in this example we assumed that the zone was not modified
-   during the rollover.  New data can be introduced in the zone as long
-   as it is signed with both keys.
-
-4.2.1.3.  Pros and Cons of the Schemes
-
-   Pre-publish key rollover: This rollover does not involve signing the
-      zone data twice.  Instead, before the actual rollover, the new key
-      is published in the key set and thus is available for
-      cryptanalysis attacks.  A small disadvantage is that this process
-      requires four steps.  Also the pre-publish scheme involves more
-      parental work when used for KSK rollovers as explained in Section
-      4.2.3.
-
-   Double signature ZSK rollover: The drawback of this signing scheme is
-      that during the rollover the number of signatures in your zone
-      doubles; this may be prohibitive if you have very big zones.  An
-      advantage is that it only requires three steps.
-
-4.2.2.  Key Signing Key Rollovers
-
-   For the rollover of a Key Signing Key, the same considerations as for
-   the rollover of a Zone Signing Key apply.  However, we can use a
-   double signature scheme to guarantee that old data (only the apex key
-   set) in caches can be verified with a new key set and vice versa.
-   Since only the key set is signed with a KSK, zone size considerations
-   do not apply.
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 18]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   --------------------------------------------------------------------
-       initial        new DNSKEY        DS change       DNSKEY removal
-   --------------------------------------------------------------------
-     Parent:
-       SOA0           -------->         SOA1            -------->
-       RRSIGpar(SOA0) -------->         RRSIGpar(SOA1)  -------->
-       DS1            -------->         DS2             -------->
-       RRSIGpar(DS)   -------->         RRSIGpar(DS)    -------->
-
-
-     Child:
-       SOA0            SOA1             -------->       SOA2
-       RRSIG10(SOA0)   RRSIG10(SOA1)    -------->       RRSIG10(SOA2)
-                                        -------->
-       DNSKEY1         DNSKEY1          -------->       DNSKEY2
-                       DNSKEY2          -------->
-       DNSKEY10        DNSKEY10         -------->       DNSKEY10
-       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  -------->       RRSIG2 (DNSKEY)
-                       RRSIG2 (DNSKEY)  -------->
-       RRSIG10(DNSKEY) RRSIG10(DNSKEY)  -------->       RRSIG10(DNSKEY)
-   --------------------------------------------------------------------
-
-   Stages of Deployment for a Double Signature Key Signing Key Rollover
-
-   initial: Initial version of the zone.  The parental DS points to
-      DNSKEY1.  Before the rollover starts, the child will have to
-      verify what the TTL is of the DS RR that points to DNSKEY1 -- it
-      is needed during the rollover and we refer to the value as TTL_DS.
-
-   new DNSKEY: During the "new DNSKEY" phase, the zone administrator
-      generates a second KSK, DNSKEY2.  The key is provided to the
-      parent, and the child will have to wait until a new DS RR has been
-      generated that points to DNSKEY2.  After that DS RR has been
-      published on all servers authoritative for the parent's zone, the
-      zone administrator has to wait at least TTL_DS to make sure that
-      the old DS RR has expired from caches.
-
-   DS change: The parent replaces DS1 with DS2.
-
-   DNSKEY removal: DNSKEY1 has been removed.
-
-   The scenario above puts the responsibility for maintaining a valid
-   chain of trust with the child.  It also is based on the premise that
-   the parent only has one DS RR (per algorithm) per zone.  An
-   alternative mechanism has been considered.  Using an established
-   trust relation, the interaction can be performed in-band, and the
-   removal of the keys by the child can possibly be signaled by the
-   parent.  In this mechanism, there are periods where there are two DS
-
-
-
-Kolkman & Gieben             Informational                     [Page 19]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   RRs at the parent.  Since at the moment of writing the protocol for
-   this interaction has not been developed, further discussion is out of
-   scope for this document.
-
-4.2.3.  Difference Between ZSK and KSK Rollovers
-
-   Note that KSK rollovers and ZSK rollovers are different in the sense
-   that a KSK rollover requires interaction with the parent (and
-   possibly replacing of trust anchors) and the ensuing delay while
-   waiting for it.
-
-   A zone key rollover can be handled in two different ways: pre-publish
-   (Section 4.2.1.1) and double signature (Section 4.2.1.2).
-
-   As the KSK is used to validate the key set and because the KSK is not
-   changed during a ZSK rollover, a cache is able to validate the new
-   key set of the zone.  The pre-publish method would also work for a
-   KSK rollover.  The records that are to be pre-published are the
-   parental DS RRs.  The pre-publish method has some drawbacks for KSKs.
-   We first describe the rollover scheme and then indicate these
-   drawbacks.
-
-   --------------------------------------------------------------------
-     initial         new DS           new DNSKEY      DS/DNSKEY removal
-   --------------------------------------------------------------------
-   Parent:
-     SOA0            SOA1             -------->       SOA2
-     RRSIGpar(SOA0)  RRSIGpar(SOA1)   -------->       RRSIGpar(SOA2)
-     DS1             DS1              -------->       DS2
-                     DS2              -------->
-     RRSIGpar(DS)    RRSIGpar(DS)     -------->       RRSIGpar(DS)
-
-
-   Child:
-     SOA0            -------->        SOA1            SOA1
-     RRSIG10(SOA0)   -------->        RRSIG10(SOA1)   RRSIG10(SOA1)
-                     -------->
-     DNSKEY1         -------->        DNSKEY2         DNSKEY2
-                     -------->
-     DNSKEY10        -------->        DNSKEY10        DNSKEY10
-     RRSIG1 (DNSKEY) -------->        RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
-     RRSIG10(DNSKEY) -------->        RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-   --------------------------------------------------------------------
-
-      Stages of Deployment for a Pre-Publish Key Signing Key Rollover
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 20]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   When the child zone wants to roll, it notifies the parent during the
-   "new DS" phase and submits the new key (or the corresponding DS) to
-   the parent.  The parent publishes DS1 and DS2, pointing to DNSKEY1
-   and DNSKEY2, respectively.  During the rollover ("new DNSKEY" phase),
-   which can take place as soon as the new DS set propagated through the
-   DNS, the child replaces DNSKEY1 with DNSKEY2.  Immediately after that
-   ("DS/DNSKEY removal" phase), it can notify the parent that the old DS
-   record can be deleted.
-
-   The drawbacks of this scheme are that during the "new DS" phase the
-   parent cannot verify the match between the DS2 RR and DNSKEY2 using
-   the DNS -- as DNSKEY2 is not yet published.  Besides, we introduce a
-   "security lame" key (see Section 4.4.3).  Finally, the child-parent
-   interaction consists of two steps.  The "double signature" method
-   only needs one interaction.
-
-4.2.4.  Automated Key Rollovers
-
-   As keys must be renewed periodically, there is some motivation to
-   automate the rollover process.  Consider the following:
-
-   o  ZSK rollovers are easy to automate as only the child zone is
-      involved.
-
-   o  A KSK rollover needs interaction between parent and child.  Data
-      exchange is needed to provide the new keys to the parent;
-      consequently, this data must be authenticated and integrity must
-      be guaranteed in order to avoid attacks on the rollover.
-
-4.3.  Planning for Emergency Key Rollover
-
-   This section deals with preparation for a possible key compromise.
-   Our advice is to have a documented procedure ready for when a key
-   compromise is suspected or confirmed.
-
-   When the private material of one of your keys is compromised it can
-   be used for as long as a valid trust chain exists.  A trust chain
-   remains intact for
-
-   o  as long as a signature over the compromised key in the trust chain
-      is valid,
-
-   o  as long as a parental DS RR (and signature) points to the
-      compromised key,
-
-   o  as long as the key is anchored in a resolver and is used as a
-      starting point for validation (this is generally the hardest to
-      update).
-
-
-
-Kolkman & Gieben             Informational                     [Page 21]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   While a trust chain to your compromised key exists, your namespace is
-   vulnerable to abuse by anyone who has obtained illegitimate
-   possession of the key.  Zone operators have to make a trade-off if
-   the abuse of the compromised key is worse than having data in caches
-   that cannot be validated.  If the zone operator chooses to break the
-   trust chain to the compromised key, data in caches signed with this
-   key cannot be validated.  However, if the zone administrator chooses
-   to take the path of a regular rollover, the malicious key holder can
-   spoof data so that it appears to be valid.
-
-4.3.1.  KSK Compromise
-
-   A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
-   as long as the compromised KSK is configured as trust anchor or a
-   parental DS points to it.
-
-   A compromised KSK can be used to sign the key set of an attacker's
-   zone.  That zone could be used to poison the DNS.
-
-   Therefore, when the KSK has been compromised, the trust anchor or the
-   parental DS should be replaced as soon as possible.  It is local
-   policy whether to break the trust chain during the emergency
-   rollover.  The trust chain would be broken when the compromised KSK
-   is removed from the child's zone while the parent still has a DS
-   pointing to the compromised KSK (the assumption is that there is only
-   one DS at the parent.  If there are multiple DSes this does not apply
-   -- however the chain of trust of this particular key is broken).
-
-   Note that an attacker's zone still uses the compromised KSK and the
-   presence of a parental DS would cause the data in this zone to appear
-   as valid.  Removing the compromised key would cause the attacker's
-   zone to appear as valid and the child's zone as Bogus.  Therefore, we
-   advise not to remove the KSK before the parent has a DS to a new KSK
-   in place.
-
-4.3.1.1.  Keeping the Chain of Trust Intact
-
-   If we follow this advice, the timing of the replacement of the KSK is
-   somewhat critical.  The goal is to remove the compromised KSK as soon
-   as the new DS RR is available at the parent.  And also make sure that
-   the signature made with a new KSK over the key set with the
-   compromised KSK in it expires just after the new DS appears at the
-   parent, thus removing the old cruft in one swoop.
-
-   The procedure is as follows:
-
-   1.  Introduce a new KSK into the key set, keep the compromised KSK in
-       the key set.
-
-
-
-Kolkman & Gieben             Informational                     [Page 22]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   2.  Sign the key set, with a short validity period.  The validity
-       period should expire shortly after the DS is expected to appear
-       in the parent and the old DSes have expired from caches.
-
-   3.  Upload the DS for this new key to the parent.
-
-   4.  Follow the procedure of the regular KSK rollover: Wait for the DS
-       to appear in the authoritative servers and then wait as long as
-       the TTL of the old DS RRs.  If necessary re-sign the DNSKEY RRSet
-       and modify/extend the expiration time.
-
-   5.  Remove the compromised DNSKEY RR from the zone and re-sign the
-       key set using your "normal" validity interval.
-
-   An additional danger of a key compromise is that the compromised key
-   could be used to facilitate a legitimate DNSKEY/DS rollover and/or
-   nameserver changes at the parent.  When that happens, the domain may
-   be in dispute.  An authenticated out-of-band and secure notify
-   mechanism to contact a parent is needed in this case.
-
-   Note that this is only a problem when the DNSKEY and or DS records
-   are used for authentication at the parent.
-
-4.3.1.2.  Breaking the Chain of Trust
-
-   There are two methods to break the chain of trust.  The first method
-   causes the child zone to appear 'Bogus' to validating resolvers.  The
-   other causes the child zone to appear 'insecure'.  These are
-   described below.
-
-   In the method that causes the child zone to appear 'Bogus' to
-   validating resolvers, the child zone replaces the current KSK with a
-   new one and re-signs the key set.  Next it sends the DS of the new
-   key to the parent.  Only after the parent has placed the new DS in
-   the zone is the child's chain of trust repaired.
-
-   An alternative method of breaking the chain of trust is by removing
-   the DS RRs from the parent zone altogether.  As a result, the child
-   zone would become insecure.
-
-4.3.2.  ZSK Compromise
-
-   Primarily because there is no parental interaction required when a
-   ZSK is compromised, the situation is less severe than with a KSK
-   compromise.  The zone must still be re-signed with a new ZSK as soon
-   as possible.  As this is a local operation and requires no
-   communication between the parent and child, this can be achieved
-   fairly quickly.  However, one has to take into account that just as
-
-
-
-Kolkman & Gieben             Informational                     [Page 23]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   with a normal rollover the immediate disappearance of the old
-   compromised key may lead to verification problems.  Also note that as
-   long as the RRSIG over the compromised ZSK is not expired the zone
-   may be still at risk.
-
-4.3.3.  Compromises of Keys Anchored in Resolvers
-
-   A key can also be pre-configured in resolvers.  For instance, if
-   DNSSEC is successfully deployed the root key may be pre-configured in
-   most security aware resolvers.
-
-   If trust-anchor keys are compromised, the resolvers using these keys
-   should be notified of this fact.  Zone administrators may consider
-   setting up a mailing list to communicate the fact that a SEP key is
-   about to be rolled over.  This communication will of course need to
-   be authenticated, e.g., by using digital signatures.
-
-   End-users faced with the task of updating an anchored key should
-   always validate the new key.  New keys should be authenticated out-
-   of-band, for example, through the use of an announcement website that
-   is secured using secure sockets (TLS) [21].
-
-4.4.  Parental Policies
-
-4.4.1.  Initial Key Exchanges and Parental Policies Considerations
-
-   The initial key exchange is always subject to the policies set by the
-   parent.  When designing a key exchange policy one should take into
-   account that the authentication and authorization mechanisms used
-   during a key exchange should be as strong as the authentication and
-   authorization mechanisms used for the exchange of delegation
-   information between parent and child.  That is, there is no implicit
-   need in DNSSEC to make the authentication process stronger than it
-   was in DNS.
-
-   Using the DNS itself as the source for the actual DNSKEY material,
-   with an out-of-band check on the validity of the DNSKEY, has the
-   benefit that it reduces the chances of user error.  A DNSKEY query
-   tool can make use of the SEP bit [3] to select the proper key from a
-   DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is
-   sent.  It can validate the self-signature over a key; thereby
-   verifying the ownership of the private key material.  Fetching the
-   DNSKEY from the DNS ensures that the chain of trust remains intact
-   once the parent publishes the DS RR indicating the child is secure.
-
-   Note: the out-of-band verification is still needed when the key
-   material is fetched via the DNS.  The parent can never be sure
-   whether or not the DNSKEY RRs have been spoofed.
-
-
-
-Kolkman & Gieben             Informational                     [Page 24]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-4.4.2.  Storing Keys or Hashes?
-
-   When designing a registry system one should consider which of the
-   DNSKEYs and/or the corresponding DSes to store.  Since a child zone
-   might wish to have a DS published using a message digest algorithm
-   not yet understood by the registry, the registry can't count on being
-   able to generate the DS record from a raw DNSKEY.  Thus, we recommend
-   that registry systems at least support storing DS records.
-
-   It may also be useful to store DNSKEYs, since having them may help
-   during troubleshooting and, as long as the child's chosen message
-   digest is supported, the overhead of generating DS records from them
-   is minimal.  Having an out-of-band mechanism, such as a registry
-   directory (e.g., Whois), to find out which keys are used to generate
-   DS Resource Records for specific owners and/or zones may also help
-   with troubleshooting.
-
-   The storage considerations also relate to the design of the customer
-   interface and the method by which data is transferred between
-   registrant and registry; Will the child zone administrator be able to
-   upload DS RRs with unknown hash algorithms or does the interface only
-   allow DNSKEYs?  In the registry-registrar model, one can use the
-   DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15],
-   which allows transfer of DS RRs and optionally DNSKEY RRs.
-
-4.4.3.  Security Lameness
-
-   Security lameness is defined as what happens when a parent has a DS
-   RR pointing to a non-existing DNSKEY RR.  When this happens, the
-   child's zone may be marked "Bogus" by verifying DNS clients.
-
-   As part of a comprehensive delegation check, the parent could, at key
-   exchange time, verify that the child's key is actually configured in
-   the DNS.  However, if a parent does not understand the hashing
-   algorithm used by child, the parental checks are limited to only
-   comparing the key id.
-
-   Child zones should be very careful in removing DNSKEY material,
-   specifically SEP keys, for which a DS RR exists.
-
-   Once a zone is "security lame", a fix (e.g., removing a DS RR) will
-   take time to propagate through the DNS.
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 25]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-4.4.4.  DS Signature Validity Period
-
-   Since the DS can be replayed as long as it has a valid signature, a
-   short signature validity period over the DS minimizes the time a
-   child is vulnerable in the case of a compromise of the child's
-   KSK(s).  A signature validity period that is too short introduces the
-   possibility that a zone is marked "Bogus" in case of a configuration
-   error in the signer.  There may not be enough time to fix the
-   problems before signatures expire.  Something as mundane as operator
-   unavailability during weekends shows the need for DS signature
-   validity periods longer than 2 days.  We recommend an absolute
-   minimum for a DS signature validity period of a few days.
-
-   The maximum signature validity period of the DS record depends on how
-   long child zones are willing to be vulnerable after a key compromise.
-   On the other hand, shortening the DS signature validity interval
-   increases the operational risk for the parent.  Therefore, the parent
-   may have policy to use a signature validity interval that is
-   considerably longer than the child would hope for.
-
-   A compromise between the operational constraints of the parent and
-   minimizing damage for the child may result in a DS signature validity
-   period somewhere between a week and months.
-
-   In addition to the signature validity period, which sets a lower
-   bound on the number of times the zone owner will need to sign the
-   zone data and which sets an upper bound to the time a child is
-   vulnerable after key compromise, there is the TTL value on the DS
-   RRs.  Shortening the TTL means that the authoritative servers will
-   see more queries.  But on the other hand, a short TTL lowers the
-   persistence of DS RRSets in caches thereby increasing the speed with
-   which updated DS RRSets propagate through the DNS.
-
-5.  Security Considerations
-
-   DNSSEC adds data integrity to the DNS.  This document tries to assess
-   the operational considerations to maintain a stable and secure DNSSEC
-   service.  Not taking into account the 'data propagation' properties
-   in the DNS will cause validation failures and may make secured zones
-   unavailable to security-aware resolvers.
-
-6.  Acknowledgments
-
-   Most of the ideas in this document were the result of collective
-   efforts during workshops, discussions, and tryouts.
-
-   At the risk of forgetting individuals who were the original
-   contributors of the ideas, we would like to acknowledge people who
-
-
-
-Kolkman & Gieben             Informational                     [Page 26]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   were actively involved in the compilation of this document.  In
-   random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
-   Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
-   Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
-   Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, and Peter Koch.
-
-   Some material in this document has been copied from RFC 2541 [12].
-
-   Mike StJohns designed the key exchange between parent and child
-   mentioned in the last paragraph of Section 4.2.2
-
-   Section 4.2.4 was supplied by G. Guette and O. Courtay.
-
-   Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of
-   the spelling and style issues.
-
-   Kolkman and Gieben take the blame for introducing all miscakes (sic).
-
-   While working on this document, Kolkman was employed by the RIPE NCC
-   and Gieben was employed by NLnet Labs.
-
-7.  References
-
-7.1.  Normative References
-
-   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
-         13, RFC 1034, November 1987.
-
-   [2]   Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-   [3]   Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System
-         KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP)
-         Flag", RFC 3757, May 2004.
-
-   [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033, March
-         2005.
-
-   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-   [6]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Protocol Modifications for the DNS Security Extensions", RFC
-         4035, March 2005.
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 27]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-7.2.  Informative References
-
-   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [8]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August
-         1996.
-
-   [9]   Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
-         (DNS NOTIFY)", RFC 1996, August 1996.
-
-   [10]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-         Update", RFC 3007, November 2000.
-
-   [11]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-         RFC 2308, March 1998.
-
-   [12]  Eastlake, D., "DNS Security Operational Considerations", RFC
-         2541, March 1999.
-
-   [13]  Orman, H. and P. Hoffman, "Determining Strengths For Public
-         Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
-         April 2004.
-
-   [14]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-         Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [15]  Hollenbeck, S., "Domain Name System (DNS) Security Extensions
-         Mapping for the Extensible Provisioning Protocol (EPP)", RFC
-         4310, December 2005.
-
-   [16]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
-         Sizes", The Journal of Cryptology 14 (255-293), 2001.
-
-   [17]  Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
-         Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
-         (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
-         1996.
-
-   [18]  Rose, S., "NIST DNSSEC workshop notes", June 2001.
-
-   [19]  Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
-         Records in DNSSEC", Work in Progress, January 2006.
-
-   [20]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
-         Resource Records (RRs)", RFC 4509, May 2006.
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 28]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   [21]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
-         T. Wright, "Transport Layer Security (TLS) Extensions", RFC
-         4366, April 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 29]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Appendix A.  Terminology
-
-   In this document, there is some jargon used that is defined in other
-   documents.  In most cases, we have not copied the text from the
-   documents defining the terms but have given a more elaborate
-   explanation of the meaning.  Note that these explanations should not
-   be seen as authoritative.
-
-   Anchored key: A DNSKEY configured in resolvers around the globe.
-      This key is hard to update, hence the term anchored.
-
-   Bogus: Also see Section 5 of [4].  An RRSet in DNSSEC is marked
-      "Bogus" when a signature of an RRSet does not validate against a
-      DNSKEY.
-
-   Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
-      exclusively for signing the apex key set.  The fact that a key is
-      a KSK is only relevant to the signing tool.
-
-   Key size: The term 'key size' can be substituted by 'modulus size'
-      throughout the document.  It is mathematically more correct to use
-      modulus size, but as this is a document directed at operators we
-      feel more at ease with the term key size.
-
-   Private and public keys: DNSSEC secures the DNS through the use of
-      public key cryptography.  Public key cryptography is based on the
-      existence of two (mathematically related) keys, a public key and a
-      private key.  The public keys are published in the DNS by use of
-      the DNSKEY Resource Record (DNSKEY RR).  Private keys should
-      remain private.
-
-   Key rollover: A key rollover (also called key supercession in some
-      environments) is the act of replacing one key pair with another at
-      the end of a key effectivity period.
-
-   Secure Entry Point (SEP) key: A KSK that has a parental DS record
-      pointing to it or is configured as a trust anchor.  Although not
-      required by the protocol, we recommend that the SEP flag [3] is
-      set on these keys.
-
-   Self-signature: This only applies to signatures over DNSKEYs; a
-      signature made with DNSKEY x, over DNSKEY x is called a self-
-      signature.  Note: without further information, self-signatures
-      convey no trust.  They are useful to check the authenticity of the
-      DNSKEY, i.e., they can be used as a hash.
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 30]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   Singing the zone file: The term used for the event where an
-      administrator joyfully signs its zone file while producing melodic
-      sound patterns.
-
-   Signer: The system that has access to the private key material and
-      signs the Resource Record sets in a zone.  A signer may be
-      configured to sign only parts of the zone, e.g., only those RRSets
-      for which existing signatures are about to expire.
-
-   Zone Signing Key (ZSK): A key that is used for signing all data in a
-      zone.  The fact that a key is a ZSK is only relevant to the
-      signing tool.
-
-   Zone administrator: The 'role' that is responsible for signing a zone
-      and publishing it on the primary authoritative server.
-
-Appendix B.  Zone Signing Key Rollover How-To
-
-   Using the pre-published signature scheme and the most conservative
-   method to assure oneself that data does not live in caches, here
-   follows the "how-to".
-
-   Step 0: The preparation: Create two keys and publish both in your key
-      set.  Mark one of the keys "active" and the other "published".
-      Use the "active" key for signing your zone data.  Store the
-      private part of the "published" key, preferably off-line.  The
-      protocol does not provide for attributes to mark a key as active
-      or published.  This is something you have to do on your own,
-      through the use of a notebook or key management tool.
-
-   Step 1: Determine expiration: At the beginning of the rollover make a
-      note of the highest expiration time of signatures in your zone
-      file created with the current key marked as active.  Wait until
-      the expiration time marked in Step 1 has passed.
-
-   Step 2: Then start using the key that was marked "published" to sign
-      your data (i.e., mark it "active").  Stop using the key that was
-      marked "active"; mark it "rolled".
-
-   Step 3: It is safe to engage in a new rollover (Step 1) after at
-      least one signature validity period.
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 31]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Appendix C.  Typographic Conventions
-
-   The following typographic conventions are used in this document:
-
-   Key notation: A key is denoted by DNSKEYx, where x is a number or an
-   identifier, x could be thought of as the key id.
-
-   RRSet notations: RRs are only denoted by the type.  All other
-   information -- owner, class, rdata, and TTL--is left out.  Thus:
-   "example.com 3600 IN A 192.0.2.1" is reduced to "A".  RRSets are a
-   list of RRs.  A example of this would be "A1, A2", specifying the
-   RRSet containing two "A" records.  This could again be abbreviated to
-   just "A".
-
-   Signature notation: Signatures are denoted as RRSIGx(RRSet), which
-   means that RRSet is signed with DNSKEYx.
-
-   Zone representation: Using the above notation we have simplified the
-   representation of a signed zone by leaving out all unnecessary
-   details such as the names and by representing all data by "SOAx"
-
-   SOA representation: SOAs are represented as SOAx, where x is the
-   serial number.
-
-   Using this notation the following signed zone:
-
-   example.net.      86400  IN SOA  ns.example.net. bert.example.net. (
-                            2006022100   ; serial
-                            86400        ; refresh (  24 hours)
-                            7200         ; retry   (   2 hours)
-                            3600000      ; expire  (1000 hours)
-                            28800 )      ; minimum (   8 hours)
-                     86400  RRSIG   SOA 5 2 86400 20130522213204 (
-                                  20130422213204 14 example.net.
-                                  cmL62SI6iAX46xGNQAdQ... )
-                     86400  NS      a.iana-servers.net.
-                     86400  NS      b.iana-servers.net.
-                     86400  RRSIG   NS 5 2 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  SO5epiJei19AjXoUpFnQ ... )
-                     86400  DNSKEY  256 3 5 (
-                                  EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
-                     86400  DNSKEY  257 3 5 (
-                                  gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
-                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
-                                  20130422213204 14 example.net.
-                                  J4zCe8QX4tXVGjV4e1r9... )
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 32]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
-                                  20130422213204 15 example.net.
-                                  keVDCOpsSeDReyV6O... )
-                     86400  RRSIG   NSEC 5 2 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  obj3HEp1GjnmhRjX... )
-   a.example.net.    86400  IN TXT  "A label"
-                     86400  RRSIG   TXT 5 3 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  IkDMlRdYLmXH7QJnuF3v... )
-                     86400  NSEC    b.example.com. TXT RRSIG NSEC
-                     86400  RRSIG   NSEC 5 3 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  bZMjoZ3bHjnEz0nIsPMM... )
-                     ...
-
-   is reduced to the following representation:
-
-       SOA2006022100
-       RRSIG14(SOA2006022100)
-       DNSKEY14
-       DNSKEY15
-
-       RRSIG14(KEY)
-       RRSIG15(KEY)
-
-   The rest of the zone data has the same signature as the SOA record,
-   i.e., an RRSIG created with DNSKEY 14.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 33]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Authors' Addresses
-
-   Olaf M. Kolkman
-   NLnet Labs
-   Kruislaan 419
-   Amsterdam  1098 VA
-   The Netherlands
-
-   EMail: olaf@nlnetlabs.nl
-   URI:   http://www.nlnetlabs.nl
-
-
-   R. (Miek) Gieben
-
-   EMail: miek@miek.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 34]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 35]
-
diff --git a/doc/rfc/rfc4648.txt b/doc/rfc/rfc4648.txt
deleted file mode 100644
index c7599b43..00000000
--- a/doc/rfc/rfc4648.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       S. Josefsson
-Request for Comments: 4648                                           SJD
-Obsoletes: 3548                                             October 2006
-Category: Standards Track
-
-
-             The Base16, Base32, and Base64 Data Encodings
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes the commonly used base 64, base 32, and base
-   16 encoding schemes.  It also discusses the use of line-feeds in
-   encoded data, use of padding in encoded data, use of non-alphabet
-   characters in encoded data, use of different encoding alphabets, and
-   canonical encodings.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 1]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. Conventions Used in This Document ...............................3
-   3. Implementation Discrepancies ....................................3
-      3.1. Line Feeds in Encoded Data .................................3
-      3.2. Padding of Encoded Data ....................................4
-      3.3. Interpretation of Non-Alphabet Characters in Encoded Data ..4
-      3.4. Choosing the Alphabet ......................................4
-      3.5. Canonical Encoding .........................................5
-   4. Base 64 Encoding ................................................5
-   5. Base 64 Encoding with URL and Filename Safe Alphabet ............7
-   6. Base 32 Encoding ................................................8
-   7. Base 32 Encoding with Extended Hex Alphabet ....................10
-   8. Base 16 Encoding ...............................................10
-   9. Illustrations and Examples .....................................11
-   10. Test Vectors ..................................................12
-   11. ISO C99 Implementation of Base64 ..............................14
-   12. Security Considerations .......................................14
-   13. Changes Since RFC 3548 ........................................15
-   14. Acknowledgements ..............................................15
-   15. Copying Conditions ............................................15
-   16. References ....................................................16
-      16.1. Normative References .....................................16
-      16.2. Informative References ...................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 2]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-1.  Introduction
-
-   Base encoding of data is used in many situations to store or transfer
-   data in environments that, perhaps for legacy reasons, are restricted
-   to US-ASCII [1] data.  Base encoding can also be used in new
-   applications that do not have legacy restrictions, simply because it
-   makes it possible to manipulate objects with text editors.
-
-   In the past, different applications have had different requirements
-   and thus sometimes implemented base encodings in slightly different
-   ways.  Today, protocol specifications sometimes use base encodings in
-   general, and "base64" in particular, without a precise description or
-   reference.  Multipurpose Internet Mail Extensions (MIME) [4] is often
-   used as a reference for base64 without considering the consequences
-   for line-wrapping or non-alphabet characters.  The purpose of this
-   specification is to establish common alphabet and encoding
-   considerations.  This will hopefully reduce ambiguity in other
-   documents, leading to better interoperability.
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [2].
-
-3.  Implementation Discrepancies
-
-   Here we discuss the discrepancies between base encoding
-   implementations in the past and, where appropriate, mandate a
-   specific recommended behavior for the future.
-
-3.1.  Line Feeds in Encoded Data
-
-   MIME [4] is often used as a reference for base 64 encoding.  However,
-   MIME does not define "base 64" per se, but rather a "base 64 Content-
-   Transfer-Encoding" for use within MIME.  As such, MIME enforces a
-   limit on line length of base 64-encoded data to 76 characters.  MIME
-   inherits the encoding from Privacy Enhanced Mail (PEM) [3], stating
-   that it is "virtually identical"; however, PEM uses a line length of
-   64 characters.  The MIME and PEM limits are both due to limits within
-   SMTP.
-
-   Implementations MUST NOT add line feeds to base-encoded data unless
-   the specification referring to this document explicitly directs base
-   encoders to add line feeds after a specific number of characters.
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 3]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-3.2.  Padding of Encoded Data
-
-   In some circumstances, the use of padding ("=") in base-encoded data
-   is not required or used.  In the general case, when assumptions about
-   the size of transported data cannot be made, padding is required to
-   yield correct decoded data.
-
-   Implementations MUST include appropriate pad characters at the end of
-   encoded data unless the specification referring to this document
-   explicitly states otherwise.
-
-   The base64 and base32 alphabets use padding, as described below in
-   sections 4 and 6, but the base16 alphabet does not need it; see
-   section 8.
-
-3.3.  Interpretation of Non-Alphabet Characters in Encoded Data
-
-   Base encodings use a specific, reduced alphabet to encode binary
-   data.  Non-alphabet characters could exist within base-encoded data,
-   caused by data corruption or by design.  Non-alphabet characters may
-   be exploited as a "covert channel", where non-protocol data can be
-   sent for nefarious purposes.  Non-alphabet characters might also be
-   sent in order to exploit implementation errors leading to, e.g.,
-   buffer overflow attacks.
-
-   Implementations MUST reject the encoded data if it contains
-   characters outside the base alphabet when interpreting base-encoded
-   data, unless the specification referring to this document explicitly
-   states otherwise.  Such specifications may instead state, as MIME
-   does, that characters outside the base encoding alphabet should
-   simply be ignored when interpreting data ("be liberal in what you
-   accept").  Note that this means that any adjacent carriage return/
-   line feed (CRLF) characters constitute "non-alphabet characters" and
-   are ignored.  Furthermore, such specifications MAY ignore the pad
-   character, "=", treating it as non-alphabet data, if it is present
-   before the end of the encoded data.  If more than the allowed number
-   of pad characters is found at the end of the string (e.g., a base 64
-   string terminated with "==="), the excess pad characters MAY also be
-   ignored.
-
-3.4.  Choosing the Alphabet
-
-   Different applications have different requirements on the characters
-   in the alphabet.  Here are a few requirements that determine which
-   alphabet should be used:
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 4]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   o  Handled by humans.  The characters "0" and "O" are easily
-      confused, as are "1", "l", and "I".  In the base32 alphabet below,
-      where 0 (zero) and 1 (one) are not present, a decoder may
-      interpret 0 as O, and 1 as I or L depending on case.  (However, by
-      default it should not; see previous section.)
-
-   o  Encoded into structures that mandate other requirements.  For base
-      16 and base 32, this determines the use of upper- or lowercase
-      alphabets.  For base 64, the non-alphanumeric characters (in
-      particular, "/") may be problematic in file names and URLs.
-
-   o  Used as identifiers.  Certain characters, notably "+" and "/" in
-      the base 64 alphabet, are treated as word-breaks by legacy text
-      search/index tools.
-
-   There is no universally accepted alphabet that fulfills all the
-   requirements.  For an example of a highly specialized variant, see
-   IMAP [8].  In this document, we document and name some currently used
-   alphabets.
-
-3.5.  Canonical Encoding
-
-   The padding step in base 64 and base 32 encoding can, if improperly
-   implemented, lead to non-significant alterations of the encoded data.
-   For example, if the input is only one octet for a base 64 encoding,
-   then all six bits of the first symbol are used, but only the first
-   two bits of the next symbol are used.  These pad bits MUST be set to
-   zero by conforming encoders, which is described in the descriptions
-   on padding below.  If this property do not hold, there is no
-   canonical representation of base-encoded data, and multiple base-
-   encoded strings can be decoded to the same binary data.  If this
-   property (and others discussed in this document) holds, a canonical
-   encoding is guaranteed.
-
-   In some environments, the alteration is critical and therefore
-   decoders MAY chose to reject an encoding if the pad bits have not
-   been set to zero.  The specification referring to this may mandate a
-   specific behaviour.
-
-4.  Base 64 Encoding
-
-   The following description of base 64 is derived from [3], [4], [5],
-   and [6].  This encoding may be referred to as "base64".
-
-   The Base 64 encoding is designed to represent arbitrary sequences of
-   octets in a form that allows the use of both upper- and lowercase
-   letters but that need not be human readable.
-
-
-
-
-Josefsson                   Standards Track                     [Page 5]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   A 65-character subset of US-ASCII is used, enabling 6 bits to be
-   represented per printable character.  (The extra 65th character, "=",
-   is used to signify a special processing function.)
-
-   The encoding process represents 24-bit groups of input bits as output
-   strings of 4 encoded characters.  Proceeding from left to right, a
-   24-bit input group is formed by concatenating 3 8-bit input groups.
-   These 24 bits are then treated as 4 concatenated 6-bit groups, each
-   of which is translated into a single character in the base 64
-   alphabet.
-
-   Each 6-bit group is used as an index into an array of 64 printable
-   characters.  The character referenced by the index is placed in the
-   output string.
-
-                      Table 1: The Base 64 Alphabet
-
-     Value Encoding  Value Encoding  Value Encoding  Value Encoding
-         0 A            17 R            34 i            51 z
-         1 B            18 S            35 j            52 0
-         2 C            19 T            36 k            53 1
-         3 D            20 U            37 l            54 2
-         4 E            21 V            38 m            55 3
-         5 F            22 W            39 n            56 4
-         6 G            23 X            40 o            57 5
-         7 H            24 Y            41 p            58 6
-         8 I            25 Z            42 q            59 7
-         9 J            26 a            43 r            60 8
-        10 K            27 b            44 s            61 9
-        11 L            28 c            45 t            62 +
-        12 M            29 d            46 u            63 /
-        13 N            30 e            47 v
-        14 O            31 f            48 w         (pad) =
-        15 P            32 g            49 x
-        16 Q            33 h            50 y
-
-   Special processing is performed if fewer than 24 bits are available
-   at the end of the data being encoded.  A full encoding quantum is
-   always completed at the end of a quantity.  When fewer than 24 input
-   bits are available in an input group, bits with value zero are added
-   (on the right) to form an integral number of 6-bit groups.  Padding
-   at the end of the data is performed using the '=' character.  Since
-   all base 64 input is an integral number of octets, only the following
-   cases can arise:
-
-   (1) The final quantum of encoding input is an integral multiple of 24
-       bits; here, the final unit of encoded output will be an integral
-       multiple of 4 characters with no "=" padding.
-
-
-
-Josefsson                   Standards Track                     [Page 6]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   (2) The final quantum of encoding input is exactly 8 bits; here, the
-       final unit of encoded output will be two characters followed by
-       two "=" padding characters.
-
-   (3) The final quantum of encoding input is exactly 16 bits; here, the
-       final unit of encoded output will be three characters followed by
-       one "=" padding character.
-
-5.  Base 64 Encoding with URL and Filename Safe Alphabet
-
-   The Base 64 encoding with an URL and filename safe alphabet has been
-   used in [12].
-
-   An alternative alphabet has been suggested that would use "~" as the
-   63rd character.  Since the "~" character has special meaning in some
-   file system environments, the encoding described in this section is
-   recommended instead.  The remaining unreserved URI character is ".",
-   but some file system environments do not permit multiple "." in a
-   filename, thus making the "." character unattractive as well.
-
-   The pad character "=" is typically percent-encoded when used in an
-   URI [9], but if the data length is known implicitly, this can be
-   avoided by skipping the padding; see section 3.2.
-
-   This encoding may be referred to as "base64url".  This encoding
-   should not be regarded as the same as the "base64" encoding and
-   should not be referred to as only "base64".  Unless clarified
-   otherwise, "base64" refers to the base 64 in the previous section.
-
-   This encoding is technically identical to the previous one, except
-   for the 62:nd and 63:rd alphabet character, as indicated in Table 2.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 7]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-         Table 2: The "URL and Filename safe" Base 64 Alphabet
-
-     Value Encoding  Value Encoding  Value Encoding  Value Encoding
-         0 A            17 R            34 i            51 z
-         1 B            18 S            35 j            52 0
-         2 C            19 T            36 k            53 1
-         3 D            20 U            37 l            54 2
-         4 E            21 V            38 m            55 3
-         5 F            22 W            39 n            56 4
-         6 G            23 X            40 o            57 5
-         7 H            24 Y            41 p            58 6
-         8 I            25 Z            42 q            59 7
-         9 J            26 a            43 r            60 8
-        10 K            27 b            44 s            61 9
-        11 L            28 c            45 t            62 - (minus)
-        12 M            29 d            46 u            63 _
-        13 N            30 e            47 v           (underline)
-        14 O            31 f            48 w
-        15 P            32 g            49 x
-        16 Q            33 h            50 y         (pad) =
-
-6.  Base 32 Encoding
-
-   The following description of base 32 is derived from [11] (with
-   corrections).  This encoding may be referred to as "base32".
-
-   The Base 32 encoding is designed to represent arbitrary sequences of
-   octets in a form that needs to be case insensitive but that need not
-   be human readable.
-
-   A 33-character subset of US-ASCII is used, enabling 5 bits to be
-   represented per printable character.  (The extra 33rd character, "=",
-   is used to signify a special processing function.)
-
-   The encoding process represents 40-bit groups of input bits as output
-   strings of 8 encoded characters.  Proceeding from left to right, a
-   40-bit input group is formed by concatenating 5 8bit input groups.
-   These 40 bits are then treated as 8 concatenated 5-bit groups, each
-   of which is translated into a single character in the base 32
-   alphabet.  When a bit stream is encoded via the base 32 encoding, the
-   bit stream must be presumed to be ordered with the most-significant-
-   bit first.  That is, the first bit in the stream will be the high-
-   order bit in the first 8bit byte, the eighth bit will be the low-
-   order bit in the first 8bit byte, and so on.
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 8]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   Each 5-bit group is used as an index into an array of 32 printable
-   characters.  The character referenced by the index is placed in the
-   output string.  These characters, identified in Table 3, below, are
-   selected from US-ASCII digits and uppercase letters.
-
-                     Table 3: The Base 32 Alphabet
-
-     Value Encoding  Value Encoding  Value Encoding  Value Encoding
-         0 A             9 J            18 S            27 3
-         1 B            10 K            19 T            28 4
-         2 C            11 L            20 U            29 5
-         3 D            12 M            21 V            30 6
-         4 E            13 N            22 W            31 7
-         5 F            14 O            23 X
-         6 G            15 P            24 Y         (pad) =
-         7 H            16 Q            25 Z
-         8 I            17 R            26 2
-
-   Special processing is performed if fewer than 40 bits are available
-   at the end of the data being encoded.  A full encoding quantum is
-   always completed at the end of a body.  When fewer than 40 input bits
-   are available in an input group, bits with value zero are added (on
-   the right) to form an integral number of 5-bit groups.  Padding at
-   the end of the data is performed using the "=" character.  Since all
-   base 32 input is an integral number of octets, only the following
-   cases can arise:
-
-   (1) The final quantum of encoding input is an integral multiple of 40
-       bits; here, the final unit of encoded output will be an integral
-       multiple of 8 characters with no "=" padding.
-
-   (2) The final quantum of encoding input is exactly 8 bits; here, the
-       final unit of encoded output will be two characters followed by
-       six "=" padding characters.
-
-   (3) The final quantum of encoding input is exactly 16 bits; here, the
-       final unit of encoded output will be four characters followed by
-       four "=" padding characters.
-
-   (4) The final quantum of encoding input is exactly 24 bits; here, the
-       final unit of encoded output will be five characters followed by
-       three "=" padding characters.
-
-   (5) The final quantum of encoding input is exactly 32 bits; here, the
-       final unit of encoded output will be seven characters followed by
-       one "=" padding character.
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 9]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-7.  Base 32 Encoding with Extended Hex Alphabet
-
-   The following description of base 32 is derived from [7].  This
-   encoding may be referred to as "base32hex".  This encoding should not
-   be regarded as the same as the "base32" encoding and should not be
-   referred to as only "base32".  This encoding is used by, e.g.,
-   NextSECure3 (NSEC3) [10].
-
-   One property with this alphabet, which the base64 and base32
-   alphabets lack, is that encoded data maintains its sort order when
-   the encoded data is compared bit-wise.
-
-   This encoding is identical to the previous one, except for the
-   alphabet.  The new alphabet is found in Table 4.
-
-                 Table 4: The "Extended Hex" Base 32 Alphabet
-
-         Value Encoding  Value Encoding  Value Encoding  Value Encoding
-             0 0             9 9            18 I            27 R
-             1 1            10 A            19 J            28 S
-             2 2            11 B            20 K            29 T
-             3 3            12 C            21 L            30 U
-             4 4            13 D            22 M            31 V
-             5 5            14 E            23 N
-             6 6            15 F            24 O         (pad) =
-             7 7            16 G            25 P
-             8 8            17 H            26 Q
-
-8.  Base 16 Encoding
-
-   The following description is original but analogous to previous
-   descriptions.  Essentially, Base 16 encoding is the standard case-
-   insensitive hex encoding and may be referred to as "base16" or "hex".
-
-   A 16-character subset of US-ASCII is used, enabling 4 bits to be
-   represented per printable character.
-
-   The encoding process represents 8-bit groups (octets) of input bits
-   as output strings of 2 encoded characters.  Proceeding from left to
-   right, an 8-bit input is taken from the input data.  These 8 bits are
-   then treated as 2 concatenated 4-bit groups, each of which is
-   translated into a single character in the base 16 alphabet.
-
-   Each 4-bit group is used as an index into an array of 16 printable
-   characters.  The character referenced by the index is placed in the
-   output string.
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 10]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-                         Table 5: The Base 16 Alphabet
-
-         Value Encoding  Value Encoding  Value Encoding  Value Encoding
-             0 0             4 4             8 8            12 C
-             1 1             5 5             9 9            13 D
-             2 2             6 6            10 A            14 E
-             3 3             7 7            11 B            15 F
-
-   Unlike base 32 and base 64, no special padding is necessary since a
-   full code word is always available.
-
-9.  Illustrations and Examples
-
-   To translate between binary and a base encoding, the input is stored
-   in a structure, and the output is extracted.  The case for base 64 is
-   displayed in the following figure, borrowed from [5].
-
-            +--first octet--+-second octet--+--third octet--+
-            |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
-            +-----------+---+-------+-------+---+-----------+
-            |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
-            +--1.index--+--2.index--+--3.index--+--4.index--+
-
-   The case for base 32 is shown in the following figure, borrowed from
-   [7].  Each successive character in a base-32 value represents 5
-   successive bits of the underlying octet sequence.  Thus, each group
-   of 8 characters represents a sequence of 5 octets (40 bits).
-
-                        1          2          3
-             01234567 89012345 67890123 45678901 23456789
-            +--------+--------+--------+--------+--------+
-            |< 1 >< 2| >< 3 ><|.4 >< 5.|>< 6 ><.|7 >< 8 >|
-            +--------+--------+--------+--------+--------+
-                                                    <===> 8th character
-                                              <====> 7th character
-                                         <===> 6th character
-                                   <====> 5th character
-                             <====> 4th character
-                        <===> 3rd character
-                  <====> 2nd character
-             <===> 1st character
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 11]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   The following example of Base64 data is from [5], with corrections.
-
-      Input data:  0x14fb9c03d97e
-      Hex:     1   4    f   b    9   c     | 0   3    d   9    7   e
-      8-bit:   00010100 11111011 10011100  | 00000011 11011001 01111110
-      6-bit:   000101 001111 101110 011100 | 000000 111101 100101 111110
-      Decimal: 5      15     46     28       0      61     37     62
-      Output:  F      P      u      c        A      9      l      +
-
-      Input data:  0x14fb9c03d9
-      Hex:     1   4    f   b    9   c     | 0   3    d   9
-      8-bit:   00010100 11111011 10011100  | 00000011 11011001
-                                                      pad with 00
-      6-bit:   000101 001111 101110 011100 | 000000 111101 100100
-      Decimal: 5      15     46     28       0      61     36
-                                                         pad with =
-      Output:  F      P      u      c        A      9      k      =
-
-      Input data:  0x14fb9c03
-      Hex:     1   4    f   b    9   c     | 0   3
-      8-bit:   00010100 11111011 10011100  | 00000011
-                                             pad with 0000
-      6-bit:   000101 001111 101110 011100 | 000000 110000
-      Decimal: 5      15     46     28       0      48
-                                                  pad with =      =
-      Output:  F      P      u      c        A      w      =      =
-
-10.  Test Vectors
-
-   BASE64("") = ""
-
-   BASE64("f") = "Zg=="
-
-   BASE64("fo") = "Zm8="
-
-   BASE64("foo") = "Zm9v"
-
-   BASE64("foob") = "Zm9vYg=="
-
-   BASE64("fooba") = "Zm9vYmE="
-
-   BASE64("foobar") = "Zm9vYmFy"
-
-   BASE32("") = ""
-
-   BASE32("f") = "MY======"
-
-   BASE32("fo") = "MZXQ===="
-
-
-
-Josefsson                   Standards Track                    [Page 12]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   BASE32("foo") = "MZXW6==="
-
-   BASE32("foob") = "MZXW6YQ="
-
-   BASE32("fooba") = "MZXW6YTB"
-
-   BASE32("foobar") = "MZXW6YTBOI======"
-
-   BASE32-HEX("") = ""
-
-   BASE32-HEX("f") = "CO======"
-
-   BASE32-HEX("fo") = "CPNG===="
-
-   BASE32-HEX("foo") = "CPNMU==="
-
-   BASE32-HEX("foob") = "CPNMUOG="
-
-   BASE32-HEX("fooba") = "CPNMUOJ1"
-
-   BASE32-HEX("foobar") = "CPNMUOJ1E8======"
-
-   BASE16("") = ""
-
-   BASE16("f") = "66"
-
-   BASE16("fo") = "666F"
-
-   BASE16("foo") = "666F6F"
-
-   BASE16("foob") = "666F6F62"
-
-   BASE16("fooba") = "666F6F6261"
-
-   BASE16("foobar") = "666F6F626172"
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 13]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-11.  ISO C99 Implementation of Base64
-
-   An ISO C99 implementation of Base64 encoding and decoding that is
-   believed to follow all recommendations in this RFC is available from:
-
-      http://josefsson.org/base-encoding/
-
-   This code is not normative.
-
-   The code could not be included in this RFC for procedural reasons
-   (RFC 3978 section 5.4).
-
-12.  Security Considerations
-
-   When base encoding and decoding is implemented, care should be taken
-   not to introduce vulnerabilities to buffer overflow attacks, or other
-   attacks on the implementation.  A decoder should not break on invalid
-   input including, e.g., embedded NUL characters (ASCII 0).
-
-   If non-alphabet characters are ignored, instead of causing rejection
-   of the entire encoding (as recommended), a covert channel that can be
-   used to "leak" information is made possible.  The ignored characters
-   could also be used for other nefarious purposes, such as to avoid a
-   string equality comparison or to trigger implementation bugs.  The
-   implications of ignoring non-alphabet characters should be understood
-   in applications that do not follow the recommended practice.
-   Similarly, when the base 16 and base 32 alphabets are handled case
-   insensitively, alteration of case can be used to leak information or
-   make string equality comparisons fail.
-
-   When padding is used, there are some non-significant bits that
-   warrant security concerns, as they may be abused to leak information
-   or used to bypass string equality comparisons or to trigger
-   implementation problems.
-
-   Base encoding visually hides otherwise easily recognized information,
-   such as passwords, but does not provide any computational
-   confidentiality.  This has been known to cause security incidents
-   when, e.g., a user reports details of a network protocol exchange
-   (perhaps to illustrate some other problem) and accidentally reveals
-   the password because she is unaware that the base encoding does not
-   protect the password.
-
-   Base encoding adds no entropy to the plaintext, but it does increase
-   the amount of plaintext available and provide a signature for
-   cryptanalysis in the form of a characteristic probability
-   distribution.
-
-
-
-
-Josefsson                   Standards Track                    [Page 14]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-13.  Changes Since RFC 3548
-
-   Added the "base32 extended hex alphabet", needed to preserve sort
-   order of encoded data.
-
-   Referenced IMAP for the special Base64 encoding used there.
-
-   Fixed the example copied from RFC 2440.
-
-   Added security consideration about providing a signature for
-   cryptoanalysis.
-
-   Added test vectors.
-
-   Fixed typos.
-
-14.  Acknowledgements
-
-   Several people offered comments and/or suggestions, including John E.
-   Hadstate, Tony Hansen, Gordon Mohr, John Myers, Chris Newman, and
-   Andrew Sieber.  Text used in this document are based on earlier RFCs
-   describing specific uses of various base encodings.  The author
-   acknowledges the RSA Laboratories for supporting the work that led to
-   this document.
-
-   This revised version is based in parts on comments and/or suggestions
-   made by Roy Arends, Eric Blake, Brian E Carpenter, Elwyn Davies, Bill
-   Fenner, Sam Hartman, Ted Hardie, Per Hygum, Jelte Jansen, Clement
-   Kent, Tero Kivinen, Paul Kwiatkowski, and Ben Laurie.
-
-15.  Copying Conditions
-
-   Copyright (c) 2000-2006 Simon Josefsson
-
-   Regarding the abstract and sections 1, 3, 8, 10, 12, 13, and 14 of
-   this document, that were written by Simon Josefsson ("the author",
-   for the remainder of this section), the author makes no guarantees
-   and is not responsible for any damage resulting from its use.  The
-   author grants irrevocable permission to anyone to use, modify, and
-   distribute it in any way that does not diminish the rights of anyone
-   else to use, modify, and distribute it, provided that redistributed
-   derivative works do not contain misleading author or version
-   information and do not falsely purport to be IETF RFC documents.
-   Derivative works need not be licensed under similar terms.
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 15]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-16.  References
-
-16.1.  Normative References
-
-   [1]   Cerf, V., "ASCII format for network interchange", RFC 20,
-         October 1969.
-
-   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-16.2.  Informative References
-
-   [3]   Linn, J., "Privacy Enhancement for Internet Electronic Mail:
-         Part I: Message Encryption and Authentication Procedures", RFC
-         1421, February 1993.
-
-   [4]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-         Extensions (MIME) Part One: Format of Internet Message Bodies",
-         RFC 2045, November 1996.
-
-   [5]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
-         "OpenPGP Message Format", RFC 2440, November 1998.
-
-   [6]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033, March
-         2005.
-
-   [7]   Klyne, G. and L. Masinter, "Identifying Composite Media
-         Features", RFC 2938, September 2000.
-
-   [8]   Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
-         4rev1", RFC 3501, March 2003.
-
-   [9]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
-         January 2005.
-
-   [10]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNSSEC Hash
-         Authenticated Denial of Existence", Work in Progress, June
-         2006.
-
-   [11]  Myers, J., "SASL GSSAPI mechanisms", Work in Progress, May
-         2000.
-
-   [12]  Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list",
-         http://zgp.org/pipermail/p2p-hackers/2001-September/
-         000315.html, September 2001.
-
-
-
-
-Josefsson                   Standards Track                    [Page 16]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-Author's Address
-
-   Simon Josefsson
-   SJD
-   EMail: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 17]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 18]
-
diff --git a/doc/rfc/rfc4697.txt b/doc/rfc/rfc4697.txt
deleted file mode 100644
index 773507ca..00000000
--- a/doc/rfc/rfc4697.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          M. Larson
-Request for Comments: 4697                                     P. Barber
-BCP: 123                                                  VeriSign, Inc.
-Category: Best Current Practice                             October 2006
-
-
-                  Observed DNS Resolution Misbehavior
-
-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 (2006).
-
-Abstract
-
-   This memo describes DNS iterative resolver behavior that results in a
-   significant query volume sent to the root and top-level domain (TLD)
-   name servers.  We offer implementation advice to iterative resolver
-   developers to alleviate these unnecessary queries.  The
-   recommendations made in this document are a direct byproduct of
-   observation and analysis of abnormal query traffic patterns seen at
-   two of the thirteen root name servers and all thirteen com/net TLD
-   name servers.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-      1.1. A Note about Terminology in this Memo ......................3
-      1.2. Key Words ..................................................3
-   2. Observed Iterative Resolver Misbehavior .........................3
-      2.1. Aggressive Requerying for Delegation Information ...........3
-           2.1.1. Recommendation ......................................5
-      2.2. Repeated Queries to Lame Servers ...........................6
-           2.2.1. Recommendation ......................................6
-      2.3. Inability to Follow Multiple Levels of Indirection .........7
-           2.3.1. Recommendation ......................................7
-      2.4. Aggressive Retransmission when Fetching Glue ...............8
-           2.4.1. Recommendation ......................................9
-      2.5. Aggressive Retransmission behind Firewalls .................9
-           2.5.1. Recommendation .....................................10
-      2.6. Misconfigured NS Records ..................................10
-           2.6.1. Recommendation .....................................11
-
-
-
-
-Larson & Barber          Best Current Practice                  [Page 1]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-      2.7. Name Server Records with Zero TTL .........................11
-           2.7.1. Recommendation .....................................12
-      2.8. Unnecessary Dynamic Update Messages .......................12
-           2.8.1. Recommendation .....................................13
-      2.9. Queries for Domain Names Resembling IPv4 Addresses ........13
-           2.9.1. Recommendation .....................................14
-      2.10. Misdirected Recursive Queries ............................14
-           2.10.1. Recommendation ....................................14
-      2.11. Suboptimal Name Server Selection Algorithm ...............15
-           2.11.1. Recommendation ....................................15
-   3. Security Considerations ........................................16
-   4. Acknowledgements ...............................................16
-   5. Internationalization Considerations ............................16
-   6. References .....................................................16
-      6.1. Normative References ......................................16
-      6.2. Informative References ....................................16
-
-1.  Introduction
-
-   Observation of query traffic received by two root name servers and
-   the thirteen com/net Top-Level Domain (TLD) name servers has revealed
-   that a large proportion of the total traffic often consists of
-   "requeries".  A requery is the same question (<QNAME, QTYPE, QCLASS>)
-   asked repeatedly at an unexpectedly high rate.  We have observed
-   requeries from both a single IP address and multiple IP addresses
-   (i.e., the same query received simultaneously from multiple IP
-   addresses).
-
-   By analyzing requery events, we have found that the cause of the
-   duplicate traffic is almost always a deficient iterative resolver,
-   stub resolver, or application implementation combined with an
-   operational anomaly.  The implementation deficiencies we have
-   identified to date include well-intentioned recovery attempts gone
-   awry, insufficient caching of failures, early abort when multiple
-   levels of indirection must be followed, and aggressive retry by stub
-   resolvers or applications.  Anomalies that we have seen trigger
-   requery events include lame delegations, unusual glue records, and
-   anything that makes all authoritative name servers for a zone
-   unreachable (Denial of Service (DoS) attacks, crashes, maintenance,
-   routing failures, congestion, etc.).
-
-   In the following sections, we provide a detailed explanation of the
-   observed behavior and recommend changes that will reduce the requery
-   rate.  None of the changes recommended affects the core DNS protocol
-   specification; instead, this document consists of guidelines to
-   implementors of iterative resolvers.
-
-
-
-
-
-Larson & Barber          Best Current Practice                  [Page 2]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-1.1.  A Note about Terminology in This Memo
-
-   To recast an old saying about standards, the nice thing about DNS
-   terms is that there are so many of them to choose from.  Writing or
-   talking about DNS can be difficult and can cause confusion resulting
-   from a lack of agreed-upon terms for its various components.  Further
-   complicating matters are implementations that combine multiple roles
-   into one piece of software, which makes naming the result
-   problematic.  An example is the entity that accepts recursive
-   queries, issues iterative queries as necessary to resolve the initial
-   recursive query, caches responses it receives, and which is also able
-   to answer questions about certain zones authoritatively.  This entity
-   is an iterative resolver combined with an authoritative name server
-   and is often called a "recursive name server" or a "caching name
-   server".
-
-   This memo is concerned principally with the behavior of iterative
-   resolvers, which are typically found as part of a recursive name
-   server.  This memo uses the more precise term "iterative resolver",
-   because the focus is usually on that component.  In instances where
-   the name server role of this entity requires mentioning, this memo
-   uses the term "recursive name server".  As an example of the
-   difference, the name server component of a recursive name server
-   receives DNS queries and the iterative resolver component sends
-   queries.
-
-   The advent of IPv6 requires mentioning AAAA records as well as A
-   records when discussing glue.  To avoid continuous repetition and
-   qualification, this memo uses the general term "address record" to
-   encompass both A and AAAA records when a particular situation is
-   relevant to both types.
-
-1.2.  Key Words
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [1].
-
-2.  Observed Iterative Resolver Misbehavior
-
-2.1.  Aggressive Requerying for Delegation Information
-
-   There can be times when every name server in a zone's NS RRSet is
-   unreachable (e.g., during a network outage), unavailable (e.g., the
-   name server process is not running on the server host), or
-   misconfigured (e.g., the name server is not authoritative for the
-   given zone, also known as "lame").  Consider an iterative resolver
-   that attempts to resolve a query for a domain name in such a zone and
-
-
-
-Larson & Barber          Best Current Practice                  [Page 3]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-   discovers that none of the zone's name servers can provide an answer.
-   We have observed a recursive name server implementation whose
-   iterative resolver then verifies the zone's NS RRSet in its cache by
-   querying for the zone's delegation information: it sends a query for
-   the zone's NS RRSet to one of the parent zone's name servers.  (Note
-   that queries with QTYPE=NS are not required by the standard
-   resolution algorithm described in Section 4.3.2 of RFC 1034 [2].
-   These NS queries represent this implementation's addition to that
-   algorithm.)
-
-   For example, suppose that "example.com" has the following NS RRSet:
-
-     example.com.   IN   NS   ns1.example.com.
-     example.com.   IN   NS   ns2.example.com.
-
-   Upon receipt of a query for "www.example.com" and assuming that
-   neither "ns1.example.com" nor "ns2.example.com" can provide an
-   answer, this iterative resolver implementation immediately queries a
-   "com" zone name server for the "example.com" NS RRSet to verify that
-   it has the proper delegation information.  This implementation
-   performs this query to a zone's parent zone for each recursive query
-   it receives that fails because of a completely unresponsive set of
-   name servers for the target zone.  Consider the effect when a popular
-   zone experiences a catastrophic failure of all its name servers: now
-   every recursive query for domain names in that zone sent to this
-   recursive name server implementation results in a query to the failed
-   zone's parent name servers.  On one occasion when several dozen
-   popular zones became unreachable, the query load on the com/net name
-   servers increased by 50%.
-
-   We believe this verification query is not reasonable.  Consider the
-   circumstances: when an iterative resolver is resolving a query for a
-   domain name in a zone it has not previously searched, it uses the
-   list of name servers in the referral from the target zone's parent.
-   If on its first attempt to search the target zone, none of the name
-   servers in the referral is reachable, a verification query to the
-   parent would be pointless: this query to the parent would come so
-   quickly on the heels of the referral that it would be almost certain
-   to contain the same list of name servers.  The chance of discovering
-   any new information is slim.
-
-   The other possibility is that the iterative resolver successfully
-   contacts one of the target zone's name servers and then caches the NS
-   RRSet from the authority section of a response, the proper behavior
-   according to Section 5.4.1 of RFC 2181 [3], because the NS RRSet from
-   the target zone is more trustworthy than delegation information from
-   the parent zone.  If, while processing a subsequent recursive query,
-   the iterative resolver discovers that none of the name servers
-
-
-
-Larson & Barber          Best Current Practice                  [Page 4]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-   specified in the cached NS RRSet is available or authoritative,
-   querying the parent would be wrong.  An NS RRSet from the parent zone
-   would now be less trustworthy than data already in the cache.
-
-   For this query of the parent zone to be useful, the target zone's
-   entire set of name servers would have to change AND the former set of
-   name servers would have to be deconfigured or decommissioned AND the
-   delegation information in the parent zone would have to be updated
-   with the new set of name servers, all within the Time to Live (TTL)
-   of the target zone's NS RRSet.  We believe this scenario is uncommon:
-   administrative best practices dictate that changes to a zone's set of
-   name servers happen gradually when at all possible, with servers
-   removed from the NS RRSet left authoritative for the zone as long as
-   possible.  The scenarios that we can envision that would benefit from
-   the parent requery behavior do not outweigh its damaging effects.
-
-   This section should not be understood to claim that all queries to a
-   zone's parent are bad.  In some cases, such queries are not only
-   reasonable but required.  Consider the situation when required
-   information, such as the address of a name server (i.e., the address
-   record corresponding to the RDATA of an NS record), has timed out of
-   an iterative resolver's cache before the corresponding NS record.  If
-   the name of the name server is below the apex of the zone, then the
-   name server's address record is only available as glue in the parent
-   zone.  For example, consider this NS record:
-
-     example.com.        IN   NS   ns.example.com.
-
-   If a cache has this NS record but not the address record for
-   "ns.example.com", it is unable to contact the "example.com" zone
-   directly and must query the "com" zone to obtain the address record.
-   Note, however, that such a query would not have QTYPE=NS according to
-   the standard resolution algorithm.
-
-2.1.1.  Recommendation
-
-   An iterative resolver MUST NOT send a query for the NS RRSet of a
-   non-responsive zone to any of the name servers for that zone's parent
-   zone.  For the purposes of this injunction, a non-responsive zone is
-   defined as a zone for which every name server listed in the zone's NS
-   RRSet:
-
-   1.  is not authoritative for the zone (i.e., lame), or
-
-   2.  returns a server failure response (RCODE=2), or
-
-   3.  is dead or unreachable according to Section 7.2 of RFC 2308 [4].
-
-
-
-
-Larson & Barber          Best Current Practice                  [Page 5]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-2.2.  Repeated Queries to Lame Servers
-
-   Section 2.1 describes a catastrophic failure: when every name server
-   for a zone is unable to provide an answer for one reason or another.
-   A more common occurrence is when a subset of a zone's name servers is
-   unavailable or misconfigured.  Different failure modes have different
-   expected durations.  Some symptoms indicate problems that are
-   potentially transient, for example, various types of ICMP unreachable
-   messages because a name server process is not running or a host or
-   network is unreachable, or a complete lack of a response to a query.
-   Such responses could be the result of a host rebooting or temporary
-   outages; these events do not necessarily require any human
-   intervention and can be reasonably expected to be temporary.
-
-   Other symptoms clearly indicate a condition requiring human
-   intervention, such as lame server: if a name server is misconfigured
-   and not authoritative for a zone delegated to it, it is reasonable to
-   assume that this condition has potential to last longer than
-   unreachability or unresponsiveness.  Consequently, repeated queries
-   to known lame servers are not useful.  In this case of a condition
-   with potential to persist for a long time, a better practice would be
-   to maintain a list of known lame servers and avoid querying them
-   repeatedly in a short interval.
-
-   It should also be noted, however, that some authoritative name server
-   implementations appear to be lame only for queries of certain types
-   as described in RFC 4074 [5].  In this case, it makes sense to retry
-   the "lame" servers for other types of queries, particularly when all
-   known authoritative name servers appear to be "lame".
-
-2.2.1.  Recommendation
-
-   Iterative resolvers SHOULD cache name servers that they discover are
-   not authoritative for zones delegated to them (i.e., lame servers).
-   If this caching is performed, lame servers MUST be cached against the
-   specific query tuple <zone name, class, server IP address>.  Zone
-   name can be derived from the owner name of the NS record that was
-   referenced to query the name server that was discovered to be lame.
-
-   Implementations that perform lame server caching MUST refrain from
-   sending queries to known lame servers for a configurable time
-   interval after the server is discovered to be lame.  A minimum
-   interval of thirty minutes is RECOMMENDED.
-
-
-
-
-
-
-
-
-Larson & Barber          Best Current Practice                  [Page 6]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-   An exception to this recommendation occurs if all name servers for a
-   zone are marked lame.  In that case, the iterative resolver SHOULD
-   temporarily ignore the servers' lameness status and query one or more
-   servers.  This behavior is a workaround for the type-specific
-   lameness issue described in the previous section.
-
-   Implementors should take care not to make lame server avoidance logic
-   overly broad: note that a name server could be lame for a parent zone
-   but not a child zone, e.g., lame for "example.com" but properly
-   authoritative for "sub.example.com".  Therefore, a name server should
-   not be automatically considered lame for subzones.  In the case
-   above, even if a name server is known to be lame for "example.com",
-   it should be queried for QNAMEs at or below "sub.example.com" if an
-   NS record indicates that it should be authoritative for that zone.
-
-2.3.  Inability to Follow Multiple Levels of Indirection
-
-   Some iterative resolver implementations are unable to follow
-   sufficient levels of indirection.  For example, consider the
-   following delegations:
-
-     foo.example.        IN   NS   ns1.example.com.
-     foo.example.        IN   NS   ns2.example.com.
-
-     example.com.        IN   NS   ns1.test.example.net.
-     example.com.        IN   NS   ns2.test.example.net.
-
-     test.example.net.   IN   NS   ns1.test.example.net.
-     test.example.net.   IN   NS   ns2.test.example.net.
-
-   An iterative resolver resolving the name "www.foo.example" must
-   follow two levels of indirection, first obtaining address records for
-   "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
-   address records for "ns1.example.com" or "ns2.example.com" in order
-   to query those name servers for the address records of
-   "www.foo.example".  Although this situation may appear contrived, we
-   have seen multiple similar occurrences and expect more as new generic
-   top-level domains (gTLDs) become active.  We anticipate many zones in
-   new gTLDs will use name servers in existing gTLDs, increasing the
-   number of delegations using out-of-zone name servers.
-
-2.3.1.  Recommendation
-
-   Clearly constructing a delegation that relies on multiple levels of
-   indirection is not a good administrative practice.  However, the
-   practice is widespread enough to require that iterative resolvers be
-   able to cope with it.  Iterative resolvers SHOULD be able to handle
-   arbitrary levels of indirection resulting from out-of-zone name
-
-
-
-Larson & Barber          Best Current Practice                  [Page 7]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-   servers.  Iterative resolvers SHOULD implement a level-of-effort
-   counter to avoid loops or otherwise performing too much work in
-   resolving pathological cases.
-
-   A best practice that avoids this entire issue of indirection is to
-   name one or more of a zone's name servers in the zone itself.  For
-   example, if the zone is named "example.com", consider naming some of
-   the name servers "ns{1,2,...}.example.com" (or similar).
-
-2.4.  Aggressive Retransmission when Fetching Glue
-
-   When an authoritative name server responds with a referral, it
-   includes NS records in the authority section of the response.
-   According to the algorithm in Section 4.3.2 of RFC 1034 [2], the name
-   server should also "put whatever addresses are available into the
-   additional section, using glue RRs if the addresses are not available
-   from authoritative data or the cache."  Some name server
-   implementations take this address inclusion a step further with a
-   feature called "glue fetching".  A name server that implements glue
-   fetching attempts to include address records for every NS record in
-   the authority section.  If necessary, the name server issues multiple
-   queries of its own to obtain any missing address records.
-
-   Problems with glue fetching can arise in the context of
-   "authoritative-only" name servers, which only serve authoritative
-   data and ignore requests for recursion.  Such an entity will not
-   normally generate any queries of its own.  Instead it answers non-
-   recursive queries from iterative resolvers looking for information in
-   zones it serves.  With glue fetching enabled, however, an
-   authoritative server invokes an iterative resolver to look up an
-   unknown address record to complete the additional section of a
-   response.
-
-   We have observed situations where the iterative resolver of a glue-
-   fetching name server can send queries that reach other name servers,
-   but is apparently prevented from receiving the responses.  For
-   example, perhaps the name server is authoritative-only and therefore
-   its administrators expect it to receive only queries and not
-   responses.  Perhaps unaware of glue fetching and presuming that the
-   name server's iterative resolver will generate no queries, its
-   administrators place the name server behind a network device that
-   prevents it from receiving responses.  If this is the case, all
-   glue-fetching queries will go unanswered.
-
-   We have observed name server implementations whose iterative
-   resolvers retry excessively when glue-fetching queries are
-   unanswered.  A single com/net name server has received hundreds of
-   queries per second from a single such source.  Judging from the
-
-
-
-Larson & Barber          Best Current Practice                  [Page 8]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-   specific queries received and based on additional analysis, we
-   believe these queries result from overly aggressive glue fetching.
-
-2.4.1.  Recommendation
-
-   Implementers whose name servers support glue fetching SHOULD take
-   care to avoid sending queries at excessive rates.  Implementations
-   SHOULD support throttling logic to detect when queries are sent but
-   no responses are received.
-
-2.5.  Aggressive Retransmission behind Firewalls
-
-   A common occurrence and one of the largest sources of repeated
-   queries at the com/net and root name servers appears to result from
-   resolvers behind misconfigured firewalls.  In this situation, an
-   iterative resolver is apparently allowed to send queries through a
-   firewall to other name servers, but not receive the responses.  The
-   result is more queries than necessary because of retransmission, all
-   of which are useless because the responses are never received.  Just
-   as with the glue-fetching scenario described in Section 2.4, the
-   queries are sometimes sent at excessive rates.  To make matters
-   worse, sometimes the responses, sent in reply to legitimate queries,
-   trigger an alarm on the originator's intrusion detection system.  We
-   are frequently contacted by administrators responding to such alarms
-   who believe our name servers are attacking their systems.
-
-   Not only do some resolvers in this situation retransmit queries at an
-   excessive rate, but they continue to do so for days or even weeks.
-   This scenario could result from an organization with multiple
-   recursive name servers, only a subset of whose iterative resolvers'
-   traffic is improperly filtered in this manner.  Stub resolvers in the
-   organization could be configured to query multiple recursive name
-   servers.  Consider the case where a stub resolver queries a filtered
-   recursive name server first.  The iterative resolver of this
-   recursive name server sends one or more queries whose replies are
-   filtered, so it cannot respond to the stub resolver, which times out.
-   Then the stub resolver retransmits to a recursive name server that is
-   able to provide an answer.  Since resolution ultimately succeeds the
-   underlying problem might not be recognized or corrected.  A popular
-   stub resolver implementation has a very aggressive retransmission
-   schedule, including simultaneous queries to multiple recursive name
-   servers, which could explain how such a situation could persist
-   without being detected.
-
-
-
-
-
-
-
-
-Larson & Barber          Best Current Practice                  [Page 9]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-2.5.1.  Recommendation
-
-   The most obvious recommendation is that administrators SHOULD take
-   care not to place iterative resolvers behind a firewall that allows
-   queries, but not the resulting replies, to pass through.
-
-   Iterative resolvers SHOULD take care to avoid sending queries at
-   excessive rates.  Implementations SHOULD support throttling logic to
-   detect when queries are sent but no responses are received.
-
-2.6.  Misconfigured NS Records
-
-   Sometimes a zone administrator forgets to add the trailing dot on the
-   domain names in the RDATA of a zone's NS records.  Consider this
-   fragment of the zone file for "example.com":
-
-     $ORIGIN example.com.
-     example.com.      3600   IN   NS   ns1.example.com  ; Note missing
-     example.com.      3600   IN   NS   ns2.example.com  ; trailing dots
-
-   The zone's authoritative servers will parse the NS RDATA as
-   "ns1.example.com.example.com" and "ns2.example.com.example.com" and
-   return NS records with this incorrect RDATA in responses, including
-   typically the authority section of every response containing records
-   from the "example.com" zone.
-
-   Now consider a typical sequence of queries.  An iterative resolver
-   attempting to resolve address records for "www.example.com" with no
-   cached information for this zone will query a "com" authoritative
-   server.  The "com" server responds with a referral to the
-   "example.com" zone, consisting of NS records with valid RDATA and
-   associated glue records.  (This example assumes that the
-   "example.com" zone delegation information is correct in the "com"
-   zone.)  The iterative resolver caches the NS RRSet from the "com"
-   server and follows the referral by querying one of the "example.com"
-   authoritative servers.  This server responds with the
-   "www.example.com" address record in the answer section and,
-   typically, the "example.com" NS records in the authority section and,
-   if space in the message remains, glue address records in the
-   additional section.  According to Section 5.4.1 of RFC 2181 [3], NS
-   records in the authority section of an authoritative answer are more
-   trustworthy than NS records from the authority section of a non-
-   authoritative answer.  Thus, the "example.com" NS RRSet just received
-   from the "example.com" authoritative server overrides the
-   "example.com" NS RRSet received moments ago from the "com"
-   authoritative server.
-
-
-
-
-
-Larson & Barber          Best Current Practice                 [Page 10]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-   But the "example.com" zone contains the erroneous NS RRSet as shown
-   in the example above.  Subsequent queries for names in "example.com"
-   will cause the iterative resolver to attempt to use the incorrect NS
-   records and so it will try to resolve the nonexistent names
-   "ns1.example.com.example.com" and "ns2.example.com.example.com".  In
-   this example, since all of the zone's name servers are named in the
-   zone itself (i.e., "ns1.example.com.example.com" and
-   "ns2.example.com.example.com" both end in "example.com") and all are
-   bogus, the iterative resolver cannot reach any "example.com" name
-   servers.  Therefore, attempts to resolve these names result in
-   address record queries to the "com" authoritative servers.  Queries
-   for such obviously bogus glue address records occur frequently at the
-   com/net name servers.
-
-2.6.1.  Recommendation
-
-   An authoritative server can detect this situation.  A trailing dot
-   missing from an NS record's RDATA always results by definition in a
-   name server name that exists somewhere under the apex of the zone
-   that the NS record appears in.  Note that further levels of
-   delegation are possible, so a missing trailing dot could
-   inadvertently create a name server name that actually exists in a
-   subzone.
-
-   An authoritative name server SHOULD issue a warning when one of a
-   zone's NS records references a name server below the zone's apex when
-   a corresponding address record does not exist in the zone AND there
-   are no delegated subzones where the address record could exist.
-
-2.7.  Name Server Records with Zero TTL
-
-   Sometimes a popular com/net subdomain's zone is configured with a TTL
-   of zero on the zone's NS records, which prohibits these records from
-   being cached and will result in a higher query volume to the zone's
-   authoritative servers.  The zone's administrator should understand
-   the consequences of such a configuration and provision resources
-   accordingly.  A zero TTL on the zone's NS RRSet, however, carries
-   additional consequences beyond the zone itself: if an iterative
-   resolver cannot cache a zone's NS records because of a zero TTL, it
-   will be forced to query that zone's parent's name servers each time
-   it resolves a name in the zone.  The com/net authoritative servers do
-   see an increased query load when a popular com/net subdomain's zone
-   is configured with a TTL of zero on the zone's NS records.
-
-   A zero TTL on an RRSet expected to change frequently is extreme but
-   permissible.  A zone's NS RRSet is a special case, however, because
-   changes to it must be coordinated with the zone's parent.  In most
-   zone parent/child relationships that we are aware of, there is
-
-
-
-Larson & Barber          Best Current Practice                 [Page 11]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-   typically some delay involved in effecting changes.  Furthermore,
-   changes to the set of a zone's authoritative name servers (and
-   therefore to the zone's NS RRSet) are typically relatively rare:
-   providing reliable authoritative service requires a reasonably stable
-   set of servers.  Therefore, an extremely low or zero TTL on a zone's
-   NS RRSet rarely makes sense, except in anticipation of an upcoming
-   change.  In this case, when the zone's administrator has planned a
-   change and does not want iterative resolvers throughout the Internet
-   to cache the NS RRSet for a long period of time, a low TTL is
-   reasonable.
-
-2.7.1.  Recommendation
-
-   Because of the additional load placed on a zone's parent's
-   authoritative servers resulting from a zero TTL on a zone's NS RRSet,
-   under such circumstances authoritative name servers SHOULD issue a
-   warning when loading a zone.
-
-2.8.  Unnecessary Dynamic Update Messages
-
-   The UPDATE message specified in RFC 2136 [6] allows an authorized
-   agent to update a zone's data on an authoritative name server using a
-   DNS message sent over the network.  Consider the case of an agent
-   desiring to add a particular resource record.  Because of zone cuts,
-   the agent does not necessarily know the proper zone to which the
-   record should be added.  The dynamic update process requires that the
-   agent determine the appropriate zone so the UPDATE message can be
-   sent to one of the zone's authoritative servers (typically the
-   primary master as specified in the zone's Start of Authority (SOA)
-   record's MNAME field).
-
-   The appropriate zone to update is the closest enclosing zone, which
-   cannot be determined only by inspecting the domain name of the record
-   to be updated, since zone cuts can occur anywhere.  One way to
-   determine the closest enclosing zone entails walking up the name
-   space tree by sending repeated UPDATE messages until successful.  For
-   example, consider an agent attempting to add an address record with
-   the name "foo.bar.example.com".  The agent could first attempt to
-   update the "foo.bar.example.com" zone.  If the attempt failed, the
-   update could be directed to the "bar.example.com" zone, then the
-   "example.com" zone, then the "com" zone, and finally the root zone.
-
-   A popular dynamic agent follows this algorithm.  The result is many
-   UPDATE messages received by the root name servers, the com/net
-   authoritative servers, and presumably other TLD authoritative
-   servers.  A valid question is why the algorithm proceeds to send
-   updates all the way to TLD and root name servers.  This behavior is
-   not entirely unreasonable: in enterprise DNS architectures with an
-
-
-
-Larson & Barber          Best Current Practice                 [Page 12]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-   "internal root" design, there could conceivably be private, non-
-   public TLD or root zones that would be the appropriate targets for a
-   dynamic update.
-
-   A significant deficiency with this algorithm is that knowledge of a
-   given UPDATE message's failure is not helpful in directing future
-   UPDATE messages to the appropriate servers.  A better algorithm would
-   be to find the closest enclosing zone by walking up the name space
-   with queries for SOA or NS rather than "probing" with UPDATE
-   messages.  Once the appropriate zone is found, an UPDATE message can
-   be sent.  In addition, the results of these queries can be cached to
-   aid in determining the closest enclosing zones for future updates.
-   Once the closest enclosing zone is determined with this method, the
-   update will either succeed or fail and there is no need to send
-   further updates to higher-level zones.  The important point is that
-   walking up the tree with queries yields cacheable information,
-   whereas walking up the tree by sending UPDATE messages does not.
-
-2.8.1.  Recommendation
-
-   Dynamic update agents SHOULD send SOA or NS queries to progressively
-   higher-level names to find the closest enclosing zone for a given
-   name to update.  Only after the appropriate zone is found should the
-   client send an UPDATE message to one of the zone's authoritative
-   servers.  Update clients SHOULD NOT "probe" using UPDATE messages by
-   walking up the tree to progressively higher-level zones.
-
-2.9.  Queries for Domain Names Resembling IPv4 Addresses
-
-   The root name servers receive a significant number of A record
-   queries where the QNAME looks like an IPv4 address.  The source of
-   these queries is unknown.  It could be attributed to situations where
-   a user believes that an application will accept either a domain name
-   or an IP address in a given configuration option.  The user enters an
-   IP address, but the application assumes that any input is a domain
-   name and attempts to resolve it, resulting in an A record lookup.
-   There could also be applications that produce such queries in a
-   misguided attempt to reverse map IP addresses.
-
-   These queries result in Name Error (RCODE=3) responses.  An iterative
-   resolver can negatively cache such responses, but each response
-   requires a separate cache entry; i.e., a negative cache entry for the
-   domain name "192.0.2.1" does not prevent a subsequent query for the
-   domain name "192.0.2.2".
-
-
-
-
-
-
-
-Larson & Barber          Best Current Practice                 [Page 13]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-2.9.1.  Recommendation
-
-   It would be desirable for the root name servers not to have to answer
-   these queries: they unnecessarily consume CPU resources and network
-   bandwidth.  A possible solution is to delegate these numeric TLDs
-   from the root zone to a separate set of servers to absorb the
-   traffic.  The "black hole servers" used by the AS 112 Project
-   (http://www.as112.net), which are currently delegated the
-   in-addr.arpa zones corresponding to RFC 1918 [7] private use address
-   space, would be a possible choice to receive these delegations.  Of
-   course, the proper and usual root zone change procedures would have
-   to be followed to make such a change to the root zone.
-
-2.10.  Misdirected Recursive Queries
-
-   The root name servers receive a significant number of recursive
-   queries (i.e., queries with the Recursion Desired (RD) bit set in the
-   header).  Since none of the root servers offers recursion, the
-   servers' response in such a situation ignores the request for
-   recursion and the response probably does not contain the data the
-   querier anticipated.  Some of these queries result from users
-   configuring stub resolvers to query a root server.  (This situation
-   is not hypothetical: we have received complaints from users when this
-   configuration does not work as hoped.)  Of course, users should not
-   direct stub resolvers to use name servers that do not offer
-   recursion, but we are not aware of any stub resolver implementation
-   that offers any feedback to the user when so configured, aside from
-   simply "not working".
-
-2.10.1.  Recommendation
-
-   When the IP address of a name server that supposedly offers recursion
-   is configured in a stub resolver using an interactive user interface,
-   the resolver could send a test query to verify that the server indeed
-   supports recursion (i.e., verify that the response has the RA bit set
-   in the header).  The user could be notified immediately if the server
-   is non-recursive.
-
-   The stub resolver could also report an error, either through a user
-   interface or in a log file, if the queried server does not support
-   recursion.  Error reporting SHOULD be throttled to avoid a
-   notification or log message for every response from a non-recursive
-   server.
-
-
-
-
-
-
-
-
-Larson & Barber          Best Current Practice                 [Page 14]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-2.11.  Suboptimal Name Server Selection Algorithm
-
-   An entire document could be devoted to the topic of problems with
-   different implementations of the recursive resolution algorithm.  The
-   entire process of recursion is woefully under-specified, requiring
-   each implementor to design an algorithm.  Sometimes implementors make
-   poor design choices that could be avoided if a suggested algorithm
-   and best practices were documented, but that is a topic for another
-   document.
-
-   Some deficiencies cause significant operational impact and are
-   therefore worth mentioning here.  One of these is name server
-   selection by an iterative resolver.  When an iterative resolver wants
-   to contact one of a zone's authoritative name servers, how does it
-   choose from the NS records listed in the zone's NS RRSet?  If the
-   selection mechanism is suboptimal, queries are not spread evenly
-   among a zone's authoritative servers.  The details of the selection
-   mechanism are up to the implementor, but we offer some suggestions.
-
-2.11.1.  Recommendation
-
-   This list is not conclusive, but reflects the changes that would
-   produce the most impact in terms of reducing disproportionate query
-   load among a zone's authoritative servers.  That is, these changes
-   would help spread the query load evenly.
-
-   o  Do not make assumptions based on NS RRSet order: all NS RRs SHOULD
-      be treated equally.  (In the case of the "com" zone, for example,
-      most of the root servers return the NS record for
-      "a.gtld-servers.net" first in the authority section of referrals.
-      Apparently as a result, this server receives disproportionately
-      more traffic than the other twelve authoritative servers for
-      "com".)
-
-   o  Use all NS records in an RRSet.  (For example, we are aware of
-      implementations that hard-coded information for a subset of the
-      root servers.)
-
-   o  Maintain state and favor the best-performing of a zone's
-      authoritative servers.  A good definition of performance is
-      response time.  Non-responsive servers can be penalized with an
-      extremely high response time.
-
-   o  Do not lock onto the best-performing of a zone's name servers.  An
-      iterative resolver SHOULD periodically check the performance of
-      all of a zone's name servers to adjust its determination of the
-      best-performing one.
-
-
-
-
-Larson & Barber          Best Current Practice                 [Page 15]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-3.  Security Considerations
-
-   The iterative resolver misbehavior discussed in this document exposes
-   the root and TLD name servers to increased risk of both intentional
-   and unintentional Denial of Service attacks.
-
-   We believe that implementation of the recommendations offered in this
-   document will reduce the amount of unnecessary traffic seen at root
-   and TLD name servers, thus reducing the opportunity for an attacker
-   to use such queries to his or her advantage.
-
-4.  Acknowledgements
-
-   The authors would like to thank the following people for their
-   comments that improved this document: Andras Salamon, Dave Meyer,
-   Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy,
-   Olafur Gudmundsson, Pekka Savola, Peter Koch, and Rob Austein.  We
-   apologize if we have omitted anyone; any oversight was unintentional.
-
-5.  Internationalization Considerations
-
-   There are no new internationalization considerations introduced by
-   this memo.
-
-6.  References
-
-6.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-6.2.  Informative References
-
-   [3]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-        RFC 2181, July 1997.
-
-   [4]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
-        2308, March 1998.
-
-   [5]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
-        Queries for IPv6 Addresses", RFC 4074, May 2005.
-
-   [6]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
-        Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
-        1997.
-
-
-
-Larson & Barber          Best Current Practice                 [Page 16]
-
-RFC 4697          Observed DNS Resolution Misbehavior       October 2006
-
-
-   [7]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E.
-        Lear, "Address Allocation for Private Internets", BCP 5, RFC
-        1918, February 1996.
-
-Authors' Addresses
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: mlarson@verisign.com
-
-
-   Piet Barber
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: pbarber@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Best Current Practice                 [Page 17]
-
-RFC 4697          Observed DNS Resolution Misbehavior       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).
-
-
-
-
-
-
-
-Larson & Barber          Best Current Practice                 [Page 18]
-
diff --git a/doc/rfc/rfc4701.txt b/doc/rfc/rfc4701.txt
deleted file mode 100644
index 03e3c543..00000000
--- a/doc/rfc/rfc4701.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           M. Stapp
-Request for Comments: 4701                           Cisco Systems, Inc.
-Category: Standards Track                                       T. Lemon
-                                                           Nominum, Inc.
-                                                           A. Gustafsson
-                                          Araneus Information Systems Oy
-                                                            October 2006
-
-
-                A DNS Resource Record (RR) for Encoding
-   Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   It is possible for Dynamic Host Configuration Protocol (DHCP) clients
-   to attempt to update the same DNS Fully Qualified Domain Name (FQDN)
-   or to update a DNS FQDN that has been added to the DNS for another
-   purpose as they obtain DHCP leases.  Whether the DHCP server or the
-   clients themselves perform the DNS updates, conflicts can arise.  To
-   resolve such conflicts, RFC 4703 proposes storing client identifiers
-   in the DNS to unambiguously associate domain names with the DHCP
-   clients to which they refer.  This memo defines a distinct Resource
-   Record (RR) type for this purpose for use by DHCP clients and
-   servers:  the "DHCID" RR.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 1]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. Terminology .....................................................3
-   3. The DHCID RR ....................................................3
-      3.1. DHCID RDATA Format .........................................3
-      3.2. DHCID Presentation Format ..................................4
-      3.3. The DHCID RR Identifier Type Codes .........................4
-      3.4. The DHCID RR Digest Type Code ..............................4
-      3.5. Computation of the RDATA ...................................5
-           3.5.1. Using the Client's DUID .............................5
-           3.5.2. Using the Client Identifier Option ..................6
-           3.5.3. Using the Client's htype and chaddr .................6
-      3.6. Examples ...................................................6
-           3.6.1. Example 1 ...........................................6
-           3.6.2. Example 2 ...........................................7
-           3.6.3. Example 3 ...........................................7
-   4. Use of the DHCID RR .............................................8
-   5. Updater Behavior ................................................8
-   6. Security Considerations .........................................8
-   7. IANA Considerations .............................................9
-   8. Acknowledgements ................................................9
-   9. References ......................................................9
-      9.1. Normative References .......................................9
-      9.2. Informative References ....................................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 2]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-1.  Introduction
-
-   A set of procedures to allow DHCP [7] [11] clients and servers to
-   automatically update the DNS ([3], [4]) is proposed in [1].
-
-   Conflicts can arise if multiple DHCP clients wish to use the same DNS
-   name or a DHCP client attempts to use a name added for another
-   purpose.  To resolve such conflicts, [1] proposes storing client
-   identifiers in the DNS to unambiguously associate domain names with
-   the DHCP clients using them.  In the interest of clarity, it is
-   preferable for this DHCP information to use a distinct RR type.  This
-   memo defines a distinct RR for this purpose for use by DHCP clients
-   or servers: the "DHCID" RR.
-
-   In order to obscure potentially sensitive client identifying
-   information, the data stored is the result of a one-way SHA-256 hash
-   computation.  The hash includes information from the DHCP client's
-   message as well as the domain name itself, so that the data stored in
-   the DHCID RR will be dependent on both the client identification used
-   in the DHCP protocol interaction and the domain name.  This means
-   that the DHCID RDATA will vary if a single client is associated over
-   time with more than one name.  This makes it difficult to 'track' a
-   client as it is associated with various domain names.
-
-2.  Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [2].
-
-3.  The DHCID RR
-
-   The DHCID RR is defined with mnemonic DHCID and type code 49.  The
-   DHCID RR is only defined in the IN class.  DHCID RRs cause no
-   additional section processing.
-
-3.1.  DHCID RDATA Format
-
-   The RDATA section of a DHCID RR in transmission contains RDLENGTH
-   octets of binary data.  The format of this data and its
-   interpretation by DHCP servers and clients are described below.
-
-   DNS software should consider the RDATA section to be opaque.  DHCP
-   clients or servers use the DHCID RR to associate a DHCP client's
-   identity with a DNS name, so that multiple DHCP clients and servers
-   may deterministically perform dynamic DNS updates to the same zone.
-   From the updater's perspective, the DHCID resource record RDATA
-   consists of a 2-octet identifier type, in network byte order,
-
-
-
-Stapp, et al.               Standards Track                     [Page 3]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-   followed by a 1-octet digest type, followed by one or more octets
-   representing the actual identifier:
-
-           < 2 octets >    Identifier type code
-           < 1 octet >     Digest type code
-           < n octets >    Digest (length depends on digest type)
-
-3.2.  DHCID Presentation Format
-
-   In DNS master files, the RDATA is represented as a single block in
-   base-64 encoding identical to that used for representing binary data
-   in [8], Section 3.  The data may be divided up into any number of
-   white-space-separated substrings, down to single base-64 digits,
-   which are concatenated to form the complete RDATA.  These substrings
-   can span lines using the standard parentheses.
-
-3.3.  The DHCID RR Identifier Type Codes
-
-   The DHCID RR Identifier Type Code specifies what data from the DHCP
-   client's request was used as input into the hash function.  The
-   identifier type codes are defined in a registry maintained by IANA,
-   as specified in Section 7.  The initial list of assigned values for
-   the identifier type code and that type's identifier is:
-
-
-   +------------------+------------------------------------------------+
-   |  Identifier Type | Identifier                                     |
-   |       Code       |                                                |
-   +------------------+------------------------------------------------+
-   |      0x0000      | The 1-octet 'htype' followed by 'hlen' octets  |
-   |                  | of 'chaddr' from a DHCPv4 client's DHCPREQUEST |
-   |                  | [7].                                           |
-   |      0x0001      | The data octets (i.e., the Type and            |
-   |                  | Client-Identifier fields) from a DHCPv4        |
-   |                  | client's Client Identifier option [10].        |
-   |      0x0002      | The client's DUID (i.e., the data octets of a  |
-   |                  | DHCPv6 client's Client Identifier option [11]  |
-   |                  | or the DUID field from a DHCPv4 client's       |
-   |                  | Client Identifier option [6]).                 |
-   |  0x0003 - 0xfffe | Undefined; available to be assigned by IANA.   |
-   |      0xffff      | Undefined; RESERVED.                           |
-   +------------------+------------------------------------------------+
-
-3.4.  The DHCID RR Digest Type Code
-
-   The DHCID RR Digest Type Code is an identifier for the digest
-   algorithm used.  The digest is calculated over an identifier and the
-   canonical FQDN as described in the next section.
-
-
-
-Stapp, et al.               Standards Track                     [Page 4]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-   The digest type codes are defined in a registry maintained by IANA,
-   as specified in Section 7.  The initial list of assigned values for
-   the digest type codes is: value 0 is reserved, and value 1 is
-   SHA-256.  Reserving other types requires IETF standards action.
-   Defining new values will also require IETF standards action to
-   document how DNS updaters are to deal with multiple digest types.
-
-3.5.  Computation of the RDATA
-
-   The DHCID RDATA is formed by concatenating the 2-octet identifier
-   type code with variable-length data.
-
-   The RDATA for all type codes other than 0xffff, which is reserved for
-   future expansion, is formed by concatenating the 2-octet identifier
-   type code, the 1-octet digest type code, and the digest value (32
-   octets for SHA-256).
-
-       < identifier-type > < digest-type > < digest >
-
-   The input to the digest hash function is defined to be:
-
-       digest = SHA-256(< identifier > < FQDN >)
-
-   The FQDN is represented in the buffer in the canonical wire format as
-   described in [9], Section 6.2.  The identifier type code and the
-   identifier are related as specified in Section 3.3: the identifier
-   type code describes the source of the identifier.
-
-   A DHCPv4 updater uses the 0x0002 type code if a Client Identifier
-   option is present in the DHCPv4 messages and it is encoded as
-   specified in [6].  Otherwise, the updater uses 0x0001 if a Client
-   Identifier option is present, and 0x0000 if not.
-
-   A DHCPv6 updater always uses the 0x0002 type code.
-
-3.5.1.  Using the Client's DUID
-
-   When the updater is using the Client's DUID (either from a DHCPv6
-   Client Identifier option or from a portion of the DHCPv4 Client
-   Identifier option encoded as specified in [6]), the first two octets
-   of the DHCID RR MUST be 0x0002, in network byte order.  The third
-   octet is the digest type code (1 for SHA-256).  The rest of the DHCID
-   RR MUST contain the results of computing the SHA-256 hash across the
-   octets of the DUID followed by the FQDN.
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 5]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-3.5.2.  Using the Client Identifier Option
-
-   When the updater is using the DHCPv4 Client Identifier option sent by
-   the client in its DHCPREQUEST message, the first two octets of the
-   DHCID RR MUST be 0x0001, in network byte order.  The third octet is
-   the digest type code (1 for SHA-256).  The rest of the DHCID RR MUST
-   contain the results of computing the SHA-256 hash across the data
-   octets (i.e., the Type and Client-Identifier fields) of the option,
-   followed by the FQDN.
-
-3.5.3.  Using the Client's htype and chaddr
-
-   When the updater is using the client's link-layer address as the
-   identifier, the first two octets of the DHCID RDATA MUST be zero.
-   The third octet is the digest type code (1 for SHA-256).  To generate
-   the rest of the resource record, the updater computes a one-way hash
-   using the SHA-256 algorithm across a buffer containing the client's
-   network hardware type, link-layer address, and the FQDN data.
-   Specifically, the first octet of the buffer contains the network
-   hardware type as it appeared in the DHCP 'htype' field of the
-   client's DHCPREQUEST message.  All of the significant octets of the
-   'chaddr' field in the client's DHCPREQUEST message follow, in the
-   same order in which the octets appear in the DHCPREQUEST message.
-   The number of significant octets in the 'chaddr' field is specified
-   in the 'hlen' field of the DHCPREQUEST message.  The FQDN data, as
-   specified above, follows.
-
-3.6.  Examples
-
-3.6.1.  Example 1
-
-   A DHCP server allocates the IPv6 address 2001:DB8::1234:5678 to a
-   client that included the DHCPv6 client-identifier option data 00:01:
-   00:06:41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request.  The
-   server updates the name "chi6.example.com" on the client's behalf and
-   uses the DHCP client identifier option data as input in forming a
-   DHCID RR.  The DHCID RDATA is formed by setting the two type octets
-   to the value 0x0002, the 1-octet digest type to 1 for SHA-256, and
-   performing a SHA-256 hash computation across a buffer containing the
-   14 octets from the client-id option and the FQDN (represented as
-   specified in Section 3.5).
-
-     chi6.example.com.     AAAA    2001:DB8::1234:5678
-     chi6.example.com.     DHCID   ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
-                                     OjxfNuVAA2kjEA= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-
-
-Stapp, et al.               Standards Track                     [Page 6]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-     \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
-             b95000da48c40 )
-
-3.6.2.  Example 2
-
-   A DHCP server allocates the IPv4 address 192.0.2.2 to a client that
-   included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
-   in its DHCP request.  The server updates the name "chi.example.com"
-   on the client's behalf and uses the DHCP client identifier option
-   data as input in forming a DHCID RR.  The DHCID RDATA is formed by
-   setting the two type octets to the value 0x0001, the 1-octet digest
-   type to 1 for SHA-256, and performing a SHA-256 hash computation
-   across a buffer containing the seven octets from the client-id option
-   and the FQDN (represented as specified in Section 3.5).
-
-     chi.example.com.      A       192.0.2.2
-     chi.example.com.      DHCID   ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
-                                     L3b/NaiUDlW2No= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-     \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd
-             6a2503956d8da )
-
-3.6.3.  Example 3
-
-   A DHCP server allocating the IPv4 address 192.0.2.3 to a client with
-   the Ethernet MAC address 01:02:03:04:05:06 using domain name
-   "client.example.com" uses the client's link-layer address to identify
-   the client.  The DHCID RDATA is composed by setting the two type
-   octets to zero, the 1-octet digest type to 1 for SHA-256, and
-   performing an SHA-256 hash computation across a buffer containing the
-   1-octet 'htype' value for Ethernet, 0x01, followed by the six octets
-   of the Ethernet MAC address, and the domain name (represented as
-   specified in Section 3.5).
-
-     client.example.com.   A       192.0.2.3
-     client.example.com.   DHCID   ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
-                                     ytcKD//7es/deY= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-     \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
-             fffedeb3f75e6 )
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 7]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-4.  Use of the DHCID RR
-
-   This RR MUST NOT be used for any purpose other than that detailed in
-   [1].  Although this RR contains data that is opaque to DNS servers,
-   the data must be consistent across all entities that update and
-   interpret this record.  Therefore, new data formats may only be
-   defined through actions of the DHC Working Group, as a result of
-   revising [1].
-
-5.  Updater Behavior
-
-   The data in the DHCID RR allows updaters to determine whether more
-   than one DHCP client desires to use a particular FQDN.  This allows
-   site administrators to establish policy about DNS updates.  The DHCID
-   RR does not establish any policy itself.
-
-   Updaters use data from a DHCP client's request and the domain name
-   that the client desires to use to compute a client identity hash, and
-   then compare that hash to the data in any DHCID RRs on the name that
-   they wish to associate with the client's IP address.  If an updater
-   discovers DHCID RRs whose RDATA does not match the client identity
-   that they have computed, the updater SHOULD conclude that a different
-   client is currently associated with the name in question.  The
-   updater SHOULD then proceed according to the site's administrative
-   policy.  That policy might dictate that a different name be selected,
-   or it might permit the updater to continue.
-
-6.  Security Considerations
-
-   The DHCID record as such does not introduce any new security problems
-   into the DNS.  In order to obscure the client's identity information,
-   a one-way hash is used.  Further, in order to make it difficult to
-   'track' a client by examining the names associated with a particular
-   hash value, the FQDN is included in the hash computation.  Thus, the
-   RDATA is dependent on both the DHCP client identification data and on
-   each FQDN associated with the client.
-
-   However, it should be noted that an attacker that has some knowledge,
-   such as of MAC addresses commonly used in DHCP client identification
-   data, may be able to discover the client's DHCP identify by using a
-   brute-force attack.  Even without any additional knowledge, the
-   number of unknown bits used in computing the hash is typically only
-   48 to 80.
-
-   Administrators should be wary of permitting unsecured DNS updates to
-   zones, whether or not they are exposed to the global Internet.  Both
-   DHCP clients and servers SHOULD use some form of update
-   authentication (e.g., [12]) when performing DNS updates.
-
-
-
-Stapp, et al.               Standards Track                     [Page 8]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-7.  IANA Considerations
-
-   IANA has allocated a DNS RR type number for the DHCID record type.
-
-   This specification defines a new number-space for the 2-octet
-   identifier type codes associated with the DHCID RR.  IANA has
-   established a registry of the values for this number-space.  Three
-   initial values are assigned in Section 3.3, and the value 0xFFFF is
-   reserved for future use.  New DHCID RR identifier type codes are
-   assigned through Standards Action, as defined in [5].
-
-   This specification defines a new number-space for the 1-octet digest
-   type codes associated with the DHCID RR.  IANA has established a
-   registry of the values for this number-space.  Two initial values are
-   assigned in Section 3.4.  New DHCID RR digest type codes are assigned
-   through Standards Action, as defined in [5].
-
-8.  Acknowledgements
-
-   Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson,
-   Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie
-   Volz for their review and suggestions.
-
-9.  References
-
-9.1.  Normative References
-
-   [1]  Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain
-        Name (FQDN) Conflicts among Dynamic Host Configuration Protocol
-        (DHCP) Clients", RFC 4703, October 2006.
-
-   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [3]  Mockapetris, P., "Domain names - concepts and facilities",
-        STD 13, RFC 1034, November 1987.
-
-   [4]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [6]  Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
-        for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
-        RFC 4361, February 2006.
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 9]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-9.2.  Informative References
-
-   [7]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-         March 1997.
-
-   [8]   Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-         RFC 3548, July 2003.
-
-   [9]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-   [10]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
-         Extensions", RFC 2132, March 1997.
-
-   [11]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
-         Carney, "Dynamic Host Configuration Protocol for IPv6
-         (DHCPv6)", RFC 3315, July 2003.
-
-   [12]  Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
-         "Secret Key Transaction Authentication for DNS (TSIG)",
-         RFC 2845, May 2000.
-
-   [13]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-         Types", RFC 3597, September 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                    [Page 10]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-Authors' Addresses
-
-   Mark Stapp
-   Cisco Systems, Inc.
-   1414 Massachusetts Ave.
-   Boxborough, MA  01719
-   USA
-
-   Phone: 978.936.1535
-   EMail: mjs@cisco.com
-
-
-   Ted Lemon
-   Nominum, Inc.
-   950 Charter St.
-   Redwood City, CA  94063
-   USA
-
-   EMail: mellon@nominum.com
-
-
-   Andreas Gustafsson
-   Araneus Information Systems Oy
-   Ulappakatu 1
-   02320 Espoo
-   Finland
-
-   EMail: gson@araneus.fi
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                    [Page 11]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                    [Page 12]
-
diff --git a/doc/rfc/rfc4892.txt b/doc/rfc/rfc4892.txt
deleted file mode 100644
index a89d3fb0..00000000
--- a/doc/rfc/rfc4892.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           S. Woolf
-Request for Comments: 4892             Internet Systems Consortium, Inc.
-Category: Informational                                        D. Conrad
-                                                                   ICANN
-                                                               June 2007
-
-
-    Requirements for a Mechanism Identifying a Name Server Instance
-
-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 IETF Trust (2007).
-
-Abstract
-
-   With the increased use of DNS anycast, load balancing, and other
-   mechanisms allowing more than one DNS name server to share a single
-   IP address, it is sometimes difficult to tell which of a pool of name
-   servers has answered a particular query.  A standardized mechanism to
-   determine the identity of a name server responding to a particular
-   query would be useful, particularly as a diagnostic aid for
-   administrators.  Existing ad hoc mechanisms for addressing this need
-   have some shortcomings, not the least of which is the lack of prior
-   analysis of exactly how such a mechanism should be designed and
-   deployed.  This document describes the existing convention used in
-   some widely deployed implementations of the DNS protocol, including
-   advantages and disadvantages, and discusses some attributes of an
-   improved mechanism.
-
-1.  Introduction and Rationale
-
-   Identifying which name server is responding to queries is often
-   useful, particularly in attempting to diagnose name server
-   difficulties.  This is most obviously useful for authoritative
-   nameservers in the attempt to diagnose the source or prevalence of
-   inaccurate data, but can also conceivably be useful for caching
-   resolvers in similar and other situations.  Furthermore, the ability
-   to identify which server is responding to a query has become more
-   useful as DNS has become more critical to more Internet users, and as
-   network and server deployment topologies have become more complex.
-
-
-
-
-
-Woolf & Conrad               Informational                      [Page 1]
-
-RFC 4892                        Serverid                       June 2007
-
-
-   The conventional means for determining which of several possible
-   servers is answering a query has traditionally been based on the use
-   of the server's IP address as a unique identifier.  However, the
-   modern Internet has seen the deployment of various load balancing,
-   fault-tolerance, or attack-resistance schemes such as shared use of
-   unicast IP addresses as documented in [RFC3258].  An unfortunate side
-   effect of these schemes has been to make the use of IP addresses as
-   identifiers associated with DNS (or any other) service somewhat
-   problematic.  Specifically, multiple dedicated DNS queries may not go
-   to the same server even though sent to the same IP address.  Non-DNS
-   methods such as ICMP ping, TCP connections, or non-DNS UDP packets
-   (such as those generated by tools like "traceroute"), etc., may well
-   be even less certain to reach the same server as the one which
-   receives the DNS queries.
-
-   There is a well-known and frequently-used technique for determining
-   an identity for a nameserver more specific than the possibly-non-
-   unique "server that answered the query I sent to IP address A.B.C.D".
-   The widespread use of the existing convention suggests a need for a
-   documented, interoperable means of querying the identity of a
-   nameserver that may be part of an anycast or load-balancing cluster.
-   At the same time, however, it also has some drawbacks that argue
-   against standardizing it as it's been practiced so far.
-
-2.  Existing Conventions
-
-   For some time, the commonly deployed Berkeley Internet Name Domain
-   (BIND) implementation of the DNS protocol suite from the Internet
-   Systems Consortium [BIND] has supported a way of identifying a
-   particular server via the use of a standards-compliant, if somewhat
-   unusual, DNS query.  Specifically, a query to a recent BIND server
-   for a TXT resource record in class 3 (CHAOS) for the domain name
-   "HOSTNAME.BIND." will return a string that can be configured by the
-   name server administrator to provide a unique identifier for the
-   responding server.  (The value defaults to the result of a
-   gethostname() call).  This mechanism, which is an extension of the
-   BIND convention of using CHAOS class TXT RR queries to sub-domains of
-   the "BIND." domain for version information, has been copied by
-   several name server vendors.
-
-   A refinement to the BIND-based mechanism, which dropped the
-   implementation-specific label, replaces "BIND." with "SERVER.".  Thus
-   the query label to learn the unique name of a server may appear as
-   "ID.SERVER.".
-
-   (For reference, the other well-known name used by recent versions of
-   BIND within the CHAOS class "BIND." domain is "VERSION.BIND.".  A
-   query for a CHAOS TXT RR for this name will return an
-
-
-
-Woolf & Conrad               Informational                      [Page 2]
-
-RFC 4892                        Serverid                       June 2007
-
-
-   administratively defined string which defaults to the software
-   version of the server responding.  This is, however, not generally
-   implemented by other vendors.)
-
-2.1.  Advantages
-
-   There are several valuable attributes to this mechanism, which
-   account for its usefulness.
-
-   1.  The "HOSTNAME.BIND." or "ID.SERVER." query response mechanism is
-       within the DNS protocol itself.  An identification mechanism that
-       relies on the DNS protocol is more likely to be successful
-       (although not guaranteed) in going to the same system as a
-       "normal" DNS query.
-
-   2.  Since the identity information is requested and returned within
-       the DNS protocol, it doesn't require allowing any other query
-       mechanism to the server, such as holes in firewalls for
-       otherwise-unallowed ICMP Echo requests.  Thus it is likely to
-       reach the same server over a path subject to the same routing,
-       resource, and security policy as the query, without any special
-       exceptions to site security policy.
-
-   3.  It is simple to configure.  An administrator can easily turn on
-       this feature and control the results of the relevant query.
-
-   4.  It allows the administrator complete control of what information
-       is given out in the response, minimizing passive leakage of
-       implementation or configuration details.  Such details are often
-       considered sensitive by infrastructure operators.
-
-2.2.  Disadvantages
-
-   At the same time, there are some serious drawbacks to the CHAOS/TXT
-   query mechanism that argue against standardizing it as it currently
-   operates.
-
-   1.  It requires an additional query to correlate between the answer
-       to a DNS query under normal conditions and the supposed identity
-       of the server receiving the query.  There are a number of
-       situations in which this simply isn't reliable.
-
-   2.  It reserves an entire class in the DNS (CHAOS) for what amounts
-       to one zone.  While CHAOS class is defined in [RFC1034] and
-       [RFC1035], it's not clear that supporting it solely for this
-       purpose is a good use of the namespace or of implementation
-       effort.
-
-
-
-
-Woolf & Conrad               Informational                      [Page 3]
-
-RFC 4892                        Serverid                       June 2007
-
-
-   3.  The initial and still common form, using "BIND.", is
-       implementation specific.  BIND is one DNS implementation.  At the
-       time of this writing, it is probably most prevalent for
-       authoritative servers.  This does not justify standardizing on
-       its ad hoc solution to a problem shared across many operators and
-       implementors.  Meanwhile, the aforementioned refinement changes
-       the query label but preserves the ad hoc CHAOS/TXT mechanism.
-
-   4.  There is no convention or shared understanding of what
-       information an answer to such a query for a server identity could
-       or should contain, including a possible encoding or
-       authentication mechanism.
-
-   5.  Hypothetically, since DNSSEC has been defined to cover all DNS
-       classes, the TXT RRs returned in response to the "ID.SERVER."
-       query could be signed, which has the advantages described in
-       [RFC4033].  However, since DNSSEC deployment for the CHAOS class
-       is neither existent nor foreseeable, and since the "ID.SERVER."
-       TXT RR is expected to be unique per server, this would be
-       impossible in practice.
-
-   The first of the listed disadvantages may be technically the most
-   serious.  It argues for an attempt to design a good answer to the
-   problem, "I need to know what nameserver is answering my queries",
-   not simply a convenient one.
-
-3.  Characteristics of an Implementation Neutral Convention
-
-   The discussion above of advantages and disadvantages to the
-   "HOSTNAME.BIND." mechanism suggest some requirements for a better
-   solution to the server identification problem.  These are summarized
-   here as guidelines for any effort to provide appropriate protocol
-   extensions:
-
-   1.  The mechanism adopted must be in-band for the DNS protocol.  That
-       is, it needs to allow the query for the server's identifying
-       information to be part of a normal, operational query.  It should
-       also permit a separate, dedicated query for the server's
-       identifying information.  But it should preserve the ability of
-       the CHAOS/TXT query-based mechanism to work through firewalls and
-       in other situations where only DNS can be relied upon to reach
-       the server of interest.
-
-   2.  The new mechanism should not require dedicated namespaces or
-       other reserved values outside of the existing protocol mechanisms
-       for these, i.e., the OPT pseudo-RR.  In particular, it should not
-       propagate the existing drawback of requiring support for a CLASS
-
-
-
-
-Woolf & Conrad               Informational                      [Page 4]
-
-RFC 4892                        Serverid                       June 2007
-
-
-       and top level domain in the authoritative server (or the querying
-       tool) to be useful.
-
-   3.  Support for the identification functionality should be easy to
-       implement and easy to enable.  It must be easy to disable and
-       should lend itself to access controls on who can query for it.
-
-   4.  It should be possible to return a unique identifier for a server
-       without requiring the exposure of information that may be non-
-       public and considered sensitive by the operator, such as a
-       hostname or unicast IP address maintained for administrative
-       purposes.
-
-   5.  It should be possible to authenticate the received data by some
-       mechanism analogous to those provided by DNSSEC.  In this
-       context, the need could be met by including encryption options in
-       the specification of a new mechanism.
-
-   6.  The identification mechanism should not be implementation-
-       specific.
-
-4.  IANA Considerations
-
-   This document proposes no specific IANA action.  Protocol extensions,
-   if any, to meet the requirements described are out of scope for this
-   document.  A proposed extension, specified and adopted by normal IETF
-   process, is described in [NSID], including relevant IANA action.
-
-5.  Security Considerations
-
-   Providing identifying information as to which server is responding to
-   a particular query from a particular location in the Internet can be
-   seen as information leakage and thus a security risk.  This motivates
-   the suggestion above that a new mechanism for server identification
-   allow the administrator to disable the functionality altogether or
-   partially restrict availability of the data.  It also suggests that
-   the server identification data should not be readily correlated with
-   a hostname or unicast IP address that may be considered private to
-   the nameserver operator's management infrastructure.
-
-   Propagation of protocol or service meta-data can sometimes expose the
-   application to denial of service or other attack.  As the DNS is a
-   critically important infrastructure service for the production
-   Internet, extra care needs to be taken against this risk for
-   designers, implementors, and operators of a new mechanism for server
-   identification.
-
-
-
-
-
-Woolf & Conrad               Informational                      [Page 5]
-
-RFC 4892                        Serverid                       June 2007
-
-
-   Both authentication and confidentiality of server identification data
-   are potentially of interest to administrators -- that is, operators
-   may wish to make such data available and reliable to themselves and
-   their chosen associates only.  This constraint would imply both an
-   ability to authenticate it to themselves and to keep it private from
-   arbitrary other parties, which leads to characteristics 4 and 5 of an
-   improved solution.
-
-6.  Acknowledgements
-
-   The technique for host identification documented here was initially
-   implemented by Paul Vixie of the Internet Software Consortium in the
-   Berkeley Internet Name Daemon package.  Comments and questions on
-   earlier versions were provided by Bob Halley, Brian Wellington,
-   Andreas Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and
-   members of the ICANN Root Server System Advisory Committee.  The
-   newest version takes a significantly different direction from
-   previous versions, owing to discussion among contributors to the
-   DNSOP working group and others, particularly Olafur Gudmundsson, Ed
-   Lewis, Bill Manning, Sam Weiler, and Rob Austein.
-
-7.  References
-
-7.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.
-
-   [RFC3258]  Hardie, T., "Distributing Authoritative Name Servers via
-              Shared Unicast Addresses", RFC 3258, April 2002.
-
-7.2.  Informative References
-
-   [BIND]     ISC, "BIND 9 Configuration Reference".
-
-   [NSID]     Austein, R., "DNS Name Server Identifier Option (NSID)",
-              Work in Progress, June 2006.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements", RFC
-              4033, March 2005.
-
-
-
-
-
-
-
-Woolf & Conrad               Informational                      [Page 6]
-
-RFC 4892                        Serverid                       June 2007
-
-
-Authors' Addresses
-
-   Suzanne Woolf
-   Internet Systems Consortium, Inc.
-   950 Charter Street
-   Redwood City, CA  94063
-   US
-
-   Phone: +1 650 423-1333
-   EMail: woolf@isc.org
-   URI:   http://www.isc.org/
-
-
-   David Conrad
-   ICANN
-   4676 Admiralty Way
-   Marina del Rey, CA  90292
-   US
-
-   Phone: +1 310 823 9358
-   EMail: david.conrad@icann.org
-   URI:   http://www.iana.org/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad               Informational                      [Page 7]
-
-RFC 4892                        Serverid                       June 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Woolf & Conrad               Informational                      [Page 8]
-
diff --git a/doc/rfc/rfc4955.txt b/doc/rfc/rfc4955.txt
deleted file mode 100644
index 2d2eb84e..00000000
--- a/doc/rfc/rfc4955.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          D. Blacka
-Request for Comments: 4955                                VeriSign, Inc.
-Category: Standards Track                                      July 2007
-
-
-                   DNS Security (DNSSEC) Experiments
-
-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 IETF Trust (2007).
-
-Abstract
-
-   This document describes a methodology for deploying alternate, non-
-   backwards-compatible, DNS Security (DNSSEC) methodologies in an
-   experimental fashion without disrupting the deployment of standard
-   DNSSEC.
-
-Table of Contents
-
-   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
-   2.  Definitions and Terminology . . . . . . . . . . . . . . . . . . 2
-   3.  Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2
-   4.  Method  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   5.  Defining an Experiment  . . . . . . . . . . . . . . . . . . . . 4
-   6.  Considerations  . . . . . . . . . . . . . . . . . . . . . . . . 5
-   7.  Use in Non-Experiments  . . . . . . . . . . . . . . . . . . . . 5
-   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                      Standards Track                     [Page 1]
-
-RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
-
-
-1.  Overview
-
-   Historically, experimentation with DNSSEC alternatives has been a
-   problematic endeavor.  There has typically been a desire to both
-   introduce non-backwards-compatible changes to DNSSEC and to try these
-   changes on real zones in the public DNS.  This creates a problem when
-   the change to DNSSEC would make all or part of the zone using those
-   changes appear bogus (bad) or otherwise broken to existing security-
-   aware resolvers.
-
-   This document describes a standard methodology for setting up DNSSEC
-   experiments.  This methodology addresses the issue of coexistence
-   with standard DNSSEC and DNS by using unknown algorithm identifiers
-   to hide the experimental DNSSEC protocol modifications from standard
-   security-aware resolvers.
-
-2.  Definitions and Terminology
-
-   Throughout this document, familiarity with the DNS system (RFC 1035
-   [5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and
-   RFC 4035 [4]) is assumed.
-
-   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].
-
-3.  Experiments
-
-   When discussing DNSSEC experiments, it is necessary to classify these
-   experiments into two broad categories:
-
-   Backwards-Compatible:  describes experimental changes that, while not
-      strictly adhering to the DNSSEC standard, are nonetheless
-      interoperable with clients and servers that do implement the
-      DNSSEC standard.
-
-   Non-Backwards-Compatible:  describes experiments that would cause a
-      standard security-aware resolver to (incorrectly) determine that
-      all or part of a zone is bogus, or to otherwise not interoperate
-      with standard DNSSEC clients and servers.
-
-   Not included in these terms are experiments with the core DNS
-   protocol itself.
-
-   The methodology described in this document is not necessary for
-   backwards-compatible experiments, although it certainly may be used
-   if desired.
-
-
-
-
-Blacka                      Standards Track                     [Page 2]
-
-RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
-
-
-4.  Method
-
-   The core of the methodology is the use of strictly unknown algorithm
-   identifiers when signing the experimental zone, and more importantly,
-   having only unknown algorithm identifiers in the DS records for the
-   delegation to the zone at the parent.
-
-   This technique works because of the way DNSSEC-compliant validators
-   are expected to work in the presence of a DS set with only unknown
-   algorithm identifiers.  From RFC 4035 [4], Section 5.2:
-
-      If the validator does not support any of the algorithms listed in
-      an authenticated DS RRset, then the resolver has no supported
-      authentication path leading from the parent to the child.  The
-      resolver should treat this case as it would the case of an
-      authenticated NSEC RRset proving that no DS RRset exists, as
-      described above.
-
-   And further:
-
-      If the resolver does not support any of the algorithms listed in
-      an authenticated DS RRset, then the resolver will not be able to
-      verify the authentication path to the child zone.  In this case,
-      the resolver SHOULD treat the child zone as if it were unsigned.
-
-   Although this behavior isn't strictly mandatory (as marked by MUST),
-   it is unlikely for a validator to implement a substantially different
-   behavior.  Essentially, if the validator does not have a usable chain
-   of trust to a child zone, then it can only do one of two things:
-   treat responses from the zone as insecure (the recommended behavior),
-   or treat the responses as bogus.  If the validator chooses the
-   latter, this will both violate the expectation of the zone owner and
-   defeat the purpose of the above rule.  However, with local policy, it
-   is within the right of a validator to refuse to trust certain zones
-   based on any criteria, including the use of unknown signing
-   algorithms.
-
-   Because we are talking about experiments, it is RECOMMENDED that
-   private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1.
-   Note that secure handling of private algorithms requires special
-   handing by the validator logic.  See "Clarifications and
-   Implementation Notes for DNSSECbis" [6] for further details.)
-   Normally, instead of actually inventing new signing algorithms, the
-   recommended path is to create alternate algorithm identifiers that
-   are aliases for the existing, known algorithms.  While, strictly
-   speaking, it is only necessary to create an alternate identifier for
-   the mandatory algorithms, it is suggested that all optional defined
-   algorithms be aliased as well.
-
-
-
-Blacka                      Standards Track                     [Page 3]
-
-RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
-
-
-   It is RECOMMENDED that for a particular DNSSEC experiment, a
-   particular domain name base is chosen for all new algorithms, then
-   the algorithm number (or name) is prepended to it.  For example, for
-   experiment A, the base name of "dnssec-experiment-a.example.com" is
-   chosen.  Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
-   defined to be "3.dnssec-experiment-a.example.com" and
-   "5.dnssec-experiment-a.example.com".  However, any unique identifier
-   will suffice.
-
-   Using this method, resolvers (or, more specifically, DNSSEC
-   validators) essentially indicate their ability to understand the
-   DNSSEC experiment's semantics by understanding what the new algorithm
-   identifiers signify.
-
-   This method creates two classes of security-aware servers and
-   resolvers: servers and resolvers that are aware of the experiment
-   (and thus recognize the experiment's algorithm identifiers and
-   experimental semantics), and servers and resolvers that are unaware
-   of the experiment.
-
-   This method also precludes any zone from being both in an experiment
-   and in a classic DNSSEC island of security.  That is, a zone is
-   either in an experiment and only possible to validate experimentally,
-   or it is not.
-
-5.  Defining an Experiment
-
-   The DNSSEC experiment MUST define the particular set of (previously
-   unknown) algorithm identifiers that identify the experiment and
-   define what each unknown algorithm identifier means.  Typically,
-   unless the experiment is actually experimenting with a new DNSSEC
-   algorithm, this will be a mapping of private algorithm identifiers to
-   existing, known algorithms.
-
-   Normally the experiment will choose a DNS name as the algorithm
-   identifier base.  This DNS name SHOULD be under the control of the
-   authors of the experiment.  Then the experiment will define a mapping
-   between known mandatory and optional algorithms into this private
-   algorithm identifier space.  Alternately, the experiment MAY use the
-   Object Identifier (OID) private algorithm space instead (using
-   algorithm number 254), or MAY choose non-private algorithm numbers,
-   although this would require an IANA allocation.
-
-   For example, an experiment might specify in its description the DNS
-   name "dnssec-experiment-a.example.com" as the base name, and declare
-   that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC
-   algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an
-   alias of DNSSEC algorithm 5 (RSASHA1).
-
-
-
-Blacka                      Standards Track                     [Page 4]
-
-RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
-
-
-   Resolvers MUST only recognize the experiment's semantics when present
-   in a zone signed by one or more of these algorithm identifiers.  This
-   is necessary to isolate the semantics of one experiment from any
-   others that the resolver might understand.
-
-   In general, resolvers involved in the experiment are expected to
-   understand both standard DNSSEC and the defined experimental DNSSEC
-   protocol, although this isn't required.
-
-6.  Considerations
-
-   There are a number of considerations with using this methodology.
-
-   1.  If an unaware validator does not correctly follow the rules laid
-       out in RFC 4035 (e.g., the validator interprets a DNSSEC record
-       prior to validating it), or if the experiment is broader in scope
-       that just modifying the DNSSEC semantics, the experiment may not
-       be sufficiently masked by this technique.  This may cause
-       unintended resolution failures.
-
-   2.  It will not be possible for security-aware resolvers unaware of
-       the experiment to build a chain of trust through an experimental
-       zone.
-
-7.  Use in Non-Experiments
-
-   This general methodology MAY be used for non-backwards compatible
-   DNSSEC protocol changes that start out as or become standards.  In
-   this case:
-
-   o  The protocol change SHOULD use public IANA allocated algorithm
-      identifiers instead of private algorithm identifiers.  This will
-      help identify the protocol change as a standard, rather than an
-      experiment.
-
-   o  Resolvers MAY recognize the protocol change in zones not signed
-      (or not solely signed) using the new algorithm identifiers.
-
-8.  Security Considerations
-
-   Zones using this methodology will be considered insecure by all
-   resolvers except those aware of the experiment.  It is not generally
-   possible to create a secure delegation from an experimental zone that
-   will be followed by resolvers unaware of the experiment.
-
-   Implementers should take into account any security issues that may
-   result from environments being configured to trust both experimental
-   and non-experimental zones.  If the experimental zone is more
-
-
-
-Blacka                      Standards Track                     [Page 5]
-
-RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
-
-
-   vulnerable to attacks, it could, for example, be used to promote
-   trust in zones not part of the experiment, possibly under the control
-   of an attacker.
-
-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]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-9.2.  Informative References
-
-   [5]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [6]  Weiler, S. and R. Austein, "Clarifications and Implementation
-        Notes for DNSSECbis", Work in Progress, March 2007.
-
-Author's Address
-
-   David Blacka
-   VeriSign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   EMail: davidb@verisign.com
-   URI:   http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-Blacka                      Standards Track                     [Page 6]
-
-RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Blacka                      Standards Track                     [Page 7]
-
diff --git a/doc/rfc/rfc4956.txt b/doc/rfc/rfc4956.txt
deleted file mode 100644
index 536c680c..00000000
--- a/doc/rfc/rfc4956.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Arends
-Request for Comments: 4956                                       Nominet
-Category: Experimental                                        M. Kosters
-                                                               D. Blacka
-                                                          VeriSign, Inc.
-                                                               July 2007
-
-
-                      DNS Security (DNSSEC) Opt-In
-
-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 IETF Trust (2007).
-
-Abstract
-
-   In the DNS security (DNSSEC) extensions, delegations to unsigned
-   subzones are cryptographically secured.  Maintaining this
-   cryptography is not always practical or necessary.  This document
-   describes an experimental "Opt-In" model that allows administrators
-   to omit this cryptography and manage the cost of adopting DNSSEC with
-   large zones.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.                Experimental                      [Page 1]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-Table of Contents
-
-   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  3
-   3.  Experimental Status  . . . . . . . . . . . . . . . . . . . . .  4
-   4.  Protocol Additions . . . . . . . . . . . . . . . . . . . . . .  5
-     4.1.  Server Considerations  . . . . . . . . . . . . . . . . . .  6
-       4.1.1.  Delegations Only . . . . . . . . . . . . . . . . . . .  6
-       4.1.2.  Insecure Delegation Responses  . . . . . . . . . . . .  6
-       4.1.3.  Dynamic Update . . . . . . . . . . . . . . . . . . . .  6
-     4.2.  Client Considerations  . . . . . . . . . . . . . . . . . .  7
-       4.2.1.  Delegations Only . . . . . . . . . . . . . . . . . . .  7
-       4.2.2.  Validation Process Changes . . . . . . . . . . . . . .  7
-       4.2.3.  NSEC Record Caching  . . . . . . . . . . . . . . . . .  8
-       4.2.4.  Use of the AD bit  . . . . . . . . . . . . . . . . . .  8
-   5.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  Transition Issues  . . . . . . . . . . . . . . . . . . . . . . 11
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
-   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
-   Appendix A.  Implementing Opt-In Using "Views" . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.                Experimental                      [Page 2]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-1.  Overview
-
-   The cost to cryptographically secure delegations to unsigned zones is
-   high for large delegation-centric zones and zones where insecure
-   delegations will be updated rapidly.  For these zones, the costs of
-   maintaining the NextSECure (NSEC) record chain may be extremely high
-   relative to the gain of cryptographically authenticating existence of
-   unsecured zones.
-
-   This document describes an experimental method of eliminating the
-   superfluous cryptography present in secure delegations to unsigned
-   zones.  Using "Opt-In", a zone administrator can choose to remove
-   insecure delegations from the NSEC chain.  This is accomplished by
-   extending the semantics of the NSEC record by using a redundant bit
-   in the type map.
-
-2.  Definitions and Terminology
-
-   Throughout this document, familiarity with the DNS system (RFC 1035
-   [1]), DNS security extensions ([4], [5], and [6], referred to in this
-   document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
-   [10]) is assumed.
-
-   The following abbreviations and terms are used in this document:
-
-   RR:  is used to refer to a DNS resource record.
-
-   RRset:  refers to a Resource Record Set, as defined by [8].  In this
-      document, the RRset is also defined to include the covering RRSIG
-      records, if any exist.
-
-   signed name:  refers to a DNS name that has, at minimum, a (signed)
-      NSEC record.
-
-   unsigned name:  refers to a DNS name that does not (at least) have an
-      NSEC record.
-
-   covering NSEC record/RRset:  is the NSEC record used to prove
-      (non)existence of a particular name or RRset.  This means that for
-      a RRset or name 'N', the covering NSEC record has the name 'N', or
-      has an owner name less than 'N' and "next" name greater than 'N'.
-
-   delegation:  refers to an NS RRset with a name different from the
-      current zone apex (non-zone-apex), signifying a delegation to a
-      subzone.
-
-
-
-
-
-
-Arends, et al.                Experimental                      [Page 3]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-   secure delegation:  refers to a signed name containing a delegation
-      (NS RRset), and a signed DS RRset, signifying a delegation to a
-      signed subzone.
-
-   insecure delegation:  refers to a signed name containing a delegation
-      (NS RRset), but lacking a DS RRset, signifying a delegation to an
-      unsigned subzone.
-
-   Opt-In insecure delegation:  refers to an unsigned name containing
-      only a delegation NS RRset.  The covering NSEC record uses the
-      Opt-In methodology described in this document.
-
-   The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [2].
-
-3.  Experimental Status
-
-   This document describes an EXPERIMENTAL extension to DNSSEC.  It
-   interoperates with non-experimental DNSSEC using the technique
-   described in [7].  This experiment is identified with the following
-   private algorithms (using algorithm 253):
-
-   "3.optin.verisignlabs.com":  is an alias for DNSSEC algorithm 3, DSA,
-      and
-
-   "5.optin.verisignlabs.com":  is an alias for DNSSEC algorithm 5,
-      RSASHA1.
-
-   Servers wishing to sign and serve zones that utilize Opt-In MUST sign
-   the zone with only one or more of these private algorithms and MUST
-   NOT use any other algorithms.
-
-   Resolvers MUST NOT apply the Opt-In validation rules described in
-   this document unless a zone is signed using one or more of these
-   private algorithms.
-
-   This experimental protocol relaxes the restriction that validators
-   MUST ignore the setting of the NSEC bit in the type map as specified
-   in RFC 4035 [6] Section 5.4.
-
-   The remainder of this document assumes that the servers and resolvers
-   involved are aware of and are involved in this experiment.
-
-
-
-
-
-
-
-
-Arends, et al.                Experimental                      [Page 4]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-4.  Protocol Additions
-
-   In DNSSEC, delegation NS RRsets are not signed, but are instead
-   accompanied by an NSEC RRset of the same name and (possibly) a DS
-   record.  The security status of the subzone is determined by the
-   presence or absence of the DS RRset, cryptographically proven by the
-   NSEC record.  Opt-In expands this definition by allowing insecure
-   delegations to exist within an otherwise signed zone without the
-   corresponding NSEC record at the delegation's owner name.  These
-   insecure delegations are proven insecure by using a covering NSEC
-   record.
-
-   Since this represents a change of the interpretation of NSEC records,
-   resolvers must be able to distinguish between RFC standard DNSSEC
-   NSEC records and Opt-In NSEC records.  This is accomplished by
-   "tagging" the NSEC records that cover (or potentially cover) insecure
-   delegation nodes.  This tag is indicated by the absence of the NSEC
-   bit in the type map.  Since the NSEC bit in the type map merely
-   indicates the existence of the record itself, this bit is redundant
-   and safe for use as a tag.
-
-   An Opt-In tagged NSEC record does not assert the (non)existence of
-   the delegations that it covers (except for a delegation with the same
-   name).  This allows for the addition or removal of these delegations
-   without recalculating or resigning records in the NSEC chain.
-   However, Opt-In tagged NSEC records do assert the (non)existence of
-   other RRsets.
-
-   An Opt-In NSEC record MAY have the same name as an insecure
-   delegation.  In this case, the delegation is proven insecure by the
-   lack of a DS bit in the type map, and the signed NSEC record does
-   assert the existence of the delegation.
-
-   Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
-   records and standard DNSSEC NSEC records.  If an NSEC record is not
-   Opt-In, there MUST NOT be any insecure delegations (or any other
-   records) between it and the RRsets indicated by the 'next domain
-   name' in the NSEC RDATA.  If it is Opt-In, there MUST only be
-   insecure delegations between it and the next node indicated by the
-   'next domain name' in the NSEC RDATA.
-
-   In summary,
-
-   o  An Opt-In NSEC type is identified by a zero-valued (or not-
-      specified) NSEC bit in the type bit map of the NSEC record.
-
-
-
-
-
-
-Arends, et al.                Experimental                      [Page 5]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-   o  A standard DNSSEC NSEC type is identified by a one-valued NSEC bit
-      in the type bit map of the NSEC record.
-
-   and
-
-   o  An Opt-In NSEC record does not assert the non-existence of a name
-      between its owner name and "next" name, although it does assert
-      that any name in this span MUST be an insecure delegation.
-
-   o  An Opt-In NSEC record does assert the (non)existence of RRsets
-      with the same owner name.
-
-4.1.  Server Considerations
-
-   Opt-In imposes some new requirements on authoritative DNS servers.
-
-4.1.1.  Delegations Only
-
-   This specification dictates that only insecure delegations may exist
-   between the owner and "next" names of an Opt-In tagged NSEC record.
-   Signing tools MUST NOT generate signed zones that violate this
-   restriction.  Servers MUST refuse to load and/or serve zones that
-   violate this restriction.  Servers also MUST reject AXFR or IXFR
-   responses that violate this restriction.
-
-4.1.2.  Insecure Delegation Responses
-
-   When returning an Opt-In insecure delegation, the server MUST return
-   the covering NSEC RRset in the Authority section.
-
-   In standard DNSSEC, NSEC records already must be returned along with
-   the insecure delegation.  The primary difference that this proposal
-   introduces is that the Opt-In tagged NSEC record will have a
-   different owner name from the delegation RRset.  This may require
-   implementations to search for the covering NSEC RRset.
-
-4.1.3.  Dynamic Update
-
-   Opt-In changes the semantics of Secure DNS Dynamic Update [9].  In
-   particular, it introduces the need for rules that describe when to
-   add or remove a delegation name from the NSEC chain.  This document
-   does not attempt to define these rules.  Until these rules are
-   defined, servers MUST NOT process DNS Dynamic Update requests against
-   zones that use Opt-In NSEC records.  Servers SHOULD return responses
-   to update requests with RCODE=REFUSED.
-
-
-
-
-
-
-Arends, et al.                Experimental                      [Page 6]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-4.2.  Client Considerations
-
-   Opt-In imposes some new requirements on security-aware resolvers
-   (caching or otherwise).
-
-4.2.1.  Delegations Only
-
-   As stated in Section 4.1 above, this specification restricts the
-   namespace covered by Opt-In tagged NSEC records to insecure
-   delegations only.  Clients are not expected to take any special
-   measures to enforce this restriction; instead, it forms an underlying
-   assumption that clients may rely on.
-
-4.2.2.  Validation Process Changes
-
-   This specification does not change the resolver's resolution
-   algorithm.  However, it does change the DNSSEC validation process.
-
-4.2.2.1.  Referrals
-
-   Resolvers MUST be able to use Opt-In tagged NSEC records to
-   cryptographically prove the validity and security status (as
-   insecure) of a referral.  Resolvers determine the security status of
-   the referred-to zone as follows:
-
-   o  In standard DNSSEC, the security status is proven by the existence
-      or absence of a DS RRset at the same name as the delegation.  The
-      existence of the DS RRset indicates that the referred-to zone is
-      signed.  The absence of the DS RRset is proven using a verified
-      NSEC record of the same name that does not have the DS bit set in
-      the type map.  This NSEC record MAY also be tagged as Opt-In.
-
-   o  Using Opt-In, the security status is proven by the existence of a
-      DS record (for signed) or the presence of a verified Opt-In tagged
-      NSEC record that covers the delegation name.  That is, the NSEC
-      record does not have the NSEC bit set in the type map, and the
-      delegation name falls between the NSEC's owner and "next" name.
-
-   Using Opt-In does not substantially change the nature of following
-   referrals within DNSSEC.  At every delegation point, the resolver
-   will have cryptographic proof that the referred-to subzone is signed
-   or unsigned.
-
-4.2.2.2.  Queries for DS Resource Records
-
-   Since queries for DS records are directed to the parent side of a
-   zone cut (see [5], Section 5), negative responses to these queries
-   may be covered by an Opt-In flagged NSEC record.
-
-
-
-Arends, et al.                Experimental                      [Page 7]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-   Resolvers MUST be able to use Opt-In tagged NSEC records to
-   cryptographically prove the validity and security status of negative
-   responses to queries for DS records.  In particular, a NOERROR/NODATA
-   (i.e., RCODE=3, but the answer section is empty) response to a DS
-   query may be proven by an Opt-In flagged covering NSEC record, rather
-   than an NSEC record matching the query name.
-
-4.2.3.  NSEC Record Caching
-
-   Caching resolvers MUST be able to retrieve the appropriate covering
-   Opt-In NSEC record when returning referrals that need them.  This
-   requirement differs from standard DNSSEC in that the covering NSEC
-   will not have the same owner name as the delegation.  Some
-   implementations may have to use new methods for finding these NSEC
-   records.
-
-4.2.4.  Use of the AD bit
-
-   The AD bit, as defined by [3] and [6], MUST NOT be set when:
-
-   o  sending a Name Error (RCODE=3) response where the covering NSEC is
-      tagged as Opt-In.
-
-   o  sending an Opt-In insecure delegation response, unless the
-      covering (Opt-In) NSEC record's owner name equals the delegation
-      name.
-
-   o  sending a NOERROR/NODATA response when query type is DS and the
-      covering NSEC is tagged as Opt-In, unless NSEC record's owner name
-      matches the query name.
-
-   This rule is based on what the Opt-In NSEC record actually proves:
-   for names that exist between the Opt-In NSEC record's owner and
-   "next" names, the Opt-In NSEC record cannot prove the non-existence
-   or existence of the name.  As such, not all data in the response has
-   been cryptographically verified, so the AD bit cannot be set.
-
-5.  Benefits
-
-   Using Opt-In allows administrators of large and/or changing
-   delegation-centric zones to minimize the overhead involved in
-   maintaining the security of the zone.
-
-   Opt-In accomplishes this by eliminating the need for NSEC records for
-   insecure delegations.  This, in a zone with a large number of
-   delegations to unsigned subzones, can lead to substantial space
-   savings (both in memory and on disk).  Additionally, Opt-In allows
-   for the addition or removal of insecure delegations without modifying
-
-
-
-Arends, et al.                Experimental                      [Page 8]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-   the NSEC record chain.  Zones that are frequently updating insecure
-   delegations (e.g., Top-Level Domains (TLDs)) can avoid the
-   substantial overhead of modifying and resigning the affected NSEC
-   records.
-
-6.  Example
-
-   Consider the zone EXAMPLE shown below.  This is a zone where all of
-   the NSEC records are tagged as Opt-In.
-
-   Example A: Fully Opt-In Zone.
-
-         EXAMPLE.               SOA    ...
-         EXAMPLE.               RRSIG  SOA ...
-         EXAMPLE.               NS     FIRST-SECURE.EXAMPLE.
-         EXAMPLE.               RRSIG  NS ...
-         EXAMPLE.               DNSKEY ...
-         EXAMPLE.               RRSIG  DNSKEY ...
-         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (
-                                       SOA NS RRSIG DNSKEY )
-         EXAMPLE.               RRSIG  NSEC ...
-
-         FIRST-SECURE.EXAMPLE.  A      ...
-         FIRST-SECURE.EXAMPLE.  RRSIG  A ...
-         FIRST-SECURE.EXAMPLE.  NSEC   NOT-SECURE-2.EXAMPLE. A RRSIG
-         FIRST-SECURE.EXAMPLE.  RRSIG  NSEC ...
-
-         NOT-SECURE.EXAMPLE.    NS     NS.NOT-SECURE.EXAMPLE.
-         NS.NOT-SECURE.EXAMPLE. A      ...
-
-         NOT-SECURE-2.EXAMPLE.  NS     NS.NOT-SECURE.EXAMPLE.
-         NOT-SECURE-2.EXAMPLE   NSEC   SECOND-SECURE.EXAMPLE NS RRSIG
-         NOT-SECURE-2.EXAMPLE   RRSIG  NSEC ...
-
-         SECOND-SECURE.EXAMPLE. NS     NS.ELSEWHERE.
-         SECOND-SECURE.EXAMPLE. DS     ...
-         SECOND-SECURE.EXAMPLE. RRSIG  DS ...
-         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DNSKEY
-         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
-
-         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE.
-         NS.UNSIGNED.EXAMPLE.   A      ...
-
-
-                                Example A.
-
-
-
-
-
-
-Arends, et al.                Experimental                      [Page 9]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-   In this example, a query for a signed RRset (e.g., "FIRST-
-   SECURE.EXAMPLE A") or a secure delegation ("WWW.SECOND-SECURE.EXAMPLE
-   A") will result in a standard DNSSEC response.
-
-   A query for a nonexistent RRset will result in a response that
-   differs from standard DNSSEC by the following: the NSEC record will
-   be tagged as Opt-In, there may be no NSEC record proving the non-
-   existence of a matching wildcard record, and the AD bit will not be
-   set.
-
-   A query for an insecure delegation RRset (or a referral) will return
-   both the answer (in the Authority section) and the corresponding
-   Opt-In NSEC record to prove that it is not secure.
-
-   Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE.  A
-
-
-         RCODE=NOERROR, AD=0
-
-         Answer Section:
-
-         Authority Section:
-         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE
-         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DS
-         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
-
-         Additional Section:
-         NS.UNSIGNED.EXAMPLE.   A      ...
-
-                                Example A.1
-
-   In the Example A.1 zone, the EXAMPLE. node MAY use either style of
-   NSEC record, because there are no insecure delegations that occur
-   between it and the next node, FIRST-SECURE.EXAMPLE.  In other words,
-   Example A would still be a valid zone if the NSEC record for EXAMPLE.
-   was changed to the following RR:
-
-         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (SOA NS
-                                       RRSIG DNSKEY NSEC )
-
-   However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
-   SECURE.EXAMPLE.)  MUST be tagged as Opt-In because there are insecure
-   delegations in the range they define.  (NOT-SECURE.EXAMPLE. and
-   UNSIGNED.EXAMPLE., respectively).
-
-   NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
-   part of the NSEC chain and also covered by an Opt-In tagged NSEC
-   record.  Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
-
-
-
-Arends, et al.                Experimental                     [Page 10]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-   removed from the zone without modifying and resigning the prior NSEC
-   record.  Delegations with names that fall between NOT-SECURE-
-   2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
-   resigning any NSEC records.
-
-7.  Transition Issues
-
-   Opt-In is not backwards compatible with standard DNSSEC and is
-   considered experimental.  Standard DNSSEC-compliant implementations
-   would not recognize Opt-In tagged NSEC records as different from
-   standard NSEC records.  Because of this, standard DNSSEC
-   implementations, if they were to validate Opt-In style responses,
-   would reject all Opt-In insecure delegations within a zone as
-   invalid.  However, by only signing with private algorithms, standard
-   DNSSEC implementations will treat Opt-In responses as unsigned.
-
-   It should be noted that all elements in the resolution path between
-   (and including) the validator and the authoritative name server must
-   be aware of the Opt-In experiment and implement the Opt-In semantics
-   for successful validation to be possible.  In particular, this
-   includes any caching middleboxes between the validator and
-   authoritative name server.
-
-8.  Security Considerations
-
-   Opt-In allows for unsigned names, in the form of delegations to
-   unsigned subzones, to exist within an otherwise signed zone.  All
-   unsigned names are, by definition, insecure, and their validity or
-   existence cannot be cryptographically proven.
-
-   In general:
-
-   o  Records with unsigned names (whether or not existing) suffer from
-      the same vulnerabilities as records in an unsigned zone.  These
-      vulnerabilities are described in more detail in [12] (note in
-      particular Sections 2.3, "Name Games" and 2.6, "Authenticated
-      Denial").
-
-   o  Records with signed names have the same security whether or not
-      Opt-In is used.
-
-   Note that with or without Opt-In, an insecure delegation may have its
-   contents undetectably altered by an attacker.  Because of this, the
-   primary difference in security that Opt-In introduces is the loss of
-   the ability to prove the existence or nonexistence of an insecure
-   delegation within the span of an Opt-In NSEC record.
-
-
-
-
-
-Arends, et al.                Experimental                     [Page 11]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-   In particular, this means that a malicious entity may be able to
-   insert or delete records with unsigned names.  These records are
-   normally NS records, but this also includes signed wildcard
-   expansions (while the wildcard record itself is signed, its expanded
-   name is an unsigned name), which can be undetectably removed or used
-   to replace an existing unsigned delegation.
-
-   For example, if a resolver received the following response from the
-   example zone above:
-
-   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
-
-         RCODE=NOERROR
-
-         Answer Section:
-
-         Authority Section:
-         DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
-         EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
-                                        RRSIG DNSKEY
-         EXAMPLE.                RRSIG  NSEC ...
-
-         Additional Section:
-
-
-                        Attacker has forged a name
-
-   The resolver would have no choice but to believe that the referral to
-   NS.FORGED. is valid.  If a wildcard existed that would have been
-   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
-   have undetectably removed it and replaced it with the forged
-   delegation.
-
-   Note that being able to add a delegation is functionally equivalent
-   to being able to add any record type: an attacker merely has to forge
-   a delegation to the nameserver under his/her control and place
-   whatever records are needed at the subzone apex.
-
-   While in particular cases, this issue may not present a significant
-   security problem, in general it should not be lightly dismissed.
-   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
-   In particular, zone signing tools SHOULD NOT default to Opt-In, and
-   MAY choose not to support Opt-In at all.
-
-
-
-
-
-
-
-
-Arends, et al.                Experimental                     [Page 12]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-9.  Acknowledgments
-
-   The contributions, suggestions, and remarks of the following persons
-   (in alphabetic order) to this document are acknowledged:
-
-      Mats Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill
-      Manning, Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter,
-      Brian Wellington.
-
-10.  References
-
-10.1.  Normative References
-
-   [1]   Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [3]   Wellington, B. and O. Gudmundsson, "Redefinition of DNS
-         Authenticated Data (AD) bit", RFC 3655, November 2003.
-
-   [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.
-
-   [7]   Blacka, D., "DNSSEC Experiments", RFC 4955, July 2007.
-
-10.2.  Informative References
-
-   [8]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-         RFC 2181, July 1997.
-
-   [9]   Wellington, B., "Secure Domain Name System (DNS) Dynamic
-         Update", RFC 3007, November 2000.
-
-   [10]  Lewis, E., "DNS Security Extension Clarification on Zone
-         Status", RFC 3090, March 2001.
-
-
-
-
-
-Arends, et al.                Experimental                     [Page 13]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-   [11]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
-         December 2001.
-
-   [12]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
-         System (DNS)", RFC 3833, August 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.                Experimental                     [Page 14]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-Appendix A.  Implementing Opt-In Using "Views"
-
-   In many cases, it may be convenient to implement an Opt-In zone by
-   combining two separately maintained "views" of a zone at request
-   time.  In this context, "view" refers to a particular version of a
-   zone, not to any specific DNS implementation feature.
-
-   In this scenario, one view is the secure view, the other is the
-   insecure (or legacy) view.  The secure view consists of an entirely
-   signed zone using Opt-In tagged NSEC records.  The insecure view
-   contains no DNSSEC information.  It is helpful, although not
-   necessary, for the secure view to be a subset (minus DNSSEC records)
-   of the insecure view.
-
-   In addition, the only RRsets that may solely exist in the insecure
-   view are non-zone-apex NS RRsets.  That is, all non-NS RRsets (and
-   the zone apex NS RRset) MUST be signed and in the secure view.
-
-   These two views may be combined at request time to provide a virtual,
-   single Opt-In zone.  The following algorithm is used when responding
-   to each query:
-
-      V_A is the secure view as described above.
-
-      V_B is the insecure view as described above.
-
-      R_A is a response generated from V_A, following standard DNSSEC.
-
-      R_B is a response generated from V_B, following DNS resolution as
-      per RFC 1035 [1].
-
-      R_C is the response generated by combining R_A with R_B, as
-      described below.
-
-      A query is DNSSEC-aware if it either has the DO bit [11] turned on
-      or is for a DNSSEC-specific record type.
-
-   1.  If V_A is a subset of V_B and the query is not DNSSEC-aware,
-       generate and return R_B, otherwise
-
-   2.  Generate R_A.
-
-   3.  If R_A's RCODE != NXDOMAIN, return R_A, otherwise
-
-
-
-
-
-
-
-
-Arends, et al.                Experimental                     [Page 15]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-   4.  Generate R_B and combine it with R_A to form R_C:
-
-          For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
-          records from R_A into R_B, EXCEPT the AUTHORITY section SOA
-          record, if R_B's RCODE = NOERROR.
-
-   5.  Return R_C.
-
-Authors' Addresses
-
-   Roy Arends
-   Nominet
-   Sandford Gate
-   Sandy Lane West
-   Oxford  OX4 6LB
-   UNITED KINGDOM
-
-   Phone: +44 1865 332211
-   EMail: roy@nominet.org.uk
-
-
-   Mark Kosters
-   VeriSign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   EMail: mkosters@verisign.com
-   URI:   http://www.verisignlabs.com
-
-
-   David Blacka
-   VeriSign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   EMail: davidb@verisign.com
-   URI:   http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-
-Arends, et al.                Experimental                     [Page 16]
-
-RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Arends, et al.                Experimental                     [Page 17]
-
diff --git a/doc/rfc/rfc5001.txt b/doc/rfc/rfc5001.txt
deleted file mode 100644
index fe153393..00000000
--- a/doc/rfc/rfc5001.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 5001                                           ISC
-Category: Standards Track                                    August 2007
-
-
-                DNS Name Server Identifier (NSID) Option
-
-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 IETF Trust (2007).
-
-Abstract
-
-   With the increased use of DNS anycast, load balancing, and other
-   mechanisms allowing more than one DNS name server to share a single
-   IP address, it is sometimes difficult to tell which of a pool of name
-   servers has answered a particular query.  While existing ad-hoc
-   mechanisms allow an operator to send follow-up queries when it is
-   necessary to debug such a configuration, the only completely reliable
-   way to obtain the identity of the name server that responded is to
-   have the name server include this information in the response itself.
-   This note defines a protocol extension to support this functionality.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                     Standards Track                     [Page 1]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     2.1.  Resolver Behavior  . . . . . . . . . . . . . . . . . . . .  3
-     2.2.  Name Server Behavior . . . . . . . . . . . . . . . . . . .  3
-     2.3.  The NSID Option  . . . . . . . . . . . . . . . . . . . . .  4
-     2.4.  Presentation Format  . . . . . . . . . . . . . . . . . . .  4
-   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  The NSID Payload . . . . . . . . . . . . . . . . . . . . .  4
-     3.2.  NSID Is Not Transitive . . . . . . . . . . . . . . . . . .  7
-     3.3.  User Interface Issues  . . . . . . . . . . . . . . . . . .  7
-     3.4.  Truncation . . . . . . . . . . . . . . . . . . . . . . . .  8
-   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
-
-1.  Introduction
-
-   With the increased use of DNS anycast, load balancing, and other
-   mechanisms allowing more than one DNS name server to share a single
-   IP address, it is sometimes difficult to tell which of a pool of name
-   servers has answered a particular query.
-
-   Existing ad-hoc mechanisms allow an operator to send follow-up
-   queries when it is necessary to debug such a configuration, but there
-   are situations in which this is not a totally satisfactory solution,
-   since anycast routing may have changed, or the server pool in
-   question may be behind some kind of extremely dynamic load balancing
-   hardware.  Thus, while these ad-hoc mechanisms are certainly better
-   than nothing (and have the advantage of already being deployed), a
-   better solution seems desirable.
-
-   Given that a DNS query is an idempotent operation with no retained
-   state, it would appear that the only completely reliable way to
-   obtain the identity of the name server that responded to a particular
-   query is to have that name server include identifying information in
-   the response itself.  This note defines a protocol enhancement to
-   achieve this.
-
-
-
-
-
-
-
-
-Austein                     Standards Track                     [Page 2]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-1.1.  Reserved Words
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Protocol
-
-   This note uses an EDNS [RFC2671] option to signal the resolver's
-   desire for information identifying the name server and to hold the
-   name server's response, if any.
-
-2.1.  Resolver Behavior
-
-   A resolver signals its desire for information identifying a name
-   server by sending an empty NSID option (Section 2.3) in an EDNS OPT
-   pseudo-RR in the query message.
-
-   The resolver MUST NOT include any NSID payload data in the query
-   message.
-
-   The semantics of an NSID request are not transitive.  That is: the
-   presence of an NSID option in a query is a request that the name
-   server which receives the query identify itself.  If the name server
-   side of a recursive name server receives an NSID request, the client
-   is asking the recursive name server to identify itself; if the
-   resolver side of the recursive name server wishes to receive
-   identifying information, it is free to add NSID requests in its own
-   queries, but that is a separate matter.
-
-2.2.  Name Server Behavior
-
-   A name server that understands the NSID option and chooses to honor a
-   particular NSID request responds by including identifying information
-   in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR in the
-   response message.
-
-   The name server MUST ignore any NSID payload data that might be
-   present in the query message.
-
-   The NSID option is not transitive.  A name server MUST NOT send an
-   NSID option back to a resolver which did not request it.  In
-   particular, while a recursive name server may choose to add an NSID
-   option when sending a query, this has no effect on the presence or
-   absence of the NSID option in the recursive name server's response to
-   the original client.
-
-
-
-
-
-Austein                     Standards Track                     [Page 3]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-   As stated in Section 2.1, this mechanism is not restricted to
-   authoritative name servers; the semantics are intended to be equally
-   applicable to recursive name servers.
-
-2.3.  The NSID Option
-
-   The OPTION-CODE for the NSID option is 3.
-
-   The OPTION-DATA for the NSID option is an opaque byte string, the
-   semantics of which are deliberately left outside the protocol.  See
-   Section 3.1 for discussion.
-
-2.4.  Presentation Format
-
-   User interfaces MUST read and write the contents of the NSID option
-   as a sequence of hexadecimal digits, two digits per payload octet.
-
-   The NSID payload is binary data.  Any comparison between NSID
-   payloads MUST be a comparison of the raw binary data.  Copy
-   operations MUST NOT assume that the raw NSID payload is null-
-   terminated.  Any resemblance between raw NSID payload data and any
-   form of text is purely a convenience, and does not change the
-   underlying nature of the payload data.
-
-   See Section 3.3 for discussion.
-
-3.  Discussion
-
-   This section discusses certain aspects of the protocol and explains
-   considerations that led to the chosen design.
-
-3.1.  The NSID Payload
-
-   The syntax and semantics of the content of the NSID option are
-   deliberately left outside the scope of this specification.
-
-   Choosing the NSID content is a prerogative of the server
-   administrator.  The server administrator might choose to encode the
-   NSID content in such a way that the server operator (or clients
-   authorized by the server operator) can decode the NSID content to
-   obtain more information than other clients can.  Alternatively, the
-   server operator might choose unencoded NSID content that is equally
-   meaningful to any client.
-
-   This section describes some of the kinds of data that server
-   administrators might choose to provide as the content of the NSID
-   option, and explains the reasoning behind specifying a simple opaque
-   byte string in Section 2.3.
-
-
-
-Austein                     Standards Track                     [Page 4]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-   There are several possibilities for the payload of the NSID option:
-
-   o  It could be the "real" name of the specific name server within the
-      name server pool.
-
-   o  It could be the "real" IP address (IPv4 or IPv6) of the name
-      server within the name server pool.
-
-   o  It could be some sort of pseudo-random number generated in a
-      predictable fashion somehow using the server's IP address or name
-      as a seed value.
-
-   o  It could be some sort of probabilistically unique identifier
-      initially derived from some sort of random number generator then
-      preserved across reboots of the name server.
-
-   o  It could be some sort of dynamically generated identifier so that
-      only the name server operator could tell whether or not any two
-      queries had been answered by the same server.
-
-   o  It could be a blob of signed data, with a corresponding key which
-      might (or might not) be available via DNS lookups.
-
-   o  It could be a blob of encrypted data, the key for which could be
-      restricted to parties with a need to know (in the opinion of the
-      server operator).
-
-   o  It could be an arbitrary string of octets chosen at the discretion
-      of the name server operator.
-
-   Each of these options has advantages and disadvantages:
-
-   o  Using the "real" name is simple, but the name server may not have
-      a "real" name.
-
-   o  Using the "real" address is also simple, and the name server
-      almost certainly does have at least one non-anycast IP address for
-      maintenance operations, but the operator of the name server may
-      not be willing to divulge its non-anycast address.
-
-   o  Given that one common reason for using anycast DNS techniques is
-      an attempt to harden a critical name server against denial of
-      service attacks, some name server operators are likely to want an
-      identifier other than the "real" name or "real" address of the
-      name server instance.
-
-   o  Using a hash or pseudo-random number can provide a fixed length
-      value that the resolver can use to tell two name servers apart
-
-
-
-Austein                     Standards Track                     [Page 5]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-      without necessarily being able to tell where either one of them
-      "really" is, but makes debugging more difficult if one happens to
-      be in a friendly open environment.  Furthermore, hashing might not
-      add much value, since a hash based on an IPv4 address still only
-      involves a 32-bit search space, and DNS names used for servers
-      that operators might have to debug at 4am tend not to be very
-      random.
-
-   o  Probabilistically unique identifiers have properties similar to
-      hashed identifiers, but (given a sufficiently good random number
-      generator) are immune to the search space issues.  However, the
-      strength of this approach is also its weakness: there is no
-      algorithmic transformation by which even the server operator can
-      associate name server instances with identifiers while debugging,
-      which might be annoying.  This approach also requires the name
-      server instance to preserve the probabilistically unique
-      identifier across reboots, but this does not appear to be a
-      serious restriction, since authoritative nameservers almost always
-      have some form of non-volatile storage.  In the rare case of a
-      name server that does not have any way to store such an
-      identifier, nothing terrible will happen if the name server
-      generates a new identifier every time it reboots.
-
-   o  Using an arbitrary octet string gives name server operators yet
-      another setting to configure, or mis-configure, or forget to
-      configure.  Having all the nodes in an anycast name server
-      constellation identify themselves as "My Name Server" would not be
-      particularly useful.
-
-   o  A signed blob is not particularly useful as an NSID payload unless
-      the signed data is dynamic and includes some kind of replay
-      protection, such as a timestamp or some kind of data identifying
-      the requestor.  Signed blobs that meet these criteria could
-      conceivably be useful in some situations but would require
-      detailed security analysis beyond the scope of this document.
-
-   o  A static encrypted blob would not be particularly useful, as it
-      would be subject to replay attacks and would, in effect, just be a
-      random number to any party that does not possess the decryption
-      key.  Dynamic encrypted blobs could conceivably be useful in some
-      situations but, as with signed blobs, dynamic encrypted blobs
-      would require detailed security analysis beyond the scope of this
-      document.
-
-   Given all of the issues listed above, there does not appear to be a
-   single solution that will meet all needs.  Section 2.3 therefore
-   defines the NSID payload to be an opaque byte string and leaves the
-   choice of payload up to the implementor and name server operator.
-
-
-
-Austein                     Standards Track                     [Page 6]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-   The following guidelines may be useful to implementors and server
-   operators:
-
-   o  Operators for whom divulging the unicast address is an issue could
-      use the raw binary representation of a probabilistically unique
-      random number.  This should probably be the default implementation
-      behavior.
-
-   o  Operators for whom divulging the unicast address is not an issue
-      could just use the raw binary representation of a unicast address
-      for simplicity.  This should only be done via an explicit
-      configuration choice by the operator.
-
-   o  Operators who really need or want the ability to set the NSID
-      payload to an arbitrary value could do so, but this should only be
-      done via an explicit configuration choice by the operator.
-
-   This approach appears to provide enough information for useful
-   debugging without unintentionally leaking the maintenance addresses
-   of anycast name servers to nogoodniks, while also allowing name
-   server operators who do not find such leakage threatening to provide
-   more information at their own discretion.
-
-3.2.  NSID Is Not Transitive
-
-   As specified in Section 2.1 and Section 2.2, the NSID option is not
-   transitive.  This is strictly a hop-by-hop mechanism.
-
-   Most of the discussion of name server identification to date has
-   focused on identifying authoritative name servers, since the best
-   known cases of anycast name servers are a subset of the name servers
-   for the root zone.  However, given that anycast DNS techniques are
-   also applicable to recursive name servers, the mechanism may also be
-   useful with recursive name servers.  The hop-by-hop semantics support
-   this.
-
-   While there might be some utility in having a transitive variant of
-   this mechanism (so that, for example, a stub resolver could ask a
-   recursive server to tell it which authoritative name server provided
-   a particular answer to the recursive name server), the semantics of
-   such a variant would be more complicated, and are left for future
-   work.
-
-3.3.  User Interface Issues
-
-   Given the range of possible payload contents described in
-   Section 3.1, it is not possible to define a single presentation
-   format for the NSID payload that is efficient, convenient,
-
-
-
-Austein                     Standards Track                     [Page 7]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-   unambiguous, and aesthetically pleasing.  In particular, while it is
-   tempting to use a presentation format that uses some form of textual
-   strings, attempting to support this would significantly complicate
-   what's intended to be a very simple debugging mechanism.
-
-   In some cases the content of the NSID payload may be binary data
-   meaningful only to the name server operator, and may not be
-   meaningful to the user or application, but the user or application
-   must be able to capture the entire content anyway in order for it to
-   be useful.  Thus, the presentation format must support arbitrary
-   binary data.
-
-   In cases where the name server operator derives the NSID payload from
-   textual data, a textual form such as US-ASCII or UTF-8 strings might
-   at first glance seem easier for a user to deal with.  There are,
-   however, a number of complex issues involving internationalized text
-   which, if fully addressed here, would require a set of rules
-   significantly longer than the rest of this specification.  See
-   [RFC2277] for an overview of some of these issues.
-
-   It is much more important for the NSID payload data to be passed
-   unambiguously from server administrator to user and back again than
-   it is for the payload data to be pretty while in transit.  In
-   particular, it's critical that it be straightforward for a user to
-   cut and paste an exact copy of the NSID payload output by a debugging
-   tool into other formats such as email messages or web forms without
-   distortion.  Hexadecimal strings, while ugly, are also robust.
-
-3.4.  Truncation
-
-   In some cases, adding the NSID option to a response message may
-   trigger message truncation.  This specification does not change the
-   rules for DNS message truncation in any way, but implementors will
-   need to pay attention to this issue.
-
-   Including the NSID option in a response is always optional, so this
-   specification never requires name servers to truncate response
-   messages.
-
-   By definition, a resolver that requests NSID responses also supports
-   EDNS, so a resolver that requests NSID responses can also use the
-   "sender's UDP payload size" field of the OPT pseudo-RR to signal a
-   receive buffer size large enough to make truncation unlikely.
-
-4.  IANA Considerations
-
-   IANA has allocated EDNS option code 3 for the NSID option
-   (Section 2.3).
-
-
-
-Austein                     Standards Track                     [Page 8]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-5.  Security Considerations
-
-   This document describes a channel signaling mechanism intended
-   primarily for debugging.  Channel signaling mechanisms are outside
-   the scope of DNSSEC, per se.  Applications that require integrity
-   protection for the data being signaled will need to use a channel
-   security mechanism such as TSIG [RFC2845].
-
-   Section 3.1 discusses a number of different kinds of information that
-   a name server operator might choose to provide as the value of the
-   NSID option.  Some of these kinds of information are security
-   sensitive in some environments.  This specification deliberately
-   leaves the syntax and semantics of the NSID option content up to the
-   implementation and the name server operator.
-
-   Two of the possible kinds of payload data discussed in Section 3.1
-   involve a digital signature and encryption, respectively.  While this
-   specification discusses some of the pitfalls that might lurk for
-   careless users of these kinds of payload data, full analysis of the
-   issues that would be involved in these kinds of payload data would
-   require knowledge of the content to be signed or encrypted,
-   algorithms to be used, and so forth, which is beyond the scope of
-   this document.  Implementors should seek competent advice before
-   attempting to use these kinds of NSID payloads.
-
-6.  Acknowledgements
-
-   Thanks to: Joe Abley, Harald Alvestrand, Dean Anderson, Mark Andrews,
-   Roy Arends, Steve Bellovin, Alex Bligh, Randy Bush, David Conrad,
-   John Dickinson, Alfred Hoenes, Johan Ihren, Daniel Karrenberg, Peter
-   Koch, William Leibzon, Ed Lewis, Thomas Narten, Mike Patton, Geoffrey
-   Sisson, Andrew Sullivan, Mike StJohns, Tom Taylor, Paul Vixie, Sam
-   Weiler, and Suzanne Woolf, none of whom are responsible for what the
-   author did with their comments and suggestions.  Apologies to anyone
-   inadvertently omitted from the above list.
-
-7.  References
-
-7.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, BCP 14, March 1997.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-
-
-
-
-
-Austein                     Standards Track                     [Page 9]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-7.2.  Informative References
-
-   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
-              Languages", RFC 2277, BCP 18, January 1998.
-
-Author's Address
-
-   Rob Austein
-   ISC
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   EMail: sra@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                     Standards Track                    [Page 10]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Austein                     Standards Track                    [Page 11]
-
diff --git a/doc/rfc/rfc5011.txt b/doc/rfc/rfc5011.txt
deleted file mode 100644
index 42235e97..00000000
--- a/doc/rfc/rfc5011.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. StJohns
-Request for Comments: 5011                                   Independent
-Category: Standards Track                                 September 2007
-
-
-        Automated Updates of DNS Security (DNSSEC) Trust Anchors
-
-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 describes a means for automated, authenticated, and
-   authorized updating of DNSSEC "trust anchors".  The method provides
-   protection against N-1 key compromises of N keys in the trust point
-   key set.  Based on the trust established by the presence of a current
-   anchor, other anchors may be added at the same place in the
-   hierarchy, and, ultimately, supplant the existing anchor(s).
-
-   This mechanism will require changes to resolver management behavior
-   (but not resolver resolution behavior), and the addition of a single
-   flag bit to the DNSKEY record.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                     Standards Track                     [Page 1]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-      1.1. Compliance Nomenclature ....................................3
-   2. Theory of Operation .............................................3
-      2.1. Revocation .................................................4
-      2.2. Add Hold-Down ..............................................4
-      2.3. Active Refresh .............................................5
-      2.4. Resolver Parameters ........................................6
-           2.4.1. Add Hold-Down Time ..................................6
-           2.4.2. Remove Hold-Down Time ...............................6
-           2.4.3. Minimum Trust Anchors per Trust Point ...............6
-   3. Changes to DNSKEY RDATA Wire Format .............................6
-   4. State Table .....................................................6
-      4.1. Events .....................................................7
-      4.2. States .....................................................7
-   5. Trust Point Deletion ............................................8
-   6. Scenarios - Informative .........................................9
-      6.1. Adding a Trust Anchor ......................................9
-      6.2. Deleting a Trust Anchor ....................................9
-      6.3. Key Roll-Over .............................................10
-      6.4. Active Key Compromised ....................................10
-      6.5. Stand-by Key Compromised ..................................10
-      6.6. Trust Point Deletion ......................................10
-   7. IANA Considerations ............................................11
-   8. Security Considerations ........................................11
-      8.1. Key Ownership vs. Acceptance Policy .......................11
-      8.2. Multiple Key Compromise ...................................12
-      8.3. Dynamic Updates ...........................................12
-   9. Normative References ...........................................12
-   10. Informative References ........................................12
-
-1.  Introduction
-
-   As part of the reality of fielding DNSSEC (Domain Name System
-   Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
-   come to the realization that there will not be one signed name space,
-   but rather islands of signed name spaces each originating from
-   specific points (i.e., 'trust points') in the DNS tree.  Each of
-   those islands will be identified by the trust point name, and
-   validated by at least one associated public key.  For the purpose of
-   this document, we'll call the association of that name and a
-   particular key a 'trust anchor'.  A particular trust point can have
-   more than one key designated as a trust anchor.
-
-   For a DNSSEC-aware resolver to validate information in a DNSSEC
-   protected branch of the hierarchy, it must have knowledge of a trust
-   anchor applicable to that branch.  It may also have more than one
-
-
-
-StJohns                     Standards Track                     [Page 2]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   trust anchor for any given trust point.  Under current rules, a chain
-   of trust for DNSSEC-protected data that chains its way back to ANY
-   known trust anchor is considered 'secure'.
-
-   Because of the probable balkanization of the DNSSEC tree due to
-   signing voids at key locations, a resolver may need to know literally
-   thousands of trust anchors to perform its duties (e.g., consider an
-   unsigned ".COM").  Requiring the owner of the resolver to manually
-   manage these many relationships is problematic.  It's even more
-   problematic when considering the eventual requirement for key
-   replacement/update for a given trust anchor.  The mechanism described
-   herein won't help with the initial configuration of the trust anchors
-   in the resolvers, but should make trust point key
-   replacement/rollover more viable.
-
-   As mentioned above, this document describes a mechanism whereby a
-   resolver can update the trust anchors for a given trust point, mainly
-   without human intervention at the resolver.  There are some corner
-   cases discussed (e.g., multiple key compromise) that may require
-   manual intervention, but they should be few and far between.  This
-   document DOES NOT discuss the general problem of the initial
-   configuration of trust anchors for the resolver.
-
-1.1.  Compliance Nomenclature
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14, [RFC2119].
-
-2.  Theory of Operation
-
-   The general concept of this mechanism is that existing trust anchors
-   can be used to authenticate new trust anchors at the same point in
-   the DNS hierarchy.  When a zone operator adds a new SEP key (i.e., a
-   DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section
-   2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
-   validated by an existing trust anchor, then the resolver can add the
-   new key to its set of valid trust anchors for that trust point.
-
-   There are some issues with this approach that need to be mitigated.
-   For example, a compromise of one of the existing keys could allow an
-   attacker to add their own 'valid' data.  This implies a need for a
-   method to revoke an existing key regardless of whether or not that
-   key is compromised.  As another example, assuming a single key
-   compromise, we need to prevent an attacker from adding a new key and
-   revoking all the other old keys.
-
-
-
-
-
-StJohns                     Standards Track                     [Page 3]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-2.1.  Revocation
-
-   Assume two trust anchor keys A and B.  Assume that B has been
-   compromised.  Without a specific revocation bit, B could invalidate A
-   simply by sending out a signed trust point key set that didn't
-   contain A.  To fix this, we add a mechanism that requires knowledge
-   of the private key of a DNSKEY to revoke that DNSKEY.
-
-   A key is considered revoked when the resolver sees the key in a
-   self-signed RRSet and the key has the REVOKE bit (see Section 7
-   below) set to '1'.  Once the resolver sees the REVOKE bit, it MUST
-   NOT use this key as a trust anchor or for any other purpose except to
-   validate the RRSIG it signed over the DNSKEY RRSet specifically for
-   the purpose of validating the revocation.  Unlike the 'Add' operation
-   below, revocation is immediate and permanent upon receipt of a valid
-   revocation at the resolver.
-
-   A self-signed RRSet is a DNSKEY RRSet that contains the specific
-   DNSKEY and for which there is a corresponding validated RRSIG record.
-   It's not a special DNSKEY RRSet, just a way of describing the
-   validation requirements for that RRSet.
-
-   N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint
-   than one without the bit set.  This affects the matching of a DNSKEY
-   to DS records in the parent [RFC3755], or the fingerprint stored at a
-   resolver used to configure a trust point.
-
-   In the given example, the attacker could revoke B because it has
-   knowledge of B's private key, but could not revoke A.
-
-2.2.  Add Hold-Down
-
-   Assume two trust point keys A and B.  Assume that B has been
-   compromised.  An attacker could generate and add a new trust anchor
-   key C (by adding C to the DNSKEY RRSet and signing it with B), and
-   then invalidate the compromised key.  This would result in both the
-   attacker and owner being able to sign data in the zone and have it
-   accepted as valid by resolvers.
-
-   To mitigate but not completely solve this problem, we add a hold-down
-   time to the addition of the trust anchor.  When the resolver sees a
-   new SEP key in a validated trust point DNSKEY RRSet, the resolver
-   starts an acceptance timer, and remembers all the keys that validated
-   the RRSet.  If the resolver ever sees the DNSKEY RRSet without the
-   new key but validly signed, it stops the acceptance process for that
-   key and resets the acceptance timer.  If all of the keys that were
-
-
-
-
-
-StJohns                     Standards Track                     [Page 4]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   originally used to validate this key are revoked prior to the timer
-   expiring, the resolver stops the acceptance process and resets the
-   timer.
-
-   Once the timer expires, the new key will be added as a trust anchor
-   the next time the validated RRSet with the new key is seen at the
-   resolver.  The resolver MUST NOT treat the new key as a trust anchor
-   until the hold-down time expires AND it has retrieved and validated a
-   DNSKEY RRSet after the hold-down time that contains the new key.
-
-   N.B.: Once the resolver has accepted a key as a trust anchor, the key
-   MUST be considered a valid trust anchor by that resolver until
-   explicitly revoked as described above.
-
-   In the given example, the zone owner can recover from a compromise by
-   revoking B and adding a new key D and signing the DNSKEY RRSet with
-   both A and B.
-
-   The reason this does not completely solve the problem has to do with
-   the distributed nature of DNS.  The resolver only knows what it sees.
-   A determined attacker who holds one compromised key could keep a
-   single resolver from realizing that the key had been compromised by
-   intercepting 'real' data from the originating zone and substituting
-   their own (e.g., using the example, signed only by B).  This is no
-   worse than the current situation assuming a compromised key.
-
-2.3.  Active Refresh
-
-   A resolver that has been configured for an automatic update of keys
-   from a particular trust point MUST query that trust point (e.g., do a
-   lookup for the DNSKEY RRSet and related RRSIG records) no less often
-   than the lesser of 15 days, half the original TTL for the DNSKEY
-   RRSet, or half the RRSIG expiration interval and no more often than
-   once per hour.  The expiration interval is the amount of time from
-   when the RRSIG was last retrieved until the expiration time in the
-   RRSIG.  That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
-   1/2*RRSigExpirationInterval))
-
-   If the query fails, the resolver MUST repeat the query until
-   satisfied no more often than once an hour and no less often than the
-   lesser of 1 day, 10% of the original TTL, or 10% of the original
-   expiration interval.  That is, retryTime = MAX (1 hour, MIN (1 day,
-   .1 * origTTL, .1 * expireInterval)).
-
-
-
-
-
-
-
-
-StJohns                     Standards Track                     [Page 5]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-2.4.  Resolver Parameters
-
-2.4.1.  Add Hold-Down Time
-
-   The add hold-down time is 30 days or the expiration time of the
-   original TTL of the first trust point DNSKEY RRSet that contained the
-   new key, whichever is greater.  This ensures that at least two
-   validated DNSKEY RRSets that contain the new key MUST be seen by the
-   resolver prior to the key's acceptance.
-
-2.4.2.  Remove Hold-Down Time
-
-   The remove hold-down time is 30 days.  This parameter is solely a key
-   management database bookeeping parameter.  Failure to remove
-   information about the state of defunct keys from the database will
-   not adversely impact the security of this protocol, but may end up
-   with a database cluttered with obsolete key information.
-
-2.4.3.  Minimum Trust Anchors per Trust Point
-
-   A compliant resolver MUST be able to manage at least five SEP keys
-   per trust point.
-
-3.  Changes to DNSKEY RDATA Wire Format
-
-   Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag.
-   If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY)
-   signed by the associated key, then the resolver MUST consider this
-   key permanently invalid for all purposes except for validating the
-   revocation.
-
-4.  State Table
-
-   The most important thing to understand is the resolver's view of any
-   key at a trust point.  The following state table describes this view
-   at various points in the key's lifetime.  The table is a normative
-   part of this specification.  The initial state of the key is 'Start'.
-   The resolver's view of the state of the key changes as various events
-   occur.
-
-   This is the state of a trust-point key as seen from the resolver.
-   The column on the left indicates the current state.  The header at
-   the top shows the next state.  The intersection of the two shows the
-   event that will cause the state to transition from the current state
-   to the next.
-
-
-
-
-
-
-StJohns                     Standards Track                     [Page 6]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-                             NEXT STATE
-           --------------------------------------------------
-    FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
-   ----------------------------------------------------------
-   Start   |       |NewKey  |       |       |       |       |
-   ----------------------------------------------------------
-   AddPend |KeyRem |        |AddTime|       |       |       |
-   ----------------------------------------------------------
-   Valid   |       |        |       |KeyRem |Revbit |       |
-   ----------------------------------------------------------
-   Missing |       |        |KeyPres|       |Revbit |       |
-   ----------------------------------------------------------
-   Revoked |       |        |       |       |       |RemTime|
-   ----------------------------------------------------------
-   Removed |       |        |       |       |       |       |
-   ----------------------------------------------------------
-
-                           State Table
-
-4.1.  Events
-
-   NewKey   The resolver sees a valid DNSKEY RRSet with a new SEP key.
-            That key will become a new trust anchor for the named trust
-            point after it's been present in the RRSet for at least 'add
-            time'.
-
-   KeyPres  The key has returned to the valid DNSKEY RRSet.
-
-   KeyRem   The resolver sees a valid DNSKEY RRSet that does not contain
-            this key.
-
-   AddTime  The key has been in every valid DNSKEY RRSet seen for at
-            least the 'add time'.
-
-   RemTime  A revoked key has been missing from the trust-point DNSKEY
-            RRSet for sufficient time to be removed from the trust set.
-
-   RevBit   The key has appeared in the trust anchor DNSKEY RRSet with
-            its "REVOKED" bit set, and there is an RRSig over the DNSKEY
-            RRSet signed by this key.
-
-4.2.  States
-
-   Start    The key doesn't yet exist as a trust anchor at the resolver.
-            It may or may not exist at the zone server, but either
-            hasn't yet been seen at the resolver or was seen but was
-            absent from the last DNSKEY RRSet (e.g., KeyRem event).
-
-
-
-
-StJohns                     Standards Track                     [Page 7]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   AddPend  The key has been seen at the resolver, has its 'SEP' bit
-            set, and has been included in a validated DNSKEY RRSet.
-            There is a hold-down time for the key before it can be used
-            as a trust anchor.
-
-   Valid    The key has been seen at the resolver and has been included
-            in all validated DNSKEY RRSets from the time it was first
-            seen through the hold-down time.  It is now valid for
-            verifying RRSets that arrive after the hold-down time.
-            Clarification: The DNSKEY RRSet does not need to be
-            continuously present at the resolver (e.g., its TTL might
-            expire).  If the RRSet is seen and is validated (i.e.,
-            verifies against an existing trust anchor), this key MUST be
-            in the RRSet, otherwise a 'KeyRem' event is triggered.
-
-   Missing  This is an abnormal state.  The key remains a valid trust-
-            point key, but was not seen at the resolver in the last
-            validated DNSKEY RRSet.  This is an abnormal state because
-            the zone operator should be using the REVOKE bit prior to
-            removal.
-
-   Revoked  This is the state a key moves to once the resolver sees an
-            RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet
-            contains this key with its REVOKE bit set to '1'.  Once in
-            this state, this key MUST permanently be considered invalid
-            as a trust anchor.
-
-   Removed  After a fairly long hold-down time, information about this
-            key may be purged from the resolver.  A key in the removed
-            state MUST NOT be considered a valid trust anchor.  (Note:
-            this state is more or less equivalent to the "Start" state,
-            except that it's bad practice to re-introduce previously
-            used keys -- think of this as the holding state for all the
-            old keys for which the resolver no longer needs to track
-            state.)
-
-5.  Trust Point Deletion
-
-   A trust point that has all of its trust anchors revoked is considered
-   deleted and is treated as if the trust point was never configured.
-   If there are no superior configured trust points, data at and below
-   the deleted trust point are considered insecure by the resolver.  If
-   there ARE superior configured trust points, data at and below the
-   deleted trust point are evaluated with respect to the superior trust
-   point(s).
-
-   Alternately, a trust point that is subordinate to another configured
-   trust point MAY be deleted by a resolver after 180 days, where such a
-
-
-
-StJohns                     Standards Track                     [Page 8]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   subordinate trust point validly chains to a superior trust point.
-   The decision to delete the subordinate trust anchor is a local
-   configuration decision.  Once the subordinate trust point is deleted,
-   validation of the subordinate zone is dependent on validating the
-   chain of trust to the superior trust point.
-
-6.  Scenarios - Informative
-
-   The suggested model for operation is to have one active key and one
-   stand-by key at each trust point.  The active key will be used to
-   sign the DNSKEY RRSet.  The stand-by key will not normally sign this
-   RRSet, but the resolver will accept it as a trust anchor if/when it
-   sees the signature on the trust point DNSKEY RRSet.
-
-   Since the stand-by key is not in active signing use, the associated
-   private key may (and should) be provided with additional protections
-   not normally available to a key that must be used frequently (e.g.,
-   locked in a safe, split among many parties, etc).  Notionally, the
-   stand-by key should be less subject to compromise than an active key,
-   but that will be dependent on operational concerns not addressed
-   here.
-
-6.1.  Adding a Trust Anchor
-
-   Assume an existing trust anchor key 'A'.
-
-   1.  Generate a new key pair.
-
-   2.  Create a DNSKEY record from the key pair and set the SEP and Zone
-       Key bits.
-
-   3.  Add the DNSKEY to the RRSet.
-
-   4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
-       'A'.
-
-   5.  Wait for various resolvers' timers to go off and for them to
-       retrieve the new DNSKEY RRSet and signatures.
-
-   6.  The new trust anchor will be populated at the resolvers on the
-       schedule described by the state table and update algorithm -- see
-       Sections 2 and 4 above.
-
-6.2.  Deleting a Trust Anchor
-
-   Assume existing trust anchors 'A' and 'B' and that you want to revoke
-   and delete 'A'.
-
-
-
-
-StJohns                     Standards Track                     [Page 9]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   1.  Set the revocation bit on key 'A'.
-
-   2.  Sign the DNSKEY RRSet with both 'A' and 'B'.  'A' is now revoked.
-       The operator should include the revoked 'A' in the RRSet for at
-       least the remove hold-down time, but then may remove it from the
-       DNSKEY RRSet.
-
-6.3.  Key Roll-Over
-
-   Assume existing keys A and B. 'A' is actively in use (i.e. has been
-   signing the DNSKEY RRSet).  'B' was the stand-by key. (i.e. has been
-   in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
-   used to sign the RRSet).
-
-      1.  Generate a new key pair 'C'.
-      2.  Add 'C' to the DNSKEY RRSet.
-      3.  Set the revocation bit on key 'A'.
-      4.  Sign the RRSet with 'A' and 'B'.
-
-   'A' is now revoked, 'B' is now the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  The operator should include
-   the revoked 'A' in the RRSet for at least the remove hold-down time,
-   but may then remove it from the DNSKEY RRSet.
-
-6.4.  Active Key Compromised
-
-   This is the same as the mechanism for Key Roll-Over (Section 6.3)
-   above, assuming 'A' is the active key.
-
-6.5.  Stand-by Key Compromised
-
-   Using the same assumptions and naming conventions as Key Roll-Over
-   (Section 6.3) above:
-
-      1.  Generate a new key pair 'C'.
-      2.  Add 'C' to the DNSKEY RRSet.
-      3.  Set the revocation bit on key 'B'.
-      4.  Sign the RRSet with 'A' and 'B'.
-
-   'B' is now revoked, 'A' remains the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  'B' should continue to be
-   included in the RRSet for the remove hold-down time.
-
-6.6.  Trust Point Deletion
-
-   To delete a trust point that is subordinate to another configured
-   trust point (e.g., example.com to .com) requires some juggling of the
-   data.  The specific process is:
-
-
-
-StJohns                     Standards Track                    [Page 10]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   1.  Generate a new DNSKEY and DS record and provide the DS record to
-       the parent along with DS records for the old keys.
-
-   2.  Once the parent has published the DSs, add the new DNSKEY to the
-       RRSet and revoke ALL of the old keys at the same time, while
-       signing the DNSKEY RRSet with all of the old and new keys.
-
-   3.  After 30 days, stop publishing the old, revoked keys and remove
-       any corresponding DS records in the parent.
-
-   Revoking the old trust-point keys at the same time as adding new keys
-   that chain to a superior trust prevents the resolver from adding the
-   new keys as trust anchors.  Adding DS records for the old keys avoids
-   a race condition where either the subordinate zone becomes unsecure
-   (because the trust point was deleted) or becomes bogus (because it
-   didn't chain to the superior zone).
-
-7.  IANA Considerations
-
-   The IANA has assigned a bit in the DNSKEY flags field (see Section 7
-   of [RFC4034]) for the REVOKE bit (8).
-
-8.  Security Considerations
-
-   In addition to the following sections, see also Theory of Operation
-   above (Section 2) and especially Section 2.2 for related discussions.
-
-   Security considerations for trust anchor rollover not specific to
-   this protocol are discussed in [RFC4986].
-
-8.1.  Key Ownership vs. Acceptance Policy
-
-   The reader should note that, while the zone owner is responsible for
-   creating and distributing keys, it's wholly the decision of the
-   resolver owner as to whether to accept such keys for the
-   authentication of the zone information.  This implies the decision to
-   update trust-anchor keys based on trusting a current trust-anchor key
-   is also the resolver owner's decision.
-
-   The resolver owner (and resolver implementers) MAY choose to permit
-   or prevent key status updates based on this mechanism for specific
-   trust points.  If they choose to prevent the automated updates, they
-   will need to establish a mechanism for manual or other out-of-band
-   updates, which are outside the scope of this document.
-
-
-
-
-
-
-
-StJohns                     Standards Track                    [Page 11]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-8.2.  Multiple Key Compromise
-
-   This scheme permits recovery as long as at least one valid trust-
-   anchor key remains uncompromised, e.g., if there are three keys, you
-   can recover if two of them are compromised.  The zone owner should
-   determine their own level of comfort with respect to the number of
-   active, valid trust anchors in a zone and should be prepared to
-   implement recovery procedures once they detect a compromise.  A
-   manual or other out-of-band update of all resolvers will be required
-   if all trust-anchor keys at a trust point are compromised.
-
-8.3.  Dynamic Updates
-
-   Allowing a resolver to update its trust anchor set based on in-band
-   key information is potentially less secure than a manual process.
-   However, given the nature of the DNS, the number of resolvers that
-   would require update if a trust anchor key were compromised, and the
-   lack of a standard management framework for DNS, this approach is no
-   worse than the existing situation.
-
-9.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer (DS)", RFC 3755, May 2004.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements", RFC
-              4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-10.  Informative References
-
-   [RFC4986]  Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy,
-              "Requirements Related to DNS Security (DNSSEC) Trust
-              Anchor Rollover", RFC 4986, August 2007.
-
-
-
-
-
-
-StJohns                     Standards Track                    [Page 12]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-Author's Address
-
-   Michael StJohns
-   Independent
-
-   EMail: mstjohns@comcast.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                     Standards Track                    [Page 13]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                     Standards Track                    [Page 14]
-
diff --git a/doc/rfc/rfc5155.txt b/doc/rfc/rfc5155.txt
deleted file mode 100644
index d4b72976..00000000
--- a/doc/rfc/rfc5155.txt
+++ /dev/null
@@ -1,2915 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          B. Laurie
-Request for Comments: 5155                                     G. Sisson
-Category: Standards Track                                      R. Arends
-                                                                 Nominet
-                                                               D. Blacka
-                                                          VeriSign, Inc.
-                                                              March 2008
-
-
-     DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   The Domain Name System Security (DNSSEC) Extensions introduced the
-   NSEC resource record (RR) for authenticated denial of existence.
-   This document introduces an alternative resource record, NSEC3, which
-   similarly provides authenticated denial of existence.  However, it
-   also provides measures against zone enumeration and permits gradual
-   expansion of delegation-centric zones.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.2.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . .  6
-   3.  The NSEC3 Resource Record  . . . . . . . . . . . . . . . . . .  7
-     3.1.  RDATA Fields . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.1.  Hash Algorithm . . . . . . . . . . . . . . . . . . . .  8
-       3.1.2.  Flags  . . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.3.  Iterations . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.4.  Salt Length  . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.5.  Salt . . . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.6.  Hash Length  . . . . . . . . . . . . . . . . . . . . .  9
-       3.1.7.  Next Hashed Owner Name . . . . . . . . . . . . . . . .  9
-       3.1.8.  Type Bit Maps  . . . . . . . . . . . . . . . . . . . .  9
-     3.2.  NSEC3 RDATA Wire Format  . . . . . . . . . . . . . . . . .  9
-       3.2.1.  Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10
-     3.3.  Presentation Format  . . . . . . . . . . . . . . . . . . . 11
-
-
-
-Laurie, et al.              Standards Track                     [Page 1]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   4.  The NSEC3PARAM Resource Record . . . . . . . . . . . . . . . . 12
-     4.1.  RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 12
-       4.1.1.  Hash Algorithm . . . . . . . . . . . . . . . . . . . . 12
-       4.1.2.  Flag Fields  . . . . . . . . . . . . . . . . . . . . . 12
-       4.1.3.  Iterations . . . . . . . . . . . . . . . . . . . . . . 13
-       4.1.4.  Salt Length  . . . . . . . . . . . . . . . . . . . . . 13
-       4.1.5.  Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     4.2.  NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 13
-     4.3.  Presentation Format  . . . . . . . . . . . . . . . . . . . 14
-   5.  Calculation of the Hash  . . . . . . . . . . . . . . . . . . . 14
-   6.  Opt-Out  . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
-   7.  Authoritative Server Considerations  . . . . . . . . . . . . . 16
-     7.1.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 16
-     7.2.  Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 17
-       7.2.1.  Closest Encloser Proof . . . . . . . . . . . . . . . . 18
-       7.2.2.  Name Error Responses . . . . . . . . . . . . . . . . . 19
-       7.2.3.  No Data Responses, QTYPE is not DS . . . . . . . . . . 19
-       7.2.4.  No Data Responses, QTYPE is DS . . . . . . . . . . . . 19
-       7.2.5.  Wildcard No Data Responses . . . . . . . . . . . . . . 19
-       7.2.6.  Wildcard Answer Responses  . . . . . . . . . . . . . . 20
-       7.2.7.  Referrals to Unsigned Subzones . . . . . . . . . . . . 20
-       7.2.8.  Responding to Queries for NSEC3 Owner Names  . . . . . 20
-       7.2.9.  Server Response to a Run-Time Collision  . . . . . . . 21
-     7.3.  Secondary Servers  . . . . . . . . . . . . . . . . . . . . 21
-     7.4.  Zones Using Unknown Hash Algorithms  . . . . . . . . . . . 21
-     7.5.  Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21
-   8.  Validator Considerations . . . . . . . . . . . . . . . . . . . 23
-     8.1.  Responses with Unknown Hash Types  . . . . . . . . . . . . 23
-     8.2.  Verifying NSEC3 RRs  . . . . . . . . . . . . . . . . . . . 23
-     8.3.  Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23
-     8.4.  Validating Name Error Responses  . . . . . . . . . . . . . 24
-     8.5.  Validating No Data Responses, QTYPE is not DS  . . . . . . 24
-     8.6.  Validating No Data Responses, QTYPE is DS  . . . . . . . . 24
-     8.7.  Validating Wildcard No Data Responses  . . . . . . . . . . 25
-     8.8.  Validating Wildcard Answer Responses . . . . . . . . . . . 25
-     8.9.  Validating Referrals to Unsigned Subzones  . . . . . . . . 25
-   9.  Resolver Considerations  . . . . . . . . . . . . . . . . . . . 26
-     9.1.  NSEC3 Resource Record Caching  . . . . . . . . . . . . . . 26
-     9.2.  Use of the AD Bit  . . . . . . . . . . . . . . . . . . . . 26
-   10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26
-     10.1. Domain Name Length Restrictions  . . . . . . . . . . . . . 26
-     10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 27
-     10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 27
-     10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 28
-     10.5. Transitioning a Signed Zone from NSEC3 to NSEC . . . . . . 28
-   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
-   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 30
-     12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30
-
-
-
-Laurie, et al.              Standards Track                     [Page 2]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-       12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30
-       12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 31
-       12.1.3. Transitioning to a New Hash Algorithm  . . . . . . . . 31
-       12.1.4. Using High Iteration Values  . . . . . . . . . . . . . 31
-     12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 32
-     12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 33
-   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
-     13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
-     13.2. Informative References . . . . . . . . . . . . . . . . . . 34
-   Appendix A.  Example Zone  . . . . . . . . . . . . . . . . . . . . 35
-   Appendix B.  Example Responses . . . . . . . . . . . . . . . . . . 40
-     B.1.  Name Error . . . . . . . . . . . . . . . . . . . . . . . . 40
-     B.2.  No Data Error  . . . . . . . . . . . . . . . . . . . . . . 42
-       B.2.1.  No Data Error, Empty Non-Terminal  . . . . . . . . . . 43
-     B.3.  Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 44
-     B.4.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 45
-     B.5.  Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46
-     B.6.  DS Child Zone No Data Error  . . . . . . . . . . . . . . . 48
-   Appendix C.  Special Considerations  . . . . . . . . . . . . . . . 48
-     C.1.  Salting  . . . . . . . . . . . . . . . . . . . . . . . . . 49
-     C.2.  Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49
-       C.2.1.  Avoiding Hash Collisions During Generation . . . . . . 50
-       C.2.2.  Second Preimage Requirement Analysis . . . . . . . . . 50
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 3]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-1.  Introduction
-
-1.1.  Rationale
-
-   The DNS Security Extensions included the NSEC RR to provide
-   authenticated denial of existence.  Though the NSEC RR meets the
-   requirements for authenticated denial of existence, it introduces a
-   side-effect in that the contents of a zone can be enumerated.  This
-   property introduces undesired policy issues.
-
-   The enumeration is enabled by the set of NSEC records that exists
-   inside a signed zone.  An NSEC record lists two names that are
-   ordered canonically, in order to show that nothing exists between the
-   two names.  The complete set of NSEC records lists all the names in a
-   zone.  It is trivial to enumerate the content of a zone by querying
-   for names that do not exist.
-
-   An enumerated zone can be used, for example, as a source of probable
-   e-mail addresses for spam, or as a key for multiple WHOIS queries to
-   reveal registrant data that many registries may have legal
-   obligations to protect.  Many registries therefore prohibit the
-   copying of their zone data; however, the use of NSEC RRs renders
-   these policies unenforceable.
-
-   A second problem is that the cost to cryptographically secure
-   delegations to unsigned zones is high, relative to the perceived
-   security benefit, in two cases: large, delegation-centric zones, and
-   zones where insecure delegations will be updated rapidly.  In these
-   cases, the costs of maintaining the NSEC RR chain may be extremely
-   high and use of the "Opt-Out" convention may be more appropriate (for
-   these unsecured zones).
-
-   This document presents the NSEC3 Resource Record which can be used as
-   an alternative to NSEC to mitigate these issues.
-
-   Earlier work to address these issues include [DNSEXT-NO], [RFC4956],
-   and [DNSEXT-NSEC2v2].
-
-1.2.  Requirements
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 4]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-1.3.  Terminology
-
-   The reader is assumed to be familiar with the basic DNS and DNSSEC
-   concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034],
-   [RFC4035], and subsequent RFCs that update them: [RFC2136],
-   [RFC2181], and [RFC2308].
-
-   The following terminology is used throughout this document:
-
-   Zone enumeration:  the practice of discovering the full content of a
-      zone via successive queries.  Zone enumeration was non-trivial
-      prior to the introduction of DNSSEC.
-
-   Original owner name:  the owner name corresponding to a hashed owner
-      name.
-
-   Hashed owner name:  the owner name created after applying the hash
-      function to an owner name.
-
-   Hash order:  the order in which hashed owner names are arranged
-      according to their numerical value, treating the leftmost (lowest
-      numbered) octet as the most significant octet.  Note that this
-      order is the same as the canonical DNS name order specified in
-      [RFC4034], when the hashed owner names are in base32, encoded with
-      an Extended Hex Alphabet [RFC4648].
-
-   Empty non-terminal:  a domain name that owns no resource records, but
-      has one or more subdomains that do.
-
-   Delegation:  an NS RRSet with a name different from the current zone
-      apex (non-zone-apex), signifying a delegation to a child zone.
-
-   Secure delegation:  a name containing a delegation (NS RRSet) and a
-      signed DS RRSet, signifying a delegation to a signed child zone.
-
-   Insecure delegation:  a name containing a delegation (NS RRSet), but
-      lacking a DS RRSet, signifying a delegation to an unsigned child
-      zone.
-
-   Opt-Out NSEC3 resource record:  an NSEC3 resource record that has the
-      Opt-Out flag set to 1.
-
-   Opt-Out zone:  a zone with at least one Opt-Out NSEC3 RR.
-
-   Closest encloser:  the longest existing ancestor of a name.  See also
-      Section 3.3.1 of [RFC4592].
-
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 5]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Closest provable encloser:  the longest ancestor of a name that can
-      be proven to exist.  Note that this is only different from the
-      closest encloser in an Opt-Out zone.
-
-   Next closer name:  the name one label longer than the closest
-      provable encloser of a name.
-
-   Base32:  the "Base 32 Encoding with Extended Hex Alphabet" as
-      specified in [RFC4648].  Note that trailing padding characters
-      ("=") are not used in the NSEC3 specification.
-
-   To cover:  An NSEC3 RR is said to "cover" a name if the hash of the
-      name or "next closer" name falls between the owner name and the
-      next hashed owner name of the NSEC3.  In other words, if it proves
-      the nonexistence of the name, either directly or by proving the
-      nonexistence of an ancestor of the name.
-
-   To match:  An NSEC3 RR is said to "match" a name if the owner name of
-      the NSEC3 RR is the same as the hashed owner name of that name.
-
-2.  Backwards Compatibility
-
-   This specification describes a protocol change that is not generally
-   backwards compatible with [RFC4033], [RFC4034], and [RFC4035].  In
-   particular, security-aware resolvers that are unaware of this
-   specification (NSEC3-unaware resolvers) may fail to validate the
-   responses introduced by this document.
-
-   In order to aid deployment, this specification uses a signaling
-   technique to prevent NSEC3-unaware resolvers from attempting to
-   validate responses from NSEC3-signed zones.
-
-   This specification allocates two new DNSKEY algorithm identifiers for
-   this purpose.  Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm
-   3, DSA.  Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5,
-   RSASHA1.  These are not new algorithms, they are additional
-   identifiers for the existing algorithms.
-
-   Zones signed according to this specification MUST only use these
-   algorithm identifiers for their DNSKEY RRs.  Because these new
-   identifiers will be unknown algorithms to existing, NSEC3-unaware
-   resolvers, those resolvers will then treat responses from the NSEC3
-   signed zone as insecure, as detailed in Section 5.2 of [RFC4035].
-
-   These algorithm identifiers are used with the NSEC3 hash algorithm
-   SHA1.  Using other NSEC3 hash algorithms requires allocation of a new
-   alias (see Section 12.1.3).
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 6]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Security aware resolvers that are aware of this specification MUST
-   recognize the new algorithm identifiers and treat them as equivalent
-   to the algorithms that they alias.
-
-   A methodology for transitioning from a DNSSEC signed zone to a zone
-   signed using NSEC3 is discussed in Section 10.4.
-
-3.  The NSEC3 Resource Record
-
-   The NSEC3 Resource Record (RR) provides authenticated denial of
-   existence for DNS Resource Record Sets.
-
-   The NSEC3 RR lists RR types present at the original owner name of the
-   NSEC3 RR.  It includes the next hashed owner name in the hash order
-   of the zone.  The complete set of NSEC3 RRs in a zone indicates which
-   RRSets exist for the original owner name of the RR and form a chain
-   of hashed owner names in the zone.  This information is used to
-   provide authenticated denial of existence for DNS data.  To provide
-   protection against zone enumeration, the owner names used in the
-   NSEC3 RR are cryptographic hashes of the original owner name
-   prepended as a single label to the name of the zone.  The NSEC3 RR
-   indicates which hash function is used to construct the hash, which
-   salt is used, and how many iterations of the hash function are
-   performed over the original owner name.  The hashing technique is
-   described fully in Section 5.
-
-   Hashed owner names of unsigned delegations may be excluded from the
-   chain.  An NSEC3 RR whose span covers the hash of an owner name or
-   "next closer" name of an unsigned delegation is referred to as an
-   Opt-Out NSEC3 RR and is indicated by the presence of a flag.
-
-   The owner name for the NSEC3 RR is the base32 encoding of the hashed
-   owner name prepended as a single label to the name of the zone.
-
-   The type value for the NSEC3 RR is 50.
-
-   The NSEC3 RR RDATA format is class independent and is described
-   below.
-
-   The class MUST be the same as the class of the original owner name.
-
-   The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
-   field.  This is in the spirit of negative caching [RFC2308].
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 7]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-3.1.  RDATA Fields
-
-3.1.1.  Hash Algorithm
-
-   The Hash Algorithm field identifies the cryptographic hash algorithm
-   used to construct the hash-value.
-
-   The values for this field are defined in the NSEC3 hash algorithm
-   registry defined in Section 11.
-
-3.1.2.  Flags
-
-   The Flags field contains 8 one-bit flags that can be used to indicate
-   different processing.  All undefined flags must be zero.  The only
-   flag defined by this specification is the Opt-Out flag.
-
-3.1.2.1.  Opt-Out Flag
-
-   If the Opt-Out flag is set, the NSEC3 record covers zero or more
-   unsigned delegations.
-
-   If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned
-   delegations.
-
-   The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned
-   delegations.  It is the least significant bit in the Flags field.
-   See Section 6 for details about the use of this flag.
-
-3.1.3.  Iterations
-
-   The Iterations field defines the number of additional times the hash
-   function has been performed.  More iterations result in greater
-   resiliency of the hash value against dictionary attacks, but at a
-   higher computational cost for both the server and resolver.  See
-   Section 5 for details of the use of this field, and Section 10.3 for
-   limitations on the value.
-
-3.1.4.  Salt Length
-
-   The Salt Length field defines the length of the Salt field in octets,
-   ranging in value from 0 to 255.
-
-3.1.5.  Salt
-
-   The Salt field is appended to the original owner name before hashing
-   in order to defend against pre-calculated dictionary attacks.  See
-   Section 5 for details on how the salt is used.
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 8]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-3.1.6.  Hash Length
-
-   The Hash Length field defines the length of the Next Hashed Owner
-   Name field, ranging in value from 1 to 255 octets.
-
-3.1.7.  Next Hashed Owner Name
-
-   The Next Hashed Owner Name field contains the next hashed owner name
-   in hash order.  This value is in binary format.  Given the ordered
-   set of all hashed owner names, the Next Hashed Owner Name field
-   contains the hash of an owner name that immediately follows the owner
-   name of the given NSEC3 RR.  The value of the Next Hashed Owner Name
-   field in the last NSEC3 RR in the zone is the same as the hashed
-   owner name of the first NSEC3 RR in the zone in hash order.  Note
-   that, unlike the owner name of the NSEC3 RR, the value of this field
-   does not contain the appended zone name.
-
-3.1.8.  Type Bit Maps
-
-   The Type Bit Maps field identifies the RRSet types that exist at the
-   original owner name of the NSEC3 RR.
-
-3.2.  NSEC3 RDATA Wire Format
-
-   The RDATA of the NSEC3 RR is as shown below:
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |   Hash Alg.   |     Flags     |          Iterations           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  Salt Length  |                     Salt                      /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  Hash Length  |             Next Hashed Owner Name            /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                         Type Bit Maps                         /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Hash Algorithm is a single octet.
-
-   Flags field is a single octet, the Opt-Out flag is the least
-   significant bit, as shown below:
-
-    0 1 2 3 4 5 6 7
-   +-+-+-+-+-+-+-+-+
-   |             |O|
-   +-+-+-+-+-+-+-+-+
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 9]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Iterations is represented as a 16-bit unsigned integer, with the most
-   significant bit first.
-
-   Salt Length is represented as an unsigned octet.  Salt Length
-   represents the length of the Salt field in octets.  If the value is
-   zero, the following Salt field is omitted.
-
-   Salt, if present, is encoded as a sequence of binary octets.  The
-   length of this field is determined by the preceding Salt Length
-   field.
-
-   Hash Length is represented as an unsigned octet.  Hash Length
-   represents the length of the Next Hashed Owner Name field in octets.
-
-   The next hashed owner name is not base32 encoded, unlike the owner
-   name of the NSEC3 RR.  It is the unmodified binary hash value.  It
-   does not include the name of the containing zone.  The length of this
-   field is determined by the preceding Hash Length field.
-
-3.2.1.  Type Bit Maps Encoding
-
-   The encoding of the Type Bit Maps field is the same as that used by
-   the NSEC RR, described in [RFC4034].  It is explained and clarified
-   here for clarity.
-
-   The RR type space is split into 256 window blocks, each representing
-   the low-order 8 bits of the 16-bit RR type space.  Each block that
-   has at least one active RR type is encoded using a single octet
-   window number (from 0 to 255), a single octet bitmap length (from 1
-   to 32) indicating the number of octets used for the bitmap of the
-   window block, and up to 32 octets (256 bits) of bitmap.
-
-   Blocks are present in the NSEC3 RR RDATA in increasing numerical
-   order.
-
-      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
-
-      where "|" denotes concatenation.
-
-   Each bitmap encodes the low-order 8 bits of RR types within the
-   window block, in network bit order.  The first bit is bit 0.  For
-   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
-   to RR type 2 (NS), and so forth.  For window block 1, bit 1
-   corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set to
-   1, it indicates that an RRSet of that type is present for the
-   original owner name of the NSEC3 RR.  If a bit is set to 0, it
-   indicates that no RRSet of that type is present for the original
-   owner name of the NSEC3 RR.
-
-
-
-Laurie, et al.              Standards Track                    [Page 10]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Since bit 0 in window block 0 refers to the non-existing RR type 0,
-   it MUST be set to 0.  After verification, the validator MUST ignore
-   the value of bit 0 in window block 0.
-
-   Bits representing Meta-TYPEs or QTYPEs as specified in Section 3.1 of
-   [RFC2929] or within the range reserved for assignment only to QTYPEs
-   and Meta-TYPEs MUST be set to 0, since they do not appear in zone
-   data.  If encountered, they must be ignored upon reading.
-
-   Blocks with no types present MUST NOT be included.  Trailing zero
-   octets in the bitmap MUST be omitted.  The length of the bitmap of
-   each block is determined by the type code with the largest numerical
-   value, within that block, among the set of RR types present at the
-   original owner name of the NSEC3 RR.  Trailing octets not specified
-   MUST be interpreted as zero octets.
-
-3.3.  Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   o  The Hash Algorithm field is represented as an unsigned decimal
-      integer.  The value has a maximum of 255.
-
-   o  The Flags field is represented as an unsigned decimal integer.
-      The value has a maximum of 255.
-
-   o  The Iterations field is represented as an unsigned decimal
-      integer.  The value is between 0 and 65535, inclusive.
-
-   o  The Salt Length field is not represented.
-
-   o  The Salt field is represented as a sequence of case-insensitive
-      hexadecimal digits.  Whitespace is not allowed within the
-      sequence.  The Salt field is represented as "-" (without the
-      quotes) when the Salt Length field has a value of 0.
-
-   o  The Hash Length field is not represented.
-
-   o  The Next Hashed Owner Name field is represented as an unpadded
-      sequence of case-insensitive base32 digits, without whitespace.
-
-   o  The Type Bit Maps field is represented as a sequence of RR type
-      mnemonics.  When the mnemonic is not known, the TYPE
-      representation as described in Section 5 of [RFC3597] MUST be
-      used.
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 11]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-4.  The NSEC3PARAM Resource Record
-
-   The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm,
-   flags, iterations, and salt) needed by authoritative servers to
-   calculate hashed owner names.  The presence of an NSEC3PARAM RR at a
-   zone apex indicates that the specified parameters may be used by
-   authoritative servers to choose an appropriate set of NSEC3 RRs for
-   negative responses.  The NSEC3PARAM RR is not used by validators or
-   resolvers.
-
-   If an NSEC3PARAM RR is present at the apex of a zone with a Flags
-   field value of zero, then there MUST be an NSEC3 RR using the same
-   hash algorithm, iterations, and salt parameters present at every
-   hashed owner name in the zone.  That is, the zone MUST contain a
-   complete set of NSEC3 RRs with the same hash algorithm, iterations,
-   and salt parameters.
-
-   The owner name for the NSEC3PARAM RR is the name of the zone apex.
-
-   The type value for the NSEC3PARAM RR is 51.
-
-   The NSEC3PARAM RR RDATA format is class independent and is described
-   below.
-
-   The class MUST be the same as the NSEC3 RRs to which this RR refers.
-
-4.1.  RDATA Fields
-
-   The RDATA for this RR mirrors the first four fields in the NSEC3 RR.
-
-4.1.1.  Hash Algorithm
-
-   The Hash Algorithm field identifies the cryptographic hash algorithm
-   used to construct the hash-value.
-
-   The acceptable values are the same as the corresponding field in the
-   NSEC3 RR.
-
-4.1.2.  Flag Fields
-
-   The Opt-Out flag is not used and is set to zero.
-
-   All other flags are reserved for future use, and must be zero.
-
-   NSEC3PARAM RRs with a Flags field value other than zero MUST be
-   ignored.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 12]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-4.1.3.  Iterations
-
-   The Iterations field defines the number of additional times the hash
-   is performed.
-
-   Its acceptable values are the same as the corresponding field in the
-   NSEC3 RR.
-
-4.1.4.  Salt Length
-
-   The Salt Length field defines the length of the salt in octets,
-   ranging in value from 0 to 255.
-
-4.1.5.  Salt
-
-   The Salt field is appended to the original owner name before hashing.
-
-4.2.  NSEC3PARAM RDATA Wire Format
-
-   The RDATA of the NSEC3PARAM RR is as shown below:
-
-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |   Hash Alg.   |     Flags     |          Iterations           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  Salt Length  |                     Salt                      /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Hash Algorithm is a single octet.
-
-   Flags field is a single octet.
-
-   Iterations is represented as a 16-bit unsigned integer, with the most
-   significant bit first.
-
-   Salt Length is represented as an unsigned octet.  Salt Length
-   represents the length of the following Salt field in octets.  If the
-   value is zero, the Salt field is omitted.
-
-   Salt, if present, is encoded as a sequence of binary octets.  The
-   length of this field is determined by the preceding Salt Length
-   field.
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 13]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-4.3.  Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   o  The Hash Algorithm field is represented as an unsigned decimal
-      integer.  The value has a maximum of 255.
-
-   o  The Flags field is represented as an unsigned decimal integer.
-      The value has a maximum value of 255.
-
-   o  The Iterations field is represented as an unsigned decimal
-      integer.  The value is between 0 and 65535, inclusive.
-
-   o  The Salt Length field is not represented.
-
-   o  The Salt field is represented as a sequence of case-insensitive
-      hexadecimal digits.  Whitespace is not allowed within the
-      sequence.  This field is represented as "-" (without the quotes)
-      when the Salt Length field is zero.
-
-5.  Calculation of the Hash
-
-   The hash calculation uses three of the NSEC3 RDATA fields: Hash
-   Algorithm, Salt, and Iterations.
-
-   Define H(x) to be the hash of x using the Hash Algorithm selected by
-   the NSEC3 RR, k to be the number of Iterations, and || to indicate
-   concatenation.  Then define:
-
-      IH(salt, x, 0) = H(x || salt), and
-
-      IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0
-
-   Then the calculated hash of an owner name is
-
-      IH(salt, owner name, iterations),
-
-   where the owner name is in the canonical form, defined as:
-
-   The wire format of the owner name where:
-
-   1.  The owner name is fully expanded (no DNS name compression) and
-       fully qualified;
-
-   2.  All uppercase US-ASCII letters are replaced by the corresponding
-       lowercase US-ASCII letters;
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 14]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   3.  If the owner name is a wildcard name, the owner name is in its
-       original unexpanded form, including the "*" label (no wildcard
-       substitution);
-
-   This form is as defined in Section 6.2 of [RFC4034].
-
-   The method to calculate the Hash is based on [RFC2898].
-
-6.  Opt-Out
-
-   In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS
-   RRSets at delegation points are not signed and may be accompanied by
-   a DS RRSet.  With the Opt-Out bit clear, the security status of the
-   child zone is determined by the presence or absence of this DS RRSet,
-   cryptographically proven by the signed NSEC3 RR at the hashed owner
-   name of the delegation.  Setting the Opt-Out flag modifies this by
-   allowing insecure delegations to exist within the signed zone without
-   a corresponding NSEC3 RR at the hashed owner name of the delegation.
-
-   An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the
-   owner name or "next closer" name of the delegation is between the
-   owner name of the NSEC3 RR and the next hashed owner name.
-
-   An Opt-Out NSEC3 RR does not assert the existence or non-existence of
-   the insecure delegations that it may cover.  This allows for the
-   addition or removal of these delegations without recalculating or re-
-   signing RRs in the NSEC3 RR chain.  However, Opt-Out NSEC3 RRs do
-   assert the (non)existence of other, authoritative RRSets.
-
-   An Opt-Out NSEC3 RR MAY have the same original owner name as an
-   insecure delegation.  In this case, the delegation is proven insecure
-   by the lack of a DS bit in the type map and the signed NSEC3 RR does
-   assert the existence of the delegation.
-
-   Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and
-   non-Opt-Out NSEC3 RRs.  If an NSEC3 RR is not Opt-Out, there MUST NOT
-   be any hashed owner names of insecure delegations (nor any other RRs)
-   between it and the name indicated by the next hashed owner name in
-   the NSEC3 RDATA.  If it is Opt-Out, it MUST only cover hashed owner
-   names or hashed "next closer" names of insecure delegations.
-
-   The effects of the Opt-Out flag on signing, serving, and validating
-   responses are covered in following sections.
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 15]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-7.  Authoritative Server Considerations
-
-7.1.  Zone Signing
-
-   Zones using NSEC3 must satisfy the following properties:
-
-   o  Each owner name within the zone that owns authoritative RRSets
-      MUST have a corresponding NSEC3 RR.  Owner names that correspond
-      to unsigned delegations MAY have a corresponding NSEC3 RR.
-      However, if there is not a corresponding NSEC3 RR, there MUST be
-      an Opt-Out NSEC3 RR that covers the "next closer" name to the
-      delegation.  Other non-authoritative RRs are not represented by
-      NSEC3 RRs.
-
-   o  Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
-      the empty non-terminal is only derived from an insecure delegation
-      covered by an Opt-Out NSEC3 RR.
-
-   o  The TTL value for any NSEC3 RR SHOULD be the same as the minimum
-      TTL value field in the zone SOA RR.
-
-   o  The Type Bit Maps field of every NSEC3 RR in a signed zone MUST
-      indicate the presence of all types present at the original owner
-      name, except for the types solely contributed by an NSEC3 RR
-      itself.  Note that this means that the NSEC3 type itself will
-      never be present in the Type Bit Maps.
-
-   The following steps describe a method of proper construction of NSEC3
-   RRs.  This is not the only such possible method.
-
-   1.  Select the hash algorithm and the values for salt and iterations.
-
-   2.  For each unique original owner name in the zone add an NSEC3 RR.
-
-       *  If Opt-Out is being used, owner names of unsigned delegations
-          MAY be excluded.
-
-       *  The owner name of the NSEC3 RR is the hash of the original
-          owner name, prepended as a single label to the zone name.
-
-       *  The Next Hashed Owner Name field is left blank for the moment.
-
-       *  If Opt-Out is being used, set the Opt-Out bit to one.
-
-       *  For collision detection purposes, optionally keep track of the
-          original owner name with the NSEC3 RR.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 16]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-       *  Additionally, for collision detection purposes, optionally
-          create an additional NSEC3 RR corresponding to the original
-          owner name with the asterisk label prepended (i.e., as if a
-          wildcard existed as a child of this owner name) and keep track
-          of this original owner name.  Mark this NSEC3 RR as temporary.
-
-   3.  For each RRSet at the original owner name, set the corresponding
-       bit in the Type Bit Maps field.
-
-   4.  If the difference in number of labels between the apex and the
-       original owner name is greater than 1, additional NSEC3 RRs need
-       to be added for every empty non-terminal between the apex and the
-       original owner name.  This process may generate NSEC3 RRs with
-       duplicate hashed owner names.  Optionally, for collision
-       detection, track the original owner names of these NSEC3 RRs and
-       create temporary NSEC3 RRs for wildcard collisions in a similar
-       fashion to step 1.
-
-   5.  Sort the set of NSEC3 RRs into hash order.
-
-   6.  Combine NSEC3 RRs with identical hashed owner names by replacing
-       them with a single NSEC3 RR with the Type Bit Maps field
-       consisting of the union of the types represented by the set of
-       NSEC3 RRs.  If the original owner name was tracked, then
-       collisions may be detected when combining, as all of the matching
-       NSEC3 RRs should have the same original owner name.  Discard any
-       possible temporary NSEC3 RRs.
-
-   7.  In each NSEC3 RR, insert the next hashed owner name by using the
-       value of the next NSEC3 RR in hash order.  The next hashed owner
-       name of the last NSEC3 RR in the zone contains the value of the
-       hashed owner name of the first NSEC3 RR in the hash order.
-
-   8.  Finally, add an NSEC3PARAM RR with the same Hash Algorithm,
-       Iterations, and Salt fields to the zone apex.
-
-   If a hash collision is detected, then a new salt has to be chosen,
-   and the signing process restarted.
-
-7.2.  Zone Serving
-
-   This specification modifies DNSSEC-enabled DNS responses generated by
-   authoritative servers.  In particular, it replaces the use of NSEC
-   RRs in such responses with NSEC3 RRs.
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 17]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   In the following response cases, the NSEC RRs dictated by DNSSEC
-   [RFC4035] are replaced with NSEC3 RRs that prove the same facts.
-   Responses that would not contain NSEC RRs are unchanged by this
-   specification.
-
-   When returning responses containing multiple NSEC3 RRs, all of the
-   NSEC3 RRs MUST use the same hash algorithm, iteration, and salt
-   values.  The Flags field value MUST be either zero or one.
-
-7.2.1.  Closest Encloser Proof
-
-   For many NSEC3 responses a proof of the closest encloser is required.
-   This is a proof that some ancestor of the QNAME is the closest
-   encloser of QNAME.
-
-   This proof consists of (up to) two different NSEC3 RRs:
-
-   o  An NSEC3 RR that matches the closest (provable) encloser.
-
-   o  An NSEC3 RR that covers the "next closer" name to the closest
-      encloser.
-
-   The first NSEC3 RR essentially proposes a possible closest encloser,
-   and proves that the particular encloser does, in fact, exist.  The
-   second NSEC3 RR proves that the possible closest encloser is the
-   closest, and proves that the QNAME (and any ancestors between QNAME
-   and the closest encloser) does not exist.
-
-   These NSEC3 RRs are collectively referred to as the "closest encloser
-   proof" in the subsequent descriptions.
-
-   For example, the closest encloser proof for the nonexistent
-   "alpha.beta.gamma.example." owner name might prove that
-   "gamma.example." is the closest encloser.  This response would
-   contain the NSEC3 RR that matches "gamma.example.", and would also
-   contain the NSEC3 RR that covers "beta.gamma.example." (which is the
-   "next closer" name).
-
-   It is possible, when using Opt-Out (Section 6), to not be able to
-   prove the actual closest encloser because it is, or is part of an
-   insecure delegation covered by an Opt-Out span.  In this case,
-   instead of proving the actual closest encloser, the closest provable
-   encloser is used.  That is, the closest enclosing authoritative name
-   is used instead.  In this case, the set of NSEC3 RRs used for this
-   proof is referred to as the "closest provable encloser proof".
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 18]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-7.2.2.  Name Error Responses
-
-   To prove the nonexistence of QNAME, a closest encloser proof and an
-   NSEC3 RR covering the (nonexistent) wildcard RR at the closest
-   encloser MUST be included in the response.  This collection of (up
-   to) three NSEC3 RRs proves both that QNAME does not exist and that a
-   wildcard that could have matched QNAME also does not exist.
-
-   For example, if "gamma.example." is the closest provable encloser to
-   QNAME, then an NSEC3 RR covering "*.gamma.example." is included in
-   the authority section of the response.
-
-7.2.3.  No Data Responses, QTYPE is not DS
-
-   The server MUST include the NSEC3 RR that matches QNAME.  This NSEC3
-   RR MUST NOT have the bits corresponding to either the QTYPE or CNAME
-   set in its Type Bit Maps field.
-
-7.2.4.  No Data Responses, QTYPE is DS
-
-   If there is an NSEC3 RR that matches QNAME, the server MUST return it
-   in the response.  The bits corresponding with DS and CNAME MUST NOT
-   be set in the Type Bit Maps field of this NSEC3 RR.
-
-   If no NSEC3 RR matches QNAME, the server MUST return a closest
-   provable encloser proof for QNAME.  The NSEC3 RR that covers the
-   "next closer" name MUST have the Opt-Out bit set (note that this is
-   true by definition -- if the Opt-Out bit is not set, something has
-   gone wrong).
-
-   If a server is authoritative for both sides of a zone cut at QNAME,
-   the server MUST return the proof from the parent side of the zone
-   cut.
-
-7.2.5.  Wildcard No Data Responses
-
-   If there is a wildcard match for QNAME, but QTYPE is not present at
-   that name, the response MUST include a closest encloser proof for
-   QNAME and MUST include the NSEC3 RR that matches the wildcard.  This
-   combination proves both that QNAME itself does not exist and that a
-   wildcard that matches QNAME does exist.  Note that the closest
-   encloser to QNAME MUST be the immediate ancestor of the wildcard RR
-   (if this is not the case, then something has gone wrong).
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 19]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-7.2.6.  Wildcard Answer Responses
-
-   If there is a wildcard match for QNAME and QTYPE, then, in addition
-   to the expanded wildcard RRSet returned in the answer section of the
-   response, proof that the wildcard match was valid must be returned.
-
-   This proof is accomplished by proving that both QNAME does not exist
-   and that the closest encloser of the QNAME and the immediate ancestor
-   of the wildcard are the same (i.e., the correct wildcard matched).
-
-   To this end, the NSEC3 RR that covers the "next closer" name of the
-   immediate ancestor of the wildcard MUST be returned.  It is not
-   necessary to return an NSEC3 RR that matches the closest encloser, as
-   the existence of this closest encloser is proven by the presence of
-   the expanded wildcard in the response.
-
-7.2.7.  Referrals to Unsigned Subzones
-
-   If there is an NSEC3 RR that matches the delegation name, then that
-   NSEC3 RR MUST be included in the response.  The DS bit in the type
-   bit maps of the NSEC3 RR MUST NOT be set.
-
-   If the zone is Opt-Out, then there may not be an NSEC3 RR
-   corresponding to the delegation.  In this case, the closest provable
-   encloser proof MUST be included in the response.  The included NSEC3
-   RR that covers the "next closer" name for the delegation MUST have
-   the Opt-Out flag set to one.  (Note that this will be the case unless
-   something has gone wrong).
-
-7.2.8.  Responding to Queries for NSEC3 Owner Names
-
-   The owner names of NSEC3 RRs are not represented in the NSEC3 RR
-   chain like other owner names.  As a result, each NSEC3 owner name is
-   covered by another NSEC3 RR, effectively negating the existence of
-   the NSEC3 RR.  This is a paradox, since the existence of an NSEC3 RR
-   can be proven by its RRSIG RRSet.
-
-   If the following conditions are all true:
-
-   o  the QNAME equals the owner name of an existing NSEC3 RR, and
-
-   o  no RR types exist at the QNAME, nor at any descendant of QNAME,
-
-   then the response MUST be constructed as a Name Error response
-   (Section 7.2.2).  Or, in other words, the authoritative name server
-   will act as if the owner name of the NSEC3 RR did not exist.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 20]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Note that NSEC3 RRs are returned as a result of an AXFR or IXFR
-   query.
-
-7.2.9.  Server Response to a Run-Time Collision
-
-   If the hash of a non-existing QNAME collides with the owner name of
-   an existing NSEC3 RR, then the server will be unable to return a
-   response that proves that QNAME does not exist.  In this case, the
-   server MUST return a response with an RCODE of 2 (server failure).
-
-   Note that with the hash algorithm specified in this document, SHA-1,
-   such collisions are highly unlikely.
-
-7.3.  Secondary Servers
-
-   Secondary servers (and perhaps other entities) need to reliably
-   determine which NSEC3 parameters (i.e., hash, salt, and iterations)
-   are present at every hashed owner name, in order to be able to choose
-   an appropriate set of NSEC3 RRs for negative responses.  This is
-   indicated by an NSEC3PARAM RR present at the zone apex.
-
-   If there are multiple NSEC3PARAM RRs present, there are multiple
-   valid NSEC3 chains present.  The server must choose one of them, but
-   may use any criteria to do so.
-
-7.4.  Zones Using Unknown Hash Algorithms
-
-   Zones that are signed according to this specification, but are using
-   an unrecognized NSEC3 hash algorithm value, cannot be effectively
-   served.  Such zones SHOULD be rejected when loading.  Servers SHOULD
-   respond with RCODE=2 (server failure) responses when handling queries
-   that would fall under such zones.
-
-7.5.  Dynamic Update
-
-   A zone signed using NSEC3 may accept dynamic updates [RFC2136].
-   However, NSEC3 introduces some special considerations for dynamic
-   updates.
-
-   Adding and removing names in a zone MUST account for the creation or
-   removal of empty non-terminals.
-
-   o  When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs
-      corresponding to empty non-terminals created by that name MUST be
-      removed.  Note that more than one name may be asserting the
-      existence of a particular empty non-terminal.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 21]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   o  When adding a name that requires adding an NSEC3 RR, NSEC3 RRs
-      MUST also be added for any empty non-terminals that are created.
-      That is, if there is not an existing NSEC3 RR matching an empty
-      non-terminal, it must be created and added.
-
-   The presence of Opt-Out in a zone means that some additions or
-   delegations of names will not require changes to the NSEC3 RRs in a
-   zone.
-
-   o  When removing a delegation RRSet, if that delegation does not have
-      a matching NSEC3 RR, then it was opted out.  In this case, nothing
-      further needs to be done.
-
-   o  When adding a delegation RRSet, if the "next closer" name of the
-      delegation is covered by an existing Opt-Out NSEC3 RR, then the
-      delegation MAY be added without modifying the NSEC3 RRs in the
-      zone.
-
-   The presence of Opt-Out in a zone means that when adding or removing
-   NSEC3 RRs, the value of the Opt-Out flag that should be set in new or
-   modified NSEC3 RRs is ambiguous.  Servers SHOULD follow this set of
-   basic rules to resolve the ambiguity.
-
-   The central concept to these rules is that the state of the Opt-Out
-   flag of the covering NSEC3 RR is preserved.
-
-   o  When removing an NSEC3 RR, the value of the Opt-Out flag for the
-      previous NSEC3 RR (the one whose next hashed owner name is
-      modified) should not be changed.
-
-   o  When adding an NSEC3 RR, the value of the Opt-Out flag is set to
-      the value of the Opt-Out flag of the NSEC3 RR that previously
-      covered the owner name of the NSEC3 RR.  That is, the now previous
-      NSEC3 RR.
-
-   If the zone in question is consistent with its use of the Opt-Out
-   flag (that is, all NSEC3 RRs in the zone have the same value for the
-   flag) then these rules will retain that consistency.  If the zone is
-   not consistent in the use of the flag (i.e., a partially Opt-Out
-   zone), then these rules will not retain the same pattern of use of
-   the Opt-Out flag.
-
-   For zones that partially use the Opt-Out flag, if there is a logical
-   pattern for that use, the pattern could be maintained by using a
-   local policy on the server.
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 22]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-8.  Validator Considerations
-
-8.1.  Responses with Unknown Hash Types
-
-   A validator MUST ignore NSEC3 RRs with unknown hash types.  The
-   practical result of this is that responses containing only such NSEC3
-   RRs will generally be considered bogus.
-
-8.2.  Verifying NSEC3 RRs
-
-   A validator MUST ignore NSEC3 RRs with a Flag fields value other than
-   zero or one.
-
-   A validator MAY treat a response as bogus if the response contains
-   NSEC3 RRs that contain different values for hash algorithm,
-   iterations, or salt from each other for that zone.
-
-8.3.  Closest Encloser Proof
-
-   In order to verify a closest encloser proof, the validator MUST find
-   the longest name, X, such that
-
-   o  X is an ancestor of QNAME that is matched by an NSEC3 RR present
-      in the response.  This is a candidate for the closest encloser,
-      and
-
-   o  The name one label longer than X (but still an ancestor of -- or
-      equal to -- QNAME) is covered by an NSEC3 RR present in the
-      response.
-
-   One possible algorithm for verifying this proof is as follows:
-
-   1.  Set SNAME=QNAME.  Clear the flag.
-
-   2.  Check whether SNAME exists:
-
-       *  If there is no NSEC3 RR in the response that matches SNAME
-          (i.e., an NSEC3 RR whose owner name is the same as the hash of
-          SNAME, prepended as a single label to the zone name), clear
-          the flag.
-
-       *  If there is an NSEC3 RR in the response that covers SNAME, set
-          the flag.
-
-       *  If there is a matching NSEC3 RR in the response and the flag
-          was set, then the proof is complete, and SNAME is the closest
-          encloser.
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 23]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-       *  If there is a matching NSEC3 RR in the response, but the flag
-          is not set, then the response is bogus.
-
-   3.  Truncate SNAME by one label from the left, go to step 2.
-
-   Once the closest encloser has been discovered, the validator MUST
-   check that the NSEC3 RR that has the closest encloser as the original
-   owner name is from the proper zone.  The DNAME type bit must not be
-   set and the NS type bit may only be set if the SOA type bit is set.
-   If this is not the case, it would be an indication that an attacker
-   is using them to falsely deny the existence of RRs for which the
-   server is not authoritative.
-
-   In the following descriptions, the phrase "a closest (provable)
-   encloser proof for X" means that the algorithm above (or an
-   equivalent algorithm) proves that X does not exist by proving that an
-   ancestor of X is its closest encloser.
-
-8.4.  Validating Name Error Responses
-
-   A validator MUST verify that there is a closest encloser proof for
-   QNAME present in the response and that there is an NSEC3 RR that
-   covers the wildcard at the closest encloser (i.e., the name formed by
-   prepending the asterisk label to the closest encloser).
-
-8.5.  Validating No Data Responses, QTYPE is not DS
-
-   The validator MUST verify that an NSEC3 RR that matches QNAME is
-   present and that both the QTYPE and the CNAME type are not set in its
-   Type Bit Maps field.
-
-   Note that this test also covers the case where the NSEC3 RR exists
-   because it corresponds to an empty non-terminal, in which case the
-   NSEC3 RR will have an empty Type Bit Maps field.
-
-8.6.  Validating No Data Responses, QTYPE is DS
-
-   If there is an NSEC3 RR that matches QNAME present in the response,
-   then that NSEC3 RR MUST NOT have the bits corresponding to DS and
-   CNAME set in its Type Bit Maps field.
-
-   If there is no such NSEC3 RR, then the validator MUST verify that a
-   closest provable encloser proof for QNAME is present in the response,
-   and that the NSEC3 RR that covers the "next closer" name has the Opt-
-   Out bit set.
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 24]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-8.7.  Validating Wildcard No Data Responses
-
-   The validator MUST verify a closest encloser proof for QNAME and MUST
-   find an NSEC3 RR present in the response that matches the wildcard
-   name generated by prepending the asterisk label to the closest
-   encloser.  Furthermore, the bits corresponding to both QTYPE and
-   CNAME MUST NOT be set in the wildcard matching NSEC3 RR.
-
-8.8.  Validating Wildcard Answer Responses
-
-   The verified wildcard answer RRSet in the response provides the
-   validator with a (candidate) closest encloser for QNAME.  This
-   closest encloser is the immediate ancestor to the generating
-   wildcard.
-
-   Validators MUST verify that there is an NSEC3 RR that covers the
-   "next closer" name to QNAME present in the response.  This proves
-   that QNAME itself did not exist and that the correct wildcard was
-   used to generate the response.
-
-8.9.  Validating Referrals to Unsigned Subzones
-
-   The delegation name in a referral is the owner name of the NS RRSet
-   present in the authority section of the referral response.
-
-   If there is an NSEC3 RR present in the response that matches the
-   delegation name, then the validator MUST ensure that the NS bit is
-   set and that the DS bit is not set in the Type Bit Maps field of the
-   NSEC3 RR.  The validator MUST also ensure that the NSEC3 RR is from
-   the correct (i.e., parent) zone.  This is done by ensuring that the
-   SOA bit is not set in the Type Bit Maps field of this NSEC3 RR.
-
-   Note that the presence of an NS bit implies the absence of a DNAME
-   bit, so there is no need to check for the DNAME bit in the Type Bit
-   Maps field of the NSEC3 RR.
-
-   If there is no NSEC3 RR present that matches the delegation name,
-   then the validator MUST verify a closest provable encloser proof for
-   the delegation name.  The validator MUST verify that the Opt-Out bit
-   is set in the NSEC3 RR that covers the "next closer" name to the
-   delegation name.
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 25]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-9.  Resolver Considerations
-
-9.1.  NSEC3 Resource Record Caching
-
-   Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs
-   when returning responses that contain them.  In DNSSEC [RFC4035], in
-   many cases it is possible to find the correct NSEC RR to return in a
-   response by name (e.g., when returning a referral, the NSEC RR will
-   always have the same owner name as the delegation).  With this
-   specification, that will not be true, nor will a cache be able to
-   calculate the name(s) of the appropriate NSEC3 RR(s).
-   Implementations may need to use new methods for caching and
-   retrieving NSEC3 RRs.
-
-9.2.  Use of the AD Bit
-
-   The AD bit, as defined by [RFC4035], MUST NOT be set when returning a
-   response containing a closest (provable) encloser proof in which the
-   NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.
-
-   This rule is based on what this closest encloser proof actually
-   proves: names that would be covered by the Opt-Out NSEC3 RR may or
-   may not exist as insecure delegations.  As such, not all the data in
-   responses containing such closest encloser proofs will have been
-   cryptographically verified, so the AD bit cannot be set.
-
-10.  Special Considerations
-
-10.1.  Domain Name Length Restrictions
-
-   Zones signed using this specification have additional domain name
-   length restrictions imposed upon them.  In particular, zones with
-   names that, when converted into hashed owner names exceed the 255
-   octet length limit imposed by [RFC1035], cannot use this
-   specification.
-
-   The actual maximum length of a domain name in a particular zone
-   depends on both the length of the zone name (versus the whole domain
-   name) and the particular hash function used.
-
-   As an example, SHA-1 produces a hash of 160 bits.  The base-32
-   encoding of 160 bits results in 32 characters.  The 32 characters are
-   prepended to the name of the zone as a single label, which includes a
-   length field of a single octet.  The maximum length of the zone name,
-   when using SHA-1, is 222 octets (255 - 33).
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 26]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-10.2.  DNAME at the Zone Apex
-
-   The DNAME specification in Section 3 of [RFC2672] has a 'no-
-   descendants' limitation.  If a DNAME RR is present at node N, there
-   MUST be no data at any descendant of N.
-
-   If N is the apex of the zone, there will be NSEC3 and RRSIG types
-   present at descendants of N.  This specification updates the DNAME
-   specification to allow NSEC3 and RRSIG types at descendants of the
-   apex regardless of the existence of DNAME at the apex.
-
-10.3.  Iterations
-
-   Setting the number of iterations used allows the zone owner to choose
-   the cost of computing a hash, and therefore the cost of generating a
-   dictionary.  Note that this is distinct from the effect of salt,
-   which prevents the use of a single precomputed dictionary for all
-   time.
-
-   Obviously the number of iterations also affects the zone owner's cost
-   of signing and serving the zone as well as the validator's cost of
-   verifying responses from the zone.  We therefore impose an upper
-   limit on the number of iterations.  We base this on the number of
-   iterations that approximates the cost of verifying an RRSet.
-
-   The limits, therefore, are based on the size of the smallest zone
-   signing key, rounded up to the nearest table value (or rounded down
-   if the key is larger than the largest table value).
-
-   A zone owner MUST NOT use a value higher than shown in the table
-   below for iterations for the given key size.  A resolver MAY treat a
-   response with a higher value as insecure, after the validator has
-   verified that the signature over the NSEC3 RR is correct.
-
-                         +----------+------------+
-                         | Key Size | Iterations |
-                         +----------+------------+
-                         | 1024     | 150        |
-                         | 2048     | 500        |
-                         | 4096     | 2,500      |
-                         +----------+------------+
-
-   This table is based on an approximation of the ratio between the cost
-   of an SHA-1 calculation and the cost of an RSA verification for keys
-   of size 1024 bits (150 to 1), 2048 bits (500 to 1), and 4096 bits
-   (2500 to 1).
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 27]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   The ratio between SHA-1 calculation and DSA verification is higher
-   (1500 to 1 for keys of size 1024).  A higher iteration count degrades
-   performance, while DSA verification is already more expensive than
-   RSA for the same key size.  Therefore the values in the table MUST be
-   used independent of the key algorithm.
-
-10.4.  Transitioning a Signed Zone from NSEC to NSEC3
-
-   When transitioning an already signed and trusted zone to this
-   specification, care must be taken to prevent client validation
-   failures during the process.
-
-   The basic procedure is as follows:
-
-   1.  Transition all DNSKEYs to DNSKEYs using the algorithm aliases
-       described in Section 2.  The actual method for safely and
-       securely changing the DNSKEY RRSet of the zone is outside the
-       scope of this specification.  However, the end result MUST be
-       that all DS RRs in the parent use the specified algorithm
-       aliases.
-
-       After this transition is complete, all NSEC3-unaware clients will
-       treat the zone as insecure.  At this point, the authoritative
-       server still returns negative and wildcard responses that contain
-       NSEC RRs.
-
-   2.  Add signed NSEC3 RRs to the zone, either incrementally or all at
-       once.  If adding incrementally, then the last RRSet added MUST be
-       the NSEC3PARAM RRSet.
-
-   3.  Upon the addition of the NSEC3PARAM RRSet, the server switches to
-       serving negative and wildcard responses with NSEC3 RRs according
-       to this specification.
-
-   4.  Remove the NSEC RRs either incrementally or all at once.
-
-10.5.  Transitioning a Signed Zone from NSEC3 to NSEC
-
-   To safely transition back to a DNSSEC [RFC4035] signed zone, simply
-   reverse the procedure above:
-
-   1.  Add NSEC RRs incrementally or all at once.
-
-   2.  Remove the NSEC3PARAM RRSet.  This will signal the server to use
-       the NSEC RRs for negative and wildcard responses.
-
-   3.  Remove the NSEC3 RRs either incrementally or all at once.
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 28]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   4.  Transition all of the DNSKEYs to DNSSEC algorithm identifiers.
-       After this transition is complete, all NSEC3-unaware clients will
-       treat the zone as secure.
-
-11.  IANA Considerations
-
-   Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
-   parameter, this document does not define a particular mechanism for
-   safely transitioning from one NSEC3 hash algorithm to another.  When
-   specifying a new hash algorithm for use with NSEC3, a transition
-   mechanism MUST also be defined.
-
-   This document updates the IANA registry "DOMAIN NAME SYSTEM
-   PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub-
-   registry "TYPES", by defining two new types.  Section 3 defines the
-   NSEC3 RR type 50.  Section 4 defines the NSEC3PARAM RR type 51.
-
-   This document updates the IANA registry "DNS SECURITY ALGORITHM
-   NUMBERS -- per [RFC4035]"
-   (http://www.iana.org/assignments/dns-sec-alg-numbers).  Section 2
-   defines the aliases DSA-NSEC3-SHA1 (6) and RSASHA1-NSEC3-SHA1 (7) for
-   respectively existing registrations DSA and RSASHA1 in combination
-   with NSEC3 hash algorithm SHA1.
-
-   Since these algorithm numbers are aliases for existing DNSKEY
-   algorithm numbers, the flags that exist for the original algorithm
-   are valid for the alias algorithm.
-
-   This document creates a new IANA registry for NSEC3 flags.  This
-   registry is named "DNSSEC NSEC3 Flags".  The initial contents of this
-   registry are:
-
-     0   1   2   3   4   5   6   7
-   +---+---+---+---+---+---+---+---+
-   |   |   |   |   |   |   |   |Opt|
-   |   |   |   |   |   |   |   |Out|
-   +---+---+---+---+---+---+---+---+
-
-      bit 7 is the Opt-Out flag.
-
-      bits 0 - 6 are available for assignment.
-
-   Assignment of additional NSEC3 Flags in this registry requires IETF
-   Standards Action [RFC2434].
-
-   This document creates a new IANA registry for NSEC3PARAM flags.  This
-   registry is named "DNSSEC NSEC3PARAM Flags".  The initial contents of
-   this registry are:
-
-
-
-Laurie, et al.              Standards Track                    [Page 29]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-     0   1   2   3   4   5   6   7
-   +---+---+---+---+---+---+---+---+
-   |   |   |   |   |   |   |   | 0 |
-   +---+---+---+---+---+---+---+---+
-
-      bit 7 is reserved and must be 0.
-
-      bits 0 - 6 are available for assignment.
-
-   Assignment of additional NSEC3PARAM Flags in this registry requires
-   IETF Standards Action [RFC2434].
-
-   Finally, this document creates a new IANA registry for NSEC3 hash
-   algorithms.  This registry is named "DNSSEC NSEC3 Hash Algorithms".
-   The initial contents of this registry are:
-
-      0 is Reserved.
-
-      1 is SHA-1.
-
-      2-255 Available for assignment.
-
-   Assignment of additional NSEC3 hash algorithms in this registry
-   requires IETF Standards Action [RFC2434].
-
-12.  Security Considerations
-
-12.1.  Hashing Considerations
-
-12.1.1.  Dictionary Attacks
-
-   The NSEC3 RRs are still susceptible to dictionary attacks (i.e., the
-   attacker retrieves all the NSEC3 RRs, then calculates the hashes of
-   all likely domain names, comparing against the hashes found in the
-   NSEC3 RRs, and thus enumerating the zone).  These are substantially
-   more expensive than enumerating the original NSEC RRs would have
-   been, and in any case, such an attack could also be used directly
-   against the name server itself by performing queries for all likely
-   names, though this would obviously be more detectable.  The expense
-   of this off-line attack can be chosen by setting the number of
-   iterations in the NSEC3 RR.
-
-   Zones are also susceptible to a pre-calculated dictionary attack --
-   that is, a list of hashes for all likely names is computed once, then
-   NSEC3 RR is scanned periodically and compared against the precomputed
-   hashes.  This attack is prevented by changing the salt on a regular
-   basis.
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 30]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   The salt SHOULD be at least 64 bits long and unpredictable, so that
-   an attacker cannot anticipate the value of the salt and compute the
-   next set of dictionaries before the zone is published.
-
-12.1.2.  Collisions
-
-   Hash collisions between QNAME and the owner name of an NSEC3 RR may
-   occur.  When they do, it will be impossible to prove the non-
-   existence of the colliding QNAME.  However, with SHA-1, this is
-   highly unlikely (on the order of 1 in 2^160).  Note that DNSSEC
-   already relies on the presumption that a cryptographic hash function
-   is second pre-image resistant, since these hash functions are used
-   for generating and validating signatures and DS RRs.
-
-12.1.3.  Transitioning to a New Hash Algorithm
-
-   Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
-   parameter, this document does not define a particular mechanism for
-   safely transitioning from one NSEC3 hash algorithm to another.  When
-   specifying a new hash algorithm for use with NSEC3, a transition
-   mechanism MUST also be defined.  It is possible that the only
-   practical and palatable transition mechanisms may require an
-   intermediate transition to an insecure state, or to a state that uses
-   NSEC records instead of NSEC3.
-
-12.1.4.  Using High Iteration Values
-
-   Since validators should treat responses containing NSEC3 RRs with
-   high iteration values as insecure, presence of just one signed NSEC3
-   RR with a high iteration value in a zone provides attackers with a
-   possible downgrade attack.
-
-   The attack is simply to remove any existing NSEC3 RRs from a
-   response, and replace or add a single (or multiple) NSEC3 RR that
-   uses a high iterations value to the response.  Validators will then
-   be forced to treat the response as insecure.  This attack would be
-   effective only when all of following conditions are met:
-
-   o  There is at least one signed NSEC3 RR that uses a high iterations
-      value present in the zone.
-
-   o  The attacker has access to one or more of these NSEC3 RRs.  This
-      is trivially true when the NSEC3 RRs with high iteration values
-      are being returned in typical responses, but may also be true if
-      the attacker can access the zone via AXFR or IXFR queries, or any
-      other methodology.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 31]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Using a high number of iterations also introduces an additional
-   denial-of-service opportunity against servers, since servers must
-   calculate several hashes per negative or wildcard response.
-
-12.2.  Opt-Out Considerations
-
-   The Opt-Out Flag (O) allows for unsigned names, in the form of
-   delegations to unsigned zones, to exist within an otherwise signed
-   zone.  All unsigned names are, by definition, insecure, and their
-   validity or existence cannot be cryptographically proven.
-
-   In general:
-
-   o  Resource records with unsigned names (whether existing or not)
-      suffer from the same vulnerabilities as RRs in an unsigned zone.
-      These vulnerabilities are described in more detail in [RFC3833]
-      (note in particular Section 2.3, "Name Chaining" and Section 2.6,
-      "Authenticated Denial of Domain Names").
-
-   o  Resource records with signed names have the same security whether
-      or not Opt-Out is used.
-
-   Note that with or without Opt-Out, an insecure delegation may be
-   undetectably altered by an attacker.  Because of this, the primary
-   difference in security when using Opt-Out is the loss of the ability
-   to prove the existence or nonexistence of an insecure delegation
-   within the span of an Opt-Out NSEC3 RR.
-
-   In particular, this means that a malicious entity may be able to
-   insert or delete RRs with unsigned names.  These RRs are normally NS
-   RRs, but this also includes signed wildcard expansions (while the
-   wildcard RR itself is signed, its expanded name is an unsigned name).
-
-   Note that being able to add a delegation is functionally equivalent
-   to being able to add any RR type: an attacker merely has to forge a
-   delegation to name server under his/her control and place whatever
-   RRs needed at the subzone apex.
-
-   While in particular cases, this issue may not present a significant
-   security problem, in general it should not be lightly dismissed.
-   Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly.
-   In particular, zone signing tools SHOULD NOT default to using Opt-
-   Out, and MAY choose to not support Opt-Out at all.
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 32]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-12.3.  Other Considerations
-
-   Walking the NSEC3 RRs will reveal the total number of RRs in the zone
-   (plus empty non-terminals), and also what types there are.  This
-   could be mitigated by adding dummy entries, but certainly an upper
-   limit can always be found.
-
-13.  References
-
-13.1.  Normative References
-
-   [RFC1034]         Mockapetris, P., "Domain names - concepts and
-                     facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC1035]         Mockapetris, P., "Domain names - implementation and
-                     specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
-                     Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136]         Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
-                     "Dynamic Updates in the Domain Name System (DNS
-                     UPDATE)", RFC 2136, April 1997.
-
-   [RFC2181]         Elz, R. and R. Bush, "Clarifications to the DNS
-                     Specification", RFC 2181, July 1997.
-
-   [RFC2308]         Andrews, M., "Negative Caching of DNS Queries (DNS
-                     NCACHE)", RFC 2308, March 1998.
-
-   [RFC2434]         Narten, T. and H. Alvestrand, "Guidelines for
-                     Writing an IANA Considerations Section in RFCs",
-                     BCP 26, RFC 2434, October 1998.
-
-   [RFC2929]         Eastlake, D., Brunner-Williams, E., and B. Manning,
-                     "Domain Name System (DNS) IANA Considerations",
-                     BCP 42, RFC 2929, September 2000.
-
-   [RFC3597]         Gustafsson, A., "Handling of Unknown DNS Resource
-                     Record (RR) Types", RFC 3597, September 2003.
-
-   [RFC4033]         Arends, R., Austein, R., Larson, M., Massey, D.,
-                     and S. Rose, "DNS Security Introduction and
-                     Requirements", RFC 4033, March 2005.
-
-   [RFC4034]         Arends, R., Austein, R., Larson, M., Massey, D.,
-                     and S. Rose, "Resource Records for the DNS Security
-                     Extensions", RFC 4034, March 2005.
-
-
-
-Laurie, et al.              Standards Track                    [Page 33]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   [RFC4035]         Arends, R., Austein, R., Larson, M., Massey, D.,
-                     and S. Rose, "Protocol Modifications for the DNS
-                     Security Extensions", RFC 4035, March 2005.
-
-   [RFC4648]         Josefsson, S., "The Base16, Base32, and Base64 Data
-                     Encodings", RFC 4648, October 2006.
-
-13.2.  Informative References
-
-   [DNSEXT-NO]       Josefsson, S., "Authenticating Denial of Existence
-                     in DNS with Minimum Disclosure", Work in Progress,
-                     July 2000.
-
-   [DNSEXT-NSEC2v2]  Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format",
-                     Work in Progress, December 2004.
-
-   [RFC2672]         Crawford, M., "Non-Terminal DNS Name Redirection",
-                     RFC 2672, August 1999.
-
-   [RFC2898]         Kaliski, B., "PKCS #5: Password-Based Cryptography
-                     Specification Version 2.0", RFC 2898,
-                     September 2000.
-
-   [RFC3833]         Atkins, D. and R. Austein, "Threat Analysis of the
-                     Domain Name System (DNS)", RFC 3833, August 2004.
-
-   [RFC4592]         Lewis, E., "The Role of Wildcards in the Domain
-                     Name System", RFC 4592, July 2006.
-
-   [RFC4956]         Arends, R., Kosters, M., and D. Blacka, "DNS
-                     Security (DNSSEC) Opt-In", RFC 4956, July 2007.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 34]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-Appendix A.  Example Zone
-
-   This is a zone showing its NSEC3 RRs.  They can also be used as test
-   vectors for the hash algorithm.
-
-   The overall TTL and class are specified in the SOA RR, and are
-   subsequently omitted for clarity.
-
-   The zone is preceded by a list that contains the hashes of the
-   original ownernames.
-
-   ; H(example)       = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
-   ; H(a.example)     = 35mthgpgcu1qg68fab165klnsnk3dpvl
-   ; H(ai.example)    = gjeqe526plbf1g8mklp59enfd789njgi
-   ; H(ns1.example)   = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
-   ; H(ns2.example)   = q04jkcevqvmu85r014c7dkba38o0ji5r
-   ; H(w.example)     = k8udemvp1j2f7eg6jebps17vp3n8i58h
-   ; H(*.w.example)   = r53bq7cc2uvmubfu5ocmm6pers9tk9en
-   ; H(x.w.example)   = b4um86eghhds6nea196smvmlo4ors995
-   ; H(y.w.example)   = ji6neoaepv8b5o6k4ev33abha8ht9fgc
-   ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
-   ; H(xx.example)    = t644ebqk9bibcna874givr6joj62mlhv
-   ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example)
-   ;                  = kohar7mbb8dc2ce8a9qvl8hon4k53uhi
-   example. 3600  IN SOA  ns1.example. bugs.x.w.example. 1 3600 300 (
-                          3600000 3600 )
-                  RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                          q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                          VI2LmKusbZsT0Q== )
-                  NS      ns1.example.
-                  NS      ns2.example.
-                  RRSIG   NS 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
-                          qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
-                          CnMXjtz6SyObxA== )
-                  MX      1 xx.example.
-                  RRSIG   MX 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          GgQ1A9xs47k42VPvpL/a1BWUz/6XsnHkjotw
-                          9So8MQtZtl2wJBsnOQsaoHrRCrRbyriEl/GZ
-                          n9Mto/Kx+wBo+w== )
-                  DNSKEY  256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU (
-                          sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h
-                          TY4hHn9npWFRw5BYubE= )
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 35]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-                  DNSKEY  257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ (
-                          j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9
-                          AbsUdblMFin8CVF3n4s= )
-                  RRSIG   DNSKEY 7 1 3600 20150420235959 (
-                          20051021000000 12708 example.
-                          AuU4juU9RaxescSmStrQks3Gh9FblGBlVU31
-                          uzMZ/U/FpsUb8aC6QZS+sTsJXnLnz7flGOsm
-                          MGQZf3bH+QsCtg== )
-                  NSEC3PARAM 1 0 12 aabbccdd
-                  RRSIG   NSEC3PARAM 7 1 3600 20150420235959 (
-                          20051021000000 40430 example.
-                          C1Gl8tPZNtnjlrYWDeeUV/sGLCyy/IHie2re
-                          rN05XSA3Pq0U3+4VvGWYWdUMfflOdxqnXHwJ
-                          TLQsjlkynhG6Cg== )
-   0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
-                          2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
-                          SOA NSEC3PARAM RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
-                          IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
-                          BOCXJZMnpuwhpA== )
-   2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          h6c++bzhRuWWt2bykN6mjaTNBcXNq5UuL5Ed
-                          K+iDP4eY8I0kSiKaCjg3tC1SQkeloMeub2GW
-                          k8p6xHMPZumXlw== )
-                  NSEC3   1 1 12 aabbccdd (
-                          2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
-                          4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
-                          NI6mRk/r1dOSUw== )
-   2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd (
-                          35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          KL1V2oFYghNV0Hm7Tf2vpJjM6l+0g1JCcVYG
-                          VfI0lKrhPmTsOA96cLEACgo1x8I7kApJX+ob
-                          TuktZ+sdsZPY1w== )
-   35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
-                          b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 36]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
-                          Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
-                          XtAIR3chwgW+SA== )
-   a.example.     NS      ns1.a.example.
-                  NS      ns2.a.example.
-                  DS      58470 5 1 (
-                          3079F1593EBAD6DC121E202A8B766A6A4837206C )
-                  RRSIG   DS 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          XacFcQVHLVzdoc45EJhN616zQ4mEXtE8FzUh
-                          M2KWjfy1VfRKD9r1MeVGwwoukOKgJxBPFsWo
-                          o722vZ4UZ2dIdA== )
-   ns1.a.example. A       192.0.2.5
-   ns2.a.example. A       192.0.2.6
-   ai.example.    A       192.0.2.9
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
-                          tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
-                          rznEn8sQ64UdqA== )
-                  HINFO   "KLH-10" "ITS"
-                  RRSIG   HINFO 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          Yi42uOq43eyO6qXHNvwwfFnIustWgV5urFcx
-                          enkLvs6pKRh00VBjODmf3Z4nMO7IOl6nHSQ1
-                          v0wLHpEZG7Xj2w== )
-                  AAAA    2001:db8:0:0:0:0:f00:baa9
-                  RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
-                          uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
-                          cHueLuXkMjBArQ== )
-   b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
-                          gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
-                          5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
-                          pOv0TSTyiTxIZg== )
-   c.example.     NS      ns1.c.example.
-                  NS      ns2.c.example.
-   ns1.c.example. A       192.0.2.7
-   ns2.c.example. A       192.0.2.8
-   gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd (
-                          ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA
-                          RRSIG )
-
-
-
-Laurie, et al.              Standards Track                    [Page 37]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          IVnezTJ9iqblFF97vPSmfXZ5Zozngx3KX3by
-                          LTZC4QBH2dFWhf6scrGFZB980AfCxoD9qbbK
-                          Dy+rdGIeRSVNyw== )
-   ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
-                          k8udemvp1j2f7eg6jebps17vp3n8i58h )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
-                          2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
-                          MpzVSKfTwx4uYA== )
-   k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
-                          kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
-                          S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
-                          Otx7w9WfcIg62A== )
-   kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd (
-                          q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          VrDXs2uVW21N08SyQIz88zml+y4ZCInTwgDr
-                          6zz43yAg+LFERjOrj3Ojct51ac7Dp4eZbf9F
-                          QJazmASFKGxGXg== )
-   ns1.example.   A       192.0.2.1
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          bu6kx73n6XEunoVGuRfAgY7EF/AJqHy7hj0j
-                          kiqJjB0dOrx3wuz9SaBeGfqWIdn/uta3SavN
-                          4FRvZR9SCFHF5Q== )
-   ns2.example.   A       192.0.2.2
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          ktQ3TqE0CfRfki0Rb/Ip5BM0VnxelbuejCC4
-                          zpLbFKA/7eD7UNAwxMgxJPtbdST+syjYSJaj
-                          4IHfeX6n8vfoGA== )
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
-                          r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
-                          ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
-                          NlkxWcLsIlMmUg== )
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 38]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
-                          t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
-                          ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
-                          HF1FWKW7RIJdtQ== )
-   t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd (
-                          0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA
-                          RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          RAjGECB8P7O+F4Pa4Dx3tC0M+Z3KmlLKImca
-                          fb9XWwx+NWUNz7NBEDBQHivIyKPVDkChcePI
-                          X1xPl1ATNa+8Dw== )
-   *.w.example.   MX      1 ai.example.
-                  RRSIG   MX 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
-                          9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
-                          ivEBP6+4KS3ldA== )
-   x.w.example.   MX      1 xx.example.
-                  RRSIG   MX 7 3 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          IrK3tq/tHFIBF0scHiE/1IwMAvckS/55hAVv
-                          QyxTFbkAdDloP3NbZzu+yoSsr3b3OX6qbBpY
-                          7WCtwwekLKRAwQ== )
-   x.y.w.example. MX      1 xx.example.
-                  RRSIG   MX 7 4 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          MqSt5HqJIN8+SLlzTOImrh5h9Xa6gDvAW/Gn
-                          nbdPc6Z7nXvCpLPJj/5lCwx3VuzVOjkbvXze
-                          8/8Ccl2Zn2hbug== )
-   xx.example.    A       192.0.2.10
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          T35hBWEZ017VC5u2c4OriKyVn/pu+fVK4AlX
-                          YOxJ6iQylfV2HQIKjv6b7DzINB3aF/wjJqgX
-                          pQvhq+Ac6+ZiFg== )
-                  HINFO   "KLH-10" "TOPS-20"
-                  RRSIG   HINFO 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          KimG+rDd+7VA1zRsu0ITNAQUTRlpnsmqWrih
-                          FRnU+bRa93v2e5oFNFYCs3Rqgv62K93N7AhW
-                          6Jfqj/8NzWjvKg== )
-                  AAAA    2001:db8:0:0:0:0:f00:baaa
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 39]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-                  RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          IXBcXORITNwd8h3gNwyxtYFvAupS/CYWufVe
-                          uBUX0O25ivBCULjZjpDxFSxfohb/KA7YRdxE
-                          NzYfMItpILl/Xw== )
-
-Appendix B.  Example Responses
-
-   The examples in this section show response messages using the signed
-   zone example in Appendix A.
-
-B.1.  Name Error
-
-   An authoritative name error.  The NSEC3 RRs prove that the name does
-   not exist and that there is no wildcard RR that should have been
-   expanded.
-
-;; Header: QR AA DO RCODE=3
-;;
-;; Question
-a.c.x.w.example.         IN A
-
-;; Answer
-;; (empty)
-
-;; Authority
-
-example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                       3600000 3600 )
-example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                       40430 example.
-                       Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                       q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                       VI2LmKusbZsT0Q== )
-
-;; NSEC3 RR that covers the "next closer" name (c.x.w.example)
-;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh
-
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
-                       2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
-                       SOA NSEC3PARAM RRSIG )
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
-                       20150420235959 20051021000000 40430 example.
-                       OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
-                       IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
-                       BOCXJZMnpuwhpA== )
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 40]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-;; NSEC3 RR that matches the closest encloser (x.w.example)
-;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
-
-b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
-                       gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
-b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 7 2 3600 (
-                       20150420235959 20051021000000 40430 example.
-                       ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
-                       5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
-                       pOv0TSTyiTxIZg== )
-
-;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example)
-;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m
-
-35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
-                       b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
-35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
-                       20150420235959 20051021000000 40430 example.
-                       g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
-                       Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
-                       XtAIR3chwgW+SA== )
-
-;; Additional
-;; (empty)
-
-   The query returned three NSEC3 RRs that prove that the requested data
-   does not exist and that no wildcard expansion applies.  The negative
-   response is authenticated by verifying the NSEC3 RRs.  The
-   corresponding RRSIGs indicate that the NSEC3 RRs are signed by an
-   "example" DNSKEY of algorithm 7 and with key tag 40430.  The resolver
-   needs the corresponding DNSKEY RR in order to authenticate this
-   answer.
-
-   One of the owner names of the NSEC3 RRs matches the closest encloser.
-   One of the NSEC3 RRs prove that there exists no longer name.  One of
-   the NSEC3 RRs prove that there exists no wildcard RRSets that should
-   have been expanded.  The closest encloser can be found by applying
-   the algorithm in Section 8.3.
-
-   In the above example, the name 'x.w.example' hashes to
-   'b4um86eghhds6nea196smvmlo4ors995'.  This indicates that this might
-   be the closest encloser.  To prove that 'c.x.w.example' and
-   '*.x.w.example' do not exist, these names are hashed to,
-   respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and
-   '92pqneegtaue7pjatc3l3qnk738c6v5m'.  The first and last NSEC3 RRs
-   prove that these hashed owner names do not exist.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 41]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-B.2.  No Data Error
-
-   A "no data" response.  The NSEC3 RR proves that the name exists and
-   that the requested RR type does not.
-
-;; Header: QR AA DO RCODE=0
-;;
-;; Question
-ns1.example.        IN MX
-
-;; Answer
-;; (empty)
-
-;; Authority
-example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                       3600000 3600 )
-example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                       40430 example.
-                       Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                       q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                       VI2LmKusbZsT0Q== )
-
-;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set.
-
-2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd (
-                       2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
-2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 7 2 3600 (
-                       20150420235959 20051021000000 40430 example.
-                       OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
-                       4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
-                       NI6mRk/r1dOSUw== )
-;; Additional
-;; (empty)
-
-   The query returned an NSEC3 RR that proves that the requested name
-   exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"),
-   but the requested RR type does not exist (type MX is absent in the
-   type code list of the NSEC3 RR), and was not a CNAME (type CNAME is
-   also absent in the type code list of the NSEC3 RR).
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 42]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-B.2.1.  No Data Error, Empty Non-Terminal
-
-   A "no data" response because of an empty non-terminal.  The NSEC3 RR
-   proves that the name exists and that the requested RR type does not.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- y.w.example.        IN A
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                        3600000 3600 )
- example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                        40430 example.
-                        Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                        q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                        VI2LmKusbZsT0Q== )
-
- ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set.
-
- ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
-                        k8udemvp1j2f7eg6jebps17vp3n8i58h )
- ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 7 2 3600 (
-                        20150420235959 20051021000000 40430 example.
-                        gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
-                        2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
-                        MpzVSKfTwx4uYA== )
-
- ;; Additional
- ;; (empty)
-
-   The query returned an NSEC3 RR that proves that the requested name
-   exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"),
-   but the requested RR type does not exist (Type A is absent in the
-   Type Bit Maps field of the NSEC3 RR).  Note that, unlike an empty
-   non-terminal proof using NSECs, this is identical to a No Data Error.
-   This example is solely mentioned to be complete.
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 43]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-B.3.  Referral to an Opt-Out Unsigned Zone
-
-   The NSEC3 RRs prove that nothing for this delegation was signed.
-   There is no proof that the unsigned delegation exists.
-
-   ;; Header: QR DO RCODE=0
-   ;;
-   ;; Question
-   mc.c.example.       IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   c.example.     NS      ns1.c.example.
-                  NS      ns2.c.example.
-
-   ;; NSEC3 RR that covers the "next closer" name (c.example)
-   ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck
-
-   35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
-                          b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
-   35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
-                          Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
-                          XtAIR3chwgW+SA== )
-
-   ;; NSEC3 RR that matches the closest encloser (example)
-   ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
-
-   0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
-                          2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
-                          SOA NSEC3PARAM RRSIG )
-   0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
-                          IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
-                          BOCXJZMnpuwhpA== )
-
-   ;; Additional
-   ns1.c.example. A       192.0.2.7
-   ns2.c.example. A       192.0.2.8
-
-   The query returned a referral to the unsigned "c.example." zone.  The
-   response contains the closest provable encloser of "c.example" to be
-   "example", since the hash of "c.example"
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 44]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR
-   and its Opt-Out bit is set.
-
-B.4.  Wildcard Expansion
-
-   A query that was answered with a response containing a wildcard
-   expansion.  The label count in the RRSIG RRSet in the answer section
-   indicates that a wildcard RRSet was expanded to produce this
-   response, and the NSEC3 RR proves that no "next closer" name exists
-   in the zone.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example. IN MX
-
-   ;; Answer
-   a.z.w.example. MX      1 ai.example.
-   a.z.w.example. RRSIG   MX 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
-                          9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
-                          ivEBP6+4KS3ldA== )
-
-   ;; Authority
-   example.       NS      ns1.example.
-   example.       NS      ns2.example.
-   example.       RRSIG   NS 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
-                          qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
-                          CnMXjtz6SyObxA== )
-
-   ;; NSEC3 RR that covers the "next closer" name (z.w.example)
-   ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
-
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
-                          r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
-                          ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
-                          NlkxWcLsIlMmUg== )
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 45]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   ;; Additional
-   ai.example.    A       192.0.2.9
-   ai.example.    RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
-                          tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
-                          rznEn8sQ64UdqA== )
-   ai.example.    AAAA    2001:db8:0:0:0:0:f00:baa9
-   ai.example.    RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
-                          uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
-                          cHueLuXkMjBArQ== )
-
-   The query returned an answer that was produced as a result of a
-   wildcard expansion.  The answer section contains a wildcard RRSet
-   expanded as it would be in a traditional DNS response.  The RRSIG
-   Labels field value of 2 indicates that the answer is the result of a
-   wildcard expansion, as the "a.z.w.example" name contains 4 labels.
-   This also shows that "w.example" exists, so there is no need for an
-   NSEC3 RR that matches the closest encloser.
-
-   The NSEC3 RR proves that no closer match could have been used to
-   answer this query.
-
-B.5.  Wildcard No Data Error
-
-   A "no data" response for a name covered by a wildcard.  The NSEC3 RRs
-   prove that the matching wildcard name does not have any RRs of the
-   requested type and that no closer match exists in the zone.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example.      IN AAAA
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                          3600000 3600 )
-   example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                          q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                          VI2LmKusbZsT0Q== )
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 46]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   ;; NSEC3 RR that matches the closest encloser (w.example)
-   ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
-
-   k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
-                          kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
-   k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
-                          S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
-                          Otx7w9WfcIg62A== )
-
-   ;; NSEC3 RR that covers the "next closer" name (z.w.example)
-   ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
-
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
-                          r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
-                          ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
-                          NlkxWcLsIlMmUg== )
-
-   ;; NSEC3 RR that matches a wildcard at the closest encloser.
-   ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
-
-   r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
-                          t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
-   r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
-                          ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
-                          HF1FWKW7RIJdtQ== )
-
-   ;; Additional
-   ;; (empty)
-
-   The query returned the NSEC3 RRs that prove that the requested data
-   does not exist and no wildcard RR applies.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 47]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-B.6.  DS Child Zone No Data Error
-
-   A "no data" response for a QTYPE=DS query that was mistakenly sent to
-   a name server for the child zone.
-
-;; Header: QR AA DO RCODE=0
-;;
-;; Question
-example.            IN DS
-
-;; Answer
-;; (empty)
-
-;; Authority
-example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                       3600000 3600 )
-example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                       40430 example.
-                       Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                       q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                       VI2LmKusbZsT0Q== )
-
-;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set.
-
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
-                       2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
-                       SOA NSEC3PARAM RRSIG )
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600
-                       20150420235959 20051021000000 40430 example.
-                       OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
-                       IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
-                       BOCXJZMnpuwhpA== )
-
-;; Additional
-;; (empty)
-
-   The query returned an NSEC3 RR showing that the requested was
-   answered by the server authoritative for the zone "example".  The
-   NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3
-   RR is from the apex of the child, not from the zone cut of the
-   parent.  Queries for the "example" DS RRSet should be sent to the
-   parent servers (which are in this case the root servers).
-
-Appendix C.  Special Considerations
-
-   The following paragraphs clarify specific behavior and explain
-   special considerations for implementations.
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 48]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-C.1.  Salting
-
-   Augmenting original owner names with salt before hashing increases
-   the cost of a dictionary of pre-generated hash-values.  For every bit
-   of salt, the cost of a precomputed dictionary doubles (because there
-   must be an entry for each word combined with each possible salt
-   value).  The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
-   salt, multiplying the cost by 2^2040.  This means that an attacker
-   must, in practice, recompute the dictionary each time the salt is
-   changed.
-
-   Including a salt, regardless of size, does not affect the cost of
-   constructing NSEC3 RRs.  It does increase the size of the NSEC3 RR.
-
-   There MUST be at least one complete set of NSEC3 RRs for the zone
-   using the same salt value.
-
-   The salt SHOULD be changed periodically to prevent pre-computation
-   using a single salt.  It is RECOMMENDED that the salt be changed for
-   every re-signing.
-
-   Note that this could cause a resolver to see RRs with different salt
-   values for the same zone.  This is harmless, since each RR stands
-   alone (that is, it denies the set of owner names whose hashes, using
-   the salt in the NSEC3 RR, fall between the two hashes in the NSEC3
-   RR) -- it is only the server that needs a complete set of NSEC3 RRs
-   with the same salt in order to be able to answer every possible
-   query.
-
-   There is no prohibition with having NSEC3 RRs with different salts
-   within the same zone.  However, in order for authoritative servers to
-   be able to consistently find covering NSEC3 RRs, the authoritative
-   server MUST choose a single set of parameters (algorithm, salt, and
-   iterations) to use when selecting NSEC3 RRs.
-
-C.2.  Hash Collision
-
-   Hash collisions occur when different messages have the same hash
-   value.  The expected number of domain names needed to give a 1 in 2
-   chance of a single collision is about 2^(n/2) for a hash of length n
-   bits (i.e., 2^80 for SHA-1).  Though this probability is extremely
-   low, the following paragraphs deal with avoiding collisions and
-   assessing possible damage in the event of an attack using hash
-   collisions.
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 49]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-C.2.1.  Avoiding Hash Collisions During Generation
-
-   During generation of NSEC3 RRs, hash values are supposedly unique.
-   In the (academic) case of a collision occurring, an alternative salt
-   MUST be chosen and all hash values MUST be regenerated.
-
-C.2.2.  Second Preimage Requirement Analysis
-
-   A cryptographic hash function has a second-preimage resistance
-   property.  The second-preimage resistance property means that it is
-   computationally infeasible to find another message with the same hash
-   value as a given message, i.e., given preimage X, to find a second
-   preimage X' != X such that hash(X) = hash(X').  The work factor for
-   finding a second preimage is of the order of 2^160 for SHA-1.  To
-   mount an attack using an existing NSEC3 RR, an adversary needs to
-   find a second preimage.
-
-   Assuming an adversary is capable of mounting such an extreme attack,
-   the actual damage is that a response message can be generated that
-   claims that a certain QNAME (i.e., the second pre-image) does exist,
-   while in reality QNAME does not exist (a false positive), which will
-   either cause a security-aware resolver to re-query for the non-
-   existent name, or to fail the initial query.  Note that the adversary
-   can't mount this attack on an existing name, but only on a name that
-   the adversary can't choose and that does not yet exist.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 50]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-Authors' Addresses
-
-   Ben Laurie
-   Nominet
-   17 Perryn Road
-   London  W3 7LR
-   England
-
-   Phone: +44 20 8735 0686
-   EMail: ben@links.org
-
-
-   Geoffrey Sisson
-   Nominet
-   Minerva House
-   Edmund Halley Road
-   Oxford Science Park
-   Oxford  OX4 4DQ
-   UNITED KINGDOM
-
-   Phone: +44 1865 332211
-   EMail: geoff-s@panix.com
-
-
-   Roy Arends
-   Nominet
-   Minerva House
-   Edmund Halley Road
-   Oxford Science Park
-   Oxford  OX4 4DQ
-   UNITED KINGDOM
-
-   Phone: +44 1865 332211
-   EMail: roy@nominet.org.uk
-
-
-   David Blacka
-   VeriSign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   EMail: davidb@verisign.com
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 51]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 52]
-
diff --git a/doc/rfc/rfc5205.txt b/doc/rfc/rfc5205.txt
deleted file mode 100644
index 4e17b1d9..00000000
--- a/doc/rfc/rfc5205.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        P. Nikander
-Request for Comments: 5205                  Ericsson Research NomadicLab
-Category: Experimental                                       J. Laganier
-                                                        DoCoMo Euro-Labs
-                                                              April 2008
-
-
-    Host Identity Protocol (HIP) Domain Name System (DNS) Extension
-
-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.
-
-Abstract
-
-   This document specifies a new resource record (RR) for the Domain
-   Name System (DNS), and how to use it with the Host Identity Protocol
-   (HIP).  This RR allows a HIP node to store in the DNS its Host
-   Identity (HI, the public component of the node public-private key
-   pair), Host Identity Tag (HIT, a truncated hash of its public key),
-   and the Domain Names of its rendezvous servers (RVSs).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 1]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  Simple Static Singly Homed End-Host  . . . . . . . . . . .  5
-     3.2.  Mobile end-host  . . . . . . . . . . . . . . . . . . . . .  6
-   4.  Overview of Using the DNS with HIP . . . . . . . . . . . . . .  8
-     4.1.  Storing HI, HIT, and RVS in the DNS  . . . . . . . . . . .  8
-     4.2.  Initiating Connections Based on DNS Names  . . . . . . . .  8
-   5.  HIP RR Storage Format  . . . . . . . . . . . . . . . . . . . .  9
-     5.1.  HIT Length Format  . . . . . . . . . . . . . . . . . . . .  9
-     5.2.  PK Algorithm Format  . . . . . . . . . . . . . . . . . . .  9
-     5.3.  PK Length Format . . . . . . . . . . . . . . . . . . . . . 10
-     5.4.  HIT Format . . . . . . . . . . . . . . . . . . . . . . . . 10
-     5.5.  Public Key Format  . . . . . . . . . . . . . . . . . . . . 10
-     5.6.  Rendezvous Servers Format  . . . . . . . . . . . . . . . . 10
-   6.  HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 10
-   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-     8.1.  Attacker Tampering with an Insecure HIP RR . . . . . . . . 12
-     8.2.  Hash and HITs Collisions . . . . . . . . . . . . . . . . . 13
-     8.3.  DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
-   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
-     11.1. Normative references . . . . . . . . . . . . . . . . . . . 14
-     11.2. Informative references . . . . . . . . . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 2]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-1.  Introduction
-
-   This document specifies a new resource record (RR) for the Domain
-   Name System (DNS) [RFC1034], and how to use it with the Host Identity
-   Protocol (HIP) [RFC5201].  This RR allows a HIP node to store in the
-   DNS its Host Identity (HI, the public component of the node public-
-   private key pair), Host Identity Tag (HIT, a truncated hash of its
-   HI), and the Domain Names of its rendezvous servers (RVSs) [RFC5204].
-
-   Currently, most of the Internet applications that need to communicate
-   with a remote host first translate a domain name (often obtained via
-   user input) into one or more IP address(es).  This step occurs prior
-   to communication with the remote host, and relies on a DNS lookup.
-
-   With HIP, IP addresses are intended to be used mostly for on-the-wire
-   communication between end hosts, while most Upper Layer Protocols
-   (ULP) and applications use HIs or HITs instead (ICMP might be an
-   example of an ULP not using them).  Consequently, we need a means to
-   translate a domain name into an HI.  Using the DNS for this
-   translation is pretty straightforward: We define a new HIP resource
-   record.  Upon query by an application or ULP for a name to IP address
-   lookup, the resolver would then additionally perform a name to HI
-   lookup, and use it to construct the resulting HI to IP address
-   mapping (which is internal to the HIP layer).  The HIP layer uses the
-   HI to IP address mapping to translate HIs and HITs into IP addresses
-   and vice versa.
-
-   The HIP Rendezvous Extension [RFC5204] allows a HIP node to be
-   reached via the IP address(es) of a third party, the node's
-   rendezvous server (RVS).  An Initiator willing to establish a HIP
-   association with a Responder served by an RVS would typically
-   initiate a HIP exchange by sending an I1 towards the RVS IP address
-   rather than towards the Responder IP address.  Consequently, we need
-   a means to find the name of a rendezvous server for a given host
-   name.
-
-   This document introduces the new HIP DNS resource record to store the
-   Rendezvous Server (RVS), Host Identity (HI), and Host Identity Tag
-   (HIT) information.
-
-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 RFC 2119 [RFC2119].
-
-
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 3]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-3.  Usage Scenarios
-
-   In this section, we briefly introduce a number of usage scenarios
-   where the DNS is useful with the Host Identity Protocol.
-
-   With HIP, most applications and ULPs are unaware of the IP addresses
-   used to carry packets on the wire.  Consequently, a HIP node could
-   take advantage of having multiple IP addresses for fail-over,
-   redundancy, mobility, or renumbering, in a manner that is transparent
-   to most ULPs and applications (because they are bound to HIs; hence,
-   they are agnostic to these IP address changes).
-
-   In these situations, for a node to be reachable by reference to its
-   Fully Qualified Domain Name (FQDN), the following information should
-   be stored in the DNS:
-
-   o  A set of IP address(es) via A [RFC1035] and AAAA [RFC3596] RR sets
-      (RRSets [RFC2181]).
-
-   o  A Host Identity (HI), Host Identity Tag (HIT), and possibly a set
-      of rendezvous servers (RVS) through HIP RRs.
-
-   When a HIP node wants to initiate communication with another HIP
-   node, it first needs to perform a HIP base exchange to set up a HIP
-   association towards its peer.  Although such an exchange can be
-   initiated opportunistically, i.e., without prior knowledge of the
-   Responder's HI, by doing so both nodes knowingly risk man-in-the-
-   middle attacks on the HIP exchange.  To prevent these attacks, it is
-   recommended that the Initiator first obtain the HI of the Responder,
-   and then initiate the exchange.  This can be done, for example,
-   through manual configuration or DNS lookups.  Hence, a new HIP RR is
-   introduced.
-
-   When a HIP node is frequently changing its IP address(es), the
-   natural DNS latency for propagating changes may prevent it from
-   publishing its new IP address(es) in the DNS.  For solving this
-   problem, the HIP Architecture [RFC4423] introduces rendezvous servers
-   (RVSs) [RFC5204].  A HIP host uses a rendezvous server as a
-   rendezvous point to maintain reachability with possible HIP
-   initiators while moving [RFC5206].  Such a HIP node would publish in
-   the DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up-
-   to-date with its current set of IP addresses.
-
-   When a HIP node wants to initiate a HIP exchange with a Responder, it
-   will perform a number of DNS lookups.  Depending on the type of
-   implementation, the order in which those lookups will be issued may
-   vary.  For instance, implementations using HIT in APIs may typically
-   first query for HIP resource records at the Responder FQDN, while
-
-
-
-Nikander & Laganier           Experimental                      [Page 4]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   those using an IP address in APIs may typically first query for A
-   and/or AAAA resource records.
-
-   In the following, we assume that the Initiator first queries for HIP
-   resource records at the Responder FQDN.
-
-   If the query for the HIP type was responded to with a DNS answer with
-   RCODE=3 (Name Error), then the Responder's information is not present
-   in the DNS and further queries for the same owner name SHOULD NOT be
-   made.
-
-   In case the query for the HIP records returned a DNS answer with
-   RCODE=0 (No Error) and an empty answer section, it means that no HIP
-   information is available at the responder name.  In such a case, if
-   the Initiator has been configured with a policy to fallback to
-   opportunistic HIP (initiating without knowing the Responder's HI) or
-   plain IP, it would send out more queries for A and AAAA types at the
-   Responder's FQDN.
-
-   Depending on the combinations of answers, the situations described in
-   Section 3.1 and Section 3.2 can occur.
-
-   Note that storing HIP RR information in the DNS at an FQDN that is
-   assigned to a non-HIP node might have ill effects on its reachability
-   by HIP nodes.
-
-3.1.  Simple Static Singly Homed End-Host
-
-   A HIP node (R) with a single static network attachment, wishing to be
-   reachable by reference to its FQDN (www.example.com), would store in
-   the DNS, in addition to its IP address(es) (IP-R), its Host Identity
-   (HI-R) and Host Identity Tag (HIT-R) in a HIP resource record.
-
-   An Initiator willing to associate with a node would typically issue
-   the following queries:
-
-   o  QNAME=www.example.com, QTYPE=HIP
-
-   o  (QCLASS=IN is assumed and omitted from the examples)
-
-   Which returns a DNS packet with RCODE=0 and one or more HIP RRs with
-   the HIT and HI (e.g., HIT-R and HI-R) of the Responder in the answer
-   section, but no RVS.
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 5]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   o  QNAME=www.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA
-
-   Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs
-   containing IP address(es) of the Responder (e.g., IP-R) in the answer
-   section.
-
-   Caption: In the remainder of this document, for the sake of keeping
-            diagrams simple and concise, several DNS queries and answers
-            are represented as one single transaction, while in fact
-            there are several queries and answers flowing back and
-            forth, as described in the textual examples.
-
-               [HIP? A?        ]
-               [www.example.com]            +-----+
-          +-------------------------------->|     |
-          |                                 | DNS |
-          | +-------------------------------|     |
-          | |  [HIP? A?        ]            +-----+
-          | |  [www.example.com]
-          | |  [HIP HIT-R HI-R ]
-          | |  [A IP-R         ]
-          | v
-        +-----+                              +-----+
-        |     |--------------I1------------->|     |
-        |  I  |<-------------R1--------------|  R  |
-        |     |--------------I2------------->|     |
-        |     |<-------------R2--------------|     |
-        +-----+                              +-----+
-
-                         Static Singly Homed Host
-
-   The Initiator would then send an I1 to the Responder's IP addresses
-   (IP-R).
-
-3.2.  Mobile end-host
-
-   A mobile HIP node (R) wishing to be reachable by reference to its
-   FQDN (www.example.com) would store in the DNS, possibly in addition
-   to its IP address(es) (IP-R), its HI (HI-R), HIT (HIT-R), and the
-   domain name(s) of its rendezvous server(s) (e.g., rvs.example.com) in
-   HIP resource record(s).  The mobile HIP node also needs to notify its
-   rendezvous servers of any change in its set of IP address(es).
-
-   An Initiator willing to associate with such a mobile node would
-   typically issue the following queries:
-
-   o  QNAME=www.example.com, QTYPE=HIP
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 6]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   Which returns a DNS packet with RCODE=0 and one or more HIP RRs with
-   the HIT, HI, and RVS domain name(s) (e.g., HIT-R, HI-R, and
-   rvs.example.com) of the Responder in the answer section.
-
-   o  QNAME=rvs.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA
-
-   Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs
-   containing IP address(es) of the Responder's RVS (e.g., IP-RVS) in
-   the answer section.
-
-              [HIP?           ]
-              [www.example.com]
-
-              [A?             ]
-              [rvs.example.com]                     +-----+
-         +----------------------------------------->|     |
-         |                                          | DNS |
-         | +----------------------------------------|     |
-         | |  [HIP?                          ]      +-----+
-         | |  [www.example.com               ]
-         | |  [HIP HIT-R HI-R rvs.example.com]
-         | |
-         | |  [A?             ]
-         | |  [rvs.example.com]
-         | |  [A IP-RVS       ]
-         | |
-         | |                +-----+
-         | | +------I1----->| RVS |-----I1------+
-         | | |              +-----+             |
-         | | |                                  |
-         | | |                                  |
-         | v |                                  v
-        +-----+                              +-----+
-        |     |<---------------R1------------|     |
-        |  I  |----------------I2----------->|  R  |
-        |     |<---------------R2------------|     |
-        +-----+                              +-----+
-
-                              Mobile End-Host
-
-   The Initiator would then send an I1 to the RVS IP address (IP-RVS).
-   Following, the RVS will relay the I1 up to the mobile node's IP
-   address (IP-R), which will complete the HIP exchange.
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 7]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-4.  Overview of Using the DNS with HIP
-
-4.1.  Storing HI, HIT, and RVS in the DNS
-
-   For any HIP node, its Host Identity (HI), the associated Host
-   Identity Tag (HIT), and the FQDN of its possible RVSs can be stored
-   in a DNS HIP RR.  Any conforming implementation may store a Host
-   Identity (HI) and its associated Host Identity Tag (HIT) in a DNS HIP
-   RDATA format.  HI and HIT are defined in Section 3 of the HIP
-   specification [RFC5201].
-
-   Upon return of a HIP RR, a host MUST always calculate the HI-
-   derivative HIT to be used in the HIP exchange, as specified in
-   Section 3 of the HIP specification [RFC5201], while the HIT possibly
-   embedded along SHOULD only be used as an optimization (e.g., table
-   lookup).
-
-   The HIP resource record may also contain one or more domain name(s)
-   of rendezvous server(s) towards which HIP I1 packets might be sent to
-   trigger the establishment of an association with the entity named by
-   this resource record [RFC5204].
-
-   The rendezvous server field of the HIP resource record stored at a
-   given owner name MAY include the owner name itself.  A semantically
-   equivalent situation occurs if no rendezvous server is present in the
-   HIP resource record stored at that owner name.  Such situations occur
-   in two cases:
-
-   o  The host is mobile, and the A and/or AAAA resource record(s)
-      stored at its host name contain the IP address(es) of its
-      rendezvous server rather than its own one.
-
-   o  The host is stationary, and can be reached directly at the IP
-      address(es) contained in the A and/or AAAA resource record(s)
-      stored at its host name.  This is a degenerated case of rendezvous
-      service where the host somewhat acts as a rendezvous server for
-      itself.
-
-   An RVS receiving such an I1 would then relay it to the appropriate
-   Responder (the owner of the I1 receiver HIT).  The Responder will
-   then complete the exchange with the Initiator, typically without
-   ongoing help from the RVS.
-
-4.2.  Initiating Connections Based on DNS Names
-
-   On a HIP node, a Host Identity Protocol exchange SHOULD be initiated
-   whenever a ULP attempts to communicate with an entity and the DNS
-   lookup returns HIP resource records.
-
-
-
-Nikander & Laganier           Experimental                      [Page 8]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-5.  HIP RR Storage Format
-
-   The RDATA for a HIP RR consists of a public key algorithm type, the
-   HIT length, a HIT, a public key, and optionally one or more
-   rendezvous server(s).
-
-    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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  HIT length   | PK algorithm  |          PK length            |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               |
-   ~                           HIT                                 ~
-   |                                                               |
-   +                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                     |                                         |
-   +-+-+-+-+-+-+-+-+-+-+-+                                         +
-   |                           Public Key                          |
-   ~                                                               ~
-   |                                                               |
-   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                               |                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
-   |                                                               |
-   ~                       Rendezvous Servers                      ~
-   |                                                               |
-   +             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |             |
-   +-+-+-+-+-+-+-+
-
-   The HIT length, PK algorithm, PK length, HIT, and Public Key fields
-   are REQUIRED.  The Rendezvous Servers field is OPTIONAL.
-
-5.1.  HIT Length Format
-
-   The HIT length indicates the length in bytes of the HIT field.  This
-   is an 8-bit unsigned integer.
-
-5.2.  PK Algorithm Format
-
-   The PK algorithm field indicates the public key cryptographic
-   algorithm and the implied public key field format.  This is an 8-bit
-   unsigned integer.  This document reuses the values defined for the
-   'algorithm type' of the IPSECKEY RR [RFC4025].
-
-   Presently defined values are listed in Section 9 for reference.
-
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 9]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-5.3.  PK Length Format
-
-   The PK length indicates the length in bytes of the Public key field.
-   This is a 16-bit unsigned integer in network byte order.
-
-5.4.  HIT Format
-
-   The HIT is stored as a binary value in network byte order.
-
-5.5.  Public Key Format
-
-   Both of the public key types defined in this document (RSA and DSA)
-   reuse the public key formats defined for the IPSECKEY RR [RFC4025].
-
-   The DSA key format is defined in RFC 2536 [RFC2536].
-
-   The RSA key format is defined in RFC 3110 [RFC3110] and the RSA key
-   size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025]
-   specification.
-
-5.6.  Rendezvous Servers Format
-
-   The Rendezvous Servers field indicates one or more variable length
-   wire-encoded domain names of rendezvous server(s), as described in
-   Section 3.3 of RFC 1035 [RFC1035].  The wire-encoded format is self-
-   describing, so the length is implicit.  The domain names MUST NOT be
-   compressed.  The rendezvous server(s) are listed in order of
-   preference (i.e., first rendezvous server(s) are preferred), defining
-   an implicit order amongst rendezvous servers of a single RR.  When
-   multiple HIP RRs are present at the same owner name, this implicit
-   order of rendezvous servers within an RR MUST NOT be used to infer a
-   preference order between rendezvous servers stored in different RRs.
-
-6.  HIP RR Presentation Format
-
-   This section specifies the representation of the HIP RR in a zone
-   master file.
-
-   The HIT length field is not represented, as it is implicitly known
-   thanks to the HIT field representation.
-
-   The PK algorithm field is represented as unsigned integers.
-
-   The HIT field is represented as the Base16 encoding [RFC4648] (a.k.a.
-   hex or hexadecimal) of the HIT.  The encoding MUST NOT contain
-   whitespaces to distinguish it from the public key field.
-
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 10]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   The Public Key field is represented as the Base64 encoding [RFC4648]
-   of the public key.  The encoding MUST NOT contain whitespace(s) to
-   distinguish it from the Rendezvous Servers field.
-
-   The PK length field is not represented, as it is implicitly known
-   thanks to the Public key field representation containing no
-   whitespaces.
-
-   The Rendezvous Servers field is represented by one or more domain
-   name(s) separated by whitespace(s).
-
-   The complete representation of the HPIHI record is:
-
-   IN  HIP   ( pk-algorithm
-               base16-encoded-hit
-               base64-encoded-public-key
-               rendezvous-server[1]
-                       ...
-               rendezvous-server[n] )
-
-   When no RVSs are present, the representation of the HPIHI record is:
-
-   IN  HIP   ( pk-algorithm
-               base16-encoded-hit
-               base64-encoded-public-key )
-
-7.  Examples
-
-   In the examples below, the public key field containing no whitespace
-   is wrapped since it does not fit in a single line of this document.
-
-   Example of a node with HI and HIT but no RVS:
-
-www.example.com.      IN  HIP ( 2 200100107B1A74DF365639CC39F1D578
-                                AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
-9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
-b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D )
-
-   Example of a node with a HI, HIT, and one RVS:
-
-www.example.com.      IN  HIP ( 2 200100107B1A74DF365639CC39F1D578
-                                AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
-9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
-b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
-                                rvs.example.com. )
-
-
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 11]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   Example of a node with a HI, HIT, and two RVSs:
-
-www.example.com.      IN  HIP ( 2 200100107B1A74DF365639CC39F1D578
-                                AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
-9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
-b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
-                                rvs1.example.com.
-                                rvs2.example.com. )
-
-8.  Security Considerations
-
-   This section contains a description of the known threats involved
-   with the usage of the HIP DNS Extension.
-
-   In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS
-   Extension allows for the provision of two HIP nodes with the public
-   keying material (HI) of their peer.  These HIs will be subsequently
-   used in a key exchange between the peers.  Hence, the HIP DNS
-   Extension introduces the same kind of threats that IPSECKEY does,
-   plus threats caused by the possibility given to a HIP node to
-   initiate or accept a HIP exchange using "opportunistic" or
-   "unpublished Initiator HI" modes.
-
-   A HIP node SHOULD obtain HIP RRs from a trusted party trough a secure
-   channel ensuring data integrity and authenticity of the RRs.  DNSSEC
-   [RFC4033] [RFC4034] [RFC4035] provides such a secure channel.
-   However, it should be emphasized that DNSSEC only offers data
-   integrity and authenticity guarantees to the channel between the DNS
-   server publishing a zone and the HIP node.  DNSSEC does not ensure
-   that the entity publishing the zone is trusted.  Therefore, the RRSIG
-   signature of the HIP RRSet MUST NOT be misinterpreted as a
-   certificate binding the HI and/or the HIT to the owner name.
-
-   In the absence of a proper secure channel, both parties are
-   vulnerable to MitM and DoS attacks, and unrelated parties might be
-   subject to DoS attacks as well.  These threats are described in the
-   following sections.
-
-8.1.  Attacker Tampering with an Insecure HIP RR
-
-   The HIP RR contains public keying material in the form of the named
-   peer's public key (the HI) and its secure hash (the HIT).  Both of
-   these are not sensitive to attacks where an adversary gains knowledge
-   of them.  However, an attacker that is able to mount an active attack
-   on the DNS, i.e., tampers with this HIP RR (e.g., using DNS
-   spoofing), is able to mount Man-in-the-Middle attacks on the
-   cryptographic core of the eventual HIP exchange (Responder's HIP RR
-   rewritten by the attacker).
-
-
-
-Nikander & Laganier           Experimental                     [Page 12]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   The HIP RR may contain a rendezvous server domain name resolved into
-   a destination IP address where the named peer is reachable by an I1,
-   as per the HIP Rendezvous Extension [RFC5204].  Thus, an attacker
-   able to tamper with this RR is able to redirect I1 packets sent to
-   the named peer to a chosen IP address for DoS or MitM attacks.  Note
-   that this kind of attack is not specific to HIP and exists
-   independently of whether or not HIP and the HIP RR are used.  Such an
-   attacker might tamper with A and AAAA RRs as well.
-
-   An attacker might obviously use these two attacks in conjunction: It
-   will replace the Responder's HI and RVS IP address by its own in a
-   spoofed DNS packet sent to the Initiator HI, then redirect all
-   exchanged packets to him and mount a MitM on HIP.  In this case, HIP
-   won't provide confidentiality nor Initiator HI protection from
-   eavesdroppers.
-
-8.2.  Hash and HITs Collisions
-
-   As with many cryptographic algorithms, some secure hashes (e.g.,
-   SHA1, used by HIP to generate a HIT from an HI) eventually become
-   insecure, because an exploit has been found in which an attacker with
-   reasonable computation power breaks one of the security features of
-   the hash (e.g., its supposed collision resistance).  This is why a
-   HIP end-node implementation SHOULD NOT authenticate its HIP peers
-   based solely on a HIT retrieved from the DNS, but SHOULD rather use
-   HI-based authentication.
-
-8.3.  DNSSEC
-
-   In the absence of DNSSEC, the HIP RR is subject to the threats
-   described in RFC 3833 [RFC3833].
-
-9.  IANA Considerations
-
-   IANA has allocated one new RR type code (55) for the HIP RR from the
-   standard RR type space.
-
-   IANA does not need to open a new registry for public key algorithms
-   of the HIP RR because the HIP RR reuses "algorithms types" defined
-   for the IPSECKEY RR [RFC4025].  Presently defined values are shown
-   here for reference only:
-
-      0 is reserved
-
-      1 is DSA
-
-      2 is RSA
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 13]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   In the future, if a new algorithm is to be used for the HIP RR, a new
-   algorithm type and corresponding public key encoding should be
-   defined for the IPSECKEY RR.  The HIP RR should reuse both the same
-   algorithm type and the same corresponding public key format as the
-   IPSECKEY RR.
-
-10.  Acknowledgments
-
-   As usual in the IETF, this document is the result of a collaboration
-   between many people.  The authors would like to thank the author
-   (Michael Richardson), contributors, and reviewers of the IPSECKEY RR
-   [RFC4025] specification, after which this document was framed.  The
-   authors would also like to thank the following people, who have
-   provided thoughtful and helpful discussions and/or suggestions, that
-   have helped improve this document: Jeff Ahrenholz, Rob Austein, Hannu
-   Flinck, Olafur Gudmundsson, Tom Henderson, Peter Koch, Olaf Kolkman,
-   Miika Komu, Andrew McGregor, Erik Nordmark, and Gabriel Montenegro.
-   Some parts of this document stem from the HIP specification
-   [RFC5201].
-
-11.  References
-
-11.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.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
-              "DNS Extensions to Support IP Version 6", RFC 3596,
-              October 2003.
-
-   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
-              Material in DNS", RFC 4025, March 2005.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 14]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
-              Encodings", RFC 4648, October 2006.
-
-   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
-              Henderson, "Host Identity Protocol", RFC 5201, April 2008.
-
-   [RFC5204]  Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
-              Rendezvous Extension", RFC 5204, April 2008.
-
-11.2.  Informative references
-
-   [RFC2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
-              (DNS)", RFC 2536, March 1999.
-
-   [RFC3110]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-              Name System (DNS)", RFC 3110, May 2001.
-
-   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
-              Name System (DNS)", RFC 3833, August 2004.
-
-   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
-              (HIP) Architecture", RFC 4423, May 2006.
-
-   [RFC5206]  Henderson, T., Ed., "End-Host Mobility and Multihoming
-              with the Host Identity Protocol", RFC 5206, April 2008.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 15]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-Authors' Addresses
-
-   Pekka Nikander
-   Ericsson Research NomadicLab
-   JORVAS  FIN-02420
-   FINLAND
-
-   Phone: +358 9 299 1
-   EMail: pekka.nikander@nomadiclab.com
-
-
-   Julien Laganier
-   DoCoMo Communications Laboratories Europe GmbH
-   Landsberger Strasse 312
-   Munich  80687
-   Germany
-
-   Phone: +49 89 56824 231
-   EMail: julien.ietf@laposte.net
-   URI:   http://www.docomolab-euro.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 16]
-
-RFC 5205                   HIP DNS Extension                  April 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.
-
-
-
-
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 17]
-
diff --git a/doc/rfc/rfc5452.txt b/doc/rfc/rfc5452.txt
deleted file mode 100644
index 6f59bf57..00000000
--- a/doc/rfc/rfc5452.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          A. Hubert
-Request for Comments: 5452            Netherlabs Computer Consulting BV.
-Updates: 2181                                                R. van Mook
-Category: Standards Track                                        Equinix
-                                                            January 2009
-
-
-     Measures for Making DNS More Resilient against Forged Answers
-
-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) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents (http://trustee.ietf.org/
-   license-info) in effect on the date of publication of this document.
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   The current Internet climate poses serious threats to the Domain Name
-   System.  In the interim period before the DNS protocol can be secured
-   more fully, measures can already be taken to harden the DNS to make
-   'spoofing' a recursing nameserver many orders of magnitude harder.
-
-   Even a cryptographically secured DNS benefits from having the ability
-   to discard bogus responses quickly, as this potentially saves large
-   amounts of computation.
-
-   By describing certain behavior that has previously not been
-   standardized, this document sets out how to make the DNS more
-   resilient against accepting incorrect responses.  This document
-   updates RFC 2181.
-
-
-
-
-
-
-
-
-Hubert & van Mook           Standards Track                     [Page 1]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Requirements and Definitions . . . . . . . . . . . . . . . . .  4
-     2.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  4
-     2.2.  Key Words  . . . . . . . . . . . . . . . . . . . . . . . .  5
-   3.  Description of DNS Spoofing  . . . . . . . . . . . . . . . . .  5
-   4.  Detailed Description of Spoofing Scenarios . . . . . . . . . .  6
-     4.1.  Forcing a Query  . . . . . . . . . . . . . . . . . . . . .  6
-     4.2.  Matching the Question Section  . . . . . . . . . . . . . .  7
-     4.3.  Matching the ID Field  . . . . . . . . . . . . . . . . . .  7
-     4.4.  Matching the Source Address of the Authentic Response  . .  7
-     4.5.  Matching the Destination Address and Port of the
-           Authentic Response . . . . . . . . . . . . . . . . . . . .  8
-     4.6.  Have the Response Arrive before the Authentic Response . .  8
-   5.  Birthday Attacks . . . . . . . . . . . . . . . . . . . . . . .  9
-   6.  Accepting Only In-Domain Records . . . . . . . . . . . . . . .  9
-   7.  Combined Difficulty  . . . . . . . . . . . . . . . . . . . . . 10
-     7.1.  Symbols Used in Calculation  . . . . . . . . . . . . . . . 10
-     7.2.  Calculation  . . . . . . . . . . . . . . . . . . . . . . . 11
-   8.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     8.1.  Repetitive Spoofing Attempts for a Single Domain Name  . . 13
-   9.  Forgery Countermeasures  . . . . . . . . . . . . . . . . . . . 13
-     9.1.  Query Matching Rules . . . . . . . . . . . . . . . . . . . 13
-     9.2.  Extending the Q-ID Space by Using Ports and Addresses  . . 14
-       9.2.1.  Justification and Discussion . . . . . . . . . . . . . 14
-     9.3.  Spoof Detection and Countermeasure . . . . . . . . . . . . 15
-   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
-   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
-   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
-     12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
-     12.2. Informative References . . . . . . . . . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook           Standards Track                     [Page 2]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-1.  Introduction
-
-   This document describes several common problems in DNS
-   implementations, which, although previously recognized, remain
-   largely unsolved.  Besides briefly recapping these problems, this
-   document contains rules that, if implemented, make complying
-   resolvers vastly more resistant to the attacks described.  The goal
-   is to make the existing DNS as secure as possible within the current
-   protocol boundaries.
-
-   The words below are aimed at authors of resolvers: it is up to
-   operators to decide which nameserver implementation to use, or which
-   options to enable.  Operational constraints may override the security
-   concerns described below.  However, implementations are expected to
-   allow an operator to enable functionality described in this document.
-
-   Almost every transaction on the Internet involves the Domain Name
-   System, which is described in [RFC1034], [RFC1035], and beyond.
-
-   Additionally, it has recently become possible to acquire Secure
-   Socket Layer/Transport Layer Security (SSL/TLS) certificates with no
-   other confirmation of identity than the ability to respond to a
-   verification email sent via SMTP ([RFC5321]) -- which generally uses
-   DNS for its routing.
-
-   In other words, any party that (temporarily) controls the Domain Name
-   System is in a position to reroute most kinds of Internet
-   transactions, including the verification steps in acquiring an SSL/
-   TLS certificate for a domain.  This in turn means that even
-   transactions protected by SSL/TLS could be diverted.
-
-   It is entirely conceivable that such rerouted traffic could be used
-   to the disadvantage of Internet users.
-
-   These and other developments have made the security and
-   trustworthiness of DNS of renewed importance.  Although the DNS
-   community is working hard on finalizing and implementing a
-   cryptographically enhanced DNS protocol, steps should be taken to
-   make sure that the existing use of DNS is as secure as possible
-   within the bounds of the relevant standards.
-
-   It should be noted that the most commonly used resolvers currently do
-   not perform as well as possible in this respect, making this document
-   of urgent importance.
-
-   A thorough analysis of risks facing DNS can be found in [RFC3833].
-
-
-
-
-
-Hubert & van Mook           Standards Track                     [Page 3]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-   This document expands on some of the risks mentioned in RFC 3833,
-   especially those outlined in the sections on "ID Guessing and Query
-   Prediction" and "Name Chaining".  Furthermore, it emphasizes a number
-   of existing rules and guidelines embodied in the relevant DNS
-   protocol specifications.  The following also specifies new
-   requirements to make sure the Domain Name System can be relied upon
-   until a more secure protocol has been standardized and deployed.
-
-   It should be noted that even when all measures suggested below are
-   implemented, protocol users are not protected against third parties
-   with the ability to observe, modify, or inject packets in the traffic
-   of a resolver.
-
-   For protocol extensions that offer protection against these
-   scenarios, see [RFC4033] and beyond.
-
-2.  Requirements and Definitions
-
-2.1.  Definitions
-
-   This document uses the following definitions:
-
-      Client: typically a 'stub-resolver' on an end-user's computer.
-
-      Resolver: a nameserver performing recursive service for clients,
-      also known as a caching server, or a full service resolver
-      ([RFC1123], Section 6.1.3.1).
-
-      Stub resolver: a very limited resolver on a client computer, that
-      leaves the recursing work to a full resolver.
-
-      Query: a question sent out by a resolver, typically in a UDP
-      packet
-
-      Response: the answer sent back by an authoritative nameserver,
-      typically in a UDP packet.
-
-      Third party: any entity other than the resolver or the intended
-      recipient of a question.  The third party may have access to an
-      arbitrary authoritative nameserver, but has no access to packets
-      transmitted by the resolver or authoritative server.
-
-      Attacker: malicious third party.
-
-      Spoof: the activity of attempting to subvert the DNS process by
-      getting a chosen answer accepted.
-
-
-
-
-
-Hubert & van Mook           Standards Track                     [Page 4]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-      Authentic response: the correct answer that comes from the right
-      authoritative server.
-
-      Target domain name: domain for which the attacker wishes to spoof
-      in an answer
-
-      Fake data: response chosen by the attacker.
-
-2.2.  Key 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].
-
-3.  Description of DNS Spoofing
-
-   When certain steps are taken, it is feasible to "spoof" the current
-   deployed majority of resolvers with carefully crafted and timed DNS
-   packets.  Once spoofed, a caching server will repeat the data it
-   wrongfully accepted, and make its clients contact the wrong, and
-   possibly malicious, servers.
-
-   To understand how this process works it is important to know what
-   makes a resolver accept a response.
-
-   The following sentence in Section 5.3.3 of [RFC1034] presaged the
-   present problem:
-
-     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.
-
-   DNS data is to be accepted by a resolver if and only if:
-
-   1.  The question section of the reply packet is equivalent to that of
-       a question packet currently waiting for a response.
-
-   2.  The ID field of the reply packet matches that of the question
-       packet.
-
-   3.  The response comes from the same network address to which the
-       question was sent.
-
-   4.  The response comes in on the same network address, including port
-       number, from which the question was sent.
-
-   In general, the first response matching these four conditions is
-   accepted.
-
-
-
-Hubert & van Mook           Standards Track                     [Page 5]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-   If a third party succeeds in meeting the four conditions before the
-   response from the authentic nameserver does so, it is in a position
-   to feed a resolver fabricated data.  When it does so, we dub it an
-   "attacker", attempting to spoof in fake data.
-
-   All conditions mentioned above can theoretically be met by a third
-   party, with the difficulty being a function of the resolver
-   implementation and zone configuration.
-
-4.  Detailed Description of Spoofing Scenarios
-
-   The previous paragraph discussed a number of requirements an attacker
-   must match in order to spoof in manipulated (or fake) data.  This
-   section discusses the relative difficulties and how implementation-
-   defined choices impact the amount of work an attacker has to perform
-   to meet said difficulties.
-
-   Some more details can be found in Section 2.2 of [RFC3833].
-
-4.1.  Forcing a Query
-
-   Formally, there is no need for a nameserver to perform service except
-   for its operator, its customers, or more generally its users.
-   Recently, open recursing nameservers have been used to amplify
-   denial-of-service attacks.
-
-   Providing full service enables the third party to send the target
-   resolver a query for the domain name it intends to spoof.  On
-   receiving this query, and not finding the answer in its cache, the
-   resolver will transmit queries to relevant authoritative nameservers.
-   This opens up a window of opportunity for getting fake answer data
-   accepted.
-
-   Queries may however be forced indirectly, for example, by inducing a
-   mail server to perform DNS lookups.
-
-   Some operators restrict access by not recursing for unauthorized IP
-   addresses, but only respond with data from the cache.  This makes
-   spoofing harder for a third party as it cannot then force the exact
-   moment a question will be asked.  It is still possible however to
-   determine a time range when this will happen, because nameservers
-   helpfully publish the decreasing time to live (TTL) of entries in the
-   cache, which indicate from which absolute time onwards a new query
-   could be sent to refresh the expired entry.
-
-   The time to live of the target domain name's RRSets determines how
-   often a window of opportunity is available, which implies that a
-   short TTL makes spoofing far more viable.
-
-
-
-Hubert & van Mook           Standards Track                     [Page 6]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-   Note that the attacker might very well have authorized access to the
-   target resolver by virtue of being a customer or employee of its
-   operator.  In addition, access may be enabled through the use of
-   reflectors as outlined in [RFC5358].
-
-4.2.  Matching the Question Section
-
-   DNS packets, both queries and responses, contain a question section.
-   Incoming responses should be verified to have a question section that
-   is equivalent to that of the outgoing query.
-
-4.3.  Matching the ID Field
-
-   The DNS ID field is 16 bits wide, meaning that if full use is made of
-   all these bits, and if their contents are truly random, it will
-   require on average 32768 attempts to guess.  Anecdotal evidence
-   suggests there are implementations utilizing only 14 bits, meaning on
-   average 8192 attempts will suffice.
-
-   Additionally, if the target nameserver can be forced into having
-   multiple identical queries outstanding, the "Birthday Attack"
-   phenomenon means that any fake data sent by the attacker is matched
-   against multiple outstanding queries, significantly raising the
-   chance of success.  Further details in Section 5.
-
-4.4.  Matching the Source Address of the Authentic Response
-
-   It should be noted that meeting this condition entails being able to
-   transmit packets on behalf of the address of the authoritative
-   nameserver.  While two Best Current Practice documents ([RFC2827] and
-   [RFC3013] specifically) direct Internet access providers to prevent
-   their customers from assuming IP addresses that are not assigned to
-   them, these recommendations are not universally (nor even widely)
-   implemented.
-
-   Many zones have two or three authoritative nameservers, which make
-   matching the source address of the authentic response very likely
-   with even a naive choice having a double digit success rate.
-
-   Most recursing nameservers store relative performance indications of
-   authoritative nameservers, which may make it easier to predict which
-   nameserver would originally be queried -- the one most likely to
-   respond the quickest.
-
-   Generally, this condition requires at most two or three attempts
-   before it is matched.
-
-
-
-
-
-Hubert & van Mook           Standards Track                     [Page 7]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-4.5.  Matching the Destination Address and Port of the Authentic
-      Response
-
-   Note that the destination address of the authentic response is the
-   source address of the original query.
-
-   The actual address of a recursing nameserver is generally known; the
-   port used for asking questions is harder to determine.  Most current
-   resolvers pick an arbitrary port at startup (possibly at random) and
-   use this for all outgoing queries.  In quite a number of cases, the
-   source port of outgoing questions is fixed at the traditional DNS
-   assigned server port number of 53.
-
-   If the source port of the original query is random, but static, any
-   authoritative nameserver under observation by the attacker can be
-   used to determine this port.  This means that matching this
-   conditions often requires no guess work.
-
-   If multiple ports are used for sending queries, this enlarges the
-   effective ID space by a factor equal to the number of ports used.
-
-   Less common resolving servers choose a random port per outgoing
-   query.  If this strategy is followed, this port number can be
-   regarded as an additional ID field, again containing up to 16 bits.
-
-   If the maximum ports range is utilized, on average, around 32256
-   source ports would have to be tried before matching the source port
-   of the original query, as ports below 1024 may be unavailable for
-   use, leaving 64512 options.
-
-   It is in general safe for DNS to use ports in the range 1024-49152
-   even though some of these ports are allocated to other protocols.
-   DNS resolvers will not be able to use any ports that are already in
-   use.  If a DNS resolver uses a port, it will release that port after
-   a short time and migrate to a different port.  Only in the case of a
-   high-volume resolver is it possible that an application wanting a
-   particular UDP port suffers a long term block-out.
-
-   It should be noted that a firewall will not prevent the matching of
-   this address, as it will accept answers that (appear to) come from
-   the correct address, offering no additional security.
-
-4.6.  Have the Response Arrive before the Authentic Response
-
-   Once any packet has matched the previous four conditions (plus
-   possible additional conditions), no further responses are generally
-   accepted.
-
-
-
-
-Hubert & van Mook           Standards Track                     [Page 8]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-   This means that the third party has a limited time in which to inject
-   its spoofed response.  For calculations, we will assume a window in
-   order of at most 100 ms (depending on the network distance to the
-   authentic authoritative nameserver).
-
-   This time period can be far longer if the authentic authoritative
-   nameservers are (briefly) overloaded by queries, perhaps by the
-   attacker.
-
-5.  Birthday Attacks
-
-   The so-called "birthday paradox" implies that a group of 23 people
-   suffices to have a more than even chance of having two or more
-   members of the group share a birthday.
-
-   An attacker can benefit from this exact phenomenon if it can force
-   the target resolver to have multiple equivalent (identical QNAME,
-   QTYPE, and QCLASS) outstanding queries at any one time to the same
-   authoritative server.
-
-   Any packet the attacker sends then has a much higher chance of being
-   accepted because it only has to match any of the outstanding queries
-   for that single domain.  Compared to the birthday analogy above, of
-   the group composed of queries and responses, the chance of having any
-   of these share an ID rises quickly.
-
-   As long as small numbers of queries are sent out, the chance of
-   successfully spoofing a response rises linearly with the number of
-   outstanding queries for the exact domain and nameserver.
-
-   For larger numbers, this effect is less pronounced.
-
-   More details are available in US-CERT [vu-457875].
-
-6.  Accepting Only In-Domain Records
-
-   Responses from authoritative nameservers often contain information
-   that is not part of the zone for which we deem it authoritative.  As
-   an example, a query for the MX record of a domain might get as its
-   responses a mail exchanger in another domain, and additionally the IP
-   address of this mail exchanger.
-
-   If accepted uncritically, the resolver stands the chance of accepting
-   data from an untrusted source.  Care must be taken to only accept
-   data if it is known that the originator is authoritative for the
-   QNAME or a parent of the QNAME.
-
-
-
-
-
-Hubert & van Mook           Standards Track                     [Page 9]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-   One very simple way to achieve this is to only accept data if it is
-   part of the domain for which the query was intended.
-
-7.  Combined Difficulty
-
-   Given a known or static destination port, matching ID field, the
-   source and destination address requires on average in the order of 2
-   * 2^15 = 65000 packets, assuming a zone has 2 authoritative
-   nameservers.
-
-   If the window of opportunity available is around 100 ms, as assumed
-   above, an attacker would need to be able to briefly transmit 650000
-   packets/s to have a 50% chance to get spoofed data accepted on the
-   first attempt.
-
-   A realistic minimal DNS response consists of around 80 bytes,
-   including IP headers, making the packet rate above correspond to a
-   respectable burst of 416 Mbit/s.
-
-   As of mid-2006, this kind of bandwidth was not common but not scarce
-   either, especially among those in a position to control many servers.
-
-   These numbers change when a window of a full second is assumed,
-   possibly because the arrival of the authentic response can be
-   prevented by overloading the bona fide authoritative hosts with decoy
-   queries.  This reduces the needed bandwidth to 42 Mbit/s.
-
-   If, in addition, the attacker is granted more than a single chance
-   and allowed up to 60 minutes of work on a domain with a time to live
-   of 300 seconds, a meager 4 Mbit/s suffices for a 50% chance at
-   getting fake data accepted.  Once equipped with a longer time,
-   matching condition 1 mentioned above is straightforward -- any
-   popular domain will have been queried a number of times within this
-   hour, and given the short TTL, this would lead to queries to
-   authoritative nameservers, opening windows of opportunity.
-
-7.1.  Symbols Used in Calculation
-
-   Assume the following symbols are used:
-
-   I: Number distinct IDs available (maximum 65536)
-
-   P: Number of ports used (maximum around 64000 as ports under 1024 are
-      not always available, but often 1)
-
-   N: Number of authoritative nameservers for a domain (averages around
-      2.5)
-
-
-
-
-Hubert & van Mook           Standards Track                    [Page 10]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-   F: Number of "fake" packets sent by the attacker
-
-   R: Number of packets sent per second by the attacker
-
-   W: Window of opportunity, in seconds.  Bounded by the response time
-      of the authoritative servers (often 0.1s)
-
-   D: Average number of identical outstanding queries of a resolver
-      (typically 1, see Section 5)
-
-   A: Number of attempts, one for each window of opportunity
-
-7.2.  Calculation
-
-   The probability of spoofing a resolver is equal to the amount of fake
-   packets that arrive within the window of opportunity, divided by the
-   size of the problem space.
-
-   When the resolver has 'D' multiple identical outstanding queries,
-   each fake packet has a proportionally higher chance of matching any
-   of these queries.  This assumption only holds for small values of
-   'D'.
-
-   In symbols, if the probability of being spoofed is denoted as P_s:
-
-              D * F
-   P_s =    ---------
-            N * P * I
-
-   It is more useful to reason not in terms of aggregate packets but to
-   convert to packet rate, which can easily be converted to bandwidth if
-   needed.
-
-   If the window of opportunity length is 'W' and the attacker can send
-   'R' packets per second, the number of fake packets 'F' that are
-   candidates to be accepted is:
-
-                          D * R * W
-   F = R * W  ->   P_s  = ---------
-                          N * P * I
-
-   Finally, to calculate the combined chance 'P_cs' of spoofing over a
-   chosen time period 'T', it should be realized that the attacker has a
-   new window of opportunity each time the TTL 'TTL' of the target
-   domain expires.  This means that the number of attempts 'A' is equal
-   to 'T / TTL'.
-
-
-
-
-
-Hubert & van Mook           Standards Track                    [Page 11]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-   To calculate the combined chance of at least one success, the
-   following formula holds:
-
-                                                        (T / TTL)
-                         A          (       D * R * W )
-   P_cs = 1 - ( 1 - P_s )    =  1 - ( 1  -  --------- )
-                                    (       N * P * I )
-
-   When common numbers (as listed above) for D, W, N, P, and I are
-   inserted, this formula reduces to:
-
-                               (T / TTL)
-              (         R    )
-   P_cs = 1 - ( 1 -  ------- )
-              (      1638400 )
-
-   From this formula, it can be seen that, if the nameserver
-   implementation is unchanged, only raising the TTL offers protection.
-   Raising N, the number of authoritative nameservers, is not feasible
-   beyond a small number.
-
-   For the degenerate case of a zero-second TTL, a window of opportunity
-   opens for each query sent, making the effective TTL equal to 'W'
-   above, the response time of the authoritative server.
-
-   This last case also holds for spoofing techniques that do not rely on
-   TTL expiry, but use repeated and changing queries.
-
-8.  Discussion
-
-   The calculations above indicate the relative ease with which DNS data
-   can be spoofed.  For example, using the formula derived earlier on an
-   RRSet with a 3600 second TTL, an attacker sending 7000 fake response
-   packets/s (a rate of 4.5 Mbit/s), stands a 10% chance of spoofing a
-   record in the first 24 hours, which rises to 50% after a week.
-
-   For an RRSet with a TTL of 60 seconds, the 10% level is hit after 24
-   minutes, 50% after less than 3 hours, 90% after around 9 hours.
-
-   For some classes of attacks, the effective TTL is near zero, as noted
-   above.
-
-   Note that the attacks mentioned above can be detected by watchful
-   server operators - an unexpected incoming stream of 4.5 Mbit/s of
-   packets might be noticed.
-
-   An important assumption however in these calculations is a known or
-   static destination port of the authentic response.
-
-
-
-Hubert & van Mook           Standards Track                    [Page 12]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-   If that port number is unknown and needs to be guessed as well, the
-   problem space expands by a factor of 64000, leading the attacker to
-   need in excess of 285Gb/s to achieve similar success rates.
-
-   Such bandwidth is not generally available, nor is it expected to be
-   so in the foreseeable future.
-
-   Note that some firewalls may need reconfiguring if they are currently
-   set up to only allow outgoing queries from a single DNS source port.
-
-8.1.  Repetitive Spoofing Attempts for a Single Domain Name
-
-   Techniques are available to use an effectively infinite number of
-   queries to achieve a desired spoofing goal.  In the math above, this
-   reduces the effective TTL to 0.
-
-   If such techniques are employed, using the same 7000 packets/s rate
-   mentioned above, and using 1 source port, the spoofing chance rises
-   to 50% within 7 seconds.
-
-   If 64000 ports are used, as recommended in this document, using the
-   same query rate, the 50% level is reached after around 116 hours.
-
-9.  Forgery Countermeasures
-
-9.1.  Query Matching Rules
-
-   A resolver implementation MUST match responses to all of the
-   following attributes of the query:
-
-   o  Source address against query destination address
-
-   o  Destination address against query source address
-
-   o  Destination port against query source port
-
-   o  Query ID
-
-   o  Query name
-
-   o  Query class and type
-
-   before applying DNS trustworthiness rules (see Section 5.4.1 of
-   [RFC2181]).
-
-   A mismatch and the response MUST be considered invalid.
-
-
-
-
-
-Hubert & van Mook           Standards Track                    [Page 13]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-9.2.  Extending the Q-ID Space by Using Ports and Addresses
-
-   Resolver implementations MUST:
-
-   o  Use an unpredictable source port for outgoing queries from the
-      range of available ports (53, or 1024 and above) that is as large
-      as possible and practicable;
-
-   o  Use multiple different source ports simultaneously in case of
-      multiple outstanding queries;
-
-   o  Use an unpredictable query ID for outgoing queries, utilizing the
-      full range available (0-65535).
-
-   Resolvers that have multiple IP addresses SHOULD use them in an
-   unpredictable manner for outgoing queries.
-
-   Resolver implementations SHOULD provide means to avoid usage of
-   certain ports.
-
-   Resolvers SHOULD favor authoritative nameservers with which a trust
-   relation has been established; stub-resolvers SHOULD be able to use
-   Transaction Signature (TSIG) ([RFC2845]) or IPsec ([RFC4301]) when
-   communicating with their recursive resolver.
-
-   In case a cryptographic verification of response validity is
-   available (TSIG, SIG(0)), resolver implementations MAY waive above
-   rules, and rely on this guarantee instead.
-
-   Proper unpredictability can be achieved by employing a high quality
-   (pseudo-)random generator, as described in [RFC4086].
-
-9.2.1.  Justification and Discussion
-
-   Since an attacker can force a full DNS resolver to send queries to
-   the attacker's own nameservers, any constant or sequential state held
-   by such a resolver can be measured, and it must not be trivially easy
-   to reverse engineer the resolver's internal state in a way that
-   allows low-cost, high-accuracy prediction of future state.
-
-   A full DNS resolver with only one or a small number of upstream-
-   facing endpoints is effectively using constants for IP source address
-   and UDP port number, and these are very predictable by potential
-   attackers, and must therefore be avoided.
-
-   A full DNS resolver that uses a simple increment to get its next DNS
-   query ID is likewise very predictable and so very spoofable.
-
-
-
-
-Hubert & van Mook           Standards Track                    [Page 14]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-   Finally, weak random number generators have been shown to expose
-   their internal state, such that an attacker who witnesses several
-   sequential "random" values can easily predict the next ones.  A
-   crypto-strength random number generator is one whose output cannot be
-   predicted no matter how many successive values are witnessed.
-
-9.3.  Spoof Detection and Countermeasure
-
-   If a resolver detects that an attempt is being made to spoof it,
-   perhaps by discovering that many packets fail the criteria as
-   outlined above, it MAY abandon the UDP query and re-issue it over
-   TCP.  TCP, by the nature of its use of sequence numbers, is far more
-   resilient against forgery by third parties.
-
-10.  Security Considerations
-
-   This document provides clarification of the DNS specification to
-   decrease the probability that DNS responses can be successfully
-   forged.  Recommendations found above should be considered
-   complementary to possible cryptographical enhancements of the domain
-   name system, which protect against a larger class of attacks.
-
-   This document recommends the use of UDP source port number
-   randomization to extend the effective DNS transaction ID beyond the
-   available 16 bits.
-
-   A resolver that does not implement the recommendations outlined above
-   can easily be forced to accept spoofed responses, which in turn are
-   passed on to client computers -- misdirecting (user) traffic to
-   possibly malicious entities.
-
-   This document directly impacts the security of the Domain Name
-   System, implementers are urged to follow its recommendations.
-
-   Most security considerations can be found in Sections 4 and 5, while
-   proposed countermeasures are described in Section 9.
-
-   For brevity's sake, in lieu of repeating the security considerations
-   references, the reader is referred to these sections.
-
-   Nothing in this document specifies specific algorithms for operators
-   to use; it does specify algorithms implementations SHOULD or MUST
-   support.
-
-   It should be noted that the effects of source port randomization may
-   be dramatically reduced by NAT devices that either serialize or limit
-   in volume the UDP source ports used by the querying resolver.
-
-
-
-
-Hubert & van Mook           Standards Track                    [Page 15]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-   DNS recursive servers sitting behind at NAT or a statefull firewall
-   may consume all available NAT translation entries/ports when
-   operating under high query load.  Port randomization will cause
-   translation entries to be consumed faster than with fixed query port.
-
-   To avoid this, NAT boxes and statefull firewalls can/should purge
-   outgoing DNS query translation entries 10-17 seconds after the last
-   outgoing query on that mapping was sent.  [RFC4787]-compliant devices
-   need to treat UDP messages with port 53 differently than most other
-   UDP protocols.
-
-   To minimize the potential that port/state exhaustion attacks can be
-   staged from the outside, it is recommended that services that
-   generate a number of DNS queries for each connection should be rate
-   limited.  This applies in particular to email servers.
-
-11.  Acknowledgments
-
-   Source port randomization in DNS was first implemented and possibly
-   invented by Dan J. Bernstein.
-
-   Although any mistakes remain our own, the authors gratefully
-   acknowledge the help and contributions of:
-      Stephane Bortzmeyer
-      Alfred Hoenes
-      Peter Koch
-      Sean Leach
-      Norbert Sendetzky
-      Paul Vixie
-      Florian Weimer
-      Wouter Wijngaards
-      Dan Wing
-
-12.  References
-
-12.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.
-
-   [RFC2181]    Elz, R. and R. Bush, "Clarifications to the DNS
-                Specification", RFC 2181, July 1997.
-
-
-
-Hubert & van Mook           Standards Track                    [Page 16]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-   [RFC2827]    Ferguson, P. and D. Senie, "Network Ingress Filtering:
-                Defeating Denial of Service Attacks which employ IP
-                Source Address Spoofing", BCP 38, RFC 2827, May 2000.
-
-   [RFC2845]    Vixie, P., Gudmundsson, O., Eastlake, D., and B.
-                Wellington, "Secret Key Transaction Authentication for
-                DNS (TSIG)", RFC 2845, May 2000.
-
-   [RFC3013]    Killalea, T., "Recommended Internet Service Provider
-                Security Services and Procedures", BCP 46, RFC 3013,
-                November 2000.
-
-   [RFC4033]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
-                Rose, "DNS Security Introduction and Requirements",
-                RFC 4033, March 2005.
-
-   [RFC4086]    Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-                Requirements for Security", BCP 106, RFC 4086,
-                June 2005.
-
-   [RFC5321]    Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
-                October 2008.
-
-12.2.  Informative References
-
-   [RFC1123]    Braden, R., "Requirements for Internet Hosts -
-                Application and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC3833]    Atkins, D. and R. Austein, "Threat Analysis of the
-                Domain Name System (DNS)", RFC 3833, August 2004.
-
-   [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
-                Internet Protocol", RFC 4301, December 2005.
-
-   [RFC4787]    Audet, F. and C. Jennings, "Network Address Translation
-                (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
-                RFC 4787, January 2007.
-
-   [RFC5358]    Damas, J. and F. Neves, "Preventing Use of Recursive
-                Nameservers in Reflector Attacks", BCP 140, RFC 5358,
-                October 2008.
-
-   [vu-457875]  United States CERT, "Various DNS service implementations
-                generate multiple simultaneous queries for the same
-                resource record", VU 457875, November 2002.
-
-
-
-
-
-
-Hubert & van Mook           Standards Track                    [Page 17]
-
-RFC 5452         DNS Resilience against Forged Answers      January 2009
-
-
-Authors' Addresses
-
-   Bert Hubert
-   Netherlabs Computer Consulting BV.
-   Braillelaan 10
-   Rijswijk (ZH)  2289 CM
-   The Netherlands
-
-   EMail: bert.hubert@netherlabs.nl
-
-
-   Remco van Mook
-   Equinix
-   Auke Vleerstraat 1
-   Enschede  7521 PE
-   The Netherlands
-
-   EMail: remco@eu.equinix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hubert & van Mook           Standards Track                    [Page 18]
-
diff --git a/doc/rfc/rfc5507.txt b/doc/rfc/rfc5507.txt
deleted file mode 100644
index a286d908..00000000
--- a/doc/rfc/rfc5507.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                                IAB
-Request for Comments: 5507                             P. Faltstrom, Ed.
-Category: Informational                                  R. Austein, Ed.
-                                                            P. Koch, Ed.
-                                                              April 2009
-
-
-                 Design Choices When Expanding 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) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-
-Abstract
-
-   This note discusses how to extend the DNS with new data for a new
-   application.  DNS extension discussions too often focus on reuse of
-   the TXT Resource Record Type.  This document lists different
-   mechanisms to extend the DNS, and concludes that the use of a new DNS
-   Resource Record Type is the best solution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-IAB, et al.                  Informational                      [Page 1]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. Background ......................................................4
-   3. Extension Mechanisms ............................................5
-      3.1. Place Selectors inside the RDATA of Existing
-           Resource Record Types ......................................5
-      3.2. Add a Prefix to the Owner Name .............................6
-      3.3. Add a Suffix to the Owner Name .............................7
-      3.4. Add a New Class ............................................8
-      3.5. Add a New Resource Record Type .............................8
-   4. Zone Boundaries are Invisible to Applications ...................9
-   5. Why Adding a New Resource Record Type Is the Preferred
-      Solution .......................................................10
-   6. Conclusion and Recommendation ..................................14
-   7. Creating a New Resource Record Type ............................14
-   8. Security Considerations ........................................15
-   9. Acknowledgements ...............................................15
-   10. IAB Members at the Time of This Writing .......................16
-   11. References ....................................................16
-      11.1. Normative References .....................................16
-      11.2. Informative References ...................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-IAB, et al.                  Informational                      [Page 2]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-1.  Introduction
-
-   The DNS stores multiple categories of data.  The two most commonly
-   used categories are infrastructure data for the DNS system itself (NS
-   and SOA Resource Records) and data that have to do with mappings
-   between domain names and IP addresses (A, AAAA, and PTR Resource
-   Records).  There are other categories as well, some of which are tied
-   to specific applications like email (MX Resource Records), while
-   others are generic Resource Record Types used to convey information
-   for multiple protocols (SRV and NAPTR Resource Records).
-
-   When storing data in the DNS for a new application, the goal must be
-   to store data in such a way that the application can query for the
-   data it wants, while minimizing both the impact on existing
-   applications and the amount of extra data transferred to the client.
-   This implies that a number of design choices have to be made, where
-   the most important is to ensure that a precise selection of what data
-   to return must be made already in the query.  A query consists of a
-   triple: {Owner (or name), Resource Record Class, Resource Record
-   Type}.
-
-   Historically, extending the DNS to store application data tied to a
-   domain name has been done in different ways at different times.  MX
-   Resource Records were created as a new Resource Record Type
-   specifically designed to support electronic mail.  SRV records are a
-   generic type that use a prefixing scheme in combination with a base
-   domain name.  NAPTR records add selection data inside the RDATA.  It
-   is clear that the methods used to add new data types to the DNS have
-   been inconsistent, and the purpose of this document is to attempt to
-   clarify the implications of each of these methods, both for the
-   applications that use them and for the rest of the DNS.
-
-   This document talks extensively about use of DNS wildcards.  Many
-   people might think use of wildcards is not something that happens
-   today.  In reality though, wildcards are in use, especially for
-   certain application-specific data such as MX Resource Records.
-   Because of this, the choice has to be made with the existence of
-   wildcards in mind.
-
-   Another overall issue that must be taken into account is what the new
-   data in the DNS are to describe.  In some cases, they might be
-   completely new data.  In other cases, they might be metadata tied to
-   data that already exist in the DNS.  Examples of new data are key
-   information for the Secure SHell (SSH) Protocol and data used for
-   authenticating the sender of email messages (metadata tied to MX
-   Resource Records).  If the new data are tied to data that already
-   exist in the DNS, an analysis should be made as to whether having
-   (for example) address records and SSH key information in different
-
-
-
-IAB, et al.                  Informational                      [Page 3]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-   DNS zones is a problem or if it is a bonus, and if it is a problem,
-   whether the specification must require all of the related data to be
-   in the same zone.  One specific difference between having the records
-   in the same zone or not has to do with maintenance of the records.
-   If they are in the same zone, the same maintainer (from a DNS
-   perspective) manages the two records.  Specifically, they must be
-   signed with the same DNSSEC keys if DNSSEC is in use.
-
-   This document does not talk about what one should store in the DNS.
-   It also doesn't discuss whether the DNS should be used for service
-   discovery, or whether the DNS should be used for storage of data
-   specific to the service.  In general, the DNS is a protocol that,
-   apart from holding metadata that makes the DNS itself function (NS,
-   SOA, DNSSEC Resource Record Types, etc.), only holds references to
-   service locations (SRV, NAPTR, A, AAAA Resource Record Types) --
-   though there are exceptions, such as MX Resource Records.
-
-2.  Background
-
-   See RFC 5395 [RFC5395] for a brief summary of the DNS query
-   structure.  Readers interested in the full story should start with
-   the base DNS specification in RFC 1035 [RFC1035] and continue with
-   the various documents that update, clarify, and extend the base
-   specification.
-
-   When composing a DNS query, the parameters used by the protocol are a
-   {owner, class, type} triple.  Every Resource Record matching such a
-   triple is said to belong to the same Resource Record Set (RRSet), and
-   the whole RRSet is always returned to the client that queries for it.
-   Splitting an RRSet is a protocol violation (sending a partial RRSet,
-   not truncating the DNS response), because it can result in coherency
-   problems with the DNS caching mechanism.  See Section 5 of [RFC2181]
-   for more information.
-
-   Some discussions around extensions to the DNS include arguments
-   around MTU size.  Note that most discussions about DNS and MTU size
-   are about the size of the whole DNS packet, not about the size of a
-   single RRSet.
-
-   Almost all DNS query traffic is carried over UDP, where a DNS message
-   must fit within a single UDP packet.  DNS response messages are
-   almost always larger than DNS query messages, so message size issues
-   are almost always about responses, not queries.  The base DNS
-   specification limits DNS messages over UDP to 512 octets; EDNS0
-   [RFC2671] specifies a mechanism by which a client can signal its
-   willingness to receive larger responses, but deployment of EDNS0 is
-   not universal, in part because of firewalls that block fragmented UDP
-   packets or EDNS0.  If a response message won't fit in a single
-
-
-
-IAB, et al.                  Informational                      [Page 4]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-   packet, the name server returns a truncated response, at which point
-   the client may retry using TCP.  DNS queries over TCP are not subject
-   to this length limitation, but TCP imposes significantly higher per-
-   query overhead on name servers than UDP.  It is also the case that
-   the policies in deployed firewalls far too often are such that they
-   block DNS over TCP, so using TCP might not in reality be an option.
-   There are also risks (although possibly small) that a change of
-   routing while a TCP flow is open creates problems when the DNS
-   servers are deployed in an anycast environment.
-
-3.  Extension Mechanisms
-
-   The DNS protocol is intended to be extensible to support new kinds of
-   data.  This section examines the various ways in which this sort of
-   extension can be accomplished.
-
-3.1.  Place Selectors inside the RDATA of Existing Resource Record Types
-
-   For a given query name, one might choose to have a single RRSet (all
-   Resource Records sharing the same {owner, class, type} triple) shared
-   by multiple applications, and have the different applications use
-   selectors within the Resource Record data (RDATA) to determine which
-   records are intended for which applications.  This sort of selector
-   mechanism is usually referred to "subtyping", because it is in effect
-   creating an additional type subsystem within a single DNS Resource
-   Record Type.
-
-   Examples of subtyping include NAPTR Resource Records [RFC3761] and
-   the original DNSSEC KEY Resource Record Type [RFC2535] (which was
-   later updated by RFC 3445 [RFC3445], and obsoleted by RFC 4033
-   [RFC4033], RFC 4034 [RFC4034] and RFC 4035 [RFC4035]).
-
-   All DNS subtyping schemes share a common weakness: with subtyping
-   schemes, it is impossible for a client to query for just the data it
-   wants.  Instead, the client must fetch the entire RRSet, then select
-   the Resource Records in which it is interested.  Furthermore, since
-   DNSSEC signatures operate on complete RRSets, the entire RRSet must
-   be re-signed if any Resource Record in it changes.  As a result, each
-   application that uses a subtyped Resource Record incurs higher
-   overhead than any of the applications would have incurred had they
-   not been using a subtyping scheme.  The fact the RRSet is always
-   passed around as an indivisible unit increases the risk the RRSet
-   will not fit in a UDP packet, which in turn increases the risk that
-   the client will have to retry the query with TCP, which substantially
-   increases the load on the name server.  More precisely: having one
-   query fail over to TCP is not a big deal, but since the typical ratio
-
-
-
-
-
-IAB, et al.                  Informational                      [Page 5]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-   of clients to servers in today's deployed DNS is very high, having a
-   substantial number of DNS messages fail over to TCP may cause the
-   queried name servers to be overloaded by TCP overhead.
-
-   Because of the size limitations, using a subtyping scheme to list a
-   large number of services for a single domain name risks triggering
-   truncation and fallback to TCP, which may in turn force the zone
-   administrator to announce only a subset of available services.
-
-3.2.  Add a Prefix to the Owner Name
-
-   By adding an application-specific prefix to a domain name, we get a
-   different {owner, class, type} triple, and therefore a different
-   RRSet.  One problem with adding prefixes has to do with wildcards,
-   especially if one has records like:
-
-   *.example.com. IN MX 1 mail.example.com.
-
-   and one wants records tied to those names.  Suppose one creates the
-   prefix "_mail".  One would then have to say something like:
-
-   _mail.*.example.com. IN X-FOO A B C D
-
-   but DNS wildcards only work with the "*" as the leftmost token in the
-   domain name (see also RFC 4592 [RFC4592]).
-
-   There have been proposals to deal with the problem that DNS wildcards
-   are always terminal records.  These proposals introduce an additional
-   set of trade-offs that would need to be taken into account when
-   assessing which extension mechanism to choose.  Aspects of extra
-   response time needed to perform the extra queries, costs of pre-
-   calculation of possible answers, or the costs induced to the system
-   as a whole come to mind.  At the time of writing, none of these
-   proposals has been published as Standards Track RFCs.
-
-   Even when a specific prefix is chosen, the data will still have to be
-   stored in some Resource Record Type.  This Resource Record Type can
-   be either a new Resource Record Type or an existing Resource Record
-   Type that has an appropriate format to store the data.  One also
-   might need some other selection mechanism, such as the ability to
-   distinguish between the records in an RRSet, given they have the same
-   Resource Record Type.  Because of this, one needs to both register a
-   unique prefix and define what Resource Record Type is to be used for
-   this specific service.
-
-
-
-
-
-
-
-IAB, et al.                  Informational                      [Page 6]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-   If the record has some relationship with another record in the zone,
-   the fact that the two records can be in different zones might have
-   implications on the trust the application has in the records.  For
-   example:
-
-   example.com.      IN MX    10 mail.example.com.
-   _foo.example.com. IN X-BAR "metadata for the mail service"
-
-   In this example, the two records might be in two different zones, and
-   as a result might be administered by two different organizations, and
-   signed by two different entities when using DNSSEC.  For these two
-   reasons, using a prefix has recently become a very interesting
-   solution for many protocol designers.  In some cases, e.g.,
-   DomainKeys Identified Mail Signatures [RFC4871], TXT records have
-   been used.  In others, such as SRV, entirely new Resource Record
-   Types have been added.
-
-3.3.  Add a Suffix to the Owner Name
-
-   Adding a suffix to a domain name changes the {owner, class, type}
-   triple, and therefore the RRSet.  In this case, since the query name
-   can be set to exactly the data one wants, the size of the RRSet is
-   minimized.  The problem with adding a suffix is that it creates a
-   parallel tree within the IN class.  Further, there is no technical
-   mechanism to ensure that the delegation for "example.com" and
-   "example.com._bar" are made to the same organization.  Furthermore,
-   data associated with a single entity will now be stored in two
-   different zones, such as "example.com" and "example.com._bar", which,
-   depending on who controls "_bar", can create new synchronization and
-   update authorization issues.
-
-   One way of solving the administrative issues is by using the DNAME
-   Resource Record Type specified in RFC 2672 [RFC2672].
-
-   Even when using a different name, the data will still have to be
-   stored in some Resource Record Type that has an appropriate format to
-   store the data.  This implies that one might have to mix the prefix
-   based selection mechanism with some other mechanism so that the right
-   Resource Record can be found out of many in a potential larger RRSet.
-
-   In RFC 2163 [RFC2163] an infix token is inserted directly below the
-   Top-Level Domain (TLD), but the result is equivalent to adding a
-   suffix to the owner name (instead of creating a TLD, one is creating
-   a second level domain).
-
-
-
-
-
-
-
-IAB, et al.                  Informational                      [Page 7]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-3.4.  Add a New Class
-
-   DNS zones are class-specific in the sense that all the records in
-   that zone share the same class as the zone's SOA record and the
-   existence of a zone in one class does not guarantee the existence of
-   the zone in any other class.  In practice, only the IN class has ever
-   seen widespread deployment, and the administrative overhead of
-   deploying an additional class would almost certainly be prohibitive.
-
-   Nevertheless, one could, in theory, use the DNS class mechanism to
-   distinguish between different kinds of data.  However, since the DNS
-   delegation tree (represented by NS Resource Records) is itself tied
-   to a specific class, attempting to resolve a query by crossing a
-   class boundary may produce unexpected results because there is no
-   guarantee that the name servers for the zone in the new class will be
-   the same as the name servers in the IN class.  The MIT Hesiod system
-   [Dyer87] used a scheme like this for storing data in the HS class,
-   but only on a very small scale (within a single institution), and
-   with an administrative fiat requiring that the delegation trees for
-   the IN and HS trees be identical.  The use of the HS class for such
-   storage of non-sensitive data was, over time, replaced by use of the
-   Lightweight Directory Access Protocol (LDAP) [RFC4511].
-
-   Even when using a different class, the data will still have to be
-   stored in some Resource Record Type that has an appropriate format.
-
-3.5.  Add a New Resource Record Type
-
-   When adding a new Resource Record Type to the system, entities in
-   four different roles have to be able to handle the new Type:
-
-   1.  There must be a way to insert the new Resource Records into the
-       zone at the Primary Master name server.  For some server
-       implementations, the user interface only accepts Resource Record
-       Types that it understands (perhaps so that the implementation can
-       attempt to validate the data).  Other implementations allow the
-       zone administrator to enter an integer for the Resource Record
-       Type code and the RDATA in Base64 or hexadecimal encoding (or
-       even as raw data).  RFC 3597 [RFC3597] specifies a standard
-       generic encoding for this purpose.
-
-   2.  A slave authoritative name server must be able to do a zone
-       transfer, receive the data from some other authoritative name
-       server, and serve data from the zone even though the zone
-       includes records of unknown Resource Record Types.  Historically,
-       some implementations have had problems parsing stored copies of
-       the zone file after restarting, but those problems have not been
-       seen for a few years.  Some implementations use an alternate
-
-
-
-IAB, et al.                  Informational                      [Page 8]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-       mechanism (e.g., LDAP) to transfer Resource Records in a zone,
-       and are primarily used within corporate environments; in this
-       case, name servers must be able to transfer new Resource Record
-       Types using whatever mechanism is used.  However, today this
-       alternative mechanism may not support unknown Resource Record
-       Types.  Hence, in Internet environments, unknown Resource Record
-       Types are supported, but in corporate environments they are
-       problematic.
-
-   3.  A caching resolver (most commonly a recursive name server) will
-       cache the records that are responses to queries.  As mentioned in
-       RFC 3597 [RFC3597], there are various pitfalls where a recursive
-       name server might end up having problems.
-
-   4.  The application must be able to get the RRSet with a new Resource
-       Record Type.  The application itself may understand the RDATA,
-       but the resolver library might not.  Support for a generic
-       interface for retrieving arbitrary DNS Resource Record Types has
-       been a requirement since 1989 (see Section 6.1.4.2 of [RFC1123]).
-       Some stub resolver library implementations neglect to provide
-       this functionality and cannot handle unknown Resource Record
-       Types, but implementation of a new stub resolver library is not
-       particularly difficult, and open source libraries that already
-       provide this functionality are available.
-
-   Historically, adding a new Resource Record Type has been very
-   problematic.  The review process has been cumbersome, DNS servers
-   have not been able to handle new Resource Record Types, and firewalls
-   have dropped queries or responses with Resource Record Types that are
-   unknown to the firewall.  This is, for example, one of the reasons
-   the ENUM standard reuses the NAPTR Resource Record, a decision that
-   today might have gone to creating a new Resource Record Type instead.
-
-   Today, there is a requirement that DNS software handle unknown
-   Resource Record Types, and investigations have shown that software
-   that is deployed, in general, does support it, except in some
-   alternate mechanisms for transferring Resource Records such as LDAP,
-   as noted above.  Also, the approval process for new Resource Record
-   Types has been updated [RFC5395] so the effort that is needed for
-   various Resource Record Types is more predictable.
-
-4.  Zone Boundaries are Invisible to Applications
-
-   Regardless of the possible choices above, we have seen a number of
-   cases where the application made assumptions about the structure of
-   the namespace and the location where specific information resides.
-   We take a small sidestep to argue against such approaches.
-
-
-
-
-IAB, et al.                  Informational                      [Page 9]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-   The DNS namespace is a hierarchy, technically speaking.  However,
-   this only refers to the way names are built from multiple labels.
-   DNS hierarchy neither follows nor implies administrative hierarchy.
-   Because of that, it cannot be assumed that data attached to a node in
-   the DNS tree is valid for the whole subtree.  Technically, there are
-   zone boundaries partitioning the namespace, and administrative
-   boundaries (or policy boundaries) may even exist elsewhere.
-
-   The false assumption has lead to an approach called "tree climbing",
-   where a query that does not receive a positive response (either the
-   requested RRSet was missing or the name did not exist) is retried by
-   repeatedly stripping off the leftmost label (climbing towards the
-   root) until the root domain is reached.  Sometimes these proposals
-   try to avoid the query for the root or the TLD level, but still this
-   approach has severe drawbacks:
-
-   o  Technically, the DNS was built as a query-response tool without
-      any search capability [RFC3467].  Adding the search mechanism
-      imposes additional burden on the technical infrastructure, in the
-      worst case on TLD and root name servers.
-
-   o  For reasons similar to those outlined in RFC 1535 [RFC1535],
-      querying for information in a domain outside the control of the
-      intended entity may lead to incorrect results and may also put
-      security at risk.  Finding the exact policy boundary is impossible
-      without an explicit marker, which does not exist at present.  At
-      best, software can detect zone boundaries (e.g., by looking for
-      SOA Resource Records), but some TLD registries register names
-      starting at the second level (e.g., CO.UK), and there are various
-      other "registry" types at second, third, or other level domains
-      that cannot be identified as such without policy knowledge
-      external to the DNS.
-
-   To restate, the zone boundary is purely a boundary that exists in the
-   DNS for administrative purposes, and applications should be careful
-   not to draw unwarranted conclusions from zone boundaries.  A
-   different way of stating this is that the DNS does not support
-   inheritance, e.g., an MX RRSet for a TLD will not be valid for any
-   subdomain of that particular TLD.
-
-5.  Why Adding a New Resource Record Type Is the Preferred Solution
-
-   By now, the astute reader might be wondering what conclusions to draw
-   from the issues presented so far.  We will now attempt to clear up
-   the reader's confusion by following the thought processes of a
-   typical application designer who wishes to store data in the DNS.
-   We'll show how such a designer almost inevitably hits upon the idea
-   of just using a TXT Resource Record, why this is a bad thing, and why
-
-
-
-IAB, et al.                  Informational                     [Page 10]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-   a new Resource Record Type should be allocated instead.  We'll also
-   explain how the reuse of an existing Resource Record, including TXT,
-   can be made less harmful.
-
-   The overall problem with most solutions has to do with two main
-   issues:
-
-   o  No semantics to prevent collision with other use
-
-   o  Space considerations in the DNS message
-
-   A typical application designer is not interested in the DNS for its
-   own sake, but rather regards it as a distributed database in which
-   application data can be stored.  As a result, the designer of a new
-   application is usually looking for the easiest way to add whatever
-   new data the application needs to the DNS in a way that naturally
-   associates the data with a DNS name and does not require major
-   changes to DNS servers.
-
-   As explained in Section 3.4, using the DNS class system as an
-   extension mechanism is not really an option, and in fact, most users
-   of the system don't even realize that the mechanism exists.  As a
-   practical matter, therefore any extension is likely to be within the
-   IN class.
-
-   Adding a new Resource Record Type is the technically correct answer
-   from the DNS protocol standpoint (more on this below), but doing so
-   requires some DNS expertise, due to the issues listed in Section 3.5.
-   Consequently, this option is often rejected.  Note that according to
-   RFC 5395 [RFC5395], some Types require IETF Consensus, while others
-   only require a specification.
-
-   There is a drawback to defining new RR types that is worth
-   mentioning.  The Resource Record Type (RRTYPE) is a 16-bit value and
-   hence is a limited resource.  In order to prevent hoarding the
-   registry has a review-based allocation policy [RFC5395]; however,
-   this may not be sufficient if extension of the DNS by addition of new
-   RR types takes up significantly and the registry starts nearing
-   completion.  In that case, the trade-offs with respect to choosing an
-   extension mechanism may need to change.
-
-   The application designer is thus left with the prospect of reusing
-   some existing DNS Types within the IN class, but when the designer
-   looks at the existing Types, almost all of them have well-defined
-   semantics, none of which quite match the needs of the new
-   application.  This has not completely prevented proposals from
-
-
-
-
-
-IAB, et al.                  Informational                     [Page 11]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-   reusing existing Resource Record Types in ways incompatible with
-   their defined semantics, but it does tend to steer application
-   designers away from this approach.
-
-   For example, Resource Record Type 40 was registered for the SINK
-   Resource Record Type.  This Resource Record Type was discussed in the
-   DNSIND working group of the IETF, and it was decided at the 46th IETF
-   to not move the I-D forward to become an RFC because of the risk of
-   encouraging application designers to use the SINK Resource Record
-   Type instead of registering a new Resource Record Type, which would
-   result in infeasibly large SINK RRsets.
-
-   Eliminating all of the above leaves the TXT Resource Record Type in
-   the IN class.  The TXT RDATA format is free form text, and there are
-   no existing semantics to get in the way.  Some attempts have been
-   made, for example, in [DNSEXT-DNS-SD], to specify a structured format
-   for TXT Resource Record Types, but no such attempt has reached RFC
-   status.  Furthermore, the TXT Resource Record can obviously just be
-   used as a bucket in which to carry around data to be used by some
-   higher-level parser, perhaps in some human-readable programming or
-   markup language.  Thus, for many applications, TXT Resource Records
-   are the "obvious" choice.  Unfortunately, this conclusion, while
-   understandable, is also problematic, for several reasons.
-
-   The first reason why TXT Resource Records are not well suited to such
-   use is precisely what makes them so attractive: the lack of pre-
-   defined common syntax or structure.  As a result, each application
-   that uses them creates its own syntax/structure, and that makes it
-   difficult to reliably distinguish one application's record from
-   others, and for its parser to avoid problems when it encounters other
-   TXT records.
-
-   Arguably, the TXT Resource Record is misnamed, and should have been
-   called the Local Container record, because a TXT Resource Record
-   means only what the data producer says it means.  This is fine, so
-   long as TXT Resource Records are being used by human beings or by
-   private agreement between data producer and data consumer.  However,
-   it becomes a problem once one starts using them for standardized
-   protocols in which there is no prior relationship between data
-   producer and data consumer.  If TXT records are used without one of
-   the naming modifications discussed earlier (and in some cases even if
-   one uses such naming mechanisms), there is nothing to prevent
-   collisions with some other incompatible use of TXT Resource Records.
-
-   This is even worse than the general subtyping problem described in
-   Section 3.1 because TXT Resource Records don't even have a
-   standardized selector field in which to store the subtype.  RFC 1464
-   [RFC1464] tried, but it was not a success.  At best, a definition of
-
-
-
-IAB, et al.                  Informational                     [Page 12]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-   a subtype is reduced to hoping that whatever scheme one has come up
-   with will not accidently conflict with somebody else's subtyping
-   scheme, and that it will not be possible to mis-parse one
-   application's use of TXT Resource Records as data intended for a
-   different application.  Any attempt to impose a standardized format
-   within the TXT Resource Record format would be at least fifteen years
-   too late, even if it were put into effect immediately; at best, one
-   can restrict the syntax that a particular application uses within a
-   TXT Resource Record and accept the risk that unrelated TXT Resource
-   Record uses will collide with it.
-
-   Using one of the naming modifications discussed in Section 3.2 and
-   Section 3.3 would address the subtyping problem, (and have been used
-   in combinations with reuse of TXT record, such as for the dns/txt
-   lookup mechanism in Domain Keys Identified Mail (DKIM)) but each of
-   these approaches brings in new problems of its own.  The prefix
-   approach (that for example SRV Resource Records use) does not work
-   well with wildcards, which is a particular problem for mail-related
-   applications, since MX Resource Records are probably the most common
-   use of DNS wildcards.  The suffix approach doesn't have wildcard
-   issues, but, as noted previously, it does have synchronization and
-   update authorization issues, since it works by creating a second
-   subtree in a different part of the global DNS namespace.
-
-   The next reason why TXT Resource Records are not well suited to
-   protocol use has to do with the limited data space available in a DNS
-   message.  As alluded to briefly in Section 3.1, typical DNS query
-   traffic patterns involve a very large number of DNS clients sending
-   queries to a relatively small number of DNS servers.  Normal path MTU
-   discovery schemes do little good here because, from the server's
-   perspective, there isn't enough repeat traffic from any one client
-   for it to be worth retaining state.  UDP-based DNS is an idempotent
-   query, whereas TCP-based DNS requires the server to keep state (in
-   the form of TCP connection state, usually in the server's kernel) and
-   roughly triples the traffic load.  Thus, there's a strong incentive
-   to keep DNS messages short enough to fit in a UDP datagram,
-   preferably a UDP datagram short enough not to require IP
-   fragmentation.
-
-   Subtyping schemes are therefore again problematic because they
-   produce larger Resource RRSets than necessary, but verbose text
-   encodings of data are also wasteful since the data they hold can
-   usually be represented more compactly in a Resource Record designed
-   specifically to support the application's particular data needs.  If
-   the data that need to be carried are so large that there is no way to
-   make them fit comfortably into the DNS regardless of encoding, it is
-   probably better to move the data somewhere else, and just use the DNS
-   as a pointer to the data, as with NAPTR.
-
-
-
-IAB, et al.                  Informational                     [Page 13]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-6.  Conclusion and Recommendation
-
-   Given the problems detailed in Section 5, it is worth reexamining the
-   oft-jumped-to conclusion that specifying a new Resource Record Type
-   is hard.  Historically, this was indeed the case, but recent surveys
-   suggest that support for unknown Resource Record Types [RFC3597] is
-   now widespread in the public Internet, and because of that, the DNS
-   infrastructure can handle new Resource Record Types.  The lack of
-   support for unknown Types remains an issue for relatively old
-   provisioning software and in corporate environments.
-
-   Of all the issues detailed in Section 3.5, provisioning the data is
-   in some respects the most difficult.  Investigations with zone
-   transfers show that the problem is less difficult for the
-   authoritative name servers themselves than the front-end systems used
-   to enter (and perhaps validate) the data.  Hand editing does not work
-   well for maintenance of large zones, so some sort of tool is
-   necessary, and the tool may not be tightly coupled to the name server
-   implementation itself.  Note, however, that this provisioning problem
-   exists to some degree with any new form of data to be stored in the
-   DNS, regardless of data format, Resource Record type (even if TXT
-   Resource Record Types are in use), or naming scheme.  Adapting front-
-   end systems to support a new Resource Record Type may be a bit more
-   difficult than reusing an existing type, but this appears to be a
-   minor difference in degree rather than a difference in kind.
-
-   Given the various issues described in this note, we believe that:
-
-   o  there is no magic solution that allows a completely painless
-      addition of new data to the DNS, but
-
-   o  on the whole, the best solution is still to use the DNS Resource
-      Record Type mechanism designed for precisely this purpose,
-      whenever possible, and
-
-   o  of all the alternate solutions, the "obvious" approach of using
-      TXT Resource Records for arbitrary names is almost certainly the
-      worst, especially for the two reasons outlined above (lack of
-      semantics and its implementations, and size leading to the need to
-      use TCP).
-
-7.  Creating a New Resource Record Type
-
-   The process for creating a new Resource Record Type is specified in
-   RFC 5395 [RFC5395].
-
-
-
-
-
-
-IAB, et al.                  Informational                     [Page 14]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-8.  Security Considerations
-
-   DNS RRSets can be signed using DNSSEC.  DNSSEC is almost certainly
-   necessary for any application mechanism that stores authorization
-   data in the DNS.  DNSSEC signatures significantly increase the size
-   of the messages transported, and because of this, the DNS message
-   size issues discussed in Sections 3.1 and 5 are more serious than
-   they might at first appear.
-
-   Adding new Resource Record Types (as discussed in Section 3.5) can
-   create two different kinds of problems: in the DNS software and in
-   applications.  In the DNS software, it might conceivably trigger bugs
-   and other bad behavior in software that is not compliant with RFC
-   3597 [RFC3597], but most such DNS software is old enough and insecure
-   enough that it should be updated for other reasons in any case.  In
-   applications and provisioning software, the changes for the new
-   features that need the new data in the DNS can be updated to
-   understand the structure of the new data format (regardless of
-   whether a new Resource Record Type is used or some other mechanism is
-   chosen).  Basic API support for retrieving arbitrary Resource Record
-   Types has been a requirement since 1989 [RFC1123].
-
-   Any new protocol that proposes to use the DNS to store data used to
-   make authorization decisions would be well advised not only to use
-   DNSSEC but also to encourage upgrades to DNS server software recent
-   enough not to be riddled with well-known exploitable bugs.
-
-9.  Acknowledgements
-
-   This document has been created over a number of years, with input
-   from many people.  The question on how to expand and use the DNS is
-   sensitive, and a document like this can not please everyone.  The
-   goal is instead to describe the architecture and tradeoffs, and make
-   some recommendations about best practices.
-
-   People that have helped include: Dean Anderson, Mark Andrews, John
-   Angelmo, Roy Badami, Dan Bernstein, Alex Bligh, Nathaniel Borenstein,
-   Stephane Bortzmeyer, Brian Carpenter, Leslie Daigle, Elwyn Davies,
-   Mark Delany, Richard Draves, Martin Duerst, Donald Eastlake, Robert
-   Elz, Jim Fenton, Tony Finch, Jim Gilroy, Olafur Gudmundsson, Eric
-   Hall, Phillip Hallam-Baker, Ted Hardie, Bob Hinden, Paul Hoffman,
-   Geoff Houston, Christian Huitema, Johan Ihren, John Klensin, Ben
-   Laurie, William Leibzon, John Levine, Edward Lewis, David MacQuigg,
-   Allison Mankin, Bill Manning, David Meyer, Pekka Nikander, Mans
-   Nilsson, Masataka Ohta, Douglas Otis, Michael Patton, Jonathan
-   Rosenberg, Anders Rundgren, Miriam Sapiro, Carsten Strotmann, Pekka
-   Savola, Chip Sharp, James Snell, Michael Thomas, Paul Vixie, Sam
-   Weiler, Florian Weimer, Bert Wijnen, and Dan Wing.
-
-
-
-IAB, et al.                  Informational                     [Page 15]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-10.  IAB Members at the Time of This Writing
-
-   Loa Andersson
-   Gonzalo Camarillo
-   Stuart Cheshire
-   Russ Housley
-   Olaf Kolkman
-   Gregory Lebovitz
-   Barry Leiba
-   Kurtis Lindqvist
-   Andrew Malis
-   Danny McPherson
-   David Oran
-   Dave Thaler
-   Lixia Zhang
-
-11.  References
-
-11.1.  Normative References
-
-   [RFC1035]        Mockapetris, P., "Domain names - implementation and
-                    specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1464]        Rosenbaum, R., "Using the Domain Name System To
-                    Store Arbitrary String Attributes", RFC 1464,
-                    May 1993.
-
-   [RFC2535]        Eastlake, D., "Domain Name System Security
-                    Extensions", RFC 2535, March 1999.
-
-   [RFC2671]        Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-                    RFC 2671, August 1999.
-
-   [RFC3597]        Gustafsson, A., "Handling of Unknown DNS Resource
-                    Record (RR) Types", RFC 3597, September 2003.
-
-   [RFC5395]        Eastlake, D., "Domain Name System (DNS) IANA
-                    Considerations", BCP 42, RFC 5395, November 2008.
-
-11.2.  Informative References
-
-   [DNSEXT-DNS-SD]  Cheshire, S. and M. Krochmal, "DNS-Based Service
-                    Discovery", Work in Progress, September 2008.
-
-   [Dyer87]         Dyer, S. and F. Hsu, "Hesiod, Project Athena
-                    Technical Plan - Name Service", Version 1.9,
-                    April 1987.
-
-
-
-
-IAB, et al.                  Informational                     [Page 16]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-   [RFC1123]        Braden, R., "Requirements for Internet Hosts -
-                    Application and Support", STD 3, RFC 1123,
-                    October 1989.
-
-   [RFC1535]        Gavron, E., "A Security Problem and Proposed
-                    Correction With Widely Deployed DNS Software",
-                    RFC 1535, October 1993.
-
-   [RFC2163]        Allocchio, C., "Using the Internet DNS to Distribute
-                    MIXER Conformant Global Address Mapping (MCGAM)",
-                    RFC 2163, January 1998.
-
-   [RFC2181]        Elz, R. and R. Bush, "Clarifications to the DNS
-                    Specification", RFC 2181, July 1997.
-
-   [RFC2672]        Crawford, M., "Non-Terminal DNS Name Redirection",
-                    RFC 2672, August 1999.
-
-   [RFC3445]        Massey, D. and S. Rose, "Limiting the Scope of the
-                    KEY Resource Record (RR)", RFC 3445, December 2002.
-
-   [RFC3467]        Klensin, J., "Role of the Domain Name System (DNS)",
-                    RFC 3467, February 2003.
-
-   [RFC3761]        Faltstrom, P. and M. Mealling, "The E.164 to Uniform
-                    Resource Identifiers (URI) Dynamic Delegation
-                    Discovery System (DDDS) Application (ENUM)",
-                    RFC 3761, April 2004.
-
-   [RFC4033]        Arends, R., Austein, R., Larson, M., Massey, D., and
-                    S. Rose, "DNS Security Introduction and
-                    Requirements", RFC 4033, March 2005.
-
-   [RFC4034]        Arends, R., Austein, R., Larson, M., Massey, D., and
-                    S. Rose, "Resource Records for the DNS Security
-                    Extensions", RFC 4034, March 2005.
-
-   [RFC4035]        Arends, R., Austein, R., Larson, M., Massey, D., and
-                    S. Rose, "Protocol Modifications for the DNS
-                    Security Extensions", RFC 4035, March 2005.
-
-   [RFC4511]        Sermersheim, J., "Lightweight Directory Access
-                    Protocol (LDAP): The Protocol", RFC 4511, June 2006.
-
-   [RFC4592]        Lewis, E., "The Role of Wildcards in the Domain Name
-                    System", RFC 4592, July 2006.
-
-
-
-
-
-IAB, et al.                  Informational                     [Page 17]
-
-RFC 5507         Design Choices When Expanding the DNS        April 2009
-
-
-   [RFC4871]        Allman, E., Callas, J., Delany, M., Libbey, M.,
-                    Fenton, J., and M. Thomas, "DomainKeys Identified
-                    Mail (DKIM) Signatures", RFC 4871, May 2007.
-
-Authors' Addresses
-
-   Internet Architecture Board
-
-   EMail: iab@iab.org
-
-
-   Patrik Faltstrom (editor)
-
-   EMail: paf@cisco.com
-
-
-   Rob Austein (editor)
-
-   EMail: sra@isc.org
-
-
-   Peter Koch (editor)
-
-   EMail: pk@denic.de
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-IAB, et al.                  Informational                     [Page 18]
-
diff --git a/doc/rfc/rfc5625.txt b/doc/rfc/rfc5625.txt
deleted file mode 100644
index 102d7e87..00000000
--- a/doc/rfc/rfc5625.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Bellis
-Request for Comments: 5625                                    Nominet UK
-BCP: 152                                                     August 2009
-Category: Best Current Practice
-
-
-                  DNS Proxy Implementation Guidelines
-
-Abstract
-
-   This document provides guidelines for the implementation of DNS
-   proxies, as found in broadband gateways and other similar network
-   devices.
-
-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) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bellis                   Best Current Practice                  [Page 1]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Terminology .....................................................3
-   3. The Transparency Principle ......................................3
-   4. Protocol Conformance ............................................4
-      4.1. Unexpected Flags and Data ..................................4
-      4.2. Label Compression ..........................................4
-      4.3. Unknown Resource Record Types ..............................4
-      4.4. Packet Size Limits .........................................4
-           4.4.1. TCP Transport .......................................5
-           4.4.2. Extension Mechanisms for DNS (EDNS0) ................6
-           4.4.3. IP Fragmentation ....................................6
-      4.5. Secret Key Transaction Authentication for DNS (TSIG) .......7
-   5. DHCP's Interaction with DNS .....................................7
-      5.1. Domain Name Server (DHCP Option 6) .........................7
-      5.2. Domain Name (DHCP Option 15) ...............................8
-      5.3. DHCP Leases ................................................8
-   6. Security Considerations .........................................9
-      6.1. Forgery Resilience .........................................9
-      6.2. Interface Binding .........................................10
-      6.3. Packet Filtering ..........................................10
-   7. Acknowledgements ...............................................10
-   8. References .....................................................11
-      8.1. Normative References ......................................11
-      8.2. Informative References ....................................12
-
-1.  Introduction
-
-   Research has found ([SAC035], [DOTSE]) that many commonly used
-   broadband gateways (and similar devices) contain DNS proxies that are
-   incompatible in various ways with current DNS standards.
-
-   These proxies are usually simple DNS forwarders, but typically do not
-   have any caching capabilities.  The proxy serves as a convenient
-   default DNS resolver for clients on the LAN, but relies on an
-   upstream resolver (e.g., at an ISP) to perform recursive DNS lookups.
-
-   Note that to ensure full DNS protocol interoperability it is
-   preferred that client stub resolvers should communicate directly with
-   full-feature, upstream recursive resolvers wherever possible.
-
-   That notwithstanding, this document describes the incompatibilities
-   that have been discovered and offers guidelines to implementors on
-   how to provide better interoperability in those cases where the
-   client must use the broadband gateway's DNS proxy.
-
-
-
-
-
-Bellis                   Best Current Practice                  [Page 2]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-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].
-
-3.  The Transparency Principle
-
-   It is not considered practical for a simple DNS proxy to implement
-   all current and future DNS features.
-
-   There are several reasons why this is the case:
-
-   o  Broadband gateways usually have limited hardware resources.
-
-   o  Firmware upgrade cycles are long, and many users do not routinely
-      apply upgrades when they become available.
-
-   o  No one knows what those future DNS features will be or how they
-      might be implemented.
-
-   o  Doing so would substantially complicate the configuration user
-      interface (UI) of the device.
-
-   Furthermore, some modern DNS protocol extensions (see, e.g., EDNS0
-   below) are intended to be used as "hop-by-hop" mechanisms.  If the
-   DNS proxy is considered to be such a "hop" in the resolution chain,
-   then for it to function correctly, it would need to be fully
-   compliant with all such mechanisms.
-
-   [SAC035] shows that the more actively a proxy participates in the DNS
-   protocol, the more likely it is that it will somehow interfere with
-   the flow of messages between the DNS client and the upstream
-   recursive resolvers.
-
-   The role of the proxy should therefore be no more and no less than to
-   receive DNS requests from clients on the LAN side, forward those
-   verbatim to one of the known upstream recursive resolvers on the WAN
-   side, and ensure that the whole response is returned verbatim to the
-   original client.
-
-   It is RECOMMENDED that proxies should be as transparent as possible,
-   such that any "hop-by-hop" mechanisms or newly introduced protocol
-   extensions operate as if the proxy were not there.
-
-   Except when required to enforce an active security or network policy
-   (such as maintaining a pre-authentication "walled garden"), end-users
-   SHOULD be able to send their DNS queries to specified upstream
-
-
-
-Bellis                   Best Current Practice                  [Page 3]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   resolvers, thereby bypassing the proxy altogether.  In this case, the
-   gateway SHOULD NOT modify the DNS request or response packets in any
-   way.
-
-4.  Protocol Conformance
-
-4.1.  Unexpected Flags and Data
-
-   The Transparency Principle above, when combined with Postel's
-   Robustness Principle [RFC0793], suggests that DNS proxies should not
-   arbitrarily reject or otherwise drop requests or responses based on
-   perceived non-compliance with standards.
-
-   For example, some proxies have been observed to drop any packet
-   containing either the "Authentic Data" (AD) or "Checking Disabled"
-   (CD) bits from DNSSEC [RFC4035].  This may be because [RFC1035]
-   originally specified that these unused "Z" flag bits "MUST" be zero.
-   However, these flag bits were always intended to be reserved for
-   future use, so refusing to proxy any packet containing these flags
-   (now that uses for those flags have indeed been defined) is not
-   appropriate.
-
-   Therefore, proxies MUST ignore any unknown DNS flags and proxy those
-   packets as usual.
-
-4.2.  Label Compression
-
-   Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
-
-   Proxies MUST forward packets regardless of the presence or absence of
-   compressed labels therein.
-
-4.3.  Unknown Resource Record Types
-
-   [RFC3597] requires that resolvers MUST handle Resource Records (RRs)
-   of unknown type transparently.
-
-   All requests and responses MUST be proxied regardless of the values
-   of the QTYPE and QCLASS fields.
-
-   Similarly, all responses MUST be proxied regardless of the values of
-   the TYPE and CLASS fields of any Resource Record therein.
-
-4.4.  Packet Size Limits
-
-   [RFC1035] specifies that the maximum size of the DNS payload in a UDP
-   packet is 512 octets.  Where the required portions of a response
-   would not fit inside that limit, the DNS server MUST set the
-
-
-
-Bellis                   Best Current Practice                  [Page 4]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   "TrunCation" (TC) bit in the DNS response header to indicate that
-   truncation has occurred.  There are however two standard mechanisms
-   (described in Sections 4.4.1 and 4.4.2) for transporting responses
-   larger than 512 octets.
-
-   Many proxies have been observed to truncate all responses at 512
-   octets, and others at a packet size related to the WAN MTU, in either
-   case doing so without correctly setting the TC bit.
-
-   Other proxies have been observed to remove the TC bit in server
-   responses that correctly had the TC bit set by the server.
-
-   If a DNS response is truncated but the TC bit is not set, then client
-   failures may result.  In particular, a naive DNS client library might
-   suffer crashes due to reading beyond the end of the data actually
-   received.
-
-   Since UDP packets larger than 512 octets are now expected in normal
-   operation, proxies SHOULD NOT truncate UDP packets that exceed that
-   size.  See Section 4.4.3 for recommendations for packet sizes
-   exceeding the WAN MTU.
-
-   If a proxy must unilaterally truncate a response, then the proxy MUST
-   set the TC bit.  Similarly, proxies MUST NOT remove the TC bit from
-   responses.
-
-4.4.1.  TCP Transport
-
-   Should a UDP query fail because of truncation, the standard fail-over
-   mechanism is to retry the query using TCP, as described in Section
-   6.1.3.2 of [RFC1123].
-
-   Whilst TCP transport is not strictly mandatory, it is supported by
-   the vast majority of stub resolvers and recursive servers.  Lack of
-   support in the proxy prevents this fail-over mechanism from working.
-
-   DNS proxies MUST therefore be prepared to receive and forward queries
-   over TCP.
-
-   Note that it is unlikely that a client would send a request over TCP
-   unless it had already received a truncated UDP response.  Some
-   "smart" proxies have been observed to first forward any request
-   received over TCP to an upstream resolver over UDP, only for the
-   response to be truncated, causing the proxy to retry over TCP.  Such
-   behaviour increases network traffic and causes delay in DNS
-   resolution since the initial UDP request is doomed to fail.
-
-
-
-
-
-Bellis                   Best Current Practice                  [Page 5]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   Therefore, whenever a proxy receives a request over TCP, the proxy
-   SHOULD forward the query over TCP and SHOULD NOT attempt the same
-   query over UDP first.
-
-4.4.2.  Extension Mechanisms for DNS (EDNS0)
-
-   The "Extension Mechanism for DNS" [RFC2671] was introduced to allow
-   the transport of larger DNS packets over UDP and also to allow for
-   additional request and response flags.
-
-   A client may send an OPT Resource Record (OPT RR) in the Additional
-   Section of a request to indicate that it supports a specific receive
-   buffer size.  The OPT RR also includes the "DNSSEC OK" (DO) flag used
-   by DNSSEC to indicate that DNSSEC-related RRs should be returned to
-   the client.
-
-   However, some proxies have been observed to either reject (with a
-   FORMERR response code) or black-hole any packet containing an OPT RR.
-   As per Section 4.1, proxies MUST NOT refuse to proxy such packets.
-
-4.4.3.  IP Fragmentation
-
-   Support for UDP packet sizes exceeding the WAN MTU depends on the
-   gateway's algorithm for handling fragmented IP packets.  Several
-   methods are possible:
-
-   1.  Fragments are dropped.
-
-   2.  Fragments are forwarded individually as they're received.
-
-   3.  Complete packets are reassembled on the gateway and then re-
-       fragmented (if necessary) as they're forwarded to the client.
-
-   Method 1 above will cause compatibility problems with EDNS0 unless
-   the DNS client is configured to advertise an EDNS0 buffer size
-   limited to the WAN MTU less the size of the IP header.  Note that RFC
-   2671 does recommend that the path MTU should be taken into account
-   when using EDNS0.
-
-   Also, whilst the EDNS0 specification allows for a buffer size of up
-   to 65535 octets, most common DNS server implementations do not
-   support a buffer size above 4096 octets.
-
-   Therefore (irrespective of which of the above methods is in use),
-   proxies SHOULD be capable of forwarding UDP packets up to a payload
-   size of at least 4096 octets.
-
-
-
-
-
-Bellis                   Best Current Practice                  [Page 6]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   NB: in theory, IP fragmentation may also occur if the LAN MTU is
-   smaller than the WAN MTU, although the author has not observed such a
-   configuration in use on any residential broadband service.
-
-4.5.  Secret Key Transaction Authentication for DNS (TSIG)
-
-   [RFC2845] defines TSIG, which is a mechanism for authenticating DNS
-   requests and responses at the packet level.
-
-   Any modifications made to the DNS portions of a TSIG-signed query or
-   response packet (with the exception of the Query ID) will cause a
-   TSIG authentication failure.
-
-   DNS proxies MUST implement Section 4.7 of [RFC2845] and either
-   forward packets unchanged (as recommended above) or fully implement
-   TSIG.
-
-   As per Section 4.3, DNS proxies MUST be capable of proxying packets
-   containing TKEY [RFC2930] Resource Records.
-
-   NB: any DNS proxy (such as those commonly found in WiFi hotspot
-   "walled gardens") that transparently intercepts all DNS queries and
-   that returns unsigned responses to signed queries, will also cause
-   TSIG authentication failures.
-
-5.  DHCP's Interaction with DNS
-
-   Whilst this document is primarily about DNS proxies, most consumers
-   rely on DHCP [RFC2131] to obtain network configuration settings.
-   Such settings include the client machine's IP address, subnet mask,
-   and default gateway, but also include DNS-related settings.
-
-   It is therefore appropriate to examine how DHCP affects client DNS
-   configuration.
-
-5.1.  Domain Name Server (DHCP Option 6)
-
-   Most gateways default to supplying their own IP address in the DHCP
-   "Domain Name Server" option [RFC2132].  The net result is that
-   without explicit re-configuration many DNS clients will, by default,
-   send queries to the gateway's DNS proxy.  This is understandable
-   behaviour given that the correct upstream settings are not usually
-   known at boot time.
-
-
-
-
-
-
-
-
-Bellis                   Best Current Practice                  [Page 7]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   Most gateways learn their own DNS settings via values supplied by an
-   ISP via DHCP or PPP over the WAN interface.  However, whilst many
-   gateways do allow the device administrator to override those values,
-   some gateways only use those supplied values to affect the proxy's
-   own forwarding function, and do not offer these values via DHCP.
-
-   When using such a device, the only way to avoid using the DNS proxy
-   is to hard-code the required values in the client operating system.
-   This may be acceptable for a desktop system but it is inappropriate
-   for mobile devices that are regularly used on many different
-   networks.
-
-   As per Section 3, end-users SHOULD be able to send their DNS queries
-   directly to specified upstream resolvers, ideally without hard-coding
-   those settings in their stub resolver.
-
-   It is therefore RECOMMENDED that gateways SHOULD support device-
-   administrator configuration of values for the "Domain Name Server"
-   DHCP option.
-
-5.2.  Domain Name (DHCP Option 15)
-
-   A significant amount of traffic to the DNS Root Name Servers is for
-   invalid top-level domain names, and some of that traffic can be
-   attributed to particular equipment vendors whose firmware defaults
-   this DHCP option to specific values.
-
-   Since no standard exists for a "local" scoped domain name suffix, it
-   is RECOMMENDED that the default value for this option SHOULD be
-   empty, and that this option MUST NOT be sent to clients when no value
-   is configured.
-
-5.3.  DHCP Leases
-
-   It is noted that some DHCP servers in broadband gateways offer, by
-   default, their own IP address for the "Domain Name Server" option (as
-   described above) but then automatically start offering the upstream
-   servers' addresses once they've been learnt over the WAN interface.
-
-   In general, this behaviour is highly desirable, but the effect for
-   the end-user is that the settings used depend on whether the DHCP
-   lease was obtained before or after the WAN link was established.
-
-   If the DHCP lease is obtained whilst the WAN link is down, then the
-   DHCP client (and hence the DNS client) will not receive the correct
-   values until the DHCP lease is renewed.
-
-
-
-
-
-Bellis                   Best Current Practice                  [Page 8]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   Whilst no specific recommendations are given here, vendors may wish
-   to give consideration to the length of DHCP leases and to whether
-   some mechanism for forcing a DHCP lease renewal might be appropriate.
-
-   Another possibility is that the learnt upstream values might be
-   persisted in non-volatile memory such that on reboot the same values
-   can be automatically offered via DHCP.  However, this does run the
-   risk that incorrect values are initially offered if the device is
-   moved or connected to another ISP.
-
-   Alternatively, the DHCP server might only issue very short (i.e., 60
-   second) leases while the WAN link is down, only reverting to more
-   typical lease lengths once the WAN link is up and the upstream DNS
-   servers are known.  Indeed, with such a configuration it may be
-   possible to avoid the need to implement a DNS proxy function in the
-   broadband gateway at all.
-
-6.  Security Considerations
-
-   This document introduces no new protocols.  However, there are some
-   security-related recommendations for vendors that are listed here.
-
-6.1.  Forgery Resilience
-
-   Whilst DNS proxies are not usually full-feature resolvers, they
-   nevertheless share some characteristics with them.
-
-   Notwithstanding the recommendations above about transparency, many
-   DNS proxies are observed to pick a new Query ID for outbound requests
-   to ensure that responses are directed to the correct client.
-
-   NB: changing the Query ID is acceptable and compatible with proxying
-   TSIG-signed packets since the TSIG signature calculation is based on
-   the original message ID, which is carried in the TSIG RR.
-
-   It has been standard guidance for many years that each DNS query
-   should use a randomly generated Query ID.  However, many proxies have
-   been observed picking sequential Query IDs for successive requests.
-
-   It is strongly RECOMMENDED that DNS proxies follow the relevant
-   recommendations in [RFC5452], particularly those in Section 9.2
-   relating to randomisation of Query IDs and source ports.  This also
-   applies to source port selection within any NAT function.
-
-   If a DNS proxy is running on a broadband gateway with NAT that is
-   compliant with [RFC4787], then it SHOULD also follow the
-   recommendations in Section 10 of [RFC5452] concerning how long DNS
-   state is kept.
-
-
-
-Bellis                   Best Current Practice                  [Page 9]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-6.2.  Interface Binding
-
-   Some gateways have been observed to have their DNS proxy listening on
-   both internal (LAN) and external (WAN) interfaces.  In this
-   configuration, it is possible for the proxy to be used to mount
-   reflector attacks as described in [RFC5358].
-
-   The DNS proxy in a gateway SHOULD NOT, by default, be accessible from
-   the WAN interfaces of the device.
-
-6.3.  Packet Filtering
-
-   The Transparency and Robustness Principles are not entirely
-   compatible with the deep packet-inspection features of security
-   appliances such as firewalls, which are intended to protect systems
-   on the inside of a network from rogue traffic.
-
-   However, a clear distinction may be made between traffic that is
-   intrinsically malformed and that which merely contains unexpected
-   data.
-
-   Examples of malformed packets that MAY be dropped include:
-
-   o  invalid compression pointers (i.e., those that point outside of
-      the current packet or that might cause a parsing loop)
-
-   o  incorrect counts for the Question, Answer, Authority, and
-      Additional Sections (although care should be taken where
-      truncation is a possibility)
-
-   Dropped packets will cause the client to repeatedly retransmit the
-   original request, with the client only detecting the error after
-   several retransmit intervals.
-
-   In these circumstances, proxies SHOULD synthesise a suitable DNS
-   error response to the client (i.e., SERVFAIL) instead of dropping the
-   packet completely.  This will allow the client to detect the error
-   immediately.
-
-7.  Acknowledgements
-
-   The author would particularly like to acknowledge the assistance of
-   Lisa Phifer of Core Competence.  In addition, the author is grateful
-   for the feedback from the members of the DNSEXT Working Group.
-
-
-
-
-
-
-
-Bellis                   Best Current Practice                 [Page 10]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
-              RFC 793, September 1981.
-
-   [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.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
-              RFC 2131, March 1997.
-
-   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
-              Extensions", RFC 2132, March 1997.
-
-   [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.
-
-   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
-              RR)", RFC 2930, September 2000.
-
-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
-              (RR) Types", RFC 3597, September 2003.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
-              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
-              RFC 4787, January 2007.
-
-   [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive
-              Nameservers in Reflector Attacks", BCP 140, RFC 5358,
-              October 2008.
-
-
-
-
-
-Bellis                   Best Current Practice                 [Page 11]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   [RFC5452]  Hubert, A. and R. van Mook, "Measures for Making DNS More
-              Resilient against Forged Answers", RFC 5452, January 2009.
-
-8.2.  Informative References
-
-   [DOTSE]    Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
-              Routers", February 2008,
-              <http://www.iis.se/docs/Routertester_en.pdf>.
-
-   [SAC035]   Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
-              Broadband Routers and Firewalls", September 2008,
-              <http://www.icann.org/committees/security/sac035.pdf>.
-
-Author's Address
-
-   Ray Bellis
-   Nominet UK
-   Edmund Halley Road
-   Oxford  OX4 4DQ
-   United Kingdom
-
-   Phone: +44 1865 332211
-   EMail: ray.bellis@nominet.org.uk
-   URI:   http://www.nominet.org.uk/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bellis                   Best Current Practice                 [Page 12]
-
diff --git a/doc/rfc/rfc5702.txt b/doc/rfc/rfc5702.txt
deleted file mode 100644
index 5155cc64..00000000
--- a/doc/rfc/rfc5702.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          J. Jansen
-Request for Comments: 5702                                    NLnet Labs
-Category: Standards Track                                   October 2009
-
-
-                  Use of SHA-2 Algorithms with RSA in
-              DNSKEY and RRSIG Resource Records for DNSSEC
-
-Abstract
-
-   This document describes how to produce RSA/SHA-256 and RSA/SHA-512
-   DNSKEY and RRSIG resource records for use in the Domain Name System
-   Security Extensions (RFC 4033, RFC 4034, and RFC 4035).
-
-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) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 1]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. DNSKEY Resource Records .........................................3
-      2.1. RSA/SHA-256 DNSKEY Resource Records ........................3
-      2.2. RSA/SHA-512 DNSKEY Resource Records ........................3
-   3. RRSIG Resource Records ..........................................3
-      3.1. RSA/SHA-256 RRSIG Resource Records .........................4
-      3.2. RSA/SHA-512 RRSIG Resource Records .........................4
-   4. Deployment Considerations .......................................5
-      4.1. Key Sizes ..................................................5
-      4.2. Signature Sizes ............................................5
-   5. Implementation Considerations ...................................5
-      5.1. Support for SHA-2 Signatures ...............................5
-      5.2. Support for NSEC3 Denial of Existence ......................5
-   6. Examples ........................................................6
-      6.1. RSA/SHA-256 Key and Signature ..............................6
-      6.2. RSA/SHA-512 Key and Signature ..............................7
-   7. IANA Considerations .............................................8
-   8. Security Considerations .........................................8
-      8.1. SHA-1 versus SHA-2 Considerations for RRSIG
-           Resource Records ...........................................8
-      8.2. Signature Type Downgrade Attacks ...........................8
-   9. Acknowledgments .................................................9
-   10. References .....................................................9
-      10.1. Normative References ......................................9
-      10.2. Informative References ....................................9
-
-1.  Introduction
-
-   The Domain Name System (DNS) is the global, hierarchical distributed
-   database for Internet Naming.  The DNS has been extended to use
-   cryptographic keys and digital signatures for the verification of the
-   authenticity and integrity of its data.  [RFC4033], [RFC4034], and
-   [RFC4035] describe these DNS Security Extensions, called DNSSEC.
-
-   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
-   and specifies a list of cryptographic algorithms to use.  This
-   document extends that list with the algorithms RSA/SHA-256 and RSA/
-   SHA-512, and specifies how to store DNSKEY data and how to produce
-   RRSIG resource records with these hash algorithms.
-
-   Familiarity with DNSSEC, RSA, and the SHA-2 [FIPS.180-3.2008] family
-   of algorithms is assumed in this document.
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 2]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-   To refer to both SHA-256 and SHA-512, this document will use the name
-   SHA-2.  This is done to improve readability.  When a part of text is
-   specific for either SHA-256 or SHA-512, their specific names are
-   used.  The same goes for RSA/SHA-256 and RSA/SHA-512, which will be
-   grouped using the name RSA/SHA-2.
-
-   The term "SHA-2" is not officially defined but is usually used to
-   refer to the collection of the algorithms SHA-224, SHA-256, SHA-384,
-   and SHA-512.  Since SHA-224 and SHA-384 are not used in DNSSEC, SHA-2
-   will only refer to SHA-256 and SHA-512 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].
-
-2.  DNSKEY Resource Records
-
-   The format of the DNSKEY RR can be found in [RFC4034].  [RFC3110]
-   describes the use of RSA/SHA-1 for DNSSEC signatures.
-
-2.1.  RSA/SHA-256 DNSKEY Resource Records
-
-   RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
-   resource records (RRs) with the algorithm number 8.
-
-   For interoperability, as in [RFC3110], the key size of RSA/SHA-256
-   keys MUST NOT be less than 512 bits and MUST NOT be more than 4096
-   bits.
-
-2.2.  RSA/SHA-512 DNSKEY Resource Records
-
-   RSA public keys for use with RSA/SHA-512 are stored in DNSKEY
-   resource records (RRs) with the algorithm number 10.
-
-   The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits and
-   MUST NOT be more than 4096 bits.
-
-3.  RRSIG Resource Records
-
-   The value of the signature field in the RRSIG RR follows the RSASSA-
-   PKCS1-v1_5 signature scheme and is calculated as follows.  The values
-   for the RDATA fields that precede the signature data are specified in
-   [RFC4034].
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 3]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-   hash = SHA-XXX(data)
-
-   Here XXX is either 256 or 512, depending on the algorithm used, as
-   specified in FIPS PUB 180-3; "data" is the wire format data of the
-   resource record set that is signed, as specified in [RFC4034].
-
-   signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
-   Here "|" is concatenation; "00", "01", "FF", and "00" are fixed
-   octets of corresponding hexadecimal value; "e" is the private
-   exponent of the signing RSA key; and "n" is the public modulus of the
-   signing key.  The FF octet MUST be repeated the exact number of times
-   so that the total length of the concatenated term in parentheses
-   equals the length of the modulus of the signer's public key ("n").
-
-   The "prefix" is intended to make the use of standard cryptographic
-   libraries easier.  These specifications are taken directly from the
-   specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 (Section 8.2 of
-   [RFC3447]), and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 (Section 9.2
-   of [RFC3447]).  The prefixes for the different algorithms are
-   specified below.
-
-3.1.  RSA/SHA-256 RRSIG Resource Records
-
-   RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
-   records (RRs) with algorithm number 8.
-
-   The prefix is the ASN.1 DER SHA-256 algorithm designator prefix, as
-   specified in PKCS #1 v2.1 [RFC3447]:
-
-   hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
-
-3.2.  RSA/SHA-512 RRSIG Resource Records
-
-   RSA/SHA-512 signatures are stored in the DNS using RRSIG resource
-   records (RRs) with algorithm number 10.
-
-   The prefix is the ASN.1 DER SHA-512 algorithm designator prefix, as
-   specified in PKCS #1 v2.1 [RFC3447]:
-
-   hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40
-
-
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 4]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-4.  Deployment Considerations
-
-4.1.  Key Sizes
-
-   Apart from the restrictions in Section 2, this document will not
-   specify what size of keys to use.  That is an operational issue and
-   depends largely on the environment and intended use.  A good starting
-   point for more information would be NIST SP 800-57 [NIST800-57].
-
-4.2.  Signature Sizes
-
-   In this family of signing algorithms, the size of signatures is
-   related to the size of the key and not to the hashing algorithm used
-   in the signing process.  Therefore, RRSIG resource records produced
-   with RSA/SHA-256 or RSA/SHA-512 will have the same size as those
-   produced with RSA/SHA-1, if the keys have the same length.
-
-5.  Implementation Considerations
-
-5.1.  Support for SHA-2 Signatures
-
-   DNSSEC-aware implementations SHOULD be able to support RRSIG and
-   DNSKEY resource records created with the RSA/SHA-2 algorithms as
-   defined in this document.
-
-5.2.  Support for NSEC3 Denial of Existence
-
-   [RFC5155] defines new algorithm identifiers for existing signing
-   algorithms, to indicate that zones signed with these algorithm
-   identifiers can use NSEC3 as well as NSEC records to provide denial
-   of existence.  That mechanism was chosen to protect implementations
-   predating RFC 5155 from encountering resource records about which
-   they could not know.  This document does not define such algorithm
-   aliases.
-
-   A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate
-   negative answers in the form of both NSEC and NSEC3 with hash
-   algorithm 1, as defined in [RFC5155].  An authoritative server that
-   does not implement NSEC3 MAY still serve zones that use RSA/SHA-2
-   with NSEC denial of existence.
-
-
-
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 5]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-6.  Examples
-
-6.1.  RSA/SHA-256 Key and Signature
-
-   Given a private key with the following values (in Base64):
-
-   Private-key-format: v1.2
-   Algorithm:       8 (RSASHA256)
-   Modulus:         wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm
-                    idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q==
-   PublicExponent:  AQAB
-   PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN+i/
-                    HAam+97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ==
-   Prime1:          4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk=
-   Prime2:          2zZpBE8ZXVnL74QjG4zINlDfH+EOEtjJJ3RtaYDugvE=
-   Exponent1:       G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk=
-   Exponent2:       GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE=
-   Coefficient:     icQdNRjlZGPmuJm2TIadubcO8X7V4y07aVhX464tx8Q=
-
-   The DNSKEY record for this key would be:
-
-   example.net.     3600  IN  DNSKEY  (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI
-                    my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P
-                    kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b}
-
-   With this key, sign the following RRSet, consisting of 1 A record:
-
-   www.example.net. 3600  IN  A  192.0.2.91
-
-   If the inception date is set at 00:00 hours on January 1st, 2000, and
-   the expiration date at 00:00 hours on January 1st, 2030, the
-   following signature should be created:
-
- www.example.net. 3600  IN  RRSIG  (A 8 3 3600 20300101000000
-                     20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9
-                     l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa
-                     cFYK/lPtPiVYP4bwg==);{id = 9033}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 6]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-6.2.  RSA/SHA-512 Key and Signature
-
-   Given a private key with the following values (in Base64):
-
-   Private-key-format: v1.2
-   Algorithm:       10 (RSASHA512)
-   Modulus:         0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf
-                    Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk
-                    8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V
-                    jXZlNKdyit99waaE4s=
-   PublicExponent:  AQAB
-   PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6
-                    AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj
-                    yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3
-                    SEIAsrB043XzGrKIVE=
-   Prime1:          8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x
-                    nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ==
-   Prime2:          3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK
-                    Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw==
-   Exponent1:       v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM
-                    MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q==
-   Exponent2:       m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J
-                    PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w==
-   Coefficient:     Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q
-                    /Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ==
-
-   The DNSKEY record for this key would be:
-
-   example.net.    3600  IN  DNSKEY  (256 3 10 AwEAAdHoNTOW+et86KuJOWRD
-                   p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD
-                   xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g
-                   pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL
-                   );{id = 3740 (zsk), size = 1024b}
-
-   With this key, sign the following RRSet, consisting of 1 A record:
-
-   www.example.net. 3600  IN  A  192.0.2.91
-
-   If the inception date is set at 00:00 hours on January 1st, 2000, and
-   the expiration date at 00:00 hours on January 1st, 2030, the
-   following signature should be created:
-
-   www.example.net. 3600  IN  RRSIG  (A 10 3 3600 20300101000000
-                    20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t
-                    6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa
-                    eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL
-                    DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw
-                    =);{id = 3740}
-
-
-
-Jansen                      Standards Track                     [Page 7]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-7.  IANA Considerations
-
-   This document updates the IANA registry "DNS SECURITY ALGORITHM
-   NUMBERS -- per [RFC4035]" (http://www.iana.org/protocols).  The
-   following entries are added to the registry:
-
-                                             Zone  Trans.
-   Value   Description       Mnemonic    Signing    Sec.   References
-     8     RSA/SHA-256      RSASHA256          Y      *    RFC 5702
-    10     RSA/SHA-512      RSASHA512          Y      *    RFC 5702
-
-   * There has been no determination of standardization of the use of
-     this algorithm with Transaction Security.
-
-8.  Security Considerations
-
-8.1.  SHA-1 versus SHA-2 Considerations for RRSIG Resource Records
-
-   Users of DNSSEC are encouraged to deploy SHA-2 as soon as software
-   implementations allow for it.  SHA-2 is widely believed to be more
-   resilient to attack than SHA-1, and confidence in SHA-1's strength is
-   being eroded by recently announced attacks.  Regardless of whether or
-   not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
-   time of this writing) that SHA-2 is the better choice for use in
-   DNSSEC records.
-
-   SHA-2 is considered sufficiently strong for the immediate future, but
-   predictions about future development in cryptography and
-   cryptanalysis are beyond the scope of this document.
-
-   The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one
-   used for RSA/SHA-1 signatures.  This should ease implementation of
-   the new hashing algorithms in DNSSEC software.
-
-8.2.  Signature Type Downgrade Attacks
-
-   Since each RRSet MUST be signed with each algorithm present in the
-   DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a
-   malicious party cannot filter out the RSA/SHA-2 RRSIG and force the
-   validator to use the RSA/SHA-1 signature if both are present in the
-   zone.  This should provide resilience against algorithm downgrade
-   attacks, if the validator supports RSA/SHA-2.
-
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 8]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-9.  Acknowledgments
-
-   This document is a minor extension to [RFC4034].  Also, we try to
-   follow the documents [RFC3110] and [RFC4509] for consistency.  The
-   authors of and contributors to these documents are gratefully
-   acknowledged for their hard work.
-
-   The following people provided additional feedback and text: Jaap
-   Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont,
-   Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Scott Rose,
-   Michael St. Johns, and Wouter Wijngaards.
-
-10.  References
-
-10.1.  Normative References
-
-   [FIPS.180-3.2008]
-              National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS PUB 180-3, October 2008.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3110]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-              Name System (DNS)", RFC 3110, May 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 the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-10.2.  Informative References
-
-   [NIST800-57]
-              Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
-              "Recommendations for Key Management", NIST SP 800-57,
-              March 2007.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-
-
-Jansen                      Standards Track                     [Page 9]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
-              (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-              Security (DNSSEC) Hashed Authenticated Denial of
-              Existence", RFC 5155, March 2008.
-
-Author's Address
-
-   Jelte Jansen
-   NLnet Labs
-   Science Park 140
-   1098 XG Amsterdam
-   NL
-
-   EMail: jelte@NLnetLabs.nl
-   URI:   http://www.nlnetlabs.nl/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                    [Page 10]
-
diff --git a/doc/rfc/rfc5933.txt b/doc/rfc/rfc5933.txt
deleted file mode 100644
index 77bd2328..00000000
--- a/doc/rfc/rfc5933.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Internet Engineering Task Force (IETF)                  V. Dolmatov, Ed.
-Request for Comments: 5933                                   A. Chuprina
-Category: Standards Track                                     I. Ustinov
-ISSN: 2070-1721                                           Cryptocom Ltd.
-                                                               July 2010
-
-
-               Use of GOST Signature Algorithms in DNSKEY
-                 and RRSIG Resource Records for DNSSEC
-
-Abstract
-
-   This document describes how to produce digital signatures and hash
-   functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms
-   for DNSKEY, RRSIG, and DS resource records, for use in the Domain
-   Name System Security Extensions (DNSSEC).
-
-Status of This Memo
-
-   This is an Internet Standards Track document.
-
-   This document is a product of the Internet Engineering Task Force
-   (IETF).  It represents the consensus of the IETF community.  It has
-   received public review and has been approved for publication by the
-   Internet Engineering Steering Group (IESG).  Further information on
-   Internet Standards is available in Section 2 of RFC 5741.
-
-   Information about the current status of this document, any errata,
-   and how to provide feedback on it may be obtained at
-   http://www.rfc-editor.org/info/rfc5933.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 1]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
-     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
-     2.1.  Using a Public Key with Existing Cryptographic
-           Libraries . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     2.2.  GOST DNSKEY RR Example  . . . . . . . . . . . . . . . . . . 4
-   3.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . . . 4
-     3.1.  RRSIG RR Example  . . . . . . . . . . . . . . . . . . . . . 5
-   4.  DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
-     4.1.  DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 5
-   5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 6
-     5.1.  Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     5.2.  Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 6
-     5.3.  Digest Sizes  . . . . . . . . . . . . . . . . . . . . . . . 6
-   6.  Implementation Considerations . . . . . . . . . . . . . . . . . 6
-     6.1.  Support for GOST Signatures . . . . . . . . . . . . . . . . 6
-     6.2.  Support for NSEC3 Denial of Existence . . . . . . . . . . . 6
-   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
-   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
-   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
-     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8
-
-1.  Introduction
-
-   The Domain Name System (DNS) is the global hierarchical distributed
-   database for Internet Naming.  The DNS has been extended to use
-   cryptographic keys and digital signatures for the verification of the
-   authenticity and integrity of its data.  RFC 4033 [RFC4033], RFC 4034
-   [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
-   Extensions, called DNSSEC.
-
-   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
-   and specifies a list of cryptographic algorithms to use.  This
-   document extends that list with the signature and hash algorithms
-   GOST R 34.10-2001 ([GOST3410], [RFC5832]) and GOST R 34.11-94
-   ([GOST3411], [RFC5831]), and specifies how to store DNSKEY data and
-   how to produce RRSIG resource records with these algorithms.
-
-   Familiarity with DNSSEC and with GOST signature and hash algorithms
-   is assumed in this document.
-
-   The term "GOST" is not officially defined, but is usually used to
-   refer to the collection of the Russian cryptographic algorithms
-   GOST R 34.10-2001 [RFC5832], GOST R 34.11-94 [RFC5831], and
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 2]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-   GOST 28147-89 [RFC5830].  Since GOST 28147-89 is not used in DNSSEC,
-   "GOST" will only refer to GOST R 34.10-2001 and GOST R 34.11-94 in
-   this document.
-
-1.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].
-
-2.  DNSKEY Resource Records
-
-   The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
-
-   GOST R 34.10-2001 public keys are stored with the algorithm
-   number 12.
-
-   The wire format of the public key is compatible with RFC 4491
-   [RFC4491]:
-
-   According to [GOST3410] and [RFC5832], a public key is a point on the
-   elliptic curve Q = (x,y).
-
-   The wire representation of a public key MUST contain 64 octets, where
-   the first 32 octets contain the little-endian representation of x and
-   the second 32 octets contain the little-endian representation of y.
-
-   Corresponding public key parameters are those identified by
-   id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
-   and the digest parameters are those identified by
-   id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
-
-2.1.  Using a Public Key with Existing Cryptographic Libraries
-
-   At the time of this writing, existing GOST-aware cryptographic
-   libraries are capable of reading GOST public keys via a generic X509
-   API if the key is encoded according to RFC 4491 [RFC4491],
-   Section 2.3.2.
-
-   To make this encoding from the wire format of a GOST public key with
-   the parameters used in this document, prepend the 64 octets of key
-   data with the following 37-byte sequence:
-
-      0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30
-      0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
-      0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 3]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-2.2.  GOST DNSKEY RR Example
-
-   Given a private key with the following value (the value of the
-   GostAsn1 field is split here into two lines to simplify reading; in
-   the private key file, it must be in one line):
-
-      Private-key-format: v1.2
-      Algorithm: 12 (ECC-GOST)
-      GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQg/9M
-                iXtXKg9FDXDN/R9CmVhJDyuzRAIgh4tPwCu4NHIs=
-
-   The following DNSKEY RR stores a DNS zone key for example.net:
-
-      example.net. 86400 IN DNSKEY 256 3 12 (
-                                   aRS/DcPWGQj2wVJydT8EcAVoC0kXn5pDVm2I
-                                   MvDDPXeD32dsSKcmq8KNVzigjL4OXZTV+t/6
-                                   w4X1gpNrZiC01g==
-                                   ) ; key id = 59732
-
-3.  RRSIG Resource Records
-
-   The value of the signature field in the RRSIG RR follows RFC 4490
-   [RFC4490] and is calculated as follows.  The values for the RDATA
-   fields that precede the signature data are specified in RFC 4034
-   [RFC4034].
-
-   hash = GOSTR3411(data)
-
-   where "data" is the wire format data of the resource record set that
-   is signed, as specified in RFC 4034 [RFC4034].
-
-   The hash MUST be calculated with GOST R 34.11-94 parameters
-   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-   The signature is calculated from the hash according to the
-   GOST R 34.10-2001 standard, and its wire format is compatible with
-   RFC 4490 [RFC4490].
-
-   Quoting RFC 4490:
-
-   "The signature algorithm GOST R 34.10-2001 generates a digital
-   signature in the form of two 256-bit numbers, r and s.  Its octet
-   string representation consists of 64 octets, where the first
-   32 octets contain the big-endian representation of s and the second
-   32 octets contain the big-endian representation of r".
-
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 4]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-3.1.  RRSIG RR Example
-
-   With the private key from Section 2.2, sign the following RRSet,
-   consisting of one A record:
-
-      www.example.net. 3600 IN A 192.0.2.1
-
-   Setting the inception date to 2000-01-01 00:00:00 UTC and the
-   expiration date to 2030-01-01 00:00:00 UTC, the following signature
-   RR will be valid:
-
-     www.example.net. 3600 IN RRSIG A 12 3 3600 20300101000000 (
-                                    20000101000000 59732 example.net.
-                                    7vzzz6iLOmvtjs5FjVjSHT8XnRKFY15ki6Kp
-                                    kNPkUnS8iIns0Kv4APT+D9ibmHhGri6Sfbyy
-                                    zi67+wBbbW/jrA== )
-
-   Note: The ECC-GOST signature algorithm uses random data, so the
-   actual computed signature value will differ between signature
-   calculations.
-
-4.  DS Resource Records
-
-   The GOST R 34.11-94 digest algorithm is denoted in DS RRs by the
-   digest type 3.  The wire format of a digest value is compatible with
-   RFC 4490 [RFC4490], that is, the digest is in little-endian
-   representation.
-
-   The digest MUST always be calculated with GOST R 34.11-94 parameters
-   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-4.1.  DS RR Example
-
-   For Key Signing Key (KSK):
-
-      example.net. 86400   DNSKEY  257 3 12 (
-                                   LMgXRHzSbIJGn6i16K+sDjaDf/k1o9DbxScO
-                                   gEYqYS/rlh2Mf+BRAY3QHPbwoPh2fkDKBroF
-                                   SRGR7ZYcx+YIQw==
-                                   ) ; key id = 40692
-
-   The DS RR will be
-
-      example.net. 3600 IN DS 40692 12 3 (
-                22261A8B0E0D799183E35E24E2AD6BB58533CBA7E3B14D659E9CA09B
-                2071398F )
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 5]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-5.  Deployment Considerations
-
-5.1.  Key Sizes
-
-   According to RFC 4357 [RFC4357], the key size of GOST public keys
-   MUST be 512 bits.
-
-5.2.  Signature Sizes
-
-   According to the GOST R 34.10-2001 digital signature algorithm
-   specification ([GOST3410], [RFC5832]), the size of a GOST signature
-   is 512 bits.
-
-5.3.  Digest Sizes
-
-   According to GOST R 34.11-94 ([GOST3411], [RFC5831]), the size of a
-   GOST digest is 256 bits.
-
-6.  Implementation Considerations
-
-6.1.  Support for GOST Signatures
-
-   DNSSEC-aware implementations MAY be able to support RRSIG and DNSKEY
-   resource records created with the GOST algorithms as defined in this
-   document.
-
-6.2.  Support for NSEC3 Denial of Existence
-
-   Any DNSSEC-GOST implementation MUST support both NSEC [RFC4035] and
-   NSEC3 [RFC5155].
-
-7.  Security Considerations
-
-   Currently, the cryptographic resistance of the GOST R 34.10-2001
-   digital signature algorithm is estimated as 2**128 operations of
-   multiple elliptic curve point computations on prime modulus of order
-   2**256.
-
-   Currently, the cryptographic resistance of the GOST R 34.11-94 hash
-   algorithm is estimated as 2**128 operations of computations of a step
-   hash function.  (There is a known method to reduce this estimate to
-   2**105 operations, but it demands padding the colliding message with
-   1024 random bit blocks each of 256-bit length; thus, it cannot be
-   used in any practical implementation).
-
-
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 6]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-8.  IANA Considerations
-
-   This document updates the IANA registry "DNS Security Algorithm
-   Numbers" [RFC4034].  The following entries have been added to the
-   registry:
-
-                                      Zone    Trans.
-    Value  Algorithm         Mnemonic Signing Sec.  References   Status
-     12    GOST R 34.10-2001 ECC-GOST     Y   *     RFC 5933    OPTIONAL
-
-   This document updates the RFC 4034 Digest Types assignment
-   ([RFC4034], Section A.2) by adding the value and status for the
-   GOST R 34.11-94 algorithm:
-
-      Value   Algorithm        Status
-        3    GOST R 34.11-94  OPTIONAL
-
-9.  Acknowledgments
-
-   This document is a minor extension to RFC 4034 [RFC4034].  Also, we
-   tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
-   and RFC 4357 [RFC4357] for consistency.  The authors of and
-   contributors to these documents are gratefully acknowledged for their
-   hard work.
-
-   The following people provided additional feedback, text, and valuable
-   assistance: Dmitry Burkov, Jaap Akkerhuis, Olafur Gundmundsson,
-   Jelte Jansen, and Wouter Wijngaards.
-
-10.  References
-
-10.1.  Normative References
-
-   [GOST3410]  "Information technology.  Cryptographic data security.
-               Signature and verification processes of [electronic]
-               digital signature.", GOST R 34.10-2001, Gosudarstvennyi
-               Standard of Russian Federation, Government Committee of
-               Russia for Standards, 2001. (In Russian).
-
-   [GOST3411]  "Information technology.  Cryptographic data security.
-               Hashing function.", GOST R 34.11-94, Gosudarstvennyi
-               Standard of Russian Federation, Government Committee of
-               Russia for Standards, 1994. (In Russian).
-
-   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 7]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-   [RFC3110]   Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
-               Domain Name System (DNS)", RFC 3110, May 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 the DNS Security Extensions",
-               RFC 4034, March 2005.
-
-   [RFC4035]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
-               Rose, "Protocol Modifications for the DNS Security
-               Extensions", RFC 4035, March 2005.
-
-   [RFC4357]   Popov, V., Kurepkin, I., and S. Leontiev, "Additional
-               Cryptographic Algorithms for Use with GOST 28147-89,
-               GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
-               Algorithms", RFC 4357, January 2006.
-
-   [RFC4490]   Leontiev, S., Ed. and G. Chudov, Ed., "Using the
-               GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and
-               GOST R 34.10-2001 Algorithms with Cryptographic Message
-               Syntax (CMS)", RFC 4490, May 2006.
-
-   [RFC4491]   Leontiev, S., Ed. and D. Shefanovski, Ed., "Using the
-               GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
-               Algorithms with the Internet X.509 Public Key
-               Infrastructure Certificate and CRL Profile", RFC 4491,
-               May 2006.
-
-   [RFC5155]   Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-               Security (DNSSEC) Hashed Authenticated Denial of
-               Existence", RFC 5155, March 2008.
-
-10.2.  Informative References
-
-   [RFC4509]   Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
-               (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
-   [RFC5830]   Dolmatov, V., Ed., "GOST 28147-89: Encryption,
-               Decryption, and Message Authentication Code (MAC)
-               Algorithms", RFC 5830, March 2010.
-
-   [RFC5831]   Dolmatov, V., Ed., "GOST R 34.11-94: Hash Function
-               Algorithm", RFC 5831, March 2010.
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 8]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-   [RFC5832]   Dolmatov, V., Ed., "GOST R 34.10-2001: Digital Signature
-               Algorithm", RFC 5832, March 2010.
-
-Authors' Addresses
-
-   Vasily Dolmatov (editor)
-   Cryptocom Ltd.
-   14/2, Kedrova St.
-   Moscow,   117218
-   Russian Federation
-
-   Phone: +7 499 124 6226
-   EMail: dol@cryptocom.ru
-
-
-   Artem Chuprina
-   Cryptocom Ltd.
-   14/2, Kedrova St.
-   Moscow,   117218
-   Russian Federation
-
-   Phone: +7 499 124 6226
-   EMail: ran@cryptocom.ru
-
-
-   Igor Ustinov
-   Cryptocom Ltd.
-   14/2, Kedrova St.
-   Moscow,   117218
-   Russian Federation
-
-   Phone: +7 499 124 6226
-   EMail: igus@cryptocom.ru
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 9]
-
diff --git a/doc/rfc/rfc6303.txt b/doc/rfc/rfc6303.txt
deleted file mode 100644
index b56eab96..00000000
--- a/doc/rfc/rfc6303.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Internet Engineering Task Force (IETF)                        M. Andrews
-Request for Comments: 6303                                           ISC
-BCP: 163                                                       July 2011
-Category: Best Current Practice
-ISSN: 2070-1721
-
-
-                        Locally Served DNS Zones
-
-Abstract
-
-   Experience with the Domain Name System (DNS) has shown that there are
-   a number of DNS zones that all iterative resolvers and recursive
-   nameservers should automatically serve, unless configured otherwise.
-   RFC 4193 specifies that this should occur for D.F.IP6.ARPA.  This
-   document extends the practice to cover the IN-ADDR.ARPA zones for RFC
-   1918 address space and other well-known zones with similar
-   characteristics.
-
-Status of This Memo
-
-   This memo documents an Internet Best Current Practice.
-
-   This document is a product of the Internet Engineering Task Force
-   (IETF).  It represents the consensus of the IETF community.  It has
-   received public review and has been approved for publication by the
-   Internet Engineering Steering Group (IESG).  Further information on
-   BCPs is available in Section 2 of RFC 5741.
-
-   Information about the current status of this document, any errata,
-   and how to provide feedback on it may be obtained at
-   http://www.rfc-editor.org/info/rfc6303.
-
-Copyright Notice
-
-   Copyright (c) 2011 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-
-
-Andrews                   Best Current Practice                 [Page 1]
-
-RFC 6303                Locally Served DNS Zones               July 2011
-
-
-   This document may contain material from IETF Documents or IETF
-   Contributions published or made publicly available before November
-   10, 2008.  The person(s) controlling the copyright in some of this
-   material may not have granted the IETF Trust the right to allow
-   modifications of such material outside the IETF Standards Process.
-   Without obtaining an adequate license from the person(s) controlling
-   the copyright in such materials, this document may not be modified
-   outside the IETF Standards Process, and derivative works of it may
-   not be created outside the IETF Standards Process, except to format
-   it for publication as an RFC or to translate it into languages other
-   than English.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-      1.1. Reserved Words .............................................3
-   2. Effects on Sites Using RFC 1918 Addresses .......................3
-   3. Changes to Iterative Resolver Behaviour .........................4
-   4. Lists Of Zones Covered ..........................................5
-      4.1. RFC 1918 Zones .............................................5
-      4.2. RFC 5735 and RFC 5737 Zones ................................5
-      4.3. Local IPv6 Unicast Addresses ...............................6
-      4.4. IPv6 Locally Assigned Local Addresses ......................6
-      4.5. IPv6 Link-Local Addresses ..................................7
-      4.6. IPv6 Example Prefix ........................................7
-   5. Zones That Are Out of Scope .....................................7
-   6. IANA Considerations .............................................8
-   7. Security Considerations .........................................8
-   8. Acknowledgements ................................................9
-   9. References ......................................................9
-      9.1. Normative References .......................................9
-      9.2. Informative References ....................................10
-
-1.  Introduction
-
-   Experience with the Domain Name System (DNS, [RFC1034] and [RFC1035])
-   has shown that there are a number of DNS zones that all iterative
-   resolvers and recursive nameservers SHOULD automatically serve,
-   unless intentionally configured otherwise.  These zones include, but
-   are not limited to, the IN-ADDR.ARPA zones for the address space
-   allocated by [RFC1918] and the IP6.ARPA zones for locally assigned
-   unique local IPv6 addresses defined in [RFC4193].
-
-
-
-
-
-
-
-
-
-Andrews                   Best Current Practice                 [Page 2]
-
-RFC 6303                Locally Served DNS Zones               July 2011
-
-
-   This recommendation is made because data has shown that significant
-   leakage of queries for these namespaces is occurring, despite
-   instructions to restrict them, and because it has therefore become
-   necessary to deploy sacrificial nameservers to protect the immediate
-   parent nameservers for these zones from excessive, unintentional
-   query load [AS112] [RFC6304] [RFC6305].  There is every expectation
-   that the query load will continue to increase unless steps are taken
-   as outlined here.
-
-   Additionally, queries from clients behind badly configured firewalls
-   that allow outgoing queries for these namespaces, but drop the
-   responses, put a significant load on the root servers (forward zones
-   but not reverse zones are configured).  They also cause operational
-   load for the root server operators, as they have to reply to
-   enquiries about why the root servers are "attacking" these clients.
-   Changing the default configuration will address all these issues for
-   the zones listed in Section 4.
-
-   [RFC4193] recommends that queries for D.F.IP6.ARPA be handled
-   locally.  This document extends the recommendation to cover the
-   IN-ADDR.ARPA zones for [RFC1918] and other well-known IN-ADDR.ARPA
-   and IP6.ARPA zones for which queries should not appear on the public
-   Internet.
-
-   It is hoped that by doing this the number of sacrificial servers
-   [AS112] will not have to be increased, and may in time be reduced.
-
-   This recommendation should also help DNS responsiveness for sites
-   that are using [RFC1918] addresses but do not follow the last
-   paragraph in Section 3 of [RFC1918].
-
-1.1.  Reserved Words
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Effects on Sites Using RFC 1918 Addresses
-
-   For most sites using [RFC1918] addresses, the changes here will have
-   little or no detrimental effect.  If the site does not already have
-   the reverse tree populated, the only effect will be that the name
-   error responses will be generated locally rather than remotely.
-
-   For sites that do have the reverse tree populated, most will either
-   have a local copy of the zones or will be forwarding the queries to
-   servers that have local copies of the zone.  Therefore, this
-   recommendation will not be relevant.
-
-
-
-Andrews                   Best Current Practice                 [Page 3]
-
-RFC 6303                Locally Served DNS Zones               July 2011
-
-
-   The most significant impact will be felt at sites that make use of
-   delegations for [RFC1918] addresses and have populated these zones.
-   These sites will need to override the default configuration expressed
-   in this document to allow resolution to continue.  Typically, such
-   sites will be fully disconnected from the Internet and have their own
-   root servers for their own non-Internet DNS tree.
-
-3.  Changes to Iterative Resolver Behaviour
-
-   Unless configured otherwise, an iterative resolver will now return
-   authoritatively (AA=1) name errors (RCODE=3) for queries within the
-   zones in Section 4, with the obvious exception of queries for the
-   zone name itself where SOA, NS, and "no data" responses will be
-   returned as appropriate to the query type.  One common way to do this
-   all at once is to serve empty (SOA and NS only) zones.
-
-   An implementation of this recommendation MUST provide a mechanism to
-   disable this new behaviour, and SHOULD allow this decision on a zone-
-   by-zone basis.
-
-   If using empty zones one SHOULD NOT use the same NS and SOA records
-   as used on the public Internet servers, as that will make it harder
-   to detect the origin of the responses and thus any leakage to the
-   public Internet servers.  It is RECOMMENDED that the NS record
-   defaults to the name of the zone and the SOA MNAME defaults to the
-   name of the only NS RR's (Resource Record's) target.  The SOA RNAME
-   SHOULD default to "nobody.invalid."  [RFC2606].  Implementations
-   SHOULD provide a mechanism to set these values.  No address records
-   need to be provided for the nameserver.
-
-   Below is an example of a generic empty zone in master file format.
-   It will produce a negative cache Time to Live (TTL) of 3 hours.
-
-   @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
-   @ 10800 IN NS @
-
-   The SOA RR is needed to support negative caching [RFC2308] of name
-   error responses and to point clients to the primary master for DNS
-   dynamic updates.
-
-   SOA values of particular importance are the MNAME, the SOA RR's TTL,
-   and the negTTL value.  Both TTL values SHOULD match.  The rest of the
-   SOA timer values MAY be chosen arbitrarily since they are not
-   intended to control any zone transfer activity.
-
-   The NS RR is needed as some UPDATE [RFC2136] clients use NS queries
-   to discover the zone to be updated.  Having no address records for
-   the nameserver is expected to abort UPDATE processing in the client.
-
-
-
-Andrews                   Best Current Practice                 [Page 4]
-
-RFC 6303                Locally Served DNS Zones               July 2011
-
-
-4.  Lists Of Zones Covered
-
-   The following subsections are the initial contents of the IANA
-   registry as described in the IANA Considerations section.  Following
-   the caveat in that section, the list contains only reverse zones
-   corresponding to permanently assigned address space.  The zone name
-   is the entity to be registered.
-
-4.1.  RFC 1918 Zones
-
-   The following zones correspond to the IPv4 address space reserved in
-   [RFC1918].
-
-                         +----------------------+
-                         | Zone                 |
-                         +----------------------+
-                         | 10.IN-ADDR.ARPA      |
-                         | 16.172.IN-ADDR.ARPA  |
-                         | 17.172.IN-ADDR.ARPA  |
-                         | 18.172.IN-ADDR.ARPA  |
-                         | 19.172.IN-ADDR.ARPA  |
-                         | 20.172.IN-ADDR.ARPA  |
-                         | 21.172.IN-ADDR.ARPA  |
-                         | 22.172.IN-ADDR.ARPA  |
-                         | 23.172.IN-ADDR.ARPA  |
-                         | 24.172.IN-ADDR.ARPA  |
-                         | 25.172.IN-ADDR.ARPA  |
-                         | 26.172.IN-ADDR.ARPA  |
-                         | 27.172.IN-ADDR.ARPA  |
-                         | 28.172.IN-ADDR.ARPA  |
-                         | 29.172.IN-ADDR.ARPA  |
-                         | 30.172.IN-ADDR.ARPA  |
-                         | 31.172.IN-ADDR.ARPA  |
-                         | 168.192.IN-ADDR.ARPA |
-                         +----------------------+
-
-4.2.  RFC 5735 and RFC 5737 Zones
-
-   The following zones correspond to those address ranges from [RFC5735]
-   and [RFC5737] that are not expected to appear as source or
-   destination addresses on the public Internet; as such, there are no
-   globally unique names associated with the addresses in these ranges.
-
-
-
-
-
-
-
-
-
-Andrews                   Best Current Practice                 [Page 5]
-
-RFC 6303                Locally Served DNS Zones               July 2011
-
-
-   The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not an
-   attempt to discourage any practice to provide a PTR RR for
-   1.0.0.127.IN-ADDR.ARPA locally.  In fact, a meaningful reverse
-   mapping should exist, but the exact setup is out of the scope of this
-   document.  Similar logic applies to the reverse mapping for ::1
-   (Section 4.3).  The recommendations made here simply assume that no
-   other coverage for these domains exists.
-
-         +------------------------------+-----------------------+
-         | Zone                         | Description           |
-         +------------------------------+-----------------------+
-         | 0.IN-ADDR.ARPA               | IPv4 "THIS" NETWORK   |
-         | 127.IN-ADDR.ARPA             | IPv4 Loopback NETWORK |
-         | 254.169.IN-ADDR.ARPA         | IPv4 LINK LOCAL       |
-         | 2.0.192.IN-ADDR.ARPA         | IPv4 TEST-NET-1       |
-         | 100.51.198.IN-ADDR.ARPA      | IPv4 TEST-NET-2       |
-         | 113.0.203.IN-ADDR.ARPA       | IPv4 TEST-NET-3       |
-         | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST        |
-         +------------------------------+-----------------------+
-
-4.3.  Local IPv6 Unicast Addresses
-
-   The reverse mappings ([RFC3596], Section 2.5 ("IP6.ARPA Domain")) for
-   the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC4291],
-   Sections 2.4, 2.5.2, and 2.5.3) are covered by these two zones:
-
-               +-------------------------------------------+
-               | Zone                                      |
-               +-------------------------------------------+
-               | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
-               |     0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA      |
-               | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
-               |     0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA      |
-               +-------------------------------------------+
-
-   Note: Line breaks and escapes ('\') have been inserted above for
-   readability and to adhere to line width constraints.  They are not
-   parts of the zone names.
-
-4.4.  IPv6 Locally Assigned Local Addresses
-
-   Section 4.4 of [RFC4193] already required special treatment of:
-
-                             +--------------+
-                             | Zone         |
-                             +--------------+
-                             | D.F.IP6.ARPA |
-                             +--------------+
-
-
-
-Andrews                   Best Current Practice                 [Page 6]
-
-RFC 6303                Locally Served DNS Zones               July 2011
-
-
-4.5.  IPv6 Link-Local Addresses
-
-   IPv6 Link-Local Addresses as described in [RFC4291], Section 2.5.6
-   are covered by four distinct reverse DNS zones:
-
-                            +----------------+
-                            | Zone           |
-                            +----------------+
-                            | 8.E.F.IP6.ARPA |
-                            | 9.E.F.IP6.ARPA |
-                            | A.E.F.IP6.ARPA |
-                            | B.E.F.IP6.ARPA |
-                            +----------------+
-
-4.6.  IPv6 Example Prefix
-
-   IPv6 example prefix [RFC3849].
-
-                       +--------------------------+
-                       | Zone                     |
-                       +--------------------------+
-                       | 8.B.D.0.1.0.0.2.IP6.ARPA |
-                       +--------------------------+
-
-   Note: 8.B.D.0.1.0.0.2.IP6.ARPA is not being used as an example here.
-
-5.  Zones That Are Out of Scope
-
-   IPv6 site-local addresses (deprecated, see [RFC4291] Sections 2.4 and
-   2.5.7), and IPv6 non-locally assigned local addresses ([RFC4193]) are
-   not covered here.
-
-   It is expected that IPv6 site-local addresses will be self correcting
-   as IPv6 implementations remove support for site-local addresses.
-   However, sacrificial servers for the zones C.E.F.IP6.ARPA through
-   F.E.F.IP6.ARPA may still need to be deployed in the short term if the
-   traffic becomes excessive.
-
-   For IPv6 non-locally assigned local addresses (L = 0) [RFC4193],
-   there has been no decision made about whether the Regional Internet
-   Registries (RIRs) will provide delegations in this space or not.  If
-   they don't, then C.F.IP6.ARPA will need to be added to the list in
-   Section 4.4.  If they do, then registries will need to take steps to
-   ensure that nameservers are provided for these addresses.
-
-
-
-
-
-
-
-Andrews                   Best Current Practice                 [Page 7]
-
-RFC 6303                Locally Served DNS Zones               July 2011
-
-
-   IP6.INT was once used to provide reverse mapping for IPv6.  IP6.INT
-   was deprecated in [RFC4159] and the delegation removed from the INT
-   zone in June 2006.  While it is possible that legacy software
-   continues to send queries for names under the IP6.INT domain, this
-   document does not specify that IP6.INT be considered a local zone.
-
-   This document has also deliberately ignored names immediately under
-   the root domain.  While there is a subset of queries to the root
-   nameservers that could be addressed using the techniques described
-   here (e.g., .local, .workgroup, and IPv4 addresses), there is also a
-   vast amount of traffic that requires a different strategy (e.g.,
-   lookups for unqualified hostnames, IPv6 addresses).
-
-6.  IANA Considerations
-
-   IANA has established a registry of zones that require this default
-   behaviour.  The initial contents of this registry are defined in
-   Section 4.  Implementors are encouraged to periodically check this
-   registry and adjust their implementations to reflect changes therein.
-
-   This registry can be amended through "IETF Review" as per [RFC5226].
-   As part of this review process, it should be noted that once a zone
-   is added it is effectively added permanently; once an address range
-   starts being configured as a local zone in systems on the Internet,
-   it will be impossible to reverse those changes.
-
-   IANA should coordinate with the RIRs to ensure that, as DNS Security
-   (DNSSEC) is deployed in the reverse tree, delegations for these zones
-   are made in the manner described in Section 7.
-
-7.  Security Considerations
-
-   During the initial deployment phase, particularly where [RFC1918]
-   addresses are in use, there may be some clients that unexpectedly
-   receive a name error rather than a PTR record.  This may cause some
-   service disruption until their recursive nameserver(s) have been
-   re-configured.
-
-   As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
-   namespaces, the zones listed above will need to be delegated as
-   insecure delegations, or be within insecure zones.  This will allow
-   DNSSEC validation to succeed for queries in these spaces despite not
-   being answered from the delegated servers.
-
-   It is recommended that sites actively using these namespaces secure
-   them using DNSSEC [RFC4035] by publishing and using DNSSEC trust
-   anchors.  This will protect the clients from accidental import of
-   unsigned responses from the Internet.
-
-
-
-Andrews                   Best Current Practice                 [Page 8]
-
-RFC 6303                Locally Served DNS Zones               July 2011
-
-
-8.  Acknowledgements
-
-   This work was supported by the US National Science Foundation
-   (research grant SCI-0427144) and DNS-OARC.
-
-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.
-
-   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
-              and E. Lear, "Address Allocation for Private Internets",
-              BCP 5, RFC 1918, February 1996.
-
-   [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 (DNS UPDATE)",
-              RFC 2136, April 1997.
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2308, March 1998.
-
-   [RFC2606]  Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
-              Names", BCP 32, RFC 2606, June 1999.
-
-   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
-              "DNS Extensions to Support IP Version 6", RFC 3596,
-              October 2003.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4159]  Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
-              August 2005.
-
-   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
-              Addresses", RFC 4193, October 2005.
-
-
-
-
-
-
-Andrews                   Best Current Practice                 [Page 9]
-
-RFC 6303                Locally Served DNS Zones               July 2011
-
-
-   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
-              Architecture", RFC 4291, February 2006.
-
-   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
-              May 2008.
-
-9.2.  Informative References
-
-   [AS112]    "AS112 Project", <http://www.as112.net/>.
-
-   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
-              Reserved for Documentation", RFC 3849, July 2004.
-
-   [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
-              BCP 153, RFC 5735, January 2010.
-
-   [RFC5737]  Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
-              Reserved for Documentation", RFC 5737, January 2010.
-
-   [RFC6304]  Abley, J. and W. Maton, "AS112 Nameserver Operations",
-              RFC 6304, July 2011.
-
-   [RFC6305]  Abley, J. and W. Maton, "I'm Being Attacked by
-              PRISONER.IANA.ORG!", RFC 6305, July 2011.
-
-Author's Address
-
-   Mark P. Andrews
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA  94063
-   US
-
-   EMail: marka@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                   Best Current Practice                [Page 10]
-
diff --git a/doc/rfc/rfc952.txt b/doc/rfc/rfc952.txt
deleted file mode 100644
index 7df339a2..00000000
--- a/doc/rfc/rfc952.txt
+++ /dev/null
@@ -1,340 +0,0 @@
-Network Working Group                               K. Harrenstien (SRI)
-Request for Comments: 952                                 M. Stahl (SRI)
-                                                        E. Feinler (SRI)
-Obsoletes:  RFC 810, 608                                    October 1985
-
-                 DOD INTERNET HOST TABLE SPECIFICATION
-
-
-STATUS OF THIS MEMO
-
-   This RFC is the official specification of the format of the Internet
-   Host Table.  This edition of the specification includes minor
-   revisions to RFC-810 which brings it up to date. Distribution of this
-   memo is unlimited.
-
-INTRODUCTION
-
-   The DoD Host Table is utilized by the DoD Hostname Server maintained
-   by the DDN Network Information Center (NIC) on behalf of the Defense
-   Communications Agency (DCA) [See RFC-953].
-
-LOCATION OF THE STANDARD DOD ONLINE HOST TABLE
-
-   A machine-translatable ASCII text version of the DoD Host Table is
-   online in the file NETINFO:HOSTS.TXT on the SRI-NIC host.  It can be
-   obtained via FTP from your local host by connecting to host
-   SRI-NIC.ARPA (26.0.0.73 or 10.0.0.51), logging in as user =
-   ANONYMOUS, password = GUEST, and retrieving the file
-   "NETINFO:HOSTS.TXT".  The same table may also be obtained via the NIC
-   Hostname Server, as described in RFC-953.  The latter method is
-   faster and easier, but requires a user program to make the necessary
-   connection to the Name Server.
-
-ASSUMPTIONS
-
-   1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
-   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
-   sign (-), and period (.).  Note that periods are only allowed when
-   they serve to delimit components of "domain style names". (See
-   RFC-921, "Domain Name System Implementation Schedule", for
-   background).  No blank or space characters are permitted as part of a
-   name. No distinction is made between upper and lower case.  The first
-   character must be an alpha character.  The last character must not be
-   a minus sign or period.  A host which serves as a GATEWAY should have
-   "-GATEWAY" or "-GW" as part of its name.  Hosts which do not serve as
-   Internet gateways should not use "-GATEWAY" and "-GW" as part of
-   their names. A host which is a TAC should have "-TAC" as the last
-   part of its host name, if it is a DoD host.  Single character names
-   or nicknames are not allowed.
-
-   2. Internet Addresses are 32-bit addresses [See RFC-796].  In the
-
-
-Harrenstien & Stahl & Feinler                                   [Page 1]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-   host table described herein each address is represented by four
-   decimal numbers separated by a period.  Each decimal number
-   represents 1 octet.
-
-   3. If the first bit of the first octet of the address is 0 (zero),
-   then the next 7 bits of the first octet indicate the network number
-   (Class A Address).  If the first two bits are 1,0 (one,zero), then
-   the next 14 bits define the net number (Class B Address).  If the
-   first 3 bits are 1,1,0 (one,one,zero), then the next 21 bits define
-   the net number (Class C Address) [See RFC-943].
-
-      This is depicted in the following diagram:
-
-      +-+------------+--------------+--------------+--------------+
-      |0|  NET <-7-> |         LOCAL ADDRESS <-24->               |
-      +-+------------+--------------+--------------+--------------+
-
-      +---+----------+--------------+--------------+--------------+
-      |1 0|      NET  <-14->        |  LOCAL ADDRESS <-16->       |
-      +---+----------+--------------+--------------+--------------+
-
-      +-----+--------+--------------+--------------+--------------+
-      |1 1 0|            NET  <-21->               | LOCAL ADDRESS|
-      +-----+--------+--------------+--------------+--------------+
-
-   4. The LOCAL ADDRESS portion of the internet address identifies a
-   host within the network specified by the NET portion of the address.
-
-   5. The ARPANET and MILNET are both Class A networks.  The NET portion
-   is 10 decimal for ARPANET, 26 decimal for MILNET, and the LOCAL
-   ADDRESS maps as follows: the second octet identifies the physical
-   host, the third octet identifies the logical host, and the fourth
-   identifies the Packet Switching Node (PSN), formerly known as an
-   Interface Message Processor (IMP).
-
-      +-+------------+--------------+--------------+--------------+
-      |0|  10 or 26  |    HOST      | LOGICAL HOST |   PSN (IMP)  |
-      +-+------------+--------------+--------------+--------------+
-
-      (NOTE:  RFC-796 also describes the local address mappings for
-      several other networks.)
-
-   6. It is the responsibility of the users of this host table to
-   translate it into whatever format is needed for their purposes.
-
-   7. Names and addresses for DoD hosts and gateways will be negotiated
-   and registered with the DDN PMO, and subsequently with the NIC,
-
-
-Harrenstien & Stahl & Feinler                                   [Page 2]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-   before being used and before traffic is passed by a DoD host.  Names
-   and addresses for domains and networks are to be registered with the
-   DDN Network Information Center (HOSTMASTER@SRI-NIC.ARPA) or
-   800-235-3155.
-
-   The NIC will attempt to keep similar information for non-DoD networks
-   and hosts, if this information is provided, and as long as it is
-   needed, i.e., until intercommunicating network name servers are in
-   place.
-
-EXAMPLE OF HOST TABLE FORMAT
-
-   NET : 10.0.0.0 : ARPANET :
-   NET : 128.10.0.0 : PURDUE-CS-NET :
-   GATEWAY : 10.0.0.77, 18.10.0.4 : MIT-GW.ARPA,MIT-GATEWAY : PDP-11 :
-             MOS : IP/GW,EGP :
-   HOST : 26.0.0.73, 10.0.0.51 : SRI-NIC.ARPA,SRI-NIC,NIC : DEC-2060 :
-          TOPS20 :TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,TCP/ECHO,ICMP :
-   HOST : 10.2.0.11 : SU-TAC.ARPA,SU-TAC : C/30 : TAC : TCP :
-
-SYNTAX AND CONVENTIONS
-
-   ; (semicolon)   is used to denote the beginning of a comment.
-                   Any text on a given line following a ';' is a
-                   comment, and not part of the host table.
-
-   NET             keyword introducing a network entry
-
-   GATEWAY         keyword introducing a gateway entry
-
-   HOST            keyword introducing a host entry
-
-   DOMAIN          keyword introducing a domain entry
-
-   :(colon)        is used as a field delimiter
-
-   ::(2 colons)    indicates a null field
-
-   ,(comma)        is used as a data element delimiter
-
-   XXX/YYY         indicates protocol information of the type
-                   TRANSPORT/SERVICE.
-
-      where TRANSPORT/SERVICE options are specified as
-
-         "FOO/BAR"       both transport and service known
-
-
-
-Harrenstien & Stahl & Feinler                                   [Page 3]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-         "FOO"           transport known; services not known
-
-         "BAR"           service is known, transport not known
-
-         NOTE:  See "Assigned Numbers" for specific options and acronyms
-         for machine types, operating systems, and protocol/services.
-
-   Each host table entry is an ASCII text string comprised of 6 fields,
-   where
-
-      Field 1         KEYWORD indicating whether this entry pertains to
-                      a NET, GATEWAY, HOST, or DOMAIN.  NET entries are
-                      assigned and cannot have alternate addresses or
-                      nicknames.  DOMAIN entries do not use fields 4, 5,
-                      or 6.
-
-      Field 2         Internet Address of Network, Gateway, or Host
-                      followed by alternate addresses.  Addresses for a
-                      Domain are those where a Domain Name Server exists
-                      for that domain.
-
-      Field 3         Official Name of Network, Gateway, Host, or Domain
-                      (with optional nicknames, where permitted).
-
-      Field 4         Machine Type
-
-      Field 5         Operating System
-
-      Field 6         Protocol List
-
-   Fields 4, 5 and 6 are optional.  For a Domain they are not used.
-
-   Fields 3-6, if included, pertain to the first address in Field 2.
-
-   'Blanks' (spaces and tabs) are ignored between data elements or
-   fields, but are disallowed within a data element.
-
-   Each entry ends with a colon.
-
-   The entries in the table are grouped by types in the order Domain,
-   Net, Gateway, and Host.  Within each type the ordering is
-   unspecified.
-
-   Note that although optional nicknames are allowed for hosts, they are
-   discouraged, except in the case where host names have been changed
-
-
-
-
-Harrenstien & Stahl & Feinler                                   [Page 4]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-   and both the new and the old names are maintained for a suitable
-   period of time to effect a smooth transition.  Nicknames are not
-   permitted for NET names.
-
-GRAMMATICAL HOST TABLE SPECIFICATION
-
-   A. Parsing grammar
-
-      <entry> ::= <keyword> ":" <addresses> ":" <names> [":" [<cputype>]
-         [":" [<opsys>]  [":" [<protocol list>] ]]] ":"
-      <addresses> ::= <address> *["," <address>]
-      <address> ::= <octet> "." <octet> "." <octet> "." <octet>
-      <octet> ::= <0 to 255 decimal>
-      <names> ::= <netname> | <gatename> | <domainname> *[","
-         <nicknames>]
-         | <official hostname> *["," <nicknames>]
-      <netname>  ::= <name>
-      <gatename> ::= <hname>
-      <domainname> ::= <hname>
-      <official hostname> ::= <hname>
-      <nickname> ::= <hname>
-      <protocol list> ::= <protocol spec> *["," <protocol spec>]
-      <protocol spec> ::= <transport name> "/" <service name>
-         | <raw protocol name>
-
-   B. Lexical grammar
-
-      <entry-field> ::= <entry-text> [<cr><lf> <blank> <entry-field>]
-      <entry-text>  ::= <print-char> *<text>
-      <blank> ::= <space-or-tab> [<blank>]
-      <keyword> ::= NET | GATEWAY | HOST | DOMAIN
-      <hname> ::= <name>*["."<name>]
-      <name>  ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
-      <cputype> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc.
-      <opsys>   ::= ITS | MULTICS | TOPS20 | UNIX...etc.
-      <transport name> ::= TCP | NCP | UDP | IP...etc.
-      <service name> ::= TELNET | FTP | SMTP | MTP...etc.
-      <raw protocol name> ::= <name>
-      <comment> ::= ";" <text><cr><lf>
-      <text>    ::= *[<print-char> | <blank>]
-      <print-char>  ::= <any printing char (not space or tab)>
-
-   Notes:
-
-      1. Zero or more 'blanks' between separators " , : " are allowed.
-      'Blanks' are spaces and tabs.
-
-
-
-Harrenstien & Stahl & Feinler                                   [Page 5]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-      2. Continuation lines are lines that begin with at least one
-      blank.  They may be used anywhere 'blanks' are legal to split an
-      entry across lines.
-
-BIBLIOGRAPHY
-
-   1. Feinler, E., Harrenstien, K., Su, Z. and White, V., "Official DoD
-      Internet Host Table Specification", RFC-810, Network Information
-      Center, SRI International, March 1982.
-
-   2. Harrenstien, K., Stahl, M., and Feinler, E., "Hostname Server",
-      RFC-953, Network Information Center, SRI International, October
-      1985.
-
-   3. Kudlick, M. "Host Names Online", RFC-608, Network Information
-      Center, SRI International, January 1973.
-
-   4. Postel, J., "Internet Protocol", RFC-791, Information Sciences
-      Institute, University of Southern California, Marina del Rey,
-      September 1981.
-
-   5. Postel, J., "Address Mappings", RFC-796, Information Sciences
-      Institute, University of Southern California, Marina del Rey,
-      September 1981.
-
-   6. Postel, J., "Domain Name System Implementation Schedule", RFC-921,
-      Information Sciences Institute, University of Southern California,
-      Marina del Rey, October 1984.
-
-   7. Reynolds, J. and Postel, J., "Assigned Numbers", RFC-943,
-      Information Sciences Institute, University of Southern California,
-      Marina del Rey, April 1985.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Harrenstien & Stahl & Feinler                                   [Page 6]
-
diff --git a/lib/bind9/api b/lib/bind9/api
index 2a59ac92..e34aa945 100644
--- a/lib/bind9/api
+++ b/lib/bind9/api
@@ -1,3 +1,8 @@
+# LIBINTERFACE ranges
+# 9.6: 50-59, 110-119
+# 9.7: 60-79
+# 9.8: 80-89
+# 9.9: 90-109
 LIBINTERFACE = 90
 LIBREVISION = 2
 LIBAGE = 0
diff --git a/lib/dns/api b/lib/dns/api
index 63ac0c79..332a0c54 100644
--- a/lib/dns/api
+++ b/lib/dns/api
@@ -1,3 +1,8 @@
-LIBINTERFACE = 92
+# LIBINTERFACE ranges
+# 9.6: 50-59, 110-119
+# 9.7: 60-79
+# 9.8: 80-89
+# 9.9: 90-109
+LIBINTERFACE = 93
 LIBREVISION = 0
 LIBAGE = 0
diff --git a/lib/dns/include/dns/time.h b/lib/dns/include/dns/time.h
index 3771e9a8..7281a334 100644
--- a/lib/dns/include/dns/time.h
+++ b/lib/dns/include/dns/time.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2012  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: time.h,v 1.17 2007-06-19 23:47:17 tbox Exp $ */
+/* $Id: time.h,v 1.19 2012-01-27 23:46:58 tbox Exp $ */
 
 #ifndef DNS_TIME_H
 #define DNS_TIME_H 1
@@ -67,6 +67,12 @@ dns_time32_totext(isc_uint32_t value, isc_buffer_t *target);
  * current date is chosen.
  */
 
+isc_int64_t
+dns_time64_from32(isc_uint32_t value);
+/*%<
+ * Covert a 32-bit cyclic time value into a 64 bit time stamp.
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_TIME_H */
diff --git a/lib/dns/include/dns/zone.h b/lib/dns/include/dns/zone.h
index 765f73fa..d5cb5b98 100644
--- a/lib/dns/include/dns/zone.h
+++ b/lib/dns/include/dns/zone.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2011  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2012  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zone.h,v 1.199 2011-12-22 07:32:41 each Exp $ */
+/* $Id: zone.h,v 1.201 2012-01-25 23:46:49 tbox Exp $ */
 
 #ifndef DNS_ZONE_H
 #define DNS_ZONE_H 1
@@ -2007,7 +2007,7 @@ dns_zone_getserialupdatemethod(dns_zone_t *zone);
  * \li	'zone' to be valid.
  */
 
-void
+isc_result_t
 dns_zone_link(dns_zone_t *zone, dns_zone_t *raw);
 
 void
diff --git a/lib/dns/nsec3.c b/lib/dns/nsec3.c
index 2217e5c9..d7e120ed 100644
--- a/lib/dns/nsec3.c
+++ b/lib/dns/nsec3.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2006, 2008-2011  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2006, 2008-2012  Internet Systems Consortium, Inc. ("ISC")
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: nsec3.c,v 1.24 2011-10-28 06:20:06 each Exp $ */
+/* $Id: nsec3.c,v 1.26 2012-01-27 23:46:58 tbox Exp $ */
 
 #include <config.h>
 
@@ -1788,7 +1788,7 @@ dns_nsec3_maxiterations(dns_db_t *db, dns_dbversion_t *version,
 	dst_key_t *key = NULL;
 	isc_buffer_t buffer;
 	isc_result_t result;
-	isc_uint16_t bits, minbits = 4096;
+	unsigned int bits, minbits = 4096;
 
 	result = dns_db_getoriginnode(db, &node);
 	if (result != ISC_R_SUCCESS)
@@ -1815,7 +1815,7 @@ dns_nsec3_maxiterations(dns_db_t *db, dns_dbversion_t *version,
 		isc_buffer_add(&buffer, rdata.length);
 		CHECK(dst_key_fromdns(dns_db_origin(db), rdataset.rdclass,
 				      &buffer, mctx, &key));
-		bits = dst_key_getbits(key);
+		bits = dst_key_size(key);
 		dst_key_free(&key);
 		if (minbits > bits)
 			minbits = bits;
diff --git a/lib/dns/rbtdb.c b/lib/dns/rbtdb.c
index 7091a399..961fe1e3 100644
--- a/lib/dns/rbtdb.c
+++ b/lib/dns/rbtdb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2011  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2012  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbtdb.c,v 1.323 2011-12-07 22:21:05 marka Exp $ */
+/* $Id: rbtdb.c,v 1.326 2012-01-04 23:46:49 tbox Exp $ */
 
 /*! \file */
 
diff --git a/lib/dns/tests/Makefile.in b/lib/dns/tests/Makefile.in
index 8e802d73..191ff7d9 100644
--- a/lib/dns/tests/Makefile.in
+++ b/lib/dns/tests/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2011, 2012  Internet Systems Consortium, Inc. ("ISC")
 #
 # Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.12 2011-12-08 16:07:21 each Exp $
+# $Id: Makefile.in,v 1.14 2012-01-27 23:46:58 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -39,12 +39,13 @@ LIBS =		@LIBS@ @ATFLIBS@
 OBJS =		dnstest.@O@
 SRCS =		dnstest.c master_test.c dbiterator_test.c time_test.c \
 		private_test.c update_test.c zonemgr_test.c zt_test.c \
-		dbdiff_test.c
+		dbdiff_test.c nsec3_test.c
 
 SUBDIRS =
 TARGETS =	master_test@EXEEXT@ dbiterator_test@EXEEXT@ time_test@EXEEXT@ \
 		private_test@EXEEXT@ update_test@EXEEXT@ zonemgr_test@EXEEXT@ \
-		zt_test@EXEEXT@ dbversion_test@EXEEXT@ dbdiff_test@EXEEXT@
+		zt_test@EXEEXT@ dbversion_test@EXEEXT@ dbdiff_test@EXEEXT@ \
+		nsec3_test@EXEEXT@
 
 @BIND9_MAKE_RULES@
 
@@ -99,6 +100,11 @@ zt_test@EXEEXT@: zt_test.@O@ dnstest.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
 			zt_test.@O@ dnstest.@O@ ${DNSLIBS} \
 				${ISCLIBS} ${LIBS}
 
+nsec3_test@EXEEXT@: nsec3_test.@O@ dnstest.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \
+			nsec3_test.@O@ dnstest.@O@ ${DNSLIBS} \
+				${ISCLIBS} ${LIBS}
+
 unit::
 	sh ${top_srcdir}/unit/unittest.sh
 
diff --git a/lib/dns/tests/nsec3_test.c b/lib/dns/tests/nsec3_test.c
new file mode 100644
index 00000000..3867ac8e
--- /dev/null
+++ b/lib/dns/tests/nsec3_test.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2012  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/* $Id: nsec3_test.c,v 1.2 2012-01-27 00:49:42 marka Exp $ */
+
+/*! \file */
+
+#include <config.h>
+
+#include <atf-c.h>
+
+#include <unistd.h>
+
+#include <dns/db.h>
+#include <dns/nsec3.h>
+
+#include "dnstest.h"
+
+/*
+ * Helper functions
+ */
+
+static void
+iteration_test(const char* file, unsigned int expected) {
+	isc_result_t result;
+	dns_db_t *db = NULL;
+	unsigned int iterations;
+
+	result = dns_test_begin(NULL, ISC_FALSE);
+	ATF_REQUIRE_EQ(result, ISC_R_SUCCESS);
+
+	result = dns_test_loaddb(&db, dns_dbtype_zone, "test", file);
+	ATF_REQUIRE_EQ(result, ISC_R_SUCCESS);
+
+	result = dns_nsec3_maxiterations(db, NULL, mctx, &iterations);
+	ATF_REQUIRE_EQ(result, ISC_R_SUCCESS);
+
+	ATF_REQUIRE_EQ(iterations, expected);
+
+	dns_db_detach(&db);
+
+	dns_test_end();
+}
+
+/*
+ * Individual unit tests
+ */
+
+ATF_TC(max_iterations);
+ATF_TC_HEAD(max_iterations, tc) {
+	atf_tc_set_md_var(tc, "descr", "check that appropriate max iterations "
+			  " is returned for different key size mixes");
+}
+ATF_TC_BODY(max_iterations, tc) {
+
+	UNUSED(tc);
+
+	iteration_test("testdata/nsec3/1024.db", 150);
+	iteration_test("testdata/nsec3/2048.db", 500);
+	iteration_test("testdata/nsec3/4096.db", 2500);
+	iteration_test("testdata/nsec3/min-1024.db", 150);
+	iteration_test("testdata/nsec3/min-2048.db", 500);
+}
+
+/*
+ * Main
+ */
+ATF_TP_ADD_TCS(tp) {
+	ATF_TP_ADD_TC(tp, max_iterations);
+
+	return (atf_no_error());
+}
+
diff --git a/lib/dns/tests/testdata/nsec3/1024.db b/lib/dns/tests/testdata/nsec3/1024.db
new file mode 100644
index 00000000..3d9c43bf
--- /dev/null
+++ b/lib/dns/tests/testdata/nsec3/1024.db
@@ -0,0 +1,21 @@
+; Copyright (C) 2012  Internet Systems Consortium, Inc. ("ISC")
+;
+; Permission to use, copy, modify, and/or distribute this software for any
+; purpose with or without fee is hereby granted, provided that the above
+; copyright notice and this permission notice appear in all copies.
+;
+; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+; AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+; PERFORMANCE OF THIS SOFTWARE.
+
+; $Id: 1024.db,v 1.3 2012-01-27 23:46:58 tbox Exp $
+
+$TTL 0
+test. SOA . . 0 0 0 0 0
+test. NS .
+; 1024 bit key.
+test. IN DNSKEY 256 3 5 AwEAAd5oKx06HRE6NRrTDz49lljdRmxgp/4YB/cyMkpwUMkaLhDNCfTq hql84ab2LRbtUWLHFXGWENvxPGQzVHeleXu+3ThNfFOwIaySedxHmLGT lTtBRDhPc8iSb+2IYDemmA+ut8kwHhCVz/tDMbD/dgAswdOtmXCpQyJk Q1HqY3Xj
diff --git a/lib/dns/tests/testdata/nsec3/2048.db b/lib/dns/tests/testdata/nsec3/2048.db
new file mode 100644
index 00000000..bc263ed9
--- /dev/null
+++ b/lib/dns/tests/testdata/nsec3/2048.db
@@ -0,0 +1,21 @@
+; Copyright (C) 2012  Internet Systems Consortium, Inc. ("ISC")
+;
+; Permission to use, copy, modify, and/or distribute this software for any
+; purpose with or without fee is hereby granted, provided that the above
+; copyright notice and this permission notice appear in all copies.
+;
+; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+; AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+; PERFORMANCE OF THIS SOFTWARE.
+
+; $Id: 2048.db,v 1.3 2012-01-27 23:46:58 tbox Exp $
+
+$TTL 0
+test. SOA . . 0 0 0 0 0
+test. NS .
+; 2048 bits
+test. IN DNSKEY 256 3 5 AwEAAcfQX59iZr9gK+XzhTZQ5KWrfCLA0iYHTqheEIhC2dXS8gUSppQS g9SmzH2129u/LSSb7gqJSoLLAsn36iinqCqUXl2BT6xzwznbSP3mn0hn N6DegsykcYhHycKH6ifjZiMN+SGGeNsi5rhoW5Cj9ptw3C3yQnrFNDbS GZCT97z5lpQU3ZcvP4RDNk7dhri7Bh3SJeaCFoqx00NgFvlBR48hosSG bGUbUKzNf58GBTkW4Us2jIWsreZx8LLLev232Hy7NU9L19k+hVq7pJOf Uvtrn5fmGSutWOzsR+8EacOnh0lwssCKjutk5MSmfdFC5P7CTZkdq58L 8he13HGmr00=
diff --git a/lib/dns/tests/testdata/nsec3/4096.db b/lib/dns/tests/testdata/nsec3/4096.db
new file mode 100644
index 00000000..cc54d75a
--- /dev/null
+++ b/lib/dns/tests/testdata/nsec3/4096.db
@@ -0,0 +1,21 @@
+; Copyright (C) 2012  Internet Systems Consortium, Inc. ("ISC")
+;
+; Permission to use, copy, modify, and/or distribute this software for any
+; purpose with or without fee is hereby granted, provided that the above
+; copyright notice and this permission notice appear in all copies.
+;
+; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+; AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+; PERFORMANCE OF THIS SOFTWARE.
+
+; $Id: 4096.db,v 1.3 2012-01-27 23:46:58 tbox Exp $
+
+$TTL 0
+test. SOA . . 0 0 0 0 0
+test. NS .
+; 4096 bits
+test. IN DNSKEY 256 3 5 AwEAAbYlqbKxXoq9mzkqdsAaSZ3XywBVAb2sCTgrQBCExyGEYNpWw3LN +imCrLQi7jHKQW6GZIqKNgQaiFEwr3zK8nPWbwNwyKU9a2hhINv/gim1 5iA87Vu7DiiJrQ0O79ospvsGsKknBQ41zaaQMp3Q/W1S6WNe4uyh4C/f R0qmxT+8MyXEqCpTGb+e+YT6BuqpNQPuYYYvUJ1/HJltzY/lY2b9RZ+Q ZJ23Zje79YIRM0kJapqj11fDUDeynhDL1DUikYCwRfQiO/blChhOHjIa uTK1qqRY3fqanLGOufpLTr7GRpL7RxeRIMJfDzmcjFLmCsMA1AJ56Bxq jiXr3ODgn9D30vAB74Lr7lqLQSWyrSlJjoZLLhmPrEP/nnuCxEhOhDRA XJpJWpcQ4Hdu+yb5K/qldnsGLLI1Hr0GmhLTDHsxDb6BxM7/8rv8QeQY GKSGshBqD2lO1xUVT8inbi8uXI1iyN68vHX6xoFT5wsjls70PxSZPO5i F40vn6BWNsHtKWOCDqMKYx8hYwiv0zETVwxBaj58vylFwYGU+g1wIQmF Pgi2HKv4KaxgikUvdFISre5rxVoG5VrmmXWiNJcLTbwZ+tE1xujCNU1c V31CaIB5hdSnkEvQADr5V64RTxWAKuSLNMU+XUqTkaJHasSm3OPJOteo SPj2uoesuxNFYps3
diff --git a/lib/dns/tests/testdata/nsec3/min-1024.db b/lib/dns/tests/testdata/nsec3/min-1024.db
new file mode 100644
index 00000000..026ad9b0
--- /dev/null
+++ b/lib/dns/tests/testdata/nsec3/min-1024.db
@@ -0,0 +1,25 @@
+; Copyright (C) 2012  Internet Systems Consortium, Inc. ("ISC")
+;
+; Permission to use, copy, modify, and/or distribute this software for any
+; purpose with or without fee is hereby granted, provided that the above
+; copyright notice and this permission notice appear in all copies.
+;
+; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+; AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+; PERFORMANCE OF THIS SOFTWARE.
+
+; $Id: min-1024.db,v 1.3 2012-01-27 23:46:58 tbox Exp $
+
+$TTL 0
+test. SOA . . 0 0 0 0 0
+test. NS .
+; 1024 bit key.
+test. IN DNSKEY 256 3 5 AwEAAd5oKx06HRE6NRrTDz49lljdRmxgp/4YB/cyMkpwUMkaLhDNCfTq hql84ab2LRbtUWLHFXGWENvxPGQzVHeleXu+3ThNfFOwIaySedxHmLGT lTtBRDhPc8iSb+2IYDemmA+ut8kwHhCVz/tDMbD/dgAswdOtmXCpQyJk Q1HqY3Xj
+; 2048 bits
+test. IN DNSKEY 256 3 5 AwEAAcfQX59iZr9gK+XzhTZQ5KWrfCLA0iYHTqheEIhC2dXS8gUSppQS g9SmzH2129u/LSSb7gqJSoLLAsn36iinqCqUXl2BT6xzwznbSP3mn0hn N6DegsykcYhHycKH6ifjZiMN+SGGeNsi5rhoW5Cj9ptw3C3yQnrFNDbS GZCT97z5lpQU3ZcvP4RDNk7dhri7Bh3SJeaCFoqx00NgFvlBR48hosSG bGUbUKzNf58GBTkW4Us2jIWsreZx8LLLev232Hy7NU9L19k+hVq7pJOf Uvtrn5fmGSutWOzsR+8EacOnh0lwssCKjutk5MSmfdFC5P7CTZkdq58L 8he13HGmr00=
+; 4096 bits
+test. IN DNSKEY 256 3 5 AwEAAbYlqbKxXoq9mzkqdsAaSZ3XywBVAb2sCTgrQBCExyGEYNpWw3LN +imCrLQi7jHKQW6GZIqKNgQaiFEwr3zK8nPWbwNwyKU9a2hhINv/gim1 5iA87Vu7DiiJrQ0O79ospvsGsKknBQ41zaaQMp3Q/W1S6WNe4uyh4C/f R0qmxT+8MyXEqCpTGb+e+YT6BuqpNQPuYYYvUJ1/HJltzY/lY2b9RZ+Q ZJ23Zje79YIRM0kJapqj11fDUDeynhDL1DUikYCwRfQiO/blChhOHjIa uTK1qqRY3fqanLGOufpLTr7GRpL7RxeRIMJfDzmcjFLmCsMA1AJ56Bxq jiXr3ODgn9D30vAB74Lr7lqLQSWyrSlJjoZLLhmPrEP/nnuCxEhOhDRA XJpJWpcQ4Hdu+yb5K/qldnsGLLI1Hr0GmhLTDHsxDb6BxM7/8rv8QeQY GKSGshBqD2lO1xUVT8inbi8uXI1iyN68vHX6xoFT5wsjls70PxSZPO5i F40vn6BWNsHtKWOCDqMKYx8hYwiv0zETVwxBaj58vylFwYGU+g1wIQmF Pgi2HKv4KaxgikUvdFISre5rxVoG5VrmmXWiNJcLTbwZ+tE1xujCNU1c V31CaIB5hdSnkEvQADr5V64RTxWAKuSLNMU+XUqTkaJHasSm3OPJOteo SPj2uoesuxNFYps3
diff --git a/lib/dns/tests/testdata/nsec3/min-2048.db b/lib/dns/tests/testdata/nsec3/min-2048.db
new file mode 100644
index 00000000..e9dc6a64
--- /dev/null
+++ b/lib/dns/tests/testdata/nsec3/min-2048.db
@@ -0,0 +1,23 @@
+; Copyright (C) 2012  Internet Systems Consortium, Inc. ("ISC")
+;
+; Permission to use, copy, modify, and/or distribute this software for any
+; purpose with or without fee is hereby granted, provided that the above
+; copyright notice and this permission notice appear in all copies.
+;
+; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+; AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+; PERFORMANCE OF THIS SOFTWARE.
+
+; $Id: min-2048.db,v 1.3 2012-01-27 23:46:58 tbox Exp $
+
+$TTL 0
+test. SOA . . 0 0 0 0 0
+test. NS .
+; 2048 bits
+test. IN DNSKEY 256 3 5 AwEAAcfQX59iZr9gK+XzhTZQ5KWrfCLA0iYHTqheEIhC2dXS8gUSppQS g9SmzH2129u/LSSb7gqJSoLLAsn36iinqCqUXl2BT6xzwznbSP3mn0hn N6DegsykcYhHycKH6ifjZiMN+SGGeNsi5rhoW5Cj9ptw3C3yQnrFNDbS GZCT97z5lpQU3ZcvP4RDNk7dhri7Bh3SJeaCFoqx00NgFvlBR48hosSG bGUbUKzNf58GBTkW4Us2jIWsreZx8LLLev232Hy7NU9L19k+hVq7pJOf Uvtrn5fmGSutWOzsR+8EacOnh0lwssCKjutk5MSmfdFC5P7CTZkdq58L 8he13HGmr00=
+; 4096 bits
+test. IN DNSKEY 256 3 5 AwEAAbYlqbKxXoq9mzkqdsAaSZ3XywBVAb2sCTgrQBCExyGEYNpWw3LN +imCrLQi7jHKQW6GZIqKNgQaiFEwr3zK8nPWbwNwyKU9a2hhINv/gim1 5iA87Vu7DiiJrQ0O79ospvsGsKknBQ41zaaQMp3Q/W1S6WNe4uyh4C/f R0qmxT+8MyXEqCpTGb+e+YT6BuqpNQPuYYYvUJ1/HJltzY/lY2b9RZ+Q ZJ23Zje79YIRM0kJapqj11fDUDeynhDL1DUikYCwRfQiO/blChhOHjIa uTK1qqRY3fqanLGOufpLTr7GRpL7RxeRIMJfDzmcjFLmCsMA1AJ56Bxq jiXr3ODgn9D30vAB74Lr7lqLQSWyrSlJjoZLLhmPrEP/nnuCxEhOhDRA XJpJWpcQ4Hdu+yb5K/qldnsGLLI1Hr0GmhLTDHsxDb6BxM7/8rv8QeQY GKSGshBqD2lO1xUVT8inbi8uXI1iyN68vHX6xoFT5wsjls70PxSZPO5i F40vn6BWNsHtKWOCDqMKYx8hYwiv0zETVwxBaj58vylFwYGU+g1wIQmF Pgi2HKv4KaxgikUvdFISre5rxVoG5VrmmXWiNJcLTbwZ+tE1xujCNU1c V31CaIB5hdSnkEvQADr5V64RTxWAKuSLNMU+XUqTkaJHasSm3OPJOteo SPj2uoesuxNFYps3
diff --git a/lib/dns/time.c b/lib/dns/time.c
index 48b67777..42d3184d 100644
--- a/lib/dns/time.c
+++ b/lib/dns/time.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007, 2009-2011  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009-2012  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: time.c,v 1.37 2011-03-09 23:47:17 tbox Exp $ */
+/* $Id: time.c,v 1.39 2012-01-27 23:46:58 tbox Exp $ */
 
 /*! \file */
 
@@ -103,8 +103,8 @@ dns_time64_totext(isc_int64_t t, isc_buffer_t *target) {
 	return (ISC_R_SUCCESS);
 }
 
-isc_result_t
-dns_time32_totext(isc_uint32_t value, isc_buffer_t *target) {
+isc_int64_t
+dns_time64_from32(isc_uint32_t value) {
 	isc_stdtime_t now;
 	isc_int64_t start;
 	isc_int64_t t;
@@ -121,7 +121,13 @@ dns_time32_totext(isc_uint32_t value, isc_buffer_t *target) {
 		t = start + (value - now);
 	else
 		t = start - (now - value);
-	return (dns_time64_totext(t, target));
+
+	return (t);
+}
+
+isc_result_t
+dns_time32_totext(isc_uint32_t value, isc_buffer_t *target) {
+	return (dns_time64_totext(dns_time64_from32(value), target));
 }
 
 isc_result_t
diff --git a/lib/dns/win32/libdns.def b/lib/dns/win32/libdns.def
index 615d068f..bf16469f 100644
--- a/lib/dns/win32/libdns.def
+++ b/lib/dns/win32/libdns.def
@@ -686,6 +686,7 @@ dns_tcpmsg_readmessage
 dns_tcpmsg_setmaxsize
 dns_time32_fromtext
 dns_time32_totext
+dns_time64_from32
 dns_time64_fromtext
 dns_time64_totext
 dns_timer_setidle
diff --git a/lib/dns/zone.c b/lib/dns/zone.c
index 30e35227..171ea698 100644
--- a/lib/dns/zone.c
+++ b/lib/dns/zone.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2011  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2012  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zone.c,v 1.658 2011-12-22 07:32:41 each Exp $ */
+/* $Id: zone.c,v 1.667.2.1 2012-01-31 01:11:55 each Exp $ */
 
 /*! \file */
 
@@ -76,6 +76,7 @@
 #include <dns/soa.h>
 #include <dns/ssu.h>
 #include <dns/stats.h>
+#include <dns/time.h>
 #include <dns/tsig.h>
 #include <dns/update.h>
 #include <dns/xfrin.h>
@@ -655,7 +656,7 @@ static void zone_name_tostr(dns_zone_t *zone, char *buf, size_t length);
 static void zone_rdclass_tostr(dns_zone_t *zone, char *buf, size_t length);
 static void zone_viewname_tostr(dns_zone_t *zone, char *buf, size_t length);
 static isc_result_t zone_send_secureserial(dns_zone_t *zone,
-					   isc_boolean_t locked,
+					   isc_boolean_t secure_locked,
 					   isc_uint32_t serial);
 
 #if 0
@@ -1491,15 +1492,20 @@ zone_load(dns_zone_t *zone, unsigned int flags) {
 
 	REQUIRE(DNS_ZONE_VALID(zone));
 
-	LOCK_ZONE(zone);
-	TIME_NOW(&now);
-
 	if (inline_secure(zone)) {
 		result = zone_load(zone->raw, flags);
 		if (result != ISC_R_SUCCESS)
-			goto cleanup;
+			return(result);
 	}
 
+	/*
+	 * Lock hierachy zmgr, raw, zone.
+	 */
+	if (inline_secure(zone))
+		LOCK_ZONE(zone->raw);
+	LOCK_ZONE(zone);
+	TIME_NOW(&now);
+
 	INSIST(zone->type != dns_zone_none);
 
 	if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_LOADING)) {
@@ -1652,6 +1658,8 @@ zone_load(dns_zone_t *zone, unsigned int flags) {
 
  cleanup:
 	UNLOCK_ZONE(zone);
+	if (inline_secure(zone))
+		UNLOCK_ZONE(zone->raw);
 	if (db != NULL)
 		dns_db_detach(&db);
 	return (result);
@@ -1795,9 +1803,9 @@ get_master_options(dns_zone_t *zone) {
 		options |= DNS_MASTER_CHECKMXFAIL;
 	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKWILDCARD))
 		options |= DNS_MASTER_CHECKWILDCARD;
-	if (zone->type == dns_zone_master &&
+	if (inline_secure(zone) || (zone->type == dns_zone_master &&
 	    ((zone->update_acl != NULL && !dns_acl_isnone(zone->update_acl)) ||
-	      zone->ssutable != NULL))
+	      zone->ssutable != NULL)))
 		options |= DNS_MASTER_RESIGN;
 	return (options);
 }
@@ -3561,7 +3569,6 @@ maybe_send_secure(dns_zone_t *zone) {
 	 * loaded, we set a flag so that it will send the necessary
 	 * information when it has finished loading.
 	 */
-	LOCK_ZONE(zone->raw);
 	if (zone->raw->db != NULL) {
 		if (zone->db != NULL) {
 			isc_uint32_t serial;
@@ -3569,15 +3576,12 @@ maybe_send_secure(dns_zone_t *zone) {
 						  NULL, NULL, &serial, NULL,
 						  NULL, NULL, NULL, NULL);
 			if (result == ISC_R_SUCCESS)
-				zone_send_secureserial(zone->raw, ISC_TRUE,
-						       serial);
+				zone_send_secureserial(zone->raw, ISC_TRUE, serial);
 		} else
 			zone_send_securedb(zone->raw, ISC_TRUE, zone->raw->db);
-	
+
 	} else
 		DNS_ZONE_SETFLAG(zone->raw, DNS_ZONEFLG_SENDSECURE);
-
-	UNLOCK_ZONE(zone->raw);
 }
 
 static isc_boolean_t
@@ -3764,9 +3768,7 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime,
 		}
 	}
 
-	zone->loadtime = loadtime;
-
-	dns_zone_log(zone, ISC_LOG_DEBUG(1), "loaded");
+	dns_zone_log(zone, ISC_LOG_DEBUG(1), "loaded; checking validity");
 
 	/*
 	 * Master / Slave / Stub zones require both NS and SOA records at
@@ -4029,6 +4031,7 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime,
 		dns_zone_log(zone, ISC_LOG_INFO, "loaded serial %u%s", serial,
 			     dns_db_issecure(db) ? " (DNSSEC signed)" : "");
 
+	zone->loadtime = loadtime;
 	DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_LOADPENDING);
 	return (result);
 
@@ -4048,8 +4051,11 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime,
 			zone_settimer(zone, &now);
 		result = ISC_R_SUCCESS;
 	} else if (zone->type == dns_zone_master ||
-		   zone->type == dns_zone_redirect)
-		dns_zone_log(zone, ISC_LOG_ERROR, "not loaded due to errors.");
+		   zone->type == dns_zone_redirect) {
+		if (!(inline_secure(zone) && result == ISC_R_FILENOTFOUND))
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "not loaded due to errors.");
+	}
 
 	return (result);
 }
@@ -5074,7 +5080,7 @@ del_sigs(dns_zone_t *zone, dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
 	unsigned int i;
 	dns_rdata_rrsig_t rrsig;
 	isc_boolean_t found, changed;
-	isc_stdtime_t warn = 0, maybe = 0;
+	isc_int64_t warn = 0, maybe = 0;
 
 	dns_rdataset_init(&rdataset);
 
@@ -5176,21 +5182,20 @@ del_sigs(dns_zone_t *zone, dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
 				 * iff there is a new offline signature.
 				 */
 				if (!dst_key_isprivate(keys[i])) {
-					if (warn != 0 &&
-					    warn > rrsig.timeexpire)
-						warn = rrsig.timeexpire;
+					isc_int64_t timeexpire =
+					   dns_time64_from32(rrsig.timeexpire);
+					if (warn != 0 && warn > timeexpire)
+						warn = timeexpire;
 					if (rdata.flags & DNS_RDATA_OFFLINE) {
 						if (maybe == 0 ||
-						    maybe > rrsig.timeexpire)
-							maybe =
-							     rrsig.timeexpire;
+						    maybe > timeexpire)
+							maybe = timeexpire;
 						break;
 					}
 					if (warn == 0)
 						warn = maybe;
-					if (warn == 0 ||
-					    warn > rrsig.timeexpire)
-						warn = rrsig.timeexpire;
+					if (warn == 0 || warn > timeexpire)
+						warn = timeexpire;
 					result = offline(db, ver, diff, name,
 							 rdataset.ttl, &rdata);
 					break;
@@ -5221,8 +5226,18 @@ del_sigs(dns_zone_t *zone, dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
 	dns_rdataset_disassociate(&rdataset);
 	if (result == ISC_R_NOMORE)
 		result = ISC_R_SUCCESS;
-	if (warn != 0)
-		set_key_expiry_warning(zone, warn, now);
+	if (warn > 0) {
+#if defined(STDTIME_ON_32BITS)
+		isc_stdtime_t stdwarn = (isc_stdtime_t)warn;
+		if (warn == stdwarn)
+#endif
+			set_key_expiry_warning(zone, (isc_stdtime_t)warn, now);
+#if defined(STDTIME_ON_32BITS)
+		else
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "key expiry warning time out of range");
+#endif
+	}
  failure:
 	if (node != NULL)
 		dns_db_detachnode(db, &node);
@@ -12188,45 +12203,45 @@ sync_secure_journal(dns_zone_t *zone, dns_journal_t *journal,
 		    isc_uint32_t start, isc_uint32_t end,
 		    dns_difftuple_t **soatuplep, dns_diff_t *diff)
 {
- 	isc_result_t result;
- 	dns_difftuple_t *tuple = NULL;
+	isc_result_t result;
+	dns_difftuple_t *tuple = NULL;
 	dns_diffop_t op = DNS_DIFFOP_ADD;
 	int n_soa = 0;
 
 	REQUIRE(soatuplep != NULL);
 
- 	if (start == end)
+	if (start == end)
 		return (DNS_R_UNCHANGED);
 
 	CHECK(dns_journal_iter_init(journal, start, end));
 	for (result = dns_journal_first_rr(journal);
- 	     result == ISC_R_SUCCESS;
+	     result == ISC_R_SUCCESS;
 	     result = dns_journal_next_rr(journal))
 	{
- 		dns_name_t *name = NULL;
- 		isc_uint32_t ttl;
- 		dns_rdata_t *rdata = NULL;
+		dns_name_t *name = NULL;
+		isc_uint32_t ttl;
+		dns_rdata_t *rdata = NULL;
 		dns_journal_current_rr(journal, &name, &ttl, &rdata);
- 
- 		if (rdata->type == dns_rdatatype_soa) {
- 			n_soa++;
- 			if (n_soa == 2) {
- 				/*
+
+		if (rdata->type == dns_rdatatype_soa) {
+			n_soa++;
+			if (n_soa == 2) {
+				/*
 				 * Save the latest raw SOA record.
- 				 */
- 				if (*soatuplep != NULL)
- 					dns_difftuple_free(soatuplep);
+				 */
+				if (*soatuplep != NULL)
+					dns_difftuple_free(soatuplep);
 				CHECK(dns_difftuple_create(diff->mctx,
- 							   DNS_DIFFOP_ADD,
- 							   name, ttl, rdata,
- 							   soatuplep));
- 			}
- 			if (n_soa == 3)
- 				n_soa = 1;
+							   DNS_DIFFOP_ADD,
+							   name, ttl, rdata,
+							   soatuplep));
+			}
+			if (n_soa == 3)
+				n_soa = 1;
 			continue;
 		}
 
- 		/* Sanity. */
+		/* Sanity. */
 		if (n_soa == 0) {
 			dns_zone_log(zone->raw, ISC_LOG_ERROR,
 				     "corrupt journal file: '%s'\n",
@@ -12251,8 +12266,8 @@ sync_secure_journal(dns_zone_t *zone, dns_journal_t *journal,
 					   &tuple));
 		dns_diff_appendminimal(diff, &tuple);
 	}
- 	if (result == ISC_R_NOMORE)
- 		result = ISC_R_SUCCESS;
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
 
  failure:
 	return(result);
@@ -12457,7 +12472,7 @@ receive_secure_serial(isc_task_t *task, isc_event_t *event) {
 
 static isc_result_t
 zone_send_secureserial(dns_zone_t *zone, isc_boolean_t locked,
-		      isc_uint32_t serial)
+		       isc_uint32_t serial)
 {
 	isc_event_t *e;
 	dns_zone_t *dummy = NULL;
@@ -12474,6 +12489,7 @@ zone_send_secureserial(dns_zone_t *zone, isc_boolean_t locked,
 	else
 		dns_zone_iattach(zone->secure, &dummy);
 	isc_task_send(zone->secure->task, &e);
+
 	DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_SENDSECURE);
 	return (ISC_R_SUCCESS);
 }
@@ -12561,11 +12577,18 @@ receive_secure_db(isc_task_t *task, isc_event_t *event) {
 	}
 
 	dns_db_closeversion(db, &version, ISC_TRUE);
+	/*
+	 * Lock hierachy zmgr, raw, zone.
+	 */
+	if (inline_secure(zone))
+		LOCK_ZONE(zone->raw);
 	LOCK_ZONE(zone);
 	DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NEEDNOTIFY);
 	result = zone_postload(zone, db, loadtime, ISC_R_SUCCESS);
 	zone_needdump(zone, 0); /* XXXMPA */
 	UNLOCK_ZONE(zone);
+	if (inline_secure(zone))
+		UNLOCK_ZONE(zone->raw);
 
  failure:
 	if (result != ISC_R_SUCCESS)
@@ -13088,6 +13111,11 @@ zone_loaddone(void *arg, isc_result_t result) {
 	    (result == ISC_R_SUCCESS || result == DNS_R_SEENINCLUDE))
 		result = tresult;
 
+	/*
+	 * Lock hierachy zmgr, raw, zone.
+	 */
+	if (inline_secure(zone))
+		LOCK_ZONE(zone->raw);
 	LOCK_ZONE(load->zone);
 	(void)zone_postload(load->zone, load->db, load->loadtime, result);
 	zonemgr_putio(&load->zone->readio);
@@ -13101,6 +13129,8 @@ zone_loaddone(void *arg, isc_result_t result) {
 		zone->update_disabled = ISC_FALSE;
 	DNS_ZONE_CLRFLAG(load->zone, DNS_ZONEFLG_THAW);
 	UNLOCK_ZONE(load->zone);
+	if (inline_secure(zone))
+		UNLOCK_ZONE(zone->raw);
 
 	load->magic = 0;
 	dns_db_detach(&load->db);
@@ -13876,7 +13906,7 @@ dns_zonemgr_setsize(dns_zonemgr_t *zmgr, int num_zones) {
 		zmgr->zonetasks = pool;
 
 	pool = NULL;
-	if (zmgr->loadtasks  == NULL)
+	if (zmgr->loadtasks == NULL)
 		result = isc_taskpool_create(zmgr->taskmgr, zmgr->mctx,
 					     ntasks, 2, &pool);
 	else
@@ -15632,9 +15662,16 @@ dns_zone_dlzpostload(dns_zone_t *zone, dns_db_t *db)
 	isc_result_t result;
 	TIME_NOW(&loadtime);
 
+	/*
+	 * Lock hierachy zmgr, raw, zone.
+	 */
+	if (inline_secure(zone))
+		LOCK_ZONE(zone->raw);
 	LOCK_ZONE(zone);
 	result = zone_postload(zone, db, loadtime, ISC_R_SUCCESS);
 	UNLOCK_ZONE(zone);
+	if (inline_secure(zone))
+		UNLOCK_ZONE(zone->raw);
 	return result;
 }
 
@@ -15675,22 +15712,63 @@ dns_zone_getserialupdatemethod(dns_zone_t *zone) {
 	return(zone->updatemethod);
 }
 
-void
+/*
+ * Lock hierachy zmgr, raw, zone.
+ */
+isc_result_t
 dns_zone_link(dns_zone_t *zone, dns_zone_t *raw) {
+	isc_result_t result;
+	dns_zonemgr_t *zmgr;
+
 	REQUIRE(DNS_ZONE_VALID(zone));
+	REQUIRE(zone->zmgr != NULL);
+	REQUIRE(zone->task != NULL);
+	REQUIRE(zone->loadtask != NULL);
+	REQUIRE(zone->raw == NULL);
+
 	REQUIRE(DNS_ZONE_VALID(raw));
+	REQUIRE(raw->zmgr == NULL);
+	REQUIRE(raw->task == NULL);
+	REQUIRE(raw->loadtask == NULL);
+	REQUIRE(raw->secure == NULL);
 
-	LOCK(&zone->lock);
-	if (zone->raw != NULL)
-		dns_zone_detach(&zone->raw);
-	dns_zone_attach(raw, &zone->raw);
-	UNLOCK(&zone->lock);
+	zmgr = zone->zmgr;
+	RWLOCK(&zmgr->rwlock, isc_rwlocktype_write);
+	LOCK_ZONE(raw);
+	LOCK_ZONE(zone);
 
-	LOCK(&raw->lock);
-	if (raw->secure != NULL)
-		dns_zone_idetach(&raw->secure);
-	dns_zone_iattach(zone, &raw->secure);
-	UNLOCK(&raw->lock);
+	result = isc_timer_create(zmgr->timermgr, isc_timertype_inactive,
+				  NULL, NULL, zone->task, zone_timer, raw,
+				  &raw->timer);
+	if (result != ISC_R_SUCCESS)
+		goto unlock;
+
+	/*
+	 * The timer "holds" a iref.
+	 */
+	raw->irefs++;
+	INSIST(raw->irefs != 0);
+
+
+	/* dns_zone_attach(raw, &zone->raw); */
+	isc_refcount_increment(&raw->erefs, NULL);
+	zone->raw = raw;
+
+	/* dns_zone_iattach(zone,  &raw->secure); */
+	zone_iattach(zone, &raw->secure);
+
+	isc_task_attach(zone->task, &raw->task);
+	isc_task_attach(zone->loadtask, &raw->loadtask);
+
+	ISC_LIST_APPEND(zmgr->zones, raw, link);
+	raw->zmgr = zmgr;
+	zmgr->refs++;
+
+ unlock:
+	UNLOCK_ZONE(zone);
+	UNLOCK_ZONE(raw);
+	RWUNLOCK(&zmgr->rwlock, isc_rwlocktype_write);
+	return (result);
 }
 
 void
@@ -15874,14 +15952,11 @@ dns_zone_keydone(dns_zone_t *zone, const char *keystr) {
 		else
 			CHECK(ISC_R_FAILURE);
 
-		DE_CONST(algstr, r.base);
-		r.length = strlen(algstr);
-		result = dns_secalg_fromtext(&alg, (isc_textregion_t *) &r);
-
-		if (result != ISC_R_SUCCESS) {
-			n = sscanf(algstr, "%hhd", &alg);
-			if (n == 0)
-				CHECK(result);
+		n = sscanf(algstr, "%hhd", &alg);
+		if (n == 0) {
+			DE_CONST(algstr, r.base);
+			r.length = strlen(algstr);
+			CHECK(dns_secalg_fromtext(&alg, &r));
 		}
 
 		/* construct a private-type rdata */
diff --git a/lib/irs/api b/lib/irs/api
index 3d2fa6ef..a45a6bff 100644
--- a/lib/irs/api
+++ b/lib/irs/api
@@ -1,3 +1,8 @@
+# LIBINTERFACE ranges
+# 9.6: 50-59, 110-119
+# 9.7: 60-79
+# 9.8: 80-89
+# 9.9: 90-109
 LIBINTERFACE = 90
 LIBREVISION = 0
 LIBAGE = 0
diff --git a/lib/isc/api b/lib/isc/api
index 2a59ac92..8a3bcf60 100644
--- a/lib/isc/api
+++ b/lib/isc/api
@@ -1,3 +1,8 @@
-LIBINTERFACE = 90
-LIBREVISION = 2
-LIBAGE = 0
+# LIBINTERFACE ranges
+# 9.6: 50-59, 110-119
+# 9.7: 60-79
+# 9.8: 80-89
+# 9.9: 90-109
+LIBINTERFACE = 91
+LIBREVISION = 0
+LIBAGE = 1
diff --git a/lib/isc/include/isc/result.h b/lib/isc/include/isc/result.h
index cc591dc3..e6d46c9d 100644
--- a/lib/isc/include/isc/result.h
+++ b/lib/isc/include/isc/result.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009, 2012  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.h,v 1.73 2009-09-02 23:48:03 tbox Exp $ */
+/* $Id: result.h,v 1.75 2012-01-27 23:46:59 tbox Exp $ */
 
 #ifndef ISC_RESULT_H
 #define ISC_RESULT_H 1
@@ -87,9 +87,10 @@
 #define ISC_R_MAXSIZE			58	/*%< max size */
 #define ISC_R_BADADDRESSFORM		59	/*%< invalid address format */
 #define ISC_R_BADBASE32			60	/*%< bad base32 encoding */
+#define ISC_R_UNSET			61	/*%< unset */
 
 /*% Not a result code: the number of results. */
-#define ISC_R_NRESULTS 			61
+#define ISC_R_NRESULTS 			62
 
 ISC_LANG_BEGINDECLS
 
diff --git a/lib/isc/result.c b/lib/isc/result.c
index fcb52952..67971d23 100644
--- a/lib/isc/result.c
+++ b/lib/isc/result.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008, 2012  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.c,v 1.71 2008-09-25 04:02:39 tbox Exp $ */
+/* $Id: result.c,v 1.73 2012-01-27 23:46:59 tbox Exp $ */
 
 /*! \file */
 
@@ -102,6 +102,7 @@ static const char *text[ISC_R_NRESULTS] = {
 	"max size",				/*%< 58 */
 	"invalid address format",		/*%< 59 */
 	"bad base32 encoding",			/*%< 60 */
+	"unset",				/*%< 61 */
 };
 
 #define ISC_RESULT_RESULTSET			2
diff --git a/lib/isc/unix/socket.c b/lib/isc/unix/socket.c
index e24d887d..2bf09159 100644
--- a/lib/isc/unix/socket.c
+++ b/lib/isc/unix/socket.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2011  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2012  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: socket.c,v 1.349 2011-11-29 01:03:47 marka Exp $ */
+/* $Id: socket.c,v 1.351 2012-01-27 23:46:59 tbox Exp $ */
 
 /*! \file */
 
@@ -1595,7 +1595,7 @@ allocate_socketevent(isc__socket_t *sock, isc_eventtype_t eventtype,
 	if (ev == NULL)
 		return (NULL);
 
-	ev->result = ISC_R_UNEXPECTED;
+	ev->result = ISC_R_UNSET;
 	ISC_LINK_INIT(ev, ev_link);
 	ISC_LIST_INIT(ev->bufferlist);
 	ev->region.base = NULL;
@@ -2048,8 +2048,6 @@ allocate_socket(isc__socketmgr_t *manager, isc_sockettype_t type,
 	if (sock == NULL)
 		return (ISC_R_NOMEMORY);
 
-	result = ISC_R_UNEXPECTED;
-
 	sock->common.magic = 0;
 	sock->common.impmagic = 0;
 	sock->references = 0;
@@ -2078,8 +2076,10 @@ allocate_socket(isc__socketmgr_t *manager, isc_sockettype_t type,
 	sock->recvcmsgbuflen = cmsgbuflen;
 	if (sock->recvcmsgbuflen != 0U) {
 		sock->recvcmsgbuf = isc_mem_get(manager->mctx, cmsgbuflen);
-		if (sock->recvcmsgbuf == NULL)
+		if (sock->recvcmsgbuf == NULL) {
+			result = ISC_R_NOMEMORY;
 			goto error;
+		}
 	}
 
 	cmsgbuflen = 0;
@@ -2096,8 +2096,10 @@ allocate_socket(isc__socketmgr_t *manager, isc_sockettype_t type,
 	sock->sendcmsgbuflen = cmsgbuflen;
 	if (sock->sendcmsgbuflen != 0U) {
 		sock->sendcmsgbuf = isc_mem_get(manager->mctx, cmsgbuflen);
-		if (sock->sendcmsgbuf == NULL)
+		if (sock->sendcmsgbuf == NULL) {
+			result = ISC_R_NOMEMORY;
 			goto error;
+		}
 	}
 
 	memset(sock->name, 0, sizeof(sock->name));
@@ -2235,7 +2237,9 @@ clear_bsdcompat(void) {
 
 static isc_result_t
 opensocket(isc__socketmgr_t *manager, isc__socket_t *sock,
-	   isc__socket_t *dup_socket) {
+	   isc__socket_t *dup_socket)
+{
+	isc_result_t result;
 	char strbuf[ISC_STRERRORSIZE];
 	const char *err = "socket";
 	int tries = 0;
@@ -2350,9 +2354,10 @@ opensocket(isc__socketmgr_t *manager, isc__socket_t *sock,
 	if (dup_socket != NULL)
 		goto setup_done;
 
-	if (make_nonblock(sock->fd) != ISC_R_SUCCESS) {
+	result = make_nonblock(sock->fd);
+	if (result != ISC_R_SUCCESS) {
 		(void)close(sock->fd);
-		return (ISC_R_UNEXPECTED);
+		return (result);
 	}
 
 #ifdef SO_BSDCOMPAT
@@ -3247,10 +3252,12 @@ internal_accept(isc_task_t *me, isc_event_t *ev) {
 
 	UNLOCK(&sock->lock);
 
-	if (fd != -1 && (make_nonblock(fd) != ISC_R_SUCCESS)) {
-		(void)close(fd);
-		fd = -1;
-		result = ISC_R_UNEXPECTED;
+	if (fd != -1) {
+		result = make_nonblock(fd);
+		if (result != ISC_R_SUCCESS) {
+			(void)close(fd);
+			fd = -1;
+		}
 	}
 
 	/*
@@ -4609,7 +4616,7 @@ isc__socket_recv2(isc_socket_t *sock0, isc_region_t *region,
 	isc__socket_t *sock = (isc__socket_t *)sock0;
 
 	event->ev_sender = sock;
-	event->result = ISC_R_UNEXPECTED;
+	event->result = ISC_R_UNSET;
 	ISC_LIST_INIT(event->bufferlist);
 	event->region = *region;
 	event->n = 0;
@@ -4823,7 +4830,7 @@ isc__socket_sendto2(isc_socket_t *sock0, isc_region_t *region,
 	if ((flags & ISC_SOCKFLAG_NORETRY) != 0)
 		REQUIRE(sock->type == isc_sockettype_udp);
 	event->ev_sender = sock;
-	event->result = ISC_R_UNEXPECTED;
+	event->result = ISC_R_UNSET;
 	ISC_LIST_INIT(event->bufferlist);
 	event->region = *region;
 	event->n = 0;
diff --git a/lib/isccc/api b/lib/isccc/api
index 3d2fa6ef..a45a6bff 100644
--- a/lib/isccc/api
+++ b/lib/isccc/api
@@ -1,3 +1,8 @@
+# LIBINTERFACE ranges
+# 9.6: 50-59, 110-119
+# 9.7: 60-79
+# 9.8: 80-89
+# 9.9: 90-109
 LIBINTERFACE = 90
 LIBREVISION = 0
 LIBAGE = 0
diff --git a/lib/isccfg/api b/lib/isccfg/api
index 6404d993..59e4f66c 100644
--- a/lib/isccfg/api
+++ b/lib/isccfg/api
@@ -1,3 +1,8 @@
+# LIBINTERFACE ranges
+# 9.6: 50-59, 110-119
+# 9.7: 60-79
+# 9.8: 80-89
+# 9.9: 90-109
 LIBINTERFACE = 90
 LIBREVISION = 1
 LIBAGE = 0
diff --git a/lib/lwres/api b/lib/lwres/api
index 3d2fa6ef..a45a6bff 100644
--- a/lib/lwres/api
+++ b/lib/lwres/api
@@ -1,3 +1,8 @@
+# LIBINTERFACE ranges
+# 9.6: 50-59, 110-119
+# 9.7: 60-79
+# 9.8: 80-89
+# 9.9: 90-109
 LIBINTERFACE = 90
 LIBREVISION = 0
 LIBAGE = 0
diff --git a/unit/atf-src/atf-version/generate-revision.sh b/unit/atf-src/atf-version/generate-revision.sh
index e7d4d3da..68ae6de1 100755
--- a/unit/atf-src/atf-version/generate-revision.sh
+++ b/unit/atf-src/atf-version/generate-revision.sh
@@ -35,7 +35,7 @@
 
 set -e
 
-Prog_Name=${0##*/}
+Prog_Name=`echo "${0}" | sed 's;.*/;;'`
 
 MTN=
 ROOT=
@@ -90,7 +90,7 @@ BEGIN {
 #    rev_date: The date of the revision.
 #
 get_rev_info_into_vars() {
-    rev_base_id=$(call_mtn automate get_base_revision_id)
+    rev_base_id=`call_mtn automate get_base_revision_id`
 
     if call_mtn status | grep "no changes" >/dev/null; then
         rev_modified=false
@@ -99,7 +99,7 @@ get_rev_info_into_vars() {
     fi
 
     # The following defines several rev_* variables.
-    eval $(extract_certs ${rev_base_id})
+    eval `extract_certs ${rev_base_id}`
 }
 
 #
diff --git a/version b/version
index 0f1ff743..5e0e30ce 100644
--- a/version
+++ b/version
@@ -1,4 +1,4 @@
-# $Id: version,v 1.59 2011-12-22 17:49:49 each Exp $
+# $Id: version,v 1.60.2.1 2012-01-31 01:16:31 each Exp $
 # 
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
@@ -7,4 +7,4 @@ MAJORVER=9
 MINORVER=9
 PATCHVER=0
 RELEASETYPE=rc
-RELEASEVER=1
+RELEASEVER=2